Главная // Актуальные документы // Актуальные документы (обновление 2025.04.26-2025.05.31) // ПНСТ (Предварительный национальный стандарт)
СПРАВКА
Источник публикации
М.: ФГБУ "Институт стандартизации", 2025
Примечание к документу
Документ введен в действие с 01.02.2025 на период до 01.02.2028 (Приказ Росстандарта от 27.12.2024 N 126-пнст).
Название документа
"ПНСТ 995-2024. Предварительный национальный стандарт Российской Федерации. Системы киберфизические. Персональные медицинские помощники. Форматы обмена данными. Общие требования"
(утв. и введен в действие Приказом Росстандарта от 27.12.2024 N 126-пнст)

"ПНСТ 995-2024. Предварительный национальный стандарт Российской Федерации. Системы киберфизические. Персональные медицинские помощники. Форматы обмена данными. Общие требования"
(утв. и введен в действие Приказом Росстандарта от 27.12.2024 N 126-пнст)


Содержание


Утвержден и введен в действие
Приказом Федерального агентства
по техническому регулированию
и метрологии
от 27 декабря 2024 г. N 126-пнст
ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
СИСТЕМЫ КИБЕРФИЗИЧЕСКИЕ
ПЕРСОНАЛЬНЫЕ МЕДИЦИНСКИЕ ПОМОЩНИКИ
ФОРМАТЫ ОБМЕНА ДАННЫМИ. ОБЩИЕ ТРЕБОВАНИЯ
Cyberphysical systems. Personal health assistants.
Data exchange formats. General requirements
ПНСТ 995-2024
ОКС 35.240.80
Срок действия
с 1 февраля 2025 года
до 1 февраля 2028 года
Предисловие
1 РАЗРАБОТАН Фондом "Технопарк Академгородка" (ИЦ НТИ Хелснет)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 194 "Кибер-физические системы"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 27 декабря 2024 г. N 126-пнст
Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16-2011 (разделы 5 и 6).
Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 630090 г. Новосибирск, ул. Николаева, 12, и/или в Федеральное агентство по техническому регулированию и метрологии по адресу: 123112 Москва, Пресненская набережная, д. 10, стр. 2.
В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе "Национальные стандарты" и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)
Введение
Актуальность настоящего стандарта связана с постоянно расширяющейся практикой дистанционного мониторинга лечащими врачами пациентов с различными хроническими заболеваниями, а также проходящими длительное амбулаторное лечение или нуждающимися в постоянном наблюдении (беременные, дети, пожилые граждане, инвалиды), реабилитации и информационной поддержке для поддержания здоровья, ведения здорового или рекомендованного образа жизни. Учитывая современные тенденции развития общества, технологий и здравоохранения, сегмент дистанционного мониторинга пациентов их лечащими врачами будет постоянно расти опережающими темпами относительно других технологий здравоохранения. Сегодня технологии дистанционного контроля, ведения и информационной поддержки пациентов находятся в зачаточном состоянии, равно как и рынок медицинских устройств, позволяющих пациентам самостоятельно измерять необходимые физиологические показатели и оперативно предоставлять к ним доступ врачам и системе здравоохранения. Кроме того, развитию систем дистанционного мониторинга здоровья препятствуют многие организационные и финансовые барьеры, однако в 2022 году в Российской Федерации стартовал масштабный проект "Персональные медицинские помощники", поставивший амбициозную цель - к 2030 году обеспечить услугами дистанционного мониторинга 20% населения России. В настоящий момент в пилотный проект по "Персональным медицинским помощникам" вошли только две нозологии: артериальная гипертензия и диабет. А его основной целью является оперативная доставка в медорганизацию показателей артериального давления и глюкозы крови, самостоятельно измеренной пациентом. Однако сама масштабность принятого проекта, а также быстрое развитие рынка медицинских устройств для персонального использования, позволяющих пациентам измерять различные показатели своего организма, являются очевидным предвестником расширения сферы применения "Персональных медицинских помощников".
Также важно отметить, что для полноценного дистанционного врачебного мониторинга недостаточно объективных физиологических показателей, измеренных медицинскими устройствами. Нужны также субъективные оценки самочувствия и состояния, фиксируемые в дневниках самонаблюдения и питания, а также контроль приверженности назначенному лечению с помощью дневников медикаментозной терапии и других инструментов дистанционного обмена информацией между врачом и пациентом.
Настоящий стандарт описывает форматы обмена данными в экосистеме "Персональных медицинских помощников" и охватывает широкий круг дистанционных взаимодействий между пациентом и его лечащим врачом. Предложенные в нем форматы и процедуры информационного обмена должны обеспечить не только сегодняшний (пилотный) этап функционирования "Персональных медицинских помощников", но и перспективное развитие и распространение их действия на другие нозологии и клинические ситуации, подключение широкого круга персональных медицинских устройств, появляющихся на рынке, а также расширение спектра информационных взаимодействий врача и пациента.
Стандарт разработан на основе анализа зарубежного и отечественного опыта и базируется на существующих международных стандартах и иных документах, описывающих взаимодействие в указанной сфере.
Стандарт будет полезен как разработчикам информационных систем и платформ, реализующих различные составляющие "Персональных медицинских помощников", так и производителям персональных медицинских устройств, позволяя бесшовно включать их разработки в экосистему дистанционного мониторинга здоровья.
1 Область применения
Настоящий стандарт устанавливает общие требования к форматам обмена данными в коммуникационной инфраструктуре персональных медицинских помощников, обеспечивающей дистанционный мониторинг состояния здоровья пациентов - пользователей персональных медицинских приборов, включающей в себя персональные медицинские приборы, менеджеры персональных медицинских приборов и шлюзы Интернета вещей, сервисы хранения и обработки результатов измерений, медицинские информационные системы и обеспечивающей дистанционный мониторинг состояния здоровья пациентов - пользователей персональных медицинских приборов (рисунок 1).
Рисунок 1 - Коммуникационная инфраструктура персональных
медицинских помощников
В качестве менеджеров персональных медицинских приборов могут выступать мобильные приложения, программное обеспечение персональных компьютеров, микропрограммы специализированных шлюзов (например, коммутаторов ЛВС). В качестве интерфейсов персональных/локальных вычислительных сетей (ПВС/ЛВС) чаще всего используются проводные интерфейсы Ethernet, USB и беспроводные интерфейсы WiFi, IrDA, Bluetooth, Bluetooth LE, Zigbee, NFC, а также российские стандартизованные протоколы для интернета вещей: NB-Fi, LoraWAN Ru, OpenUNB, NB-IoT. Сервис хранения и обработки результатов измерений может быть реализован в составе медицинской информационной системы или как отдельная платформа персональных медицинских помощников.
Требования стандарта распространяются на форматы обмена данными при следующих информационных взаимодействиях:
а) между персональным медицинским прибором и шлюзом Интернета вещей или менеджером персональных медицинских приборов;
б) между шлюзом Интернета вещей и сервисом хранения и обработки результатов измерений;
в) между менеджером персонального медицинского прибора и сервисом хранения и обработки результатов измерений;
г) между медицинской информационной системой и сервисом хранения и обработки результатов измерений.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие документы:
ГОСТ 7.67 Система стандартов по информации, библиотечному и издательскому делу. Коды названий стран
ГОСТ Р 7.0.64 (ИСО 8601:2004) Система стандартов по информации, библиотечному и издательскому делу. Представление дат и времени. Общие требования
ГОСТ Р 34.11 Информационная технология. Криптографическая защита информации. Функция хэширования
ГОСТ Р ИСО/МЭК 7498-1 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель
ГОСТ Р ИСО/МЭК 8824-1 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации
ГОСТ Р ИСО/МЭК 9834-1 Информационная технология. Взаимосвязь открытых систем. Процедуры действий уполномоченных по регистрации ВОС. Часть 1. Общие процедуры и верхние дуги дерева идентификатора объекта АСН.1
ГОСТ Р ИСО/МЭК 9834-8 Информационная технология. Взаимосвязь открытых систем. Процедуры работы уполномоченных по регистрации ВОС. Часть 8. Создание, регистрация универсально уникальных идентификаторов (УУИд) и их использование в качестве компонентов идентификатора объекта АСН.1
ГОСТ Р 56842/ISO/IEEE 11073-10101:2004 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10101. Номенклатура
ГОСТ Р 56845/ISO/IEEE 11073-20601:2016 Информатизация здоровья. Обмен данными с персональными медицинскими приборами. Часть 20601. Прикладной профиль. Оптимизированный протокол обмена
ОКВ ОК (МК (ИСО 4217) 003-97) 014 Общероссийский классификатор валют
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется принять в части, не затрагивающей эту ссылку.
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1 персональные медицинские помощники: Комплексная система, включающая программные и технические средства для обеспечения дистанционного наблюдения за состоянием здоровья пациента, в том числе платформу, медицинские изделия с функцией дистанционной передачи данных, а также устройства, предназначенные для регистрации параметров состояния здоровья человека (вместе - медицинские приборы), и информационные системы, предназначенные для дистанционного наблюдения за состоянием здоровья пациентов.
3.2
медицинский прибор (medical device): Прибор (аппаратура или система приборов), используемый для мониторинга состояния, выполнения процедур или терапии пациента и обычно не оказывающий влияние на процессы метаболизма.
[ГОСТ Р 56843-2015/ISO/IEEE 11073-10201:2004, пункт 3.36]
3.3
персональный медицинский прибор (personal health device): Прибор, используемый для личного медицинского применения.
[ГОСТ Р 56845-2019/ISO/IEEE 11073-20601:2016, пункт 3.1.13]
3.4
Интернет вещей; IoT (Internet of Things): Инфраструктура взаимосвязанных сущностей, систем и информационных ресурсов, а также служб, позволяющих обрабатывать информацию о физическом и виртуальном мире и реагировать на нее.
[ГОСТ Р 71777-2024 (ИСО/МЭК 20924:2024), статья 3.13]
3.5
менеджер (manager): Узел, получающий данные от одного или нескольких персональных медицинских приборов по локальной или персональной вычислительной сети.
[Адаптировано из ГОСТ Р 56845-2019/ISO/IEEE 11073-20601:2016, пункт 3.1.9]
3.6 шлюз Интернета вещей: Узел, получающий данные от одного или нескольких персональных медицинских приборов по протоколу Интернета вещей.
4 Обозначения и сокращения
АСН.1 - Абстрактная синтаксическая нотация версии один, определенная в стандарте ГОСТ Р ИСО/МЭК 8824-1;
ИВЛ - аппарат искусственной вентиляции легких;
ИНН - индивидуальный номер налогоплательщика;
ЛВС - локальная вычислительная сеть;
МИС - медицинская информационная система;
МКБ - международная классификация болезней и проблем, связанных со здоровьем;
ОГРН - основной государственный регистрационный номер;
ОИД - объектный идентификатор, структура которого описана в стандарте ГОСТ Р ИСО/МЭК 8824-1, а правила присваивания - в стандарте ГОСТ Р ИСО/МЭК 9834-1;
ПВС - персональная вычислительная сеть;
ПМП - персональный медицинский прибор;
СНИЛС - страховой номер индивидуального лицевого счета;
УУИД - универсальный уникальный идентификатор (см. UUID);
ЭКГ - электрокардиограмма;
API - прикладной программный интерфейс (Application Programming Interface);
BCP - лучшие текущие практики, рекомендации, публикуемые организацией Internet Engineering Task Force (IETF) для использования в сети Интернет (Best Current Practices);
FHIR - ресурсы быстрой интероперабельности в здравоохранении, спецификация электронной передачи данных между медицинскими информационными системами (Fast Healthcare Interoperability Resources);
GPS - система глобального позиционирования (Global Positioning System);
GUID - глобально уникальный идентификатор, вариант реализации UUID (Globally Unique Identifier);
HL7 - Международная организация по разработке стандартов информатизации здоровья (Health Level Seven International);
HTML - язык разметки гипертекста (HyperText Markup Language);
HTTP - протокол передачи гипертекста, сетевой протокол прикладного уровня (Hypertext Transfer Protocol);
IrDA - обмен данными по инфракрасному излучению, беспроводная передача информации с помощью инфракрасного излучения (Infrared Data Association);
JSON - нотация объектов JavaScript (JavaScript Object Notation);
LOINC - логические названия и коды идентификаторов исследований (Logical Observation Identifiers Names and Codes);
MDC - коммуникация с медицинскими устройствами, номенклатура терминов коммуникация с медицинскими приборами (Medical Device Communication);
MDS - система медицинского прибора, класс, описывающий сведения о медицинском приборе (Medical Device System);
MIME - многоцелевые расширения электронной почты в сети Интернет, протокол передачи различных типов содержания по электронной почте (Multipurpose Internet Mail Extensions);
MQTT - транспорт телеметрии с помощью очереди сообщений, протокол передачи сообщений Интернета вещей (Message Queuing Telemetry Transport);
NFC - связь в близком поле, технология беспроводной передачи данных малого радиуса действия (Near field communication);
REST - передача репрезентативного состояния, архитектурный стиль взаимодействия компонентов распределенного приложения (Representational State Transfer);
RFC - документ, публикуемый организацией Internet Engineering Task Force (IETF) в качестве стандартов Интернет (Request for comment);
RPC - удаленный вызов процедуры (Remote Procedure Call);
SNOMED CT - систематизированная номенклатура медицины, клинические термины (The Systematized Nomenclature of Medicine, Clinical Terms);
UCUM - унифицированные коды единиц измерений (Unified Code for Units of Measure);
UML - унифицированный язык моделирования, визуальный язык моделирования данных и процессов (Unified Modeling Language);
URI - унифицированный идентификатор ресурса (Uniform Resource Identifier);
URL - унифицированный указатель местонахождения ресурса, адрес ресурса в сети Интернет (Uniform Resource Locator);
USB - универсальная последовательная шина, последовательный интерфейс для подключения периферийных устройств к вычислительной технике (Universal Serial Bus);
UUID - универсальный уникальный идентификатор, правила присваивания которого определены в стандарте ГОСТ Р ИСО/МЭК 9834-8 (Universally Unique Identifier);
WiFi - беспроводная точность, технология беспроводной локальной сети (Wireless Fidelity);
XAdES - представление усиленной квалифицированной электронной подписи на языке XML (XML Advanced Electronic Signatures);
XHTML - расширяемый язык разметки гипертекста, серия спецификаций, усиливающих требования к представлению гипертекста, совместимому с требованиями языка XML (eXtensible HyperText Markup Language);
XML - расширяемый язык разметки (eXtensible Markup Language);
XSD - определение схемы XML-документа (XML Schema Definition).
5 Форматы обмена данными с персональными медицинскими приборами
Форматы обмена данными между персональным медицинским прибором (ПМП) и шлюзом Интернета вещей или менеджером персональных медицинских приборов (далее - менеджер ПМП или менеджер) регламентируются на прикладном уровне модели взаимосвязи открытых систем (см. ГОСТ Р ИСО/МЭК 7498-1). Общие требования к этим форматам установлены в стандарте ГОСТ Р 56845. Для ряда специализаций персональных медицинских приборов эти требования конкретизированы в [1] - [21].
В состав форматов обмена данными входят элементы с кодируемыми значениями. В качестве системы кодирования этих значений следует использовать номенклатуру коммуникаций с медицинскими приборами MDC, определенную в ГОСТ Р 56842. Стандарты специализаций приборов содержат дополнения к этой номенклатуре.
Если персональный медицинский прибор не поддерживает обмен данными в соответствии с ГОСТ Р 56845, то рекомендуется обеспечить преобразование его данных в форматы, предусмотренные ГОСТ Р 56845 и ГОСТ Р 56842. Такое преобразование может быть выполнено с помощью специализированного модуля в составе программного обеспечения менеджера ПМП или шлюза Интернета вещей.
6 Форматы обмена данными с сервисом хранения и обработки результатов измерений
6.1 Общие требования
Взаимодействия с сервисом хранения и обработки результатов измерений описаны на уровне архитектурного стиля REST с использованием протокола HTTP. В основу требований к этим взаимодействиям положена спецификация FHIR - ресурсы быстрой интероперабельности в здравоохранении версии 5.0 [22], разработанная организацией HL7. Эта спецификация предоставляется по лицензии Creative Commons "No Rights Reserved" [23], то есть без сохранения прав. Ограничения накладываются только на использование товарных знаков и .
Настоящий стандарт не противоречит спецификации [22], и предложенные в нем форматы обмена могут быть реализованы с помощью свободно распространяемого программного обеспечения HAPI FHIR [24].
Примечание - Применение других версий спецификации FHIR, а также набора используемых ресурсов допустимо для существующих информационных систем в ПМП при наличии опубликованных интеграционных профилей (документов, регламентирующих порядок взаимодействия и описание ресурсов).
6.2 Требования к модели данных в форматах взаимодействия
Сервис хранения и обработки результатов измерений получает и предоставляет данные с помощью запросов HTTP в архитектурном стиле REST. Эти данные поступают в хранилище результатов измерений. Модель данных хранилища результатов измерений описана в терминах ресурсов данных и их профилей.
Выбор типов ресурсов данных определен исходя из следующего сценария:
а) основным назначением сервиса хранения и обработки результатов измерений (далее - сервис) является обеспечение информационного взаимодействия между пациентом и лечащим врачом в процессе дистанционного мониторинга;
б) для взаимодействия пациент использует персональные медицинские приборы и менеджеры этих приборов (в качестве менеджеров могут выступать смартфоны, планшеты, персональные компьютеры, облачные решения и шлюзы Интернета вещей), а врач использует рабочее место МИС;
в) дистанционный мониторинг осуществляется в соответствии с планом ведения, назначенным лечащим врачом;
г) план ведения ограничен следующими мероприятиями:
1) сбор результатов измерений, выполняемых ПМП,
2) ведение дневников питания, самонаблюдений, приема лекарств,
3) передача пациенту этапного эпикриза в процессе выполнения плана ведения и по его завершении;
д) в процессе выполнения плана пациенту и лечащему врачу могут выдаваться предупреждения и напоминания, например предупреждения об аномальном результате измерений или напоминания о необходимости приема лекарственного препарата;
е) состав информации, передаваемый сервису хранения и обработки результатов измерений, должен быть минимально достаточным для взаимодействия пациента с лечащим врачом в рамках назначенного плана ведения.
Концептуальная диаграмма хореографии данного сценария показана на рисунке 2.
Рисунок 2 - Диаграмма хореографии сценария взаимодействия
Взаимодействие менеджера ПМП с сервисом может осуществляться не только по подписке, например, с помощью запросов на получение данных, передаваемых сервису по расписанию.
МИС передает сервису запросы на регистрацию подписки участникам взаимодействия (рисунок 3), а затем отправляет сервису план ведения дистанционного мониторинга, который по подписке доставляется менеджеру ПМП (рисунок 4). Взаимодействие участников при выполнении плана ведения показано на рисунке 5.
Рисунок 3 - Регистрация подписок
Рисунок 4 - Назначение плана ведения
Рисунок 5 - Выполнение плана ведения
ПМП выполняет измерение и передает полученный результат менеджеру ПМП или шлюзу Интернета вещей, который преобразует результат в формат REST API и передает его сервису. Преобразованный результат по подписке или по запросу доставляется МИС. Если результат выходит за пределы целевого диапазона, указанного в плане ведения, то МИС передает сервису соответствующее предупреждение, которое по подписке доставляется менеджеру ПМП и затем пациенту. По событию, предусмотренному в плане ведения, например, по завершению плана ведения или по истечению определенного срока, в МИС формируется этапный эпикриз, который может быть передан сервису и в соответствии с порядком взаимодействия доставляется менеджеру ПМП и затем пациенту.
В процессе выполнения план может быть скорректирован (рисунок 6).
Рисунок 6 - Коррекция плана ведения
При реализации этой схемы должна быть использована машина рабочих процессов, контролирующая выполнение мероприятий, назначенных в плане ведения, и инициирующая передачу менеджеру ПМП (а через него пациенту) соответствующих предупреждений и напоминаний. Такая машина может быть развернута в менеджере ПМП, в сервисе, в МИС или в облачном решении. Размещение машины рабочих процессов и взаимодействие с ней не входит в область применения настоящего стандарта.
Персональный медицинский прибор может быть связан с менеджером ПМП, и в этом случае менеджер будет осуществлять преобразование результата измерений в формат REST API и передачу преобразованного результата сервису хранения результатов измерений.
Предупреждение об аномальном результате измерений или ином событии, требующем реакции от пациента, может формироваться автоматически, например, при получении от ПМП статуса ошибки позиционирования датчика, или с участием медицинского работника. Эти детали информационного взаимодействия влияют на содержание передаваемых данных и события передачи, но используемые типы ресурсов могут оставаться теми же самыми.
Для большей части выбранных типов ресурсов рекомендованы профили, которые могут быть доработаны с учетом особенностей реализации сервиса хранения и обработки результатов измерений и потенциального расширения специализаций персональных медицинских приборов и их функций. В связи с этим для выбранных типов ресурсов даются полные описания, которые могут быть использованы для решения более широких задач, и на основе этих описаний предлагаются профили, специфичные для задачи дистанционного мониторинга.
7 Метамодель данных хранилища результатов измерений
7.1 Источник
Метамодель данных хранилища результатов измерений основана на спецификации [22].
7.2 Верхний уровень
Верхний уровень метамодели данных хранилища результатов измерений показан на рисунке 7.
Рисунок 7 - Верхний уровень метамодели данных
хранилища результатов измерений
Он представлен следующими пакетами сущностей:
а) ресурсы данных - ресурсы REST, с помощью которых хранилище импортирует и экспортирует результаты измерений;
б) терминологические ресурсы - коллекции кодируемых понятий, представленные в форме систем кодирования и наборов значений;
в) типы данных - простые и комплексные типы данных, используемые при описании элементов ресурсов данных;
г) Rest API - операции над экземплярами ресурсов данных.
7.3 Ресурсы данных
При описании ресурсов данных используются сущности, представленные на рисунке 8.
Рисунок 8 - Описание ресурсов данных
Центральной сущностью является ресурс. Экземпляр ресурса представляет собой информационный объект, обладающий следующими свойствами:
а) имеет определенную идентификацию, по которой его можно адресовать в информационных ресурсах;
б) имеет один из типов, определенных в информационной модели предметной области;
в) содержит совокупность структурированных элементов данных, описанных в определении типа ресурса;
г) имеет определенную версию, которая изменяется при изменении экземпляра ресурса;
д) имеет несколько представлений (XML, JSON).
Экземпляр ресурса может включать в себя другой экземпляр ресурса по ссылке или по значению. Вложение экземпляров может иметь только один уровень. Ссылка дается на весь экземпляр, сослаться на часть его элементов нельзя.
На элементы ресурса могут быть наложены ограничения. Каждое ограничение имеет:
а) уникальный идентификатор;
б) степень строгости (является ли нарушение ограничения ошибкой или предупреждением);
в) место применения ограничения (путь в описании структуры типа ресурса);
г) человеко-читаемое описание;
д) логическое выражение на формальном языке, которое должно быть истинным при выполнении ограничения (инвариант).
Специфическим видом ограничения является привязка элемента с кодированным значением к конкретному набору значений.
Для каждого типа ресурсов (не являющегося абстрактным) задаются параметры поиска его экземпляров. Определение параметра имеет следующие элементы:
а) имя параметра;
б) тип значения параметра;
в) человеко-читаемое описание;
г) индексное выражение.
Определение типа ресурса является рамочным и рассчитано на использование в различном контексте. Для конкретной предметной области обычно требуется адаптировать его определение, в том числе:
а) описать правила использования или неиспользования элементов ресурса;
б) добавить элементы, не предусмотренные в определении типа ресурса;
в) указать или изменить терминологические ресурсы, которые могут использоваться для элементов с кодированными значениями.
Такая адаптация называется профилем. Профиль может быть основан на типе ресурса или на другом профиле.
Типы ресурсов, используемые в хранилище результатов измерений, описаны в разделе 11.
7.4 Типы данных
Все типы данных являются потомками абстрактного типа Element. Простые типы данных являются потомками абстрактного типа PrimitiveType, а комплексные - потомками абстрактного типа DataType. В свою очередь комплексные типы данных подразделяются на комплексные типы данных общего назначения, специальные комплексные типы и типы метаданных. Комплексные типы данных могут иметь компоненты простого или комплексного типа общим числом не менее двух (рисунок 9).
Рисунок 9 - Типы данных
Тип Element является базовым для всех сущностей модели данных - типов данных, типов ресурсов, вспомогательных классов. Общие сведения о типе Element приведены в таблице 1, а состав элементов - в таблице 2.
Таблица 1
Общие сведения о типе Element
Имя
Описание
Связи с другими элементами модели
Element
Базовый класс для всех элементов, типов ресурсов и типов данных
-
Таблица 2
Состав элементов типа Element
Имя
Описание
Тип
Кратность
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Может использоваться для представления дополнительной информации, не являющейся частью базового определения ресурса. Существует строгий набор правил по определению и использованию расширений, обеспечивающий их безопасное и управляемое применение. Хотя каждый разработчик и может определить расширение, существует ряд требований, которых он должен придерживаться при определении расширения
Extension
0..*
К типу Element применяется ограничение, приведенное в таблице 3. Оно означает, что значение элемента экземпляра ресурса может отсутствовать только в том случае, если у него есть одно или несколько расширений. Пустой элемент должен исключаться из экземпляра ресурса.
Таблица 3
Ограничение типа Element
id
Уровень
Путь
Описание
Выражение
ele-1
Правило
Базовый
Все элементы должны иметь атрибут @value или потомков
hasValue() or (children().count() > id.count())
Идентификатор id должен быть уникальным в пределах конкретного экземпляра ресурса, включая вложенные в него экземпляры ресурсов, со следующими исключениями:
а) в экземпляре ресурса Bundle уникальность ограничена рамками элемента Bundle.entry.resource;
б) в экземпляре ресурса Parameters уникальность ограничена рамками элемента Parameters.parameter.resource.
Некоторые элементы данных не имеют фиксированный тип данных. В этом случае в табличном представлении вместо имени типа данных указывается символ "*". Такой элемент может иметь один из следующих типов данных:
а) простые типы:
1) base64Binary;
2) boolean;
3) canonical;
4) code;
5) date;
6) dateTime;
7) decimal;
8) id;
9) instant;
10) integer;
11) integer64;
12) markdown;
13) oid;
14) positiveInt;
15) string;
16) time;
17) unsignedInt;
18) uri;
19) url;
20) uuid;
б) комплексные типы данных общего назначения:
1) Address;
2) Age;
3) Annotation;
4) Attachment;
5) CodeableConcept;
6) CodeableReference;
7) Coding;
8) ContactPoint;
9) Count;
10) Distance;
11) Duration;
12) HumanName;
13) Identifier;
14) Money;
15) Period;
16) Quantity;
17) Range;
18) Ratio;
19) RatioRange;
20) Reference;
21) SampledData;
22) Signature;
23) Timing;
в) типы метаданных:
1) ContactDetail;
2) DataRequirement;
3) Expression;
4) ParameterDefinition;
5) RelatedArtifact;
6) TriggerDefinition;
7) UsageContext;
8) Availability;
9) ExtendedContactDetail;
ИС МЕГАНОРМ: примечание.
Нумерация пунктов дана в соответствии с официальным текстом документа.
в) специальные типы данных:
1) Dosage;
2) Meta.
Имя такого элемента заканчивается символами "[x]", вместо которых в конкретном экземпляре ресурса подставляется имя типа данных, у которого первый символ переведен в верхний регистр, например, value[x] может быть заменено на valueString, и этот вариант элемента value будет иметь тип данных string.
В других случаях допускается только ограниченное подмножество типов данных из приведенного выше списка. В табличном представлении допустимые типы данных перечислены в описании, а в UML-представлении они перечислены в атрибуте стереотипа TypeChoice.
Детальное описание типов данных приведено в разделе 9.
7.5 Терминологические ресурсы
Терминологические ресурсы подразделяются на системы кодирования и наборы значений (рисунок 10). Система кодирования описывает коллекцию кодированных понятий (справочник, классификатор). Каждое понятие имеет код, значение, определение и может иметь дополнительные свойства. Набор значений представляет собой объединение подмножеств, взятых из системы кодирования и других наборов значений. Правила формирования этих подмножеств сформулированы с помощью определения. Для получения полного списка понятий, описываемого набором значений, используется операция $expand (раскрыть).
Рисунок 10 - Терминологические ресурсы
Система кодирования описана в форме экземпляра ресурса CodeSystem (пункт 15.1.2), набор значений - в форме экземпляра ресурса ValueSet (пункт 15.2.2).
7.6 REST API
Прикладной программный интерфейс (Application Program Interface) хранилища результатов измерений предоставляет методы, приведенные на рисунке 11.
Рисунок 11 - REST API
Метод Создать используется для создания нового экземпляра ресурса заданного типа. Он вызывается с помощью метода HTTP POST, например POST https://example.com/base/{типРесурса}.
Метод Заменить используется для замены всего содержания существующего экземпляра ресурса. Он вызывается с помощью метода HTTP PUT, например PUT https://example.com/base/{типРесурса}/{id}, где id - уникальный логический идентификатор экземпляра ресурса.
Метод Исправить используется для изменения части содержания существующего экземпляра ресурса. Он вызывается с помощью метода HTTP PATCH, например PATCH https://example.com/base/{типРесурса}/{id}, где id - уникальный логический идентификатор экземпляра ресурса.
Метод Получить историю используется для получения истории изменения содержания экземпляра ресурса. Он вызывается с помощью метода HTTP GET, например GET https://example.com/base/{типРесурса}/{id}/_history, где id - уникальный логический идентификатор экземпляра ресурса.
Метод Прочитать используется для получения текущего содержания экземпляра ресурса. Он вызывается с помощью метода HTTP GET, например GET https://example.com/base/{типРесурса}/{id}, где id - логический уникальный идентификатор экземпляра ресурса.
Метод Найти используется для поиска экземпляров ресурсов, удовлетворяющих заданным критериям. Он вызывается с помощью метода HTTP GET например GET https://example.com/base/{типРесурса}?параметры_поиска....
Метод Вызвать операцию используется для применения операции к содержанию экземпляра ресурса. Он вызывается с помощью метода HTTP GET например https://example.com/base/{типРесурса}/{id}/${имяОперации}.
Метод Выполнить транзакцию используется для согласованного выполнения других методов над несколькими экземплярами ресурсов в одной транзакции. Он вызывается с помощью метода HTTP POST, например POST https://example.com/base/, где тело запроса содержит спецификацию транзакции, составленную из экземпляров ресурсов и действий, выполняемых над этими экземплярами. Спецификация задается с помощью экземпляра ресурса Bundle (контейнер).
Метод Удалить используется для удаления текущего содержания существующего экземпляра ресурса. Он вызывается с помощью метода HTTP DELETE, например DELETE https://example.com/base/{типРесурса}/{id}, где id - уникальный идентификатор экземпляра ресурса.
Детальная спецификация REST API приведена в разделе 12.
8 Компоненты модели данных хранилища результатов измерений
8.1 Правила именования
При описании типов данных и ресурсов используются следующие правила именования:
а) имена типов данных, ресурсов и их элементов должны допускать использование в программном коде. Поэтому для них задан шаблон [A-Za-z0-9\-\.]{1,64}. Кроме того, эти имена не должны совпадать с ключевыми словами языков программирования или языков манипулирования данными;
б) имя типа данных или ресурса должно быть значащим для человека, читающего программный код или составляющего запрос к базе данных. Поскольку шаблон имени допускает только буквы латинского алфавита, цифры, дефисы и точки, то для составления значащих имен следует использовать слова и сочетания слов на английском языке. Так как пробельные символы в именах не разрешены, то словосочетания следует записывать слитно в одном из двух вариантов "верблюжьей" нотации: lowerCamelCase (первое слово начинается в нижнем регистре, следующие слова - в верхнем, например managingOrganization) или UpperCamelCase (каждое слово начинается в верхнем регистре, например StructureDefinition). Все символы слова, кроме первого, должны записываться в нижнем регистре. При именовании должны соблюдаться следующие требования:
1) для имени следует использовать "наиболее широко используемый" термин данной предметной области;
2) имя должно полностью отражать значение моделируемого понятия;
3) существительные должны использоваться в единственном числе, даже если элемент кратный;
4) сокращения должны использоваться в крайних случаях;
5) при использовании сокращение должно трактоваться как слово (например, targetUri для обозначения ссылки на унифицированный идентификатор ресурса URI);
6) имена должны быть краткими (полное описание понятия должно даваться в определении);
7) не следует использовать суффиксы, подчеркивающие тип данных элемента (например, typeCode или nameText);
8) если подбор соответствующего термина на английском языке вызывает затруднение, следует обратиться к толковому словарю Webster (https://www.webster-dictionary.org/), онлайновой платформе ISO (https://www.iso.org/obp/ui) и другим ресурсам сети Интернет;
в) имя простого типа данных записывается в нотации lowerCamelCase. Дефисы и точки в имени простого типа данных не допускаются;
г) имя комплексного типа данных или ресурса записывается в нотации UpperCamelCase. Дефисы и точки в имени комплексного типа данных не допускаются;
д) имя элемента комплексного типа данных или ресурса записывается в нотации lowerCamelCase. Дефисы и точки в имени элемента не допускаются.
8.2 Способы описания
Для каждого комплексного типа данных и ресурса дается описание в форме диаграммы классов на языке UML и в форме иерархической таблицы. В общем случае комплексный тип данных или ресурс представляется в виде нескольких классов, включая головной класс с именем типа данных или ресурса и вспомогательные классы, связанные с головным и между собой отношениями направленной композиции. Цель композиции именуется по правилам, принятым для элемента комплексного типа данных, указанным в подразделе 8.1. Имена вспомогательных классов уникальны только в пределах конкретного комплексного типа данных или ресурса.
При описании классов на языке UML используется пользовательский профиль, описанный в приложении А.
Независимо от числа вспомогательных классов каждый комплексный тип данных или ресурс описывается одной иерархической таблицей, формат которой описан в таблице 4.
Таблица 4
Формат иерархической таблицы
Графа
Содержание
Имя
Имя элемента комплексного типа данных или ресурса (соответствует имени элемента в XML-представлении или имени свойства в JSON-представлении). Некоторые имена имеют суффикс "[x]", означающий полиморфизм. Для вспомогательных классов указывается имя целевого конца композиции, а за ним имена элементов вспомогательного класса, имеющие в качестве префикса имя целевого конца и символ точки, например entry, entry.resource, entry.link, entry.link.relation
Описание
Описание элемента и сведения об ограничениях, наложенных на элемент
Тип
Тип данных элемента. Для элемента, представляющего целевой конец композиции, в качестве имени типа данных используется BackboneElement (в отдельных случаях - Element). Для полиморфного элемента указывается тип данных Element, а в графе Описание перечисляются допустимые типы данных
Кратность
Нижняя и верхняя граница допустимого числа повторений элемента
На элементы структуры комплексного типа данных или типа ресурса могут быть наложены ограничения. Таблица ограничений имеет формат, приведенный в таблице 5.
Таблица 5
Формат таблицы ограничений
Графа
Содержание
Идентификатор
Уникальный идентификатор ограничения
Вид
Вид ограничения
Путь
Путь к элементу ресурса, на который наложено ограничение
Описание
Описание ограничения
Выражение
Машинно-обрабатываемое представление ограничения
Для элементов структуры комплексного типа данных или типа ресурса, имеющих кодируемые значения, могут быть заданы привязки наборам значений. Таблица привязок имеет формат, приведенный в таблице 6.
Таблица 6
Формат таблицы привязок к наборам значений
Графа
Содержание
Путь
Путь к элементу ресурса с кодируемым значением
Набор значений
Идентификация набора значений в форме адреса URL
Тип привязки
Степень обязательности привязки
Описание
Описание набора значений
Таблица критериев поиска экземпляров ресурсов имеет формат, приведенный в таблице 7.
Таблица 7
Формат таблицы критериев поиска
Графа
Содержание
Имя
Имя критерия (параметра). Эквивалентно имени индекса, создаваемого для данного ресурса REST
Тип
Тип критерия (параметра)
Описание
Описание критерия
Выражение
Выражение, по которому строится критерий поиска
9 Типы данных
9.1 Общие сведения
В настоящем разделе представлены все типы данных, определенные в спецификации [22], вне зависимости от того, включены ли они в определение элементов ресурсов REST, составляющих хранилище результатов измерений. Это позволяет использовать настоящий раздел и для других предметных областей.
В нем приведены основные сведения о каждом типе данных, включая общие сведения, состав элементов (в форме диаграмм UML и в табличной форме), ограничения, наложенные на элементы, привязки к наборам значений. Дополнительные сведения, в том числе примеры, формальные описания в виде экземпляров ресурса StructureDefinition, схемы представлений в XML и JSON, приведены в спецификации [22].
Типы данных, определенные в [22], подразделяются на следующие категории:
а) простые типы данных;
б) комплексные типы данных:
1) типы данных общего назначения;
2) специальные типы данных;
3) типы метаданных.
Простые типы данных являются потомками абстрактного типа данных PrimitiveType, наследуют от него необязательный элемент уникального идентификатора id и возможность расширения.
Комплексные типы данных являются потомками абстрактного типа данных DataType (тип данных), наследуют от него необязательный элемент уникального идентификатора id и возможность расширения.
9.2 Простые типы данных
9.2.1 Общие сведения
Простые типы могут иметь элемент value (значение) и не имеют потомков (однако, как и любой другой тип данных, могут иметь расширения extension). Если расширения отсутствуют, то элемент value обязателен.
При описании простых типов элементу value сопоставляется примитивный тип данных спецификации схем XSD. Возможные значения элемента value могут быть ограничены регулярным выражением (regex), которое имеет рекомендательный характер и может уточняться на стадии реализации.
Диаграмма классов простых типов данных показана на рисунке 12. Перечень простых типов данных приведен в таблице 8.
Таблица 8
Простые типы данных
Имя
Описание
Пункт
base64Binary
Двоичное содержание
boolean
Булевский тип данных
canonical
Ссылка на ресурс по его каноническому URL
code
Перечислимые значения
date
Дата в соответствии со стандартом ГОСТ Р 7.0.64, в том числе с уменьшенной точностью
dateTime
Дата и время в соответствии со стандартом ГОСТ Р 7.0.64, в том числе с уменьшенной точностью
decimal
Десятичное значение
id
Идентификатор
instant
Штамп даты и времени с точностью до секунды или более высокой
integer
Целочисленное значение в диапазоне
-2 147 483 648..2 147 483 647 (32 бита)
integer64
Целочисленное значение в диапазоне
- 9 223 372 036 854 775 808..9 223 372 036 854 775 807 (64 бита)
markdown
Структурированный текст, размеченный в соответствии со спецификацией GitHub Flavored Markdown
oid
Объектный идентификатор в формате URI
positiveInt
Положительное целочисленное значение в диапазоне 1..2 147 483 647
string
Строковые данные в кодировке Unicode
time
Время суток
unsignedInt
Неотрицательное целочисленное значение в диапазоне 0..2 147 483 647
uri
Унифицированный идентификатор ресурса
url
Унифицированный адрес ресурса
uuid
Универсально уникальный идентификатор в формате URI
Рисунок 12 - Простые типы данных
9.2.2 Тип данных base64Binary
Тип данных base64Binary предназначен для представления двоичного содержания. Общие сведения о типе данных base64Binary приведены в таблице 9, а состав элементов - в таблице 10.
Таблица 9
Общие сведения о типе данных base64Binary
Имя
Описание
Связи с другими элементами модели
base64Binary
Поток байтов, закодированных в соответствии с [25].
Для длины потока нет заданного верхнего предела, но в конкретной реализации она может быть ограничена, что обязательно должно документироваться.
В XML: xs:base64Binary.
В JSON - string.
Regex: (?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]
{2}==|[A-Za-z0-9+/]{3}=)?
Отношение генерализации от base64Binary к PrimitiveType
Таблица 10
Состав элементов типа данных base64Binary
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Значение данного типа
xs:base64Binary
0..1
9.2.3 Тип данных boolean
Булевский тип данных (true/false). Общие сведения о типе данных boolean приведены в таблице 11, а состав элементов - в таблице 12.
Таблица 11
Общие сведения о типе данных boolean
Имя
Описание
Связи с другими элементами модели
boolean
Значение true | false.
Regex: true|false
Отношение генерализации от boolean к PrimitiveType
Таблица 12
Состав элементов типа данных boolean
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Значение данного типа
xs:boolean
0..1
9.2.4 Тип данных canonical
Тип данных canonical используется для ссылок на экземпляр ресурса по его каноническому URL (для ресурсов, имеющих компонент url). Общие сведения о типе данных canonical приведены в таблице 13, а состав элементов - в таблице 14.
Таблица 13
Общие сведения о типе данных canonical
Имя
Описание
Связи с другими элементами модели
canonical
URI, предоставляющий ссылку на ресурс по его каноническому URL (блок с элементом url типа uri).
Тип canonical отличается тем, что в данной спецификации он имеет особый смысл и может иметь компонент версии, отделенный символом вертикальной черты (|). Следует учитывать, что тип canonical используется не для фактических канонических URL, являющихся целью данных ссылок, а только для URI, которые ссылаются на них, и может иметь суффикс версии. Как и другие URI, элементы типа canonical могут иметь ссылку #фрагмент.
В XML - xs:anyURI.
В JSON - string.
Regex: \S*
Отношение генерализации от canonical к uri
Таблица 14
Состав элементов типа данных canonical
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
value
Значение данного типа
xs:anyURI
0..1
9.2.5 Тип данных code
Тип данных code предназначен для представления перечислимых значений (контролируемых строк) и является специализацией строкового типа string. Общие сведения о типе данных code приведены в таблице 15, а состав элементов - в таблице 16.
Таблица 15
Общие сведения о типе данных code
Имя
Описание
Связи с другими элементами модели
code
Указывает, что значение value берется из множества контролируемых строк, где-либо определенных.
Технически тип code ограничен строкой, в которой не меньше одного символа и отсутствуют ведущие и концевые пробельные элементы, и в содержании которой могут быть только единичные пробелы.
В XML - xs:token.
В JSON - string.
Regex: [^\s]+( [^\s]+)*
С этим типом данных может быть связан набор значений ValueSet
Отношение генерализации от code к string
Таблица 16
Состав элементов типа данных code
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
value
Значение данного типа
xs:anyURI
0..1
9.2.6 Тип данных date
Тип данных date используется для представления дат в соответствии со стандартом ГОСТ Р 7.0.64. Допускается указание даты с уменьшенной точностью (до месяца или года). Общие сведения о типе данных date приведены в таблице 17, а состав элементов - в таблице 18.
Таблица 17
Общие сведения о типе данных date
Имя
Описание
Связи с другими элементами модели
date
Дата или ее часть (например, только год или год + месяц), используемая для коммуникации с человеком.
Формат YYYY, YYYY-MM или YYYY-MM-DD, например, 2018, 1973-06 или 1905-08-23. В дате не должно быть часового пояса.
В XML: xs:gYear|xs:gYearMonth|xs:date.
В JSON: string.
Regex: ([0-9]([0-9]([0-9][1-9]|[1-9]0)|[1-9]00)|[1-9]000)(-(0[1-9]|1[0-2])(-(0[1-9]|[1-2][0-9]|3[0-1]))?)?
Отношение генерализации от date к PrimitiveType
Таблица 18
Состав элементов типа данных date
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Значение данного типа
xs:gYear|xs:gYearMonth|xs:date
0..1
9.2.7 Тип данных dateTime
Тип данных dateTime используется для представления дат и времени в соответствии со стандартом ГОСТ Р 7.0.64. Допускается указание даты и времени с уменьшенной точностью (до минуты, часа, дня, месяца или года). Общие сведения о типе данных dateTime приведены в таблице 19, а состав элементов - в таблице 20.
Таблица 19
Общие сведения о типе данных dateTime
Имя
Описание
Связи с другими элементами модели
dateTime
Дата, дата и время или часть даты (например, только год или год + месяц), используемые при коммуникации с человеком.
Формат YYYY, YYYY-MM, YYYY-MM-DD или YYYY-MM-DDThh:mm:ss+zz:zz, например, 2018, 1973-06, 1905-08-23, 2015-02-07T13:28:17-05:00 или 2017-01-01T00:00:00.000Z.
Если часы и минуты указаны, то часовой пояс должен быть указан. Секунды могут быть указаны в соответствии с этой схемой, но могут быть заполнены нулями и могут игнорироваться получателем. Даты ДОЛЖНЫ быть валидными. Время "24:00" не разрешено. Дополнительные високосные секунды разрешены.
В XML: xs:gYear|xs:gYearMonth|xs:date|xs:dateTime.
В JSON: string.
Regex: ([0-9]([0-9]([0-9][1-9]|[1-9]0)|[1-9]00)|[1-9]000)(-(0[1-9]|1[0-2])(-(0[1-9]|[1-2][0-9]|3[0-1])(T([01][0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]+)?(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00)))?)?)?
Отношение генерализации от dateTime к PrimitiveType
Таблица 20
Состав элементов типа данных dateTime
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Значение данного типа
xs:gYear|xs:gYearMonth|xs:date|xs:dateTime
0..1
9.2.8 Тип данных decimal
Тип данных decimal предназначен для представления десятичных значений. Общие сведения о типе данных decimal приведены в таблице 21, а состав элементов - в таблице 22.
Таблица 21
Общие сведения о типе данных decimal
Имя
Описание
Связи с другими элементами модели
decimal
Рациональные числа, имеющие десятичное представление.
В XML - xs:decimal|xs:double.
В JSON - number.
Regex: -?(0|[1-9][0-9]*)(\.[0-9]+)?([eE][+-]?[0-9]+)?
Отношение генерализации от decimal к PrimitiveType
Таблица 22
Состав элементов типа данных decimal
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Значение данного типа
xs:decimal|xs:double
0..1
9.2.9 Тип данных id
Тип данных id предназначен для представления идентификаторов. Общие сведения о типе данных id приведены в таблице 23, а состав элементов - в таблице 24.
Таблица 23
Общие сведения о типе данных id
Имя
Описание
Связи с другими элементами модели
id
Любое сочетание символов в кодировке ASCII в нижнем или верхнем регистре ('A'...'Z', и 'a'...'z'), цифры ('0'...'9'), знаки '-' и '.', длина которого не превышает 64 символа. (Им может быть целое число, идентификатор ОИД или UUID без префикса или любой шаблон, удовлетворяющий этим ограничениям.)
В XML - xs:string.
В JSON - string.
Regex: [A-Za-z0-9\-\.]{1,64}
Отношение генерализации от id к string
Таблица 24
Состав элементов типа данных id
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
value
Значение данного типа
xs:string
0..1
9.2.10 Тип данных instant
Тип данных instant предназначен для представления штампа даты и времени с точностью до секунды или более высокой. Общие сведения о типе данных instant приведены в таблице 25, а состав элементов - в таблице 26.
Таблица 25
Общие сведения о типе данных instant
Имя
Описание
Связи с другими элементами модели
instant
Тип instant представляет собой время в формате YYYY-MM-DDThh:mm:ss.sss+zz:zz (например, 2015-02-07T13:28:17.239+02:00 или 2017-01-01T00:00:00Z). Время должно быть указано с точностью до секунд или выше и должно указывать часовой пояс.
Примечание - Этот тип рассчитан на точное указание времени (например, для регистрационного журнала), а для вывода пользователю следует использовать типы date или dateTime (которые могут иметь ту же точность, что instant, но не обязательно).
В XML: xs:dateTime.
В JSON: string.
Regex: ([0-9]([0-9]([0-9][1-9]|[1-9]0)|[1-9]00)|[1-9]000)-(0[1-9]|1[0-2])-(0[1-9]|[1-2][0-9]|3[0-1])T([01][0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]{1,9})?(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))
Отношение генерализации от instant к PrimitiveType
Таблица 26
Состав элементов типа данных instant
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Значение данного типа
xs:dateTime
0..1
9.2.11 Тип данных integer
Тип данных integer предназначен для передачи целочисленных значений. Общие сведения о типе данных integer приведены в таблице 27, а состав элементов - в таблице 28.
Таблица 27
Общие сведения о типе данных integer
Имя
Описание
Связи с другими элементами модели
integer
Целое число со знаком в диапазоне -2 147 483 648..2 147 483 647 (32 бита; для больших значений используйте тип decimal)
В XML: xs:int (без ведущих нулей).
В JSON: number (без десятичной точки).
Regex: [0]|[-+]?[1-9][0-9]*
Отношение генерализации от integer к PrimitiveType
Таблица 28
Состав элементов типа данных integer
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Значение данного типа
xs:int
0..1
9.2.12 Тип данных integer64
Тип данных integer64 предназначен для передачи больших целочисленных значений, которые могут принимать счетчики записей или таймеры. Общие сведения о типе данных integer64 приведены в таблице 29, а состав элементов - в таблице 30.
Таблица 29
Общие сведения о типе данных integer64
Имя
Описание
Связи с другими элементами модели
integer
Целое число со знаком в диапазоне
-9 223 372 036 854 775 808..
+ 9 223 372 036 854 775 807 (64 бита).
В XML: xs:long (без ведущих нулей).
В JSON: string.
Regex: [0]|[-+]?[1-9][0-9]*
Отношение генерализации от integer64 к PrimitiveType
Таблица 30
Состав элементов типа данных integer64
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Значение данного типа
xs:long
0..1
9.2.13 Тип данных markdown
Тип данных markdown предназначен для удобочитаемого представления структурированного текста в соответствии со спецификацией GitHub Flavored Markdown (https://github.github.com/gfm/). Общие сведения о типе данных markdown приведены в таблице 31, а состав элементов - в таблице 32.
Таблица 31
Общие сведения о типе данных markdown
Имя
Описание
Связи с другими элементами модели
markdown
Строка, которая может содержать символы в синтаксисе markdown (облегченный язык разметки), представляющем расширение формата CommonMark, предложенное в GFM.
В XML: xs:string.
В JSON: string.
Regex: ^[\s\S]+$ (в regex нельзя указать ограничение длины)
Отношение генерализации от markdown к string
Таблица 32
Состав элементов типа данных markdown
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
value
Значение данного типа
xs:string
0..1
9.2.14 Тип данных oid
Тип данных oid представляет глобально уникальные объектные идентификаторы (ОИД), присваиваемые в соответствии с регламентом, описанным в стандарте ГОСТ Р ИСО/МЭК 9834-1. Структура ОИД описана в стандарте ГОСТ Р ИСО/МЭК 8824-1, хранилище верхних уровней дерева ОИД представлено по адресу https://oidref.com/, хранилище верхних уровней российской ветви 1.2.643 - по адресу https://oid.iitrust.ru. ОИД является одним из вариантов унифицированного идентификатора ресурса URI и может быть представлен в форме URI. Это представление используется в типе данных oid. Общие сведения о типе данных oid приведены в таблице 33, а состав элементов - в таблице 34.
Таблица 33
Общие сведения о типе данных oid
Имя
Описание
Связи с другими элементами модели
oid
Представление объектного идентификатора (ОИД) в форме URI [26]; например, urn:oid:1.2.3.4.5.
В XML - xs:anyURI.
В JSON - string (в формате URI).
Regex: urn:oid:[0-2](\.(0|[1-9][0-9]*))+
Отношение генерализации от oid к uri
Таблица 34
Состав элементов типа данных oid
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
value
Значение данного типа
xs:anyURI
0..1
9.2.15 Тип данных positiveInt
Тип данных positiveInt используется для представления положительных целых чисел. Общие сведения о типе данных positiveInt приведены в таблице 35, а состав элементов - в таблице 36.
Таблица 35
Общие сведения о типе данных positiveInt
Имя
Описание
Связи с другими элементами модели
positiveInt
Любое положительное целое число в диапазоне 1...2 147 483 647
В XML - xs:positiveinteger.
В JSON - number.
Regex: [1-9][0-9]*
Отношение генерализации от positiveInt к integer
Таблица 36
Состав элементов типа данных positiveInt
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Значение данного типа
xs:positiveinteger
0..1
9.2.16 Тип данных string
Тип данных string представляет собой строковые данные в кодировке Unicode, которые могут быть записаны несколькими строками (то есть могут содержать символы возврата строки и перевода каретки). Общие сведения о типе данных string приведены в таблице 37, а состав элементов - в таблице 38.
Таблица 37
Общие сведения о типе данных string
Имя
Описание
Связи с другими элементами модели
string
Последовательность символов Unicode.
Строка string ДОЛЖНА не превышать 1MB (1024*1024 символов и не содержать символы Unicode с кодом меньше 32, за исключением u0009 (горизонтальная табуляция), u0010 (возврат каретки) и u0013 (перевод строки). Ведущие и концевые пробельные символы разрешены, но ДОЛЖНЫ быть удалены, если используется формат XML.
Примечание - Это означает, что строка, состоящая только из пробельных элементов, должна быть превращена в пустую строку, но это будет трактоваться как недопустимое значение элемента. Поэтому строки ПО ВОЗМОЖНОСТИ ДОЛЖНЫ содержать не пробельные символы.
С этим типом данных может быть связан набор значений ValueSet.
В XML - xs:string.
В JSON - string.
Regex: ^[\s\S]+$
Отношение генерализации от string к PrimitiveType
Таблица 38
Состав элементов типа данных string
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Значение данного типа
xs:string
0..1
9.2.17 Тип данных time
Тип данных time используется для представления времени. Общие сведения о типе данных time приведены в таблице 39, а состав элементов - в таблице 40.
Таблица 39
Общие сведения о типе данных time
Имя
Описание
Связи с другими элементами модели
time
Время суток в формате hh:mm:ss. Дата не указывается. Секунды могут быть указаны в соответствии со схемой, но могут быть заполнены нулями и игнорироваться получателем. Время "24:00" не должно использоваться. Часовой пояс должен отсутствовать. Время может быть преобразовано в длительность Duration после полуночи.
В XML - xs:time.
В JSON - string (в формате xs:time).
Regex: ([01][0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]{1,9})?
Отношение генерализации от time к Element
Таблица 40
Состав элементов типа данных time
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Значение данного типа
xs:time
0..1
9.2.18 Тип данных unsignedInt
Тип данных unsignedInt используется для представления целых чисел без знака. Общие сведения о типе данных unsignedInt приведены в таблице 41, а состав элементов - в таблице 42.
Таблица 41
Общие сведения о типе данных unsignedInt
Имя
Описание
Связи с другими элементами модели
unsignedInt
Любое неотрицательное целое число в диапазоне 0...2 147 483 647.
В XML - xs:nonNegativeInteger.
В JSON - number.
Regex: [0]|([1-9][0-9]*)
Отношение генерализации от unsignedInt к integer
Таблица 42
Состав элементов типа данных unsignedInt
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Значение данного типа
xs:time
0..1
9.2.19 Тип данных uri
Тип данных uri используется для представления унифицированных идентификаторов ресурсов. Он имеет три основные разновидности: объектные идентификаторы oid, универсальные уникальные идентификаторы uuid и унифицированные адреса ресурсов url. Общие сведения о типе данных uri приведены в таблице 43, а состав элементов - в таблице 44.
Таблица 43
Общие сведения о типе данных uri
Имя
Описание
Связи с другими элементами модели
uri
Ссылка Uniform Resource Identifier Reference [27].
Примечание - URI чувствительны к регистру. Для UUID (urn:uuid:53fefa32-fcbb-4ff8-8a92-55ee120877b7) следует использовать нижний регистр.
В XML - xs:anyURI.
В JSON - string (в формате URI).
Regex: \S* (Это выражение разрешает очень многое, но URI должны быть валидными. Разработчики могут использовать более специфичные регулярные выражения. URI может быть абсолютным или относительным и может иметь необязательный идентификатор фрагмента. С этим типом данных может быть связан набор значений ValueSet)
Отношение генерализации от uri к Element
Таблица 44
Состав элементов типа данных uri
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
value
Значение данного типа
xs:anyURI
0..1
9.2.20 Тип данных url
Тип данных url представляет унифицированные адреса ресурсов URL. Общие сведения о типе данных url приведены в таблице 45, а состав элементов - в таблице 46.
Таблица 45
Общие сведения о типе данных url
Имя
Описание
Связи с другими элементами модели
url
Uniform Resource Locator [28]. Следует учитывать, что URL может быть непосредственно доступен при использовании указанного в нем протокола.
Наиболее распространены протоколы http{s}:, ftp:, mailto: и mllp:.
В XML - xs:anyURI.
В JSON - string (в формате URL).
Regex: \S*
Отношение генерализации от url к uri
Таблица 46
Состав элементов типа данных url
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
value
Значение данного типа
xs:anyURI
0..1
9.2.21 Тип данных uuid
Тип данных uuid представляет универсально уникальные идентификаторы UUID (GUID) в форме URI. Общие сведения о типе данных uuid приведены в таблице 47, а состав элементов - в таблице 48.
Таблица 47
Общие сведения о типе данных uuid
Имя
Описание
Связи с другими элементами модели
uuid
UUID (он же GUID), представленный как URI [29]; например, urn:uuid:c757873d-ec9a-4326-a141-556f43239520.
В XML - xs:anyURI.
В JSON - string (в формате URI).
Regex: urn:uuid:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}
Отношение генерализации от uuid к uri
Таблица 48
Состав элементов типа данных uuid
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
value
Значение данного типа
xs:anyURI
0..1
9.2.22 Ограничения простых типов данных
Простые типы данных являются потомками типа данных PrimitiveType и наследуют его ограничение, представленное в таблице 49.
Таблица 49
Ограничение типа данных PrimitiveType
id
Уровень
Путь
Описание
Выражение
ele-1
Правило
Базовый
Все элементы должны иметь атрибут @value или потомков
hasValue() or (children().count() > id.count())
Применительно к типам данных это ограничение трактуется следующим образом: если значение типа данных не указано, то должно присутствовать как минимум расширение extension, представляющее дополнительное свойство значения (например, причину его отсутствия).
9.3 Комплексные типы данных общего назначения
9.3.1 Общие сведения
Диаграммы классов комплексных типов данных общего назначения показаны на рисунках 13 и 14. Перечень комплексных типов данных общего назначения приведен в таблице 50.
Таблица 50
Комплексные типы данных общего назначения
Имя
Описание
Пункт
Address
Почтовый адрес лица или организации
Age
Возраст
Annotation
Примечания к содержанию ресурса
Attachment
Вложение в ресурс (по значению или по ссылке)
CodeableConcept
Кодированное понятие
Coding
Кодированное значение
ContactPoint
Контактная информация лица или организации
Count
Счетчик
Distance
Дистанция
Duration
Длительность
HumanName
Именование физического лица (фамилия, имя, отчество или другие имена)
Identifier
Идентификатор сущности (субъекта или объекта) в определенном пространстве имен
Money
Денежная сумма
MoneyQuantity
Представление денежной суммы в форме дроби
Period
Период времени или (неопределенный) момент времени внутри периода
Quantity
Физическая величина
Range
Диапазон значений физических величин
Ratio
Отношение между двумя физическими величинами, выраженное в форме числителя и знаменателя
RatioRange
Представление диапазона отношений двух физических величин
SampledData
Представление серии считываний, осуществляемых прибором
Signature
Подпись
SimpleQuantity
Ограничение типа данных Quantity, в котором отсутствует элемент comparator
Timing
Представление списка повторяющихся событий
Рисунок 13 - Комплексные типы данных общего назначения
(начало)
Рисунок 14 - Комплексные типы данных общего назначения
(окончание)
9.3.2 Тип данных Address
Тип данных Address описывает почтовый адрес лица или организации, но может также использоваться для указания мест, куда почта не доставляется. Общие сведения о типе данных Address приведены в таблице 51, а состав элементов - в таблице 52.
Таблица 51
Общие сведения о типе данных Address
Имя
Описание
Связи с другими элементами модели
Address
Адрес, представленный в формате почтовых соглашений (в отличие от координат GPS или других обозначений местонахождения). Этот тип данных может использоваться для почтовых адресов, а также для мест посещения, куда почта не доставляется
Отношение генерализации от Address к Element
Таблица 52
Состав элементов типа данных Address
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
use
Использование адреса - одно из значений home (домашний) | work (служебный) | temp (временный) | old (прежний) | billing (для счетов)
code
0..1
type
Тип адреса: postal (почтовый) | physical (физический) | both (почтовый и физический)
code
0..1
text
Полный текст адреса
string
0..1
line
Строка адреса. Порядок строк должен соответствовать указанному на почтовом конверте
string
0..*
city
Наименование города или населенного пункта
string
0..1
district
Район
string
0..1
State
Административный субъект страны (область, край, республика)
string
0..1
postalCode
Почтовый индекс
string
0..1
country
Страна (код в соответствии с ГОСТ 7.67)
string
0..1
period
Срок действия адреса
Period
0..1
Привязки к наборам значений описаны в таблице 53.
Таблица 53
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Address.use
http://hl7.org/fhir/ValueSet/address-use
Обязательная
Использование адреса
Address.type
http://hl7.org/fhir/ValueSet/address-type
Обязательная
Тип адреса
9.3.3 Тип данных Annotation
Тип данных Annotation используется для представления примечаний к содержанию ресурса. Общие сведения о типе данных Annotation приведены в таблице 54, а состав элементов - в таблице 55.
Таблица 54
Общие сведения о типе данных Annotation
Имя
Описание
Связи с другими элементами модели
Annotation
Текстовое примечание, содержащее сведения о том, кто и когда его сделал
Отношение генерализации от Annotation к DataType
Таблица 55
Состав элементов типа данных Annotation
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
author[x]
Лицо или организация, сделавшая примечание. Тип x может принимать значения Reference или string
DataType
0..1
author-Reference
Ссылка на лицо или организацию, сделавшую примечание. Допустимые типы ссылочных ресурсов: Practitioner | PractitionerRole | Patient | RelatedPerson | Organization
Reference
authorString
Информация о лице или организации, сделавшей примечание
string
time
Момент создания примечания
dateTime
0..1
text
Текст примечания в формате markdown
markdown
1
9.3.4 Тип данных Attachment
Тип данных Attachment используется для представления вложений в содержание экземпляров ресурсов или ссылок на эти вложения. Общие сведения о типе данных Attachment приведены в таблице 56, а состав элементов - в таблице 57.
Примечание - Для свертки данных рекомендуется использовать алгоритм ГОСТ Р 34.11.
Таблица 56
Общие сведения о типе данных Attachment
Имя
Описание
Связи с другими элементами модели
Attachment
Этот тип данных предназначен для представления вложений или для ссылок на них. Под вложениями понимается дополнительное содержание данных, определенное в других форматах. Чаще всего он используется для представления изображений или представления документов в таких форматах, как PDF. Но он может использоваться для любых данных, тип которых специфицирован в MIME
Отношение генерализации от Attachment к DataType
Таблица 57
Состав элементов типа данных Attachment
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
contentType
Тип содержания MIME, включая кодировку и т.д. Привязка к набору значений: http://hl7.org/fhir/ValueSet/mimetypes (обязательная)
code
0..1
language
Код человеческое языка содержания. Тег языка из BCP-47 [30]
code
0..1
data
Вложенные данные в формате base64
base64Binary
0..1
url
Адрес URL, откуда можно взять данные
url
0..1
size
Количество байтов в содержании (если указан url)
integer64
0..1
hash
Свертка данных (sha-1, base64ed, ГОСТ Р 34.11) в формате base64
base64Binary
0..1
title
Метка для изображения вместо данных
string
0..1
creation
Дата и время создания вложения
dateTime
0..1
height
Высота изображения в пикселах (фото/видео)
positiveInt
0..1
width
Ширина изображения в пикселах (фото/видео)
positiveInt
0..1
frames
Число кадров (фото)
positiveInt
0..1
duration
Длительность в секундах (аудио/видео)
decimal
0..1
pages
Число страниц при печати
positiveInt
0..1
Содержание, передаваемое в экземпляре ресурса Attachment, может передаваться по значению в элементе data или по ссылке в элементе url. Если указаны оба элемента, то ссылка должна указывать на те же самые данные, которое переданы в элементе data.
Элемент contentType должен быть заполнен, если данные передаются в элементе data, и может быть заполнен, если данные передаются по ссылке url.
Если элементы data и url отсутствуют, то это означает, что данные с указанным сочетанием типа содержания contentType и языка language отсутствуют.
Если данные передаются по ссылке, то в элементе hash можно задать их контрольную свертку, чтобы иметь возможность проверки целостности данных, возвращаемых по ссылке.
В ряде случаев кратность элемента ресурса, имеющего тип Attachment, может превышать 1. Правильное использование кратного элемента состоит в том, чтобы его экземпляры имели одно и то же содержание, но с разными типами содержания MIME и/или представленные на разных языках.
Ограничения типа данных Attachment описаны в таблице 58. Привязки к наборам значений описаны в таблице 59.
Таблица 58
Ограничения типа данных Attachment
Идентификатор
Вид
Путь
Описание
Выражение
att-1
Правило
Базовый
Если элемент data присутствует, то элемент contentType обязателен
data.empty() or contentType.exists()
Таблица 59
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Attachment.contentType
https://hl7.org/fhir/valueset-mimetypes.html
Обязательная
Все допустимые коды из BCP-13
(см. http://tools.ietf.org/html/bcp13)
Attachment.language
http://hl7.org/fhir/ValueSet/all-languages
Обязательная
Все допустимые коды языка из BCP-47
(см. http://tools.ietf.org/html/bcp47)
http://hl7.org/fhir/ValueSet/languages
Рекомендованная
Наиболее распространенные коды языка
9.3.5 Тип данных CodeableConcept
Тип данных CodeableConcept предназначен для представления кодированных понятий, при котором допускается указывать код, взятый из классификатора или справочника, код вместе с текстом, который детализирует значение кода (например, кода прочие), или только текст, если никакой код классификатора или справочника не может быть сопоставлен этому тексту. Общие сведения о типе данных CodeableConcept приведены в таблице 60, а состав элементов - в таблице 61.
Таблица 60
Общие сведения о типе данных CodeableConcept
Имя
Описание
Связи с другими элементами модели
CodeableConcept
Кодированное понятие (CodeableConcept) представляет значение, которое обычно принадлежит одной или нескольким терминологиям либо онтологиям, но может быть представлено только текстом text.
С этим типом данных может быть связан набор значений ValueSet
Отношение генерализации от CodeableConcept к DataType
Таблица 61
Состав элементов типа данных CodeableConcept
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
coding
Код, определенный в терминологической системе. При представлении кодированного понятия может быть указано несколько кодов (понятие может быть описано кодами из разных систем кодирования или даже несколькими кодами в одной системе кодирования)
Coding
0..*
text
Текст, послуживший источником для кодирования
string
0..1
В значении типа CodeableConcept можно передать несколько кодов из разных систем кодирования при условии, что все эти коды относятся к одному и тому же понятию. Например, в одном значении можно передать код из общероссийского классификатора и соответствующий ему код из местного справочника.
9.3.6 Тип данных Coding
Тип данных Coding предназначен для представления кодированных значений. В отличие от CodeableConcept наличие текста, детализирующего значение кода, не предусмотрено. Общие сведения о типе данных Coding приведены в таблице 62, а состав элементов - в таблице 63.
Таблица 62
Общие сведения о типе данных Coding
Имя
Описание
Связи с другими элементами модели
Coding
Представление определенного понятия, используя символ из определенной "системы кодирования".
С этим типом данных может быть связан набор значений ValueSet
Отношение генерализации от Coding к DataType
Таблица 63
Состав элементов типа данных Coding
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
system
Идентификация терминологической системы
uri
0..1
version
Идентификация версии системы - если применима
string
0..1
code
Символ в синтаксисе, определенном системой system
code
0..1
display
Представление символа, определенное в системе system
string
0..1
userSelected
Признак выбора кода пользователем
boolean
0..1
Элемент code является кодом понятия. Элемент system в сочетании с версией version (если указана) идентифицирует систему кодирования. Элемент display содержит человеко-читаемый текст, предназначенный для визуализации вместо кода.
Если с течением времени кодированные понятия остаются неизменными, то версия version не нужна. Если система кодирования описывает полную классификацию (например, Международная статистическая классификация болезней и проблем, связанных со здоровьем), то версия version обязательна, поскольку при добавлении нового понятия значение кода, присвоенного "другим и неуточненным" понятиям, изменяется.
Элемент system должен содержать URI системы кодирования, а не набора значений (например, ValueSet.url), поскольку набор значений описывает множество допустимых кодов, но не связывает их с понятиями.
Элемент code должен являться символом, синтаксис которого определен в системе кодирования, идентифицируемой значением элемента system. В некоторых системах кодирования (например, посткоординируемых) коды могут представлять собой выражения, составленные из других заранее определенных кодов. Примером служат системы единиц измерения.
Если элемент display присутствует, то он должен содержать краткий человеко-читаемый текст, идентифицирующий понятие данной системы кодирования. С одним кодом может быть связано несколько текстов:
- основной, указанный в элементе CodeSystem.concept.display;
- дополнительные, указанные в элементах CodeSystem.concept.designation.value (например, переводы основного текста на другие языки).
Ограничения типа данных Coding описаны в таблице 64.
Таблица 64
Ограничения типа данных Coding
Идентификатор
Вид
Путь
Описание
Выражение
cod-1
Предупреждение
Базовый
Если элемент code присутствует, то элемент display должен отсутствовать
code.exists().not() implies display.exists().not()
9.3.7 Тип данных ContactPoint
Тип данных ContactPoint предназначен для представления контактной информации лица или организации. Общие сведения о типе данных ContactPoint приведены в таблице 65, а состав элементов - в таблице 66.
Таблица 65
Общие сведения о типе данных ContactPoint
Имя
Описание
Связи с другими элементами модели
ContactPoint
Детали всех видов технологий контактов с лицом или организацией, включая телефон, электронную почту и т.д.
Отношение генерализации от ContactPoint к DataType
Таблица 66
Состав элементов типа данных ContactPoint
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
system
Тип контакта. Допустимые значения: phone (телефон) | fax (факс) | email (электронная почта) | url (URL) | sms (СМС) | other (другой)
Coding
0..1
value
Номер или иной телекоммуникационный адрес
string
0..1
use
Код использования. Допустимые значения: home (домашний) | work (служебный) | temp (временный) | old (прежний) | mobile (мобильный)
Coding
0..1
rank
Приоритет контакта - (1 - наивысший)
positiveInt
0..1
period
Срок действия контактной информации
Period
0..1
Ограничения типа данных ContactPoint описаны в таблице 67. Привязки к наборам значений описаны в таблице 68.
Таблица 67
Ограничения типа данных ContactPoint
Идентификатор
Вид
Путь
Описание
Выражение
cpt-2
Правило
Базовый
Если элемент value присутствует, то элемент system обязателен
value.empty() or system.exists()
Таблица 68
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
ContactPoint.system
https://hl7.org/fhir/valueset-contact-point-system.html
Обязательная
Тип контакта
ContactPoint.use
http://hl7.org/fhir/ValueSet/contact-point-use
Обязательная
Код использования
9.3.8 Тип данных HumanName
Тип данных HumanName предназначен для описания именования физического лица (фамилия, имя, отчество или другие имена). Общие сведения о типе данных HumanName приведены в таблице 69, а состав элементов - в таблице 70.
Именование лица может иметь ограниченный срок действия, задаваемый в элементе period.
Таблица 69
Общие сведения о типе данных HumanName
Имя
Описание
Связи с другими элементами модели
HumanName
Именование физического лица, включая полный текст, отдельные части и информацию о применении.
Именования лиц могут изменяться. Лица могут использовать разные именования в разных ситуациях. Именования могут делиться на отдельные части, имеющие разную значимость в разном контексте
Отношение генерализации от HumanName к DataType
Таблица 70
Состав элементов типа данных HumanName
Имя
Описание
Тип
Кратность
Унаследованные элементы
Id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
use
Использование именования лица. Допустимые значения: usual (обычное) | official официальное) | temp (временное) | nickname (псевдоним) | anonymous (деперсонифицированное) | old (прежнее) | maiden (девичье)
code
0..1
text
Полное именование лица
string
0..1
family
Фамилия физического лица
string
0..1
given
Имя физического лица
string
0..*
middle
Отчества либо второе и следующие имена физического лица, разделяемые пробелом
string
0..1
period
Срок действия именования физического лица
Period
0..1
В элементе given передаются все имена лица в том порядке, как это указано в свидетельстве о рождении или паспорте. Для российских граждан первый экземпляр элемента given должен содержать имя, второй - отчество (при наличии).
Элемент text (полное именование) предусмотрен на тот случай, если выделить имя, фамилию и другие структурированные компоненты не представляется возможным. Если заполнены и элемент text, и другие компоненты именования, то элемент text не должен содержать иные компоненты.
Привязки к наборам значений описаны в таблице 71.
Таблица 71
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
HumanName.use
http://hl7.org/fhir/ValueSet/name-use
Обязательная
Использование именования лица
9.3.9 Тип данных Identifier
Тип данных Identifier представляет идентификатор сущности (субъекта или объекта) в пространстве имен, идентифицированном элементом system. Общие сведения о типе данных Identifier приведены в таблице 72, а состав элементов - в таблице 73.
Таблица 72
Общие сведения о типе данных Identifier
Имя
Описание
Связи с другими элементами модели
Identifier
Цифровая или буквенно-цифровая строка, ассоциируемая с одним объектом или сущностью в данной системе идентификации
Отношение генерализации от Identifier к DataType
Таблица 73
Состав элементов типа данных Identifier
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
use
Тип использования идентификатора. Допустимые значения: usual (обычный) | official (официальный) | temp (временный) | secondary (вторичный) | old (прежний)
code
0..1
type
Тип идентификатора, описывающий его назначение
CodeableConcept
0..1
system
Пространство имен для значений идентификатора. Оно представляет собой URI, например, https://id.edu.gov.ru/Organization/ogrn или urn:ietf:rfc:3986, если значение value идентификатора само по себе является глобально уникальным (ОИД или UUID)
uri
0..1
value
Значение идентификатора (уникальное в пространстве имен)
string
0..1
period
Срок действия идентификатора
Period
0..1
assigner
Ссылка на организацию, присвоившую идентификатор
Reference
0..1
Срок действия идентификатора задается элементом period. Компонент period.start указывает дату присвоения (выдачи) идентификатора, компонент period.end - дату прекращения его действия (например, дату выдачи и срок действия загранпаспорта). Элемент assigner содержит идентификатор организации, присвоившей идентификатор. Поскольку он имеет тип Reference, то в компоненте assigner.display можно передать наименование организации.
Элемент system содержит абсолютный URI, определяющий схему идентификации (структура идентификатора, правила присваивания и т.д.). Для глобально уникальных идентификаторов ОИД и УУИД (например, Global Unique Identifier) схема идентификации должна иметь значение urn:ietf:rfc:3986. Если system содержит URL, то он, по возможности, должен быть разрешимым. Значение элемента system чувствительно к регистру.
Значение элемента value должно быть уникальным в пространстве имен, определяемом схемой идентификации system. Оно должно быть чувствительным к регистру за исключением тех случаев, когда схема идентификации предусматривает иное. В некоторых случаях значение value известно, а элемент system отсутствует (например, элемент value содержит значение штрих-кода, считанного с упаковки лекарства). В таких случаях уникальность значения value должна обеспечиваться исходя из контекста применения идентификаторов. В качестве паллиатива вместо system можно использовать элемент type (тип идентификатора).
Ограничения типа данных Identifier описаны в таблице 74. Привязки к наборам значений описаны в таблице 75.
Таблица 74
Ограничения типа данных Identifier
Идентификатор
Вид
Путь
Описание
Выражение
ident-1
Предупреждение
Базовый
Идентификаторы без компонента value имеют ограниченное применение. Если идентификатор не известен, то можно передать элемент value, у которого нет атрибута value, но есть расширение extension, указывающее причину отсутствия идентификатора
value.empty() or system.exists()
Таблица 75
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Identifier.use
http://hl7.org/fhir/ValueSet/identifier-use
Обязательная
Тип использования идентификатора
Identifier.type
http://hl7.org/fhir/ValueSet/identifier-type
Расширяемая
Тип идентификатора, описывающий его назначение
9.3.10 Тип данных Money
Тип данных Money предназначен для представления денежной суммы. Общие сведения о типе данных Money приведены в таблице 76, а состав элементов - в таблице 77.
Таблица 76
Общие сведения о типе данных Money
Имя
Описание
Связи с другими элементами модели
Money
Денежная сумма
Отношение генерализации от Money к DataType
Таблица 77
Состав элементов типа данных Money
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Величина суммы
decimal
0..1
currency
Код денежной единицы
Coding
0..1
Привязки к наборам значений описаны в таблице 78.
Таблица 78
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Money.currency
http://hl7.org/fhir/ValueSet/currencies
Обязательная
Код денежной единицы в соответствии с ОКВ ОК (МК (ИСО 4217) 003-97) 014
ИС МЕГАНОРМ: примечание.
В официальном тексте документа, видимо, допущена опечатка: имеется в виду таблица 94, а не 93.
Иногда денежная сумма должна представляться как дробь, числителем которой является денежная единица. В этом случае денежная сумма имеет тип данных Quantity с профилем MoneyQuantity, описанным в таблице 93.
9.3.11 Тип данных Period
Тип данных Period предназначен для представления периода времени или (неопределенного) момента времени внутри периода. Общие сведения о типе данных Period приведены в таблице 79, а состав элементов - в таблице 80.
Таблица 79
Общие сведения о типе данных Period
Имя
Описание
Связи с другими элементами модели
Period
Период времени, определенный датой/временем начала и конца. Период задает диапазон времени. По контексту использования определяется, имеется ли в виду весь диапазон или какой-то один момент времени внутри этого диапазона
Отношение генерализации от Period к DataType
Таблица 80
Состав элементов типа данных Period
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
start
Дата и время начала периода (включительно)
dateTime
0..1
end
Дата и время конца периода (включительно)
dateTime
0..1
Если элемент start отсутствует, то начало периода не известно. Отсутствие элемента end означает текущий период. В элементе end может быть указана фактическая или планируемая дата завершения периода (включительно).
Ограничения типа данных Period описаны в таблице 81.
Таблица 81
Ограничения типа данных Period
Идентификатор
Вид
Путь
Описание
Выражение
per-1
Правило
Базовый
Если элементы start и end присутствуют, то значение элемента start должно быть меньше значения элемента end или равно ему
start.hasValue().not() or end.hasValue().not() or (start.low-Boundary() <=end.highBoundary())
9.3.12 Тип данных Quantity
Тип данных Quantity предназначен для представления значения физической величины. Может быть указано точное значение или его нижняя либо верхняя оценка (используя свойство comparator). Общие сведения о типе данных Quantity приведены в таблице 82, а состав элементов - в таблице 83.
Таблица 82
Общие сведения о типе данных Quantity
Имя
Описание
Связи с другими элементами модели
Quantity
Измеримая величина (или потенциально измеримая величина).
С этим типом данных может быть связан набор значений ValueSet
Отношение генерализации от Quantity к DataType
Таблица 83
Состав элементов типа данных Quantity
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
value
Измеренная или измеримая величина
decimal
0..1
comparator
Оператор сравнения < | <= | >= | >
code
0..1
unit
Наименование единицы измерения
string
0..1
system
Система кодирования единиц измерения
uri
0..1
code
Код единицы измерения
code
0..1
Ограничения типа данных Quantity описаны в таблице 84. Привязки к наборам значений описаны в таблице 85.
Таблица 84
Ограничения типа данных Quantity
Идентификатор
Вид
Путь
Описание
Выражение
qty-3
Правило
Базовый
Если элемент code присутствует, то элемент system также ДОЛЖЕН присутствовать
code.empty() or system.exists()
Таблица 85
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Quantity.comparator
http://hl7.org/fhir/ValueSet/quantity-comparator
Обязателен
Интерпретация значения value
9.3.13 Специализации и профили типа данных Quantity
9.3.13.1 Специализация Distance (расстояние)
Специализация Distance ограничивает тип данных Quantity величинами расстояния.
Специализация Distance описана в таблице 86. Привязки к наборам значений описаны в таблице 87.
Таблица 86
Специализация Distance
Имя типа данных
Правила
Идентификатор
Вид
Путь
Описание
Выражение
Distance
dis-1
Правило
Базовый
Если элемент value присутствует, то ДОЛЖЕН быть указан элемент code, представляющий единицу длины. Если элемент system присутствует, то он должен иметь значение http://unitsofmeasure.org
(code.exists() or value.empty()) and (system.empty() or system = %ucum)
Таблица 87
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Distance.code
http://hl7.org/fhir/ValueSet/all-distance-units
Расширяемая
Все общие коды расстояния UCUM, являющиеся производными от метра
9.3.13.2 Специализация Age (возраст)
Специализация Age ограничивает тип данных Quantity величинами времени.
Специализация Age описана в таблице 88. Привязки к наборам значений описаны в таблице 89.
Таблица 88
Специализация Age
Имя типа данных
Правила
Идентификатор
Вид
Путь
Описание
Выражение
Age
age-1
Правило
Базовый
Если элемент value присутствует, то должен быть указан элемент code, представляющий единицу времени. Если элемент system присутствует, то он должен иметь значение http://unitsofmeasure.org. Если элемент value присутствует, то должен быть положительным
(code.exists() or value.empty()) and (system.empty() or system = %ucum) and (value.empty() or value.hasValue().not() or value > 0)
Таблица 89
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Age.code
http://hl7.org/fhir/ ValueSet/age-units
Расширяемая
Все общие коды времени UCUM, являющиеся производными от года
9.3.13.3 Специализация Count (счетчик)
Специализация Count ограничивает тип данных Quantity безразмерными величинами с целочисленным значением.
Специализация Count описана в таблице 90.
Таблица 90
Специализация Count
Имя типа данных
Правила
Идентификатор
Вид
Путь
Описание
Выражение
Count
cnt-3
Правило
Базовый
Если элемент value присутствует, то должен быть указан элемент code со значением '1'. Если элемент system присутствует, то он должен иметь значение http://unitsofmeasure.org. Если элемент value присутствует, то его строковое представление не должно содержать десятичную точку
(code.exists() or value.empty()) and (system.empty() or system = %ucum) and (code.empty() or code = '1') and (value.empty() or value.hasValue().not() or value.toString().contains('.').not())
9.3.13.4 Специализация Duration (длительность)
Специализация Duration ограничивает тип данных Quantity величинами времени.
Специализация Duration описана в таблице 91. Привязки к наборам значений описаны в таблице 92.
Таблица 91
Специализация Duration
Имя типа данных
Правила
Идентификатор
Вид
Путь
Описание
Выражение
Duration
drt-1
Правило
Базовый
Если элемент value присутствует, то должен быть указан элемент code, представляющий единицу времени. Если элемент system присутствует, то он должен иметь значение http://unitsofmeasure.org
code.exists() implies ((system = %ucum) and value.exists())
Таблица 92
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Duration.code
http://hl7.org/fhir/ValueSet/duration-units
Расширяемая
Все общие коды времени UCUM, являющиеся производными от года
9.3.13.5 Профиль SimpleQuantity
В дополнение к специализациям типа данных Quantity определен профиль SimpleQuantity, описанный в таблице 93.
Таблица 93
Профиль SimpleQuantity
Имя профиля
Правила
Идентификатор
Вид
Путь
Описание
Выражение
SimpleQuantity
sqty-1
Правило
Базовый
Элемент comparator (оператор сравнения) не используется
comparator.empty()
Это не отдельный тип данных, а ограничение типа данных Quantity.
9.3.13.6 Профиль MoneyQuantity
В дополнение к специализациям типа данных Quantity определен профиль MoneyQuantity, описанный в таблице 94.
Таблица 94
Профиль MoneyQuantity
Имя профиля
Правила
Идентификатор
Вид
Путь
Описание
Выражение
MoneyQuantity
mtqy-1
Правило
Базовый
Если элемент value присутствует, то должен быть указан элемент code, который ДОЛЖЕН представлять денежную единицу. Если элемент system присутствует, то он должен иметь значение urn:iso:std:iso:4217
(code.exists() or value.empty()) and (system.empty() or system = 'urn:iso:std:iso:4217'
Это не отдельный тип данных, а ограничение типа данных Quantity, используемое при представлении денежных сумм в форме дроби.
9.3.14 Тип данных Range
Тип данных Range предназначен для указания диапазона значений физических величин. Общие сведения о типе данных Range приведены в таблице 95, а состав элементов - в таблице 96.
Таблица 95
Общие сведения о типе данных Range
Имя
Описание
Связи с другими элементами модели
Range
Множество упорядоченных величин, определенное нижним и верхним пределами. Обычно используется одно значение из этого диапазона. Диапазоны чаще всего указывают в инструкциях.
Единицы измерения unit и code/system элементов low и high должны совпадать. Если low или high отсутствуют, это означает, что нижний или верхний предел не определен. Флаг сравнения comparator в элементах low или high не должен присутствовать. Тип Range не следует использовать для указания значения за пределами диапазона. В этом случае следует использовать тип величины Quantity с элементом comparator.
Величины low и high включаются в диапазон и могут иметь произвольно высокую точность, например, диапазон от 1,5 до 2,5 включает в себя 1,50 и 2,50, но не 1,49 или 2,51
Отношение генерализации от Range к DataType
Таблица 96
Состав элементов типа данных Range
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
low
Нижняя граница диапазона
SimpleQuantity
0..1
high
Верхняя граница диапазона
SimpleQuantity
0..1
Ограничения типа данных Range описаны в таблице 97.
Таблица 97
Ограничения типа данных Range
Идентификатор
Вид
Путь
Описание
Выражение
rng-2
Правило
Базовый
Если элементы low и high присутствуют, то значение элемента low должно быть меньше значения элемента high или равно ему
low.value.empty() or high.value.empty() or low.lowBoundary().comparable(high.highBoundary()).not() or (low.lowBoundary() <= high.highBoundary())
9.3.15 Тип данных Ratio
Тип данных Ratio предназначен для представления отношения двух физических величин в форме дроби. Тип данных может использоваться для представления обычной дроби, например, "2/3". Общие сведения о типе данных Ratio приведены в таблице 98, а состав элементов - в таблице 99.
Таблица 98
Общие сведения о типе данных Ratio
Имя
Описание
Связи с другими элементами модели
Ratio
Отношение между двумя величинами, выраженное числителем numerator и знаменателем denominator.
Тип данных Ratio следует использовать только для представления отношения двух чисел, если оно не может быть подходящим образом выражено с помощью типа данных Quantity и общей единицы измерения. Если знаменатель denominator имеет значение "1", то вместо Ratio следует использовать Quantity
Отношение генерализации от Ratio к DataType
Таблица 99
Состав элементов типа данных Ratio
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
numerator
Числитель отношения
Quantity
0..1
denominator
Знаменатель отношения
SimpleQuantity
0..1
Ограничения типа данных Ratio описаны в таблице 100.
Таблица 100
Ограничения типа данных Ratio
Идентификатор
Вид
Путь
Описание
Выражение
rat-1
Правило
Базовый
Элементы numerator and denominator должны одновременно присутствовать или отсутствовать. Если они отсутствуют, должно присутствовать хотя бы одно расширение extension
(numerator.exists() and denominator.exists()) or (numerator.empty() and denominator.empty() and extension.exists())
9.3.16 Тип данных RatioRange
Тип данных RatioRange предназначен для представления диапазонов отношений двух физических величин, представленных в форме дроби. Общие сведения о типе данных RatioRange приведены в таблице 101, а состав элементов - в таблице 102.
Таблица 101
Общие сведения о типе данных RatioRange
Имя
Описание
Связи с другими элементами модели
RatioRange
Диапазон отношений между двумя величинами, выраженный диапазоном числителя lowNumerator.. лшлшhighNumerator и знаменателем denominator.
Если знаменатель denominator имеет значение '1', то вместо RatioRange следует использовать Range
Отношение генерализации от RatioRange к DataType
Таблица 102
Состав элементов типа данных RatioRange
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
lowNumerator
Нижний предел числителя
SimpleQuantity
0..1
highNumerator
Верхний предел числителя
SimpleQuantity
0..1
denominator
Знаменатель отношения
SimpleQuantity
0..1
Ограничения типа данных RatioRange описаны в таблице 103.
Таблица 103
Ограничения типа данных RatioRange
Идентификатор
Вид
Путь
Описание
Выражение
ratrng-1
Правило
Базовый
Элементы numerator and denominator должны одновременно присутствовать или отсутствовать. Если они отсутствуют, должно присутствовать хотя бы одно расширение extension
((lowNumerator.exists() or highNumerator.exists()) and denominator.exists()) or (lowNumerator.empty() and highNumerator.empty() and denominator.empty() and extension.exists())
ratrng-2
Правило
Базовый
Если оба элемента lowNumerator и highNumerator присутствуют, то значение элемента lowNumerator должно быть меньше значения элемента highNumerator или равно ему
lowNumerator.hasValue().not() or highNumerator.hasValue().not() or (lowNumerator.lowBoundary() <= highNumerator.highBoundary()
9.3.17 Тип данных SampledData
Тип данных SampledData предназначен для представления серии считываний, осуществляемых приборами, например, кардиографами. Каждое считывание представляет собой десятичное значение или код. Результат измерения определяется по следующей формуле, содержащей значение i-го считывания data с поправками на смещение базового значения origin.value и масштабный коэффициент factor:
измеряемое значение[i] = SampledData.data[i] * SampledData.factor + SampledData.origin.value
Общие сведения о типе данных SampledData приведены в таблице 104, состав элементов - в таблице 105.
Таблица 104
Общие сведения о типе данных SampledData
Имя
Описание
Связи с другими элементами модели
SampledData
Серия считываний, осуществленная прибором, с указанием верхней и нижней границы диапазона значений. Может быть многомерной
Отношение генерализации от SampledData к DataType
Таблица 105
Состав элементов типа данных SampledData
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
origin
Смещение нулевого значения и его единицы
SimpleQuantity
1
interval
Число intervalUnits между считываниями
decimal
0..1
intervalUnit
Единицы измерения интервала между считываниями
code
1
factor
Масштабирующий коэффициент, применяемый к считыванию до добавления базового смещения
decimal
0..1
lowerLimit
Нижний предел значения считывания
decimal
0..1
upperLimit
Верхний предел значения считывания
decimal
0..1
dimensions
Число считываний в каждый момент времени. Если оно больше единицы, то размерности будут чередоваться - все считывания в данный момент времени будут записаны сразу
positiveInt
1
codeMap
Ссылка на экземпляр ресурса CodeMap, описывающего коды, которые могут передаваться вместо числового значения считывания. Эти коды должны быть дополнительными к 'E', 'U', 'L' (или 'e', 'u', 'l').
canonical
0..1
offsets
Последовательность десятичных значений смещений во времени, разделенных пробелами (символ u20). Единицы, в которых выражаются эти значения, берутся из intervalUnit. Абсолютное время начала измерений задается за рамками данного типа данных, например, в элементе Observation.effectiveDateTime. Если этот элемент присутствует, то число считываний должно быть равно числу смещений, указанному в элементе offsets, умноженному на размерность dimensions
string
0..1
data
Последовательность считываний, разделенных пробелами (символ u20). Считывания могут быть десятичными значениями или кодами "E" (ошибка), "L" (меньше нижнего предела измерений) или "U" (больше верхнего предела измерений)
string
1
В дополнение к кодам 'E', 'U', 'L' могут использоваться другие коды, описанные в ссылочном экземпляре ресурса CodeMap, в котором должна быть только одна группа, не содержащая ни числовые значения, ни коды 'E', 'U', 'L' (и для безопасности 'e', 'u', 'l'). Дополнительные коды не должны содержать пробелы и escape-последовательности и не должны начинаться с цифр.
Привязки к наборам значений описаны в таблице 106.
Таблица 106
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
SampledData.interval-Unit
http://unitsofmeasure.org
Расширяемая
Единицы измерения интервала между считываниями
9.3.18 Тип данных Timing
Тип данных Timing предназначен для представления списка повторяющихся событий. Правила повторения могут задаваться простыми кодом, указанным в поле code, или конструкцией типа Repeat, указанной в поле repeat. Общие сведения о типе данных Timing приведены в таблице 107, а состав элементов - в таблице 108.
Таблица 107
Общие сведения о типе данных Timing
Имя
Описание
Связи с другими элементами модели
Timing
Расписание описывает наступление события, которое может совершаться несколько раз. Расписания используются, чтобы указать, когда события ожидаются или требуются, и могут также использоваться для представления сводки предшествующих или текущих событий. Определение компонентов типа данных Timing дается для "будущих" событий, но они могут использоваться и для описания истории или текущих событий.
Расписание Timing может быть списком событий и/или критериями наступления событий, которые могут быть представлены в структурированной форме и/или в форме кода. Если предусмотрены и событие, и спецификация повторения, то список событий следует понимать, как интерпретацию информации повторяющейся структуры.
Примечание - Тип данных Timing допускает модифицирующие расширения modifierExtension
Отношение генерализации от Timing к BackboneElement
Таблица 108
Состав элементов типа данных Timing
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
modifierExtension
Модифицирующее расширение, которое нельзя игнорировать, даже если оно не распознано
Extension
0..*
Собственные элементы
event
Моменты наступления события
dateTime
0..*
repeat
Правила повторения события
Element
0..1
repeat.bound[x]
Продолжительность расписания, где [x] может принимать значения Duration|Range|Period
0..1
repeat.boundsDuration
Продолжительность
Duration
repeat.boundsRange
Интервал дат и времени
Range
repeat.boundsPeriod
Период времени
Period
repeat.count
Число повторений
positiveInt
0..1
repeat.countMax
Максимальное число повторений
positiveInt
0..1
repeat.duration
Длительность события
decimal
0..1
repeat.durationMax
Максимальная длительность события
decimal
0..1
repeat.durationUnit
Единица длительности события: s (секунда) | min (минута) | h (час) | d (сутки) | wk (неделя) | mo (месяц) | a (год)
code
0..1
repeat.frequency
Частота повторения события в заданном периоде, то есть событие повторяется frequency раз в заданном периоде
positiveInt
0..1
repeat.frequencyMax
Максимальная частота повторения в заданном периоде
positiveInt
0..1
repeat.period
Период, в течение которого событие повторяется frequency раз
decimal
0..1
repeat.periodMax
Максимальный период, в течение которого событие повторяется frequency раз
decimal
0..1
repeat.periodUnit
Единица длительности периода: s (секунда) | min (минута) | h (час) | d (сутки) | wk (неделя) | mo (месяц) | a (год)
code
0..1
repeat.dayOfWeek
День недели - одно из значений mon | tue | wed | thu | fri | sat | sun
code
0..*
repeat.timeOfDay
Время наступления события в течение дня
time
0..*
repeat.when
Код периода времени повторения события
code
0..*
repeat.offset
Минуты от заданного периода времени повторения события (до или после)
unsigned-Int
0..1
code
Правило повторения в кодированной форме (например, BID | TID | QID | AM | PM | QD | QOD | +)
CodeableConcept
0..1
Ограничения типа данных Timing описаны в таблице 109. Привязки к наборам значений описаны в таблице 110.
Таблица 109
Ограничения типа данных Timing
Идентификатор
Вид
Путь
Описание
Выражение
tim-1
Правило
Timing.repeat
Если элемент duration присутствует, то элемент durationUnit также должен присутствовать
duration.empty() or durationUnit.exists()
tim-2
Правило
Timing.repeat
Если элемент period присутствует, то элемент periodUnit также должен присутствовать
period.empty() or periodUnit.exists()
tim-4
Правило
Timing.repeat
Если элемент duration присутствует, то он должен иметь неотрицательное значение
duration.exists() implies duration >= 0
tim-5
Правило
Timing.repeat
Если элемент period присутствует, то он должен иметь неотрицательное значение
period.exists() implies period >= 0
tim-6
Правило
Timing.repeat
Если элемент periodMax присутствует, то элемент period также должен присутствовать
periodMax.empty() or period.exists()
tim-7
Правило
Timing.repeat
Если элемент durationMax присутствует, то также должен присутствовать элемент duration
durationMax.empty() or duration.exists()
tim-8
Правило
Timing.repeat
Если элемент countMax присутствует, то элемент count также должен присутствовать
countMax.empty() or count.exists()
tim-9
Правило
Timing.repeat
Если элемент offset присутствует, то элемент when также должен присутствовать и не принимать значения C (постоянно) | CM | CD | CV
offset.empty() or (when.exists() and when.select($this in ('C' | 'CM' | 'CD' | 'CV')).allFalse())
tim-10
Правило
Timing.repeat
Элементы timeOfDay и when взаимно исключаемые
timeOfDay.empty() or when.empty()
Таблица 110
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Timing.repeat. durationUnit
http://hl7.org/fhir/ValueSet/units-of-time
Обязателен
Единицы времени
Timing.repeat.day-OfWeek
http://hl7.org/fhir/ValueSet/days-of-week
Обязателен
Дни недели
Timing.repeat.when
http://hl7.org/fhir/ValueSet/event-timing
Обязателен
Реальные события, к которым привязано расписание
Timing.code
http://hl7.org/fhir/ValueSet/timing-abbreviation
Предпочтителен
Аббревиатуры частоты событий
9.3.19 Тип данных Signature
9.3.19.1 Общие сведения и состав элементов
Тип данных Signature предназначен для представления подписи, в том числе образца собственноручной подписи, в виде графического файла или сертификата усиленной квалифицированной электронной подписи. Общие сведения о типе данных Signature приведены в таблице 111, а состав элементов - в таблице 112.
Таблица 111
Общие сведения о типе данных Signature
Имя
Описание
Связи с другими элементами модели
Signature
Электронное представление подписи и ее контекста. Подпись может быть криптографической (XML DigSig или JWS), с помощью которой можно обеспечить неоспоримость, или быть графическим образом, представляющим подпись или процесс подписания
Отношение генерализации от Signature к DataType
Таблица 112
Состав элементов типа данных Signature
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
type
Код причины подписи. Он может быть явно включен как часть подписи и использоваться для учетности различных действий с документом
Coding
0..*
when
Момент создания подписи
instant
0..1
who
Ссылка на лицо, организацию или прибор, поставивший подпись. Допустимые типы ссылочных ресурсов: Practitioner | PractitionerRole | RelatedPerson | Patient | Device | Organization
Reference
0..1
onBehalfOf
Ссылка на лицо, организацию или прибор, от чьего имени поставлена подпись. Допустимые типы ссылочных ресурсов: Practitioner | PractitionerRole | RelatedPerson | Patient | Device | Organization
Reference
0..1
targetFormat
Технический формат подписанного содержания ресурса (mime)
code
0..1
sigFormat
Технический формат подписи (mime). Важными типами mime являются application/signature+xml для XMLdSig, application/jose для JWS и image/* для графического образа подписи
code
0..1
data
Содержание подписи (XML DigSig, JWS, графический образ и т.д.).
base64Binary
0..1
9.3.19.2 Электронная подпись XML
Если для электронной подписи используется спецификация XML Digital Signature (contentType = application/signature+xml), то применяются следующие требования:
а) элемент Signature.data содержит представление подписи в формате base64;
б) электронная подпись является отсоединенной;
в) для целей длительного хранения электронная подпись должна соответствовать спецификации XAdES-X-L, добавляющей штамп даты и времени, цепочку сертификатов и результаты проверки отзыва сертификатов.
Подпись экземпляра ресурса применяется к канонической форме XML-представления его содержания.
9.3.19.3 Электронная подпись JSON
Если для электронной подписи используется спецификация JSON Digital Signature (contentType = application/jose), то применяются следующие требования:
а) элемент Signature.data содержит представление подписи JWS-Signature [31] в формате base64;
б) электронная подпись является отсоединенной;
в) для целей длительного хранения электронная подпись должна соответствовать спецификации JAdES-XL, добавляющей штамп даты и времени, цепочку сертификатов и результаты проверки отзыва сертификатов.
Подпись экземпляра ресурса применяется к канонической форме JSON-представления его содержания.
9.3.19.4 Каноническое представление содержания экземпляра ресурса в формате XML
Каноническое представление содержания экземпляра ресурса в формате XML должно удовлетворять следующим требованиям:
а) в значениях атрибутов и в XHTML представлении элемента не должно быть иных пробельных символов кроме пробела. При этом пробелы не должны быть кратными;
б) для пространств имен FHIR и XHTML должны использоваться пространства имен по умолчанию;
в) все комментарии должны быть опущены;
г) в escape-последовательностях должны использоваться исходные символы Unicode (например, &#39; вместо &quot;);
д) должна использоваться инструкция <?xml version="1.0" encoding="UTF-8"?>;
е) должен быть применен метод каноникализации Canonical XML 1.1 (http://www.w3.org/TR/xml-c14n11).
Данный метод канонического представления идентифицируется, используя URI http://hl7.org/fhir/canonicalization/xml. В дополнение к нему определены методы канонического представления, приведенные в таблице 113.
Таблица 113
Дополнительные методы канонического представления
содержания экземпляра ресурса в формате XML
URI
Дополнительная обработка содержания
http://hl7.org/fhir/canonicalization/xml#data
Перед подписью должно быть удалено текстовое представление содержания ресурса (элемент text)
http://hl7.org/fhir/canonicalization/xml#static
Кроме текстового представления содержания ресурса (элемент text) удаляются метаданные (элемент meta). Это позволяет сохранять целостность подписи при передаче содержания на другой сервер или при выполнении рабочих процессов, изменяющих значения тегов в метаданных
http://hl7.org/fhir/canonicalization/xml#narrative
В содержании оставляются только элементы id и text (то есть подписывается только человеко-читаемое содержание)
http://hl7.org/fhir/canonicalization/xml#document
В контейнере Bundle типа document подписывается все внутреннее содержание, кроме Bundle.id и Bundle.metadata (чтобы сохранять целостность подписи при передаче документа на другой сервер)
9.3.19.5 Каноническое представление содержания экземпляра ресурса в формате JSON
Каноническое представление содержания экземпляра ресурса в формате JSON должно удовлетворять следующим требованиям:
а) в значениях свойств объектов и в XHTML представлении объекта Narrative не должно быть иных пробельных символов кроме пробела. При этом пробелы не должны быть кратными;
б) внутри каждого объекта свойства сортируются по алфавиту.
Данный метод канонического представления идентифицируется, используя URI http://hl7.org/fhir/canonicalization/json. В дополнение к нему определены методы канонического представления, приведенные в таблице 114.
Таблица 114
Дополнительные методы канонического представления
содержания экземпляра ресурса в формате JSON
URI
Дополнительная обработка содержания
http://hl7.org/fhir/canonicalization/json#data
Перед подписью должно быть удалено текстовое представление содержания ресурса (элемент text)
http://hl7.org/fhir/canonicalization/json#static
Кроме текстового представления содержания ресурса (элемент text) удаляются метаданные (элемент meta). Это позволяет сохранять целостность подписи при передаче содержания на другой сервер или при выполнении рабочих процессов, изменяющих значения тегов в метаданных
http://hl7.org/fhir/canonicalization/json#narrative
В содержании оставляются только элементы id и text (то есть подписывается только человеко-читаемое содержание)
http://hl7.org/fhir/canonicalization/json#document
В контейнере Bundle типа document подписывается все внутреннее содержание, кроме Bundle.id и Bundle.metadata (чтобы сохранять целостность подписи при передаче документа на другой сервер)
9.4 Специальные типы данных
9.4.1 Общие сведения
Специальные типы данных используются для вспомогательных целей. Диаграмма классов, описывающая эти типы данных, показана на рисунке 15.
Рисунок 15 - Специальные типы данных
Перечень специальных типов данных приведен в таблице 115.
Таблица 115
Специальные типы данных
Имя
Описание
Пункт
BackboneType
Базовый тип вспомогательных классов
CodeableReference
Ссылка на кодированное понятие или экземпляр ресурса
DataType
Базовый тип данных
Dosage
Дозировка
ElementDefinition
Определение элемента типа данных или ресурса
Extension
Дополнительная информация, не являющаяся частью базового определения ресурса или типа данных
Meta
Метаданные экземпляра ресурса
Narrative
Форматированный текст с описанием содержания экземпляра ресурса
Reference
Ссылка на экземпляр ресурса
xhtml
Текст с упрощенной разметкой xhtml
9.4.2 Базовый тип вспомогательных классов BackboneType
Базовый тип вспомогательных классов BackboneType является детализацией типа данных Element, добавляющей к его свойствам еще одно - modifierExtension (модифицирующее расширение). Общие сведения о типе данных BackboneType приведены в таблице 116, а состав элементов - в таблице 117.
Таблица 116
Общие сведения о типе данных BackboneType
Имя
Описание
Связи с другими элементами модели
BackboneType
Базовое определение комплексных типов данных, которые могут содержать модифицирующие расширения
Отношение генерализации от BackboneType к Element
Таблица 117
Состав элементов типа данных BackboneType
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
modifierExtension
Расширение, которое нельзя игнорировать, даже если оно не распознано
Extension
0..*
9.4.3 Тип данных CodeableReference
Элемент записи электронной медицинской карты может представлять собой ссылку на конкретный экземпляр данных или на общее понятие. Например, лекарственный препарат может быть прописан в связи с головной болью, что указано кодом R51 классификации МКБ-10, или же в связи с результатами исследования, содержащимися в конкретном экземпляре ресурса Observation (исследование).
Возможность такой вариабельности предусмотрена в типе данных CodeableReference (ссылка на кодированное понятие или экземпляр ресурса). Общие сведения о типе данных CodeableReference приведены в таблице 118, а состав элементов - в таблице 119.
Таблица 118
Общие сведения о типе данных CodeableReference
Имя
Описание
Связи с другими элементами модели
CodeableReference
Ссылка на кодированное понятие или экземпляр ресурса
Отношение генерализации от CodeableReference к DataType
Таблица 119
Состав элементов типа данных CodeableReference
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
concept
Кодированное понятие
CodeableConcept
0..1
reference
Ссылка на экземпляр ресурса
Reference
0..1
Если кодированное понятие и ссылка на экземпляр ресурса присутствуют одновременно, то они должны быть согласованы друг с другом. Например, если в concept.coding.code указан код головной боли, то ссылочный экземпляр ресурса должен описывать головную боль.
9.4.4 Базовый тип данных DataType
Тип данных DataType является базовым для всех типов данных. Общие сведения о базовом типе данных DataType приведены в таблице 120, а состав элементов - в таблице 121.
Таблица 120
Общие сведения о типе данных DataType
Имя
Описание
Связи с другими элементами модели
DataType
Базовое определение типов данных
Отношение генерализации от DataType к Element
Таблица 121
Состав элементов типа данных DataType
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
9.4.5 Тип данных Dosage
Тип данных Dosage используется для представления структурированных сведений о дозировке, указываемой в рецептах и описаниях лекарственных средств. Общие сведения о типе данных Dosage приведены в таблице 122, состав элементов представлен на рисунке 16 и в таблице 123. Ограничения типа данных Dosage описаны в таблице 124.
Таблица 122
Общие сведения о типе данных Dosage
Имя
Описание
Связи с другими элементами модели
Dosage
Дозировка
Отношение генерализации от Dosage к BackboneType
Рисунок 16 - Тип данных Dosage
Таблица 123
Состав элементов типа данных Dosage
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
modifierExtension
Модифицирующее расширение, которое нельзя игнорировать, даже если оно не распознано
Extension
0..*
Собственные элементы
sequence
Порядковый номер инструкции по дозировке
integer
0..1
text
Человеко-читаемое описание дозировки (указанное в части Signature рецепта)
string
0..1
additionalInstruction
Дополнительная инструкция или указание пациенту, например, "принимать с едой"
Codeable-Concept
0..*
patientInstruction
Описание применения, рассчитанное на пациента
string
0..1
timing
Кратность приема
Timing
0..*
asNeeded
Признак "принимать при необходимости"
boolean
0..*
asNeededFor
Принимать в случае ...
Codeable-Concept
0..*
site
Место применения
Codeable-Concept
0..1
route
Путь введения
Codeable-Concept
0..1
method
Способ приема
Codeable-Concept
0..1
doseAndRate
Принятое количество лекарства, назначенное количество или типичное количество
Element
0..*
doseAndRate.type
Вид дозы или скорости
Codeable-Concept
0..1
doseAndRate.dose[x]
Количество лекарства в одной дозе. Допустимые типы данных: Range|SimpleQuantity
*
0..1
doseAndRate.rate[x]
Количество лекарства за единицу времени (например в сутки). Допустимые типы данных: Ratio|Range|SimpleQuantity
*
0..1
maxDosePerPeriod
Максимальное количество лекарства в единицу времени
Ratio
0..*
maxDosePerAdministration
Максимальная доза за прием
Simple-Quantity
0..1
maxDosePerLifetime
Максимальная доза за жизнь
Simple-Quantity
0..1
Таблица 124
Ограничения типа данных Dosage
Идентификатор
Вид
Путь
Описание
Выражение
dos-1
Правило
Базовый
Элемент AsNeededFor может присутствовать только в том случае, если элемент AsNeeded пуст или имеет значение true
asNeededFor.empty() or asNeeded.empty() or asNeeded
9.4.6 Тип данных ElementDefinition
9.4.6.1 Общие сведения, состав, ограничения и привязки к наборам значений
Тип данных ElementDefinition используется в ресурсе StructureDefinition для формализованного описания элементов типов данных, ресурсов и расширений. Общие сведения о типе данных ElementDefinition приведены в таблице 125, состав элементов представлен на рисунке 17 и в таблице 126.
Таблица 125
Общие сведения о типе данных ElementDefinition
Имя
Описание
Связи с другими элементами модели
ElementDefinition
Ссылка на экземпляр ресурса
Отношение генерализации от ElementDefinition к BackboneType
Рисунок 17 - Тип данных ElementDefinition
Таблица 126
Состав элементов типа данных ElementDefinition
Имя
Описание
Тип данных
Кратность
Унаследованные элементы
id
Логический идентификатор элемента данных
id
0..1
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifier-Extension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
path
Путь к данному элементу, начиная от имени ресурса или расширения и заканчивая данным элементом. Компоненты пути разделяются точками
string
1
representation
Код, определяющий способ представления данного элемента в экземплярах, в случае отклонения от обычной ситуации. Допустимые значения: xmlAttr (элемент представляется в виде атрибута XML) | xmlText (элемент представляется в виде текста атрибута XML - только для простых типов данных) | typeAttr (тип элемента указывается с помощью xsi:type) | cdaText (в данной версии модели не используется) | xhtml (элемент представляется с помощью упрощенного XHTML)
code
0..*
sliceName
Имя варианта определения данного элемента, если вариабельность имеет место. Имя должно иметь формат токена без точек или пробелов. Оно должно быть уникальным и обозначать конкретный набор ограничений, применяемых к данному элементу. Это имя используется для назначения имен вариантам определения данного элемента
string
0..1
sliceIs-Constraining
Значение true указывает, что это определение варианта ограничивает определение варианта с тем же именем в наследуемом профиле. Значение false указывает, что это определение варианта не переопределяет определение варианта в наследуемом профиле. Если значение отсутствует, то вариант может переопределять или не переопределять вариант в наследуемом профиле в зависимости от значения sliceName
boolean
0..1
label
Предпочтительное имя элемента для визуализации его значения
string
0..1
code
Код конкретной терминологии, имеющий то же значение, что и данный элемент
Coding
0..*
slicing
Указывает, что определение элемента имеет несколько вариантов (например, применяются несколько разных ограничений к одному и тому же элементу базовой структуры). Вариабельность может задаваться для любого элемента, имеющего максимальную кратность "*" в базовом ресурсе, или для любого элемента, тип которого может выбираться из нескольких вариантов. Описания вариантов следуют за данным элементом и имеют тот же самый путь path, пока не встретится более короткий путь (завершающий список вариантов)
Element
0..1
slicing. discriminator
Указывает, каким образом различаются варианты определения элемента данных
Element
0..*
slicing. discriminator. type
Способ различения вариантов определения элемента. Допустимые значения: value (по значению элемента) | exists (по существованию элемента) | type (по типу элемента) | profile (по соответствию элемента определенному профилю) | position (по индексу экземпляра элемента)
code
1
slicing. discriminator. path
Выражение FHIRPath, использующее простое подмножество языка и идентифицирующее элемент, на котором основано различение вариантов
string
1
slicing. description
Человеко-читаемый текст, описывающий вариабельность. Если дискриминатор не указан, наличие этого текста обязательно
string
0..1
slicing. ordered
Признак соответствия порядка следования вариантов в определении элемента и в экземпляре ресурса
boolean
0..1
slicing.rules
Разрешены ли дополнительные варианты, явно не описанные в спецификации. Допустимые значения: closed (дополнительные варианты запрещены) | open (дополнительные варианты возможны) | openAtEnd (дополнительные варианты возможны в конце списка)
code
1
short
Краткое описание элемента (например, для представления в автоматически генерируемых отчетах)
string
0..1
definition
Полное описание семантики элемента данных. Если элемент произведен из существующего элемента (например, с помощью ограничения), то полное описание данного элемента ДОЛЖНО быть совместимо с полным описанием базового элемента, но при этом должно передавать специфику элемента в конкретном контексте использования ресурса
markdown
0..1
comment
Пояснения к использованию элемента данных, например, как использовать его значение, когда его следует исключить и т.д.
markdown
0..1
requirements
Это свойство предназначено для прослеживания того, почему элемент был создан и почему к нему применяются ограничения. Его можно использовать для ссылок на спецификацию, описывающую требования к структуре данного элемента
markdown
0..1
alias
Другое имя, употребляемое для идентификации данного элемента в иной системе
string
0..*
min
Минимальная кратность элемента в экземпляре
unsigned-Int
0..1
max
Максимальная кратность элемента в экземпляре
string
0..1
base
Информация о базовом определении элемента. Если определение элемента не является оригинальным (например, представляет собой ограничение другого типа данных или является потомком типа), то содержание определения может отличаться от базового определения. Если элемент оригинален, то здесь указывается сам элемент
Element
0..1
base.path
Путь, идентифицирующий базовый элемент и представляющий собой список имен потомков, разделенных точками. Список начинается с имени ресурса или расширения
string
1
base.min
Минимальная кратность базового элемента, указанная в его определении
unsigned-Int
1
base.max
Максимальная кратность базового элемента, указанная в его определении
string
1
content-Reference
Указывает другой элемент в определении ресурса, чей контекст применим к данному элементу
uri
0..1
type
Тип данных, который может иметь данный элемент
Element
0..*
type.code
Адрес URL определения типа данных или ресурса, используемого в качестве типа данных данного элемента. Адрес должен быть относителен к http://hl7.org/fhir/StructureDefinition, например "string" означает ссылку на http://hl7.org/fhir/StructureDefinition/string
uri
1
type.profile
Идентификация профиля или руководства по реализации, которому должен соответствовать тип данного элемента. Если указано несколько профилей, то достаточно соответствия одному из них
canonical
0..*
type.target-Profile
Идентификация целевого профиля (только для элементов типа Reference, содержащих ссылку на другой ресурс, или типа canonical, ссылающихся на определение другой структуры)
canonical
0..*
type. aggregation
Способ агрегирования с целевым экземпляром ресурса. Допустимые значения: contained (ссылается на вложенный экземпляр ресурса) | referenced (ссылается на внешний экземпляр ресурса) | bundled (ссылается на экземпляр ресурса, вложенный в тот же контейнер Bundle)
code
0..*
type.versioning
Версионность ссылки на экземпляр ресурса. Допустимые значения: either (может включать или не включать версию) | independent (версия не включается)) | specific (версия включается)
code
0..1
defaultValue[x]
Значение элемента по умолчанию
*
0..1
meaningWhen-Missing
Трактовка отсутствия данного элемента
markdown
0..1
orderMeaning
Если свойство присутствует, то оно указывает, что порядок следования экземпляров повторяющегося элемента существенен, и описывает его смысл. Его отсутствие означает, что порядок следования экземпляров не имеет значения
string
0..1
fixed[x]
Указывает значение, которое должен иметь элемент в экземпляре. При сравнении незначащие пробелы игнорируются, и все компоненты значения должны совпадать (сравнение чувствительно к регистру). Отсутствующий компонент должен отсутствовать и в экземпляре
*
0..1
pattern[x]
Указывает образцовое значение, которое должно присутствовать в экземпляре элемента, то есть любое значение, указанное в pattern, должно присутствовать в экземпляре. Указание pattern является "ограничением по образцу". Если pattern[x] используется для ограничения элемента с простым типом данных, то указанное в нем значение должно в точности совпадать со значением экземпляра элемента. Если pattern[x] используется для ограничения элемента, содержащего массива значений, то каждое значение, указанное в массиве pattern[x], должно (рекурсивно) совпадать по крайней мере с одним значением в массиве, содержащемся в элементе. Если pattern[x] используется для ограничения комплексного объекта, то каждое свойство, указанное в pattern[x], должно присутствовать в комплексном объекте и иметь (рекурсивно) то же самое значение. Если pattern[x] указано для повторяющегося элемента, то его значение применяется к каждому повторению элемента
*
0..1
example
Пример значения данного элемента
Element
0..*
example.label
Описание назначения примера
string
1
example. value[x]
Значение типа [x], допустимого для данного элемента, предлагаемое в качестве примера
*
1
minValue[x]
Минимальное значение элемента
*
0..1
maxValue[x]
Максимальное значение элемента
*
0..1
maxLength
Максимальное число символов, допускаемое для значения элемента со строковым типом данных
integer
0..1
condition
Ссылка на инвариант, описывающий дополнительные требования к кратности элемента или к его значению
id
0..*
constraint
Формальное ограничение, например, совместимость наличия элемента с наличием другого элемента, и иное ограничение, которое может быть вычислено в контексте экземпляра элемента
Element
0..*
constraint.key
Идентификатор ограничения, наложенного на кратность элементов
id
1
constraint. requirements
Описание причины ограничения
string
0..1
constraint. severity
Степень влияния ограничения на прикладную обработку. Допустимые значения: error (ошибка) | warning (предупреждение)
code
1
constraint. suppress
Указывает, что при профилировании элемента ограничение с кодом степени warning (предупреждение) может быть исключено
boolean
0..1
constraint. human
Текст сообщения о нарушении данного ограничения
string
1
constraint. expression
Выражение на языке FHIRPath, позволяющее проверить выполнение ограничения
string
0..1
constraint. source
Ссылка на источник ограничения
canonical
0..1
mustHave-Value
Указывает, что элемент с простым типом данных должен иметь значение, даже если имеет расширение
boolean
0..1
value-Alternatives
Расширение, которое может заменить значение элемента с простым типом данных
canonical
0..*
mustSupport
Значение true указывает, что потребитель или поставщик содержания экземпляра ресурса должен обеспечить какую-либо содержательную поддержку данного элемента. Значение false указывает, что присваивание значения оставлено на усмотрение поставщика, а использование - на усмотрение потребителя
boolean
0..1
isModifier
Значение true указывает, что значение данного элемента влияет на интерпретацию элемента или ресурса, который его содержит, и значение данного элемента не может игнорироваться. Обычно указывается для элементов, характеризующих статус экземпляра ресурса, квалифицирующих его или отрицающих его содержание
boolean
0..1
isModifier-Reason
Разъяснение причины, по которой значение данного элемента влияет на интерпретацию содержащего его ресурса или элемента
string
0..1
isSummary
Должен ли данный элемент включаться в результат запроса, в котором параметр _summary=true.
boolean
0..1
binding
Привязка кодируемого значения элемента (code, Coding, CodeableConcept, Quantity) или элемента типа string либо uri к набору значений
Element
0..1
binding. strength
Степень обязательности применения данной привязки к набору значений. Допустимые значения: обязателен | расширяемый (набор может быть расширен) | предпочтительный | пример (в качестве примера)
code
1
binding. description
Наименование набора значений
string
0..1
binding. valueSet
Ссылка на определение набора значений
canonical
0..1
mapping
Указывает понятие, определенное во внешней спецификации, примерно соответствующее данному элементу
Element
0..1
mapping. identity
Ссылка на идентификатор внешней спецификации, указанный в StructureDefinition.mapping.identity
id
1
mapping. language
Идентификация синтаксиса, на котором представлено отображение mapping.map
code
0..1
mapping.map
Указание той части внешней спецификации, которая соответствует данному элементу
string
1
mapping. comment
Примечание к спецификации отображения
string
0..1
Ограничения описаны в таблице 127, привязки к наборам значений - в таблице 128.
Таблица 127
Ограничения типа данных ElementDefinition
Идентификатор
Вид
Путь
Описание
Выражение
eld-2
Правило
Базовый
min <= max
min.empty() or max.empty() or (max = '*') or iif(max != '*', min <= max.toInteger())
eld-3
Правило
ElementDefinition.max
Кратность max должна быть числом или символом "*"
empty() or ($this = '*') or (toInteger() >= 0)
eld-4
Правило
ElementDefinition.type
Элемент aggregation может быть указан только в том случае, если одним из разрешенных типов данных является Reference или canonical
aggregation. empty() or (code = 'Reference') or (code = 'canonical') or (code = 'CodeableReference')
eld-5
Правило
Базовый
Если в определении элемента указан элемент contentReference, то в нем нельзя указать тип type, значение по умолчанию defaultValue, фиксированное значение fixed, образцовое значение pattern, пример example, минимальное и максимальное значение minValue, maxValue, максимальную длину maxLength или привязку к набору значений binding
contentReference. empty() or (type.empty() and defaultValue.empty() and fixed.empty() and pattern.empty() and example. empty() and minValue.empty() and maxValue.empty() and maxLength.empty() and binding.empty())
eld-6
Правило
Базовый
Фиксированное значение fixed можно указать только в том случае, если элемент имеет единственный тип
fixed.empty() or (type.count() <= 1)
eld-7
Правило
Базовый
Образцовое значение pattern можно указать только в том случае, если элемент имеет единственный тип
pattern.empty() or (type.count() <= 1)
eld-8
Правило
Базовый
Образцовое значение pattern и фиксированное значение fixed исключают друг друга
pattern.empty() or fixed.empty()
eld-11
Правило
Базовый
Привязка к набору значений binding может быть указана только для элементов с кодируемыми значениями или имеющими тип string либо uri
binding.empty() or type.code.empty() or type.code.contains(":") or type.select((code = 'code') or (code = 'Coding') or (code='Codeable-Concept') or (code = 'Quantity') or (code = 'string') or (code = 'uri') or (code = 'Duration')).exists()
eld-12
Правило
ElementDefinition.binding
Значение свойства valueSet должно начинаться с http://, или https://, или urn:, или #
valueSet.exists() implies (valueSet.startsWith('http:') or valueSet.startsWith('https') or ueSet.startsWith('urn:') or valueSet.startsWith('#'))
eld-13
Правило
Базовый
Значения свойства code типов type, допускаемых для данного элемента, не должны повторяться
type.select(code).isDistinct()
eld-14
Правило
Базовый
Значения свойства key ограничений constraint не должны повторяться
constraint.select(key).isDistinct()
eld-15
Правило
Базовый
Значение по умолчанию default и свойство семантики отсутствия элемента meaningWhenMissing исключают друг друга
defaultValue.empty() or meaningWhenMissing.empty()
eld-16
Правило
Базовый
Значение имени варианта sliceName должно состоять из допустимых токенов, разделенных символом "/"
sliceName.empty() or sliceName.matches('^[a-zA-Z0-9\\/\\-_\\[\\]\\@]+$')
eld-17
Правило
ElementDefinition.type
Свойство целевого профиля targetProfile допустимо только в том случае, если элемент имеет тип Reference, CodeableReference или canonical
(code='Reference' or code = 'canonical' or code = 'CodeableReference') or targetProfile.empty()
eld-18
Правило
Базовый
Если признак модификации семантики isModifier равен true, то должна быть указана причина модификации modifierReason
(isModifier.exists() and isModifier) implies isModifierReason.exists()
eld-19
Правило
Базовый
Имя элемента не должно содержать определенные специальные символы
path.matches('[^\
\s\\.,:;\\\'\\/|?!@#$%&*()\\
[\\]{}]{1,64}(\\.
[^\\s\\.,:;\\\'\\/|?!@#$%&*()\\
[\\]{}]{1,64}(\\
[x\\])?(\\:[^\\s\\.]+)?)*')
eld-20
Правило
Базовый
Рекомендуется, чтобы имя элемента состояло из букв латинского алфавита и цифр, а его длина не превышала 64 символа, иначе некоторые генераторы программного кода могут возвращать ошибки
p a t h . m a t c h e s( ' [A - Z a - z ]
[ A - Z a - z 0 - 9 ] * ( \ \ . [ a - z ]
[A-Za-z0-9]*(\\[x])?)*')
eld-21
Правило
ElementDefinition.constraint
Рекомендуется, чтобы в описании ограничения (constraint) присутствовало выражение expression, иначе программные валидаторы содержания элемента не смогут проверить выполнение ограничения
expression.exists()
eld-22
Правило
Базовый
Признак ограничивающего варианта (sliceIsConstraining) может быть указано только в случае, если присутствует имя варианта sliceName
sliceIsConstraining. exists() implies sliceName. exists()
eld-23
Правило
ElementDefinition.binding
Элемент binding должен иметь свойство valueSet или description
description.exists() or valueSet. exists()
eld-24
Рекомендация
Базовый
Вместо fixed[x] следует использовать pattern[x]
fixed.exists().not()
eld-25
Предупреждение
Базовый
Если порядок следования экземпляров элемента не имеет значения, то упорядоченность вариантов элемента не должна задаваться
orderMeaning. empty() implies slicing. where(rules='openAtEnd' or ordered).exists().not()
eld-26
Правило
ElementDefinition.constraint
Ограничение с кодом степени error (ошибка) не может быть исключено
(severity = 'error') implies suppress.empty()
eld-27
Предупреждение
Базовый
Идентификатор identity элемента mapping должен быть уникальным
mapping.select (identity).isDistinct()
eld-28
Правило
Базовый
Если mustHaveValue = true, то элемент valueAlternatives должен отсутствовать
mustHaveValue. value implies valueAlternatives.empty()
Таблица 128
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
ElementDefinition.representation
http://hl7.org/fhir/ValueSet/property-representation
Обязательная
Представление свойства при сериализации
ElementDefinition.slicing.discriminator.type
http://hl7.org/fhir/ValueSet/discriminator-type
Обязательная
Интерпретация значения элемента при вычислении дискриминатора
ElementDefinition.slicing.rules
http://hl7.org/fhir/ValueSet/resource-slicing-rules
Обязательная
Интерпретация вариантов определения элемента
ElementDefinition.type.code
http://hl7.org/fhir/ValueSet/elementdefinition-types
Расширяемая
Допустимые типы элементов
ElementDefinition.type.aggregation
http://hl7.org/fhir/ValueSet/resource-aggregation-mode
Обязательная
Варианты ссылок на экземпляр ресурса
ElementDefinition.constraint.severity
http://hl7.org/fhir/ValueSet/constraint-severity
Обязательная
Степень нарушения ограничения
ElementDefinition.mapping.language
http://hl7.org/fhir/ValueSet/mime-type
Обязательная
Тип содержания Mime - все допустимые коды из BCP-13 (http://tools.ietf.org/html/bcp13)
9.4.6.2 Использование пути ElementDefinition.path
Свойство пути path является важнейшим свойством определения элемента. Оно не только именует элемент, но еще и указывает его место в иерархии элементов. Для каждого пути path существует только одно исходное определение. Оно является главным определением, которому должны соответствовать все другие определения с этим же значением пути path.
Каждый элемент данных определен в экземпляре ресурса StructureDefinition, описывающем тип ресурса или тип данных. Он задает идентификацию элемента и представляет контекст, в котором значение элемента обретает определенный смысл. При определении элементов должны соблюдаться следующие правила:
а) имена элементов (части пути path, разделенные символом '.') не должны содержать пробельные символы (то есть символы Unicode, помеченные как пробельные);
б) имена элементов не должны содержать символы ,:;/|?!@#$%^&*()[]{};
в) имена элементов не должны содержать символы, не входящие в таблицу-ASCII;
г) длина имен элементов не должна превышать 64 символа;
д) пути path не могут подразумевать элементы, не определенные явно (например, путь a.b.c.d не может быть задан, если не определен путь a.b.c);
е) по соглашению каждый путь начинается с прописной буквы, но все следующие имена (кроме имен типов) должны начинаться со строчной буквы. Имена всех типов ресурсов и типов данных (кроме примитивных) должны следовать этому соглашению.
Если элемент является полиморфным (может иметь несколько типов данных), то путь должен заканчиваться символами "[x]", означающими, что имя элемента при сериализации может изменяться.
Элементы могут быть определены, используя следующие конструкции:
а) с помощью экземпляра ресурса StructureDefinition, в котором элемент kind = resource, complex-type или primitive-type, а элемент derivation = specialization. Это типы ресурсов или типы данных, определенные в спецификации;
б) в элементах данных.
В экземплярах ресурса StructureDefinition, имеющих свойство derivation = ограничение (то есть в профилях ресурсов и типов данных), не разрешается указывать или определять элементы типа ElementDefinition, у которых значение пути path отсутствует в определении базового типа, от которого они произведены.
9.4.6.3 Идентификатор ElementDefinition.id
Кроме элемента path, каждый элемент типа данных ElementDefinition должен содержать унаследованный элемент id (идентификатор), которому должно быть присвоено уникальное значение в соответствии со следующим алгоритмом:
а) значение id должно конструироваться как строка, разделенная точками, у которой каждый компонент соответствует токену в пути path;
б) для каждого компонента пути path в идентификаторе id используется синтаксис pathpart.slicename/reslicename (то есть компонент:имя-варианта/имя-подварианта).
При отсутствии вариантов определения элемента значение идентификатора id должно в точности совпадать со значением пути path.
9.4.6.4 Интерпретация значений элементов типа данных ElementDefinition в разных контекстах
Тип данных ElementDefinition используется в ресурсе StructureDefinition. Способ использования и интерпретации полей типа данных ElementDefinition зависит от контекста в соответствии с таблицей 129.
Таблица 129
Интерпретация элементов типа данных ElementDefinition
в зависимости от контекста
Элемент типа данных Element-Definition
Определение типа, первый элемент
Определение типа, следующие элементы
Определение ограничения типа, первый элемент
Определение ограничения типа, следующие элементы
sliceName
запрещен
запрещен
запрещен
обязателен для варианта, иначе запрещен
label
не обязателен
не обязателен
рекомендован
рекомендован
code
не обязателен
не обязателен
не обязателен
не обязателен
slicing
запрещен
запрещен
запрещен
не обязателен
short/definition
обязателен
обязателен
обязателен
обязателен
requirements/comments/alias
запрещен
не обязателен
запрещен
не обязателен
base
snapshot: обязателен
differential: не обязателен
snapshot: обязателен
differential: не обязателен
обязателен
обязателен
type
обязателен
обязателен
не обязателен
не обязателен
name-Reference
запрещен
не обязателен
запрещен
не обязателен
min/max
не обязателен (irrelevant)
обязателен
не обязателен
не обязателен
default-Value[x]
запрещен
не обязателен
запрещен
не обязателен
meaning-WhenMissing
запрещен
не обязателен
запрещен
не обязателен
fixed[x]
запрещен
запрещен
запрещен
не обязателен
pattern[x]
запрещен
запрещен
запрещен
не обязателен
example[x]
запрещен
не обязателен
запрещен
не обязателен
minValue[x]
запрещен
запрещен
запрещен
не обязателен
maxValue[x]
запрещен
запрещен
запрещен
не обязателен
maxLength
запрещен
запрещен
запрещен
не обязателен
mustSupport
запрещен
запрещен
не обязателен
не обязателен
isModifier
запрещен
не обязателен
запрещен
не обязателен
isSummary
запрещен
не обязателен
запрещен
не обязателен
binding
запрещен
не обязателен
запрещен
не обязателен
constraint
не обязателен
не обязателен
не обязателен
не обязателен
condition
запрещен
не обязателен
запрещен
не обязателен
mapping
не обязателен
не обязателен
не обязателен
не обязателен
Примечания
1 Графы Определение типа: экземпляр ресурса StructureDefinition без элемента baseDefinition или имеющий поле derivationType со значением специализация.
2 Графы Определение ограничения типа: экземпляр ресурса StructureDefinition с элементом baseDefinition, имеющий поле derivationType со значением ограничение, то есть описание структуры, ограничивающей другую структуру:
3 В графах Определение ограничения типа используются следующие обозначения:
: присутствие и семантика элемента должны совпадать с определением в базовой структуре;
: описание элемента должно быть согласовано с описанием совпадающего элемента базовой структуры;
: могут быть определены дополнительные ограничения и отображения, но они не должны заменять те, что уже присутствуют в базовой структуре.
Зависимость использования пути path и типа type от контекста, в котором они используются, представлена в таблице 130.
Таблица 130
Зависимость использования пути path и типа type
от контекста использования
Контекст
Путь path (первый элемент)
Путь path (следующие элементы)
Тип type (первый элемент)
Базовое определение типа данных
Имя типа
Путь внутри типа данных
Element
Ограничение типа данных
Имя базового типа
Путь внутри типа данных
Имя базового типа
Базовое определения ресурса
Имя ресурса
Путь внутри ресурса
DomainResource или иногда Resource
Ограничение ресурса
Имя ресурса
Путь внутри ресурса (в том числе с заходом внутрь типа данных)
Имя ресурса
Базовое определение ограничения (являющего стандартным типом данных)
Extension
Extension.value[x] или Extension.extension
Extension
Определение пользовательского расширения
Extension
Extension.value[x] или Extension.extension (для комплексных расширений)
Extension
9.4.6.5 Правила описания вариантов элемента (slicing)
Спецификация вариантов (slicing) допускается только при ограничении существующей структуры. Свойство slicing может использоваться только при первом вхождении элемента. Все остальные вхождения должны иметь свойство sliceName. Специальное имя @default применяется ко всем вхождениям, которые не входят в число других вхождений.
Первое вхождение (для которого указана спецификация slicing) описывает набор ограничений, применяемых ко всем вхождениям. Его описание следует обычным правилам, за исключением следующего:
а) должно присутствовать свойство slicing;
б) минимальная кратность (min) указывает общее число вхождений вариантов, включая число открытой порции вариантов (отдельные варианты могут иметь другое значение минимальной кратности min).
9.4.6.6 Ограничение элементов, для которых допускается выбор типа
Элементы, для которых допускается выбор из нескольких типов, могут ограничиваться. Существует два вида ограничений таких элементов:
а) ограничение, накладываемое на элемент в целом, например, ограничение кратности или ограничения выбора типа;
б) ограничение, применяемое к элементу конкретного типа, например, привязка к набору значений (binding).
При ограничении элемента, для которого допускается выбор из нескольких типов, применяются следующие правила:
а) ограничение списка допустимых типов должно применяться к исходному элементу, в имени которого указан признак "[x]";
б) включение в спецификацию пути path элемента, специфичного для типа (например, Patient.deceased[x]:deceasedBoolean) не должно интерпретироваться как ограничение допустимых типов. Оно описывает ограничение конкретного типа элемента;
в) исходный элемент всегда должен быть представлен в полном списке элементов snapshot; варианты, специфичные для типа, представляются по мере необходимости.
9.4.6.7 Правила, применяемые к кратностям min и max
К кратностям min и max применяются следующие правила:
а) если указание базового определения StructureDefinition.baseDefinition отсутствует, то min и max должны быть указаны;
б) в элементах StructureDefinition.differential.element кратности min и max всегда необязательны; если они отсутствуют, то по умолчанию их значения совпадают с кратностями min и max, указанными для базового определения;
в) в элементах StructureDefinition.snapshot.element кратности min и max должны быть указаны;
г) если элемент необязателен (min = 0) и в его определении указан элемент fixed (фиксированное значение) или pattern (образец значения), то их значения применяются только в том случае, если элемент присутствует.
9.4.6.8 Правила, применяемые к агрегированию
Если в определении структуры присутствует поле type.aggregation (способ агрегирования с целевым ресурсом), то это определение должно относиться к элементу типа Reference или CodeableReference и в нем должен быть указан целевой профиль targetProfile.
Если в определении присутствует поле type.versioning (зависимость от версии ссылочного ресурса), то это определение должно относиться к элементу типа Reference и в экземпляре элемента ссылка должна воплощаться в соответствии со спецификацией версионности.
9.4.6.9 Отсутствующие элементы
Большинство элементов имеет минимальную кратность 0, то есть они могут отсутствовать в экземпляре ресурса. При обработке такого экземпляра приложение должно считать значение отсутствующего элемента неизвестным - оно может иметься у поставщика данных, но отсутствовать по причинам защиты информации, или отсутствовать у самого поставщика.
Это же применимо к ситуации, когда элемент присутствует, но его значение и все его дочерние элементы отсутствуют, а наличествуют только расширения.
Однако для некоторых элементов в настоящей спецификации можно указать особую трактовку отсутствия значения. Например, если конец периода (Period.end) не указан, то это означает, что период продолжается (никакое конкретное значение по умолчанию концу периода не может быть присвоено). Для указания такой трактовки предусмотрено текстовое свойство meaningWhenMissing.
9.4.7 Тип данных Extension
Тип данных Extension может использоваться для представления дополнительной информации, не являющейся частью базового определения ресурса или типа данных. Поскольку он наследует свойство extension с типом Extension и кратностью 0..* от типа данных Element, то внутри расширения могут быть другие расширения и т.д. Общие сведения о типе данных Extension приведены в таблице 131, а состав элементов - в таблице 132.
Таблица 131
Общие сведения о типе данных Extension
Имя
Описание
Связи с другими элементами модели
Extension
Необязательный элемент, включаемый во все типы ресурсов
Отношение генерализации от Extension к Element
Таблица 132
Состав элементов типа данных Extension
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
url
Идентификатор структуры расширения (url, откуда можно взять описание структуры расширения)
uri
1
value[x]
Значение, передаваемое в расширении, ДОЛЖНО иметь тип из ограниченного набора типов
*
0..1
Имя value[x] означает, что тип значения определяется в зависимости от назначения расширения. В конкретном экземпляре типа данных Extension это имя должно заменяться на одно из имен, перечисленных в таблице 133.
Таблица 133
Имена типов значений, передаваемых в расширении Extension
Имя
Описание
Тип
valueBase64Binary
Двоичное содержание
base64Binary
valueBoolean
Булевское значение
boolean
valueCanonical
Канонический URL
canonical
valueCode
Перечислимый тип
code
valueDate
Дата
date
valueDateTime
Дата и время
dateTime
valueDecimal
Десятичное значение
decimal
valueId
Идентификатор
id
valueInstant
Штамп даты и времени
instant
valueInteger
Целочисленное значение (32 бита)
integer
valueInteger64
Целочисленное значение (64 бита)
integer64
valueMarkdown
Структурированный текст с разметкой Markdown
markdown
valueOid
Объектный идентификатор
oid
valuePositiveInt
Положительное целое число
positiveInt
valueString
Строка
string
valueTime
Время
time
valueUnsignedInt
Неотрицательное целое число
unsignedInt
valueUri
Унифицированный идентификатор ресурса
uri
valueUrl
Унифицированный адрес ресурса
url
valueUuid
Унифицированный уникальный идентификатор
uuid
valueAddress
Адрес
Address
valueAge
Возраст в единицах длительности
Age
valueAnnotation
Аннотация
Annotation
valueAttachment
Вложение
Attachment
valueCodeableConcept
Кодированное понятие
CodeableConcept
valueCodeableReference
Ссылка на кодированное понятие или экземпляр ресурса
CodeableReference
valueCoding
Кодированное значение
Coding
valueContactPoint
Контактная информация
ContactPoint
valueCount
Количество подсчетов (в единицах)
Count
valueDistance
Дистанция (в единицах расстояния)
Distance
valueDuration
Длительность (в единицах длительности)
Duration
valueHumanName
Именование физического лица
HumanName
valueIdentifier
Идентификатор
Identifier
valueMoney
Денежная сумма
Money
valuePeriod
Период
Period
valueQuantity
Физическая величина
Quantity
valueRange
Диапазон
Range
valueRatio
Отношение
Ratio
valueRatioRange
Диапазон отношений
RatioRange
valueReference
Ссылка на другой экземпляр ресурса
Reference
valueSampledData
Серия считываний
SampledData
valueSignature
Подпись
Signature
valueTiming
Расписание
Timing
valueContactDetail
Детальная контактная информация
ContactDetail
valueDataRequirement
Общие требования к данным ресурса знаний
DataRequirement
valueExpression
Выражение на определенном языке, которое может использоваться для получения значения
Expression
valueParameterDefinition
Определение параметра
ParameterDefinition
valueRelatedArtifact
Сведения об артефакте, связанном с ресурсами знаний
RelatedArtifact
valueTriggerDefinition
Описание события, инициирующего применение ресурса знаний
TriggerDefinition
valueUsageContext
Описание контекста использования
UsageContext
valueAvailability
Сведения о доступности физического места, службы или медицинского работника
Availability
valueExtendedContactDetail
Детальная контактная информация лица или организации
ExtendedContactDetail
valueDosage
Дозировка
Dosage
valueMeta
Метаданные ресурса
Meta
9.4.8 Тип данных Meta
Тип данных Meta описывает метаданные экземпляра ресурса. Общие сведения о типе данных Meta приведены в таблице 134, а состав элементов - в таблице 135.
Таблица 134
Общие сведения о типе данных Meta
Имя
Описание
Связи с другими элементами модели
Meta
Набор метаданных экземпляра ресурса. Все метаданные не обязательны, но некоторые из них могут быть объявлены обязательными при профилировании или в зависимости от контекста использования
Отношение генерализации от Meta к DataType
Таблица 135
Состав элементов типа данных Meta
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
versionId
Логический идентификатор версии экземпляра ресурса. Может быть указан при ссылке на этот экземпляр
id
0..1
lastUpdated
Точные дата и время изменения содержания экземпляра ресурса
instant
0..1
source
Идентификатор источника, послужившего основой для содержания экземпляра ресурса
uri
0..1
profile
Ссылка на определение ресурса или его профиля, представленное экземпляром ресурса StructureDefinition
canonical
0..*
security
Категория конфиденциальности экземпляра ресурса. Привязка к набору значений http://hl7.org/fhir/ValueSet/security-labels (расширяемая)
Coding
0..*
tag
Тег, применяемый к данному экземпляру ресурса. Теги предназначены для дополнительной идентификации ресурсов сторонними процессами и потоками работ. Привязка к набору значений http://hl7.org/fhir/ValueSet/common-tags (пример)
Coding
0..*
9.4.9 Тип данных Narrative
9.4.9.1 Общие требования
Тип данных Narrative (повествование) может использоваться для представления форматированного текста, описывающего содержание экземпляра ресурса. Этот текст может генерироваться по структурированному содержанию экземпляра ресурса, может расширять или дополнять это содержание, или отсутствовать. Назначение текста определяется полем status. Форматированный текст представлен в поле div с использованием упрощенного формата XHTML.
Общие сведения о типе данных Narrative приведены в таблице 136, а состав элементов - в таблице 137.
Таблица 136
Общие сведения о типе данных Narrative
Имя
Описание
Связи с другими элементами модели
Narrative
Человеко-читаемое представление содержания экземпляра ресурса
Отношение генерализации от Narrative к Element
Таблица 137
Состав элементов типа данных Narrative
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
status
Одно из значений: generated (сгенерирован) | extensions (расширен) | additional (дополнен) | empty (пуст)
code
1
div
Текст в упрощенном формате XHTML
xhtml
1
9.4.9.2 Текст в формате XHTML
Значение элемента div должно представлять собой фрагмент XHTML, в котором используются только базовое форматирование, описанное в главах 7 - 11 (кроме раздела 4 главы 9) и в главе 15 стандарта HTML 4.0, элементы <a> (по имени или по ссылке href), изображения и внутренние атрибуты стилей. В содержании фрагмента должны отсутствовать элементы head и body, внешние ссылки на стили, запрещенные элементы, скрипты, формы, ссылки base/link/xlink, фреймы frame и iframe, объекты и атрибуты, относящиеся к событиям (например, onClick). Эти ограничения наложены, чтобы повествовательное описание экземпляра ресурса полностью содержалось в этом экземпляре, и чтобы не было активного содержания.
В представлении XML фрагмент XHTML воспроизводится как есть, например:
<narrative>
<status value="additional"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>
Это <i>пример</i> с использованием <b>xhtml</b> форматирования
</p>
</div>
</narrative>
В представлении JSON фрагмент XHTML воспроизводится как строковое значение, например:
div: <div xmlns=\http://www.w3.org/1999/xhtml\><p>Это <i>пример</i> с
использованием <b>xhtml</b> форматирования</p></div>
В обоих представлениях должна использоваться кодировка UTF-8.
9.4.9.3 Ссылки на изображения
Текст в формате XHTML может содержать ссылки на изображения при условии, что эти изображения представлены в экземпляре ресурса в форме вложенных экземпляров ресурсов DocumentReference или Binary, например:
<Patient xmlns="http://hl7.org/fhir">
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>... <img src="#pic1"/>. ....</p>
</div>
</text>
<contained>
<Binary><id value="pic1"/><contentType value="image/gif"/><data
value="MEKH....SD/Z"/></Binary>
</contained>
</Patient>
В этом примере атрибут src содержит значение идентификатора id вложенного экземпляра ресурса Binary. Это значение указано с префиксом #, который должен предшествовать любой ссылке на вложенный экземпляр ресурса.
Чтобы обозреватель Интернет мог воспроизвести повествовательное содержание с такими ссылками, оно должно быть предварительно обработано, например, можно сохранить изображение в виде файла в месте, доступном обозревателю, и заменить <img src ...> на соответствующую ссылку.
9.4.9.4 Перекрестные ссылки внутри экземпляра ресурса
Перекрестные ссылки между повествовательным содержанием и структурированным содержанием экземпляра ресурса (в обоих направлениях) осуществляются с помощью XML-конструкции id/idref. Соответственно цель ссылки (id) должна иметь имя, уникальное в пределах полного содержания экземпляра ресурса и начинающееся с буквы или подчеркивания. Пробельные элементы внутри имени не допускаются.
В представлении JSON свойство id эквивалентно XML-атрибуту id.
9.4.9.5 Рекомендованные стили
В таблице 138 приведены рекомендованные стили разметки повествовательного содержания экземпляра ресурса.
Таблица 138
Рекомендованные стили разметки повествовательного содержания
Имя стиля
Описание
Представление
bold
Полужирный текст
{ font-weight: bold }
italics
Курсив
{ font-style: italic }
underline
Подчеркнутый текст
{ text-decoration: underline }
strikethrough
Перечеркнутый текст
{ text-decoration: line-through }
left
Выравнивание влево
{ text-align : left }
right
Выравнивание вправо
{ text-align : right }
center
Выравнивание по центру
{ text-align : center }
justify
Выравнивание по ширине
{ text-align : justify }
border-left
Граница слева
{ border-left: 1px solid grey }
border-right
Граница справа
{ border-right: 1px solid grey }
border-top
Граница сверху
{ border-top: 1px solid grey }
border-bottom
Граница снизу
{ border-bottom: 1px solid grey }
arabic
Нумерованный список (арабские цифры: 1, 2, 3, ...)
{ list-style-type: decimal }
little-roman
Нумерованный список (римские цифры в нижнем регистре: i, ii, iii, ...)
{ list-style-type: lower-roman }
ИС МЕГАНОРМ: примечание.
В официальном тексте документа, видимо, допущена опечатка: одна и та же строка таблицы повторяется трижды.
little-roman
Нумерованный список (римские цифры в нижнем регистре: i, ii, iii, ...)
{ list-style-type: lower-roman }
little-roman
Нумерованный список (римские цифры в нижнем регистре: i, ii, iii, ...)
{ list-style-type: lower-roman }
big-roman
Нумерованный список (римские цифры в верхнем регистре: I, II, III, ...)
{ list-style-type: upper-roman }
little-alpha
Нумерованный список (символы в нижнем регистре: a, b, c, ...)
{ list-style-type: lower-alpha }
big-alpha
Нумерованный список (символы в верхнем регистре: A, B, C, ...)
{ list-style-type: upper-alpha }
disc
Маркированный список (сплошные кружки)
{ list-style-type: disc }
circle
Маркированный список (кружки с отверстиями)
{ list-style-type : circle }
square
Маркированный список (сплошные квадраты)
{ list-style-type: square }
unlist
Немаркированный список
{ list-style-type: none }
9.4.9.6 Связывание повествовательного и структурированного содержания
В ряде случаев может оказаться полезным указание связи между повествовательным и структурированным содержанием экземпляра ресурса. Для этой цели используются расширения extension, имеющие следующие идентификаторы url:
а) http://hl7.org/fhir/StructureDefinition/narrativeLink - ссылка из элемента структурированного содержания на фрагмент повествовательного содержания, не имеющая определенной семантики;
б) http://hl7.org/fhir/StructureDefinition/originalText - ссылка из кодированного элемента структурированного содержания на фрагмент повествовательного содержания, имеющая семантику "текст, послуживший основанием для присваивания кода".
Пример использования расширения originalText:
{
"resourceType" : "Condition",
"text" : {
"status" : "additional",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">В анамнезе <span
id=\"a1\">астма</span></div>"
},
"code" : {
"coding" : {
"system" : "urn:oid:1.2.643.5.1.13.13.11.1005",
"code" : "J45.9",
"display" : "астма неуточненная"
},
"extension" : [{
"url" : "http://hl7.org/fhir/StructureDefinition/originalText",
valueUrl : #a1
}]
}
}
В этом примере фрагменту повествовательного содержания "астма" присвоен идентификатор a1. Элемент структурированного содержания code имеет тип CodeableConcept. Его кодированный компонент coding имеет тип Coding с компонентами system (идентификатор системы кодирования), code (код понятия) и display (краткое описание понятия). Компонент system имеет значение urn:oid:1.2.643.5.1.13.13.11.1005 (объектный идентификатор классификации МКБ-10 в нормативно-справочной информации Минздрава России), компонент code имеет значение J45.9, а display - "астма неуточненная".
В элемент структурированного содержания code добавлено расширение с идентификатором url = http://hl7.org/fhir/StructureDefinition/originalText и значением valueUrl = #a1, представляющим собой внутреннюю ссылку на фрагмент текста с идентификатором a1, послуживший основанием для присваивания кода МКБ.
Аналогичный метод может быть использован для ссылок в пределах контейнера Bundle. Но в этом случае идентификатору a1 должен предшествовать полный URL того экземпляра ресурса, внутри которого содержится ссылочный фрагмент:
<Bundle xmlns="http://hl7.org/fhir">
<entry>
<fullUrl value="http://example.org/fhir/Composition/abcdefghij"/>
<Composition>
<id value="c1"/>
<section>
...
<text>
<div xmlns="http://www.w3.org/1999/xhtml">
...
<p>В анамнезе <span id="a1">астма</span></p>
...
</div>
</text>
</section>
</Composition>
</entry>
<entry>
<Condition>
<code>
<extension url="http://hl7.org/fhir/StructureDefinition/originalText">
<valueUrl value="http://example.org/fhir/Composition/abcdefghij#a1"/>
</extension>
<coding>
<system value="urn:oid:1.2.643.5.1.13.13.11.1005"/>
<code value="J45.9"/>
<display value="Астма неуточненная"/>
</coding>
</code>
</Condition>
</entry>
</Bundle>
9.4.10 Тип данных Reference
9.4.10.1 Общие требования, состав и ограничения
Тип данных Reference используется для представления ссылки на экземпляр ресурса. Например, экземпляр ресурса Organization (организация) может ссылаться на экземпляр ресурса EndPoint, описывающий сервис, предоставляемый организацией в сети Интернет. Общие сведения о типе данных Reference приведены в таблице 139, а состав элементов - в таблице 140. Ограничения типа данных Reference описаны в таблице 141.
Таблица 139
Общие сведения о типе данных Reference
Имя
Описание
Связи с другими элементами модели
Reference
Ссылка на экземпляр ресурса
Отношение генерализации от Reference к Element
Таблица 140
Состав элементов типа данных Reference
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
reference
Литеральная ссылка (абсолютный, внутренний или относительный URL)
string
0..1
type
Тип ссылочного ресурса
uri
0..1
identifier
Логический идентификатор экземпляра ресурса, если литеральный идентификатор не известен
Identifier
0..1
display
Текстовая альтернатива ссылочного экземпляра ресурса
string
0..1
Таблица 141
Ограничения типа данных Reference
Идентификатор
Вид
Путь
Описание
Выражение
ref-1
Правило
Базовый
Если ссылка является локальной, то она должна указывать на вложенный экземпляр ресурса
reference.exists() implies (reference.startsWith('#').not() or (reference.substring(1).trace('url') in %rootResource.contained.id.trace('ids')) or (reference='#' and %rootResource!=%resource))
ref-2
Правило
Базовый
Если расширение отсутствует, то хотя бы один из элементов reference, identifier и display должен присутствовать
reference.exists() or identifier.exists() or display.exists() or extension.exists()
9.4.10.2 Тип целевого ресурса
В экземпляре ресурса элемент, имеющий тип данных Reference, всегда ссылается другой экземпляр фиксированного и известного типа. В принципе тип целевого ресурса может быть определен при разрешении ссылки с помощью анализа ссылочного содержания, но это может оказаться очень затратной операцией. Поэтому целесообразно тип указывать в ссылке, например:
subject: {
reference : http://someserver/some-path,
type : Patient
}
Если тип указан в ссылке, то он должен совпадать с типом ресурса, разрешенного по значению элемента reference. Элемент type имеет тип uri и должен представляться по отношению к базовому URL http://hl7.org/fhir/StructureDefinition/, то есть содержать просто имя типа ресурса, например Patient.
9.4.10.3 Литеральные ссылки
Экземпляры ресурсов идентифицируются и адресуются по их адресу URL. Элемент reference может содержать следующие варианты URL:
- абсолютный URL;
- относительный URL (дополняющий базовый URL сервера или, если экземпляр ресурса включен в контейнер Bundle, дополняющий значение базового URL, содержащегося в значении элемента Bundle.entry.fullUrl);
- фрагмент внутренней ссылки.
Литеральные ссылки могут содержать идентификатор версии экземпляра ресурса, например:
<target>
<reference value="Observation/12/_history/2"/>
</target>
9.4.10.4 Логические ссылки
Во многих случаях литеральный идентификатор ссылочного объекта недоступен или не существует, например:
а) ссылочный объект имеет национальный идентификатор, к примеру, ОГРН, ИНН или СНИЛС, но для доступа к этому объекту не используется REST API, описанный в настоящем документе;
б) сервер, хранящий содержание ссылочного объекта, недоступен.
В этих случаях в ссылке может быть указан логический идентификатор ссылочного объекта, присвоенный какой-либо внешней организацией или информационной системой. Например, ссылка на объект, содержащий информацию о пациенте, имеющим СНИЛС 12345678901, может иметь следующий вид:
<patient>
<identifier>
<system value="urn:oid:1.2.643.100.3" />
<value value=12345678901 />
</identifier>
</patient>
Компонент identifier ссылки типа Reference не обязан указывать на фактически существующий экземпляр ресурса REST, достаточно того, что ссылочный объект в принципе может быть представлен в виде такого экземпляра.
Поскольку ссылка по логическому идентификатору может оказаться не разрешаемой, то такие механизмы, как поиск по цепочке ссылок (chaining) или включение в результат поиска ссылочных экземпляров (include) со ссылками по логическому идентификатору не работают.
Если в ссылке указаны и литеральный, и логический идентификатор, то приоритет отдается литеральному идентификатору.
9.4.11 Тип данных xhtml
Тип данных xhtml используется для представления форматированного текста с упрощенной разметкой XHTML. Общие сведения о типе данных xhtml приведены в таблице 142. Этот тип данных не имеет собственных элементов.
Таблица 142
Общие сведения о типе данных xhtml
Имя
Описание
Связи с другими элементами модели
xhtml
Текст в формате упрощенного XHTML
Отношение генерализации от Reference к Element
Примечания
1 Упрощенный XHTML содержит только базовые элементы и атрибуты HTML, описанные в главах 7 - 11 и 15 стандарта HTML 4.0 (исключая раздел 4 главы 9), элементы <a> (с атрибутами name или href), изображения и атрибуты стилей.
2 Допускается использовать только ссылки на стили, указываемые в атрибутах class и id элементов XHTML. Разрешены стили, приведенные в таблице 138.
3 При сериализации в XML следует указывать пространство имен http://www.w3.org/1999/xhtml, например:
<div xmlns=http://www.w3.org/1999/xhtml>
<p> Пример системы кодирования</p>
<table>
<tr>
<td>
<b>Код</b>
</td>
<td>
<b>Значение</b>
</td>
<td>
<b>Описание</b>
</td>
</tr>
<tr>
<td>1/<td>
<td>мужской</td>
<td>мужской пол</td>
</tr>
<tr>
<td>2</td>
<td>женский</td>
<td>женский пол</td>
</tr>
</table>
</div>
9.5 Типы метаданных
9.5.1 Общие сведения
Типы метаданных используются для представления метаданных описаний типов ресурсов и типов данных. Диаграмма классов, описывающая эти типы данных, показана на рисунке 18.
Рисунок 18 - Типы метаданных
Перечень типов метаданных приведен в таблице 143.
Таблица 143
Типы метаданных
Имя
Описание
Пункт
Availability
Сведения о доступности
ContactDetail
Детальная контактная информация
Contributor
Сведения об участнике ресурса знаний
DataRequirement
Общие требования к данным ресурса знаний
Expression
Выражение на определенном языке, которое может использоваться для получения значения
ExtendedContactDetail
Детальная контактная информация лица или организации
MonetaryComponent
Компонент цены
ParameterDefinition
Определение параметра
RelatedArtifact
Сведения об артефакте, связанном с ресурсом знаний
TriggerDefinition
Описание события, инициирующего применение ресурса знаний
UsageContext
Контекст использования
VirtualServiceDetail
Идентификация службы дистанционной коммуникации
9.5.2 Тип данных Availability
Тип данных Availability используется для сведений о доступности физического места, службы или медицинского работника. Общие сведения о типе данных Availability приведены в таблице 144, а состав элементов - на рисунке 19 и в таблице 145.
Таблица 144
Общие сведения о типе данных Availability
Имя
Описание
Связи с другими элементами модели
Availability
Сведения о доступности
Отношение генерализации от Availability к DataType
Рисунок 19 - Тип данных Availability
Таблица 145
Состав элементов типа данных Availability
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
availableTime
Доступные дни и время
Element
0..*
availableTime.daysOfWeek
День недели. Допустимые значения: mon | tue | wed | thu | fri | sat | sun
code
0..*
availableTime.allDay
Доступно 24/7
boolean
0..1
availableTime.availableStartTime
Время начала доступности (игнорируется, если allDay=true)
time
0..1
availableTime.availableEndTime
Время завершения доступности (игнорируется, если allDay=true)
time
0..1
notAvailableTime
Недоступное время
Element
0..*
notAvailableTime.description
Причина, по которой это время недоступно
string
0..1
notAvailableTime.during
В течение этого интервала служба недоступна
Period
0..1
Ограничения описаны в таблице 146, привязки к наборам значений - в таблице 147.
Таблица 146
Ограничения типа данных Availability
Идентификатор
Вид
Путь
Описание
Выражение
av-1
Правило
Availability.availableTime
Если allDay = true, то элементы availableStartTime и availableEndTime должны отсутствовать
allDay.exists().not() or (allDay implies availableStartTime.exists().not() and availableEndTime.exists().not())
Таблица 147
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Availability.availableTime.daysOfWeek
http://hl7.org/fhir/Value-Set/days-of-week
Обязательная
Дни недели
9.5.3 Тип данных ContactDetail
Тип данных ContactDetail используется для представления списка контактных данных лица или организации. Общие сведения о типе данных ContactDetail приведены в таблице 148, а состав элементов - в таблице 149.
Таблица 148
Общие сведения о типе данных ContactDetail
Имя
Описание
Связи с другими элементами модели
ContactDetail
Детальная контактная информация
Отношение генерализации от ContactDetail к DataType
Таблица 149
Состав элементов типа данных ContactDetail
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
name
Ф.И.О. лица или наименование организации
string
0..1
telecom
Контактный телекоммуникационный адрес лица или организации
ContactPoint
0..*
9.5.4 Тип данных Contributor
Тип данных Contributor используется для представления сведений об участнике ресурса знаний. Общие сведения о типе данных Contributor приведены в таблице 150, а состав элементов - в таблице 151.
Таблица 150
Общие сведения о типе данных Contributor
Имя
Описание
Связи с другими элементами модели
Contributor
Сведения об участнике ресурса знаний
Отношение генерализации от Contributor к DataType
Таблица 151
Состав элементов типа данных Contributor
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
type
Тип участника. Допустимые значения: author (автор) | editor (редактор) | reviewer (рецензент) | endorser (рекомендатель)
code
0..1
name
Именование физического лица или наименование организации, ответственной за вклад в ресурс знаний
string
1
contact
Контактная информация участника ресурса знаний
ContactDetail
0..*
9.5.5 Тип данных DataRequirement
Тип данных DataRequirement определяет общие требования к данным ресурса знаний. Общие сведения о типе данных DataRequirement приведены в таблице 152, а состав элементов - на рисунке 20 и в таблице 153.
Таблица 152
Общие сведения о типе данных DataRequirement
Имя
Описание
Связи с другими элементами модели
DataRequirement
Общие требования к данным ресурса знаний
Отношение генерализации от DataRequirement к DataType
Рисунок 20 - Тип данных DataRequirement
Таблица 153
Состав элементов типа данных DataRequirement
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
type
Тип требуемых данных
code
1
profile
Идентификация профиля требуемых данных
canonical
0..1
subject[x]
Объект данных (тип ресурса со сведениями об участнике)
*
0..1
mustSupport
Указывает специфичные структурные элементы, на которые ссылается модуль знаний
string
0..*
codeFilter
Ожидаемые коды
Element
0..*
codeFilter.path
Путь к кодированному элементу, используемому в фильтре
string
0..1
codeFilter.searchParam
Параметр поиска по кодированному значению (типа token)
string
0..1
codeFilter.valueSet
Набор допустимых значений, которые могут быть указаны в фильтре
canonical
0..*
codeFilter.code
Ожидаемые коды
Coding
0..*
dateFilter
Ожидаемые даты/интервалы дат/длительность
Element
0..*
dateFilter.path
Путь к элементу, содержащему дату, интервал дат или длительность, используемому в фильтре
string
0..1
dateFilter.searchParam
Параметр поиска по значению даты, интервалу дат или длительности
string
0..1
dateFilter.value[x]
Значение фильтра. Допустимые типы данных: dateTime | Period | Duration
*
0..1
valueFilter
Ожидаемые значения
Element
0..*
valueFilter.path
Путь к элементу, используемому в фильтре
string
0..1
valueFilter.searchParam
Параметр поиска
string
0..1
valueFilter.comparator
Оператор сравнения eq (равно) | gt (больше) | lt (меньше) | ge (больше или равно) | le (меньше или равно) | sa (начинается после) | eb (завершается до)
code
0..1
valueFilter.value[x]
Значение периода, даты или длительности. Допустимые типы данных: dateTime | Period | Duration
*
0..1
limit
Число результатов
positiveInt
0..1
sort
Сортировка результатов
Element
0..*
sort.path
Путь к сортируемому элементу
string
0..1
sort.direction
Направление сортировки: ascending (по возрастанию) | descending (по убыванию)
code
0..1
Ограничения описаны в таблице 154, привязки к наборам значений - в таблице 155.
Таблица 154
Ограничения типа данных DataRequirement
Идентификатор
Вид
Путь
Описание
Выражение
drq-1
Правило
DataRequirement.code-Filter
Должны быть указаны или путь path, или параметр поиска searchParam, но не оба вместе
path.exists() xor searchParam.exists()
drq-2
Правило
DataRequirement.date-Filter
Должны быть указаны или путь path, или параметр поиска searchParam, но не оба вместе
path.exists() xor searchParam.exists
Таблица 155
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
DataRequirement
http://hl7.org/fhir/ValueSet/fhir-types
Обязательная
Все типы данных и типы ресурсов
DataRequirement.subject[x]
http://hl7.org/fhir/ValueSet/participant-resource-types
Расширяемая
Типы ресурсов, содержащих сведения об участниках
DataRequirement.valueFilter.comparator
http://hl7.org/fhir/ValueSet/value-filter-comparator
Обязательная
Операторы сравнения
DataRequirement.sort.direction
http://hl7.org/fhir/ValueSet/sort-direction
Обязательная
Направления сортировки
9.5.6 Тип данных Expression
Тип данных Expression описывает выражение на определенном языке (идентифицируемом типом среды MIME), которое может использоваться для получения значения. Общие сведения о типе данных Expression приведены в таблице 156, а состав элементов - в таблице 157.
Таблица 156
Общие сведения о типе данных Expression
Имя
Описание
Связи с другими элементами модели
Expression
Выражение на определенном языке, которое может использоваться для получения значения
Отношение генерализации от Expression к DataType
Таблица 157
Состав элементов типа данных Expression
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
description
Человеко-читаемое описание выражения
string
0..1
name
Имя, присвоенное выражению для последующих ссылок
code
0..1
language
Идентификация языка выражения
code
0..1
expression
Выражение на указанном языке
string
0..1
reference
Ссылка на определение выражения
uri
0..1
Ограничения описаны в таблице 158, привязки к наборам значений - в таблице 159.
Таблица 158
Ограничения типа данных Expression
Идентификатор
Вид
Путь
Описание
Выражение
exp-1
Правило
Базовый
Должен быть указан хотя бы один из элементов expression и reference
expression.exists() or reference.exists()
exp-2
Правило
Базовый
Значение имени name должно быть валидным для большинства языков программирования
name.hasValue() implies name.matches('[A-Za-z][A-Za-z0-9\\_]{0,63}')
Таблица 159
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Expression.language
http://hl7.org/fhir/ValueSet/expression-language
Расширяемая
Коды, описанные в таблице 160
Таблица 160
Наиболее широко используемые коды языков программирования
Код
Значение
Определение
text/cql
CQL
Язык Clinical Quality Language
text/fhirpath
FHIRPath
Язык FHIRPath
text/x-fhir-query
FHIR Query
Синтаксис HTTP-запросов FHIR (обычно не включая базовый URL)
text/cql-identifier
CQL Identifier
Идентификатор выражения на языке Clinical Quality Language, обычно имя определения верхнего уровня
text/cql-expression
CQL Expression
Выражение на языке Clinical Quality Language
9.5.7 Тип данных ExtendedContactDetail
Тип данных ExtendedContactDetail описывает детальную контактную информацию лица или организации. Общие сведения о типе данных ExtendedContactDetail приведены в таблице 161, а состав элементов - в таблице 162.
Таблица 161
Общие сведения о типе данных ExtendedContactDetail
Имя
Описание
Связи с другими элементами модели
Extended-ContactDetail
Детальная контактная информация лица или организации
Отношение генерализации от ExtendedContactDetail к DataType
Таблица 162
Состав элементов типа данных ExtendedContactDetail
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
purpose
Цель контакта
CodeableConcept
0..1
name
Именование контактного лица
HumanName
0..1
telecom
Контактный телекоммуникационный адрес лица или организации
ContactPoint
0..*
address
Контактный адрес
Address
0..1
organization
Ссылка на организацию, отвечающую за содержание контактной информации
Reference
0..1
period
Срок действия контактной информации
Period
0..1
Привязки к наборам значений описаны в таблице 163.
Таблица 163
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
ExtendedContact-Detail.purpose
http://terminology.hl7.org/ValueSet/contactentity-type
Предпочтительная
Цель контакта с лицом или организацией
9.5.8 Тип данных MonetaryComponent
Тип данных MonetaryComponent описывает компонент цены, например, скидка, налог, вычет. Общие сведения о типе данных MonetaryComponent приведены в таблице 164, а состав элементов - в таблице 165.
Таблица 164
Общие сведения о типе данных MonetaryComponent
Имя
Описание
Связи с другими элементами модели
MonetaryComponent
Компонент цены
Отношение генерализации от MonetaryComponent к DataType
Таблица 165
Состав элементов типа данных MonetaryComponent
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
type
Компонент цены. Допустимые значения: base (базовая цена) | surcharge (надбавка) | deduction (вычет) | discount (скидка) | tax (налог) | informational (сумма для информации, в цену не входит)
code
1
code
Подкатегория компонента цены, например, налог на добавленную стоимость
CodeableConcept
0..1
factor
Множитель
decimal
0..1
amount
Сумма (до умножения на множитель)
Money
0..1
Привязки к наборам значений приведены в таблице 166.
Таблица 166
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
MonetaryComponent.type
http://hl7.org/fhir/ValueSet/price-component-type
Обязательная
Тип компонента цены
9.5.9 Тип данных ParameterDefinition
Тип данных ParameterDefinition используется для описания входных или выходных параметров. Общие сведения о типе данных ParameterDefinition приведены в таблице 167, а состав элементов - в таблице 168.
Таблица 167
Общие сведения о типе данных ParameterDefinition
Имя
Описание
Связи с другими элементами модели
ParameterDefinition
Определение параметра
Отношение генерализации от ParameterDefinition к DataType
Таблица 168
Состав элементов типа данных ParameterDefinition
Имя
Описание
Тип
Кратность
name
Имя параметра. Используется для доступа к значению параметра
code
0..1
use
Вид параметра - in (входной) или out (выходной)
code
1
min
Минимальная кратность
integer
0..1
max
Максимальная кратность - число или * (не ограничена)
string
0..1
documentation
Краткое описание параметра
string
0..1
type
Тип значения параметра. Может принимать значение имени простого типа данных, комплексного типа данных, ресурса или any - любой тип
code
1
profile
Идентификация профиля
canonical
0..1
9.5.10 Тип данных RelatedArtifact
Тип данных RelatedArtifact описывает сведения о различных артефактах, связанных с ресурсами знаний, например, о версиях документов, библиографии и т.д. Общие сведения о типе данных RelatedArtifact приведены в таблице 169, а состав элементов - в таблице 170.
Таблица 169
Общие сведения о типе данных RelatedArtifact
Имя
Описание
Связи с другими элементами модели
RelatedArtifact
Сведения об артефакте, связанном с ресурсом знаний
Отношение генерализации от RelatedArtifact к DataType
Таблица 170
Состав элементов типа данных RelatedArtifact
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
type
Тип связи с артефактом
code
1
classifier
Дополнительный классификатор
Codeable-Concept
0..*
label
Краткое название
string
0..1
display
Краткое описание связанного артефакта
string
0..1
citation
Библиографическая ссылка на артефакт
markdown
0..1
document
Документ, на который дается ссылка
Attachment
0..1
resource
Ссылка на артефакт, являющийся экземпляром ресурса, имеющего канонический идентификатор
canonical
0..1
resourceReference
Ссылка на артефакт, являющийся экземпляром ресурса, не по каноническому идентификатору
Reference
0..1
publicationStatus
Статус публикации ссылочного артефакта. Допустимые значения: draft (проект) | active (действует) | retired (действие прекращено) | unknown (неизвестен)
code
0..1
publicationDate
Дата публикации ссылочного артефакта
date
0..1
Привязки к наборам значений описаны в таблице 171.
Таблица 171
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
RelatedArtifact.type
http://hl7.org/fhir/ValueSet/related-artifact-type
Обязательная
Тип связи с артефактом
RelatedArtifact.classifier
http://hl7.org/fhir/ValueSet/citation-artifact-classifier
Пример
Классификатор библиографии
RelatedArtifact.publication-Status
http://hl7.org/fhir/ValueSet/publication-status
Обязательная
Статус жизненного цикла артефакта
9.5.11 Тип данных TriggerDefinition
Тип данных TriggerDefinition описывает события, инициирующие применение ресурса знаний. Общие сведения о типе данных TriggerDefinition приведены в таблице 172, а состав элементов - в таблице 173.
Таблица 172
Общие сведения о типе данных TriggerDefinition
Имя
Описание
Связи с другими элементами модели
Trigger-Definition
Описание события, инициирующего применение ресурса знаний. Выделяются три типа событий:
именованное событие;
расписание;
изменение данных или доступ к ним.
Для именованного события указывается имя, интерпретация которого оставляется на усмотрение среды вычислений.
Событие может инициироваться по расписанию, в том числе в фиксированный момент времени или периодически.
Событие может инициироваться изменением данных или доступом к ним. Уточнение наступления события может быть указано в элементе condition
Отношение генерализации от TriggerDefinition к DataType
Таблица 173
Состав элементов типа данных TriggerDefinition
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
type
Тип триггера. Допустимые значения: named-event (именованное событие) | periodic (расписание) | data-changed (любое изменение данных, включая добавление, модификацию, удаление) | data-added (добавление данных) | data-modified (модификация данных) | data-removed (удаление данных) | data-accessed (доступ к данным) | data-access-ended (завершение доступа к данным)
code
1
name
Идентификатор события - имя или URI
string
0..1
code
Код, идентифицирующий событие
CodeableConcept
0..1
subscription-Topic
Ссылка на экземпляр ресурса SubscriptionTopic, содержащий определение события
canonical
0..1
timing[x]
Расписание события (для периодического триггера)
0..1
data
Данные инициирующие событие (для триггера, срабатывающего по данным)
DataRequirement
0..*
Если указано несколько экземпляров элемента data, для срабатывания триггера должны быть выполнены все указанные в них условия
condition
Логическое выражение, формально описывающее условие срабатывания триггера
Expression
0..1
Ограничения описаны в таблице 174, привязки к наборам значений - в таблице 175.
Таблица 174
Ограничения типа данных TriggerDefinition
Идентификатор
Вид
Путь
Описание
Выражение
trd-1
Правило
Базовый
Должны быть указаны или расписание timing, или инициирующие данные data, но не оба вместе
data.empty() or timing.empty()
trd-2
Правило
Базовый
Элемент condition может быть указан только при наличии элемента data
condition.exists() implies data.exists()
trd-3
Правило
Базовый
Для именованного события должен быть указан элемент name, для расписания - timing, для инициирующих данных - data
(type = 'named-event' implies name.exists()) and (type = 'periodic' implies timing.exists()) and (type.startsWith('data-') implies data.exists())
Таблица 175
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
TriggerDefinition.type
http://hl7.org/fhir/ValueSet/trigger-type
Обязательная
Тип триггера
9.5.12 Тип данных UsageContext
Тип данных UsageContext используется для представления контекста, в котором используется ресурс. Примерами типов контекста служат пол, возраст, категория пользователя и т.д. Общие сведения о типе данных UsageContext приведены в таблице 176, а состав элементов - в таблице 177.
Таблица 176
Общие сведения о типе данных UsageContext
Имя
Описание
Связи с другими элементами модели
UsageContext
Описание контекста использования
Отношение генерализации от UsageContext к DataType
Таблица 177
Состав элементов типа данных UsageContext
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
code
Тип контекста использования
Coding
1
value[x]
Значение контекста. Допустимые значения: valueCodeableConcept | valueQuantity | valueRange | valueReference
*
1
9.5.13 Тип данных VirtualServiceDetail
Тип данных VirtualServiceDetail используется для идентификации службы дистанционной коммуникации. Общие сведения о типе данных VirtualServiceDetail приведены в таблице 178, а состав элементов - в таблице 179.
Таблица 178
Общие сведения о типе данных VirtualServiceDetail
Имя
Описание
Связи с другими элементами модели
VirtualServiceDetail
Идентификация службы дистанционной коммуникации
Отношение генерализации от VirtualServiceDetail к DataType
Таблица 179
Состав элементов типа данных VirtualServiceDetail
Имя
Описание
Тип
Кратность
Унаследованные элементы
id
Уникальный идентификатор для ссылок между элементами
string
0..1
extension
Дополнительное содержание
Extension
0..*
Собственные элементы
channelType
Тип службы дистанционной коммуникации
Coding
0..1
address[x]
Контактный адрес или номер. Допустимые значения: addressUrl | addressString | addressContactPoint | addressExtendedContactDetail
*
0..1
additionalInfo
Адрес URL дополнительной информации о подключении
url
0..*
maxParticipants
Максимальное число участников сеанса
positiveInt
sessionKey
Контактный адрес или номер. Допустимые значения: addressUrl | addressString | addressContactPoint | addressExtendedContactDetail
string
0..1
Привязки к наборам значений описаны в таблице 180.
Таблица 180
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
VirtualServiceDetail.channelType
http://hl7.org/fhir/ValueSet/virtual-service-type
Пример
Тип службы дистанционной коммуникации
10 Ресурсы REST
10.1 Общие сведения
10.1.1 Принципы определения ресурсов REST
Ресурсы REST описывают элементы данных, ограничения и связи "объектов деятельности", наиболее релевантных для здравоохранения, например, "пациент", "медицинский работник", "процедура", "направление на исследование", "результат исследования".
Каждый тип ресурса описывается отдельной информационной моделью, имеющей представление в форме диаграммы классов UML и табличные представления. Все эти модели используют компактный набор типов данных, описанный в разделе 9.
При разработке типов ресурсов используются следующие архитектурные принципы:
а) повторное использование и композиция - типы ресурсов создаются исходя из правила 80/20 - акцент делается на 20% требований, удовлетворяющим 80% интероперабельности. Остальные 20% интероперабельности могут быть обеспечены с помощью механизмов расширения и профилирования. Типы ресурсов обычно содержат ссылки на другие типы ресурсов, что улучшает возможности повторного использования и позволяет строить из атомарных типов ресурсов более сложные структуры, например документы или сообщения;
б) масштабируемость - спецификация [22] ориентирована на архитектурный стиль REST, чтобы все транзакции обмена данными могли осуществляться без сохранения состояния, что исключает необходимость поддержки сложных сеансов между серверами и тем самым способствует возможности горизонтального масштабирования;
в) производительность - экземпляры ресурсов могут передаваться по вычислительной сети с использованием оптимизированных форматов, что может способствовать повышению производительности выполнения комплексных транзакций;
г) понятность - описания типов ресурсов должны быть равным образом понятными техническим экспертам и нетехническим сотрудникам;
д) обеспечение точности данных - в спецификации [22] предусмотрены механизмы привязки кодируемых данных к наборам значений и валидации этих данных. Кроме того, предусмотрены механизмы валидации экземпляров ресурсов на соответствие схемам XML или JSON, а также ряду бизнес-правил. Это способствует обеспечению точности данных и семантической интероперабельности;
е) простота внедрения - для внедрения спецификации пригодны стандартные решения, в том числе приложения с открытым кодом, например [24].
Принципы, положенные в основу спецификации [22], позволяют эффективно применять ее для построения микросервисных решений, а также для решений, обеспечивающих информационное взаимодействие с различными гаджетами и ПМП. В то же время она может использоваться и для традиционного обмена сообщениями. При этом вместо сложных и ограниченных синтаксисов запросов, предложенных в стандартах HL7 Version 2 и Version 3, может использоваться стандартный синтаксис запросов HTTP.
Спецификация [22] предоставляется по лицензии Creative Commons "No Rights Reserved", то есть без сохранения прав. Но при этом на использование торговых марок и накладываются определенные ограничения.
10.1.2 Расширения
Возможность расширений типов данных и типов ресурсов является существенной частью парадигмы спецификации [22]. Каждый элемент экземпляра ресурса может иметь дочерние элементы расширения (extension), представляющие дополнительную информацию, не являющиеся частью базового определения типа ресурса. Приложения не должны отклонять экземпляр ресурса только на основании того, что он содержит расширения, однако могут отклонить его на основании содержания конкретного расширения.
Использование расширений позволяет сохранять компактность базисной модели, используемой для определения новых ресурсов. Спецификация [22] содержит реестр расширений, которые могут представлять интерес для разработчиков информационных систем.
10.1.3 Производные типы
Тип ресурса может производиться от другого типа ресурса следующими двумя способами:
а) специализация (specialization) базового типа ресурса, при которой вновь определяемый тип ресурса производится от базового объекта с помощью наследования его свойств и добавления к ним новых свойств;
б) ограничение (constraint) базового типа ресурса, при котором вновь определяемый тип ресурса производится от базового объекта с помощью ограничения кратности свойств базового объекта (в том числе удаления свойства), наложения дополнительных ограничений (к уже имеющимся) и при необходимости расширения уже существующих свойств и объектов.
Ограничение базового типа ресурса называется профилированием, а вновь полученный объект - профилем базового объекта.
В качестве базового ресурса можно выбрать ранее описанный профиль. Таким образом может быть создана иерархия профилей.
10.1.4 Ссылки между экземплярами ресурсов
Экземпляр ресурса может включать в себя другой экземпляр ресурса (или профиля) по ссылке или по значению. Например, тип ресурса Person (общие демографические данные гражданина) имеет свойство managingOrganization (организация - владелец данного экземпляра сведений о физическом лице), которое может содержать ссылку на экземпляр ресурса Organization (общие сведения об организации). Сослаться на часть свойств экземпляра ресурса нельзя, но можно описать профиль ссылочного объекта, содержащий только требуемые свойства.
10.1.5 Профилирование
Типы ресурсов, разработанные с помощью специализации базовых объектов, являются рамочными. Многие свойства этих объектов, например, унаследованные от базовых объектов, являются необязательными. Поэтому при сопоставлении вновь разработанного типа ресурса со сведениями об объекте учета на эти свойства должны быть наложены дополнительные ограничения, то есть одному типу объекта учета обычно соответствует не сам такой тип ресурса, а его профиль. Например, для типа ресурса Observation (результат исследования) определены профили, специфичные для конкретных исследований: observation-resprate (частота дыхания), observation-oxygensat (оксигенация) и другие.
Сведениям об объекте учета, имеющим простую структуру, целесообразно сопоставить один тип ресурса и один его профиль. Сведениям об объекте учета, имеющим более сложную структуру, может быть сопоставлено несколько типов ресурсов (каждый со своим профилем) или один тип ресурса с несколькими профилями. Для описания таких сведений в спецификации [22] предусмотрены так называемые руководства по реализации (implementation guide), в том числе руководство по реализации ресурсов REST для персональных медицинских приборов [32].
10.1.6 Описание типа ресурса
Описание типа ресурса содержит следующие разделы:
а) область применения и использования;
б) описание структуры ресурса (в виде диаграммы классов UML и иерархической таблицы);
в) ограничения (правила форматно-логического контроля);
г) комментарии к особенностям идентификации и связям;
д) привязки к наборам значений;
е) параметры поиска.
В зависимости от особенностей конкретного ресурса некоторые разделы могут быть опущены, а другие - добавлены.
Иерархическая таблица, описывающая структуру ресурса, имеет формат, приведенный в таблице 4. Таблица ограничений имеет формат, приведенный в таблице 5. Таблица привязок к наборам значений имеет формат, приведенный в таблице 6. Таблица критериев поиска имеет формат, приведенный в таблице 7.
10.1.7 Категории ресурсов
Можно выделить следующие категории ресурсов:
а) базисные ресурсы, на основе которых создаются определения остальных ресурсов;
б) ресурсы общего назначения, являющиеся компонентами инфраструктуры информационного взаимодействия;
в) предметные ресурсы, используемые в конкретных предметных областях.
Базисные ресурсы описаны в пункте 10.2, ресурсы общего назначения - в пункте 10.3, предметные ресурсы, используемые для взаимодействия с хранилищем результатов измерений - в разделе 11.
10.2 Базисные ресурсы
10.2.1 Общие сведения
Базисные ресурсы перечислены в таблице 181. Они представляют собой абстрактные классы и не имеют собственных экземпляров.
Таблица 181
Базисные ресурсы
Имя
Описание
Пункт
Resource
Общие элементы всех ресурсов
DomainResource
Дополнительные элементы, общие для большинства ресурсов
10.2.2 Ресурс Resource
10.2.2.1 Область применения и использования
Базисный ресурс Resource является родителем каждого конкретного ресурса. С помощью унаследованных от него необязательных элементов можно задать идентификатор экземпляра ресурса, ссылку на его метаданные, ссылку на правила, которым надо следовать при создании экземпляра, человеческий язык, на котором представлено содержание экземпляра ресурса.
10.2.2.2 Структура ресурса
Состав элементов ресурса Resource представлен на рисунке 21 и в таблице 182.
Рисунок 21 - Ресурс Resource
Таблица 182
Состав элементов ресурса Resource
Имя
Описание
Тип
Кратность
id
Логический идентификатор экземпляра ресурса, используемый в URL этого экземпляра. Будучи присвоенным, это значение никогда не изменяется
id
0..1
meta
Метаданные экземпляра ресурса. Их содержание обрабатывается инфраструктурой. Изменение метаданных ресурса не обязательно влечет за собой изменение экземпляра ресурса
Meta
0..1
implicitRules
Ссылка на набор правил, которым надо следовать при создании экземпляра ресурса и которые должны учитываться при обработке его содержания. Нередко это ссылка на руководство по реализации, определяющее специфичные правила наряду с другими профилями, и т.д.
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
10.2.2.3 Привязки к наборам значений
Привязки к наборам значений перечислены в таблице 183.
Таблица 183
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Resource.language
http://hl7.org/fhir/ValueSet/all-languages
Обязательная
Все допустимые коды языка из BCP-47 (см. http://tools.ietf.org/html/bcp47)
http://hl7.org/fhir/ValueSet/languages
Рекомендованная
Наиболее распространенные коды языка
10.2.2.4 Логический идентификатор id и другие идентификаторы экземпляров ресурсов
Экземпляр ресурса может быть идентифицирован двумя разными способами:
а) по адресу URL местонахождения экземпляра (основанному на "логическом" идентификаторе id). Этот адрес изменяется при перемещении экземпляра из одного места в другое;
б) по некоторому "внутренне присущему" идентификатору ("бизнес-идентификатору" или "каноническому URL"), являющемуся значением одного из элементов ресурса и остающемуся неизменным при перемещении экземпляра из одного места в другое.
Каждый ресурс наследует элемент id (логический идентификатор) от ресурса Resource. При создании экземпляра ресурса сервер присваивает этому идентификатору определенное значение, уникальное среди всех экземпляров ресурса данного типа. Пока экземпляр хранится на этом сервере, значение идентификатора id не изменяется.
Местонахождение экземпляра задается абсолютным адресом URL, сконструированным из базового URL, имени типа ресурса и логического идентификатора, например: http://test.fhir.org/r5/rest/Patient/123 (где 123 - логический идентификатор экземпляра ресурса Patient). Перекрестные ссылки между экземплярами ресурсов используют их местонахождение в форме абсолютного или относительного URL.
Бизнес-идентификаторы обычно позволяют связать содержание экземпляра ресурса с объектом "реального мира". Большинство типов ресурсов имеет элемент identifier типа Identifier, предназначенный для хранения бизнес-идентификаторов.
Некоторые типы ресурсов имеют элемент url, предназначенный для хранения "канонического URL", идентифицирующий экземпляр ресурса данного типа. Это специальная разновидность бизнес-идентификатора. Элемент url имеет тип uri и наряду с URL может содержать URI, но назван так по историческим причинам. Канонический идентификатор служит неизменным логическим идентификатором экземпляра ресурса.
10.2.2.5 Правила implicitRules
Элемент implicitRules содержит ссылку на набор правил, которым надо следовать при создании экземпляра ресурса и которые должны учитываться при обработке его содержания; например, это может быть ссылка на руководство по реализации, определяющее специфичные правила наряду с другими профилями, и т.д.
10.2.2.6 Язык language
Элемент language указывает основной человеческий язык, на котором представлено содержание ресурса. Его значение представляет собой код из BCP-47 [30]. Этот же код по возможности должен быть указан в повествовательном содержании экземпляра ресурса, представленном элементом text, наследуемым от ресурса DomainResource. Поскольку код языка из BCP-47 очень сложен, для элемента language рекомендована привязка к набору значений http://hl7.org/fhir/ValueSet/languages, охватывающему наиболее распространенные коды языка.
10.2.2.7 Метаданные ресурса meta
Каждый тип ресурса наследует от ресурса Resource элемент метаданных meta типа Meta, значения которого имеют служебный характер и могут использоваться для ограничения доступа к экземпляру ресурса, форматно-логического контроля его содержания, обеспечения версионности, а также для других целей, в том числе определяемых пользователем. Компоненты типа данных Meta описаны в пункте 9.4.8.
10.2.3 Ресурс DomainResource
10.2.3.1 Область применения и использования
Базисный ресурс DomainResource является детализацией абстрактного ресурса Resource и в свою очередь является абстрактным. Он описывает расширения содержания экземпляра ресурса и вложенные в него экземпляры ресурсов.
10.2.3.2 Структура ресурса
Состав элементов ресурса DomainResource представлен на рисунке 22 и в таблице 184.
Рисунок 22 - Ресурс DomainResource
Таблица 184
Состав элементов ресурса DomainResource
Имя
Описание
Тип
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Собственные элементы
text
Человеко-читаемый текст, содержащий сводные сведения о содержании экземпляра ресурса, который может использоваться для представления содержания человеку. Он не обязан содержать все структурированные данные, но должен содержать сведения, достаточные для получения представления о содержании ресурса. В определении ресурса может быть указано, какое содержание следует представить в элементе text
Narrative
0..1
contained
Экземпляры ресурсов, не существующие отдельно от данного экземпляра ресурса, который их содержит - они не могут быть идентифицированы отдельно от него и не могут самостоятельно входить в транзакции
Resource
0..*
extension
Может использоваться для представления дополнительной информации, не являющейся частью базового определения ресурса. Существует строгий набор правил по определению и использованию расширений, обеспечивающий их безопасное и управляемое применение. Хотя каждый разработчик и может определить расширение, существует ряд требований, которых он должен придерживаться при определении расширения
Extension
0..*
modifierExtension
Может использоваться для представления дополнительной информации, не являющейся частью базового определения ресурса, но модифицирующей семантику этого элемента и/или его потомков. Обычно модификация состоит в отрицании или уточнении. Существует строгий набор правил по определению и использованию расширений, обеспечивающий их безопасное и управляемое применение. Хотя каждый разработчик и может определить расширение, существует ряд требований, которых он должен придерживаться при определении расширения. Требуется, чтобы приложения, обрабатывающие экземпляр ресурса, проверяли наличие модифицирующих расширений. Модифицирующие расширения не должны изменять семантику любого элемента, унаследованного от класса Resource или DomainResource (в том числе семантику самого расширения modifierExtension)
Extension
0..*
10.2.3.3 Ограничения ресурса DomainResource
Ограничения ресурса DomainResource описаны в таблице 185.
Таблица 185
Ограничения ресурса DomainResource
Идентификатор
Вид
Путь
Описание
Выражение
dom-2
Правило
Базовый
Допускается только один уровень вложения экземпляров ресурсов
contained.contained.empty()
dom-3
Правило
Базовый
Должна быть ссылка на вложенный экземпляр ресурса в содержащем его экземпляре или ссылка во вложенном экземпляре на содержащий его экземпляр
contained.where((('#'+id in (%resource.descendants().reference | %resource.descendants().ofType(canonical) | %resource.descendants().ofType(uri) | %resource.descendants().ofType(url))) or descendants().where(reference = '#').exists() or descendants().where(ofType(canonical) = '#').exists() or descendants().where(ofType(canonical) = '#').exists()).not()).trace('unmatched', id).empty()
dom-4
Правило
Базовый
Во вложенном экземпляре ресурса должны отсутствовать элементы meta.versionId и meta.lastUpdated
contained.meta.versionId.empty() and contained.meta.lastUpdated.empty()
dom-5
Правило
Базовый
Во вложенном экземпляре ресурса должен отсутствовать элемент meta.security
contained.meta.security.empty()
dom-6
Рекомендация
Базовый
У экземпляра ресурса должно быть повествовательное содержание
text.'div'.exists()
10.2.3.4 Использование вложенных ресурсов
Вложенный экземпляр ресурса существует только в содержащем его экземпляре. Обычно вложенные экземпляры используются, если у них отсутствует уникальный идентификатор. Например, в тонометре, рассчитанном на двух пациентов, в качестве идентификатора пациента используется номер группы памяти. Тогда в экземпляр ресурса Observation, содержащий результат измерения, можно вложить экземпляр ресурса Patient, в котором в качестве идентификатора указан номер группы памяти.
10.2.3.5 Параметры поиска
Параметры поиска, общие для всех потомков ресурса DomainResource, описаны в таблице 186.
Таблица 186
Параметры поиска, общие для потомков ресурса DomainResource
Имя
Тип
Описание
Выражение
_text
special
Поиск экземпляра ресурса по повествовательному содержанию
-
10.3 Ресурсы общего назначения
10.3.1 Общие сведения
Ресурсы общего назначения, которые могут быть использованы в запросах REST API и в ответах на эти запросы, перечислены в таблице 187.
Таблица 187
Ресурсы общего назначения
Имя
Описание
Пункт
Bundle
Контейнер экземпляров ресурсов
MessageHeader
Заголовок сообщения
OperationOutcome
Результат операции
Parameters
Параметры операции
Subscription
Подписка
SubscriptionStatus
Статус подписки
SubscriptionTopic
Тема подписки
10.3.2 Ресурс Bundle (контейнер экземпляров ресурсов)
10.3.2.1 Область применения и использования
Ресурс Bundle служит для сборки экземпляров ресурсов в единый контейнер. Такие контейнеры используются для разных целей, в том числе:
а) возвращение коллекции экземпляров ресурсов, отобранной в соответствии с критериями поиска;
б) возвращение коллекции версий экземпляра ресурса для целей анализа истории изменений;
в) передача нескольких экземпляров ресурсов в одном сообщении;
г) группировка экземпляров ресурсов в самодостаточный комплекс, обладающий семантической целостностью, например медицинский документ;
д) создание, изменение и удаление нескольких экземпляров ресурсов в одной транзакции;
е) передача уведомлений о событиях по теме подписки;
ж) сохранение коллекции экземпляров ресурсов.
10.3.2.2 Структура ресурса
Ресурс Bundle является детализацией абстрактного ресурса Resource. Состав элементов ресурса Bundle представлен на рисунке 23 и в таблице 188.
Рисунок 23 - Ресурс Bundle
Таблица 188
Состав элементов ресурса Bundle
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Собственные элементы
identifier
Постоянный идентификатор контейнера, не изменяемый при его передаче от одного субъекта к другому
Identifier
0..1
type
Указывает назначение контейнера, то есть предполагаемое использование. Допустимые значения: document (документ) | message (сообщение) | transaction (транзакция) | transaction-response (результат транзакции) | batch (пакет)| batch-response (ответный пакет) | history (история) | searchset (результат поиска) | collection (коллекция) | subscription-notification (уведомление подписки)
code
1
timestamp
Штамп даты и времени создания контейнера
instant
0..1
total
Общее число совпадений
unsignedInt
0..1
link
Связь, относящаяся ко всему контейнеру
BackboneElement
0..*
link.relation
Имя, детализирующее функциональное назначение данной связи. Список значений берется из [33] (www.iana.org/assignments/link-www.iana.org/assignments/link-relations/link-relations.xhtml#link-relations-1)
string
1
link.url
Адрес детальной информации о данной связи
uri
1
entry
Запись, содержащая экземпляр ресурса или информацию
BackboneElement
0..*
entry.link
Связь, относящаяся к данной записи
BackboneElement
0..*
entry.link.relation
Имя, детализирующее функциональное назначение данной связи. Список значений берется из [33] (www.iana.org/assignments/link-relations/link-relations.xhtml#link-relations-1)
string
1
entry.link.url
Адрес детальной информации о данной связи
uri
1
entry.fullUrl
Абсолютный URL или URN, идентифицирующий экземпляр ресурса
uri
0..1
entry. resource
Экземпляр ресурса, содержащийся в контейнере. Его назначение или смысл определяются типом контейнера Bundle.type
Resource
0..1
entry. search
Информация о поиске, в результате которого сформирована данная запись
BackboneElement
0..1
entry. search. mode
Причина включения записи в коллекцию результатов. Допустимые значения: match (соответствует параметрам поиска) | include (включена в соответствии с параметрами _include или _revinclude) | outcome (предназначена для передачи информации либо предупреждения о процессе поиска)
code
0..1
entry. search. score
Оценка степени совпадения с параметрами поиска, поставленная сервером при поиске (между 0 и 1)
decimal
0..1
entry. request
В контейнере пакета или транзакции - запрос обработки. В контейнере истории - метод, использованный для обработки версии экземпляра ресурса
BackboneElement
0..1
entry. request. method
При инициировании транзакции или пакета здесь должен быть указан метод HTTP, выполняемый для этой записи. В контейнере истории здесь должен быть указан выполненный метод HTTP. Допустимые значения: GET | HEAD | POST | PUT | DELETE | PATCH
code
1
entry. request. url
Адрес URL относительно корня (адреса, по которому отправлен запрос)
uri
1
entry.request.ifNoneMatch
Если значения ETag совпадают, возвратить статус HTTP 304 Not Modified (не модифицировано)
string
0..1
entry.request.ifModified-Since
Выполнять метод HTTP, если дата последнего изменения хранящегося экземпляра ресурса больше или равна значению данного элемента
instant
0..1
entry.request.ifMatch
Выполнять этот метод, если значение элемента meta.versionId хранящегося экземпляра ресурса, представленное в форме ETag, совпадает со значением данного элемента
string
0..1
entry.request.ifNoneExist
Указывает, что информационный ресурс не выполняет метод создания, если указанный экземпляр ресурса уже существует. Это часть URL, представляющая запрос, следующая за знаком вопроса (не включая этот знак)
string
0..1
entry. response
Указывает результаты обработки соответствующей записи запроса (request) контейнера пакета или транзакции, на которую дается ответ, или результаты операции при возвращении истории
BackboneElement
0..1
entry.response.status
Код статуса, возвращенный при обработке данной записи. Статус должен начинаться с трехзначного кода HTTP code (например, 404) и может содержать стандартное описание HTTP этого кода
string
1
entry. response. location
Заголовок Location, созданный выполненным методом и заполняемый, если он возвращает Location
uri
0..1
entry. response. etag
Если метод создает версию экземпляра ресурса, здесь возвращается его тег ETag
string
0..1
entry. response. lastModified
Дата и время изменения экземпляра ресурса сервером
instant
0..1
entry. response. outcome
Экземпляр ресурса OperationOutcome, содержащий указания и предупреждения, появившиеся в результате обработки данной записи в пакете или транзакции
Resource
0..1
signature
Электронная подпись содержания контейнера
Signature
0..1
issues
Описание проблем формирования содержания контейнера и предупреждения, относящиеся к контейнеру в целом
Resource
0..1
10.3.2.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 189.
Таблица 189
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Bundle.type
http://hl7.org/fhir/ValueSet/bundle-type
Обязательная
Тип контейнера
Bundle.link.relation
http://hl7.org/fhir/ValueSet/iana-link-relations
Обязательная
Функциональное назначение связи, определенное в https://www.iana.org/assignments/link-relations/link-relations.xhtml#link-relations-1
Bundle.entry.search.mode
http://hl7.org/fhir/ValueSet/search-entry-mode
Обязательная
Причина включения записи в коллекцию результатов
Bundle.entry.request.method
http://hl7.org/fhir/ValueSet/http-verb
Обязательная
Метод HTTP
10.3.2.4 Ограничения ресурса Bundle
Ограничения ресурса Bundle приведены в таблице 190.
Таблица 190
Ограничения ресурса Bundle
Идентификатор
Вид
Путь
Описание
Выражение
bdl-1
Правило
Базовый
Указывать элемент total только при type = searchset или history
total.empty() or (type = 'searchset') or (type = 'history')
bdl-2
Правило
Базовый
Указывать элемент entry.search только при type = searchset
entry.search.empty() or (type = 'searchset')
bdl-5
Правило
Bundle. entry
Если элементы request и response отсутствуют, то запись должна содержать элемент resource
resource.exists() or request.exists() or response.exists()
bdl-7
Правило
Базовый
Значение fullUrl должно быть уникальным в контейнере, или записи entry с одинаковыми значениями fullUrl должны содержать элементы resource с разными значениями элементов meta.versionId (за исключением контейнеров истории)
(type = 'history') or entry.where(fullUrl.exists()).select(fullUrl&resource.meta.versionId).isDistinct()
bdl-8
Правило
Bundle. entry
Значение fullUrl не должно содержать компонент версии
fullUrl.contains('/_history/').not()
bdl-9
Правило
Базовый
Идентификатор документа identifier должен иметь компоненты system и value
type = 'document' implies (identifier.system.exists() and identifier.value.exists())
bdl-10
Правило
Базовый
Документ должен иметь дату
type = ment' implies (timestamp.hasValue())
bdl-11
Правило
Базовый
Первым ресурсом в контейнере документа должен быть Composition
type = 'document' implies entry.first().resource.is(Composition)
bdl-12
Правило
Базовый
Первым ресурсом в контейнере сообщения должен быть MessageHeader
type = 'message' implies entry.first().resource.is(MessageHeader)
bdl-13
Правило
Базовый
Первым ресурсом в контейнере уведомления подписки должен быть SubscriptionStatus
type = 'subscription-notification' implies entry.first().resource.is(SubscriptionStatus)
bdl-14
Правило
Базовый
Метод PATCH в контейнере истории не допустим
type = 'history' implies entry.request.method != 'PATCH'
bdl-15
Правило
Базовый
Если тип контейнера Bundle.type = transaction | transaction-response | batch | batch-response или Bundle.request.method = POST, то элемент Bundle.entry.fullUrl обязателен
type='transaction' or type = 'transaction-response' or type='batch' or type='batch-response' or entry.all(fullUrl.exists() or request.method='POST')
bdl-16
Правило
Базовый
Если элемент issue представлен экземпляром ресурса OperationOutcome, то элементы issue.severity этого экземпляра должны иметь значение information (информация) или warning (предупреждение)
issues.exists() implies (issues.issue.severity = 'information' or issues.issue.severity = 'warning')
bdl-17
Правило
Базовый
В контейнере документа элемент issues должен отсутствовать
type = 'document' implies issues.empty()
bdl-18
Правило
Базовый
В контейнере результата поиска должен присутствовать элемент link со значением отношения self
type = 'searchset' implies link.where(relation = 'self' and url.exists()).exists()
bdl-3a
Правило
Базовый
В контейнере документа, сообщения, результата поиски или коллекции все элементы entry должны содержать элемент resource, а элементы request и response в них должны отсутствовать
type in ('document' | 'message' | 'searchset' | 'collection') implies entry.all(resource.exists() and request.empty() and response.empty())
bdl-3b
Правило
Базовый
В контейнере истории все элементы entry должны содержать элементы request и response, а если элемент request.method имеет значение POST или PUT, то элемент entry должен содержать элемент resource
type = 'history' implies entry.all(request.exists() and response.exists() and ((request.method in ('POST' | 'PUT')) = resource.exists()))
bdl-3c
Правило
Базовый
В контейнере транзакции или пакета все элементы entry должны содержать элемент request, а если элемент request.method имеет значение POST, PUT или PATCH, то элемент entry должен содержать элемент resource
type in ('transaction' | 'batch') implies entry.all(request.method.exists() and ((request.method in ('POST' | 'PATCH' | 'PUT')) = resource.exists()))
bdl-3d
Правило
Базовый
В контейнере результата транзакции или ответного пакета все элементы entry должны содержать элемент response
type in ('transaction-response' | 'batch-response') implies entry.all(response.exists())
10.3.2.5 Использование контейнеров Bundle
Документ
Контейнер документа, в котором Bundle.type = document, состоит из записей entry, первая из которых содержит экземпляр ресурса Composition. Каждая запись entry должна содержать элемент resource (экземпляр ресурса).
Сообщение
Контейнер документа, в котором Bundle.type = message, состоит из записей entry, первая из которых содержит экземпляр ресурса MessageHeader. Каждая запись entry должна содержать элемент resource (экземпляр ресурса).
Результаты поиска
Контейнер результата поиска, в котором Bundle.type = 'searchset', состоит из нуля или более записей entry. Каждая запись entry должна содержать экземпляр ресурса.
В элементе Bundle.total может быть указано общее число экземпляров ресурсов, удовлетворяющих условию поиска.
В каждой записи entry могут быть указаны два специфичных элемента, характеризующих поиск:
а) entry.search.mode указывает, удовлетворяет ли экземпляр ресурса условию поиска или он включен в результат поиска, поскольку в результате присутствует экземпляр ресурса, для которого данный экземпляр является ссылочным (что может иметь место, если к условию поиска добавлен параметр _include или _revinclude);
б) entry.search.score содержит оценку степени релевантности результата поиска, которая может принимать значения от 0 (наименее релевантный) до 1 (наиболее релевантный). Обычно результаты поиска сортируются по убыванию степени релевантности, но клиент может задать иной порядок сортировки.
История
Контейнер истории изменений, где Bundle.type = 'history', состоит из нуля или более записей entry. Каждая запись entry должна содержать элемент request, описывающий выполненные изменения. Если значение элемента entry.request.method равно 'POST' или 'PUT', то запись entry должна содержать экземпляр ресурса, представляющий его состояние после выполнения этой операции. Чтобы потребители могли получить доступ к заголовку location, должен также присутствовать элемент response.
Кроме того, в элементе Bundle.total может быть указано общее число экземпляров ресурса, включенных в историю изменений.
Транзакция/пакет
Контейнер транзакции или пакета, где Bundle.type = 'transaction' или 'batch', состоит из нуля или более записей entry. Каждая запись entry должна содержать элемент request, детализирующий запрос HTTP и указывающий системе, выполняющей транзакцию, что следует делать с содержанием записи entry. Если значение элемента entry.request.method равно 'POST' или 'PUT', то запись entry должна содержать экземпляр ресурса, который служит телом запроса HTTP.
Результат транзакции/ответный пакет
Контейнер результата транзакции или ответного пакета, где Bundle.type = transaction-response или batch-response, состоит из нуля или более записей entry, по одной на каждую запись транзакции или пакета, на которую дается ответ. Каждая запись entry должна содержать элемент response, описывающий результат запроса HTTP, выполненного для соответствующей записи контейнера транзакции или пакета.
Коллекция
Контейнер коллекции, где Bundle.type = collection, состоит из нуля или более записей entry. Специального назначения у такого контейнера нет. Каждая запись entry должна содержать экземпляр ресурса.
URL ресурса и правила уникальности в контейнере
За исключением контейнеров транзакции или пакета, каждая запись entry контейнера Bundle должна иметь элемент fullUrl, идентифицирующий экземпляр ресурса, включенный в эту запись. Он идентифицирует экземпляр, но не его версию. Если экземпляру ресурса не присвоен постоянный идентификатор, который может быть использован в контейнере, то следует назначить ему идентификатор UUID (с префиксом urn:uuid:), областью действия которого является данный контейнер, и поместить его в элемент fullURL.
Если в контейнере Bundle транзакции или пакета элемент entry.request.method = POST и экземпляр ресурса не имеет уникального идентификатора, то запись entry может не иметь элемент fullUrl при условии, что на этот экземпляр ресурса нет ссылок из других записей entry. Если же такие ссылки присутствуют, то следует назначить экземпляру ресурса идентификатор UUID (с префиксом urn:uuid:), областью действия которого является данный контейнер, и поместить его в элемент fullURL.
Конкретная версия экземпляра ресурса должна быть включена в контейнер Bundle не более одного раза. Однако в один и тот же контейнер могут быть включены разные версии одного и того же экземпляра ресурса. Например, это имеет место в контейнере истории, где Bundle.type = history.
Разрешение ссылок в контейнере Bundle
Экземпляры ресурсов, вложенные в контейнер Bundle, могут содержать ссылки на экземпляры других ресурсов. Ссылочные экземпляры ресурсов могут входить в тот же самый контейнер Bundle. Содержание ссылки от этого не изменяется.
Приложение сервера, читающее контейнер транзакции, сначала должно найти ссылочные экземпляры внутри контейнера, и только после этого выполнить поиск, используя полный адрес URL ссылки. Должен использоваться следующий алгоритм разрешения ссылок в контейнере Bundle:
Наряду с относительным адресом URL (например, Patient/123) ссылка на другой экземпляр ресурса может использовать любую схему URI. Поэтому рекомендуется использовать следующий алгоритм обработки ссылок в контейнере транзакции:
Обработать ссылки reference.value, имеющие схему URN (например, urn:uuid:9d1714da-b7e6-455b-bfd2-69ce0ff5fb12):
а) выполнить поиск элемента entry.fullUrl, значение которого совпадает со значением ссылки reference.value;
б) если такой элемент найден, то в качестве ссылочного экземпляра ресурса следует использовать entry.resource.
Обработать ссылки reference.value, представляющие собой абсолютный URL:
а) если ссылка reference.value не содержит указание версии (то есть компонент /_history отсутствует, например, https://fhir.example.org/base/Patient/123), то выполнить поиск элемента entry.fullUrl, значение которого совпадает со значением ссылки reference.value;
б) если найден один такой элемент, то в качестве ссылочного экземпляра ресурса следует использовать entry.resource;
в) если найдено несколько таких элементов, то сервер может выбрать из них тот, который имеет наибольшее значение времени последнего изменения, указанного в элементе meta.lastUpdated;
г) если ссылка reference.value содержит указание версии (то есть компонент /_history присутствует, например: https://fhir.example.org/base/Patient/123/_history/a), то разбить ее значение на две части: ссылка без указания версии (например, https://fhir.example.org/base/Patient/123) и идентификатор версии (например, "a");
д) выполнить поиск элемента entry, у которого значение элемента fullUrl совпадает со ссылкой без указания версии и значение элемента resource.meta.versionId совпадает с идентификатором версии;
е) если найден единственный элемент, то в качестве ссылочного экземпляра ресурса следует использовать entry.resource;
ж) если найдено несколько элементов, сгенерировать ошибку транзакции;
и) если ссылочный экземпляр не найден, то сервер может выполнить взаимодействие чтения read или чтения версии vread, чтобы считать ссылочный экземпляр ресурса за пределами контейнера Bundle. Если такого экземпляра нет, сгенерировать ошибку транзакции.
Обработать ссылки reference.value, представляющие собой относительный URL вида "[type]/[id], например, Patient/123:
а) извлечь базовый URL из значения элемента fullUrl записи entry, в которую вложен экземпляр ресурса с проверяемой ссылкой, и вставить его перед относительным URL (например, https://fhir.example.org/ + Patient/123 --> https://fhir.example.org/Patient/123);
б) выполнить проверку, описанную для абсолютного URL;
в) если базовый URL выделить не удалось, и элемент entry.request.method записи entry, в которую вложен экземпляр ресурса с проверяемой ссылкой, имеет значение POST, PUT or PATCH, то взять URL сервера, которому адресована транзакция, вставить его перед относительным URL и выполнить проверку, описанную для абсолютного URL.
Обработать условные ссылки reference.value:
а) выполнить поиск по параметрам, указанным в относительной ссылке после типа ресурса;
б) если найден единственный экземпляр ресурса, то его следует использовать в качестве ссылочного экземпляра;
в) если найдено несколько экземпляров, сгенерировать ошибку транзакции;
г) если результат поиска пуст, сгенерировать ошибку транзакции.
Если ссылка не принадлежит ни к одной из указанных выше категорий, сгенерировать ошибку транзакции.
Для применения этого алгоритма требуется, чтобы запись entry содержала элемент fullUrl. Поэтому клиенты по возможности должны заполнять в контейнере транзакции элементы Bundle.entry.fullUrl.
Обработка контейнеров Bundle с использованием REST API
У контейнера Bundle есть своя конечная точка, как и у большинства других ресурсов. Она обслуживает обычные взаимодействия, при которых экземпляры контейнера Bundle рассматриваются как статические, то есть контейнер пакета, транзакции или сообщения может быть отправлена с помощью метода POST по адресу /Bundle. В этом случае содержание контейнера обрабатывается не как пакет, транзакция или сообщение, а как обычный экземпляр ресурса с индексированием и т.д. Операция GET/Bundle/[id] возвратит тот же самый экземпляр контейнера.
Параметры поиска экземпляров ресурса Bundle
ИС МЕГАНОРМ: примечание.
В официальном тексте документа, видимо, допущена опечатка: имеется в виду подраздел 12.27, а не 191.
Специальные параметры поиска экземпляров ресурса Bundle описаны в таблице 191. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 191.
Таблица 191
Специальные параметры поиска экземпляров ресурса Bundle
Имя
Тип
Описание
Выражение
composition
reference
Если Bundle.type = document, то первая запись entry должна содержать экземпляр ресурса Composition, и этот параметр обеспечивает возможность сцепленного поиска его содержания
Bundle.entry[0].resource as Composition
identifier
token
Постоянный идентификатор контейнера
Bundle.identifier
message
reference
Если Bundle.type = message, то первая запись entry должна содержать экземпляр ресурса MessageHeader, и этот параметр обеспечивает возможность сцепленного поиска его содержания
Bundle.entry[0].resource as Message Header
timestamp
date
Дата и время формирования содержания контейнера
Bundle.timestamp
type
token
Тип контейнера. Допустимые значения: document | message | transaction | transaction-response | batch | batch-response | history | searchset | collection | subscription-notification
Bundle.type
10.3.3 Заголовок сообщения MessageHeader
10.3.3.1 Область применения и использования
Ресурс MessageHeader используется в качестве заголовка сообщения в составе контейнера Bundle, у которого элемент type имеет значение message.
10.3.3.2 Структура ресурса
Ресурс MessageHeader является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса MessageHeader представлен на рисунке 24 и в таблице 192.
Рисунок 24 - Ресурс MessageHeader
Таблица 192
Состав элементов ресурса MessageHeader
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrative
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
event[x]
Код события передачи сообщения. Допустимые типы данных: Coding | canonical (ссылка на экземпляр ресурса EventDefinition)
*
1
destination
Приложение-получатель
BackboneElement
0..*
destination.endpoint[x]
Адресат сообщения. Допустимые типы данных: url | Reference (ссылка на экземпляр ресурса Endpoint)
*
1
destination.name
Человеко-читаемое имя целевой системы
string
0..1
destination.target
Ссылка на идентификацию конечной целевой системы
Reference
0..1
destination.receiver
Ссылка на конечного получателя
Reference
0..1
sender
Ссылка на отправителя
Reference
0..1
author
Ссылка на автора сообщения
Reference
0..1
source
Приложение-отправитель
BackboneElement
1
source.endpoint[x]
Источник данных. Допустимые типы данных: url | Reference (ссылка на экземпляр ресурса Endpoint)
*
1
source.name
Человеко-читаемое имя системы-отправителя
string
0..1
source.software
Наименование программного обеспечения
string
0..1
source.version
Версия программного обеспечения
string
0..1
source.contact
Телекоммуникационный адрес службы технической поддержки
ContactPoint
0..1
responsible
Ответственный за содержание сообщения
Reference
0..1
reason
Причина события
CodeableConcept
0..1
response
Исходное сообщение
BackboneElement
0..1
response.identifier
Идентификатор исходного сообщения Bundle.identifier
id
1
response.code
Код типа ответа. Допустимые значения: без-ошибки | ошибка | фатальная-ошибка
code
1
response.details
Полные сведения о проблемах в исходном сообщении
Reference
0..1
focus
Ссылка на основной экземпляр ресурса в данном сообщении. Им может быть в том числе экземпляр ресурса Parameters
Reference
0..*
definition
Ссылка на экземпляр ресурса Messagedefinition, содержащий определение состава данного сообщения
canonical
0..1
10.3.3.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 193.
Таблица 193
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
MessageHeader.event[x]
http://hl7.org/fhir/ValueSet/message-events
Пример
Тип события
MessageHeader.reason
http://hl7.org/fhir/ValueSet/message-reason-encounter
Пример
Причина события
MessageHeader.response.code
http://hl7.org/fhir/ValueSet/response-code
Обязательная
Код типа ответа
10.3.3.4 Использование ресурса MessageHeader
Время события, инициировавшего передачу сообщения, должно быть указано в экземпляре ресурса, на который дана ссылка в элементе focus. Время формирования сообщения должно быть указано в элементе Bundle.timestamp.
Получатель сообщения не обязан отклонять его, если ссылка в элементе receiver относится к другому субъекту. Например, он может выполнять роль регистратора или маршрутизатора сообщений.
Все экземпляры ресурсов, на которые ссылаются элементы MessageHeader.focus, должны находиться внутри контейнера сообщения.
Ссылочные экземпляры ресурсов автора и ответственного могут быть включены в контейнер сообщения или находиться за его пределами, если получатель сообщения может получить к ним доступ. В качестве автора или ответственного могут выступать как информационные системы, так и лица или организации, использующие информационные системы.
10.3.3.5 Параметры поиска экземпляров ресурса MessageHeader
Специальные параметры поиска экземпляров ресурса MessageHeader описаны в таблице 194. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 194
Специальные параметры поиска экземпляров
ресурса MessageHeader
Имя
Тип
Описание
Выражение
author
reference
Логический автор сообщения
MessageHeader.author
code
token
Допустимые значения: ok (успешно) | transient-error (преходящая ошибка) | fatal-error (фатальная-ошибка)
MessageHeader.response.code
destination
string
Человеко-читаемое имя целевой системы
MessageHeader.destination.name
destination-uri
uri
Адрес получателя сообщения
MessageHeader.destination.endpoint
event
token
Код типа события
MessageHeader.event.ofType(Coding) | MessageHeader.event.ofType(canonical)
focus
reference
Экземпляр ресурса, содержащийся в сообщении
MessageHeader.focus (любой тип ресурса)
receiver
reference
Получатель сообщения
MessageHeader.destination.receiver
response-id
token
Идентификатор исходного сообщения
MessageHeader.response.identifier
responsible
reference
Ответственный за содержание сообщения
MessageHeader.responsible
sender
reference
Система - отправитель сообщения
MessageHeader.sender
(Person, Organization)
source
string
Наименование системы - отправителя сообщения
MessageHeader.source.name
target
reference
Идентификация конечной целевой системы
MessageHeader.destination.target
10.3.4 Результат операции OperationOutcome
10.3.4.1 Область применения и использования
Ресурс OperationOutcome (результат операции) служит для описания ошибок, предупреждений и информационных сообщений о результате предпринятой системой операции. Он используется в первую очередь для передачи следующих сведений:
- ошибка взаимодействия REST или выполнения операции;
- применения операции $validate (проверка содержания экземпляра ресурса на соответствие правилам);
- ошибка обработки сообщения;
- ошибка обработки транзакции или пакета;
- информация о поиске (в контейнере результата поиска Bundle).
10.3.4.2 Структура ресурса
Ресурс OperationOutcome является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса OperationOutcome представлен на рисунке 25 и в таблице 195.
Рисунок 25 - Ресурс OperationOutcome
Таблица 195
Состав элементов ресурса OperationOutcome
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
issue
Ошибка, предупреждение или информационное сообщение, создаваемые в результате действия системы
Issue
1..*
issue. severity
Серьезность отклонения от успешной обработки. Допустимые значения: fatal (фатальная ошибка) | error (ошибка) | warning (предупреждение) | information (информация)
code
1
issue.code
Тип отклонения от нормальной обработки. Система, создающая экземпляр ресурса OperationOutcome, должна выбрать наиболее подходящий код отклонения и может предусмотреть дополнительный код ошибки в элементе details. Допустимые значения: invalid (несоответствие спецификации) | structure (ошибочная структура) | required (отсутствует обязательный элемент) | value (ошибочное значение элемента) | invariant (нарушено ограничение) | security (ошибка доступа) | login (требуется аутентификация) | unknown (неизвестный принципал) | expired (сеанс закончен) | forbidden (доступ запрещен) | suppressed (частичная информация) | processing (ошибка обработки) | not-supported (не поддерживается) | duplicate (попытка создания дубликата) | multiple-matches (несколько совпадений) | not-found (не найден) | deleted (ссылка на удаленный элемент) | too-long (слишком длинное) | code-invalid (ошибочный код) | extension (недопустимое расширение) | too-costly (слишком затратное) | business-rule (нарушено бизнес-правило) | conflict (конфликт версий) | limited-filter (некоторые фильтры могут быть применены не ко всем результатам) | transient (преходящая ошибка) | lock-error (экземпляр блокирован) | no-store (хранилище данных недоступно) | exception (возникло исключение) | timeout (таймаут) | incomplete (неполные результаты) | throttled (система на обслуживании) | informational (информационное) | success (операция успешно завершена)
code
1
issue. details
Дополнительные сведения об ошибке, например ее описание или код, присвоенный системой
CodeableConcept
0..1
issue.diagnostics
Дополнительная диагностическая информация об отклонении
string
0..*
issue. location
Этот элемент запрещен, поскольку он специфичен для XML. Он заменен на элемент issue.expression, не зависящий от формата и более простой для разбора
string
0..*
issue.expression
Выражение, использующее ограниченное подмножество языка FHIRPath и идентифицирующее один из элементов экземпляра ресурса, значение которого привело к данной ситуации
string
0..*
10.3.4.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 196.
Таблица 196
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
OperationOutcome.issue.severity
http://hl7.org/fhir/ValueSet/issue-severity
Обязательная
Серьезность отклонения от успешной обработки
OperationOutcome.issue.code
http://hl7.org/fhir/ValueSet/issue-type
Обязательная
Тип отклонения от успешной обработки
OperationOutcome.issue.details
http://hl7.org/fhir/ValueSet/operation-outcome
Пример
Примеры кодов дополнительных сведений об ошибке
10.3.4.4 Использование ресурса OperationOutcome
При передаче информации о результате выполнения запроса ресурс OperationOutcome полезен в тех случаях, если необходима более детальная информация по сравнению с кодами ответа HTTP. Такая детализация может содержать следующую информацию:
а) более точные сведения о месте возникновения проблемы;
б) несколько разных проблем;
в) более точные коды ошибок.
Сведения, передаваемые в экземпляре ресурса OperationOutcome, должны быть согласованы с кодом статуса HTTP. Например, если код статуса HTTP сигнализирует об ошибке (300+), то хотя бы один элемент issue должен иметь код серьезности error (ошибка) или fatal-error (фатальная ошибка) и указывать причину ошибки.
Ресурс OperationOutcome должен содержать хотя бы один элемент issue даже в случае успешного результата. В этом случае он должен иметь код серьезности information (информация).
10.3.4.5 Использование выражения expression
В случае предупреждения или ошибки рекомендуется указывать в элементе expression место возникновения проблемы, используя выражение на упрощенном языке FHIRPath. Такое выражение не должно содержать функцию .resolve(). Следующие выражения допустимы:
Person.identifier
Person.identifier[2].value
Пример недопустимого выражения:
Person.identifier.where(system.value='http://example.com/mrn').value
При выполнении запросов на поиск сведения об ошибках могут возвращаться также в заголовках HTTP. Эти сведения возвращаются, используя выражение, чувствительное к регистру и состоящее из двух частей: префикс "http" и заголовок либо имя параметра запроса, отделенное от префикса точкой. Примеры таких выражений приведены в таблице 197.
Таблица 197
Примеры выражений
Выражение
Описание
http."code"
Ссылка на параметр поиска code
http."name:exact"
Ссылка на параметр поиска name с модификатором ":exact"
http.Authorization
Ссылка на заголовок Authorization (например, чтобы указать его отсутствие и необходимость определенной формы аутентификации)
Эта нотация следует соглашениям, по которым заголовки HTTP должны начинаться символом в верхнем регистре, а параметры, передаваемые в адресной строке URL, должны начинаться символом в нижнем регистре.
10.3.5 Параметры операции Parameters
10.3.5.1 Область применения и использования
Ресурс Parameters (параметры операции) служит для описания параметров, которые могут передаваться операции или возвращаться ею. У этого ресурса нет собственной конечной точки.
10.3.5.2 Состав ресурса
Диаграмма классов UML ресурса Parameters показана на рисунке 26, состав элементов приведен в таблице 198.
Рисунок 26 - Ресурс Parameters (параметры операции)
Таблица 198
Состав элементов ресурса Parameters
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
parameter
Параметр операции
BackboneElement
0..*
parameter.name
Наименование параметра операции
string
1
parameter.value[x]
Значение параметра. Вместо [x] должно быть указано имя типа данных, в котором первый символ переведен в верхний регистр
*
0..1
parameter.resource
Экземпляр ресурса
Resource
0..1
parameter.part
Именованный компонент составного параметра. Допускается только один уровень вложения
См. элемент parameter
0..*
10.3.5.3 Ограничения
Ограничения ресурса Parameters приведены в таблице 199.
Таблица 199
Ограничения ресурса Parameters
Идентификатор
Описание
Выражение
Inv-1
В элементе parameter должен присутствовать либо компонент value, либо компонент resource, либо компоненты part
(part.exists() and value.empty() and resource.empty()) or (part.empty() and (value.exists() x or resource.exists()))
10.3.6 Подписка Subscription
10.3.6.1 Область применения и использования
Тип ресурса Subscription описывает подписку на уведомления об изменении экземпляров ресурсов, предоставляемые сервером другой системе (клиенту). Темы подписки, поддерживаемые сервером, описаны с помощью экземпляров ресурса SubscriptionTopic, в которых может быть определен набор допустимых фильтров (в элементе SubscriptionTopic.canFilterBy). При регистрации подписки клиенты могут указать требуемые им фильтры (из числа допустимых) в элементе Subscription.filterBy. Как только подписка зарегистрирована, любое событие, удовлетворяющее теме подписки и фильтрам (если они указаны), вызывает отправку клиенту уведомления об этом событии по заданному каналу. Уведомление представляет собой контейнер Bundle типа subscription-notification, в котором первая запись Bundle.entry содержит экземпляр ресурса SubscriptionStatus (статус подписки).
Канал, по которому должны передаваться уведомления, указан в элементе Subscription.channel, а адрес передачи уведомлений - в элементе Subscription.endpoint (конечная точка). В спецификации [22] определены каналы, приведенные в таблице 200. При необходимости могут быть реализованы другие каналы уведомлений.
Таблица 200
Система кодирования http://terminology.hl7.org/CodeSystem/
subscription-channel-type
Код
Значение
Описание
rest-hook
Rest Hook
Сервер отправляет уведомление конечной точке с адресом URI помощью метода HTTP POST. Содержание уведомления имеет заданный тип среды MIME
websocket
Websocket
Сервер отправляет уведомление, используя соединение по веб-сокету с заданным адресом URL, установленное клиентом
email
Email
Сервер отправляет уведомление по электронной почте на заданный адрес URI
message
Message
Сервер отправляет уведомление в форме сообщения (то есть контейнер Bundle типа message) приложению, идентифицируемому адресом URI
10.3.6.2 Структура ресурса
Ресурс Subscription является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Subscription представлен на рисунке 27 и в таблице 201.
Рисунок 27 - Ресурс Subscription
Таблица 201
Состав элементов ресурса Subscription
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Дополнительный идентификатор
Identifier
0..*
name
Человеко-читаемое наименование подписки
string
0..1
status
Статус подписки. Допустимые значения: requested (запрошена) | active (действует) | error (ошибка уведомления) | off (истекла или слишком много ошибок) | entered-in-error (создана по ошибке)
code
1
topic
Ссылка на тему подписки
canonical
1
contact
Контактная информация техподдержки подписки
ContactPoint
0..*
end
Дата и время завершения подписки
instant
0..1
managingEntity
Ссылка на субъект, ответственный за изменение подписки. Допустимые типы ресурсов: CareTeam | HealthcareService | Organization | RelatedPerson | Patient | Practitioner | PractitionerRole
Reference
0..1
reason
Причина подписки
string
0..1
filterBy
Критерий фильтрации потока подписки
Element
0..*
filterBy.resourceType
Тип ресурса, допустимый для данного фильтра подписки
uri
0..1
filterBy.filterParameter
Имя фильтра, определенное в экземпляре ресурса SubscriptionTopic
string
filterBy.comparator
Оператор сравнения
code
0..1
filterBy.modifier
Поддерживаемый модификатор параметра поиска missing | exact | contains | not | text | in | not-in | below | above | type | identifier | of-type | code-text | text-advanced | iterate
code
0..1
filterBy.value
Значение параметра поиска или путь к элементу ресурса, указываемые в фильтре, например Ie1950 или Patient/123
string
1
channelType
Тип канала уведомлений
code
1
endpoint
Адрес конечной точки, получающей уведомления
url
0..1
parameter.name
Наименование параметра
string
1
parameter.value
Значение параметра
string
1
heartbeatPeriod
Интервал между периодическими уведомлениями в секундах
unsignedInt
0..1
timeout
Таймаут в секундах
unsignedInt
0..1
contentType
Тип MIME содержания уведомления
code
0..1
content
Объем содержания, передаваемого в теле уведомления. Допустимые значения: empty (пустое) | id-only (только id) | full-resource (весь экземпляр ресурса)
code
0..1
maxCount
Максимальное число событий в одном уведомлении
positiveInt
0..1
10.3.6.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 202.
Таблица 202
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Subscription.status
http://hl7.org/fhir/ValueSet/subscription-status
Обязательная
Статус подписки
Subscription.filterBy.resourceType
http://hl7.org/fhir/ValueSet/subscription-types
Расширяемая
Тип ресурса, допустимый для фильтра подписки
Subscription.filterBy.comparator
http://hl7.org/fhir/ValueSet/search-comparator
Обязательная
Оператор сравнения, используемый в параметрах поиска
Subscription.filterBy. modifier
http://hl7.org/fhir/ValueSet/search-modifier-code
Обязательная
Модификатор параметра поиска
Subscription.channelType
http://hl7.org/fhir/ValueSet/subscription-channel-type
Расширяемая
Тип канала подписки
Subscription.contentType
http://hl7.org/fhir/ValueSet/mimetypes
Обязательная
Тип MIME (все возможные коды из BCP-13, см. http://tools.ietf.org/html/bcp13
Subscription.content
http://hl7.org/fhir/ValueSet/subscription-payload-content
Обязательная
Объем содержания, передаваемого в теле уведомления
10.3.6.4 Ограничения ресурса Subscription
Ограничения ресурса Subscription описаны в таблице 203.
Таблица 203
Ограничения ресурса Subscription
Идентификатор
Вид
Путь
Описание
Выражение
scr-1
Правило
Subscription.filterBy
Элементы comparator и modifier взаимно исключающие
(comparator.exists() and modifier.exists()).not()
10.3.6.5 Параметры поиска экземпляров ресурса Subscription
Специальные параметры поиска экземпляров ресурса Subscription описаны в таблице 204. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 204
Специальные параметры поиска экземпляров
ресурса Subscription
Имя
Тип
Описание
Выражение
contact
token
Контактная информация техподдержки подписки
Subscription.contact
content-level
token
Объем содержания, передаваемого в теле уведомления
Subscription.content
filter-value
string
Значение параметра поиска или путь к элементу ресурса
Subscription.filterBy.value
identifier
token
Идентификатор подписки
Subscription.identifier
name
string
Человеко-читаемое наименование подписки
Subscription.name
owner
reference
Субъект, ответственный за изменение подписки
Subscription.managingEntity (Practitioner, Organization, CareTeam, Patient, HealthcareService, PractitionerRole, RelatedPerson)
payload
token
Тип MIME содержания уведомления
Subscription.contentType
status
token
Текущий статус подписки
Subscription.status
topic
uri
Канонический идентификатор темы подписки, инициирующей уведомления
Subscription.topic
type
token
Тип канала уведомлений
Subscription.channelType
url
uri
Адрес конечной точки, получающей уведомления
Subscription.endpoint
10.3.6.6 Объем содержания
В элементе content могут быть указаны три варианта объема содержания:
- empty (пустое);
- id-only (только идентификатор id);
- full-resource (весь экземпляр ресурса).
При выборе объема содержания следует принимать во внимание производительность обработки и безопасность персональных медицинских данных. Во многих случаях целесообразно выбрать вариант id-only, обеспечивающий хороший баланс безопасности и производительности. Если сервер не поддерживает запрошенный вариант объема содержания, он может отказать в создании экземпляра ресурса Subscription или принять его с изменением варианта объема содержания.
Если указан вариант объема содержания empty, то любая информация о событии, вызвавшем уведомление, может быть получена по другим каналам, например, с помощью REST API. Получив уведомление, клиент может передать серверу запрос на поиск экземпляров ресурсов, типы которых перечислены в теме подписки SubscriptionTopic, измененных после определенного момента времени. Это наилучший вариант с точки зрения безопасности персональных медицинских данных.
10.3.6.7 Передача пакета уведомлений
При частом обновлении информации по теме подписки сервер может объединить несколько уведомлений в один контейнер Bundle типа subscription-notification. При этом сервер должен не откладывать передачу пакета уведомлений дольше, чем указано в элементе Subscription.heartbeat.
10.3.6.8 Управление подписками
Клиент инициирует взаимодействие create или update, в котором тело запроса содержит экземпляр ресурса Subscription с начальным статусом status = requested (запрошена). При успешном взаимодействии клиент выделяет из заголовка Location, возвращенного сервером в ответ на запрос, логический идентификатор id созданного экземпляра ресурса Subscription для дальнейшего управления подпиской.
Сервер проверяет тело запроса на предмет возможности регистрации подписки. Если регистрация возможна, он создает экземпляр ресурса Subscription со статусом status = requested. В противном случае он по возможности должен возвратить экземпляр ресурса OperationOutcome с указанием причины отказа в регистрации.
При активации подписки сервер присваивает элементу status значение active (действует). Он может это сделать сразу при регистрации подписки, минуя статус requested.
При наличии соответствующей авторизации клиент может выполнить поиск экземпляров ресурса Subscription или чтение истории изменения экземпляра, например, чтобы найти свои действующие подписки. Если подписка более не нужна, клиент инициирует удаление соответствующего экземпляра ресурса Subscription.
Если при передаче уведомления возникла ошибка (например, конечная точка клиента, указанная в Subscription.endpoint, недоступна), то сервер может повторить уведомление фиксированное число раз. Если ошибка не исчезла, то сервер по возможности должен присвоить статусу подписки значение error и сохранить у себя сведения об ошибке, например, в экземпляре ресурса SubscriptionStatus. Сервер может повторить попытки уведомления спустя некоторое время. При успешной передаче уведомления он может присвоить подписке статус active и удалить сохраненные сведения об ошибке. Если повторы попыток не помогают, сервер может присвоить подписке статус off и прекратить дальнейшие попытки.
Сведения об ошибках передаются в экземпляре ресурса SubscriptionStatus, содержащемся в первой записи entry контейнера уведомления Bundle. Клиент может получить сведения об ошибках, запросив применение операции $status к соответствующему экземпляру ресурса Subscription. Для возобновления передачи уведомлений клиент может инициировать взаимодействие изменения update, передав в теле запроса экземпляр ресурса Subscription со статусом active.
10.3.7 Тема подписки SubscriptionTopic
10.3.7.1 Область применения и использования
Тип ресурса SubscriptionTopic описывает тему подписки на уведомления об изменении экземпляров ресурсов, предоставляемые сервером другой системе (клиенту).
10.3.7.2 Структура ресурса
Ресурс SubscriptionTopic является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса SubscriptionTopic представлен на рисунке 28 и в таблице 205.
Рисунок 28 - Ресурс SubscriptionTopic
Таблица 205
Состав элементов ресурса SubscriptionTopic
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
url
Канонический идентификатор темы подписки в форме глобально уникального URI
uri
identifier
Формальный идентификатор, используемый для идентификации темы подписки при ее представлении в других форматах
Identifier
0..*
version
Версия темы подписки
string
0..1
versionAlgorithm[x]
Способ сравнения версий. Допустимые значения: versionAlgorithmString|version-AlgorithmCoding
0..1
name
Наименование темы подписки, предназначенное для компьютерной обработки
string
0..1
title
Человеко-читаемое наименование темы подписки
string
0..1
derivedFrom
Базовая тема подписки, полностью или частично используемая данной темой
canonical
0..1
status
Статус публикации. Допустимые значения: draft (проект) | active (действует) | retired (действие прекращено) | unknown (неизвестен)
code
experimental
Признак использования для целей тестирования или обучения
boolean
0..1
date
Дата (и необязательное время) публикации темы подписки. Она должна обновляться при изменении версии определения или ее статуса либо при существенном изменении его содержания
dateTime
0..1
publisher
Издатель - наименование организации или Ф.И.О. лица, опубликовавшего тему подписки
string
0..1
contact
Контактная информация издателя темы подписки
ContactDetail
0..*
description
Краткое описание темы подписки, ориентированное на потребителя
markdown
0..1
useContext
Контекст использования темы подписки
UsageContext
0..*
jurisdiction
Страна или регион, где предполагается использование темы подписки. Элемент запрещен, оставлен только для обратной совместимости. Вместо него следует использовать элемент useContext с соответствующим значением компонента code
CodeableConcept
0..*
purpose
Описание назначения темы подписки
markdown
0..1
copyright
Авторские права на тему подписки
markdown
0..1
copyrightLabel
Краткая характеристика авторских прав (до 50 символов), например, "Все права сохраняются"
string
0..1
approvalDate
Дата утверждения темы подписки
date
0..1
lastReviewDate
Дата последнего пересмотра темы подписки
date
0..1
effectivePeriod
Период действия темы подписки
Period
1
resourceTrigger
Определение триггера на основе ресурсов, используемого темой подписки
BackboneElement
0..*
resourceTrigger.description
Текстовое описание триггера на основе ресурсов
markdown
0..1
resourceTrigger.resource
Тип ресурса, который может использоваться в данном триггере
uri
1
resourceTrigger.supportedInteraction
Поддерживаемые взаимодействия. Допустимые значения: create (создать) | update (изменить) | delete (удалить)
code
0..*
resourceTrigger.queryCriteria
Правило срабатывания триггера, основанное на запросе
BackboneElement
0..1
resourceTrigger.queryCriteria.previous
Условие в форме REST-запроса, применяемого к экземпляру ресурса в том состоянии, которое он имел до выполнения действия (например, до изменения). Указывается без базового URL и ведущей косой черты (/)
string
0..1
resourceTrigger.queryCriteria.resultForCreate
Поведение сервера при создании экземпляра ресурса в случае выполнения условия, указанного в элементе previous. Допустимые значения: test-passes (тест проходит) | test-fails (тест не проходит)
code
0..1
resourceTrigger.queryCriteria.current
Условие в форме REST-запроса, применяемого к экземпляру ресурса в том состоянии, которое он имеет после выполнения действия (например, после изменения). Указывается без базового URL и ведущей косой черты (/)
string
0..1
resourceTrigger.queryCriteria.resultForDelete
Поведение сервера при удалении экземпляра ресурса в случае выполнения условия, указанного в элементе previous. Допустимые значения: test-passes (тест проходит) | test-fails (тест не проходит)
code
0..1
resourceTrigger.queryCriteria.requireBoth
Если имеет значение true, то для инициации уведомления должны выполняться условия, указанные в элементах previous и current. Если имеет значение false или отсутствует, то уведомление инициируется, когда выполнено хотя бы одно из условий, указанных в previous и current
boolean
0..1
eventTrigger
Определение триггера на основе событий, используемого темой подписки
BackboneElement
0..*
eventTrigger.description
Текстовое описание триггера на основе событий
markdown
0..1
eventTrigger.event
Событие, инициирующее срабатывание триггера
CodeableConcept
1
eventTrigger.resource
Имя типа ресурса, который может использоваться в данном триггере
uri
1
canFilterBy
Свойство, по которому может фильтроваться уведомление по данной теме
BackboneElement
0..*
canFilterBy.description
Описание параметра фильтра
markdown
0..1
canFilterBy.resource
Имя основного типа ресурса, который может использоваться в данном фильтре
uri
0..1
canFilterBy.filterParameter
Имя фильтра, определенное в экземпляре ресурса SubscriptionTopic
string
canFilterBy.filterDefinition
Адрес URL определения параметра фильтра
uri
0..1
canFilterBy.comparator
Оператор сравнения
code
0..*
canFilterBy.modifier
Поддерживаемый модификатор параметра фильтра. Допустимые значения: missing | exact | contains | not | text | in | not-in | below | above | type | identifier | of-type | code-text | text-advanced | iterate
code
0..*
notificationShape
Свойства, предназначенные для описания форм уведомлений по данной теме
BackboneElement
0..*
notificationShape.resource
Имя основного типа ресурса, используемого в уведомлении
uri
1
notificationShape.include
Значение параметра _include, инициирующего включение ссылочного экземпляра ресурса по прямой ссылке
string
0..*
notificationShape.revinclude
Значение параметра _revinclude, инициирующего включение ссылочного экземпляра ресурса по обратной ссылке
string
0..*
10.3.7.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 206.
Таблица 206
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Subscription.status
http://hl7.org/fhir/ValueSet/subscription-status
Обязательная
Использование адреса
10.3.7.4 Ограничения ресурса SubscriptionTopic
Ограничения ресурса SubscriptionTopic описаны в таблице 207.
Таблица 207
Ограничения ресурса SubscriptionTopic
Идентификатор
Вид
Путь
Описание
Выражение
scr-1
Правило
Subscription.filterBy
Элементы comparator и modifier взаимно исключающие
(comparator.exists() and modifier.exists()).not()
10.3.7.5 Параметры поиска экземпляров ресурса SubscriptionTopic
Специальные параметры поиска экземпляров ресурса SubscriptionTopic описаны в таблице 208. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 208
Специальные параметры поиска экземпляров
ресурса SubscriptionTopic
Имя
Тип
Описание
Выражение
date
date
Дата публикации темы подписки
SubscriptionTopic.date
derived-or-self
uri
Канонический идентификатор темы подписки или базовой темы
SubscriptionTopic.url | SubscriptionTopic.derivedFrom
effective
date
Период действия темы подписки
SubscriptionTopic.effectivePeriod
event
token
Событие, инициирующее срабатывание триггера
SubscriptionTopic.eventTrigger.event
identifier
token
Формальный идентификатор темы подписки
SubscriptionTopic.identifier
resource
uri
Допустимый тип ресурса, который может использоваться в данном триггере
SubscriptionTopic.resourceTrigger.resource | SubscriptionTopic.eventTrigger.resource | SubscriptionTopic.canFilterBy.resource | SubscriptionTopic.notificationShape.resource
status
token
Статус публикации. Допустимые значения: draft | active | retired | unknown
SubscriptionTopic.status
title
string
Человеко-читаемое наименование темы подписки
SubscriptionTopic.title
trigger-description
string
Текстовое описание триггера на основе ресурсов
SubscriptionTopic.resourceTrigger.description
url
uri
Канонический идентификатор темы подписки
SubscriptionTopic.url
version
token
Версия темы подписки
SubscriptionTopic.version
10.3.8 Статус подписки SubscriptionStatus
10.3.8.1 Область применения и использования
Тип ресурса SubscriptionStatus описывает статус подписки на уведомления об изменении экземпляров ресурсов, предоставляемые сервером другой системе (клиенту). Он не имеет собственной конечной точки, и его экземпляры используются только в контейнере Bundle типа subscription-notification.
10.3.8.2 Структура ресурса
Ресурс SubscriptionStatus является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса представлен на рисунке 29 и в таблице 209.
Рисунок 29 - Ресурс SubscriptionStatus
Таблица 209
Состав элементов ресурса SubscriptionStatus
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
Modifier-Extension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные атрибуты
status
Статус подписки. Допустимые значения: requested | active | error | off | entered-in-error
code
0..1
type
Тип уведомления. Допустимые значения: handshake | heartbeat | event-notification | query-status | query-event
code
0..1
eventsSinceSubscriptionStart
Число событий с момента начала подписки
integer64
0..1
notificationEvent
Детальные сведения о событиях, относящихся к данному уведомлению
BackboneElement
0..*
notificationEvent.eventNumber
Порядковый номер события
integer64
notificationEvent.timeStamp
Штамп даты и времени возникновения события
instant
0..1
notificationEvent.focus
Основной экземпляр ресурса в сведениях о событии
Reference
0..1
notificationEvent.additionalContext
Контекст события. Обычно содержит ссылку на экземпляр ресурса, связанный с основным экземпляром, указанным в элементе focus
Reference
0..1
subscription
Ссылка на экземпляр ресурса Subscription, инициировавший данное уведомление
Reference
topic
Ссылка на тему подписки, с которой связано данное уведомление
canonical
0..1
error
Ошибка подписки
CodeableConcept
0..*
10.3.8.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 210.
Таблица 210
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
SubscriptionStatus.status
http://hl7.org/fhir/ValueSet/subscription-status
Обязательная
Статус подписки
SubscriptionStatus.type
http://hl7.org/fhir/ValueSet/subscription-notification-type
Обязательная
Тип уведомления
SubscriptionStatus.error
http://hl7.org/fhir/ValueSet/subscription-error
Пример
Код ошибки
10.3.8.4 Ограничения ресурса SubscriptionStatus
Ограничения ресурса SubscriptionStatus описаны в таблице 211.
Таблица 211
Ограничения ресурса SubscriptionStatus
Идентификатор
Вид
Путь
Описание
Выражение
sst-1
Правило
Базовый
При типе уведомления event-notification или query-event элемент notificationEvent обязателен
(type = 'event-notification' or type = 'query-event') implies notificationEvent.exists()
sst-2
Правило
Базовый
При типе уведомления query-status элемент status обязателен
type = 'query-status' implies status.exists()
10.3.8.5 Нумерация уведомлений
Поскольку каналы уведомлений, перечисленные в таблице 200, не обеспечивают гарантированную доставку уведомлений, то использование монотонно возрастающей нумерации уведомлений позволяет выявлять некоторые виды ошибок доставки. Если используются другие каналы уведомлений (например, очереди сообщений), то нумерация уведомлений не обязательна, но может оказаться полезной. Поэтому элемент SubscriptionStatus.notificationEvent.eventNumber определен как обязательный. При этом нумерация может быть сквозной для всех уведомлений по данной подписке или же только для уведомлений, переданных в конкретном контейнере Bundle.
10.3.8.6 Типы уведомлений
Определены пять типов уведомлений:
а) event (уведомление о событии);
б) handshake (уведомление о соединении);
в) heartbeat (периодическое уведомление);
г) query-status (запрос статуса);
д) query-event (запрос события).
Во всех случаях тело уведомления представляет собой контейнер Bundle типа Issubscription-notification, в котором первая запись Bundle.entry содержит экземпляр ресурса SubscriptionStatus (статус подписки).
10.3.8.7 Уведомление о событии
При уведомлении о событии (SubscriptionStatus.type=event) к элементам ресурса SubscriptionStatus предъявляются требования, приведенные в таблице 212.
Таблица 212
Требования к элементам ресурса SubscriptionStatus
при уведомлении о событии
Элемент
Обязательность
Примечание
SubscriptionStatus.status
Рекомендован
Текущий статус соответствующей подписки (например, active)
SubscriptionStatus. type
Обязателен
Должен иметь значение event-notification
SubscriptionStatus.eventsSinceSubscriptionStart
Условно обязателен
Обязателен для каналов уведомлений, не гарантирующих доставку
SubscriptionStatus.notificationEvent
Обязателен
При уведомлении о событии этот элемент обязателен
SubscriptionStatus.notificationEvent.eventNumber
Условно обязателен
Обязателен для каналов уведомлений, не гарантирующих доставку
SubscriptionStatus.notificationEvent.timestamp
Рекомендован
По значению этого элемента клиент может определить фактический момент возникновения события
SubscriptionStatus.notificationEvent.focus
Условно обязателен
Обязательность зависит от объема содержания, передаваемого в теле уведомления:
empty: должен отсутствовать;
id-only: должен присутствовать;
full-resource: должен присутствовать
SubscriptionStatus.notificationEvent.additionalContext
Условно обязателен
Обязательность зависит от объема содержания, передаваемого в теле уведомления:
empty: должен отсутствовать;
id-only: по возможности должен присутствовать;
full-resource: по возможности должен присутствовать
SubscriptionStatus.topic
Необязателен
Если по человеко-читаемому описанию темы подписки можно определить, что в содержание уведомления включена персональная медицинская информация, то из соображений ее безопасности этот элемент лучше опустить
10.3.8.8 Соединение
При уведомлении о соединении (SubscriptionStatus.type=event) к элементам ресурса SubscriptionStatus предъявляются требования, приведенные в таблице 213. Действия клиента по получении такого уведомления зависят от канала уведомлений. Например, если уведомления передаются по каналу rest-hook, то конечная точка клиента должна возвратить серверу соответствующий код статуса HTTP.
Таблица 213
Требования к элементам ресурса SubscriptionStatus
при уведомлении о соединении
Элемент
Обязательность
Примечание
SubscriptionStatus.status
Рекомендован
Текущий статус соответствующей подписки (например, active)
SubscriptionStatus.type
Обязателен
Должен иметь значение handshake
SubscriptionStatus.eventsSinceSubscriptionStart
Необязателен
Если этот элемент присутствует, то для вновь созданной подписки он должен иметь значение 0. При повторном соединении его значение может быть ненулевым
SubscriptionStatus.notificationEvent
Условно обязателен
В контейнер Bundle с уведомлением о соединении могут быть включены уведомления о событиях (например, при возобновлении соединения сервер может включить в контейнер Bundle уведомления обо всех событиях, имевших место после завершения соединения)
SubscriptionStatus.notificationEvent.eventNumber
Условно обязателен
Обязателен для каналов уведомлений, не гарантирующих доставку
SubscriptionStatus.notificationEvent.timestamp
Условно обязателен
Если в контейнер Bundle с уведомлением о соединении включены уведомления о предыдущих событиях, то рекомендуется передавать этот элемент, чтобы клиент мог обработать уведомления о предыдущих событиях в правильном контексте
SubscriptionStatus.notificationEvent. focus
Условно обязателен
Обязательность зависит от объема содержания, передаваемого в теле уведомления:
empty: должен отсутствовать;
id-only: должен присутствовать;
full-resource: должен присутствовать
SubscriptionStatus.notificationEvent.additionalContext
Условно обязателен
Обязательность зависит от объема содержания, передаваемого в теле уведомления:
empty: должен отсутствовать;
id-only: по возможности должен присутствовать;
full-resource: по возможности должен присутствовать
SubscriptionStatus.topic
Необязателен
Если по человеко-читаемому описанию темы подписки можно определить, что в содержание уведомления включена персональная медицинская информация, то из соображений ее безопасности этот элемент лучше опустить
10.3.8.9 Периодическое уведомление
При периодическом уведомлении (SubscriptionStatus.type= heartbeat) к элементам ресурса SubscriptionStatus предъявляются требования, приведенные в таблице 214.
Таблица 214
Требования к элементам ресурса SubscriptionStatus
при периодическом уведомлении
Элемент
Обязательность
Примечание
SubscriptionStatus.status
Рекомендован
Текущий статус соответствующей подписки (например, active)
SubscriptionStatus.type
Обязателен
Должен иметь значение heartbeat
SubscriptionStatus.eventsSinceSubscriptionStart
Условно рекомендован
Наличие этого элемента позволяет клиенту выявить пропуск уведомлений. Рекомендован для подписок, не гарантирующих доставку уведомлений
SubscriptionStatus.notificationEvent
Условно обязателен
В контейнер Bundle с периодическим уведомлением могут быть включены уведомления о событиях (например, при возобновлении соединения сервер может включить в контейнер Bundle уведомления обо всех событиях, имевших место после завершения соединения)
SubscriptionStatus.notificationEvent.eventNumber
Условно обязателен
Если в контейнер Bundle с периодическим уведомлением включены уведомления о предыдущих событиях, то рекомендуется передавать этот элемент для каналов уведомлений, не гарантирующих доставку
SubscriptionStatus.notificationEvent.timestamp
Условно обязателен
Если в контейнер Bundle с периодическим уведомлением включены уведомления о предыдущих событиях, то рекомендуется передавать этот элемент, чтобы клиент мог обработать уведомления о предыдущих событиях в правильном контексте
SubscriptionStatus.notificationEvent.focus
Условно обязателен
Обязательность зависит от объема содержания, передаваемого в теле уведомления:
empty: должен отсутствовать;
id-only: при наличии элемента notificationEvent должен присутствовать;
full-resource: при наличии элемента notificationEvent должен присутствовать
SubscriptionStatus.notificationEvent.additionalContext
Условно обязателен
Обязательность зависит от объема содержания, передаваемого в теле уведомления:
empty: должен отсутствовать;
id-only: при наличии элемента notificationEvent по возможности должен присутствовать;
full-resource: при наличии элемента notificationEvent по возможности должен присутствовать
SubscriptionStatus.topic
Необязателен
Если по человеко-читаемому описанию темы подписки можно определить, что в содержание уведомления включена персональная медицинская информация, то из соображений ее безопасности этот элемент лучше опустить
10.3.8.10 Запрос статуса
Клиент может запросить у сервера текущий статус подписки с помощью операции $status. В ответ на этот запрос сервер должен возвратить уведомление, в котором SubscriptionStatus.type = query-status. К элементам возвращенного экземпляра ресурса SubscriptionStatus предъявляются требования, приведенные в таблице 215.
Таблица 215
Требования к элементам ресурса SubscriptionStatus
при запросе статуса
Элемент
Обязательность
Примечание
SubscriptionStatus.status
Обязателен
Текущий статус соответствующей подписки (например, active)
SubscriptionStatus.type
Обязателен
Должен иметь значение query-status
SubscriptionStatus.eventsSinceSubscriptionStart
Условно обязателен
Наличие этого элемента позволяет клиенту выявить пропуск уведомлений. Обязателен для подписок, не гарантирующих доставку уведомлений
SubscriptionStatus.notificationEvent
Условно обязателен
В контейнер Bundle с ответом на запрос статуса могут быть включены уведомления о недавних событиях
SubscriptionStatus.topic
Рекомендован
Если по человеко-читаемому описанию темы подписки можно определить, что в содержание уведомления включена персональная медицинская информация, то из соображений ее безопасности этот элемент лучше опустить. В остальных случаях этот элемент рекомендован
10.3.8.11 Запрос события
Сервер может обеспечивать обработку запроса сведений о событиях, которые уже произошли, переданного с помощью операции $events. В ответ на этот запрос сервер должен возвратить уведомление, в котором SubscriptionStatus.type = query-event. К элементам возвращенного экземпляра ресурса SubscriptionStatus предъявляются требования, приведенные в таблице 216.
Таблица 216
Требования к элементам ресурса SubscriptionStatus
при запросе события
Элемент
Обязательность
Примечание
SubscriptionStatus.status
Рекомендован
Текущий статус соответствующей подписки (например, active)
SubscriptionStatus.type
Обязателен
Должен иметь значение query-event
SubscriptionStatus.eventsSinceSubscriptionStart
Условно рекомендован
Наличие этого элемента позволяет клиенту выявить пропуск уведомлений. Рекомендован для подписок, не гарантирующих доставку уведомлений
SubscriptionStatus.notificationEvent
Условно обязателен
Обязателен, если сведения о событиях найдены
SubscriptionStatus.notificationEvent.eventNumber
Условно обязателен
Обязателен для каналов уведомлений, не гарантирующих доставку
SubscriptionStatus.notificationEvent.timestamp
Рекомендован
По значению этого элемента клиент может определить фактический момент возникновения события
SubscriptionStatus.notificationEvent.focus
Условно обязателен
Обязательность зависит от объема содержания, передаваемого в теле уведомления:
empty: должен отсутствовать;
id-only: при наличии элемента notificationEvent должен присутствовать;
full-resource: при наличии элемента notificationEvent должен присутствовать
SubscriptionStatus.notificationEvent.additionalContext
Условно обязателен
Обязательность зависит от объема содержания, передаваемого в теле уведомления:
empty: должен отсутствовать;
id-only: при наличии элемента notificationEvent по возможности должен присутствовать;
full-resource: при наличии элемента notificationEvent по возможности должен присутствовать
SubscriptionStatus.topic
Необязателен
Если по человеко-читаемому описанию темы подписки можно определить, что в содержание уведомления включена персональная медицинская информация, то из соображений ее безопасности этот элемент лучше опустить
11 Модель данных хранилища результатов измерений
11.1 Состав данных хранилища результатов измерений
11.1.1 Общий состав данных
Хранилище результатов измерений содержит данные трех основных служб (рисунок 30):
а) служба результатов измерений (сведения о состоянии здоровья пациента, о назначенных ему мероприятиях, о выполнении мероприятий, об используемых медицинских приборах);
б) служба подписки (темы подписки и подписки клиентов на заданные темы);
в) терминологическая служба (системы кодирования и наборы значений).
Рисунок 30 - Общий состав данных хранилища
результатов измерений
11.1.2 Состав данных службы результатов измерений
11.1.2.1 Общие требования
Состав данных службы результатов измерений представлен в таблице 217.
Таблица 217
Состав данных службы результатов измерений
Раздел хранилища
Описание
Дневники
Дневники самонаблюдения, приема лекарств, приема питания
Эпикризы и предупреждения
Этапные эпикризы, предупреждения и напоминания пациенту
Персональные медицинские приборы
Идентификация и свойства персональных медицинских приборов и менеджеров
Планы ведения
Планы ведения пациентов
Результаты измерений
Результаты измерений, выполненных ПМП
11.1.2.2 Дневники
Состав данных раздела "Дневники" приведен на рисунке 31 и в таблице 218. На рисунке показаны ссылки между экземплярами ресурсов, в том числе ссылки на экземпляры ресурсов, хранящихся в других разделах.
Рисунок 31 - Состав данных раздела "Дневники"
Таблица 218
Состав данных раздела "Дневники"
Имя
Описание
Ресурс/профиль
Пункт
Запись дневника
Абстрактный объект, используется для группировки видов записей дневников
-
-
Запись дневника питания
Запись дневника приема питания
NutritionIntake
Запись дневника приема лекарств
Запись дневника приема или применения лекарственных препаратов
MedicationStatement
Запись дневника самонаблюдений
Запись дневника самонаблюдений
Questionnaire-Response
Форма дневника
Форма дневника самонаблюдений
Questionnaire
11.1.2.3 Эпикризы и предупреждения
Состав данных раздела "Эпикризы и предупреждения" представлен на рисунке 32 и в таблице 219. На рисунке показаны ссылки между экземплярами ресурсов, в том числе ссылки на экземпляры ресурсов, хранящихся в других разделах.
Рисунок 32 - Состав данных раздела
"Эпикризы и предупреждения"
Таблица 219
Состав данных раздела "Эпикризы и предупреждения"
Имя
Описание
Ресурс/профиль
Пункт
Заключение врача
Этапный эпикриз в процессе ведения пациента и по завершении плана ведения
DiagnosticReport-Dm
Результат исследования
Результат исследования, полученный вне рамок дистанционного мониторинга
Observation, вложен в экземпляр ресурса DiagnosticReport
Предупреждение или напоминание
Предупреждение или напоминание, предназначенное пациенту
DetectedIssue-Dm
11.1.2.4 Персональные медицинские приборы
Состав данных раздела "Персональные медицинские приборы" представлен на рисунке 33 и в таблице 220. На рисунке показаны ссылки между экземплярами ресурсов, в том числе ссылки на экземпляры ресурсов, хранящихся в других разделах.
Рисунок 33 - Состав данных раздела
"Персональные медицинские приборы"
Таблица 220
Состав данных раздела "Персональные медицинские приборы"
Имя
Описание
Ресурс/профиль
Пункт
Персональный медицинский прибор
Персональный медицинский прибор
Device-Phd
Менеджер ПМП
Менеджер персонального медицинского прибора
Device-Phg
11.1.2.5 Планы ведения
ИС МЕГАНОРМ: примечание.
В официальном тексте документа, видимо, допущена опечатка: имеется в виду таблица 221, а не 220.
Состав данных раздела "Планы ведения" представлен на рисунке 34 и в таблице 220. На рисунке показаны ссылки между экземплярами ресурсов, в том числе ссылки на экземпляры ресурсов, хранящихся в других разделах.
Рисунок 34 - Состав данных раздела "Планы ведения"
Таблица 221
Состав данных раздела "Планы ведения"
Имя
Описание
Ресурс/профиль
Пункт
План ведения ДМ
План ведения дистанционного мониторинга пациента
CarePlan-DM
Целевой показатель
Целевой показатель, который планируется достичь в результате выполнения плана ведения
Goal-DM
Результат исследования
Результат исследований, необходимый для вычисляемого результата измерений (например, рост пациента для весов, способных вычислить индекс массы тела)
Observation
Мероприятие
Мероприятие, выполняемое в рамках плана ведения
Task
Измерение с помощью ПМП
Task-Phd
Лекарственное назначение
Task-Medication
Ведение дневника приема лекарств
Task-MedStat
Ведение дневника питания
Task-NutrInt
Ведение дневника самонаблюдений
Task-QuestResp
Составление заключения врача
Task-DiagRep
Лечащий врач
Медицинский специалист, составивший план ведения и контролирующий его выполнение
Practitioner-Dm
Пациент
Пациент, которому назначен план дистанционного мониторинга
Patient-Dm
Привязка прибора к пациенту
Ассоциация между пациентом и персональным медицинскими прибором или менеджером ПМП
DeviceAssociation-Dm
Метрика прибора
Измерительная способность ПМП
DeviceMetric
11.1.2.6 Результаты измерений
Состав данных раздела "Результаты измерений" представлен на рисунке 35 и в таблице 222. На рисунке показаны ссылки между экземплярами ресурсов, в том числе ссылки на экземпляры ресурсов, хранящихся в других разделах.
Рисунок 35 - Состав данных раздела "Результаты измерений"
Таблица 222
Состав данных раздела "Результаты измерений"
Имя
Описание
Ресурс/профиль
Пункт
Скалярная величина
Числовой результат: физическая величина, например, частота сердечных сокращений, процент заряда батареи прибора
Observation-PhdNumeric
Сверка показаний таймеров
Сверка показаний таймеров менеджера и ПМП
Observation-PhdCoincidentTimeStamp
Массив скалярных величин
Совокупность связанных физических величин, например, систолическое и диастолическое артериальное давление
Observation-PhdCompoundNumeric
Строковый результат
Человеко-читаемая строка, принадлежащая определенному списку
Observation-PhdStringEnumeration
Кодируемый результат
Кодированное значение, принадлежащее определенному справочнику значений
Observation-PhdCodedEnumeration
Битовый результат
Целое число, отдельные биты которого характеризуют определенные состояния, например, состояние источника питания, состояние датчика
Observation-PhdBitsEnumeration
Массив считываний
Массив числовых считываний биосигнала, например, кардиограммы
Observation-PhdRtsa
Медиаданные
Медиаданные, например, растровое изображение или аудиоданные
Observation-PhdMedia
11.1.3 Состав данных службы подписки
Состав данных службы подписки приведен на рисунке 36 и в таблице 223.
Рисунок 36 - Состав данных службы подписки
Таблица 223
Состав данных службы подписки
Имя
Описание
Ресурс
Пункт
Подписка
Подписка на уведомления по определенной теме
Subscription
Тема подписки
Тема, доступная для подписки
SubscriptionTopic
11.1.4 Состав данных терминологической службы
Состав данных терминологической службы приведен на рисунке 37 и в таблице 224.
Рисунок 37 - Состав данных терминологической службы
Таблица 224
Состав данных терминологической службы
Имя
Описание
Ресурс
Пункт
Набор значений
Подмножество понятий из системы кодирования и (необязательно) одного или нескольких наборов значений
ValueSet
Система кодирования
Коллекция кодированных понятий (справочник или классификатор)
CodeSystem
11.2 Ресурс CarePlan - план дистанционного мониторинга пациента
11.2.1 Область применения и использования
Тип ресурса CarePlan описывает индивидуальный план ведения пациента, составляемый лечащим врачом на основе одного или нескольких типовых планов с учетом особенностей состояния здоровья и социального статуса пациента. Индивидуальный план ведения обычно включает в себя несколько мероприятий - визиты к врачам разных специальностей (явки), обследования и лечебных воздействий. Мероприятия должны проводиться в определенном порядке. Часть мероприятий должна проводиться строго одно после другого, часть мероприятий может проводиться независимо друг от друга или параллельно. Порядок проведения мероприятий задается правилами типа "визит к пульмонологу должен проводиться после рентгенографии легких" или "повторный визит к участковому терапевту должен проводиться после выполнения всех остальных мероприятий".
Для каждого мероприятия плана задают:
а) вид мероприятия (визит, обследование, лечение);
б) тип мероприятия (визит к офтальмологу, общий анализ крови, санаторно-курортное лечение и т.д.);
в) описание подготовки пациента к выполнению мероприятия;
г) описание действий пациента при самостоятельном выполнении мероприятия (например, видеоролик по правильному измерению артериального давления или по замене аккумуляторных батарей в приборе);
д) график выполнения (например, через две недели, а затем каждые 4 месяца);
е) признак контрольной точки (при проведении такого мероприятия обязательно проводится оценка эффективности плана, на основании которой план может быть скорректирован).
11.2.2 Структура ресурса
Ресурс CarePlan является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса CarePlan представлен на рисунке 38 и в таблице 225.
Рисунок 38 - Ресурс CarePlan
Таблица 225
Состав элементов ресурса CarePlan
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Идентификатор плана ведения
Identifier
0..*
instantiatesCanonical
Ссылка на типовой план, представленный в виде экземпляра ресурса
canonical
0..*
instantiatesUri
Ссылка на URL типового плана
uri
0..*
basedOn
Ссылка на план, требование или направление, на котором основан данный план
Reference
0..*
replaces
Ссылка на заменяемый план
Reference
0..*
partOf
Ссылка на головной план
Reference
0..*
status
Статус плана. Допустимые значения: draft | active | on-hold | revoked | completed | entered-in-error | unknown
code
1
intent
Роль плана. Допустимые значения: proposal | plan | order | option | directive
code
1
category
Тип плана ведения
CodeableConcept
0..*
title
Человеко-читаемое наименование плана
string
0..1
description
Описание плана
string
0..1
subject
Ссылка на субъект плана - пациент или группа
Reference
1
encounter
Ссылка на случай медицинской помощи
Reference
0..1
period
Период действия плана
Period
0..1
created
Дата и время создания плана
dateTime
0..1
custodian
Ссылка на ответственное лицо или организацию
Reference
0..1
contributor
Ссылка на лицо, роль, устройство или организацию, принявшие участие в составлении плана
Reference
0..*
careTeam
Ссылка на бригаду медицинских работников, участвующих в назначении и выполнении плана
Reference
0..*
addresses
Код клинического состояния пациента или ссылка на описание состояния, в связи с которым назначен данный план
Codeable-Reference
0..*
supportingInfo
Ссылка на экземпляр ресурса, являющийся частью данного плана
Reference
0..*
goal
Ссылка на желательный результат плана
Reference
0..*
activity
Мероприятие, которое уже выполнено или должно быть выполнено в рамках плана
Backbone-Element
0..*
performedActivity
Ссылка на мероприятие плана
Codeable-Reference
0..*
progress
Примечания к статусу или выполнению мероприятия
Annotation
0..*
plannedActivityReference
Ссылка на планируемое мероприятие
Reference
0..*
note
Примечание к плану
Annotation
0..*
11.2.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 226.
Таблица 226
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
CarePlan.status
http://hl7.org/fhir/ValueSet/request-status
Обязательная
Состояния жизненного цикла требования
CarePlan.intent
http://hl7.org/fhir/ValueSet/care-plan-intent
Обязательная
Степень директивности
CarePlan.category
http://hl7.org/fhir/ValueSet/care-plan-category
Пример
Тип плана ведения
CarePlan.addresses
http://hl7.org/fhir/ValueSet/clinical-findings
Пример
Клиническое состояние пациента
CarePlan.activity.performedActivity
http://hl7.org/fhir/ValueSet/care-plan-activity-performed
Пример
Тип мероприятия плана ведения
11.2.4 Параметры поиска экземпляров ресурса CarePlan
Специальные параметры поиска экземпляров ресурса CarePlan описаны в таблице 227. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 227
Специальные параметры поиска экземпляров ресурса CarePlan
Имя
Тип
Описание
Выражение
activity-reference
reference
Планируемое мероприятие
CarePlan.activity.plannedActivityReference (Appointment, MedicationRequest, Task, NutritionOrder, RequestOrchestration, VisionPrescription, DeviceRequest, ServiceRequest, CommunicationRequest, ImmunizationRecommendation, SupplyRequest)
based-on
reference
Ссылка на план, требование или направление, на котором основан данный план
CarePlan.basedOn (CarePlan, RequestOrchestration, NutritionOrder, ServiceRequest)
care-team
reference
Ссылка на бригаду медицинских работников
CarePlan.careTeam (CareTeam)
category
token
Тип плана ведения
CarePlan.category
condition
reference
Ссылка на описание состояния пациента
CarePlan.addresses.reference
custodian
reference
Ссылка на ответственное лицо или организацию
CarePlan.custodian (Practitioner, Organization, CareTeam, Device, Patient, PractitionerRole, RelatedPerson)
date
date
Период действия плана
CarePlan.period
encounter
reference
Ссылка на случай медицинской помощи
CarePlan.encounter (Encounter)
goal
reference
Ссылка на желательный результат плана
CarePlan.goal (Goal)
identifier
token
Идентификатор плана ведения
CarePlan.identifier
instantiates-canonical
reference
Ссылка на типовой план, представленный в виде экземпляра ресурса
CarePlan.instantiatesCanonical (Question-naire, Measure, PlanDefinition, OperationDefinition, ActivityDefinition)
instantiates-uri
uri
Ссылка на URL типового плана
CarePlan.instantiatesUri
intent
token
Роль плана. Допустимые значения: proposal | plan | order | option | directive
CarePlan.intent
part-of
reference
Ссылка на головной план
CarePlan.partOf (CarePlan)
patient
reference
Ссылка на пациента - субъекта плана
CarePlan.subject.where(resolve() is Patient) (Patient)
replaces
reference
Ссылка на заменяемый план
CarePlan.replaces (CarePlan)
status
token
Статус плана. Допустимые значения: draft | active | on-hold | revoked | completed | entered-in-error | unknown
CarePlan.status
subject
reference
Ссылка на субъект плана
CarePlan.subject
11.2.5 Профиль плана дистанционного мониторинга пациента
Профиль плана дистанционного мониторинга пациента CarePlan-Dm ограничивает элементы ресурса CarePlan в соответствии с рисунком 39 и таблицей 228. Имя ресурса остается неизменным - CarePlan, имя профиля передается в элементе meta.profile.
Рисунок 39 - Профиль CarePlan-Dm
Таблица 228
Состав элементов профиля CarePlan-Dm
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
Унаследованы от абстрактного класса DomainResource
text
Полное описание плана ведения, ориентированное на пациента
Narrattive1
text.status
Статус повествовательного содержания. Фиксированное значение "additional"
code
1
text.div
Текст в формате xhtml с ограниченным форматированием
xhtml
1
Собственные элементы
identifier
Идентификатор плана ведения, присвоенный медицинской информационной системой
Identifier
1
status
Статус плана. Допустимые значения: draft | active | on-hold | revoked | completed | entered-in-error | unknown
code
1
intent
Роль плана. Фиксированное значение "plan"
code
1
category
Тип плана ведения
CodeableConcept
1
description
Краткое описание плана
string
1
subject
Ссылка на идентификацию пациента
Reference
1
period
Период действия плана
Period
1
custodian
Ссылка на идентификацию лечащего врача
Reference
1
supportingInfo
Ссылка на экземпляр ресурса Observation со сведениями о показателях, необходимых для интерпретации результатов измерений
Reference
0..*
goal
Ссылка на желательный результат плана
Reference
1..*
11.2.6 Контекст профиля
Содержание экземпляра ресурса CarePlan представляет собой только часть плана ведения. Полное содержание плана ведения может быть представлено направленным графом, включающим в себя ссылочные экземпляры ресурсов. Этот граф служит контекстом профиля.
Рекомендуемый контекст профиля плана дистанционного мониторинга пациента показан на рисунке 40.
Рисунок 40 - Контекст профиля CarePlan-DM
Согласно этому рисунку, полный план дистанционного мониторинга пациента должен включать в себя:
а) экземпляр ресурса CarePlan,
б) один или несколько экземпляров ресурса Goal, описывающих целевые показатели, которые должны быть достигнуты при выполнении плана;
в) идентификацию лечащего врача (экземпляр ресурса Practitioner);
г) идентификацию пациента (экземпляр ресурса Patient);
д) одно или несколько мероприятий (экземпляры ресурса Task), осуществляемых в процессе выполнения плана. Для каждого мероприятия должны быть указаны расписание выполнения (класс Input) и исполнитель (класс Performer). Исполнителями могут быть пациент, лечащий врач и персональный медицинский прибор (должен быть выбран ровно один);
е) один или несколько персональных медицинских приборов (экземпляры ресурса Device), привязанных к пациенту с помощью экземпляров ресурса DeviceAssociation.
ж) экземпляры ресурса Observation, содержащие показатели состояния пациента (например, вес и рост), требуемые для автоматической интерпретации результатов измерений.
11.2.7 Создание и изменение плана дистанционного мониторинга
Полный план дистанционного мониторинга пациента должен передаваться в контейнере транзакции Bundle, у которого элемент type имеет значение transaction. В процессе выполнения в план могут вноситься изменения, которые также должны передаваться в контейнере транзакции Bundle.
При завершении или прекращении выполнения плана следует присвоить элементу CarePlan.status значение revoked или completed, элементу CarePlan.period.end присвоить дату (дату и время) этого события, и внести соответствующие изменения во все экземпляры ресурсов Task, содержащие ссылки на данный экземпляр ресурса CarePlan. Все эти действия должны быть специфицированы в одном контейнере транзакции Bundle.
При приостановке выполнения плана следует присвоить элементу CarePlan.status значение on-hold, и внести соответствующие изменения статуса во все экземпляры ресурсов Task, содержащие ссылки на данный экземпляр ресурса CarePlan и имеющие значение статуса in-progress.
При возобновлении выполнения плана следует присвоить элементу CarePlan.status значение active и выполнить замену статуса на in-progress во всех экземплярах ресурса Task, содержащих ссылки на данный экземпляр ресурса CarePlan, у которых предыдущее значение статуса имело значение in-progress.
Действия по приостановке или возобновления выполнения должны быть специфицированы в одном контейнере транзакции Bundle.
В процессе выполнения плана не должны допускаться изменения следующих элементов ресурса CarePlan:
а) identifier - идентификатор плана ведения;
б) subject - ссылка на идентификацию пациента;
в) custodian - ссылка на идентификацию лечащего врача.
При необходимости таких изменений следует прекратить действие плана, включая все его мероприятия, и создать новые экземпляры ресурса CarePlan и связанных с ним мероприятий.
11.3 Ресурс Goal - цель
11.3.1 Область применения и использования
Тип ресурса Goal используется для описания целевого состояния здоровья субъекта медицинской помощи, которое планируется достичь за заданный период или к заданному моменту времени. Это целевое состояние может достигаться в результате лечения или естественного восстановления организма с течением времени.
Например, целью ведения пациента с диабетом может быть концентрация показателя гликированного гемоглобина не выше 5,6% за три месяца в результате лекарственной терапии, контроля питания и увеличенной физической активности.
11.3.2 Структура ресурса
Ресурс Goal является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Goal представлен на рисунке 41 и в таблице 229.
Рисунок 41 - Ресурс Goal
Таблица 229
Состав элементов ресурса Goal
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Внешний идентификатор цели
Identifier
0..*
lifecycleStatus
Состояние жизненного цикла цели. Допустимые значения: proposed (предложена) | planned (запланирована) | accepted (принята) | active (действует) | on-hold (приостановлена) | completed (достигнута) | cancelled (отменена) | entered-in-error (введена по ошибке) | rejected (отклонена)
code
1
achievement-Status
Состояние достижения цели. Рекомендованные значения: in-progress (в процессе) | improving (улучшение) | worsening (ухудшение) | no-change (без изменений) | achieved (достигнута) | sustaining (необходимо поддерживать) | not-achieved (не достигнута) | no-progress (без динамики) | not-attainable (недостижима)
CodeableConcept
0..1
category
Категория цели
CodeableConcept
0..*
continuous
После достижения цели требуется поддержка
boolean
0..1
priority
Приоритет цели. Рекомендованные значения: high-priority (высокий приоритет) | medium-priority (умеренный приоритет) | low-priority (низкий приоритет)
CodeableConcept
0..1
description
Код или текст описания цели
CodeableConcept
1
subject
Ссылка на субъект цели
Reference
1
start[x]
Начало движения к цели
*
0..1
target
Целевой показатель
BackboneElement
0..*
target.measure
Код или наименование целевого параметра
CodeableConcept
0..1
target.detail[x]
Значение целевого параметра
*
0..1
target.due[x]
Ожидаемая дата или длительность достижения цели
*
0..1
statusDate
Дата перехода в текущее состояние
date
0..1
statusReason
Причина перехода в текущее состояние
string
0..1
source
Ссылка на лицо, ответственное за достижение цели
Reference
0..1
addresses
Ссылка на состояние/диагноз, в связи с которым поставлена цель
Reference
0..*
note
Примечание к цели
Annotation
0..*
outcome
Код достигнутого показателя или ссылка на него
CodeableReference
0..*
11.3.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 230.
Таблица 230
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Goal.lifecycleStatus
http://hl7.org/fhir/ValueSet/goal-status
Обязательная
Состояние жизненного цикла цели
Goal.achievementStatus
http://hl7.org/fhir/ValueSet/goal-achievement
Предпочтительная
Состояние достижения цели
Goal.category
http://hl7.org/fhir/ValueSet/goal-category
Пример
Категория цели
Goal.priority
http://hl7.org/fhir/ValueSet/goal-priority
Предпочтительная
Приоритет цели
Goal.description
http://hl7.org/fhir/ValueSet/clinical-findings
Пример
Коды состояний, проблем и диагнозов, определенные в номенклатуре SNOMED CT как потомки понятия с кодом 404684003
Goal.start[x]
http://hl7.org/fhir/ValueSet/goal-start-event
Пример
Начало движения к цели
Goal.target.measure
http://hl7.org/fhir/ValueSet/observation-codes
Пример
Все коды LOINC
Goal.outcome
http://hl7.org/fhir/ValueSet/clinical-findings
Пример
Коды состояний, проблем и диагнозов, определенные в номенклатуре SNOMED CT как потомки понятия с кодом 404684003
11.3.4 Ограничения ресурса Goal
Ограничения ресурса Goal описаны в таблице 231.
Таблица 231
Ограничения ресурса Goal
Идентификатор
Вид
Путь
Описание
Выражение
gol-1
Правило
Goal.target
Если элемент Goal.target.detail присутствует, то должен присутствовать элемент Goal.target.measure
(detail.exists() and measure.exists()) or detail.exists().not()
11.3.5 Параметры поиска экземпляров ресурса Goal
Специальные параметры поиска экземпляров ресурса Goal описаны в таблице 232. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 232
Специальные параметры поиска экземпляров ресурса Goal
Имя
Тип
Описание
Выражение
achievement-status
token
Состояние достижения цели
Goal.achievementStatus
addresses
reference
Ссылка на состояние/диагноз, в связи с которым поставлена цель
Goal.addresses
(Condition, RiskAssessment, MedicationRequest, NutritionOrder, Observation, Procedure, MedicationStatement, ServiceRequest)
category
token
Категория цели
Goal.category
description
token
Код или текст описания цели
Goal.description
identifier
token
Внешний идентификатор цели
Goal.identifier
lifecycle-status
token
Состояние жизненного цикла цели
Goal.lifecycleStatus
patient
reference
Ссылка на субъект цели - пациент
Goal.subject.where(resolve() is Patient) (Patient)
start-date
date
Дата начала движения к цели
(Goal.start.ofType(date))
subject
reference
Ссылка на субъект цели
Goal.subject
(Group, Organization, Patient)
target-date
date
Ожидаемая дата достижения цели
(Goal.target.due.ofType(date))
target-measure
token
Код или наименование целевого параметра
Goal.target.measure
11.3.6 Профиль цели дистанционного мониторинга пациента
Профиль цели дистанционного мониторинга пациента Goal-Dm ограничивает элементы ресурса Goal в соответствии с рисунком 42 и таблицей 233. Имя ресурса остается неизменным - Goal, имя профиля передается в элементе meta.profile.
Рисунок 42 - Профиль Goal-Dm
Таблица 233
Состав элементов профиля Goal-Dm
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание цели, ориентированное на пациента
Narrattive
0..1
text.status
Статус повествовательного содержания. Фиксированное значение "additional"
code
1
text.div
Текст в формате xhtml с ограниченным форматированием
xhtml
1
Собственные элементы
identifier
Уникальный идентификатор цели, присвоенный медицинской информационной системой
Identifier
1
lifecycleStatus
Состояние жизненного цикла цели. Допустимые значения: proposed (предложена) | planned (запланирована) | accepted (принята) | active (действует) | on-hold (приостановлена) | completed (достигнута) | cancelled (отменена) | entered-in-error (введена по ошибке) | rejected (отклонена)
code
1
description
Код или текст описания цели
CodeableConcept
1
subject
Ссылка на субъект цели
Reference
1
target
Целевой показатель
BackboneElement
0..*
target.measure
Код или наименование целевого параметра
CodeableConcept
1
target.detailRange
Диапазон значений целевого параметра
Range
1
statusDate
Дата перехода в текущее состояние
date
1
11.4 Ресурс ServiceRequest - назначение
11.4.1 Область применения и использования
В зависимости от значения элемента intent тип ресурса ServiceRequest описывает назначение, предложение или план диагностических и иных мероприятий, результаты которых представляются в виде экземпляров ресурсов Procedure (процедура), DiagnosticReport (заключение врача) и Observation (результат исследования).
Примерами мероприятий служат:
- диагностические исследования;
- эндоскопические процедуры;
- консультации;
- биопсии;
- хирургические процедуры;
- физиотерапевтические процедуры;
- патронаж;
- другие клинические вмешательства.
Основным применением ресурса ServiceRequest является обеспечение процессов назначения мероприятий в интересах одного пациента. Однако во многих случаях оказания медицинской помощи диагностические мероприятия выполняются для групп лиц, медицинских изделий и даже объектов окружающей среды. Состав ресурса ServiceRequest охватывает все эти случаи. Он может использоваться для передачи назначений врача или предложений по диагностике, сформированных системой поддержки медицинских решений. Его экземпляры могут использоваться для описания планируемых мероприятий в составе плана ведения пациента.
11.4.2 Структура ресурса
Ресурс ServiceRequest является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса ServiceRequest представлен на рисунке 43 и в таблице 234.
Рисунок 43 - Ресурс ServiceRequest
Таблица 234
Состав элементов ресурса ServiceRequest
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Идентификатор назначения
Identifier
0..*
instantiatesCanonical
Ссылка на экземпляр ресурса, описывающий определение назначения
canonical
0..*
instantiatesUri
Ссылка на внешнее определение назначения
uri
0..*
basedOn
Ссылка на требование, для выполнения которого предназначено назначения
Reference
0..*
replaces
Заменяемое назначение
Reference
0..*
requisition
Общий идентификатор группы связанных назначений или требований
Identifier
0..1
status
Состояние выполнения назначения. Допустимые значения: draft (в процессе подготовки) | active (действует) | on-hold (приостановлено) | revoked (отозвано) | completed (завершено) | entered-in-error (создано по ошибке) | unknown (неизвестное)
code
1
intent
Категория требования, с которым связано выполнение назначения. Допустимые значения: proposal (предложение) | plan (план) | directive (указание) | order (требование) | original-order (исходное требование) | reflex-order (вторичное требование) | filler-order (требование исполнителя) | instance-order (частичное требование) | option (опция)
code
1
partOf
Ссылка на мероприятие, частью которого является данное мероприятие
Reference
0..*
category
Классификация назначения
CodeableConcept
0..1
priority
Срочность назначения. Допустимые значения: routine (обычная) | urgent (ургентная) | asap (как можно скорее) | stat (немедленно). По умолчанию - обычная
code
0..1
doNot-Perform
Значение true указывает, что данное назначение в определенных случаях не должно выполняться. Эти случаи определяются значениями элементов code, occurrence, bodySite и performer. Например, если присутствует элемент occurrence - не должно выполняться в течение данного периода, если присутствует элемент performer - не должно выполняться данным исполнителем
boolean
0..1
code
Код назначения или ссылка на определение плана или действия
CodeableReference
0..1
orderDetail
Дополнительные детали и указания по выполнению назначения
BackboneElement
0..*
orderDetail.Parameter-Focus
Код контекста назначения или ссылка на контекст
CodeableReference
0..1
orderDetail.parameter
Дополнительная информация, требуемая для выполнения данного назначения
BackboneElement
1..*
orderDetail.parameter. code
Тип параметра, например, device-configuration (детали конфигурации прибора)
CodeableConcept
1
orderDetail.parameter.value[x]
Значение параметра
*
1
quantity[x]
Назначенное количество
*
0..1
subject
Ссылка на субъект назначения. Обычно субъектом является пациент, но им может быть группа лиц, устройство, например, гемодиализный аппарат, или даже местонахождение, например, при анализе окружающей среды
Reference
0..1
focus
Ссылка на фокус назначения, если он отличается от субъекта назначения, например, плод или донор
Reference
0..1
encounter
Ссылка на случай медицинской помощи
Reference
0..1
occurrence[x]
Ожидаемые дата и время выполнения назначения
*
0..1
asNeeded[x]
Признак выполнения назначения при необходимости или кодируемое условие выполнения
*
0..1
authoredOn
Дата и время создания данного экземпляра ресурса
dateTime
0..1
requester
Ссылка на инициатора назначения
Reference
0..1
performerType
Требуемый тип исполнителя назначения
CodeableConcept
0..1
performer
Ссылка на требуемого исполнителя назначения. Если указано несколько экземпляров данного элемента, то они трактуются как альтернативные исполнители без учета порядка указания. Если требуется несколько исполнителей, то ссылка должна указывать на экземпляр ресурса CareTeam
Reference
0..*
location
Ссылка на предпочтительное место выполнения назначения
CodeableReference
0..*
reason
Причина назначения - кодируемое значение типа CodeableConcept или ссылка на экземпляр ресурса Condition | Observation | DiagnosticReport | DocumentReference | DetectedIssue
CodeableReference
0..*
supportingInfo
Дополнительная клиническая информация
CodeableReference
0..*
insurance
Ссылка на страховой план, покрытие расходов или авторизацию, имеющую отношение к назначению
Reference
0..*
specimen
Ссылка на идентификацию и описание биоматериала
Reference
0..*
bodySite
Целевая анатомическая область назначенной процедуры
CodeableConcept
0..*
body-Structure
Ссылка на идентификацию и описание целевой анатомической области назначенной процедуры
Reference
0..1
note
Примечание
Annotation
0..*
patientInstruction
Указания в терминах, доступных пациенту, например, подготовка к проведению исследования или выполнению процедуры
BackboneElement
0..*
patientInstruction.instruction[x]
Содержание указаний
*
0..1
relevantHistory
Ссылка на экземпляр ресурса, описывающий динамику изменения назначения, например, переходы состояний выполнения
Reference
0..*
11.4.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 235.
Таблица 235
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
ServiceRequest.status
http://hl7.org/fhir/ValueSet/request-status
Обязательная
Состояние выполнения назначения
ServiceRequest.intent
http://hl7.org/fhir/ValueSet/request-intent
Обязательная
Категория требования, с которым связано выполнение назначения
ServiceRequest.category
http://hl7.org/fhir/ValueSet/servicerequest-category
Пример
Классификация назначения
ServiceRequest.priority
http://hl7.org/fhir/ValueSet/request-priority
Пример
Срочность назначения
ServiceRequest.code
http://hl7.org/fhir/ValueSet/procedure-code
Пример
Код процедуры
ServiceRequest.orderDetail.parameter.code
http://hl7.org/fhir/ValueSet/servicerequest-orderdetail-parameter-code
Пример
Тип параметра назначения
ServiceRequest.asNeeded[x]
http://hl7.org/fhir/Value Set/medication-as-needed-reason
Пример
Условие выполнения назначения
ServiceRequest.performerType
http://hl7.org/fhir/ValueSet/participant-role
Пример
Тип исполнителя назначения
ServiceRequest.location
ServiceDeliveryLocationRoleType
Пример
Место выполнения назначения
ServiceRequest.reason
http://hl7.org/fhir/ValueSet/procedure-reason
Пример
Причина назначения
ServiceRequest.bodySite
http://hl7.org/fhir/ValueSet/body-site
Пример
Анатомическая область
11.4.4 Ограничения ресурса ServiceRequest
Ограничения ресурса ServiceRequest описаны в таблице 236.
Таблица 236
Ограничения ресурса ServiceRequest
Идентификатор
Вид
Путь
Описание
Выражение
bdystr-1
Правило
Базовый
Элемент bodyStructure может присутствовать только в том случае, если элемент bodySite отсутствует
bodySite.exists() implies bodyStructure.empty()
prr-1
Правило
Базовый
Элемент orderDetail может присутствовать только в том случае, если элемент code присутствует
orderDetail.empty() or code.exists()
11.4.5 Параметры поиска экземпляров ресурса ServiceRequest
Специальные параметры поиска экземпляров ресурса ServiceRequest описаны в таблице 237. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 237
Специальные параметры поиска экземпляров
ресурса ServiceRequest
Имя
Тип
Описание
Выражение
authored
date
Дата и время создания экземпляра ресурса
ServiceRequest.authoredOn
based-on
reference
Ссылка на требование, для выполнения которого предназначено назначение
ServiceRequest.basedOn
(CarePlan, MedicationRequest, ServiceRequest)
body-site
token
Целевая анатомическая область назначенной процедуры
ServiceRequest.bodySite
body-structure
reference
Ссылка на идентификацию и описание целевой анатомической области назначенной процедуры
ServiceRequest.bodyStructure
(BodyStructure)
category
token
Классификация назначения
ServiceRequest.category
code-concept
token
Код назначения
ServiceRequest.code.concept
code-reference
reference
Ссылка на определение плана или действия
ServiceRequest.code.reference
encounter
reference
Ссылка на случай медицинской помощи
ServiceRequest.encounter
(Encounter)
identifier
token
Идентификатор назначения
ServiceRequest.identifier
instantiates-canonical
reference
Ссылка на экземпляр ресурса, описывающий определение назначения
ServiceRequest.instantiatesCanonical
(PlanDefinition, ActivityDefinition)
instantiates-uri
uri
Ссылка на внешнее определение назначения
ServiceRequest.instantiatesUri
intent
token
Категория требования, с которым связано выполнение назначения
ServiceRequest.intent
occurrence
date
Ожидаемые дата и время выполнения назначения
ServiceRequest.occurrence.ofType(dateTime) | ServiceRequest.occurrence.ofType(Period) | ServiceRequest.occurrence.ofType(Timing)
patient
reference
Ссылка на субъект назначения - пациент
ServiceRequest.subject.where(resolve() is Patient)
(Patient)
performer
reference
Ссылка на требуемого исполнителя
ServiceRequest.performer
(Practitioner, Organization, CareTeam, Device, Patient, HealthcareService, PractitionerRole, RelatedPerson)
performer-type
token
Тип исполнителя назначения
ServiceRequest.performerType
priority
token
Срочность назначения
ServiceRequest.priority
replaces
reference
Ссылка на заменяемое назначение
ServiceRequest.replaces
(ServiceRequest)
requester
reference
Заменяемые назначения
ServiceRequest.requester
(Practitioner, Organization, Device, Patient, PractitionerRole, RelatedPerson)
requisition
token
Идентификатор группы связанных назначений
ServiceRequest.requisition
specimen
reference
Ссылка на идентификацию и описание биоматериала
ServiceRequest.specimen
(Specimen)
status
token
Состояние выполнения назначения
ServiceRequest.status
subject
reference
Ссылка на субъект назначения
ServiceRequest.subject (Group, Device, Patient, Location)
11.5 Ресурс Task - мероприятие
11.5.1 Область применения и использования
Тип ресурса Task идентифицирует мероприятие и состояние его выполнения. Экземпляры ресурса Task могут использоваться при управлении рабочими процессами, включающими в себя комплексы связанных мероприятий по выполнению таких требований, как заказ лабораторных исследований, лекарственные назначения и т.д.
Экземпляр ресурса Task отражает шаг рабочего процесса, например отмену заказа, получение результата лабораторного исследования, заказ вторичных исследований в зависимости от полученного результата и т.д.
Основной предмет мероприятия описывается по ссылке, содержащейся в элементе focus. Для выполнения мероприятия могут требоваться определенные входные данные, передаваемые в элементе input. Результат выполнения мероприятия может быть передан в элементе output. Его содержание может служить входными данными для следующего мероприятия.
11.5.2 Структура ресурса
Ресурс Task является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Task представлен на рисунке 44 и в таблице 238.
Рисунок 44 - Ресурс Task
Таблица 238
Состав элементов ресурса Task
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifier-Extension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Идентификатор мероприятия
Identifier
0..*
instantiatesCanonical
Ссылка на экземпляр ресурса, описывающий определение мероприятия
canonical
0..*
instantiatesUri
Ссылка на внешнее определение мероприятия
uri
0..*
basedOn
Ссылка на требование, для выполнения которого предназначено мероприятие
Reference
0..*
groupIdentifier
Общий идентификатор группы мероприятий или требований
Identifier
0..1
partOf
Ссылка на мероприятие, частью которого является данное мероприятие
Reference
0..*
status
Состояние выполнения мероприятия. Допустимые значения: draft (в процессе подготовки) | requested (назначено) | received (получено исполнителем) | accepted (принято к исполнению) | rejected (отклонено) | ready (готово к выполнению) | cancelled (отменено) | in-progress (выполняется) | on-hold (приостановлено) | failed (прекращено) | completed (завершено) | entered-in-error (создано по ошибке)
code
1
statusReason
Причина перехода в данное состояние
Codeable-Concept
0..*
businessStatus
Детали состояния выполнения
Codeable-Concept
0..1
intent
Категория требования, с которым связано выполнение мероприятия. Допустимые значения: unknown (неизвестная) | proposal (предложение) | plan (план) | order (требование) | original-order (исходное требование) | reflex-order (вторичное требование) | filler-order (требование исполнителя) | instance-order (частичное требование) | option (опция). Значение этого элемента не должно изменяться после создания экземпляра ресурса Task
code
1
priority
Срочность мероприятия. Допустимые значения: routine (обычная) | urgent (ургентная) | asap (как можно скорее) | stat (немедленно). По умолчанию - обычная
code
0..1
doNotPerform
Значение true указывает, что данное мероприятие в определенных случаях не должно выполняться. Эти случаи определяются значениями элементов code, subject, occurrence, requestedPerformer и performer. Например, если присутствует элемент requestedPeriod - не должно выполняться в течение данного периода, если присутствует элемент requestedPerformer - не должно выполняться данным исполнителем
boolean
0..1
code
Тип мероприятия
Codeable-Concept
0..1
description
Описание мероприятия
string
0..1
focus
Ссылка на экземпляр ресурса, содержащий выполняемое требование или подлежащий манипуляции данным мероприятием. Если таких экземпляров должно быть несколько, следует использовать подчиненные мероприятия
Reference
0..1
for
Ссылка на экземпляр ресурса, для которого выполняется данное мероприятие
Reference
0..1
encounter
Ссылка на случай медицинской помощи
Reference
0..1
requestedPeriod
Ожидаемый период выполнения мероприятия
Period
0..1
executionPeriod
Фактический период выполнения мероприятия
Period
0..1
authoredOn
Дата и время создания данного экземпляра ресурса
dateTime
0..1
lastModified
Дата и время последнего изменения данного экземпляра ресурса
dateTime
0..1
requester
Ссылка на инициатора мероприятия
Reference
0..1
requestedPerformer
Ссылка на требуемого исполнителя мероприятия
Codeable-Reference
0..*
owner
Ссылка на ответственного за выполнение мероприятия
Reference
0..1
performer
Исполнитель мероприятия
Backbone-Element
0..*
performer. function
Функция исполнителя
Codeable-Concept
0..1
performer.actor
Ссылка на исполнителя мероприятия
Reference
1
location
Ссылка на место проведения мероприятия
Reference
0..1
reason
Причина мероприятия - кодируемое значение типа CodeableConcept или ссылка на экземпляр ресурса
Codeable-Reference
0..*
insurance
Ссылка на страховой план, покрытие расходов или авторизацию, имеющую отношение к мероприятию
Reference
0..*
note
Дополнительная информация об акте питания
Annotation
0..*
relevantHistory
Ссылка на экземпляр ресурса, описывающий динамику изменения мероприятия, например, переходы состояний выполнения
Reference
0..*
restriction
Ограничения на выполнение мероприятия
Backbone-Element
0..1
restriction.repetitions
Число повторений мероприятия
positiveInt
0..1
restriction.period
Требуемый период выполнения мероприятия. Должен содержаться в периоде, указанном в требовании, для выполнения которого предназначено данное мероприятие
Period
1
restriction.recipient
Если у требования, для выполнения которого предназначено данное мероприятие, несколько субъектов, то в этом элементе могут быть указаны конкретные субъекты, затрагиваемые данным мероприятием
Reference
0..*
input
Дополнительная информация, требуемая для выполнения данного мероприятия
Backbone-Element
0..*
input.type
Имя входного параметра
Codeable-Concept
1
input.value[x]
Значение входного параметра
*
1
output
Выходная информация, произведенная данным мероприятием
Backbone-Element
0..*
output.type
Имя выходного параметра
Codeable-Concept
1
output.value[x]
Значение выходного параметра
*
1
11.5.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 239.
Таблица 239
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Task.status
http://hl7.org/fhir/ValueSet/task-status
Обязательная
Состояние выполнения мероприятия
Task.statusReason
http://hl7.org/fhir/ValueSet/task-status-reason
Пример
Причина перехода в данное состояние
Task.intent
http://hl7.org/fhir/ValueSet/task-intent
Обязательная
Категория требования, с которым связано выполнение мероприятия
Task.priority
http://hl7.org/fhir/ValueSet/request-priority
Обязательная
Срочность мероприятия
Task.code
http://hl7.org/fhir/ValueSet/task-code
Пример
Тип мероприятия
Task.requestedPerformer
http://hl7.org/fhir/ValueSet/performer-role
Предпочтительная
Роль исполнителя
11.5.4 Ограничения ресурса Task
Ограничения ресурса Task описаны в таблице 240.
Таблица 240
Ограничения ресурса Task
Идентификатор
Вид
Путь
Описание
Выражение
tsk-1
Правило
Базовый
Элемент Task.restriction допустим, если мероприятие представляет собой выполнение действия над экземпляром ресурса, указанным в элементе focus
restriction.exists() implies code.coding.where(code='fulfill' and system='http://hl7.org/fhir/CodeSystem/task-code').exists() and focus.exists()
inv-1
Правило
Базовый
Значение элемента lastModified должно быть больше значения элемента authoredOn или равно ему
lastModified.exists().not() or authoredOn.exists().not() or lastModified >= authoredOn
11.5.5 Переходы состояний выполнения мероприятий
На рисунке 45 приведена "типичная" диаграмма перехода состояний мероприятия. На практике могут использоваться не все переходы, и некоторые переходы могут быть добавлены, включая обратные переходы из терминальных состояний (failed или completed) в состояние выполнения in-progress.
Рисунок 45 - Переходы состояний выполнения мероприятия
Вновь созданный экземпляр ресурса Task, идентифицирующий мероприятие, имеет состояние draft (в процессе подготовки). Если оказалось, что он создан по ошибке, то может быть переведен в состояние entered-in-error (создано по ошибке). Для подготовки к выполнению мероприятия может понадобиться несколько предварительных этапов, например назначение исполнителя (requested), получение исполнителем (received), принятие к исполнению (accepted). Вместо такой детализации переходов состояния мероприятию может быть присвоено состоянию ready (готово к выполнению). На любом из предварительных этапов мероприятие может быть отменено (cancelled). Из состояний ready и accepted возможен переход в состояние in-progress (выполняется). Выполнение мероприятия может быть приостановлено (on-hold) и возобновлено (обратный переход в состояние in-progress). Отменить уже начатое мероприятие нельзя - оно должно завершиться успешно (completed) или быть прекращено досрочно (failed).
11.5.6 Статистика переходов состояний
Экземпляр ресурса Task хранит текущее состояние выполнения мероприятия. Для анализа процесса выполнения мероприятия, например времени выполнения отдельных этапов, может понадобиться статистика переходов состояний. Такая статистика может сохраняться в экземплярах ресурса Provenance (происхождение), и ссылки на них могут храниться в элементах relevantHistory.
11.5.7 Параметры поиска экземпляров ресурса Task
ИС МЕГАНОРМ: примечание.
В официальном тексте документа, видимо, допущена опечатка: имеется в виду таблица 241, а не 227.
Специальные параметры поиска экземпляров ресурса Task описаны в таблице 227. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 241
Специальные параметры поиска экземпляров ресурса Task
Имя
Тип
Описание
Выражение
actor
reference
Ссылка на исполнителя мероприятия
Task.performer.actor (Practitioner, Organization, CareTeam, Patient, PractitionerRole, RelatedPerson)
authored-on
date
Дата создания
Task.authoredOn
based-on
reference
Ссылка на требование, для выполнения которого предназначено данное мероприятие
Task.basedOn (Any)
business-status
token
Детали состояния выполнения
Task.businessStatus
code
token
Тип мероприятия
Task.code
encounter
reference
Ссылка на случай медицинской помощи
Task.encounter (Encounter)
focus
reference
Ссылка на экземпляр ресурса, содержащий выполняемое требование или подлежащий манипуляции данным мероприятием
Task.focus (Any)
group-identifier
token
Общий идентификатор группы мероприятий или требований
Task.groupIdentifier
identifier
token
Идентификатор мероприятия
Task.identifier
intent
token
Категория требования, с которым связано выполнение мероприятия
Task.intent
modified
date
Дата и время последнего изменения
Task.lastModified
output
reference
Ссылка на экземпляр ресурса в выходных данных
Task.output.value.ofType(Reference)
owner
reference
Ссылка на ответственного за выполнение мероприятия
Task.owner (Practitioner, Organization, CareTeam, Patient, PractitionerRole, RelatedPerson)
part-of
reference
Ссылка на мероприятие, частью которого является данное мероприятие
Task.partOf (Task)
patient
reference
Ссылка на пациента
Task.for.where(resolve() is Patient) (Patient)
performer
token
Тип исполнителя мероприятия
Task.requestedPerformer.concept
period
date
Фактический период выполнения мероприятия
Task.executionPeriod
priority
token
Срочность мероприятия
Task.priority
requested-performer-reference
reference
Ссылка на требуемого исполнителя
Task.requestedPerformer.reference
requester
reference
Ссылка на инициатора мероприятия
Task.requester (Practitioner, Organization, Device, Patient, PractitionerRole, RelatedPerson)
status
token
Состояние мероприятия
Task.status
subject
reference
Ссылка на субъект мероприятия
Task.for (Any)
11.5.8 Профили мероприятий
Профили мероприятий, назначаемых в рамках планов дистанционного мониторинга пациентов, перечислены в таблице 242.
Таблица 242
Профили мероприятий дистанционного мониторинга
Имя профиля
Описание
Пункт
Task-Medication
Лекарственное назначение
Task-Phd
Выполнение измерений
Task-MedStat
Ведение дневника приема лекарств
Task-NutrInt
Ведение дневника питания
Task-QuestResp
Ведение дневника самонаблюдений
Task-DiagRep
Составление этапного эпикриза
Общая структура профилей мероприятий дистанционного мониторинга показана на рисунке 46 и приведена в таблице 243.
Рисунок 46 - Профиль мероприятий дистанционного мониторинга
Таблица 243
Состав элементов профиля мероприятий
дистанционного мониторинга
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
Унаследованы от абстрактного класса DomainResource
text
Полное описание мероприятия, ориентированное на пациента
Narrattive
1
text.status
Статус повествовательного содержания. Фиксированное значение "additional"
code
1
text.div
Текст в формате xhtml с ограниченным форматированием
xhtml
1
Собственные элементы
identifier
Идентификатор мероприятия, присвоенный медицинской информационной системой
Identifier
1
basedOn[1]
Ссылка на экземпляр ресурса CarePlan
Reference
1
basedOn[2]
Ссылка на экземпляр ресурса Questionnaire (только для ведения дневника самонаблюдений)
Reference
0..1
status
Состояние выполнения мероприятия. Допустимые значения: draft (в процессе подготовки) | requested (назначено) | received (получено исполнителем) | accepted (принято к исполнению) | rejected (отклонено) | ready (готово к выполнению) | cancelled (отменено) | in-progress (выполняется) | on-hold (приостановлено) | failed (прекращено) | completed (завершено) | entered-in-error (создано по ошибке)
code
1
intent
Категория требования, с которым связано выполнение мероприятия. Фиксированное значение "order" (требование)
code
1
code
Тип мероприятия
Codeable-Concept
1
description
Указания по выполнению мероприятия
string
1
for
Ссылка на экземпляр Person - субъект мероприятия
Reference
1
requestedPeriod
Ожидаемый период выполнения мероприятия
Period
1
requestedPerformer
Ссылка на требуемого исполнителя
CodeableReference
1
requestedPerformer.reference
Ссылка на экземпляр ресурса исполнителя
Reference
1
requestedPerformer.reference.reference
Относительный URL экземпляра ресурса
string
1
input
Входной параметр
Backbone-Element
0..*
input.type
Расписание выполнения мероприятия
CodeableConcept
1
input.type. text
Повествовательное описание расписания
string
1
input.valueTiming
Структурированное описание расписания
Timing
1
Профили отличаются друг от друга требованиями к заполнению следующих элементов:
- meta.profile - имя профиля;
- code - идентификация мероприятия;
- requestedPerformer - требуемый исполнитель.
11.5.9 Профиль Task-Medication
Профиль Task-Medication (лекарственное назначение) ограничивает элементы ресурса Task в соответствии с рисунком 46 и таблицей 243. Имя ресурса остается неизменным - Task, имя профиля передается в элементе meta.profile.
В элементе requestedPerformer (требуемый исполнитель) должна быть передана ссылка на экземпляр ресурса Patient, идентифицирующий лицо, применяющее назначенный лекарственный препарат (обычно сам пациент).
Требования к заполнению элемента code приведены в таблице 244. В первом экземпляре элемента code.coding должны быть переданы код анатомо-терапевтическо-химической классификации (АТХ) назначенного лекарственного препарата (при наличии). В следующих экземплярах элемента code.coding должны передаваться торговые наименования лекарственного препарата (синонимы). Международное непатентованное наименование должно передаваться в элементе code.text.
Таблица 244
Требования к заполнению элемента code
в профиле Task-Medication
Имя
Описание
Тип данных
Кратность
code.coding[1]
Анатомо-терапевтическо-химическая классификация назначенного лекарственного препарата
Coding
0..1
code.coding[1].system
Фиксированное значение "https://www.whocc.no" (при наличии кода АТХ)
uri
0..1
code.coding[1].code
Код АТХ (при наличии)
code
0..1
code.coding[2-n]
Торговое наименование лекарственного препарата
Coding
0..n-1
code.coding[2-n].display
Торговое наименование
string
1
code.text
Международное непатентованное наименование
string
1
11.5.10 Профиль Task-Phd
Профиль Task-Phd (выполнение измерений) ограничивает элементы ресурса Task в соответствии с рисунком 46 и таблицей 243. Имя ресурса остается неизменным - Task, имя профиля передается в элементе meta.profile.
В элементе requestedPerformer (требуемый исполнитель) должна быть передана ссылка на экземпляр ресурса Device, идентифицирующий персональный медицинский прибор, выполняющий измерения.
Требования к заполнению элемента code приведены в таблице 245.
Таблица 245
Требования к заполнению элемента code в профиле Task-Phd
Имя
Описание
Тип данных
Кратность
code.coding
Код специализации ПМП (таблица 246)
Coding
1
code.coding.system
Фиксированное значение "urn:iso:std:iso:11073:10101" (номенклатура терминов MDC, определенная в ГОСТ Р 56842)
uri
1
code.coding.code
Числовой код из номенклатуры MDC
code
1
code.coding.display
Мнемокод из номенклатуры MDC
string
1
code.text
Наименование специализации ПМП
string
1
Таблица 246
Коды специализации ПМП в номенклатуре MDC
Наименование специализации
Числовой код
Мнемокод
Активность при одиноком проживании
528455
MDC_DEV_SPEC_PROFILE_AI_ACTIVITY_HUB
Анализатор мочи
528406
MDC_DEV_SPEC_PROFILE_URINE_ANALYZER
Весы
528399
MDC_DEV_SPEC_PROFILE_SCALE
Глюкометр
528401
MDC_DEV_SPEC_PROFILE_GLUCOSE
Дыхательная терапия апноэ сна
528408
MDC_DEV_SPEC_PROFILE_SABTE
Инсулиновая помпа
528403
MDC_DEV_SPEC_PROFILE_INSULIN_PUMP
Коагулометр
528402
MDC_DEV_SPEC_PROFILE_COAG
Монитор кровяного давления
528391
MDC_DEV_SPEC_PROFILE_BP
Монитор медикаментов
528456
MDC_DEV_SPEC_PROFILE_AI_MED_MINDER
Монитор состава тела
528404
MDC_DEV_SPEC_PROFILE_BCA
Непрерывный мониторинг глюкозы
528409
MDC_DEV_SPEC_PROFILE_CGM
Пикфлоуметр
528405
MDC_DEV_SPEC_PROFILE_PEAK_FLOW
Пульсоксиметр
528388
MDC_DEV_SPEC_PROFILE_PULS_OXIM
Сердечно-сосудистый фитнес
528425
MDC_DEV_SPEC_PROFILE_HF_CARDIO
Силовой фитнес
528426
MDC_DEV_SPEC_PROFILE_HF_STRENGTH
Термометр
528392
MDC_DEV_SPEC_PROFILE_TEMP
Частота дыхания
528397
MDC_DEV_SPEC_PROFILE_RESP_RATE
Электрокардиограф (1 - 3 отведения)
528390
MDC_DEV_SPEC_PROFILE_MIN_ECG
11.5.11 Профиль Task-MedStat
Профиль Task-MedStat (ведение дневника приема лекарств) ограничивает элементы ресурса Task в соответствии с рисунком 46 и таблицей 243. Имя ресурса остается неизменным - Task, имя профиля передается в элементе meta.profile.
В элементе requestedPerformer (требуемый исполнитель) должна быть передана ссылка на экземпляр ресурса Patient, идентифицирующий лицо, заполняющее записи дневника (обычно сам пациент).
Требования к заполнению элемента code приведены в таблице 247.
Таблица 247
Требования к заполнению элемента code в профиле Task-MedStat
Имя
Описание
Тип данных
Кратность
code.coding
Тип мероприятия дистанционного мониторинга
Coding
1
code.coding. system
URI справочника типов мероприятий дистанционного мониторинга (URL или объектный идентификатор). Рекомендуемое значение "http://loinc.org"
uri
1
code.coding. code
Код мероприятия в справочнике. Рекомендуемое значение "87232-5"
code
1
code.coding. display
Наименование мероприятия в справочнике. Рекомендуемое значение "Medication administration.brief"
string
0..1
code.text
Фиксированное значение "Ведение дневника приема лекарств"
string
1
11.5.12 Профиль Task-NutrInt
Профиль Task-NutrInt (ведение дневника питания) ограничивает элементы ресурса Task в соответствии с рисунком 46 и таблицей 243. Имя ресурса остается неизменным - Task, имя профиля передается в элементе meta.profile.
В элементе requestedPerformer (требуемый исполнитель) должна быть передана ссылка на экземпляр ресурса Patient, идентифицирующий лицо, заполняющее записи дневника (обычно сам пациент).
Требования к заполнению элемента code приведены в таблице 248.
Таблица 248
Требования к заполнению элемента code в профиле Task-NutrInt
Имя
Описание
Тип данных
Кратность
code.coding
Тип мероприятия дистанционного мониторинга
Coding
1
code.coding. system
URI справочника типов мероприятий дистанционного мониторинга (URL или объектный идентификатор). Рекомендуемое значение "http://loinc.org"
uri
1
code.coding.code
Код мероприятия в справочнике. Рекомендуемое значение "84282-3"
code
1
code.coding. display
Наименование мероприятия в справочнике. Рекомендуемое значение "Nutrition and dietetics Patient's home Note"
string
0..1
code.text
Фиксированное значение "Ведение дневника питания"
string
1
11.5.13 Профиль Task-QuestResp
Профиль Task-QuestResp (ведение дневника самонаблюдений) ограничивает элементы ресурса Task в соответствии с рисунком 46 и таблицей 243. Имя ресурса остается неизменным - Task, имя профиля передается в элементе meta.profile.
В элементе requestedPerformer (требуемый исполнитель) должна быть передана ссылка на экземпляр ресурса Patient, идентифицирующий лицо, заполняющее записи дневника (обычно сам пациент). Во втором экземпляре элемента basedOn должна быть передана ссылка на экземпляр ресурса Questionnaire, описывающий форму дневника самонаблюдений.
Требования к заполнению элемента code приведены в таблице 249.
Таблица 249
Требования к заполнению элемента code
в профиле Task-QuestResp
Имя
Описание
Тип данных
Кратность
code.coding
Тип мероприятия дистанционного мониторинга
Coding
1
code.coding. system
URI справочника типов мероприятий дистанционного мониторинга (URL или объектный идентификатор). Рекомендуемое значение "http://loinc.org"
uri
1
code.coding.code
Код мероприятия в справочнике. Рекомендуемое значение "74465-6"
code
1
code.coding. display
Наименование мероприятия в справочнике. Рекомендуемое значение "Questionnaire response Document"
string
0..1
code.text
Фиксированное значение "Ведение дневника самонаблюдений"
string
1
11.5.14 Профиль Task-DiagRep
Профиль Task-DiagRep (составление этапного эпикриза) ограничивает элементы ресурса Task в соответствии с рисунком 46 и таблицей 243. Имя ресурса остается неизменным - Task, имя профиля передается в элементе meta.profile.
В элементе requestedPerformer (требуемый исполнитель) должна быть передана ссылка на экземпляр ресурса Practitioner, идентифицирующий лечащего врача, составляющего заключение.
Требования к заполнению элемента code приведены в таблице 250.
Таблица 250
Требования к заполнению элемента code в профиле Task-DiagRep
Имя
Описание
Тип данных
Кратность
code.coding
Тип мероприятия дистанционного мониторинга
Coding
1
code.coding. system
URI справочника типов мероприятий дистанционного мониторинга (URL или объектный идентификатор). Рекомендуемое значение "http://loinc.org"
uri
1
code.coding.code
Код мероприятия в справочнике. Рекомендуемое значение "75498-6"
code
1
code.coding. display
Наименование мероприятия в справочнике. Рекомендуемое значение "Telehealth Summary note"
string
0..1
code.text
Фиксированное значение "Составление этапного эпикриза"
string
1
11.6 Ресурс Subscription - подписка на изменения экземпляров ресурсов
11.6.1 Общие сведения
Экземпляр ресурса Subscription передается клиентом серверу для регистрации подписки на одну из тем, предоставляемых сервером в форме экземпляров ресурса SubscriptionTopic. Он содержит элементы данных, задающие канал передачи уведомлений по этой теме. Состав элементов ресурса Subscription описан в 10.3.6, состав элементов ресурса SubscriptionTopic - в 10.3.7.
В настоящем подразделе приведены примеры протоколов взаимодействия клиента и сервера при использовании каналов передачи уведомлений rest-hook и websocket.
11.6.2 Канал rest-hook
Диаграмма последовательности UML при использовании канала rest-hook приведена на рисунке 47.
Рисунок 47 - Взаимодействие при использовании
канала rest-hook
На диаграмме показан пример последовательности взаимодействий при подписке по каналу rest-hook:
а) клиент передает серверу запрос HTTP POST на создание экземпляра ресурса Subscription, в котором элементу channelType присвоено значение rest-hook, а элементу endpoint - адрес URL конечной точки клиента, поддерживающей протокол HTTP/S;
б) сервер возвращает клиенту созданный экземпляр ресурса Subscription, у которого элементу state присвоено значение requested (запрошена);
в) сервер отправляет запрос HTTP POST конечной точке, указанной клиентом в элементе Subscription.endpoint, с целью проверки соединения. Запрос содержит контейнер Bundle типа subscription-notification, содержащий экземпляр ресурса SubscriptionStatus, у которого элемент type имеет значение handshake;
г) конечная точка клиента принимает запрос и возвращает код успеха HTTP 200;
д) при циклических уведомлениях сервер передает конечной точке клиента запрос HTTP POST, содержащий уведомление в форме контейнера Bundle типа subscription-notification, не реже одного раза в течение интервала, указанного в элементе heartbeatPeriod;
е) конечная точка клиента принимает запрос и возвращает код успеха HTTP 200;
ж) при уведомлениях о событии сервер передает конечной точке клиента запрос HTTP POST, содержащий уведомление в форме контейнера Bundle типа subscription-notification, при возникновении события;
и) конечная точка клиента принимает запрос и возвращает код успеха HTTP 200.
В целях безопасности рекомендуется, чтобы сервер отказывал в регистрации подписки, если конечная точка клиента не обеспечивает взаимодействие по протоколу HTTPS.
11.6.3 Канал websocket
Диаграмма последовательности UML при использовании канала websocket приведена на рисунке 48.
Рисунок 48 - Взаимодействие при использовании
канала websocket
На диаграмме показана возможная последовательность взаимодействий при подписке по каналу websocket:
а) клиент передает серверу запрос HTTP POST на создание экземпляра ресурса Subscription, в котором элементу channelType присвоено значение websocket;
б) сервер возвращает клиенту созданный экземпляр ресурса Subscription, у которого элементу state присвоено значение active;
в) клиент запрашивает токен для соединения по веб-сокету, передавая запрос HTTP GET, в котором указано применение операции $get-ws-binding-token к созданному экземпляру ресурса Subscription;
г) сервер передает клиенту экземпляр ресурса Parameters, содержащий токен, время жизни токена и URL веб-сокета;
д) клиент соединяется с сервером по веб-сокету, используя возвращенный URL (предпочтительно имеющий протокол wss://);
е) клиент передает по веб-сокету сообщение bind-with-token;
ж) сервер возвращает клиенту по веб-сокету контейнер Bundle типа subscription-notification, содержащий экземпляр ресурса SubscriptionStatus, у которого элемент type имеет значение handshake;
и) при циклических уведомлениях сервер передает клиенту по веб-сокету уведомление в форме контейнера Bundle типа subscription-notification не реже одного раза в течение интервала, указанного в элементе heartbeatPeriod;
к) при уведомлениях о событии сервер передает клиенту по веб-сокету уведомление в форме контейнера Bundle типа subscription-notification при возникновении события;
л) по завершении сеанса "уведомление" клиент прекращает соединение по веб-сокету (это может сделать и сервер по истечении срока жизни токена).
Если сеанс должен быть продолжен, а срок жизни токена истекает, то клиент должен заново передать серверу запрос HTTP GET, в котором указано применение операции $get-ws-binding-token к созданному экземпляру ресурса Subscription. Сервер передаст клиенту ответ, содержащий токен, время жизни токена и URL веб-сокета. Токен и URL могут быть теми же или новыми.
11.7 Ресурс Device - сведения о медицинском изделии
11.7.1 Область применения и использования
Тип ресурса Device используется для передачи сведений об идентификации медицинского изделия и его местонахождении. Согласно статье 38 [34] медицинскими изделиями являются любые инструменты, аппараты, приборы, оборудование, материалы и прочие изделия, применяемые в медицинских целях отдельно или в сочетании между собой, а также вместе с другими принадлежностями, необходимыми для применения указанных изделий по назначению, включая специальное программное обеспечение, и предназначенные производителем для профилактики, диагностики, лечения и медицинской реабилитации заболеваний, мониторинга состояния организма человека, проведения медицинских исследований, восстановления, замещения, изменения анатомической структуры или физиологических функций организма, предотвращения или прерывания беременности, функциональное назначение которых не реализуется путем фармакологического, иммунологического, генетического или метаболического воздействия на организм человека.
Состав элементов ресурса Device позволяет передавать сведения и об изделиях немедицинского назначения, например, о смартфонах, компьютерах и программном обеспечении.
Изделие может быть отнесено к одной или нескольким категориям, например, коммуникационные изделия, медицинские аппараты, изделия для домашнего использования, для диагностики in vitro, имплантаты, одноразовые, многоразовые, программное обеспечение. Одним из классов коммуникационных изделий являются персональные медицинские приборы, используемые пациентами или иными лицами, не являющимися медицинскими работниками, в целях наблюдения за состоянием организма и передачи результатов наблюдения.
11.7.2 Структура ресурса
Ресурс Device является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Device представлен на рисунке 49 и в таблице 251.
Рисунок 49 - Ресурс Device
Таблица 251
Состав элементов ресурса Device
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifier-Extension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Идентификатор экземпляра медицинского изделия
Identifier
0..*
displayName
Наименование медицинского изделия, используемое по умолчанию для представления в элементе display ссылки на него
string
0..1
definition
Код описания медицинского изделия или ссылка на его описание
CodeableReference
0..1
udiCarrier
Уникальный идентификатор медицинского изделия (UDI)
BackboneElement
0..*
udiCarrier.deviceIdentifier
Обязательный фиксированный компонент UDI
string
1
udiCarrier.issuer
Идентификатор организации, присвоившей UDI
uri
1
udiCarrier.jurisdiction
Идентификатор организации, регулирующей применение UDI
uri
0..1
udiCarrier.carrierAIDC
Машиночитаемое представление штрихкода. Тип base64Binary используется в связи с тем, что оно может содержать символы, отсутствующие в представлении на языке XML
base64-Binary
0..1
udiCarrier.carrierHRF
Человеко-читаемое представление штрихкода. Если для представления модели изделия и его серийного номера используются отдельные штрихкоды, то их подписи должны быть объединены, и первой следует указать модель изделия
string
0..1
udiCarrier.entryType
Тип источника UDI. Допустимые значения: barcode (штрихкод) | rfid (радиочастотная метка) | manual (введен вручную с этикетки) | card (введен вручную с карточки имплантата) | self-reported (со слов пациента) | electronic-transmission (считан с медицинского прибора) | unknown (неизвестный)
code
0..1
status
Статус данного экземпляра ресурса. Допустимые значения: active (действителен) | inactive (недействителен) | entered-in-error (введен по ошибке)
code
0..1
availabilityStatus
Статус доступности медицинского изделия. Рекомендованные значения: lost (утрачен) | damaged (поврежден) | destroyed (уничтожен) | available (доступен)
CodeableConcept
0..1
biologicalSourceEvent
Идентификатор биологического источника
Identifier
0..1
manufacturer
Наименование производителя медицинского изделия
string
0..1
manufactureDate
Дата и время производства медицинского изделия
dateTime
0..1
expirationDate
Срок годности медицинского изделия
dateTime
0..1
lotNumber
Номер партии медицинских изделий
string
0..1
serialNumber
Серийный номер медицинского изделия
string
0..1
name
Наименование медицинского изделия
BackboneElement
0..*
name.value
Наименование
string
1
name.type
Тип наименования
code
1
name.display
Признак предпочтительного наименования
boolean
0..1
modelNumber
Номер модели медицинского изделия
string
0..1
partNumber
Артикул медицинского изделия
string
0..1
category
Категория медицинского изделия
CodeableConcept
0..*
type
Тип медицинского изделия
CodeableConcept
0..*
version
Модификация медицинского изделия или версия его программного обеспечения
BackboneElement
0..*
version.type
Тип модификации или версии
CodeableConcept
0..1
version.component
Идентификация аппаратного модуля или программного обеспечения, к которому относится данная версия
Identifier
0..1
version.install-Date
Дата установки аппаратного модуля или программного обеспечения
dateTime
0..1
version.value
Обозначение версии
string
1
conformsTo
Соответствие медицинского изделия стандартам или спецификациям
BackboneElement
0..*
conformsTo.category
Тип стандарта или спецификации
CodeableConcept
0..1
conformsTo.specification
Обозначение стандарта или спецификации
CodeableConcept
1
conformsTo.version
Версия стандарта или спецификации, например год публикации или номер
string
0..1
property
Статическое или практически постоянное свойство медицинского изделия, например разрешающая способность, точность, физические атрибуты
BackboneElement
0..*
property.type
Тип свойства
CodeableConcept
1
property.value[x]
Значение свойства
*
1
mode
Режим работы. Рекомендованные значения: normal (нормальный) | demo (демонстрационный) | service (сервисный) | maintenance (на обслуживании) | test (тестовый)
CodeableConcept
0..1
cycle
Количество циклов
Count
0..1
duration
Длительность
Duration
0..1
owner
Ссылка на организацию - владельца медицинского изделия
Reference
0..1
contact
Контактная информация технической поддержки
ContactPoint
0..*
location
Ссылка на местонахождение медицинского изделия
Reference
0..1
url
Сетевой адрес медицинского прибора
uri
0..1
endpoint
Ссылка на описание конечной точки, предназначенной для доступа к функциям медицинского изделия
Reference
0..*
gateway
Код типа менеджера или ссылка на описание менеджера
CodeableReference
0..*
note
Примечание
Annotation
0..*
safety
Класс безопасности медицинского изделия
CodeableConcept
0..*
parent
Ссылка на медицинское изделие, частью которого служит данное изделие
Reference
0..1
11.7.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 252.
Таблица 252
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Device.udiCarrier. entryType
http://hl7.org/fhir/ValueSet/udi-entry-type
Обязательная
Тип источника UDI
Device.status
http://hl7.org/fhir/ValueSet/device-status
Обязательная
Статус экземпляра ресурса Device
Device.availabilityStatus
http://hl7.org/fhir/ValueSet/device-availability-status
Расширяемая
Статус доступности медицинского изделия
Device.name.type
http://hl7.org/fhir/ValueSet/device-nametype
Обязательная
Тип наименования медицинского изделия
Device.category
http://hl7.org/fhir/ValueSet/device-category
Пример
Категория медицинского изделия
Device.type
http://hl7.org/fhir/ValueSet/device-type
Пример
Тип медицинского изделия
Device.version.type
http://hl7.org/fhir/ValueSet/device-versiontype
Пример
Тип модификации или версии
Device.conformsTo.category
http://hl7.org/fhir/ValueSet/device-specification-category
Пример
Тип стандарта или спецификации
Device.conformsTo.specification
http://hl7.org/fhir/ValueSet/device-specification-type
Пример
Обозначение стандарта или спецификации
Device.property.type
http://hl7.org/fhir/ValueSet/device-property-type
Пример
Тип свойства
Device.mode
http://hl7.org/fhir/ValueSet/device-operation-mode
Пример
Режим работы
Device.safety
http://hl7.org/fhir/ValueSet/device-safety
Пример
Класс безопасности прибора
11.7.4 Ограничения ресурса Device
Ограничения ресурса Device описаны в таблице 253.
Таблица 253
Ограничения ресурса Device
Идентификатор
Вид
Путь
Описание
Выражение
dev-1
Правило
Базовый
Признак Device.name.display должен быть истинным не более чем для одного экземпляра элемента Device.name
name.where(display=true).count() <= 1
11.7.5 Идентификация медицинских изделий и типы изделий
Почти всем изделиям присвоены различные идентификаторы и коды, обычно прикрепленные к самому изделию или к его упаковке. Они могут представлять собой напечатанные этикетки, таблички, штрих-коды или радиочастотные метки. Идентификаторы и коды могут присваиваться производителями или поставщиками изделий (например, серийный номер или артикул), другими организациями и реестрами. Эти идентификаторы и коды по возможности должны быть представлены в экземпляре ресурса Device. Это не всегда просто, поскольку в составе ресурса предусмотрено несколько семантически отличающихся элементов для представления кодов и идентификаторов, а в документации на изделия термины "код" и "идентификатор" могут быть перемешаны.
Элемент identifier предназначен только для идентификации экземпляра изделия, например с помощью инвентарного номера, присвоенного владельцем изделия. Для серийного номера, присвоенного производителем изделия, должен использоваться элемент serialNumber. Такие идентификаторы, как артикул или глобальный номер товарной продукции GTIN, представляют тип изделия и должны передаваться в элементе type.
Одним из источников типов изделий является глобальная номенклатура медицинских изделий GMDN (Global Medical Device Nomenclature, https://www.gmdnagency.org/).
Для машиночитаемой маркировки медицинских изделий в целях их прослеживания могут использоваться уникальные идентификаторы устройства UDI (Unique Device Identifier, https://www.imdrf.org/consultations/udi-system-medical-devices). Для хранения UDI предусмотрен элемент udiCarrier. В соответствии с [35] принята собственная система маркировки, согласно которой каждому изделию присваивается идентификатор, состоящий из четырех компонентов. Этот идентификатор также может быть представлен в элементе udiCarrier.
11.7.6 Параметры поиска экземпляров ресурса Device
Специальные параметры поиска экземпляров ресурса Device описаны в таблице 254. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 254
Специальные параметры поиска экземпляров ресурса Device
Имя
Тип
Описание
Выражение
biological-source-event
token
Идентификатор биологического источника
Device.biologicalSourceEvent
code
token
Код описания медицинского изделия
Device.definition.concept
definition
reference
Ссылка на описание медицинского изделия
Device.definition.reference
device-name
string
Поиск по строковым полям элемента Device.name или Device.type
Device.name.value | Device.type.coding.display | Device.type.text
expiration-date
date
Срок годности медицинского изделия
Device.expirationDate
identifier
token
Идентификатор экземпляра медицинского изделия
Device.identifier
location
reference
Ссылка на местонахождение прибора
Device.location
(Location)
lot-number
string
Номер партии медицинских изделий
Device.lotNumber
manufacture-date
date
Дата и время производства медицинского изделия
Device.manufactureDate
manufacturer
string
Наименование производителя медицинского изделия
Device.manufacturer
model
string
Номер модели медицинского изделия
Device.modelNumber
organization
reference
Ссылка на организацию - владельца медицинского изделия
Device.owner
(Organization)
parent
reference
Ссылка на медицинское изделие, частью которого служит данное изделие
Device.parent
(Device)
serial-number
string
Серийный номер медицинского изделия
Device.serialNumber | Device.identifier.where(type='SNO')
specification
token
Обозначение стандарта или спецификации
Device.conformsTo.specification
specification-version
composite
Комплекс из обозначения стандарта или спецификации и версии
On Device.conformsTo:
specification: specification
version: version
status
token
Статус данного экземпляра ресурса. Допустимые значения: active (действителен) | inactive (недействителен) | entered-in-error (введен по ошибке)
Device.status
type
token
Тип медицинского изделия
Device.type
udi-carrier
string
Человеко-читаемое представление штрихкода или радиометки, используемой для уникального идентификатора медицинского изделия
Device.udiCarrier.carrierHRF
udi-di
string
Обязательный фиксированный компонент UDI
Device.udiCarrier.deviceIdentifier
url
uri
Сетевой адрес медицинского прибора
Device.url
version
string
Обозначение версии
Device.version.value
11.7.7 Профиль Device-Phd
11.7.7.1 Общие требования
Аппаратное и программное обеспечение ПМП может содержать сведения о приборе, включая идентификацию ПМП. Эти сведения должны передаваться между участниками информационного взаимодействия по сценарию, показанному на рисунке 50.
Рисунок 50 - Сценарий передачи данных о ПМП
МИС передает сервису сведения о ПМП, предоставленном пациенту, в форме экземпляра ресурса Device. Пока пациент пользуется прибором, эти сведения могли измениться, например, обновилась прошивка прибора или загруженное в него программное обеспечение. Поэтому после установления связи со шлюзом Интернета вещей или с менеджером прибор может передать ему актуальные сведения о себе. Эта передача осуществляется в соответствии со стандартом ГОСТ Р 56845.
Шлюз или менеджер должен преобразовать сведения о ПМП в экземпляр ресурса Device и передать его сервису хранения и обработки результатов измерений. Сервис должен обновить сведения о ПМП в своем хранилище. По подписке обновленные сведения передаются МИС в форме экземпляра ресурса Device.
Если ПМП не имеет возможности передачи сведений по стандарту ГОСТ Р 56845, то шлюз или менеджер может сначала преобразовать сведения о ПМП в формат, предписанный этим стандартом, а затем преобразовать их в экземпляр ресурса Device. Описание преобразования, специфичного для ПМП с интерфейсом Bluetooth Low Energy, приведено в [36].
Рекомендуемый состав сведений о ПМП, передаваемых сервису хранения и обработки результатов измерений в форме экземпляра ресурса Device, включает в себя:
- идентификаторы ПМП;
- производителя, модель и серийный номер ПМП;
- идентификаторы и версии аппаратных и программных компонентов ПМП;
- специализации ПМП;
- ссылку на сведения о шлюзе или менеджере, взаимодействующем с ПМП.
11.7.7.2 Преобразование сведений о ПМП
Согласно стандарту ГОСТ Р 56845, состав сведений о ПМП определяется классом MDS (Medical device system - система медицинского прибора). Каждый ПМП обладает одним экземпляром класса MDS.
Атрибуты верхнего уровня класса MDS идентифицируются с помощью 32-разрядного целочисленного кода, принадлежащего номенклатуре MDC (medical device communication - коммуникация с медицинским прибором). Каждому целочисленному коду соответствует строковый номенклатурный код и его описание. Номенклатура MDC определена в стандарте ГОСТ Р 56842. Стандарты, описывающие специализации ПМП, могут содержать дополнения к номенклатуре MDC, которые еще не успели войти в текущую версию стандарта ГОСТ Р 56842.
ПМП передает шлюзу или менеджеру экземпляр класса MDS, который может использоваться для обеспечения эффективного взаимодействия с ПМП. Для передачи сервису хранения и обработки результатов измерений должна использоваться часть атрибутов этого класса, перечисленная в таблице 255.
Таблица 255
Атрибуты класса MDS, предназначенные для передачи сервису
хранения и обработки результатов измерений
Имя атрибута
Номенклатурный код
Тип атрибута
Примечание
Кратность
System-Model
MDC_ATTR_ID_MODEL
SystemModel
Производитель и модель ПМП
1
System-Id
MDC_ATTR_SYS_ID
OCTET STRING
Идентификатор ПМП в формате EUI-64
1
Production-Specification
MDC_ATTR_ID_PROD_SPECN
ProductionSpec
Список сведений о компонентах ПМП, включая серийные номера и т.д. в формате, заданном производителем
0..1
System-Type-Spec-List
MDC_ATTR_SYS_TYPE_SPEC_LIST
TypeVerList
Список специализаций ПМП
0..1
11.7.7.3 Отображение атрибута System-Model
Отображение атрибута System-Model на элементы ресурса Device приведено в таблице 256.
Таблица 256
Отображение атрибута System-Model на элементы ресурса Device
Номенклатурный код или имя компонента
Отображение на элемент ресурса Device
MDC_ID_MODEL_NUMBER
modelNumber
MDC_ID_MODEL_MANUFACTURER
manufacturer
11.7.7.4 Отображение атрибута System-Id
Отображение атрибута System-Id на компоненты элемента identifier ресурса Device приведено в таблице 257.
Таблица 257
Отображение атрибута System-Id на компоненты
элемента identifier ресурса Device
Компонент
Значение
identifier.system
"urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680"
identifier.type.coding.system
"http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDevice-Identifiers"
identifier.type.coding.code
"SYSID"
identifier.value
значение System-Id в формате EUI-64 (восемь пар шестнадцатеричных цифр, разделенных дефисами, например, FE-ED-AB-EE-DE-AD-77-C3)
11.7.7.5 Отображение атрибута Production-Specification
Атрибут Production-Specification содержит список сведений о приборе, тип которых определяется значением компонента spec-type. Отображение атрибута Production-Specification на элементы ресурса Device в зависимости от значения этого компоненты приведено в таблице 258.
Таблица 258
Отображение атрибута Production-Specification
на элементы ресурса Device
Экземпляр Production-Specification
Отображение на элементы ресурса Device
Production-Specification.spec-type = 1 (серийный номер)
Production-Specification.value
serialNumber=Production-Specification.value
Production-Specification.spec-type = 2 (номер партии)
Production-Specification.value
partNumber=Production-Specification.value
Production-Specification.spec-type = 3 (версия аппаратного обеспечения)
Production-Specification.value
version.type.coding.code="531974"
version.type.coding.system="urn.iso.std.
iso:11073:10101"
version.type.text="MDC_ID_PROD_SPEC_HW"
version.value=Production-Specification.value
Production-Specification.spec-type = 4 (программное обеспечение)
Production-Specification.PrivateOid
Production-Specification.value
version.type.coding.code="531975"
version.type.coding.system="urn.iso.std.
iso:11073:10101"
version.type.text="MDC_ID_PROD_SPEC_SW"
version.value=Production-Specification.value
Production-Specification.spec-type = 5 (версия прошивки)
Production-Specification.value
version.type.coding.code="531976"
version.type.coding.system="urn.iso.std.
iso:11073:10101"
version.type.text="MDC_ID_PROD_SPEC_FW"
version.value=Production-Specification.value
Production-Specification.spec-type = 6 (версия протокола)
Production-Specification.value
version.type.coding.code="531977"
version.type.coding.system="urn.iso.std.
iso:11073:10101"
version.type.text="MDC_ID_PROD_SPEC_PROTOCOL"
version.value=Production-Specification.value
11.7.7.6 Отображение атрибута System-Type-Spec-List
Атрибут System-Type-Spec-List содержит список специализаций прибора. Отображение атрибута System-Type-Spec-List на элементы ресурса Device приведено в таблице 259.
Таблица 259
Отображение атрибута System-Type-Spec-List
на элементы ресурса Device
Экземпляр System-Type-Spec-List
Отображение на элемент ресурса Device
System-Type-Spec-List.type
conformsTo.specification.coding.system ="urn.iso.std.iso:11073:10101"
conformsTo.specification.coding.code = System-Type-Spec-List.type
conformsTo.specification.coding.text=<значение номенклатурного кода MDC, соответствующее System-Type-Spec-List.type>
System-Type-Spec-List.version
conformsTo.specification.version= System-Type-Spec-List.version
11.7.7.7 Дополнительная информация о приборе
Шлюз Интернета вещей или менеджер ПМП должны дополнить сведения, полученные от ПМП, следующими атрибутами:
а) тип прибора;
б) идентификация шлюза или менеджера.
Тип прибора указывает, что это ПМП. Он отображается на элемент Device.type в соответствии с таблицей 260.
Таблица 260
Тип прибора (ПМП)
Элемент ресурса Device
Значение
Device.type.coding.code
"65573"
Device.type.coding.system
"urn.iso.std.iso:11073:10101"
Device.type.text
"MDC_MOC_VMS_MDS_SIMP"
Идентификация шлюза или менеджера отображается на элемент Device.gateway в соответствии с таблицей 261.
Таблица 261
Идентификация шлюза или менеджера
Элемент ресурса Device
Значение
Device.gateway.reference.type
"Device"
Device.gateway.reference.identifier.type.coding.system
"http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers"
Device.gateway.reference.identifier.type.coding.code
"SYSID"
Device.gateway.reference.identifier.system
"urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680"
Device.gateway.reference.identifier.value
значение System-Id в формате EUI-64 (восемь пар шестнадцатеричных цифр, разделенных дефисами, например, FE-ED-AB-EE-DE-AD-77-C3)
11.7.7.8 Состав элементов профиля Device-Phd
Профиль Device-Phd (персональный медицинский прибор) оставляет в ресурсе Device только те элементы, которые задействованы в 11.7.7.3 - 11.7.7.7 (рисунок 51 и таблица 262). Имя ресурса остается неизменным - Device, имя профиля передается в элементе meta.profile.
Рисунок 51 - Профиль Device-Phd
Таблица 262
Состав элементов профиля Device-Phd
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
Собственные элементы
identifier
Идентификатор медицинского прибора
Identifier
1
manufacturer
Наименование производителя медицинского изделия
string
0..1
serialNumber
Серийный номер медицинского прибора
string
0..1
modelNumber
Номер модели медицинского прибора
string
0..1
partNumber
Артикул медицинского прибора
string
0..1
type
Тип медицинского прибора
CodeableConcept
1
conformsTo
Специализация медицинского прибора
BackboneElement
0..*
conformsTo.category
Тип стандарта или спецификации
CodeableConcept
0..1
conformsTo.specification
Обозначение стандарта или спецификации
CodeableConcept
1
conformsTo.version
Версия стандарта или спецификации, например, год публикации или номер
string
0..1
gateway
Код типа менеджера (шлюза) или ссылка на описание менеджера (шлюза)
CodeableReference
0..1
11.7.8 Профиль Device-Phg
МИС передает сервису сведения о шлюзе Интернета вещей или менеджере ПМП, предоставленном пациенту, в форме экземпляра ресурса Device, соответствующего профилю Device-Phg (шлюз). Он используется только для проверки значения элемента Device.gateway, передаваемого в сведениях о ПМП. Состав элементов профиля Device-Phg приведен на рисунке 52 и в таблице 263. Имя ресурса остается неизменным - Device, имя профиля передается в элементе meta.profile.
Рисунок 52 - Профиль Device-Phg
Таблица 263
Состав элементов профиля Device-Phg
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
Собственные элементы
identifier
Идентификатор медицинского прибора
Identifier
1
type
Тип медицинского прибора (таблица 264)
CodeableConcept
1
note
Краткое описание медицинского прибора
Annotation
0..1
Тип прибора указывает, что это шлюз Интернета вещей или менеджер ПМП. Он отображается на элемент Device.type в соответствии с таблицей 264.
Таблица 264
Тип прибора (шлюз Интернета вещей или менеджер ПМП)
Элемент ресурса Device
Значение
Device.type.coding.code
"531981"
Device.type.coding.system
"urn.iso.std.iso:11073:10101"
Device.type.text
"MDC_MOC_VMS_MDS_AHD"
11.8 Ресурс DeviceAssociation - ассоциация медицинского изделия с пациентом
11.8.1 Область применения и использования
Тип ресурса DeviceAssociation используется для описания ассоциации медицинского изделия с субъектом и/или оператором. К числу медицинских изделий, для которых может понадобиться такое описание, относятся, например, имплантаты, каталки, персональные медицинские приборы.
Субъектами ассоциаций могут быть:
а) пациенты, использующие имплантаты, протезы, регистраторы активности, персональные медицинские приборы и т.д.;
б) группы лиц - некоторые персональные медицинские приборы, например, весы или тонометр, могут быть ассоциированы с членами семьи или группой лиц;
в) медицинские работники, использующие мобильные телефоны, планшеты и т.д.;
г) изделия - изделие может быть ассоциировано с другим изделием и при этом не являться его неотъемлемой частью. Примером может служить радиочастотная метка, используемая для отслеживания местонахождения каталки;
д) близкие лица - изделие, например, аварийный оповещатель, может быть ассоциировано с близким лицом пациента.
11.8.2 Структура ресурса
Ресурс DeviceAssociation является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса DeviceAssociation представлен на рисунке 53 и в таблице 265.
Рисунок 53 - Ресурс DeviceAssociation
Таблица 265
Состав элементов ресурса DeviceAssociation
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifier-Extension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Идентификатор ассоциации
Identifier
0..*
device
Ссылка на медицинское изделие, ассоциированное с пациентом или группой
Reference
1
category
Вид ассоциации
Codeable-Concept
0..*
status
Состояние ассоциации изделия с пациентом/группой
Codeable-Concept
1
statusReason
Причина перехода в данное состояние
Codeable-Concept
0..*
subject
Ссылка на лицо, группу лиц или изделие, с которым ассоциировано данное изделие
Reference
0..1
bodyStructure
Ссылка на анатомическую область субъекта, в которой или на которой находится медицинское изделие
Reference
0..1
period
Период ассоциации медицинского изделия с субъектом
Period
0..1
operation
Функционирование медицинского изделия
BackboneElement
0..*
operation.status
Состояние функционирования медицинского изделия
Codeable-Concept
1
operation.operator
Ссылка на оператора (лицо, использующее функции медицинского изделия)
Reference
0..*
operation.period
Период функционирования медицинского изделия
Period
0..1
11.8.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 266.
Таблица 266
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
DeviceAssociation.status
http://hl7.org/fhir/ValueSet/deviceassociation-status
Обязательная
Состояние ассоциации изделия
DeviceAssociation.statusReason
http://hl7.org/fhir/ValueSet/deviceassociation-status-reason
Обязательная
Причина состояния ассоциации
DeviceAssociation.operation.status
http://hl7.org/fhir/ValueSet/deviceassociation-operationstatus
Пример
Статус функционирования изделия
11.8.4 Параметры поиска экземпляров ресурса DeviceAssociation
Специальные параметры поиска экземпляров ресурса DeviceAssociation описаны в таблице 267. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 267
Специальные параметры поиска экземпляров
ресурса DeviceAssociation
Имя
Тип
Описание
Выражение
device
reference
Ссылка на изделие
DeviceAssociation.device
(Device)
identifier
token
Идентификатор ассоциации
DeviceAssociation.identifier
operator
reference
Ссылка на оператора
DeviceAssociation.operation.operator
(Practitioner, Patient, RelatedPerson)
patient
reference
Ссылка на пациента
DeviceAssociation.subject.where(resolve() is Patient)
status
token
Состояние ассоциации
DeviceAssociation.status
subject
reference
Ссылка на субъект ассоциации
DeviceAssociation.subject.where(resolve() is (Practitioner, Group, Device, Patient, RelatedPerson))
11.8.5 Профиль DeviceAssociation-Dm
Профиль DeviceAssociation-Dm ограничивает экземпляр ресурса DeviceAssociation элементами, необходимыми для привязки персонального медицинского прибора, шлюза Интернета вещей или менеджера ПМП к пациенту. Состав профиля DeviceAssociation-Dm приведен на рисунке 54 и в таблице 268. Имя ресурса остается неизменным - DeviceAssociation, имя профиля передается в элементе meta.profile.
Рисунок 54 - Профиль DeviceAssociation-Dm
Таблица 268
Состав элементов профиля DeviceAssociation-Dm
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
Собственные элементы
identifier
Уникальный идентификатор ассоциации, присвоенный медицинской информационной системой
Identifier
1
device
Ссылка на ПМП, шлюз или менеджер, ассоциированный с пациентом или группой
Reference
1
status
Состояние ассоциации прибора с пациентом/группой
CodeableConcept
1
status.coding
Кодированное значение
Coding
1
status.coding.system
Фиксированное значение "http://hl7.org/fhir/deviceassociation-status"
uri
1
status.coding.code
Фиксированное значение "unknown" (неизвестно)
code
1
subject
Ссылка на лицо, группу лиц, с которыми ассоциирован данный прибор
Reference
0..1
period
Период ассоциации медицинского прибора с субъектом
Period
0..1
11.9 Ресурс DeviceDefinition - описание медицинского изделия
11.9.1 Область применения и использования
Тип ресурса DeviceDefinition используется для описания общих характеристик и функций определенной модели изделия или класса изделий, например, модели персонального кардиомонитора. Он применяется в основном для описания медицинских изделий, но может описывать смартфоны, компьютеры, программное обеспечение и т.д. Экземпляр ресурса DeviceDefinition содержит описание изделия, обычно включаемого в каталоги или регистрационные удостоверения. При необходимости с его помощью можно описывать составные части изделия.
Примечание - Поскольку тип ресурса Device предназначен для описания конкретного экземпляра изделия, в нем предусмотрены такие элементы, как номер партии или серийный номер. Подобные элементы в типе ресурса DeviceDefinition отсутствуют.
11.9.2 Структура ресурса
Ресурс DeviceDefinition является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса DeviceDefinition представлен на рисунке 55 и в таблице 269.
Рисунок 55 - Ресурс DeviceDefinition
Таблица 269
Состав элементов ресурса DeviceDefinition
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
description
Дополнительная информация о медицинском изделии
markdown
0..1
identifier
Идентификатор модели медицинского изделия
Identifier
0..*
udiDeviceIdentifier
Уникальный идентификатор медицинского изделия (UDI). Предназначен для штрих-кодирования
BackboneElement
0..*
udiDeviceIdentifier.deviceIdentifier
Идентификатор каждого изделия, на которое распространяется данное описание. Назначается организацией, присваивающей идентификаторы на данной территории
string
1
udiDeviceIdentifier.issuer
Идентификатор организации, присвоившей UDI
uri
1
udiDeviceIdentifier.jurisdiction
Идентификатор организации, регулирующей применение UDI
uri
1
udiDeviceIdentifier.marketDistribution
Сведения о вводе в обращение
BackboneElement
0..*
udiDeviceIdentifier.marketDistribution.marketPeriod
Период обращения
Period
1
udiDeviceIdentifier.marketDistribution.subJurisdiction
Территория обращения
uri
1
regulatoryIdentifier
Идентификация регистрационного удостоверения
BackboneElement
0..*
regulatoryIdentifier.type
Тип регистрации: basic (обычная) | master (генеральная) | license (лицензия)
code
1
regulatoryIdentifier.deviceIdentifier
Номер регистрационного удостоверения
string
1
regulatoryIdentifier.issuer
Идентификация регуляторного органа
uri
1
regulatoryIdentifier.jurisdiction
Идентификация территории регистрации
uri
1
partNumber
Артикул медицинского изделия
string
0..1
manufacturer
Ссылка на идентификацию производителя медицинского изделия
Reference
0..1
deviceName
Наименование медицинского изделия у производителя
BackboneElement
0..*
deviceName.name
Наименование медицинского изделия
string
1
deviceName.type
Тип наименования: registered-name (наименование в регистрационном удостоверении) | user-friendly-name (краткое наименование для пользователя) | patient-reported-name (наименование для пациента)
code
1
modelNumber
Артикул модели медицинского изделия
string
0..1
classification
Классификация медицинского изделия
BackboneElement
0..*
classification.type
Классификация модели медицинского изделия или класс риска
CodeableConcept
1
classification.Justification
Уточнение классификации медицинского изделия
RelatedArtifact
0..*
conformsTo
Соответствие медицинского изделия стандартам или спецификациям
BackboneElement
0..*
conformsTo.category
Тип стандарта или спецификации
CodeableConcept
0..1
conformsTo.specification
Обозначение стандарта или спецификации, которой соответствует медицинское изделие
CodeableConcept
1
conformsTo.version
Версия стандарта или спецификации, например, год публикации или номер
string
0..*
conformsTo.source
Стандарт, нормативный документ, методические указания или иная публикация, содержащая описание соответствия
RelatedArtifact
0..*
hasPart
Составная часть данного медицинского изделия
BackboneElement
0..*
hasPart.reference
Ссылка на описание составной части медицинского изделия
Reference
1
hasPart.count
Количество экземпляров составной части в данном медицинском изделии
integer
0..1
packaging
Сведения об упаковке медицинского изделия
BackboneElement
0..*
packaging.identifier
Идентификатор упаковки медицинского изделия
Identifier
0..1
packaging.type
Вид упаковки
CodeableConcept
0..1
packaging.count
Количество экземпляров изделия в упаковке
integer
0..1
packaging. distributor
Поставщик упакованного медицинского изделия
BackboneElement
0..*
packaging. distributor. name
Наименование поставщика
string
0..1
packaging. distributor. organization-Reference
Ссылка на экземпляр ресурса Organization со сведениями о поставщике
Reference
0..*
packaging.udiDevice-Identifier
Уникальный идентификатор медицинского изделия (UDI). Предназначен для штрих-кодирования
udiDeviceIdentifier
0..*
packaging. packaging
Вложенная упаковка
packaging
0..*
version
Версия медицинского изделия или программного обеспечения
BackboneElement
0..*
version.type
Тип версии, например, присвоена производителем, одобрена регуляторным органом, внутренняя
CodeableConcept
0..1
version.component
Идентификатор аппаратного или программного модуля изделия, к которому относится версия
Identifier
0..1
version.value
Идентификатор версии
string
1
safety
Класс безопасности медицинского изделия
CodeableConcept
0..*
shelfLifeStorage
Срок годности и требования к хранению
BackboneElement
0..*
shelfLifeStorage.type
Тип срока годности, например, срок годности упакованного изделия, срок годности после распаковки и т.д.
CodeableConcept
0..1
shelfLifeStorage.period[x]
Срок годности. Допустимы варианты periodDuration (длительность типа Duration) | periodString (текстовое описание типа string)
*
0..1
shelfLifeStorage.special-Precautions-ForStorage
Требования к хранению. Если требования взяты из справочника, то должны быть указаны код и его значение
CodeableConcept
0..*
languageCode
Код языка человеко-читаемого текста, выводимого изделием
CodeableConcept
0..*
property
Характеристика медицинского изделия, например, разрешающая способность, точность, размеры
BackboneElement
0..*
property.type
Вид характеристики
CodeableConcept
1
property.value[x]
Значение характеристики. Допустимые варианты элемента: valueQuantity | valueCodeableConcept | valueString | valueBoolean | valueInteger | valueRange | valueAttachment
*
1
owner
Ссылка на организацию - владельца медицинского изделия
Reference
0..1
contact
Контактная информация технической поддержки
ContactPoint
0..*
link
Ассоциированное изделие, например присоединенное к данному изделию, взаимодействующее с ним, заменяющее его
BackboneElement
0..*
link.relation
Вид ассоциации с данным изделием
Coding
1
link.related-Device
Ссылка на описание ассоциированного изделия или код вида ассоциированного изделия
CodeableReference
1
note
Примечание
Annotation
0..*
material
Субстанция, использованная для производства материала или материалов, из которых изготовлено изделие
BackboneElement
0..*
material.substance
Субстанция, которую изделие содержит или может содержать либо из которой оно изготовлено
CodeableConcept
1
material.alternate
Признак альтернативы
boolean
0..1
material.allergenicIndicator
Признак аллергенности
boolean
0..1
productionIdentifierInUDI
Вид идентификатора, представленного штрихкодом. Допустимые значения: lot-number (партия) | manufactured-date (дата производства) | serial-number (серийный номер) | expiration-date (срок годности) | biological-source (биологический источник) | software-version (версия программного обеспечения)
code
0..*
guideline
Руководство по применению данной модели изделия
BackboneElement
0..1
guideline.useContext
Условие использования
UsageContext
0..*
guideline.usageInstruction
Детальные указания по применению
markdown
0..1
guideline.relatedArtifact
Источник информации или ссылка на руководство
RelatedArtifact
0..*
guideline.indication
Показания к применению
CodeableConcept
0..*
guideline.contraindication
Противопоказания к применению
CodeableConcept
0..*
guideline warning
Предостережение
CodeableConcept
0..*
guideline.intendedUse
Основное назначение медицинского изделия
string
0..1
correctiveAction
Прослеживание последнего корректирующего действия по обеспечению безопасности
BackboneElement
0..1
correctiveAction.recall
Является ли корректирующее действие отзывом изделия
boolean
1
correctiveAction.scope
Охват действия: model (модель) | lot-numbers (партии) | serial-numbers (серийные номера)
code
0..1
correctiveAction.period
Даты начала и завершения корректирующего действия
Period
1
chargeItem
Код оплаты или ссылка на сведения об оплате, относящиеся к данной модели изделия
BackboneElement
0..*
chargeItemCode
Код оплаты или ссылка на сведения об оплате
CodeableReference
1
count
Коэффициент, применяемый к коду оплаты
Quantity
1
effectivePeriod
Период оплаты
Period
0..1
useContext
Контекст оплаты
UsageContext
0..*
11.9.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 270.
Таблица 270
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
DeviceDefinition.regulatoryIdentifier.type
http://hl7.org/fhir/ValueSet/devicedefinition-regulatory-identifier-type
Обязательная
Тип регистрации медицинского изделия
DeviceDefinition.deviceName.type
http://hl7.org/fhir/ValueSet/device-nametype
Обязательная
Тип наименования медицинского изделия
DeviceDefinition.classification.type
http://hl7.org/fhir/ValueSet/device-type
Пример
Тип медицинского изделия. Включает понятия, определенные в номенклатуре SNOMED CT (http://www.snomed.org/) с кодом 49062001 и дочерними кодами
DeviceDefinition.conformsTo.category
http://hl7.org/fhir/ValueSet/device-specification-category
Пример
Тип стандарта или спецификации
DeviceDefinition.conformsTo.specification
http://hl7.org/fhir/ValueSet/device-specification-type
Пример
Обозначение стандарта или спецификации
DeviceDefinition.safety
http://hl7.org/fhir/ValueSet/device-safety
Пример
Класс безопасности медицинского изделия
DeviceDefinition.property.type
http://hl7.org/fhir/ValueSet/device-property-type
Пример
Вид характеристики медицинского изделия
DeviceDefinition.link.relation
http://hl7.org/fhir/ValueSet/devicedefinition-relationtype
Расширяемая
Вид ассоциации с данным изделием
DeviceDefinition.productionIdentifierInUDI
http://hl7.org/fhir/ValueSet/device-productidentifierinudi
Обязательная
Вид идентификатора медицинского изделия, представленного штрих-кодом
DeviceDefinition.correctiveAction.scope
http://hl7.org/fhir/ValueSet/device-correctiveactionscope
Обязательная
Охват корректирующего действия
11.9.4 Параметры поиска экземпляров ресурса DeviceDefinition
Специальные параметры поиска экземпляров ресурса DeviceDefinition описаны в таблице 271. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 271
Специальные параметры поиска экземпляров
ресурса DeviceDefinition
Имя
Тип
Описание
Выражение
device-name
string
Поиск по строковым полям элементов DeviceDefinition.name или DeviceDefinition.classification.type. Способ реализации зависит от сервера
DeviceDefinition.deviceName.name | DeviceDefinition.classification.type.coding.display | DeviceDefinition.classification.type.text
identifier
token
Идентификатор модели медицинского изделия
DeviceDefinition.identifier
manufacturer
reference
Ссылка на идентификацию производителя медицинского изделия
DeviceDefinition.manufacturer
(Organization)
organization
reference
Ссылка на организацию - владельца медицинского изделия
DeviceDefinition.owner
(Organization)
specification
token
Обозначение стандарта или спецификации, которой соответствует медицинское изделие
DeviceDefinition.conformsTo.specification
specification-version
composite
Сочетание обозначения стандарта или спецификации и версии
DeviceDefinition.conformsTo:
specification: specification
version: version
type
token
Тип стандарта или спецификации
DeviceDefinition.conformsTo.category
11.10 Ресурс DeviceMetric - измерительная способность медицинского прибора
11.10.1 Область применения и использования
Тип ресурса DeviceMetric используется для описания динамических свойств медицинского прибора, характеризующих его настройку или измерительную способность (метрику), в том числе непосредственную или вычисляемую. Кроме того, с его помощью можно описать операционный статус метрики, тип калибровки, время последней калибровки, состояние калибровки, цвет графика при выводе на монитор.
11.10.2 Структура ресурса
Ресурс DeviceMetric является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса DeviceMetric представлен на рисунке 56 и в таблице 272.
Рисунок 56 - Ресурс DeviceMetric
Таблица 272
Состав элементов ресурса DeviceMetric
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Идентификатор метрики
Identifier
0..*
type
Идентификация метрики
CodeableConcept
1
unit
Единица измерения
CodeableConcept
0..1
device
Ссылка на медицинский прибор
Reference
1
operationalStatus
Операционный статус. Допустимые значения: on (метрика функционирует, и результаты будут передаваться) | off (метрика не функционирует) | standby (метрика функционирует, но передача результатов приостановлена) | entered-in-error (метрика введена по ошибке)
code
0..1
color
Наименование цвета отображения на мониторе или графике (из системы CSS Color Module Level 4) либо код цвета в системе RGB (#RRGGBB в шестнадцатеричной системе)
code
0..1
category
Категория метрики. Допустимые значения: measurement (измерение) | setting (параметр прибора) | calculation (вычисление) | unspecified (неизвестная)
CodeableConcept
1
measurementFrequency
Частота опроса
Quantity
0..1
calibration
Калибровка
BackboneElement
0..*
type
Тип калибровки. Допустимые значения: unspecified (не указан) | offset (сдвиг) | gain (коэффициент) | two-point (сдвиг и коэффициент)
code
0..1
state
Состояние калибровки. Допустимые значения: not-calibrated (не калибрована) | calibration-required (требуется калибровка) | calibrated (калибрована) | unspecified (не указано)
code
0..1
time
Дата и время последней калибровки
instant
0..1
11.10.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 273.
Таблица 273
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
DeviceMetric.type
http://hl7.org/fhir/ValueSet/devicemetric-type
Предпочтительная
Подмножество кодов номенклатуры терминов MDC, определенной в ГОСТ Р 56845, описывающее типы метрик и их компонентов, а также единицы измерения
DeviceMetric.unit
http://hl7.org/fhir/ValueSet/ucum-units
Предпочтительная
Коды, определенные в системе UCUM (Unified Code for Units of Measure - унифицированные коды единиц измерения)
DeviceMetric.operationalStatus
http://hl7.org/fhir/ValueSet/metric-operational-status
Обязательная
Операционный статус метрики
DeviceMetric.color
http://hl7.org/fhir/ValueSet/color-codes
Обязательная
Наименование цвета из системы CSS Color Module Level 4 либо код цвета в системе RGB (#RRGGBB в шестнадцатеричной системе)
DeviceMetric.category
http://hl7.org/fhir/ValueSet/metric-category
Обязательная
Категория метрики
DeviceMetric.calibration.type
http://hl7.org/fhir/ValueSet/metric-calibration-type
Обязательная
Тип калибровки
DeviceMetric.calibration.state
DeviceMetric-CalibrationState
Обязательная
Состояние калибровки
11.10.4 Параметры поиска экземпляров ресурса DeviceMetric
Специальные параметры поиска экземпляров ресурса DeviceMetric описаны в таблице 274. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 274
Специальные параметры поиска экземпляров
ресурса DeviceMetric
Имя
Тип
Описание
Выражение
category
token
Категория метрики
DeviceMetric.category
device
reference
Ссылка на медицинский прибор
DeviceMetric.device
(Device)
identifier
token
Идентификатор метрики
DeviceMetric.identifier
type
token
Тип метрики
DeviceMetric.type
11.11 Ресурс Observation - результат исследования
11.11.1 Область применения и использования
Тип ресурса Observation используется для передачи результатов клинических исследований, в том числе:
а) жизненно важные показатели, например вес, температура, артериальное давление;
б) результаты лабораторных анализов, например концентрация глюкозы в капиллярной крови;
в) медицинские изображения;
г) результаты измерений, выполненных медицинским прибором, например, кардиографом или пульсоксиметром;
д) настройка приборов, например ИВЛ;
е) оценка по шкалам и индексам, например по шкале комы Глазго или шкале Апгар.
Тип ресурса Observation не должен использоваться, если клиническая информация может быть передана с помощью других ресурсов; например, ресурс AllergyIntolerance описывает аллергии пациента, ресурс MedicationStatement - применение лекарственного препарата, ресурс FamilyMemberHistory - семейный анамнез; ресурс Procedure - сведения о выполненной процедуре, ресурс QuestionnaireResponse - ответы на вопросник, ресурс Condition - диагноз или общее состояние пациента, ресурс ClinicalImpression - клиническое описание.
11.11.2 Структура ресурса
Ресурс Observation является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Observation представлен на рисунке 57 и в таблице 275.
Рисунок 57 - Ресурс Observation
Таблица 275
Состав элементов ресурса Observation
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Идентификатор результата исследования
Identifier
0..*
instantiates[x]
Ссылка на определение исследования
*
0..1
basedOn
Ссылка на план или требование, для выполнения которого предназначено данное исследование
Reference
0..*
triggeredBy
Исследование, инициировавшее данное исследование
BackboneElement
0..*
triggeredBy.observation
Ссылка на экземпляр ресурса Observation
Reference
1
triggeredBy.type
Тип инициации. Допустимые значения: reflex (в связи с результатом исследования) | repeat (повторение исследования с теми же настройками) | re-run (повторение исследования с другими настройками)
code
1
triggeredBy. reason
Описание причины инициации исследования
string
0..1
partOf
Ссылка на исследование, частью которого является данное исследование
Reference
0..*
status
Состояние исследования. Допустимые значения: registered (исследование выполнено, но результат пока не доступен) | preliminary (предварительный результат, может быть неполным или не проверенным) | final (исследование выполнено и результат доступен) | amended (результат выполненного исследования изменен или дополнен) | corrected (исправлена ошибка в результате исследования) cancelled (исследование отменено) | entered-in-error (результат исследования введен по ошибке) | unknown (состояние результата исследования не известно)
code
1
category
Категория исследования
CodeableConcept
0..*
code
Вид исследования
CodeableConcept
1
subject
Ссылка на субъект исследования
Reference
0..1
focus
Ссылка на экземпляр ресурса, описывающего предмет исследования, если он отличается от субъекта
Reference
0..*
encounter
Ссылка на случай медицинской помощи
Reference
0..1
effective[x]
Физиологически релевантные дата и время либо период, к которому относится результат исследования (например, дата и время взятия биоматериала)
*
0..1
issued
Дата и время доступности текущей версии результата исследования
instant
0..1
performer
Ссылка на исполнителя исследования
Reference
0..*
value[x]
Результат исследования
*
0..1
dataAbsent-Reason
Причина отсутствия результата исследования
CodeableConcept
0..1
interpretation
Интерпретация результата исследования (норма, выше нормы и т.д.)
CodeableConcept
0..*
note
Примечание к исследованию
Annotation
0..*
bodySite
Код анатомической области субъекта, к которой относится результат исследования
CodeableConcept
0..1
bodyStructure
Ссылка на описание анатомической области субъекта, к которой относится результат исследования
Reference
0..1
method
Методика исследования
CodeableConcept
0..1
specimen
Ссылка на идентификацию исследованного биоматериала
Reference
0..1
device
Ссылка на медицинский прибор, с помощью которого получен результат исследования, или на его измерительную способность
Reference
0..1
referenceRange
Справочный диапазон
BackboneElement
0..*
referenceRange. low
Нижняя граница диапазона
SimpleQuantity
0..1
referenceRange. high
Верхняя граница диапазона
SimpleQuantity
0..1
referenceRange. normalValue
Качественное значение нормы (например, 'отрицательный результат')
CodeableConcept
0..1
referenceRange. type
Вид справочного диапазона
CodeableConcept
0..1
referenceRange. appliesTo
Популяция для данного справочного диапазона
CodeableConcept
0..*
referenceRange. age
Возрастная группа (диапазон)
Range
0..1
referenceRange. text
Повествовательное описание справочного диапазона
markdown
0..1
hasMember
Ссылка на экземпляр ресурса, являющийся частью результата данного исследования, например на запись дневника самонаблюдений
Reference
0..*
derivedFrom
Ссылка на экземпляр ресурса, используемого для получения данного результата исследования
Reference
0..*
component
Компонент результата исследования
BackboneElement
0..*
component.code
Вид исследования
CodeableConcept
1
component. value[x]
Результат исследования
-
0..1
component.dataAbsentReason
Причина отсутствия результата исследования
CodeableConcept
0..1
component.interpretation
Интерпретация результата исследования (норма, выше нормы и т.д.)
CodeableConcept
0..*
component.referenceRange
Справочный диапазон
BackboneElement
0..*
component.referenceRange.low
Нижняя граница диапазона
Simple-Quantity
0..1
component.referenceRange. high
Верхняя граница диапазона
Simple-Quantity
0..1
component.referenceRange.normalValue
Качественное значение нормы (например, 'отрицательный результат')
CodeableConcept
0..1
component.referenceRange. type
Вид справочного диапазона
CodeableConcept
0..1
component.referenceRange.appliesTo
Популяция для данного справочного диапазона
CodeableConcept
0..*
component.referenceRange.age
Возрастная группа (диапазон)
Range
0..1
component.referenceRange.text
Повествовательное описание справочного диапазона
markdown
0..1
11.11.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 276.
Таблица 276
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Observation. triggeredBy.type
http://hl7.org/fhir/ValueSet/observation-triggeredbytype
Обязательная
Тип инициации исследования
Observation.status
http://hl7.org/fhir/ValueSet/observation-status
Обязательная
Состояние исследования
Observation.category
http://hl7.org/fhir/ValueSet/observation-category
Предпочтительная
Категория исследования
Observation.code
http://hl7.org/fhir/ValueSet/observation-codes
Пример
Все коды LOINC
Observation.dataAbsentReason
http://hl7.org/fhir/ValueSet/data-absent-reason
Расширяемая
Причина отсутствия результата исследования
Observation.interpretation
http://hl7.org/fhir/ValueSet/observation-interpretation
Расширяемая
Интерпретация результата исследования
Observation.bodySite
http://hl7.org/fhir/ValueSet/bodysite
Пример
Все коды анатомических областей, определенные в номенклатуре SNOMED CT как потомки понятия с кодом 442083009
Observation.method
http://hl7.org/fhir/ValueSet/observation-methods
Пример
Коды методик, определенные в номенклатуре SNOMED CT как потомки понятия с кодом 272394005, или 129264002, или 386053000
Observation.referenceRange.normalValue
http://hl7.org/fhir/ValueSet/observation-referencerange-normalvalue
Расширяемая
Коды, описывающие нормальные значения, например Absent (отсутствует)
Observation.referenceRange.type
http://hl7.org/fhir/ValueSet/referencerange-meaning
Предпочтительная
Тип справочного диапазона
Observation.referenceRange.appliesTo
http://hl7.org/fhir/ValueSet/referencerange-appliesto
Пример
Популяция
Observation. component.code
http://hl7.org/fhir/ValueSet/observation-codes
Пример
Все коды LOINC
Observation. component.dataAbsentReason
http://hl7.org/fhir/ValueSet/data-absent-reason
Расширяемая
Причина отсутствия результата исследования
Observation. component.interpretation
http://hl7.org/fhir/ValueSet/observation-interpretation
Расширяемая
Интерпретация результата исследования
11.11.4 Ограничения ресурса Observation
Ограничения ресурса Observation описаны в таблице 277.
Таблица 277
Ограничения ресурса Observation
Идентификатор
Вид
Путь
Описание
Выражение
obs-3
Правило
Observation.referenceRange
Должен присутствовать хотя бы один из компонентов low, high или text
low.exists() or high.exists() or text.exists()
obs-6
Правило
Базовый
Если отсутствует элемент Observation.value[x], должен присутствовать элемент dataAbsentReason
dataAbsentReason.empty() or value.empty()
obs-7
Правило
Базовый
Если значение элемента Observation.component.code совпадает со значением элемента Observation.code, то элемент Observation.value должен отсутствовать (результат исследования возвращается в элементе Observation.component.value[x])
value.empty() or component.code.where(coding.intersect(%resource.code.coding).exists()).empty()
obs-8
Правило
Базовый
Элемент bodyStructure должен присутствовать только при отсутствии элемента Observation.bodySite
bodySite.exists() implies bodyStructure.empty()
obs-9
Правило
Observation.specimen
Если элемент Observation.specimen ссылается на экземпляр ресурса Group, то его членами должны быть экземпляры ресурса Specimen
(reference.resolve().exists() and reference.resolve() is Group) implies reference.resolve().member.entity.resolve().all($this is Specimen)
11.11.5 Использование элемента Observation.component
Элемент Observation.component используется для передачи компонентов результата исследования, которые должны интерпретироваться совместно. Компоненты могут быть отдельными частями результата или могут детализировать исследование, указанное в элементе Observation.code. Компоненты могут использоваться только в том случае, если исследование выполняется по одной методике, одним исполнителем, одним прибором и в одно и то же время.
Примерами результатов исследований, имеющих компоненты, служат:
а) измерение артериального давления, компонентами которого служат систолическое и диастолическое давление;
б) оценка по шкале Апгар, представленная в виде одного экземпляра ресурса Observation с пятью компонентами;
в) представление нескольких ответов на один вопрос.
В то же время исследование индекса массы тела не должно содержать компоненты веса и роста, поскольку они являются самостоятельными измерениями и должны быть представлены отдельными экземплярами ресурса Observation.
11.11.6 Использование элементов Observation.hasMember и Observation.derivedFrom
Элементы Observation.hasMember и Observation.derivedFrom используются для ссылок на результаты исследований, которые могут интерпретироваться и использоваться сами по себе и различаются хотя бы одним из элементов method, performer, device, effective. Примерами могут служить:
а) панели лабораторных исследований. В этом случае элемент Observation.code содержит код панели, элемент Observation.value[x] обычно отсутствует, компоненты панели представляются в виде отдельных экземпляров ресурса Observation, а в экземплярах элемента Observation.hasMember даются ссылки на эти компоненты. Например, результат микробиологического исследования содержит ссылки на идентификацию изолята и на исследование чувствительности к антибиотикам;
б) вычисляемые результаты. В этом случае оба элемента Observation.code и Observation.value[x] присутствуют, а результаты исследований, использованные для вычислений, передаются по ссылке в экземплярах элемента Observation.derivedFrom.
11.11.7 Результаты с кодированными значениями
Результат исследования может представляться в форме кода из определенной системы кодирования. Например, медицинский прибор вместо количественного значения (или вместе с ним) может передать код 8574682, определенный в системе кодирования MDC (ГОСТ Р 56842) и указывающий на низкий заряд батареи. Этот же код в другой системе кодирования может иметь иное значение. И наоборот, это же состояние заряда батареи может иметь другой код в местной системе кодирования.
В таких случаях в качестве value[x] должен использоваться вариант valueCodeableConcept, в котором можно указать несколько эквивалентных кодов из разных систем кодирования.
Если код подобного события отсутствует или указан код, означающий "прочее", то в компоненте valueCodeableConcept.text можно передать подходящее текстовое значение.
11.11.8 Варианты типа данных результата исследования
В экземпляре ресурса Observation вместо value[x] должен быть подставлен один из следующих элементов, определяющих тип данных:
а) valueQuantity;
б) valueCodeableConcept;
в) valueString;
г) valueBoolean;
д) valueInteger;
е) valueRange;
ж) valueRatio;
и) valueSampledData;
к) valueTime;
л) valueDateTime;
м) valuePeriod;
н) valueAttachment.
Вариант valueAttachment представляет двоичный результат исследования, например изображение.
Вариант valueBoolean используется редко, поскольку большинство результатов исследований кроме ответов да/нет могут содержать исключительное значение, например "неизвестно". Поэтому вместо valueBoolean рекомендуется использовать вариант valueCodeableConcept, привязанный к набору значений с трехзначной логикой, например http://hl7.org/fhir/R4/valueset-example-yesnodontknow.html.
11.11.9 Физиологически релевантное время результата исследования
Варианты effectiveDateTime или effectivePeriod указывают физиологически релевантное время результата исследования. Для результата исследования биоматериала должны быть указаны начало и завершение сбора материала (к примеру, при суточном анализе мочи), но если время сбора достаточно короткое, например при анализе венозной крови, то вместо интервала может быть указан момент времени. Если исследование выполнено непосредственно с пациентом (например, измерение артериального давления или рентген грудной клетки), то обычно вместо интервала указывают момент времени.
11.11.10 Отмененное или прекращенное исследование
Если измерение или анализ не могут быть выполнены (например, недостаточно биоматериала), то элементу status должно быть присвоено значение cancelled и должна быть указана причина, желательно кодированная. Для этого можно опустить элемент value[x] и использовать элемент dataAbsentReason или указать соответствующий код в варианте valueCodeableConcept.
11.11.11 Параметры поиска экземпляров ресурса Observation
Специальные параметры поиска экземпляров ресурса Observation описаны в таблице 278. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 278
Специальные параметры поиска экземпляров ресурса Observation
Имя
Тип
Описание
Выражение
based-on
reference
Ссылка на план или требование, для выполнения которого предназначено данное исследование
Observation.basedOn
(CarePlan, MedicationRequest, NutritionOrder, DeviceRequest, ServiceRequest, ImmunizationRecommendation)
category
token
Категория исследования
Observation.category
code
token
Вид исследования
Observation.code
code-value-concept
composite
Вид исследования и кодированное значение результата
On Observation: code: code-value-concept: value.ofType(CodeableConcept)
code-value-date
composite
Вид исследования и значение результата в форме даты и времени или диапазона дат и времени
On Observation: code: code-value-date: value.ofType(dateTime) | value.ofType(Period)
code-value-quantity
composite
Вид исследования и количественное значение результата
On Observation: code: code-value-quantity: value.ofType(Quantity)
code-value-string
composite
Вид исследования и строковое значение результата
On Observation: code: code-value-string: value.ofType(string)
combo-code
token
Вид исследования, в том числе у компонентов исследования
Observation.code | Observation.component.code
combo-code-value-concept
composite
Вид исследования и кодированное значение результата, в том числе у компонентов исследования
On Observation | Observation.component:
combo-code: code combo-value-concept: value.ofType(CodeableConcept)
combo-code-value-quantity
composite
Вид исследования и количественное значение результата, в том числе у компонентов исследования
On Observation | Observation.component:
combo-code: code combo-value-quantity: value.ofType(Quantity)
combo-data-absent-reason
token
Причина отсутствия элемента Observation.value[x] или Observation.component.value[x]
Observation.dataAbsentReason | Observation.component.dataAbsentReason
combo-value-concept
token
Значение результата исследования или компонента исследования, если оно имеет тип данных CodeableConcept
Observation.value.ofType(CodeableConcept) | Observation.component.value.ofType(CodeableConcept)
combo-value-quantity
quantity
Значение результата исследования или компонента исследования, если оно имеет тип данных Quantity или SampledData
Observation.value.ofType(Quantity) | Observation.value.ofType(SampledData) | Observation.component.value.ofType(Quantity) | Observation.component.value.ofType(SampledData)
component-code
token
Вид исследования у компонента
Observation.component.code
component-code-value-concept
composite
Вид исследования и кодированное значение результата у компонента исследования
On Observation.component:
component-code: code
component-value-concept: value.ofType(CodeableConcept)
component-code-value-quantity
composite
Вид исследования и количественное значение результата у компонента исследования
On Observation.component:
component-code: code
component-value-quantity: value.ofType(Quantity)
component-data-absent-reason
token
Причина отсутствия элемента Observation.component.value[x]
Observation.component.dataAbsentReason
component-value-canonical
uri
Значение URL элемента valueCanonical у компонента исследования
Observation.component.value.ofType(canonical)
component-value-concept
token
Значение результата компонента исследования, если оно имеет тип данных CodeableConcept
Observation.component.value.ofType(CodeableConcept)
component-value-quantity
quantity
Значение результата компонента исследования, если оно имеет тип данных Quantity или SampledData
Observation.component.value.ofType(Quantity) | Observation.component.value.ofType(SampledData)
component-value-reference
reference
Значение результата компонента исследования, если оно имеет тип данных Reference
Observation.component.value.ofType(Reference) (MolecularSequence)
data-absent-reason
token
Причина отсутствия элемента Observation.value[x]
Observation.dataAbsentReason
date
date
Физиологически релевантные дата и время либо период, к которому относится результат исследования
Observation.effective.ofType(dateTime) | Observation.effective.ofType(Period) | Observation.effective.ofType(Timing) | Observation.effective.ofType(instant)
derived-from
reference
Ссылка на экземпляр ресурса, используемого для получения данного результата исследования
Observation.derivedFrom
(GenomicStudy, Observation, ImagingStudy, MolecularSequence, ImagingSelection, QuestionnaireResponse, DocumentReference)
device
reference
Ссылка на медицинский прибор, с помощью которого получен результат исследования, или на его измерительную способность
Observation.device
(Device, DeviceMetric)
encounter
reference
Ссылка на случай медицинской помощи
Observation.encounter
(Encounter)
focus
reference
Ссылка на экземпляр ресурса, описывающего предмет исследования, если он отличается от субъекта
Observation.focus
(Any)
has-member
reference
Ссылка на экземпляр ресурса, являющийся частью результата данного исследования
Observation.hasMember
(Observation, MolecularSequence, QuestionnaireResponse)
identifier
token
Идентификатор результата исследования
Observation.identifier
method
token
Методика исследования
Observation.method
part-of
reference
Ссылка на исследование, частью которого является данное исследование
Observation.partOf
(GenomicStudy, Immunization, MedicationDispense, MedicationAdministration, Procedure, ImagingStudy, MedicationStatement)
patient
reference
Ссылка на субъект исследования (если это пациент)
Observation.subject.where(resolve() is Patient) (Patient)
performer
reference
Ссылка на исполнителя исследования
Observation.performer
(Practitioner, Organization, CareTeam, Patient, PractitionerRole, RelatedPerson)
specimen
reference
Ссылка на идентификацию исследованного биоматериала
Observation.specimen
(Specimen, Group)
status
token
Состояние исследования
Observation.status
subject
reference
Ссылка на субъект исследования
Observation.subject
(Practitioner, Group, Organization, BiologicallyDerivedProduct, NutritionProduct, Device, Medication, Patient, Procedure, Substance, Location)
value-canonical
uri
Значение URL элемента valueCanonical
Observation.value.ofType(canonical)
value-concept
token
Значение результата исследования, если оно имеет тип данных CodeableConcept
Observation.value.ofType(CodeableConcept)
value-date
date
Значение результата исследования, если оно имеет тип данных dateTime или Period
Observation.value.ofType(dateTime) | Observation.value.ofType(Period)
value-markdown
string
Значение результата исследования, если оно имеет тип данных string, а также поиск по компоненту text значения результата типа CodeableConcept
Observation.value.ofType(markdown) | Observation.value.ofType(CodeableConcept).text
value-quantity
quantity
Значение результата исследования, если оно имеет тип данных Quantity или SampledData
Observation.value.ofType(Quantity) | Observation.value.ofType(SampledData)
value-reference
reference
Значение результата исследования, если оно имеет тип данных Reference.
Observation.value.ofType(Reference) (MolecularSequence)
11.11.12 Передача результатов измерений
Примерный процесс передачи результата измерений показан на рисунке 58.
Рисунок 58 - Процесс передачи результата измерений
ПМП устанавливает связь с менеджером ПМП или шлюзом интернета вещей (далее для краткости упоминается только менеджер). Затем ПМП передает протокольные данные, необходимые для интерпретации результатов измерений или управления прибором, например выбранные единицы измерения или процент заряда батареи. Если за время, прошедшее с предыдущего сеанса связи, у ПМП прервалась линия времени (например, таймер был сброшен или пациент изменил дату и время таймера), то ПМП должен передать менеджеру показания своего таймера в формате ГОСТ Р 56845. Менеджер формирует экземпляр ресурса Observation, содержащий сверку показаний таймера ПМП и таймера менеджера, и передает его сервису обработки и хранения результатов измерений (далее - сервис). Сервис сохраняет сверку таймеров, а МИС получает сохраненный экземпляр ресурса Observation по подписке.
ПМП осуществляет измерение показателей состояния пациента или среды его обитания и передает менеджеру результат измерения в формате ГОСТ Р 56845. Менеджер преобразует полученный результат в экземпляр ресурса Observation, в том числе добавляет в него идентификатор ПМП, дату и время поступления результата измерения, а также идентификатор последней сверки таймеров. Затем менеджер передает сервису сформированный экземпляр ресурса Observation. Сервис сохраняет результат измерений, а МИС получает сохраненный экземпляр ресурса Observation по подписке.
11.11.13 Варианты типов результатов измерений
Взаимодействие ПМП с менеджером, осуществляемое в соответствии со стандартом ГОСТ Р 56845, может включать в себя обмен данными, не являющимися результатами измерений. Например, пользователь может изменить на своих весах единицы веса с фунтов на килограммы. Весы информируют об этом шлюз. В передаче этого события сервису нет никакой необходимости. Передача требуется, если по событию измерения ПМП передает менеджеру один из 12 атрибутов, перечисленных в таблице 279.
Таблица 279
Атрибуты, передаваемые по событию измерения
Атрибут
Описание
Basic-Nu-Observed-Value
Одно число, представленное в формате SFLOAT
Simple-Nu-Observed-Value
Одно число, представленное в формате FLOAT
Compound-Basic-Nu-Observed-Value
Несколько чисел, представленных в формате SFLOAT
Compound-Simple-Nu-Observed-Value
Несколько чисел, представленных в формате FLOAT
Nu-Observed-Value
Одно число, представленное в формате FLOAT и дополненное единицами измерения и типом данных
Compound Nu-Observed-Value
Несколько чисел, представленных в формате FLOAT и дополненных единицами измерения и типом данных
Simple-Sa-Observed-Value
Последовательность масштабируемых периодических числовых считываний
Enum-Observed-Value-Simple-OID
Результат измерения, представленный номенклатурным кодом
Enum-Observed-Value-Basic-Bit-Str
Поле из 16 битов, каждый из которых описывает определенное состояние или событие
Enum-Observed-Value-Simple-Bit-Str
Поле из 32 битов, каждый из которых описывает определенное состояние или событие
Enum-Observed-Value-Simple-Str
Человеко-читаемая строка
Enum-Observed-Value
Поле из 32 битов, каждый из которых описывает определенное состояние или событие, дополненное номенклатурным кодом или строкой, а также типом данных
Каждый результат измерения представлен одним и только одним из этих атрибутов. Если ПМП передает данные, не содержащие такой атрибут, то эта информация адресована менеджеру, чтобы он мог декодировать переданный затем результат измерения, и сервису не передается.
Некоторые атрибуты, например Basic-Nu-Observed-Value и Simple-Nu-Observed-Value, представляют один и тот же тип измерений, отличающийся только длиной представления чисел с плавающей точкой. Поэтому варианты типов результатов измерений сводятся к следующим шести вариантам:
а) число (Basic-, Simple-, and Nu-Observed-Value);
б) вектор (Compound-*-Nu-Observed-Value);
в) последовательность периодических считываний (Simple-Sa-Observed-Value);
г) код (Enum-Observed-Value-Simple-OID);
д) группа двоичных состояний или событий (Enum-Observed-Value-*-Bit-Str);
е) человеко-читаемая строка (Enum-Observed-Value-Simple-Str).
11.11.14 Представления чисел с плавающий точкой FLOAT и SFLOAT
В стандарте ГОСТ Р 56845 для чисел с плавающей точкой определены форматы FLOAT и SFLOAT. Формат SFLOAT использует 16 битов, а FLOAT - 32 бита. Для передачи некоторых типов ошибок зарезервированы пять специальных значений, приведенных в таблице 280.
Таблица 280
Зарезервированные значения чисел с плавающей точкой
FLOAT
SFLOAT
Описание
Представление в экземпляре ресурса Observation
0x007FFFFF
0x7FF
Не число (NaN)
dataAbsentReason.coding.code = 'not-a-number'
0x007FFFFE
0x7FE
Положительная бесконечность (+inf)
dataAbsentReason.coding.code = 'positive-infinity'
0x00800002
0x802
Отрицательная бесконечность (-inf)
dataAbsentReason.coding.code = 'negative-infinity'
0x00800000
0x800
Не может быть представлено с данной точностью
dataAbsentReason.coding.code = 'error'
0x00800001
0x801
Зарезервировано для будущего использования
dataAbsentReason.coding.code = 'error'
11.11.15 Номенклатурные коды
Согласно стандарту ГОСТ Р 56845 типы измерений, единицы измерения и ряд других характеристик, относящихся к результатам измерений, должны передаваться в виде номенклатурных кодов, определенных в стандарте ГОСТ Р 56842. Эти коды представляют собой 32-битовые целые числа без знака. Старшие 16 битов задают раздел номенклатуры, а младшие 16 битов - код термина в этом разделе. С каждым номенклатурным кодом связан "почти человеко-читаемый" мнемокод; например, с кодом 147842 связан мнемокод MDC_ECG_HEART_RATE (частота сокращений сердца, определенная по ЭКГ). ПМП передает шлюзу только числовой номенклатурный код, а при передаче сервису шлюз по возможности дополняет номенклатурный код мнемокодом. В ряде случаев ПМП передает только код термина, если раздел можно определить из контекста передачи.
При передаче результатов измерений ПМП использует в качестве единиц измерений соответствующий номенклатурный код. При передаче сервису шлюз должен указать код единицы измерения, определенный в стандарте UCUM [37].
11.11.16 Отображение номенклатурного кода в элементы с типом данных CodeableConcept
При отображении номенклатурных кодов в элементы ресурса Observation, имеющие тип данных CodeableConcept, он должен представляться в компонентах этого типа данных следующим образом:
а) coding.code = номенклатурный код;
б) coding.system = "urn:iso:std:iso:11073:10101";
в) text = мнемокод (необязательный компонент).
Мнемокод может быть дополнен его кратким описанием на русском языке, например, "MDC_ECG_HEART_RATE: частота сокращений сердца, определенная по ЭКГ".
Согласно стандарту ГОСТ Р 56845, в составе каждого результата измерений должен присутствовать атрибут Type, указывающий тип измерения. Однако в составе результата измерений могут быть атрибуты, модифицирующие или изменяющие значение атрибута Type. Поэтому рекомендуется использовать следующий алгоритм присваивания номенклатурного кода элементу Observation.code.coding.code:
а) partition = Type.partition;
б) termCode = Type.code;
в) если присутствует атрибут Metric-Id:
1) termCode = Metric-Id;
2) если присутствует атрибут Metric-Id-Partition:
3) partition = Metric-Id-Partition;
г) если результат измерения задается атрибутом Nu-Observed-Value или Enum-Observed-Value:
1) termCode = *-Observed-Value.metric;
2) Observation.code.coding.code = partition*216+termCode.
В элементах, имеющих тип данных CodeableConcept, группа компонентов coding.code и coding.system может повторяться при условии, что они относятся к одному и тому же понятию, возможно, с разной степенью общности. Если номенклатурному коду соответствует понятие, определенное в профиле жизненно важных показателей (https://www.hl7.org/fhir/observation-vitalsigns.html), то во второй группе компонентов coding.code и coding.system должен быть передан код, указанный в этом профиле. В еще одной группе следует передать код измерения, взятый из нормативно-справочной информации Минздрава России.
11.11.17 Представление единиц измерения
Результаты измерений, представляющие физические величины, могут содержать единицы измерения. Они передаются в атрибуте Unit-Code, но атрибуты Nu-Observed-Value и Compound-Nu-Observed-Value содержат собственные компоненты единиц измерения, которые переопределяют значение атрибута Unit-Code.
Все коды единиц измерения определены в разделе 4 номенклатуры MDC (см. 11.11.17), поэтому ПМП передает менеджеру только код термина. При формировании экземпляра ресурса Observation менеджер должен преобразовать код термина в эквивалентный код системы UCUM. Если эквивалентный код отсутствует, то в экземпляр ресурса Observation должен быть помещен полный 32-битовый номенклатурный код, вычисляемый по коду термина для раздела 4.
11.11.18 Преобразование битовых полей
Результаты измерений могут содержать битовые поля, в которых каждый бит описывает состояние или событие. Например, результат измерения, переданный пульсоксиметром, может содержать 16-битовое поле, в котором установлен бит 11 (то есть имеет значение 1), означающий плохой сигнал.
Битовые поля в нотации АСН.1 могут быть определены следующим образом (см. [1] - [21]):
MeasurementStatus ::= BITS-16 {
invalid(0),
questionable(1),
not-available(2),
calibration-ongoing(3),
test-data(4),
demo-data(5),
validated-data(8),
early-indication(9),
msmt-ongoing(10),
msmt-state-in-alarm(14),
msmt-state-al-inhibited(15)
}
Здесь каждому значащему биту присвоено имя, например test-data (тестовые данные), а в скобах указан номер бита. Номер 0 соответствует старшему значащему биту. Для некоторых битов определение пропущено, они могут быть задействованы в следующих версиях стандартов. В данном примере использованы 11 битов из 16.
Преобразование битового поля осуществляется следующим образом. Номенклатурный код битового поля помещается в элемент Observation.code в соответствии с таблицей 281.
Таблица 281
Преобразование номенклатурного кода битового поля
Компонент элемента Observation.code
Значение
Observation.code.coding.system
"urn:iso:std:iso:11073:10101"
Observation.code.coding.code
номенклатурный код, например 150604
Observation.code.text
мнемокод, соответствующий номенклатурному коду (необязателен), дополненный текстом, например "MDC_PULS_OXIM_DEV_STATUS: Состояние процесса измерений"
Затем для каждого значащего бита создается отдельный экземпляр элемента Observation.component, компоненты которого заполняются в соответствии с таблицей 282.
Таблица 282
Преобразование значения отдельного бита
Компонент элемента Observation.code
Значение
Observation.component.code.coding.system
"http://hl7.org/fhir/uv/phd/CodeSystem/ASN1 ToHL7"
Observation.component.code.coding.code
Номенклатурный код, дополненный точкой и номером бита, например "150604.11"
Observation.component.code.text
Имя бита в определении АСН.1 (необязательно), например, "signal-poor"
Observation.component.valueCodeableConcept.coding.system
"http://terminology.hl7.org/CodeSystem/v2-0136"
Observation.component.valueCodeableConcept.coding.code
"Y", если бит установлен, "N", если бит снят
Observation.component.valueCodeableConcept.text
Человеко-читаемый текст, соответствующий значению бита, например "Плохой сигнал"
Если бит описывает событие (event), например, signal-poor (плохой сигнал), то экземпляр элемента Observation.component создается только для установленного бита. Если бит описывает состояние (state), например lim-low-off (обнаружение нижнего предела отключено), то экземпляр элемента Observation.component создается при любом значении бита.
11.11.19 Идентификатор результата измерения
Некоторые ПМП повторно передают старые данные. Чтобы исключить появление дубликатов результатов измерений в базе данных сервиса, менеджер ПМП должен присваивать элементу Observation.identifier значение, одинаковое для всех дубликатов, и при передаче экземпляра Observation сервису использовать контейнер транзакции Bundle, в котором указан элемент ifNoneExists с соответствующим фильтром.
11.11.20 Статус результата измерений
Атрибут Measurement-Status передается как 16-битовое поле. Он определяет 11 событий, идентифицирующих ошибки или особые условия измерения. Он имеет тип данных MeasurementStatus, имеющий следующее определение на языке АСН.1:
MeasurementStatus ::= BITS-16 {
invalid(0),
questionable(1),
not-available(2),
calibration-ongoing(3),
test-data(4),
demo-data(5),
validated-data(8),
early-indication(9),
msmt-ongoing(10),
msmt-state-in-alarm(14),
msmt-state-al-inhibited(15)
}
Биты могут быть установлены параллельно, но не все сочетания битов имеют смысл.
Для передачи статуса результата измерений используются три элемента ресурса Observation: dataAbsentReason, interpretation и meta.security (таблица 283).
Таблица 283
Передача статуса результатов измерений
в элементах ресурса Observation
Бит
Имя
Описание
Элемент ресурса Observation
0
invalid
Ошибочный результат
dataAbsentReason.coding.system="http://terminology.hl7.org/CodeSystem/data-absent-reason"
dataAbsentReason.coding.code="error"
1
questionable
Достоверность результата под вопросом
interpretation.coding.system=http://hl7.org/fhir/uv/pocd/CodeSystem/measurement-status
interpretation.coding.code="questionable"
2
not-available
Результат недоступен
dataAbsentReason.coding.system="http://terminology.hl7.org/CodeSystem/data-absent-reason"
dataAbsentReason.coding.code="not-performed"
3
calibration-ongoing
В процессе калибровки
interpretation.coding.system="http://hl7.org/fhir/uv/pocd/CodeSystem/measurement-status"
interpretation.coding.code="calibration-ongoing"
4
test-data
Тестовый результат
meta.security.code="HTEST"
meta.security.system="http://terminology.hl7.org/CodeSystem/v3-ActReason"
5
demo-data
Демонстрационный результат
meta.security.code="HTEST"
meta.security.system="http://terminology.hl7.org/CodeSystem/v3-ActReason"
8
validated-data
Результат проверен
interpretation.coding.system="http://hl7.org/fhir/uv/pocd/CodeSystem/measurement-status"
interpretation.coding.code="validated-data"
9
early-indication
Предварительный результат
interpretation.coding.system="http://hl7.org/fhir/uv/pocd/CodeSystem/measurement-status"
interpretation.coding.code="early-indication"
10
msmt-ongoing
В процессе измерения
dataAbsentReason.coding.code="temp-unknown" data-AbsentReason.coding.system="http://terminology.hl7.org/CodeSystem/data-absent-reason"
14
msmt-value-exceed-boundaries
Результат за пределами диапазона
interpretation.coding.system="http://hl7.org/fhir/uv/pocd/CodeSystem/measurement-status"
interpretation.coding.code="in-alarm"
15
msmt-state-ann-inhibited
Оповещение о выходе за пределы диапазона отключено
interpretation.coding.system="http://hl7.org/fhir/uv/pocd/CodeSystem/measurement-status"
interpretation.coding.code="alarm-inhibited"
Если результат измерения передается в атрибуте Nu-Observed-Value или Enum-Observed-Value, то статус результата измерений берется из компонента state этого атрибута.
11.11.21 Сверка таймеров
Сверка таймеров представляет собой значение таймера менеджера, считанное при получении от ПМП значения таймера ПМП. В предположении, что таймер менеджера синхронизирован с мировым временем (например, по протоколу Network Time Protocol) лучше, чем таймер ПМП (что обычно имеет место), менеджер должен корректировать время выполнения измерения на разность между показаниями двух таймеров. Иными словами, менеджер должен поместить момент измерения на свою линию времени.
Сверка таймеров должна осуществляться после каждого прерывания линии времени у ПМП, например после ручной переустановки даты и времени на ПМП.
Сверка таймеров передается сервису в форме экземпляра ресурса Observation, структура которого описана в пункте 0. При передаче сервису результата измерений идентификатор последней сверки таймеров должен передаваться в элементе Observation.derivedFrom.
Экземпляр ресурса Observation, содержащий сверку таймеров, должен заполняться следующим образом:
а) текущее время менеджера передается в элементе Observation.effectiveDateTime;
б) текущее время ПМП передается в элементе Observation.valueDateTime.
Если ПМП в результатах измерений не передает штампы даты и времени, то экземпляр сверки таймеров не создается и менеджер передает сервису дату и время получения от ПМП результата измерений.
Если ПМП не сообщает менеджеру свое текущее время, но при этом передает в результатах измерений штампы даты и времени, то создается экземпляр сверки таймеров, заполняемый следующим образом:
а) текущее время менеджера передается в элементе Observation.effectiveDateTime;
б) элемент Observation.valueDateTime не передается;
в) в элементе Observation.dataAbsentReason.coding.system передается значение http://terminology.hl7.org/CodeSystem/data-absent-reason;
г) в элементе Observation.dataAbsentReason.coding.code передается значение "unknown".
При передаче результата измерений сервису менеджер указывает дату и время получения от ПМП результата измерений.
11.11.22 Сверка таймера и тактового счетчика
Вместо таймера ПМП может использовать тактовый счетчик ("относительное время"). Стандарт ГОСТ Р 56845 предусматривает два типа счетчиков: обычный 32-битовый с величиной такта 1/8 миллисекунды и 64-битовый с величиной такта 1 микросекунда. Текущее значение счетчика, приведенное к микросекундам, передается в элементе Observation.valueQuantity. Оно используется менеджером для преобразования в дату и время с часовым поясом.
Если ПМП не сообщает менеджеру текущее значение тактового счетчика, но при этом передает в результатах измерений штампы относительного времени, то создается экземпляр сверки таймеров, в котором Observation.valueQuantity не передается, а в элементе Observation.dataAbsentReason.coding.code передается значение unknown.
11.11.23 ПМП, не соответствующие стандарту ГОСТ Р 56845
Ряд моделей ПМП, например использующие протокол связи Bluetooth Low Energy, не соответствует стандарту ГОСТ Р 56845. Менеджер должен преобразовать информацию, передаваемую такими ПМП, в объекты MDS и Metric, определенные в этом стандарте, а затем передать эти объекты сервису в форме экземпляров ресурса Observation. Один из вариантов такого преобразования описан в [36].
11.11.24 Профиль Observation-PhdNumeric
11.11.24.1 Общие требования
Профиль Observation-PhdNumeric (скалярная величина) используется для передачи скалярных физических величин, в том числе безразмерных. Примерами таких величин могут служить температура тела, вес, рост, концентрация глюкозы, частота сердечных сокращений и т.д.
Результат измерений, передаваемый ПМП, является скалярным, если он содержит один из атрибутов, перечисленных в таблице 284.
Таблица 284
Атрибуты скалярных результатов измерений
Атрибут
Тип данных
Примечание
Basic-Nu-Observed-Value
SFLOAT
16-битовое число с 12-битовой мантиссой
Simple-Nu-Observed-Value
FLOAT
32-битовое число с 24-битовой мантиссой
Nu-Observed-Value
FLOAT
Комплексный атрибут. Содержит компоненты value (значение), metric-id (идентификатор метрики), state (статус результата измерения) и unit-code (единица измерения)
11.11.24.2 Отображение скалярных результатов измерений на элементы ресурса Observation
Отображение скалярных результатов измерений на элементы ресурса Observation приведено в таблице 285. Единицы измерения должны быть преобразованы в коды UCUM. В некоторых случаях потребуются определенные ухищрения. Например, для кардиографа единица измерения интервала R-R может быть определена мнемокодом MDC_DIM_TICK, означающим число тактов. В этом случае результат измерения должен содержать атрибут с мнемокодом MDC_ATTR_TICK_RES, содержащий число тактов в секунду. Таким образом, если этот атрибут имеет значение 2048, а результат измерения интервала R-R равен 3092, то длительность интервала R-R равна 1,5 секунды.
Таблица 285
Отображение скалярных результатов измерений
на элементы ресурса Observation
Атрибут
Отображение на элементы ресурса Observation
Basic-Nu-Observed-Value.value
Observation.valueQuantity.value
Unit-Code
Observation.valueQuantity.code (код UCUM)
Observation.valueQuantity.system="http://unitsofmeasure.org"
Simple-Nu-Observed-Value.value
Observation.valueQuantity.value
Nu-Observed-Value.value
Observation.valueQuantity.value
Nu-Observed-Value.unit
Observation.valueQuantity.system="http://unitsofmeasure.org" Observation.valueQuantity.code
Nu-Observed-Value.metric-id
Значение компонента metric-id влияет на Observation.code, см. 11.11.16
Nu-Observed-Value.state
Преобразование компонента state приведено в таблице 283
11.11.24.3 Дополнительная информация к числовому результату
Согласно [38], числовые результаты могут содержать дополнительные атрибуты, предоставляющие дальнейшие сведения об измерении, а именно:
а) Accuracy (точность);
б) Alert-Op-State (состояние предупреждений о выходе результата измерения за нижнюю или верхнюю границу);
в) Alert-Op-Text-String (тексты предупреждений о выходе результата измерения за нижнюю или верхнюю границу);
г) Current-Limits (границы контролируемого диапазона);
д) Measurement-Confidence-95 (границы диапазона достоверности 95%);
е) Threshold-Notification-Text-String (предупреждение о выходе за границу).
11.11.24.4 Атрибут Accuracy
Атрибут Accuracy (точность) имеет абсолютное значение и определяет максимальное отклонение фактического значения от сообщенного наблюдаемого значения (если оно может быть указано) во всем диапазоне измерений. Выражается в тех же единицах измерения, что и результаты наблюдений. При передаче результатов измерений с определенной точностью сообщаемое значение должно обладать определенным числом разрядов, достаточным для представления такой точности.
Отображение атрибута Accuracy на элементы ресурса Observation представлено в таблице 286.
Таблица 286
Отображение атрибута Accuracy на элементы
ресурса Observation
Компонент элемента Observation.component
Значение
Примечание
code.coding.code
"67914"
Номенклатурный код атрибута Accuracy
code.coding.system
"urn:iso:std:iso:11073:10101"
Идентификатор системы кодирования MDC
code.text
"MDC_ATTR_NU_ACCUR_MSMT: точность"
Необязательный текст
valueQuantity.value
Значение атрибута Accuracy
-
valueQuantity.system
"http://unitsofmeasure.org"
Идентификатор системы кодирования UCUM
valueQuantity.code
Код единицы измерения
Должен использоваться тот же код, что у результата измерения
11.11.24.5 Атрибут Alert-Op-State
Атрибут Alert-Op-State (состояние предупреждений о выходе результата измерения за нижнюю или верхнюю границу) используется при передаче результатов измерений, выполненных пульсоксиметром. Он представляет собой битовое поле, идентифицирующее состояние предупреждений о выходе результата измерения за нижнюю или верхнюю границу заданного диапазона.
Отображение атрибута Alert-Op-State на элементы ресурса Observation представлено в таблице 287.
Таблица 287
Отображение атрибута Alert-Op-State на элементы
ресурса Observation
Компонент элемента Observation.component
Значение
Примечание
code.coding.code
"68746.n"
Атрибут Alert-Op-State имеет номенклатурный код 68746. Номер бита n может принимать значение 0, 1 или 2
code.coding.system
"http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7"
Идентификатор системы кодирования ASN1ToHL7
code.text
"lim-alert-off" (предупреждение о выходе за границы отключено) | "lim-low-off" (предупреждение о выходе за нижнюю границу отключено) | "lim-high-off" (предупреждение о выходе за верхнюю границу отключено) для битов 0 | 1 | 2 соответственно
Необязательный текст
valueCodeableConcept.coding.code
"Y" или "N"
"Y" - бит установлен, "N" - бит снят
valueCodeableConcept.coding.system
"http://terminology.hl7.org/CodeSystem/v2-0203"
Идентификатор системы кодирования v2-0203
11.11.24.6 Атрибут Alert-Op-Text-String
Атрибут Alert-Op-Text-String (тексты предупреждений о выходе результата измерения за нижнюю или верхнюю границу) используется при передаче результатов измерений, выполненных пульсоксиметром. Он содержит тексты предупреждений о выходе результата измерения за нижнюю или верхнюю границу заданного диапазона.
Отображение атрибута Alert-Op-Text-Stringe на элементы ресурса Observation представлено в таблице 288.
Таблица 288
Отображение атрибута Alert-Op-Text-String
на элементы ресурса Observation
Компонент элемента Observation.component
Значение
Примечание
code.coding.code
"68104"
Номенклатурный код атрибута Alert-Op-Text-String
code.coding.system
"urn:iso:std:iso:11073:10101"
Идентификатор системы кодирования MDC
code.text
"MDC_ATTR_AL_OP_TEXT_STRING: строки предупреждений о выходе за границы"
Необязательный текст
valueString
Alert-Op-Text-String.lower-text + " " + Alert-Op-Text-String.upper-text
Конкатенация текстов предупреждений о выходе результата измерений за нижнюю и верхнюю границу
11.11.24.7 Атрибут Current-Limits
Атрибут Current-Limits (границы контролируемого диапазона) используется при передаче результатов измерений, выполненных пульсоксиметром. Он содержит границы диапазона, выход за которые должен контролироваться.
Отображение атрибута Current-Limits на элементы ресурса Observation представлено в таблице 289.
Таблица 289
Отображение атрибута Current-Limits на элементы
ресурса Observation
Компонент элемента Observation.component
Значение
Примечание
code.coding.code
"67892"
Номенклатурный код атрибута Current-Limits
code.coding.system
"urn:iso:std:iso:11073:10101"
Идентификатор системы кодирования MDC
code.text
"MDC_ATTR_LIMIT_CURR: нижняя и верхняя граница"
Необязательный текст
valueRange.low.value
Current-Limits.lower
Нижняя граница
valueRange.low.system
"http://unitsofmeasure.org"
Идентификатор системы кодирования UCUM
valueRange.low.code
Код единицы измерения
Должен использоваться тот же код, что у результата измерения
valueRange.high.value
Current-Limits.upper
Верхняя граница
valueRange.high.system
"http://unitsofmeasure.org"
Идентификатор системы кодирования UCUM
valueRange.high.code
Код единицы измерения
Должен использоваться тот же код, что у результата измерения
11.11.24.8 Атрибут Measurement-Confidence-95
Атрибут Measurement-Confidence-95 (границы диапазона достоверности 95%) используется при передаче результатов измерений, выполненных глюкометром непрерывного действия. Он содержит нижнюю и верхнюю границу диапазона, в который производитель прибора с вероятностью 95% гарантирует вхождение результата измерения.
Отображение атрибута Measurement-Confidence-95 на элементы ресурса Observation представлено в таблице 290.
Таблица 290
Отображение атрибута Measurement-Confidence-95
на элементы ресурса Observation
Компонент элемента Observation.component
Значение
Примечание
code.coding.code
"68236"
Номенклатурный код атрибута Measurement-Confidence-95
code.coding.system
"urn:iso:std:iso:11073:10101"
Идентификатор системы кодирования MDC
code.text
"MDC_ATTR_MSMT_CONFIDENCE_95: доверительный интервал 95%"
Необязательный текст
valueRange.low.value
Measurement-Confidence-95.lower-bound
Нижняя граница
valueRange.low.system
"http://unitsofmeasure.org"
Идентификатор системы кодирования UCUM
valueRange.low.code
Код единицы измерения
Должен использоваться тот же код, что у результата измерения
valueRange.high.value
Measurement-Confidence-95.upper-bound
Верхняя граница
valueRange.high.system
"http://unitsofmeasure.org"
Идентификатор системы кодирования UCUM
valueRange.high.code
Код единицы измерения
Должен использоваться тот же код, что у результата измерения
11.11.24.9 Атрибут Threshold-Notification-Text-String
Атрибут Threshold-Notification-Text-String (предупреждение о выходе за границу) используется при передаче результатов измерений, выполненных глюкометром непрерывного действия. Он содержит текст текущего предупреждения о выходе за границу заданного диапазона.
Отображение атрибута Threshold-Notification-Text-String на элементы ресурса Observation представлено в таблице 291.
Таблица 291
Отображение атрибута Threshold-Notification-Text-String
на элементы ресурса Observation
Компонент элемента Observation.component
Значение
Примечание
code.coding.code
"68232"
Номенклатурный код атрибута Threshold-Notifi cation-Text-String
code.coding.system
"urn:iso:std:iso:11073:10101"
Идентификатор системы кодирования MDC
code.text
"MDC_ATTR_THRES_NOTIF_TEXT_STRING: предупреждение о выходе за границу"
Необязательный текст
valueString
Threshold-Notification-Text-String
Текст текущего предупреждения о выходе за границы заданного диапазона
11.11.24.10 Состав элементов профиля Observation-PhdNumeric
Профиль Observation-PhdNumeric (скалярный результат измерения) оставляет в ресурсе Observation только те элементы, которые могут использоваться при преобразовании скалярного результата измерения из формата, предусмотренного стандартом ГОСТ Р 56845 (рисунок 59 и таблица 292). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
Рисунок 59 - Профиль Observation-PhdNumeric
Таблица 292
Состав элементов профиля Observation-PhdNumeric
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
meta.profile
Фиксированное значение "Observation-PhdNumeric"
string
1
meta.security
Статус результата измерения (если тестовый или демонстрационный)
Coding
0..1
meta.security.system
Система кодирования значений статуса. Фиксированное значение "http://terminology.hl7.org/CodeSystem/v3-ActReason"
uri
1
meta.security.code
Код статуса. Фиксированное значение "HTEST"
code
1
Собственные элементы
identifier
Идентификатор результата измерения
Identifier
1
status
Состояние измерения. Фиксированное значение unknown (состояние результата измерения не известно). Фактическое состояние измерения передается в других элементах в соответствии с таблицей 283
code
1
category
Категория измерения. Заполняется кодом LOINC, если измеряются жизненно важные показатели
CodeableConcept
0..1
code
Вид измерения. Заполняется в соответствии с 11.11.16
CodeableConcept
1
effective[x]
Дата и время или диапазон даты и времени выполнения измерения. Допустимые значения: effectiveDateTime | effectivePeriod
*
1
valueQuantity
Результат измерения
SimpleQuantity
0..1
dataAbsent-Reason
Причина отсутствия результата измерения (см. таблицу 280)
CodeableConcept
0..1
interpretation
Статус результата измерений (см. таблицу 283)
CodeableConcept
0..1
device
Ссылка на экземпляр ресурса Device, идентифицирующий персональный медицинский прибор, с помощью которого получен результат измерения
Reference
0..1
derivedFrom
Ссылка на экземпляр ресурса Observation, содержащий сверку таймеров ПМП и менеджера
Reference
0..1
component
Дополнительные сведения о результате измерения
BackboneElement
0..*
component.code
Вид сведений
CodeableConcept
1
component. value[x]
Значение сведений. Допустимые значения: valueQuantity (скалярная величина) | valueCodeableConcept (битовое поле) | valueString (текст) | valueRange (границы)
*
0..1
component.dataAbsentReason
Причина отсутствия значения сведений (см. таблицу 280)
CodeableConcept
0..1
11.11.25 Профиль Observation-PhdCompoundNumeric
11.11.25.1 Общие требования
Профиль Observation-PhdCompoundNumeric (массив скалярных величин) используется для передачи вектора или массива связанных скалярных величин, измеренных примерно в один и тот же момент времени, например вектора ускорения или показателей артериального давления (систолическое, диастолическое, среднее).
Результат измерений, передаваемый ПМП, является массивом скалярных величин, если он содержит один из атрибутов, перечисленных в таблице 293.
Таблица 293
Атрибуты массива скалярных результатов измерений
Атрибут
Тип данных
Примечание
Compound-Basic-Nu-Observed-Value
Массив SFLOAT
Массив 16-битовых чисел с 12-битовой мантиссой
Compound-Simple-Nu-Observed-Value
Массив FLOAT
Массив 32-битовых чисел с 24-битовой мантиссой
Compound-Nu-Observed-Value
Массив FLOAT
Массив комплексных атрибутов, содержащих компоненты value (значение), metric-id (идентификатор метрики), state (статус результата измерения) и unit-code (единица измерения)
Каждый элемент массива передается в отдельном экземпляре элемента Observation.component. Если результат измерения содержит атрибут Compound-Basic-Nu-Observed-Value или Compound-Simple-Nu-Observed-Value, то он должен содержать атрибут Metric-Id-List, содержащий список кодов, идентифицирующих виды измеренных величин. Порядок следования кодов совпадает с порядком следования элементов массива. Если результат измерения содержит атрибут Compound-Nu-Observed-Value, то код вида измерений берется из его компонента metric-id. Полученный код вида измерений преобразуется в 32-битовый номенклатурный код в соответствии с 11.11.16. Результат преобразования передается в элементе Observation.component.code.
Результат измерений включает в себя атрибут Type. Его значение преобразуется в 32-битовый номенклатурный код в соответствии с 11.11.16. Результат преобразования передается в элементе Observation.code. Элемент Observation.value не заполняется. Если в атрибуте Measurement-Status установлены биты 0 (Ошибочный результат), 2 (Результат недоступен) или 10 (В процессе измерения), то соответствующий код должен быть передан в элементе Observation.dataAbsentReason. В этом случае компоненты массива не передаются.
11.11.25.2 Отображение массива скалярных результатов измерений на элементы ресурса Observation
Отображение массива скалярных результатов измерений на элементы ресурса Observation приведено в таблице 294. Атрибут Metric-Id-List содержит список атрибутов Metric-Id и его n-й элемент обозначается как Metric-Id[n].
Таблица 294
Отображение массива скалярных результатов измерений
на элементы ресурса Observation
Атрибут
Отображение на элементы ресурса Observation
Compound-Basic-Nu-Observed-Value.value[n]
Observation.component[n].valueQuantity.value
Unit-Code
Observation.component[1..n].valueQuantity.system="http://unitsofmeasure.org"
Observation.component[1..n].valueQuantity.code (эквивалентный код UCUM)
Metric-Id[n]
Observation.component[n].code.coding.code
Simple-Nu-Observed-Value.value[n]
Observation.component[n].valueQuantity.value
Nu-Observed-Value.value[n]
Observation.component[n].valueQuantity.value
Nu-Observed-Value.unit[n]
Observation.component[n].valueQuantity.system="http://unitsofmeasure.org"
Observation.component[n].valueQuantity.code (эквивалентный код UCUM)
Nu-Observed-Value.metric-id[n]
Observation.component[n].code.coding.code
Nu-Observed-Value.state[n]
Преобразование компонента state осуществляется по аналогии с таблицей 283. При этом биты 4 и 5 игнорируются
11.11.25.3 Дополнительная информация к массиву скалярных результатов
Вместе с массивом числовых результатов может быть передан атрибут Accuracy (точность). Он имеет абсолютное значение и определяет максимальное отклонение фактического значения от сообщенного наблюдаемого значения (если оно может быть указано) во всем диапазоне измерений. Этот атрибут применим только в тех случаях, если все элементы массива имеют одинаковые единицы измерения, и выражается в этих же единицах. При передаче результатов измерений с определенной точностью сообщаемое значение должно обладать определенным числом разрядов, достаточным для представления такой точности.
Отображение атрибута Accuracy на элементы ресурса Observation представлено в таблице 286.
11.11.25.4 Состав элементов профиля Observation-PhdCompoundNumeric
Профиль Observation-PhdCompoundNumeric (скалярный результат измерения) оставляет в ресурсе Observation только те элементы, которые могут использоваться при преобразовании массива скалярных результатов измерения из формата ГОСТ Р 56845 (рисунок 60 и таблица 295). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
Рисунок 60 - Профиль Observation-PhdCompoundNumeric
Таблица 295
Состав элементов профиля Observation-PhdCompoundNumeric
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
meta.profile
Фиксированное значение "ObservationPhdCompoundNumeric"
string
1
meta.security
Статус результата измерения (если тестовый или демонстрационный)
Coding
0..1
meta.security.system
Система кодирования значений статуса. Фиксированное значение "http://terminology.hl7.org/CodeSystem/v3-ActReason"
uri
1
meta.security.code
Код статуса. Фиксированное значение "HTEST"
code
1
Собственные элементы
identifier
Идентификатор результата измерения
Identifier
1
status
Состояние измерения. Фиксированное значение "unknown" (состояние результата измерения не известно). Фактическое состояние измерения передается в других элементах в соответствии с таблицей 283
code
1
category
Категория измерения. Заполняется кодом LOINC, если измеряются жизненно важные показатели
Codeable-Concept
0..1
code
Вид измерения. Заполняется в соответствии с 11.11.16
Codeable-Concept
1
effective[x]
Дата и время или диапазон даты и времени выполнения измерения. Допустимые значения: effectiveDateTime | effectivePeriod
*
1
dataAbsentReason
Причина отсутствия результата измерения
Codeable-Concept
0..1
interpretation
Статус результата измерений (см. таблицу 283)
Codeable-Concept
0..1
device
Ссылка на экземпляр ресурса Device, идентифицирующий персональный медицинский прибор, с помощью которого получен результат измерения
Reference
0..1
derivedFrom
Ссылка на экземпляр ресурса Observation, содержащий сверку таймеров ПМП и менеджера
Reference
0..1
component
Компонент результата измерений или точность результатов
Backbone-Element
0..*
component.code
Вид измерения. Заполняется в соответствии с 11.11.16
Codeable-Concept
1
component.value-Quantity
Результат измерения
SimpleQuantity
0..1
component.data-AbsentReason
Причина отсутствия результата измерений (см. таблицу 280)
Codeable-Concept
0..1
component. interpretation
Статус результата измерений (см. таблицу 283)
Codeable-Concept
0..1
11.11.26 Профиль Observation-PhdCodedEnumeration
11.11.26.1 Общие требования
Профиль Observation-PhdCodedEnumeration (кодируемый результат) используется для передачи результата измерений, представленного кодом из определенного перечня. Примером может служить контекст питания, ассоциированный с измерением концентрации глюкозы и определяемый кодами: fasting (натощак), preprandial (перед едой), postprandial (после еды) и т.д.
Результат измерений, передаваемый ПМП, является кодируемым результатом, если он содержит один из атрибутов, перечисленных в таблице 296.
Таблица 296
Атрибуты кодируемого результата
Атрибут
Тип данных
Примечание
Enum-Observed-Value-Simple-OID
16-битовый код термина
Номер раздела берется из атрибута Type или Enum-Observed-Value-Partition
Enum-Observed-Value (вариант с типом значения OID-Type)
16-битовый код термина
Комплексный атрибут. Содержит компоненты metric-id (идентификатор метрики), state (статус результата измерения), value (значение). Номер раздела для значения берется из атрибута Type или Enum-Observed-Value-Partition
Атрибут Enum-Observed-Value-Simple-OID содержит 16-битовый код термина. Код раздела, требуемый для вычисления 32-битового номенклатурного кода, берется из атрибута Type или Enum-Observed-Value-Partition.
Атрибут Enum-Observed-Value содержит полиморфный компонент value. При передаче кодированного результата этот компонент должен иметь тип OID-Type.
Если результат измерения содержит атрибут Enum-Observed-Value-Simple-OID, то он должен содержать атрибут Metric-Id, содержащий код, идентифицирующий вид измерения. Если результат измерения содержит атрибут Enum-Observed-Value, то код вида измерений берется из его компонента metric-id. Полученный код вида измерения преобразуется в 32-битовый номенклатурный код в соответствии с 11.11.16. Результат преобразования передается в элементе Observation.code.
11.11.26.2 Отображение кодируемых результатов измерений на элементы ресурса Observation
Отображение кодируемых результатов измерений на элементы ресурса Observation приведено в таблице 297.
Таблица 297
Отображение кодируемых результатов измерений
на элементы ресурса Observation
Атрибут
Отображение на элементы ресурса Observation
Enum-Observed-
Observation.valueCodeableConcept.coding.system="urn:iso:std:iso:11073:10101"
Value-Simple-OID или Enum-Observed-Value.value
Observation.valueCodeableConcept.coding.code
Observation.valueCodeableConcept.text = мнемокод, соответствующий номенклатурному коду (необязателен), дополненный текстом, например "MDC_CTXT_GLU_MEAL_POSTPRANDIAL: После еды"
Enum-Observed-Value.metric-id
Значение компонента metric-id влияет на Observation.code, см. 11.11.16
Enum-Observed-Value.state
Преобразование компонента state приведено в таблице 283
11.11.26.3 Состав элементов профиля Observation-PhdCodedEnumeration
Профиль Observation-PhdCodedEnumeration (кодируемый результат измерения) оставляет в ресурсе Observation только те элементы, которые могут использоваться при преобразовании кодируемых результатов измерения из формата ГОСТ Р 56845 (рисунок 61 и таблица 298). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
Рисунок 61 - Профиль Observation-PhdCodedEnumeration
Таблица 298
Состав элементов профиля Observation-PhdCodedEnumeration
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
meta.profile
Фиксированное значение "Observation-PhdCodedEnumeration"
string
1
meta.security
Статус результата измерения (если тестовый или демонстрационный)
Coding
0..1
meta.security.system
Система кодирования значений статуса. Фиксированное значение "http://terminology.hl7.org/CodeSystem/v3-ActReason"
uri
1
meta.security.code
Код статуса. Фиксированное значение "HTEST"
code
1
Собственные элементы
identifier
Идентификатор результата измерения
Identifier
1
status
Состояние измерения. Фиксированное значение "unknown" (состояние результата измерения не известно). Фактическое состояние измерения передается в других элементах в соответствии с таблицей 283
code
1
category
Категория измерения. Заполняется кодом LOINC, если измеряются жизненно важные показатели
Codeable-Concept
0..1
code
Вид измерения. Заполняется в соответствии с 11.11.16
Codeable-Concept
1
effective[x]
Дата и время или диапазон даты и времени выполнения измерения. Допустимые значения: effectiveDateTime | effectivePeriod
*
1
dataAbsentReason
Причина отсутствия результата измерения (см. таблицу 280)
Codeable-Concept
0..1
interpretation
Статус результата измерений (см. таблицу 283)
Codeable-Concept
0..1
device
Ссылка на экземпляр ресурса Device, идентифицирующий персональный медицинский прибор, с помощью которого получен результат измерения
Reference
0..1
derivedFrom
Ссылка на экземпляр ресурса Observation, содержащий сверку таймеров ПМП и менеджера
Reference
0..1
11.11.27 Профиль Observation-PhdBitsEnumeration
11.11.27.1 Общие требования
Профиль Observation-PhdBitsEnumeration (битовый результат) используется для передачи результата измерений, представленного битовым полем. Примером могут служить сведения о состоянии датчика пульсоксиметра, содержащие признаки sensor-displaced (неправильная установка датчика) и т.д. Несколько таких признаков может быть передано в одном результате.
Результат измерений, передаваемый ПМП, является битовым результатом, если он содержит один из атрибутов, перечисленных в таблице 299.
Таблица 299
Атрибуты битового результата
Атрибут
Тип данных
Примечание
Enum-Observed-Value-Simple-Bit-Str
32-битовое значение
Каждый бит может означать отдельный признак
Enum-Observed-Value-Basic-Bit-Str
16-битовое значение
Каждый бит может означать отдельный признак
Enum-Observed-Value (вариант с типом значения BITS-32)
32-битовое значение
Комплексный атрибут. Содержит компоненты metric-id (идентификатор метрики), state (статус результата измерения), value (значение). Каждый бит значения может означать отдельный признак
Атрибут Enum-Observed-Value-Basic-Bit-Str содержит 16-битовый код термина, а атрибут Enum-Observed-Value-Simple-Bit-Str - 32-битовый код термина. Код раздела, требуемый для вычисления 32-битового номенклатурного кода, берется из атрибута Type или Enum-Observed-Value-Partition.
Атрибут Enum-Observed-Value содержит полиморфный компонент value. При передаче кодированного результата этот компонент должен иметь тип BITS-32.
Если результат измерения содержит атрибут Enum-Observed-Value-Basic-Bit-Str или Enum-Observed-Value-Simple-Bit-Str, то он должен содержать атрибут Metric-Id, содержащий код, идентифицирующий вид измерения. Если результат измерения содержит атрибут Enum-Observed-Value, то код вида измерений берется из его компонента metric-id. Полученный код вида измерения преобразуется в 32-битовый номенклатурный код в соответствии с 11.11.16. Результат преобразования передается в элементе Observation.code.
Результат измерений включает в себя атрибут Type. Его значение преобразуется в 32-битовый номенклатурный код в соответствии с 11.11.16. Результат преобразования передается в элементе Observation.code. Элемент Observation.value не заполняется. Если в атрибуте Measurement-Status установлены биты 0 (Ошибочный результат), 2 (Результат недоступен) или 10 (В процессе измерения), то соответствующий код должен быть передан в элементе Observation.dataAbsentReason. В этом случае компоненты битового результата не передаются.
11.11.27.2 Отображение битовых результатов измерений на элементы ресурса Observation
Отображение битовых результатов измерений на элементы ресурса Observation приведено в таблице 300. Бит результата измерения с номером n обозначается через bit[n], номер соответствующего ему экземпляра компонента обозначается через m. Поскольку не все биты результата могут быть значащими и снятые биты состояний не должны отображаться в компонентах ресурса Observation, то m <= n.
Таблица 300
Отображение битовых результатов измерений на элементы
ресурса Observation
Атрибут
Отображение на элементы ресурса Observation
Enum-Observed-Value-Basic-Bit_str.bit[n] (0 <= n <= 15), Enum-Observed-Value-Simple-Bit_str.bit[n] (0 <= n <= 31), Enum-Observed-Value.value.bit[n] (0 <= n <= 31)
Observation.component[m].code.coding.system="http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7"
Observation.component[m].code.coding.code= номенклатурный код измерения, дополненный точкой и значением n
Observation.component[m].code.text= имя бита n в определении АСН.1 битового результата (необязательно), например "sensor-displaced"
Observation.component[m].valueCodableConcept.coding.system="http://terminology.hl7.org/CodeSystem/v2-0136"
Observation.component[m].valueCodableConcept.coding.code="Y", если бит n установлен, "N", если бит n снят
Observation.valueCodeableConcept.text = текст на русском языке, соответствующий имени и значению бита (необязательно), например "Неправильная установка датчика"
Enum-Observed-Value.metric-id
Значение компонента metric-id влияет на Observation.code, см. 11.11.16
Enum-Observed-Value.state
Преобразование компонента state приведено в таблице 283
Если бит n не поддерживается
Observation.component[m].dataAbsentReason.coding.system="http://terminology.hl7.org/CodeSystem/data-absent-reason"
Observation.component[m].dataAbsentReason.coding.code="unsupported"
11.11.27.3 Состав элементов профиля Observation-PhdBitsEnumeration
Профиль Observation-PhdBitsEnumeration (кодируемый результат измерения) оставляет в ресурсе Observation только те элементы, которые могут использоваться при преобразовании кодируемых результатов измерения из формата ГОСТ Р 56845 (рисунок 62 и таблица 301). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
Рисунок 62 - Профиль Observation-PhdBitsEnumeration
Таблица 301
Состав элементов профиля Observation-PhdBitsEnumeration
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
meta.profile
Фиксированное значение "Observation-PhdBitsEnumeration"
string
1
meta.security
Статус результата измерения (если тестовый или демонстрационный)
Coding
0..1
meta.security. system
Система кодирования значений статуса. Фиксированное значение "http://terminology.hl7.org/CodeSystem/v3-ActReason"
uri
1
meta.security.code
Код статуса. Фиксированное значение "HTEST"
code
1
Собственные элементы
identifier
Идентификатор результата измерения
Identifier
1
status
Состояние измерения. Фиксированное значение "unknown" (состояние результата измерения не известно). Фактическое состояние измерения передается в других элементах в соответствии с таблицей 283
code
1
category
Категория измерения. Заполняется кодом LOINC, если измеряются жизненно важные показатели
CodeableConcept
0..1
code
Вид измерения. Заполняется в соответствии с 11.11.16
CodeableConcept
1
effective[x]
Дата и время или диапазон даты и времени выполнения измерения. Допустимые значения: effectiveDateTime | effectivePeriod
*
1
dataAbsentReason
Причина отсутствия результата измерения (см. таблицу 280)
CodeableConcept
0..1
interpretation
Статус результата измерений (см. таблицу 283)
CodeableConcept
0..1
device
Ссылка на экземпляр ресурса Device, идентифицирующий персональный медицинский прибор, с помощью которого получен результат измерения
Reference
0..1
derivedFrom
Ссылка на экземпляр ресурса Observation, содержащий сверку таймеров ПМП и менеджера
Reference
0..1
component
Бит результата измерений
BackboneElement
0..*
component.code
Вид измерения. Заполняется в соответствии с таблицей 300
CodeableConcept
1
component.valueCoding
Результат измерения. Заполняется в соответствии с таблицей 300
ValueCoding
0..1
component.dataAbsentReason
Причина отсутствия результата измерений
CodeableConcept
0..1
component.dataAbsentReason.coding.system
Фиксированное значение "http://terminology.hl7.org/CodeSystem/data-absent-reason"
uri
1
component.dataAbsentReason.coding.code
Фиксированное значение "unsupported"
code
1
11.11.28 Профиль Observation-PhdStringEnumeration
11.11.28.1 Общие требования
Профиль Observation-PhdStringEnumeration (строковый результат) используется для передачи результата измерений, представленного строкой теста. Примером может служить наименование физического упражнения, контролируемого монитором сердечно-сосудистой активности.
Результат измерений, передаваемый ПМП, является строковым результатом, если он содержит один из атрибутов, перечисленных в таблице 302.
Таблица 302
Атрибуты кодируемого результата
Атрибут
Тип данных
Примечание
Enum-Observed-Value-Simple-Str
Строка печатаемых символов в кодировке ASCII
Номер раздела берется из атрибута Type или Enum-Observed-Value-Partition
Enum-Observed-Value (вариант с типом значения OCTET STRING)
Строка печатаемых символов в кодировке ASCII
Комплексный атрибут. Содержит компоненты metric-id (идентификатор метрики), state (статус результата измерения), value (значение). Номер раздела для значения берется из атрибута Type или Enum-Observed-Value-Partition
Атрибут Enum-Observed-Value содержит полиморфный компонент value. При передаче строкового результата этот компонент должен иметь тип OCTET STRING.
Если результат измерения содержит атрибут Enum-Observed-Value-Simple-Str, то он должен содержать атрибут Metric-Id, содержащий код, идентифицирующий вид измерения. Если результат измерения содержит атрибут Enum-Observed-Value, то код вида измерений берется из его компонента metric-id. Полученный код вида измерения преобразуется в 32-битовый номенклатурный код в соответствии с 11.11.16. Результат преобразования передается в элементе Observation.code.
11.11.28.2 Отображение строковых результатов измерений на элементы ресурса Observation
Отображение строковых результатов измерений на элементы ресурса Observation приведено в таблице 303.
Таблица 303
Отображение строковых результатов измерений
на элементы ресурса Observation
Атрибут
Отображение на элементы ресурса Observation
Enum-Observed-Value-Simple-Str или Enum-Observed-Value.value
Observation.valueString
Enum-Observed-Value.metric-id
Значение компонента metric-id влияет на Observation.code, см. 11.11.16
Enum-Observed-Value.state
Преобразование компонента state приведено в таблице 283
11.11.28.3 Состав элементов профиля Observation-PhdStringEnumeration
Профиль Observation-PhdStringEnumeration (строковый результат измерения) оставляет в ресурсе Observation только те элементы, которые могут использоваться при преобразовании кодируемых результатов измерения из формата ГОСТ Р 56845 (рисунок 63 и таблица 304). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
Рисунок 63 - Профиль Observation-PhdStringEnumeration
Таблица 304
Состав элементов профиля Observation-PhdStringEnumeration
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
meta.profile
Фиксированное значение "Observation-PhdStringEnumeration"
string
1
meta.security
Статус результата измерения (если тестовый или демонстрационный)
Coding
0..1
meta.security.system
Система кодирования значений статуса. Фиксированное значение "http://terminology.hl7.org/CodeSystem/v3-ActReason"
uri
1
meta.security. code
Код статуса. Фиксированное значение "HTEST"
code
1
Собственные элементы
identifier
Идентификатор результата измерения
Identifier
1
status
Состояние измерения. Фиксированное значение "unknown" (состояние результата измерения не известно). Фактическое состояние измерения передается в других элементах в соответствии с таблицей 283
code
1
code
Вид измерения. Заполняется в соответствии с 11.11.16
CodeableConcept
1
effectiveDateTime
Дата и время или диапазон даты и времени выполнения измерения. Допустимые значения: effectiveDateTime | effectivePeriod
*
1
valueString
Результат измерения
string
0..1
dataAbsent-Reason
Причина отсутствия результата измерения (см. таблицу 280)
CodeableConcept
0..1
interpretation
Статус результата измерений (см. таблицу 283)
CodeableConcept
0..1
device
Ссылка на экземпляр ресурса Device, идентифицирующий персональный медицинский прибор, с помощью которого получен результат измерения
Reference
0..1
derivedFrom
Ссылка на экземпляр ресурса Observation, содержащий сверку таймеров ПМП и менеджера
Reference
0..1
11.11.29 Профиль Observation-PhdRtsa
11.11.29.1 Общие требования
Профиль Observation-PhdRtsa (массив считываний) используется для передачи периодических считываний биосигнала, например, плетизмограмм или кардиограмм. Массив считываний является одномерным. Для передачи векторов ускорения или считываний нескольких отведений кардиограммы должны использоваться отдельные экземпляры ресурса Observation
Результат измерений, передаваемый ПМП, является массивом считываний, если он содержит атрибут Simple-Sa-Observed-Value. Перечень его атрибутов, учитываемых при преобразовании в экземпляр ресурса Observation, приведен в таблице 305.
Таблица 305
Атрибуты массива считываний
Атрибут
Тип данных
Примечание
Simple-Sa-Observed-Value
OCTET STRING
Строка байтов, содержащая считывания в формате, определяемом атрибутами Sa-Specification и Scale-and-Range-Specification
Sample-Period.period
integer
Интервал между считываниями, выраженный в 1/8 миллисекунды. Таким образом, 8000 = 1 с
Unit-Code
OID-Type
16-битовый термин для единиц измерения. Для получения номенклатурного кода следует использовать раздел 4 номенклатуры MDC (см. 11.11.17)
Sa-Specification.sampletype.significant-bits
integer
Число значащих битов в считывании
Sa-Specification.sampletype.sample-size
integer
Число битов в считывании; задает значение X в атрибутах Scale-and-Range-SpecificationX
Sa-Specification.array-size
integer
Число считываний, содержащихся в атрибуте Simple-Sa-Observed-Value
Scale-and-Range-SpecificationX.upper-absolute-value
FLOAT
Верхняя граница результата измерений (необязательная)
Scale-and-Range-SpecificationX.lower-absolute-value
FLOAT
Нижняя граница результата измерений (необязательная)
Scale-and-Range-SpecificationX.upper-scaled-value
X-битовое целое число
Верхняя граница считываний (необязательная)
Scale-and-Range-SpecificationX.lower-scaled-value
X-битовое целое число
Нижняя граница считываний (необязательная)
Считывание представляет собой целое число, полученное с помощью аналого-цифрового преобразователя. Для преобразования считывания в результат измерения используется следующая формула:
y = ((A - B)x)/(I - J) + A - (A - B)I/(I - J),
где y = результат измерения;
x = считывание;
A = верхняя граница результатов измерений;
B = нижняя граница результатов измерений;
I = верхняя граница считываний;
J = нижняя граница считываний.
Эта формула может быть приведена к следующему виду:
y = sx + b,
где s - коэффициент масштабирования, а b - смещение нулевого значения считывания. Величин s определяется как (A - B)/(I - J), а b - как (BI - AJ)/(I - J). Единицы измерения определяются кодом термина, переданным в атрибуте Unit-Code.
Если атрибут significant-bits равен 255, то считывания, а также значения атрибутов lower-scaled-value и upper-scaled-value должны интерпретироваться как целые числа со знаком, представленные в форме дополнения до двух.
11.11.29.2 Отображение массива считываний на элементы ресурса Observation
Отображение массива считываний на элементы ресурса Observation приведено в таблице 306. Считывание с номером i обозначается как data[i].
Таблица 306
Отображение массива считываний
на элементы ресурса Observation
Атрибут
Отображение на элементы ресурса Observation
Simple-Sa-Observed-Value.data[i]
Observation.valueSampledData.data[i]
Unit-Code.code
Observation.valueSampledData.origin.system = ="http://unitsofmeasure.org"
Observation.valueSampledData.origin.code (эквивалентный код UCUM)
Смещение b
Observation.valueSampledData.origin.value = b
Коэффициент масштабирования s
Observation.valueSampledData.factor = s
Sample-Period.period/8
Observation.valueSampledData.interval
Observation.valueSampledData.intervalUnit = "ms"
-
Observation.valueSampledData.dimensions = 1
Scale-and-Range-SpecificationX.upper-absolute-value
Observation.referenceRange.high.value
Unit-Code.code
Observation.referenceRange.high.system = ="http://unitsofmeasure.org"
Observation.referenceRange.high.code ((эквивалентный код UCUM))
Scale-and-Range-SpecificationX.lower-absolute-value
Observation.referenceRange.low.value
Unit-Code.code
Observation.referenceRange.low.system = ="http://unitsofmeasure.org"
Observation.referenceRange.low.code ((эквивалентный код UCUM))
11.11.29.3 Состав элементов профиля Observation-PhdRtsa
Профиль Observation-PhdRtsa (массив считываний) оставляет в ресурсе Observation только те элементы, которые могут использоваться для передачи результатов измерения биосигнала (рисунок 64 и таблица 307). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
Рисунок 64 - Профиль Observation-PhdRtsa
Таблица 307
Состав элементов профиля Observation-PhdRtsa
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
meta.profile
Фиксированное значение "Observation-PhdRtsa"
string
1
meta.security
Статус результата измерения (если тестовый или демонстрационный)
Coding
0..1
meta.security.system
Система кодирования значений статуса. Фиксированное значение "http://terminology.hl7.org/CodeSystem/v3-ActReason"
uri
1
meta.security.code
Код статуса. Фиксированное значение "HTEST"
code
1
Собственные элементы
identifier
Идентификатор результата измерения
Identifier
1
status
Состояние измерения. Фиксированное значение "unknown" (состояние результата измерения не известно). Фактическое состояние измерения передается в других элементах в соответствии с таблицей 283
code
1
code
Вид измерения. Заполняется в соответствии с 11.11.16
CodeableConcept
1
effectiveDateTime
Дата и время или диапазон даты и времени выполнения измерения. Допустимые значения: effectiveDateTime | effectivePeriod
*
1
valueSampledData
Результат измерения
string
0..1
valueSampledData.origin
Смещение нулевого значения и его единицы
SimpleQuantity
1
valueSampledData. origin.value
Значение смещения
decimal
1
valueSampledData. origin.system
Система кодирования единиц измерения. Фиксированное значение "http://unitsofmeasure.org"
uri
1
valueSampledData. origin.code
Код единицы измерения в системе UCUM
code
1
valueSampledData.interval
Число intervalUnits между считываниями
decimal
0..1
factor
Масштабирующий коэффициент, применяемый к считыванию до добавления базового смещения
decimal
0..1
valueSampledData.intervalUnit
Единицы измерения интервала между считываниями. Фиксированное значение "ms" (миллисекунды)
code
1
valueSampledData. factor
Масштабирующий коэффициент, применяемый к считыванию до добавления базового смещения
decimal
0..1
dimensions
Число считываний в каждый момент времени. Фиксированное значение "1"
positiveInt
1
dataAbsentReason
Причина отсутствия результата измерения (см. таблицу 280)
CodeableConcept
0..1
interpretation
Статус результата измерений (см. таблицу 283)
CodeableConcept
0..1
device
Ссылка на экземпляр ресурса Device, идентифицирующий персональный медицинский прибор, с помощью которого получен результат измерения
Reference
0..1
referenceRange
Диапазон значений считываний
BackboneElement
0..1
referenceRange.low
Нижняя граница диапазона
SimpleQuantity
0..1
referenceRange.low. value
Значение нижней границы
decimal
1
referenceRange.low.system
Система кодирования единиц измерения. Фиксированное значение "http://unitsofmeasure.org"
uri
1
referenceRange.low. code
Код единицы измерения в системе UCUM (должен совпадать с valueSampledData.origin.code)
code
1
referenceRange.high
Верхняя граница диапазона
SimpleQuantity
0..1
referenceRange.high.value
Значение верхней границы
decimal
1
referenceRange.high.system
Система кодирования единиц измерения. Фиксированное значение "http://unitsofmeasure.org"
uri
1
referenceRange.high. code
Код единицы измерения в системе UCUM (должен совпадать с valueSampledData.origin.code)
code
1
derivedFrom
Ссылка на экземпляр ресурса Observation, содержащий сверку таймеров ПМП и менеджера
Reference
0..1
11.11.30 Профиль Observation-PhdMedia
11.11.30.1 Общие требования
Профиль Observation-PhdMedia (медиаданные) может использоваться для передачи растровых изображений, например, плетизмограмм или кардиограмм, аудиосигналов фетального допплера, видеоданных.
Предполагается, что ПМП, передающий медиаданные, способен вместе с ними передать следующую информацию:
а) уникальный идентификатор медицинского прибора, например, MAC-адрес или его эквивалент для интерфейсов Bluetooth и ZigBee, идентификатор PID.VID устройства USB, международный идентификатор мобильного абонента IMSI;
б) дату и время выполнения измерения.
Менеджер ПМП или шлюз, получающий медиаданные, должен добавить к ним следующую информацию:
а) свой идентификатор (может совпадать с идентификатором ПМП, если ПМП интегрирован в менеджер или шлюз);
б) тип среды MIME,
в) дату и время получения медиаданных от ПМП;
г) вид измерения.
11.11.30.2 Состав элементов профиля Observation-PhdMedia
Профиль Observation-PhdMedia (медиаданные) оставляет в ресурсе Observation только те элементы, которые могут использоваться для передачи медиаданных и сопутствующей информации (рисунок 65 и таблица 308). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
Рисунок 65 - Профиль Observation-PhdMedia
Таблица 308
Состав элементов профиля Observation-PhdMedia
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
meta.profile
Фиксированное значение "Observation-PhdMedia"
string
1
Собственные элементы
status
Состояние измерения. Фиксированное значение "final" (окончательный результат)
code
1
code
Вид измерений
CodeableConcept
1
code.coding
Кодированное представление вида измерений
Coding
0..1
code.coding.system
Система кодирования. Фиксированное значение "http://loinc.org"
uri
1
code.coding.code
Код вида измерений в системе LOINC
code
1
code.text
Наименование вида измерений
string
0..1
effectiveDateTime
Показание таймера менеджера на момент получения результата измерения
dateTime
1
valueAttachment
Медиаданные
Attachment
1
valueAttachment.contentType
Тип содержания MIME, включая кодировку и т.д. Привязка к набору значений: http://hl7.org/fhir/ValueSet/mimetypes (обязательная)
code
1
valueAttachment.data
Вложенные данные в формате base64
base64Binary
1
valueAttachment.title
Наименование данных
string
0..1
valueAttachment. creation
Дата и время выполнения измерения
dateTime
1
device
Ссылка на экземпляр ресурса Device, идентифицирующий ПМП
Reference
1
device.type
Фиксированное значение "Device"
string
1
device.identifier
Уникальный идентификатор ПМП
Identifier
1
device.identifier.value
Значение идентификатора
string
1
11.11.31 Профиль Observation-PhdCoincidentTimeStamp
11.11.31.1 Общие требования
Профиль Observation-PhdCoincidentTimeStamp (сверка таймеров) используется для сравнения линий времени ПМП и менеджера или шлюза. Элемент Observation.effectiveDateTime должен содержать текущее значение таймера менеджера, а Observation.valueDateTime или Observation.valueQuantity - текущее значение таймера ПМП. Вариант Observation.valueDateTime выбирается, если ПМП использует таймер даты и времени, а вариант Observation.valueQuantity - если ПМП использует тактовый счетчик.
Если результат измерения, передаваемый ПМП, содержит штамп даты и времени или значение тактового счетчика, то соответствующий ему экземпляр ресурса Observation должен в себя ссылку на экземпляр ресурса Observation, содержащий наиболее актуальный результат сверки таймеров. В противном случае ссылка не создается.
11.11.31.2 Код вида измерений
В элементе Observation.code передается тип таймера, используемый ПМП. Менеджер ПМП определяет тип таймера, считывая атрибуты объекта MDS, приведенным в таблице 309.
Таблица 309
Атрибуты объекта MDS, указывающие тип таймера ПМП
Атрибут
Тип таймера
Описание
Отображение на элементы ресурса Observation
Date-and-Time
Абсолютное время
Дата и время со смещением относительно UTC
Observation.code.coding.code = 67975
Base-Offset-Time
Базовое смещение
Дата и время со смещением относительно другой базы
Observation.code.coding.code = 68226
Relative-Time
Тактовый счетчик
Последовательность тактов длительностью 1/8 миллисекунды
Observation.code.coding.code = 67983
HiRes-Relative-Time
Тактовый счетчик с высоким разрешением
Последовательность тактов длительностью 1 микросекунда
Observation.code.coding.code = 68072
Элемент Observation.code.coding.system должен иметь значение "urn:iso:std:iso:11073:10101".
11.11.31.3 Состав элементов профиля Observation-PhdCoincidentTimeStamp
Профиль Observation-PhdCoincidentTimeStamp (сверка таймеров) оставляет в ресурсе Observation только те элементы, которые могут использоваться для передачи результата сверки таймеров (рисунок 66 и таблица 310). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
Рисунок 66 - Профиль Observation-PhdCoincidentTimeStamp
Таблица 310
Состав элементов профиля Observation-PhdCoincidentTimeStamp
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
meta.profile
Фиксированное значение "Observation-PhdCoincidentTimeStamp"
string
1
Собственные элементы
status
Состояние измерения. Фиксированное значение "final" (окончательный результат)
code
1
code
Тип таймера ПМП. Заполняется в соответствии с таблицей 309
CodeableConcept
1
effectiveDateTime
Показание таймера менеджера на момент сверки
dateTime
1
value[x]
Показание таймера ПМП на момент сверки. Допустимые значения: valueDateTime (для таймера даты и времени) | valueQuantity (для тактового счетчика)
string
1
device
Ссылка на экземпляр ресурса Device, идентифицирующий ПМП
Reference
1
11.12 Ресурс Patient - сведения о пациенте
11.12.1 Область применения и использования
Тип ресурса Patient используется для описания общих демографических данных пациента и его идентификации в различных реестрах, в первую очередь в списках пациентов организаций здравоохранения. В его элементах отсутствуют сведения о гражданстве, этнической группе, статусе донора органов и т.д. Эти сведения могут быть переданы в экземплярах ресурсов других типов или в расширениях.
11.12.2 Структура ресурса
Ресурс Patient является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Patient представлен на рисунке 67 и в таблице 311.
Рисунок 67 - Ресурс Patient
Таблица 311
Состав элементов ресурса Patient
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Идентификатор пациента
Identifier
0..*
active
Признак активности данной записи о пациенте
boolean
0..1
name
Именование пациента
HumanName
0..*
telecom
Контактная информация пациента
ContactPoint
0..*
gender
Пол пациента. Допустимые значения: male (мужской) | female (женский) | other (другой) | unknown (неизвестный)
code
0..1
birthDate
Дата рождения пациента (с точностью до дня, месяца или года)
date
0..1
deceased[x]
Признак или дата и время смерти пациента
*
0..1
address
Адрес пациента
Address
0..*
maritalStatus
Семейное положение пациента
CodeableConcept
0..1
multipleBirth[x]
Признак или номер близнеца
*
0..1
photo
Фотография пациента
Attachment
0..*
contact
Контактное лицо или организация
BackboneElement
0..*
contact. relationship
Отношение контактного лица к пациенту
CodeableConcept
0..*
contact.name
Именование контактного лица
HumanName
0..1
contact.address
Адрес контактного лица
Address
0..1
contact.telecom
Контактная информация контактного лица
ContactPoint
0..*
contact.gender
Пол контактного лица. Допустимые значения: male (мужской) | female (женский) | other (другой) | unknown (неизвестный)
code
0..1
contact. organization
Ссылка на организацию, ассоциированную с контактным лицом
Reference
0..1
contact.period
Период действия информации о контактном лице
Period
0..1
communication
Язык общения с пациентом
BackboneElement
0..*
communication. language
Язык
CodeableConcept
1
communication. preferred
Признак предпочтительного языка общения
boolean
0..1
general-Practitioner
Ссылка на участкового терапевта или врача общей практики пациента
Reference
0..*
managing-Organization
Ссылка на организацию, ответственную за сведения о пациенте
Reference
0..1
link
Ссылка на другой экземпляр сведений о пациенте или на сведения о близком лице
BackboneElement
0..*
link.other
Ссылка на другой экземпляр ресурса Person или экземпляр ресурса RelatedPerson
Reference
1
link.type
Тип связи с другим экземпляром ресурса. Допустимые значения: replaced-by (заменен ссылочным экземпляром | replaces (заменяет ссылочный экземпляр) | refer (ссылочный экземпляр содержит дополнительные сведения) | seealso (ссылочный экземпляр содержит сведения об этом же лице)
code
1
11.12.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 312.
Таблица 312
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Patient.gender
http://hl7.org/fhir/ValueSet/administrative-gender
Обязательная
Пол лица, указываемый в административных целях
Patient.maritalStatus
http://hl7.org/fhir/ValueSet/marital-status
Extensible
Семейное положение
Patient.contact.relationship
http://hl7.org/fhir/ValueSet/patient-contactrelationship
Extensible
Отношение контактного лица к пациенту
Patient.contact. gender
http://hl7.org/fhir/ValueSet/administrative-gender
Обязательная
Пол лица, указываемый в административных целях
Patient. communication.language
http://hl7.org/fhir/ValueSet/all-languages
Обязательная
Все коды из BCP-47 [30] (см. http://tools.ietf.org/html/bcp47)
http://hl7.org/fhir/ValueSet/languages
Рекомендованная
Коды наиболее распространенных языков
Patient.link.type
http://hl7.org/fhir/ValueSet/link-type
Обязательная
Тип связи с другим экземпляром ресурса
11.12.4 Ограничения ресурса Patient
Ограничения ресурса Patient описаны в таблице 313.
Таблица 313
Ограничения ресурса Patient
Идентификатор
Вид
Путь
Описание
Выражение
pat-1
Правило
Patient.contact
Хотя бы один из компонентов name, telecom, address или organization должен присутствовать
name.exists() or telecom.exists() or address.exists() or organization.exists()
11.12.5 Параметры поиска экземпляров ресурса Patient
Специальные параметры поиска экземпляров ресурса Patient описаны в таблице 314. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 314
Специальные параметры поиска экземпляров ресурса Patient
Имя
Тип
Описание
Выражение
active
token
Признак активности данной записи о пациенте
Patient.active
address
string
Поиск по строковым компонентам, включая line, city, district, state, country, postalCode, text
Patient.address
address-city
string
Город
Patient.address.city
address-country
string
Страна
Patient.address.country
address-postalcode
string
Почтовый индекс
Patient.address.postalCode
address-state
string
Единица административного деления верхнего уровня, например, область, край, республика
Patient.address.state
address-use
token
Код использования адреса
Patient.address.use
birthdate
date
Дата рождения
Patient.birthDate
death-date
date
Дата и время смерти
(Patient.deceased.ofType(dateTime))
deceased
token
Наличие признака или даты и времени смерти
Patient.deceased.exists() and Patient.deceased != false
email
token
Электронная почта
Patient.telecom.where (system='email')
family
string
Фамилия
Patient.name.family
gender
token
Пол
Patient.gender
general practitioner
reference
Ссылка на участкового терапевта или врача общей практики
Patient.generalPractitioner
(Practitioner, Organization, PractitionerRole)
given
string
Имя или отчество
Patient.name.given
identifier
token
Идентификатор пациента
Patient.identifier
language
token
Код языка общения (независимо от предпочтительности)
Patient.communication.language
link
reference
Ссылка на другой экземпляр сведений о пациенте или на сведения о близком лице
Patient.link.other
(Patient, RelatedPerson)
name
string
Поиск по строковым компонентам именования, включая family, given, prefix, suffix, text
Patient.name
organization
reference
Ссылка на организацию, ответственную за сведения о пациенте
Patient.managingOrganization
(Organization)
phone
token
Телефон
Patient.telecom.where(system='phone')
phonetic
string
Фонетический поиск по фамилии, имени или отчеству
Patient.name
telecom
token
Телекоммуникационный адрес (независимо от типа)
Patient.telecom
11.12.6 Профиль пациента при дистанционном мониторинге
Профиль пациента при дистанционном мониторинге Patient-Dm ограничивает элементы ресурса Patient в соответствии с рисунком 68 и таблицей 315. Имя ресурса остается неизменным - Patient, имя профиля передается в элементе meta.profile.
Рисунок 68 - Профиль Patient-Dm
Таблица 315
Состав элементов Patient-Dm
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
Собственные элементы
identifier
Уникальный идентификатор пациента в медицинской информационной системе
Identifier
1
11.13 Ресурс Practitioner - сведения о медицинском специалисте
11.13.1 Область применения и использования
Тип ресурса Practitioner используется для описания общих демографических данных медицинского работника, контактной информации и квалификации.
11.13.2 Структура ресурса
Ресурс Practitioner является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Practitioner представлен на рисунке 69 и в таблице 316.
Рисунок 69 - Ресурс Practitioner
Таблица 316
Состав элементов ресурса Practitioner
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifier-Extension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Идентификатор медицинского работника
Identifier
0..*
active
Признак активности данной записи о медицинском работнике
boolean
0..1
name
Именование медицинского работника
HumanName
0..*
telecom
Контактная информация медицинского работника
ContactPoint
0..*
gender
Пол медицинского работника. Допустимые значения: male (мужской) | female (женский) | other (другой) | unknown (неизвестный)
code
0..1
birthDate
Дата рождения медицинского работника (с точностью до дня, месяца или года)
date
0..1
deceased[x]
Признак или дата и время смерти медицинского работника
*
0..1
address
Адрес медицинского работника
Address
0..*
photo
Фотография медицинского работника
Attachment
0..*
qualification
Квалификация медицинского работника
BackboneElement
0..*
qualification.identifier
Ссылка на другой экземпляр ресурса Person или экземпляр ресурса RelatedPerson
Identifier
0..*
qualification.code
Код квалификации
CodeableConcept
1
qualification.period
Период действия квалификации
Period
0..1
qualification.issuer
Ссылка на организацию, удостоверившую квалификацию
Reference
0..1
11.13.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 317.
Таблица 317
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Practitioner.gender
http://hl7.org/fhir/ValueSet/administrative-gender
Обязательная
Пол лица, указываемый в административных целях
Practitioner.qualification.code
http://terminology.hl7.org/ValueSet/v2-0360
Обязательная
Код квалификации
Practitioner. communication.language
http://hl7.org/fhir/ValueSet/all-languages
Обязательная
Все коды из BCP-47 [30] (см. http://tools.ietf.org/html/bcp47)
http://hl7.org/fhir/ValueSet/languages
Рекомендованная
Коды наиболее распространенных языков
11.13.4 Параметры поиска экземпляров ресурса Practitioner
Специальные параметры поиска экземпляров ресурса Practitioner описаны в таблице 318. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 318
Специальные параметры поиска экземпляров
ресурса Practitioner
Имя
Тип
Описание
Выражение
active
token
Признак активности данной записи о медицинском работнике
Practitioner.active
address
string
Поиск по строковым компонентам, включая line, city, district, state, country, postalCode, text
Practitioner.address
address-city
string
Город
Practitioner.address.city
address-country
string
Страна
Practitioner.address.country
address-postalcode
string
Почтовый индекс
Practitioner.address.postalCode
address-state
string
Единица административного деления верхнего уровня, например, область, край, республика
Practitioner.address.state
address-use
token
Код использования адреса
Practitioner.address.use
communication
token
Язык общения с медицинским работником
Practitioner.communication.language
death-date
date
Дата и время смерти
(Practitioner.deceased.ofType(dateTime))
deceased
token
Наличие признака или даты и времени смерти
Practitioner.deceased.exists() and Practitioner.deceased != false
email
token
Электронная почта
Practitioner.telecom.where(system='email')
family
string
Фамилия
Practitioner.name.family
gender
token
Пол
Practitioner.gender
given
string
Имя или отчество
Practitioner.name.given
identifier
token
Идентификатор медицинского работника
Practitioner.identifier | Practitioner.qualification.identifier
name
string
Поиск по строковым компонентам именования, включая family, given, prefix, suffix, text
Practitioner.name
phone
token
Телефон
Practitioner.telecom.where(system='phone')
phonetic
string
Фонетический поиск по фамилии, имени или отчеству
Practitioner.name
qualification-period
date
Срок действия квалификации
Practitioner.qualification.period
telecom
token
Телекоммуникационный адрес (независимо от типа)
Practitioner.telecom
11.13.5 Профиль медицинского работника при дистанционном мониторинге
Профиль медицинского работника при дистанционном мониторинге Practitioner-Dm ограничивает элементы ресурса Practitioner в соответствии с рисунком 70 и таблицей 319. Имя ресурса остается неизменным - Practitioner, имя профиля передается в элементе meta.profile.
Рисунок 70 - Профиль Practitioner-Dm
Таблица 319
Состав элементов Practitioner-Dm
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
Собственные элементы
identifier
Идентификатор медицинского работника
Identifier
1
telecom
Контактная информация медицинского работника
ContactPoint
1..*
11.14 Ресурс DiagnosticReport - заключение врача
11.14.1 Область применения и использования
Тип ресурса DiagnosticReport используется для описания заключения врача. В его структуре предусмотрены сведения о самом заключении, о субъекте заключения и, если это заключение врача-лаборанта или патологоанатома, о биоматериале.
11.14.2 Структура ресурса
Ресурс DiagnosticReport является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса DiagnosticReport представлен на рисунке 71 и в таблице 320.
Рисунок 71 - Ресурс DiagnosticReport
Таблица 320
Состав элементов ресурса DiagnosticReport
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifier-Extension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Внешний идентификатор заключения
Identifier
0..*
basedOn
Ссылка на требование, для выполнения которого предназначено заключение
Reference
0..*
category
Категория клинической дисциплины, отделения или службы, составившей заключение (например, гематология, банк крови)
CodeableConcept
0..1
code
Код/наименование заключения
CodeableConcept
0..1
encounter
Ссылка на случай медицинской помощи
Reference
0..1
subject
Ссылка на субъект назначения. Обычно субъектом является пациент, но не всегда
Reference
0..1
status
Состояние составления заключения. Допустимые значения: registered (составлено, но пока не доступно) | partial (частичное) | preliminary (предварительное, может быть неполным или не проверенным) | modified (изменено до того, как стало окончательным) | final (окончательное) | amended (изменено после того, как стало окончательным) | corrected (исправлено) | appended (дополнено) | cancelled (отменено) | entered-in-error (введено по ошибке) | unknown (неизвестное)
code
1
effective[x]
Физиологически релевантные дата и время либо период, к которому относится заключение (например, дата и время взятия биоматериала)
*
0..1
issued
Дата и время создания текущей версии заключения
instant
0..1
performer
Ссылка на составителя заключения
Reference
0..*
resultsInterpreter
Ссылка на лицо или организацию, ответственную за содержание заключения
Reference
0..*
specimen
Ссылка на идентификацию и описание биоматериала, по которому составлено заключение
Reference
0..*
result
Ссылка на результат исследования, вошедший в заключение
Reference
0..*
note
Примечание к заключению
Annotation
0..*
study
Ссылка на исследование генома или лучевое исследование
Reference
0..*
supportingInfo
Дополнительные сведения, использованные для обоснования заключения
BackboneElement
0..*
supportingInfo. type
Тип дополнительных сведений
CodeableConcept
1
supportingInfo.reference
Ссылка на экземпляр ресурса, содержащий дополнительные сведения
Reference
1
media
Ссылка на источник изображения или двоичных данных
BackboneElement
0..*
media.comment
Причина включения изображения или данных в заключение либо иные комментарии к ним
string
0..1
media.link
Ссылка на источник изображения или данных
Reference
1
composition
Ссылка на экземпляр ресурса Composition, описывающий структуру содержания заключения
Reference
0..1
conclusion
Текст заключения
markdown
0..1
conclusionCode
Код, представляющий заключение (например, код диагноза)
CodeableConcept
0..*
presentedForm
Форматированное представление заключения
Attachment
0..*
11.14.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 321.
Таблица 321
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
DiagnosticReport.status
http://hl7.org/fhir/ValueSet/diagnostic-report-status
Обязательная
Состояние составления заключения
DiagnosticReport.category
http://hl7.org/fhir/ValueSet/diagnostic-service-sections
Пример
Категория клинической дисциплины, отделения или службы
DiagnosticReport.code
http://hl7.org/fhir/ValueSet/report-codes
Предпочтительная
Все коды LOINC, относящиеся к диагностическим исследованиям
DiagnosticReport.supportingInfo.type
http://terminology.hl7.org/ValueSet/v2-0936
Пример
Тип дополнительных сведений.
DiagnosticReport.conclusionCode
SNOMEDCTClinicalFindings
Пример
Коды состояний, проблем и диагнозов, определенные в номенклатуре SNOMED CT как потомки понятия с кодом 404684003
11.14.4 Ограничения ресурса DiagnosticReport
Ограничения ресурса DiagnosticReport описаны в таблице 322.
Таблица 322
Ограничения ресурса DiagnosticReport
Идентификатор
Вид
Путь
Описание
Выражение
dgr-1
Правило
Базовый
Если элемент DiagnosticReport.composition содержит ссылку на экземпляр ресурса Composition, то на все экземпляры ресурсов Observation, содержащиеся в элементах Composition.entry, должны быть ссылки из элементов DiagnosticReport.entry или из элементов Observation.hasMember
composition.exists() implies (composition.resolve().section.entry.reference.where(resolve() is Observation) in (result.reference|result.reference.resolve().hasMember.reference))
11.14.5 Параметры поиска экземпляров ресурса DiagnosticReport
Специальные параметры поиска экземпляров ресурса DiagnosticReport описаны в таблице 323. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 323
Специальные параметры поиска экземпляров
ресурса DiagnosticReport
Имя
Тип
Описание
Выражение
based-on
reference
Ссылка на требование, для выполнения которого предназначено заключение
DiagnosticReport.basedOn
(CarePlan, MedicationRequest, NutritionOrder, ServiceRequest, ImmunizationRecommendation)
category
token
Категория клинической дисциплины, отделения или службы, составившей заключение
DiagnosticReport.category
code
token
Вид заключения
DiagnosticReport.code
conclusion
token
Код, представляющий заключение
DiagnosticReport.conclusionCode
date
date
Физиологически релевантные дата и время, к которым относится заключение
DiagnosticReport.effective.ofType(dateTime) | DiagnosticReport.effective.ofType(Period)
encounter
reference
Ссылка на случай медицинской помощи
DiagnosticReport.encounter
(Encounter)
identifier
token
Внешний идентификатор заключения
DiagnosticReport.identifier
issued
date
Дата и время создания заключения
DiagnosticReport.issued
media
reference
Ссылка на источник изображения или двоичных данных
DiagnosticReport.media.link
(DocumentReference)
patient
reference
Ссылка на субъект заключения (если это пациент)
DiagnosticReport.subject.where(resolve() is Patient)
(Patient)
performer
reference
Ссылка на составителя заключения
DiagnosticReport.performer
(Practitioner, Organization, CareTeam, PractitionerRole)
result
reference
Ссылка на результат исследования, вошедший в заключение
DiagnosticReport.result
(Observation)
results-interpreter
reference
Ссылка на лицо или организацию, ответственную за содержание заключения
DiagnosticReport.resultsInterpreter
(Practitioner, Organization, CareTeam, PractitionerRole)
specimen
reference
Ссылка на идентификацию и описание биоматериала, по которому составлено заключение
DiagnosticReport.specimen
(Specimen)
status
token
Состояние составления заключения
DiagnosticReport.status
study
reference
Ссылка на исследование генома или лучевое исследование
DiagnosticReport.study
(GenomicStudy, ImagingStudy)
subject
reference
Ссылка на субъект заключения
DiagnosticReport.subject
(Practitioner, Group, Organization, BiologicallyDerivedProduct, Device, Medication, Patient, Substance, Location)
11.14.6 Профиль заключения врача при дистанционном мониторинге
При дистанционном мониторинге заключение врача представляет собой этапный эпикриз, подводящий итоги выполнения плана ведения и содержащий рекомендации по дальнейшему ведению пациента. Полное содержание заключения должно храниться в медицинской информационной системе, а в хранилище результатов измерений должно передаваться сокращенное содержание в объеме, рассчитанном на восприятие пациентом. Это требование отражено в профиле заключения врача при дистанционном мониторинге DiagnosticReport-Dm, ограничивающем элементы ресурса DiagnosticReport в соответствии с рисунком 72 и таблицей 324. Имя ресурса остается неизменным - DiagnosticReport, имя профиля передается в элементе meta.profile.
В целях безопасности персональных данных исключена возможность приложения скана оригинала заключения или представления оригинала заключения в формате pdf, предусмотренная в элементе presentedForm. Сокращен список допустимых значений состояния составления заключения.
Рисунок 72 - Профиль DiagnosticReport-Dm
Таблица 324
Состав элементов DiagnosticReport-Dm
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
Собственные элементы
identifier
Уникальный идентификатор заключения, присвоенный медицинской информационной системой
Identifier
1
basedOn
Ссылка на план ведения пациента
Reference
1
code
Код/наименование заключения
CodeableConcept
1
subject
Ссылка на экземпляр ресурса Patient, идентифицирующий пациента - субъекта дистанционного мониторинга
Reference
1
status
Состояние составления заключения. Допустимые значения: final (окончательное) | amended (изменено после того, как стало окончательным) | corrected (исправлено) | appended (дополнено)
code
1
issued
Дата и время создания текущей версии заключения
instant
1
performer
Ссылка на составителя заключения
Reference
1
conclusion
Текст заключения
markdown
1
11.15 Ресурс MedicationStatement - дневник приема лекарств
11.15.1 Область применения и использования
Тип ресурса MedicationStatement описывает запись дневника приема лекарств. Эта запись может относиться к прошлому, текущему или будущему применению лекарственного препарата. Источником информации может быть пациент, близкое лицо или медицинский работник. Информация может браться по памяти, с упаковки лекарственного препарата или инструкции по его применению, из листа лекарственных назначений.
В отличие от ресурса MedicationAdministration (применение лекарственного препарата) ресурс MedicationStatement рассчитан на менее точную и менее полную информацию о применении (или неприменении) лекарственного препарата. Например, дата и время применения не является обязательной, равно и такие детали, как количество препарата или скорость введения.
В состав ресурса MedicationStatement входит элемент adherence, с помощью которого можно указать степень соответствия указаниям по применению лекарственного препарата, специфичную для этого ресурса.
11.15.2 Структура ресурса
Ресурс MedicationStatement является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса MedicationStatement представлен на рисунке 73 и в таблице 325.
Рисунок 73 - Ресурс MedicationStatement
Таблица 325
Состав элементов ресурса MedicationStatement
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Внешний идентификатор записи дневника приема лекарств
Identifier
0..*
partOf
Ссылка на экземпляр ресурса, содержащий сведения о процедуре, или на другой экземпляр записи дневника приема лекарств
Reference
0..*
status
Статус записи дневника приема лекарств. Допустимые значения: recorded (внесена) | entered-in-error (введена по ошибке) | draft (черновик)
code
1
category
Тип записи о применении лекарственного препарата
CodeableConcept
0..*
medication
Код или наименование лекарственного препарата или ссылка на его описание в форме экземпляра ресурса Medication
CodeableReference
0..*
subject
Ссылка на экземпляр ресурса, идентифицирующего субъект применения лекарственного препарата
Reference
1
encounter
Ссылка на случай медицинской помощи
Reference
0..1
effective[x]
Дата и время (интервал дат и времени) применения (или неприменения) лекарственного препарата
*
0..1
dateAsserted
Дата и время регистрации применения (или неприменения) лекарственного препарата
dateTime
0..1
informationSource
Ссылка на идентификацию лица или организации, представившей информацию о применении лекарственного препарата
Reference
0..*
derivedFrom
Ссылка на информацию, предоставленную для регистрации применения лекарственного препарата
Reference
0..*
reason
Код понятия или ссылка на экземпляр ресурса, описывающего причину применения лекарственного препарата
CodeableReference
0..*
note
Дополнительная информация о применении лекарственного препарата, не отраженная в других элементах
Attachment
0..*
relatedClinicalInformation
Ссылка на сопутствующую клиническую информацию, например, срок беременности
Reference
0..*
renderedDosageInstruction
Полный текст инструкции по дозировке
markdown
0..1
dosage
Дозировка примененного или применяемого лекарственного препарата
Dosage
1
adherence
Применение или отсутствие применения лекарственного препарата
BackboneElement
0..1
adherence.code
Код соответствия указаниям по применению
CodeableConcept
1
adherence.reason
Причина данного варианта соответствия
CodeableConcept
0..1
11.15.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 326.
Таблица 326
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
MedicationStatement.status
http://hl7.org/fhir/ValueSet/medication-statement-status
Обязательная
Статус записи дневника приема лекарств
MedicationStatement.category
http://hl7.org/fhir/ValueSet/medicationrequest-admin-location
Пример
Тип записи о применении лекарственного препарата
MedicationStatement.medication
http://hl7.org/fhir/ValueSet/medication-codes
Пример
Коды лекарственных препаратов и субстанций, определенные в номенклатуре SNOMED CT как потомки понятия с кодом 763158003
MedicationStatement.reason
http://hl7.org/fhir/ValueSet/condition-code
Пример
Коды состояний, проблем и диагнозов, определенные в номенклатуре SNOMED CT как потомки понятия с кодом 404684003
MedicationStatement.adherence.code
http://hl7.org/fhir/ValueSet/medication-statement-adherence
Пример
Коды соответствия указаниям по применению лекарственных препаратов
MedicationStatement.adherence.reason
http://hl7.org/fhir/ValueSet/medication-statement-adherence
Пример
Коды соответствия указаниям по применению лекарственных препаратов (в качестве примера)
11.15.4 Параметры поиска экземпляров ресурса MedicationStatement
Специальные параметры поиска экземпляров ресурса MedicationStatement описаны в таблице 327. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 327
Специальные параметры поиска экземпляров
ресурса MedicationStatement
Имя
Тип
Описание
Выражение
adherence
token
Код соответствия указаниям по применению
MedicationStatement.adherence.code
category
token
Тип записи о применении лекарственного препарата
MedicationStatement.category
code
token
Код лекарственного препарата
MedicationStatement.medication.concept
effective
date
Дата и время применения (или неприменения) лекарственного препарата
MedicationStatement.effective.ofType(dateTime) | ment.effective.ofType(Period)
encounter
reference
Ссылка на случай медицинской помощи
MedicationStatement.encounter
(Encounter)
identifier
token
Внешний идентификатор записи дневника приема лекарств
MedicationStatement.identifier
medication
reference
Ссылка на описание лекарственного препарата
MedicationStatement.medication.reference
patient
reference
Ссылка на экземпляр ресурса, идентифицирующего пациента
MedicationStatement.subject.where(resolve() is Patient)
(Patient)
source
reference
Ссылка на идентификацию лица или организации, представившей информацию о применении лекарственного препарата
MedicationStatement.informationSource
(Practitioner, Organization, Patient, PractitionerRole, RelatedPerson)
status
token
Статус записи дневника приема лекарств
MedicationStatement.status
subject
reference
Ссылка на экземпляр ресурса, идентифицирующего субъект применения лекарственного препарата
MedicationStatement.subject
(Group, Patient)
11.16 Ресурс QuestionnaireResponse - дневник самонаблюдения
11.16.1 Область применения и использования
Тип ресурса QuestionnaireResponse описывает структуру ответов на вопросник, позволяющую включать вопросы по значению или по ссылке на вопросник.
При заполнении ответов о состоянии конкретного субъекте в определенный момент времени должен создаваться отдельный экземпляр ресурса QuestionnaireResponse. При необходимости в него могут вноситься изменения и дополнения.
В предметной области дистанционного мониторинга состояния пациента экземпляр ресурса QuestionnaireResponse может использоваться в качестве строки дневника самонаблюдений.
Если экземпляр ресурса QuestionnaireResponse содержит ссылку на вопросник, то его содержание может быть проверено на соответствие вопроснику, например, что на обязательные пункты даны ответы, что кратность и тип данных ответов соответствуют их описанию в вопроснике.
Содержание экземпляров ресурса QuestionnaireResponse может заполняться медицинскими работниками, пациентами или их близкими. Ответы на вопросы могут предоставляться другими лицами от имени пациента. Эти ответы могут содержать сведения о родственниках (например, при заполнении семейного анамнеза). Поэтому в структуре ресурса QuestionnaireResponse проводится различие между оператором (author), субъектом ответов (subject) и источником информации.
Для ссылки на случай медицинской помощи, к которому относятся ответы, может использоваться элемент encounter. Это позволяет соотносить ответы на вопросник с направлениями на исследования и с результатами исследований в рамках того же случая медицинской помощи.
Для указания языка, на котором даны ответы, может использоваться элемент language.
Порядок вопросов в группах и вложенных группах должен сохраняться при сборе и визуализации ответов. Иерархия пунктов в экземпляре ресурса QuestionnaireResponse должна воспроизводить иерархию пунктов в ссылочном экземпляре ресурса Questionnaire (при наличии ссылки).
11.16.2 Структура ресурса
Ресурс QuestionnaireResponse является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса QuestionnaireResponse представлен на рисунке 74 и в таблице 328.
Рисунок 74 - Ресурс QuestionnaireResponse
Таблица 328
Состав элементов ресурса QuestionnaireResponse
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Глобально уникальный идентификатор ответа на вопросник или иной идентификатор, не зависящий от версии
Identifier
0..*
basedOn
Ссылка на экземпляр ресурса, содержащий сведения о плане ведения или назначении, при выполнении которого даны ответы на вопросник
Reference
0..*
questionnaire
Ссылка на экземпляр вопросника
canonical
0..1
partOf
Ссылка на экземпляр ресурса, содержащий сведения о процедуре или результате исследования, частью которых являются данные ответы на вопросник
Reference
0..*
subject
Ссылка на экземпляр ресурса, идентифицирующего субъект ответа на вопросник
Reference
0..1
encounter
Ссылка на случай медицинской помощи
Reference
0..1
authored
Дата сбора ответов
dateTime
0..1
status
Статус ответов на вопросник. Позволяет прослеживать жизненный цикл ответа. Допустимые значения: in-progress (в процессе заполнения) | completed (заполнены) | amended (дополнены) | entered-in-error (введены по ошибке) | stopped (заполнение прекращено)
code
1
author
Ссылка на оператора по вводу ответов (лицо или устройство)
Reference
0..1
source
Ссылка на лицо или устройство, предоставившее ответы на вопросник
Reference
0..1
item
Пункт вопросника (вопрос, группа)
BackboneElement
0..*
item.linkId
Уникальный идентификатор пункта вопросника
string
1
item.definition
Ссылка на определение пункта
uri
0..1
item.text
Текст пункта
string
0..1
item.answer
Ответ на вопрос
BackboneElement
0..*
value[x]
Содержание ответа
*
1
11.16.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 329.
Таблица 329
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
QuestionnaireResponse.status
http://hl7.org/fhir/ValueSet/questionnaire-answers-status
Обязательная
Жизненный статус дневника
QuestionnaireResponse.item.answer.value[x]
http://hl7.org/fhir/ValueSet/questionnaire-answers
Пример
Примеры вариантов ответа
11.16.4 Ограничения ресурса QuestionnaireResponse
Ограничения ресурса QuestionnaireResponse описаны в таблице 330.
Таблица 330
Ограничения ресурса QuestionnaireResponse
Идентификатор
Вид
Путь
Описание
Выражение
qrs-1
Правило
QuestionnaireResponse.item
Элемент item не может содержать элементы item и answer одновременно
(answer.exists() and item.exists()).not()
qrs-2
Правило
QuestionnaireResponse.item
Ответы на повторяющийся вопрос должны собираться в массив ответов, привязанных к единственному экземпляру вопроса
repeat(answer|item).select(item.where(answer.value.exists()).linkId.isDistinct()).allTrue()
11.16.5 Ссылки на экземпляры ресурса Questionnaire
Содержание экземпляра ресурса QuestionnaireResponse может быть автономным или включать ссылка на описание вопросника Questionnaire. При наличии такой ссылки должны выполняться следующие требования:
- структура экземпляра ресурса QuestionnaireResponse должна быть совместимой со структурой вопросника, описанной в экземпляре ресурса (например, ответы на вопросы должны быть организованы в те же самые группы, ответы на вложенные вопросы должны оставаться вложенными и т.д.);
- связь между вопросами, группами и ответами задается с помощью элементов linkId. Значение этих элементов уникальны в экземпляре ресурса Questionnaire, но могут повторяться в экземпляре ресурса QuestionnaireResponse, если допускается повторение соответствующего пункта или его родителя;
- все пункты вопросника Questionnaire, в том числе пункты типа display, релевантные для интерпретации ответов, по возможности должны быть включены в экземпляре ресурса QuestionnaireResponse. Пока статус завершенности экземпляра ресурса QuestionnaireResponse не получит значение completed, это могут быть пункты, которые должны быть пропущены в зависимости от текущих ответов. Когда QuestionnaireResponse.status = completed, все пропускаемые пункты должны быть исключены.
11.16.6 Валидация ответов на вопросник
Требования к ответам, описанные в экземпляре ресурса Questionnaire, не обязаны выполняться, пока заполнение ответов не будет завершено, то есть элемент QuestionnaireResponse.status не получит значение completed или amended. Например, ответы на обязательные вопросы могут быть пропущены, требования к длине ответов могут не выполняться и т.д. Такие экземпляры QuestionnaireResponse могут сохраняться сервером для будущей доработки. Если же элемент QuestionnaireResponse.status имеет значение completed или amended, то сервер по возможности должен обеспечить валидацию содержания экземпляра QuestionnaireResponse на соответствие требованиям в ссылочном экземпляре ресурса Questionnaire.
В ресурсе QuestionnaireResponse предусмотрены два разных способа представления вложенных пунктов: item.item и item.answer.item. Первый предназначен для пунктов, вложенных в пункты типа group, а второй - для пунктов, вложенных в пункты типа question, то есть в вопросы. Это связано с тем, что пункты, вложенные в вопросы, всегда вложены в каждый ответ на вопрос. Если вопрос допускает несколько ответов, то каждый из них должен иметь свое множество вложенных пунктов.
11.16.7 Параметры поиска экземпляров ресурса QuestionnaireResponse
Специальные параметры поиска экземпляров ресурса QuestionnaireResponse описаны в таблице 331. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 331
Специальные параметры поиска экземпляров ресурса
QuestionnaireResponse
Имя
Тип
Описание
Выражение
author
reference
Ссылка на оператора по вводу ответов
QuestionnaireResponse.author
(Practitioner, Organization, Device, Patient, PractitionerRole, RelatedPerson)
authored
date
Дата сбора ответов
QuestionnaireResponse.authored
based-on
reference
Ссылка на экземпляр ресурса, содержащий сведения о плане ведения или назначении, при выполнении которого даны ответы на вопросник
QuestionnaireResponse.basedOn
(CarePlan, ServiceRequest)
encounter
reference
Ссылка на случай медицинской помощи
QuestionnaireResponse.encounter
(Encounter)
identifier
token
Глобально уникальный идентификатор ответа на вопросник
QuestionnaireResponse.identifier
item-subject
reference
Ссылка на экземпляр ресурса, идентифицирующего субъект ответа на вопросник
QuestionnaireResponse.item.where(extension('http://hl7.org/fhir/StructureDefinition/questionnaireresponse-isSubject').exists()).answer.value.ofType(Reference)
part-of
reference
Ссылка на экземпляр ресурса, содержащий сведения о процедуре или результате исследования, частью которых являются данные ответы на вопросник
QuestionnaireResponse.partOf
(Observation, Procedure)
patient
reference
Ссылка на экземпляр ресурса со сведениями о пациенте, являющемся субъектом вопросника
QuestionnaireResponse.subject.where(resolve() is Patient)
(Patient)
questionnaire
reference
Ссылка на экземпляр вопросника
QuestionnaireResponse.questionnaire
(Questionnaire)
source
reference
Ссылка на лицо или устройство, предоставившее ответы на вопросник
QuestionnaireResponse.source
(Practitioner, Organization, Device, Patient, PractitionerRole, RelatedPerson)
status
token
Статус ответов на вопросник
QuestionnaireResponse.status
subject
reference
Ссылка на экземпляр ресурса, идентифицирующего субъект вопросника
QuestionnaireResponse.subject
(Any)
11.17 Ресурс Questionnaire - описание дневника самонаблюдения
11.17.1 Область применения и использования
Тип ресурса Questionnaire описывает вопросник, то есть организованную коллекцию вопросов, предназначенную для сбора информации от пациентов, медицинских работников или иных участников процесса оказания медицинской помощи, для описания вопросников широкого профиля, в том числе дневника самонаблюдения. Одним из важных приложений ресурса является описание дневника самонаблюдения.
Экземпляр ресурса Questionnaire тесно связан с экземплярами ресурса QuestionnaireResponse: в нем представлены вопросы и правила ответов, а экземпляры ресурса QuestionnaireResponse содержат ответы на эти вопросы, полученные от определенного пользователя в определенный момент времени.
Вопросник, определяемый с помощью экземпляра ресурса Questionnaire, состоит из пунктов, типы которых представлены в таблице 332.
Таблица 332
Типы пунктов вопросника
(система кодирования http://hl7.org/fhir/item-type)
Уровень
Код
Значение
Описание
1
group
группа
Пункт, не требующий прямого ответа и содержащий хотя бы один дочерний пункт
1
display
текст
Текст, не требующий ответа и не содержащий дочерние пункты
1
question
вопрос
Пункт, требующий ответа. Может иметь дочерние пункты. Тип question является абстрактным - в экземпляре ресурса Questionnaire могут быть указаны только его потомки, соответствующие конкретным типам данных ответа
2
boolean
булевский
Пункт с бинарным ответом true/false (элемент valueBoolean)
2
decimal
десятичный
Пункт с десятичным ответом (элемент valueDecimal)
2
integer
целочисленный
Пункт с целочисленным ответом (элемент valueInteger)
2
date
дата
Пункт с ответом в виде даты (элемент valueDate)
2
dateTime
дата и время
Пункт с ответом в виде даты и времени (элемент valueDateTime)
2
time
время
Пункт с ответом в виде времени, не зависящего от даты (элемент valueTime)
2
string
строка
Пункт с коротким однострочным ответом (элемент valueString, не содержащий символы перехода на новую строку/возврата каретки)
2
text
текст
Пункт с длинным многострочным ответом (элемент valueString)
2
url
адрес URL
Пункт с ответом в форме адреса URL, например, адресом веб-сайта, службы FTP и т.д. (элемент valueUri)
2
coding
перечисляемый
Пункт с перечисляемыми вариантами ответа (элемент valueCoding)
2
attachment
вложение
Пункт с двоичным ответом, например, изображением, PDF и т.д. (элемент valueAttachment)
2
reference
ссылка
Пункт с ответом в виде ссылки на экземпляр ресурса (элемент valueReference)
2
quantity
физическая величина
Пункт с ответом в форме сочетания числа и единицы измерения (элемент valueSimpleQuantity). Для ограничения допустимых единиц измерения, передаваемых в компонентах valueSimpleQuantity.system и valueSimpleQuantity.code, используются расширения http://hl7.org/fhir/StructureDefinition/questionnaire-unitOption и http://hl7.org/fhir/StructureDefinition/questionnaire-unitValueSetity.code
С каждым пунктом могут быть связаны правила его предъявления при заполнении, например, пункт может быть пропущен в зависимости от ответа на тот или иной вопрос. Экземпляр ресурса Questionnaire содержит только описание вопросника, заполняется в соответствии с этим описанием экземпляр ресурса QuestionnaireResponse.
11.17.2 Структура ресурса
Ресурс Questionnaire является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Questionnaire представлен на рисунке 75 и в таблице 333.
Рисунок 75 - Ресурс Questionnaire
Таблица 333
Состав элементов ресурса Questionnaire
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
url
Канонический идентификатор вопросника, представленный в форме URI
uri
0..1
identifier
Глобально уникальный идентификатор вопросника или иной идентификатор, не зависящий от версии
Identifier
0..*
version
Версия вопросника
string
0..1
versionAlgorithm[x]
Алгоритм сравнения версий
*
0..1
name
Имя вопросника (для компьютера)
string
0..1
title
Краткое описательное имя вопросника (для человека)
string
0..1
derivedFrom
Ссылка на вопросник, взятый за основу данного вопросника
canonical
0..*
status
Статус версии вопросника. Позволяет прослеживать жизненный цикл содержания вопросника. Допустимые значения: draft (проект) | active (действует) | retired (действие прекращено) | unknown (статус неизвестен)
code
experimental
Признак тестового вопросника
boolean
0..1
subjectType
Тип ресурса, разрешенный в качестве субъекта для экземпляра ресурса QuestionnaireResponse
code
0..*
date
Дата (и необязательное время) публикации вопросника. Должна изменяться при смене версии и кода статуса. Кроме того, она должна изменяться, если содержание вопросника претерпевает существенные изменения
dateTime
0..1
publisher
Наименование организации или Ф.И.О. издателя, опубликовавшего вопросник
string
0..1
contact
Контактная информация издателя
ContactDetail
0..*
description
Описание вопросника для его потребителя
markdown
0..1
useContext
Контекст использования вопросника (по умолчанию - не ограничен)
UsageContext
0..*
jurisdiction
Юрисдикция, в которой применяется вопросник. Может задавать страну, регион или иную единицу административного деления. Использование запрещено. Вместо него рекомендуется использовать элемент useContext, у которого компонент code имеет значение http://terminology.hl7.org/CodeSystem/usage-context-type#jurisdiction, а компонент valueCodeableConcept - юрисдикцию
CodeableConcept
0..*
purpose
Назначение вопросника
markdown
0..1
copyright
Авторские права на вопросник
markdown
0..1
copyrightLabel
Торговая марка и год(ы)
string
0..1
approvalDate
Дата утверждения
date
0..1
lastReviewDate
Дата последнего пересмотра
date
0..1
effectivePeriod
Период действия
Period
0..1
code
Тема вопросника
Coding
0..*
item
Пункт вопросника (вопрос, группа)
BackboneElement
0..*
item.linkId
Уникальный идентификатор пункта вопросника
string
1
item.definition
Ссылка на определение пункта
uri
0..1
item.code
Тема пункта
Coding
0..*
item.prefix
Номер пункта, например 1a, 2.5.3
string
0..1
item.text
Текст пункта
string
0..1
item.type
Тип пункта. Допустимые значения: group | display | boolean | decimal | integer | date | dateTime
code
1
item.enableWhen
Условие предъявления пункта при заполнении вопросника
BackboneElement
0..*
item.enableWhen.question
Значение элемента linkId для вопроса, чей ответ (или отсутствие ответа) влияет на предъявление данного пункта
string
1
item.enableWhen.operator
Оператор сравнения. Допустимые значения: exists | = | != | > | < | >= | <=
code
1
item.enableWhen.answer[x]
Значение, с которым сравнивается ответ на вопрос, идентифицированный элементом question. Если ответов несколько, достаточно положительного сравнения хотя бы с одним из них. Допустимые типы значения: boolean | decimal | integer | date | dateTime | time | string | Coding | Quantity | Reference
*
1
item.enableBehavior
Интерпретация нескольких экземпляров элемента enableWhen. Допустимые значения: all (все должны быть истинными) | any (хотя бы один должен быть истинным)
code
0..1
item.disabledDisplay
Способ представления пропускаемых пунктов. Допустимые значения: hidden (скрыт) | protected (защищен от ввода)
code
0..1
item.required
Значение true указывает, что пункт должен присутствовать в "заполненном" вопроснике, а false - что пункт может быть пропущен при заполнении вопросника. По умолчанию false
boolean
0..1
item.repeats
Значение true указывает, что на один пункт можно дать несколько ответов (если это вопрос) или что пункт может повторяться (если это группа пунктов). По умолчанию false
boolean
0..1
item.readOnly
Значение true указывает, что значение пункта не может быть изменено респондентом. Если указано для пункта, то распространяется на все подчиненные пункты и вопросы
boolean
0..1
item.maxLength
Максимальное число символов в ответе на вопрос
integer
0..1
item.answerConstraint
Для вопросов с ограниченными вариантами ответов (заданными в элементе Option или answerValueSet) указывает возможность дополнительных вариантов. Допустимые значения: optionsOnly (только заданные значения) | optionsOrType (заданные значения и значения типа, указанного в элементе type) | optionsOrString (заданные значения и произвольная строка)
code
0..1
item.answerValueSet
Ссылка на набор значений с вариантами ответа
canonical
0..1
item.answerOption
Вариант ответа
BackboneElement
0..*
item.answerOption.value[x]
Вариант ответа. Допустимые значения: integer|date|time|string|Coding|Reference
*
1
item.answerOption.initialSelected
Значение true указывает, что этот вариант должен быть заранее предложен
boolean
0..1
item.initial
Заранее заполненный ответ
BackboneElement
0..*
item.initial.value[x]
Заранее заполненный ответ
*
1
item.item
Вложенный пункт или вопрос (см. item)
BackboneElement
0..*
11.17.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 334.
Таблица 334
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
Questionnaire.versionAlgorithm[x]
http://hl7.org/fhir/ValueSet/version-algorithm
Расширяемая
Алгоритм сравнения версий
Questionnaire.status
http://hl7.org/fhir/ValueSet/publication-status
Обязательная
Статус жизненного цикла системы кодирования
Questionnaire.subjectType
http://hl7.org/fhir/ValueSet/resource-types
Обязательная
Тип ресурса
Questionnaire.jurisdiction
http://hl7.org/fhir/ValueSet/jurisdiction
Расширяемая
Страны и регионы, для которых предназначена данная система кодирования
Questionnaire.code
http://hl7.org/fhir/ValueSet/questionnaire-questions
Пример
Примеры типов групп и вопросов
Questionnaire.item.code
http://hl7.org/fhir/ValueSet/questionnaire-questions
Пример
Примеры типов групп и вопросов
Questionnaire.item.type
http://hl7.org/fhir/ValueSet/item-type
Обязательная
Тип пункта
Questionnaire.item.enableWhen.operator
http://hl7.org/fhir/ValueSet/questionnaire-enable-operator
Обязательная
Оператор сравнения
Questionnaire.item. enableWhen.answer[x]
http://hl7.org/fhir/ValueSet/questionnaire-answers
Пример
Примеры типов сравниваемых значений
Questionnaire.item.enableBehavior
http://hl7.org/fhir/ValueSet/questionnaire-enable-behavior
Обязательная
Интерпретация нескольких экземпляров элемента enableWhen
Questionnaire.item.disabledDisplay
http://hl7.org/fhir/ValueSet/questionnaire-disabled-display
Обязательная
Способ представления пропускаемых пунктов
Questionnaire.item.answerConstraint
http://hl7.org/fhir/ValueSet/questionnaire-answer-constraint
Обязательная
Возможность дополнительных вариантов ответа
Questionnaire.item.answerOption.value[x]
http://hl7.org/fhir/ValueSet/questionnaire-answers
Пример
Примеры вариантов ответа
Questionnaire.item.initial.value[x]
http://hl7.org/fhir/ValueSet/questionnaire-answers
Пример
Примеры вариантов ответа
11.17.4 Ограничения ресурса Questionnaire
Ограничения ресурса Questionnaire описаны в таблице 335.
Таблица 335
Ограничения ресурса Questionnaire
Идентификатор
Вид
Путь
Описание
Выражение
cnl-0
Предупреждение
Базовый
Значение элемента name должно быть пригодно в качестве идентификатора программного модуля
name.exists() implies name.matches('^[A-Z]([A-Za-z0-9_]){1,254}$')
cnl-1
Предупреждение
Questionnaire.url
Адрес URL не должен содержать символы | или #
exists() implies matches('^[^|#]+$')
que-1a
Правило
Questionnaire.item
В экземпляре ресурса Questionnaire, имеющим статус завершенности complete, пункты типа group должны иметь вложенные пункты
(type='group' and %resource.status='complete') implies item.empty().not()
que-1b
Предупреждение
Questionnaire.item
Пункты типа group по возможности должны иметь вложенные пункты
type='group' implies item.empty().not()
que-1c
Правило
Questionnaire.item
Пункты типа display не должны содержать дочерние пункты
type='display' implies item.empty()
que-2
Правило
Базовый
Значения идентификаторов linkId пунктов типа group и question должны быть уникальными в пределах вопросника
descendants().linkId.isDistinct()
que-3
Правило
Questionnaire.item
У пунктов типа display должен отсутствовать элемент code
type!='display' or code.empty()
que-4
Правило
Questionnaire.item
Пункт типа question не может одновременно иметь элементы answerOption и answerValueSet
answer
Option.empty() or answerValueSet.empty()
que-5
Правило
Questionnaire.item
Элементы answerOption или answerValueSet могут быть только у пунктов типа coding, decimal, integer, date, dateTime, time, string или quantity
(type='coding' or type = 'decimal' or type = 'integer' or type = 'date' or type = 'dateTime' or type = 'time' or type = 'string' or type = 'quantity') or (answerValueSet.empty() and answerOption.empty())
que-6
Правило
Questionnaire.item
У пунктов типа display должны отсутствовать признаки обязательности required и повторения repeat
type!='display' or (required.empty() and repeats.empty())
que-7
Правило
Questionnaire.item.enableWhen
Если элемент operator имеет значение exists, то элемент answer должен иметь тип boolean
operator = 'exists' implies (answer is boolean)
que-8
Правило
Questionnaire.item
У пунктов типа group или display должны отсутствовать заранее заполненные ответы
(type!='group' and type!='display') or initial.empty()
que-9
Правило
Questionnaire.item
У пунктов типа display должен отсутствовать признак readonly
type!='display' or readOnly.empty()
que-10
Правило
Questionnaire.item
Ограничение максимальной длины maxLength может быть задано только для пунктов с простым ответом
(type in ('boolean' | 'decimal' | 'integer' | 'string' | 'text' | 'url')) or answerConstraint='optionOrString' or maxLength.empty()
que-11
Правило
Questionnaire.item
Элемент initial должен отсутствовать, если присутствует хотя бы один элемент answerOption. Вместо элемента initial в этом случае следует использовать элемент answerOption.initialSelected
answerOption.empty() or initial.empty()
que-12
Правило
Questionnaire.item
Если присутствует несколько элементов enableWhen, то должен присутствовать элемент enableBehavior
enableWhen.count() > 1 implies enableBehavior.exists()
que-13
Правило
Questionnaire.item
Несколько заранее заданных ответов может присутствовать только при наличии признака повторения repeats со значением true
repeats=true or initial.count() <= 1
que-14
Предупреждение
Questionnaire.item
Элемент answerConstraint может присутствовать только при наличии элемента answerOption или answerValueSet
answerConstraint.exists() implies answerOption.exists() or answerValueSet.exists()
que-15
Предупреждение
Questionnaire. item. linkId
Длина значения идентификатора linkId не должна превышать 255 символов
$this.length() <= 255
11.17.5 Параметры поиска экземпляров ресурса Questionnaire
Специальные параметры поиска экземпляров ресурса Questionnaire описаны в таблице 336. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 336
Специальные параметры поиска экземпляров ресурса
Questionnaire
Имя
Тип
Описание
Выражение
combo-code
token
Тема вопросника или пункта
Questionnaire.code | Questionnaire.item.code
context
token
Контекст использования, назначенный системе кодирования
(Questionnaire.useContext.value.ofType(CodeableConcept))
context-quantity
quantity
Количественное значение контекста или диапазон количественных значений (если имеются), назначенных вопроснику
(Questionnaire.useContext.value.ofType(Quantity)) | (Questionnaire.useContext.value.ofType(Range))
context-type
token
Тип контекста, назначенного вопроснику
Questionnaire.useContext.code
context-type-quantity
composite
Сочетание типа контекста данного вопросника и его количественного значения или диапазона значений
On Questionnaire.useContext:
context-type: code
context-quantity: value.ofType(Quantity) | value.ofType(Range)
context-type-value
composite
Сочетание типа контекста данного вопросника и его значения
On Questionnaire.useContext:
context-type: code
context: value.ofType(CodeableConcept)
date
date
Дата публикации вопросника
Questionnaire.date
definition
uri
Ссылка на определение пункта
Questionnaire.item.definition
description
string
Описание вопросника
Questionnaire.description
effective
date
Предполагаемый период использования
Questionnaire.effectivePeriod
identifier
token
Внешний идентификатор вопросника
Questionnaire.identifier
item-code
token
Тема пункта
Questionnaire.item.code
jurisdiction
token
Страна или регион, для которого предназначен вопросник
Questionnaire.jurisdiction
name
string
Имя вопросника, предназначенное для машинной обработки
Questionnaire.name
publisher
string
Наименование издателя вопросника
Questionnaire.publisher
questionnaire-code
token
Тема вопросника
Questionnaire.code
status
token
Текущий статус вопросника
Questionnaire.status
subject-type
token
Ссылка на субъект вопросника
Questionnaire.subjectType
title
string
Имя вопросника, предназначенное для человека
Questionnaire.title
url
uri
Значение URI, идентифицирующее данный вопросник
Questionnaire.url
version
token
Версия вопросника
Questionnaire.version
11.18 Ресурс NutritionIntake (дневник питания)
11.18.1 Область применения и использования
Ресурс NutritionIntake описывает общую структуру однократной регистрации акта питания (приема пищи или потребления жидкости) как в стационаре, так и на дому или в системе общественного питания. В область применения ресурса NutritionIntake не входит парентеральное питание.
Состав элементов ресурса NutritionIntake рассчитан на потребности анализа медицинским специалистом (например, диетологом или эндокринологом). Источником информации может быть сам пациент, лицо, обеспечивающее уход за ним или медицинский работник. Информация может заполняться постфактум или непосредственно во время акта питания. Она может вводиться в информационную систему медицинской организации, в мобильное приложение или в приложение на персональном компьютере. Сведения о составе и калорийности продукта (пищи или жидкости) могут браться из справочников, с товарных этикеток или из меню.
Учитывая многообразие продуктов питания и причин контроля питания, все элементы с кодируемыми значениями (за исключением состояния питания status) имеют тип данных CodeableConcept, позволяющий вводить текст в дополнение к коду или вместо кода. Привязки этих элементов к наборам значений даются в качестве примеров.
11.18.2 Структура ресурса
Ресурс NutritionIntake является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса NutritionIntake представлен на рисунке 76 и в таблице 337.
Рисунок 76 - Ресурс NutritionIntake
Таблица 337
Состав элементов ресурса NutritionIntake
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Идентификатор акта питания
Identifier
0..*
instantiates-Canonical
Ссылка на экземпляр ресурса, описывающий протокол или определение
canonical
0..*
instantiatesUri
Ссылка на внешний протокол или определение
uri
0..*
basedOn
Ссылка на план ведения, назначение или заказ питания
Reference
0..*
partOf
Ссылка на дневник питания, процедуру или исследование, частью которого является заполнение дневника питания
Reference
0..*
status
Состояние питания. Допустимые значения: preparation (приготовление) | in-progress (в процессе) | not-done (не принято) | on-hold (приостановлено) | stopped (остановлено) | completed (выполнено) | entered-in-error (введено по ошибке) | unknown (неизвестно)
code
1
statusReason
Причина текущего состояния питания
CodeableConcept
0..*
code
Тип питания
CodeableConcept
0..1
subject
Ссылка на субъект питания (пациент, группа или животное)
Reference
1
encounter
Ссылка на случай медицинской помощи
Reference
0..1
occurrence[x]
Интервал времени, в течение которого осуществлялся или осуществляется акт питания (или имел место отказ от питания)
*
0..1
recorded
Дата и время регистрации акта питания источником информации
dateTime
0..1
reported[x]
Источник информации об акте питания (лицо, роль или организация)
*
0..1
consumedItem
Потребленный продукт
BackboneElement
1..*
consumedItem.type
Тип потребленного продукта
CodeableConcept
1
consumedItem.nutritionProduct
Идентификация потребленного продукта (код или ссылка на описание продукта)
CodeableReference
1
consumedItem.schedule
Расписание потребления продукта
Timing
0..1
consumedItem.amount
Количество продукта
SimpleQuantity
0..1
consumedItem.rate
Скорость потребления
SimpleQuantity
0..1
consumedItem.notConsumed
Признак, что продукт не был потреблен (например, госпитализированный пациент отказался от него). В дневнике, заполняемом пациентом, этот элемент отсутствует
boolean
0..1
consumedItem.notConsumedReason
Причина отказа от потребления продукта
CodeableConcept
0..1
ingredientLabel
Состав продукта
BackboneElement
0..*
ingredientLabel.nutrient
Компонент продукта (белок, жир, гидрокарбонат, витамин, минерал и т.д.) или калории
CodeableReference
1
ingredientLabel.amount
Количество компонента или калорий
SimpleQuantity
1
performer
Лицо, роль, организация или медицинское изделие, обеспечившее или обеспечивающее акт питания
BackboneElement
0..*
performer.function
Тип лица, роли или организации, обеспечившей или обеспечивающей акт питания
CodeableConcept
0..1
performer.actor
Ссылка на лицо, роль, организацию или медицинское изделие, обеспечившее или обеспечивающее акт питания
Reference
1
location
Ссылка на место акта питания
Reference
0..1
derivedFrom
Ссылка на экземпляр ресурса NutritionOrder (заказ питания) или иную информацию, имеющую отношение к данному акту питания, например, на экземпляры ресурсов AllergyIntolerance (непереносимость), Observation (результат исследования) или QuestionnaireAnswers (дневник самонаблюдения)
Reference
0..*
reason
Причина акта питания (состояние пациента или результат исследования) - кодируемое значение типа CodeableConcept или ссылка на экземпляр ресурса Condition | Observation | DiagnosticReport | DocumentReference
CodeableReference
0..*
note
Дополнительная информация об акте питания
Annotation
0..*
11.18.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 338.
Таблица 338
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
tritionIntake.status
http://hl7.org/fhir/ValueSet/event-status
Обязательная
Коды состояний жизненного цикла события
NutritionIntake.statusReason
http://hl7.org/fhir/ValueSet/clinicalimpression-status-reason
Пример
Примеры кодов причин отсутствия описания состояния пациента
NutritionIntake.code
http://hl7.org/fhir/ValueSet/diet-type
Пример
Примеры типов питания, включая типы диет
NutritionIntake.consumedItem.type
http://hl7.org/fhir/ValueSet/edible-substance-type
Пример
Примеры съедобных субстанций
NutritionIntake.consumedItem.nutritionProduct
http://hl7.org/fhir/ValueSet/food-type
Пример
Примеры типов продуктов
NutritionIntake.consumedItem.notConsumedReason
http://hl7.org/fhir/ValueSet/not-consumed-reason
Пример
Примеры причин отказа от продукта
NutritionIntake.ingredientLabel.nutrient
http://hl7.org/fhir/ValueSet/nutrient-code
Пример
Примеры питательных веществ
NutritionIntake. performer. function
http://hl7.org/fhir/ValueSet/performer-role
Пример
Примеры кодов ролей лиц, обеспечивших обеспечивающих акт питания
NutritionIntake.reason
http://hl7.org/fhir/ValueSet/condition-code
Пример
Пример набора значений с кодами диагнозов/состояний
11.18.4 Параметры поиска экземпляров ресурса NutritionIntake
Специальные параметры поиска экземпляров ресурса NutritionIntake описаны в таблице 339. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 339
Специальные параметры поиска экземпляров ресурса
NutritionIntake
Имя
Тип
Описание
Выражение
code
token
Тип питания
NutritionIntake.code
date
date
Интервал времени, в течение которого осуществлялся или осуществляется акт питания (или имел место отказ от питания)
NutritionIntake.occurrence.ofType(dateTime) | NutritionIntake.occurrence.ofType(Period)
encounter
reference
Ссылка на случай медицинской помощи
NutritionIntake.encounter
(Encounter)
identifier
token
Идентификатор акта питания
NutritionIntake.identifier
nutrition
token
Идентификация потребленного продукта
NutritionIntake.consumedItem.nutritionProduct.concept
patient
reference
Ссылка на идентификацию пациента
NutritionIntake.subject.where(resolve() is Patient) (Patient)
source
reference
Ссылка на источник информации об акте питания
(NutritionIntake.reported as Reference) (Practitioner, Organization, Patient, PractitionerRole, RelatedPerson)
status
token
Состояние питания
NutritionIntake.status
subject
reference
Ссылка на субъект акта питания (пациент, группа)
NutritionIntake.subject
(Group, Patient)
11.19 Ресурс DetectedIssue - предупреждение
11.19.1 Область применения и использования
Тип ресурса DetectedIssue описывает предупреждение о выявленной проблеме, которое может быть выдано системой поддержки принятия медицинских решений или сформулировано медицинским работником. Такое предупреждение может быть направлено другому медицинскому работнику или пациенту.
11.19.2 Структура ресурса
Ресурс DetectedIssue является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса DetectedIssue представлен на рисунке 77 и в таблице 340.
Рисунок 77 - Ресурс DetectedIssue
Таблица 340
Состав элементов ресурса DetectedIssue
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
identifier
Уникальный идентификатор предупреждения
Identifier
0..*
category
Категория проблемы
CodeableConcept
0..*
code
Тип проблемы
CodeableConcept
0..1
severity
Серьезность выявленной проблемы. Допустимые значения: high (высокая) | moderate (умеренная) | low (низкая)
code
0..1
subject
Ссылка на экземпляр ресурса, к которому относится предупреждение
Reference
0..1
encounter
Ссылка на случай медицинской помощи
Reference
0..1
status
Статус предупреждения. Допустимые значения: preliminary (предварительное) | final (окончательное) | entered-in-error (создано по ошибке) | mitigated (учтено)
code
1
identified[x]
Дата и время или период выявления проблемы
*
0..1
author
Ссылка на экземпляр ресурса, описывающего лицо или прибор, выявивший проблему
Reference
0..1
implicated
Ссылка на экземпляр ресурса, представляющего потенциально проблемную планируемую или текущую деятельность
Reference
0..*
evidence
Основание признания деятельности проблемной
BackboneElement
0..*
evidence.code
Код основания признания деятельности проблемной
CodeableConcept
0..*
evidence.detail
Ссылка на экземпляр ресурса, содержащего сведения об основании признания деятельности проблемной
Reference
0..*
detail
Текстовое описание выявленной проблемы
markdown
0..1
reference
Ссылка на источник, описывающий возможную причину выявленной проблемы
uri
0..1
mitigation
Действие, необходимое для смягчения или исключения выявленной проблемы
BackboneElement
0..*
mitigation.action
Кодируемое представление или текст описания необходимого действия
CodeableConcept
1
mitigation.date
Дата и время выполнения необходимого действия
dateTime
0..1
mitigation.author
Ссылка на исполнителя необходимого действия
Reference
0..1
mitigation.note
Примечание к выполненному действию
Annotation
0..*
11.19.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 341.
Таблица 341
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
DetectedIssue.status
http://hl7.org/fhir/ValueSet/detectedissue-status
Обязательная
Статус предупреждения
DetectedIssue.category
http://hl7.org/fhir/ValueSet/detectedissue-category
Предпочтительная
Категория проблемы или противопоказаний, например, межлекарственное взаимодействие
DetectedIssue.code
http://hl7.org/fhir/ValueSet/detectedissue-category
Предпочтительная
Вид проблемы или противопоказаний, например, межлекарственное взаимодействие
DetectedIssue.severity
http://hl7.org/fhir/ValueSet/detectediss
Обязательная
Указывает потенциальную степень воздействия выявленной проблемы на пациента
DetectedIssue. evidence. code
http://hl7.org/fhir/ValueSet/manifestation-or-symptom
Пример
Коды состояний, проблем и диагнозов, определенные в номенклатуре SNOMED CT как потомки понятия с кодом 404684003
DetectedIssue. mitigation. action
http://hl7.org/fhir/ValueSet/detectedissue-mitigation-action
Предпочтительная
Вид необходимого действия
11.19.4 Параметры поиска экземпляров ресурса DetectedIssue
Специальные параметры поиска экземпляров ресурса DetectedIssue описаны в таблице 342. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 342
Специальные параметры поиска экземпляров ресурса
DetectedIssue
Имя
Тип
Описание
Выражение
author
reference
Ссылка на лицо или прибор, выявивший проблему
DetectedIssue.author
(Practitioner, Device, Patient, PractitionerRole, RelatedPerson)
category
token
Категория проблемы
DetectedIssue.category
code
token
Тип проблемы
DetectedIssue.code
identified
date
Дата и время выявления проблемы
DetectedIssue.identified.ofType(dateTime) | DetectedIssue.identified.ofType(Period)
identifier
token
Уникальный идентификатор предупреждения
DetectedIssue.identifier
implicated
reference
Ссылка на экземпляр ресурса, представляющего потенциально проблемную планируемую или текущую деятельность
DetectedIssue.implicated
(Any)
patient
reference
Ссылка на экземпляр ресурса Patient, к которому относится предупреждение
DetectedIssue.subject.where(resolve() is Patient)
(Patient)
status
token
Статус предупреждения
DetectedIssue.status
subject
reference
Ссылка на экземпляр ресурса, к которому относится предупреждение
DetectedIssue.subject
(Practitioner, Group, Organization, BiologicallyDerivedProduct, NutritionProduct, Device, Medication, Patient, Procedure, Substance, Location)
11.19.5 Профиль DetectedIssue-Dm
Состав элементов профиля DetectedIssue-Dm приведен на рисунке 78 и в таблице 343. Имя ресурса остается неизменным - DetectedIssue, имя профиля передается в элементе meta.profile.
Рисунок 78 - Профиль DetectedIssue-Dm
Таблица 343
Состав элементов профиля DetectedIssue-Dm
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
1
Собственные элементы
identifier
Уникальный идентификатор предупреждения
Identifier
1
severity
Серьезность выявленной проблемы. Допустимые значения: high (высокая) | moderate (умеренная) | low (низкая)
code
1
subject
Ссылка на экземпляр ресурса Patient, к которому относится предупреждение
Reference
1
status
Статус предупреждения. Допустимые значения: final (окончательное) | entered-in-error (создано по ошибке)
code
1
identifiedDateTime
Дата и время выявления проблемы
dateTime
0..1
author
Ссылка на экземпляр ресурса Practitioner или Device, описывающего лицо или прибор, выявивший проблему
Reference
0..1
detail
Текстовое описание выявленной проблемы
markdown
1
mitigation
Действие, необходимое для смягчения или исключения выявленной проблемы
BackboneElement
0..*
mitigation.action
Кодируемое представление или текст описания необходимого действия
CodeableConcept
1
12 REST API и поиск
12.1 Общие сведения
Для каждого типа ресурсов определен один и тот же комплекс взаимодействий, основанный на архитектурном стиле REST. При описании REST API предполагается, что отдельные экземпляры ресурсов организованы в коллекции по их типу. REST API позволяет выполнять операции как на уровне экземпляров ресурсов, так и на уровне типов ресурсов, а также на уровне системы в целом. Эти операции далее называются взаимодействиями. Все взаимодействия являются синхронными.
12.2 Взаимодействия
12.2.1 Общие сведения
Возможные взаимодействия на уровне экземпляров ресурсов перечислены в таблице 344, взаимодействия на уровне типов ресурсов - в таблице 345, взаимодействия на уровне системы - в таблице 346.
Таблица 344
Взаимодействия на уровне экземпляров ресурсов
Взаимодействие
Описание
read
Чтение текущего содержания экземпляра ресурса
vread
Чтение содержания конкретной версии экземпляра ресурса
update
Изменение содержания экземпляра ресурса с заданным логическим идентификатором (или создание, если экземпляра с таким идентификатором не существует)
patch
Исправление содержания экземпляра ресурса с заданным логическим идентификатором
delete
Удаление экземпляра ресурса
history
Получение истории изменения содержания экземпляра ресурса
Таблица 345
Взаимодействия на уровне типов ресурсов
Взаимодействие
Описание
create
Создание нового экземпляра ресурса с логическим идентификатором, присвоенным сервером
search
Поиск экземпляров ресурса данного типа, используя определенные критерии
delete
Удаление коллекции экземпляров ресурса данного типа, используя определенные критерии
history
Получение истории изменения содержания экземпляров ресурса данного типа
Таблица 346
Взаимодействия на уровне системы
Взаимодействие
Описание
capabilities
Получение описания возможностей системы
batch/transaction
Выполнение нескольких действий или операций в одном взаимодействии
delete
Удаление коллекции экземпляров ресурса независимо от типа, используя определенные критерии
history
Получение истории изменения содержания экземпляров ресурса независимо от типа
search
Поиск экземпляров ресурса независимо от типа, используя определенные критерии
В дополнение к этим взаимодействиям определена система операций, представленная системой конечных точек, обеспечивающих валидацию экземпляров ресурсов, обработку сообщений и документов.
12.2.2 Описание формата взаимодействия
Далее используется следующий стиль описания формата взаимодействия:
Глагол [base]/[type]/[id]{?_format=[mime-type]}
Здесь "Глагол" соответствует методу HTTP, используемому для взаимодействия, компоненты, заключенные в квадратные скобки, обязательны, в фигурные - необязательны. При описании формата могут использоваться следующие компоненты:
а) base: базовый URL;
б) mime-type: тип среды MIME;
в) type: имя типа ресурса (например, Patient)
г) id: логический идентификатор экземпляра ресурса;
д) vid: идентификатор версии экземпляра ресурса;
е) parameters: параметры, определенные для данного взаимодействия.
При конструировании адреса URL, соответствующего этому формату, следует использовать представление символов, описанное в [27].
12.2.3 Базовый URL
Базовый URL представляет собой адрес, по которому обеспечивается доступ ко всем экземплярам ресурсов. Он имеет следующий формат
http{s}://сервер{/путь}
Компонент пути необязателен и не содержит концевую косую черту. У каждого типа ресурса есть конечная точка с адресом /<тип ресурса>. Например, конечная точка для типа ресурса Patient имеет следующий адрес:
https://server/path/Patient
Для адресации конечной точки типа ресурса допускаются два варианта: с концевой косой чертой и без нее.
Все логические взаимодействия определены относительно базового URL. Все URL и идентификаторы, являющиеся компонентами URL, чувствительны к регистру. В качестве кодировки используется UTF-8.
12.3 Метаданные и версионность ресурсов
В структуре каждого типа ресурса предусмотрены элементы метаданных. Эти элементы отображаются на запросы и ответы HTTP в соответствии с таблицей 347.
Таблица 347
Отображение метаданных на запросы и ответы HTTP
Элемент метаданных
Описание
Отображение
.id
Логический идентификатор экземпляра ресурса
Содержится в адресе URL
.meta.versionId
Идентификатор версии экземпляра ресурса
Заголовок ETag
.meta.lastUpdated
Дата и время последнего изменения экземпляра ресурса
Заголовок Last-Modified
Идентификатор версии экземпляра ресурса трактуется как "слабый" ETag и должен представляться заключенным в кавычки с префиксом W/, например ETag: .
12.4 Коды статуса HTTP
Правила использования специфичных кодов статуса HTTP приводятся ниже в тех случаях, когда требуется правильное отображение этих кодов на конкретные состояния ответов на запросы. Для передачи детальной информации об ошибках в ряде случаев должен использоваться экземпляр ресурса OperationOutcome, однако это не всегда возможно для ответов с кодом статуса HTTP 4xx или 5xx.
12.5 Заголовки HTTP
В таблице приведено использование нескольких заголовков HTTP для изменения обработки или формата запросов или результатов.
Таблица 348
Использование заголовков HTTP
Заголовок
Направление
Описание
Accept
запрос
Согласование типа MIME содержания
ETag
ответ
Значение элемента .meta.versionId в форме "слабого" ETag
If-Match
запрос
Совпадение значений ETag при условных запросах
If-Modified-Since
запрос
Чтение при условии, что экземпляр ресурса изменился после заданного момента времени
If-None-Exist
запрос
Нестандартный заголовок, определенный организацией Health Level Seven в целях предотвращения дублей экземпляров ресурса
If-None-Match
запрос
Несовпадение значений ETag при условных запросах
Last-Modified
ответ
Значение элемента .meta.lastUpdated, преобразованное в требуемый формат
Prefer
запрос
Задает различные варианты поведения, специфичные для отдельных запросов
Location
ответ
Указывает адрес URL вновь созданного экземпляра ресурса
Content-Location
ответ
Используется в схеме асинхронной обработки для указания адреса, по которому можно получить ответ на запрос
12.6 Управление содержанием ответа
Если сервер использует часовой пояс по умолчанию, то следует возвращать его значение в заголовке Date ответа HTTP.
Для улучшения пропускной способности в спецификации предусмотрены средства сокращения возвращаемого содержания (параметры управления ответом _summary и _elements, см. таблицу 349).
12.7 Типы содержания и кодировки
Формальные типы среды MIME для передачи содержания экземпляров ресурсов имеют значения application/fhir+xml (передача содержания в формате XML) или application/fhir+json (передача содержания в формате JSON).
При передаче запросов на поиск с помощью HTTP POST может использоваться тип среды MIME application/x-www-form-urlencoded.
Если клиент передает в заголовке Accept более общий тип среды MIME (application/xml, text/json или application/json), то сервер по возможности должен указать в ответе запрошенный тип.
Если в заголовке Accept указан формат, который сервер не поддерживает, то должен быть возвращен статус HTTP 406 Not Acceptable. Если неподдерживаемый формат указан в запросе на поиск, передаваемом с помощью HTTP POST, то должен быть возвращен статус HTTP 415 Unsupported Media Type.
Содержание экземпляров ресурсов должно представляться в кодировке UTF-8.
12.8 Общие параметры
В таблице 349 перечислены параметры, которые могут использоваться во всех взаимодействиях.
Таблица 349
Общие параметры
Имя параметра
Описание
_format
Задает альтернативное представление тела ответа, используемое вместо типа среды MIME, указанного в заголовке Accept. Значения xml, text/xml, application/xml, application/fhir+xml должны трактоваться как представление тела ответа в формате XML, а значения json, application/json, application/fhir+json - как представление тела ответа в формате JSON
_pretty
Допустимые значения true и false. Значение true указывает, что тело ответа должно представляться в формате, удобном для чтения человеком
_summary
Задает заранее определенное сокращенное представление экземпляра ресурса в теле ответа
_elements
Перечисляет конкретные элементы экземпляра ресурса, которые должны быть возвращены в теле ответа. Обязательные элементы возвращаются, даже если не указаны в этом перечислении
12.9 Поддержка версионности
Сервер по возможности должен поддерживать версионность, то есть присваивать соответствующие значения элементам meta.versionId, поддерживать чтение версий экземпляра ресурса и изменения с учетом номера версии.
Информация о поддержке версионности экземпляров конкретного типа ресурса возвращается сервером в ответ на запрос GET [base]/metadata в элементе CapabilityStatement.rest.resource.versioning, который может принимать следующие значения:
а) no-version: версионность и элемент meta.versionId не поддерживаются;
б) versioned: версионность и элемент meta.versionId поддерживаются;
в) versioned-update: версионность, элемент meta.versionId и изменения с учетом номера версии поддерживаются.
12.10 Часовой пояс клиента
Рекомендуется указывать часовой пояс клиента в нестандартном заголовке client-timezone запроса HTTP. Формат заголовка определен в проекте RFC draft-sharhalakis-httptz-05 (https://datatracker.ietf.org/doc/html/draft-sharhalakis-httptz-05).
12.11 Взаимодействие чтения read
Взаимодействие read обеспечивает чтение текущего содержания экземпляра ресурса. Оно выполняется с помощью метода HTTP GET:
GET [base]/[type]/[id] {?_format=[mime-type]}
По данному запросу сервер возвратит единичный экземпляр, содержание которого определяется типом ресурса. Соответствующий URL этого экземпляра может быть доступен обозревателю Интернет. Возвращаемый экземпляр ресурса должен иметь элемент id со значением [id]. Сервер по возможности должен возвратить заголовок ETag с номером версии (если версионность поддерживается) и заголовок Last-Modified (дата и время последнего изменения экземпляра ресурса).
Неизвестные экземпляры ресурса и удаленные экземпляры ресурса трактуются по-разному: при применении метода GET к удаленному экземпляру ресурса должен возвращаться код статуса HTTP 410 Gone, а при применении метода GET к неизвестному экземпляру ресурса должен возвращаться код статуса HTTP 404 Not Found.
При взаимодействии read может быть указан параметр summary. Запрос
GET [base]/[type]/[id] {?_summary=<значение>}
возвратит подмножество элементов экземпляра ресурса, определяемое кодом <значение>:
а) true: передать сокращенное содержание, указанное в определении типа ресурса;
б) false: передать полное содержание;
в) text: передать только человеко-читаемое значение элемента text, логический идентификатор id, метаданные meta и обязательные элементы верхнего уровня;
г) count: передать только число возвращенных экземпляров (0 или 1);
д) data: передать все содержание, кроме элемента text.
При взаимодействии read может быть указан параметр _elements, в значении которого перечислены все передаваемые элементы экземпляра ресурса.
Следует иметь в виду, что сокращенное содержание экземпляра ресурса может быть не пригодно для использования во взаимодействии изменения update. Сервер по возможности должен передать элемент meta.tag со значением SUBSETTED в качестве признака сокращенного содержания.
Вместо метода GET может использоваться метод HEAD. В этом случае передаются только заголовки HTTP, а тело ответа отсутствует.
12.12 Взаимодействие чтения версии vread
Взаимодействие чтения версии vread предоставляет содержание заданной версии экземпляра ресурса. Оно выполняется с помощью метода HTTP GET:
GET [base]/[type]/[id]/_history/[vid] {?_format=[mime-type]}
Сервер возвратит единичный экземпляр, содержание которого определяется типом ресурса type, идентификатором экземпляра id и идентификатором версии vid. Возвращаемый экземпляр ресурса должен иметь элемент id со значением [id] и элемент meta.versionId, содержащий значение [vid].
Сервер по возможности должен возвратить заголовок ETag с номером версии (если версионность поддерживается) и заголовок Last-Modified (дата и время последнего изменения экземпляра ресурса).
Если версия содержания экземпляра ресурса ровно та, при которой этот экземпляр был удален, то сервер по возможности должен возвратить код статуса HTTP 410 Gone, а если версия с таким идентификатором отсутствует - код статуса HTTP 404 Not Found.
Даже если сервер не поддерживает версионность, он, по возможности, должен поддерживать чтение текущей версии содержания экземпляра ресурса. Если при этом сделан запрос предыдущей версии содержания, то сервер должен возвратить код статуса 404 Not Found и экземпляр ресурса OperationOutcome, уточняющий, что для данного типа или экземпляра ресурса история изменения не поддерживается.
Вместо метода GET может использоваться метод HEAD.
12.13 Взаимодействия изменения update
12.13.1 Общие требования
Взаимодействие изменения update создает новую текущую версию существующего содержания ресурса или создает начальную версию содержания, если экземпляр ресурса с данным [id] не существует. Оно выполняется с помощью метода HTTP PUT:
PUT [base]/[type]/[id] {?_format=[mime-type]}.
Тело запроса должно содержать экземпляр ресурса, у которого элемент id имеет значение [id]. Если элемент id отсутствует или его значение не равно [id], то сервер должен возвратить код статуса HTTP 400 и по возможности должен возвратить экземпляр ресурса OperationOutcome, идентифицирующий причину ошибки. Если тело запроса содержит элемент meta, то сервер должен игнорировать элементы meta.versionId и meta.lastUpdated. Если сервер поддерживает версионность, он должен заполнить элементы meta.versionId и meta.lastUpdated новыми правильными значениями.
Изменение предшествующих версий экземпляра ресурса не поддерживается. Измененное содержание передается целиком, вместе с неизмененными элементами.
При успешном выполнении запроса сервер должен возвратить код статуса HTTP 200 OK, если содержание ресурса было изменено, или HTTP 201 Created, если экземпляр ресурса был создан либо возвращен к жизни. При этом должны быть возвращены заголовки Last-Modified и ETag, в котором указан новый идентификатор версии versionId содержания ресурса. Если экземпляр ресурса был создан (то есть возвращен код статуса HTTP 201 Created), сервер по возможности должен возвратить заголовок Location следующего вида:
Location: [base]/[type]/[id]/_history/[vid],
где [id] - существующий или вновь созданный логический идентификатор экземпляра ресурса, а [vid] - новый номер версии экземпляра. Если сервер не поддерживает версионность ресурса данного типа, то заголовок Location должен иметь следующий вид:
Location: [base]/[type]/[id].
При выполнении изменения сервер может сохранять комментарии, инструкции, форматирование содержания, передаваемого в формате XML, либо пробельные элементы содержания, передаваемого в формате JSON, но не обязан это делать. Это должно быть учтено при использовании электронной подписи.
12.13.2 Использование update для создания нового экземпляра ресурса
Сервер может позволить клиенту выполнить запрос PUT с указанием еще не существующего идентификатора [id] и тем самым позволить клиенту самостоятельно назначить идентификатор экземпляра ресурса. Такое поведение сервера не является обязательным, но в отдельных случаях может потребоваться.
Если сервер не создал новый экземпляр ресурса, он не должен возвращать код статуса HTTP 201 Created. При создании нового экземпляра ресурса должен быть возвращен заголовок Location, описанный в 12.13.1.
12.13.3 Отклонение взаимодействия изменения
Сервер может отклонить запрос изменения update из-за возможного нарушения целостности данных или по иным бизнес-правилам и возвратить соответствующий код статуса HTTP (обычно 422 Unprocessable Entity).
В дополнение к обычным кодам статуса HTTP, относящимся к безопасности, заголовку и согласованию типу содержания, могут быть возвращены следующие коды статуса HTTP:
- 400 Bad Request - содержание ресурса не может быть разобрано или нарушает наложенные на него ограничения (или условное изменение относится более чем к одному экземпляру ресурса);
- 401 Not Authorized - для данного взаимодействия требуется авторизация;
- 404 Not Found - тип ресурса не поддерживается;
- 405 Method Not allowed - изменяемый экземпляр ресурса не существует, а сервер не позволяет клиенту самостоятельно назначать идентификатор экземпляра ресурса;
- 409 Conflict/412 Precondition Failed - конфликт версий;
- 422 Unprocessable Entity - переданное содержание не соответствует профилю ресурса или нарушает иные бизнес-правила сервера.
Для каждой из этих ошибок сервер по возможности должен передать экземпляр ресурса OperationOutcome, детализирующий причину ошибки.
12.13.4 Условное изменение
Условное изменение позволяет клиенту запросить изменение существующего экземпляра ресурса не по его идентификатору [id], а по некоторым критериям поиска, то есть передать запрос следующего вида:
PUT [base]/[type]?[параметры поиска].
При выполнении такого запроса сервер осуществляет поиск, определенный для данного типа ресурса. Дальнейшие действия зависят от числа найденных экземпляров ресурса:
а) не найдены, в теле запроса элемент id не указан. Сервер создает новый экземпляр ресурса;
б) не найдены, в теле запроса указан элемент id. Сервер трактует это как взаимодействие update для создания нового экземпляра ресурса (см. 0) или отклоняет его, если не поддерживает такое взаимодействие;
в) найден один экземпляр, в теле запроса элемент id не указан или имеет значение, совпадающее со значением элемента id в найденном экземпляре. Сервер выполняет изменение найденного экземпляра ресурса;
г) найден один экземпляр, в теле запроса элемент id указан, но имеет значение, не совпадающее со значением элемента id в найденном экземпляре. Сервер возвращает код статуса HTTP 400 Bad Request и по возможности возвращает экземпляр ресурса OperationOutcome, детализирующий причину ошибки;
д) найдено несколько экземпляров. Сервер возвращает код статуса HTTP 412 Precondition Failed и по возможности возвращает экземпляр ресурса OperationOutcome, детализирующий причину ошибки.
Если сервер не поддерживает условное изменение, то он должен возвратить код статуса HTTP 400 Bad Request и может возвратить экземпляр ресурса OperationOutcome, детализирующий причину ошибки.
Клиент может запросить изменение экземпляра ресурса при условии, что заданная версия экземпляра отсутствует на сервере. Такой запрос осуществляется с помощью нестандартного заголовка HTTP If-None-Match, указав версию экземпляра в форме "слабого" ETag, например:
If-None-Match: W/"[идентификатор версии]".
Если вместо "слабого" ETag указан символ звездочки (If-None-Match: *), то новый экземпляр ресурса не создается, если на сервере нет существующих версий экземпляра.
12.13.5 Обеспечение целостности изменений
Если один и тот же экземпляр ресурса изменяется несколькими клиентами, то потерю изменений можно предотвратить с помощью использования сочетания заголовков ETag и If-Match. В этом случае сервер должен возвращать заголовок ETag с каждым экземпляром ресурса, например:
HTTP 200 OK
Date: Sat, 09 Feb 2013 16:09:50 GMT
Last-Modified: Sat, 02 Feb 2013 12:02:47 GMT
ETag: W/"23"
Content-Type: application/fhir+json
Если заголовок ETag присутствует, то он должен содержать идентификатор версии экземпляра ресурса. Сервер может генерировать номер версии любым способом, с теми ограничениями, что он должен соответствовать типу данных id и быть уникальным в пространстве идентификаторов версий ресурса данного типа. Если экземпляры ресурсов возвращаются в контейнере Bundle, то к ним заголовок ETag не относится и элемент идентификатора версии ресурса versionId должен использоваться напрямую.
Если клиент запрашивает изменение с использованием алгоритма обеспечения целостности, то он должен включить в запрос заголовок If-Match, повторяющий значение заголовка ETag, полученного от сервера, например:
PUT [base]/Patient/347
If-Match: W/"23"
Если идентификатор версии, указанный в заголовке If-Match, не совпадает с идентификатором версии текущего содержания экземпляра ресурса, то сервер должен возвратить код статуса HTTP 412 Precondition Failed и не выполнять изменение содержания ресурса.
Сервер может требовать, чтобы клиент передавал заголовок If-Match, возвращая код статуса HTTP 400 Bad Request, если этот заголовок отсутствует. Если сервер обнаружил, что изменение не может быть выполнено в силу внутренних причин (например, изменение экземпляра ресурса заблокировано), то должен быть возвращен код статуса HTTP 409 Conflict.
12.14 Взаимодействие исправления patch
12.14.1 Общие требования
При взаимодействии изменения update клиент передает серверу полное содержание экземпляра ресурса, даже если в нем изменился всего один элемент. При больших объемах содержания это приводит к снижению эффективности пропускной способности канала передачи данных. В качестве альтернативы может использоваться взаимодействие исправления patch, при котором клиент передает серверу только измененные элементы экземпляра ресурса.
Взаимодействие исправления выполняется с помощью метода HTTP PATCH:
PATCH [base]/[type]/[id] {?_format=[mime-type]}.
Тело запроса должно содержать экземпляр ресурса Parameters, описывающий выполняемые изменения.
Сервер должен представить хранящийся у него экземпляр ресурса в формате, указанном в параметре _format, и применить к этому представлению изменения, указанные в экземпляре ресурса Parameters. Затем сервер должен использовать измененное представление как тело запроса на изменение хранящегося у него экземпляра ресурса. Соответственно применяются все требования к обработке ошибок и идентификаторов версий, описанные в подразделе 12.13.
Взаимодействие исправления определено не для всех типов ресурсов. Примером может служить ресурс Binary.
12.14.2 Условное исправление
Если сервер поддерживает взаимодействие patch и условное изменение, то по возможности он должен поддерживать условное исправление. При выполнении такого запроса сервер осуществляет поиск, определенный для данного типа ресурса. Дальнейшие действия зависят от числа найденных экземпляров ресурса:
а) не найдены. Сервер возвращает код статуса HTTP 404 Not Found;
б) найден один экземпляр. Сервер выполняет исправление найденного экземпляра ресурса;
в) найдено несколько экземпляров. Сервер возвращает код статуса HTTP 412 Precondition Failed, указывающее, что заданное клиентом условие недостаточно избирательное.
12.14.3 Обеспечение целостности человеко-читаемого представления
Исправление может привести к тому, что человеко-читаемое представление экземпляра ресурса (значение элемента text.div) перестанет соответствовать обновленному содержанию. Если text.div отсутствует среди исправляемых элементов и значение text.status в исправляемом экземпляре ресурса отличается от generated (сгенерировано), то сервер может или отклонить взаимодействие patch, или сгенерировать значение text.div самостоятельно и присвоить элементу text.status значение generated.
12.15 Взаимодействие удаления delete
12.15.1 Общие требования
Взаимодействие удаления delete удаляет существующий экземпляр ресурса. Оно выполняется с помощью метода HTTP DELETE:
DELETE [base]/[type]/[id].
Тело запроса должно быть пустым.
Взаимодействие удаления delete означает, что последующие запросы на чтение экземпляра ресурса, неспецифичные для версии, должны возвращать код статуса HTTP 410 Gone, а запросы на поиск не должны возвращать этот экземпляр. При успешном удалении либо при отсутствии экземпляра ресурса с заданным идентификатором сервер должен возвратить один из следующих кодов статуса:
- HTTP 200 OK, если ответ содержит дополнительные сведения;
- HTTP 204 No Content, если ответ содержит дополнительные сведения;
- HTTP 202 Accepted, если серверу запрещено сообщать факт удаления.
Поддержка удаления ресурса любого типа, ресурса конкретного типа или конкретного экземпляра ресурса зависит от политики безопасности и бизнес-правил сервера. Если серверу запрещено удалять ресурсы определенного типа в соответствии с общей политикой, то он должен возвратить код статуса HTTP 405 Method not allowed. Если он отказывает в удалении конкретного экземпляра ресурса по причинам, специфичным для этого экземпляра, например если удаление нарушает ссылочную целостность, то он должен возвратить код статуса HTTP 409 Conflict.
Применение взаимодействия удаления delete к уже удаленному экземпляру ресурса не приводит ни к какому эффекту, и сервер по возможности должен возвратить один из следующих кодов статуса:
а) HTTP 200 OK, если ответ содержит дополнительные сведения;
б) HTTP 204 No Content, если ответ не содержит дополнительные сведения.
В составе многих типов ресурсов присутствует элемент status, описывающий возможные состояния экземпляра ресурса. Эти состояния могут перекрываться с идеей удаления. Семантика удаления должна быть описана для каждого типа ресурса, имеющего элемент status. Если такое описание отсутствует, то взаимодействие удаления delete должно трактоваться как удаление экземпляра ресурса вне зависимости от значения элемента status.
Если сервер обеспечивает ведение истории версий, то взаимодействие delete не удаляет историю версий конкретного экземпляра ресурса. В этом случае удаление эквивалентно созданию специальной записи истории, у которой нет содержания и которая помечена как удаленная. Удаление предыдущих версий не поддерживается. Если сервер разрешает создание экземпляров ресурсов с заданными логическими идентификаторами id, то история изменений экземпляра может быть продолжена после удаления. Для обеспечения целостности идентификаторов версий сервер может включить в ответ на запрос удаления заголовок ETag, позволяющий управлять версиями после удаленного экземпляра ресурса.
Это правило не является обязательным и сервер может удалить как экземпляр ресурса, так и историю его версий, если это соответствует политике или бизнес-правилам.
12.15.2 Условное удаление
Условное удаление позволяет клиенту запросить удаление существующего экземпляра ресурса не по его идентификатору [id], а по некоторым критериям поиска, то есть передать запросы следующего вида:
- для удаления экземпляров ресурса заданного типа:
DELETE [base]/[type]?[search parameters];
- для удаления экземпляров ресурса независимо от их типа:
DELETE [base]?[search parameters].
При выполнении такого запроса сервер выполняет поиск, определенный для данного типа ресурса или для любых типов ресурсов. Дальнейшие действия зависят от числа найденных экземпляров ресурса:
а) не найдены или найден единственный экземпляр. Сервер удаляет найденный экземпляр ресурса;
б) найдено несколько экземпляров. Сервер может удалить все найденные экземпляры или возвратить код статуса HTTP 412 Precondition Failed, указывающий, что переданные ему параметры поиска недостаточно избирательные.
Если сервер не поддерживает условное удаление, то он по возможности должен возвратить код статуса HTTP 400 Bad Request и может возвратить экземпляр ресурса OperationOutcome, детализирующий причину ошибки.
12.16 Взаимодействие создания create
12.16.1 Общие требования
Взаимодействие создания create создает новый экземпляр ресурса в хранилище, определяемом сервером. Если клиенту требуется управлять присваиванием логических идентификаторов экземплярам ресурсов, то вместо create следует использовать update. Взаимодействие create выполняется с помощью запроса HTTP POST следующего вида:
POST [base]/[type] {?_format=[mime-type]}.
Тело запроса должно содержать экземпляр ресурса. Он не должен иметь элемент id. Если элемент id присутствует, сервер должен игнорировать его. Если тело запроса имеет элемент meta, сервер должен игнорировать значения его компонентов versionId и lastUpdated. Сервер должен заполнить элементы id, meta.versionId и meta.lastUpdated правильными новыми значениями.
При выполнении взаимодействия create сервер по возможности должен воспринимать экземпляр ресурса в том виде, как он получен, и при последующем чтении возвращать то же самое содержание.
При успешном создании экземпляр ресурса сервер возвращает код статуса HTTP 201 Created. Кроме того, он должен возвратить заголовок Location, содержащий новый логический идентификатор созданного экземпляра ресурса и новый идентификатор версии:
Location: [base]/[type]/[id]/_history/[vid],
где [id] - идентификатор экземпляра ресурса, а [vid] - идентификатор версии содержания экземпляра ресурса. Если сервер не поддерживает версионность, то заголовок Location должен иметь следующий вид:
Location: [base]/[type]/[id].
Заголовок Location может содержать абсолютный или относительный URL.
Сервер по возможности должен возвратить заголовок ETag, содержащий идентификатор версии содержания экземпляра ресурса (если версионность поддерживается), и заголовок Last-Modified.
Если синтаксис содержания ресурса не валиден или не корректен и не может быть использован для создания нового экземпляра ресурса, сервер возвращает код статуса HTTP 400 Bad Request. Если сервер отклоняет содержание ресурса в связи с тем, что оно нарушает бизнес-правила, то он возвращает код статуса HTTP 422 Unprocessable Entity. В каждом из этих случаев сервер по возможности должен возвратить тело ответа, содержащее экземпляр ресурса OperationOutcome, детализирующий причину ошибки.
При создании экземпляра ресурса сервер может сохранять комментарии, инструкции, форматирование содержания, передаваемого в формате XML, либо пробельные элементы содержания, передаваемого в формате JSON, но не обязан это делать. Это должно быть учтено при использовании электронной подписи.
В дополнение к обычным кодам статуса HTTP, относящимся к безопасности, заголовку и согласованию типу содержания, могут быть возвращены следующие коды статуса HTTP:
а) 400 Bad Request - содержание тела запроса не может быть разобрано или нарушает наложенные на него ограничения;
б) 404 Not Found - тип ресурса не поддерживается;
в) 422 Unprocessable Entity - переданное содержание не соответствует профилю ресурса или нарушает иные бизнес-правила. Сервер по возможности должен передать экземпляр ресурса OperationOutcome, детализирующий причину ошибки.
12.16.2 Условное создание
Это взаимодействие позволяет клиенту инициировать создание нового экземпляра ресурса при условии, что на сервере еще нет некоторого эквивалентного экземпляра ресурса. Клиент задает эквивалентность с помощью заголовка If-None-Exist, являющегося расширением спецификации HTTP:
If-None-Exist: [параметры поиска],
где [параметры поиска] представляют собой ту часть URL, которая следует за знаком вопроса "?").
При обработке запроса на условное создание сервер сначала выполняет поиск экземпляра ресурса данного типа, соответствующего заданным параметрам поиска. Дальнейшие действия зависят от числа найденных экземпляров:
а) не найдены. Сервер создает новый экземпляр ресурса в соответствии с 12.16.1;
б) найден один экземпляр. Сервер игнорирует запрос, возвращает код статуса HTTP 200 OK, текущее содержание этого экземпляра и все заголовки, как если бы экземпляр был создан;
в) найдено несколько экземпляров. Сервер возвращает код статуса HTTP 412 Precondition Failed, указывающий, что переданные ему параметры поиска недостаточно избирательные.
Этот вариант создания призван понизить риск создания дубликатов. Например, клиент может запросить создание экземпляра ресурса Person (демографические данные физического лица) при условии, что на сервере еще нет экземпляра ресурса Person, имеющего заданный СНИЛС или ИНН.
Если сервер не поддерживает условное создание, то он должен возвратить код статуса HTTP 400 Bad Request и может возвратить экземпляр ресурса OperationOutcome, детализирующий причину ошибки.
12.17 Взаимодействие поиска search
12.17.1 Общие требования
Взаимодействие поиска search выполняет поиск экземпляров ресурса, соответствующих определенным параметрам, с помощью запросов HTTP GET. Параметры поиска представляют собой пары вида "имя=значение", закодированные в соответствии с правилами URL.
Параметры поиска могут применяться к ресурсам любого типа (например, параметр _id определен для каждого типа ресурсов), к ресурсам конкретного типа (например, параметр даты рождения birthDate используется для поиска экземпляров ресурса Patient). Может осуществляться текстовый поиск по человеко-читаемому содержанию экземпляру ресурса или по всем его строковым элементам. Некоторые параметры управляют выводом результатов поиска.
В типичном REST API коллекция найденных экземпляров ресурсов представляется в форме массива. В данном предварительном стандарте требуется, чтобы результаты поиска возвращались в форме контейнера Bundle, у которого элемент type имеет значение searchset. Это позволяет иметь в результате поиска дополнительную информацию (например, число найденных экземпляров), обеспечивать дополнительную функциональность (например, постраничный вывод) и включать в результат поиска экземпляры ресурсов разных типов.
Структура контейнера результатов поиска показана на рисунке 79. Экземпляры ресурсов, содержащиеся в этом контейнере, представляются в элементе resource в составе отдельных записей entry. Ссылки на страницы результатов поиска представлены элементами link. Причина включения экземпляра ресурса в результат поиска представлена элементом search. Его компонент mode может иметь следующие значения: match (экземпляр ресурса удовлетворяет критериям поиска) | include (экземпляр ресурса включен по прямой или обратной ссылке) | outcome (запись entry содержит экземпляр ресурса OperationOutcome с дополнительной информацией об обработке запроса на поиск).
Рисунок 79 - Контейнер результатов поиска
12.17.2 Контекст поиска
Операции поиска осуществляются в одном из следующих контекстов:
а) система - все типы ресурсов;
б) тип ресурса.
Если параметры поиска отсутствуют, например, GET [base], GET [base]/Patient, то сервер должен включить в результат поиска все экземпляры ресурсов данного контекста. Если число найденных экземпляров слишком велико, сервер может отклонить такой запрос или использовать постраничный вывод результатов.
12.17.3 Запрос HTTP GET
Клиент выполняет поиск с помощью запроса HTTP GET, в котором параметры поиска включены в адресную строку URL (таблица 350).
Таблица 350
Поиск с помощью запроса HTTP GET
Контекст
Описание
Система
GET [base]?param1=value&...{&_format=[mime-type]}
Тип ресурса
GET [base]/[resource-type]/?param1=value&...{&_format=[mime-type]}
12.17.4 Возвращаемые коды статуса HTTP
При успешном поиске сервер должен возвратить код статуса HTTP 200 OK, а тело ответа должно представлять собой контейнер Bundle, в который включена коллекция найденных экземпляров ресурсов. При этом элемент type ресурса Bundle должен иметь значение searchset. Экземпляры ресурсов, включенные в контейнер, могут быть получены от другого сервера, то есть базовый URL в элементе Bundle.entry.fullUrl может отличаться от базового URL, указанного в запросе поиска.
Коллекция, полученная в результате поиска, может быть очень большой, поэтому сервер может использовать постраничный вывод, описанный в 12.22. Сервер может также включить в контейнер Bundle экземпляры ресурсов OperationOutcome, содержащие дополнительную информацию о поиске. Они не должны содержать информацию о проблемах поиска, имеющих статус фатальной ошибки (OperationOutcome.severity = fatal), при этом в элементах Bundle.entry.search.mode записей Bundle.entry, содержащих эти экземпляры, должны быть указаны значения outcome.
Если поиск не может быть выполнен, то сервер должен возвратить код статуса HTTP 4xx или 5xx. Если такая ошибка возникла на уровне обработки ресурсов, то сервер по возможности должен включить в тело ответа экземпляр ресурса OperationOutcome, детализирующий ошибку.
В дополнение к обычным кодам статуса HTTP, относящимся к безопасности, заголовку и согласованию типу содержания, могут быть возвращены следующие коды статуса HTTP:
а) 400 Bad Request - запрос поиска не может быть выполнен или нарушает правила валидации;
б) 401 Not Authorized - для предпринятого взаимодействия требуется авторизация;
в) 404 Not Found - тип ресурса не поддерживается;
г) 405 Method Not Allowed - сервер не поддерживает выбранный тип запроса.
Для каждой из этих ошибок сервер по возможности должен передать экземпляр ресурса OperationOutcome, детализирующий причину ошибки.
12.17.5 Именованный поиск
Клиенту могут потребоваться возможности поиска, не укладывающиеся в стандартную схему. Для этой цели может использоваться именованный поиск, реализуемый специфичным образом. Именованный поиск задается с помощью параметра _query, например:
GET [base]/Person?_query=имя&параметры.
При именованном поиске могут задаваться параметры, не определенные для каких-либо ресурсов. В строке запроса может быть указан только один экземпляр параметра _query. Сервер должен отказать в обработке запроса, если он не поддерживает параметр _query или не способен обработать запрос с данным именем.
12.17.6 Параметры управления содержанием
В дополнение к общим параметрам, описанным в таблице 349, могут быть указаны также параметры управления содержанием, перечисленные в таблице 367. Их описание приведено в подразделе 12.27.
12.18 Взаимодействие описания возможностей capabilities
Взаимодействие capabilities позволяет получить описание возможностей, обеспечиваемых сервером. Оно выполняется с помощью следующей команды HTTP GET:
GET [base]/metadata{?_format=[mime-type]}.
Ответ на запрос должен содержать экземпляр ресурса CapabilityStatement, описывающий типы ресурсов и взаимодействия, обеспечиваемые сервером для этих типов ресурсов.
По возможности в ответе на запрос должен возвращаться заголовок ETag, идентифицирующий версию описания возможностей.
12.19 Взаимодействие транзакции transaction
12.19.1 Общие требования
Взаимодействие транзакции transaction позволяет задать несколько взаимодействий в одном запросе HTTP. Все взаимодействия выполняются в одной транзакции: если при хотя бы одном взаимодействии возникла ошибка, результаты всех ранее выполненных взаимодействий откатываются.
Взаимодействие транзакции осуществляется с помощью запроса HTTP POST следующего вида:
POST [base] {?_format=[mime-type]}.
Тело запроса должно содержать контейнер Bundle, у которого элемент type имеет значение transaction. Структура контейнера транзакции показана на рисунке 80.
Рисунок 80 - Контейнер транзакции
Запрос на выполнение взаимодействия представляется в элементе request в составе записи entry. Если взаимодействие выполняется с помощью запроса PUT или POST, то элемент resource должен содержать экземпляр ресурса, представляющий тело запроса.
12.19.2 Правила выполнения транзакции
Сервер либо выполняет все запросы (то есть при обработке каждой записи entry возвращается код статуса HTTP 2xx или 3xx) и возвращает контейнер результата транзакции, либо отклоняет все запросы и возвращает ответ с кодом статуса HTTP 4xx или 5xx. Результат выполнения не должен зависеть от порядка следования экземпляров ресурсов в контейнере транзакции. В одной транзакции может присутствовать только один экземпляр ресурса с данным идентификатором.
Запросы, содержащиеся в транзакции, должны выполняться в следующем порядке:
а) все взаимодействия удаления (DELETE);
б) все взаимодействия создания (POST);
в) все взаимодействия изменения (PUT) или исправления (PATCH);
г) все взаимодействия чтения, чтения версии, поиска, истории (GET или HEAD).
Экземпляры ресурсов, вложенные в контейнер транзакции, могут содержать перекрестные ссылки. Присвоив новый логический идентификатор id экземпляру ресурса, создаваемому с помощью запроса POST, сервер должен обновить все ссылки на него внутри контейнера Bundle. Ссылки на экземпляры ресурсов, не включенные в контейнер, оставляются неизменными.
Элемент fullUrl записи entry, содержащей создаваемый экземпляр ресурса, трактуется как идентификатор этого экземпляра внутри контейнера Bundle. При создании экземпляра сервер игнорирует этот идентификатор и присваивает собственный. При выполнении изменения сервер по возможности осуществляет преобразование значения элемента fullUrl в местный адрес URL, по которому находится изменяемый экземпляр ресурса. Если такое преобразование не представляется возможным, сервер заменяет базовую часть значения fullUrl на собственный базовый адрес. Это позволяет передать контейнер транзакции нескольким серверам, не меняя значения элементов fullUrl, указанных внутри контейнера.
12.19.3 Условные ссылки
При формировании контейнера транзакции у клиента может отсутствовать логический идентификатор ссылочного экземпляра ресурса. На этот случай в транзакции (и только в транзакции) ссылка на экземпляр ресурса по логическому идентификатору может быть заменена на условие поиска, например, <reference value="Patient?identifier=12345"/>. Это условие должно задаваться относительно базового пути [base] и начинаться с типа ресурса [type]. Параметры управления содержанием результата поиска должны отсутствовать.
При выполнении транзакции сервер должен осуществить следующие действия:
а) проверить все ссылки на предмет наличия в них условий поиска;
б) выполнить поиск по этим условиям;
в) если результат поиска пуст или содержит более одного экземпляра ресурса, откатить транзакцию и возвратить клиенту сообщение об ошибке;
г) если найден единственный экземпляр ресурса, заменить условие поиска на логический идентификатор этого экземпляра.
12.19.4 Результат транзакции
При успешном выполнении транзакции тело ответа должно содержать контейнер результата транзакции Bundle, у которого элемент type имеет значение transaction-response. Структура этого контейнера показана на рисунке 81.
Рисунок 81 - Контейнер результата транзакции
Контейнер результата транзакции содержит по одной записи entry на каждую запись entry контейнера транзакции, и в том же порядке. Запись entry содержит информацию о результате транзакции в элементе response, включая код статуса HTTP и содержание заголовков Location, ETag, Last-Modified. В зависимости от значения заголовка Prefer, указанного при запросе транзакции, в запись entry может быть включен экземпляр ресурса.
Если при выполнении транзакции произошла ошибка, то вместо контейнера Bundle возвращается один экземпляр ресурса OperationOutcome, содержащий детальные сведения об ошибке.
12.20 Взаимодействие истории history
Взаимодействие истории history обеспечивает получение истории изменений конкретного экземпляра ресурса, истории изменения экземпляров ресурса данного типа или истории изменения экземпляров ресурсов всех типов. Эти три варианта выполняются с помощью следующих запросов HTTP GET:
а) GET [base]/[type]/[id]/_history{?[parameters]&_format=[mime-type]};
б) GET [base]/[type]/_history{?[parameters]&_format=[mime-type]};
в) GET [base]/_history{?[parameters]&_format=[mime-type]}.
Тело ответа должно представлять собой контейнер Bundle, у которого элемент type имеет значение history. Оно содержит историю изменения версий экземпляров ресурсов, включая удаленные, и должна быть отсортирована в обратном хронологическом порядке.
Структура контейнера истории показана на рисунке 82.
Рисунок 82 - Контейнер истории
Каждая запись entry должна содержать хотя бы один из элементов resource и request. Элемент resource содержит версию экземпляра ресурса, а элемент request предоставляет информацию о взаимодействии, которое привело к данной версии, что позволяет клиенту-подписчику отличить вновь созданный экземпляр от изменения уже существующего экземпляра. Главная причина, почему элемент resource может отсутствовать, состоит в том, что содержание экземпляра могло быть изменено не с помощью REST API. Если элемент entry.request.method имеет значение PUT или POST, то элемент entry должен содержать элемент resource.
Взаимодействия create, update, patch и delete пополняют историю изменений. Другие взаимодействия не пополняют ее. Поскольку операция исправления patch в конечном счете приводит к изменению экземпляра ресурса, то соответствующий ей элемент entry.request.method будет иметь значение PUT.
Вместо GET может использоваться запрос HEAD.
Примечания
1 В истории изменений условные создания, изменения и удаления преобразуются в обычные взаимодействия.
2 Содержание ресурса, показанное в истории изменений, является тем, как оно сохранено сервером, а не тем, как оно было предоставлено клиентом (могут быть отличия).
3 Сервер по возможности должен как минимум заполнить элемент response.lastModified, чтобы можно было определить момент выполнения действия сервером.
Сервер может регистрировать только успешные взаимодействия. Сервер может указывать в истории только код статуса HTTP 200 OK вместо более специфичных статусов успеха.
В дополнение к стандартному параметру _format могут быть указаны также параметры, перечисленные в таблице 351. Каждый из этих параметров не может быть указан более одного раза.
Таблица 351
Дополнительные параметры в запросе истории
Параметр
Тип
Описание
_count
integer
Максимальное число элементов entry, указанных на одной странице
_offset
number
Число пропускаемых экземпляров ресурса (при постраничном выводе истории изменений)
_since
instant
Включить только те версии экземпляров ресурсов, которые были созданы в заданный момент времени или после него
_at
date(Time)
Включить только те версии экземпляров ресурсов, которые были текущими в некоторый момент интервала, заданного значением данного параметра
_list
reference
Включить только те версии экземпляров ресурсов, на которые есть ссылки в данном списке
_sort
token
Сортировка версий экземпляра ресурса по дате и времени последнего изменения:
-_lastUpdated (по умолчанию) - в порядке убывания
_lastUpdated - в порядке возрастания
none - без сортировки
Историю версий можно ограничить определенным периодом времени, указав параметр _since, содержащий полные дату и время с часовым поясом. Клиент должен иметь в виду, что в связи с неточностью времени он может получить более одного уведомления об изменении содержания экземпляра в момент _since. Сервер не обязан указывать время с точностью менее секунды.
Поскольку список изменений может быть длинным, сервер может использовать постраничный вывод. В этом случае он должен использовать метод, описанный в [38] (https://tools.ietf.org/html/rfc5005), учитывая максимальное число записей entry на странице, указанное в параметре _count.
Взаимодействие истории history может использоваться для организации подписки, при которой подписчик синхронизирует свои данные с издателем.
История версий ведется последовательно для каждого экземпляра ресурса, она не предназначена для прослеживания ветвей. Соответственно, нет возможности изменить или удалить предыдущую версию, можно только изменить часть ее метаданных в целях управления доступом. Все предшествующие версии содержания экземпляра ресурса предполагаются устаревшими и неактивными, оставленными для целей аудита/целостности.
Если требуется явно указать, что предшествующая версия содержания экземпляра ресурса появилась по ошибке, то следует использовать ресурс Provenance (происхождение), содержащий ссылку на эту версию. При прослеживании истории конкретного экземпляра ресурса приложение по возможности должно извлекать экземпляры ресурсов Provenance, ссылающиеся на этот экземпляр или его версию.
Если сделан запрос на получении истории, не являющейся доступной (например, сервер не хранит историю версий ресурсов данного типа или конкретного экземпляра ресурса), то сервер должен возвратить код статуса HTTP 404 Not Found и по возможности возвратить экземпляр ресурса OperationOutcome, детализирующий причину ошибки.
12.21 Транзакционная целостность
При выполнении взаимодействий create и update сервер не обязан сохранять экземпляр ресурса в том виде, как его предоставил клиент. При последующем чтении с помощью взаимодействия содержание экземпляра ресурса может отличаться от исходного по нескольким причинам, например:
а) предоставленное содержание объединяется с текущим;
б) к предоставленному содержанию применяется форматно-логический контроль и по его результатам содержание может быть изменено;
в) сервер поддерживает не все возможные элементы содержания или значения этих элементов.
В связи с этим рекомендуется придерживаться следующих правил:
а) перед запросом на изменение клиенту следует считать последнюю версию экземпляра ресурса;
б) клиент вносит в него необходимые изменения, оставляя остальное содержание неизменным;
в) клиент передает полученный результат серверу, используя взаимодействие изменения update. При этом он должен быть способен обработать возвращенные коды статуса HTTP 409 или 412.
12.22 Постраничный вывод
12.22.1 Общие требования
Для снижения нагрузки на сервер, а также для снижения сетевого трафика может использоваться постраничный вывод результатов поиска или истории изменений. В этом случае возвращаемый результат содержит ссылки link с адресами URL, по которым можно запросить другие страницы результата, например:
<Bundle xmlns="http://hl7.org/fhir">
<id value="900ef882-8ec7-410d-85d2-e5e9dbae5e24"/>
<meta>
<lastUpdated value="2023-09-19T18:37:52.066+00:00"/>
</meta>
<type value="searchset"/>
<link>
<relation value="self"/>
<url value="https://hapi.fhir.org/baseR5/Patient?_format=xml&amp;birthdate
=ge1950"/>
</link>
<link>
<relation value="next"/>
<url value="https://hapi.fhir.org/baseR5?_getpages=900ef882-8ec7-410d-
85d2-e5e9dbae5e24&amp;_getpagesoffset=20&amp;_count=20&amp;_format=xml&amp;_
pretty=true&amp;_bundletype=searchset"/>
</link>
<entry>
<fullUrl value="https://hapi.fhir.org/baseR5/Patient/3506"/>
<resource>
<Patient xmlns="http://hl7.org/fhir">
<id value=3506/>
......
С помощью параметра _count можно указать, сколько экземпляров ресурса следует возвратить на одной странице. Если _count имеет значение 0, то сервер должен возвратить экземпляр ресурса Bundle, в котором элемент total содержит общее число найденных экземпляров, но при этом в нем нет ни одного экземпляра ресурса и ссылок link на предыдущую/следующую страницу, например:
<Bundle xmlns="http://hl7.org/fhir">
<id value="069e1b59-1864-4395-b47d-6a06ed0c9c98"/>
<meta>
<lastUpdated value="2023-09-19T18:42:30.462+00:00"/>
<tag>
<system value="http://terminology.hl7.org/CodeSystem/v3-
ObservationValue"/>
<code value="SUBSETTED"/>
<display value="Resource encoded in summary mode"/>
</tag>
</meta>
<type value="searchset"/>
<total value=796/>
</Bundle>
Следует учесть, что элемент total содержит общее число экземпляров ресурсов, соответствующих условию поиска. В это число не входят экземпляры ресурсов, включаемых в Bundle в соответствии с требованием, указанным в параметрах _include или _revinclude.
Значение параметра _count никак не влияет на значение элемента Bundle.total, поскольку последний указывает общее число найденных экземпляров, а не число экземпляров ресурсов, включенных в конкретный экземпляр ресурса Bundle.
12.22.2 Смещение от начала вывода
С помощью параметра _offset можно указать смещение от начала вывода, то есть число экземпляров ресурса, пропускаемое перед формированием страницы вывода. В подсчете не участвуют экземпляры других ресурсов, включаемых в Bundle, например, ссылочные экземпляры ресурсов, включаемые в соответствии с требованием, указанным в параметре _include или _revinclude.
12.22.3 Включение других экземпляров ресурсов в результат запроса (_include и _revinclude)
Для снижения числа последовательных запросов поиска, требуемых для получения нужной информации, и тем самым для ускорения поиска можно указать серверу, что вместе с искомым экземпляром ресурса необходимо возвратить экземпляры ресурсов, на которые он ссылается, или экземпляры, которые ссылаются на него. Для этого используются параметры _include и _revinclude.
Значения параметров управления поиском _include и _revinclude состоят из двух частей, разделенных двоеточием (:):
а) тип ресурса;
б) имя параметра поиска, определенного для этого ресурса и имеющего тип reference.
Значения параметров _include и _revinclude не могут задаваться списком. Вместо этого должны быть указаны отдельные параметры управления поиском.
Для каждого ресурса, включенного в результат поиска вследствие применения параметров _include и _revinclude, элементу entry.search.mode ресурса Bundle присваивается значение include. Если добавить нечего, то в результат поиска дополнительные экземпляры ресурсов не включаются и ошибка не генерируется.
При постраничном выводе результата поиска все экземпляры включенных экземпляров ресурсов должны быть на одной странице с найденными экземплярами, чтобы она была самодостаточной.
12.22.4 Актуальность результатов запроса
Результаты запроса актуальны только на момент выполнения запроса. После его выполнения экземпляры ресурсов могут изменяться и повторение запроса может привести к другим результатам.
12.23 Нестандартные заголовки
В таблице 352 приведены нестандартные заголовки HTTP, предназначенные для использования в целях технической поддержки или отладки.
Таблица 352
Нестандартные заголовки HTTP
Заголовок
Направление
Примечания
X-Request-Id
обе стороны
Уникальный идентификатор запроса или ответа, присвоенный клиентом или сервером соответственно
X-Correlation-Id
обе стороны
Идентификатор запроса, присвоенный клиентом и возвращаемый сервером в ответе на запрос
X-Forwarded-For
запрос
Исходный IP-адрес клиента, передаваемый промежуточному узлу
X-Forwarded-Host
запрос
Исходный адрес хоста, указанный клиентом в заголовке HTTP Host
X-Intermediary
обе стороны
Используется активным промежуточным узлом, изменяющим содержание запроса или ответа
X-Forwarded-Proto
обе стороны
Идентификация исходного протокола, используемого клиентом для соединения с промежуточным узлом
X-Forwarded-Port
обе стороны
Идентификация исходного порта, используемого клиентом для соединения с промежуточным узлом
X-Forwarded-Prefix
обе стороны
Заголовок, позволяющий приложениям использовать суб-URL
Заголовок X-Request-Id предназначен для идентификации запросов или ответов в системных журналах. Клиент может присвоить запросу идентификатор и указать его в заголовке X-Request-Id. Сервер может использовать этот идентификатор или присвоить запросу собственный идентификатор, предназначенный для передачи в X-Request-Id ответа на запрос. Если идентификатор, присвоенный сервером, отличается от идентификатора, присвоенного клиентом, то сервер по возможности должен передать идентификатор, присвоенный клиентом, в заголовке X-Correlation-Id.
Протокол HTTP может маршрутизироваться, используя прокси. Такие прокси прозрачны для приложений, но при этом существует риск получения устаревшего содержания из-за кеширования.
На пути от поставщика к потребителю могут использоваться интерфейсные машины. Они отличаются от прокси тем, что активно меняют содержание передаваемых данных и не связаны требованиями, предъявляемыми к прокси. Такие агенты должны добавлять к запросу заголовки X-Intermediary, способствующие отладке или технической поддержке, например:
X-Intermediary: [идентификация агента, обычно полное доменное имя]
Конечные точки не должны использовать этот заголовок.
12.24 Сводная информация
Сводная информация по запросам HTTP приведена в таблице 353.
Таблица 353
Сводная информация по запросам
Взаимодействие
Путь
Запрос
Глагол HTTP
Заголовок Content-Type
Тело
Заголовок Prefer
Заголовок условия
read (чтение)
/[type]/[id]
GET или HEAD
не применим
отсутствует
не применим
возможен: If-Modified-Since, If-None-Match
vread (чтение версии)
/[type]/[id]/_history/[vid]
GET или HEAD
не применим
отсутствует
не применим
не применим
update (изменение)
/[type]/[id]
PUT
обязателен
экземпляр ресурса
не обязателен
возможен: If-Match
patch (исправление)
/[type]/[id]
PATCH
обязателен
экземпляр ресурса Parameters
обязателен
возможен: If-Match
delete (удаление)
/[type]/[id]
DELETE
не применим
не применим
не применим
не применим
create (создание)
/[type]
POST
обязателен
экземпляр ресурса
обязателен
возможен: If-None-Exist
search (поиск по типу)
/[type]?
GET
не применим
не применим
не применим
не применим
/[type]/_search?
POST
application/x-www-form-urlencoded
параметры запроса
не применим
не применим
search (поиск по системе)
?
GET
не применим
не применим
не применим
не применим
/_search
POST
application/x-www-form-urlencoded
параметры запроса
не применим
не применим
capabilities (возможности)
/metadata
не применим
не применим
не применим
не применим
transaction (транзакция)
/
POST
обязателен
экземпляр ресурса Bundle
не обязателен
не применим
batch (пакет)
/
POST
обязателен
экземпляр ресурса Bundle
не обязателен
не применим
history (история экземпляра)
/[type]/[id]/_history
GET
не применим
не применим
не применим
не применим
history (история типа)
/[type]/_history
GET
не применим
не применим
не применим
не применим
history (история системы)
/_history
GET
не применим
не применим
не применим
не применим
(операция)
/$[name], /[type]/$[name] или /[type]/[id]/$[name]
POST
обязателен
экземпляр ресурса Parameters
не применим
не применим
GET
не применим
не применим
не применим
не применим
POST
application/x-www-form-urlencoded
параметры запроса
не применим
не применим
Сводная информация по ответам на запрос приведена в таблице 354. В графе "Коды статуса HTTP" приведены коды, описанные в настоящем предварительном стандарте. В дополнение к ним могут возвращаться другие коды, в том числе относящиеся к аутентификации и ошибкам сервера.
Таблица 354
Сводная информация по ответам на запрос
Взаимодействие
Ответ на запрос
Заголовок Content-Type
Тело
Заголовок Location
Заголовок версионности
Коды статуса HTTP
read (чтение)
обязателен
экземпляр ресурса
не применим
O: ETag, Last-Modified
200, 202, 404, 
vread (чтение версии)
обязателен
экземпляр ресурса
не применим
O: ETag, Last-Modified
200, 202, 404, 
update (изменение)
обязателен при наличии тела
в зависимости от заголовка Prefer - экземпляр ресурса
не применим
O: ETag, Last-Modified
200, 201, 202, 400,
404, 405, 409,
412, 422
patch (исправление)
обязателен при наличии тела
в зависимости от заголовка Prefer - экземпляр ресурса
не применим
возможны:
ETag, Last-Modified
200, 201, 202, 400,
404, 405, 409,
412, 422
delete (удаление)
обязателен при наличии тела
возможен экземпляр ресурса OperationOutcome
не применим
не применим
200, 202, 204, 404,
405, 409, 412
create (создание)
обязателен при наличии тела
в зависимости от заголовка Prefer - экземпляр ресурса
обязателен
возможны:
ETag, Last-Modified
201, 202, 400, 404,
405, 422
search (поиск по типу)
обязателен
экземпляр ресурса Bundle
не применим
не применим
200, 202, 401,
404, 405
search (поиск по системе)
обязателен
экземпляр ресурса Bundle
не применим
не применим
200, 202, 401,
404, 405
capabilities (возможности)
обязателен
экземпляр ресурса CapabilityStatement
не применим
не применим
200, 202, 404
transaction (транзакция)
обязателен
экземпляр ресурса Bundle
не применим
не применим
200, 202, 400, 404,
405, 409, 412, 422
batch (пакет)
обязателен
экземпляр ресурса Bundle
не применим
не применим
200, 202, 400, 404,
405, 409, 412, 422
history (история экземпляра)
обязателен
экземпляр ресурса Bundle
не применим
не применим
200, 202
history (история типа)
обязателен
экземпляр ресурса Bundle
не применим
не применим
200, 202
history (история системы)
обязателен
экземпляр ресурса Bundle
не применим
не применим
200, 202
(операция)
обязателен
Экземпляр ресурса Parameters
не применим
не применим
200, 202 и другие в зависимости от типа операции
12.25 Шаблон асинхронных запросов
Для выполнения асинхронного запроса сервер должен поддерживать заголовок Prefer со значением respond-async (асинхронный ответ). При этом в заголовке Accept может быть указан формат экземпляра ресурса Bundle, возвращаемого при успешном выполнении запроса, или экземпляра ресурса OperationOutcome, возвращаемого при ошибке приема или выполнении запроса.
При успешном приеме запроса сервер должен возвратить код статуса HTTP 202 Accepted и заголовок Content-Location, содержащий абсолютный URL конечной точки, которой должны направляться запросы статуса ответа. Тело ответа может содержать экземпляр ресурса OperationOutcome.
При ошибке приема (например, запрос содержит неподдерживаемый параметр поиска) должен возвращаться код статуса HTTP 4XX или 5XX, а тело ответа должно содержать экземпляр ресурса OperationOutcome с описанием ошибки.
После получения ответа об успешном приеме запроса клиент может выполнять следующие действия:
- отменить выполнение запроса с помощью отправки конечной точке запроса DELETE. При успешной отмене запроса в ответ на обращение к конечной точке должны возвращаться код статуса HTTP 404 Not Found и соответствующий ему экземпляр ресурса OperationOutcome. При ошибке отмены конечная точка должна возвратить код статуса HTTP 4XX или 5XX и может возвратить экземпляр ресурса OperationOutcome с описанием ошибки;
- запросить статус выполнения с помощью отправки конечной точке запроса GET. При частых запросах статуса конечная точка может возвратить код статуса HTTP 429 Too Many Requests. Если исходный запрос еще не выполнен, конечная точка должна возвратить код статуса HTTP 202 Accepted и может возвратить заголовок X-Progress с текстовым описанием состояния выполнения, например, процент выполнения. Если при обработке запроса статуса произошла ошибка, конечная точка должна возвратить код статуса HTTP 4XX или 5XX и может возвратить экземпляр ресурса OperationOutcome с описанием ошибки. Если выполнение исходного запроса завершено (успешно или нет), то конечная точка должна возвратить код статуса HTTP 200 OK и тело, содержащее контейнер Bundle, у которого элемент type имеет значение batch-response. Результат исходного запроса должен возвращаться в первой записи контейнера Bundle.entry[0], а информация об ошибках его выполнения - в элементе Bundle.entry[0].response.
12.26 Обработка запросов поиска
12.26.1 Параметры поиска
Входные данные операции поиска именуются параметрами поиска. Параметр поиска может представлять собой:
а) фильтр, применимый к любому типу ресурса (например, _id);
б) фильтр, применимый к конкретному типу ресурса (например, параметр поиска birthdate применим к типу ресурса Patient и обеспечивает поиск по дате рождения Patient.birthDate);
в) фильтр поиска по текстовым элементам экземпляра ресурса;
г) параметр, управляющий результатами поиска.
Имена параметров поиска чувствительны к регистру. Параметры применяются в следующем порядке:
а) сначала параметры фильтрации (в произвольном порядке);
б) затем параметр сортировки _sort;
в) затем параметры постраничного вывода;
г) затем параметры включения ссылочных экземпляров ресурсов (_include, _revinclude).
В отсутствие фильтров поиска, например, GET [base], GET [base]/Patient или POST [base]/_search, POST [base]/Patient/_search без указания тела, сервер по возможности должен возвратить все экземпляры ресурсов данного контекста. Если их слишком много, сервер может отклонить запрос, возвратив статус HTTP 413 Payload Too Large, или использовать постраничный вывод с параметрами по умолчанию.
12.26.2 Контекст поиска
Операции поиска выполняются в одном из следующих контекстов:
а) все типы ресурсов: GET [base]?параметры. Если при поиске в этом контексте добавлен параметр _type, то все остальные параметры поиска должны быть общими для всех типов ресурсов, перечисленных в значении этого параметра. Если параметр _type отсутствует, то все параметры поиска должны быть общими для всех типов ресурсов, обрабатываемых данным сервером;
б) конкретный тип ресурса: GET [base]/[type]?параметры.
12.26.3 Результаты поиска
Результаты поиска всегда возвращаются в контейнере Bundle, у которого элемент type имеет значение searchset. Они содержат экземпляры ресурсов и дополнительные метаданные. Структура контейнера результатов поиска показана на рисунке 79.
Параметры поиска, примененные сервером, могут отличаться от тех, что были заданы клиентом. Они возвращаются в элементе Bundle.link, у которого элемент relation имеет значение self.
Контейнер результатов поиска Bundle может содержать записи entry, тип которых определяется значением элемента entry.search.mode:
а) match: содержание элемента entry.resource соответствует фильтрам, указанным в запросе поиска;
б) include: элемент entry.resource содержит ссылочный экземпляр ресурса;
в) outcome: элемент entry.resource содержит экземпляр ресурса OperationOutcome с информацией о выполнении поиска.
12.26.4 Типы параметров поиска
Значения параметров поиска передаются в виде строк, закодированных в соответствии со спецификацией URL-Encoded. На содержание этих строк накладываются дополнительные ограничения в форме типа параметра. Допустимые типы параметров приведены в таблице 355.
Таблица 355
Типы параметров
Тип
Описание
number
Значение параметра должно быть целым или десятичным числом
date
Значение параметра представляет дату или дату и время в стандартном формате XML
string
Значение параметра представляет собой строку символов, которая может содержать пробелы, но не запятые. Совпадающая строка должна начинаться со значения параметра или равняться ему, регистр и диакритические знаки игнорируются
token
Значением параметра является кодированное значение или идентификатор в форме строки или пары "пространство имен|значение"
reference
Значение параметра является ссылкой на другой экземпляр ресурса
composite
Значение параметра представляет собой сочетание нескольких критериев
quantity
Значение параметра представляет физическую величину
uri
Значение параметра представляет URI [27]
special
Специальное значение, состав которого приведен в описании параметра
12.26.5 Модификаторы
Модификаторы параметров поиска изменяют семантику параметров. Например, модифицированный параметр поиска birthdate:missing=true позволяет найти экземпляры ресурса Patient, у которых дата рождения отсутствует.
В запросах поиска модификаторы обозначаются как суффиксы имени параметра поиска в формате [имя]:[модификатор]. К одному параметру поиска может быть применен только один модификатор.
Поскольку модификаторы изменяют семантику параметров поиска, то сервер по возможности должен отклонить запрос поиска, если в нем указан модификатор, не поддерживаемый этим сервером. При отклонении должен быть возвращен код статуса HTTP 400 Bad Request и экземпляр ресурса OperationOutcome с точным описанием причины отклонения.
Возможность применения модификатора к параметру поиска зависит от реализации поиска конкретным сервером. Однако существуют общие ограничения применимости модификатора в зависимости от типа параметра. Например, модификатор exact (точное совпадение) имеет смысл для параметров типа string, но не может быть применен к параметру типа token. Исключение составляют параметры поиска типа special - для каждого такого параметра список допустимых модификаторов индивидуален.
Таблица 356
Модификаторы параметров поиска
Имя
Тип параметра
Описание
above
uri
Значение параметра является продолжением значения элемента типа uri
below
uri
Значение параметра является началом значения элемента типа uri
contains
string, uri
Значение параметра является подстрокой в любом месте значения элемента, на который отображается параметр
exact
string
Значение параметра полностью совпадает со значением элемента, на который отображается параметр (включая регистр и диакритические знаки)
identifier
reference
Значение параметра совпадает со значением компонента identifier ссылочного элемента типа Reference, на который отображается параметр
in
token
Значение элемента, на который отображается параметр, принадлежит заданному набору значений
iterate
-
Параметр поиска означает включение (_include, _revinclude), применяемое к включенному экземпляру ресурса
missing
date, number, quantity, reference, string, token, uri
Присутствие элемента, на который отображается параметр (если значение параметра равно true), или отсутствие этого элемента (если значение параметра равно false)
not
token
Элемент, на который отображается параметр, отсутствует либо его значение не совпадает со значением параметра
text
token
Значение параметра совпадает со значением компонента типа string (CodeableConcept.text, Coding.display, Identifier.type.text или Reference.display) элемента, на который отображается параметр, в соответствии с базовыми правилами (совпадающая строка должна начинаться со значения параметра или равняться ему, регистр и диакритические знаки игнорируются)
Если значением параметра является список, то модификатор применяется к каждому элементу списка.
12.26.6 Префиксы
Префиксы значений параметров используются для параметров типа number, date и quantity, имеющих упорядоченные области значений. Они позволяют избежать применения escape-последовательностей в строке URL и обеспечивают наглядность визуализации.
Допустимые префиксы приведены в таблице 357. При описании префиксов "значение параметра" обозначает значение параметра поиска, а "значение элемента" - значение элемента ресурса, на который отображается параметр.
Таблица 357
Допустимые префиксы значений параметров поиска
Префикс
Описание
Формальное определение
eq
значение элемента равно значению параметра или полностью содержится в нем
диапазон значений параметра полностью содержит диапазон значений элемента
ne
значение элемента не равно значению параметра
диапазон значений параметра не полностью содержит диапазон значений элемента
gt
значение элемента больше значения параметра
диапазон над значением параметра пересекается с диапазоном значений элемента
lt
значение элемента меньше значения параметра
диапазон под значением параметра пересекается с диапазоном значений элемента
ge
значение элемента больше значения параметра или равно ему
диапазон над значением параметра пересекается с диапазоном значений элемента или диапазон значений параметра полностью содержит диапазон значений элемента
le
значение элемента меньше значения параметра или равно ему
диапазон под значением параметра пересекается с диапазоном значений элемента или диапазон значений параметра полностью содержит диапазон значений элемента
sa
значение элемента начинается после значения параметра
диапазон значений параметра не пересекается с диапазоном значений элемента и диапазон над значением параметра содержит диапазон значений элемента
eb
значение элемента заканчивается до значения параметра
диапазон значений параметра не пересекается с диапазоном значений элемента и диапазон под значением параметра содержит диапазон значений элемента
Использование префиксов предполагает, что элемент присутствует и его значение определено. Для поиска элементов с отсутствующими значениями следует использовать модификаторы missing или not.
Префиксы могут использоваться в списках значений параметра, подразумевающих логическое ИЛИ. В этих случаях префикс относится только к значению, которому он предшествует.
По умолчанию предполагается префикс eq. Следует иметь в виду, что применение префиксов отличается от аналогичных математических операций. Префиксы sa (начинается после) и eb (заканчивается до) применимы к десятичным значениям, но не применимы к целым.
Графа "формальное определение" содержит описание префикса в терминах диапазонов, применимых для десятичных значений и дат. Эти диапазоны могут быть явными или подразумеваемыми. Например, десятичное число 2.0 имеет подразумеваемый диапазон значений от 1.95 до 2.05, а для даты 2015-08-12 подразумевается диапазон времени в течение всего дня. У элемента с типом данных Range, Period или Timing диапазон значений задан явно. Варианты диапазонов приведены в таблице 358.
Таблица 358
Варианты диапазонов
Диапазон
Описание
Примеры
Диапазон значений
Определяется точностью представления значения
Число 2.0 имеет диапазон значений от 1.95 до 2.05.
Дата 2015-08-12 имеет диапазон значений от 2015-08-12T00:00:00.0000 включительно до 2015-08-13T00:00:00.0000 исключительно
Диапазон под значением
Множество значений до заданного значения
Диапазон под значением 2.0 включает все значения меньше 2.00000000000000000000.
Диапазон под значением 2015-08-12T05:23:45 включает все значения времени до 2015-08-12T05:23:45.000000000000000
Диапазон над значением
Множество значений после заданного значения
Диапазон над значением 2.0 включает все значения, большие < 2.00000000000000000000.
Диапазон над значением 2015-08-12T05:23:45 включает все значения времени после 2015-08-12T05:23:45.000000000000000
12.26.7 Использование escape-последовательностей в значении параметра поиска
В строке URL запроса поиска символы доллара ($), запятой (,) и вертикальной черты (|) имеют специальное значение. Если эти символы должны присутствовать в значении параметра поиска, то им должен предшествовать символ обратной косой черты (\), который должен предшествовать самому себе. Выражение param=xxx$xxx означает, что параметр имеет тип composite, а param=xx\$xx означает, что параметр имеет строковое значение xx$xx. Выражение param=xx\xx недопустимо, а param=xx\\xx означает, что параметр имеет строковое xx\xx. По запросу GET [base]/Observation?code=a,b должны быть найдены все экземпляры ресурса Observation, у которых элемент code принимает значение "a" или "b", а по запросу GET [base]/Observation?code=a\,b должны быть найдены все экземпляры ресурса Observation, у которых элемент code имеет значение "a,b".
12.26.8 Параметр типа date
Параметр типа date используется для поиска по заданной дате или дате и времени либо по заданному периоду.
Значение параметра типа date должно иметь представление даты и времени ГГГГ-ММ-ДДТЧЧ:ММ:СС.СССС[Z|(+|-)ЧЧ:ММ] (стандартный формат даты и времени в XML). Допускаются также представления с уменьшенной точностью.
Поиск по дате всегда оперирует "диапазонами значений", зависящими от типа данных элемента, на который отображается параметр поиска (таблица 359).
Таблица 359
Диапазоны значений даты и времени
Тип данных
Диапазон значений
date
Диапазон значений день (при полном представлении даты), месяц или год (при представлении даты с уменьшенной точностью)
dateTime
Тот же диапазон, что для типа данных date. Например, дата 2013-01-10 задает все моменты времени от 00:00 10 января 2013 года до 00:00 января 2013 года (исключая этот момент)
instant
Фиксированный момент времени с диапазоном значений, определяемым точностью системного таймера сервера
Period
Явно заданный диапазон, у которого верхняя или нижняя граница может отсутствовать
Timing
Детали расписания игнорируются и учитываются только внешние границы. Например, расписание "через день с 31 января 2013 года по 24 марта 2013 года" попадет в результат поиска по дате 1 февраля 2013 года, хотя эта дата не входит в расписание
Отсутствующая нижняя граница диапазона всегда "раньше" любой фактической даты (даты и времени). Отсутствующая верхняя граница диапазона всегда "позже" любой фактической даты (даты и времени). При поиске по значению параметра типа date могут использоваться префиксы. Примеры совпадений значения элемента со значением параметра приведены в таблице 360.
Таблица 360
Примеры совпадений значения элемента
со значением параметра типа date
Значение параметра
Примеры совпадений значения элемента
[параметр]=eq2013-01-14
2013-01-14T00:00 совпадает (очевидно)
2013-01-14T10:00 совпадает - входит в диапазон
2013-01-15T00:00 не совпадает - не входит в диапазон
[параметр]=ne2013-01-14
2013-01-15T00:00 совпадает - не входит в диапазон
2013-01-14T00:00 не совпадает - входит в диапазон
2013-01-14T10:00 не совпадает - входит в диапазон
[параметр]=lt2013-01-14T10:00
2013-01-14 совпадает, поскольку включает моменты времени до 10:00 14 января 2013 года
Период от 2013-01-13T12:00 до 2013-01-14T12:00 совпадает, поскольку включает моменты времени до 10:00 14 января 2013 года
Период от 2013-01-14T08:00 до 2013-01-15T08:00 совпадает, поскольку включает моменты времени до 10:00 14 января 2013 года
[параметр]=gt2013-01-14T10:00
2013-01-14 совпадает, поскольку включает моменты времени после 10:00 14 января 2013 года
Период от 2013-01-13T12:00 до 2013-01-14T12:00 совпадает, поскольку включает моменты времени после 10:00 14 января 2013 года
Период от 2013-01-14T12:00 до 2013-01-15T12:00 совпадает, поскольку включает моменты времени после 10:00 14 января 2013 года
[параметр]=ge2013-03-14
Период "после 21 января 2013 года" совпадает, поскольку в него попадают моменты времени после 14 марта 2013 года
[параметр]=le2013-03-14
Период "после 21 января 2013 года" совпадает, поскольку в него попадают моменты времени до 14 марта 2013 года
[параметр]=sa2013-03-14
Период "после 15 марта 2013 года" совпадает, поскольку начинается после 14 марта 2013 года
Период "после 21 января 2013 года" не совпадает, поскольку начинается до 14 марта 2013 года
Период "до 21 января 2013 года включительно" не совпадает, поскольку начинается и завершается до 14 марта 2013 года
Период "с 2013-03-13T12:00 до 2013-03-14T12:00" не совпадает, поскольку начинается до 14 марта 2013 года
Период "с 2013-03-14T12:00 до 2013-03-15T12:00" не совпадает, поскольку начинается до завершения суток 14 марта 2013 года
[parameter]=eb2013-03-14
Период "после 15 марта 2013 года" не совпадает, поскольку начинается после 14 марта 2013 года
Период "после 21 января 2013 года" не совпадает, поскольку начинается до 14 марта 2013 года, но не завершается до этой даты
Период "до 21 января 2013 года включительно" совпадает, поскольку завершается до 14 марта 2013 года
Период "с 2013-03-13T12:00 до 2013-03-14T12:00" не совпадает, поскольку завершается после начала суток 14 марта 2013 года
Период "с 2013-03-14T12:00 до 2013-03-15T12:00" не совпадает, поскольку начинается до завершения суток 14 марта 2013 года
При выполнении поиска по дате и времени сервер по возможности должен учитывать часовые пояса. Если значения параметра и значение элемента не содержат часовой пояс, то должен использоваться местный часовой пояс сервера.
12.26.9 Параметр типа number
Параметр типа number используется для поиска по заданному числовому значению.
Примеры совпадений значения элемента со значением параметра приведены в таблице 361.
Таблица 361
Примеры совпадений значения элемента
со значением параметра типа number
Значение параметра
Примеры совпадений значения элемента
[параметр]=100
Совпадает, если равно 100 с точностью до 3 значащих цифр, то есть фактически поиск ведется по отрезку [99.5 ... 100.5])
[параметр]=100.00
Совпадает, если равно 100 с точностью до 5 значащих цифр, то есть фактически поиск ведется по отрезку [99.995 ... 100.005])
[параметр]=1e2
Совпадает, если равно 100 с точностью до 1 значащей цифры, то есть фактически поиск ведется по отрезку [50 ... 150])
[параметр]=lt100
Совпадает, если меньше 100
[параметр]=le100
Совпадает, если меньше или равно 100
[параметр]=gt100
Совпадает, если больше 100
[параметр]=ge100
Совпадает, если больше или равно 100
[параметр]=ne100
Совпадает, если не равно 100 с точностью до 3 значащих цифр (то есть не принадлежит отрезку [99.5 ... 100.5])
Если числовой поиск ведется по элементу ресурса, значение которого является целым числом, и значение параметра поиска не представлено в экспоненциальной форме и не содержит ненулевые цифры после десятичной точки, то правило учета значащих цифр не применяется и поиск ведется по точному совпадению.
При использовании префиксов gt, lt, ge, le, sa и eb неявно определяемая точность игнорируется и значения параметра трактуются как имеющие произвольно высокую точность. При использовании остальных префиксов точность определяется по числу цифр в значении параметра поиска, исключая ведущие нули. Таким образом, 100 и 1.00e2 имеют три значащие цифры.
12.26.10 Параметр типа quantity
Параметр типа quantity используется для поиска по заданному значению физической величины, имеющему следующие форматы:
а) [параметр]={[префикс]}[число] для поиска значения элемента типа Quantity по компоненту value;
б) [параметр]={[префикс]}[число]|[system]|[code] для поиска значения элемента типа Quantity по сочетанию компонентов value, system и code;
в) [параметр]={[префикс]}[число]||[code] поиска значения элемента типа Quantity по сочетанию компонентов value, system и code или unit.
Числовой компонент параметра поиска типа quantity может задаваться как в десятичном, так и в экспоненциальном формате.
Примеры запросов на поиск по значению физической величины приведены в таблице 362.
Таблица 362
Примеры запросов на поиск по значению физической величины
Запрос
Описание
GET [base]/Observation?value-quantity=5.4|http://unitsofmeasure.org|mg
Поиск результатов исследования со значением 5.4(+/- 0.05) mg, где mg - код из системы единиц измерения UCUM (вариант system/code)
GET [base]/Observation?value-quantity=5.40e-3|http://unitsofmeasure.org|g
Поиск результатов исследования со значением 0.0054(+/- 0.00005) g, где g - код из системы единиц измерения UCUM (вариант system/code)
GET [base]/Observation?value-quantity=5.4||mg
Поиск результатов исследования со значением 5.4(+/- 0.05) mg, где единица измерения mg код, указанный в компоненте code (вариант code), или текст, указанный в компоненте unit (вариант unit)
GET [base]/Observation?value-quantity=5.4
Поиск результатов исследования со значением 5.4(+/- 0.05) безотносительно к единице измерения (вариант value)
GET [base]/Observation?value-quantity=le5.4|http://unitsofmeasure.org|mg
Поиск результатов исследования со значением, меньшим или равным 5.4 mg, где mg - код из системы единиц измерения UCUM (вариант system/code)
12.26.11 Параметр типа reference
Параметр типа reference используется для поиска по ссылке на экземпляр ресурса, используя следующие варианты:
а) [параметр]=[id] - поиск по логическому идентификатору [id] экземпляра ресурса (относительная ссылка);
б) [параметр]=[type]/[id] - поиск по логическому идентификатору [id] экземпляра ресурса (относительная ссылка, в которой могут быть указаны разные типы ресурсов);
в) [параметр]=[url] - поиск по абсолютному или каноническому URL.
Если относительная ссылка разрешается тем же самым адресом, что и абсолютный URL, то при поиске она считается совпадающей с абсолютным URL. Например, при запросе
GET http://example.org/fhir/Observation?subject=Patient/123
должны быть найдены экземпляры ресурса Observation, у которых элемент subject.reference имеет следующие значения:
а) Patient/123 - точное совпадение со значением параметра поиска;
б) http://example.org/fhir/Patient/123 - значение параметра поиска неявно разрешается этим URL по базовому URL сервера.
Аналогично при запросе
GET http://example.org/fhir/Observation?subject=http://example.org/fhir/Patient/123
должны быть найдены экземпляры ресурса Observation, у которых элемент subject.reference имеет следующие значения:
а) http://example.org/fhir/Patient/123 - точное совпадение со значением параметра поиска;
б) Patient/123 - значение элемента неявно разрешается значением параметра поиска по базовому URL сервера.
При запросе без указания типа ресурса
GET http://example.org/fhir/Observation?subject=123
должны быть найдены экземпляры ресурса Observation, у которых элемент subject.reference имеет следующие значения:
а) Patient/123 - относительный URL экземпляра ресурса Patient;
б) http://example.org/fhir/Patient/123 - абсолютный URL экземпляра ресурса Patient с базовым URL запроса;
ИС МЕГАНОРМ: примечание.
Нумерация пунктов дана в соответствии с официальным текстом документа.
а) Practitioner/123 - относительный URL экземпляра ресурса Practitioner;
б) http://example.org/fhir/Practitioner/123 - абсолютный URL экземпляра ресурса Practitioner с базовым URL запроса;
в) и др.
Некоторые ссылки могут указывать на экземпляры ресурсов нескольких типов, например, элемент Observation.subject может содержать ссылки на экземпляры ресурсов Patient, Group, Device, Location, Organization, Procedure, Practitioner, Medication, Substance, BiologicallyDerivedProduct, NutritionProduct. При этом экземпляры ресурсов разных типов могут иметь одинаковые логические идентификаторы id. Если по заданному значению параметра поиска найдены экземпляры ресурсов нескольких типов, то сервер по возможности должен отклонить такой запрос. Поэтому рекомендуется указывать тип ссылочного экземпляра ресурса в запросе, например:
GET [base]/Observation?subject:Patient/23.
В ряде случаев ограничение типа ссылочного ресурса присутствует в определении параметра поиска. Например, для ресурса Observation определен параметр поиска subject, отображаемый на элемент Observation.subject и допускающий ссылки на экземпляры ресурсов нескольких типов. Наряду с ним определен параметр поиска patient, который также отображается на элемент Observation.subject, но при этом допускает ссылки только на экземпляры ресурса Patient.
Параметры поиска типа reference могут иметь модификатор identifier. В этом случае поиск осуществляется по компоненту identifier ссылки. Например, по запросу
GET [base]/Observation?subject:identifier=http://acme.org/fhir/identifier/mrn|123456
будет осуществлен поиск результатов исследований, у которых элемент subject.identifier.system = http://acme.org/fhir/identifier/mrn, а subject.identifier.value = 123456.
12.26.12 Параметр типа string
Параметр типа string используется для поиска по строковым значениям элементов. При поиске игнорируются регистр и диакритические символы. По умолчанию считается, что значение параметра типа string совпадает со значением элемента, если значение элемента начинается со значения параметра или равно ему (после нормализации регистра обоих значений и удаления диакритических символов. При применении модификатора contains поиск успешен, если значения параметра содержится в любом месте значения элемента. При применении модификатора exact поиск успешен, если значение параметра идентично значению элемента (с учетом регистра и диакритических символов).
Если параметр типа string отображается на элемент с комплексным типом данных (содержащим компоненты), то поиск значения параметра должен осуществляться по каждому компоненту типа string. Например, параметр name отображается на элемент Patient.name типа HumanName, содержащий строковые компоненты text, family, given, prefix, suffix. Тогда для успеха поиска по значению параметра name достаточно, чтобы был успешен поиск хотя бы по одному из этих компонентов.
Для ограничения поиска фамилией определен параметр поиска family, отображенный на элемент Patient.name.family.
12.26.13 Параметр типа token
Параметры типа token в основном используются для поиска по элементам, содержащим кодированные значения или идентификаторы. Такие элементы имеют компонент system, идентифицирующий систему кодирования или схему идентификации, и компонент code (код) или value (идентификатор), и поиск ведется по сочетанию этих компонентов. Параметры типа token используются также для поиска по элементам, имеющим типы данных uri, boolean, ContactPoints, id, когда требуется точное совпадение значения параметра со значением элемента.
Значения параметров типа token могут иметь следующие форматы:
а) [параметр]=[code] - значение [code] совпадает с компонентом Coding.code или Identifier.value безотносительно к значению компонента Coding.system или Identifier.system;
б) [параметр]=[system]|[code] - значение [code] совпадает с компонентом Coding.code или Identifier.value, а значение [system] совпадает с компонентом Coding.system или Identifier.system соответственно;
в) [параметр]=|[code] - значение [code] совпадает с компонентом Coding.code или Identifier.value, а компоненты Coding.system или Identifier.system отсутствуют;
г) [параметр]=[system]| - любой элемент, у которого значение [system] совпадает с компонентом Coding.system или Identifier.system.
Для поиска по значениям элементов, имеющих тип данных id, ContactPoint, uri или boolean, допустим только формат [параметр]=[code].
Применение параметров типа token в зависимости от типа данных элемента представлено в таблице 363.
Таблица 363
Применение параметров типа token
в зависимости от типа данных элемента
Тип данных
Компонент system
Компонент code
Примечание
Coding
Coding.system
Coding.code
-
CodeableConcept
CodeableConcept.coding.system
CodeableConcept.coding.code
Для успешного поиска достаточно совпадения хотя бы с одним экземпляром элемента CodeableConcept.coding
Identifier
Identifier.system
Identifier.value
-
ContactPoint
не применим
ContactPoint.value
-
code
подразумеваемый
code
Компонент system определен в привязке элемента к набору значений, но по факту не используется
boolean
подразумеваемый
boolean
Для значений типа boolean подразумевается система кодирования http://terminology.hl7.org/CodeSystem/special-values, но по факту не используется
id
не применим
id
-
uri
не применим
uri
-
string
не применим
string
Иногда параметры типа token отображаются на элементы типа string, чтобы указать поиск по точному совпадению с учетом регистра
Примеры запросов поиска с параметрами типа token приведены в таблице 364.
Таблица 364
Примеры запросов поиска с параметрами типа token
Запрос
Описание
GET [base]/Patient?identifier=http://acme.org/patient|2345
Поиск пациентов с идентификатором 2345 в схеме идентификации http://acme.org/patient
GET [base]/Patient?gender=male
Поиск пациентов с кодом пола male
GET [base]/Patient?gender:not=male
Поиск пациентов, у которых код пола не равно male или отсутствует
GET [base]/Composition?section=48765-2
Поиск медицинских документов, содержащих раздел "Аллергии и побочные реакции" (код 48765-2 в системе кодирования LOINC http://loinc.org)
GET [base]/Composition?section:not=48765-2
Поиск медицинских документов, не содержащих раздел "Аллергии и побочные реакции" (код 48765-2 в системе кодирования LOINC http://loinc.org). Следует иметь в виду, что этот запрос нельзя трактовать как "документ, имеющий раздел, отличающийся от "Аллергии и побочные реакции", поскольку отрицание not применяется к коллекции значений section.code, а не к отдельному экземпляру
GET [base]/Patient?active=true
Поиск активных пациентов
GET [base]/Condition?code=http://acme.org/condtions/codes|ha125
Поиск состояний с кодом ha125 в системе кодирования http://acme.org/conditions/codes
GET [base]/Condition?code=ha125
Поиск состояний с кодом ha125 безотносительно к системе кодирования
GET [base]/Condition?code:text=Головная боль
Поиск состояний, у которых текстовый компонент элемента code (text или display) имеет значение "Головная боль"
12.26.14 Параметр типа uri
Параметр типа uri используется для поиска по значениям элементов с типом данных uri и url, содержащих идентификаторы URI [27]. Значение параметра должно полностью совпадать со значением элемента с учетом регистра и диакритических знаков. Для поиска с частичным совпадением используются модификаторы above или below. В следующих примерах параметр url имеет тип uri:
GET [base]/ValueSet?url=http://hl7.org/fhir/ValueSet/example-filter
GET [base]/ValueSet?url:below=http://hl7.org/fhir/ValueSet
GET [base]/ValueSet?url:above=http://hl7.org/fhir/ValueSet/example-filter/_history/1
GET [base]/ValueSet?url=urn:oid:1.2.3.4.5
Первый запрос означает поиск наборов значений ValueSet, у которых элемент url имеет значение http://acme.org/fhir/ValueSet/123.
Второй запрос означает поиск наборов значений ValueSet, у которых элемент url начинается со значения http://acme.org/fhir/.
В третьем запросе указано обратное условие: значение элемента url должно быть началом значения параметра запроса.
В четвертом запросе указан поиск по объектному идентификатору. Модификаторы above или below применимы только к адресам URL, но не идентификаторам URN, примером которых служит объектный идентификатор.
12.26.15 Параметры типа special
Некоторые параметры имеют тип special (особые). Способ использования каждого такого параметра уникален. К числу особых параметров относятся:
а) _filter (применим ко всем типам ресурсов);
б) section-text (применим к ресурсу Composition);
в) contains (применим к ресурсу Location);
г) near (применим к ресурсу Location).
12.26.16 Параметр типа composite
Значение параметра типа composite представляет собой сочетание нескольких критериев, накладываемых на компоненты элемента комплексного типа. В качестве разделителя используется знак доллара ($). Например, запрос
GET [base]/ Observation?component-code-value-quantity=http://www.radlex.org| RID49679$le1.7
означает поиск экземпляров ресурса Observation, у которых компонент code элемента component имеет значение RID49679 в системе кодирования http://www.radlex.org и компонент value имеет значение, меньшее или равное 1.7.
Модификаторы не применимы к параметрам типа composite.
Примеры запросов поиска с параметрами типа composite приведены в таблице 365.
Таблица 365
Примеры запросов поиска с параметрами типа composite
Запрос
Описание
GET [base]/DiagnosticReport?result.code-value-quantity=http://loinc.org|2823-3$gt5.4|http://unitsofmeasure.org|mmol/L
Поиск протоколов, содержащих результат исследования калия в крови выше 5.4 mmol/L (код единицы измерения в системе UCUM)
GET [base]/Observation?component-code-value-quantity=http://loinc.org|8480-6$lt60
Поиск результатов исследований, содержащих систолическое давление, меньшее 60. В качестве единиц измерения подразумевается код mmHg в системе UCUM (миллиметры ртутного столба)
GET [base]/Group?characteristic-value=gender$mixed
Поиск групп, у которых характеристика gender (пол) имеет текстовой значение mixed (смешанный)
GET [base]/Questionnaire?context-type-value=focus$http://snomed.info/sct|408934002
Поиск заполненных опросников с основной темой "Профилактика потребления психоактивных веществ" (код 408934002 в номенклатуре медицинских терминов SNOMED CT)
12.27 Простые варианты поиска
12.27.1 Общие требования
В простом запросе поиска выделяются следующие компоненты:
а) значение параметра, с которым осуществляется сравнение,
б) тип сравнения;
в) нуль, одно или несколько значений, выделяемых из содержания экземпляра ресурса.
Например, поиск экземпляров ресурса Patient с параметром запроса given=value представляет собой запрос к серверу на сравнение значения имени пациента со значением параметра поиска value, используя сравнение строк по умолчанию.
Значения параметров поиска разбираются на компоненты в соответствии с типом параметра.
Способ сравнения определяется типом параметра поиска, модификатором или префиксом. Например, для параметра поиска типа number по умолчанию используется равенство, то есть "{значение элемента} равно {значение параметра поиска})". Модификатор изменяет способ сравнения, к примеру, модификатор not изменяет равенство на его отрицание, а именно, "не({значение элемента} равно {значение параметра поиска})". Наконец, префикс можно использовать для отношений типа "больше", то есть "{значение элемента} равно {значение параметра поиска})". В простом запросе не допускается указание модификатора одновременно с префиксом.
12.27.2 Совпадение и кратность
Многие элементы ресурсов определены как массивы (коллекции) значений. Например, у пациента может быть несколько имен или адресов. Совпадение значения параметра поиска с коллекцией значений считается успешным, если оно имеет место хотя бы с одним экземпляром в составе коллекции. Например, если экземпляр ресурса Patient содержит два экземпляра элемента name, то совпадение считается успешным, если значение параметра совпало хотя бы с одним из них.
12.27.3 Совпадение и субэлементы
Если параметр поиска отображается на элемент с комплексным типом данных (то есть элемент содержит субэлементы), то по умолчанию сравнение значения параметра со значением этого элемента интерпретируется как сравнение с одним или несколькими значениями субэлементов соответствующего типа.
12.27.4 Соединение параметров поиска операторами И и ИЛИ
Параметры поиска могут соединяться операторами И и ИЛИ. Соединение ИЛИ означает объединение найденных множеств, соединение И - пересечение. Соединения осуществляются на уровне экземпляров ресурсов и порядок параметров поиска не имеет значения.
Если в запросе указаны несколько параметров поиска, то они используются для получения пересечения результатов поиска по отдельным параметрам, то есть соединяются с помощью оператора И. При этом параметр поиска с одним и тем же именем может быть указан более одного раза.
Для объединения найденных множеств, то есть соединения с помощью оператора ИЛИ, в параметре поиска следует указать список значений, разделенных запятыми (,). Каждое значение в этом списке может иметь собственный префикс. Например, по запросу
GET [base]/Observation?code=http://loinc.org|8867-4&value-quantity=lt60,gt100
должны быть возвращены результаты измерений частоты сердечных сокращений (код 8867-4 в системе кодирования LOINC), которые имеют значения ниже 60 или выше 100, то есть за пределами нормы для взрослого человека.
Если к параметру поиска применен модификатор, то его действие распространяется на все значения в списке. Например, по запросу
GET [base]/Patient?given:exact=Михаил,Петр
должны быть возвращены экземпляры ресурса Patient, у которых хотя бы один экземпляр элемента given в точности равен "Михаил" или "Петр". В отсутствие модификатора могут быть возвращены также экземпляры ресурса Patient, у которых второй экземпляр элемента given, в котором передается отчество или второе имя, имеет значение "Петрович".
В одном запросе могут быть указаны соединения параметров поиска как с операторами И, так и операторами ИЛИ. Но при этом отсутствует стандартная возможность соединения разноименных параметров поиска с помощью ИЛИ. Для объединения результатов запросов по разноименным параметрам можно выполнить последовательность запросов или передать несколько запросов в одном контейнере пакета Bundle, у которого элемент type имеет значение batch.
12.27.5 Поиск по идентификаторам
12.27.5.1 Общие требования
Ресурс может иметь идентификаторы нескольких типов: логический идентификатор id типа id, бизнес-идентификаторы типа Identifier или канонический url типа canonical. Особенности поиск по идентификаторам этих типов представлены в следующих подпунктах.
12.27.5.2 Логические идентификаторы
Логический идентификатор id экземпляра ресурса служит уникальным ключом этого экземпляра в конкретном контексте (в хранилище экземпляров ресурсов данного типа на сервере, внутри контейнера Bundle). Для поиска по логическому идентификатору используется параметр поиска _id.
Поскольку логический идентификатор уникален в контексте поиска, то поиск по нему всегда возвращает нуль или один экземпляр ресурса. Это функционально эквивалентно простой операции чтения со следующими отличиями:
а) если экземпляр ресурса с таким логическим идентификатором существует и может быть возвращен, то результатом запроса будет не сам экземпляр, а контейнер результатов поиска Bundle, в который вложен этот экземпляр;
б) если экземпляр ресурса с таким логическим идентификатором не существует или не может быть возвращен, то результатом поиска также будет контейнер результатов поиска Bundle, в который может быть вложен экземпляр ресурса OperationOutcome с описанием причины отсутствия результата;
в) в контейнере результатов поиска Bundle могут быть возвращены дополнительные ссылочные экземпляры ресурсов;
г) поиск может быть ограничен дополнительными параметрами.
12.27.5.3 Идентификаторы типа Identifier и ссылки типа Reference
Обычно в составе ресурса присутствует единственный элемент identifier типа Identifier с кратностью 0..*. Для таких типов ресурса определен одноименный параметр поиска identifier типа token.
В ссылках типа Reference на экземпляр ресурса нередко присутствует компонент identifier со значением идентификатора ссылочного ресурса. Если для такой ссылки определен параметр поиска, то можно осуществить поиск по значению этого компонента, используя модификатор identifier. Например, по запросу
GET [base]/Patient?general-practitioner:identifier=urn:oid:1.2.643.100.3|12345678901
должны быть найдены все пациенты участкового врача со СНИЛС 12345678901.
12.27.5.4 Канонические идентификаторы типа canonical
Ресурсы, называемые каноническими, например, CodeSystem (система кодирования) и ValueSet (набор значений), имеют особую (каноническую) схему идентификации, дополняющую логический идентификатор id и бизнес-идентификаторы identifier. В их структуре присутствуют следующие элементы:
а) url типа uri - глобально уникальный идентификатор типа URI (URL или UUID);
б) version типа string - бизнес-версия содержания.
В отличие от версии экземпляра ресурса meta.versionId, присваиваемой сервером автоматически при создании или изменении экземпляра, бизнес-версия присваивается издателем содержания экземпляра канонического ресурса. Рекомендуется использовать схему присваивания Semantic Versioning 2.0.0 (https://semver.org), согласно которой номер бизнес-версии состоит из трех номеров в формате Главный.Младший.Исправление, которые последовательно увеличиваются по следующим правилам:
а) главный номер увеличивается, если содержание стало обратно несовместимым;
б) младший номер увеличивается, если добавлена новая функциональность, но содержание осталось обратно совместимым;
в) номер исправления увеличивается при исправлении ошибок содержания, не влияющих на обратную совместимость.
Ссылка на экземпляр канонического ресурса имеет тип canonical, а не Reference. Ее значение имеет следующие форматы:
а) <url экземпляра>;
б) <url экземпляра>|<номер бизнес-версии>.
Первый формат означает ссылку на последнюю (текущую) бизнес-версию экземпляр канонического ресурса, второй - ссылку на экземпляр с заданной версией.
Параметры поиска по элементам типа canonical имеют тип reference.
12.27.6 Сцепленный поиск
Для уменьшения числа операций запроса ссылочные параметры могут быть "сцеплены" с помощью добавления имени параметра поиска целевого ресурса ссылки с использованием точки (,) в качестве разделителя. Это можно делать рекурсивно, следуя по логическому пути в графе связей экземпляров ресурсов. К примеру, для ресурса DiagnosticReport (протокол исследования) определен параметр поиска subject. Соответствующий ему элемент DiagnosticReport.subject обычно содержит ссылку на экземпляр ресурса Patient, при этом для ресурса Patient определен параметр поиска name, отображаемый на элемент Patient.name. Тогда по запросу
GET [base]/DiagnosticReport?subject.name=иван
должны быть возвращены все протоколы, в которых элемент name субъекта исследования содержит "иван" (с начала элемента либо его компонентов, без учета регистра). Поскольку элемент DiagnosticReport.subject может содержать ссылку на разные типы ресурсов, то можно ограничить сцепленный поиск ресурсом определенного типа. Например, по запросу
GET [base]/DiagnosticReport?subject:Patient.name= иван
должны быть возвращены все протоколы, в которых субъектом является пациент и элемент Patient.name субъекта исследования содержит "иван".
Несмотря на то, что в простых запросах разделитель & означает логическое И, его использование между сцепленными параметрами поиска означает логическое ИЛИ, то есть сцепленные параметры поиска применяются не последовательно, а параллельно. По запросу
GET [base]/DiagnosticReport?subject:Patient.name=иван&subject:Patient.birthday=1970
должны быть возвращены все протоколы исследований пациентов, в которых компоненты именования пациента начинаются с "иван", и все протоколы исследований пациентов с годом рождения 1970.
К параметрам, участвующим в сцеплении, не должны применяться модификаторы.
12.27.7 Обратное сцепление
Параметр _has предоставляет ограниченные возможности обратного сцепления, то есть поиска экземпляров ресурсов по свойствах экземпляров ресурсов, которые на них ссылаются. Например, по запросу
GET [base]/Patient?_has:Observation:patient:code=1234-5
должны быть возвращены экземпляры ресурса Patient, на которые есть ссылки из экземпляров ресурса Observation с кодом исследования 1234-5.
Значения параметра _has могут задаваться списком, означающим логическое ИЛИ (например, _has:Observation:patient:code=123,456). Параметр _has может быть указан несколько раз (к примеру, _has:Observation:patient:code=123&_has:Observation:patient:code=456). Хотя разделитель & означает логическое И, его использование между параметрами поиска _has означает логическое ИЛИ, то есть параметры _has применяются не последовательно, а параллельно.
Параметры _has могут быть вложенными. Например, по запросу
GET [base]/Patient?_has:Observation:patient:_has:AuditEvent:entity:agent=UserId
должны быть возвращены экземпляры ресурса Patient, на которые есть ссылки из экземпляров ресурса Observation, являющихся целями ссылок из экземпляров ресурса AuditEvent (регистрируемое событие), у которых элемент agent (участник события) имеет идентификатор UserId.
Параметр _has может использоваться внутри сцепления. По запросу
GET [base]/Encounter?patient._has:Group:member:_id=102
должны быть возвращены экземпляры ресурса Encounter (случай медицинской помощи), относящиеся к пациентам, входящим в группу с идентификатором 102.
К параметрам, участвующим в обратном сцеплении, не должны применяться модификаторы.
12.28 Обработка ошибок
Если сервер не в состоянии выполнить запрос, он может возвратить код статуса HTTP, идентифицирующий ошибку, или может возвратить код статуса HTTP 200 OK и контейнер результата запроса Bundle, в который вложен экземпляр ресурса OperationOutcome, содержащий сведения об ошибке. Код статуса HTTP 403 Forbidden означает, что сервер отказывается выполнить запрос, а другие коды 4xx или коды 5xx означают наличие ошибки какого-либо рода. Если запрос не выполнен, сервер по возможности должен возвратить экземпляр ресурса OperationOutcome, детализирующий причину. Пустой результат запроса ошибкой не является.
12.29 Неподдерживаемые параметры
Сервер может получить запрос с параметрами, которые он не распознает или не поддерживает (вообще или в данном запросе). В общем случае сервер по возможности должен игнорировать неизвестные или неподдерживаемые параметры, поскольку различные компоненты стека HTTP и прокси могут добавить к запросу параметры, которые клиент не в состоянии контролировать. Клиент может определить фактически примененные параметры, анализируя компонент url элемента link контейнера результата запроса Bundle, у которого компонент relation имеет значение self.
Клиент может указать серверу вариант обработки таких параметров с помощью заголовка HTTP Prefer:
а) Prefer: handling=strict означает требование возвращения ошибки при получении неизвестного или неподдерживаемого параметра;
б) Prefer: handling=lenient означает требование игнорирования неизвестного или неподдерживаемого параметра.
Сервер по возможности должен выполнить такое требования, не обязан это делать.
12.30 Стандартные параметры
Для всех типов ресурсов определены стандартные параметры поиска, приведенные в таблице 366.
Таблица 366
Стандартные параметры поиска
Имя
Тип
Описание
Путь
_content
string
Текстовый поиск по всему содержанию экземпляра ресурса
-
_filter
special
Параметр, предоставляющий более содержательную грамматику поиска
-
_has
special
Ограниченная поддержка обратного сцепленного поиска
-
_id
token
Логический идентификатор ресурса id (не полный URL)
Resource.id
_in
reference
Принадлежность к группе, представленной экземпляром ресурса Group, List или CareTeam
Resource.id
_language
token
Основной язык содержания экземпляра ресурса
Resource.language
_lastUpdated
date
Дата и время последнего изменения содержания экземпляра ресурса
Resource.meta.lastUpdated
_list
string
Все экземпляры ресурсов, идентификаторы id которых перечислены в данном списке
-
_profile
reference
Поиск экземпляров ресурсов с данным значением профиля meta.profile
Resource.meta.profile
_query
string
Пользовательский именованный запрос
-
_security
token
Поиск по значению категории доступа meta.security
Resource.meta.security
_source
uri
Поиск по источнику содержания экземпляра ресурса meta.source
Resource.meta.source
_tag
token
Поиск по тегу метаданных meta.tag
Resource.meta.tag
_text
string
Текстовый поиск по повествовательному содержанию экземпляра ресурса
-
12.31 Управление результатами запроса
12.31.1 Общие требования
Для управления результатами запроса на поиск экземпляров ресурса используются параметры, перечисленные в таблице 367.
Таблица 367
Параметры управления результатами поиска
Имя
Тип
Описание
Допустимое значение
_count
number
Число экземпляров ресурсов на одной странице (при постраничном выводе результатов запроса)
Неотрицательное целое число
_elements
token
Список элементов ресурса, которые должны быть возвращены в теле ответа. Обязательные элементы возвращаются, даже если не указаны в этом перечислении
-
_include
string
Включение в результат поиска ссылочных экземпляров
SourceType:searchParam(:targetType)
_maxresults
number
Максимальное число возвращаемых результатов поиска
Неотрицательное целое число
_offset
number
Число пропускаемых экземпляров ресурса (при постраничном выводе результатов запроса)
Неотрицательное целое число
_revinclude
string
Включение в результат поиска экземпляров ресурсов, содержащих ссылки на найденные экземпляры
SourceType:searchParam(:targetType)
_score
token
Добавление оценки релевантности запросу
true | false
_sort
string
Сортировка результатов поиска
Имя параметра поиска, допустимого для данного ресурса. Для сортировки по убыванию перед именем параметра должен быть указан знак минуса (-)
_summary
string
Возвращение элементов краткого содержания (для ресурсов, где они определены)
true | false (по умолчанию) text | data | count
_total
token
Точность подсчета общего числа результатов поиска
none | estimate | accurate
За исключением параметров _include и _revinclude, параметры управления результатами поиска должны присутствовать в единственном экземпляре. Сервер может управлять результатами поиска в соответствии с первым экземпляром параметра или выдать сообщение об ошибке.
12.31.2 Параметр _sort (сортировка)
Параметр _sort задает сортировку найденных экземпляров ресурса внутри контейнера Bundle. Его значение представляет собой список параметров поиска, по которым должна выполняться сортировка. Параметры перечисляются через запятую в порядке уровня сортировки. Например, по запросу
GET [base]/Observation?_sort=status,-date,category
должен быть возвращен контейнер результатов запроса Bundle, в котором найденные экземпляры ресурса Observation отсортированы в порядке возрастания статуса (лексикографически), затем в порядке убывания даты исследования, затем по категории исследования. Префикс '-' перед именем параметра поиска означает сортировку по убыванию.
Сортировка по параметрам поиска типа string по возможности должна выполняться без учета регистра.
В тех случаях, когда указана сортировка по параметру поиска типа date, отображаемому на элемент комплексного типа (например, Period), способ сортировки оставляется на усмотрение сервера. Например, сортировка может осуществляться по началу периода, указанному в компоненте start.
12.31.3 Параметр _total (общее число найденных экземпляров ресурса)
Общее число найденных экземпляров ресурса может возвращаться в элементе total контейнера результатов запроса Bundle. В это число не входят экземпляры добавленных ссылочных ресурсов.
Подсчет точного числа найденных экземпляров ресурса может создавать существенную нагрузку для сервера. Для управления подсчетом клиент может указать в запросе параметр _total, допустимые значения которого перечислены в таблице 368.
Таблица 368
Допустимые значения параметра _total
Значение
Описание
none
Подсчет найденных экземпляров ресурса не требуется
estimate
Достаточна грубая оценка числа найденных экземпляров ресурса
accurate
Требуется точное число найденных экземпляров ресурса
Сервер может игнорировать параметр _total или какие-либо из его значений.
12.31.4 Параметры _count (размер страницы вывода) и _offset (смещение от начала вывода)
Использование параметров _count и _offset для управления постраничным выводом результатов запроса описано в подразделе 12.22.
Для возвращения наиболее позднего экземпляра ресурса, удовлетворяющего заданным критериям, может использоваться сочетание параметров _sort и _count. Для этого в запросе поиска по этим критериям можно задать сортировку по дате изменения в порядке обратной хронологии и указать _count=1.
12.31.5 Параметр _maxresults (максимальное число возвращаемых результатов поиска)
Параметр _maxresults задает максимальное число возвращаемых результатов поиска. Если сервер поддерживает применение этого параметра, то он должен возвратить его в компоненте url элемента link контейнера результатов поиска Bundle, у которого компонент relation имеет значение self.
Значение параметра _maxresults не оказывает никакого влияния на значение элемента Bundle.total, поскольку этот элемент содержит общее число экземпляров ресурса, удовлетворяющих критериям поиска.
Использование параметра _maxresults не отменяет постраничный вывод. Например, в запросе можно указать _maxresults=10&_count=5 для ограничения вывода до двух страниц по пять результатов на каждой.
12.31.6 Параметр _summary (возвращение элементов краткого содержания)
Параметр _summary задает подмножество элементов ресурса, которые должны быть возвращены в контейнере результатов поиска Bundle. Допустимые значения параметра _summary приведены в таблице 369.
Таблица 369
Допустимые значения параметра _summary
Значение
Описание
true
Возвращение подмножества элементов, помеченных как summary в определении ресурса (см. описание элемента ElementDefinition.isSummary в таблице 126)
text
Возвращение только человеко-читаемого значения элемента text, логического идентификатора id, метаданных meta и обязательных элементов верхнего уровня
data
Возвращение всего содержания, кроме элемента text
count
Возвращение только общего числа найденных экземпляров ресурса
false
Возвращение всех элементов экземпляров ресурса
Сервер не обязан возвращать результаты в соответствии с заданным значением параметра _summary. Следует иметь в виду, что сокращенное содержание экземпляра ресурса может быть не пригодно для использования во взаимодействии изменения update. Сервер по возможности должен передать элемент meta.tag со значением SUBSETTED в качестве признака сокращенного содержания.
Поскольку для интерпретации результатов поиска важно знать фактически примененные параметры, то независимо от значения параметра _summary в контейнере результатов поиска Bundle должен быть возвращен элемент link, у которого компонент relation имеет значение self.
Параметры _include и _revinclude не могут быть указаны, если _summary=text.
12.31.7 Параметр _score (добавление оценки релевантности запросу)
Параметр _score используется для добавления оценки релевантности запросу при недетерминированном поиске. Допустимые значения параметра _score приведены в таблице 370.
Таблица 370
Допустимые значения параметра _score
Значение
Описание
true
Добавлять оценку релевантности запросу
false
Не добавлять оценку релевантности запросу (по умолчанию)
Пример оценки релевантности запросу приведен в подразделе 12.32.
12.31.8 Параметр _elements (вывод заданных элементов ресурса)
В параметре _elements перечисляются имена верхнеуровневых элементов ресурса, которые должны быть возвращены в теле ответа. Каждое имя должно быть базовым, без указания признака варианта типа данных [x]. Например, имя value допустимо, а имена value[x] и valueQuantity - нет.
Сервер по возможности должен возвратить запрошенные элементы содержания, логический идентификатор id, а также обязательные элементы, отсутствующие в списке, и элемент meta.tag со значением SUBSETTED в качестве признака сокращенного содержания.
Если элементы, перечисленные в значении параметра _elements, имеют префикс типа ресурса, например, _elements=Patient.gender, то сервер по возможности должен распространить ограничение на возвращаемые элементы на все экземпляры ресурсов, вложенные в контейнер результата поиска Bundle, в том числе на включенные ссылочные экземпляры.
12.31.9 Параметры _include и _revinclude (включение ссылочных экземпляров ресурсов)
Наряду с экземплярами ресурса, удовлетворяющими критериям поиска, в результат поиска могут быть включены ссылочные экземпляры ресурсов. Например, в дополнение к найденным экземплярам ресурса Observation, содержащим результаты исследований, в результат поиска могут быть включены экземпляры ресурса Patient, идентифицирующие субъектов этих исследований.
Параметр _include используется для включения экземпляров ресурсов по ссылкам, содержащимся в найденных экземплярах (прямые ссылки). Параметр _revinclude используется для включения экземпляров ресурсов, ссылающихся на найденные экземпляры (обратные ссылки).
Значение этих параметров состоят из двух или трех компонентов, разделенных двоеточием (:).
[_include|_revinclude]=[ресурс]:где [ресурс] - тип ресурса, а символ * (звездочка) указывает все параметры поиска типа reference, поддерживаемые сервером для этого типа ресурса и параметров _include или _revinclude. Список этих параметров может не совпадать с общим списком параметров типа reference, поддерживаемые сервером для этого типа ресурса.
[_include|_revinclude]=[ресурс]:[параметр]
где [ресурс] - тип ресурса, а [параметр] - параметр поиска типа reference.
[_include|_revinclude]= [ресурс]:[параметр]:[целевой тип]
где [ресурс] - тип ресурса, [параметр] - параметр поиска типа reference, а [целевой тип] - целевой тип ресурса.
Параметры _include и _revinclude не могут иметь список значений, но могут повторяться с разными значениями в одном запросе поиска.
Добавленный экземпляр ресурса содержится в отдельной записи entry контейнера результата поиска Bundle. При этом элемент entry.search.mode имеет значение include, чтобы отличить добавленный экземпляр от найденного.
Для добавления ссылочных экземпляров ресурсов к уже добавленным экземплярам используется дополнительный параметр _include или _revinclude с модификатором iterate.
Например, по запросу
GET [base]/DiagnosticReport?_include=DiagnosticReport:result&_include:iterate=Observation:encounter
должны быть возвращены найденные экземпляры ресурса DiagnosticReport, экземпляры ресурса Observation, на которые ссылаются элементы DiagnosticReport.result, и экземпляры ресурса Encounter, на которые ссылаются элементы Observation.encounter добавленных экземпляров ресурса Observation. (В данном случае имена параметров поиска, указанных в параметрах _include, совпадают с именами соответствующих им элементов.)
Возможность использования модификатора iterate и предельная глубина вложенности параметров _include или _revinclude определяется сервером для каждого типа ресурса.
12.32 Соответствие результата запросу
Если поиск не является детерминированным, то алгоритм поиска может генерировать показатель соответствия найденного экземпляра ресурса критериям поиска. Эта оценка возвращается в элементе entry.score, например:
"entry": {
"score": 0.45,
"resource": {
"resourceType": "Patient",
... patient data ...
}
}
Оценка представляет собой десятичное число между 0 и 1, где 1 - точное соответствие, а 0 - отсутствие соответствия.
12.33 Именованный поиск
Параметр _query идентифицирует именованную операцию, реализующую особую логику поиска. Для нее могут быть определены дополнительные параметры.
Именованные запросы разрешены в контексте системы или типа ресурса. Они не могут быть определены на уровне экземпляра ресурса.
При использовании именованного запроса по возможности должны быть доступны все стандартные параметры поиска, описанные в подразделе 12.30. Если именованный запрос определен для типа ресурса, то по возможности должны быть доступны специальные параметры поиска, определенные для этого типа.
Для определения именованного запроса используется экземпляр ресурса OperationDefinition, например:
<?xml version="1.0" encoding="UTF-8"?>
<OperationDefinition xmlns="http://hl7.org/fhir">
<!-- Определение именованного запроса current-high-risk -->
<id value="current-high-risk" />
<url value="http://example.org/OperationDefinition/current-high-risk" />
<version value="0.0.1" />
<name value="Пациенты палат интенсивной терапии" />
<status value="draft" />
<kind value="query" />
<description value=Поиск пациентов по палатам интенсивной терапии />
<code value="current-high-risk" />
<resource value="Patient" />
<system value="false" />
<type value="true" />
<instance value="false" />
<!-- Входной параметр -->
<parameter>
<name value="ward" />
<use value="in" />
<min value="0" />
<max value="*" />
<documentation value="Идентификатор палаты интенсивной терапии" />
<type value="string" />
<searchType value="reference" />
</parameter>
<!-- Выходной параметр -->
<parameter>
<name value="return" />
<use value="out" />
<min value="1" />
<max value="1" />
<documentation value="Контейнер результатов поиска" />
<type value="Bundle" />
</parameter>
</OperationDefinition>
Варианты вызова именованного запроса current-high-risk приведены в таблице 371.
Таблица 371
Варианты вызова именованного запроса current-high-risk
Запрос
Описание
GET [base]/Patient?_query=current-high-risk
Запрос без дополнительных параметров
GET [base]/Patient?_query=current-high-risk&ward=Location/A1
Запрос с параметром ward, содержащим ссылку на палату интенсивной терапии, идентифицируемую экземпляром ресурса Location/A1
GET [base]/Patient?_query=current-high-risk&birthdate=ge1970-01-1
Запрос без параметра ward, но с дополнительным параметром birthdate (дата рождения), определенным для ресурса Patient. Сервер по возможности должен применять параметры, определенные для типа соответствующего типа ресурса, но может их игнорировать
GET [base]/Patient?_query=current-high-risk&birthdate=ge1970-01-01&ward=Location/A1
Запрос с параметром ward и дополнительным параметром birthdate, определенным для ресурса Patient. Параметры запроса не являются упорядоченными, поэтому параметр ward может быть указан в любом месте строки параметров поиска
12.34 Актуальность результатов запроса
Результаты операции поиска актуальны только на момент ее выполнения. Это особенно важно иметь в виду при постраничном выводе результатов, если каждая страница формируется в момент ее запроса, а не заранее.
12.35 Отображение типов данных на типы параметров
Отображение типов данных на типы параметров приведено в таблице 372.
Таблица 372
Отображение типов данных на типы параметров
Тип данных
Тип параметра
number
date
reference
quantity
uri
string
token
Простые типы
base64Binary
Не используется при поиске
boolean
Нет
Нет
Нет
Нет
Нет
Нет
Да, допустимые значения true|false)
canonical
Нет
Нет
Да
Нет
Да
Нет
Да
code
Нет
Нет
Нет
Нет
Нет
Нет
Да
date
Нет
Да
Нет
Нет
Нет
Нет
Нет
dateTime
Нет
Да
Нет
Нет
Нет
Нет
Нет
decimal
Да
Нет
Нет
Нет
Нет
Нет
Нет
id
Нет
Нет
Нет
Нет
Нет
Нет
Да
instant
Нет
Да
Нет
Нет
Нет
Нет
Нет
integer
Нет
Нет
Нет
Нет
Нет
Нет
Нет
markdown
Не используется при поиске
oid
См. тип данных uri
positiveInt
См. тип данных integer
string
Нет
Нет
Нет
Нет
Нет
Да
Да
time
Не используется при поиске
unsignedInt
См. тип данных integer
uri
Нет
Нет
Да
Нет
Да
Нет
Нет
url
См. тип данных uri
uuid
См. тип данных uri
Комплексные типы
Address
Нет
Нет
Нет
Нет
Нет
Да (поиск по строковым компонентам адреса)
Нет
Age
Нет
Нет
Нет
Да
Нет
Нет
Нет
Annotation
Не используется при поиске
Attachment
Не используется при поиске
CodeableConcept
Нет
Нет
Нет
Нет
Нет
Нет
Да
CodeableReference
Не используется при поиске
Coding
Нет
Нет
Нет
Нет
Нет
Нет
Да
Count
Не используется при поиске
ContactPoint
Нет
Нет
Нет
Нет
Нет
Нет
Да
Distance
Не используется при поиске
Duration
Нет
Нет
Нет
Да
Нет
Нет
Нет
HumanName
Нет
Нет
Нет
Нет
Нет
Да (поиск по строковым компонентам именования)
Нет
Identifier
Нет
Нет
Нет
Нет
Нет
Нет
Да
Money
Нет
Нет
Нет
Да
Нет
Нет
Нет
Period
Нет
Да
Нет
Нет
Нет
Нет
Нет
Quantity
Нет
Нет
Нет
Да
Нет
Нет
Нет
Range
Нет
Нет
Нет
Да
Нет
Нет
Нет
Ratio
Не используется при поиске
Reference
Нет
Нет
Да
Нет
Нет
Нет
Нет
SampledData
Не используется при поиске
Signature
Не используется при поиске
Timing
Нет
Да
Нет
Нет
Нет
Нет
Нет
12.36 Транзакции
Несколько запросов поиска может быть передано в одном контейнере пакета или транзакции Bundle. Каждый запрос должен выполняться независимо от другого. Ответы на запросы возвращаются в контейнере результата пакета или транзакции Bundle. При успешном выполнении всех запросов поиска контейнер результата пакета или транзакции должен иметь структуру, показанную на рисунке 83.
Рисунок 83 - Структура контейнера результата
пакета или транзакции запросов поиска
Если при выполнении какого-либо запроса поиска возникла ошибка, то вместо контейнера результата транзакции должен быть возвращен экземпляр ресурса OperationOutcome с описанием ошибки, а в контейнере результатов пакета экземпляр ресурса OperationOutcome должен быть возвращен вместо соответствующего контейнера результата поиска Bundle.
12.37 Сообщения с запросами поиска
Для передачи запроса поиска в сообщении должен использоваться экземпляр Parameters, у которого элемент name имеет значение url, а элемент valueString содержит часть строки поиска после базового URL (включая знак вопроса). Элемент event заголовка сообщения должен иметь значение search-type, если поиск осуществляется в контексте типа ресурса, или search-system, если поиск осуществляется в контексте системы.
Ответное сообщение может содержать контейнер результатов поиска Bundle или экземпляр ресурса Binary, содержащий двоичное представление результата поиска в ином формате, например, файл формата CSV, упакованный в архив ZIP.
13 Операции
13.1 Общие требования
В REST API определен общий набор взаимодействий (чтение, изменение, поиск и т.д.), обеспечиваемых сервисом хранения и обработки результатов измерений или иным сервером. Они следуют парадигме REST по управлению состоянием с помощью действий Create (создать)/Read (читать)/Update (изменить)/Delete (удалить), совершаемых над совокупностью идентифицированных экземпляров ресурсов. Хотя во многих случаях этого достаточно, существует определенная функциональность, которая более эффективно реализуется с помощью парадигмы, подобной RPC (Remote Procedure Call - удаленный вызов процедуры), согласно которой выполняются (Execute) именованные операции с входными и выходными параметрами,
Операции предпочтительны в следующих случаях:
а) требуется не просто возвращать существующую информацию, но еще и активно формировать возвращаемый контент;
б) необходимо инициировать побочное действие, например, автоматически создать экземпляр ресурса уведомлений при получении результата измерений, выходящего за заданные границы, или выполнить иные изменения, не укладывающиеся в рамки REST;
в) требуется применить форматно-логический контроль к нескольким экземплярам ресурсов разных типов;
г) необходимо выполнить скоординированные изменения нескольких экземпляров ресурсов (это можно сделать с помощью контейнеров Bundle типа transaction, но операции обеспечивают более гибкий подход).
Операции обладают следующими общими свойствами:
а) каждая операция имеет имя;
б) для каждой операции определены списки входных и выходных параметров;
в) параметрами могут служить экземпляры ресурсов, типизированные значения или параметры поиска;
г) к операциям предъявляются те же требования информационной безопасности, как и к REST API;
д) идентификаторы URI конечных точек операций основаны на существующей схеме адресации конечных точек REST API;
е) операции могут использовать все типы ресурсов, экземпляры которых содержатся в хранилище результатов измерений;
ж) операции могут применяться к экземпляру ресурса, к типу ресурса или ко всему хранилищу.
13.2 Выполнение операции
Для вызова операции используется адрес URL, произведенный от конечной точки сервера с помощью указания имени операции, которому предшествует знак доллара ('$'), например:
POST Базовый_URL/Observation/1/$everything
Если в определении операции элемент affectsState (воздействует на состояние) имеет значение false и все параметры операции имеют простые типы данных без расширений, то операцию можно вызвать и с помощью метода GET (или HEAD).
Операции могут вызываться для конечных точек следующих трех типов:
а) базовый URL-адрес сервера (например, http://localhost:8080). Такие операции манипулируют содержанием базы данных сервера, например, "получить все расширения, которыми может оперировать данный сервер";
б) URL типа ресурса (например, (http://localhost:8080/Observation). Такие операции манипулируют экземплярами ресурсов данного типа;
в) URL экземпляра ресурса (например, (http://localhost:8080/Observation/1). Такие операции манипулируют конкретным экземпляром ресурса.
Тело вызова операции содержит экземпляр специального ресурса Parameters, представляющий коллекцию именованных параметров в форме <ключ, значение>, где значение может иметь простой или комплексный тип данных либо представлять собой экземпляр ресурса. Значения могут также представлять собой строки в формате параметров поиска.
По завершении операции возвращается код статуса HTTP, характеризующий результат ее выполнения, и может возвратиться другой экземпляр ресурса Parameters, содержащий один или несколько выходных параметров. Если определен единственный выходной параметр с именем return и максимального кратностью 1, и его типом является ресурс, то результатом операции должен быть экземпляр этого ресурса, без вложения в экземпляр ресурса Parameters. Если выходные параметры отсутствуют, то возвращается пустое тело ответа.
Таким образом, операция получает на вход коллекцию из нуля или нескольких параметров и возвращает коллекцию из нуля или нескольких параметров результата вызова. Тело метода POST и возвращаемого результата (при наличии) всегда является экземпляром ресурса.
Для вызова операция может использоваться метод GET с параметрами в адресной строке, если выполнены следующие условия:
а) все входные параметры являются простыми (то есть их значения не имеют комплексные типы данных наподобие Identifier или Reference;
б) операция не воздействует на состояние сервера.
Если тело ответа является экземпляром ресурса Bundle, не имеющим семантику результата поиска, то элемент Bundle.type должен иметь значение collection и может содержать ссылки на страницы результата.
13.3 Операции без параметров
Если операция не имеет входных параметров и не воздействует на состояние сервера, то она может быть вызвана с помощью метода GET, например:
GET [Базовый_URL]/Observation/1/$meta.
Если операция без входных параметров воздействует на состояние сервера, то она должна быть вызвана с помощью метода POST. В этом случае экземпляр ресурса Parameters не передается, поскольку он не может быть пустым. Поэтому при вызове такой операции следует указать, что тело отсутствует, например:
POST [Базовый_URL]/Observation/1/$meta
Content-Length: 0.
13.4 Определение операции
Для каждой операция должна быть указана следующая информация:
а) уровень, на котором она вызывается - система, тип ресурса или экземпляр ресурса;
б) имя операции;
в) список параметров с их определениями.
Для каждого параметра необходимо указать следующую информацию:
а) имя параметра. Для удобства реализации имя должно быть валидным для наиболее распространенных языков программирования;
б) использование параметра - in (входной) | out (выходной) | both (входной и выходной) и его кратность;
в) тип значения параметра - тип данных или тип ресурса;
г) тип параметра поиска (не обязателен). Если параметр имеет строковое значение и используется как параметр поиска, то можно назначить ему один из типов number | date | string | token | reference | composite | quantity | uri | special и указать, какие модификаторы параметров поиска могут использоваться;
д) профиль (не обязателен) - экземпляр ресурса StructureDefinition, описывающий дополнительные ограничения, накладываемые на параметр. Может задаваться только в том случае, если значение параметра имеет тип данных или является экземпляром ресурса;
е) описание назначения параметра.
Параметры могут содержать вложенные компоненты. Для каждого компонента предоставляется та же информация, что и для параметра, кроме использования, которое наследуется от параметра, чьей частью является данный компонент.
Машинно-обрабатываемое описание операции представляет собой экземпляр ресурса Operation Definition.
13.5 Синхронное выполнение операции
13.5.1 Адрес конечной точки
Обычно операции выполняются синхронно: клиент отправляет серверу запрос на выполнение операции, содержащий ее входные параметры, а сервер возвращает выходные параметры результата выполнения операции.
Адрес URL конечной точки операции зависит от уровня ее выполнения:
а) система: [Базовый_URL]/$[имя операции];
б) тип ресурса: [Базовый_URL]/[тип ресурса]/$[имя операции];
в) экземпляр ресурса: [Базовый_URL]/[тип ресурса]/[идентификатор экземпляра]/$[имя операции].
13.5.2 Запрос на выполнение операции
Обычно для вызова операции инициируется передача конечной точке операции запроса HTTP POST. Тело запроса содержит экземпляр ресурса Parameters, содержащий список именованных входных параметров. Если входной параметр имеет тип параметра поиска, то в имени параметра могут использоваться модификаторы (например, code:in).
К формату тела запроса операции предъявляются стандартные требования интерфейса REST.
Если элемент affectsState в определении операции имеет значение false и все параметры имеют простые типы данных без расширений, то операцию можно вызвать с помощью метода GET. При этом все значения параметров добавляются к URL в компоненте запроса (то есть после символа '?'), например:
GET [Базовый_URL]/ValueSet/$expand?url=http://hl7.org/fhir/ValueSet/body-site&filter=abdo.
Если параметр операции может повторяться, то при ее вызове с помощью HTTP GET имя параметра следует повторить для каждого его значения. Например, параметр resource (тип ресурса) операции $subset, применяемой к типу ресурса CapabilityStatement (объявление возможностей), имеет кратность 1..*. Тогда для получения подмножества объявления возможностей, включающего в себя сведения о типах ресурсов Person и Organization, следует сделать запрос
GET [Базовый_URL]/CapabilityStatement/$subset?resource=Person&resource=Organization.
Если при вызове операции задается ровно один входной параметр типа Resource (независимо от того, определены ли другие необязательные параметры), то операцию можно вызвать с помощью метода POST, указав входной экземпляр ресурса в теле запроса (при этом в URL не должно быть никаких параметров).
Сервер может поддерживать задание входных параметров, используя формат multi-part/form-data [40], что может оказаться полезным при отладке операций с использованием HTML-форм.
13.6 Результат выполнения операции
Если операция выполнена успешно, возвращается статус HTTP с кодом 2xx или 303 See Other. Другие значения кодов 3xx следует воспринимать, как признак ошибки выполнения операции и клиенту может потребоваться новый вызов, если он в состоянии обработать перенаправление (например, на страницу аутентификации). Коды статуса HTTP 4xx или 5xx означают ошибку и в этом случае должен быть возвращен экземпляр ресурса OperationOutcome с детальными сведениями об ошибке.
В общем случае результатом выполнения операции является экземпляр ресурса Parameters, содержащий один или несколько именованных выходных параметров.
В случае единственного выходного параметра типа Resource с именем return вместо экземпляра ресурса Parameters возвращается экземпляр ресурса другого типа.
Как и при других взаимодействиях, в заголовке Accept вызова операции может быть указан формат возвращаемого результата.
Сервер может сохранить экземпляр ресурса, возвращенный в качестве результата запроса. В этом случае экземпляр должен содержать элемент идентификатора id. Если возвращенный экземпляр ресурса не сохранен сервером, элемент id должен отсутствовать.
13.7 Асинхронное выполнение операции
13.7.1 Начальный запрос
При асинхронном выполнении начальный запрос операции передается так же, как при синхронном, только в нем должны быть указаны заголовок Accept, определяющий формат представления возвращаемых экземпляров ресурсов (application/xml или application/json), и заголовок Prefer со значением respond-async.
13.7.2 Успешный прием начального запроса
При успешном приеме начального запроса должен быть возвращен код статуса HTTP 202 Accepted и заголовок Location с абсолютным адресом URL конечной точки, которая должна опрашиваться для получения статуса и результата обработки запроса. В теле ответа может быть возвращен экземпляр ресурса OperationOutcome, содержащий какую-либо дополнительную информацию.
13.7.3 Ошибка приема начального запроса
При ошибке приема начального запроса (например, указан неподдерживаемый параметр поиска) должен быть возвращен код статуса HTTP 4XX или 5XX и экземпляр ресурса OperationOutcome с описанием ошибки.
13.7.4 Отмена начального запроса
После получения ответа об успешном приеме начального запроса клиент может отменить обработку запроса, передав запрос HTTP DELETE по адресу конечной точки, возвращенному в заголовке Location. Если после отмена начального запроса клиент направит на этот адрес новый запрос, то сервер должен возвратить код статуса HTTP 404 Not Found и экземпляр ресурса OperationOutcome с описанием ошибки.
Если запрос отмены обработан успешно, то сервер должен возвратить код статуса HTTP 202 Accepted и может возвратить в теле ответа экземпляр ресурса OperationOutcome, содержащий какую-либо дополнительную информацию. При ошибке обработки запроса отмены сервер должен возвратить код статуса HTTP 4XX или 5XX и может возвратить в теле ответа экземпляр ресурса OperationOutcome, содержащий информацию об ошибке.
13.7.5 Запрос статуса обработки
13.7.5.1 Общие требования
После получения ответа об успешном приеме начального запроса клиент может запросить статус обработки, передав запрос HTTP GET по адресу конечной точки, возвращенному в заголовке Location. Клиент должен придерживаться экспоненциального увеличения интервала между последовательными запросами статуса. Сервер может передать в заголовке Retry-After рекомендуемый интервал в секундах или рекомендуемые дату и время следующего запроса. Сервер по возможности должен вести статистику запросов статуса, получаемых от данного клиента, и при повышенной частоте запросов может в дополнение к заголовку Retry-After возвратить код статуса HTTP 429 Too Many Requests, а также экземпляр ресурса OperationOutcome, содержащий поясняющую информацию. При повторении частой передачи запроса статуса сервер может возвратить код статуса HTTP 429 Too Many Requests и отменить дальнейшую обработку начального запроса.
13.7.5.2 Ответ "в процессе"
Если обработка начального запроса продолжается, то сервер должен возвратить код статуса HTTP 202 Accepted и может возвратить заголовок X-Progress с текстовым описанием стадии обработки длиной до 100 символов, например, указать процент завершения обработки или более общий статус "в процессе".
13.7.5.3 Ответ "ошибка"
Если при обработке запроса статуса возникла ошибка, то сервер должен возвратить код статуса HTTP 4XX или 5XX и по возможности должен возвратить в теле ответа экземпляр ресурса OperationOutcome с описанием ошибки. Если ошибка возникла на инфраструктурном уровне и формирование экземпляра ресурса OperationOutcome не представляется возможным, то сервер может передать информацию об ошибке в ином формате и указать это формат в заголовке Content-Type.
Сервер не должен использовать такой ответ, если ошибка возникла не при обработке запроса статуса, а при обработке начального запроса. Код, возвращаемый в элементе OperationOutcome.issue.code, должен означать преходящую ошибку, означающий, что клиенту следует повторить запрос статуса позже.
13.7.5.4 Ответ "обработка завершена"
При завершении обработки начального запроса, даже в случае, если она была аварийно прекращена, сервер должен возвратить код статуса HTTP 200 OK и экземпляр контейнера Bundle типа batch-response. В элементе Bundle.entry[0].response по возможности должны быть возвращен код результата обработки и дополнительная информация, например, описании возникшей ошибки. В элементе Bundle.entry[0].resource может быть возвращен экземпляр ресурса, представляющий собой результат выполнения операции. Если в результате выполнения операции было создано, изменено или найдено несколько экземпляров ресурсов, то элемент Bundle.entry[0].resource может содержать контейнер Bundle соответствующего типа, в который вложены эти экземпляры.
13.8 Операции с системами кодирования
13.8.1 Операция $lookup
13.8.1.1 Общие сведения
Если на вход операции $lookup задана пара <система кодирования, код> или значение типа Coding, то операция возвратит детальные сведения о кодированном понятии, включая определение, статус, обозначения и свойства. Обязательными параметрами является или пара <система кодирования, код>, или значение типа Coding. Остальные параметры необязательны. Операция является идемпотентной. Ее параметры представлены в таблице 373.
Таблица 373
Параметры операции $lookup
Имя
Кратность
Тип данных
Описание
Входные параметры
code
0..1
code
Код, для которого требуется найти данные. Если код указан, обязательно должна быть указана система кодирования
system
0..1
uri
Система кодирования, из которой берется код. Если система кодирования указана, обязательно должен быть указан код
version
0..1
string
Версия системы кодирования, если она предусмотрена
property.subproperty.code
1
code
Имя вложенного свойства
property
0..*
code
Имя свойства, значение которого должно быть возвращено в выходных параметрах. Если ни одно имя свойства не указано, сервер определяет список возвращаемых свойств по своему усмотрению.
Для всех систем кодирования определены следующие свойства:
url (уникальный идентификатор);
name (имя);
version (версия);
display (значение для вывода);
definition (описание);
designation (обозначение);
parent (код родительского понятия);
child (код дочернего понятия).
Для обозначения designation указывается также язык обозначения).
Некоторые из свойств возвращаются на одном уровне с именем, а остальные (кроме языка обозначения) в группе элементов property
coding
0..1
Coding
Значение типа Coding, для которого требуется найти данные. Если оно указано, то параметры code и system должны отсутствовать
date
0..1
dateTime
Дата, на которую должна быть возвращены данные о кодированном понятии. Обычно данные ищутся на текущую дату, но иногда бывает важно знать, какими они были раньше
displayLanguage
0..1
code
Язык, на котором должны быть представлены данные
Выходные параметры
name
1
string
Наименование системы кодирования
version
0..1
string
Версия системы кодирования, для которой возвращены данные
display
1
string
Предпочтительное значение понятия для вывода
designation
0..*
Дополнительное обозначение понятия
designation.language
0..1
code
Язык обозначения
designation.use
0..1
Coding
Код, указывающий назначение обозначения
designation.value
1
string
Текстовое значение обозначения
property
0..*
-
Свойство, содержащее дополнительные данные о коде, включая статус
property.code
1
code
Имя свойства
property.value
0..1
code | Coding | string | integer | boolean | dateTime | decimal
Машиночитаемое значение свойства (например, code для свойства с кодированным значением)
property.description
0..1
string
Человеко-читаемое значение свойства (например, display для свойства с кодированным значением)
property.subproperty
0..*
-
Вложенное свойство (используется в основном для групп отношений в системе кодирования SNOMED CT))
property.subproperty.value
1
code | Coding | string | integer | boolean | dateTime | decimal
Машиночитаемое значение вложенного свойства (например, code для вложенного свойства с кодированным значением)
property.subproperty.description
0..1
string
Человеко-читаемое значение вложенного свойства (например, display для вложенного свойства с кодированным значением)
13.8.1.2 Примеры
Запрос на поиск данных о коде DSG из системы кодирования с url = http://terminology.hl7.org/CodeSystem/v2-0203:
https://hapi.fhir.org/baseR5/CodeSystem/$lookup?system=http://terminology.hl7.org/CodeSystem/v2-0203&code=DSG
Ответ (код найден):
HTTP 200 OK
[заголовки]
{
"resourceType": "Parameters",
"parameter": [ {
"name": "name",
"valueString": "Тип идентификатора"
}, {
"name": "version",
"valueString": "3.0.0"
}, {
"name": "display",
"valueString": "Группа исследований"
}, {
"name": "abstract",
"valueBoolean": false
}, {
"name": "property",
"part": [ {
"name": "code",
"valueCode": "v2-concComment"
}, {
"name": "value",
"valueString": "Пример: группа лучевых исследований"
} ]
}, {
"name": "property",
"part": [ {
"name": "code",
"valueCode": "status"
}, {
"name": "value",
"valueString": "N"
} ]
} ]
}
Ответ: код не найден
HTTP 404 Not Found
[заголовки]
{
"resourceType": "OperationOutcome",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h1>Operation
Outcome</h1><table border=\"0\"><tr><td style=\"font-weight:
bold;\">ERROR</td><td>[]</td><td>HAPI-1738: Unable to find code[null] in
system[null]</td></tr></table></div>"
},
"issue": [ {
"severity": "error",
"code": "processing",
"diagnostics": "HAPI-1738: Unable to find code[null] in system[null]"
} ]
}
13.8.2 Операция $validate-code
13.8.2.1 Общие сведения
Операция $validate-code выполняет проверку принадлежности кода к системе кодирования. Если она вызывается на уровне системы или типа ресурса, то должен быть указан один из параметров url или codeSystem. Операция возвращает результат проверки (true/false), сообщение об ошибке и рекомендованное человеко-читаемое значение кода.
При вызове операции клиент должен предоставить один и только один параметр, задающий код (code+system, coding, or codeableConcept). Другие параметры (включая версию version и человеко-читаемое значение кода display) не обязательны.
Варианты URL вызова:
[Базовый_URL]/CodeSystem/$validate-code
[Базовый_URL]/CodeSystem/[идентификатор]/$validate-code
Операция является идемпотентной. Ее параметры представлены в таблице 374.
Таблица 374
Параметры операции $validate-code
Имя
Кратность
Тип данных
Описание
Входные параметры
url
0..1
uri
Канонический адрес URL системы кодирования
codeSystem
0..1
CodeSystem
Экземпляр системы кодирования, предоставленный как параметр операции
code
0..1
code
Код, требующий валидации
version
0..1
string
Версия системы кодирования, если она предусмотрена
display
0..1
string
Человеко-читаемое значение кода. Если параметр display указан, должен быть указан параметр code
coding
0..1
Coding
Значение типа Coding, требующее валидации. Его компонент system должен идентифицировать ту же систему кодирования, что и элемент url
codeableConcept
0..1
CodeableConcept
Значение типа CodeableConcept, требующее валидации. Сервер должен возвратить true, если хотя бы одно из кодируемых значений, указанных в компоненте coding, принадлежит системе кодирования, указанной в элементе url
date
0..1
dateTime
Дата, на которую должен быть валидирован код. Обычно валидация осуществляется на текущую дату, но иногда бывает важно валидировать код по более раннему содержанию системы кодирования
abstract
0..1
boolean
Если этот параметр имеет значение true и валидация осуществляется для системы кодирования, в которой понятия имеют признак abstract, указывающий, может ли понятие быть выбрано пользователем, то сервер должен рассматривать эти понятия как действительные. Если этот параметр имеет значение true, то он должен их рассматривать как недействительные
display-Language
0..1
code
Язык представления человеко-читаемого представления кода (если требуется валидация свойства display)
Выходные параметры
result
1
boolean
Значение true, если кодируемое понятие успешно валидировано
message
0..1
string
Если result = false, то этот элемент описывает детали ошибки валидации. Если result = true, то в этом элементе могут быть переданы указания и предупреждения
display
0..1
string
Человеко-читаемое значения понятия, если требуется представить результат валидации пользователю
13.8.2.2 Валидация значения типа code
Запрос на валидацию кода DSG в системе кодирования с url = http://terminology.hl7.org/CodeSystem/v2-0203:
https://hapi.fhir.org/baseR5/CodeSystem/$validate-code?url=http://terminology.hl7.org/CodeSystem/v2-0203&code=DSG
Ответ (код валиден):
HTTP 200 OK
[заголовки]
{
"resourceType": "Parameters",
"parameter": [ {
"name": "result",
"valueBoolean": true
}, {
"name": "display",
"valueString": "Группа исследований"
} ]
}
Ответ (код не найден):
HTTP 200 OK
[заголовки]
{
"resourceType": "Parameters",
"parameter": [ {
"name": "result",
"valueBoolean": false
}, {
"name": "message",
"valueString": "Unable to validate code http://terminology.hl7.
org/CodeSystem/v2-0203#DSG1 - Code is not found in CodeSystem: http://
terminology.hl7.org/CodeSystem/v2-0203"
} ]
}
Если в строке запроса указан дополнительный параметр display, например:
https://hapi.fhir.org/baseR5/CodeSystem/$validate-code?url=http://terminology.hl7.org/CodeSystem/v2-0203&code=DSG&display=Группа%20исследований
то проверяется валидность пары <code, display>.
Если запрос неправилен, например, указан ошибочный параметр, то возвращается экземпляр ресурса OperationOutcome с сообщением об ошибке следующего вида:
HTTP 400 Bad Request
[заголовки]
{
"resourceType": "OperationOutcome",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h1>Operation
Outcome</h1><table border=\"0\"><tr><td style=\"font-weight:
bold;\">ERROR</td><td>[]</td><td>HAPI-0908: Either CodeSystem ID or
CodeSystem identifier must be provided. Unable to validate.</td></tr></
table></div>"
},
"issue": [ {
"severity": "error",
"code": "processing",
"diagnostics": "HAPI-0908: Either CodeSystem ID or CodeSystem
identifier must be provided. Unable to validate."
} ]
}
13.8.2.3 Валидация значения типа Coding
Запрос на валидацию кода 85.1 в системе кодирования с url = https://rosstat.gov.ru/opendata/7708234640-okved2:
POST localhost:8080/fhir/CodeSystem/$validate-code
[другие заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "url",
"valueUri": "https://rosstat.gov.ru/opendata/7708234640-okved2"
},
{
"name": "coding",
"valueCoding": {
"system": "https://rosstat.gov.ru/opendata/7708234640-okved2",
"code": "85.1",
"display": "Образование общее"
}
}
]
}
Ответ (код валиден):
HTTP/1.1 200 OK
[другие заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "result",
"valueBoolean": true
},
{
"name": "display",
"valueString": "Образование общее"
}
]
}
Ответ (код не соответствует текстовому значению):
HTTP/1.1 200 OK
[другие заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "result",
"valueBoolean": false
},
{
"name": "message",
"valueString": "Unknown code {https://rosstat.gov.ru/opendata/7708234640-
okved2}85.1 - Concept Display : Образование"
}
]
}
13.8.2.4 Валидация значения типа CodeableConcept
Запрос на валидацию значения типа CodeableConcept, содержащего коды Yes и Y в системе кодирования с url = http://terminology.hl7.org/CodeSystem/v2-0532:
POST localhost:8080/fhir/CodeSystem/$validate-code
[заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "url",
"valueUri": "http://terminology.hl7.org/CodeSystem/v2-0532"
},
{
"name": "codeableConcept",
"valueCodeableConcept": {
"coding": [
{
"code": "Yes",
"display": "Да"
},
{
"code": "Y",
"display": "Yes"
}
]
}
}
]
}
Ответ (код валиден):
HTTP/1.1 200 OK
[заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "result",
"valueBoolean": true
},
{
"name": "display",
"valueString": "Образование общее"
}
]
}
Примечание - Массив coding в теле запроса просматривается последовательно. Если первый элемент массива валиден, то другие не проверяются. Если первый элемент не принадлежит данной системе кодирования, то проверяется второй элемент и т.д.
Ответ (код не валиден):
HTTP/1.1 200 OK
[заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "result",
"valueBoolean": false
},
{
"name": "message",
"valueString": "Unknown code {https://rosstat.gov.ru/
opendata/7708234640-okved2}85.99 - Concept Display : Образование"
}
]
}
Ответ (ошибка вызова):
HTTP/1.1 400 Bad Request
[заголовки]
{
"resourceType": "OperationOutcome",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h1>Operation
Outcome</h1><table border=\"0\"><tr><td style=\"font-weight: bold;\">ERROR</
td><td>[]</td><td><pre>Coding.system 'https://rosstat.gov.ru/
opendata/7708234640-okved3' does not equal with CodeSystem.url 'https://rosstat.
gov.ru/opendata/7708234640-okved2'. Unable to validate.</pre></td>\n\t\t\t</tr>\
n\t\t</table>\n\t</div>"
},
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics": "Coding.system 'https://rosstat.gov.ru/
opendata/7708234640-okved3' does not equal with CodeSystem.url 'https://rosstat.
gov.ru/opendata/7708234640-okved2'. Unable to validate."
}
]
}
13.9 Операции с наборами значений
13.9.1 Операция $expand
13.9.1.1 Общие сведения
Операция $expand возвращает раскрытие набора значений, то есть список кодов, которые образуют набор значений в соответствии с его определением, заданным с помощью ресурса ValuSet. Если набор значений сохранен вместе с раскрытием, то она возвращает сохраненное раскрытие. Если набор значений сохранен без раскрытия, то она создает раскрытие динамически.
Если операция вызывается на уровне системы или типа ресурса, то должен быть задан один из входных параметров url, context или valueSet. В ответ возвращается либо экземпляр ресурса ValueSet, описывающий раскрытие, либо экземпляр ресурса OperationOutcome, содержащий сообщение об ошибке.
Если набор значений сохранен вместе с раскрытием, то операция $expand является идемпотентной. Если раскрытие создается динамически, то при повторном вызове результат может измениться. Параметры операции $expand представлены в таблице 375.
Таблица 375
Параметры операции $expand
Имя
Кратность
Тип данных
Описание
Входные параметры
url
0..1
uri
Каноническая ссылка на набор значений
valueSet
0..1
ValueSet
Определение набора значений, включенное непосредственно в запрос
valueSetVersion
0..1
string
Версия набора значений, использованная при генерации раскрытия набора значений
context
0..1
uri
Контекст набора значений, то есть ссылка на определение элемента ресурса, содержащее привязку к набору значений. Ссылка должна иметь формат [URL экземпляра ресурса StructureDefinition>#<имя элемента или путь к элементу>]
contextDirection
0..1
code
Направление контекста. Допустимые значения: incoming (коды, которые клиент может отправлять серверу с помощью PUT/POST) | outgoing (коды, которые клиент может получать от сервера). В большинстве случаев эти наборы кодов совпадают, но иногда могут различаться
filter
0..1
string
Текстовый фильтр, применяемый к человеко-читаемым значениям кодов (передаваемым в элементе display) в целях ограничения числа возвращаемых кодов. Способ фильтрации определяется сервером, который может его документировать в элементе TerminologyCapabilities..expansion.textFilter. Типичными примерами фильтрации служат:
- совпадение по началу значения
- использование заполнителей, например %, &, ?
ИС МЕГАНОРМ: примечание.
В официальном тексте документа, видимо, допущена опечатка: одна и та же строка таблицы повторяется дважды.
filter
0..1
string
Текстовый фильтр, применяемый к человеко-читаемым значениям кодов (передаваемым в элементе display) в целях ограничения числа возвращаемых кодов. Способ фильтрации определяется сервером, который может его документировать в элементе TerminologyCapabilities..expansion.textFilter. Типичными примерами фильтрации служат:
- совпадение по началу значения
- использование заполнителей, например %, &, ?
date
0..1
dateTime
Дата, по состоянию на которую должно быть выполнено раскрытие. Если дата указана, то сервер должен использовать определения набора значений и систем кодирования, имевшиеся на эту дату, либо возвратить ошибку, если это не представляется возможным. Обычно раскрытие осуществляется на текущую дату, но иногда требуется получить прошлое состояние набора значений. Трактовка этой даты зависит от реализации
offset
0..1
integer
Поддержка постраничного вывода - с какого места списка значений следует начать вывод (по умолчанию - 0). Место идентифицирует порядковый номер значения (с базой 0), а не номер страницы вывода
count
0..1
integer
Число кодов, выводимых на одной странице. Постраничный вывод применяется только к линейным наборам значений. Сервер игнорирует требование постраничного вывода, если набор значений не является линейным. Если count = 0, то это означает, что клиент запрашивает число элементов в раскрытии. В этом случае сервер по возможности должен возвратить размер и для иерархических наборов значений
includeDesignations
0..1
boolean
Признак включения обозначений (designation) в результат раскрытия набора значений
designation
0..*
string
Строка в формате токена (system|code), задающая использование (use) или язык (language) обозначения, которое должно быть включено в результат раскрытия набора значений. Если язык не задан, то сервер возвращает обозначения по своему усмотрению
includeDefinition
0..1
boolean
Признак включения описания в результат раскрытия набора значений
activeOnly
0..1
boolean
Признак включения неактивных понятий в раскрытие набора значений. Если в определении набора значений указано, что неактивные понятия включены в него, то с помощью этого параметра можно исключить их из раскрытия. Но если в определении набора значений указано, что неактивные понятия исключены в него, то включить их в раскрытие с помощью этого параметра нельзя
excludeNested
0..1
boolean
Признак включения дочерних кодов (ValueSet.expansion.contains.contains) в раскрытие набора значений
excludeNotForUI
0..1
boolean
Признак, что раскрытый набор значений не используется в интерфейсе пользователя. Те наборы значений, что используются в интерфейсе пользователя, могут содержать "абстрактные" коды, которые помогают пользователю в навигации по иерархии кодируемых значений, но сами не могут быть выбраны пользователем. Наборы значений, не используемые в пользовательском интерфейсе, могут быть линейными, не содержащими "абстрактные" коды. Точная трактовка понятия "используется в пользовательском интерфейсе" зависит от системы кодирования и от того, какие коды включаются в набор значений
excludePostCoordinated
0..1
boolean
Признак исключения пост-координируемых кодов из раскрытия набора значений
displayLanguage
0..1
code
Код языка, на котором представляется человеко-читаемое значение (display) кода в раскрытии набора значений, то есть язык представления ValueSet.expansion.contains.display
exclude-system
0..*
canonical
Система кодирования или ее конкретная версия, исключаемая из раскрытия набора значений. Она задается по правилам канонического URL: [system]|[version]
system-version
0..*
canonical
Версия системы кодирования, используемая при раскрытии набора значений (если версия не указана в определении набора значений) Она задается по правилам канонического URL: [system]|[version]
check-system-version
0..*
canonical
Крайний случай: указывает версию системы кодирования, которую следует использовать. Если в определении набора значений указана другая версия, то вместо возвращения раскрытия должна генерироваться ошибка. Версия системы кодирования задается по правилам канонического URL: [system]|[version]
force-system-version
0..*
canonical
Крайний случай: указывает версию системы кодирования, которую следует использовать. Если в определении набора значений указана другая версия, то должна использоваться версия, указанная в этом параметре. Она задается по правилам канонического URL: [system]|[version]
Выходные параметры
return
1
ValueSet
Результат раскрытия набора значений. Сервер по возможности должен воспроизвести все входные параметры в списке элементов ValueSet.expansion.parameter list.
Поскольку это единственный выходной параметр, то он является экземпляром ресурса и поэтому имеет имя return
Возвращаемое раскрытие набора значений должно восприниматься как динамическое, которое может изменяться с течением времени (это зависит от того, как определен набор значений).
Если раскрытие слишком велико, то сервер может возвратить экземпляр ресурса OperationOutcome с кодом ошибки too-costly (слишком затратное). В этом случае клиент может запросить раскрытие набора значений по частям, указывая параметры offset и count. В отличие от запросов, где при постраничной выдаче указываются ссылки на другие страницы, сервер должен пропустить offset кодов и выдать следующие count кодов. Сервер не обязан поддерживать эти параметры, но если поддерживает, то должен обрабатывать оба этих параметра. К иерархическим раскрытиям эти параметры не применимы.
Если сервер не может правильно раскрыть набор значений, поскольку не имеет информации о содержании системы кодирования, указанной в определении набора значений, то он должен возвратить ошибку. Если набор значений не полон, поскольку включает в себя пост-координируемые коды, например, коды производных единиц измерения, то в раскрытие набора значений может быть включено расширение http://hl7.org/fhir/StructureDefinition/valueset-unclosed, указывающее, что раскрытие не является полным.
13.9.1.2 Примеры
Запрос на раскрытие набора значений с идентификатором 95507, применяя фильтр Ye:
http://hapi.fhir.org/baseR4/ValueSet/95507/$expand?filter=Ye
Запрос на раскрытие набора значений по его каноническому URL, применяя фильтр Ye:
http://hapi.fhir.org/baseR4/ValueSet/$expand?url=http://terminology.hl7.org/ValueSet/yndontknow&filter=Ye
Запрос на раскрытие набора значений, включенного в параметры запроса:
POST hapi.fhir.org/baseR5/ValueSet/$expand
[заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "valueSet",
"resource": {
"resourceType": "ValueSet",
"meta": {
"versionId": "3"
},
"url": "http://terminology.hl7.org/ValueSet/yesnodontknow",
"status": "active",
"compose": {
"include": [
{
"valueSet": [
"http://terminology.hl7.org/ValueSet/v2-0136"
]
},
{
"system": "http://terminology.hl7.org/CodeSystem/data-
absent-reason",
"concept": [
{
"code": "asked-unknown",
"display": "Вопрос оставлен без ответа"
}
]
}
]
}
}
}
]
}
Результат запроса:
HTTP 200 OK
[заголовки]
{
"resourceType": "ValueSet",
"id": "95507",
"meta": {
"extension": [ {
"url": "http://hapifhir.io/fhir/StructureDefinition/valueset-
expansion-message",
"valueString": "ValueSet was expanded using an expansion that was
pre-calculated at 2023-11-14T16:13:25.248+00:00 (00:50:52 ago)"
} ],
"versionId": "1"
},
"url": "http://terminology.hl7.org/ValueSet/yndontknow",
"status": "active",
"compose": {
"include": [ {
"valueSet": [ "http://terminology.hl7.org/ValueSet/v2-0136" ]
}, {
"system": "http://terminology.hl7.org/CodeSystem/data-absent-
reason",
"concept": [ {
"code": "asked-unknown",
"display": "Вопрос оставлен без ответа"
} ]
} ]
},
"expansion": {
"identifier": "59f11860-03f0-4ce4-8b7e-6349b7366190",
"timestamp": "2023-11-14T17:04:17+00:00",
"total": 1,
"offset": 0,
"parameter": [ {
"name": "offset",
"valueInteger": 0
}, {
"name": "count",
"valueInteger": 1000
} ],
"contains": [ {
"system": "http://terminology.hl7.org/CodeSystem/v2-0532",
"version": "2.1.0",
"code": "Y",
"display": "Yes"
} ]
}
}
13.9.2 Операция $validate-code
13.9.2.1 Общие сведения
Операция $validate-code выполняет проверку принадлежности кода к набору значений. Если она вызывается на уровне системы или типа ресурса, то должен быть указан один из параметров url, context или valueSet. Операция возвращает результат проверки (true/false), сообщение об ошибке и рекомендованное человеко-читаемое значение кода.
При вызове операции клиент ДОЛЖЕН предоставить один и только один параметр, задающий код (code+system, coding, or codeableConcept). Другие параметры (включая версию version и человеко-читаемое значение кода display) не обязательны.
Варианты URL вызова:
[Базовый_URL]/ValueSet/$validate-code
[Базовый_URL]/ValueSet/[идентификатор]/$validate-code
Операция не является идемпотентной, поскольку содержание набора значений может быть динамическим. Ее параметры представлены в таблице 376.
Таблица 376
Параметры операции $validate-code
Имя
Кратность
Тип данных
Описание
Входные параметры
url
0..1
uri
Канонический адрес URL набора значений
context
0..1
uri
Контекст набора значений, то есть ссылка на определение элемента ресурса, содержащее привязку к набору значений. Ссылка должна иметь формат [URL экземпляра ресурса StructureDefinition>#<имя элемента или путь к элементу>]
valueSet
0..1
ValueSet
Экземпляр набора значений, предоставленный как параметр операции
valueSetVersion
0..1
string
Версия набора значений
code
0..1
code
Код, требующий валидации. Если он указан, то должны быть указаны либо система кодирования system, либо контекст context
system
0..1
uri
Система кодирования, которой принадлежит код
systemVersion
0..1
string
Версия системы кодирования, если она предусмотрена
display
0..1
string
Человеко-читаемое значение кода. Если параметр display указан, должен быть указан параметр code. Если параметр display не указан, то сервер может возвратить рекомендуемое значение
coding
0..1
Coding
Значение типа Coding, требующее валидации
codeableConcept
0..1
CodeableConcept
Значение типа CodeableConcept, требующее валидации. Сервер должен возвратить true, если хотя бы одно из кодируемых значений, указанных в компоненте coding, принадлежит набору значений
date
0..1
dateTime
Дата, на которую должен быть валидирован код. Обычно валидация осуществляется на текущую дату, но иногда бывает важно валидировать код по более раннему содержанию набора значений
abstract
0..1
boolean
Если этот параметр имеет значение true и валидация осуществляется для контекста, в котором понятия имеют признак abstract, указывающий, может ли понятие быть выбрано пользователем, то сервер должен рассматривать эти понятия как действительные. Если этот параметр имеет значение true, то он должен их рассматривать как недействительные
displayLanguage
0..1
code
Язык представления человеко-читаемого представления кода (если требуется валидация свойства display)
Выходные параметры
result
1
boolean
Значение true, если кодируемое понятие успешно валидировано
message
0..1
string
Если result = false, то этот элемент описывает детали ошибки валидации. Если result = true, то в этом элементе могут быть переданы указания и предупреждения
display
0..1
string
Человеко-читаемое значения понятия, если требуется представить результат валидации пользователю
13.9.2.2 Валидация значения типа code
Запрос на валидацию кода Y, принадлежащего системе кодирования http://terminology.hl7.org/CodeSystem/v2-0532, в наборе значений с url = http://hl7.org/fhir/ValueSet/yesnodontknow:
http://hapi.fhir.org/baseR5/ValueSet/$validate-code?url=http://terminology.hl7.org/ValueSet/yndontknow&system=http://terminology.hl7.org/CodeSystem/v2-0532&code=Y
Ответ (код валиден):
HTTP 200 OK
[заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "result",
"valueBoolean": true
},
{
"name": "display",
"valueString": "Yes"
}
]
}
Ответ (код не валиден или система кодирования не найдена):
HTTP 200 OK
[заголовки]
{
"resourceType": "Parameters",
"parameter": [ {
"name": "result",
"valueBoolean": false
}, {
"name": "message",
"valueString": "Unable to validate code http://terminology.hl7.org/
CodeSystem/v2-0532#Y1 - Unknown code \"http://terminology.hl7.org/CodeSystem/
v2-0532#Y1\". Code validation occurred using a ValueSet expansion that was pre-
calculated at 2023-11-14T16:13:25.248+00:00 (00:35:19 ago)"
} ]
}
Если в строке запроса указан дополнительный параметр display, например:
hapi.fhir.org/baseR5/ValueSet/$validate-code?url=http://terminology.hl7.org/ValueSet/yndontknow&system=http://terminology.hl7.org/CodeSystem/v2-0532&code=Y&display=Yes
то проверяется валидность пары <code, display> в системе кодирования, указанной вместе с кодом.
Если запрос неправилен, например, не указан проверяемый код, то возвращается экземпляр ресурса OperationOutcome с сообщением об ошибке, к примеру:
HTTP 400 Bad Request
[заголовки]
{
"resourceType": "OperationOutcome",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h1>Operation Outcome</
h1><table border=\"0\"><tr><td style=\"font-weight: bold;\">ERROR</td><td>[]</
td><td>HAPI-0899: No code, coding, or codeableConcept provided to validate</
td></tr></table></div>"
},
"issue": [ {
"severity": "error",
"code": "processing",
"diagnostics": "HAPI-0899: No code, coding, or codeableConcept provided to
validate"
} ]
}
13.9.2.3 Валидация значения типа Coding
Запрос на валидацию значения типа Coding, содержащего код Y в системе кодирования http://terminology.hl7.org/CodeSystem/v2-0532, в наборе значений с url = http://hl7.org/fhir/ValueSet/yesnodontknow:
POST hapi.fhir.org/baseR5/ValueSet/$validate-code
[заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "url",
"valueUri": "http://hl7.org/fhir/ValueSet/yesnodontknow"
},
{
"name": "coding",
"valueCoding": {
"code": "Y",
"system": "http://terminology.hl7.org/CodeSystem/v2-0532",
display: Yes
}
}
]
}
Ответы те же, что приведены в 13.9.2.2.
13.9.2.4 Валидация значения типа CodeableConcept
Запрос на валидацию значения типа CodeableConcept, содержащего коды Yes и Y в системе кодирования http://terminology.hl7.org/CodeSystem/v2-0532, в наборе значений с url = http://hl7.org/fhir/ValueSet/yesnodontknow:
POST hapi.fhir.org/baseR5/ValueSet/$validate-code
[заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "url",
"valueUri": "http://hl7.org/fhir/ValueSet/yesnodontknow"
},
{
"name": "codeableConcept",
"valueCodeableConcept": {
"coding": [
{
"code": "Yes",
"system": "http://terminology.hl7.org/CodeSystem/v2-0532",
"display": "Да"
},
{
"code": "Y",
"system": "http://terminology.hl7.org/CodeSystem/v2-0532",
display: Yes
}
]
}
}
]
}
Ответ (второй код валиден):
HTTP 400 Bad Request
[заголовки]
<Parameters
xmlns="http://hl7.org/fhir">
<parameter>
<name value="result"/>
<valueBoolean value="true"/>
</parameter>
<parameter>
<name value="message"/>
<valueString value="Code was validated against in-memory expansion of
ValueSet: http://hl7.org/fhir/ValueSet/yesnodontknow"/>
</parameter>
<parameter>
<name value="display"/>
<valueString value="Yes"/>
</parameter>
</Parameters
Примечание - Массив coding в теле запроса просматривается последовательно. Если первый элемент массива валиден, то другие не проверяются. Если первый элемент не принадлежит данной системе кодирования, то проверяется второй элемент и т.д.
Ответы в случае, если все коды не валидны:
HTTP 400 Bad Request
[заголовки]
<Parameters
xmlns="http://hl7.org/fhir">
<parameter>
<name value="result"/>
<valueBoolean value="false"/>
</parameter>
<parameter>
<name value="message"/>
<valueString value="Unknown code 'http://terminology.hl7.org/CodeSystem/
v2-0532#Y1' for in-memory expansion of ValueSet 'http://hl7.org/fhir/ValueSet/
yesnodontknow'"/>
</parameter>
</Parameters>
В ответе последний ошибочный код.
Ответ (ошибка вызова):
HTTP 400 Bad Request
[заголовки]
<OperationOutcome
xmlns="http://hl7.org/fhir">
<text>
<status value="generated"/>
<div
xmlns="http://www.w3.org/1999/xhtml">
<h1>Operation Outcome</h1>
<table border="0">
<tr>
<td style="font-weight: bold;">ERROR</td>
<td>[]</td>
<td>HAPI-0899: No code, coding, or codeableConcept provided to
validate</td>
</tr>
</table>
</div>
</text>
<issue>
<severity value="error"/>
<code value="processing"/>
<diagnostics value="HAPI-0899: No code, coding, or codeableConcept provided
to validate"/>
</issue>
</OperationOutcome>
14 Обмен сообщениями
14.1 Основные положения
Ресурсы могут использоваться в традиционном контексте обмена сообщениями. Сообщения требования передается приложением-источником приложению-получателю при возникновении некоторого события, обычно события реального мира. Сообщение требования состоит из экземпляра ресурса Bundle, имеющего тип message. В него вложены другие экземпляры ресурсов, первый из которых должен иметь тип MessageHeader (заголовок сообщения). Он содержит код события MessageHeader.code, характеризующий природу сообщения требования, и дополнительные метаданные. Какие другие ресурсы будут включены в сообщение, зависит от типа требования.
Приложение-получатель обрабатывает требование и возвращает одно или несколько ответных сообщений, которые также состоят из экземпляра ресурса Bundle типа message и включенных в него экземпляров ресурсов, первым из них должен быть заголовок сообщения MessageHeader, содержащий раздел результата обработки сообщения, за которым следуют экземпляры ресурсов других типов, составляющие содержание ответа. Среди них выделяются так называемые фокальные экземпляры, перечисленные в элементах MessageHeader.focus. Они являются центральными компонентами сообщения; другие экземпляры, включенные в сообщение, должны прямо или косвенно ссылаться на фокальные экземпляры либо (опять-таки прямо или косвенно) быть ссылочными для фокальных экземпляров.
14.2 Механизмы передачи сообщений
Содержание сообщения передается от одного приложения другому с помощью некоторого механизма доставки, после чего приложению-источнику возвращается один или несколько ответов. Точный механизм не имеет значения - им может быть обмен файлами, обмен по протоколу HTTP или что-нибудь другое. Единственное ограничение состоит в том, что требования передаются по известному адресу, а ответы возвращаются приложению-источнику.
Соглашения о содержании сообщений и поведению двух взаимодействующих приложений образуют "контракт", описывающий взаимодействие. Содержание контракта дополняет правила, описанные в настоящей спецификации.
Настоящая спецификация игнорирует существование шлюзов и агентов передачи сообщений, которые могут быть промежуточными узлами между источником и получателем. Они либо прозрачны для содержания сообщения/транзакции, либо активно манипулируют содержанием сообщения (в частности, нередко изменяют заголовки сообщения). Если промежуточные агенты модифицируют содержание сообщения, то они становятся ответственными за выполнение контракта (включая применяемые профили) в обоих направлениях.
Ключевой характеристикой сообщения является воздействие его содержания.
14.3 Воздействие сообщения
Категории воздействия сообщений показаны на рисунке 84 и представлены в таблице 377.
Рисунок 84 - Воздействия сообщений
Таблица 377
Категории воздействия сообщений
Категория
Описание
Требование
Сообщение требует выполнения изменений, которые не следует осуществлять более одного раза, например, бронирование
Запрос
Сообщение запрашивает текущую информацию. Ретроспективная обработка ошибочна или бесполезна
Уведомление
Содержание не обязано быть актуальным и может быть обработано повторно, хотя при обработке старых уведомлений могут возникать проблемы версионности
Некоторые события обмена сообщениями могут быть отнесены к одной из этих категорий, но другим категории не могут быть присвоены заранее, поскольку могут зависеть от содержания, контекста или сценария использования.
14.4 Влияние на получателей
Другим ключевым аспектом сообщения является его влияние на получателей. В некоторых случаях достаточно направить сообщение конечной точке, в других может потребоваться, что сообщение было направлено конкретной организации или конкретному лицу. Соотнесение влияния на получателей с категорией сообщения представлено в таблице 378.
Таблица 378
Соотнесение влияния на получателей с категорией сообщения
Категория
Описание
Требование
Сообщение следует направлять одному и только одному получателю
Запрос
Сообщение может быть направлено одному и только одному получателю
Уведомление
Сообщение может быть направлено одному или нескольким получателям
14.5 Шаблоны обмена сообщениями
На каждое сообщение требования должно быть передано одно или несколько ответных сообщений. Должен быть дан хотя бы один ответ, чтобы отправитель знал, что сообщение было доставлено. В ответ на сообщение требования не должно возвращаться несколько сообщений. Не рекомендуется возвращать несколько ответов на сообщение запроса.
В принципе не требуется, чтобы приложение-источник ожидало ответа на транзакцию прежде чем инициировать новую транзакцию. Но во многих случаях определенный поток сообщений может требовать последовательной обработки. Кроме того, некоторые методы передачи также могут требовать последовательной доставки сообщений.
14.6 Синхронное взаимодействие
Шаблон синхронного взаимодействия, при котором отправитель передает сообщение и ожидает получение единственного ответа по тому же самому каналу передачи данных, а затем передает следующее сообщение, самый легкий для понимания и управления:
а) отправитель передает сообщение получателю (серверу);
б) сервер обрабатывает его и возвращает ответ.
Обычно (хотя не всегда) отправитель ждет ответа на текущее сообщение и только потом посылает новое.
14.7 Асинхронное взаимодействие
Синхронный обмен сообщениями не рассчитан на ситуацию, когда на одно сообщение передается несколько ответов, что имеет место при постраничной передаче результатов запроса, и ограничивает пропускную способность канала передачи данных, что может оказаться существенным при передаче большого объема данных. Кроме того, ожидание ответных сообщений может оказаться неприемлемым. В этих случаях следует использовать асинхронное взаимодействие.
При асинхронном взаимодействии сервер немедленно подтверждает получение сообщения, а ответ на него возвращает отдельно. На одно сообщение сервер может возвратить несколько ответов.
По содержанию заголовка сообщения получатель может определить, является ли оно новым, требующим обработки, или ответом на ранее переданное сообщение. Асинхронная передача сообщений сложнее по реализации, поскольку при ней больше вариантов ошибочных ситуаций. Настоящий стандарт не предписывает никакой протокол обработки ошибок; он оставляется на усмотрение разработчиков взаимодействия.
Обмен сообщениями можно реализовать, используя конечную точку REST в качестве центрального узла. Это не самый эффективный метод, но оно может быть полезен для реализации асинхронного обмена невысокой интенсивности.
Отправитель сообщения использует запрос HTTP POST для передачи ресурса Bundle, содержащего сообщение, конечной точке /Bundle, используя адрес uri, указанный в поле MessageHeader.destination.endpoint. Сервер REST принимает ресурс Bundle, сохраняет его как один ресурс и индексирует его по содержанию заголовка MessageHeader.
Для получения сообщений получатель выполняет поиск всех адресованных ему сообщений, принятых сервером с момента последней проверки:
GET [Базовый_URL]/Bundle?message.destination-uri=[rcv]&_lastUpdated=>2021-03-01T02:00:02+01:00.
Получатель обрабатывает все сообщения, полученные в ответ на этот запрос. После обработки сообщения получатель создает ответ на него, меняя местами источник и получателя, и отправляет обратно на сервер.
Для получения этих ответов источник сообщений запрашивает все адресованные ему сообщения, принятые сервером с момента последней проверки:
GET [Базовый_URL]/Bundle?message.destination-uri=[snd]&message.response-id:missing=false&_lastUpdated=>2021-03-03T06:03:522+01:00.
Этот простой протокол нуждается в администрировании, чтобы несколько взаимодействующих сторон не мешали друг другу, используя одинаковые идентификаторы, а также для исключения злоумышленных атак.
14.8 Идентификаторы и штампы времени в заголовке сообщения
Входящее сообщение имеет два идентификатора: Bundle.id и MessageHeader.id. При создании нового сообщения ему должен быть присвоен идентификатор (MessageHeader.id), уникальный для данного потока сообщений. Поскольку потоки сообщений нередко перемешиваются, рекомендуется присваивать глобально уникальный идентификатор. С этой целью можно использовать UUID или ОИД. При каждой передаче сообщения полю Bundle.id следует присваивать новое значение.
Когда получатель получил и обработал сообщение, он возвращает новое сообщение с новым идентификатором, включенное в экземпляр ресурса Bundle, также имеющий новый идентификатор. Заголовок ответного сообщения повторяет идентификатор сообщения требования MessageHeader.id в поле MessageHeader.response.identifier, чтобы система-источник могла соотнести ответ с требованием.
Сообщение имеет 2 важных штампа даты и времени:
а) Bundle.timestamp: время отправки сообщения;
б) Bundle.meta.lastUpdated: последнее время изменения сообщения (сохранения или модификации).
Кроме того, сообщение может иметь дополнительные штампы даты и времени в полях meta.lastUpdated или других полях вложенных ресурсов. Их назначение зависит от события, по которому передано сообщение.
14.9 Отсутствие надежного транспорта сообщений
Некоторые из механизмов передачи сообщений являются надежными - сообщение всегда доставляется или его источнику возвращается сообщение об ошибке. Однако в большинстве реализаций используются механизмы, не предусматривающие надежный транспорт сообщений и требование или ответ на него могут быть потеряны. Настоящая спецификация описывает простой подход, которому получателю по возможности должны следовать, чтобы обеспечить предсказуемую функциональность.
Если отправитель сообщения реализует надежный транспорт, то по истечении сконфигурированного таймаута ожидания ответного сообщения, заданного в элементе messaging.reliableCache ресурса CapabilityStatement, он должен выполнить действия, указанные в таблице 379.
Таблица 379
Действия по истечении таймаута при надежном транспорте
Категория
Действие
Требование
Повторно отправить сообщение (с тем же самым Message.id) в экземпляре ресурса Bundle с тем же самым Bundle.id
Запрос
Повторно отправить сообщение (с тем же самым Message.id) в экземпляре ресурса с Bundle с другим Bundle.id
Уведомление
Повторно отправить сообщение (с тем же самым Message.id) в экземпляре ресурса с Bundle с другим Bundle.id
Если получатель сообщения реализует надежный транспорт, то он должен проверить Bundle.id и MessageHeader.id в кэше ранее полученных сообщений. Предпринимаемые действия зависят от результата проверки (таблица 380).
Таблица 380
Проверка идентификаторов ранее полученных сообщений
Результат проверки
Действие
Сообщение с такими Bundle.id и MessageHeader.id еще не получалось
Нормальная ситуация, сообщение следует обработать
Сообщение с такими Bundle.id и MessageHeader.id уже было получено
Ранее посланный ответ не был получен источником требования (утерян). Он должен быть послан повторно
Сообщение с таким MessageHeader.id уже было получено, но Bundle.id новый
Сообщение было отправлено источником повторно для обработки. Сервер может либо выполнить повторную обработку, либо отклонить сообщение
Сообщение с таким Bundle.id уже было получено, но MessageHeader.id новый
Ошибка - идентификатор Bundle.id не должен использоваться для другого сообщения
Период кэширования обычно не должен быть слишком большим. Как минимум, он должен быть на 1 минуту дольше таймаута системы-отправителя, но в зависимости от политики повторной отправки сообщений, принятой системой-отправителем, он может быть и больше.
Приложения, реализующие надежный транспорт, объявляют длительность надежного кэша в элементе messaging.reliableCache экземпляра ресурса CapabilityStatement, описывающего возможности приложения.
14.10 Вызов операций над ресурсами с помощью сообщений
Сообщение можно следующим образом использовать для вызова операции, определенной в интерфейсе RESTful:
а) сторона, вызывающая операцию, отправляет сообщение, то есть ресурс Bundle, у которого поле type = message, содержащий ресурс заголовка MessageHeader, поля которого имеют следующие значения:
1) event.system = urn:ietf:rfc:3986;
2) event.code = адрес URL, указанный в поле.url экземпляра ресурса OperationDefinition, содержащего определение вызываемой операции;
3) MessageHeader.focus = ссылка на ресурс Parameters;
4) ресурс Parameters заполняется значениями в соответствии с определением операции;
б) получатель сообщения выполняет затребованную операцию и затем отправляет сообщение, то есть ресурс Bundle, у которого поле type = message, содержащий ресурс заголовка MessageHeader, поля которого имеют следующие значения:
1) тот же код события, что и в исходном сообщении;
2) в поле response заголовка MessageHeader указана ссылка на исходное сообщение и код результата вызова и при наличии - причины ошибки вызова;
3) MessageHeader.focus = ссылка на ресурс Parameters;
4) ресурс Parameters заполняется значениями в соответствии с определением ответа на вызов операции;
5) если в определении операции указано единственное возвращаемое значение, то оно возвращается непосредственно по ссылке из MessageHeader.focus.
Ниже приведен пример:
<Bundle xmlns=http://hl7.org/fhir>
<id value="urn:uuid:77831928-2a35-4c08-9496-8232323bf48c"/>
<!-- Обычное содержание Bundle -->
<entry>
<fullUrl value="urn:uuid:6080d4a7-5e05-45dc-96d5-f75329564d1f"/>
<resource>
<MessageHeader>
<id value="cac8143e-6138-4f45-b086-bb8ebf976aae">
<!-- Обычное содержание заголовка -->
<event>
<system value=urn:ietf:rfc:3986"/>
<!-- Раскрытие набора значений -->
<code value=http://hl7.org/fhir/OperationDefinition/ValueSet-
expand/>
</event>
<!-- Ссылка на параметры раскрытия набора значений -->
<focus>
<reference value="urn:uuid:00213637-dc7c-40d2-a7de-f4ef1eea5685"/>
</focus>
</MessageHeader>
</resource>
</entry>
<entry>
<fullUrl value="urn:uuid:00213637-dc7c-40d2-a7de-f4ef1eea5685"/>
<resource>
<Parameters>
<parameter>
<name value="identifier"/>
<valueUri value="http://hl7.org/fhir/ValueSet/identifier-type"/>
</parameter>
</Parameters>
</resource>
</entry>
</Bundle>
Следует учесть, что операцию нельзя вызвать по URL. Указанным выше способом можно вызывать только операции, определенные на уровне системы или ресурса для конкретного ресурса.
14.11 Осуществление поиска с помощью сообщений
Тем же способом, что вызывается операция, можно выполнить поиск. При поиске также используется ресурс Parameters со следующими правилами:
а) код события должен быть равен search-type или search-system, система кодирования http://hl7.org/fhir/restful-interaction;
б) если тип события равен search-type, то должен быть параметр resourceType, задающий тип искомого ресурса.
Типы параметров поиска преобразуются в типы данных FHIR в соответствии с таблицей 381.
Таблица 381
Преобразование типов параметров поиска в типы данных
Тип параметра поиска
Тип данных
number
integer
date
dateTime
string
string
token
string или Coding (выделение системы кодирования system и кода code)
reference
uri
composite
string
quantity
string или Quantity (в случае разбора синтаксиса)
uri
uri
Пример:
<Bundle xmlns="http://hl7.org/fhir">
<id value="urn:uuid:77831928-2a35-4c08-9496-8232323bf48c"/>
<!-- Обычное содержание Bundle -->
<entry>
<fullUrl value="urn:uuid:c466754c-09c0-4f59-9f76-a48bd0ea27c9"/>
<resource>
<MessageHeader>
<!-- Обычное содержание заголовка -->
<event>
<system value="http://hl7.org/fhir/restful-interaction"/>
<!-- Search against Patient -->
<code value="search-type"/>
</event>
<!-- Ссылка на параметры поиска -->
<data>
<reference value="urn:uuid:59a17a19-46eb-42d9-821a-f93a0c530cac"/>
</data>
</MessageHeader>
</resource>
</entry>
<entry>
<fullUrl value="urn:uuid:59a17a19-46eb-42d9-821a-f93a0c530cac"/>
<resource>
<Parameters>
<parameter>
<name value="resourceType"/>
<valueString value="Person"/>
</parameter>
<parameter>
<name value="gender"/>
<valueString value="m"/>
</parameter>
</Parameters>
</resource>
</entry>
</Bundle>
15 Терминологические ресурсы
15.1 Системы кодирования
15.1.1 Общие требования
Многие элементы ресурсов имеют кодированные значения - строки символов, идентифицирующих определенные "понятия". В настоящем документе кодированные значения всегда трактуются как пары "система" и "код", где "система" идентифицирует систему кодирования, в которой определены "коды". Общий шаблон представления кодированного значения включает в себя следующие компоненты:
а) system - идентификатор URI, идентифицирующий систему кодирования;
б) version - строка, идентифицирующая версию системы кодирования;
в) code - код, однозначно идентифицирующий понятие в системе кодирования и предназначенный для компьютерной обработки;
г) display - имя понятия, определенное в системе кодирования и предназначенное для человеческого восприятия.
Для кодированных значений могут использоваться следующие типы данных:
а) Coding - полностью соответствует этому шаблону;
б) code - содержит только компонент code. Компонент system подразумевается - его значение приведено в определении элемента типа code и не передается в экземпляре ресурса;
в) CodeableConcept - представляет кодируемое понятия в виде текста (в компоненте text) и/или одного или нескольких компонентов типа Coding;
г) CodeableReference - содержит или ссылку на другой экземпляр ресурса (компонент reference) или кодируемое понятие типа CodeableConcept (компонент concept).
Кроме того, кодированные значения могут содержаться в элементах следующих типов:
а) Quantity - этот тип данных имеет компоненты system и code для представления единиц измерения;
б) string - в некоторых случаях значения элемента этого типа ограничены конечным множеством строк, которые могут рассматриваться как кодированные значения, у которых компоненты code и display совпадают;
в) uri - подобно типу данных string, идентификаторы URI также могут трактоваться как кодируемые элементы.
Формальное описание системы кодирования представляется экземпляром ресурса CodeSystem.
15.1.2 Ресурс CodeSystem (система кодирования)
15.1.2.1 Область применения и использования
Ресурс CodeSystem описывает систему кодирования - справочник или классификатор, в том числе иерархический или фасетный.
15.1.2.2 Структура ресурса
Ресурс CodeSystem является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса CodeSystem представлен на рисунке 85 и в таблице 382.
Рисунок 85 - Ресурс CodeSystem
Таблица 382
Состав элементов ресурса CodeSystem
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifierExtension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
url
Канонический идентификатор системы кодирования, представленный в форме URI
uri
0..1
identifier
Объектный идентификатор системы кодирования или иной идентификатор, не зависящий от версии
Identifier
0..*
version
Версия системы кодирования
string
0..1
versionAlgorithm[x]
Алгоритм сравнения версий
*
0..1
name
Имя системы кодирования (для компьютера)
string
0..1
title
Краткое описательное имя системы кодирования (для человека)
string
0..1
status
Статус версии системы кодирования. Позволяет прослеживать жизненный цикл содержания системы кодирования. Допустимые значения: draft (проект) | active (действует) | retired (действие прекращено) | unknown (статус неизвестен)
code
1
experimental
Признак тестовой системы кодирования
boolean
0..1
date
Дата (и необязательное время) публикации системы кодирования. Должна изменяться при смене версии и кода статуса. Кроме того, она должна изменяться, если содержание системы кодирования претерпевает существенные изменения
dateTime
0..1
publisher
Наименование организации или Ф.И.О. издателя, опубликовавшего систему кодирования
string
0..1
contact
Контактная информация издателя
Contact-Detail
0..*
description
Описание системы кодирования для ее потребителя
markdown
0..1
useContext
Контекст использования системы кодирования (по умолчанию - не ограничен)
Usage-Context
0..*
jurisdiction
Юрисдикция, в которой применяется набор значений. Может задавать страну, регион или иную единицу административного деления. Использование запрещено. Вместо него рекомендуется использовать элемент useContext, у которого компонент code имеет значение http://terminology.hl7.org/CodeSystem/usage-context-type#jurisdiction, а компонент valueCodeableConcept - юрисдикцию
Codeable-Concept
0..*
purpose
Назначение системы кодирования
markdown
0..1
copyright
Авторские права на систему кодирования
markdown
0..1
copyrightLabel
Торговая марка и год(ы)
string
0..1
approvalDate
Дата утверждения
date
1
lastReviewDate
Дата последнего пересмотра
date
1
effectivePeriod
Период действия
Period
1
topic
Тема. Использование запрещено. Вместо него рекомендуется использовать элемент useContext, у которого компонент code имеет значение http://terminology.hl7.org/CodeSystem/usage-context-type#topic, а компонент valueCodeableConcept - тему
CodeableConcept
0..*
author
Контактная информация автора
ContactDetail
0..*
editor
Контактная информация редактора
ContactDetail
0..*
reviewer
Контактная информация рецензента
ContactDetail
endorser
Контактная информация одобрившей стороны
ContactDetail
0..*
relatedArtifact
Дополнительная документация, библиография и т.д.
RelatedArtifact
0..*
caseSensitive
Признак учета регистра при сравнении кодов
boolean
0..1
valueSet
Каноническая ссылка на набор значений, содержащий всю данную систему кодирования
canonical
0..1
hierarchyMeaning
Семантика иерархии понятий, представленной в данной системе кодирования. Допустимые значения: grouped-by (группировка) | is-a (детализация) | part-of (целое-часть) | classified-with (классификация) | none (отсутствует)
code
0..1
compositional
Признак, определяет ли данная система кодирования композиционную (то есть пост-координируемую) грамматику
boolean
0..1
versionNeeded
Этот признак указывает, что система кодирования не гарантирует постоянство понятия, связанного с кодом, поэтому вместе с кодом всегда следует указывать номер версии системы кодирования
boolean
0..1
content
Код, указывающий тип содержания системы кодирования. Допустимые значения: not-present (понятия не включены) | example (пример нескольких понятий) | fragment (фрагмент содержания) | complete (полное содержание) | supplement (дополнение)
code
1
supplements
Ссылка на систему кодирования, которую дополняет данный экземпляр ресурса CodeSystem. Чаще всего это используется при переводе системы кодирования на другой язык
canonical
0..1
count
Общее число понятий, описанных в данной системе кодирования. Для композиционной системы кодирования способ подсчета определяется организацией, ответственной за ведение системы кодирования
unsignedInt
0..1
filter
Фильтр, который может использоваться при образовании набора значений из данной системы кодирования. Фильтрация обычно требует указания дополнительного свойства кода для каждого термина, по которому осуществляется фильтрация
BackboneElement
0..*
filter.code
Код, идентифицирующий данный фильтр, когда он используется в элементе ValueSet.compose.include.filter
code
1
filter.description
Описание, как и почему используется фильтр
string
0..1
filter.operator
Оператор, который можно использовать в данном фильтре. Допустимые значения: = (Равно) | is-a (Является) | descendent-of (Потомок) | is-not-a (Не является) | regex (Регулярное выражение) | in (Принадлежит) | not-in (Не принадлежит) | generalizes (Обобщает) | exists (Существует)
code
1..*
filter.value
Описание значения, которое может использоваться в фильтре
string
1
property
Свойство, добавляемое к коду
BackboneElement
0..*
property.code
Код, используемый для идентификации свойства. Он используется внутри системы кодирования (в элементе CodeSystem.concept.property.code), а также снаружи, например, при фильтрации свойств
code
1
property.uri
Ссылка на формальное описание смысла свойства
uri
0..1
property. description
Описание свойства - с какой целью оно определено и как использовать его значение
string
0..1
property.type
Тип значения свойства. Допустимые значения: code | Coding | string | integer | boolean | dateTime | decimal
code
1
concept
Понятие, включенное в систему кодирования
BackboneElement
0..*
concept.code
Код - текстовый символ, однозначно идентифицирующий понятие в системе кодирования
code
1
concept.display
Человеко-читаемая строка, рекомендуемая для представления значения данного кода по умолчанию
string
0..1
concept.definition
Формальное определение понятия. Оно не всегда присутствует в унаследованных системах кодирования, но для новых систем настоятельно рекомендуется
string
0..1
concept. designation
Дополнительное представление понятия - на другом языке, синоним и т.д.
BackboneElement
0..*
concept. designation.language
Язык обозначения понятия
code
0..1
concept.designation.use
Код, указывающий, как используется данное обозначение понятия
Coding
0..1
concept.designation.additionalUse
Дополнительное использование обозначения понятия
Coding
0..*
concept.designation.value
Текстовое значение данного обозначения
string
1
concept.property
Значение свойства данного понятия
BackboneElement
0..*
concept.property. code
Код, являющийся ссылкой на CodeSystem.property.code
code
1
concept.property. value[x]
Значение данного свойства. Допустимые значения: code | Coding | string | integer | boolean | dateTime | decimal
*
1
15.1.2.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 383.
Таблица 383
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
CodeSystem.versionAlgorithm[x]
http://hl7.org/fhir/ValueSet/version-algorithm
Расширяемая
Алгоритм сравнения версий
CodeSystem.status
http://hl7.org/fhir/ValueSet/publication-status
Обязательная
Статус жизненного цикла системы кодирования
CodeSystem.jurisdiction
http://hl7.org/fhir/ValueSet/jurisdiction
Расширяемая
Страны и регионы, для которых предназначена данная система кодирования
CodeSystem.topic
http://hl7.org/fhir/ValueSet/definition-topic
Пример
Категория системы кодирования, используемая для поиска и фильтрации
CodeSystem.hierarchyMeaning
http://hl7.org/fhir/ValueSet/codesystem-hierarchy-meaning
Обязательная
Семантика иерархии понятий в системе кодирования
CodeSystem. content
http://hl7.org/fhir/ValueSet/codesystem-content-mode
Обязательная
Объем представления содержания системы кодирования в ресурсе CodeSystem
CodeSystem.filter.operator
http://hl7.org/fhir/ValueSet/filter-operator
Обязательная
Вид операции, выполняемой как часть фильтра, основанного на значениях свойств
CodeSystem. property.type
http://hl7.org/fhir/ValueSet/concept-property-type
Обязательная
Тип данных значения свойства
CodeSystem. concept.designation. language
http://hl7.org/fhir/ValueSet/languages
Обязательная
Естественный язык
CodeSystem.concept.designation.use
http://hl7.org/fhir/ValueSet/designation-use
Расширяемая
Детали использования обозначения понятия
CodeSystem.concept.designation.additionalUse
http://hl7.org/fhir/ValueSet/designation-use
Расширяемая
Детали использования обозначения понятия
15.1.2.4 Ограничения ресурса CodeSystem
Ограничения ресурса CodeSystem описаны в таблице 384.
Таблица 384
Ограничения ресурса CodeSystem
Идентификатор
Вид
Путь
Описание
Выражение
csd-0
Предупреждение
Базовый
Элемент name должен содержать машинно-обрабатываемое имя, соответствующее синтаксису идентификатора
name.exists() implies name.matches('^[A-Z]([A-Za-z0-9_]){1,254}$')
csd-1
Правило
Базовый
Внутри системы кодирования все коды должны быть уникальными
concept.exists() implies concept.code.combine(%resource.concept.descendants().concept.code).isDistinct()
cnl-1
Предупреждение
CodeSystem.url
Строка URL не должна содержать символы | или # - это препятствует обработке канонических ссылок
exists() implies matches('^[^|#]+$')
csd-2
Предупреждение
Базовый
При наличии неявной иерархии следует заполнить элемент hierarchyMeaning
concept.concept.exists() implies hierarchyMeaning.exists()
csd-3
Предупреждение
Базовый
При наличии неявной иерархии следует заполнить элемент hierarchyMeaning
concept.where(property.code = 'parent' or property.code = 'child').exists() implies hierarchyMeaning.exists()
csd-4
Правило
Базовый
Если элемент content = supplement, то следует указать, какая система кодирования дополняется
CodeSystem.content = 'supplement' implies CodeSystem.supplements.exists()
csd-5
Правило
CodeSystem.concept.designation
Если элемент concept.designation.additionalUse присутствует, то должен присутствовать элемент concept.designation.use
additionalUse.exists() implies use.exists()
15.1.2.5 Особенности идентификации
В ресурсе CodeSystem предусмотрены три идентификатора системы кодирования:
а) CodeSystem.id: логический идентификатор системы кодирования в системе, которая ведет ее экземпляр. При переносе экземпляра ресурса CodeSystem на другой сервер он может измениться;
б) CodeSystem.url: канонический URL, который постоянен для данной системы кодирования и содержится в каждой ее копии. По возможности это должен быть адрес URL содержания исходной версии системы кодирования у ее первоисточника;
в) CodeSystem.identifier: пара system/value, которая используется для идентификации системы кодирования во внешнем контексте. Элемент system идентифицирует схему идентификации, а элемент value - идентификатор системы кодирования, присвоенный согласно данной схеме. Если для идентификации системы кодирования используется объектный идентификатор (ОИД), то system = urn:ietf:rfc:3986, а value = urn:oid:1.2.643.2.40.10.997.1.
15.1.2.6 Версии системы кодирования
Многие системы кодирования с течением времени изменяются. Если при этом меняется значение ранее назначенных кодов, то интерпретация системы кодирования становится зависимой от версии. Это существенно усложняет использование системы кодирования, поэтому такая практика нежелательна. Если значение кодов изменяется, то следует не только присвоить измененной системе кодирования идентификатор версии CodeSystem.version, но и указать признак необходимости учета версии CodeSystem.versionNeeded = true. При передаче кодов такой системы кодирования в экземплярах элементов типа Coding в дополнение к идентификатору системы кодирования system следует также указать идентификатор версии version.
15.1.2.7 Фрагментирование системы кодирования
Система кодирования может распространяться в форме нескольких фрагментов. Содержание такой системы кодирования представляется несколькими экземплярами ресурса CodeSystem, у которых элемент CodeSystem.content имеет значение fragment (фрагмент). Элементы CodeSystem.url у всех фрагментов должны иметь одно и то же значение.
15.1.2.8 Дополнение системы кодирования
Если элемент CodeSystem.content имеет значение supplement (дополнение), то ресурс описывает дополнение системы кодирования. К описанию дополнения применяются следующие правила:
а) элемент CodeSystem.supplements должен иметь значение URL дополняемой системы кодирования;
б) значение элемента CodeSystem.url дополнения не должно передаваться в экземплярах элементов типа Coding в качестве идентификатора системы кодирования system.
Дополнение не может определять новые коды, отсутствующие в дополняемой системе кодирования. Оно используется для добавления новых свойств к существующим кодам или для описания дополнительных обозначений этих кодов.
15.1.2.9 Краткое описание, определение и обозначение
Элемент concept, описывающий кодируемое понятие, имеет компоненты display и definition. Компонент display содержит краткий текст, который может быть представлен пользователю вместо кода. Компонент definition содержит формальное определение кодированного понятия. По возможности эти компоненты должны быть в каждом описании понятия.
В дополнение к краткому значению display и определению definition понятие может иметь несколько обозначений concept.designation. Обозначения могут представлять значения кодов на другом языке или синонимы.
15.1.2.10 Свойства понятий
В системе кодирования могут быть определены дополнительные свойства понятий. Каждое понятие, включенное в систему кодирования, может иметь несколько свойств из числа тех, что определены в этой системе кодирования. Примерами таких свойств могут служить:
а) контрольная цифра кода;
б) дата ввода понятия в действие;
в) дата прекращения действия понятия;
г) структурированная связь с другим понятием этой же или иной системы кодирования.
Идентификаторами свойства служат CodeSystem.property.uri (адрес формального определения свойства, должен быть глобально уникальным) и CodeSystem.property.code (идентификатор свойства, уникален в пределах данной системы кодирования). Код CodeSystem.property.code используется для внутренних ссылок в элементе CodeSystem.concept.property.code, а также для внешних ссылок, например, при описании набора значений в элементе ValueSet.compose.include.filter.property, когда известно, к какой системе кодирования это свойство относится.
Описание свойства содержит элементы, приведенные в таблице 385.
Таблица 385
Компоненты свойства понятия
Имя
Описание
Тип данных
Кратность
code
Идентификатор свойства
code
1
uri
Ссылка на формальное определение свойства, например, в системе кодирования https://www.hl7.org/fhir/codesystem-concept-properties.html.
uri
0..1
description
Описание свойства
string
0..1
type
Тип данных значения свойства. Значения типа code | Coding представляют собой коды, определенные в системе кодирования (той же самой или другой), то есть являются ссылками на другие кодированные понятия
code | Coding | string | integer | boolean | dateTime
1
15.1.2.11 Определения стандартных свойств
Для гармонизации систем кодирования рекомендуется использовать стандартные свойства понятий, определенные в системе кодирования http://hl7.org/fhir/concept-properties (таблица 386).
Таблица 386
Стандартные свойства понятий
URI
Тип значения
Описание
http://hl7.org/fhir/concept-properties#status
code
Статус понятия. Свойство, идентифицируемое данным URI, должно использовать как минимум следующие значения статуса:
active - действующее понятие;
experimental - предусмотрено для тестирования, но в будущем может быть удалено;
deprecated - понятие устарело и в будущем будет удалено;
retired - присутствует по историческим причинам, но не должно использоваться
http://hl7.org/fhir/concept-properties#inactive
boolean
Если понятие не считается действующим, должно иметь значение true. По умолчанию используется значение false
http://hl7.org/fhir/concept-properties#effectiveDate
date
Дата последнего изменения статуса понятия
http://hl7.org/fhir/concept-properties#deprecationDate
date
Дата признания понятия устаревшим
http://hl7.org/fhir/concept-properties#retirementDate
date
Дата запрета на использование понятия
http://hl7.org/fhir/concept-properties#notSelectable
boolean
Понятие используется для группировки других понятий и не должно использоваться самостоятельно (может использоваться для фильтрации и т.д.). Такое понятие именуется абстрактным
http://hl7.org/fhir/concept-properties#parent
code
Прямой родитель понятия в иерархии
http://hl7.org/fhir/concept-properties#child
code
Прямой потомок понятия в иерархии
http://hl7.org/fhir/concept-properties#partOf
code
Понятие, идентифицируемое значением этого свойства (по коду) содержит данное понятие в качестве компонента
http://hl7.org/fhir/concept-properties#synonym
code
Значение этого свойства содержит альтернативный код данного понятия
http://hl7.org/fhir/concept-properties#comment
code
Дополнительные сведения об использовании данного понятия
http://hl7.org/fhir/concept-properties#itemWeight
decimal
Числовое значение, позволяющее сравнивать понятия A numeric value that allows the comparison (меньше, больше) или выполнять иные манипуляции с понятиями
Свойства с идентификаторами http://hl7.org/fhir/concept-properties#parent и http://hl7.org/fhir/concept-properties#child используются для указания отношение родитель/потомок между понятиями.
15.1.2.12 Статус системы кодирования
Статус системы кодирования характеризует состояние ее жизненного цикла. Допустимые значения статуса приведены в таблице 387.
Таблица 387
Состояния системы кодирования
Имя
Значение
Описание
unknown
Статус неизвестен
Статус неизвестен
draft
Проект
Создан проект
active
Действует
Проект утвержден и введен в действие
retired
Действие прекращено
Действие прекращено
15.1.2.13 Иерархии понятий
Система кодирования может иметь иерархическую структуру, используя вложенные элементы concept. Значение отношений иерархии в этом случае определяется элементом hierarchyMeaning. В такой структуре у каждого понятия имеется только один родитель.
В некоторых системах кодирования понятия могут иметь несколько родителей. В этих случаях вместо вложенных элементов concept надо использовать дополнительные свойства property понятий, содержащие ссылки на родительские коды. Можно также воспроизвести основную иерархию с помощью вложения элементов concept, а дополнительные связи обеспечить с помощью свойств property.
15.1.2.14 Параметры поиска экземпляров ресурса CodeSystem
Специальные параметры поиска экземпляров ресурса CodeSystem описаны в таблице 388. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 388
Специальные параметры поиска экземпляров ресурса CodeSystem
Имя
Тип
Описание
Выражение
code
token
Код, определенный в системе кодирования
CodeSystem.concept.code
content-mode
token
not-present | example | fragment | complete | supplement
CodeSystem.content
context
token
Контекст использования, назначенный системе кодирования
(CodeSystem.useContext.value.ofType(CodeableConcept))
context-quantity
quantity
Количественное значение контекста или диапазон количественных значений (если имеются), назначенных системе кодирования
(CodeSystem.useContext.value.ofType(Quantity)) | (CodeSystem.useContext.value.ofType(Range))
context-type
token
Тип контекста, назначенного системе кодирования
CodeSystem.useContext.code
context-type-quantity
composite
Сочетание типа контекста данной системы кодирования и его количественного значения или диапазона значений
On CodeSystem.useContext:
context-type: code
context-quantity: value.ofType(Quantity) | value.ofType(Range)
context-type-value
composite
Сочетание типа контекста данной системы кодирования и его значения
On CodeSystem.useContext:
context-type: code
context: value.ofType(CodeableConcept)
date
date
Дата публикации системы кодирования
CodeSystem.date
derived-from
reference
Ресурс, от которого произведена данная система кодирования
CodeSystem.relatedArtifact.where(-type='derived-from').resource
(Any)
description
string
Описание системы кодирования
CodeSystem.description
effective
date
Предполагаемый период использования
CodeSystem.effectivePeriod
identifier
token
Внешний идентификатор системы кодирования
CodeSystem.identifier
jurisdiction
token
Страна или регион, для которого предназначена система кодирования
CodeSystem.jurisdiction
language
token
Язык обозначений в системе кодирования
CodeSystem.concept. designation.language
name
string
Имя системы кодирования, предназначенное для машинной обработки
CodeSystem.name
predecessor
reference
Предшествующая система кодирования
CodeSystem.relatedArtifact.where(-type='predecessor').resource
(Any)
publisher
string
Наименование издателя системы кодирования
CodeSystem.publisher
status
token
Текущий статус системы кодирования
CodeSystem.status
supplements
reference
Поиск экземпляров ресурса CodeSystem, дополняющих данную систему кодирования
CodeSystem.supplements
(CodeSystem)
system
uri
Схема кодирования всех кодов, определенных в данной системе кодирования (то же, что и 'url')
CodeSystem.url
title
string
Имя системы кодирования, предназначенное для человека
CodeSystem.title
topic
token
Тема, ассоциированная с данной системой кодирования
CodeSystem.topic
url
uri
Значение URI, идентифицирующее данную систему кодирования
CodeSystem.url
version
token
Версия системы кодирования
CodeSystem.version
15.2 Наборы значений
15.2.1 Общие требования
Кодированные значения элемента ресурса могут быть ограничены набором значений, принадлежащих одной или нескольким системам кодирования. Например, значения элемента type ресурса Device, описывающего тип персонального медицинского прибора, могут быть ограничены релевантным подмножеством кодов номенклатуры MDC, описанной в ГОСТ Р 56842.
Наборы значений применяются для валидации содержания экземпляра ресурса при его создании или изменении и для представления списков допустимых значений в интерфейсе пользователя. Идентификаторы url наборов значений никогда не передаются в качестве компонентов system кодированных значений - в этих компонентах могут быть указаны только идентификаторы url систем кодирования. Привязка кодированного элемента ресурса к набору значений задается в экземпляре ресурса StructureDefinition, описывающем структуру ресурса или комплексного типа данных.
Формальное описание набора значений представляется экземпляром ресурса ValueSet.
15.2.2 Ресурс ValueSet (набор значений)
15.2.2.1 Область применения и использования
Ресурс ValueSet служит средством конструирования наборов значений, состоящих из подмножеств кодов, определенных в одной или нескольких системах кодирования. В нем выделяются два основных элемента:
а) compose (сборка), описывающий, какие коды должны быть включены в набор значений;
б) expansion (раскрытие), содержащий список кодов, фактически включенных в набор значений.
Экземпляр ресурса ValueSet может содержать элемент compose или элемент resource, или оба этих элемента одновременно. Для работы с ними предусмотрены следующие операции:
а) $expand, запрашивающая создание или обновление значений элемента expansion по правилам, определенным в содержании элемента compose;
б) $validate-code", запрашивающая проверку принадлежности конкретного кодированного значения к набору значений.
15.2.2.2 Структура ресурса
Ресурс ValueSet является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса ValueSet представлен на рисунке 86 и в таблице 389.
Рисунок 86 - Ресурс ValueSet
Таблица 389
Состав элементов ресурса ValueSet
Имя
Описание
Тип данных
Кратность
Унаследованы от абстрактного класса Resource
id
Логический идентификатор экземпляра ресурса
id
0..1
meta
Метаданные экземпляра ресурса
Meta
0..1
implicitRules
Совокупность правил, по которым должен создаваться экземпляр ресурса
uri
0..1
language
Основной человеческий язык, на котором представлено содержание ресурса
code
0..1
Унаследованы от абстрактного класса DomainResource
text
Текстовое описание содержания экземпляра ресурса для интерпретации человеком
Narrattive
0..1
contained
Вложенный экземпляр ресурса
Resource
0..*
extension
Дополнительное содержание, определенное при реализации
Extension
0..*
modifier-Extension
Модифицирующее расширение, которое не может быть проигнорировано
Extension
0..*
Собственные элементы
url
Канонический идентификатор набора значений, представленный в форме URI
uri
0..1
identifier
Формальный идентификатор набора значений, используемый при его представлении в других форматах или спецификациях
Identifier
0..*
version
Версия набора значений
string
0..1
version-Algorithm[x]
Алгоритм сравнения версий
*
0..1
name
Имя набора значений (для компьютера)
string
0..1
title
Имя набора значений (для человека)
string
0..1
status
Статус версии набора значений. Применяется к метаданным набора значений и к определению набора значений compose. Раскрытие набора значений не имеет статуса. Допустимые значения: draft (проект) | active (действует) | retired (действие прекращено) | unknown (статус неизвестен)
code
1
experimental
Признак тестового набора значений
boolean
0..1
date
Дата (и необязательное время) последнего изменения метаданных или определения набора значений compose
dateTime
0..1
publisher
Наименование организации или Ф.И.О. издателя, опубликовавшего набор значений
string
0..1
contact
Контактная информация издателя
ContactDetail
0..*
description
Описание набора значений
markdown
0..1
useContext
Контекст использования набора значений (по умолчанию - не ограничен)
UsageContext
0..*
immutable
Признак возможности создания новых версий логического определения содержания набора значений
boolean
0..1
purpose
Назначение набора значений
markdown
0..1
copyright
Авторские права на набор значений
markdown
0..1
copyright-Label
Торговая марка и год(ы)
string
0..1
approvalDate
Дата утверждения
date
1
lastReview-Date
Дата последнего пересмотра
date
1
effective-Period
Период действия
Period
1
topic
Тема. Использование запрещено. Вместо него рекомендуется использовать элемент useContext, у которого компонент code имеет значение http://terminology.hl7.org/CodeSystem/usage-context-type#topic, а компонент valueCodeableConcept - тему
CodeableConcept
0..*
author
Контактная информация автора
ContactDetail
0..*
editor
Контактная информация редактора
ContactDetail
0..*
reviewer
Контактная информация рецензента
ContactDetail
-
endorser
Контактная информация одобрившей стороны
ContactDetail
0..*
related-Artifact
Дополнительная документация, библиография и т.д.
RelatedArtifact
0..*
compose
Комплекс критериев, определяющих содержание набора значений с помощью включения или исключения кодов из одной или нескольких систем кодирования. Его называют также логическим определением содержания
BackboneElement
0..1
compose. lockeddate
Дата ввода в действие, используемая для определения версий определений всех ссылочных систем кодирования и наборов значений, включенных в сборку, но не привязанных к конкретной версии
date
0..1
compose. inactive
Признак включения в набор значений неактивных кодов, которые не должны использоваться. Если inactive = true, то неактивные коды должны быть представлены в экземплярах элемента expansion, если inactive = false, то они должны не представляться в экземплярах элемента expansion. Если этот признак отсутствует, то трактовка отсутствия зависит от реализации или от соответствующего параметра операции $expand. Обычно ожидается, что неактивные коды будут представлены
boolean
0..1
compose. include
Включение одного или нескольких кодов из системы кодирования или других наборов значений
BackboneElement
1..*
compose. include.system
Канонический идентификатор ссылочной системы кодирования, представленный в форме URI
uri
0..1
compose. include.version
Версия ссылочной системы кодирования, из которой включаются понятия, или символ *, указывающий все версии
string
0..1
compose. include. concept
Включаемое понятие
BackboneElement
0..*
compose.include.concept.code
Код включаемого понятия
code
0..1
compose.include.concept.display
Краткое описание кодированного понятия для пользователя. Если оно отсутствует, то программа при его визуализации должна использовать значение понятия, определенное в системе кодирования
string
0..1
compose.include.concept.designation
Дополнительное представление понятия - на другом языке, синоним и т.д
BackboneElement
0..*
compose.include. concept.designation.language
Язык обозначения понятия
code
0..1
compose.include. concept.designation.use
Код использования данного обозначения понятия
Coding
0..1
compose.include. concept.designation.additionalUse
Код дополнительного использования данного обозначения понятия
Coding
0..*
compose.include. concept.designation.value
Текстовое значение обозначения понятия
string
1
compose.include. filter
Критерий отбора (фильтрации) кодированных понятий из системы кодирования, основанных на их свойствах (в том числе связях), или из результатов фильтрации по другому критерию. Если задано несколько критериев отбора, то все они должны быть истинными
BackboneElement
0..*
compose.include. filter.property
Код, идентифицирующий свойство значения из системы кодирования или определенный в ней фильтр
code
1
compose.include. filter.op
Оператор, который можно использовать в данном фильтре. Допустимые значения: = (равно) | is-a (является) | descendent-of (потомок) | is-not-a (не является) | regex (регулярное выражение) | in (принадлежит) | not-in (не принадлежит) | generalizes (обобщает) | exists (существует)
code
1
compose.include. filter.value
Код из системы кодирования, или шаблон (для оператора regex), или булевское выражение (для оператора exists)
string
1
compose.include.valueSet
Ссылка на включаемый набор значений
canonical
0..*
compose.include.copyright
Авторские права на систему кодирования, включенную в набор значений
string
0..1
compose.exclude
Исключение одного или нескольких кодов из системы кодирования или из другого набора значений
BackboneElement
1..*
compose.exclude.system
Канонический идентификатор ссылочной системы кодирования, представленный в форме URI
uri
0..1
compose.exclude.version
Версия ссылочной системы кодирования, из которой берутся исключаемые понятия, или символ *, указывающий все версии
string
0..1
compose.exclude. concept
Исключаемое понятие
BackboneElement
0..*
compose.exclude. concept.code
Код исключаемого понятия
code
0..1
compose.exclude. concept.display
Краткое описание кодированного понятия для пользователя. Если оно отсутствует, то программа при его визуализации должна использовать значение понятия, определенное в системе кодирования
string
0..1
compose.exclude. concept.designation
Дополнительное представление понятия - на другом языке, синоним и т.д
BackboneElement
0..*
compose.exclude. concept.designation.language
Язык обозначения понятия
code
0..1
compose.exclude. concept.designation.use
Код использования данного обозначения понятия
Coding
0..1
compose.exclude. concept.designation.additionalUse
Код дополнительного использования данного обозначения понятия
Coding
0..1
compose.exclude. concept.designation.value
Текстовое значение обозначения понятия
string
1
compose.exclude. filter
Критерий отбора (фильтрации) кодированных понятий из системы кодирования, основанных на их свойствах (в том числе связях), или из результатов фильтрации по другому критерию. Если задано несколько критериев отбора, то все они должны быть истинными
BackboneElement
0..*
compose.exclude. filter.property
Код, идентифицирующий свойство значения из системы кодирования или определенный в ней фильтр
code
1
compose.exclude. filter.op
Оператор, который можно использовать в данном фильтре. Допустимые значения: = (равно) | is-a (является) | descendent-of (потомок) | is-not-a (не является) | regex (регулярное выражение) | in (принадлежит) | not-in (не принадлежит) | generalizes (обобщает) | exists (существует)
code
1
compose.exclude. filter.value
Код из системы кодирования, или критерий (для оператора regex), или булевское выражение (для оператора exists)
string
1
compose.exclude. valueSet
Ссылка на исключаемый набор значений
canonical
0..*
compose.exclude. copyright
Авторские права на систему кодирования, включенную в набор значений
string
0..1
compose.property
Свойство, возвращаемое в раскрытии набора значений, если клиент не запросил конкретные свойства. Может представлять собой код из определения свойства в системе кодирования или формальный URL со ссылкой на свойство. Особое значение * означает все свойства, известные серверу
string
0..*
ИС МЕГАНОРМ: примечание.
В официальном тексте документа, видимо, допущена опечатка: одна и та же строка таблицы повторяется дважды.
compose.property
Свойство, возвращаемое в раскрытии набора значений, если клиент не запросил конкретные свойства. Может представлять собой код из определения свойства в системе кодирования или формальный URL со ссылкой на свойство. Особое значение * означает все свойства, известные серверу
string
0..*
expansion
Набор значений может быть также раскрыт, то есть превращен в простую коллекцию перечислимых значений. Результат раскрытия, если оно имело место, хранится в данном элементе
BackboneElement
0..1
expansion. identifier
Уникальный идентификатор раскрытия набора значений
uri
0..1
expansion.next
Ссылка на следующую страницу вывода раскрытия набора значений
uri
0..1
expansion. timestamp
Момент времени, в который осуществлено раскрытие
dateTime
1
expansion.total
Общее число понятий в раскрытии набора значений
integer
0..1
expansion.offset
Если представление раскрытия набора значений осуществляется постранично, то здесь может быть указано смещение от начала раскрытия. Если постраничное представление раскрытия не используется, то этот элемент не должен использоваться
integer
0..1
expansion. parameter
Параметр, управляющий процессом раскрытия набора значений
BackboneElement
0..*
expansion. parameter.name
Имя параметра, контролирующего раскрытие набора значений
string
1
expansion. parameter.value[x]
Значение параметра, контролирующего раскрытие набора значений. Допустимые типы данных: string | boolean | integer | decimal | uri | code | dateTime
*
0..1
expansion. property
Свойство, добавляемое к коду
BackboneElement
0..*
expansion. property.code
Код, идентифицирующий свойство. Используется в элементе expansion.contains.property.code
code
1
expansion. property.uri
Ссылка на формальное описание семантики свойства, например, на систему кодирования http://hl7.org/fhir/concept-properties
uri
0..1
expansion. contains
Код понятия, входящий в раскрытие набора значений
BackboneElement
0..*
expansion. contains.system
Абсолютный идентификатор URI системы кодирования, в которой определен код, включенный в данное раскрытие набора значений
uri
0..1
expansion. contains.abstract
Значение true указывает, что этот код включен только в целях навигации и пользователь не может его выбрать
boolean
0..1
expansion. contains.inactive
Признак неактивности кода в системе кодирования, где он определен
boolean
0..1
expansion. contains.version
Версия системы кодирования, из которой взят данный код
string
0..1
expansion. contains.code
Код значения в иерархии раскрытия набора значений. Если он отсутствует, то данный элемент expansion.contains используется как абстрактный и не представляет допустимый код значения
code
0..1
expansion. contains.display
Человеко-читаемая строка, рекомендуемая для представления значения данного кода
string
0..1
expansion.contains.designation
Дополнительное представление понятия - на другом языке, синоним и т.д.
BackboneElement
0..*
expansion.contains.designation.language
Язык обозначения понятия
code
0..1
expansion.contains.designation.use
Код использования обозначения понятия
Coding
0..1
expansion.contains.designation. additionalUse
Код дополнительного использования данного обозначения понятия
Coding
0..*
expansion.contains.designation.value
Текстовое значение обозначения понятия
string
0..1
expansion.contains. property
Свойство понятия
BackboneElement
0..*
expansion.contains. property.code
Код, идентифицирующий свойство понятия. Должен принадлежать коллекции expansion.property.code
code
1
expansion.contains.property.value[x]
Значение свойства. Допустимые типы данных: string | boolean | integer | decimal |uri | code | dateTime
*
1
expansion.contains. property.subProperty
Субсвойство понятия
BackboneElement
0..*
expansion.contains. property.subProperty code
Код, идентифицирующий субсвойство понятия. Должен принадлежать коллекции expansion.property.code
code
1
expansion.contains. property.subProperty.value[x]
Значение субсвойства. Допустимые типы данных: string | boolean | integer | decimal |uri | code | dateTime
*
1
expansion. contains.contains
Дочерний код или дочерняя запись в иерархии раскрытия набора значений
BackboneElement
0..*
scope
Дополнительные пояснения к описанию набора значений
BackboneElement
0..1
scope. inclusionCriteria
Описание критериев включения понятий или кодов
string
0..1
scope. exclusionCriteria
Описание критериев исключения понятий или кодов
string
0..1
15.2.2.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 390.
Таблица 390
Привязки к наборам значений
Путь
Набор значений
Тип привязки
Описание
ValueSet.versionAlgorithm[x]
http://hl7.org/fhir/ValueSet/version-algorithm
Расширяемая
Алгоритм сравнения версий
ValueSet.status
http://hl7.org/fhir/ValueSet/publication-status
Обязательная
Статус жизненного цикла набора значений
ValueSet. jurisdiction
http://hl7.org/fhir/ValueSet/jurisdiction
Расширяемая
Страны и регионы, для которых предназначен данный набор значений
ValueSet.topic
http://hl7.org/fhir/ValueSet/definition-topic
Пример
Тема
ValueSet.compose.include.concept.designation.language
http://hl7.org/fhir/ValueSet/languages
Предпочтительная
Естественный язык
ValueSet.compose.include.concept.designation.use
http://hl7.org/fhir/ValueSet/designation-use
Расширяемая
Детали использования обозначения понятия
ValueSet.compose.include.concept.designation.additionalUse
http://hl7.org/fhir/ValueSet/designation-use
Расширяемая
Детали использования обозначения понятия
ValueSet.compose.include.filter.op
http://hl7.org/fhir/ValueSet/filter-operator
Обязательная
Вид операции, выполняемой как часть фильтра, основанного на значениях свойств
15.2.2.4 Ограничения ресурса ValueSet
Ограничения ресурса ValueSet приведены в таблице 391.
Таблица 391
Ограничения ресурса ValueSet
Идентификатор
Вид
Путь
Описание
Выражение
cnl-0
Предупреждение
Базовый
Имя должно быть пригодным для использования в качестве идентификатора модуля приложениями машинной обработки, такими как генерация кода
name.exists() implies name.matches('^[A-Z]([A-Za-z0-9_]){1,254}$')
cnl-1
Предупреждение
ValueSet.url
URL не должен содержать | или # - эти символы затрудняют обработку канонических ссылок
exists() implies matches('^[^|# ]+$')
vsd-1
Правило
ValueSet.compose.include
Во включаемом или исключаемом множестве значений (include/exclude) должен быть указан компонент valueSet (ссылка на набор значений) или system (ссылка на систему кодирования)
valueSet.exists() or system.exists()
vsd-2
Правило
ValueSet.compose.include
Во включаемом или исключаемом наборе значений, где указан элемент concept (понятие) или filter (фильтр) должен быть указан элемент system (ссылка на систему кодирования)
(concept.exists() or filter.exists()) implies system.exists()
vsd-3
Правило
ValueSet.compose.include
Элементы concept (понятие) и filter (фильтр) не могут быть указаны одновременно
concept.empty() or filter.empty()
vsd-6
Правило
ValueSet.expansion.contains
Должен быть указан элемент code (код понятия) или display (значение понятия)
code.exists() or display.exists()
vsd-9
Правило
ValueSet.expansion.contains
Если элемент раскрытия набора значений contains не является абстрактным (компонент abstract = true), то должен быть указан компонент code (код понятия)
code.exists() or abstract = true
vsd-10
Правило
ValueSet.expansion.contains
Если указан элемент code (код понятия), то должен быть указан элемент system (ссылка на систему кодирования)
code.empty() or system.exists()
vsd-11
Правило
ValueSet.compose.include.concept. designation
Если элемент concept.designation.additionalUse присутствует, то должен присутствовать элемент concept.designation.use
additionalUse.exists() implies use.exists()
15.2.2.5 Особенности идентификации
В ресурсе ValueSet предусмотрены три идентификатора набора значений:
а) ValueSet.id: логический идентификатор набора значений в системе, которая ведет его экземпляр. В качестве логического идентификатора используется UUID;
б) ValueSet.url: канонический URL который постоянен для данного набора значений и содержится в каждой его копии. В идеале это должен быть адрес URL содержания исходной версии набора значений у его первоисточника, но это не всегда возможно;
в) ValueSet.identifier: пара system/value, которая используется для идентификации набора значений во внешнем контексте. Элемент system идентифицирует схему идентификации, а элемент value - идентификатор системы кодирования, присвоенный согласно данной схеме. Обязательной парой является та, которая указывает объектный идентификатор (ОИД) системы кодирования. В этом случае system = urn:ietf:rfc:3986, а объектный идентификатор представляется в форме URI, например, urn:oid:1.2.643.2.40.10.996.1.
Кроме того, любое раскрытие набора значений имеет собственный идентификатор ValueSet.expansion.identifier, который однозначно идентифицирует это раскрытие.
Элементы identifier и version могут использоваться для ссылки на набор значений при разработке, в профиле или в сообщении.
При передаче кодированных значений (имеющих тип данных Coding или CodeableConcept) указывается только идентификатор системы кодирования, но не набора значений. Описание набора значений служит для форматно-логического контроля кодированного значения. Например, в описании набора значений MeasurementUnits может быть указано, что единица измерения должна браться из ОКЕИ или из UCUM. А в конкретном сообщении должен передаваться код из ОКЕИ или UCUM с указанием идентификатора выбранной системы кодирования. Наличие в сообщения кода из другой системы кодирования считается ошибкой.
15.2.2.6 Интенсиональные и экстенсиональные наборы значений
Набор значений может быть описан как интенсиональный или экстенсиональный. Эти термины восходят к понятиям, которыми оперируют математическая логика и теория множеств.
Интенсиональный набор значений обычно определен алгоритмически. Например, его состав может быть определен правилом "все европейские страны". Интенсиональные наборы значений имеют то достоинство, что они могут динамически обновляться. Если, к примеру, в системе кодирования стран мира появилась новая европейская страна, то она автоматически должна попасть в этот набор значений.
Экстенсиональный набор значений представляет собой перечисление входящих в него кодов. Это позволяет контролировать его состав, но затрудняет обеспечение актуальности.
15.2.2.7 Правила композиции
Правила композиции, то есть получения результирующего набора значений, формулируются следующим образом:
а) набор значений может представлять собой простой список кодов или же критерий выбора кодов из системы кодирования. К таким наборам значений предъявляются следующие требования:
б) операции include (включить) кумулятивны. Набор значений содержит объединение всех результатов применения этой операции;
в) к этому объединению применяются все фильтры и ссылки;
г) в операции include может задаваться одна система кодирования и несколько наборов значений;
д) если указаны только наборы значений (в элементах valueSet), то коды "выбираются" для включения, если они присутствуют в каждом из этих наборов значений (то есть образуется пересечение содержания этих наборов значений);
е) если указана только система кодирования, то применяются следующие правила:
ж) если понятия concept и фильтры filter не заданы, то включаются все коды из данной системы кодирования;
и) если заданы понятия concept, то только они и включаются;
к) если задан фильтр filter, то включаются все коды, удовлетворяющие критерию фильтрации;
л) если заданы и наборы значений, и система кодирования, то коды "включаются", если они выбраны из системы кодирования (после применения операций concept и filter) и входят в каждый ссылочный набор значений (то есть образуется пересечение отфильтрованного содержания системы кодирования с этими наборами значений);
м) если ссылка на систему кодирования не зависит от ее версии и присутствуют фильтры filter, то содержание результирующего набора значений является открытым и изменяется с течением времени по мере изменения ссылочной системы кодирования;
н) использование фильтров по свойствам кодов, описанным в системе кодирования, возможно только в случае, если соответствующее свойство в ней определено;
о) в дополнение к включению можно исключать коды. Операция исключения exclude трактуется так же, как операция включения include, но выбранные с ее помощью коды исключаются из результирующего набора значений;
п) наборы значений могут включать в себя абстрактные коды, то есть коды, взятые из соответствующей системы кодирования, но помеченные как запрещенные для выбора пользователем. Они обычно используются в качестве механизма группировки и могут включаться в результирующий набор путем перечисления или с помощью фильтрации;
р) все операции исключения compose.exclude должны обрабатываться таким образом, чтобы исключенные коды не могли попасть в раскрытие набора значений expansion.
15.2.2.8 Набор значений, образованный из нескольких систем кодирования
В набор значений могут входить коды, принадлежащие разным системам кодирования. Типичным случаем является выборка основной части кодов из одной системы кодирования и добавление к ней нескольких дополнительных кодов [например, кода для Союзного государства в дополнение к ОКВ ОК (МК (ИСО 4217) 003-97) 014].
15.2.2.9 Раскрытие набора значений
Раскрытие набора значений представляет собой результат применения определения набора значений. Раскрытия наиболее полезны, если набор значений включает в себя все коды, определенные в системе кодирования, или отфильтрованное подмножество этих кодов.
Экземпляр ресурса ValueSet, представляющий собой раскрытый набор значений, содержит элемент ValueSet.expansion, содержащий список кодов, входящих в этот набор. Дополнительно он может содержать элемент ValueSet.compose, описывающий алгоритм получения этого списка. Список кодов может быть иерархическим.
15.2.2.10 Параметры поиска экземпляров ресурса ValueSet
Специальные параметры поиска экземпляров ресурса ValueSet описаны в таблице 392. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 392
Специальные параметры поиска экземпляров ресурса ValueSet
Имя
Тип
Описание
Выражение
code
token
Код, входящий в набор значений
ValueSet.expansion.contains.code | ValueSet.compose.include.concept.code
context
token
Контекст использования, назначенный набору значений
(ValueSet.useContext.value.ofType(CodeableConcept))
context-quantity
quantity
Количественное значение контекста или диапазон количественных значений (если имеются), назначенных набору значений
(ValueSet.useContext.value.ofType(Quantity)) | (ValueSet.useContext.value.ofType(Range))
context-type
token
Тип контекста, назначенного набору значений
ValueSet.useContext.code
context-type-quantity
composite
Тип использования контекста и количественное значение контекста или диапазон количественных значений (если имеются), назначенных набору значений
On ValueSet.useContext:
context-type: code
context-quantity: value.ofType(Quantity) | value.ofType(Range)
context-type-value
composite
Тип использования контекста и значение, входящее в набор значений
On ValueSet.useContext:
context-type: code
context: value.ofType(CodeableConcept)
date
date
Дата публикации набора значений
ValueSet.date
derived-from
reference
Экземпляр ресурса, от которого произведен набор значений
ValueSet.relatedArtifact. where(type='derived-from').resource
(Any)
description
string
Описание набора значений
ValueSet.description
effective
date
Предполагаемый период использования
ValueSet.effectivePeriod
expansion
uri
Идентификатор раскрытия набора значений
ValueSet.expansion.identifier
identifier
token
Внешний идентификатор набора значений
ValueSet.identifier
jurisdiction
token
Страна или регион, для которого предназначен набор значений
ValueSet.jurisdiction
name
string
Имя набора значений, предназначенное для машинной обработки
ValueSet.name
predecessor
reference
Предшественник набора значений
ValueSet.relatedArtifact.where(type='predecessor').resource
(Any)
publisher
string
Наименование издателя набора значений
ValueSet.publisher
reference
uri
Ссылка на систему кодирования, включенную в набор значений или исключенную из него, или ссылка на набор значений
ValueSet.compose.include.system
status
token
Текущий статус набора значений
ValueSet.status
title
string
Имя набора значений, предназначенное для человека
ValueSet.title
topic
token
Тема, ассоциированная с данным набором значений
ValueSet.topic
url
uri
Идентификатор URI набора значений
ValueSet.url
version
token
Версия набора значений
ValueSet.version
16 Аутентификация и авторизация
Аутентификация персональных медицинских приборы осуществляется менеджерами ПМП и шлюзами Интернета вещей в соответствии с используемыми протоколами передачи данных, например, MQTT или Bluetooth. Варианты аутентификации и авторизации менеджеров (шлюзов) сервисом хранения и обработки результатов измерений предложены в технической статье [41], которую предполагается доработать до статуса стандарта ITU-T H.812.5. В частности, рекомендуется использовать протокол OAuth 2.0 [42] и профиль JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants [43].
Приложение А
(справочное)
ПРОФИЛЬ UML
А.1 Общие сведения
При разработке типов данных и ресурсов на языке UML используется профиль, состав которого показан на рисунке А.1.
Рисунок А.1 - Состав профиля UML
Профиль UML состоит из стереотипов, перечисленных в таблице А.1.
Таблица А.1
Стереотипы профиля UML
Имя
Применение
Описание
Подраздел
Binding
Элемент
Привязка элемента к набору значений
Constraint
Элемент, класс
Ограничение элемента или класса
Extension
Элемент, класс, тип данных
Метаданные расширения элемента, класса или типа данных
Interface
Класс
Ресурс REST служит интерфейсом
Modifying
Элемент
Описание модификации семантики ресурса в зависимости от значения элемента
Profile
Класс
Метаданные профиля ресурса REST
RefTarget
Поле
Метаданные ссылки на ресурс REST
Resource
Класс
Ссылка на определение ресурса REST
Slice
Элемент
Метаданные группировок экземпляров повторяющегося элемента
TypeChoice
Элемент
Допустимые типы данных полиморфного элемента
А.2 Стереотип Binding
Стереотип Binding описывает привязку элемента к набору значений. Его атрибуты приведены в таблице А.2.
Таблица А.2
Атрибуты стереотипа Binding
Имя
Описание
Тип
Кратность
valueSet
URL набора значений
String
1
strength
Степень привязки к набору значений: ?? (пример привязки) | ? (предпочтительная привязка) |+ (расширяемая привязка) | ! (обязательная привязка)
String
1
description
Описание привязки
String
1
А.3 Стереотип Constraint
Стереотип Constraint описывает ограничение элемента или класса. Его атрибуты приведены в таблице А.3. В списках в качестве разделителей используется символ вертикальной черты (|).
Таблица А.3
Атрибуты стереотипа Constraint
Имя
Описание
Тип
Кратность
key
Список идентификаторов ограничений
String
1
level
Список строгости ограничений
String
1
location
Список мест применения ограничений
String
1
description
Список описаний ограничения
String
1
expression
Список логических выражений на языке FHIRPath, которые должны быть истинными (инварианты)
String
1
А.4 Стереотип Extension
Стереотип Extension описывает метаданные расширения элемента, класса или типа данных. Его атрибуты приведены в таблице А.4.
Таблица А.4
Атрибуты стереотипа Extension
Имя
Описание
Тип
Кратность
identity
Идентификатор расширения
String
1
cardinality
Кратность расширения
String
1
type
Тип данных расширения
String
1
context
Контекст расширения
String
1
А.5 Стереотип Interface
Стереотип Interface указывает, что данный тип ресурса REST является интерфейсом.
А.6 Стереотип Modifying
Стереотип Modifying указывает, что значение элемента может изменять семантику экземпляра ресурса. Его атрибуты приведены в таблице А.5.
Таблица А.5
Атрибуты стереотипа Modifying
Имя
Описание
Тип
Кратность
meaning
Описание изменения семантики
String
1
А.7 Стереотип Profile
Стереотип Profile указывает, что данный класс является профилем ресурса REST или другого профиля. Его атрибуты приведены в таблице А.6.
Таблица А.6
Атрибуты стереотипа Profile
Имя
Описание
Тип
Кратность
baseDefinition
URL определения базового типа ресурса или профиля
String
1
derivation
Способ определения профиля: specialization (специализация) | constraint (ограничение)
String
1
А.8 Стереотип RefTarget
Стереотип RefTarget описывает допустимые типы ссылочных ресурсов. Его атрибуты приведены в таблице А.7. В списке в качестве разделителей используется символ вертикальной черты (|).
Таблица А.7
Атрибуты стереотипа RefTarget
Имя
Описание
Тип
Кратность
target
Список типов ссылочных ресурсов или Any (любой)
String
1
А.9 Стереотип Resource
Стереотип Resource указывает, что данный класс является основным в определении типа ресурса. Его атрибуты приведены в таблице А.8.
Таблица А.8
Атрибуты стереотипа Resource
Имя
Описание
Тип
Кратность
url
URL описания типа ресурса
String
1
А.10 Стереотип Slice
Стереотип Slice указывает, что коллекция экземпляров данного элемента разбивается на непересекающиеся подмножества. Его атрибуты приведены в таблице А.9.
Таблица А.9
Атрибуты стереотипа Slice
Имя
Описание
Тип
Кратность
discriminatorType
Тип дискриминатора: value (срезы различаются по значению элемента) | exists (срезы различаются по наличию или отсутствию элемента) | type (срезы различаются по типу элемента) | profile (срезы различаются по соответствию элемента заданному профилю) | position (срезы различаются по индексу элемента)
String
1
discriminatorPath
Путь к элементу, используемому для выделения срезов. Задается с использованием ограниченного подмножества языка FHIRPath
String
1
А.11 Стереотип TypeChoice
Стереотип TypeChoice описывает допустимые типы данных полиморфного элемента. Его атрибуты приведены в таблице А.10. В списке в качестве разделителей используется символ вертикальной черты (|).
Таблица А.10
Атрибуты стереотипа TypeChoice
Имя
Описание
Тип
Кратность
datatype
Список допустимых типов данных
String
1
Приложение Б
(справочное)
ПРИМЕР ПЛАНА ДИСТАНЦИОННОГО МОНИТОРИНГА
Б.1 Текстовое содержание плана для представления пациенту
Целевой уровень домашнего артериального давления:
- систолическое от 100 до 140;
- диастолическое от 60 до 90.
Лечение препаратом индапамид + рамиприл (0.625 мг + 2.5 мг), торговое наименование Консилар-Д24, один раз в день, предпочтительно утром. Капсулы необходимо проглатывать целиком и запивать достаточным количеством воды.
Ограничение потребления поваренной соли до 6 г/сут.
Аэробные нагрузки два раза в день по 30 мин.
Этапный эпикриз через две недели.
Измерение артериального давления 2 раза в день.
Ведение дневника приема лекарств.
Ведение дневника физической активности.
Для выполнения плана пациенту выдан тонометр ГемоДин-АКСМА (серийный номер 1234567).
Б.2 Структурированное содержание плана
Структурированное содержание плана дистанционного мониторинга включает в себя экземпляры ресурсов, перечисленные в таблице Б.1
Таблица Б.1
Структурированное содержание плана
дистанционного мониторинга
Ресурс
Профиль
Содержание
Patient
Patient-Dm
Идентификация пациента
Device
Device-Phg
Идентификация шлюза Интернета вещей
Device
Device-Phd
Идентификация персонального медицинского прибора
DeviceAssociation
DeviceAssociation-Dm
Привязка ПМП к пациенту
Goal
Goal-Dm
Целевой диапазон значений систолического артериального давления
Goal
Goal-Dm
Целевой диапазон значений диастолического артериального давления
Practitioner
Practitioner-Dm
Идентификация лечащего врача
CarePlan
CarePlan-Dm
План дистанционного мониторинга
Observation
http://hl7.org/fhir/StructureDefinition/vitalsigns
Рост пациента
Observation
http://hl7.org/fhir/StructureDefinition/vitalsigns
Вес пациента
Observation
http://hl7.org/fhir/StructureDefinition/vitalsigns
Возраст пациента (оценочный)
Task
Task-Medication
Лекарственное назначение
Task
Task-MedStat
Ведение дневника приема лекарств
Task
Task-NutrInt
Ведение дневника питания
Task
Task-QuestResp
Ведение дневника самонаблюдений
Task
Task-Phd
Измерение артериального давления
Task
Task-DiagRep
Составление этапного эпикриза
ИС МЕГАНОРМ: примечание.
В официальном тексте документа, видимо, допущена опечатка: имеется в виду рисунок Б.1, а не Б.2.
Между экземплярами ресурсов установлены ссылки, показанные на рисунке Б.2. Тем самым образован граф примера плана дистанционного мониторинга. Наличие ссылок позволяет сократить число запросов HTTP GET, необходимых для считывания полного содержания плана, с помощью использования параметров управления результатами поиска _include и _revinclude.
Рисунок Б.1 - Граф плана дистанционного мониторинга
Б.3 Транзакция создания плана
Тело транзакции создания плана представляет собой контейнер Bundle типа transaction, в который вложены экземпляры ресурсов, перечисленные в таблице Б.1 Для каждого экземпляра указан метод создания HTTP POST и условие создания ifNoneExist, согласно которому экземпляр создается только в том случае, если на сервере отсутствует экземпляр с таким же идентификатором identifier.
Чтобы можно было воспользоваться параметрами управления результатами поиска _include и _revinclude и в то же время осуществлять поиск по идентификаторам identifier, каждая ссылка между экземплярами ресурсов имеет следующий вид:
<reference value=полный URL ссылочного экземпляра ресурса/>
<type value=тип ссылочного ресурса/>
<identifier>
<system value=схема идентификации/>
<value value=значение идентификатора/>
</identifier>
Тело транзакции представлено на языке XML, чтобы можно было включить в него комментарии. При создании экземпляров ресурсов комментарии не сохраняются.
При проверке примера валидатором https://validator.fhir.org/ будут выданы ошибки и предупреждения. Ошибками помечены элементы profile, например, <profile value="Device-Phg"/>. Это связано с тем, что значение профиля должно представлять собой абсолютный URL, но указать базовый URL, который должен предшествовать имени профиля, в настоящем документе не представляется возможным - он должен вести на конкретную страницу платформы медицинских помощников. Большинство предупреждений связано с тем, что в кодируемых значениях указан компонент system, идентифицирующий систему кодирования, не известную валидатору, например, http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers.
<?xml version="1.0" encoding="UTF-8"?>
<Bundle xmlns="http://hl7.org/fhir" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance">
<!-- Тип контейнера - транзакция -->
<type value="transaction"/>
<!-- Дата и время формирования контейнера -->
<timestamp value="2023-11-10T12:15:23+03:00"/>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<resource>
<!-- Идентификация пациента -->
<Patient>
<meta>
<!-- Имя профиля -->
<profile value="Patient-Dm"/>
</meta>
<!-- Уникальный идентификатор (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</Patient>
</resource>
<!-- Создать экземпляр ресурса Patient при условии, что нет экземпляра с
таким же идентификатором -->
<request>
<method value="POST"/>
<url value="Patient"/>
<ifNoneExist value="identifier=urn:uuid:1d5706b0-d040-4602-b9fd-
c6ff445c5793"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:f9f2cab0-8a46-454d-b70a-c06582be1a61"/>
<resource>
<!-- Идентификация шлюза IoT -->
<Device>
<meta>
<!-- Имя профиля -->
<profile value="Device-Phg"/>
</meta>
<!-- Уникальный идентификатор в формате EUI-64. В качестве
идентификатора можно использовать MAC-адрес -->
<identifier>
<type>
<coding>
<system value="http://hl7.org/fhir/uv/phd/CodeSystem/
ContinuaDeviceIdentifiers"/>
<code value="SYSID"/>
</coding>
</type>
<system value="urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680"/>
<value value="ED-AB-EE-DE-AD-77-C3-AA"/>
</identifier>
<!-- Тип прибора - шлюз -->
<type>
<coding>
<system value="urn:iso:std:iso:11073:10101"/>
<code value="531981"/>
</coding>
<text value="MDC_MOC_VMS_MDS_AHD: Шлюз IoT или менеджер ПМП"/>
</type>
</Device>
</resource>
<!-- Создать экземпляр ресурса Device при условии, что нет экземпляра с
таким же идентификатором -->
<request>
<method value="POST"/>
<url value="Device"/>
<ifNoneExist value="identifier=ED-AB-EE-DE-AD-77-C3-AA"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:bfc0c54d-aa0d-47bb-90fc-66d407fd81d0"/>
<resource>
<!-- Идентификация персонального медицинского прибора -->
<Device>
<meta>
<!-- Имя профиля -->
<profile value="Device-Phd"/>
</meta>
<!-- Уникальный идентификатор в формате EUI-64. Возвращается прибором
по запросу.
Если прибор соответствует ГОСТ Р 56845-2019, то это атрибут System-
Id объекта MDS
-->
<identifier>
<type>
<coding>
<system value="http://hl7.org/fhir/uv/phd/CodeSystem/
ContinuaDeviceIdentifiers"/>
<code value="SYSID"/>
</coding>
</type>
<system value="urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680"/>
<value value="FE-ED-AB-EE-DE-AD-77-C3"/>
</identifier>
<!-- Производитель прибора. Возвращается прибором по запросу -->
<manufacturer value="ООО &quot;АКСМА&quot;, г. Балашиха"/>
<!-- Серийный номер прибора. Возвращается прибором по запросу -->
<serialNumber value=1234567/>
<!-- Модель прибора. Возвращается прибором по запросу -->
<modelNumber value=ГемоДин-АКСМА/>
<!-- Тип прибора - ПМП -->
<type>
<coding>
<system value="urn:iso:std:iso:11073:10101"/>
<code value="65573"/>
</coding>
<text value="MDC_MOC_VMS_MDS_SIMP"/>
</type>
<!-- Версии компонентов прибора. Возвращаются прибором по запросу -->
<version>
<!-- Версии аппарата -->
<type>
<coding>
<system value="urn:iso:std:iso:11073:10101"/>
<code value="531974"/>
</coding>
<text value="MDC_ID_PROD_SPEC_HW"/>
</type>
<value value="1.1.2"/>
</version>
<version>
<!-- Версии прошивки -->
<type>
<coding>
<system value="urn:iso:std:iso:11073:10101"/>
<code value="531976"/>
</coding>
<text value="MDC_ID_PROD_SPEC_FW"/>
</type>
<value value="6.3.4"/>
</version>
<conformsTo>
<!-- Специализация прибора -->
<specification>
<coding>
<system value="urn:iso:std:iso:11073:10101"/>
<code value="528391"/>
</coding>
<text value="MDC_DEV_SPEC_PROFILE_BP: Тонометр"/>
</specification>
</conformsTo>
<!-- Ссылка на шлюз, получающий данные от прибора -->
<gateway>
<reference>
<reference value="urn:uuid:f9f2cab0-8a46-454d-b70a-c06582be1a61"/>
<type value="Device"/>
<identifier>
<type>
<coding>
<system value="http://hl7.org/fhir/uv/phd/CodeSystem/
ContinuaDeviceIdentifiers"/>
<code value="SYSID"/>
</coding>
</type>
<system value="urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680"/>
<value value="ED-AB-EE-DE-AD-77-C3-AA"/>
</identifier>
</reference>
</gateway>
</Device>
</resource>
<!-- Создать экземпляр ресурса Device при условии, что нет экземпляра с
таким же идентификатором -->
<request>
<method value="POST"/>
<url value="Device"/>
<ifNoneExist value="identifier=FE-ED-AB-EE-DE-AD-77-C3"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:0c20196d-92c0-4a6f-a3a8-44f452b3fb19"/>
<resource>
<!-- Привязка ПМП к пациенту -->
<DeviceAssociation>
<meta>
<!-- Имя профиля -->
<profile value="DeviceAssociation-Dm"/>
</meta>
<!-- Уникальный идентификатор привязки (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:6fc39ea7-06b4-4c61-95b2-3ea1c0b37334"/>
</identifier>
<!-- Ссылка на идентификацию ПМП -->
<device>
<reference value="urn:uuid:f9f2cab0-8a46-454d-b70a-c06582be1a61"/>
<identifier>
<type>
<coding>
<system value="http://hl7.org/fhir/uv/phd/CodeSystem/
ContinuaDeviceIdentifiers"/>
<code value="SYSID"/>
</coding>
</type>
<system value="urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680"/>
<value value="ED-AB-EE-DE-AD-77-C3-AA"/>
</identifier>
</device>
<!-- Статус привязки -->
<status>
<coding>
<system value="http://hl7.org/fhir/deviceassociation-status"/>
<code value="unknown"/>
</coding>
</status>
<!-- Ссылка на идентификацию пациента -->
<subject>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</subject>
</DeviceAssociation>
</resource>
<!-- Создать экземпляр ресурса DeviceAssociation при условии, что нет
экземпляра с таким же идентификатором -->
<request>
<method value="POST"/>
<url value="DeviceAssociation"/>
<ifNoneExist value="identifier=urn:uuid:6fc39ea7-06b4-4c61-95b2-
3ea1c0b37334"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:1e7d69b0-6985-4546-a1b2-8c5bac31218c"/>
<resource>
<!-- Цель ведения N1 -->
<Goal>
<meta>
<!-- Имя профиля -->
<profile value="Goal-Dm"/>
</meta>
<text>
<status value="additional"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Целевой уровень систолического артериального давления</p>
<p>больше 100 и меньше 140</p>
</div>
</text>
<!-- Уникальный идентификатор цели (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:2cf15749-7b55-4980-a856-6146740438f0"/>
</identifier>
<!-- Состояние жизненного цикла цели -->
<lifecycleStatus value="active"/>
<!-- Описание цели -->
<description>
<text value=Систолическое артериальное давление от 100 до 140/>
</description>
<!-- Ссылка на идентификацию пациента -->
<subject>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</subject>
<!-- Целевой показатель -->
<target>
<!-- Вид измерения -->
<measure>
<!-- Код вида измерения в системе LOINC -->
<coding>
<system value="http://loinc.org"/>
<code value=8480-6/>
</coding>
<!-- Код вида измерения в НСИ Минздрава России -->
<coding>
<system value="urn:oid:1.2.643.5.1.13.13.99.2.262"/>
<code value=3/>
<display value=Артериальное давление систолическое/>
</coding>
<text value=Систолическое артериальное давление/>
</measure>
<!-- Целевой диапазон -->
<detailRange>
<!-- Нижняя граница -->
<low>
<value value="100"/>
<unit value="мм.рт.ст."/>
<system value="http://unitsofmeasure.org"/>
<code value="mm[Hg]"/>
</low>
<!-- Верхняя граница -->
<high>
<value value="140"/>
<unit value="мм.рт.ст."/>
<system value="http://unitsofmeasure.org"/>
<code value="mm[Hg]"/>
</high>
</detailRange>
</target>
<!-- Дата текущего состояния цели -->
<statusDate value=2023-11-21/>
</Goal>
</resource>
<!-- Создать экземпляр ресурса Goal при условии, что нет экземпляра с таким
же идентификатором -->
<request>
<method value="POST"/>
<url value="Goal"/>
<ifNoneExist value="identifier=urn:uuid:2cf15749-7b55-4980-a856-
6146740438f0"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:ac884dc1-6637-4f1e-975f-bede48879fb5"/>
<resource>
<!-- Цель ведения N2 -->
<Goal>
<meta>
<!-- Имя профиля -->
<profile value="Goal-Dm"/>
</meta>
<text>
<status value="additional"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Целевой уровень диастолического артериального давления</p>
<p>больше 60 и меньше 90</p>
</div>
</text>
<!-- Уникальный идентификатор цели (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1db18272-93ca-412d-81ed-bf46b1c0713c"/>
</identifier>
<!-- Состояние жизненного цикла цели -->
<lifecycleStatus value="active"/>
<!-- Описание цели -->
<description>
<text value="Диастолическое артериальное давление от 60 до 90"/>
</description>
<!-- Ссылка на идентификацию пациента -->
<subject>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</subject>
<!-- Целевой показатель -->
<target>
<!-- Вид измерения -->
<measure>
<!-- Код вида измерения в системе LOINC -->
<coding>
<system value="http://loinc.org"/>
<code value="8462-4"/>
</coding>
<!-- Код вида измерения в НСИ Минздрава России -->
<coding>
<system value="urn:oid:1.2.643.5.1.13.13.99.2.262"/>
<code value="2"/>
<display value="Артериальное давление диастолическое"/>
</coding>
<text value="Диастолическое артериальное давление"/>
</measure>
<!-- Целевой диапазон -->
<detailRange>
<!-- Нижняя граница -->
<low>
<value value="60"/>
<unit value="мм.рт.ст."/>
<system value="http://unitsofmeasure.org"/>
<code value="mm[Hg]"/>
</low>
<!-- Верхняя граница -->
<high>
<value value="90"/>
<unit value="мм.рт.ст."/>
<system value="http://unitsofmeasure.org"/>
<code value="mm[Hg]"/>
</high>
</detailRange>
</target>
<!-- Дата текущего состояния цели -->
<statusDate value=2023-11-21/>
</Goal>
</resource>
<!-- Создать экземпляр ресурса Goal при условии, что нет экземпляра с таким
же идентификатором -->
<request>
<method value="POST"/>
<url value="Goal"/>
<ifNoneExist value="identifier=urn:uuid:1db18272-93ca-412d-81ed-
bf46b1c0713c"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:92fdce2b-8701-4dc2-aff7-10f13e15c44f"/>
<resource>
<!-- Идентификация лечащего врача -->
<Practitioner>
<meta>
<!-- Имя профиля -->
<profile value="Practitioner-Dm"/>
</meta>
<!-- Уникальный идентификатор лечащего врача (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:5e0afd03-76e0-403e-9b17-06f477fd9a55"/>
</identifier>
<!-- Телекоммуникационные адреса -->
<telecom>
<system value="url"/>
<value value="https://t.me/practitioner123"/>
</telecom>
<telecom>
<system value="email"/>
<value value="practitioner123@mail.ru"/>
</telecom>
</Practitioner>
</resource>
<!-- Создать экземпляр ресурса Practitioner при условии, что нет экземпляра
с таким же идентификатором -->
<request>
<method value="POST"/>
<url value="Practitioner"/>
<ifNoneExist value="identifier=urn:uuid:5e0afd03-76e0-403e-9b17-
06f477fd9a55"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:e0144d84-172e-4514-811e-7e2546358977"/>
<resource>
<!-- План дистанционного мониторинга -->
<CarePlan>
<meta>
<profile value="CarePlan-Dm"/>
</meta>
<text>
<status value="additional"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Целевой уровень домашнего артериального давления:</p>
<p>- систолическое от 100 до 140</p>
<p>- диастолическое от 60 до 90</p>
<p>Лечение препаратом индапамид + рамиприл (0.625 мг + 2.5 мг),
торговое наименование Консилар-Д24, предпочтительно утром</p>
<p>Капсулы необходимо проглатывать целиком и запивать достаточным
количеством воды</p>
<p>Ограничение потребления поваренной соли до 6 г/сут</p>
<p>Аэробные нагрузки два раза в день по 30 мин</p>
<p>Этапный эпикриз через две недели</p>
<p>Измерение артериального давления 2 раза в день</p>
<p>Ведение дневника приема лекарств</p>
<p>Ведение дневника физической активности</p>
<p>Тонометр ГемоДин-АКСМА серийный номер 1234567</p>
</div>
</text>
<!-- Уникальный идентификатор плана ведения (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:c3eab073-5fe2-4a5d-bcbf-6d59aeed4004"/>
</identifier>
<status value="active"/>
<intent value="plan"/>
<!-- Категория плана ведения -->
<category>
<text value="Дистанционный мониторинг"/>
</category>
<description value="Достижение целевого уровня артериального
давления"/>
<!-- Ссылка на идентификацию пациента -->
<subject>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</subject>
<!-- Начало действия плана -->
<period>
<start value="2023-11-20"/>
</period>
<!-- Ссылка на идентификацию лечащего врача -->
<custodian>
<reference value="urn:uuid:92fdce2b-8701-4dc2-aff7-10f13e15c44f"/>
<type value="Practitioner"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:5e0afd03-76e0-403e-9b17-06f477fd9a55"/>
</identifier>
</custodian>
<!-- Ссылка на цель ведения N1 -->
<goal>
<reference value="urn:uuid:1e7d69b0-6985-4546-a1b2-8c5bac31218c"/>
<type value="Goal"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:2cf15749-7b55-4980-a856-6146740438f0"/>
</identifier>
</goal>
<!-- Ссылка на цель ведения N2 -->
<goal>
<reference value="urn:uuid:ac884dc1-6637-4f1e-975f-bede48879fb5"/>
<type value="Goal"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1db18272-93ca-412d-81ed-bf46b1c0713c"/>
</identifier>
</goal>
</CarePlan>
</resource>
<!-- Создать экземпляр ресурса CarePlan при условии, что нет экземпляра с
таким же идентификатором -->
<request>
<method value="POST"/>
<url value="CarePlan"/>
<ifNoneExist value="identifier=urn:uuid:c3eab073-5fe2-4a5d-bcbf-
6d59aeed4004"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:1d5ec929-ec43-4ef0-9ef6-0a80c9095312"/>
<resource>
<!-- Рост пациента -->
<Observation>
<meta>
<profile value="http://hl7.org/fhir/StructureDefinition/
vitalsigns"/>
</meta>
<!-- Уникальный идентификатор измерения (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:b85497fe-14e1-4dce-bae6-c7ea01e7c2ea"/>
</identifier>
<!-- Ссылка на план ведения -->
<basedOn>
<reference value="urn:uuid:e0144d84-172e-4514-811e-7e2546358977"/>
<type value="CarePlan"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:c3eab073-5fe2-4a5d-bcbf-6d59aeed4004"/>
</identifier>
</basedOn>
<status value="final"/>
<!-- Категория измерения -->
<category>
<coding>
<system value="http://terminology.hl7.org/CodeSystem/observation-
category"/>
<code value="vital-signs"/>
</coding>
<text value="Жизненно важные показатели"/>
</category>
<!-- Вид измерения -->
<code>
<!-- Код измерения по LOINC -->
<coding>
<system value="http://loinc.org"/>
<code value=8302-2/>
</coding>
<!-- Код измерения по НСИ Минздрава России -->
<coding>
<system value="urn:oid:1.2.643.5.1.13.13.99.2.262"/>
<code value="51"/>
<display value="Длина тела"/>
</coding>
<text value="Рост"/>
</code>
<!-- Ссылка на идентификацию пациента -->
<subject>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</subject>
<!-- Дата измерения -->
<effectiveDateTime value="2023-11-03"/>
<!-- Рост -->
<valueQuantity>
<value value="169"/>
<unit value="см"/>
<system value="http://unitsofmeasure.org"/>
<code value="см"/>
</valueQuantity>
</Observation>
</resource>
<!-- Создать экземпляр ресурса Observation при условии, что нет экземпляра
с таким же идентификатором -->
<request>
<method value="POST"/>
<url value="Observation"/>
<ifNoneExist value="identifier=urn:uuid:b85497fe-14e1-4dce-bae6-
c7ea01e7c2ea"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:79b5604b-c28e-4a7f-b90c-6274e7f51542"/>
<resource>
<!-- Вес пациента -->
<Observation>
<!-- Уникальный идентификатор измерения (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:117bc50b-2ab3-467b-8db1-72e26e867e08"/>
</identifier>
<!-- Ссылка на план ведения -->
<basedOn>
<reference value="urn:uuid:e0144d84-172e-4514-811e-7e2546358977"/>
<type value="CarePlan"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:c3eab073-5fe2-4a5d-bcbf-6d59aeed4004"/>
</identifier>
</basedOn>
<status value="final"/>
<!-- Категория измерения -->
<category>
<coding>
<system value="http://terminology.hl7.org/CodeSystem/observation-
category"/>
<code value="vital-signs"/>
</coding>
<text value="Жизненно важные показатели"/>
</category>
<!-- Вид измерения -->
<code>
<!-- Код измерения по LOINC -->
<coding>
<system value="http://loinc.org"/>
<code value=29463-7/>
</coding>
<!-- Код измерения по НСИ Минздрава России -->
<coding>
<system value="urn:oid:1.2.643.5.1.13.13.99.2.262"/>
<code value="50"/>
<display value="Масса тела"/>
</coding>
<text value="Вес"/>
</code>
<!-- Ссылка на идентификацию пациента -->
<subject>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</subject>
<!-- Дата измерения -->
<effectiveDateTime value="2023-11-03"/>
<!-- Вес -->
<valueQuantity>
<value value="72"/>
<unit value="кг"/>
<system value="http://unitsofmeasure.org"/>
<code value="kg"/>
</valueQuantity>
</Observation>
</resource>
<!-- Создать экземпляр ресурса Observation при условии, что нет экземпляра
с таким же идентификатором -->
<request>
<method value="POST"/>
<url value="Observation"/>
<ifNoneExist value="identifier=urn:uuid:117bc50b-2ab3-467b-8db1-
72e26e867e08"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:5c80d3ef-2ce7-4b01-9af1-566bfdea386e"/>
<resource>
<!-- Возраст пациента (оценочный) -->
<Observation>
<!-- Уникальный идентификатор измерения (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:dd8e885d-93c9-4f6b-a582-b3531cfad62c"/>
</identifier>
<!-- Ссылка на план ведения -->
<basedOn>
<reference value="urn:uuid:e0144d84-172e-4514-811e-7e2546358977"/>
<type value="CarePlan"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:c3eab073-5fe2-4a5d-bcbf-6d59aeed4004"/>
</identifier>
</basedOn>
<status value="final"/>
<!-- Вид измерения -->
<code>
<!-- Код измерения по LOINC -->
<coding>
<system value="http://loinc.org"/>
<code value="21611-9"/>
</coding>
<text value="Оценка возраста"/>
</code>
<!-- Ссылка на идентификацию пациента -->
<subject>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</subject>
<!-- Дата измерения -->
<effectiveDateTime value="2023-11-03"/>
<! -- Вес -->
<valueQuantity>
<value value="72"/>
<unit value="лет"/>
<system value="http://unitsofmeasure.org"/>
<code value="a"/>
</valueQuantity>
</Observation>
</resource>
<!-- Создать экземпляр ресурса Observation при условии, что нет экземпляра
с таким же идентификатором -->
<request>
<method value="POST"/>
<url value="Observation"/>
<ifNoneExist value="identifier=urn:uuid:dd8e885d-93c9-4f6b-a582-
b3531cfad62c"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:ed0a3c4b-af09-4b23-b034-9977dd76f2cc"/>
<resource>
<!-- Лекарственное назначение -->
<Task>
<meta>
<profile value="Task-Medication"/>
</meta>
<!-- Полное описание мероприятия, ориентированное на пациента -->
<text>
<status value="additional"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Индапамид + рамиприл (0.625 мг + 2.5 мг), торговое наименование
Консилар-Д24, предпочтительно утром</p>
<p>Капсулы необходимо проглатывать целиком и запивать достаточным
количеством воды</p>
</div>
</text>
<!-- Уникальный идентификатор мероприятия (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:19bdb0b6-dc88-4f9d-bd62-757ffe2ad3ab"/>
</identifier>
<!-- Ссылка на план ведения -->
<basedOn>
<reference value="urn:uuid:e0144d84-172e-4514-811e-7e2546358977"/>
<type value="CarePlan"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:c3eab073-5fe2-4a5d-bcbf-6d59aeed4004"/>
</identifier>
</basedOn>
<status value="ready"/>
<intent value="order"/>
<code>
<!-- Код АТХ лекарственного препарата -->
<coding>
<system value="https://www.whocc.no"/>
<code value=C09BA05/>
</coding>
<!-- Торговое наименование лекарственного препарата -->
<coding>
<display value="Консилар-Д24"/>
</coding>
<!-- Международное непатентованное наименование -->
<text value="Рамиприл + Индапамид"/>
</code>
<description value="Консилар-Д24 1 капс. (0.625 мг + 2.5 мг)
однократно утром/>
<!-- Ссылка на пациента, которому назначен лекарственный препарат -->
<for>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</for>
<!-- Период выполнения мероприятия -->
<requestedPeriod>
<start value="2023-11-20"/>
<end value="2023-12-04"/>
</requestedPeriod>
<!-- Ссылка на исполнителя мероприятия - пациента -->
<requestedPerformer>
<reference>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</reference>
</requestedPerformer>
<!-- Расписание выполнения мероприятия -->
<input>
<!-- Повествовательное описание расписания -->
<type>
<text value="Однократно утром"/>
</type>
<!-- Структурированное описание расписания -->
<valueTiming>
<code>
<coding>
<system value="http://terminology.hl7.org/CodeSystem/v3-
GTSAbbreviation"/>
<code value="AM"/>
</coding>
</code>
</valueTiming>
</input>
</Task>
</resource>
<!-- Создать экземпляр ресурса Task при условии, что нет экземпляра с таким
же идентификатором -->
<request>
<method value="POST"/>
<url value="Task"/>
<ifNoneExist value="identifier=urn:uuid:19bdb0b6-dc88-4f9d-bd62-
757ffe2ad3ab"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:2a815d96-eea0-4526-bb28-3861c1d2b018"/>
<resource>
<!-- Ведение дневника приема лекарств -->
<Task>
<meta>
<profile value="Task-MedStat"/>
</meta>
<!-- Полное описание мероприятия, ориентированное на пациента -->
<text>
<status value="additional"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Вести дневник приема лекарств</p>
<p>Заполнять после каждого приема лекарства</p>
</div>
</text>
<!-- Уникальный идентификатор мероприятия (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:d3d11735-f6e9-462f-b01d-76e06d0d0f25"/>
</identifier>
<!-- Ссылка на план ведения -->
<basedOn>
<reference value="urn:uuid:e0144d84-172e-4514-811e-7e2546358977"/>
<type value="CarePlan"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:c3eab073-5fe2-4a5d-bcbf-6d59aeed4004"/>
</identifier>
</basedOn>
<status value="ready"/>
<intent value="order"/>
<code>
<!-- Код в справочнике типов мероприятий -->
<coding>
<system value="http://loinc.org"/>
<code value="87232-5"/>
<display value="Medication administration.brief"/>
</coding>
<!-- Текст типа мероприятия -->
<text value="'Ведение дневника приема лекарств"/>
</code>
<description value="Ведение дневника приема лекарств"/>
<!-- Ссылка на пациента, применяющего лекарственный препарат -->
<for>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</for>
<!-- Период выполнения мероприятия -->
<requestedPeriod>
<start value="2023-11-20"/>
<end value="2023-12-04"/>
</requestedPeriod>
<!-- Ссылка на исполнителя мероприятия - пациента -->
<requestedPerformer>
<reference>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</reference>
</requestedPerformer>
<!-- Расписание выполнения мероприятия -->
<input>
<!-- Повествовательное описание расписания -->
<type>
<text value="После каждого приема лекарственного препарата"/>
</type>
<!-- Структурированное описание расписания -->
<valueTiming>
<repeat>
<when value="IMD"/>
</repeat>
</valueTiming>
</input>
</Task>
</resource>
<!-- Создать экземпляр ресурса Task при условии, что нет экземпляра с таким
же идентификатором -->
<request>
<method value="POST"/>
<url value="Task"/>
<ifNoneExist value="identifier=urn:uuid:d3d11735-f6e9-462f-b01d-
76e06d0d0f25"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:139ab70d-a1bb-4bc5-ab00-a841ebda7ebe"/>
<resource>
<!-- Ведение дневника питания -->
<Task>
<meta>
<profile value="Task-NutrInt"/>
</meta>
<!-- Полное описание мероприятия, ориентированное на пациента -->
<text>
<status value="additional"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Вести дневник приема питания</p>
<p>Заполнять после каждого приема лекарства</p>
</div>
</text>
<!-- Уникальный идентификатор мероприятия (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:4c8c91a7-d4aa-49a2-9ced-e9da7c5ad4f4"/>
</identifier>
<!-- Ссылка на план ведения -->
<basedOn>
<reference value="urn:uuid:e0144d84-172e-4514-811e-7e2546358977"/>
<type value="CarePlan"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:c3eab073-5fe2-4a5d-bcbf-6d59aeed4004"/>
</identifier>
</basedOn>
<status value="ready"/>
<intent value="order"/>
<code>
<!-- Код в справочнике типов мероприятий -->
<coding>
<system value="http://loinc.org"/>
<code value="84282-3"/>
<display value="Nutrition and dietetics Patient's home Note"/>
</coding>
<!-- Текст типа мероприятия -->
<text value="'Ведение дневника приема питания"/>
</code>
<description value="Ведение дневника приема питания"/>
<!-- Ссылка на пациента, принимающего питание -->
<for>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</for>
<!-- Период выполнения мероприятия -->
<requestedPeriod>
<start value="2023-11-20"/>
<end value="2023-12-04"/>
</requestedPeriod>
<!-- Ссылка на исполнителя мероприятия - пациента -->
<requestedPerformer>
<reference>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</reference>
</requestedPerformer>
<!-- Расписание выполнения мероприятия -->
<input>
<!-- Повествовательное описание расписания -->
<type>
<text value=После каждого приема питания/>
</type>
<!-- Структурированное описание расписания -->
<valueTiming>
<repeat>
<when value="IMD"/>
</repeat>
</valueTiming>
</input>
</Task>
</resource>
<!-- Создать экземпляр ресурса Task при условии, что нет экземпляра с таким
же идентификатором -->
<request>
<method value="POST"/>
<url value="Task"/>
<ifNoneExist value="identifier=urn:uuid:4c8c91a7-d4aa-49a2-9ced-
e9da7c5ad4f4"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:ec5c3376-db87-456f-b809-f629b4cd20cc"/>
<resource>
<!-- Ведение дневника самонаблюдений -->
<Task>
<meta>
<profile value="Task-QuestResp"/>
</meta>
<!-- Полное описание мероприятия, ориентированное на пациента -->
<text>
<status value="additional"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Вести дневник самонаблюдений</p>
<p>Заполнять в течение дня</p>
</div>
</text>
<!-- Уникальный идентификатор мероприятия (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:654c8a9c-e15c-41b1-aa0f-cdad7e35ba8e"/>
</identifier>
<!-- Ссылка на план ведения -->
<basedOn>
<reference value="urn:uuid:e0144d84-172e-4514-811e-7e2546358977"/>
<type value="CarePlan"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:c3eab073-5fe2-4a5d-bcbf-6d59aeed4004"/>
</identifier>
</basedOn>
<status value="ready"/>
<intent value=order/>
<code>
<!-- Код в справочнике типов мероприятий -->
<coding>
<system value="http://loinc.org"/>
<code value="74465-6"/>
<display value="Questionnaire response Document"/>
</coding>
<!-- Текст типа мероприятия -->
<text value="'Ведение дневника самонаблюдений"/>
</code>
<description value="Ведение дневника самонаблюдений"/>
<!-- Ссылка на пациента, принимающего питание -->
<for>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</for>
<!-- Период выполнения мероприятия -->
<requestedPeriod>
<start value="2023-11-20"/>
<end value="2023-12-04"/>
</requestedPeriod>
<!-- Ссылка на исполнителя мероприятия - пациента -->
<requestedPerformer>
<reference>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</reference>
</requestedPerformer>
<!-- Расписание выполнения мероприятия -->
<input>
<!-- Повествовательное описание расписания -->
<type>
<text value="В течение дня"/>
</type>
<!-- Структурированное описание расписания -->
<valueTiming>
<repeat>
<when value="IMD"/>
</repeat>
</valueTiming>
</input>
</Task>
</resource>
<!-- Создать экземпляр ресурса Task при условии, что нет экземпляра с таким
же идентификатором -->
<request>
<method value="POST"/>
<url value="Task"/>
<ifNoneExist value="identifier=urn:uuid:654c8a9c-e15c-41b1-aa0f-
cdad7e35ba8e"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:d54a8662-9199-43ff-b9d4-6132a3a71c88"/>
<resource>
<!-- Измерение артериального давления -->
<Task>
<meta>
<profile value="Task-Phd"/>
</meta>
<!-- Полное описание мероприятия, ориентированное на пациента -->
<text>
<status value="additional"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Измерять артериальное давление</p>
<p>два раза в день</p>
</div>
</text>
<!-- Уникальный идентификатор мероприятия (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:9a1ffda7-8822-4790-9fdf-b8b07c94845a"/>
</identifier>
<!-- Ссылка на план ведения -->
<basedOn>
<reference value="urn:uuid:e0144d84-172e-4514-811e-7e2546358977"/>
<type value="CarePlan"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:c3eab073-5fe2-4a5d-bcbf-6d59aeed4004"/>
</identifier>
</basedOn>
<status value="ready"/>
<intent value="order"/>
<code>
<!-- Код в справочнике типов мероприятий -->
<coding>
<system value="urn:iso:std:iso:11073:10101"/>
<code value="528391"/>
<display value="MDC_DEV_SPEC_PROFILE_BP"/>
</coding>
<!-- Текст типа мероприятия -->
<text value="Измерение артериального давления"/>
</code>
<description value="Измерение артериального давления"/>
<!-- Ссылка на пациента -->
<for>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</for>
<!-- Период выполнения мероприятия -->
<requestedPeriod>
<start value="2023-11-20"/>
<end value="2023-12-04"/>
</requestedPeriod>
<!-- Ссылка на исполнителя мероприятия - персональный медицинский
прибор -->
<requestedPerformer>
<reference>
<reference value="urn:uuid:bfc0c54d-aa0d-47bb-90fc-66d407fd81d0"/>
<type value="Device"/>
<identifier>
<type>
<coding>
<system value="http://hl7.org/fhir/uv/phd/CodeSystem/
ContinuaDeviceIdentifiers"/>
<code value="SYSID"/>
</coding>
</type>
<system value="urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680"/>
<value value="FE-ED-AB-EE-DE-AD-77-C3"/>
</identifier>
</reference>
</requestedPerformer>
<!-- Расписание выполнения мероприятия -->
<input>
<!-- Повествовательное описание расписания -->
<type>
<text value=Два раза в день/>
</type>
<!-- Структурированное описание расписания -->
<valueTiming>
<code>
<coding>
<system value="http://terminology.hl7.org/CodeSystem/v3-
GTSAbbreviation"/>
<code value="BID"/>
</coding>
<text value="Два раза в день"/>
</code>
</valueTiming>
</input>
</Task>
</resource>
<!-- Создать экземпляр ресурса Task при условии, что нет экземпляра с таким
же идентификатором -->
<request>
<method value="POST"/>
<url value="Task"/>
<ifNoneExist value="identifier=urn:uuid:9a1ffda7-8822-4790-9fdf-
b8b07c94845a"/>
</request>
</entry>
<entry>
<!-- В качестве адреса URL используется GUID - экземпляр еще не создан -->
<fullUrl value="urn:uuid:03b50a6f-fa21-48e9-9103-fca514ca849e"/>
<resource>
<!-- Составление этапного эпикриза -->
<Task>
<meta>
<profile value="Task-DiagRep"/>
</meta>
<!-- Полное описание мероприятия, ориентированное на пациента -->
<text>
<status value="additional"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Составить этапный эпикриз</p>
</div>
</text>
<!-- Уникальный идентификатор мероприятия (GUID) -->
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:6a7df814-ffc7-48da-ab05-5c4358f1801b"/>
</identifier>
<!-- Ссылка на план ведения -->
<basedOn>
<reference value="urn:uuid:e0144d84-172e-4514-811e-7e2546358977"/>
<type value="CarePlan"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:c3eab073-5fe2-4a5d-bcbf-6d59aeed4004"/>
</identifier>
</basedOn>
<status value="ready"/>
<intent value="order"/>
<code>
<!-- Код в справочнике типов мероприятий -->
<coding>
<system value="http://loinc.org"/>
<code value="75498-6"/>
<display value="Telehealth Summary note"/>
</coding>
<!-- Текст типа мероприятия -->
<text value="Этапный эпикриз дистанционного мониторинга"/>
</code>
<description value="Составление этапного эпикриза дистанционного
мониторинга"/>
<!-- Ссылка на пациента -->
<for>
<reference value="urn:uuid:e3c4b5fc-44a1-4788-963c-4d1a6bb6079d"/>
<type value="Patient"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:1d5706b0-d040-4602-b9fd-c6ff445c5793"/>
</identifier>
</for>
<!-- Период выполнения мероприятия -->
<requestedPeriod>
<start value="2023-12-04"/>
<end value="2023-12-06"/>
</requestedPeriod>
<!-- Ссылка на исполнителя мероприятия - лечащего врача -->
<requestedPerformer>
<reference>
<reference value="urn:uuid:92fdce2b-8701-4dc2-aff7-10f13e15c44f"/>
<type value="Practitioner"/>
<identifier>
<system value="urn:ietf:rfc:3986"/>
<value value="urn:uuid:5e0afd03-76e0-403e-9b17-06f477fd9a55"/>
</identifier>
</reference>
</requestedPerformer>
</Task>
</resource>
<!-- Создать экземпляр ресурса Task при условии, что нет экземпляра с таким
же идентификатором -->
<request>
<method value="POST"/>
<url value="Task"/>
<ifNoneExist value="identifier=urn:uuid:6a7df814-ffc7-48da-ab05-
5c4358f1801b"/>
</request>
</entry>
</Bundle>
Приложение В
(справочное)
СОПОСТАВЛЕНИЕ СТАНДАРТА С HL7 FHIR R4
В.1 Общие сведения
Во многих разработках медицинских информационных систем, включая прототип платформы персональных медицинских помощников, реализованы требования, содержащиеся в спецификации HL7 FHIR Release 4 (кратко FHIR R4, см. https://hl7.org/fhir/R4). В значительной мере это обусловлено тем, что офис национального координатора ONC (The Office of the National Coordinator for Health Information Technology) утвердил требование соответствия Руководству по базовой реализации в США (US Core Implementation Guide), основанное на FHIR R4, в программе сертификации медицинских информационных систем (https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and).
Для предметной области дистанционного мониторинга состояния пациента с помощью персональных медицинских приборов версия HL7 FHIR Release 5 (кратко R5, см. https://hl7.org/fhir/R5) является более предпочтительной по следующим причинам:
а) механизм подписок на новые или измененные результаты измерений, предложенный в FHIR R4, оказался недостаточно эффективным. В частности, он не позволял обеспечить режим регулярного опроса наличия новых или измененных данных. Поэтому уже в HL7 FHIR Release 4B (кратко R4B) к ресурсу Subscription (подписка) добавились ресурсы SubscriptionTopic (тема подписки) и SubscriptionStatus (статус подписки). Определения этих ресурсов затем были перенесены в R5;
б) использование ресурса Observation (результат исследования) для передачи содержания дневников питания, имевшее место в реализациях R4, было признано недостаточно состоятельным и в R5 появился специализированный ресурс NutritionIntake (дневник питания);
в) в версии R4 ресурс Device (сведения о медицинском изделии) содержал ссылку на пациента, использующего данный прибор, из-за чего требовалось создавать новые экземпляры этого ресурса при передаче от одного пациента к другому. Кроме того, этот ресурс содержал сведения о текущем состоянии использования. В R5 был определен ресурс DeviceAssociation (ассоциация медицинского изделия с субъектом). Субъектами ассоциаций могут быть пациенты, группы лиц (к примеру, весы или тонометр могут быть ассоциированы с членами семьи или группой лиц), медицинские работники, использующие мобильные приборы, изделия (например, радиочастотная метка, прикрепленная к переносному прибору), близкие лица пациента. В этом же ресурсе можно передать сведения о текущем состоянии использования прибора.
Для предметной области дистанционного мониторинга состояния пациента с помощью персональных медицинских приборов другие отличия R5 от R4 имеют менее принципиальный характер. При этом значительная часть профилей, определенных в настоящем стандарте, будет пригодна без каких-либо изменений как для R5, так и для R4.
Чтобы упростить миграцию с R4 на R5, в настоящем приложении приведены сведения об отличиях в описаниях ресурсов и их профилей между этими версиями спецификации. Они показывают, что за исключением приведенных выше принципиальных отличий миграция разработок в предметной области дистанционного мониторинга состояния пациента с помощью персональных медицинских приборов не должна вызвать сколько-нибудь существенных затруднений.
В.2 Базисные ресурсы
Определения базисных ресурсов Resource и DomainResource в R4 и R5 совпадают.
В.3 Ресурсы общего назначения
В.3.1 Ресурс Bundle - контейнер экземпляров ресурсов
Изменения ресурса Bundle по сравнению с версиями R4 и R4B представлены в таблице В.1.
Таблица В.1
Изменения ресурса Bundle по сравнению с версиями R4 и R4B
Путь
Изменение
Bundle.type
Добавлен вариант значения subscription-notification
Bundle.link.relation
Тип изменен со string на code. Задана обязательная привязка к набору значений http://hl7.org/fhir/ValueSet/iana-link-relations|5.0.0
Bundle.issues
Дополнительный необязательный элемент
В 3.2 Ресурс MessageHeader - заголовок сообщения
Изменения ресурса MessageHeader по сравнению с версиями R4 и R4B представлены в таблице В.2.
Таблица В.2
Изменения ресурса MessageHeader
по сравнению с версиями R4 и R4B
Путь
Изменение
MessageHeader.event[x]
Добавлен вариант типа значения canonical(EventDefinition).
Вариант типа uri удален
MessageHeader.destination.endpoint[x]
Переименован с endpoint на endpoint[x] и тем самым значение может иметь несколько типов данных.
Элемент сделан необязательным
Добавлен вариант типа данных Reference(Endpoint)
MessageHeader.sender
Добавлен вариант ссылки на экземпляр ресурса Device
MessageHeader.author
Добавлен вариант ссылки на экземпляры ресурсов Device, Organization
MessageHeader.source. endpoint[x]
Переименован с endpoint на endpoint[x] и тем самым значение может иметь несколько типов данных.
Элемент сделан необязательным
Добавлен вариант типа данных Reference(Endpoint)
MessageHeader.response.identifier
Тип данных изменен с id на Identifier
MessageHeader.enterer
Необязательный элемент удален
В.3.3 Ресурс OperationOutcome - результат операции
Изменения ресурса OperationOutcome по сравнению с версиями R4 и R4B представлены в таблице В.3.
Таблица В.3
Изменения ресурса OperationOutcome
по сравнению с версиями R4 и R4B
Путь
Изменение
OperationOutcome.issue.severity
Добавлен вариант значения success
OperationOutcome.issue.code
Добавлены варианты значения limited-filter, success
В.3.4 Ресурс Parameters - параметры операции
Изменения ресурса Parameters по сравнению с версиями R4 и R4B представлены в таблице В.4.
Таблица В.4
Изменения ресурса Parameters
по сравнению с версиями R4 и R4B
Путь
Изменение
Parameters.parameter.value[x]
Добавлены варианты типа значения integer64, CodeableReference, RatioRange, Availability, ExtendedContactDetail, Meta.
Удален вариант типа значения Contributor
В.3.5 Ресурс Subscription - подписка
Изменения ресурса Subscription по сравнению с версиями R4 и R4B представлены в таблице В.5.
Таблица В.5
Изменения ресурса Subscription
по сравнению с версиями R4 и R4B
Путь
Изменение
Subscription.identifier
Добавлен необязательный элемент
Subscription.name
Добавлен необязательный элемент
Subscription.status
Добавлен вариант значения entered-in-error
Subscription.topic
Добавлен обязательный элемент
Subscription.managingEntity
Добавлен необязательный элемент
Subscription.reason
Элемент сделан необязательным
Subscription.filterBy
Добавлен необязательный элемент
Subscription.filterBy.resourceType
Добавлен необязательный элемент
Subscription.filterBy.filterParameter
Добавлен обязательный элемент
Subscription.filterBy.comparator
Добавлен необязательный элемент
Subscription.filterBy.modifier
Добавлен необязательный элемент
Subscription.filterBy.value
Добавлен обязательный элемент
Subscription.channelType
Добавлен обязательный элемент
Subscription.endpoint
Добавлен необязательный элемент
Subscription.parameter
Добавлен необязательный элемент
Subscription.parameter.name
Добавлен обязательный элемент
Subscription.parameter.value
Добавлен обязательный элемент
Subscription.heartbeatPeriod
Добавлен необязательный элемент
Subscription.timeout
Добавлен необязательный элемент
Subscription.contentType
Добавлен необязательный элемент
Subscription.content
Добавлен необязательный элемент
Subscription.maxCount
Добавлен необязательный элемент
Subscription.criteria
Обязательный элемент удален
Subscription.error
Необязательный элемент удален
Subscription.channel
Обязательный элемент удален
В.3.6 Ресурс SubscriptionStatus - статус подписки
В R4 отсутствует.
В.3.7 Ресурс SubscriptionTopic - тема подписки
В R4 отсутствует.
В.3.8 Ресурс CarePlan - план ведения
Изменения ресурса CarePlan по сравнению с версиями R4 и R4B представлены в таблице В.6.
Таблица В.6
Изменения ресурса CarePlan по сравнению с версиями R4 и R4B
Путь
Изменение
CarePlan.basedOn
Добавлены варианты ссылок на экземпляры ресурсов ServiceRequest, RequestOrchestration, NutritionOrder
CarePlan.intent
Добавлен вариант значения directive
CarePlan.custodian
Переименован с author на custodian
CarePlan.addresses
Тип данных изменен с Reference(Condition) на CodeableReference
CarePlan.activity.performedActivity
Добавлен необязательный элемент
CarePlan.activity.outcomeCodeableConcept
Элемент удален. Вместо него следует использовать элемент CarePlan.activity.performedActivity
CarePlan.activity.outcomeReference
Элемент удален. Вместо него следует использовать элемент CarePlan.activity.performedActivity
CarePlan.activity.detail
Элемент удален. Вместо него следует использовать элемент CarePlan.activity.plannedActivityReference
В.3.9 Профиль CarePlan-Dm
Изменения ресурса CarePlan, требующие учета при реализации профиля CarePlan-Dm, приведены в таблице В.7.
Таблица В.7
Изменения ресурса CarePlan, требующие учета
при реализации профиля CarePlan-Dm
Путь
Изменение
CarePlan.basedOn
Добавлены варианты ссылок на экземпляры ресурсов ServiceRequest, RequestOrchestration, NutritionOrder
CarePlan.custodian
Переименован с author на custodian
В.3.10 Ресурс Goal - цель
Изменения ресурса Goal по сравнению с версиями R4 и R4B представлены в таблице В.8.
Таблица В.8
Изменения ресурса Goal по сравнению с версиями R4 и R4B
Путь
Изменение
Goal.continuous
Добавлен необязательный элемент
Goal.source
Переименован с expressedBy на source
Добавлены вариант ссылки на экземпляр ресурса CareTeam
Goal.addresses
Добавлены варианты ссылок на экземпляры ресурсов MedicationRequest, Procedure
Goal.outcome
Добавлен необязательный элемент
Goal.outcomeCode
Элемент удален. Вместо него следует использовать элемент Goal.outcome
Goal.outcomeReference
Элемент удален. Вместо него следует использовать элемент Goal.outcome
В.3.11 Профиль цели дистанционного мониторинга пациента Goal-Dm
Изменения ресурса Goal не требуют учета при реализации профиля CarePlan-Dm.
В.3.12 Ресурс ServiceRequest - назначение
Изменения ресурса ServiceRequest по сравнению с версиями R4 и R4B представлены в таблице В.9.
Таблица В.9
Изменения ресурса ServiceRequest
по сравнению с версиями R4 и R4B
Путь
Изменение
ServiceRequest.code
Тип данных изменен с CodeableConcept на CodeableReference
ServiceRequest.orderDetail
Тип данных изменен с CodeableConcept на BackboneElement
ServiceRequest.orderDetail.parameterFocus
Добавлен необязательный элемент
ServiceRequest.orderDetail.parameter
Добавлен обязательный элемент
ServiceRequest.orderDetail.parameter.code
Добавлен обязательный элемент
ServiceRequest.orderDetail.parameter.value[x]
Добавлен обязательный элемент
ServiceRequest.focus
Добавлен необязательный элемент
ServiceRequest.location
Добавлен необязательный элемент
ServiceRequest.reason
Добавлен необязательный элемент
ServiceRequest.supportingInfo
Тип данных изменен с Reference(Resource) на CodeableReference
ServiceRequest.bodyStructure
Добавлен необязательный элемент
ServiceRequest.patientInstruction
Максимальная кратность изменена с 1 на *
Тип данных изменен на BackboneElement
ServiceRequest.patientInstruction.instruction[x]
Добавлен необязательный элемент
ServiceRequest.locationCode
Элемент удален
ServiceRequest.locationReference
Элемент удален
ServiceRequest.reasonCode
Элемент удален. Вместо него следует использовать элемент reason
ServiceRequest.reasonReference
Элемент удален. Вместо него следует использовать элемент reason
В.3.13 Ресурс Task - мероприятие
Изменения ресурса Task по сравнению с версиями R4 и R4B представлены в таблице В.10.
Таблица В.10
Изменения ресурса Task по сравнению с версиями R4 и R4B
Путь
Изменение
Task.statusReason
Тип данных изменен с CodeableConcept на CodeableReference
Task.doNotPerform
Добавлен необязательный элемент
Task.requestedPeriod
Добавлен необязательный элемент
Task.requestedPerformer
Добавлен необязательный элемент
Task.owner
Удалены варианты ссылок на экземпляры ресурсов HealthcareService, Device
Task.performer
Добавлен необязательный элемент
Task.performer.function
Добавлен необязательный элемент
Task.performer.actor
Добавлен обязательный элемент
Task.reason
Добавлен необязательный элемент
Task.input.value[x]
Добавлены варианты типов данных integer64, CodeableReference, RatioRange, Availability, ExtendedContactDetail, Meta.
Удален вариант типа данных Contributor
Task.output.value[x]
Добавлены варианты типов данных integer64, CodeableReference, RatioRange, Availability, ExtendedContactDetail, Meta.
Удален вариант типа данных Contributor
Task.performerType
Элемент удален. Вместо него следует использовать элемент Task.requestedPerformer
Task.reasonCode
Элемент удален. Вместо него следует использовать элемент reason
Task.reasonReference
Элемент удален. Вместо него следует использовать элемент reason
В.3.14 Профиль Task-Medication
Изменения ресурса Task, требующие учета при реализации профиля Task-Medication, приведены в таблице В.11.
Таблица В.11
Изменения ресурса Task, требующие учета при реализации
профиля Task-Medication
Путь
Изменение
Task.requestedPerformer
Добавлен обязательный элемент
Task.reason
Добавлен необязательный элемент
Task.performerType
Элемент удален. Вместо него следует использовать элемент Task.requestedPerformer
Task.reasonCode
Элемент удален. Вместо него следует использовать элемент reason
Task.reasonReference
Элемент удален. Вместо него следует использовать элемент reason
В.3.15 Профиль Task-Phd
Изменения ресурса Task, требующие учета при реализации профиля Task-Phd, приведены в таблице В.11.
В.3.16 Профиль Task-MedStat
Изменения ресурса Task, требующие учета при реализации профиля Task-MedStat, приведены в таблице В.11.
В.3.17 Профиль Task-NutrInt
Изменения ресурса Task, требующие учета при реализации профиля Task-NutrInt, приведены в таблице В.11.
В.3.18 Профиль Task-QuestResp
Изменения ресурса Task, требующие учета при реализации профиля Task-QuestResp, приведены в таблице В.11.
В.3.19 Профиль Task-DiagRep
Изменения ресурса Task, требующие учета при реализации профиля Task-DiagRep, приведены в таблице В.11.
В.3.20 Ресурс Device - сведения о медицинском изделии
Изменения ресурса Device по сравнению с версиями R4 и R4B представлены в таблице В.12.
Таблица В.12
Изменения ресурса Device по сравнению с версиями R4 и R4B
Путь
Изменение
Device.displayName
Добавлен необязательный элемент
Device.definition
Тип данных изменен с Reference(DeviceDefinition) на CodeableReference
Device.udiCarrier.deviceIdentifier
Элемент сделан обязательным
Device.udiCarrier.issuer
Элемент сделан обязательным
Device.udiCarrier.entryType
Добавлен вариант значения electronic-transmission
Device.status
Удален вариант значения unknown
Device.availabilityStatus
Добавлен необязательный элемент
Device.biologicalSourceEvent
Добавлен необязательный элемент
Device.name
Переименован с deviceName на name
Device.name.value
Добавлен обязательный элемент
Device.name.type
Перемещен из Device.deviceName в Device.name.
Удалены варианты значений udi-label-name, manufacturer-name, model-name, other.
Добавлен вариант значения registered-name
Device.name.display
Добавлен необязательный элемент
Device.category
Добавлен необязательный элемент
Device.type
Максимальная кратность изменена с 1 на *
Device.version.installDate
Добавлен необязательный элемент
Device.conformsTo
Переименован со specialization на conformsTo
Device.conformsTo.category
Добавлен необязательный элемент
Device.conformsTo.specification
Добавлен обязательный элемент
Device.conformsTo.version
Перемещен из Device.specialization в Device.conformsTo
Device.property.value[x]
Добавлен обязательный элемент
Device.mode
Добавлен необязательный элемент
Device.cycle
Добавлен необязательный элемент
Device.duration
Добавлен необязательный элемент
Device.endpoint
Добавлен необязательный элемент
Device.gateway
Добавлен необязательный элемент
Device.statusReason
Элемент удален. Вместо него можно использовать элемент operation.status ресурса DeviceAssociation
Device.distinctIdentifier
Элемент удален
Device.deviceName.name
Элемент удален
Device.specialization.systemType
Элемент удален
Device.property.valueQuantity
Элемент удален
Device.property.valueCode
Элемент удален
Device.patient
Элемент удален. Для привязки прибора к пациенту можно использовать ресурс DeviceAssociation
В.3.21 Профиль Device-Phd
Изменения ресурса Device, требующие учета при реализации профиля Device-Phd, приведены в таблице В.13.
Таблица В.13
Изменения ресурса Device, требующие учета
при реализации профиля Device-Phd
Путь
Изменение
Device.conformsTo
Переименован с specialization на conformsTo
Device.conformsTo.specification
Добавлен обязательный элемент
Device.conformsTo.version
Перемещен из Device.specialization в Device.conformsTo
Device.gateway
Добавлен необязательный элемент
В.3.22 Профиль Device-Phg
Изменения ресурса Device не требуют учета при реализации профиля Device-Phg.
В.3.23 DeviceAssociation - ассоциация медицинского изделия с субъектом
В R4 отсутствует.
В.3.24 Профиль DeviceAssociation-Dm
К R4 неприменим.
В.3.25 Ресурс DeviceMetric - измерительная способность медицинского прибора
Изменения ресурса DeviceMetric по сравнению с версиями R4 и R4B представлены в таблице В.14.
Таблица В.14
Изменения ресурса DeviceMetric
по сравнению с версиями R4 и R4B
Путь
Изменение
DeviceMetric.device
Добавлен обязательный элемент
DeviceMetric.color
Привязка к набору значений http://hl7.org/fhir/ValueSet/metric-color|4.0.0 изменена на требование "Наименование цвета из системы CSS Color Module Level 4 либо код цвета в системе RGB (#RRGGBB в шестнадцатеричной системе)"
DeviceMetric.measurementFrequency
Добавлен необязательный элемент
DeviceMetric.source
Элемент удален
DeviceMetric.parent
Элемент удален
DeviceMetric.measurementPeriod
Элемент удален
В.3.26 Ресурс Observation - результат исследования
Изменения ресурса Observation по сравнению с версиями R4 и R4B представлены в таблице В.15.
Таблица В.15
Изменения ресурса Observation
по сравнению с версиями R4 и R4B
Путь
Изменение
Observation.instantiates[x]
Добавлен необязательный элемент
Observation.triggeredBy
Добавлен необязательный элемент
Observation.triggeredBy.observation
Добавлен обязательный элемент
Observation.triggeredBy.type
Добавлен обязательный элемент
Observation.triggeredBy.reason
Добавлен необязательный элемент
Observation.partOf
Добавлен вариант ссылки на экземпляр ресурса GenomicStudy
Observation.subject
Добавлены варианты ссылок на экземпляры ресурсов Organization, Procedure, Practitioner, Medication, Substance, BiologicallyDerivedProduct, NutritionProduct
Observation.value[x]
Добавлены варианты типов данных Attachment, Reference(MolecularSequence)
Observation.bodyStructure
Добавлен необязательный элемент
Observation.specimen
Добавлен вариант ссылки на экземпляр ресурса Group
Observation.referenceRange.normalValue
Добавлен необязательный элемент
Observation.referenceRange.text
Тип данных изменен со string на markdown
Observation.derivedFrom
Добавлены варианты ссылок на экземпляры ресурсов ImagingSelection, GenomicStudy.
Удален вариант ссылки на экземпляр ресурса Media
Observation.component.value[x]
Добавлены варианты типов данных Attachment, Reference(MolecularSequence)
В.3.27 Профиль Observation-PhdNumeric
Изменения ресурса Observation не требуют учета при реализации профиля Observation-PhdNumeric.
В.3.28 Профиль Observation-PhdCompoundNumeric
Изменения ресурса Observation не требуют учета при реализации профиля Observation-PhdCompoundNumeric.
В.3.29 Профиль Observation-PhdCodedEnumeration
Изменения ресурса Observation не требуют учета при реализации профиля Observation-PhdCodedEnumeration.
В.3.30 Профиль Observation-PhdBitsEnumeration
Изменения ресурса Observation не требуют учета при реализации профиля Observation-PhdBitsEnumeration.
В.3.31 Профиль Observation-PhdStringEnumeration
Изменения ресурса Observation не требуют учета при реализации профиля Observation-PhdStringEnumeration.
В.3.32 Профиль Observation-PhdRtsa
Изменения ресурса Observation не требуют учета при реализации профиля Observation-PhdRtsa.
В.3.33 Профиль Observation-PhdMedia
Изменения ресурса Observation не требуют учета при реализации профиля Observation-PhdMedia.
В.3.34 Профиль Observation-PhdCoincidentTimeStamp
Изменения ресурса Observation не требуют учета при реализации профиля Observation-PhdCoincidentTimeStamp.
В.3.35 Ресурс Patient - сведения о пациенте
Изменения ресурса Patient по сравнению с версиями R4 и R4B представлены в таблице В.16.
Таблица В.16
Изменения ресурса Patient по сравнению с версиями R4 и R4B
Путь
Изменение
Patient.communication.language
Степень привязки изменена с предпочтительной на обязательную.
Набор значений изменен с http://hl7.org/fhir/ValueSet/common-languages на http://hl7.org/fhir/ValueSet/all-languages. Максимальный набор значений изменен с http://hl7.org/fhir/ValueSet/all-languages на none
В.3.36 Профиль Patient-Dm
Изменения ресурса Patient не требуют учета при реализации профиля Patient-Dm.
В.3.37 Ресурс Practitioner - сведения о медицинском специалисте
Изменения ресурса Practitioner по сравнению с версиями R4 и R4B представлены в таблице В.17.
Таблица В.17
Изменения ресурса Practitioner
по сравнению с версиями R4 и R4B
Путь
Изменение
Practitioner.active
Элемент маркирован как модифицирующий (то есть его значение не может быть игнорировано)
Practitioner.deceased[x]
Добавлен необязательный элемент
Practitioner.communication
Тип значения изменен с CodeableConcept на BackboneElement
Отменена предпочтительная привязка к набору значений 'http://hl7.org/fhir/ValueSet/languages. Максимальный набор значений заменен на http://hl7.org/fhir/ValueSet/all-languages
Practitioner.communication.language
Добавлен обязательный элемент
Practitioner.communication.preferred
Добавлен необязательный элемент
В.3.38 Профиль Practitioner-Dm
Изменения ресурса Practitioner не требуют учета при реализации профиля Practitioner-Dm.
В.3.39 Ресурс DiagnosticReport - заключение врача
Изменения ресурса DiagnosticReport по сравнению с версиями R4 и R4B представлены в таблице В.18.
Таблица В.18
Изменения ресурса DiagnosticReport
по сравнению с версиями R4 и R4B
Путь
Изменение
DiagnosticReport.status
Добавлен вариант значения modified
DiagnosticReport.subject
Добавлены варианты ссылок на экземпляры ресурсов Organization, Practitioner, Medication, Substance, BiologicallyDerivedProduct
DiagnosticReport.note
Добавлен необязательный элемент
DiagnosticReport.study
Добавлен необязательный элемент
DiagnosticReport.supportingInfo
Добавлен необязательный элемент
DiagnosticReport.supportingInfo.type
Добавлен обязательный элемент
DiagnosticReport.supportingInfo.reference
Добавлен обязательный элемент
DiagnosticReport.media.link
Добавлен вариант ссылки на экземпляр ресурса DocumentReference
Удален вариант ссылки на экземпляр ресурса Media
DiagnosticReport.composition
Добавлен необязательный элемент
DiagnosticReport.conclusion
Тип изменен со string на markdown
DiagnosticReport.imagingStudy
Элемент удален
В.3.40 Профиль DiagnosticReport-Dm
Изменения ресурса DiagnosticReport не требуют учета при реализации профиля DiagnosticReport-Dm.
В.3.41 Ресурс MedicationStatement - дневник приема лекарств
Изменения ресурса MedicationStatement по сравнению с версиями R4 и R4B представлены в таблице В.19.
Таблица В.19
Изменения ресурса MedicationStatement
по сравнению с версиями R4 и R4B
Путь
Изменение
MedicationStatement.partOf
Удалены варианты ссылок на экземпляры ресурсов MedicationAdministration, MedicationDispense, Observation
MedicationStatement.status
Удалены варианты значений active, completed, intended, stopped, on-hold, unknown, not-taken
Добавлены варианты значений recorded, draft
MedicationStatement.category
Максимальная кратность изменена с 1 на *
MedicationStatement.medication
Переименован с medication[x] на medication.
Добавлен тип значения CodeableReference.
Удалены типы значения CodeableConcept, Reference(Medication)
MedicationStatement.encounter
Переименован с context на encounter
Удален вариант ссылки на экземпляр ресурса EpisodeOfCare
MedicationStatement.effective[x]
Добавлен тип значения Timing
MedicationStatement.informationSource
Максимальная кратность изменена с 1 на *
MedicationStatement.reason
Добавлен необязательный элемент
MedicationStatement.relatedClinicalInformation
Добавлен необязательный элемент
MedicationStatement.renderedDosageInstruction
Добавлен необязательный элемент
MedicationStatement.adherence
Добавлен необязательный элемент
MedicationStatement.adherence.code
Добавлен обязательный элемент
MedicationStatement.adherence.reason
Добавлен необязательный элемент
MedicationStatement.basedOn
Элемент удален
MedicationStatement.statusReason
Элемент удален
MedicationStatement.reasonCode
Элемент удален. Вместо него следует использовать reason
MedicationStatement.reasonReference
Элемент удален. Вместо него следует использовать reason
В.3.42 Ресурс QuestionnaireResponse - дневник самонаблюдения
Изменения ресурса QuestionnaireResponse по сравнению с версиями R4 и R4B представлены в таблице В.20.
Таблица В.20
Изменения ресурса QuestionnaireResponse
по сравнению с версиями R4 и R4B
Путь
Изменение
QuestionnaireResponse.identifier
Максимальная кратность изменена с 1 на *
QuestionnaireResponse.questionnaire
Элемент сделан обязательным
QuestionnaireResponse.source
Добавлены варианты ссылок на экземпляры ресурсов Device, Organization
QuestionnaireResponse.item.answer.value[x]
Элемент сделан обязательным.
Добавлен тип значения Quantity (http://hl7.org/fhir/StructureDefinition/SimpleQuantity)
В.3.43 Ресурс Questionnaire - описание дневника самонаблюдения
Изменения ресурса Questionnaire по сравнению с версиями R4 и R4B представлены в таблице В.21.
Таблица В.21
Изменения ресурса Questionnaire
по сравнению с версиями R4 и R4B
Путь
Изменение
Questionnaire.versionAlgorithm[x]
Добавлен необязательный элемент
Questionnaire.subjectType
Удалены варианты значения CatalogEntry, DeviceUseStatement, DocumentManifest, DomainResource, EffectEvidenceSynthesis, Media, MedicinalProduct, MedicinalProductAuthorization, MedicinalProductContraindication, MedicinalProductIndication, MedicinalProductIngredient, MedicinalProductInteraction, MedicinalProductManufactured, MedicinalProductPackaged, MedicinalProductPharmaceutical, MedicinalProductUndesirableEffect, RequestGroup, ResearchDefinition, ResearchElementDefinition, Resource, RiskEvidenceSynthesis, SubstanceSpecification
Добавлены варианты значения ActorDefinition, AdministrableProductDefinition, ArtifactAssessment, BiologicallyDerivedProductDispense, Citation, ClinicalUseDefinition, ConditionDefinition, DeviceAssociation, DeviceDispense, DeviceUsage, EncounterHistory, EvidenceReport, FormularyItem, GenomicStudy, ImagingSelection, Ingredient, InventoryItem, InventoryReport, ManufacturedItemDefinition, MedicinalProductDefinition, NutritionIntake, NutritionProduct, PackagedProductDefinition, Permission, RegulatedAuthorization, RequestOrchestration, Requirements, SubscriptionStatus, SubscriptionTopic, SubstanceDefinition, TestPlan, Transport
Questionnaire.copyrightLabel
Добавлен необязательный элемент
Questionnaire.item.type
Удалены варианты значения choice, open-choice
Добавлены варианты значения question, coding
Questionnaire.item.disabledDisplay
Добавлен необязательный элемент
Questionnaire.item.answerConstraint
Добавлен необязательный элемент
В.3.44 Ресурс NutritionIntake (дневник питания)
В R4 отсутствует.
В.3.45 Ресурс DetectedIssue - предупреждение
Изменения ресурса DetectedIssue по сравнению с версиями R4 и R4B представлены в таблице В.22.
Таблица В.22
Изменения ресурса DetectedIssue
по сравнению с версиями R4 и R4B
Путь
Изменение
DetectedIssue.status
Привязка к набору значений изменена с http://hl7.org/fhir/ValueSet/observation-status|4.0.0 на http://hl7.org/fhir/ValueSet/detectedissue-status. Удалены варианты значения registered, amended, corrected, cancelled, unknown
Добавлен вариант значения mitigated
DetectedIssue.category
Добавлен необязательный элемент
DetectedIssue.subject
Добавлен необязательный элемент
DetectedIssue.encounter
Добавлен необязательный элемент
DetectedIssue.author
Добавлены варианты ссылок на экземпляры ресурсов Patient, RelatedPerson
DetectedIssue.detail
Тип значения изменен со string на markdown
DetectedIssue.mitigation.note
Добавлен необязательный элемент
DetectedIssue.patient
Элемент удален
В.3.46 Профиль DetectedIssue-Dm
Изменения ресурса DetectedIssue, требующие учета при реализации профиля DetectedIssue-Dm, приведены в таблице В.23.
Таблица В.23
Изменения ресурса DetectedIssue, требующие учета
при реализации профиля Device-Phd
Путь
Изменение
DetectedIssue.status
Привязка к набору значений изменена с http://hl7.org/fhir/ValueSet/observation-status|4.0.0 на http://hl7.org/fhir/ValueSet/detectedissue-status. Удалены варианты значения registered, amended, corrected, cancelled, unknown. Добавлен вариант значения mitigated
DetectedIssue.subject
Добавлен необязательный элемент
Библиография
[1]
ISO/IEEE 11073-10404:2022 Информатизация здоровья. Совместимость приборов. Часть 10404. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Пульсовой оксиметр (Health informatics - Device interoperability - Part 10404: Personal health device communication - Device specialization - Pulse oximeter)
[2]
IEEE 11073-10406-2023 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10406. Специализация прибора: базовый электрокардиограф (ЭКГ с 1 - 3 отведениями) [Standard for Health Informatics - Device Interoperability Part 10406: Personal Health Device Communication - Device Specialization - Basic Electrocardiography (ECG) (1- to 3-lead ECG)]
[3]
ISO/IEEE 11073-10407:2022 Информатизация здоровья. Взаимодействие с приборами. Часть 10407. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Монитор артериального давления (Health informatics - Device interoperability - Part 10407: Personal health device communication - Device specialization - Blood pressure monitor)
[4]
ISO/IEEE 11073-10408:2022 Информатизация здоровья. Взаимодействие с приборами. Часть 10408. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Термометр (Health informatics - Device interoperability - Part 10408: Personal health device communication - Device specialization - Thermometer)
[5]
ISO/IEEE 11073-10415:2022 Информатизация здоровья. Взаимодействие с приборами. Часть 10415. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Весы (Health informatics - Device interoperability - Part 10415: Personal health device communication - Device specialization - Weighing scale)
[6]
ISO/IEEE 11073-10417:2017 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10417. Специализация прибора. Глюкометр (Health informatics - Personal health device communication - Part 10417: Device specialization - Glucose meter)
[7]
ISO/IEEE 11073-10418:2014 Информатика в здравоохранении. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10418. Специализация прибора. Монитор международного нормализованного коэффициента (INR) (Health informatics - Personal health device communication - Part 10418: Device specialization - International Normalized Ratio (INR) monitor)
[8]
ISO/IEEE 11073-10418:2014/Cor 1:2016 Информатика в здравоохранении. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10418. Специализация прибора. Монитор международного нормализованного коэффициента (INR). Техническая поправка 1: описание стандарта и тендеры (Health informatics - Personal health device communication - Part 10418: Device specialization - International Normalized Ratio (INR) monitor - Technical Corrigendum 1)
[9]
ISO/IEEE 11073-10419:2019 Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10419. Специализация прибора. Инсулиновая помпа (Health informatics - Personal health device communication - Part 10419: Device specialization - Insulin pump)
[10]
ISO/IEEE 11073-10420:2022 Информатизация здоровья. Взаимодействие с приборами. Часть 10420. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Анализатор композиционного состава организма (Health informatics - Device interoperability - Part 10420: Personal health device communication - Device specialization - Body composition analyzer)
[11]
ISO/IEEE 11073-10421:2012 Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10421. Специализация прибора. Пневмотахометр [Health informatics - Personal health device communication - Part 10421: Device specialization - Peak expiratory flow monitor (peak flow)]
[12]
ISO/IEEE 11073-10422:2017 Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10422. Специализация прибора. Уриноанализатор (Health informatics - Personal health device communication - Part 10422: Device specialization - Urine analyser)
[13]
ISO/IEEE 11073-10424:2016 Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10424. Специализация прибора. Дыхательная терапевтическая аппаратура при приступах апноэ во сне [Health informatics - Personal health device communication - Part 10424: Device specialization - Sleep apnoea breathing therapy equipment (SABTE)]
[14]
ISO/IEEE 11073-10424:2016/Cor 1:2018 Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10424. Специализация прибора. Дыхательная терапевтическая аппаратура при приступах апноэ во сне. Техническая поправка 1 [Health informatics - Personal health device communication - Part 10424: Device specialization - Sleep apnoea breathing therapy equipment (SABTE) - Technical Corrigendum 1]
[15]
IEEE 11073-10425-2023 Информатизация здоровья. Совместимость приборов. Часть 10425. Обмен данными с персональными медицинскими приборами. Специализация прибора. Глюкометр непрерывного действия (CGM) [Health informatics - Device Interoperability Part 10425: Personal Health Device Communication - Device Specialization - Continuous Glucose Monitor (CGM)]
[16]
IEEE P11073-10426 Информатика в здравоохранении. Персональные медицинские устройства связи. Специализация устройств. Домашний медицинский уход, окружающая среда, аппарат искусственной вентиляции легких (Health Informatics - Personal Health Device Communication - Device Specialization - Home Healthcare Environment Ventilator)
[17]
ISO/IEEE 11073-10427:2018 Информатика в здравоохранении. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10427. Специализация прибора. Монитор состояния питания медицинских приборов индивидуального контроля (Health informatics - Personal health device communication - Part 10427: Device specialization - Power status monitor of personal health devices)
[18]
IEEE 11073-10429-2022 Информатика в здравоохранении. Взаимодействие устройств. Часть 10429: Связь с персональными медицинскими устройствами. Специализация устройств. Спирометрия (Health Informatics - Device Interoperability - Part 10429: Personal Health Device Communication - Device Specialization - Spirometry)
[19]
ISO/IEEE 11073-10441:2015 Информатика в здравоохранении. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10441. Специализация прибора. Монитор физической активности пациентов, страдающих сердечно-сосудистыми заболеваниями (Health informatics - Personal health device communication - Part 10441: Device specialization - Cardiovascular fitness and activity monitor)
[20]
ISO/IEEE 11073-10442:2015 Информатика в здравоохранении. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10442. Специализация прибора. Силомер (Health informatics - Personal health device communication - Part 10442: Device specialization - Strength fitness equipment)
[21]
IEEE 11073-10471-2023 Информатика в здравоохранении. Взаимодействие устройств. Часть 10471: Связь с персональными медицинскими устройствами. Специализация устройств. Центр независимой жизнедеятельности (IEEE Health Informatics - Device Interoperability - Part 10471: Personal Health Device Communication - Device Specialization - Independent Living Activity Hub)
[22]
HL7 FHIR Release 5. - URL: https://hl7.org/fhir/index.html
[23]
Creative Commons. CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. - URL: https://creativecommons.org/publicdomain/zero/1.0/
[24]
HAPI FHIR: Complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. - URL: https://hapifhir.io/
[25]
RFC 4648 The Base16, Base32, and Base64 Data Encodings
[26]
RFC 3001 A URN Namespace of Object Identifiers
[27]
RFC 3986 Uniform Resource Identifier (URI): Generic Syntax
[28]
RFC 1738 Uniform Resource Locators (URL)
[29]
RFC 4122 A Universally Unique IDentifier (UUID) URN Namespace
[30]
RFC 4647 Matching of Language Tags
[31]
RFC 7515 JSON Web Signature (JWS)
[32]
HL7 FHIR Personal Health Device Implementation Guide. - URL: https://github.com/HL7/phd/
[33]
RFC 8288 Web Linking
[34]
Федеральный закон от 21 ноября 2011 г. N 323-ФЗ "Об основах охраны здоровья граждан в Российской Федерации"
[35]
Постановление Правительства Российской Федерации от 31 мая 2023 г. N 894 "Об утверждении Правил маркировки отдельных видов медицинских изделий средствами идентификации и особенностях внедрения государственной информационной системы мониторинга за оборотом товаров, подлежащих обязательной маркировке средствами идентификации, в отношении отдельных видов медицинских изделий"
[36]
Personal Health Devices Transcoding. - URL: https://www.bluetooth.com/wp-content/uploads/2019/03/PHD_Transcoding_WP_v16.pdf
[37]
Unified Code for Units of Measure (UCUM). - URL: https://ucum.org/
[38]
ISO/IEEE 11073-20601:2022 Информатизация здоровья. Взаимодействие с приборами. Часть 20601. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Прикладной профиль. Оптимизированный протокол обмена (Health informatics - Device interoperability - Part 20601: Personal health device communication - Application profile - Optimized exchange protocol)
[39]
RFC 5005 Feed Paging and Archiving
[40]
RFC 2388 Returning Values from Forms: multipart/form-data
[41]
ITU-T. Technical Paper (17 October 2019). HSTP-H812-FHIR In-teroperability design guidelines for personal health systems: Services interface: FHIR Observation Upload for trial implementation
[42]
RFC 6749 The OAuth 2.0 Authorization Framework
[43]
RFC 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
УДК 004:61:006.354
ОКС 35.240.80
Ключевые слова: киберфизические системы, персональные медицинские помощники, форматы обмена данными