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

Workflows

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

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

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

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

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

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

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

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

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

Несколько правил применяются к каждому рабочему процессу:

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

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

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

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

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