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

Workflows

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

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

Каждый рабочий процесс описывает участников, последовательность FHIR-взаимодействий и основные правила, а также содержит примеры API-вызовов и фрагменты передаваемых данных.

Доступные сценарии

Рабочий процесс	Что охватывает	Ресурсы
Вакцинация	Национальный календарь → рекомендация → консультация и визиты для вакцинации → регистрация введённой дозы	PlanDefinition, ImmunizationRecommendation, Encounter, Immunization, AdverseEvent
От назначения лабораторного исследования до получения результата	Назначение лабораторного исследования и передача результата	ServiceRequest, Specimen, Observation, DiagnosticReport
Жизненный цикл электронного направления	Создание и выполнение направления, включая цепочку согласований в рамках государственного медицинского страхования	ServiceRequest, Task, Procedure
Маршрут пациента (Episode of Care)	Объединение визитов, диагнозов и результатов по клиническому случаю в рамках одного эпизода на протяжении времени	EpisodeOfCare, Encounter, Condition, Observation
Электронный рецепт и отпуск лекарственного средства	Назначение лекарственного средства, его отпуск и передача отчётности в SHIF	MedicationRequest, MedicationDispense, Condition

Создание и подписание клинического документа (формирование документа на основе Composition и его подписание для придания юридической силы) описаны в разделе Documents руководства DHP Integrations IG, а не здесь.

Дополнительные сценарии (популяционный скрининг) будут добавляться по мере завершения соответствующих профилей.

Модель взаимодействия

Для всех рабочих процессов действуют несколько общих правил:

• Сначала выполните аутентификацию. Каждый запрос должен содержать bearer-токен OAuth2 (Authorization: Bearer <token>), полученный через SSO платформы. Клиенты для межсистемного взаимодействия используют поток client credentials; пользовательские приложения - поток authorization code через oneID.
• Укажите профиль. Каждый отправляемый ресурс должен содержать meta.profile, чтобы сервер валидировал его по соответствующему профилю UZ Core. См. Общие рекомендации → метаданные.
• ​Объединяйте связанные ресурсы в Bundle. Если несколько ресурсов относятся к одному процессу, их можно отправить в составе Bundle типа transaction или batch, а для завершённого документа - в Bundle типа document. См. Общие рекомендации → Bundle.
• Учитывайте согласие пациента. Запросы на чтение выполняются с учётом Consent пациента; при отказе в доступе сервер возвращает 403. Каждый факт доступа регистрируется в AuditEvent.
• ​Только логическое удаление. Записи выводятся из использования путём изменения статуса, а не методом DELETE. См. Общие рекомендации → удаление.

Как связаны ресурсы

Большинство клинических данных связано с Patient через несколько типовых схем использования references. На схеме ниже показана эта основная структура; она не является исчерпывающим перечнем всех профилей (полный набор см. в разделе Артефакты):

• Ресурс Patient может быть связан с несколькими ресурсами Encounter (визитами); связанные Encounter можно объединить в EpisodeOfCare (продолжающийся клинический случай).
• В рамках Encounter медицинские работники регистрируют ресурсы Condition (диагнозы), Observation (результаты и жизненные показатели), Procedure и MedicationRequest.
• Ресурсы рабочих процессов (ServiceRequest, Task) обеспечивают назначение и выполнение; ресурсы результатов (Observation, DiagnosticReport) содержат reference на исходное назначение.
• Завершённые данные, имеющие юридическую силу, объединяются в документ на основе Composition и подписываются с использованием Provenance.

Примечание о выборе между документом и ресурсами рабочего процесса: текущие клинические данные следует хранить в виде отдельных ресурсов (Condition, Observation, Procedure); документ на основе Composition следует формировать только тогда, когда требуется завершённый артефакт, имеющий юридическую силу (выписной эпикриз, подписанное свидетельство или подписанный отчёт).