Uzbekistan Digital Health Platform - Integrations
0.10.0 - draft Uzbekistan флаг

This page is part of the Uzbekistan Digital Health Platform - Integrations (v0.10.0: Releases Draft) based on FHIR (HL7® FHIR® Standard) v5.0.0. This is the current published version. For a full list of available versions, see the Directory of published versions

Home

Официальный URL: https://dhp.uz/fhir/integrations/ImplementationGuide/uz.dhp.integrations Версия: 0.10.0
Draft по состоянию на 2026-09-30 Вычисляемое имя: DHPintegrations

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

Руководство по интеграции DHP

Обзор

​Данное руководство по внедрению определяет спецификации интеграции на основе FHIR R5 для сторонних систем, интегрирующихся с Цифровой платформой здравоохранения (DHP). Руководство предназначено для обеспечения обмена данными между внешними системами здравоохранения и DHP при сохранении их собственного суверенитета данных.

Назначени

Руководство по интеграции DHP предоставляет:

  • Стандартные структуры данных - FHIR-профили и расширения для внешних систем, интегрирующихся с DHP
  • Терминологию - CodeSystem и ValueSet для стандартизированного кодирования
  • Спецификации API - шаблоны обмена данными между внешними системами и DHP
  • Шаблоны интеграции - поддержка гибридной архитектуры DHP
  • Требования соответствия - требования для интеграции сторонних систем

Это руководство предназначено для разработчиков, создающих или настраивающих системы, которые необходимо интегрировать с DHP. Примерами таких систем являются медицинские информационные системы (МИС), системы архивирования и передачи изображений (PACS), лабораторные информационные системы (ЛИС), а также любые другие сторонние медицинские приложения, которым необходимо обмениваться данными с DHP.

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

Подход к интеграции - гибридная модель

DHP использует гибридный подход к интеграции, при котором не все данные централизованы. Вместо этого платформа сочетает централизованное хранение основных медицинских данных с распределёнными специализированными данными, поддерживаемыми внешними системами.

graph LR
    CoreData["DHP Core Data<br/>Demographics<br/>Clinical Records<br/>Referrals<br/>Lab Results<br/>Registries"]

    MIS["MIS<br/>Patient Records<br/>Appointments<br/>Billing"]
    PACS["PACS<br/>Medical Images<br/>Imaging Studies"]
    LIS["LIS<br/>Lab Workflows<br/>Specimen Tracking"]
    Other["Other 3rd-Party Systems<br/>Specialized Data<br/>& Services"]

    LIS -->|"transmits<br/>results"| CoreData
    CoreData -->|"lab orders"| LIS
    CoreData <-->|"query &<br/>update"| MIS
    CoreData <-->|"DICOM:<br/>references &<br/>retrieves images"| PACS
    CoreData <-->|"FHIR API<br/>integration"| Other

    style CoreData fill:#4A90E2,stroke:#2E5C8A,stroke-width:3px,color:#fff
    style MIS fill:#F5A623,stroke:#D68910,stroke-width:2px,color:#000
    style PACS fill:#F5A623,stroke:#D68910,stroke-width:2px,color:#000
    style LIS fill:#F5A623,stroke:#D68910,stroke-width:2px,color:#000
    style Other fill:#9B59B6,stroke:#7D3C98,stroke-width:2px,color:#fff

Данные, хранящиеся в DHP

DHP централизованно хранит и управляет основными медицинскими данными:

  • Демографические и мастер-данные пациентов - мастер-индекс пациентов и демографическая информация
  • Основные клинические записи (ЭМК) - основные данные электронных медицинских карт
  • Направления и рецепты - клинические назначения и документация направлений
  • Результаты лабораторных исследований - результаты анализов и диагностические отчёты, переданные из ЛИС
  • Мастер-реестры - реестр пациентов, справочник медицинских работников, реестр организаций и терминологические сервисы

Данные, поддерживаемые внешними системами

Внешние системы поддерживают собственные операционные данные, интегрируясь через FHIR API. Примеры включают:

  • Системы МИС - записи пациентов, записи на приём, данные биллинга и специфические для учреждения рабочие процессы
  • Системы PACS - медицинские изображения и диагностические исследования (DHP поддерживает обмен изображениями на основе DICOM, хранение ссылок на изображения в PACS и получение изображений для авторизованных пользователей)
  • Системы ЛИС - лабораторные рабочие процессы, отслеживание образцов и детальные данные обработки анализов
  • Другие сторонние системы - любые медицинские приложения со специализированными данными или сервисами, которым необходимо интегрироваться с DHP

