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

Uzbekistan Digital Health Platform, опубликовано Ministry of Health of the Republic of Uzbekistan. Это руководство не является санкционированной публикацией; это непрерывная сборка для версии 0.4.0, созданной FHIR (HL7® FHIR® Standard) CI Build. Эта версия основана на нынешнем содержании https://github.com/uzinfocom-org/digital-health-ig/ и регулярно изменяется. Смотрите каталог опубликованных версий

Доступ к API

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

Конечные точки (Endpoints)

  • Playground: playground.dhp.uz/fhir
  • Production: fhir.dhp.uz

Безопасность и аутентификация

Для обеспечения безопасности, конфиденциальности и надежного контроля доступа в рамках Национальной цифровой платформы здравоохранения (DHP) реализована система аутентификации и авторизации, основанная на международном стандарте OAuth 2.0. Она поддерживает как frontend-, так и backend-сценарии приложений. Централизованный сервер Single Sign-On (SSO) обеспечивает безопасную идентификацию всех участников платформы от пациентов и медицинских организаций до внешних систем.

DHP поддерживает два основных сценария аутентификации:

  • Backend-приложения через grant client_credentials (без участия пользователя),
  • Frontend-приложения через grant authorization code с поддержкой redirect_uri и опциональным PKCE (Proof Key for Code Exchange).

Интеграция backend

Данный раздел описывает процесс получения токена доступа для backend-приложений с использованием протокола OAuth 2.0 и grant-типа client_credentials. Этот поток используется, когда сервису необходимо получить доступ к защищённым API от своего имени, а не от имени пользователя.

Конфигурация клиента

Backend-клиент должен быть зарегистрирован на сервере SSO. После регистрации предоставляются:

  • client_id идентификатор, выданный провайдером
  • client_secret секретный ключ, выданный провайдером

Получение токена

Запрос

POST /oauth/token

Тело запроса

Параметр Значение
grant_type client_credentials
client_id <client_id>
client_secret <client_secret>

Ошибки (Error Responses)

Интеграция frontend

В этом разделе описывается, как frontend-приложения могут авторизовать пользователей через сервер SSO, используя стандартный Authorization Code grant протокола OAuth 2.0. Данный поток обеспечивает единый вход и безопасную аутентификацию пользователей в экосистеме DHP.

Конфигурация клиента

Frontend-приложение должно быть зарегистрировано на сервере SSO. После регистрации предоставляются:

  • client_id идентификатор, выданный провайдером
  • redirect_uri - URL-адрес, предоставленный вашим приложением

Процесс авторизации (Authorization Flow)

  1. Перенаправьте пользователя на frontend SSO:
GET sso.dhp.uz

Параметры:

Параметр Значение
client_id <client_id>
redirect_uri <redirect_uri>
  1. Код авторизации:

После успешного входа пользователь будет перенаправлен обратно на redirect_uri с кодом авторизации.

  1. Обмен кода на токен:

Этот обмен необходимо выполнить на стороне backend для защиты client_secret. Если у приложения нет backend, используйте PKCE.

  1. Использование токена:

Включайте токен доступа в каждый запрос:

Authorization: Bearer <access_token>

Транзакции

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

Транзакция - это Bundle с type, установленным в transaction. Каждая запись (entry) содержит:

  • fullUrl - временный идентификатор ресурса в формате urn:uuid:
  • resource - ресурс для создания или обновления
  • request.method - HTTP-метод (POST для создания, PUT для обновления)
  • request.url - тип ресурса (для POST) или путь к ресурсу (для PUT)

Ресурсы внутри транзакции могут ссылаться друг на друга через значения urn:uuid:. Сервер заменяет их на реальные идентификаторы после обработки.

Отправьте Bundle через POST [base] (не на конкретный endpoint ресурса).

Пример запроса: Transaction Bundle JSON - отправляет EpisodeOfCare, Encounter и три Observation.

Ответ сервера

При успехе сервер возвращает Bundle типа transaction-response. Каждая запись содержит response.status и response.location с присвоенным сервером идентификатором.

Пример: Успешный ответ JSON

Если какая-либо запись не проходит валидацию, вся транзакция откатывается, и сервер возвращает OperationOutcome с описанием ошибки.

Пример: Ошибка JSON

Обработка ошибок

(будет дополнено требуется описание обработки ошибок)

Must Support

Требование Must Support в данном руководстве применяется в двух контекстах:

  1. Профили UZ Core: элемент должен быть заполнен при обмене данными между системами в Узбекистане.

  2. Специфические профили DHP: элемент поддерживается DHP, и клиентские системы обязаны заполнять его, если данные доступны.

Если элемент не может быть заполнен, потому что данные отсутствуют в исходной системе, и правила кардинальности позволяют это, элемент может оставаться пустым. Если же правила кардинальности требуют обязательного заполнения, необходимо использовать расширение Data Absent Reason.