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

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

General guidance

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

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

Сквозные правила, применимые ко всем профилям UZ Core. Они отвечают на вопросы, которые разработчики задают чаще всего - какие метаданные нужны каждому ресурсу, что делать, когда для поля нет значения, как кодировать единицы измерения, как объединять ресурсы в бандлы и как платформа сообщает об ошибках.

Обязательные метаданные ресурса

Каждый ресурс, передаваемый на платформе, помимо своего клинического содержания, должен содержать:

  • meta.profile - канонический URL (с версией) профиля UZ Core, которому ресурс заявляет о соответствии. Именно так сервер узнаёт, по каким правилам выполнять валидацию.
  • id - логический идентификатор ресурса на сервере. Новым ресурсам он назначается сервером.
{
  "resourceType": "Observation",
  "id": "abc-123",
  "meta": {
    "profile": ["https://dhp.uz/fhir/core/StructureDefinition/uz-core-observation"],
    "lastUpdated": "2026-05-30T09:12:00+05:00"
  }
}

Содержимое передаётся в формате JSON в кодировке UTF-8.

Отсутствующие и подавленные данные

Существует разница между «у меня нет значения» и «значения не существует», и FHIR позволяет указать, какой из случаев имеет место:

  • Значение просто отсутствует - не указывайте элемент. Не отправляйте пустую строку или заполнитель. Это допустимо для любого опционального (0..) элемента, включая опциональные элементы Must Support.
  • Обязательный элемент, но значение действительно неизвестно - вы не можете опустить элемент 1.., поэтому используйте определённый для ресурса механизм обозначения «неизвестно»: расширение data-absent-reason на элементе (пример) или код «unknown», если связанный набор значений его предоставляет (например, кодируемый элемент, привязанный к набору значений, включающему unknown).
  • Никогда не выдумывайте данные ради удовлетворения ограничения. Фальшивая дата рождения или фиктивный идентификатор хуже, чем зафиксированное отсутствие данных.

Некоторые профили добавляют явный слот data-absent-reason - например, UZ Core Patient допускает расширение data-absent-reason на элементе value идентификатора для редкого случая, когда недоступен даже идентификатор.

См. Must Support, чтобы узнать, как это взаимодействует с флагом S.

Единицы измерения и количества

