Инсталиране

Поддържан хост и предварителни изисквания

Референтното внедряване е Ubuntu система с архитектура amd64. В Windows Server 2019, 2022 или 2025 на болницата ИТ екипът активира Hyper-V и създава виртуална машина Generation 2 с Ubuntu Server 24.04 LTS. LOSPOR не използва Windows контейнери. Appliance не включва предварително изграден VHDX; ИТ екипът инсталира и актуализира стандартна Ubuntu виртуална машина съгласно политиката на болницата за сървъри. Подготовка на хоста предоставя файл за автоматична инсталация, който подготвя всичко изброено по-долу, и скрипт за Hyper-V, който създава виртуалната машина от него.

Инсталирайте на Ubuntu виртуалната машина:

• Docker Engine и приставката docker compose, версия 2.19.0 или по-нова. Поддържат се както класическото хранилище на образи (overlay2), така и containerd хранилището — включително прясна инсталация на Docker в Ubuntu, която вече по подразбиране използва containerd хранилището;
• OpenSSL, curl и Python 3 (използва се за точна проверка на IPv4/IPv6 CIDR мрежи и на незадължителния адрес за поддръжка);
• gzip и tar за обработка на проверени офлайн версии;
• стандартните текстови инструменти на Ubuntu, включително awk, basename, cmp, flock, grep, sed, sha256sum, tail, tr и wc;
• OpenSSH Server за SSH тунела към достъпния само през loopback авариен Status;
• стандартните инструменти на Ubuntu, проверявани от скрипта за готовност (getent, ss и timedatectl).

ИТ екипът на болницата не инсталира Node.js, npm, Git, Prisma, PostgreSQL, Caddy, nginx или инструменти за разработка. PostgreSQL, Caddy, nginx, средите за изпълнение на Node и всички приложения на LOSPOR пристигат в контейнерна версия, проверена с контролни суми. Предоставеният контейнер с инструменти изпълнява управлението на данните за достъп и базата данни, без да добавя Node.js на сървъра.

Виртуалната машина изисква още:

• два DNS записа за сървъра — един клиничен и един за научни цели. Вътрешните записи (split-horizon) са допустими и са обичайни за система, която не е публикувана в интернет;
• сертификат по един от трите начина в раздел Сертификати по-долу. Само първият изисква входящ достъп от интернет до порт 80;
• клиничният HTTPS порт да е достъпен от отделенията, а loopback портът на Status да е свободен за аварийния достъп. Стойностите по подразбиране са 443 и 3443 и могат да се променят чрез HOSPITAL_HTTPS_PORT и HOSPITAL_STATUS_PORT в site.env;
• мрежите за Research/VPN и за ИТ управление за Research Browser и Status, зададени в Status след инсталирането;
• криптирано дисково пространство на хоста, NTP, наблюдение на свободното място и защита с UPS;
• отделно криптирано местоназначение за копията на резервните архиви.

Вижте Мрежови и TLS граници за точния договор за двата адреса, CIDR мрежите, режима на сертификата, проверките и безопасната промяна.

Започнете с поне 8 виртуални процесорни ядра, 16 GiB RAM и 200 GiB свободно място в разширяемо криптирано хранилище. Ако хранилището на Docker е в отделна файлова система, то се нуждае от същия свободен капацитет. Преди по-широко внедряване оразмерете според измерения обем на случаите, образите и резервните копия.

Водената инсталация изпълнява отчета за готовност, който не прави промени, преди да създаде каквото и да е, и спира при всяка грешка. Изпълнете го отново по всяко време след инсталацията:

sudo sh /opt/lospor-hospital/current/scripts/readiness-check.sh --strict

Той проверява Ubuntu/архитектурата, Docker/Compose, процесора, RAM, диска, синхронизацията на часовника, DNS, конфигурираните HTTP/HTTPS/Status портове и настройките за резервни копия. Не инсталира пакети, не променя защитната стена, не резервира портове, не променя Docker и не записва конфигурация.

