Единая платформа цифрового здравоохранения Узбекистана
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/ и регулярно изменяется. Смотрите каталог опубликованных версий

e-Referral lifecycle

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

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

Этот рабочий процесс показывает, как создаётся и выполняется направление. Направления - это то место, где разработчики чаще всего теряются, потому что задействованы два ресурса, и их взаимосвязь не очевидна из таблиц профилей. Правило в одну строку:

ServiceRequest - это само направление, то есть что должно быть сделано. Task - это работа по его выполнению, то есть кто это сделал, когда и насколько далеко продвинулось дело.

Статус профилей: профили ServiceRequest и Task находятся в разработке. На этой странице описана предполагаемая модель, чтобы системы могли уже сейчас на неё ориентироваться; пока профили не опубликованы, используйте базовые ресурсы FHIR R5 и правила, приведённые ниже. Профилированы Procedure, Observation, Encounter и Condition, используемые при выполнении.

Участники: направляющий клиницист; комиссии по согласованию (для направлений по государственному страхованию); выполняющее учреждение.

e-Referral lifecycleReferringclinicianReferringclinicianDHPDHPApprovalcommissionsApprovalcommissionsPerformingfacilityPerformingfacility1POST ServiceRequest(intent = order, coverageKind)alt[coverageKind = state-insurance]2create approval Task chain(first Task status = requested)loop[approve-family-doctor ... approve-hospitalization]3advance Task(accepted -> in-progress -> completed)final approval Task completed[other financing]4referral proceeds directly(no Task created)5recordProcedure/Observation(basedOn -> ServiceRequest)6final Task completed7ServiceRequest -> completed


1. Создание направления

Клиницист создаёт ServiceRequest (intent = order), несущий классификацию направления: запрашиваемая услуга в code, срочность в priority (routine | urgent | stat), целевая услуга через HealthcareService, клиническое обоснование в reason и тип финансирования в расширении coverageKind (state-insurance | insurance | self-payment | other).

POST [base]/ServiceRequest
{ "resourceType": "ServiceRequest", "status": "active", "intent": "order",
  "priority": "routine",
  "code": { "coding": [{ "system": "http://snomed.info/sct", "code": "..." }] },
  "subject": { "reference": "Patient/[id]" },
  "requester": { "reference": "PractitionerRole/[id]" },
  "reason": [{ "reference": { "reference": "Condition/[id]" } }] }

2. Цепочка согласований (только для государственного страхования)

Это центральное правило принятия решения:

Если ServiceRequest.coverageKind = state-insurance, платформа создаёт цепочку согласующих Task; в противном случае Task не создаётся, и направление выполняется напрямую.

Каждый этап согласования - это Task, ссылающийся на ServiceRequest (Task.focus/basedOn), с Task.code из набора категорий согласования:

approve-family-doctor → approve-specialist → approve-regional-commission → approve-national-commission → approve-insurance-fund → approve-hospitalization

Task несёт две оси статуса: FHIR-статус Task.status (жизненный цикл: requested, accepted, in-progress, completed, rejected, on-hold, failed, …) и Task.businessStatus (доменное состояние, отображаемое пользователям: in-review, confirmed, overdue, …).

У задач нет пользовательского интерфейса. Менеджеры действуют по событиям процесса; они никогда не закрывают Task напрямую. Это предотвращает пометку этапа как завершённого без выполнения соответствующей работы.

3. Правила синхронизации

ServiceRequest и его Task сохраняют согласованность по следующим правилам:

Событие Эффект
ServiceRequest становится active (государственное страхование) создаётся первый согласующий Task со status=requested
ServiceRequest установлен в revoked все открытые Task устанавливаются в revoked
ServiceRequest установлен в entered-in-error все Task устанавливаются в entered-in-error
Финальный согласующий Task completed ServiceRequest устанавливается в completed
Task комиссии failed/отклонён ServiceRequest устанавливается в revoked
Возвращён на доработку Task → on-hold / in-review; ServiceRequest → on-hold, затем обратно в active с новым согласующим Task
Нарушение SLA только Task.businessStatus = overdue - статус ServiceRequest не меняется
Referral ServiceRequest status, driven by Task eventson-holdentered-in-erroractivecompletedrevokedAn SLA breach sets only Task.businessStatus = overdue;the ServiceRequest status does not change. created (status = active) returned for revision resubmitted with a new approval Task final approval / fulfilment Task completed cancelled, or a commission Task failed / rejected cancelled correction


Отображаемая пользователю метка выводится из состояния Task - например, businessStatus=overdue → «Просрочено», status=requested → «Ожидает принятия», status=rejected → «Отклонено».

4. Выполнение

Когда услуга оказана, выполняющее учреждение фиксирует результат относительно направления: Procedure и/или Observation (и Encounter для визита), каждый из которых ссылается обратно на ServiceRequest через basedOn. Результаты визуализации используют ImagingStudy/DocumentReference; текстовое заключение использует DiagnosticReport. По завершении финальный Task переводится в completed, а ServiceRequest - в completed.

GET [base]/Task?based-on=ServiceRequest/[id]&_sort=-modified
GET [base]/ServiceRequest?patient=Patient/[id]&status=active
GET [base]/Procedure?based-on=ServiceRequest/[id]

Отменённое направление не может быть выполнено, Procedure не может начаться без активного ServiceRequest, а завершённая Procedure не может быть изменена.

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