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

How to read this guide

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

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

Если вы совсем не знакомы с FHIR, сначала начните с основ FHIR, а затем вернитесь к этой странице.

Что такое профиль

UZ Core не создает новые структуры данных. Каждый профиль UZ Core берет стандартный ресурс FHIR R5 (например, Patient или Observation) и добавляет поверх него национальные правила: какие элементы являются обязательными, какие должны поддерживаться, какие национальные системы идентификаторов и терминологии следует использовать, а также какие расширения, специфичные для Узбекистана, применяются. Ресурс FHIR, соответствующий профилю UZ Core, также является валидным базовым ресурсом FHIR.

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

Четыре представления на странице профиля

На каждой странице профиля (например, UZ Core Patient) над таблицей элементов отображается один и тот же набор вкладок, соответствующих различным представлениям профиля:

Для большинства задач по реализации достаточно вкладки Key Elements, а также пояснительного текста на этой странице и на странице профиля.

Как работать с таблицей элементов

Каждая строка таблицы соответствует одному элементу (полю). Столбцы:

• Name - путь элемента, например, Patient.identifier или Observation.value[x]. Отступы показывают вложенность.

• Flags - короткие обозначения, которые показывают наиболее важные правила:

  Флаги	Значение	Что это означает для вас
  S	Must Support	Вы должны уметь заполнять этот элемент, когда у вас есть данные, и обрабатывать его при получении. См. Must Support.
  ?!	Элемент-модификатор	Этот элемент/расширение изменяет смысл ресурса (например, status = entered-in-error). Приложения должны обрабатывать этот элемент/расширение и не могут его игнорировать.
  Σ	Summary-элемент	Возвращается в кратких результатах поиска.
  C	Есть ограничение	Применяется invariant - наведите указатель на элемент или см. раздел Constraints.
  I	Invariant	Формальное правило (FHIRPath), которому должны соответствовать данные.

• Кратность - сколько раз элемент может встречаться:

  Кратность	Значение
  1..1	Обязательный, ровно один раз. Его необходимо передавать.
  1..*	Обязательный, как минимум один раз.
  0..1	Необязательный, не более одного раза.
  0..*	Необязательный, любое количество раз.

  Обязательные элементы (1..) составляют набор "Must Have". Элементы Must Support (S) составляют набор "Must Support". Описательный текст в верхней части каждой страницы профиля перечисляет оба набора простым языком, чтобы вам не приходилось расшифровывать таблицу.

• Type - тип данных или, для references, ресурс(ы), на которые он указывает. Reference вида Reference(UZ Core Patient) означает, что он должен указывать на ресурс, соответствующий этому профилю.
• Description & Constraints - определение, привязка к ValueSet и любые фиксированные значения.

References и CodeableReferences

Два разных типа указывают на другие ресурсы и по-разному вкладываются в JSON.

Обычный Reference указывает только на другой ресурс. Указатель задается строкой в ключе reference:

"patient": { "reference": "Patient/example" }

CodeableReference - это тип FHIR R5, который может передавать в одном и том же поле кодированное понятие, reference на ресурс или оба значения сразу. Поэтому поле вроде Immunization.reason может означать: "по этой кодированной причине" или "на основании этого ресурса Condition". Когда CodeableReference указывает на ресурс, reference находится на один уровень глубже - внутри объекта reference:

"reason": [
  { "reference": { "reference": "Condition/example" } }
]

Чтобы передать код вместо указателя, используйте concept:

"reason": [
  { "concept": { "coding": [{ "system": "...", "code": "..." }] } }
]

Столбец Type показывает, с чем вы работаете: Reference(...) или CodeableReference(...). В случае сомнений определение соответствующего поля в базовой спецификации FHIR R5 является авторитетным источником.

Срезы (Slices)

