Единая платформа цифрового здравоохранения Узбекистана
0.5.0 - ci-build
Единая платформа цифрового здравоохранения Узбекистана
0.5.0 - ci-build
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/ и регулярно изменяется. Смотрите каталог опубликованных версий
На этой странице представлены переводы с языка оригинала, на котором былонаписано руководство. Информацию об этих переводах и инструкции попредоставлению отзывов о переводах можно найти здесь.
Машинный перевод, требуется проверка человеком. Эта страница автоматически переведена с английского языка с помощью искусственного интеллекта и пока не проверена редактором. При любых расхождениях приоритет имеет оригинальная англоязычная версия.
Эта страница объясняет, как читать профили UZ Core, чтобы вы могли перейти от «у меня есть клиническая задача» к «вот ресурс и вот поля, которые мне нужны». Прочитайте её один раз перед началом внедрения - она объясняет соглашения, используемые на каждой странице профиля.
Если вы совсем не знакомы с FHIR, начните сначала с Основ FHIR, а затем вернитесь сюда.
UZ Core не изобретает новые структуры данных. Каждый профиль UZ Core берёт стандартный ресурс FHIR R5 (например, Patient или Observation) и добавляет к нему национальные правила: какие элементы обязательны, какие должны поддерживаться, какие национальные системы идентификаторов и терминологии использовать, и какие специфичные для Узбекистана расширения применяются. Ресурс FHIR, валидный относительно профиля UZ Core, также является валидным базовым ресурсом FHIR.
Поскольку профили только добавляют правила, страница профиля в основном сообщает вам, что отличается от базового FHIR - что вы должны заполнить и что вы должны уметь обрабатывать. Всё остальное ведёт себя точно так же, как в базовой спецификации FHIR R5.
Каждая страница профиля (например, UZ Core Patient) показывает один и тот же набор вкладок над таблицей элементов:
| Представление | Что оно показывает | Когда его использовать |
|---|---|---|
| Key Elements | Ограниченные, обязательные для поддержки и обязательные элементы - подобранный краткий список | Начните здесь. Это представление «что мне действительно нужно». |
| Differential | Только то, что UZ Core изменил относительно базового FHIR | Чтобы увидеть национальные правила с одного взгляда. |
| Snapshot | Каждый элемент ресурса, базовый + профиль | Когда вам нужна полная картина элемента, которого вы не видите в других местах. |
| All | Всё, включая сопоставления и ограничения | Справочник. |
Для большинства задач внедрения представления Key Elements плюс описательного текста на этой странице и странице профиля достаточно.
Каждая строка в таблице - это один элемент (поле). Столбцы такие:
Patient.identifier или Observation.value[x]. Отступ показывает вложенность.Flags - короткие символы, несущие наиболее важные правила:
| Флаг | Значение | Что это значит для вас |
|---|---|---|
| S | Must Support | Вы должны уметь заполнять это, когда у вас есть данные, и обрабатывать это, когда вы их получаете. См. Must Support. |
| ?! | Элемент-модификатор | Этот элемент/расширение изменяет смысл ресурса (например, status = entered-in-error). Приложения должны обрабатывать этот элемент/расширение и не имеют права его игнорировать. |
| Σ | Элемент сводки | Возвращается в сводках поиска. |
| C | Имеет ограничение | Применяется инвариант - наведите курсор на элемент или прочитайте раздел «Ограничения». |
| I | Инвариант | Формальное правило (FHIRPath), которому должны удовлетворять данные. |
Cardinality - сколько раз элемент может появляться:
| Кардинальность | Значение |
|---|---|
1..1 |
Обязательно, ровно один. Вы обязаны его отправить. |
1..* |
Обязательно, по крайней мере один. |
0..1 |
Опционально, не более одного. |
0..* |
Опционально, любое количество. |
Обязательные (1..) элементы образуют набор «Must Have». Обязательные для поддержки (S) элементы образуют набор «Must Support». Описательный текст в начале каждой страницы профиля перечисляет оба набора простым языком, чтобы вам не приходилось расшифровывать таблицу.
Reference(UZ Core Patient) означает, что она должна указывать на ресурс, соответствующий этому профилю.Два разных типа указывают на другие ресурсы, и они по-разному вкладываются в JSON.
Простой Reference указывает только на другой ресурс. Указатель - это строка под ключом reference:
"patient": { "reference": "Patient/example" }
CodeableReference - это тип FHIR R5, который может нести либо кодированное понятие, либо ссылку на ресурс (или оба) в одном поле - так что поле вроде Immunization.reason может сказать «из-за этой кодированной причины» или «из-за этого ресурса Condition». Когда он указывает на ресурс, ссылка находится на один уровень глубже, вложенная внутрь объекта reference:
"reason": [
{ "reference": { "reference": "Condition/example" } }
]
а чтобы указать код вместо указателя, используйте concept:
"reason": [
{ "concept": { "coding": [{ "system": "...", "code": "..." }] } }
]
Столбец Type сообщает вам, с каким из них вы имеете дело: Reference(...) против CodeableReference(...). В случае сомнений авторитетным является определение базового FHIR R5 каждого поля.
Некоторые элементы слайсируются - один и тот же элемент разделяется на именованные варианты со своими собственными правилами. Например, Patient.identifier слайсируется на nationalId, passportLocal, passportForeign и так далее, каждый из которых зафиксирован на конкретной национальной системе идентификаторов. В таблице слайсы появляются как строки с отступом под элементом с именем слайса в скобках, например identifier:nationalId. Заполняйте тот слайс, который соответствует вашим данным; вам не нужно заполнять каждый слайс.
См. Системы идентификаторов для полного набора слайсов идентификаторов пациента, практикующего специалиста и организации и их системных URI.
Большинство кодированных элементов используют тип CodeableConcept: ноль или более записей coding плюс опциональный свободный текст text.
coding - это system + code (+ display), взятые из CodeSystem.text - это человекочитаемая фраза для понятия в целом - обычно исходная формулировка из источника. Указывайте её, когда ни один код не подходит, или вместе с кодом(ами), чтобы сохранить то, что было фактически записано.coding, но каждый coding в одном CodeableConcept должен означать одно и то же - например, одно и то же понятие, выраженное в SNOMED CT и в национальной системе кодов. Это переводы одного понятия, а не список разных находок. Чтобы записать несколько различных понятий, повторите элемент (несколько CodeableConcepts), а не упаковывайте их в один."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 отклоняет значение только из текста - по крайней мере один coding должен быть из набора значений - тогда как связки extensible, preferred и example допускают текст, когда подходящий код недоступен.
Когда элемент связан с набором значений, сила связки сообщает вам, насколько она строгая:
UZ Core публикует национальные CodeSystems и ValueSets на узбекском языке (с переводами на русский и английский) и дополняет международную терминологию HL7 переводами на узбекский/русский. Коды можно валидировать на терминологическом сервере платформы - см. Общие рекомендации.
https://dhp.uz/fhir/core/sid/...). См. Системы идентификаторов.OperationOutcome при сбое - так что правила на этих страницах принудительно применяются, а не носят рекомендательный характер.S.