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

Must Support

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

Многие элементы в профилях UZ Core помечены как Must Support (флаг S в таблицах профилей). На этой странице точно определено, что означает это требование.

Кратко

Если элемент помечен как Must Support, система, которая создаёт ресурс, должна уметь заполнять его при наличии соответствующих данных, а система, которая принимает ресурс, должна уметь принять и обработать его без ошибки.

Must Support определяет функциональную возможность системы. Сам по себе этот флаг не делает элемент обязательным - обязательность определяется кратностью (1..). Элемент может быть помечен Must Support и при этом оставаться необязательным (0..1): передавать его требуется только при наличии данных.

Два контекста применения Must Support

Значение флага немного различается в зависимости от профиля, в котором он используется:

  • Профили UZ Core - элемент следует заполнять при обмене ресурсом между системами в Узбекистане.
  • Профили, специфичные для DHP - Платформа DHP поддерживает этот элемент, а клиентская система должна заполнять его при наличии данных.

На практике правило в обоих случаях одинаково: передавайте элемент при наличии данных и обеспечьте возможность его приёма.

Must Have и Must Support

В верхней части страницы каждого профиля простым языком приведены два перечня:

  • "Каждый [Resource] Must Have …" - обязательные элементы (кратность 1..1 или 1..*). Они должны присутствовать всегда, иначе ресурс невалиден.
  • "Каждый [Resource] Must Support …" - элементы Must Support (флаг S). Их необходимо заполнять при наличии данных, а при получении - обрабатывать.

Конкретный пример - UZ Core Patient:

  • Must Have: как минимум один identifier.
  • Must Support: name, gender, birthDate, address, active, а также расширения для указания национальности, гражданства и управляющей организации.

Таким образом, ресурс Patient без identifier невалиден, однако Patient с действительно неизвестной датой рождения остаётся валидным: система поддерживает birthDate, но соответствующего значения у неё нет.

Что означает поддержка для разных видов элементов

Требование интерпретируется в зависимости от вида элемента:

Вид элемента Система-производитель должна … Система-потребитель должна …
Примитивный элемент (string, date, code, boolean …) уметь передавать значение при его наличии уметь читать и сохранять/отображать значение
Сложный элемент (например, address, name) уметь передавать как минимум один из вложенных элементов, которые сами помечены Must Support уметь обрабатывать эти вложенные элементы
Reference уметь передавать Reference на указанный целевой профиль или профили уметь разрешать Reference и переходить по нему
Кодированный элемент (привязан к ValueSet) уметь передавать код из привязанного ValueSet уметь интерпретировать коды из этого ValueSet
Элемент со срезами уметь передавать срезы, соответствующие имеющимся данным уметь обрабатывать любой из полученных определённых срезов

Если данные отсутствуют

Система-производитель, которая поддерживает элемент, но не имеет для него значения, должна соблюдать правила из раздела Общие рекомендации → Отсутствующие и скрытые данные. Кратко:

  • Если значение просто отсутствует, элемент следует опустить (если только его наличие не является обязательным согласно кратности).
  • Если элемент обязателен, но значение действительно неизвестно, вместо вымышленного значения используйте соответствующий код unknown или механизм data-absent-reason.
  • Никогда не передавайте значение-заполнитель или фиктивное значение только для того, чтобы выполнить требование Must Support. Также не передавайте вместо значения пустой элемент или пустую строку - элемент следует опустить.

Как проверяется соблюдение Must Support

Платформа DHP проверяет каждую операцию создания и обновления на соответствие применимому профилю и связанным с ним ValueSet: проверяются структура, кратность, типы данных и терминологические привязки. Ресурс, нарушающий обязательную кратность или терминологическую привязку со степенью required, отклоняется с возвратом OperationOutcome (см. Общие рекомендации → Ошибки). Сервер не может отклонить ресурс на основании правил Must Support, относящихся к системам-потребителям (системам, принимающим данные). Однако соответствие вашей системы этим правилам всё равно проверяется до её подключения к Платформе.

Чем Must Support не является

  • Это не то же самое, что обязательность. Необязательный элемент Must Support может отсутствовать, если данных нет.
  • Это не означает "отображать в пользовательском интерфейсе". Требование означает, что система технически способна обработать элемент; способ его представления определяется проектным решением.
  • Требование не становится менее строгим из-за неудобства реализации. Если система не может создавать или обрабатывать элемент Must Support, она не соответствует требованиям.

Что читать дальше