Инсталиране на клиентска версия

Версията се получава от публичното GitHub хранилище и съдържа необработен Ed25519 подпис върху своя заключващ файл. Поддържащият изтегля прегледаната неизменяема версия, проверява release.lock.sig, проверява версионирания придружаващ файл release.lock.sha256 и всеки пакет спрямо заключващия файл, копира пълния окончателен набор на чиста криптирана USB памет, запазва физически контрол над нея и извършва инсталацията на място. Точните онлайн и офлайн команди са описани в Проверка на Hospital версия.

При първата инсталация изпълнете losporctl-install.sh, изтеглен от lospor.org или пренесен на USB паметта на поддържащия. Той проверява подписа на заключващия файл спрямо вградения си ключ, проверява архива за внедряване спрямо този заключващ файл, разархивира го в нова начална директория в /opt/lospor-hospital, запазва ключа и стартира водената инсталация. Нищо не трябва да се въвежда или сравнява. Виртуална машина, създадена със скрипта за Hyper-V, вече носи скрипта в /usr/local/lib/lospor/losporctl-install.sh и го предлага при първото влизане в конзолата; машина, създадена с помощника за Windows, го изпълнява сама при първото стартиране с отговорите, дадени там (вижте Подготовка на хоста). Ако първата инсталация спре по средата, изпълнете същата команда отново: тя изброява какво е оставил опитът и предлага --resume или --discard-unfinished (вижте Когато първа инсталация не е завършила). При следващи обновявания изпълнявайте run-online-release.sh или load-offline.sh от /opt/lospor-hospital/current/scripts; активният доверен стартер сам проверява и подготвя новия архив за внедряване.

Двата стартера приемат заключващия файл на версията, каноничния му придружаващ .sha256 файл и директорията с артефактите на версията и автоматично избират инсталиране или обновяване. Офлайн инсталацията изисква пълния окончателен набор: манифест, архив за внедряване, доказателства за сигурност, заключващ файл, придружаващ файл, необработен 64-байтов release.lock.sig и всички части на образите. Не разархивирайте върху съществуваща версия, не подавайте друга команда и не задавайте ръчно HOSPITAL_IMAGES_VERIFIED. Това е краткотрайно потвърждение, подавано само от проверяващите стартери; то никога не се записва в .env.

Веригата от контролни суми открива променени байтове спрямо заключващия и придружаващия файл. Подписът удостоверява поддържащия, защото ключът идва по втори канал: онлайн losporctl-install.sh го приема само ако съвпада и с отпечатъка, публикуван на lospor.org; офлайн той идва от USB паметта на поддържащия. Ключ, който само се намира в изтеглената версия, никога не се приема автоматично за доверен.

Воденият инсталатор започва с двуезичен избор на език. Българският е избран предварително; английският остава ясно видима възможност за чуждестранен оператор. Изборът веднага сменя езика на останалата част от инсталатора и се запазва като LOSPOR_DEFAULT_LOCALE=bg|en. Той определя само първия изглед преди вход: изричният избор при вход се записва в акаунта и след това има предимство във всички приложения.

При нова инсталация вграденото предварително изчислено насочване за по-бързо въвеждане при възрастни и при деца е включено по подразбиране; инсталаторът не пита. Това са начални настройки, а не твърдение за клинична приложимост. Самото документиране на педиатрични случаи е постоянна включена възможност на Hospital; настройките управляват само предварителното изчисляване, а не дали може да се документира дете. По-късно Status може да изключва и включва всяка група поотделно след ново удостоверяване на оператора и посочена причина. Изключването премахва само бъдещите предложения за лекарства, инфузии и течности; ръчното документиране, проверките за безопасност/алергии, калкулаторите, педиатричната документация, историята и ретроспективните сборове остават достъпни. Обновяване никога не заменя съхранените настройки с началните стойности.

