Как работи автоматичното записване

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

Накратко

Мислете за управлението на автоматичното записване като за един служител, определен за всеки случай:

1. Служителят записва промяната в местна тава.
2. Промените за този случай се изпращат една по една, в реда, в който са направени.
3. Сървърът потвърждава промяната и връща новата ревизия на раздела.
4. Едва тогава промяната се маха от тавата.

Предоперативният, интраоперативният и следоперативният формуляр използват този процес. Мобилното приложение пази тавата си в SecureStore. Уеб приложението и PWA я пазят в IndexedDB.

Събития във времевата таблица

Добавянето, редактирането и изтриването на елемент от времевата таблица са отделни операции със стабилни идентификатори. Редактирането или изтриването на един медикамент, вливане, показател или събитие не заменя цялата времева ос. Повторният опит със същата операция е безопасен.

Часовник и часова зона на времевата ос

Започването на случай записва две неща заедно: точния момент в UTC и часовата зона по IANA, използвана от клинициста, например Europe/Sofia. Видимото ЧЧ:ММ остава за показване, но никога не се използва само по себе си за възстановяване на дата.

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

Наследените случаи, които имат само ЧЧ:ММ, остават четими, но LOSPOR не измисля времеви отметки за записаните им колони. Наследена моментна снимка се преобразува в събития само когато съществува надежден startedAt, и преобразуването се отказва, ако би породило бъдещи отчитания.

"Сега" идва от сървъра

Кое е планирано и кое е дадено, в коя колона е "сега" и кога е направен даден запис се решава спрямо "сега". Всеки отговор на API носи часовника на сървъра (X-LOSPOR-Server-Time, в милисекунди от епохата) и всяко приложение коригира своето "сега" с разликата между устройството и сървъра. Корекцията е разлика между два момента: не се разчита час от денонощието и не участва часова зона, така че сървър в друга часова зона не може да измести нищо. Час, избран от клинициста, никога не минава през нея.

Две устройства

Всеки раздел на случая има нарастващ номер на ревизия. Записът казва коя ревизия е редактирал потребителят. Ако друго устройство я е придвижило първо, сървърът връща по-новата ревизия. LOSPOR опитва променените полета още веднъж срещу нея. Така различни полета могат да се слеят, без да заменят целия формуляр.

Един изпращач за всяка промяна

Записът след редакция и периодичната фонова синхронизация изпращат това, което чака в тавата. До 9.11.4 двете можеха да вземат една и съща промяна едновременно и да я изпратят два пъти. Закъснялото копие се отказваше като остаряло, изпращаше се отново срещу по-новата ревизия и презаписваше записаното междувременно: екранът показваше новата стойност, а сървърът пазеше старата.

Сега всеки раздел на случая има само един изпращач в даден момент; другият изчаква и намира промяната вече изпратена. Редакция, записана в тавата, докато друг запис е на път, никога не се премахва и не се заменя от него. След успех тя се изпраща следваща, срещу ревизията, която записът е създал; след неуспех остава в тавата точно както е записана.

Един ред за всеки случай

Неизпратените промени във времевата таблица на даден случай (нови записи, редакции, изтривания) се изпращат в един ред, реда, в който са направени, а изпращането спира при първата промяна, която още не може да замине. Преди 9.13.0 новите записи и редакциите се изпращаха поотделно, така че изтриване можеше да стигне до сървъра преди записа, който изтрива, да бъде отказано като "не е намерен", а записът да се върне.

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

Промяна, отказана окончателно от сървъра (правило на времевата ос, по-късна промяна другаде, липса на права), се изважда от опашката, никога не се изпраща отново и се показва в графиката с какво е била и защо, докато клиницистът не я отбележи като видяна.

Важи промяната, направена последна

Всяка промяна във времевата таблица носи кога е направена (X-Lospor-Made-At, по коригирания часовник). Сървърът пази промяната, направена последна, а не пристигналата последна: редакция или изтриване, направени преди последната промяна на записа, и добавяне, изпратено отново след по-късна промяна, се отказват с 412 SUPERSEDED. Редакция, направена преди изтриване, не може да върне записа.

Повторно отваряне и приключване

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

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

В облачната услуга, ако сървърът открие вероятна идентифицираща информация, управлението на автоматичното записване задържа това поле на устройството и показва причината до него. Другите безопасни полета в същия формуляр пак могат да се запишат. Болничният уред не го отказва: текстът остава в болницата така, както е въведен, и се почиства всеки път, когато напуска уреда (вижте „Данни и научна работа“).

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

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

Проверката за вероятно име се пропуска само при структурирани избори от каталозите по МКБ-10, операциите, медикаментите и алергиите. Проверките за ЕГН, дълги числа, дати и имейл продължават да важат за тези наименования.

Когато сървърът не може да бъде достигнат

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

До 8.4.0 всеки запис изчакваше пълното време за изчакване на мрежата, преди да заключи, че е офлайн, а интраоперативните записи се подреждат по случай, така че един недостижим запис забавяше всичко зад себе си — и следващият запис плащаше същата цена отново. Приложението губеше секунди, за да стигне повторно до отговор, който вече имаше.

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

Периодът на изчакване е съзнателно по-кратък от периодичното изпразване на опашката, така че всяко изпразване все пак прави един истински опит и възстановената връзка се улавя на следващия цикъл, вместо да бъде заключена навън.

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

Запитване, което никога не отговаря

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

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

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

Оперативни бележки

• Миграция на схемата: 20260723000000_autosave_manager_revisions
• Заглавия за ревизиите:
  • x-lospor-preop-revision
  • x-lospor-intraop-revision
  • x-lospor-postop-revision
• Наследените заглавия за конфликт по времева отметка остават приемани по време на миграцията.
• Излизането от профила или изтриването на чернова изчиства съответните местни клинични опашки.