Експлоатация

Списък за проверка

Всеки ред казва къде да се погледне. Status е https://<клиничен адрес>/status/; командите се изпълняват в конзолата на системата.

Всеки ден

• Изисква внимание днес, в началото на прегледа в Status, е празно или всяка точка в него има отговорник. От конзолата: sudo losporctl status.
• Проверен архив и Потвърждение за външен архив в прегледа са в изправност (Поддръжка → Копия извън сървъра показва последното копие).
• Прегледайте новите инциденти, неуспешните доставки към Central и събитията за сигурност в прегледа на Status.

Всяка седмица

• Обновявания: проверете дали има нова версия и планирайте прозореца.
• Управление → Външен ИИ: политиката и данните за достъп са както трябва.
• Дисковото пространство и изтичането на сертификата в прегледа не наближават границата.

Всеки месец

• Поддръжка → Пробно възстановяване на най-новия локален архив.
• Профили: премахнете напусналите; потвърдете, че администраторите пазят кодовете си за възстановяване на MFA.
• Поддръжка → Операционна система на сървъра (Ubuntu): няма чакащи обновления за сигурност и не е нужно рестартиране. От конзолата: sudo losporctl host state.

Всяко тримесечие

• Поддръжка → Копия извън сървъра → Проверка от най-новото копие и я отбележете в Готовност.
• Готовност: всяко потвърждение все още е вярно; потвърждението за пробно възстановяване изтича след 92 дни.
• Ако тайните са се променили, съхранете ги отново: Поддръжка → Съхранение на тайните (или sudo losporctl secrets escrow /media/usb).
• Поддръжка → Смяна на данните за достъп (или sudo losporctl secrets rotate, след това sudo losporctl secrets commit), в спокоен период: всички влизат отново. След това съхранете тайните отново в Поддръжка → Съхранение на тайните.

Когато нещо не е наред, sudo losporctl check изпълнява пълната проверка на изправността. Поддръжка → Файл за поддръжка (или sudo losporctl support-bundle create) записва файл за поддръжката на LOSPOR без лични данни и го предлага за изтегляне. Обновявания показва проверено досие за всяка версия: как е изградена, уязвимостите и приетите изключения и какво изисква връщането след миграция. Архивиране и възстановяване съдържа пълните процедури за архивите и копията извън сървъра.

Командата losporctl

losporctl е единствената конзолна команда за болничния ИТ екип. Инсталацията я поставя в /usr/local/bin/losporctl и тя винаги се изпълнява от активната проверена версия. Тя изпълнява собствените скриптове на системата, така че всичко описано за тях остава в сила. Всяка команда освен help и version изисква sudo.

sudo losporctl status
sudo losporctl check
sudo losporctl backup run
sudo losporctl support-bundle create
sudo losporctl update check
sudo losporctl config plan
sudo losporctl host state

status казва с обикновени думи как е системата и дава следващата стъпка за всичко, което изисква внимание. status --json дава същото като един обект за наблюдение. version, backup list, backup offhost state, config show, config advanced и host state също приемат --json и отпечатват по един обект със schemaVersion; всяка команда, която променя системата, отказва --json с изходен код 2. support-bundle create записва файл за поддръжката на LOSPOR само с версии, състояния, времена и резултати от проверки: без пациенти, случаи, акаунти, имена, адреси или тайни. Командата показва файла, за да може да бъде прочетен преди изпращане. Команда, която рестартира услуги (config apply, update apply, update offline, secrets commit, secrets rollback, host reboot, host upgrade), първо казва какво ще стане и иска yes; --yes потвърждава предварително. Изходен код 0 е успех, 1 неуспех, 2 грешна употреба, 3 блокирано от заключване или състояние, 4 нужно е sudo.

Полезни команди

docker compose ps
docker compose logs --since 1h api
docker compose logs --since 1h delivery-worker
docker compose logs --since 1h postgres
docker compose logs --since 1h status
sudo sh /opt/lospor-hospital/current/scripts/backup-now.sh
sudo sh /opt/lospor-hospital/current/scripts/doctor.sh
sudo sh /opt/lospor-hospital/current/scripts/readiness-check.sh
sudo sh /opt/lospor-hospital/current/scripts/appliance-operator.sh state
sudo sh /opt/lospor-hospital/current/scripts/rotate-operational-secrets.sh state

