Архитектура на приложението

LOSPOR v7 е разделен на шест хранилища:

• API (lospor-api) отговаря за поведението по HTTP, удостоверяването, PostgreSQL, миграциите с Prisma, имейла, доставчиците на изкуствен интелект, изготвянето на PDF, одитните данни и съхранението и износа по OMOP.
• Уеб приложение (lospor-app) отговаря за интерфейса в браузъра на базата на Next.js. То няма данни за достъп до базата и не използва Prisma.
• Мобилно приложение/PWA (lospor-mobile) отговаря за клиничния интерфейс на Expo и за съхранението офлайн на устройството.
• Core (lospor-core) отговаря за клиничните правила без рамка, каталозите, проверките, протоколите за синхронизация и споделените договори за данни.
• База данни (lospor-browser) отговаря за самостоятелния интерфейс за научна работа, качество и сравнителен анализ. Той няма данни за достъп до базата и използва само управлявани проекции през API.
• Документация (lospor-docs) отговаря за насоките за потребители, администратори и разработчици.

Поток на заявките

Новите клиенти използват версионирания API директно:

Уеб / Мобилно / PWA -> https://api.lospor.org/v1 -> PostgreSQL
Браузър на базата данни -> https://api.lospor.org/v1/research -> PostgreSQL

През периода на съвместимост с V6 заявките към стария уеб адрес се препращат, без крайната точка да се реализира наново:

Клиент V6 -> https://app.lospor.org/api/* -> https://api.lospor.org/v1/*

Съвместимият посредник е предвиден да остане 12 месеца след производственото издание на V7. Той дава време на инсталираните мобилни версии да се обновят. Това не означава, че всяко старо поведение е пренесено в уеб приложението.

Удостоверяване

API е инстанцията за вход и състояние на профила. Нативните клиенти използват подписан bearer токен. Клиентите в браузър използват същия сесиен токен, управляван от API, в HttpOnly бисквитка. Промените на роли, изтриването на профил, нулирането на пароли и отнемането на токени се проверяват спрямо живия профил.

Първото издание на V7 поддържа само собствените клиенти на LOSPOR. API е структуриран и документиран за бъдещи интеграции, но регистрацията на клиенти от трети страни и обхватните удостоверения още не са включени.

Споделена клинична област

Core отговаря за правилата, които трябва да дават един и същ клиничен отговор на всеки клиент:

• клинични каталози, синоними, дървета, профили и резервни данни офлайн;
• лаборатории, системи по МКБ-10, предложения за ASA и рискови групи;
• клинични граници, проверки, готовност, приключване, Aldrete и предаване;
• мониториране, дихателен път, техника и метаданни за опциите;
• проекция на времевата таблица, активни инфузии/вливания/газове/агенти, общи количества и смислови описания на събитията;
• педиатричен режим, точна хронологична възраст, педиатрични правила за риск/гладуване/болка, прегледани педиатрични калкулатори и произход на клиничните правила;
• клинични набори от правила според режима, канонични пътища на въвеждане, метаданни за мерните единици и детерминиран ред платформа/заведение/лично;
• извеждане на състоянието, политика за профилите, договори за търсене, мерни единици и обобщения;
• кеширане на опциите, заключвания, периодични запитвания, обработка на ревизии и конфликти и решения за автоматично записване; и
• договори за версия на API, възможности, грешки, изправност и сесии.

Core няма реализация на React, Expo, Next.js, Prisma, съхранение или мрежа. Клиентите пазят преводите, оформлението, анимацията, вибрациите и съхранението на устройството. API пази заявките към базата и адаптерите към външните услуги.

Граница на клиничните набори от правила

Core определя и проверява пълните набори за възрастни и за деца. API отговаря за тяхното съхранение, публикуване, собственост и избор. Уеб приложението отговаря за средата за редактиране; мобилното приложение и PWA показват действащия избор само за четене.

За всеки клиничен режим един публикуван набор се определя в следния ред: личен, на заведението, на платформата. Правилата не се смесват между нивата, а педиатричният никога не преминава към набора за възрастни. Публикуваните версии са неизменяеми; промените се правят чрез копиране на версия в нова чернова.

Заключване и безопасност офлайн

API получава права за редактиране на случай с една атомарна операция в PostgreSQL. Две устройства не могат и двете да бъдат уведомени, че са получили едно и също свободно право. Клиентите могат съзнателно да останат използваеми, когато крайната точка за заключване е временно недостъпна; проверките на ревизиите пак отхвърлят остарелите записи, преди да презапишат по-нови данни на сървъра.

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

Граница на внедряването

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

В момента API поддържа внедряване във Vercel/безсървърна среда и задава output: standalone за бъдеща локална инсталация с Node или контейнер. Едно лечебно заведение може по-късно да пусне API, уеб приложението и PostgreSQL на един физически сървър; те са отделни процеси, но не непременно отделни машини.

Ред на издаване

1. Публикувайте и маркирайте Core v7.
2. Обновете API, уеб приложението, мобилното приложение/PWA и браузъра на базата данни към етикета на Core и проверете чистите инсталации.
3. Приложете миграциите на базата, управлявани от API.
4. Внедрете API и проверете проверките за изправност и готовност, както и /v1/capabilities.
5. Внедрете уеб приложението и браузъра на базата данни с техния адрес на API.
6. Издайте PWA/мобилното приложение след тестовете за съвместимост от край до край.
7. Изтласкайте етикета на изданието на API последен, за да може версионираният му междухранилищен манифест да стартира автоматичната проверка.

Етикетите на V6 остават основата за връщане назад. Издание никога не бива да насочва npm към локална съседна директория на разработчик.

Наложени граници

Проверките на хранилищата отхвърлят реализации на Prisma, база данни или удостоверяване в уеб приложението и отхвърлят код за съхранение в браузъра или на устройството в API. Договорните тестове на API изискват всяка реализирана публична операция да има изрични параметри, тела на заявките, успешни отговори, грешки, удостоверяване и заглавия за ревизия или идемпотентност, където е приложимо. Междухранилищната проверка на изданието потвърждава чистите инсталации, истинска миграция на PostgreSQL и интеграционен набор, компилациите на API и клиентите, потоците в браузъра, възстановяването на PWA офлайн и износа за Android.