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

На каждой странице профиля вверху приведены два набора простым языком:

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

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

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

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

Что означает "поддержка" в зависимости от вида элемента

Обязательство трактуется в зависимости от вида элемента:

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

Когда у вас нет данных

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

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

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

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

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

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

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