3.3
3.4
3.5
3.6 шлюз Интернета вещей: Узел, получающий данные от одного или нескольких персональных медицинских приборов по протоколу Интернета вещей.
АСН.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).
Форматы обмена данными между персональным медицинским прибором (ПМП) и шлюзом Интернета вещей или менеджером персональных медицинских приборов (далее - менеджер ПМП или менеджер) регламентируются на прикладном уровне модели взаимосвязи открытых систем (см. ГОСТ Р ИСО/МЭК 7498-1). Общие требования к этим форматам установлены в стандарте ГОСТ Р 56845. Для ряда специализаций персональных медицинских приборов эти требования конкретизированы в [1] - [21].
В состав форматов обмена данными входят элементы с кодируемыми значениями. В качестве системы кодирования этих значений следует использовать номенклатуру коммуникаций с медицинскими приборами MDC, определенную в ГОСТ Р 56842. Стандарты специализаций приборов содержат дополнения к этой номенклатуре.
Если персональный медицинский прибор не поддерживает обмен данными в соответствии с ГОСТ Р 56845, то рекомендуется обеспечить преобразование его данных в форматы, предусмотренные ГОСТ Р 56845 и ГОСТ Р 56842. Такое преобразование может быть выполнено с помощью специализированного модуля в составе программного обеспечения менеджера ПМП или шлюза Интернета вещей.
Взаимодействия с сервисом хранения и обработки результатов измерений описаны на уровне архитектурного стиля REST с использованием протокола HTTP. В основу требований к этим взаимодействиям положена спецификация FHIR - ресурсы быстрой интероперабельности в здравоохранении версии 5.0 [22], разработанная организацией HL7. Эта спецификация предоставляется по лицензии Creative Commons "No Rights Reserved" [23], то есть без сохранения прав. Ограничения накладываются только на использование товарных знаков
.Настоящий стандарт не противоречит спецификации [22], и предложенные в нем форматы обмена могут быть реализованы с помощью свободно распространяемого программного обеспечения HAPI FHIR [24].
Примечание - Применение других версий спецификации FHIR, а также набора используемых ресурсов допустимо для существующих информационных систем в ПМП при наличии опубликованных интеграционных профилей (документов, регламентирующих порядок взаимодействия и описание ресурсов).
Сервис хранения и обработки результатов измерений получает и предоставляет данные с помощью запросов HTTP в архитектурном стиле REST. Эти данные поступают в хранилище результатов измерений. Модель данных хранилища результатов измерений описана в терминах ресурсов данных и их профилей.
Выбор типов ресурсов данных определен исходя из следующего сценария:
а) основным назначением сервиса хранения и обработки результатов измерений (далее - сервис) является обеспечение информационного взаимодействия между пациентом и лечащим врачом в процессе дистанционного мониторинга;
б) для взаимодействия пациент использует персональные медицинские приборы и менеджеры этих приборов (в качестве менеджеров могут выступать смартфоны, планшеты, персональные компьютеры, облачные решения и шлюзы Интернета вещей), а врач использует рабочее место МИС;
в) дистанционный мониторинг осуществляется в соответствии с планом ведения, назначенным лечащим врачом;
г) план ведения ограничен следующими мероприятиями:
1) сбор результатов измерений, выполняемых ПМП,
2) ведение дневников питания, самонаблюдений, приема лекарств,
3) передача пациенту этапного эпикриза в процессе выполнения плана ведения и по его завершении;
д) в процессе выполнения плана пациенту и лечащему врачу могут выдаваться предупреждения и напоминания, например предупреждения об аномальном результате измерений или напоминания о необходимости приема лекарственного препарата;
е) состав информации, передаваемый сервису хранения и обработки результатов измерений, должен быть минимально достаточным для взаимодействия пациента с лечащим врачом в рамках назначенного плана ведения.
Концептуальная диаграмма хореографии данного сценария показана на рисунке 2.
![]() Взаимодействие менеджера ПМП с сервисом может осуществляться не только по подписке, например, с помощью запросов на получение данных, передаваемых сервису по расписанию.
МИС передает сервису запросы на регистрацию подписки участникам взаимодействия (рисунок 3), а затем отправляет сервису план ведения дистанционного мониторинга, который по подписке доставляется менеджеру ПМП (рисунок 4). Взаимодействие участников при выполнении плана ведения показано на рисунке 5.
![]() ![]() ![]() ПМП выполняет измерение и передает полученный результат менеджеру ПМП или шлюзу Интернета вещей, который преобразует результат в формат REST API и передает его сервису. Преобразованный результат по подписке или по запросу доставляется МИС. Если результат выходит за пределы целевого диапазона, указанного в плане ведения, то МИС передает сервису соответствующее предупреждение, которое по подписке доставляется менеджеру ПМП и затем пациенту. По событию, предусмотренному в плане ведения, например, по завершению плана ведения или по истечению определенного срока, в МИС формируется этапный эпикриз, который может быть передан сервису и в соответствии с порядком взаимодействия доставляется менеджеру ПМП и затем пациенту.
В процессе выполнения план может быть скорректирован (рисунок 6).
![]() При реализации этой схемы должна быть использована машина рабочих процессов, контролирующая выполнение мероприятий, назначенных в плане ведения, и инициирующая передачу менеджеру ПМП (а через него пациенту) соответствующих предупреждений и напоминаний. Такая машина может быть развернута в менеджере ПМП, в сервисе, в МИС или в облачном решении. Размещение машины рабочих процессов и взаимодействие с ней не входит в область применения настоящего стандарта.
Персональный медицинский прибор может быть связан с менеджером ПМП, и в этом случае менеджер будет осуществлять преобразование результата измерений в формат REST API и передачу преобразованного результата сервису хранения результатов измерений.
Предупреждение об аномальном результате измерений или ином событии, требующем реакции от пациента, может формироваться автоматически, например, при получении от ПМП статуса ошибки позиционирования датчика, или с участием медицинского работника. Эти детали информационного взаимодействия влияют на содержание передаваемых данных и события передачи, но используемые типы ресурсов могут оставаться теми же самыми.
Для большей части выбранных типов ресурсов рекомендованы профили, которые могут быть доработаны с учетом особенностей реализации сервиса хранения и обработки результатов измерений и потенциального расширения специализаций персональных медицинских приборов и их функций. В связи с этим для выбранных типов ресурсов даются полные описания, которые могут быть использованы для решения более широких задач, и на основе этих описаний предлагаются профили, специфичные для задачи дистанционного мониторинга.
Метамодель данных хранилища результатов измерений основана на спецификации [22].
Верхний уровень метамодели данных хранилища результатов измерений показан на рисунке 7.
![]() хранилища результатов измерений
Он представлен следующими пакетами сущностей:
а) ресурсы данных - ресурсы REST, с помощью которых хранилище импортирует и экспортирует результаты измерений;
б) терминологические ресурсы - коллекции кодируемых понятий, представленные в форме систем кодирования и наборов значений;
в) типы данных - простые и комплексные типы данных, используемые при описании элементов ресурсов данных;
г) Rest API - операции над экземплярами ресурсов данных.
При описании ресурсов данных используются сущности, представленные на рисунке 8.
![]() Центральной сущностью является ресурс. Экземпляр ресурса представляет собой информационный объект, обладающий следующими свойствами:
а) имеет определенную идентификацию, по которой его можно адресовать в информационных ресурсах;
б) имеет один из типов, определенных в информационной модели предметной области;
в) содержит совокупность структурированных элементов данных, описанных в определении типа ресурса;
г) имеет определенную версию, которая изменяется при изменении экземпляра ресурса;
д) имеет несколько представлений (XML, JSON).
Экземпляр ресурса может включать в себя другой экземпляр ресурса по ссылке или по значению. Вложение экземпляров может иметь только один уровень. Ссылка дается на весь экземпляр, сослаться на часть его элементов нельзя.
На элементы ресурса могут быть наложены ограничения. Каждое ограничение имеет:
а) уникальный идентификатор;
б) степень строгости (является ли нарушение ограничения ошибкой или предупреждением);
в) место применения ограничения (путь в описании структуры типа ресурса);
г) человеко-читаемое описание;
д) логическое выражение на формальном языке, которое должно быть истинным при выполнении ограничения (инвариант).
Специфическим видом ограничения является привязка элемента с кодированным значением к конкретному набору значений.
Для каждого типа ресурсов (не являющегося абстрактным) задаются параметры поиска его экземпляров. Определение параметра имеет следующие элементы:
а) имя параметра;
б) тип значения параметра;
в) человеко-читаемое описание;
г) индексное выражение.
Определение типа ресурса является рамочным и рассчитано на использование в различном контексте. Для конкретной предметной области обычно требуется адаптировать его определение, в том числе:
а) описать правила использования или неиспользования элементов ресурса;
б) добавить элементы, не предусмотренные в определении типа ресурса;
в) указать или изменить терминологические ресурсы, которые могут использоваться для элементов с кодированными значениями.
Такая адаптация называется профилем. Профиль может быть основан на типе ресурса или на другом профиле.
Типы ресурсов, используемые в хранилище результатов измерений, описаны в разделе 11.
Все типы данных являются потомками абстрактного типа Element. Простые типы данных являются потомками абстрактного типа PrimitiveType, а комплексные - потомками абстрактного типа DataType. В свою очередь комплексные типы данных подразделяются на комплексные типы данных общего назначения, специальные комплексные типы и типы метаданных. Комплексные типы данных могут иметь компоненты простого или комплексного типа общим числом не менее двух (рисунок 9).
![]() Тип Element является базовым для всех сущностей модели данных - типов данных, типов ресурсов, вспомогательных классов. Общие сведения о типе Element приведены в таблице 1, а состав элементов - в таблице 2.
Таблица 1
Таблица 2
К типу Element применяется ограничение, приведенное в таблице 3. Оно означает, что значение элемента экземпляра ресурса может отсутствовать только в том случае, если у него есть одно или несколько расширений. Пустой элемент должен исключаться из экземпляра ресурса.
Таблица 3
Идентификатор 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.
Терминологические ресурсы подразделяются на системы кодирования и наборы значений (рисунок 10). Система кодирования описывает коллекцию кодированных понятий (справочник, классификатор). Каждое понятие имеет код, значение, определение и может иметь дополнительные свойства. Набор значений представляет собой объединение подмножеств, взятых из системы кодирования и других наборов значений. Правила формирования этих подмножеств сформулированы с помощью определения. Для получения полного списка понятий, описываемого набором значений, используется операция $expand (раскрыть).
![]() Система кодирования описана в форме экземпляра ресурса CodeSystem (пункт 15.1.2), набор значений - в форме экземпляра ресурса ValueSet (пункт 15.2.2).
Прикладной программный интерфейс (Application Program Interface) хранилища результатов измерений предоставляет методы, приведенные на рисунке 11.
![]() Метод Создать используется для создания нового экземпляра ресурса заданного типа. Он вызывается с помощью метода HTTP POST, например POST /template/go.php?url=https://example.com/base/{типРесурса}.
Метод Заменить используется для замены всего содержания существующего экземпляра ресурса. Он вызывается с помощью метода HTTP PUT, например PUT /template/go.php?url=https://example.com/base/{типРесурса}/{id}, где id - уникальный логический идентификатор экземпляра ресурса.
Метод Исправить используется для изменения части содержания существующего экземпляра ресурса. Он вызывается с помощью метода HTTP PATCH, например PATCH /template/go.php?url=https://example.com/base/{типРесурса}/{id}, где id - уникальный логический идентификатор экземпляра ресурса.
Метод Получить историю используется для получения истории изменения содержания экземпляра ресурса. Он вызывается с помощью метода HTTP GET, например GET /template/go.php?url=https://example.com/base/{типРесурса}/{id}/_history, где id - уникальный логический идентификатор экземпляра ресурса.
Метод Прочитать используется для получения текущего содержания экземпляра ресурса. Он вызывается с помощью метода HTTP GET, например GET /template/go.php?url=https://example.com/base/{типРесурса}/{id}, где id - логический уникальный идентификатор экземпляра ресурса.
Метод Найти используется для поиска экземпляров ресурсов, удовлетворяющих заданным критериям. Он вызывается с помощью метода HTTP GET например GET /template/go.php?url=https://example.com/base/{типРесурса}?параметры_поиска....
Метод Вызвать операцию используется для применения операции к содержанию экземпляра ресурса. Он вызывается с помощью метода HTTP GET например /template/go.php?url=https://example.com/base/{типРесурса}/{id}/${имяОперации}.
Метод Выполнить транзакцию используется для согласованного выполнения других методов над несколькими экземплярами ресурсов в одной транзакции. Он вызывается с помощью метода HTTP POST, например POST /template/go.php?url=https://example.com/base/, где тело запроса содержит спецификацию транзакции, составленную из экземпляров ресурсов и действий, выполняемых над этими экземплярами. Спецификация задается с помощью экземпляра ресурса Bundle (контейнер).
Метод Удалить используется для удаления текущего содержания существующего экземпляра ресурса. Он вызывается с помощью метода HTTP DELETE, например DELETE /template/go.php?url=https://example.com/base/{типРесурса}/{id}, где id - уникальный идентификатор экземпляра ресурса.
Детальная спецификация REST API приведена в разделе 12.
При описании типов данных и ресурсов используются следующие правила именования:
а) имена типов данных, ресурсов и их элементов должны допускать использование в программном коде. Поэтому для них задан шаблон [A-Za-z0-9\-\.]{1,64}. Кроме того, эти имена не должны совпадать с ключевыми словами языков программирования или языков манипулирования данными;
б) имя типа данных или ресурса должно быть значащим для человека, читающего программный код или составляющего запрос к базе данных. Поскольку шаблон имени допускает только буквы латинского алфавита, цифры, дефисы и точки, то для составления значащих имен следует использовать слова и сочетания слов на английском языке. Так как пробельные символы в именах не разрешены, то словосочетания следует записывать слитно в одном из двух вариантов "верблюжьей" нотации: lowerCamelCase (первое слово начинается в нижнем регистре, следующие слова - в верхнем, например managingOrganization) или UpperCamelCase (каждое слово начинается в верхнем регистре, например StructureDefinition). Все символы слова, кроме первого, должны записываться в нижнем регистре. При именовании должны соблюдаться следующие требования:
1) для имени следует использовать "наиболее широко используемый" термин данной предметной области;
2) имя должно полностью отражать значение моделируемого понятия;
3) существительные должны использоваться в единственном числе, даже если элемент кратный;
4) сокращения должны использоваться в крайних случаях;
5) при использовании сокращение должно трактоваться как слово (например, targetUri для обозначения ссылки на унифицированный идентификатор ресурса URI);
6) имена должны быть краткими (полное описание понятия должно даваться в определении);
7) не следует использовать суффиксы, подчеркивающие тип данных элемента (например, typeCode или nameText);
8) если подбор соответствующего термина на английском языке вызывает затруднение, следует обратиться к толковому словарю Webster (/template/go.php?url=https://www.webster-dictionary.org/), онлайновой платформе ISO (/template/go.php?url=https://www.iso.org/obp/ui) и другим ресурсам сети Интернет;
в) имя простого типа данных записывается в нотации lowerCamelCase. Дефисы и точки в имени простого типа данных не допускаются;
г) имя комплексного типа данных или ресурса записывается в нотации UpperCamelCase. Дефисы и точки в имени комплексного типа данных не допускаются;
д) имя элемента комплексного типа данных или ресурса записывается в нотации lowerCamelCase. Дефисы и точки в имени элемента не допускаются.
Для каждого комплексного типа данных и ресурса дается описание в форме диаграммы классов на языке UML и в форме иерархической таблицы. В общем случае комплексный тип данных или ресурс представляется в виде нескольких классов, включая головной класс с именем типа данных или ресурса и вспомогательные классы, связанные с головным и между собой отношениями направленной композиции. Цель композиции именуется по правилам, принятым для элемента комплексного типа данных, указанным в подразделе 8.1. Имена вспомогательных классов уникальны только в пределах конкретного комплексного типа данных или ресурса.
При описании классов на языке UML используется пользовательский профиль, описанный в приложении А.
Независимо от числа вспомогательных классов каждый комплексный тип данных или ресурс описывается одной иерархической таблицей, формат которой описан в таблице 4.
Таблица 4
На элементы структуры комплексного типа данных или типа ресурса могут быть наложены ограничения. Таблица ограничений имеет формат, приведенный в таблице 5.
Таблица 5
Для элементов структуры комплексного типа данных или типа ресурса, имеющих кодируемые значения, могут быть заданы привязки наборам значений. Таблица привязок имеет формат, приведенный в таблице 6.
Таблица 6
Таблица критериев поиска экземпляров ресурсов имеет формат, приведенный в таблице 7.
Таблица 7
В настоящем разделе представлены все типы данных, определенные в спецификации [22], вне зависимости от того, включены ли они в определение элементов ресурсов REST, составляющих хранилище результатов измерений. Это позволяет использовать настоящий раздел и для других предметных областей.
В нем приведены основные сведения о каждом типе данных, включая общие сведения, состав элементов (в форме диаграмм UML и в табличной форме), ограничения, наложенные на элементы, привязки к наборам значений. Дополнительные сведения, в том числе примеры, формальные описания в виде экземпляров ресурса StructureDefinition, схемы представлений в XML и JSON, приведены в спецификации [22].
Типы данных, определенные в [22], подразделяются на следующие категории:
а) простые типы данных;
б) комплексные типы данных:
1) типы данных общего назначения;
2) специальные типы данных;
3) типы метаданных.
Простые типы данных являются потомками абстрактного типа данных PrimitiveType, наследуют от него необязательный элемент уникального идентификатора id и возможность расширения.
Комплексные типы данных являются потомками абстрактного типа данных DataType (тип данных), наследуют от него необязательный элемент уникального идентификатора id и возможность расширения.
9.2.1 Общие сведения
Простые типы могут иметь элемент value (значение) и не имеют потомков (однако, как и любой другой тип данных, могут иметь расширения extension). Если расширения отсутствуют, то элемент value обязателен.
При описании простых типов элементу value сопоставляется примитивный тип данных спецификации схем XSD. Возможные значения элемента value могут быть ограничены регулярным выражением (regex), которое имеет рекомендательный характер и может уточняться на стадии реализации.
Диаграмма классов простых типов данных показана на рисунке 12. Перечень простых типов данных приведен в таблице 8.
Таблица 8
![]() Тип данных base64Binary предназначен для представления двоичного содержания. Общие сведения о типе данных base64Binary приведены в таблице 9, а состав элементов - в таблице 10.
Таблица 9
Таблица 10
Булевский тип данных (true/false). Общие сведения о типе данных boolean приведены в таблице 11, а состав элементов - в таблице 12.
Таблица 11
Таблица 12
Тип данных canonical используется для ссылок на экземпляр ресурса по его каноническому URL (для ресурсов, имеющих компонент url). Общие сведения о типе данных canonical приведены в таблице 13, а состав элементов - в таблице 14.
Таблица 13
Таблица 14
Тип данных code предназначен для представления перечислимых значений (контролируемых строк) и является специализацией строкового типа string. Общие сведения о типе данных code приведены в таблице 15, а состав элементов - в таблице 16.
Таблица 15
Таблица 16
Тип данных date используется для представления дат в соответствии со стандартом ГОСТ Р 7.0.64. Допускается указание даты с уменьшенной точностью (до месяца или года). Общие сведения о типе данных date приведены в таблице 17, а состав элементов - в таблице 18.
Таблица 17
Таблица 18
Тип данных dateTime используется для представления дат и времени в соответствии со стандартом ГОСТ Р 7.0.64. Допускается указание даты и времени с уменьшенной точностью (до минуты, часа, дня, месяца или года). Общие сведения о типе данных dateTime приведены в таблице 19, а состав элементов - в таблице 20.
Таблица 19
Таблица 20
Тип данных decimal предназначен для представления десятичных значений. Общие сведения о типе данных decimal приведены в таблице 21, а состав элементов - в таблице 22.
Таблица 21
Таблица 22
Тип данных id предназначен для представления идентификаторов. Общие сведения о типе данных id приведены в таблице 23, а состав элементов - в таблице 24.
Таблица 23
Таблица 24
Тип данных instant предназначен для представления штампа даты и времени с точностью до секунды или более высокой. Общие сведения о типе данных instant приведены в таблице 25, а состав элементов - в таблице 26.
Таблица 25
Таблица 26
Тип данных integer предназначен для передачи целочисленных значений. Общие сведения о типе данных integer приведены в таблице 27, а состав элементов - в таблице 28.
Таблица 27
Таблица 28
Тип данных integer64 предназначен для передачи больших целочисленных значений, которые могут принимать счетчики записей или таймеры. Общие сведения о типе данных integer64 приведены в таблице 29, а состав элементов - в таблице 30.
Таблица 29
Таблица 30
Тип данных markdown предназначен для удобочитаемого представления структурированного текста в соответствии со спецификацией GitHub Flavored Markdown (/template/go.php?url=https://github.github.com/gfm/). Общие сведения о типе данных markdown приведены в таблице 31, а состав элементов - в таблице 32.
Таблица 31
Таблица 32
Тип данных oid представляет глобально уникальные объектные идентификаторы (ОИД), присваиваемые в соответствии с регламентом, описанным в стандарте ГОСТ Р ИСО/МЭК 9834-1. Структура ОИД описана в стандарте ГОСТ Р ИСО/МЭК 8824-1, хранилище верхних уровней дерева ОИД представлено по адресу /template/go.php?url=https://oidref.com/, хранилище верхних уровней российской ветви 1.2.643 - по адресу /template/go.php?url=https://oid.iitrust.ru. ОИД является одним из вариантов унифицированного идентификатора ресурса URI и может быть представлен в форме URI. Это представление используется в типе данных oid. Общие сведения о типе данных oid приведены в таблице 33, а состав элементов - в таблице 34.
Таблица 33
Таблица 34
Тип данных positiveInt используется для представления положительных целых чисел. Общие сведения о типе данных positiveInt приведены в таблице 35, а состав элементов - в таблице 36.
Таблица 35
Таблица 36
Тип данных string представляет собой строковые данные в кодировке Unicode, которые могут быть записаны несколькими строками (то есть могут содержать символы возврата строки и перевода каретки). Общие сведения о типе данных string приведены в таблице 37, а состав элементов - в таблице 38.
Таблица 37
Таблица 38
Тип данных time используется для представления времени. Общие сведения о типе данных time приведены в таблице 39, а состав элементов - в таблице 40.
Таблица 39
Таблица 40
Тип данных unsignedInt используется для представления целых чисел без знака. Общие сведения о типе данных unsignedInt приведены в таблице 41, а состав элементов - в таблице 42.
Таблица 41
Таблица 42
Тип данных uri используется для представления унифицированных идентификаторов ресурсов. Он имеет три основные разновидности: объектные идентификаторы oid, универсальные уникальные идентификаторы uuid и унифицированные адреса ресурсов url. Общие сведения о типе данных uri приведены в таблице 43, а состав элементов - в таблице 44.
Таблица 43
Таблица 44
Тип данных url представляет унифицированные адреса ресурсов URL. Общие сведения о типе данных url приведены в таблице 45, а состав элементов - в таблице 46.
Таблица 45
Таблица 46
Тип данных uuid представляет универсально уникальные идентификаторы UUID (GUID) в форме URI. Общие сведения о типе данных uuid приведены в таблице 47, а состав элементов - в таблице 48.
Таблица 47
Таблица 48
9.2.22 Ограничения простых типов данных
Простые типы данных являются потомками типа данных PrimitiveType и наследуют его ограничение, представленное в таблице 49.
Таблица 49
Применительно к типам данных это ограничение трактуется следующим образом: если значение типа данных не указано, то должно присутствовать как минимум расширение extension, представляющее дополнительное свойство значения (например, причину его отсутствия).
9.3.1 Общие сведения
Диаграммы классов комплексных типов данных общего назначения показаны на рисунках 13 и 14. Перечень комплексных типов данных общего назначения приведен в таблице 50.
Таблица 50
![]() (начало)
![]() (окончание)
Тип данных Address описывает почтовый адрес лица или организации, но может также использоваться для указания мест, куда почта не доставляется. Общие сведения о типе данных Address приведены в таблице 51, а состав элементов - в таблице 52.
Таблица 51
Таблица 52
Привязки к наборам значений описаны в таблице 53.
Таблица 53
Тип данных Annotation используется для представления примечаний к содержанию ресурса. Общие сведения о типе данных Annotation приведены в таблице 54, а состав элементов - в таблице 55.
Таблица 54
Таблица 55
Тип данных Attachment используется для представления вложений в содержание экземпляров ресурсов или ссылок на эти вложения. Общие сведения о типе данных Attachment приведены в таблице 56, а состав элементов - в таблице 57.
Примечание - Для свертки данных рекомендуется использовать алгоритм ГОСТ Р 34.11.
Таблица 56
Таблица 57
Содержание, передаваемое в экземпляре ресурса Attachment, может передаваться по значению в элементе data или по ссылке в элементе url. Если указаны оба элемента, то ссылка должна указывать на те же самые данные, которое переданы в элементе data.
Элемент contentType должен быть заполнен, если данные передаются в элементе data, и может быть заполнен, если данные передаются по ссылке url.
Если элементы data и url отсутствуют, то это означает, что данные с указанным сочетанием типа содержания contentType и языка language отсутствуют.
Если данные передаются по ссылке, то в элементе hash можно задать их контрольную свертку, чтобы иметь возможность проверки целостности данных, возвращаемых по ссылке.
В ряде случаев кратность элемента ресурса, имеющего тип Attachment, может превышать 1. Правильное использование кратного элемента состоит в том, чтобы его экземпляры имели одно и то же содержание, но с разными типами содержания MIME и/или представленные на разных языках.
Ограничения типа данных Attachment описаны в таблице 58. Привязки к наборам значений описаны в таблице 59.
Таблица 58
Таблица 59
Тип данных CodeableConcept предназначен для представления кодированных понятий, при котором допускается указывать код, взятый из классификатора или справочника, код вместе с текстом, который детализирует значение кода (например, кода прочие), или только текст, если никакой код классификатора или справочника не может быть сопоставлен этому тексту. Общие сведения о типе данных CodeableConcept приведены в таблице 60, а состав элементов - в таблице 61.
Таблица 60
Таблица 61
В значении типа CodeableConcept можно передать несколько кодов из разных систем кодирования при условии, что все эти коды относятся к одному и тому же понятию. Например, в одном значении можно передать код из общероссийского классификатора и соответствующий ему код из местного справочника.
Тип данных Coding предназначен для представления кодированных значений. В отличие от CodeableConcept наличие текста, детализирующего значение кода, не предусмотрено. Общие сведения о типе данных Coding приведены в таблице 62, а состав элементов - в таблице 63.
Таблица 62
Таблица 63
Элемент code является кодом понятия. Элемент system в сочетании с версией version (если указана) идентифицирует систему кодирования. Элемент display содержит человеко-читаемый текст, предназначенный для визуализации вместо кода.
Если с течением времени кодированные понятия остаются неизменными, то версия version не нужна. Если система кодирования описывает полную классификацию (например, Международная статистическая классификация болезней и проблем, связанных со здоровьем), то версия version обязательна, поскольку при добавлении нового понятия значение кода, присвоенного "другим и неуточненным" понятиям, изменяется.
Элемент system должен содержать URI системы кодирования, а не набора значений (например, ValueSet.url), поскольку набор значений описывает множество допустимых кодов, но не связывает их с понятиями.
Элемент code должен являться символом, синтаксис которого определен в системе кодирования, идентифицируемой значением элемента system. В некоторых системах кодирования (например, посткоординируемых) коды могут представлять собой выражения, составленные из других заранее определенных кодов. Примером служат системы единиц измерения.
Если элемент display присутствует, то он должен содержать краткий человеко-читаемый текст, идентифицирующий понятие данной системы кодирования. С одним кодом может быть связано несколько текстов:
- основной, указанный в элементе CodeSystem.concept.display;
- дополнительные, указанные в элементах CodeSystem.concept.designation.value (например, переводы основного текста на другие языки).
Ограничения типа данных Coding описаны в таблице 64.
Таблица 64
Тип данных ContactPoint предназначен для представления контактной информации лица или организации. Общие сведения о типе данных ContactPoint приведены в таблице 65, а состав элементов - в таблице 66.
Таблица 65
Таблица 66
Ограничения типа данных ContactPoint описаны в таблице 67. Привязки к наборам значений описаны в таблице 68.
Таблица 67
Таблица 68
Тип данных HumanName предназначен для описания именования физического лица (фамилия, имя, отчество или другие имена). Общие сведения о типе данных HumanName приведены в таблице 69, а состав элементов - в таблице 70.
Именование лица может иметь ограниченный срок действия, задаваемый в элементе period.
Таблица 69
Таблица 70
В элементе given передаются все имена лица в том порядке, как это указано в свидетельстве о рождении или паспорте. Для российских граждан первый экземпляр элемента given должен содержать имя, второй - отчество (при наличии).
Элемент text (полное именование) предусмотрен на тот случай, если выделить имя, фамилию и другие структурированные компоненты не представляется возможным. Если заполнены и элемент text, и другие компоненты именования, то элемент text не должен содержать иные компоненты.
Привязки к наборам значений описаны в таблице 71.
Таблица 71
Тип данных Identifier представляет идентификатор сущности (субъекта или объекта) в пространстве имен, идентифицированном элементом system. Общие сведения о типе данных Identifier приведены в таблице 72, а состав элементов - в таблице 73.
Таблица 72
Таблица 73
Срок действия идентификатора задается элементом 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
Таблица 75
Тип данных Money предназначен для представления денежной суммы. Общие сведения о типе данных Money приведены в таблице 76, а состав элементов - в таблице 77.
Таблица 76
Таблица 77
Привязки к наборам значений описаны в таблице 78.
Таблица 78
Иногда денежная сумма должна представляться как дробь, числителем которой является денежная единица. В этом случае денежная сумма имеет тип данных Quantity с профилем MoneyQuantity, описанным в таблице 93.
Тип данных Period предназначен для представления периода времени или (неопределенного) момента времени внутри периода. Общие сведения о типе данных Period приведены в таблице 79, а состав элементов - в таблице 80.
Таблица 79
Таблица 80
Если элемент start отсутствует, то начало периода не известно. Отсутствие элемента end означает текущий период. В элементе end может быть указана фактическая или планируемая дата завершения периода (включительно).
Ограничения типа данных Period описаны в таблице 81.
Таблица 81
Тип данных Quantity предназначен для представления значения физической величины. Может быть указано точное значение или его нижняя либо верхняя оценка (используя свойство comparator). Общие сведения о типе данных Quantity приведены в таблице 82, а состав элементов - в таблице 83.
Таблица 82
Таблица 83
Ограничения типа данных Quantity описаны в таблице 84. Привязки к наборам значений описаны в таблице 85.
Таблица 84
Таблица 85
9.3.13 Специализации и профили типа данных Quantity
Специализация Distance ограничивает тип данных Quantity величинами расстояния.
Специализация Distance описана в таблице 86. Привязки к наборам значений описаны в таблице 87.
Таблица 86
Таблица 87
Специализация Age ограничивает тип данных Quantity величинами времени.
Специализация Age описана в таблице 88. Привязки к наборам значений описаны в таблице 89.
Таблица 88
Таблица 89
Специализация Count ограничивает тип данных Quantity безразмерными величинами с целочисленным значением.
Специализация Count описана в таблице 90.
Таблица 90
Специализация Duration ограничивает тип данных Quantity величинами времени.
Специализация Duration описана в таблице 91. Привязки к наборам значений описаны в таблице 92.
Таблица 91
Таблица 92
В дополнение к специализациям типа данных Quantity определен профиль SimpleQuantity, описанный в таблице 93.
Таблица 93
Это не отдельный тип данных, а ограничение типа данных Quantity.
В дополнение к специализациям типа данных Quantity определен профиль MoneyQuantity, описанный в таблице 94.
Таблица 94
Это не отдельный тип данных, а ограничение типа данных Quantity, используемое при представлении денежных сумм в форме дроби.
Тип данных Range предназначен для указания диапазона значений физических величин. Общие сведения о типе данных Range приведены в таблице 95, а состав элементов - в таблице 96.
Таблица 95
Таблица 96
Ограничения типа данных Range описаны в таблице 97.
Таблица 97
Тип данных Ratio предназначен для представления отношения двух физических величин в форме дроби. Тип данных может использоваться для представления обычной дроби, например, "2/3". Общие сведения о типе данных Ratio приведены в таблице 98, а состав элементов - в таблице 99.
Таблица 98
Таблица 99
Ограничения типа данных Ratio описаны в таблице 100.
Таблица 100
Тип данных RatioRange предназначен для представления диапазонов отношений двух физических величин, представленных в форме дроби. Общие сведения о типе данных RatioRange приведены в таблице 101, а состав элементов - в таблице 102.
Таблица 101
Таблица 102
Ограничения типа данных RatioRange описаны в таблице 103.
Таблица 103
Тип данных SampledData предназначен для представления серии считываний, осуществляемых приборами, например, кардиографами. Каждое считывание представляет собой десятичное значение или код. Результат измерения определяется по следующей формуле, содержащей значение i-го считывания data с поправками на смещение базового значения origin.value и масштабный коэффициент factor:
измеряемое значение[i] = SampledData.data[i] * SampledData.factor + SampledData.origin.value
Общие сведения о типе данных SampledData приведены в таблице 104, состав элементов - в таблице 105.
Таблица 104
Таблица 105
В дополнение к кодам 'E', 'U', 'L' могут использоваться другие коды, описанные в ссылочном экземпляре ресурса CodeMap, в котором должна быть только одна группа, не содержащая ни числовые значения, ни коды 'E', 'U', 'L' (и для безопасности 'e', 'u', 'l'). Дополнительные коды не должны содержать пробелы и escape-последовательности и не должны начинаться с цифр.
Привязки к наборам значений описаны в таблице 106.
Таблица 106
Тип данных Timing предназначен для представления списка повторяющихся событий. Правила повторения могут задаваться простыми кодом, указанным в поле code, или конструкцией типа Repeat, указанной в поле repeat. Общие сведения о типе данных Timing приведены в таблице 107, а состав элементов - в таблице 108.
Таблица 107
Таблица 108
Ограничения типа данных Timing описаны в таблице 109. Привязки к наборам значений описаны в таблице 110.
Таблица 109
Таблица 110
9.3.19.1 Общие сведения и состав элементов
Тип данных Signature предназначен для представления подписи, в том числе образца собственноручной подписи, в виде графического файла или сертификата усиленной квалифицированной электронной подписи. Общие сведения о типе данных Signature приведены в таблице 111, а состав элементов - в таблице 112.
Таблица 111
Таблица 112
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 (например, ' вместо ");
д) должна использоваться инструкция <?xml version="1.0" encoding="windows-1251"?>;
е) должен быть применен метод каноникализации Canonical XML 1.1 (/template/go.php?url=https://www.w3.org/TR/xml-c14n11).
Данный метод канонического представления идентифицируется, используя URI /template/go.php?url=https://hl7.org/fhir/canonicalization/xml. В дополнение к нему определены методы канонического представления, приведенные в таблице 113.
Таблица 113
содержания экземпляра ресурса в формате XML
9.3.19.5 Каноническое представление содержания экземпляра ресурса в формате JSON
Каноническое представление содержания экземпляра ресурса в формате JSON должно удовлетворять следующим требованиям:
а) в значениях свойств объектов и в XHTML представлении объекта Narrative не должно быть иных пробельных символов кроме пробела. При этом пробелы не должны быть кратными;
б) внутри каждого объекта свойства сортируются по алфавиту.
Данный метод канонического представления идентифицируется, используя URI /template/go.php?url=https://hl7.org/fhir/canonicalization/json. В дополнение к нему определены методы канонического представления, приведенные в таблице 114.
Таблица 114
содержания экземпляра ресурса в формате JSON
9.4.1 Общие сведения
Специальные типы данных используются для вспомогательных целей. Диаграмма классов, описывающая эти типы данных, показана на рисунке 15.
![]() Перечень специальных типов данных приведен в таблице 115.
Таблица 115
Базовый тип вспомогательных классов BackboneType является детализацией типа данных Element, добавляющей к его свойствам еще одно - modifierExtension (модифицирующее расширение). Общие сведения о типе данных BackboneType приведены в таблице 116, а состав элементов - в таблице 117.
Таблица 116
Таблица 117
Элемент записи электронной медицинской карты может представлять собой ссылку на конкретный экземпляр данных или на общее понятие. Например, лекарственный препарат может быть прописан в связи с головной болью, что указано кодом R51 классификации МКБ-10, или же в связи с результатами исследования, содержащимися в конкретном экземпляре ресурса Observation (исследование).
Возможность такой вариабельности предусмотрена в типе данных CodeableReference (ссылка на кодированное понятие или экземпляр ресурса). Общие сведения о типе данных CodeableReference приведены в таблице 118, а состав элементов - в таблице 119.
Таблица 118
Таблица 119
Если кодированное понятие и ссылка на экземпляр ресурса присутствуют одновременно, то они должны быть согласованы друг с другом. Например, если в concept.coding.code указан код головной боли, то ссылочный экземпляр ресурса должен описывать головную боль.
Тип данных DataType является базовым для всех типов данных. Общие сведения о базовом типе данных DataType приведены в таблице 120, а состав элементов - в таблице 121.
Таблица 120
Таблица 121
Тип данных Dosage используется для представления структурированных сведений о дозировке, указываемой в рецептах и описаниях лекарственных средств. Общие сведения о типе данных Dosage приведены в таблице 122, состав элементов представлен на рисунке 16 и в таблице 123. Ограничения типа данных Dosage описаны в таблице 124.
Таблица 122
![]() Таблица 123
Таблица 124
9.4.6.1 Общие сведения, состав, ограничения и привязки к наборам значений
Тип данных ElementDefinition используется в ресурсе StructureDefinition для формализованного описания элементов типов данных, ресурсов и расширений. Общие сведения о типе данных ElementDefinition приведены в таблице 125, состав элементов представлен на рисунке 17 и в таблице 126.
Таблица 125
![]() Таблица 126
Ограничения описаны в таблице 127, привязки к наборам значений - в таблице 128.
Таблица 127
Таблица 128
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
в зависимости от контекста
Примечания
1 Графы Определение типа: экземпляр ресурса StructureDefinition без элемента baseDefinition или имеющий поле derivationType со значением специализация.
2 Графы Определение ограничения типа: экземпляр ресурса StructureDefinition с элементом baseDefinition, имеющий поле derivationType со значением ограничение, то есть описание структуры, ограничивающей другую структуру:
3 В графах Определение ограничения типа используются следующие обозначения:
Зависимость использования пути path и типа type от контекста, в котором они используются, представлена в таблице 130.
Таблица 130
от контекста использования
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.
Тип данных Extension может использоваться для представления дополнительной информации, не являющейся частью базового определения ресурса или типа данных. Поскольку он наследует свойство extension с типом Extension и кратностью 0..* от типа данных Element, то внутри расширения могут быть другие расширения и т.д. Общие сведения о типе данных Extension приведены в таблице 131, а состав элементов - в таблице 132.
Таблица 131
Таблица 132
Имя value[x] означает, что тип значения определяется в зависимости от назначения расширения. В конкретном экземпляре типа данных Extension это имя должно заменяться на одно из имен, перечисленных в таблице 133.
Таблица 133
Тип данных Meta описывает метаданные экземпляра ресурса. Общие сведения о типе данных Meta приведены в таблице 134, а состав элементов - в таблице 135.
Таблица 134
Таблица 135
9.4.9.1 Общие требования
Тип данных Narrative (повествование) может использоваться для представления форматированного текста, описывающего содержание экземпляра ресурса. Этот текст может генерироваться по структурированному содержанию экземпляра ресурса, может расширять или дополнять это содержание, или отсутствовать. Назначение текста определяется полем status. Форматированный текст представлен в поле div с использованием упрощенного формата XHTML.
Общие сведения о типе данных Narrative приведены в таблице 136, а состав элементов - в таблице 137.
Таблица 136
Таблица 137
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="/template/go.php?url=https://www.w3.org/1999/xhtml">
<p>
Это <i>пример</i> с использованием <b>xhtml</b> форматирования
</p>
</div>
</narrative>
В представлении JSON фрагмент XHTML воспроизводится как строковое значение, например:
использованием <b>xhtml</b> форматирования</p></div>
В обоих представлениях должна использоваться кодировка windows-1251.
9.4.9.3 Ссылки на изображения
Текст в формате XHTML может содержать ссылки на изображения при условии, что эти изображения представлены в экземпляре ресурса в форме вложенных экземпляров ресурсов DocumentReference или Binary, например:
<Patient xmlns="/template/go.php?url=https://hl7.org/fhir">
<text>
<status value="generated"/>
<div xmlns="/template/go.php?url=https://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
9.4.9.6 Связывание повествовательного и структурированного содержания
В ряде случаев может оказаться полезным указание связи между повествовательным и структурированным содержанием экземпляра ресурса. Для этой цели используются расширения extension, имеющие следующие идентификаторы url:
а) /template/go.php?url=https://hl7.org/fhir/StructureDefinition/narrativeLink - ссылка из элемента структурированного содержания на фрагмент повествовательного содержания, не имеющая определенной семантики;
б) /template/go.php?url=https://hl7.org/fhir/StructureDefinition/originalText - ссылка из кодированного элемента структурированного содержания на фрагмент повествовательного содержания, имеющая семантику "текст, послуживший основанием для присваивания кода".
Пример использования расширения originalText:
{
"resourceType" : "Condition",
"text" : {
"status" : "additional",
"div": "<div xmlns=\"/template/go.php?url=https://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" : "/template/go.php?url=https://hl7.org/fhir/StructureDefinition/originalText",
}]
}
}
В этом примере фрагменту повествовательного содержания "астма" присвоен идентификатор 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 = /template/go.php?url=https://hl7.org/fhir/StructureDefinition/originalText и значением valueUrl = #a1, представляющим собой внутреннюю ссылку на фрагмент текста с идентификатором a1, послуживший основанием для присваивания кода МКБ.
Аналогичный метод может быть использован для ссылок в пределах контейнера Bundle. Но в этом случае идентификатору a1 должен предшествовать полный URL того экземпляра ресурса, внутри которого содержится ссылочный фрагмент:
<Bundle xmlns="/template/go.php?url=https://hl7.org/fhir">
<entry>
<fullUrl value="/template/go.php?url=https://example.org/fhir/Composition/abcdefghij"/>
<Composition>
<id value="c1"/>
<section>
...
<text>
<div xmlns="/template/go.php?url=https://www.w3.org/1999/xhtml">
...
<p>В анамнезе <span id="a1">астма</span></p>
...
</div>
</text>
</section>
</Composition>
</entry>
<entry>
<Condition>
<code>
<extension url="/template/go.php?url=https://hl7.org/fhir/StructureDefinition/originalText">
<valueUrl value="/template/go.php?url=https://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.1 Общие требования, состав и ограничения
Тип данных Reference используется для представления ссылки на экземпляр ресурса. Например, экземпляр ресурса Organization (организация) может ссылаться на экземпляр ресурса EndPoint, описывающий сервис, предоставляемый организацией в сети Интернет. Общие сведения о типе данных Reference приведены в таблице 139, а состав элементов - в таблице 140. Ограничения типа данных Reference описаны в таблице 141.
Таблица 139
Таблица 140
Таблица 141
9.4.10.2 Тип целевого ресурса
В экземпляре ресурса элемент, имеющий тип данных Reference, всегда ссылается другой экземпляр фиксированного и известного типа. В принципе тип целевого ресурса может быть определен при разрешении ссылки с помощью анализа ссылочного содержания, но это может оказаться очень затратной операцией. Поэтому целесообразно тип указывать в ссылке, например:
}
Если тип указан в ссылке, то он должен совпадать с типом ресурса, разрешенного по значению элемента reference. Элемент type имеет тип uri и должен представляться по отношению к базовому URL /template/go.php?url=https://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=
</identifier>
</patient>
Компонент identifier ссылки типа Reference не обязан указывать на фактически существующий экземпляр ресурса REST, достаточно того, что ссылочный объект в принципе может быть представлен в виде такого экземпляра.
Поскольку ссылка по логическому идентификатору может оказаться не разрешаемой, то такие механизмы, как поиск по цепочке ссылок (chaining) или включение в результат поиска ссылочных экземпляров (include) со ссылками по логическому идентификатору не работают.
Если в ссылке указаны и литеральный, и логический идентификатор, то приоритет отдается литеральному идентификатору.
Тип данных xhtml используется для представления форматированного текста с упрощенной разметкой XHTML. Общие сведения о типе данных xhtml приведены в таблице 142. Этот тип данных не имеет собственных элементов.
Таблица 142
Примечания
1 Упрощенный XHTML содержит только базовые элементы и атрибуты HTML, описанные в главах 7 - 11 и 15 стандарта HTML 4.0 (исключая раздел 4 главы 9), элементы <a> (с атрибутами name или href), изображения и атрибуты стилей.
2 Допускается использовать только ссылки на стили, указываемые в атрибутах class и id элементов XHTML. Разрешены стили, приведенные в таблице 138.
3 При сериализации в XML следует указывать пространство имен /template/go.php?url=https://www.w3.org/1999/xhtml, например:
<div xmlns=
<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.1 Общие сведения
Типы метаданных используются для представления метаданных описаний типов ресурсов и типов данных. Диаграмма классов, описывающая эти типы данных, показана на рисунке 18.
![]() Перечень типов метаданных приведен в таблице 143.
Таблица 143
Тип данных Availability используется для сведений о доступности физического места, службы или медицинского работника. Общие сведения о типе данных Availability приведены в таблице 144, а состав элементов - на рисунке 19 и в таблице 145.
Таблица 144
![]() Таблица 145
Ограничения описаны в таблице 146, привязки к наборам значений - в таблице 147.
Таблица 146
Таблица 147
Тип данных ContactDetail используется для представления списка контактных данных лица или организации. Общие сведения о типе данных ContactDetail приведены в таблице 148, а состав элементов - в таблице 149.
Таблица 148
Таблица 149
Тип данных Contributor используется для представления сведений об участнике ресурса знаний. Общие сведения о типе данных Contributor приведены в таблице 150, а состав элементов - в таблице 151.
Таблица 150
Таблица 151
Тип данных DataRequirement определяет общие требования к данным ресурса знаний. Общие сведения о типе данных DataRequirement приведены в таблице 152, а состав элементов - на рисунке 20 и в таблице 153.
Таблица 152
![]() Таблица 153
Ограничения описаны в таблице 154, привязки к наборам значений - в таблице 155.
Таблица 154
Таблица 155
Тип данных Expression описывает выражение на определенном языке (идентифицируемом типом среды MIME), которое может использоваться для получения значения. Общие сведения о типе данных Expression приведены в таблице 156, а состав элементов - в таблице 157.
Таблица 156
Таблица 157
Ограничения описаны в таблице 158, привязки к наборам значений - в таблице 159.
Таблица 158
Таблица 159
Таблица 160
Тип данных ExtendedContactDetail описывает детальную контактную информацию лица или организации. Общие сведения о типе данных ExtendedContactDetail приведены в таблице 161, а состав элементов - в таблице 162.
Таблица 161
Таблица 162
Привязки к наборам значений описаны в таблице 163.
Таблица 163
Тип данных MonetaryComponent описывает компонент цены, например, скидка, налог, вычет. Общие сведения о типе данных MonetaryComponent приведены в таблице 164, а состав элементов - в таблице 165.
Таблица 164
Таблица 165
Привязки к наборам значений приведены в таблице 166.
Таблица 166
Тип данных ParameterDefinition используется для описания входных или выходных параметров. Общие сведения о типе данных ParameterDefinition приведены в таблице 167, а состав элементов - в таблице 168.
Таблица 167
Таблица 168
Тип данных RelatedArtifact описывает сведения о различных артефактах, связанных с ресурсами знаний, например, о версиях документов, библиографии и т.д. Общие сведения о типе данных RelatedArtifact приведены в таблице 169, а состав элементов - в таблице 170.
Таблица 169
Таблица 170
Привязки к наборам значений описаны в таблице 171.
Таблица 171
Тип данных TriggerDefinition описывает события, инициирующие применение ресурса знаний. Общие сведения о типе данных TriggerDefinition приведены в таблице 172, а состав элементов - в таблице 173.
Таблица 172
Таблица 173
Ограничения описаны в таблице 174, привязки к наборам значений - в таблице 175.
Таблица 174
Таблица 175
Тип данных UsageContext используется для представления контекста, в котором используется ресурс. Примерами типов контекста служат пол, возраст, категория пользователя и т.д. Общие сведения о типе данных UsageContext приведены в таблице 176, а состав элементов - в таблице 177.
Таблица 176
Таблица 177
Тип данных VirtualServiceDetail используется для идентификации службы дистанционной коммуникации. Общие сведения о типе данных VirtualServiceDetail приведены в таблице 178, а состав элементов - в таблице 179.
Таблица 178
Таблица 179
Привязки к наборам значений описаны в таблице 180.
Таблица 180
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.1 Общие сведения
Базисные ресурсы перечислены в таблице 181. Они представляют собой абстрактные классы и не имеют собственных экземпляров.
Таблица 181
10.2.2.1 Область применения и использования
Базисный ресурс Resource является родителем каждого конкретного ресурса. С помощью унаследованных от него необязательных элементов можно задать идентификатор экземпляра ресурса, ссылку на его метаданные, ссылку на правила, которым надо следовать при создании экземпляра, человеческий язык, на котором представлено содержание экземпляра ресурса.
10.2.2.2 Структура ресурса
Состав элементов ресурса Resource представлен на рисунке 21 и в таблице 182.
![]() Таблица 182
10.2.2.3 Привязки к наборам значений
Привязки к наборам значений перечислены в таблице 183.
Таблица 183
10.2.2.4 Логический идентификатор id и другие идентификаторы экземпляров ресурсов
Экземпляр ресурса может быть идентифицирован двумя разными способами:
а) по адресу URL местонахождения экземпляра (основанному на "логическом" идентификаторе id). Этот адрес изменяется при перемещении экземпляра из одного места в другое;
б) по некоторому "внутренне присущему" идентификатору ("бизнес-идентификатору" или "каноническому URL"), являющемуся значением одного из элементов ресурса и остающемуся неизменным при перемещении экземпляра из одного места в другое.
Каждый ресурс наследует элемент id (логический идентификатор) от ресурса Resource. При создании экземпляра ресурса сервер присваивает этому идентификатору определенное значение, уникальное среди всех экземпляров ресурса данного типа. Пока экземпляр хранится на этом сервере, значение идентификатора id не изменяется.
Местонахождение экземпляра задается абсолютным адресом URL, сконструированным из базового URL, имени типа ресурса и логического идентификатора, например: /template/go.php?url=https://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 рекомендована привязка к набору значений /template/go.php?url=https://hl7.org/fhir/ValueSet/languages, охватывающему наиболее распространенные коды языка.
10.2.2.7 Метаданные ресурса meta
Каждый тип ресурса наследует от ресурса Resource элемент метаданных meta типа Meta, значения которого имеют служебный характер и могут использоваться для ограничения доступа к экземпляру ресурса, форматно-логического контроля его содержания, обеспечения версионности, а также для других целей, в том числе определяемых пользователем. Компоненты типа данных Meta описаны в пункте 9.4.8.
10.2.3.1 Область применения и использования
Базисный ресурс DomainResource является детализацией абстрактного ресурса Resource и в свою очередь является абстрактным. Он описывает расширения содержания экземпляра ресурса и вложенные в него экземпляры ресурсов.
10.2.3.2 Структура ресурса
Состав элементов ресурса DomainResource представлен на рисунке 22 и в таблице 184.
![]() Таблица 184
10.2.3.3 Ограничения ресурса DomainResource
Ограничения ресурса DomainResource описаны в таблице 185.
Таблица 185
10.2.3.4 Использование вложенных ресурсов
Вложенный экземпляр ресурса существует только в содержащем его экземпляре. Обычно вложенные экземпляры используются, если у них отсутствует уникальный идентификатор. Например, в тонометре, рассчитанном на двух пациентов, в качестве идентификатора пациента используется номер группы памяти. Тогда в экземпляр ресурса Observation, содержащий результат измерения, можно вложить экземпляр ресурса Patient, в котором в качестве идентификатора указан номер группы памяти.
10.2.3.5 Параметры поиска
Параметры поиска, общие для всех потомков ресурса DomainResource, описаны в таблице 186.
Таблица 186
10.3.1 Общие сведения
Ресурсы общего назначения, которые могут быть использованы в запросах REST API и в ответах на эти запросы, перечислены в таблице 187.
Таблица 187
10.3.2.1 Область применения и использования
Ресурс Bundle служит для сборки экземпляров ресурсов в единый контейнер. Такие контейнеры используются для разных целей, в том числе:
а) возвращение коллекции экземпляров ресурсов, отобранной в соответствии с критериями поиска;
б) возвращение коллекции версий экземпляра ресурса для целей анализа истории изменений;
в) передача нескольких экземпляров ресурсов в одном сообщении;
г) группировка экземпляров ресурсов в самодостаточный комплекс, обладающий семантической целостностью, например медицинский документ;
д) создание, изменение и удаление нескольких экземпляров ресурсов в одной транзакции;
е) передача уведомлений о событиях по теме подписки;
ж) сохранение коллекции экземпляров ресурсов.
10.3.2.2 Структура ресурса
Ресурс Bundle является детализацией абстрактного ресурса Resource. Состав элементов ресурса Bundle представлен на рисунке 23 и в таблице 188.
![]() Таблица 188
10.3.2.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 189.
Таблица 189
10.3.2.4 Ограничения ресурса Bundle
Ограничения ресурса Bundle приведены в таблице 190.
Таблица 190
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 отсутствует, например, /template/go.php?url=https://fhir.example.org/base/Patient/123), то выполнить поиск элемента entry.fullUrl, значение которого совпадает со значением ссылки reference.value;
б) если найден один такой элемент, то в качестве ссылочного экземпляра ресурса следует использовать entry.resource;
в) если найдено несколько таких элементов, то сервер может выбрать из них тот, который имеет наибольшее значение времени последнего изменения, указанного в элементе meta.lastUpdated;
г) если ссылка reference.value содержит указание версии (то есть компонент /_history присутствует, например: /template/go.php?url=https://fhir.example.org/base/Patient/123/_history/a), то разбить ее значение на две части: ссылка без указания версии (например, /template/go.php?url=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 (например, /template/go.php?url=https://fhir.example.org/ + Patient/123 --> /template/go.php?url=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
Специальные параметры поиска экземпляров ресурса Bundle описаны в таблице 191. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 191.
Таблица 191
10.3.3.1 Область применения и использования
Ресурс MessageHeader используется в качестве заголовка сообщения в составе контейнера Bundle, у которого элемент type имеет значение message.
10.3.3.2 Структура ресурса
Ресурс MessageHeader является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса MessageHeader представлен на рисунке 24 и в таблице 192.
![]() Таблица 192
10.3.3.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 193.
Таблица 193
10.3.3.4 Использование ресурса MessageHeader
Время события, инициировавшего передачу сообщения, должно быть указано в экземпляре ресурса, на который дана ссылка в элементе focus. Время формирования сообщения должно быть указано в элементе Bundle.timestamp.
Получатель сообщения не обязан отклонять его, если ссылка в элементе receiver относится к другому субъекту. Например, он может выполнять роль регистратора или маршрутизатора сообщений.
Все экземпляры ресурсов, на которые ссылаются элементы MessageHeader.focus, должны находиться внутри контейнера сообщения.
Ссылочные экземпляры ресурсов автора и ответственного могут быть включены в контейнер сообщения или находиться за его пределами, если получатель сообщения может получить к ним доступ. В качестве автора или ответственного могут выступать как информационные системы, так и лица или организации, использующие информационные системы.
10.3.3.5 Параметры поиска экземпляров ресурса MessageHeader
Специальные параметры поиска экземпляров ресурса MessageHeader описаны в таблице 194. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 194
ресурса MessageHeader
10.3.4.1 Область применения и использования
Ресурс OperationOutcome (результат операции) служит для описания ошибок, предупреждений и информационных сообщений о результате предпринятой системой операции. Он используется в первую очередь для передачи следующих сведений:
- ошибка взаимодействия REST или выполнения операции;
- применения операции $validate (проверка содержания экземпляра ресурса на соответствие правилам);
- ошибка обработки сообщения;
- ошибка обработки транзакции или пакета;
- информация о поиске (в контейнере результата поиска Bundle).
10.3.4.2 Структура ресурса
Ресурс OperationOutcome является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса OperationOutcome представлен на рисунке 25 и в таблице 195.
![]() Таблица 195
10.3.4.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 196.
Таблица 196
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='/template/go.php?url=https://example.com/mrn').value
При выполнении запросов на поиск сведения об ошибках могут возвращаться также в заголовках HTTP. Эти сведения возвращаются, используя выражение, чувствительное к регистру и состоящее из двух частей: префикс "http" и заголовок либо имя параметра запроса, отделенное от префикса точкой. Примеры таких выражений приведены в таблице 197.
Таблица 197
Эта нотация следует соглашениям, по которым заголовки HTTP должны начинаться символом в верхнем регистре, а параметры, передаваемые в адресной строке URL, должны начинаться символом в нижнем регистре.
10.3.5.1 Область применения и использования
Ресурс Parameters (параметры операции) служит для описания параметров, которые могут передаваться операции или возвращаться ею. У этого ресурса нет собственной конечной точки.
10.3.5.2 Состав ресурса
Диаграмма классов UML ресурса Parameters показана на рисунке 26, состав элементов приведен в таблице 198.
![]() Таблица 198
10.3.5.3 Ограничения
Ограничения ресурса Parameters приведены в таблице 199.
Таблица 199
10.3.6.1 Область применения и использования
Тип ресурса Subscription описывает подписку на уведомления об изменении экземпляров ресурсов, предоставляемые сервером другой системе (клиенту). Темы подписки, поддерживаемые сервером, описаны с помощью экземпляров ресурса SubscriptionTopic, в которых может быть определен набор допустимых фильтров (в элементе SubscriptionTopic.canFilterBy). При регистрации подписки клиенты могут указать требуемые им фильтры (из числа допустимых) в элементе Subscription.filterBy. Как только подписка зарегистрирована, любое событие, удовлетворяющее теме подписки и фильтрам (если они указаны), вызывает отправку клиенту уведомления об этом событии по заданному каналу. Уведомление представляет собой контейнер Bundle типа subscription-notification, в котором первая запись Bundle.entry содержит экземпляр ресурса SubscriptionStatus (статус подписки).
Канал, по которому должны передаваться уведомления, указан в элементе Subscription.channel, а адрес передачи уведомлений - в элементе Subscription.endpoint (конечная точка). В спецификации [22] определены каналы, приведенные в таблице 200. При необходимости могут быть реализованы другие каналы уведомлений.
Таблица 200
subscription-channel-type
10.3.6.2 Структура ресурса
Ресурс Subscription является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Subscription представлен на рисунке 27 и в таблице 201.
![]() Таблица 201
10.3.6.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 202.
Таблица 202
10.3.6.4 Ограничения ресурса Subscription
Ограничения ресурса Subscription описаны в таблице 203.
Таблица 203
10.3.6.5 Параметры поиска экземпляров ресурса Subscription
Специальные параметры поиска экземпляров ресурса Subscription описаны в таблице 204. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 204
ресурса Subscription
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.1 Область применения и использования
Тип ресурса SubscriptionTopic описывает тему подписки на уведомления об изменении экземпляров ресурсов, предоставляемые сервером другой системе (клиенту).
10.3.7.2 Структура ресурса
Ресурс SubscriptionTopic является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса SubscriptionTopic представлен на рисунке 28 и в таблице 205.
![]() Таблица 205
10.3.7.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 206.
Таблица 206
10.3.7.4 Ограничения ресурса SubscriptionTopic
Ограничения ресурса SubscriptionTopic описаны в таблице 207.
Таблица 207
10.3.7.5 Параметры поиска экземпляров ресурса SubscriptionTopic
Специальные параметры поиска экземпляров ресурса SubscriptionTopic описаны в таблице 208. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 208
ресурса SubscriptionTopic
10.3.8.1 Область применения и использования
Тип ресурса SubscriptionStatus описывает статус подписки на уведомления об изменении экземпляров ресурсов, предоставляемые сервером другой системе (клиенту). Он не имеет собственной конечной точки, и его экземпляры используются только в контейнере Bundle типа subscription-notification.
10.3.8.2 Структура ресурса
Ресурс SubscriptionStatus является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса представлен на рисунке 29 и в таблице 209.
![]() Таблица 209
10.3.8.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 210.
Таблица 210
10.3.8.4 Ограничения ресурса SubscriptionStatus
Ограничения ресурса SubscriptionStatus описаны в таблице 211.
Таблица 211
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
при уведомлении о событии
10.3.8.8 Соединение
При уведомлении о соединении (SubscriptionStatus.type=event) к элементам ресурса SubscriptionStatus предъявляются требования, приведенные в таблице 213. Действия клиента по получении такого уведомления зависят от канала уведомлений. Например, если уведомления передаются по каналу rest-hook, то конечная точка клиента должна возвратить серверу соответствующий код статуса HTTP.
Таблица 213
при уведомлении о соединении
10.3.8.9 Периодическое уведомление
При периодическом уведомлении (SubscriptionStatus.type= heartbeat) к элементам ресурса SubscriptionStatus предъявляются требования, приведенные в таблице 214.
Таблица 214
при периодическом уведомлении
10.3.8.10 Запрос статуса
Клиент может запросить у сервера текущий статус подписки с помощью операции $status. В ответ на этот запрос сервер должен возвратить уведомление, в котором SubscriptionStatus.type = query-status. К элементам возвращенного экземпляра ресурса SubscriptionStatus предъявляются требования, приведенные в таблице 215.
Таблица 215
при запросе статуса
10.3.8.11 Запрос события
Сервер может обеспечивать обработку запроса сведений о событиях, которые уже произошли, переданного с помощью операции $events. В ответ на этот запрос сервер должен возвратить уведомление, в котором SubscriptionStatus.type = query-event. К элементам возвращенного экземпляра ресурса SubscriptionStatus предъявляются требования, приведенные в таблице 216.
Таблица 216
при запросе события
11.1.1 Общий состав данных
Хранилище результатов измерений содержит данные трех основных служб (рисунок 30):
а) служба результатов измерений (сведения о состоянии здоровья пациента, о назначенных ему мероприятиях, о выполнении мероприятий, об используемых медицинских приборах);
б) служба подписки (темы подписки и подписки клиентов на заданные темы);
в) терминологическая служба (системы кодирования и наборы значений).
![]() результатов измерений
11.1.2 Состав данных службы результатов измерений
11.1.2.1 Общие требования
Состав данных службы результатов измерений представлен в таблице 217.
Таблица 217
11.1.2.2 Дневники
Состав данных раздела "Дневники" приведен на рисунке 31 и в таблице 218. На рисунке показаны ссылки между экземплярами ресурсов, в том числе ссылки на экземпляры ресурсов, хранящихся в других разделах.
![]() Таблица 218
11.1.2.3 Эпикризы и предупреждения
Состав данных раздела "Эпикризы и предупреждения" представлен на рисунке 32 и в таблице 219. На рисунке показаны ссылки между экземплярами ресурсов, в том числе ссылки на экземпляры ресурсов, хранящихся в других разделах.
![]() "Эпикризы и предупреждения"
Таблица 219
11.1.2.4 Персональные медицинские приборы
Состав данных раздела "Персональные медицинские приборы" представлен на рисунке 33 и в таблице 220. На рисунке показаны ссылки между экземплярами ресурсов, в том числе ссылки на экземпляры ресурсов, хранящихся в других разделах.
![]() "Персональные медицинские приборы"
Таблица 220
11.1.2.5 Планы ведения
Состав данных раздела "Планы ведения" представлен на рисунке 34 и в таблице 220. На рисунке показаны ссылки между экземплярами ресурсов, в том числе ссылки на экземпляры ресурсов, хранящихся в других разделах.
![]() Таблица 221
11.1.2.6 Результаты измерений
Состав данных раздела "Результаты измерений" представлен на рисунке 35 и в таблице 222. На рисунке показаны ссылки между экземплярами ресурсов, в том числе ссылки на экземпляры ресурсов, хранящихся в других разделах.
![]() Таблица 222
11.1.3 Состав данных службы подписки
Состав данных службы подписки приведен на рисунке 36 и в таблице 223.
![]() Таблица 223
11.1.4 Состав данных терминологической службы
Состав данных терминологической службы приведен на рисунке 37 и в таблице 224.
![]() Таблица 224
11.2.1 Область применения и использования
Тип ресурса CarePlan описывает индивидуальный план ведения пациента, составляемый лечащим врачом на основе одного или нескольких типовых планов с учетом особенностей состояния здоровья и социального статуса пациента. Индивидуальный план ведения обычно включает в себя несколько мероприятий - визиты к врачам разных специальностей (явки), обследования и лечебных воздействий. Мероприятия должны проводиться в определенном порядке. Часть мероприятий должна проводиться строго одно после другого, часть мероприятий может проводиться независимо друг от друга или параллельно. Порядок проведения мероприятий задается правилами типа "визит к пульмонологу должен проводиться после рентгенографии легких" или "повторный визит к участковому терапевту должен проводиться после выполнения всех остальных мероприятий".
Для каждого мероприятия плана задают:
а) вид мероприятия (визит, обследование, лечение);
б) тип мероприятия (визит к офтальмологу, общий анализ крови, санаторно-курортное лечение и т.д.);
в) описание подготовки пациента к выполнению мероприятия;
г) описание действий пациента при самостоятельном выполнении мероприятия (например, видеоролик по правильному измерению артериального давления или по замене аккумуляторных батарей в приборе);
д) график выполнения (например, через две недели, а затем каждые 4 месяца);
е) признак контрольной точки (при проведении такого мероприятия обязательно проводится оценка эффективности плана, на основании которой план может быть скорректирован).
11.2.2 Структура ресурса
Ресурс CarePlan является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса CarePlan представлен на рисунке 38 и в таблице 225.
![]() Таблица 225
11.2.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 226.
Таблица 226
11.2.4 Параметры поиска экземпляров ресурса CarePlan
Специальные параметры поиска экземпляров ресурса CarePlan описаны в таблице 227. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 227
Профиль плана дистанционного мониторинга пациента CarePlan-Dm ограничивает элементы ресурса CarePlan в соответствии с рисунком 39 и таблицей 228. Имя ресурса остается неизменным - CarePlan, имя профиля передается в элементе meta.profile.
![]() Таблица 228
11.2.6 Контекст профиля
Содержание экземпляра ресурса CarePlan представляет собой только часть плана ведения. Полное содержание плана ведения может быть представлено направленным графом, включающим в себя ссылочные экземпляры ресурсов. Этот граф служит контекстом профиля.
Рекомендуемый контекст профиля плана дистанционного мониторинга пациента показан на рисунке 40.
![]() Согласно этому рисунку, полный план дистанционного мониторинга пациента должен включать в себя:
а) экземпляр ресурса 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.1 Область применения и использования
Тип ресурса Goal используется для описания целевого состояния здоровья субъекта медицинской помощи, которое планируется достичь за заданный период или к заданному моменту времени. Это целевое состояние может достигаться в результате лечения или естественного восстановления организма с течением времени.
Например, целью ведения пациента с диабетом может быть концентрация показателя гликированного гемоглобина не выше 5,6% за три месяца в результате лекарственной терапии, контроля питания и увеличенной физической активности.
11.3.2 Структура ресурса
Ресурс Goal является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Goal представлен на рисунке 41 и в таблице 229.
![]() Таблица 229
11.3.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 230.
Таблица 230
11.3.4 Ограничения ресурса Goal
Ограничения ресурса Goal описаны в таблице 231.
Таблица 231
11.3.5 Параметры поиска экземпляров ресурса Goal
Специальные параметры поиска экземпляров ресурса Goal описаны в таблице 232. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 232
Профиль цели дистанционного мониторинга пациента Goal-Dm ограничивает элементы ресурса Goal в соответствии с рисунком 42 и таблицей 233. Имя ресурса остается неизменным - Goal, имя профиля передается в элементе meta.profile.
![]() Таблица 233
11.4.1 Область применения и использования
В зависимости от значения элемента intent тип ресурса ServiceRequest описывает назначение, предложение или план диагностических и иных мероприятий, результаты которых представляются в виде экземпляров ресурсов Procedure (процедура), DiagnosticReport (заключение врача) и Observation (результат исследования).
Примерами мероприятий служат:
- диагностические исследования;
- эндоскопические процедуры;
- консультации;
- биопсии;
- хирургические процедуры;
- физиотерапевтические процедуры;
- патронаж;
- другие клинические вмешательства.
Основным применением ресурса ServiceRequest является обеспечение процессов назначения мероприятий в интересах одного пациента. Однако во многих случаях оказания медицинской помощи диагностические мероприятия выполняются для групп лиц, медицинских изделий и даже объектов окружающей среды. Состав ресурса ServiceRequest охватывает все эти случаи. Он может использоваться для передачи назначений врача или предложений по диагностике, сформированных системой поддержки медицинских решений. Его экземпляры могут использоваться для описания планируемых мероприятий в составе плана ведения пациента.
11.4.2 Структура ресурса
Ресурс ServiceRequest является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса ServiceRequest представлен на рисунке 43 и в таблице 234.
![]() Таблица 234
11.4.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 235.
Таблица 235
11.4.4 Ограничения ресурса ServiceRequest
Ограничения ресурса ServiceRequest описаны в таблице 236.
Таблица 236
11.4.5 Параметры поиска экземпляров ресурса ServiceRequest
Специальные параметры поиска экземпляров ресурса ServiceRequest описаны в таблице 237. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 237
ресурса ServiceRequest
11.5.1 Область применения и использования
Тип ресурса Task идентифицирует мероприятие и состояние его выполнения. Экземпляры ресурса Task могут использоваться при управлении рабочими процессами, включающими в себя комплексы связанных мероприятий по выполнению таких требований, как заказ лабораторных исследований, лекарственные назначения и т.д.
Экземпляр ресурса Task отражает шаг рабочего процесса, например отмену заказа, получение результата лабораторного исследования, заказ вторичных исследований в зависимости от полученного результата и т.д.
Основной предмет мероприятия описывается по ссылке, содержащейся в элементе focus. Для выполнения мероприятия могут требоваться определенные входные данные, передаваемые в элементе input. Результат выполнения мероприятия может быть передан в элементе output. Его содержание может служить входными данными для следующего мероприятия.
11.5.2 Структура ресурса
Ресурс Task является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Task представлен на рисунке 44 и в таблице 238.
![]() Таблица 238
11.5.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 239.
Таблица 239
11.5.4 Ограничения ресурса Task
Ограничения ресурса Task описаны в таблице 240.
Таблица 240
11.5.5 Переходы состояний выполнения мероприятий
На рисунке 45 приведена "типичная" диаграмма перехода состояний мероприятия. На практике могут использоваться не все переходы, и некоторые переходы могут быть добавлены, включая обратные переходы из терминальных состояний (failed или completed) в состояние выполнения in-progress.
![]() Вновь созданный экземпляр ресурса 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
Специальные параметры поиска экземпляров ресурса Task описаны в таблице 227. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 241
Профили мероприятий, назначаемых в рамках планов дистанционного мониторинга пациентов, перечислены в таблице 242.
Таблица 242
Общая структура профилей мероприятий дистанционного мониторинга показана на рисунке 46 и приведена в таблице 243.
![]() Таблица 243
дистанционного мониторинга
Профили отличаются друг от друга требованиями к заполнению следующих элементов:
- meta.profile - имя профиля;
- code - идентификация мероприятия;
- requestedPerformer - требуемый исполнитель.
Профиль Task-Medication (лекарственное назначение) ограничивает элементы ресурса Task в соответствии с рисунком 46 и таблицей 243. Имя ресурса остается неизменным - Task, имя профиля передается в элементе meta.profile.
В элементе requestedPerformer (требуемый исполнитель) должна быть передана ссылка на экземпляр ресурса Patient, идентифицирующий лицо, применяющее назначенный лекарственный препарат (обычно сам пациент).
Требования к заполнению элемента code приведены в таблице 244. В первом экземпляре элемента code.coding должны быть переданы код анатомо-терапевтическо-химической классификации (АТХ) назначенного лекарственного препарата (при наличии). В следующих экземплярах элемента code.coding должны передаваться торговые наименования лекарственного препарата (синонимы). Международное непатентованное наименование должно передаваться в элементе code.text.
Таблица 244
в профиле Task-Medication
Профиль Task-Phd (выполнение измерений) ограничивает элементы ресурса Task в соответствии с рисунком 46 и таблицей 243. Имя ресурса остается неизменным - Task, имя профиля передается в элементе meta.profile.
В элементе requestedPerformer (требуемый исполнитель) должна быть передана ссылка на экземпляр ресурса Device, идентифицирующий персональный медицинский прибор, выполняющий измерения.
Требования к заполнению элемента code приведены в таблице 245.
Таблица 245
Таблица 246
Профиль Task-MedStat (ведение дневника приема лекарств) ограничивает элементы ресурса Task в соответствии с рисунком 46 и таблицей 243. Имя ресурса остается неизменным - Task, имя профиля передается в элементе meta.profile.
В элементе requestedPerformer (требуемый исполнитель) должна быть передана ссылка на экземпляр ресурса Patient, идентифицирующий лицо, заполняющее записи дневника (обычно сам пациент).
Требования к заполнению элемента code приведены в таблице 247.
Таблица 247
Профиль Task-NutrInt (ведение дневника питания) ограничивает элементы ресурса Task в соответствии с рисунком 46 и таблицей 243. Имя ресурса остается неизменным - Task, имя профиля передается в элементе meta.profile.
В элементе requestedPerformer (требуемый исполнитель) должна быть передана ссылка на экземпляр ресурса Patient, идентифицирующий лицо, заполняющее записи дневника (обычно сам пациент).
Требования к заполнению элемента code приведены в таблице 248.
Таблица 248
Профиль Task-QuestResp (ведение дневника самонаблюдений) ограничивает элементы ресурса Task в соответствии с рисунком 46 и таблицей 243. Имя ресурса остается неизменным - Task, имя профиля передается в элементе meta.profile.
В элементе requestedPerformer (требуемый исполнитель) должна быть передана ссылка на экземпляр ресурса Patient, идентифицирующий лицо, заполняющее записи дневника (обычно сам пациент). Во втором экземпляре элемента basedOn должна быть передана ссылка на экземпляр ресурса Questionnaire, описывающий форму дневника самонаблюдений.
Требования к заполнению элемента code приведены в таблице 249.
Таблица 249
в профиле Task-QuestResp
Профиль Task-DiagRep (составление этапного эпикриза) ограничивает элементы ресурса Task в соответствии с рисунком 46 и таблицей 243. Имя ресурса остается неизменным - Task, имя профиля передается в элементе meta.profile.
В элементе requestedPerformer (требуемый исполнитель) должна быть передана ссылка на экземпляр ресурса Practitioner, идентифицирующий лечащего врача, составляющего заключение.
Требования к заполнению элемента code приведены в таблице 250.
Таблица 250
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.
![]() канала 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.
![]() канала 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.1 Область применения и использования
Тип ресурса Device используется для передачи сведений об идентификации медицинского изделия и его местонахождении. Согласно статье 38 [34] медицинскими изделиями являются любые инструменты, аппараты, приборы, оборудование, материалы и прочие изделия, применяемые в медицинских целях отдельно или в сочетании между собой, а также вместе с другими принадлежностями, необходимыми для применения указанных изделий по назначению, включая специальное программное обеспечение, и предназначенные производителем для профилактики, диагностики, лечения и медицинской реабилитации заболеваний, мониторинга состояния организма человека, проведения медицинских исследований, восстановления, замещения, изменения анатомической структуры или физиологических функций организма, предотвращения или прерывания беременности, функциональное назначение которых не реализуется путем фармакологического, иммунологического, генетического или метаболического воздействия на организм человека.
Состав элементов ресурса Device позволяет передавать сведения и об изделиях немедицинского назначения, например, о смартфонах, компьютерах и программном обеспечении.
Изделие может быть отнесено к одной или нескольким категориям, например, коммуникационные изделия, медицинские аппараты, изделия для домашнего использования, для диагностики in vitro, имплантаты, одноразовые, многоразовые, программное обеспечение. Одним из классов коммуникационных изделий являются персональные медицинские приборы, используемые пациентами или иными лицами, не являющимися медицинскими работниками, в целях наблюдения за состоянием организма и передачи результатов наблюдения.
11.7.2 Структура ресурса
Ресурс Device является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Device представлен на рисунке 49 и в таблице 251.
![]() Таблица 251
11.7.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 252.
Таблица 252
11.7.4 Ограничения ресурса Device
Ограничения ресурса Device описаны в таблице 253.
Таблица 253
11.7.5 Идентификация медицинских изделий и типы изделий
Почти всем изделиям присвоены различные идентификаторы и коды, обычно прикрепленные к самому изделию или к его упаковке. Они могут представлять собой напечатанные этикетки, таблички, штрих-коды или радиочастотные метки. Идентификаторы и коды могут присваиваться производителями или поставщиками изделий (например, серийный номер или артикул), другими организациями и реестрами. Эти идентификаторы и коды по возможности должны быть представлены в экземпляре ресурса Device. Это не всегда просто, поскольку в составе ресурса предусмотрено несколько семантически отличающихся элементов для представления кодов и идентификаторов, а в документации на изделия термины "код" и "идентификатор" могут быть перемешаны.
Элемент identifier предназначен только для идентификации экземпляра изделия, например с помощью инвентарного номера, присвоенного владельцем изделия. Для серийного номера, присвоенного производителем изделия, должен использоваться элемент serialNumber. Такие идентификаторы, как артикул или глобальный номер товарной продукции GTIN, представляют тип изделия и должны передаваться в элементе type.
Одним из источников типов изделий является глобальная номенклатура медицинских изделий GMDN (Global Medical Device Nomenclature, /template/go.php?url=https://www.gmdnagency.org/).
Для машиночитаемой маркировки медицинских изделий в целях их прослеживания могут использоваться уникальные идентификаторы устройства UDI (Unique Device Identifier, /template/go.php?url=https://www.imdrf.org/consultations/udi-system-medical-devices). Для хранения UDI предусмотрен элемент udiCarrier. В соответствии с [35] принята собственная система маркировки, согласно которой каждому изделию присваивается идентификатор, состоящий из четырех компонентов. Этот идентификатор также может быть представлен в элементе udiCarrier.
11.7.6 Параметры поиска экземпляров ресурса Device
Специальные параметры поиска экземпляров ресурса Device описаны в таблице 254. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 254
11.7.7.1 Общие требования
Аппаратное и программное обеспечение ПМП может содержать сведения о приборе, включая идентификацию ПМП. Эти сведения должны передаваться между участниками информационного взаимодействия по сценарию, показанному на рисунке 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
хранения и обработки результатов измерений
Отображение атрибута System-Model на элементы ресурса Device приведено в таблице 256.
Таблица 256
11.7.7.4 Отображение атрибута System-Id
Отображение атрибута System-Id на компоненты элемента identifier ресурса Device приведено в таблице 257.
Таблица 257
элемента identifier ресурса Device
11.7.7.5 Отображение атрибута Production-Specification
Атрибут Production-Specification содержит список сведений о приборе, тип которых определяется значением компонента spec-type. Отображение атрибута Production-Specification на элементы ресурса Device в зависимости от значения этого компоненты приведено в таблице 258.
Таблица 258
на элементы ресурса Device
11.7.7.6 Отображение атрибута System-Type-Spec-List
Атрибут System-Type-Spec-List содержит список специализаций прибора. Отображение атрибута System-Type-Spec-List на элементы ресурса Device приведено в таблице 259.
Таблица 259
на элементы ресурса Device
Шлюз Интернета вещей или менеджер ПМП должны дополнить сведения, полученные от ПМП, следующими атрибутами:
а) тип прибора;
б) идентификация шлюза или менеджера.
Тип прибора указывает, что это ПМП. Он отображается на элемент Device.type в соответствии с таблицей 260.
Таблица 260
Идентификация шлюза или менеджера отображается на элемент Device.gateway в соответствии с таблицей 261.
Таблица 261
11.7.7.8 Состав элементов профиля Device-Phd
Профиль Device-Phd (персональный медицинский прибор) оставляет в ресурсе Device только те элементы, которые задействованы в 11.7.7.3 - 11.7.7.7 (рисунок 51 и таблица 262). Имя ресурса остается неизменным - Device, имя профиля передается в элементе meta.profile.
![]() Таблица 262
МИС передает сервису сведения о шлюзе Интернета вещей или менеджере ПМП, предоставленном пациенту, в форме экземпляра ресурса Device, соответствующего профилю Device-Phg (шлюз). Он используется только для проверки значения элемента Device.gateway, передаваемого в сведениях о ПМП. Состав элементов профиля Device-Phg приведен на рисунке 52 и в таблице 263. Имя ресурса остается неизменным - Device, имя профиля передается в элементе meta.profile.
![]() Таблица 263
Тип прибора указывает, что это шлюз Интернета вещей или менеджер ПМП. Он отображается на элемент Device.type в соответствии с таблицей 264.
Таблица 264
11.8.1 Область применения и использования
Тип ресурса DeviceAssociation используется для описания ассоциации медицинского изделия с субъектом и/или оператором. К числу медицинских изделий, для которых может понадобиться такое описание, относятся, например, имплантаты, каталки, персональные медицинские приборы.
Субъектами ассоциаций могут быть:
а) пациенты, использующие имплантаты, протезы, регистраторы активности, персональные медицинские приборы и т.д.;
б) группы лиц - некоторые персональные медицинские приборы, например, весы или тонометр, могут быть ассоциированы с членами семьи или группой лиц;
в) медицинские работники, использующие мобильные телефоны, планшеты и т.д.;
г) изделия - изделие может быть ассоциировано с другим изделием и при этом не являться его неотъемлемой частью. Примером может служить радиочастотная метка, используемая для отслеживания местонахождения каталки;
д) близкие лица - изделие, например, аварийный оповещатель, может быть ассоциировано с близким лицом пациента.
11.8.2 Структура ресурса
Ресурс DeviceAssociation является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса DeviceAssociation представлен на рисунке 53 и в таблице 265.
![]() Таблица 265
11.8.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 266.
Таблица 266
11.8.4 Параметры поиска экземпляров ресурса DeviceAssociation
Специальные параметры поиска экземпляров ресурса DeviceAssociation описаны в таблице 267. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 267
ресурса DeviceAssociation
Профиль DeviceAssociation-Dm ограничивает экземпляр ресурса DeviceAssociation элементами, необходимыми для привязки персонального медицинского прибора, шлюза Интернета вещей или менеджера ПМП к пациенту. Состав профиля DeviceAssociation-Dm приведен на рисунке 54 и в таблице 268. Имя ресурса остается неизменным - DeviceAssociation, имя профиля передается в элементе meta.profile.
![]() Таблица 268
11.9.1 Область применения и использования
Тип ресурса DeviceDefinition используется для описания общих характеристик и функций определенной модели изделия или класса изделий, например, модели персонального кардиомонитора. Он применяется в основном для описания медицинских изделий, но может описывать смартфоны, компьютеры, программное обеспечение и т.д. Экземпляр ресурса DeviceDefinition содержит описание изделия, обычно включаемого в каталоги или регистрационные удостоверения. При необходимости с его помощью можно описывать составные части изделия.
Примечание - Поскольку тип ресурса Device предназначен для описания конкретного экземпляра изделия, в нем предусмотрены такие элементы, как номер партии или серийный номер. Подобные элементы в типе ресурса DeviceDefinition отсутствуют.
11.9.2 Структура ресурса
Ресурс DeviceDefinition является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса DeviceDefinition представлен на рисунке 55 и в таблице 269.
![]() Таблица 269
11.9.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 270.
Таблица 270
11.9.4 Параметры поиска экземпляров ресурса DeviceDefinition
Специальные параметры поиска экземпляров ресурса DeviceDefinition описаны в таблице 271. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 271
ресурса DeviceDefinition
11.10.1 Область применения и использования
Тип ресурса DeviceMetric используется для описания динамических свойств медицинского прибора, характеризующих его настройку или измерительную способность (метрику), в том числе непосредственную или вычисляемую. Кроме того, с его помощью можно описать операционный статус метрики, тип калибровки, время последней калибровки, состояние калибровки, цвет графика при выводе на монитор.
11.10.2 Структура ресурса
Ресурс DeviceMetric является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса DeviceMetric представлен на рисунке 56 и в таблице 272.
![]() Таблица 272
11.10.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 273.
Таблица 273
11.10.4 Параметры поиска экземпляров ресурса DeviceMetric
Специальные параметры поиска экземпляров ресурса DeviceMetric описаны в таблице 274. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 274
ресурса DeviceMetric
11.11.1 Область применения и использования
Тип ресурса Observation используется для передачи результатов клинических исследований, в том числе:
а) жизненно важные показатели, например вес, температура, артериальное давление;
б) результаты лабораторных анализов, например концентрация глюкозы в капиллярной крови;
в) медицинские изображения;
г) результаты измерений, выполненных медицинским прибором, например, кардиографом или пульсоксиметром;
д) настройка приборов, например ИВЛ;
е) оценка по шкалам и индексам, например по шкале комы Глазго или шкале Апгар.
Тип ресурса Observation не должен использоваться, если клиническая информация может быть передана с помощью других ресурсов; например, ресурс AllergyIntolerance описывает аллергии пациента, ресурс MedicationStatement - применение лекарственного препарата, ресурс FamilyMemberHistory - семейный анамнез; ресурс Procedure - сведения о выполненной процедуре, ресурс QuestionnaireResponse - ответы на вопросник, ресурс Condition - диагноз или общее состояние пациента, ресурс ClinicalImpression - клиническое описание.
11.11.2 Структура ресурса
Ресурс Observation является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Observation представлен на рисунке 57 и в таблице 275.
![]() Таблица 275
11.11.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 276.
Таблица 276
11.11.4 Ограничения ресурса Observation
Ограничения ресурса Observation описаны в таблице 277.
Таблица 277
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, привязанный к набору значений с трехзначной логикой, например /template/go.php?url=https://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
11.11.12 Передача результатов измерений
Примерный процесс передачи результата измерений показан на рисунке 58.
![]() ПМП устанавливает связь с менеджером ПМП или шлюзом интернета вещей (далее для краткости упоминается только менеджер). Затем ПМП передает протокольные данные, необходимые для интерпретации результатов измерений или управления прибором, например выбранные единицы измерения или процент заряда батареи. Если за время, прошедшее с предыдущего сеанса связи, у ПМП прервалась линия времени (например, таймер был сброшен или пациент изменил дату и время таймера), то ПМП должен передать менеджеру показания своего таймера в формате ГОСТ Р 56845. Менеджер формирует экземпляр ресурса Observation, содержащий сверку показаний таймера ПМП и таймера менеджера, и передает его сервису обработки и хранения результатов измерений (далее - сервис). Сервис сохраняет сверку таймеров, а МИС получает сохраненный экземпляр ресурса Observation по подписке.
ПМП осуществляет измерение показателей состояния пациента или среды его обитания и передает менеджеру результат измерения в формате ГОСТ Р 56845. Менеджер преобразует полученный результат в экземпляр ресурса Observation, в том числе добавляет в него идентификатор ПМП, дату и время поступления результата измерения, а также идентификатор последней сверки таймеров. Затем менеджер передает сервису сформированный экземпляр ресурса Observation. Сервис сохраняет результат измерений, а МИС получает сохраненный экземпляр ресурса Observation по подписке.
11.11.13 Варианты типов результатов измерений
Взаимодействие ПМП с менеджером, осуществляемое в соответствии со стандартом ГОСТ Р 56845, может включать в себя обмен данными, не являющимися результатами измерений. Например, пользователь может изменить на своих весах единицы веса с фунтов на килограммы. Весы информируют об этом шлюз. В передаче этого события сервису нет никакой необходимости. Передача требуется, если по событию измерения ПМП передает менеджеру один из 12 атрибутов, перечисленных в таблице 279.
Таблица 279
Каждый результат измерения представлен одним и только одним из этих атрибутов. Если ПМП передает данные, не содержащие такой атрибут, то эта информация адресована менеджеру, чтобы он мог декодировать переданный затем результат измерения, и сервису не передается.
Некоторые атрибуты, например 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
11.11.15 Номенклатурные коды
Согласно стандарту ГОСТ Р 56845 типы измерений, единицы измерения и ряд других характеристик, относящихся к результатам измерений, должны передаваться в виде номенклатурных кодов, определенных в стандарте ГОСТ Р 56842. Эти коды представляют собой 32-битовые целые числа без знака. Старшие 16 битов задают раздел номенклатуры, а младшие 16 битов - код термина в этом разделе. С каждым номенклатурным кодом связан "почти человеко-читаемый" мнемокод; например, с кодом 147842 связан мнемокод MDC_ECG_HEART_RATE (частота сокращений сердца, определенная по ЭКГ). ПМП передает шлюзу только числовой номенклатурный код, а при передаче сервису шлюз по возможности дополняет номенклатурный код мнемокодом. В ряде случаев ПМП передает только код термина, если раздел можно определить из контекста передачи.
При передаче результатов измерений ПМП использует в качестве единиц измерений соответствующий номенклатурный код. При передаче сервису шлюз должен указать код единицы измерения, определенный в стандарте UCUM [37].
При отображении номенклатурных кодов в элементы ресурса 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 может повторяться при условии, что они относятся к одному и тому же понятию, возможно, с разной степенью общности. Если номенклатурному коду соответствует понятие, определенное в профиле жизненно важных показателей (/template/go.php?url=https://www.hl7.org/fhir/observation-vitalsigns.html), то во второй группе компонентов coding.code и coding.system должен быть передан код, указанный в этом профиле. В еще одной группе следует передать код измерения, взятый из нормативно-справочной информации Минздрава России.
Результаты измерений, представляющие физические величины, могут содержать единицы измерения. Они передаются в атрибуте 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), означающий плохой сигнал.
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.component, компоненты которого заполняются в соответствии с таблицей 282.
Таблица 282
Если бит описывает событие (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
Если результат измерения передается в атрибуте 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 передается значение /template/go.php?url=https://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.1 Общие требования
Профиль Observation-PhdNumeric (скалярная величина) используется для передачи скалярных физических величин, в том числе безразмерных. Примерами таких величин могут служить температура тела, вес, рост, концентрация глюкозы, частота сердечных сокращений и т.д.
Результат измерений, передаваемый ПМП, является скалярным, если он содержит один из атрибутов, перечисленных в таблице 284.
Таблица 284
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
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
ресурса Observation
11.11.24.5 Атрибут Alert-Op-State
Атрибут Alert-Op-State (состояние предупреждений о выходе результата измерения за нижнюю или верхнюю границу) используется при передаче результатов измерений, выполненных пульсоксиметром. Он представляет собой битовое поле, идентифицирующее состояние предупреждений о выходе результата измерения за нижнюю или верхнюю границу заданного диапазона.
Отображение атрибута Alert-Op-State на элементы ресурса Observation представлено в таблице 287.
Таблица 287
ресурса Observation
11.11.24.6 Атрибут Alert-Op-Text-String
Атрибут Alert-Op-Text-String (тексты предупреждений о выходе результата измерения за нижнюю или верхнюю границу) используется при передаче результатов измерений, выполненных пульсоксиметром. Он содержит тексты предупреждений о выходе результата измерения за нижнюю или верхнюю границу заданного диапазона.
Отображение атрибута Alert-Op-Text-Stringe на элементы ресурса Observation представлено в таблице 288.
Таблица 288
на элементы ресурса Observation
11.11.24.7 Атрибут Current-Limits
Атрибут Current-Limits (границы контролируемого диапазона) используется при передаче результатов измерений, выполненных пульсоксиметром. Он содержит границы диапазона, выход за которые должен контролироваться.
Отображение атрибута Current-Limits на элементы ресурса Observation представлено в таблице 289.
Таблица 289
ресурса Observation
11.11.24.8 Атрибут Measurement-Confidence-95
Атрибут Measurement-Confidence-95 (границы диапазона достоверности 95%) используется при передаче результатов измерений, выполненных глюкометром непрерывного действия. Он содержит нижнюю и верхнюю границу диапазона, в который производитель прибора с вероятностью 95% гарантирует вхождение результата измерения.
Отображение атрибута Measurement-Confidence-95 на элементы ресурса Observation представлено в таблице 290.
Таблица 290
на элементы ресурса Observation
11.11.24.9 Атрибут Threshold-Notification-Text-String
Атрибут Threshold-Notification-Text-String (предупреждение о выходе за границу) используется при передаче результатов измерений, выполненных глюкометром непрерывного действия. Он содержит текст текущего предупреждения о выходе за границу заданного диапазона.
Отображение атрибута Threshold-Notification-Text-String на элементы ресурса Observation представлено в таблице 291.
Таблица 291
на элементы ресурса Observation
11.11.24.10 Состав элементов профиля Observation-PhdNumeric
Профиль Observation-PhdNumeric (скалярный результат измерения) оставляет в ресурсе Observation только те элементы, которые могут использоваться при преобразовании скалярного результата измерения из формата, предусмотренного стандартом ГОСТ Р 56845 (рисунок 59 и таблица 292). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
![]() Таблица 292
11.11.25.1 Общие требования
Профиль Observation-PhdCompoundNumeric (массив скалярных величин) используется для передачи вектора или массива связанных скалярных величин, измеренных примерно в один и тот же момент времени, например вектора ускорения или показателей артериального давления (систолическое, диастолическое, среднее).
Результат измерений, передаваемый ПМП, является массивом скалярных величин, если он содержит один из атрибутов, перечисленных в таблице 293.
Таблица 293
Каждый элемент массива передается в отдельном экземпляре элемента 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
11.11.25.3 Дополнительная информация к массиву скалярных результатов
Вместе с массивом числовых результатов может быть передан атрибут Accuracy (точность). Он имеет абсолютное значение и определяет максимальное отклонение фактического значения от сообщенного наблюдаемого значения (если оно может быть указано) во всем диапазоне измерений. Этот атрибут применим только в тех случаях, если все элементы массива имеют одинаковые единицы измерения, и выражается в этих же единицах. При передаче результатов измерений с определенной точностью сообщаемое значение должно обладать определенным числом разрядов, достаточным для представления такой точности.
Отображение атрибута Accuracy на элементы ресурса Observation представлено в таблице 286.
11.11.25.4 Состав элементов профиля Observation-PhdCompoundNumeric
Профиль Observation-PhdCompoundNumeric (скалярный результат измерения) оставляет в ресурсе Observation только те элементы, которые могут использоваться при преобразовании массива скалярных результатов измерения из формата ГОСТ Р 56845 (рисунок 60 и таблица 295). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
![]() Таблица 295
11.11.26.1 Общие требования
Профиль Observation-PhdCodedEnumeration (кодируемый результат) используется для передачи результата измерений, представленного кодом из определенного перечня. Примером может служить контекст питания, ассоциированный с измерением концентрации глюкозы и определяемый кодами: fasting (натощак), preprandial (перед едой), postprandial (после еды) и т.д.
Результат измерений, передаваемый ПМП, является кодируемым результатом, если он содержит один из атрибутов, перечисленных в таблице 296.
Таблица 296
Атрибут 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
11.11.26.3 Состав элементов профиля Observation-PhdCodedEnumeration
Профиль Observation-PhdCodedEnumeration (кодируемый результат измерения) оставляет в ресурсе Observation только те элементы, которые могут использоваться при преобразовании кодируемых результатов измерения из формата ГОСТ Р 56845 (рисунок 61 и таблица 298). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
![]() Таблица 298
11.11.27.1 Общие требования
Профиль Observation-PhdBitsEnumeration (битовый результат) используется для передачи результата измерений, представленного битовым полем. Примером могут служить сведения о состоянии датчика пульсоксиметра, содержащие признаки sensor-displaced (неправильная установка датчика) и т.д. Несколько таких признаков может быть передано в одном результате.
Результат измерений, передаваемый ПМП, является битовым результатом, если он содержит один из атрибутов, перечисленных в таблице 299.
Таблица 299
Атрибут 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
11.11.27.3 Состав элементов профиля Observation-PhdBitsEnumeration
Профиль Observation-PhdBitsEnumeration (кодируемый результат измерения) оставляет в ресурсе Observation только те элементы, которые могут использоваться при преобразовании кодируемых результатов измерения из формата ГОСТ Р 56845 (рисунок 62 и таблица 301). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
![]() Таблица 301
11.11.28.1 Общие требования
Профиль Observation-PhdStringEnumeration (строковый результат) используется для передачи результата измерений, представленного строкой теста. Примером может служить наименование физического упражнения, контролируемого монитором сердечно-сосудистой активности.
Результат измерений, передаваемый ПМП, является строковым результатом, если он содержит один из атрибутов, перечисленных в таблице 302.
Таблица 302
Атрибут 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
11.11.28.3 Состав элементов профиля Observation-PhdStringEnumeration
Профиль Observation-PhdStringEnumeration (строковый результат измерения) оставляет в ресурсе Observation только те элементы, которые могут использоваться при преобразовании кодируемых результатов измерения из формата ГОСТ Р 56845 (рисунок 63 и таблица 304). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
![]() Таблица 304
11.11.29.1 Общие требования
Профиль Observation-PhdRtsa (массив считываний) используется для передачи периодических считываний биосигнала, например, плетизмограмм или кардиограмм. Массив считываний является одномерным. Для передачи векторов ускорения или считываний нескольких отведений кардиограммы должны использоваться отдельные экземпляры ресурса Observation
Результат измерений, передаваемый ПМП, является массивом считываний, если он содержит атрибут Simple-Sa-Observed-Value. Перечень его атрибутов, учитываемых при преобразовании в экземпляр ресурса Observation, приведен в таблице 305.
Таблица 305
Считывание представляет собой целое число, полученное с помощью аналого-цифрового преобразователя. Для преобразования считывания в результат измерения используется следующая формула:
где 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
11.11.29.3 Состав элементов профиля Observation-PhdRtsa
Профиль Observation-PhdRtsa (массив считываний) оставляет в ресурсе Observation только те элементы, которые могут использоваться для передачи результатов измерения биосигнала (рисунок 64 и таблица 307). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
![]() Таблица 307
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.
![]() Таблица 308
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
Элемент Observation.code.coding.system должен иметь значение "urn:iso:std:iso:11073:10101".
11.11.31.3 Состав элементов профиля Observation-PhdCoincidentTimeStamp
Профиль Observation-PhdCoincidentTimeStamp (сверка таймеров) оставляет в ресурсе Observation только те элементы, которые могут использоваться для передачи результата сверки таймеров (рисунок 66 и таблица 310). Имя ресурса остается неизменным - Observation, имя профиля передается в элементе meta.profile.
![]() Таблица 310
11.12.1 Область применения и использования
Тип ресурса Patient используется для описания общих демографических данных пациента и его идентификации в различных реестрах, в первую очередь в списках пациентов организаций здравоохранения. В его элементах отсутствуют сведения о гражданстве, этнической группе, статусе донора органов и т.д. Эти сведения могут быть переданы в экземплярах ресурсов других типов или в расширениях.
11.12.2 Структура ресурса
Ресурс Patient является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Patient представлен на рисунке 67 и в таблице 311.
![]() Таблица 311
11.12.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 312.
Таблица 312
11.12.4 Ограничения ресурса Patient
Ограничения ресурса Patient описаны в таблице 313.
Таблица 313
11.12.5 Параметры поиска экземпляров ресурса Patient
Специальные параметры поиска экземпляров ресурса Patient описаны в таблице 314. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 314
Профиль пациента при дистанционном мониторинге Patient-Dm ограничивает элементы ресурса Patient в соответствии с рисунком 68 и таблицей 315. Имя ресурса остается неизменным - Patient, имя профиля передается в элементе meta.profile.
![]() Таблица 315
11.13.1 Область применения и использования
Тип ресурса Practitioner используется для описания общих демографических данных медицинского работника, контактной информации и квалификации.
11.13.2 Структура ресурса
Ресурс Practitioner является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Practitioner представлен на рисунке 69 и в таблице 316.
![]() Таблица 316
11.13.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 317.
Таблица 317
11.13.4 Параметры поиска экземпляров ресурса Practitioner
Специальные параметры поиска экземпляров ресурса Practitioner описаны в таблице 318. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 318
ресурса Practitioner
Профиль медицинского работника при дистанционном мониторинге Practitioner-Dm ограничивает элементы ресурса Practitioner в соответствии с рисунком 70 и таблицей 319. Имя ресурса остается неизменным - Practitioner, имя профиля передается в элементе meta.profile.
![]() Таблица 319
11.14.1 Область применения и использования
Тип ресурса DiagnosticReport используется для описания заключения врача. В его структуре предусмотрены сведения о самом заключении, о субъекте заключения и, если это заключение врача-лаборанта или патологоанатома, о биоматериале.
11.14.2 Структура ресурса
Ресурс DiagnosticReport является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса DiagnosticReport представлен на рисунке 71 и в таблице 320.
![]() Таблица 320
11.14.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 321.
Таблица 321
11.14.4 Ограничения ресурса DiagnosticReport
Ограничения ресурса DiagnosticReport описаны в таблице 322.
Таблица 322
11.14.5 Параметры поиска экземпляров ресурса DiagnosticReport
Специальные параметры поиска экземпляров ресурса DiagnosticReport описаны в таблице 323. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 323
ресурса DiagnosticReport
При дистанционном мониторинге заключение врача представляет собой этапный эпикриз, подводящий итоги выполнения плана ведения и содержащий рекомендации по дальнейшему ведению пациента. Полное содержание заключения должно храниться в медицинской информационной системе, а в хранилище результатов измерений должно передаваться сокращенное содержание в объеме, рассчитанном на восприятие пациентом. Это требование отражено в профиле заключения врача при дистанционном мониторинге DiagnosticReport-Dm, ограничивающем элементы ресурса DiagnosticReport в соответствии с рисунком 72 и таблицей 324. Имя ресурса остается неизменным - DiagnosticReport, имя профиля передается в элементе meta.profile.
В целях безопасности персональных данных исключена возможность приложения скана оригинала заключения или представления оригинала заключения в формате pdf, предусмотренная в элементе presentedForm. Сокращен список допустимых значений состояния составления заключения.
![]() Таблица 324
11.15.1 Область применения и использования
Тип ресурса MedicationStatement описывает запись дневника приема лекарств. Эта запись может относиться к прошлому, текущему или будущему применению лекарственного препарата. Источником информации может быть пациент, близкое лицо или медицинский работник. Информация может браться по памяти, с упаковки лекарственного препарата или инструкции по его применению, из листа лекарственных назначений.
В отличие от ресурса MedicationAdministration (применение лекарственного препарата) ресурс MedicationStatement рассчитан на менее точную и менее полную информацию о применении (или неприменении) лекарственного препарата. Например, дата и время применения не является обязательной, равно и такие детали, как количество препарата или скорость введения.
В состав ресурса MedicationStatement входит элемент adherence, с помощью которого можно указать степень соответствия указаниям по применению лекарственного препарата, специфичную для этого ресурса.
11.15.2 Структура ресурса
Ресурс MedicationStatement является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса MedicationStatement представлен на рисунке 73 и в таблице 325.
![]() Таблица 325
11.15.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 326.
Таблица 326
11.15.4 Параметры поиска экземпляров ресурса MedicationStatement
Специальные параметры поиска экземпляров ресурса MedicationStatement описаны в таблице 327. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 327
ресурса MedicationStatement
11.16.1 Область применения и использования
Тип ресурса QuestionnaireResponse описывает структуру ответов на вопросник, позволяющую включать вопросы по значению или по ссылке на вопросник.
При заполнении ответов о состоянии конкретного субъекте в определенный момент времени должен создаваться отдельный экземпляр ресурса QuestionnaireResponse. При необходимости в него могут вноситься изменения и дополнения.
В предметной области дистанционного мониторинга состояния пациента экземпляр ресурса QuestionnaireResponse может использоваться в качестве строки дневника самонаблюдений.
Если экземпляр ресурса QuestionnaireResponse содержит ссылку на вопросник, то его содержание может быть проверено на соответствие вопроснику, например, что на обязательные пункты даны ответы, что кратность и тип данных ответов соответствуют их описанию в вопроснике.
Содержание экземпляров ресурса QuestionnaireResponse может заполняться медицинскими работниками, пациентами или их близкими. Ответы на вопросы могут предоставляться другими лицами от имени пациента. Эти ответы могут содержать сведения о родственниках (например, при заполнении семейного анамнеза). Поэтому в структуре ресурса QuestionnaireResponse проводится различие между оператором (author), субъектом ответов (subject) и источником информации.
Для ссылки на случай медицинской помощи, к которому относятся ответы, может использоваться элемент encounter. Это позволяет соотносить ответы на вопросник с направлениями на исследования и с результатами исследований в рамках того же случая медицинской помощи.
Для указания языка, на котором даны ответы, может использоваться элемент language.
Порядок вопросов в группах и вложенных группах должен сохраняться при сборе и визуализации ответов. Иерархия пунктов в экземпляре ресурса QuestionnaireResponse должна воспроизводить иерархию пунктов в ссылочном экземпляре ресурса Questionnaire (при наличии ссылки).
11.16.2 Структура ресурса
Ресурс QuestionnaireResponse является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса QuestionnaireResponse представлен на рисунке 74 и в таблице 328.
![]() Таблица 328
11.16.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 329.
Таблица 329
11.16.4 Ограничения ресурса QuestionnaireResponse
Ограничения ресурса QuestionnaireResponse описаны в таблице 330.
Таблица 330
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
11.17.1 Область применения и использования
Тип ресурса Questionnaire описывает вопросник, то есть организованную коллекцию вопросов, предназначенную для сбора информации от пациентов, медицинских работников или иных участников процесса оказания медицинской помощи, для описания вопросников широкого профиля, в том числе дневника самонаблюдения. Одним из важных приложений ресурса является описание дневника самонаблюдения.
Экземпляр ресурса Questionnaire тесно связан с экземплярами ресурса QuestionnaireResponse: в нем представлены вопросы и правила ответов, а экземпляры ресурса QuestionnaireResponse содержат ответы на эти вопросы, полученные от определенного пользователя в определенный момент времени.
Вопросник, определяемый с помощью экземпляра ресурса Questionnaire, состоит из пунктов, типы которых представлены в таблице 332.
Таблица 332
(система кодирования /template/go.php?url=https://hl7.org/fhir/item-type)
С каждым пунктом могут быть связаны правила его предъявления при заполнении, например, пункт может быть пропущен в зависимости от ответа на тот или иной вопрос. Экземпляр ресурса Questionnaire содержит только описание вопросника, заполняется в соответствии с этим описанием экземпляр ресурса QuestionnaireResponse.
11.17.2 Структура ресурса
Ресурс Questionnaire является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса Questionnaire представлен на рисунке 75 и в таблице 333.
![]() Таблица 333
11.17.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 334.
Таблица 334
11.17.4 Ограничения ресурса Questionnaire
Ограничения ресурса Questionnaire описаны в таблице 335.
Таблица 335
11.17.5 Параметры поиска экземпляров ресурса Questionnaire
Специальные параметры поиска экземпляров ресурса Questionnaire описаны в таблице 336. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 336
Questionnaire
11.18.1 Область применения и использования
Ресурс NutritionIntake описывает общую структуру однократной регистрации акта питания (приема пищи или потребления жидкости) как в стационаре, так и на дому или в системе общественного питания. В область применения ресурса NutritionIntake не входит парентеральное питание.
Состав элементов ресурса NutritionIntake рассчитан на потребности анализа медицинским специалистом (например, диетологом или эндокринологом). Источником информации может быть сам пациент, лицо, обеспечивающее уход за ним или медицинский работник. Информация может заполняться постфактум или непосредственно во время акта питания. Она может вводиться в информационную систему медицинской организации, в мобильное приложение или в приложение на персональном компьютере. Сведения о составе и калорийности продукта (пищи или жидкости) могут браться из справочников, с товарных этикеток или из меню.
Учитывая многообразие продуктов питания и причин контроля питания, все элементы с кодируемыми значениями (за исключением состояния питания status) имеют тип данных CodeableConcept, позволяющий вводить текст в дополнение к коду или вместо кода. Привязки этих элементов к наборам значений даются в качестве примеров.
11.18.2 Структура ресурса
Ресурс NutritionIntake является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса NutritionIntake представлен на рисунке 76 и в таблице 337.
![]() Таблица 337
11.18.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 338.
Таблица 338
11.18.4 Параметры поиска экземпляров ресурса NutritionIntake
Специальные параметры поиска экземпляров ресурса NutritionIntake описаны в таблице 339. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 339
NutritionIntake
11.19.1 Область применения и использования
Тип ресурса DetectedIssue описывает предупреждение о выявленной проблеме, которое может быть выдано системой поддержки принятия медицинских решений или сформулировано медицинским работником. Такое предупреждение может быть направлено другому медицинскому работнику или пациенту.
11.19.2 Структура ресурса
Ресурс DetectedIssue является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса DetectedIssue представлен на рисунке 77 и в таблице 340.
![]() Таблица 340
11.19.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 341.
Таблица 341
11.19.4 Параметры поиска экземпляров ресурса DetectedIssue
Специальные параметры поиска экземпляров ресурса DetectedIssue описаны в таблице 342. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 342
DetectedIssue
11.19.5 Профиль DetectedIssue-Dm
Состав элементов профиля DetectedIssue-Dm приведен на рисунке 78 и в таблице 343. Имя ресурса остается неизменным - DetectedIssue, имя профиля передается в элементе meta.profile.
![]() Таблица 343
Для каждого типа ресурсов определен один и тот же комплекс взаимодействий, основанный на архитектурном стиле REST. При описании REST API предполагается, что отдельные экземпляры ресурсов организованы в коллекции по их типу. REST API позволяет выполнять операции как на уровне экземпляров ресурсов, так и на уровне типов ресурсов, а также на уровне системы в целом. Эти операции далее называются взаимодействиями. Все взаимодействия являются синхронными.
12.2.1 Общие сведения
Возможные взаимодействия на уровне экземпляров ресурсов перечислены в таблице 344, взаимодействия на уровне типов ресурсов - в таблице 345, взаимодействия на уровне системы - в таблице 346.
Таблица 344
Таблица 345
Таблица 346
В дополнение к этим взаимодействиям определена система операций, представленная системой конечных точек, обеспечивающих валидацию экземпляров ресурсов, обработку сообщений и документов.
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 имеет следующий адрес:
/template/go.php?url=https://server/path/Patient
Для адресации конечной точки типа ресурса допускаются два варианта: с концевой косой чертой и без нее.
Все логические взаимодействия определены относительно базового URL. Все URL и идентификаторы, являющиеся компонентами URL, чувствительны к регистру. В качестве кодировки используется windows-1251.
В структуре каждого типа ресурса предусмотрены элементы метаданных. Эти элементы отображаются на запросы и ответы HTTP в соответствии с таблицей 347.
Таблица 347
Идентификатор версии экземпляра ресурса трактуется как "слабый" ETag и должен представляться заключенным в кавычки с префиксом W/, например ETag:
.Правила использования специфичных кодов статуса HTTP приводятся ниже в тех случаях, когда требуется правильное отображение этих кодов на конкретные состояния ответов на запросы. Для передачи детальной информации об ошибках в ряде случаев должен использоваться экземпляр ресурса OperationOutcome, однако это не всегда возможно для ответов с кодом статуса HTTP 4xx или 5xx.
В таблице приведено использование нескольких заголовков HTTP для изменения обработки или формата запросов или результатов.
Таблица 348
Если сервер использует часовой пояс по умолчанию, то следует возвращать его значение в заголовке Date ответа HTTP.
Для улучшения пропускной способности в спецификации предусмотрены средства сокращения возвращаемого содержания (параметры управления ответом _summary и _elements, см. таблицу 349).
Формальные типы среды 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.
Содержание экземпляров ресурсов должно представляться в кодировке windows-1251.
В таблице 349 перечислены параметры, которые могут использоваться во всех взаимодействиях.
Таблица 349
Сервер по возможности должен поддерживать версионность, то есть присваивать соответствующие значения элементам meta.versionId, поддерживать чтение версий экземпляра ресурса и изменения с учетом номера версии.
Информация о поддержке версионности экземпляров конкретного типа ресурса возвращается сервером в ответ на запрос GET [base]/metadata в элементе CapabilityStatement.rest.resource.versioning, который может принимать следующие значения:
а) no-version: версионность и элемент meta.versionId не поддерживаются;
б) versioned: версионность и элемент meta.versionId поддерживаются;
в) versioned-update: версионность, элемент meta.versionId и изменения с учетом номера версии поддерживаются.
Рекомендуется указывать часовой пояс клиента в нестандартном заголовке client-timezone запроса HTTP. Формат заголовка определен в проекте RFC draft-sharhalakis-httptz-05 (/template/go.php?url=https://datatracker.ietf.org/doc/html/draft-sharhalakis-httptz-05).
Взаимодействие 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, а тело ответа отсутствует.
Взаимодействие чтения версии 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.
Взаимодействие изменения 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.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.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, детализирующий причину ошибки.
Взаимодействие создания 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.1 Общие требования
Взаимодействие поиска search выполняет поиск экземпляров ресурса, соответствующих определенным параметрам, с помощью запросов HTTP GET. Параметры поиска представляют собой пары вида "имя=значение", закодированные в соответствии с правилами URL.
Параметры поиска могут применяться к ресурсам любого типа (например, параметр _id определен для каждого типа ресурсов), к ресурсам конкретного типа (например, параметр даты рождения birthDate используется для поиска экземпляров ресурса Patient). Может осуществляться текстовый поиск по человеко-читаемому содержанию экземпляру ресурса или по всем его строковым элементам. Некоторые параметры управляют выводом результатов поиска.
В типичном REST API коллекция найденных экземпляров ресурсов представляется в форме массива. В данном предварительном стандарте требуется, чтобы результаты поиска возвращались в форме контейнера Bundle, у которого элемент type имеет значение searchset. Это позволяет иметь в результате поиска дополнительную информацию (например, число найденных экземпляров), обеспечивать дополнительную функциональность (например, постраничный вывод) и включать в результат поиска экземпляры ресурсов разных типов.
Структура контейнера результатов поиска показана на рисунке 79. Экземпляры ресурсов, содержащиеся в этом контейнере, представляются в элементе resource в составе отдельных записей entry. Ссылки на страницы результатов поиска представлены элементами link. Причина включения экземпляра ресурса в результат поиска представлена элементом search. Его компонент mode может иметь следующие значения: match (экземпляр ресурса удовлетворяет критериям поиска) | include (экземпляр ресурса включен по прямой или обратной ссылке) | outcome (запись entry содержит экземпляр ресурса OperationOutcome с дополнительной информацией об обработке запроса на поиск).
![]() 12.17.2 Контекст поиска
Операции поиска осуществляются в одном из следующих контекстов:
а) система - все типы ресурсов;
б) тип ресурса.
Если параметры поиска отсутствуют, например, GET [base], GET [base]/Patient, то сервер должен включить в результат поиска все экземпляры ресурсов данного контекста. Если число найденных экземпляров слишком велико, сервер может отклонить такой запрос или использовать постраничный вывод результатов.
12.17.3 Запрос HTTP GET
Клиент выполняет поиск с помощью запроса HTTP GET, в котором параметры поиска включены в адресную строку URL (таблица 350).
Таблица 350
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.
Взаимодействие capabilities позволяет получить описание возможностей, обеспечиваемых сервером. Оно выполняется с помощью следующей команды HTTP GET:
GET [base]/metadata{?_format=[mime-type]}.
Ответ на запрос должен содержать экземпляр ресурса CapabilityStatement, описывающий типы ресурсов и взаимодействия, обеспечиваемые сервером для этих типов ресурсов.
По возможности в ответе на запрос должен возвращаться заголовок ETag, идентифицирующий версию описания возможностей.
12.19.1 Общие требования
Взаимодействие транзакции transaction позволяет задать несколько взаимодействий в одном запросе HTTP. Все взаимодействия выполняются в одной транзакции: если при хотя бы одном взаимодействии возникла ошибка, результаты всех ранее выполненных взаимодействий откатываются.
Взаимодействие транзакции осуществляется с помощью запроса HTTP POST следующего вида:
POST [base] {?_format=[mime-type]}.
Тело запроса должно содержать контейнер Bundle, у которого элемент type имеет значение transaction. Структура контейнера транзакции показана на рисунке 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.
![]() Контейнер результата транзакции содержит по одной записи entry на каждую запись entry контейнера транзакции, и в том же порядке. Запись entry содержит информацию о результате транзакции в элементе response, включая код статуса HTTP и содержание заголовков Location, ETag, Last-Modified. В зависимости от значения заголовка Prefer, указанного при запросе транзакции, в запись entry может быть включен экземпляр ресурса.
Если при выполнении транзакции произошла ошибка, то вместо контейнера Bundle возвращается один экземпляр ресурса OperationOutcome, содержащий детальные сведения об ошибке.
Взаимодействие истории 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.
![]() Каждая запись 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
Историю версий можно ограничить определенным периодом времени, указав параметр _since, содержащий полные дату и время с часовым поясом. Клиент должен иметь в виду, что в связи с неточностью времени он может получить более одного уведомления об изменении содержания экземпляра в момент _since. Сервер не обязан указывать время с точностью менее секунды.
Поскольку список изменений может быть длинным, сервер может использовать постраничный вывод. В этом случае он должен использовать метод, описанный в [38] (/template/go.php?url=https://tools.ietf.org/html/rfc5005), учитывая максимальное число записей entry на странице, указанное в параметре _count.
Взаимодействие истории history может использоваться для организации подписки, при которой подписчик синхронизирует свои данные с издателем.
История версий ведется последовательно для каждого экземпляра ресурса, она не предназначена для прослеживания ветвей. Соответственно, нет возможности изменить или удалить предыдущую версию, можно только изменить часть ее метаданных в целях управления доступом. Все предшествующие версии содержания экземпляра ресурса предполагаются устаревшими и неактивными, оставленными для целей аудита/целостности.
Если требуется явно указать, что предшествующая версия содержания экземпляра ресурса появилась по ошибке, то следует использовать ресурс Provenance (происхождение), содержащий ссылку на эту версию. При прослеживании истории конкретного экземпляра ресурса приложение по возможности должно извлекать экземпляры ресурсов Provenance, ссылающиеся на этот экземпляр или его версию.
Если сделан запрос на получении истории, не являющейся доступной (например, сервер не хранит историю версий ресурсов данного типа или конкретного экземпляра ресурса), то сервер должен возвратить код статуса HTTP 404 Not Found и по возможности возвратить экземпляр ресурса OperationOutcome, детализирующий причину ошибки.
При выполнении взаимодействий create и update сервер не обязан сохранять экземпляр ресурса в том виде, как его предоставил клиент. При последующем чтении с помощью взаимодействия содержание экземпляра ресурса может отличаться от исходного по нескольким причинам, например:
а) предоставленное содержание объединяется с текущим;
б) к предоставленному содержанию применяется форматно-логический контроль и по его результатам содержание может быть изменено;
в) сервер поддерживает не все возможные элементы содержания или значения этих элементов.
В связи с этим рекомендуется придерживаться следующих правил:
а) перед запросом на изменение клиенту следует считать последнюю версию экземпляра ресурса;
б) клиент вносит в него необходимые изменения, оставляя остальное содержание неизменным;
в) клиент передает полученный результат серверу, используя взаимодействие изменения update. При этом он должен быть способен обработать возвращенные коды статуса HTTP 409 или 412.
12.22.1 Общие требования
Для снижения нагрузки на сервер, а также для снижения сетевого трафика может использоваться постраничный вывод результатов поиска или истории изменений. В этом случае возвращаемый результат содержит ссылки link с адресами URL, по которым можно запросить другие страницы результата, например:
<Bundle xmlns="/template/go.php?url=https://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="/template/go.php?url=https://hapi.fhir.org/baseR5/Patient?_format=xml&birthdate
=ge1950"/>
</link>
<link>
<relation value="next"/>
<url value="/template/go.php?url=https://hapi.fhir.org/baseR5?_getpages=900ef882-8ec7-410d-
85d2-e5e9dbae5e24&_getpagesoffset=20&_count=20&_format=xml&_
pretty=true&_bundletype=searchset"/>
</link>
<entry>
<fullUrl value="/template/go.php?url=https://hapi.fhir.org/baseR5/Patient/3506"/>
<resource>
<Patient xmlns="/template/go.php?url=https://hl7.org/fhir">
<id value=
......
С помощью параметра _count можно указать, сколько экземпляров ресурса следует возвратить на одной странице. Если _count имеет значение 0, то сервер должен возвратить экземпляр ресурса Bundle, в котором элемент total содержит общее число найденных экземпляров, но при этом в нем нет ни одного экземпляра ресурса и ссылок link на предыдущую/следующую страницу, например:
<Bundle xmlns="/template/go.php?url=https://hl7.org/fhir">
<id value="069e1b59-1864-4395-b47d-6a06ed0c9c98"/>
<meta>
<lastUpdated value="2023-09-19T18:42:30.462+00:00"/>
<tag>
<system value="/template/go.php?url=https://terminology.hl7.org/CodeSystem/v3-
ObservationValue"/>
<code value="SUBSETTED"/>
<display value="Resource encoded in summary mode"/>
</tag>
</meta>
<type value="searchset"/>
<total value=
</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 Актуальность результатов запроса
Результаты запроса актуальны только на момент выполнения запроса. После его выполнения экземпляры ресурсов могут изменяться и повторение запроса может привести к другим результатам.
В таблице 352 приведены нестандартные заголовки HTTP, предназначенные для использования в целях технической поддержки или отладки.
Таблица 352
Заголовок X-Request-Id предназначен для идентификации запросов или ответов в системных журналах. Клиент может присвоить запросу идентификатор и указать его в заголовке X-Request-Id. Сервер может использовать этот идентификатор или присвоить запросу собственный идентификатор, предназначенный для передачи в X-Request-Id ответа на запрос. Если идентификатор, присвоенный сервером, отличается от идентификатора, присвоенного клиентом, то сервер по возможности должен передать идентификатор, присвоенный клиентом, в заголовке X-Correlation-Id.
Протокол HTTP может маршрутизироваться, используя прокси. Такие прокси прозрачны для приложений, но при этом существует риск получения устаревшего содержания из-за кеширования.
На пути от поставщика к потребителю могут использоваться интерфейсные машины. Они отличаются от прокси тем, что активно меняют содержание передаваемых данных и не связаны требованиями, предъявляемыми к прокси. Такие агенты должны добавлять к запросу заголовки X-Intermediary, способствующие отладке или технической поддержке, например:
X-Intermediary: [идентификация агента, обычно полное доменное имя]
Конечные точки не должны использовать этот заголовок.
Сводная информация по запросам HTTP приведена в таблице 353.
Таблица 353
Сводная информация по ответам на запрос приведена в таблице 354. В графе "Коды статуса HTTP" приведены коды, описанные в настоящем предварительном стандарте. В дополнение к ним могут возвращаться другие коды, в том числе относящиеся к аутентификации и ошибкам сервера.
Таблица 354
Для выполнения асинхронного запроса сервер должен поддерживать заголовок 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.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
12.26.5 Модификаторы
Модификаторы параметров поиска изменяют семантику параметров. Например, модифицированный параметр поиска birthdate:missing=true позволяет найти экземпляры ресурса Patient, у которых дата рождения отсутствует.
В запросах поиска модификаторы обозначаются как суффиксы имени параметра поиска в формате [имя]:[модификатор]. К одному параметру поиска может быть применен только один модификатор.
Поскольку модификаторы изменяют семантику параметров поиска, то сервер по возможности должен отклонить запрос поиска, если в нем указан модификатор, не поддерживаемый этим сервером. При отклонении должен быть возвращен код статуса HTTP 400 Bad Request и экземпляр ресурса OperationOutcome с точным описанием причины отклонения.
Возможность применения модификатора к параметру поиска зависит от реализации поиска конкретным сервером. Однако существуют общие ограничения применимости модификатора в зависимости от типа параметра. Например, модификатор exact (точное совпадение) имеет смысл для параметров типа string, но не может быть применен к параметру типа token. Исключение составляют параметры поиска типа special - для каждого такого параметра список допустимых модификаторов индивидуален.
Таблица 356
Модификаторы параметров поиска
Если значением параметра является список, то модификатор применяется к каждому элементу списка.
12.26.6 Префиксы
Префиксы значений параметров используются для параметров типа number, date и quantity, имеющих упорядоченные области значений. Они позволяют избежать применения escape-последовательностей в строке URL и обеспечивают наглядность визуализации.
Допустимые префиксы приведены в таблице 357. При описании префиксов "значение параметра" обозначает значение параметра поиска, а "значение элемента" - значение элемента ресурса, на который отображается параметр.
Таблица 357
Использование префиксов предполагает, что элемент присутствует и его значение определено. Для поиска элементов с отсутствующими значениями следует использовать модификаторы missing или not.
Префиксы могут использоваться в списках значений параметра, подразумевающих логическое ИЛИ. В этих случаях префикс относится только к значению, которому он предшествует.
По умолчанию предполагается префикс eq. Следует иметь в виду, что применение префиксов отличается от аналогичных математических операций. Префиксы sa (начинается после) и eb (заканчивается до) применимы к десятичным значениям, но не применимы к целым.
Графа "формальное определение" содержит описание префикса в терминах диапазонов, применимых для десятичных значений и дат. Эти диапазоны могут быть явными или подразумеваемыми. Например, десятичное число 2.0 имеет подразумеваемый диапазон значений от 1.95 до 2.05, а для даты 2015-08-12 подразумевается диапазон времени в течение всего дня. У элемента с типом данных Range, Period или Timing диапазон значений задан явно. Варианты диапазонов приведены в таблице 358.
Таблица 358
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 могут использоваться префиксы. Примеры совпадений значения элемента со значением параметра приведены в таблице 360.
Таблица 360
со значением параметра типа date
При выполнении поиска по дате и времени сервер по возможности должен учитывать часовые пояса. Если значения параметра и значение элемента не содержат часовой пояс, то должен использоваться местный часовой пояс сервера.
12.26.9 Параметр типа number
Параметр типа number используется для поиска по заданному числовому значению.
Примеры совпадений значения элемента со значением параметра приведены в таблице 361.
Таблица 361
со значением параметра типа number
Если числовой поиск ведется по элементу ресурса, значение которого является целым числом, и значение параметра поиска не представлено в экспоненциальной форме и не содержит ненулевые цифры после десятичной точки, то правило учета значащих цифр не применяется и поиск ведется по точному совпадению.
При использовании префиксов 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
12.26.11 Параметр типа reference
Параметр типа reference используется для поиска по ссылке на экземпляр ресурса, используя следующие варианты:
а) [параметр]=[id] - поиск по логическому идентификатору [id] экземпляра ресурса (относительная ссылка);
б) [параметр]=[type]/[id] - поиск по логическому идентификатору [id] экземпляра ресурса (относительная ссылка, в которой могут быть указаны разные типы ресурсов);
в) [параметр]=[url] - поиск по абсолютному или каноническому URL.
Если относительная ссылка разрешается тем же самым адресом, что и абсолютный URL, то при поиске она считается совпадающей с абсолютным URL. Например, при запросе
GET /template/go.php?url=https://example.org/fhir/Observation?subject=Patient/123
должны быть найдены экземпляры ресурса Observation, у которых элемент subject.reference имеет следующие значения:
а) Patient/123 - точное совпадение со значением параметра поиска;
б) /template/go.php?url=https://example.org/fhir/Patient/123 - значение параметра поиска неявно разрешается этим URL по базовому URL сервера.
Аналогично при запросе
GET /template/go.php?url=https://example.org/fhir/Observation?subject=/template/go.php?url=https://example.org/fhir/Patient/123
должны быть найдены экземпляры ресурса Observation, у которых элемент subject.reference имеет следующие значения:
а) /template/go.php?url=https://example.org/fhir/Patient/123 - точное совпадение со значением параметра поиска;
б) Patient/123 - значение элемента неявно разрешается значением параметра поиска по базовому URL сервера.
При запросе без указания типа ресурса
GET /template/go.php?url=https://example.org/fhir/Observation?subject=123
должны быть найдены экземпляры ресурса Observation, у которых элемент subject.reference имеет следующие значения:
а) Patient/123 - относительный URL экземпляра ресурса Patient;
б) /template/go.php?url=https://example.org/fhir/Patient/123 - абсолютный URL экземпляра ресурса Patient с базовым URL запроса;
а) Practitioner/123 - относительный URL экземпляра ресурса Practitioner;
б) /template/go.php?url=https://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=/template/go.php?url=https://acme.org/fhir/identifier/mrn|123456
будет осуществлен поиск результатов исследований, у которых элемент subject.identifier.system = /template/go.php?url=https://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 приведены в таблице 364.
Таблица 364
12.26.14 Параметр типа uri
Параметр типа uri используется для поиска по значениям элементов с типом данных uri и url, содержащих идентификаторы URI [27]. Значение параметра должно полностью совпадать со значением элемента с учетом регистра и диакритических знаков. Для поиска с частичным совпадением используются модификаторы above или below. В следующих примерах параметр url имеет тип uri:
GET [base]/ValueSet?url=/template/go.php?url=https://hl7.org/fhir/ValueSet/example-filter
GET [base]/ValueSet?url:below=/template/go.php?url=https://hl7.org/fhir/ValueSet
GET [base]/ValueSet?url:above=/template/go.php?url=https://hl7.org/fhir/ValueSet/example-filter/_history/1
GET [base]/ValueSet?url=urn:oid:1.2.3.4.5
Первый запрос означает поиск наборов значений ValueSet, у которых элемент url имеет значение /template/go.php?url=https://acme.org/fhir/ValueSet/123.
Второй запрос означает поиск наборов значений ValueSet, у которых элемент url начинается со значения /template/go.php?url=https://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=/template/go.php?url=https://www.radlex.org| RID49679$le1.7
означает поиск экземпляров ресурса Observation, у которых компонент code элемента component имеет значение RID49679 в системе кодирования /template/go.php?url=https://www.radlex.org и компонент value имеет значение, меньшее или равное 1.7.
Модификаторы не применимы к параметрам типа composite.
Примеры запросов поиска с параметрами типа composite приведены в таблице 365.
Таблица 365
12.27.1 Общие требования
В простом запросе поиска выделяются следующие компоненты:
а) значение параметра, с которым осуществляется сравнение,
б) тип сравнения;
в) нуль, одно или несколько значений, выделяемых из содержания экземпляра ресурса.
Например, поиск экземпляров ресурса Patient с параметром запроса given=value представляет собой запрос к серверу на сравнение значения имени пациента со значением параметра поиска value, используя сравнение строк по умолчанию.
Значения параметров поиска разбираются на компоненты в соответствии с типом параметра.
Способ сравнения определяется типом параметра поиска, модификатором или префиксом. Например, для параметра поиска типа number по умолчанию используется равенство, то есть "{значение элемента} равно {значение параметра поиска})". Модификатор изменяет способ сравнения, к примеру, модификатор not изменяет равенство на его отрицание, а именно, "не({значение элемента} равно {значение параметра поиска})". Наконец, префикс можно использовать для отношений типа "больше", то есть "{значение элемента} равно {значение параметра поиска})". В простом запросе не допускается указание модификатора одновременно с префиксом.
12.27.2 Совпадение и кратность
Многие элементы ресурсов определены как массивы (коллекции) значений. Например, у пациента может быть несколько имен или адресов. Совпадение значения параметра поиска с коллекцией значений считается успешным, если оно имеет место хотя бы с одним экземпляром в составе коллекции. Например, если экземпляр ресурса Patient содержит два экземпляра элемента name, то совпадение считается успешным, если значение параметра совпало хотя бы с одним из них.
12.27.3 Совпадение и субэлементы
Если параметр поиска отображается на элемент с комплексным типом данных (то есть элемент содержит субэлементы), то по умолчанию сравнение значения параметра со значением этого элемента интерпретируется как сравнение с одним или несколькими значениями субэлементов соответствующего типа.
12.27.4 Соединение параметров поиска операторами И и ИЛИ
Параметры поиска могут соединяться операторами И и ИЛИ. Соединение ИЛИ означает объединение найденных множеств, соединение И - пересечение. Соединения осуществляются на уровне экземпляров ресурсов и порядок параметров поиска не имеет значения.
Если в запросе указаны несколько параметров поиска, то они используются для получения пересечения результатов поиска по отдельным параметрам, то есть соединяются с помощью оператора И. При этом параметр поиска с одним и тем же именем может быть указан более одного раза.
Для объединения найденных множеств, то есть соединения с помощью оператора ИЛИ, в параметре поиска следует указать список значений, разделенных запятыми (,). Каждое значение в этом списке может иметь собственный префикс. Например, по запросу
GET [base]/Observation?code=/template/go.php?url=https://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 (/template/go.php?url=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.
К параметрам, участвующим в обратном сцеплении, не должны применяться модификаторы.
Если сервер не в состоянии выполнить запрос, он может возвратить код статуса HTTP, идентифицирующий ошибку, или может возвратить код статуса HTTP 200 OK и контейнер результата запроса Bundle, в который вложен экземпляр ресурса OperationOutcome, содержащий сведения об ошибке. Код статуса HTTP 403 Forbidden означает, что сервер отказывается выполнить запрос, а другие коды 4xx или коды 5xx означают наличие ошибки какого-либо рода. Если запрос не выполнен, сервер по возможности должен возвратить экземпляр ресурса OperationOutcome, детализирующий причину. Пустой результат запроса ошибкой не является.
Сервер может получить запрос с параметрами, которые он не распознает или не поддерживает (вообще или в данном запросе). В общем случае сервер по возможности должен игнорировать неизвестные или неподдерживаемые параметры, поскольку различные компоненты стека HTTP и прокси могут добавить к запросу параметры, которые клиент не в состоянии контролировать. Клиент может определить фактически примененные параметры, анализируя компонент url элемента link контейнера результата запроса Bundle, у которого компонент relation имеет значение self.
Клиент может указать серверу вариант обработки таких параметров с помощью заголовка HTTP Prefer:
а) Prefer: handling=strict означает требование возвращения ошибки при получении неизвестного или неподдерживаемого параметра;
б) Prefer: handling=lenient означает требование игнорирования неизвестного или неподдерживаемого параметра.
Сервер по возможности должен выполнить такое требования, не обязан это делать.
Для всех типов ресурсов определены стандартные параметры поиска, приведенные в таблице 366.
Таблица 366
12.31.1 Общие требования
Для управления результатами запроса на поиск экземпляров ресурса используются параметры, перечисленные в таблице 367.
Таблица 367
За исключением параметров _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 или какие-либо из его значений.
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. Следует иметь в виду, что сокращенное содержание экземпляра ресурса может быть не пригодно для использования во взаимодействии изменения update. Сервер по возможности должен передать элемент meta.tag со значением SUBSETTED в качестве признака сокращенного содержания.
Поскольку для интерпретации результатов поиска важно знать фактически примененные параметры, то независимо от значения параметра _summary в контейнере результатов поиска Bundle должен быть возвращен элемент link, у которого компонент relation имеет значение self.
Параметры _include и _revinclude не могут быть указаны, если _summary=text.
12.31.7 Параметр _score (добавление оценки релевантности запросу)
Параметр _score используется для добавления оценки релевантности запросу при недетерминированном поиске. Допустимые значения параметра _score приведены в таблице 370.
Таблица 370
Пример оценки релевантности запросу приведен в подразделе 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 определяется сервером для каждого типа ресурса.
Если поиск не является детерминированным, то алгоритм поиска может генерировать показатель соответствия найденного экземпляра ресурса критериям поиска. Эта оценка возвращается в элементе entry.score, например:
"entry": {
"score": 0.45,
"resource": {
"resourceType": "Patient",
... patient data ...
}
}
Оценка представляет собой десятичное число между 0 и 1, где 1 - точное соответствие, а 0 - отсутствие соответствия.
Параметр _query идентифицирует именованную операцию, реализующую особую логику поиска. Для нее могут быть определены дополнительные параметры.
Именованные запросы разрешены в контексте системы или типа ресурса. Они не могут быть определены на уровне экземпляра ресурса.
При использовании именованного запроса по возможности должны быть доступны все стандартные параметры поиска, описанные в подразделе 12.30. Если именованный запрос определен для типа ресурса, то по возможности должны быть доступны специальные параметры поиска, определенные для этого типа.
Для определения именованного запроса используется экземпляр ресурса OperationDefinition, например:
<?xml version="1.0" encoding="windows-1251"?>
<OperationDefinition xmlns="/template/go.php?url=https://hl7.org/fhir">
<!-- Определение именованного запроса current-high-risk -->
<id value="current-high-risk" />
<url value="/template/go.php?url=https://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
Результаты операции поиска актуальны только на момент ее выполнения. Это особенно важно иметь в виду при постраничном выводе результатов, если каждая страница формируется в момент ее запроса, а не заранее.
Отображение типов данных на типы параметров приведено в таблице 372.
Таблица 372
Несколько запросов поиска может быть передано в одном контейнере пакета или транзакции Bundle. Каждый запрос должен выполняться независимо от другого. Ответы на запросы возвращаются в контейнере результата пакета или транзакции Bundle. При успешном выполнении всех запросов поиска контейнер результата пакета или транзакции должен иметь структуру, показанную на рисунке 83.
![]() пакета или транзакции запросов поиска
Если при выполнении какого-либо запроса поиска возникла ошибка, то вместо контейнера результата транзакции должен быть возвращен экземпляр ресурса OperationOutcome с описанием ошибки, а в контейнере результатов пакета экземпляр ресурса OperationOutcome должен быть возвращен вместо соответствующего контейнера результата поиска Bundle.
Для передачи запроса поиска в сообщении должен использоваться экземпляр Parameters, у которого элемент name имеет значение url, а элемент valueString содержит часть строки поиска после базового URL (включая знак вопроса). Элемент event заголовка сообщения должен иметь значение search-type, если поиск осуществляется в контексте типа ресурса, или search-system, если поиск осуществляется в контексте системы.
Ответное сообщение может содержать контейнер результатов поиска Bundle или экземпляр ресурса Binary, содержащий двоичное представление результата поиска в ином формате, например, файл формата CSV, упакованный в архив ZIP.
В REST API определен общий набор взаимодействий (чтение, изменение, поиск и т.д.), обеспечиваемых сервисом хранения и обработки результатов измерений или иным сервером. Они следуют парадигме REST по управлению состоянием с помощью действий Create (создать)/Read (читать)/Update (изменить)/Delete (удалить), совершаемых над совокупностью идентифицированных экземпляров ресурсов. Хотя во многих случаях этого достаточно, существует определенная функциональность, которая более эффективно реализуется с помощью парадигмы, подобной RPC (Remote Procedure Call - удаленный вызов процедуры), согласно которой выполняются (Execute) именованные операции с входными и выходными параметрами,
Операции предпочтительны в следующих случаях:
а) требуется не просто возвращать существующую информацию, но еще и активно формировать возвращаемый контент;
б) необходимо инициировать побочное действие, например, автоматически создать экземпляр ресурса уведомлений при получении результата измерений, выходящего за заданные границы, или выполнить иные изменения, не укладывающиеся в рамки REST;
в) требуется применить форматно-логический контроль к нескольким экземплярам ресурсов разных типов;
г) необходимо выполнить скоординированные изменения нескольких экземпляров ресурсов (это можно сделать с помощью контейнеров Bundle типа transaction, но операции обеспечивают более гибкий подход).
Операции обладают следующими общими свойствами:
а) каждая операция имеет имя;
б) для каждой операции определены списки входных и выходных параметров;
в) параметрами могут служить экземпляры ресурсов, типизированные значения или параметры поиска;
г) к операциям предъявляются те же требования информационной безопасности, как и к REST API;
д) идентификаторы URI конечных точек операций основаны на существующей схеме адресации конечных точек REST API;
е) операции могут использовать все типы ресурсов, экземпляры которых содержатся в хранилище результатов измерений;
ж) операции могут применяться к экземпляру ресурса, к типу ресурса или ко всему хранилищу.
Для вызова операции используется адрес URL, произведенный от конечной точки сервера с помощью указания имени операции, которому предшествует знак доллара ('$'), например:
POST Базовый_URL/Observation/1/$everything
Если в определении операции элемент affectsState (воздействует на состояние) имеет значение false и все параметры операции имеют простые типы данных без расширений, то операцию можно вызвать и с помощью метода GET (или HEAD).
Операции могут вызываться для конечных точек следующих трех типов:
а) базовый URL-адрес сервера (например, /template/go.php?url=https://localhost:8080). Такие операции манипулируют содержанием базы данных сервера, например, "получить все расширения, которыми может оперировать данный сервер";
б) URL типа ресурса (например, (/template/go.php?url=https://localhost:8080/Observation). Такие операции манипулируют экземплярами ресурсов данного типа;
в) URL экземпляра ресурса (например, (/template/go.php?url=https://localhost:8080/Observation/1). Такие операции манипулируют конкретным экземпляром ресурса.
Тело вызова операции содержит экземпляр специального ресурса Parameters, представляющий коллекцию именованных параметров в форме <ключ, значение>, где значение может иметь простой или комплексный тип данных либо представлять собой экземпляр ресурса. Значения могут также представлять собой строки в формате параметров поиска.
По завершении операции возвращается код статуса HTTP, характеризующий результат ее выполнения, и может возвратиться другой экземпляр ресурса Parameters, содержащий один или несколько выходных параметров. Если определен единственный выходной параметр с именем return и максимального кратностью 1, и его типом является ресурс, то результатом операции должен быть экземпляр этого ресурса, без вложения в экземпляр ресурса Parameters. Если выходные параметры отсутствуют, то возвращается пустое тело ответа.
Таким образом, операция получает на вход коллекцию из нуля или нескольких параметров и возвращает коллекцию из нуля или нескольких параметров результата вызова. Тело метода POST и возвращаемого результата (при наличии) всегда является экземпляром ресурса.
Для вызова операция может использоваться метод GET с параметрами в адресной строке, если выполнены следующие условия:
а) все входные параметры являются простыми (то есть их значения не имеют комплексные типы данных наподобие Identifier или Reference;
б) операция не воздействует на состояние сервера.
Если тело ответа является экземпляром ресурса Bundle, не имеющим семантику результата поиска, то элемент Bundle.type должен иметь значение collection и может содержать ссылки на страницы результата.
Если операция не имеет входных параметров и не воздействует на состояние сервера, то она может быть вызвана с помощью метода GET, например:
GET [Базовый_URL]/Observation/1/$meta.
Если операция без входных параметров воздействует на состояние сервера, то она должна быть вызвана с помощью метода POST. В этом случае экземпляр ресурса Parameters не передается, поскольку он не может быть пустым. Поэтому при вызове такой операции следует указать, что тело отсутствует, например:
POST [Базовый_URL]/Observation/1/$meta
Content-Length: 0.
Для каждой операция должна быть указана следующая информация:
а) уровень, на котором она вызывается - система, тип ресурса или экземпляр ресурса;
б) имя операции;
в) список параметров с их определениями.
Для каждого параметра необходимо указать следующую информацию:
а) имя параметра. Для удобства реализации имя должно быть валидным для наиболее распространенных языков программирования;
б) использование параметра - in (входной) | out (выходной) | both (входной и выходной) и его кратность;
в) тип значения параметра - тип данных или тип ресурса;
г) тип параметра поиска (не обязателен). Если параметр имеет строковое значение и используется как параметр поиска, то можно назначить ему один из типов number | date | string | token | reference | composite | quantity | uri | special и указать, какие модификаторы параметров поиска могут использоваться;
д) профиль (не обязателен) - экземпляр ресурса StructureDefinition, описывающий дополнительные ограничения, накладываемые на параметр. Может задаваться только в том случае, если значение параметра имеет тип данных или является экземпляром ресурса;
е) описание назначения параметра.
Параметры могут содержать вложенные компоненты. Для каждого компонента предоставляется та же информация, что и для параметра, кроме использования, которое наследуется от параметра, чьей частью является данный компонент.
Машинно-обрабатываемое описание операции представляет собой экземпляр ресурса Operation Definition.
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=/template/go.php?url=https://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-форм.
Если операция выполнена успешно, возвращается статус HTTP с кодом 2xx или 303 See Other. Другие значения кодов 3xx следует воспринимать, как признак ошибки выполнения операции и клиенту может потребоваться новый вызов, если он в состоянии обработать перенаправление (например, на страницу аутентификации). Коды статуса HTTP 4xx или 5xx означают ошибку и в этом случае должен быть возвращен экземпляр ресурса OperationOutcome с детальными сведениями об ошибке.
В общем случае результатом выполнения операции является экземпляр ресурса Parameters, содержащий один или несколько именованных выходных параметров.
В случае единственного выходного параметра типа Resource с именем return вместо экземпляра ресурса Parameters возвращается экземпляр ресурса другого типа.
Как и при других взаимодействиях, в заголовке Accept вызова операции может быть указан формат возвращаемого результата.
Сервер может сохранить экземпляр ресурса, возвращенный в качестве результата запроса. В этом случае экземпляр должен содержать элемент идентификатора id. Если возвращенный экземпляр ресурса не сохранен сервером, элемент id должен отсутствовать.
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.1 Операция $lookup
13.8.1.1 Общие сведения
Если на вход операции $lookup задана пара <система кодирования, код> или значение типа Coding, то операция возвратит детальные сведения о кодированном понятии, включая определение, статус, обозначения и свойства. Обязательными параметрами является или пара <система кодирования, код>, или значение типа Coding. Остальные параметры необязательны. Операция является идемпотентной. Ее параметры представлены в таблице 373.
Таблица 373
13.8.1.2 Примеры
Запрос на поиск данных о коде DSG из системы кодирования с url = /template/go.php?url=https://terminology.hl7.org/CodeSystem/v2-0203:
/template/go.php?url=https://hapi.fhir.org/baseR5/CodeSystem/$lookup?system=/template/go.php?url=https://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=\"/template/go.php?url=https://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
13.8.2.2 Валидация значения типа code
Запрос на валидацию кода DSG в системе кодирования с url = /template/go.php?url=https://terminology.hl7.org/CodeSystem/v2-0203:
/template/go.php?url=https://hapi.fhir.org/baseR5/CodeSystem/$validate-code?url=/template/go.php?url=https://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 /template/go.php?url=https://terminology.hl7.
org/CodeSystem/v2-0203#DSG1 - Code is not found in CodeSystem: /template/go.php?url=https://
terminology.hl7.org/CodeSystem/v2-0203"
} ]
}
Если в строке запроса указан дополнительный параметр display, например:
/template/go.php?url=https://hapi.fhir.org/baseR5/CodeSystem/$validate-code?url=/template/go.php?url=https://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=\"/template/go.php?url=https://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 = /template/go.php?url=https://rosstat.gov.ru/opendata/7708234640-okved2:
POST localhost:8080/fhir/CodeSystem/$validate-code
[другие заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "url",
"valueUri": "/template/go.php?url=https://rosstat.gov.ru/opendata/7708234640-okved2"
},
{
"name": "coding",
"valueCoding": {
"system": "/template/go.php?url=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 {/template/go.php?url=https://rosstat.gov.ru/opendata/7708234640-
okved2}85.1 - Concept Display : Образование"
}
]
}
13.8.2.4 Валидация значения типа CodeableConcept
Запрос на валидацию значения типа CodeableConcept, содержащего коды Yes и Y в системе кодирования с url = /template/go.php?url=https://terminology.hl7.org/CodeSystem/v2-0532:
POST localhost:8080/fhir/CodeSystem/$validate-code
[заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "url",
"valueUri": "/template/go.php?url=https://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 {/template/go.php?url=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=\"/template/go.php?url=https://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 '/template/go.php?url=https://rosstat.gov.ru/
opendata/7708234640-okved3' does not equal with CodeSystem.url '/template/go.php?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 '/template/go.php?url=https://rosstat.gov.ru/
opendata/7708234640-okved3' does not equal with CodeSystem.url '/template/go.php?url=https://rosstat.
gov.ru/opendata/7708234640-okved2'. Unable to validate."
}
]
}
13.9.1 Операция $expand
13.9.1.1 Общие сведения
Операция $expand возвращает раскрытие набора значений, то есть список кодов, которые образуют набор значений в соответствии с его определением, заданным с помощью ресурса ValuSet. Если набор значений сохранен вместе с раскрытием, то она возвращает сохраненное раскрытие. Если набор значений сохранен без раскрытия, то она создает раскрытие динамически.
Если операция вызывается на уровне системы или типа ресурса, то должен быть задан один из входных параметров url, context или valueSet. В ответ возвращается либо экземпляр ресурса ValueSet, описывающий раскрытие, либо экземпляр ресурса OperationOutcome, содержащий сообщение об ошибке.
Если набор значений сохранен вместе с раскрытием, то операция $expand является идемпотентной. Если раскрытие создается динамически, то при повторном вызове результат может измениться. Параметры операции $expand представлены в таблице 375.
Таблица 375
Возвращаемое раскрытие набора значений должно восприниматься как динамическое, которое может изменяться с течением времени (это зависит от того, как определен набор значений).
Если раскрытие слишком велико, то сервер может возвратить экземпляр ресурса OperationOutcome с кодом ошибки too-costly (слишком затратное). В этом случае клиент может запросить раскрытие набора значений по частям, указывая параметры offset и count. В отличие от запросов, где при постраничной выдаче указываются ссылки на другие страницы, сервер должен пропустить offset кодов и выдать следующие count кодов. Сервер не обязан поддерживать эти параметры, но если поддерживает, то должен обрабатывать оба этих параметра. К иерархическим раскрытиям эти параметры не применимы.
Если сервер не может правильно раскрыть набор значений, поскольку не имеет информации о содержании системы кодирования, указанной в определении набора значений, то он должен возвратить ошибку. Если набор значений не полон, поскольку включает в себя пост-координируемые коды, например, коды производных единиц измерения, то в раскрытие набора значений может быть включено расширение /template/go.php?url=https://hl7.org/fhir/StructureDefinition/valueset-unclosed, указывающее, что раскрытие не является полным.
13.9.1.2 Примеры
Запрос на раскрытие набора значений с идентификатором 95507, применяя фильтр Ye:
/template/go.php?url=https://hapi.fhir.org/baseR4/ValueSet/95507/$expand?filter=Ye
Запрос на раскрытие набора значений по его каноническому URL, применяя фильтр Ye:
/template/go.php?url=https://hapi.fhir.org/baseR4/ValueSet/$expand?url=/template/go.php?url=https://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": "/template/go.php?url=https://terminology.hl7.org/ValueSet/yesnodontknow",
"status": "active",
"compose": {
"include": [
{
"valueSet": [
"/template/go.php?url=https://terminology.hl7.org/ValueSet/v2-0136"
]
},
{
"system": "/template/go.php?url=https://terminology.hl7.org/CodeSystem/data-
absent-reason",
"concept": [
{
"code": "asked-unknown",
"display": "Вопрос оставлен без ответа"
}
]
}
]
}
}
}
]
}
Результат запроса:
HTTP 200 OK
[заголовки]
{
"resourceType": "ValueSet",
"id": "95507",
"meta": {
"extension": [ {
"url": "/template/go.php?url=https://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": "/template/go.php?url=https://terminology.hl7.org/ValueSet/yndontknow",
"status": "active",
"compose": {
"include": [ {
"valueSet": [ "/template/go.php?url=https://terminology.hl7.org/ValueSet/v2-0136" ]
}, {
"system": "/template/go.php?url=https://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": "/template/go.php?url=https://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
Запрос на валидацию кода Y, принадлежащего системе кодирования /template/go.php?url=https://terminology.hl7.org/CodeSystem/v2-0532, в наборе значений с url = /template/go.php?url=https://hl7.org/fhir/ValueSet/yesnodontknow:
/template/go.php?url=https://hapi.fhir.org/baseR5/ValueSet/$validate-code?url=/template/go.php?url=https://terminology.hl7.org/ValueSet/yndontknow&system=/template/go.php?url=https://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 /template/go.php?url=https://terminology.hl7.org/
CodeSystem/v2-0532#Y1 - Unknown code \"/template/go.php?url=https://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=/template/go.php?url=https://terminology.hl7.org/ValueSet/yndontknow&system=/template/go.php?url=https://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=\"/template/go.php?url=https://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 в системе кодирования /template/go.php?url=https://terminology.hl7.org/CodeSystem/v2-0532, в наборе значений с url = /template/go.php?url=https://hl7.org/fhir/ValueSet/yesnodontknow:
POST hapi.fhir.org/baseR5/ValueSet/$validate-code
[заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "url",
"valueUri": "/template/go.php?url=https://hl7.org/fhir/ValueSet/yesnodontknow"
},
{
"name": "coding",
"valueCoding": {
"code": "Y",
"system": "/template/go.php?url=https://terminology.hl7.org/CodeSystem/v2-0532",
}
}
]
}
Ответы те же, что приведены в 13.9.2.2.
13.9.2.4 Валидация значения типа CodeableConcept
Запрос на валидацию значения типа CodeableConcept, содержащего коды Yes и Y в системе кодирования /template/go.php?url=https://terminology.hl7.org/CodeSystem/v2-0532, в наборе значений с url = /template/go.php?url=https://hl7.org/fhir/ValueSet/yesnodontknow:
POST hapi.fhir.org/baseR5/ValueSet/$validate-code
[заголовки]
{
"resourceType": "Parameters",
"parameter": [
{
"name": "url",
"valueUri": "/template/go.php?url=https://hl7.org/fhir/ValueSet/yesnodontknow"
},
{
"name": "codeableConcept",
"valueCodeableConcept": {
"coding": [
{
"code": "Yes",
"system": "/template/go.php?url=https://terminology.hl7.org/CodeSystem/v2-0532",
"display": "Да"
},
{
"code": "Y",
"system": "/template/go.php?url=https://terminology.hl7.org/CodeSystem/v2-0532",
}
]
}
}
]
}
Ответ (второй код валиден):
HTTP 400 Bad Request
[заголовки]
<Parameters
xmlns="/template/go.php?url=https://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: /template/go.php?url=https://hl7.org/fhir/ValueSet/yesnodontknow"/>
</parameter>
<parameter>
<name value="display"/>
<valueString value="Yes"/>
</parameter>
</Parameters
Примечание - Массив coding в теле запроса просматривается последовательно. Если первый элемент массива валиден, то другие не проверяются. Если первый элемент не принадлежит данной системе кодирования, то проверяется второй элемент и т.д.
Ответы в случае, если все коды не валидны:
HTTP 400 Bad Request
[заголовки]
<Parameters
xmlns="/template/go.php?url=https://hl7.org/fhir">
<parameter>
<name value="result"/>
<valueBoolean value="false"/>
</parameter>
<parameter>
<name value="message"/>
<valueString value="Unknown code '/template/go.php?url=https://terminology.hl7.org/CodeSystem/
v2-0532#Y1' for in-memory expansion of ValueSet '/template/go.php?url=https://hl7.org/fhir/ValueSet/
yesnodontknow'"/>
</parameter>
</Parameters>
В ответе последний ошибочный код.
Ответ (ошибка вызова):
HTTP 400 Bad Request
[заголовки]
<OperationOutcome
xmlns="/template/go.php?url=https://hl7.org/fhir">
<text>
<status value="generated"/>
<div
xmlns="/template/go.php?url=https://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>
Ресурсы могут использоваться в традиционном контексте обмена сообщениями. Сообщения требования передается приложением-источником приложению-получателю при возникновении некоторого события, обычно события реального мира. Сообщение требования состоит из экземпляра ресурса Bundle, имеющего тип message. В него вложены другие экземпляры ресурсов, первый из которых должен иметь тип MessageHeader (заголовок сообщения). Он содержит код события MessageHeader.code, характеризующий природу сообщения требования, и дополнительные метаданные. Какие другие ресурсы будут включены в сообщение, зависит от типа требования.
Приложение-получатель обрабатывает требование и возвращает одно или несколько ответных сообщений, которые также состоят из экземпляра ресурса Bundle типа message и включенных в него экземпляров ресурсов, первым из них должен быть заголовок сообщения MessageHeader, содержащий раздел результата обработки сообщения, за которым следуют экземпляры ресурсов других типов, составляющие содержание ответа. Среди них выделяются так называемые фокальные экземпляры, перечисленные в элементах MessageHeader.focus. Они являются центральными компонентами сообщения; другие экземпляры, включенные в сообщение, должны прямо или косвенно ссылаться на фокальные экземпляры либо (опять-таки прямо или косвенно) быть ссылочными для фокальных экземпляров.
Содержание сообщения передается от одного приложения другому с помощью некоторого механизма доставки, после чего приложению-источнику возвращается один или несколько ответов. Точный механизм не имеет значения - им может быть обмен файлами, обмен по протоколу HTTP или что-нибудь другое. Единственное ограничение состоит в том, что требования передаются по известному адресу, а ответы возвращаются приложению-источнику.
Соглашения о содержании сообщений и поведению двух взаимодействующих приложений образуют "контракт", описывающий взаимодействие. Содержание контракта дополняет правила, описанные в настоящей спецификации.
Настоящая спецификация игнорирует существование шлюзов и агентов передачи сообщений, которые могут быть промежуточными узлами между источником и получателем. Они либо прозрачны для содержания сообщения/транзакции, либо активно манипулируют содержанием сообщения (в частности, нередко изменяют заголовки сообщения). Если промежуточные агенты модифицируют содержание сообщения, то они становятся ответственными за выполнение контракта (включая применяемые профили) в обоих направлениях.
Ключевой характеристикой сообщения является воздействие его содержания.
Категории воздействия сообщений показаны на рисунке 84 и представлены в таблице 377.
![]() Таблица 377
Некоторые события обмена сообщениями могут быть отнесены к одной из этих категорий, но другим категории не могут быть присвоены заранее, поскольку могут зависеть от содержания, контекста или сценария использования.
Другим ключевым аспектом сообщения является его влияние на получателей. В некоторых случаях достаточно направить сообщение конечной точке, в других может потребоваться, что сообщение было направлено конкретной организации или конкретному лицу. Соотнесение влияния на получателей с категорией сообщения представлено в таблице 378.
Таблица 378
На каждое сообщение требования должно быть передано одно или несколько ответных сообщений. Должен быть дан хотя бы один ответ, чтобы отправитель знал, что сообщение было доставлено. В ответ на сообщение требования не должно возвращаться несколько сообщений. Не рекомендуется возвращать несколько ответов на сообщение запроса.
В принципе не требуется, чтобы приложение-источник ожидало ответа на транзакцию прежде чем инициировать новую транзакцию. Но во многих случаях определенный поток сообщений может требовать последовательной обработки. Кроме того, некоторые методы передачи также могут требовать последовательной доставки сообщений.
Шаблон синхронного взаимодействия, при котором отправитель передает сообщение и ожидает получение единственного ответа по тому же самому каналу передачи данных, а затем передает следующее сообщение, самый легкий для понимания и управления:
а) отправитель передает сообщение получателю (серверу);
б) сервер обрабатывает его и возвращает ответ.
Обычно (хотя не всегда) отправитель ждет ответа на текущее сообщение и только потом посылает новое.
Синхронный обмен сообщениями не рассчитан на ситуацию, когда на одно сообщение передается несколько ответов, что имеет место при постраничной передаче результатов запроса, и ограничивает пропускную способность канала передачи данных, что может оказаться существенным при передаче большого объема данных. Кроме того, ожидание ответных сообщений может оказаться неприемлемым. В этих случаях следует использовать асинхронное взаимодействие.
При асинхронном взаимодействии сервер немедленно подтверждает получение сообщения, а ответ на него возвращает отдельно. На одно сообщение сервер может возвратить несколько ответов.
По содержанию заголовка сообщения получатель может определить, является ли оно новым, требующим обработки, или ответом на ранее переданное сообщение. Асинхронная передача сообщений сложнее по реализации, поскольку при ней больше вариантов ошибочных ситуаций. Настоящий стандарт не предписывает никакой протокол обработки ошибок; он оставляется на усмотрение разработчиков взаимодействия.
Обмен сообщениями можно реализовать, используя конечную точку 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.
Этот простой протокол нуждается в администрировании, чтобы несколько взаимодействующих сторон не мешали друг другу, используя одинаковые идентификаторы, а также для исключения злоумышленных атак.
Входящее сообщение имеет два идентификатора: Bundle.id и MessageHeader.id. При создании нового сообщения ему должен быть присвоен идентификатор (MessageHeader.id), уникальный для данного потока сообщений. Поскольку потоки сообщений нередко перемешиваются, рекомендуется присваивать глобально уникальный идентификатор. С этой целью можно использовать UUID или ОИД. При каждой передаче сообщения полю Bundle.id следует присваивать новое значение.
Когда получатель получил и обработал сообщение, он возвращает новое сообщение с новым идентификатором, включенное в экземпляр ресурса Bundle, также имеющий новый идентификатор. Заголовок ответного сообщения повторяет идентификатор сообщения требования MessageHeader.id в поле MessageHeader.response.identifier, чтобы система-источник могла соотнести ответ с требованием.
Сообщение имеет 2 важных штампа даты и времени:
а) Bundle.timestamp: время отправки сообщения;
б) Bundle.meta.lastUpdated: последнее время изменения сообщения (сохранения или модификации).
Кроме того, сообщение может иметь дополнительные штампы даты и времени в полях meta.lastUpdated или других полях вложенных ресурсов. Их назначение зависит от события, по которому передано сообщение.
Некоторые из механизмов передачи сообщений являются надежными - сообщение всегда доставляется или его источнику возвращается сообщение об ошибке. Однако в большинстве реализаций используются механизмы, не предусматривающие надежный транспорт сообщений и требование или ответ на него могут быть потеряны. Настоящая спецификация описывает простой подход, которому получателю по возможности должны следовать, чтобы обеспечить предсказуемую функциональность.
Если отправитель сообщения реализует надежный транспорт, то по истечении сконфигурированного таймаута ожидания ответного сообщения, заданного в элементе messaging.reliableCache ресурса CapabilityStatement, он должен выполнить действия, указанные в таблице 379.
Таблица 379
Если получатель сообщения реализует надежный транспорт, то он должен проверить Bundle.id и MessageHeader.id в кэше ранее полученных сообщений. Предпринимаемые действия зависят от результата проверки (таблица 380).
Таблица 380
Период кэширования обычно не должен быть слишком большим. Как минимум, он должен быть на 1 минуту дольше таймаута системы-отправителя, но в зависимости от политики повторной отправки сообщений, принятой системой-отправителем, он может быть и больше.
Приложения, реализующие надежный транспорт, объявляют длительность надежного кэша в элементе messaging.reliableCache экземпляра ресурса CapabilityStatement, описывающего возможности приложения.
Сообщение можно следующим образом использовать для вызова операции, определенной в интерфейсе 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=
<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=
<!-- Раскрытие набора значений -->
<code value=
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="/template/go.php?url=https://hl7.org/fhir/ValueSet/identifier-type"/>
</parameter>
</Parameters>
</resource>
</entry>
</Bundle>
Следует учесть, что операцию нельзя вызвать по URL. Указанным выше способом можно вызывать только операции, определенные на уровне системы или ресурса для конкретного ресурса.
Тем же способом, что вызывается операция, можно выполнить поиск. При поиске также используется ресурс Parameters со следующими правилами:
а) код события должен быть равен search-type или search-system, система кодирования /template/go.php?url=https://hl7.org/fhir/restful-interaction;
б) если тип события равен search-type, то должен быть параметр resourceType, задающий тип искомого ресурса.
Типы параметров поиска преобразуются в типы данных FHIR в соответствии с таблицей 381.
Таблица 381
Пример:
<Bundle xmlns="/template/go.php?url=https://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="/template/go.php?url=https://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.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.1 Область применения и использования
Ресурс CodeSystem описывает систему кодирования - справочник или классификатор, в том числе иерархический или фасетный.
15.1.2.2 Структура ресурса
Ресурс CodeSystem является детализацией абстрактного ресурса DomainResource. Состав элементов ресурса CodeSystem представлен на рисунке 85 и в таблице 382.
![]() Таблица 382
15.1.2.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 383.
Таблица 383
15.1.2.4 Ограничения ресурса CodeSystem
Ограничения ресурса CodeSystem описаны в таблице 384.
Таблица 384
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
15.1.2.11 Определения стандартных свойств
Для гармонизации систем кодирования рекомендуется использовать стандартные свойства понятий, определенные в системе кодирования /template/go.php?url=https://hl7.org/fhir/concept-properties (таблица 386).
Таблица 386
Свойства с идентификаторами /template/go.php?url=https://hl7.org/fhir/concept-properties#parent и /template/go.php?url=https://hl7.org/fhir/concept-properties#child используются для указания отношение родитель/потомок между понятиями.
15.1.2.12 Статус системы кодирования
Статус системы кодирования характеризует состояние ее жизненного цикла. Допустимые значения статуса приведены в таблице 387.
Таблица 387
15.1.2.13 Иерархии понятий
Система кодирования может иметь иерархическую структуру, используя вложенные элементы concept. Значение отношений иерархии в этом случае определяется элементом hierarchyMeaning. В такой структуре у каждого понятия имеется только один родитель.
В некоторых системах кодирования понятия могут иметь несколько родителей. В этих случаях вместо вложенных элементов concept надо использовать дополнительные свойства property понятий, содержащие ссылки на родительские коды. Можно также воспроизвести основную иерархию с помощью вложения элементов concept, а дополнительные связи обеспечить с помощью свойств property.
15.1.2.14 Параметры поиска экземпляров ресурса CodeSystem
Специальные параметры поиска экземпляров ресурса CodeSystem описаны в таблице 388. В дополнение к ним могут использоваться общие параметры поиска, описанные в подразделе 12.27.
Таблица 388
15.2.1 Общие требования
Кодированные значения элемента ресурса могут быть ограничены набором значений, принадлежащих одной или нескольким системам кодирования. Например, значения элемента type ресурса Device, описывающего тип персонального медицинского прибора, могут быть ограничены релевантным подмножеством кодов номенклатуры MDC, описанной в ГОСТ Р 56842.
Наборы значений применяются для валидации содержания экземпляра ресурса при его создании или изменении и для представления списков допустимых значений в интерфейсе пользователя. Идентификаторы url наборов значений никогда не передаются в качестве компонентов system кодированных значений - в этих компонентах могут быть указаны только идентификаторы url систем кодирования. Привязка кодированного элемента ресурса к набору значений задается в экземпляре ресурса StructureDefinition, описывающем структуру ресурса или комплексного типа данных.
Формальное описание набора значений представляется экземпляром ресурса 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.
![]() Таблица 389
15.2.2.3 Привязки к наборам значений
Привязки к наборам значений описаны в таблице 390.
Таблица 390
15.2.2.4 Ограничения ресурса ValueSet
Ограничения ресурса ValueSet приведены в таблице 391.
Таблица 391
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
Аутентификация персональных медицинских приборы осуществляется менеджерами ПМП и шлюзами Интернета вещей в соответствии с используемыми протоколами передачи данных, например, 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].
(справочное)
А.1 Общие сведения
При разработке типов данных и ресурсов на языке UML используется профиль, состав которого показан на рисунке А.1.
![]() Профиль UML состоит из стереотипов, перечисленных в таблице А.1.
Таблица А.1
Стереотип Binding описывает привязку элемента к набору значений. Его атрибуты приведены в таблице А.2.
Таблица А.2
Стереотип Constraint описывает ограничение элемента или класса. Его атрибуты приведены в таблице А.3. В списках в качестве разделителей используется символ вертикальной черты (|).
Таблица А.3
Стереотип Extension описывает метаданные расширения элемента, класса или типа данных. Его атрибуты приведены в таблице А.4.
Таблица А.4
Стереотип Interface указывает, что данный тип ресурса REST является интерфейсом.
Стереотип Modifying указывает, что значение элемента может изменять семантику экземпляра ресурса. Его атрибуты приведены в таблице А.5.
Таблица А.5
Стереотип Profile указывает, что данный класс является профилем ресурса REST или другого профиля. Его атрибуты приведены в таблице А.6.
Таблица А.6
Стереотип RefTarget описывает допустимые типы ссылочных ресурсов. Его атрибуты приведены в таблице А.7. В списке в качестве разделителей используется символ вертикальной черты (|).
Таблица А.7
Стереотип Resource указывает, что данный класс является основным в определении типа ресурса. Его атрибуты приведены в таблице А.8.
Таблица А.8
Стереотип Slice указывает, что коллекция экземпляров данного элемента разбивается на непересекающиеся подмножества. Его атрибуты приведены в таблице А.9.
Таблица А.9
Стереотип TypeChoice описывает допустимые типы данных полиморфного элемента. Его атрибуты приведены в таблице А.10. В списке в качестве разделителей используется символ вертикальной черты (|).
Таблица А.10
(справочное)
ПРИМЕР ПЛАНА ДИСТАНЦИОННОГО МОНИТОРИНГА
Б.1 Текстовое содержание плана для представления пациенту
Целевой уровень домашнего артериального давления:
- систолическое от 100 до 140;
- диастолическое от 60 до 90.
Лечение препаратом индапамид + рамиприл (0.625 мг + 2.5 мг), торговое наименование Консилар-Д24, один раз в день, предпочтительно утром. Капсулы необходимо проглатывать целиком и запивать достаточным количеством воды.
Ограничение потребления поваренной соли до 6 г/сут.
Аэробные нагрузки два раза в день по 30 мин.
Этапный эпикриз через две недели.
Измерение артериального давления 2 раза в день.
Ведение дневника приема лекарств.
Ведение дневника физической активности.
Для выполнения плана пациенту выдан тонометр ГемоДин-АКСМА (серийный номер 1234567).
Б.2 Структурированное содержание плана
Структурированное содержание плана дистанционного мониторинга включает в себя экземпляры ресурсов, перечисленные в таблице Б.1
Таблица Б.1
дистанционного мониторинга
Между экземплярами ресурсов установлены ссылки, показанные на рисунке Б.2. Тем самым образован граф примера плана дистанционного мониторинга. Наличие ссылок позволяет сократить число запросов HTTP GET, необходимых для считывания полного содержания плана, с помощью использования параметров управления результатами поиска _include и _revinclude.
![]() Б.3 Транзакция создания плана
Тело транзакции создания плана представляет собой контейнер Bundle типа transaction, в который вложены экземпляры ресурсов, перечисленные в таблице Б.1 Для каждого экземпляра указан метод создания HTTP POST и условие создания ifNoneExist, согласно которому экземпляр создается только в том случае, если на сервере отсутствует экземпляр с таким же идентификатором identifier.
Чтобы можно было воспользоваться параметрами управления результатами поиска _include и _revinclude и в то же время осуществлять поиск по идентификаторам identifier, каждая ссылка между экземплярами ресурсов имеет следующий вид:
<reference value=полный URL ссылочного экземпляра ресурса/>
<type value=тип ссылочного ресурса/>
<identifier>
<system value=схема идентификации/>
<value value=значение идентификатора/>
</identifier>
Тело транзакции представлено на языке XML, чтобы можно было включить в него комментарии. При создании экземпляров ресурсов комментарии не сохраняются.
При проверке примера валидатором /template/go.php?url=https://validator.fhir.org/ будут выданы ошибки и предупреждения. Ошибками помечены элементы profile, например, <profile value="Device-Phg"/>. Это связано с тем, что значение профиля должно представлять собой абсолютный URL, но указать базовый URL, который должен предшествовать имени профиля, в настоящем документе не представляется возможным - он должен вести на конкретную страницу платформы медицинских помощников. Большинство предупреждений связано с тем, что в кодируемых значениях указан компонент system, идентифицирующий систему кодирования, не известную валидатору, например, /template/go.php?url=https://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers.
<?xml version="1.0" encoding="windows-1251"?>
<Bundle xmlns="/template/go.php?url=https://hl7.org/fhir" xmlns:xsi="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://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="ООО "АКСМА", г. Балашиха"/>
<!-- Серийный номер прибора. Возвращается прибором по запросу -->
<serialNumber value=
<!-- Модель прибора. Возвращается прибором по запросу -->
<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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://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=
</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="/template/go.php?url=https://loinc.org"/>
<code value=
</coding>
<!-- Код вида измерения в НСИ Минздрава России -->
<coding>
<system value="urn:oid:1.2.643.5.1.13.13.99.2.262"/>
<code value=
<display value=
</coding>
<text value=
</measure>
<!-- Целевой диапазон -->
<detailRange>
<!-- Нижняя граница -->
<low>
<value value="100"/>
<unit value="мм.рт.ст."/>
<system value="/template/go.php?url=https://unitsofmeasure.org"/>
<code value="mm[Hg]"/>
</low>
<!-- Верхняя граница -->
<high>
<value value="140"/>
<unit value="мм.рт.ст."/>
<system value="/template/go.php?url=https://unitsofmeasure.org"/>
<code value="mm[Hg]"/>
</high>
</detailRange>
</target>
<!-- Дата текущего состояния цели -->
<statusDate value=
</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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://unitsofmeasure.org"/>
<code value="mm[Hg]"/>
</low>
<!-- Верхняя граница -->
<high>
<value value="90"/>
<unit value="мм.рт.ст."/>
<system value="/template/go.php?url=https://unitsofmeasure.org"/>
<code value="mm[Hg]"/>
</high>
</detailRange>
</target>
<!-- Дата текущего состояния цели -->
<statusDate value=
</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="/template/go.php?url=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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://terminology.hl7.org/CodeSystem/observation-
category"/>
<code value="vital-signs"/>
</coding>
<text value="Жизненно важные показатели"/>
</category>
<!-- Вид измерения -->
<code>
<!-- Код измерения по LOINC -->
<coding>
<system value="/template/go.php?url=https://loinc.org"/>
<code value=
</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="/template/go.php?url=https://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="/template/go.php?url=https://terminology.hl7.org/CodeSystem/observation-
category"/>
<code value="vital-signs"/>
</coding>
<text value="Жизненно важные показатели"/>
</category>
<!-- Вид измерения -->
<code>
<!-- Код измерения по LOINC -->
<coding>
<system value="/template/go.php?url=https://loinc.org"/>
<code value=
</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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://www.whocc.no"/>
<code value=
</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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://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=
<code>
<!-- Код в справочнике типов мероприятий -->
<coding>
<system value="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://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="/template/go.php?url=https://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, см. /template/go.php?url=https://hl7.org/fhir/R4). В значительной мере это обусловлено тем, что офис национального координатора ONC (The Office of the National Coordinator for Health Information Technology) утвердил требование соответствия Руководству по базовой реализации в США (US Core Implementation Guide), основанное на FHIR R4, в программе сертификации медицинских информационных систем (/template/go.php?url=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, см. /template/go.php?url=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
В 3.2 Ресурс MessageHeader - заголовок сообщения
Изменения ресурса MessageHeader по сравнению с версиями R4 и R4B представлены в таблице В.2.
Таблица В.2
по сравнению с версиями R4 и R4B
В.3.3 Ресурс OperationOutcome - результат операции
Изменения ресурса OperationOutcome по сравнению с версиями R4 и R4B представлены в таблице В.3.
Таблица В.3
по сравнению с версиями R4 и R4B
В.3.4 Ресурс Parameters - параметры операции
Изменения ресурса Parameters по сравнению с версиями R4 и R4B представлены в таблице В.4.
Таблица В.4
по сравнению с версиями R4 и R4B
В.3.5 Ресурс Subscription - подписка
Изменения ресурса Subscription по сравнению с версиями R4 и R4B представлены в таблице В.5.
Таблица В.5
по сравнению с версиями R4 и R4B
В.3.6 Ресурс SubscriptionStatus - статус подписки
В R4 отсутствует.
В.3.7 Ресурс SubscriptionTopic - тема подписки
В R4 отсутствует.
В.3.8 Ресурс CarePlan - план ведения
Изменения ресурса CarePlan по сравнению с версиями R4 и R4B представлены в таблице В.6.
Таблица В.6
В.3.9 Профиль CarePlan-Dm
Изменения ресурса CarePlan, требующие учета при реализации профиля CarePlan-Dm, приведены в таблице В.7.
Таблица В.7
при реализации профиля CarePlan-Dm
В.3.10 Ресурс Goal - цель
Изменения ресурса Goal по сравнению с версиями R4 и R4B представлены в таблице В.8.
Таблица В.8
В.3.11 Профиль цели дистанционного мониторинга пациента Goal-Dm
Изменения ресурса Goal не требуют учета при реализации профиля CarePlan-Dm.
В.3.12 Ресурс ServiceRequest - назначение
Изменения ресурса ServiceRequest по сравнению с версиями R4 и R4B представлены в таблице В.9.
Таблица В.9
по сравнению с версиями R4 и R4B
В.3.13 Ресурс Task - мероприятие
Изменения ресурса Task по сравнению с версиями R4 и R4B представлены в таблице В.10.
Таблица В.10
В.3.14 Профиль Task-Medication
Изменения ресурса Task, требующие учета при реализации профиля Task-Medication, приведены в таблице В.11.
Таблица В.11
профиля Task-Medication
В.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
В.3.21 Профиль Device-Phd
Изменения ресурса Device, требующие учета при реализации профиля Device-Phd, приведены в таблице В.13.
Таблица В.13
при реализации профиля Device-Phd
В.3.22 Профиль Device-Phg
Изменения ресурса Device не требуют учета при реализации профиля Device-Phg.
В.3.23 DeviceAssociation - ассоциация медицинского изделия с субъектом
В R4 отсутствует.
В.3.24 Профиль DeviceAssociation-Dm
К R4 неприменим.
В.3.25 Ресурс DeviceMetric - измерительная способность медицинского прибора
Изменения ресурса DeviceMetric по сравнению с версиями R4 и R4B представлены в таблице В.14.
Таблица В.14
по сравнению с версиями R4 и R4B
В.3.26 Ресурс Observation - результат исследования
Изменения ресурса Observation по сравнению с версиями R4 и R4B представлены в таблице В.15.
Таблица В.15
по сравнению с версиями R4 и R4B
В.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
В.3.36 Профиль Patient-Dm
Изменения ресурса Patient не требуют учета при реализации профиля Patient-Dm.
В.3.37 Ресурс Practitioner - сведения о медицинском специалисте
Изменения ресурса Practitioner по сравнению с версиями R4 и R4B представлены в таблице В.17.
Таблица В.17
по сравнению с версиями R4 и R4B
В.3.38 Профиль Practitioner-Dm
Изменения ресурса Practitioner не требуют учета при реализации профиля Practitioner-Dm.
В.3.39 Ресурс DiagnosticReport - заключение врача
Изменения ресурса DiagnosticReport по сравнению с версиями R4 и R4B представлены в таблице В.18.
Таблица В.18
по сравнению с версиями R4 и R4B
В.3.40 Профиль DiagnosticReport-Dm
Изменения ресурса DiagnosticReport не требуют учета при реализации профиля DiagnosticReport-Dm.
В.3.41 Ресурс MedicationStatement - дневник приема лекарств
Изменения ресурса MedicationStatement по сравнению с версиями R4 и R4B представлены в таблице В.19.
Таблица В.19
по сравнению с версиями R4 и R4B
В.3.42 Ресурс QuestionnaireResponse - дневник самонаблюдения
Изменения ресурса QuestionnaireResponse по сравнению с версиями R4 и R4B представлены в таблице В.20.
Таблица В.20
по сравнению с версиями R4 и R4B
В.3.43 Ресурс Questionnaire - описание дневника самонаблюдения
Изменения ресурса Questionnaire по сравнению с версиями R4 и R4B представлены в таблице В.21.
Таблица В.21
по сравнению с версиями R4 и R4B
В.3.44 Ресурс NutritionIntake (дневник питания)
В R4 отсутствует.
В.3.45 Ресурс DetectedIssue - предупреждение
Изменения ресурса DetectedIssue по сравнению с версиями R4 и R4B представлены в таблице В.22.
Таблица В.22
по сравнению с версиями R4 и R4B
В.3.46 Профиль DetectedIssue-Dm
Изменения ресурса DetectedIssue, требующие учета при реализации профиля DetectedIssue-Dm, приведены в таблице В.23.
Таблица В.23
при реализации профиля Device-Phd
Вернуться в "Каталог нормативных документов"
Источник информации: https://internet-law.ru/documents/prod/pnst_predvaritelnyj-nacionalnyj-standart/1/pnst_79836.html
На правах рекламы:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||