Управление на преноса към Central от страницата за състояние
Central е изключен при нова болнична инсталация. След включване връзката е само за изпращане: Hospital създава криптирани и подписани пакети и ги изпраща. Central няма маршрут, данни за вход или роля в базата данни, с които да чете или записва в болничната база.
Две независими заключвания
/status/control разделя две действия. Всеки формуляр отново изисква текущата
парола на системния администратор и създава отделен одитен запис.
- Настройване на преноса използва еднократен токен от Central, HTTPS адрес, код и име на обекта, лечебно заведение, клиентски сертификат и CA на Central. Хешът на настройката не съдържа токена или частен ключ. Локалната настройка и одитът се записват в една транзакция.
- Одобряване на клиничния износ е възможно само след заключване на преноса.
Записва се дали износът е включен, дали има редактиран текст, фиксираният
профил
bg-en-v1, одобрителят, датата, хешът на преноса и причината. Включването на преноса никога не включва автоматично клиничния износ.
Старите промени през клиничен администратор POST /v1/hospital/enroll,
PUT /v1/hospital/export-policy и POST /v1/hospital/deliveries връщат
404 без кеширане в 1.2.1. Те заобикаляха независимото потвърждение с парола,
реда на двете заключвания или ограниченото одитирано повторно изпращане. Старите GET
изгледи за политиката и историята остават само за четене; чрез тях не може да
се включи пренос, да се одобри износ или да се започне изпращане.
Автоматично изпращане и оттегляне в клиничното приложение
След задаване на общите заключвания за пренос и клиничен износ в Status всеки подходящ финализиран случай автоматично се поставя за изпращане. Черновите, незавършените случаи и случаите, които още са в срока за отмяна на финализирането, остават локални. Няма първоначално включване, одобряване или изключване на отделен случай.
Hospital Web показва ограниченото Central състояние на Member, финализирал
случая, на HOD за съответното лечебно заведение и на clinical Admin. Правото
следва клинициста, който е удостоверил записа, а не този, който го е започнал:
Member, създал случая и предал го на друг, не запазва никакво право върху
доставката. Обичайните права за четене, промяна, финализиране, печат и научен
достъп остават отделни. Страницата /central-delivery показва какво даден
човек е изпратил към Central и в какво състояние е то — единственият изглед в
продукта през всички случаи. Списъкът
съдържа само вътрешен ключ за маршрута, час на финализиране и ограничено
състояние на изпращането. Тези контроли умишлено липсват в Mobile и PWA. Състоянията
различават никога неизпращан, чакащ, приет, чакащ оттегляне, оттеглен и
отхвърлен случай. Никога не се връщат patient identifier, Central pseudonym,
необработен batch identifier, payload или свободен текст от Central грешка.
Приет случай може да бъде оттеглен и по-късно изпратен отново. И при двете действия редът на случая и advisory lock за Central резервацията се заключват преди промяната; действието и ограниченият му одитен запис се записват в една PostgreSQL транзакция. Случай, който вече е резервиран в активен пакет, не може да се променя по време на изпращането; интерфейсът изчаква подписания резултат. Оттеглянето остава чакащо, докато валидното подписано приемане не бъде записано локално, след което става оттеглено. Повторното изпращане поставя нов UPSERT и никога не изтрива или пренаписва болничния случай.
Какво показва страницата
Показват се само оперативни метаданни: произходът на адреса, идентификатори на обекта и лечебното заведение, хеш и дата на заключването, SHA-256 отпечатъци и валидност на клиентския сертификат и CA, идентификатори на ключове, съвместимост и ограничения, дати на свързване и доставка, броячи на опашките, последни пакети, хешове, фиксирани кодове за грешка, опити и подписани разписки.
Никога не се получават или показват токенът, паролата, PEM съдържание, ключове,
данни за базата, идентификатори и клинични полета на случаи, свободен текст за
грешки или самият износ. Нов опит се разрешава само за пакет RETRY или
REJECTED и изисква парола и причина. Както създаването, така и вземането на
вече чакащ пакет изискват пълно заключване на преноса и включено, датирано
одобрение за клиничен износ. Изключена политика не позволява пакетът да бъде
взет или повторен през стар маршрут.
Подготовка и възстановяване
Central първо подписва secrets/api/site-client.csr. Болничният ИТ екип
инсталира сертификата като secrets/api/site-client-cert.pem, а CA като
secrets/api/central-ca.pem. Central създава еднократен токен. След това ИТ
настройва преноса от Status и отделно решава дали да одобри клиничния износ.
Свързването обхваща две отделни системи. Локалната настройка и одитът са една PostgreSQL транзакция, но приемането на токена от отдалечения Central не може да бъде част от същата транзакция. Ако Central приеме заявката, а локалният запис се провали, спрете и съгласувайте обекта в Central, преди да поискате нов токен. Не отслабвайте одита или сертификатните проверки за сляп повторен опит.