Единая платформа цифрового здравоохранения Узбекистана
0.5.0 - ci-build Uzbekistan флаг

Uzbekistan Digital Health Platform, опубликовано Ministry of Health of the Republic of Uzbekistan. Это руководство не является санкционированной публикацией; это непрерывная сборка для версии 0.5.0, созданной FHIR (HL7® FHIR® Standard) CI Build. Эта версия основана на нынешнем содержании https://github.com/uzinfocom-org/digital-health-ig/ и регулярно изменяется. Смотрите каталог опубликованных версий

Laboratory order to result

​На этой странице представлены переводы с языка оригинала, на котором былонаписано руководство. Информацию об этих переводах и инструкции попредоставлению отзывов о переводах можно найти здесь.

Машинный перевод, требуется проверка человеком. Эта страница автоматически переведена с английского языка с помощью искусственного интеллекта и пока не проверена редактором. При любых расхождениях приоритет имеет оригинальная англоязычная версия.

Этот рабочий процесс показывает, как назначается лабораторное исследование и как возвращается его результат. Это каноническая диагностическая цепочка FHIR с явно прописанной связкой ссылок - таблица профиля сообщает вам, что Observation.specimen существует, но эта страница говорит вам, что он должен указывать на образец, полученный по данному назначению.

Действующие лица: назначающий клиницист; лаборатория (ЛИС); платформа (DHP).

Последовательность взаимодействий:

Ordering a test and returning the resultOrderingclinicianOrderingclinicianDHPFHIR serverDHPFHIR serverLaboratory(LIS)Laboratory(LIS)1POST ServiceRequest (intent = order)2order availablecollect specimen,run each analyte3POST Bundle (transaction):Specimen+Observations + DiagnosticReport(all reference ServiceRequest)4GET DiagnosticReport?based-on=ServiceRequest/[id]&_include=DiagnosticReport:result5Bundle - report + observations


Цепочка и её ссылки:

Laboratory result - reference wiring ServiceRequest Specimen Observation DiagnosticReportBlue boxes are profiled in UZ Core and link totheir profile page; the rest are not yet profiled. request basedOn specimen basedOn result


Статус профилей: Specimen и Observation спрофилированы в UZ Core. Профили ServiceRequest и DiagnosticReport находятся в разработке - до их публикации используйте базовые ресурсы FHIR R5 с пропущенным meta.profile или установленным на базовый ресурс, и следуйте связке, описанной ниже.

1. Назначение исследования

Клиницист создаёт ServiceRequest с intent = order, исследованием или панелью в code, пациентом в subject, заказчиком (requester) и reasonCode/reasonReference (исследуемое состояние Condition). Назначаемые исследования публикуются как записи HealthcareService; priority имеет значение routine, urgent или asap.

POST [base]/ServiceRequest
{ "resourceType": "ServiceRequest", "status": "active", "intent": "order",
  "code": { "coding": [{ "system": "http://loinc.org", "code": "58410-2" }] },
  "subject": { "reference": "Patient/[id]" },
  "requester": { "reference": "PractitionerRole/[id]" },
  "priority": "routine" }

Повтор ранее проведённого исследования устанавливает ServiceRequest.basedOn на исходное назначение.

2. Забор образца

Лаборатория регистрирует Specimen с его type, датой/временем забора и идентификатором, пациентом в subject и, что особенно важно, с Specimen.request, указывающим обратно на ServiceRequest.

POST [base]/Specimen
{ "resourceType": "Specimen",
  "meta": { "profile": ["https://dhp.uz/fhir/core/StructureDefinition/uz-core-specimen"] },
  "subject": { "reference": "Patient/[id]" },
  "request": [{ "reference": "ServiceRequest/[id]" }],
  "type": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/v2-0487", "code": "BLD", "display": "Whole blood" }] } }

3. Возврат результатов

Каждый аналит представлен как Observation с LOINC-кодом в code, value[x], interpretation (норма / повышено / понижено / критическое) и referenceRange. Каждый Observation устанавливает basedOn на ServiceRequest и specimen на Specimen. Набор обобщается в DiagnosticReport, у которого basedOn указывает на ServiceRequest, а result перечисляет Observation.

GET [base]/DiagnosticReport?based-on=ServiceRequest/[id]&_include=DiagnosticReport:result
GET [base]/Observation?patient=Patient/[id]&category=laboratory&_sort=-date

​Весь набор лучше всего возвращать как один транзакционный Bundle, чтобы назначение, образец, наблюдения и отчёт поступали атомарно. Финализированный, подписанный отчёт собирается как document Bundle (заголовок Composition, ссылающийся на результаты, подписанный через Provenance) - Composition ссылается на ресурсы, а не дублирует их. См. Общее руководство → Bundle.

Статус и параллелизм

ServiceRequest.status следует жизненному циклу назначения (draft → active → completed, либо revoked); entered-in-error/unknown зарезервированы для исправлений. Отмена переводит активное назначение в revoked (с примечанием), а завершённое назначение не может быть изменено. Параллельные правки используют оптимистичный контроль параллелизма - отправляйте ETag из вашего последнего чтения как If-Match; устаревшая версия отклоняется с 412 Precondition Failed. Перечитайте и повторите - см. Параллелизм.

Связанное