За промени по CIDR или сертификатите използвайте Мрежови и TLS граници, а за управлявания staged import, go-live, rollback и finalize — Импорт на терминология. И двете процедури са fail-closed и имат български изход за оператора и българска документация.

Не публикувайте PostgreSQL, worker route или sockets за управление на контейнери. По време на клинична употреба не редактирайте ръчно редове в базата данни или Status SQLite. Страницата Status съдържа само разрешени operational events; за подробна диагностика използвайте host-only Compose logs с rotation. Няма Sentry или външна услуга за logs/telemetry.

Промяна на настройките на сайта

Болничният ИТ екип отговаря за един файл: /opt/lospor-hospital/site.env. В него са имената, режимът на сертификата, мрежовите ограничения, портовете, подателят на писмата, контактът за поддръжка и прозорецът за обновявания. Файлът site.env.example във версията описва всяка настройка. Тайните и генерираните стойности са в /opt/lospor-hospital/secrets/appliance.env, а .env се компилира от двата файла. Никога не редактирайте тези два файла и не поставяйте тайна в site.env: компилаторът отказва и двете.

Редактирайте site.env, прегледайте промяната и я приложете:

sudo sh /opt/lospor-hospital/current/scripts/apply-site-config.sh --plan
sudo sh /opt/lospor-hospital/current/scripts/apply-site-config.sh --yes

Планът проверява всяка стойност (имена, режим на сертификата, точни мрежи, портове, адреси, контакт за поддръжка, прозорец и часова зона за обновявания), проверява резултата с Compose и показва само настройките, които се променят. Прилагането взема общото заключване за поддръжка, запазва последната работеща конфигурация, оставя Compose да пресъздаде само услугите с променена конфигурация и изпълнява doctor. Ако системата не се възстанови в изправно състояние, предишната конфигурация се връща и стартира отново. Отхвърлената промяна се запазва в .data/config/site.env.rejected. Изходен код 3 означава, че и възстановената конфигурация не е изправна и трябва да се прегледа конзолата.

Адреси, сертификат и портове

Тези три настройки променят адреса, който всички използват, затова се променят от конзолата, никога в Status. Всяка има своя команда. Тя променя само своите настройки, показва плана, иска yes и връща всичко обратно, ако промяната бъде отказана, отменена или системата не е изправна:

sudo losporctl config addresses lospor.hospital.local lospor-research.hospital.local
sudo losporctl config certificate operator /root/fullchain.pem /root/private.key /etc/ssl/certs/hospital-ca.crt
sudo losporctl config certificate acme it@hospital.example
sudo losporctl config certificate local
sudo losporctl config ports 443 3443

За сертификата на болницата командата копира сертификата и ключа на мястото им. След това рестартира входната точка и изпълнява пълната проверка на изправността; ако тя се провали, предишните файлове и настройки се връщат.

Разширени настройки

Няколко стойности за фина настройка имат стойности по подразбиране, подходящи за повечето болници: колко често се правят архиви, колко дълго се пазят, колко свободно място оставят, колко дълго се пазят изследователските експорти и приетите от Central пакети, колко случая влизат в един пакет към Central и колко често системата проверява за нова версия. Болница, която има нужда от друга стойност, я променя в Поддръжка → Разширени настройки, в часове, дни или GB, или от конзолата:

sudo losporctl config advanced
sudo losporctl config advanced set HOSPITAL_BACKUP_INTERVAL_SECONDS 7200
sudo losporctl config advanced reset all

Всяка стойност може да се задава само в твърди граници, които пазят политиките на системата: архив поне на всеки четири часа, всеки архив се пази поне 48 часа и поне 14 дневни архива. Променените стойности се пазят в /opt/lospor-hospital/advanced.env, който не съществува, докато всички стойности са по подразбиране. Промяната се преглежда, прилага и проверява като всяка настройка на сайта, а предишните стойности се връщат, ако системата не е изправна. Status показва разширените настройки, различни от стойностите по подразбиране, в Изисква внимание днес, за да започва разговорът с поддръжката от верните факти.

