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

API access

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

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

Конечные точки

Это базовые URL-адреса FHIR-сервера - тот самый [base], который показан в примерах API на каждой странице профиля. Добавьте к одному из них тип ресурса и любые параметры поиска, например [base]/Patient?identifier=....

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

Доступность возможностей платформы

Профили в данном руководстве определяют целевую FHIR-поверхность для DHP. Платформа вводит эту поверхность поэтапно, поэтому некоторые возможности пока недоступны на playground. Разрабатывайте в соответствии с профилем как он написан - формы запросов, показанные во всём этом руководстве, корректны; там, где возможность ещё не запущена, в примечании ниже приведён временный подход.

Статус отражает состояние playground на 2026-06-03 и меняется по мере развёртывания. Считайте источником истины об ожидаемом поведении профили, а не эту таблицу.

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

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

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

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

Интеграция backend

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

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

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

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

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

Запрос

POST /oauth/token

Тело запроса

Ошибки (Error Responses)

• 400 Bad Request
• 401 Unauthorized

Интеграция 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

Параметры:

2 Код авторизации:

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

3 Обмен кода на токен:

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

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

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

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

Параллельный доступ

Платформа использует оптимистичную блокировку, чтобы два клиента, обновляющие один и тот же ресурс, не могли незаметно перезаписать изменения друг друга (проблема «потерянного обновления»).

Каждое чтение возвращает текущую версию ресурса в виде слабого ETag:

GET [base]/Observation/[id]

200 OK
ETag: W/"3"

Чтобы выполнить обновление безопасно, отправьте это значение обратно в заголовке If-Match. Сервер применяет запись только в том случае, если ресурс всё ещё имеет ту же версию, после чего версия инкрементируется:

PUT [base]/Observation/[id]
If-Match: W/"3"

200 OK
ETag: W/"4"

Если кто-то другой изменил ресурс с момента вашего чтения, версия больше не совпадает, и запись отклоняется - ничего не перезаписывается:

PUT [base]/Observation/[id]
If-Match: W/"3"

412 Precondition Failed
{ "resourceType": "OperationOutcome",
  "issue": [{ "severity": "error", "code": "invalid", "details": { "text": "Version is mismatch" } }] }

При 412 перечитайте ресурс, повторно примените своё изменение поверх новой версии и снова выполните PUT. Платформа требует If-Match при каждом обновлении: PUT без него отклоняется с 412, поэтому всегда отправляйте обратно ETag из вашего последнего чтения.

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

<to be filled in - describe error handling here>

Must Support

Многие элементы в профилях помечены как Must Support. О том, что это означает, в каких двух контекстах используется и как обращаться с элементами, которые вы не можете заполнить, см. на отдельной странице Must Support.