Шаблон интеграции

Для большинства данных внешних систем DHP может хранить ссылки на данные во внешних системах, а не дублировать всё. Однако определённые критические данные, такие как результаты лабораторных исследований, передаются и хранятся в DHP. Этот гибридный подход:

  • Сохраняет владение данными за системой-источником
  • Обеспечивает доступ к исходным данным в реальном времени через API-интеграцию
  • Сохраняет специфические для системы рабочие процессы и бизнес-логику
  • Упрощает соответствие требованиям управления данными

DHP и внешние системы поддерживают взаимодополняющие наборы данных и взаимодействуют через FHIR и пользовательские API: DHP предоставляет авторитетные мастер-данные и основные клинические записи, в то время как внешние системы предоставляют специализированные операционные данные и доменно-специфические возможности.

Подходы к обмену данными

Интеграции с DHP поддерживают два взаимодополняющих метода обмена медицинскими данными:

graph LR
    External["3rd-Party Systems"]

    subgraph Approach1["Request Resources"]
        Resources["Workflow Resources:<br/>ServiceRequest<br/>MedicationRequest<br/>Appointment<br/>CarePlan<br/>etc."]
    end

    subgraph Approach2["Clinical Documents"]
        Forms["Clinical Forms<br/>Form 003 (inpatient)<br/>Form 096 (birth)<br/>etc."]
        Document["Document Bundle<br/>Composition header (metadata, attestation)<br/>Referenced Resources:<br/>Patient, Observation, Encounter, etc."]
        Forms -.->|"represented as"| Document
    end

    DHP["DHP"]

    External <-->|"CRUD<br/>operations"| Resources
    External <-->|"submit/<br/>retrieve"| Document

    Resources -->|"FHIR API"| DHP
    Document -->|"FHIR API"| DHP

    style External fill:#9B59B6,stroke:#7D3C98,stroke-width:2px,color:#fff
    style Resources fill:#E8F4F8,stroke:#4A90E2,stroke-width:2px
    style Forms fill:#F0E6FF,stroke:#9B59B6,stroke-width:2px
    style Document fill:#FFF4E6,stroke:#F5A623,stroke-width:2px
    style DHP fill:#4A90E2,stroke:#2E5C8A,stroke-width:3px,color:#fff

Ресурсы запросов

Для операционных рабочих процессов, требующих отслеживания статуса, DHP предпочитает ресурсы запросов. Примеры включают ServiceRequest, MedicationRequest, Appointment, CarePlan и Claim. Эти ресурсы поддерживают отслеживание состояния (запрошено → принято → в процессе → завершено), что делает их идеальными для координации в реальном времени.

Клинические документы

Для данных, требующих юридической аутентификации и долгосрочного хранения (например, Форма 003 для стационара, Форма 096 для рождений), DHP использует клинические документы - Bundle, содержащий заголовок Composition с метаданными и аттестацией, а также связанные клинические ресурсы (Patient, Observation, Condition и др.).

Когда требуется физическая подпись, документ печатается, подписывается, сканируется, и PDF встраивается в Provenance.signature.data. DHP заблаговременно принимает переработанные правила R6 из 6.1.2.2.9 Signing Bundles, так как они обеспечивают более чистый подход - подпись хранится вместе с Bundle и очевидно, что весь документ подписан.

Данный подход сочетает практичность с готовностью к будущему. Рабочий процесс сканирования и встраивания соответствует текущим юридическим требованиям и может быть развёрнут в Q1 2026. При этом структура Provenance.signature полностью поддерживает криптографические цифровые подписи — когда правовая и техническая инфраструктура Узбекистана созреет, те же ресурсы FHIR смогут нести настоящие цифровые подписи без изменений архитектуры.

Выбор подхода

flowchart TD
    Start["Healthcare Data"]

    Q1{"Needs workflow<br/>status tracking?"}
    Q2{"Needs legal<br/>authentication &<br/>persistence?"}
    Q3{"Needs physical<br/>signature?"}

    Request["Request Resource<br/>(ServiceRequest, MedicationRequest,<br/>Appointment, etc.)"]
    Document["Clinical Document<br/>(Bundle + Composition)"]
    Physical["Print, Sign, Scan"]
    Provenance["Provenance.signature<br/>(scanned PDF in signature.data)"]

    Start --> Q1
    Q1 -->|"Yes"| Request
    Q1 -->|"No"| Q2
    Q2 -->|"Yes"| Document
    Q2 -->|"No"| Request

    Document --> Q3
    Q3 -->|"Yes"| Physical
    Q3 -->|"No"| Done1["Done"]
    Physical --> Provenance
    Provenance -->|"target = Bundle"| Document

    style Request fill:#E8F4F8,stroke:#4A90E2,stroke-width:2px
    style Document fill:#FFF4E6,stroke:#F5A623,stroke-width:2px
    style Provenance fill:#F0E6FF,stroke:#9B59B6,stroke-width:2px
    style Physical fill:#FCE4EC,stroke:#E91E63,stroke-width:2px

