Преминете към основното съдържание

LOSPOR API

Каноничният префикс на API във V7 е /v1. Работещ API предоставя:

  • /health/live за изправност на процеса
  • /health/ready за готовност на процеса и на базата данни
  • /v1/capabilities за съвместимост на клиента и откриване на възможности
  • /openapi.json за генерирания договор на крайните точки

Нативните клиенти се удостоверяват с:

Authorization: Bearer <token>
X-LOSPOR-Client: mobile
X-LOSPOR-Client-Version: <version>

Клиентите в браузър използват HttpOnly сесийна бисквитка, управлявана от API. Заглавията за ревизия, идемпотентност, източник и заключване са описани изцяло в OpenAPI и остават част от споделения протокол за синхронизация в Core.

Документът OpenAPI на v7.3.0 описва изрично всяка поддържана клиентска, административна, поддържаща и свързана с изправността операция: параметри, тела на заявките, тела на отговорите, изтегляния, заглавия, удостоверяване и грешки на крайните точки. Генерирането се проваля, ако маршрут няма договор или ако остарял договор няма маршрут. Двете тайни планирани задачи се пазят в отделен вътрешен опис и не се предоставят за генериране на SDK.

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

Права за редактиране на случай​

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

Подреждане на клиничните записи​

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

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

Запис, изграден върху остаряла ревизия, се отказва с 409 и текущата версия на раздела от сървъра. Клиент, който въпреки това възнамерява да я презапише — запис от опашката офлайн по определение е остарял — изпраща overrideConflict в тялото или заглавието x-lospor-override-conflict. Това се записва: одитен запис назовава презаписаните раздели, ревизията, която клиентът е смятал, че държи, и ревизията, която е отхвърлил. Задаването на флага при липса на конфликт не записва нищо.

Приключването допълва, а не презаписва. Всяко приключване на случай е отделен запис, който носи кой го е извършил и, при корекция, защо и кой запис заменя. Тригер в базата отхвърля UPDATE и DELETE, така че случай, който е бил приключен, отворен отново, коригиран и приключен наново, запазва това, което е било удостоверено първоначално.

Час на сървъра и последната промяна​

Всеки отговор носи X-LOSPOR-Server-Time: часовника на сървъра в милисекунди от епохата, достъпен за браузърите чрез CORS. Клиентите го използват, за да коригират "сега" на интраоперативната времева ос; никога не се прилага към въведен час.

Записите на събития във времевата таблица (POST /v1/cases/{id}/events, PUT и DELETE /v1/cases/{id}/events/{eventId}) приемат X-Lospor-Made-At — кога е направена промяната на устройството. Стойността е ограничена до две минути след "сега" на сървъра. Запис, направен преди последната промяна на събитието, се отказва с 412 и { "code": "SUPERSEDED" }: между устройствата важи промяната, направена последна, а не пристигналата последна. Записи без заглавката се смятат за направени при пристигането си. Събития, записани преди 9.13.0, нямат такъв час и никога не се отказват.

Събитията могат да носят recordedAt (кога е въведен записът, ISO момент с отместване) и stopConfirmed. Спиране с час повече от минута след въвеждането му предизвиква въпрос, когато часът дойде; финализирането отказва случай с такова спиране без отговор (unconfirmed_stops).

Пълнота на износа​

Пакетите по OMOP с над 5000 отговарящи случая връщат HTTP 422 с EXPORT_LIMIT_EXCEEDED и без частичен износ. Износът на личния профил е поточен ZIP с манифест и NDJSON записи, разгърнати чрез курсор.

Управляваните износи на браузъра за научна работа са фонови задачи. Записът за създаването им приема само кохорти от приключени случаи. Той замразява нормализираното определение на кохортата, обхвата по заведение за съответното действие, отсечката в базата, версията на източника и точните родителски, събитийни, релационни и раздели ревизии. Заснемането на ревизиите използва транзакция с повторяемо четене и съхранява хеш на манифеста. Ако заснет случай се промени преди създаването на файла, задачата се проваля видимо и трябва да бъде създадена отново, вместо този случай да бъде пропуснат мълчаливо. Завършена задача съхранява един неизменяем файл с контролна сума; по-късните изтегляния подават този файл, вместо да се обръщат отново към живата база. OMOP CSV е ZIP, съдържащ манифест и отделни CSV файлове за таблиците. Страниците по OMOP се съпоставят веднъж и се записват през частни работни обекти, вместо кохортата да се зарежда многократно.

Използвайте RESEARCH_EXPORT_STORAGE_DRIVER=filesystem само за локално или собствено частно съхранение. Vercel изисква RESEARCH_EXPORT_STORAGE_DRIVER=s3 и частна кофа, съвместима с S3. Настройте правило за жизнения цикъл на обектното хранилище, което да прекъсва остарелите незавършени съставни качвания. Вътрешният работен процес за износ изолира провалите на отделните задачи и поддържа ограничено възстановяване на партиди през планирания маршрут /v1/internal/research-exports/process.