Числовые измерения используют UCUM (http://unitsofmeasure.org) для кода единицы измерения:

{
  "valueQuantity": {
    "value": 7.2,
    "unit": "%",
    "system": "http://unitsofmeasure.org",
    "code": "%"
  }
}
  • Всегда заполняйте system и code машиночитаемым кодом UCUM, а не только человекочитаемой строкой unit.
  • Если результат сообщается без единицы измерения (безразмерный счёт, титр, отношение), всё равно отправляйте value; опускайте code/system, только если UCUM-единицы действительно нет.
  • Референсные диапазоны и флаги интерпретации (норма / высокое / низкое / критическое) относятся соответственно к Observation.referenceRange и Observation.interpretation.

Адреса

Адреса встречаются в нескольких ресурсах (Patient, Practitioner, Organization, Location). UZ Core поддерживает как узбекистанские, так и международные адреса.

Адрес в Узбекистане

Для административно-территориальных единиц используйте кодированные значения из официальных реестров. Платформа проверяет, что регион, район и город соответствуют кодам из системы цифрового управления населением (Digital Population Management, DPM):

{
  "address": [{
    "use": "home",
    "type": "physical",
    "country": "UZ",
    "state": "1727",            // Region code from https://terminology.dhp.uz/fhir/core/ValueSet/state-vs (e.g., 1727 for Tashkent Region)
    "district": "1727220",      // District code from https://terminology.dhp.uz/fhir/core/ValueSet/regions-vs (e.g., 1727220 for Bekobod district)
    "city": "17150085",         // Mahalla code from https://terminology.dhp.uz/fhir/core/ValueSet/mahalla-vs (citizens' assembly)
    "line": ["Amir Temur ko'chasi"],
    "text": "Yangi Sergeli mahallasi, Amir Temur ko'chasi, 15-uy, 42-xonadon"
  }]
}

Международный адрес

Для адресов за пределами Узбекистана административно-территориальные единицы указываются свободным текстом без обязательных наборов значений, что позволяет гибко представлять структуры иностранных адресов:

{
  "address": [{
    "use": "home",
    "type": "physical",
    "country": "US",
    "state": "California",             // Free text
    "district": "Los Angeles County",  // Free text
    "city": "Los Angeles",             // Free text
    "line": ["123 Main Street", "Apt 4B"],
    "postalCode": "90001"
  }]
}

Терминология и многоязычные обозначения

  • Используйте коды из связанного набора значений в соответствии с силой связки.
  • Обозначения (отображаемые названия на узбекском / русском / английском) предназначены только для отображения - смысл несёт именно code. См. Основы FHIR, чтобы узнать, как UZ CodeSystems и терминологические дополнения HL7 предоставляют эти многоязычные обозначения.
  • Коды можно проверить на терминологическом сервере платформы с помощью стандартной операции $validate-code:
POST [base]/ValueSet/$validate-code
{ "resourceType": "Parameters",
  "parameter": [
    { "name": "url", "valueUri": "https://dhp.uz/fhir/core/ValueSet/uz-core-diagnosis" },
    { "name": "system", "valueUri": "http://hl7.org/fhir/sid/icd-10" },
    { "name": "code", "valueCode": "E11" } ] }

См. Системы идентификаторов для систем идентификаторов (не терминологии).

Бандлы: document, transaction и searchset

Выбирайте Bundle.type в зависимости от того, что вы делаете:

Bundle.type Используйте для
transaction Отправки нескольких взаимозависимых ресурсов как одной атомарной единицы (все успешно или все неудачно) - например, набор лабораторных результатов (ServiceRequest + Specimen + Observation + DiagnosticReport).
batch Отправки нескольких независимых операций вместе без атомарности.
document Завершённого, юридически значимого клинического документа - Composition в качестве заголовка, за которым следуют ссылающиеся клинические ресурсы. Используется для выписных эпикризов, справок, подписанных отчётов.
searchset Возвращается сервером в ответ на поиск. Вы потребляете такие бандлы, но не создаёте их.

Когда несколько ресурсов связаны, передавайте их вместе в одном бандле, а не отдельными нескоординированными вызовами. См. Сценарии работы для конкретных примеров бандлов transaction и document.

Создание, обновление и удаление

  • Платформа поддерживает стандартные REST-взаимодействия: GET (чтение/поиск), POST (создание), PUT (обновление), PATCH (частичное обновление) и DELETE. Точные взаимодействия для каждого ресурса объявлены в CapabilityStatement.
  • Логическое удаление, а не физическое. Клинические данные не удаляются при удалении ресурса. Чтобы вывести запись из обращения, измените её статус: установите entered-in-error, inactive, revoked или эквивалент для данного ресурса в зависимости от случая. Например, отозванный Goal становится cancelled/completed, отозванное Consent устанавливается в inactive, ошибочная клиническая запись устанавливается в entered-in-error. Ресурс и его история остаются доступными для запросов.
  • Параллелизм. Обновления используют оптимистичную блокировку. Сохраняйте ETag из последнего чтения и отправляйте его обратно как If-Match при обновлении; если кто-то другой изменил ресурс с момента вашего чтения, версия больше не совпадает, и сервер отвечает 412 Precondition Failed («Version is mismatch»). Перечитайте и повторите попытку - см. Параллелизм.
  • Идемпотентность. Для рабочих и финансовых операций, которые не должны дублироваться при повторе, используйте условное создание/обновление, чтобы повторный запрос не создавал второй ресурс.

Ошибки

Когда запрос завершается неудачей - валидация, авторизация, конфликт - сервер возвращает OperationOutcome с серьёзностью, кодом и человекочитаемой диагностикой:

{
  "resourceType": "OperationOutcome",
  "issue": [{
    "severity": "error",
    "code": "required",
    "diagnostics": "Patient.identifier: minimum required = 1, but only found 0",
    "expression": ["Patient.identifier"]
  }]
}

Распространённые коды, которые вы встретите: required/value/invariant (ресурс не прошёл валидацию профиля), code-invalid (код отсутствует в связанном наборе значений), forbidden (авторизация/согласие отклонили запрос - см. руководство по контролю доступа) и 412 с кодом invalid (конфликт версий If-Match - см. Параллелизм). Читайте diagnostics и expression, чтобы найти проблемный элемент.

Куда двигаться дальше