Идентификация версий

Артефакты этого руководства - профили, расширения, кодовые системы, наборы значений, ConceptMap, системы именования и FHIR-пакет - имеют версию самого руководства. Версионирование следует семантическому версионированию (SemVer) в формате MAJOR.MINOR.PATCH, поэтому каждый артефакт в версии 0.7.0 руководства также имеет версию 0.7.0, и всегда понятно, к какому выпуску относится артефакт.

MAJOR и MINOR следуют за UZ Core: выпуск этого руководства имеет мажорную и минорную версию того выпуска UZ Core, на основе которого он собран и с которым согласован. PATCH за UZ Core не следует: это руководство может выпустить патч самостоятельно, а патч UZ Core не требует выпуска здесь. Точную версию, от которой зависит руководство, смотрите в таблице зависимостей ниже.

Пока артефакт находится в разработке и не готов к промышленному использованию, он имеет статус draft. Когда он готов к промышленному использованию, он получает статус active, а выведенный из обращения артефакт - статус retired.

Версии в разработке: 0.x.x

  • Статус руководства: draft
  • Статус артефактов: draft, флаг experimental установлен в true
  • Используются во время первоначальной разработки и тестирования
  • Между минорными версиями возможны обратно несовместимые изменения

Промышленные версии: 1.x.x и далее

  • Статус руководства: active
  • Статус артефактов: active, флаг experimental установлен в false
  • Первый стабильный выпуск начинается с 1.0.0
  • Действуют строгие правила совместимости SemVer
  • Новая мажорная версия означает обратно несовместимые изменения или существенные архитектурные обновления

Исключение из всего перечисленного - переводческие дополнения (supplements): они имеют версию той кодовой системы, которую дополняют, а не версию этого руководства. Дополнения SNOMED CT версионируются по выпуску SNOMED CT, например 2026.1.0, а дополнение LOINC - по выпуску LOINC, например 2.82. Если дополнение нужно обновить, а дополняемая система не изменилась, добавляется дополнительный номер версии, например 2.82.1.

IGPackageFHIRComment
.. Uzbekistan Digital Health Platform - Integrationsuz.dhp.integrations#0.10.0R5
... HL7 Terminology (THO)hl7.terminology.r5#7.4.0R5Automatically added as a dependency - all IGs depend on HL7 Terminology
... FHIR Extensions Packhl7.fhir.uv.extensions.r5#5.3.0R5Automatically added as a dependency - all IGs depend on the HL7 Extension Pack
... Uzbekistan Digital Health Platformuz.dhp.core#0.10.0R5
.... HL7 Terminology (THO)hl7.terminology.r5#7.3.0R5
.... fhir.dicomfhir.dicom#2025.2.20250411R4
... FHIR Tooling Extensions IGhl7.fhir.uv.tools.r5#1.1.2R5for example references

Package hl7.fhir.uv.extensions.r5#5.3.0

This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, May 16, 2026 18:32+1000+10:00)

Package uz.dhp.core#0.10.0

National implementation guide for Uzbekistan using FHIR R5. (built Tue, Sep 29, 2026 18:08+0500+05:00)

Package hl7.fhir.uv.sdc#3.0.0

The SDC specification provides an infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR.
This includes two components:
* Support more sophisticated questionnaire/form use-cases such as those needed for research, oncology, pathology and other clinical domains.
*Support pre-population and auto-population of EHR data into forms/questionnaires for uses outside direct clinical care (patient safety, adverse event reporting, public health reporting, etc.). (built Tue, Mar 8, 2022 18:32+0000+00:00)

Package hl7.fhir.uv.tools.r5#1.1.2

This IG defines the extensions that the tools use internally. Some of these extensions are content that are being evaluated for elevation into the main spec, and others are tooling concerns (built Tue, Mar 24, 2026 11:13+1100+11:00)

This publication includes IP covered under the following statements.

There are no Global profiles defined