Тези две настройки са само политика; те не определят клиничната приложимост на съдържанието във версията. След миграциите и началното настройване на Hospital инсталаторът изпълнява точно веднъж provisioner-а от основния API с изричен --apply. Той атомарно публикува и избира отделно прегледаните включени базови конфигурации за възрастни и деца чрез технически участник, собственост на версията. При сблъсък, частично състояние, противоречащ избор или променено съдържание инсталацията се прекратява безопасно. След това същата проверка само за четене на точната версия v2, която използват runtime и Status, трябва да покаже „Готово“ и за двете групи преди стартиране на услугите, doctor или съобщение за успех. Проверката на съдържанието не обвързва двете настройки на политика, а ръчното документиране остава налично и при изключена политика. В Status идентичността и състоянието на публикуване на набора, точният брой правила/профили и SHA-256 трябва да продължат да съвпадат с включената снимка v2, преди да се показват изчислителни насоки. Вижте Политика за изчислителни насоки.

Незадължителният външен ИИ за предоперативния съветник, извличането от изображения на лабораторни резултати и OCR на монитор е включен по политика по подразбиране, отделно от локалното насочване, и остава ясно отбелязан като ненастроен, докато болничният ИТ екип не добави собствените данни за достъп на болницата до Mistral през Status. Инсталаторът никога не ги пита и не ги пренася. В Status данните веднага се запечатват с ключ, достъпен единствено за API, и никога не се записват в .env, аргументи, Compose метаданни, дневници или отговор към браузър. Удостоверен с парола оператор в Status може да включва и изключва външния ИИ и да заменя или премахва данните за достъп, като посочи причина за одита. Всяка болница използва собствен акаунт в Mistral и трябва да откаже използването на своите API данни за обучение на модели. Вижте Управление на външен ИИ.

Незадължителният местен адрес за поддръжка не се пита при инсталацията. Той е вътрешен HTTPS адрес за помощ/заявки без вградени данни за достъп или един mailto: имейл без допълнително съдържание и се задава по-късно като HOSPITAL_SUPPORT_URL в Status Поддръжка → Настройки на сайта или в site.env. Празната стойност, която е по подразбиране, насочва клиницистите към местния администратор без активна връзка. Mobile/PWA съдържа съответстваща на версията офлайн помощ и показва настроения контакт чрез публичния отговор за възможностите, който не съдържа тайни. Екранът за докладване първо показва безопасен преглед и никога не включва данни за пациент, случай, клинични стойности, акаунт, лечебно заведение, токен или свободен текст. Нищо не се изпраща автоматично; тема и съдържание на mailto: се добавят едва след като клиницистът умишлено отвори прегледаната чернова.

Инсталаторът не пита за място за външно архивиране. Новата инсталация започва в честния режим „отложено“ и Status показва критично предупреждение, докато ИТ екипът не настрои шифровани копия в мрежова папка или на SFTP сървър от Поддръжка → Копия извън сървъра или свое собствено външно прехвърляне. Вижте Архивиране и възстановяване.

Инсталация от изходен код за разработка