Некоторые элементы разделяются на срезы: один и тот же элемент делится на именованные варианты со своими правилами. Например, Patient.identifier разделяется на nationalId, passportLocal, passportForeign и другие срезы, каждый из которых закреплен за конкретной национальной системой идентификаторов. В таблице срезы отображаются как вложенные строки под соответствующим элементом, с названием среза в скобках, например identifier:nationalId. Заполняйте тот срез, который соответствует вашим данным; заполнять все срезы не требуется.

Полный набор срезов идентификаторов пациентов, медицинских работников и организаций, а также их URI систем см. в разделе "Системы идентификаторов".

Кодированные значения (CodeableConcept)

Большинство кодированных элементов используют тип CodeableConcept: ноль или более записей coding плюс необязательный свободный текст в поле text.

• Каждый coding состоит из system + code (+ display) взятых из CodeSystem.
• text - человекочитаемая формулировка для понятия в целом, обычно исходная формулировка из первичного источника. Указывайте text, если подходящего кода нет, или вместе с кодом/кодами, чтобы сохранить фактически записанную формулировку.
• Можно указать более одного coding, но все coding внутри одного CodeableConcept должны означать одно и то же. Например, это может быть одно и то же понятие, выраженное в SNOMED CT и в национальной системе кодирования. Это переводы одного понятия, а не список разных клинических находок. Чтобы зафиксировать несколько разных понятий, повторите элемент, то есть используйте несколько CodeableConcept, вместо того чтобы помещать их в один.

"code": {
  "coding": [
    { "system": "http://snomed.info/sct", "code": "25064002", "display": "Headache" },
    { "system": "http://hl7.org/fhir/sid/icd-10", "code": "R51", "display": "Headache" }
  ],
  "text": "Headache"
}

Если подходящего кода нет, укажите только text - имеющуюся у вас формулировку, без coding:

"code": {
  "text": "Throbbing pain behind the left eye since this morning"
}

Степень привязки на элементе (см. ниже) определяет, разрешено ли это: привязка required отклоняет значение только с text - как минимум один coding должен быть из ValueSet, - тогда как привязки extensible, preferred и example допускают text, если подходящего кода нет.

Терминологические привязки

Когда элемент привязан к ValueSet, степень обязательности привязки показывает, насколько строго нужно соблюдать эту привязку:

• required - необходимо использовать код из ValueSet.
• extensible - используйте код из ValueSet, если подходящий код есть; в противном случае можно использовать другой код.
• preferred - использование ValueSet рекомендуется, но не является обязательным.
• example - приведено только в качестве примера; можно использовать любой код.

UZ Core публикует национальные CodeSystem и ValueSet на узбекском языке с переводами на русский и английский, а также дополняет международную терминологию HL7 переводами на узбекский и русский языки. Коды можно валидировать на терминологическом сервере Платформы - см. раздел Общие рекомендации.

Соглашения, используемые во всем UZ Core

• Профили построены на базе FHIR R5 и описывают только национальные отличия.
• Идентификаторы следуют единой иерархической схеме (https://dhp.uz/fhir/core/sid/...). См. раздел "Системы идентификаторов".
• Имена и другой человекочитаемый текст используют узбекский язык как основной, а переводы передаются как designations.
• Ожидается, что каждый ресурс содержит метаданные профиля и Provenance - см. раздел "Общие рекомендации".
• Платформа валидирует каждый create/update-запрос по соответствующему профилю и ValueSet и при ошибке возвращает OperationOutcome. Поэтому правила на этих страницах являются обязательными, а не рекомендательными.

Куда перейти дальше

• Must Support - что обязывает делать флаг S.
• Общие рекомендации - сквозные правила: отсутствующие данные, единицы измерения, Bundles, терминология, логическое удаление.
• Рабочие процессы - сквозные сценарии, показывающие, какие ресурсы создавать, в каком порядке и для какой реальной клинической задачи.
• Каждая страница профиля - описание "Must Have / Must Support" и раздел "Quick Start" с примерами API-вызовов.