Обновления за сигурност на Ubuntu

Ubuntu инсталира обновленията за сигурност сам всяка нощ. Поддръжка → Операционна система на сървъра (Ubuntu) показва дали това работи: версията и докога получава поправки за сигурност, колко обновления чакат, как е минало последното автоматично обновяване и дали Ubuntu има нужда от рестартиране. Същото има и в конзолата:

sudo losporctl host state
sudo losporctl host security-update
sudo losporctl host reboot
sudo losporctl host upgrade

• Инсталиране на обновленията за сигурност сега изпълнява същите обновления веднага, в общото заключване за поддръжка, затова никога едновременно с архив или обновяване.
• Рестартиране на сървъра се предлага, когато Ubuntu го поиска. Първо се прави проверен архив; ако той се провали, сървърът не се рестартира. Клиницистите не могат да използват LOSPOR няколко минути, а всички услуги стартират отново сами.
• За да се рестартира системата сама, задайте Рестартиране след обновления на Ubuntu на window в настройките на сайта. Тогава тя прави архив и се рестартира в прозореца за обновяване, когато Ubuntu поиска, най-много веднъж на ден и никога докато чака или върви обновяване. Стойността по подразбиране, manual, оставя това на болничния ИТ екип.
• Собствените обновления на Docker рестартират всички клинични услуги, затова нощното обновяване никога не ги инсталира. sudo losporctl host upgrade инсталира всички обновления, включително Docker, след архив, връща услугите и изпълнява doctor. Изпълнявайте го в прозореца за поддръжка.

Всяка операция се записва в .data/host-os/operations.v1.tsv.

Външен ИИ

Външният ИИ е незадължителен и е отделен от включеното насочване за възрастни/деца. За включване или изключване и за замяна или премахване на credential за Mistral използвайте единствено контрола в Status. Операцията изисква нормална сесия на operator, удостоверена с парола, повторно удостоверяване и причина за одита; console recovery сесия не може да я извършва. Status показва само състоянието на доставчика/конфигурацията и времената. Никога не получава credential или неговия ciphertext.

Не добавяйте MISTRAL_API_KEY към .env или Compose. Единственият поддържан път е API sealing service, защитена чрез secrets/api/external-ai-seal-key. Съхранявайте този файл offline с пълния набор тайни на appliance: загубата или замяната му прави съхранените credentials нечетими и кара възстановяването да спре безопасно преди промяна на базата данни. Вижте Управление на външен ИИ.

readiness-check.sh е само за четене. Изпълнявайте го след промени по хоста, Docker, DNS, storage или time service. Без --strict той съобщава всеки проблем, но връща управлението за диагностика; инсталирането използва strict mode и спира при неизпълнено изискване.

Status при прекъсване

От адрес, разрешен в HOSPITAL_STATUS_ALLOWED_CIDRS, използвайте https://<clinical>/status/. Ако Caddy не е достъпен, създайте tunnel от администраторска workstation към резервния listener, достъпен само през loopback:

ssh -L 3443:127.0.0.1:3443 appliance-admin@hospital-host

След това отворете https://localhost:3443/status/. И двата номера следват HOSPITAL_STATUS_PORT, така че сайт, който го е променил, трябва да тунелира съответния порт. Очаква се предупреждение за локалния self-signed certificate на инсталацията. Status работи при отказ на clinical API/database, но не и при отказ на хоста, Docker daemon, Status container или volume, електрозахранването или болничната мрежа.

Appliance administrator

Appliance operator използва един email/парола в клиничното приложение и Status, защитени с отделни verifiers. След паролата Status допълнително изисква TOTP на системния администратор или един неизползван Status код за възстановяване. Съхранявайте офлайн в хранилището за пароли на болничния ИТ екип десетте еднократни кода, издадени при настройването. Използвайте само координираните host команди:

sudo sh /opt/lospor-hospital/current/scripts/appliance-operator.sh verify
sudo sh /opt/lospor-hospital/current/scripts/appliance-operator.sh state
sudo sh /opt/lospor-hospital/current/scripts/appliance-operator.sh rotate
sudo sh /opt/lospor-hospital/current/scripts/appliance-operator.sh transfer
sudo sh /opt/lospor-hospital/current/scripts/appliance-operator.sh recovery-token

Паролите се въвеждат чрез скрити standard-input prompts. Никога не поставяйте парола в environment variable, argument, shell history или ръчно написан JSON файл. Вижте Наблюдение чрез Status за процедурите за инициализиране, прекъсната промяна, възстановяване и поправка.

Смяна на обикновените данни за достъп

Не променяйте поотделно .env, PostgreSQL роля или токен на Status. Поддържаната процедура на сървъра подготвя защитена транзакция, временно застъпва данните за достъп, когато е необходимо, прилага и проверява новото поколение, доказва отказа на старите стойности и автоматично отменя промяната при неуспех:

Поддръжка → Смяна на данните за достъп в Status прави точно това чрез агента на сървъра, след като администраторът отметне потвърждението и въведе отново паролата. Сменят се ключът за сесиите, токените на работните процеси, токените на Status и двете пароли за базата данни; ключовете за идентичност на пациентите, псевдонимите, шифроването, манифеста на архивите и печатите, ключът за MFA и входовете в Status никога не се сменят. Смяна, която вече чака от конзолата, прекъсната смяна или смяна, чиято отмяна не може да бъде доказана, се оставя на болничния ИТ екип в конзолата със state. Процедурата в конзолата:

sudo sh /opt/lospor-hospital/current/scripts/rotate-operational-secrets.sh prepare ordinary
sudo sh /opt/lospor-hospital/current/scripts/rotate-operational-secrets.sh state
sudo sh /opt/lospor-hospital/current/scripts/rotate-operational-secrets.sh commit

Използвайте rollback, за да отхвърлите или отмените чакаща транзакция. Смяната на ключа за сесии умишлено извежда всички потребители; координираната процедура за паролата на системния оператор по-горе е отделна. Ако state покаже защитен остатък след проверено прилагане, поправете собствеността/правата му и изпълнете sh scripts/rotate-operational-secrets.sh cleanup; почистването не променя активното поколение. Вижте Смяна на оперативните данни за достъп за отделните обхвати, одитните доказателства, ограниченията и приемателното упражнение под Linux.

Акаунти

Саморегистрацията е изключена. Първоначалният administrator създава проверени и одобрени локални потребители. Всеки акаунт принадлежи към институция и получава минимално необходимото role. Премахвайте своевременно напусналите потребители и редовно преглеждайте administrators. Вижте Предоставяне на Hospital акаунти.

Съхранение на данни

Изтрит акаунт не се заличава веднага. Той се маркира като изтрит, а 30 дни по-късно appliance го анонимизира и премахва свързаните с него rate-limit rows. Забавянето позволява отмяна на случайно изтриване; след него заличаването е постоянно и умишлено не може да се възстанови от работещата система.

Purge се изпълнява ежедневно в delivery worker по негов собствен часовник (HOSPITAL_RETENTION_INTERVAL_SECONDS, по подразбиране 86400). Няма отделна услуга и не е необходимо да се настройва host cron.

Страницата Status го отчита под Data retention purge:

Показание	Значение
RETENTION_COMPLETED	Purge е завършил през последните 36 часа.
RETENTION_AGING	Няма успешен резултат от 36 часа. Проучете.
RETENTION_OVERDUE	Няма успешен резултат от 48 часа. Задължението се просрочва.
RETENTION_API_UNAVAILABLE	Worker не е успял да достигне API.
RETENTION_REJECTED	API е отказал заявката; проверете CRON_SECRET.
RETENTION_EHR_STAGING_REJECTED	Изтриването на изтеклите данни от ЕЗД се е провалило.
RETENTION_SIGNAL_MISSING	На този appliance никога не е записван purge.

Същото ежедневно изпълнение изтрива временно пазените данни от ЕЗД. Това е изпратеното от болничната система, което чака преглед от клиницист:

• импортите след изтичане на срока им, заедно с полетата им;
• файловете, запазени от транспорта с папка в processed/ и rejected/.

То никога не засяга входящата папка, в която са още непрочетени файлове, нито изходящата, която болничната система взема. Срокът е 14 дни по подразбиране — най-дългото, за което импорт се предлага на клиницистите. Управление може да го съкрати, но никога да го удължи.

RETENTION_SIGNAL_MISSING се показва като unknown, никога като healthy. Задължение за заличаване, за което никой не може да представи доказателство, не трябва да се показва в зелено.

За незабавно изпълнение, без да чакате ежедневния цикъл:

docker compose exec delivery-worker sh -c \
  'curl -s -H "Authorization: Bearer $CRON_SECRET" \
     http://api:3002/v1/internal/purge-deleted'

Маршрутът е достъпен само във вътрешната мрежа на appliance; не се обслужва през clinical hostname.

Автоматично закриване на случаи

Случай, подаден за преглед, се финализира автоматично след изтичане на тридесетминутния преглед, за да не остане завършен случай отворен само защото никой не се е върнал да го подпише. До 1.3.0 appliance нямаше часовник за това: обхождането се изпълняваше само в serverless инсталацията, а на хоспитален сървър случай се закриваше единствено ако клиницист случайно го е гледал в момента на изтичането.

Обхождането се изпълнява на всеки пет минути в delivery worker, по собствен часовник (HOSPITAL_CASE_CLOSE_INTERVAL_SECONDS, по подразбиране 300). Няма отделна услуга и няма host cron за конфигуриране.

Случай, който не може да бъде закрит — непълна документация — не се закрива. Той се отлага с нарастващо изчакване, за да бъдат достигнати случаите след него, и се финализира при следващо обхождане, след като липсващият запис бъде въведен.

Status страницата го показва под Автоматично закриване на случаи:

Показание	Значение
CASE_CLOSE_COMPLETED	Обхождане е завършило през последните 20 минути.
CASE_CLOSE_AGING	Нищо не е успяло от 20 минути. Проверете.
CASE_CLOSE_OVERDUE	Нищо не е успяло от един час. Случаите остават отворени.
CASE_CLOSE_API_UNAVAILABLE	Worker не можа да достигне API.
CASE_CLOSE_REJECTED	API отказа заявката; проверете CRON_SECRET.
CASE_CLOSE_SIGNAL_MISSING	На този appliance никога не е записвано обхождане.

За незабавно изпълнение:

docker compose exec delivery-worker sh -c \
  'curl -s -H "Authorization: Bearer $CRON_SECRET" \
     http://api:3002/v1/internal/close-expired-cases'

Клиничен протокол за печат

Appliance предоставя разрешена HTML страница за печат; не генерира PDF файлове на сървъра. Клиницистите използват Печат / Запазване като PDF в браузъра. Приложението за телефон заявява петминутна връзка за печат с обхват до един случай и отваря страницата в браузъра на устройството; не изтегля скрит PDF файл. PDF може да бъде създаден само от браузъра или операционната система, когато предлага Запазване като PDF като print destination.

За тази функция не инсталирайте Chrome, Chromium, Edge, Puppeteer или услуга за PDF rendering на appliance. Hospital не изисква такъв third-party renderer. При приемателната проверка потвърдете както достъп в същата институция, така и отказ за различна институция, преди да печатате истински клиничен случай.

Прекъсване на Central

Клиничната работа продължава с локалната база данни. Одобрените доставки остават в опашката и се повтарят след възстановяване на връзката. Никога не заобикаляйте проверката на receipt и не маркирайте ръчно batch като приет.

Обновявания на справочните данни

Импортирайте терминологични обновявания единствено чрез staged wrapper scripts/import-terminology.sh. Неговият строг manifest записва source, version, licence approval, checksums, minimums, import time и operator. Изпълнете go-live gate и тествайте търсенето и на двата поддържани езика преди клинично въвеждане; използвайте документираната rollback команда, а не директен seed script.