chmod +x scripts/*.sh infra/postgres/*.sh
./scripts/install.sh

Инсталаторът:

1. създава уникални локални тайни и сертификатни материали;
2. използва образи на версията с проверена цялост или изгражда локално включените образи само при изрично разпознат режим за изходен код/разработка;
3. мигрира локалната PostgreSQL база данни;
4. създава ограничената проверка на базата данни, която изпълнява само SELECT 1;
5. създава една институция и първоначалния системен администратор;
6. инициализира отделни проверяващи механизми за клиничната система и Status от една и съща еднократно въведена парола;
7. зарежда включения каталог с опции от Core;
8. запечатва незадължителните данни за достъп до доставчика на външен ИИ, без да съхранява откритата им стойност;
9. предоставя точно веднъж двете прегледани базови конфигурации на версията за възрастни и деца и изисква проверката им в базата данни да е успешна;
10. стартира клиничните услуги, услугите за научни цели, работните процеси, резервните копия, Status и TLS;
11. изчаква до пет минути за готовност, създава действителен удостоверен архив и изпълнява проверката на системата през конфигурираните адреси, преди да съобщи успех.

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

Паролата на администратора се подава само през стандартния вход към еднократните инициализатори; не се записва в .env, аргументи на командния ред, метаданни на Compose или контейнерен образ. Един и същ имейл/парола работи в клиничното приложение и Status, но всеки от тях съхранява собствен независим хеш. При първия вход в Status след това е задължително да се настрои TOTP приложение за удостоверяване и се показват десет еднократни кода за възстановяване. Болничният ИТ екип трябва да запази кодовете офлайн, преди да продължи. Инсталаторът създава отделен ключ за шифроване на MFA в Status; той никога не използва повторно MFA ключа на клиничните администратори или ключа за ограничаване на опитите.

Незадължителните данни за достъп до външния ИИ използват отделен трети ред на стандартния вход и се прочитат само от еднократния процес за запечатване. Те не са настройка на средата и се премахват от паметта на инсталатора веднага след тази операция.

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

Инсталация без данни за достъп до Central в secrets/ е поддържано, а не влошено състояние: инсталаторът го посочва и болницата работи самостоятелно. Клиничните данни остават локални, а износът за научни цели започва едва след свързване на болницата с Central.

Какво обслужва всеки адрес

На клиницистите се дава едно име. На настолен компютър то отваря уеб приложението; на телефон /app може да се инсталира на началния екран.

Hospital предоставя анестезиологичния протокол като разрешен за печат HTML. Не изпълнява Chromium или друг сървърен PDF генератор и не предлага API за изтегляне на PDF. В уеб приложението изберете Печат / Запазване като PDF, за да отворите прозореца за печат на браузъра. В телефонното приложение Отваряне на протокол за печат получава петминутна връзка, ограничена до конкретния случай, и отваря същата страница в браузъра на устройството. „Запазване като PDF“ е налично само когато браузърът/операционната система го предлага. Полетата за самоличност на пациента остават празни и се попълват на ръка след отпечатване. Връзката за печат не отслабва достъпа до институцията: издава се само след обичайната проверка на правата за случая и изтича след пет минути.

URL	Предоставя
https://<clinical>/	Уеб приложение
https://<clinical>/app	Инсталируемо телефонно приложение (PWA)
https://<clinical>/v1/…	API за двата клиента
https://<clinical>/status/	Status на системата, ограничен до HOSPITAL_STATUS_ALLOWED_CIDRS и независим вход
https://<research>/	Browser за научни цели, ограничен до HOSPITAL_RESEARCH_ALLOWED_CIDRS

Ако Caddy не е достъпен, ИТ екипът на болницата може да достигне същия Status контейнер на https://localhost:3443/status/ през SSH тунел — или през порта, зададен в HOSPITAL_STATUS_PORT. Портът е свързан само към loopback и използва самоподписан сертификат за localhost. Вижте Наблюдение чрез Status за командата за тунела и ограниченията.

Сертификати

Всеки браузър изисква доказателство, че този сървър отговаря на заявеното име. Има три начина, които се различават главно по това кой какво прави.

	кой какво прави	входящ интернет	предупреждения в браузъра
Публичен удостоверяващ орган (acme)	Системата получава сертификата автоматично, но публичен удостоверяващ орган трябва да се свърже към нея през порт 80, за да провери името	необходим	няма
Собствен удостоверяващ орган на болницата (operator)	ИТ екипът на болницата издава сертификат и предоставя два файла; системата ги използва	не е необходим	няма — управляваните устройства вече имат доверие на този орган
Собствен орган на Caddy (local)	Системата създава такъв, но никое устройство не му се доверява	не е необходим	на всяко устройство, освен ако ИТ не разпространи кореновия сертификат

Повечето болници с Windows домейн вече поддържат удостоверяващ орган, на който всички управлявани устройства имат доверие. operator е обичайният избор за система, която не е публикувана в интернет.

Използване на собствения удостоверяващ орган на болницата

Поискайте от ИТ сертификат, който покрива и двете имена — клиничното и това за научни цели — след което подайте сертификата, ключа му и удостоверителя на болницата на една команда, която ги инсталира, прилага настройката и проверява резултата (вижте Адреси, сертификат и портове):

sudo losporctl config certificate operator /root/fullchain.pem /root/private.key /etc/ssl/certs/hospital-ca.crt

След това scripts/readiness-check.sh проверява режима и съответствието на ключа, SAN за клиничното и Research име, зададения CA и пълната верига, началната/крайната дата, server EKU и поне 30 дни оставаща валидност. Инсталаторът парсва точната конфигурация на Caddy за режима преди свързване към порт. HOSPITAL_TLS_MODE е единственият нормален избор; свободни Caddy директиви не се приемат.

HOSPITAL_TLS_VERIFY_CA определя на кого се доверява системата, когато проверява себе си. Настройката е по-важна, отколкото изглежда: scripts/doctor.sh е проверката за прилагане на версия и за потвърждаване на връщането след неуспех. Ако системата не може да провери собствения си сертификат, тя инсталира обновяването, не преминава проверката, връща предишната версия, отново не преминава проверката и оставя заключване за преглед от оператор.

Същият файл определя на кого се доверява уредът, когато се свързва навън — към болничната EHR система. Болниците подписват вътрешните си сървъри със собствен удостоверяващ орган, така че без него връзката се отказва заради неразпознат сертификат, а не заради проблем с криптирането — което отвън изглежда като „LOSPOR не поддържа HTTPS“ и завършва с интеграция, настроена на нешифрован адрес. Не се събира нищо допълнително: отговорът тук важи и в двете посоки.

HOSPITAL_EHR_TLS_CA го замества за рядкия случай, в който EHR системата стои зад друг удостоверяващ орган. scripts/readiness-check.sh показва кой се използва, за да сочи отказаната връзка към доверието, а не към мрежата.

Нешифровани EHR адреси се отказват. HOSPITAL_EHR_ALLOW_INSECURE_ENDPOINT=true разрешава такъв, и то само към частен адрес — клиентската тайна за OAuth се изпраща към token URL, така че нешифрован адрес поставя паролата за интеграция на болницата в явен вид при всяка заявка за токен. Първо опитайте същия хост на https://, после удостоверяващия орган по-горе; обикновено там е проблемът.

НЗИС не публикува FHIR адреси за списъците си с кодове, затова всяка болнична система ги назовава по свой начин. Адрес, който назовава списъка си (…/CL013, urn:…:ksmp, …/МКБ-10), се разпознава както е. Всеки друг адрес се показва в Status в Управление на болничната система → Адреси на списъците с кодове, щом от него пристигне код, и може да се въведе там и предварително от документацията на доставчика. Посочете веднъж кой списък е: МКБ-10, операции по ICD-10-PCS, процедури по КСМП, пътищата на въвеждане CL013 или CL046, или лабораторните изследвания CL024. ICD-10-PCS с публикувания си адрес (http://www.cms.gov/Medicare/Coding/ICD10) не се нуждае от отговор. Нищо не чака отговора; дотогава кодовете пристигат с имената, дадени от болницата.

Бележка за local

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

Хост порт 80 се публикува само от COMPOSE_PROFILES=tls-acme, който инсталаторът извежда от HOSPITAL_TLS_MODE=acme. Режимите operator и local не го заемат.

Воденият инсталатор не пита за мрежовите списъци. Докато болничният ИТ екип не ги зададе в Status → Поддръжка → Настройки на сайта, Status отговаря на всяка частна мрежа (10.0.0.0/8 172.16.0.0/12 192.168.0.0/16, с HOSPITAL_NETWORK_ALLOW_ALL_PRIVATE=confirmed; за вход все пак са нужни парола и MFA), а Research Browser не отговаря на никого (127.0.0.1/32). Изисква внимание днес и Готовност показват това, докато и двата списъка не са зададени; промяната, която ги стеснява, изключва превключвателя за всички частни мрежи. Списъци, подадени на инсталатора в HOSPITAL_STATUS_ALLOWED_CIDRS и HOSPITAL_RESEARCH_ALLOWED_CIDRS, се използват както са. Невалидни стойности, мрежи за целия интернет и всички RFC1918 диапазони без превключвателя се отказват. В конзолата списъците се променят с:

sudo sh /opt/lospor-hospital/current/scripts/configure-network-boundaries.sh \
  --research "10.24.30.0/24" --status "10.24.40.0/24"

Командата проверява кандидат-конфигурацията на Caddy преди замяна и пази последната работеща граница. Прекият авариен Status остава само на loopback.

Терминологични данни

Версията съдържа всичко нужно за клинична работа: МКБ-10 с българските наименования (НЗИС 1.5.27), групите процедури и операциите по ICD-10-PCS, българския списък с лекарства, английските синоними на диагнозите от ICD-10-CM и изследователските кодове по OMOP на диагнозите, операциите, изследванията и лекарствата. Инсталацията ги зарежда.

Пакетът терминология от Athena не е задължителен. Импортирайте го от reference-data/, когато изследванията изискват по-нова версия на речниците или пълните речници на OMOP на сървъра; вижте reference-data/README.md и Импорт на терминология. След като пакет е импортиран, scripts/doctor.sh --go-live изисква доказателствата за manifest/контролни суми да останат валидни и повтаря проверката на връзки и бройки; без пакет само отчита, че се използват включените кодове.

Първоначални приемателни проверки

sudo sh /opt/lospor-hospital/current/scripts/backup-now.sh
sudo sh /opt/lospor-hospital/current/scripts/doctor.sh

Освен клиничните маршрути, doctor.sh проверява двата пътя към Status, вътрешната му готовност, синхронизирането на поколенията на данните за достъп и безопасните маркери на резервното копиране и работните процеси.

След това изпълнете ръчно един случай през уеб приложението и PWA, прекъснете мрежата по време на интраоперативно редактиране, свържете се отново, проверете възстановяването, финализирайте случая и потвърдете, че локалният Browser може да го прегледа. Отворете протокола за печат и от уеб приложението, и от PWA; потвърдете, че се отваря прозорецът за печат на браузъра и че няма действие „Изтегляне на PDF“ в LOSPOR или генериран от сървъра PDF отговор.

Готовност за клинична употреба

Инсталацията завършва в състояние инсталирано, но все още не е одобрено за клинична употреба. Страницата „Готовност“ в Status (/status/go-live) събира оставащото в един списък и една оценка. Част от точките системата проверява сама: валиден HTTPS сертификат, работещи услуги, синхронизиран часовник, актуални локални архиви, съхранени инсталационни тайни и работещ маршрут за обновявания. Две стъпки са по избор и никога не спират готовността: импортиран пакет терминология (но пакет, който е импортиран и след това изисква оператор, я спира) и копия извън сървъра, правени от LOSPOR, които не са нужни на болница, архивираща цялата виртуална машина.

Останалото потвърждават хора:

• пробно възстановяване: проверка от Status, проверка от външното копие или възстановяване на архива на виртуалната машина (валидно 92 дни);
• мрежовите ограничения, проверени от представителни компютри;
• кодовете за възстановяване на MFA, съхранени в хранилището за пароли на ИТ;
• записана политика за обновяване на сървъра; и
• клинично приемане на уеб приложението, мобилното приложение, печатния запис и работата без мрежа.

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

Записването или оттеглянето на потвърждение изисква администраторската парола и кратка бележка и се записва с псевдонимен идентификатор на оператора. Оценката се изчислява наново от текущите наблюдения при всяко отваряне на страницата, така че отпаднала проверка отново прави системата неготова. Докато тече възстановяване или операция с терминология, тя показва поддръжка. Прекъснато активиране на версия показва нужно е възстановяване, докато болничният ИТ екип не провери конзолата.