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

Uzbekistan Digital Health Platform - Локальная сборка (v0.7.0), построенная FHIR (HL7® FHIR® Стандартные инструменты сборки. Смотрите каталог опубликованных версий

Laboratory order to result

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

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

Участники: клиницист, назначающий исследование; лаборатория (LIS - Laboratory Information System, лабораторная информационная система); платформа DHP (Digital Health Platform - Цифровая платформа здравоохранения).

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

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


Цепочка ресурсов и её references:

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


​Статус профилирования: все четыре ресурса профилированы в UZ Core - Specimen, Observation, ServiceRequest (лабораторный профиль) и DiagnosticReport. В элементе meta.profile каждого ресурса укажите соответствующий профиль и настройте связи, как показано ниже.

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

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

POST [base]/ServiceRequest
{ "resourceType": "ServiceRequest",
  "meta": { "profile": ["https://dhp.uz/fhir/core/StructureDefinition/uz-core-servicerequest-laboratory"] },
  "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 указывается reference на исходное назначение.

2. Взятие образца

Лаборатория регистрирует Specimen, указывая type, дату и время взятия образца, идентификатор и пациента в subject. Важно, чтобы Specimen.request содержал reference на 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 (normal / high / low / critical) и референсный диапазон в referenceRange. В каждом Observation в basedOn указывается reference на ServiceRequest, а в specimen - reference на Specimen. Набор результатов обобщается в DiagnosticReport: его basedOn содержит reference на ServiceRequest, а result - references на ресурсы Observation.

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

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

Статусы и параллельное редактирование

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

Связанные материалы