ПНСТ 995-2024 Системы киберфизические. Персональные медицинские помощники. Форматы обмена данными. Общие требования

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

пнет

995— 2024

Системы киберфизические

ПЕРСОНАЛЬНЫЕ МЕДИЦИНСКИЕ ПОМОЩНИКИ

Форматы обмена данными.

Общие требования

Издание официальное

Москва Российский институт стандартизации 2025

ПНСТ 995—2024

Предисловие

1 РАЗРАБОТАН Фондом «Технопарк Академгородка» (ИЦ НТИ Хелснет)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 194 «Кибер-физические системы»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 27 декабря 2024 г. № 126-пнст

Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТР 1.16—2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 630090 г. Новосибирск, ул. Николаева, 12, и/или в Федеральное агентство по техническому регулированию и метрологии по адресу: 123112 Москва, Пресненская набережная, д. 10, стр. 2.

В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе «Национальные стандарты» и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

© Оформление. ФГБУ «Институт стандартизации», 2025

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

II

ПНСТ 995—2024

Содержание

1 Область применения..................................................................1

2 Нормативные ссылки..................................................................2

3 Термины и определения................................................................2

4 Обозначения и сокращения.............................................................3

5 Форматы обмена данными с персональными медицинскими приборами........................5

6 Форматы обмена данными с сервисом хранения и обработки результатов измерений.............5

6.1 Общие требования.................................................................5

6.2 Требования к модели данных в формате взаимодействия.................................6

7 Метамодель данных хранилища результатов измерений....................................10

7.1 Источник.........................................................................10

7.2 Верхний уровень..................................................................10

7.3 Ресурсы данных...................................................................11

7.4 Типы данных.....................................................................13

7.5 Терминологические ресурсы........................................................15

7.6 REST API........................................................................16

8 Компоненты модели данных хранилища результатов измерений.............................17

8.1 Правила именования...............................................................17

8.2 Способы описания.................................................................18

9 Типы данных........................................................................19

9.1 Общие сведения..................................................................19

9.2 Простые типы данных..............................................................19

9.3 Комплексные типы данных общего назначения.........................................32

9.4 Специальные типы данных..........................................................57

9.5 Типы метаданных..................................................................84

10 Ресурсы REST......................................................................97

10.1 Общие сведения.................................................................97

10.2 Базисные ресурсы................................................................99

10.3 Ресурсы общего назначения.......................................................104

11 Модель данных хранилища результатов измерений......................................135

11.1 Состав данных хранилища результатов измерений....................................135

11.2 Ресурс CarePlan — план дистанционного мониторинга пациента.........................144

11.3 Ресурс Goal — цель..............................................................151

11.4 Ресурс ServiceRequest — назначение...............................................155

11.5 Ресурс Task — мероприятие.......................................................161

11.6 Ресурс Subscription — подписка на изменения экземпляров ресурсов.....................174

11.7 Ресурс Device — сведения о медицинском изделии....................................177

11.8 Ресурс DeviceAssociation — ассоциация медицинского изделия с пациентом...............189

11.9 Ресурс DeviceDefinition — описание медицинского изделия.............................192

11.10 Ресурс DeviceMetric — измерительная способность медицинского прибора...............199

11.11 Ресурс Observation — результат исследования.......................................201

11.12 Ресурс Patient — сведения о пациенте.............................................241

11.13 Ресурс Practitioner — сведения о медицинском специалисте...........................245

11.14 Ресурс DiagnosticReport — заключение врача.......................................249

11.15 Ресурс Medicationstatement — дневник приема лекарств..............................254

11.16 Ресурс QuestionnaireResponse — дневник самонаблюдения...........................258

11.17 Ресурс Questionnaire — описание дневника самонаблюдения..........................262

11.18 Ресурс Nutritionintake (дневник питания)............................................271

11.19 Ресурс Detectedlssue — предупреждение...........................................275

12 REST API и поиск..................................................................279

12.1 Общие сведения................................................................279

12.2 Взаимодействия.................................................................280

12.3 Метаданные и версионность ресурсов..............................................281

12.4 Коды статуса HTTP..............................................................281

12.5 Заголовки HTTP.................................................................281

III

ПНСТ 995—2024

12.6 Управление содержанием ответа...................................................282

12.7 Типы содержания и кодировки.....................................................282

12.8 Общие параметры...............................................................282

12.9 Поддержка версионности.........................................................283

12.10 Часовой пояс клиента...........................................................283

12.11 Взаимодействие чтения read.....................................................283

12.12 Взаимодействие чтения версии vread..............................................283

12.13 Взаимодействия изменения update................................................284

12.14 Взаимодействие исправления patch...............................................286

12.15 Взаимодействие удаления delete..................................................286

12.16 Взаимодействие создания create..................................................287

12.17 Взаимодействие поиска search...................................................289

12.18 Взаимодействие описания возможностей capabilities.................................290

12.19 Взаимодействие транзакции transaction............................................291

12.20 Взаимодействие истории history...................................................293

12.21 Транзакционная целостность.....................................................294

12.22 Постраничный вывод............................................................295

12.23 Нестандартные заголовки........................................................296

12.24 Сводная информация...........................................................297

12.25 Шаблон асинхронных запросов...................................................299

12.26 Обработка запросов поиска......................................................300

12.27 Простые варианты поиска.......................................................310

12.28 Обработка ошибок..............................................................313

12.29 Неподдерживаемые параметры...................................................313

12.30 Стандартные параметры.........................................................313

12.31 Управление результатами запроса.................................................314

12.32 Соответствие результата запросу.................................................317

12.33 Именованный поиск.............................................................318

12.34 Актуальность результатов запроса................................................319

12.35 Отображение типов данных на типы параметров.....................................319

12.36 Транзакции....................................................................320

12.37 Сообщения с запросами поиска...................................................321

13 Операции.........................................................................321

13.1 Общие требования..............................................................321

13.2 Выполнение операции............................................................322

13.3 Операции без параметров........................................................323

13.4 Определение операции...........................................................323

13.5 Синхронное выполнение операции.................................................323

13.6 Результат выполнения операции...................................................324

13.7 Асинхронное выполнение операции................................................324

13.8 Операции с системами кодирования................................................325

13.9 Операции с наборами значений....................................................333

14 Обмен сообщениями...............................................................342

14.1 Основные положения............................................................342

14.2 Механизмы передачи сообщений..................................................343

14.3 Воздействие сообщения..........................................................343

14.4 Влияние на получателей..........................................................343

14.5 Шаблоны обмена сообщениями....................................................344

14.6 Синхронное взаимодействие......................................................344

14.7 Асинхронное взаимодействие.....................................................344

14.8 Идентификаторы и штампы времени в заголовке сообщения...........................345

14.9 Отсутствие надежного транспорта сообщений........................................345

14.10 Вызов операций над ресурсами с помощью сообщений...............................346

14.11 Осуществление поиска с помощью сообщений......................................347

15 Терминологические ресурсы.........................................................348

15.1 Системы кодирования............................................................348

IV

ПНСТ 995—2024

15.2 Наборы значений................................................................359

16 Аутентификация и авторизация......................................................371

Приложение А (справочное) Профиль UML...............................................372

Приложение Б (справочное) Пример плана дистанционного мониторинга......................376

Приложение В (справочное) Сопоставление стандарта с HL7 FHIR R4.........................402

Библиография.......................................................................414

V

ПНСТ 995—2024

Введение

Актуальность настоящего стандарта связана с постоянно расширяющейся практикой дистанционного мониторинга лечащими врачами пациентов с различными хроническими заболеваниями, а также проходящими длительное амбулаторное лечение или нуждающимися в постоянном наблюдении (беременные, дети, пожилые граждане, инвалиды), реабилитации и информационной поддержке для поддержания здоровья, ведения здорового или рекомендованного образа жизни. Учитывая современные тенденции развития общества, технологий и здравоохранения, сегмент дистанционного мониторинга пациентов их лечащими врачами будет постоянно расти опережающими темпами относительно других технологий здравоохранения. Сегодня технологии дистанционного контроля, ведения и информационной поддержки пациентов находятся в зачаточном состоянии, равно как и рынок медицинских устройств, позволяющих пациентам самостоятельно измерять необходимые физиологические показатели и оперативно предоставлять к ним доступ врачам и системе здравоохранения. Кроме того, развитию систем дистанционного мониторинга здоровья препятствуют многие организационные и финансовые барьеры, однако в 2022 году в Российской Федерации стартовал масштабный проект «Персональные медицинские помощники», поставивший амбициозную цель — к 2030 году обеспечить услугами дистанционного мониторинга 20 % населения России. В настоящий момент в пилотный проект по «Персональным медицинским помощникам» вошли только две нозологии: артериальная гипертензия и диабет. А его основной целью является оперативная доставка в медорганизацию показателей артериального давления и глюкозы крови, самостоятельно измеренной пациентом. Однако сама масштабность принятого проекта, а также быстрое развитие рынка медицинских устройств для персонального использования, позволяющих пациентам измерять различные показатели своего организма, являются очевидным предвестником расширения сферы применения «Персональных медицинских помощников».

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

Настоящий стандарт описывает форматы обмена данными в экосистеме «Персональных медицинских помощников» и охватывает широкий круг дистанционных взаимодействий между пациентом и его лечащим врачом. Предложенные в нем форматы и процедуры информационного обмена должны обеспечить не только сегодняшний (пилотный) этап функционирования «Персональных медицинских помощников», но и перспективное развитие и распространение их действия на другие нозологии и клинические ситуации, подключение широкого круга персональных медицинских устройств, появляющихся на рынке, а также расширение спектра информационных взаимодействий врача и пациента.

Стандарт разработан на основе анализа зарубежного и отечественного опыта и базируется на существующих международных стандартах и иных документах, описывающих взаимодействие в указанной сфере.

Стандарт будет полезен как разработчикам информационных систем и платформ, реализующих различные составляющие «Персональных медицинских помощников», так и производителям персональных медицинских устройств, позволяя бесшовно включать их разработки в экосистему дистанционного мониторинга здоровья.

VI

ПНСТ 995—2024

ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Системы киберфизические

ПЕРСОНАЛЬНЫЕ МЕДИЦИНСКИЕ ПОМОЩНИКИ

Форматы обмена данными. Общие требования

Cyberphysical systems. Personal health assistants. Data exchange formats. General requirements

Срок действия — с 2025—02—01 до 2028—02—01

1 Область применения

Настоящий стандарт устанавливает общие требования к форматам обмена данными в коммуникационной инфраструктуре персональных медицинских помощников, обеспечивающей дистанционный мониторинг состояния здоровья пациентов — пользователей персональных медицинских приборов, включающей в себя персональные медицинские приборы, менеджеры персональных медицинских приборов и шлюзы Интернета вещей, сервисы хранения и обработки результатов измерений, медицинские информационные системы и обеспечивающей дистанционный мониторинг состояния здоровья пациентов — пользователей персональных медицинских приборов (рисунок 1).

Рисунок 1 — Коммуникационная инфраструктура персональных медицинских помощников

В качестве менеджеров персональных медицинских приборов могут выступать мобильные приложения, программное обеспечение персональных компьютеров, микропрограммы специализированных

Издание официальное

1

ПНСТ 995—2024

шлюзов (например, коммутаторов ЛВС). В качестве интерфейсов персональных/локальных вычислительных сетей (ПВС/ЛВС) чаще всего используются проводные интерфейсы Ethernet, USB и беспроводные интерфейсы WiFi, IrDA, Bluetooth, Bluetooth LE, Zigbee, NFC, а также российские стандартизованные протоколы для интернета вещей: NB-Fi, LoraWAN Ru, OpenUNB, NB-loT. Сервис хранения и обработки результатов измерений может быть реализован в составе медицинской информационной системы или как отдельная платформа персональных медицинских помощников.

Требования стандарта распространяются на форматы обмена данными при следующих информационных взаимодействиях:

а) между персональным медицинским прибором и шлюзом Интернета вещей или менеджером персональных медицинских приборов;

б) между шлюзом Интернета вещей и сервисом хранения и обработки результатов измерений;

в) между менеджером персонального медицинского прибора и сервисом хранения и обработки результатов измерений;

г) между медицинской информационной системой и сервисом хранения и обработки результатов измерений.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие документы:

ГОСТ 7.67 Система стандартов по информации, библиотечному и издательскому делу. Коды названий стран

ГОСТ Р 7.0.64 (ИСО 8601:2004) Система стандартов по информации, библиотечному и издательскому делу. Представление дат и времени. Общие требования

ГОСТ Р 34.11 Информационная технология. Криптографическая защита информации. Функция хэширования

ГОСТ Р ИСО/МЭК 7498-1 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель

ГОСТ Р ИСО/МЭК 8824-1 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации

ГОСТ Р ИСО/МЭК 9834-1 Информационная технология. Взаимосвязь открытых систем. Процедуры действий уполномоченных по регистрации ВОС. Часть 1. Общие процедуры и верхние дуги дерева идентификатора объекта АСН.1

ГОСТ Р ИСО/МЭК 9834-8 Информационная технология. Взаимосвязь открытых систем. Процедуры работы уполномоченных по регистрации ВОС. Часть 8. Создание, регистрация универсально уникальных идентификаторов (УУИд) и их использование в качестве компонентов идентификатора объекта АСН.1

ГОСТ Р 56842/ISO/IEEE 11073-10101:2004 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10101. Номенклатура

ГОСТ Р 56845/ISO/IEEE 11073-20601:2016 Информатизация здоровья. Обмен данными с персональными медицинскими приборами. Часть 20601. Прикладной профиль. Оптимизированный протокол обмена

ОКВ ОК (МК (ИСО 4217) 003-97) 014 Общероссийский классификатор валют

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется принять в части, не затрагивающей эту ссылку.

2

ПНСТ 995—2024

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 персональные медицинские помощники: Комплексная система, включающая программные и технические средства для обеспечения дистанционного наблюдения за состоянием здоровья пациента, в том числе платформу, медицинские изделия с функцией дистанционной передачи данных, а также устройства, предназначенные для регистрации параметров состояния здоровья человека (вместе — медицинские приборы), и информационные системы, предназначенные для дистанционного наблюдения за состоянием здоровья пациентов.

3.2

медицинский прибор (medical device): Прибор (аппаратура или система приборов), используемый для мониторинга состояния, выполнения процедур или терапии пациента и обычно не оказывающий влияние на процессы метаболизма.

[ГОСТ Р 56843—2015/ISO/IEEE 11073-10201:2004, пункт 3.36]

3.3

персональный медицинский прибор (personal health device): Прибор, используемый для личного медицинского применения.

[ГОСТ Р 56845—2019/ISO/IEEE 11073-20601:2016, пункт 3.1.13]

3.4

Интернет вещей; loT (Internet of Things): Инфраструктура взаимосвязанных сущностей, систем и информационных ресурсов, а также служб, позволяющих обрабатывать информацию о физическом и виртуальном мире и реагировать на нее.

[ГОСТ Р 71777—2024 (ИСО/МЭК 20924:2024), статья 3.13]

_

менеджер (manager): Узел, получающий данные от одного или нескольких персональных медицинских приборов по локальной или персональной вычислительной сети.

[Адаптировано из ГОСТ Р 56845—2019/ISO/IEEE 11073-20601:2016, пункт 3.1.9]________________

3.6 шлюз Интернета вещей: Узел, получающий данные от одного или нескольких персональных медицинских приборов по протоколу Интернета вещей.

4 Обозначения и сокращения

з

ПНСТ 995—2024

4

ПНСТ 995—2024

5 Форматы обмена данными с персональными медицинскими приборами

Форматы обмена данными между персональным медицинским прибором (ПМП) и шлюзом Интернета вещей или менеджером персональных медицинских приборов (далее — менеджер ПМП или менеджер) регламентируются на прикладном уровне модели взаимосвязи открытых систем (см. ГОСТ Р ИСО/МЭК 7498-1). Общие требования к этим форматам установлены в стандарте ГОСТ Р 56845. Для ряда специализаций персональных медицинских приборов эти требования конкретизированы в [1]—[21].

В состав форматов обмена данными входят элементы с кодируемыми значениями. В качестве системы кодирования этих значений следует использовать номенклатуру коммуникаций с медицинскими приборами MDC, определенную в ГОСТ Р 56842. Стандарты специализаций приборов содержат дополнения к этой номенклатуре.

Если персональный медицинский прибор не поддерживает обмен данными в соответствии с ГОСТ Р 56845, то рекомендуется обеспечить преобразование его данных в форматы, предусмотренные ГОСТ Р 56845 и ГОСТ Р 56842. Такое преобразование может быть выполнено с помощью специализированного модуля в составе программного обеспечения менеджера ПМП или шлюза Интернета вещей.

6 Форматы обмена данными с сервисом хранения и обработки результатов измерений

6.1 Общие требования

Взаимодействия с сервисом хранения и обработки результатов измерений описаны на уровне архитектурного стиля REST с использованием протокола HTTP. В основу требований к этим взаимодействиям положена спецификация FHIR — ресурсы быстрой интероперабельности в здравоохранении версии 5.0 [22], разработанная организацией HL7. Эта спецификация предоставляется по лицензии Creative Commons «No Rights Reserved» [23], то есть без сохранения прав. Ограничения накладываются только на использование товарных знаков HL7® и FHIR®.

Настоящий стандарт не противоречит спецификации [22], и предложенные в нем форматы обмена могут быть реализованы с помощью свободно распространяемого программного обеспечения HAPI FHIR [24].

5

ПНСТ 995—2024

Примечание — Применение других версий спецификации FHIR, а также набора используемых ресурсов допустимо для существующих информационных систем в ПМП при наличии опубликованных интеграционных профилей (документов, регламентирующих порядок взаимодействия и описание ресурсов).

6.2 Требования к модели данных в форматах взаимодействия

Сервис хранения и обработки результатов измерений получает и предоставляет данные с помощью запросов HTTP в архитектурном стиле REST. Эти данные поступают в хранилище результатов измерений. Модель данных хранилища результатов измерений описана в терминах ресурсов данных и их профилей.

Выбор типов ресурсов данных определен исходя из следующего сценария:

а) основным назначением сервиса хранения и обработки результатов измерений (далее — сервис) является обеспечение информационного взаимодействия между пациентом и лечащим врачом в процессе дистанционного мониторинга;

б) для взаимодействия пациент использует персональные медицинские приборы и менеджеры этих приборов (в качестве менеджеров могут выступать смартфоны, планшеты, персональные компьютеры, облачные решения и шлюзы Интернета вещей), а врач использует рабочее место МИС;

в) дистанционный мониторинг осуществляется в соответствии с планом ведения, назначенным лечащим врачом;

г) план ведения ограничен следующими мероприятиями:

1) сбор результатов измерений, выполняемых ПМП,

2) ведение дневников питания, самонаблюдений, приема лекарств,

3) передача пациенту этапного эпикриза в процессе выполнения плана ведения и по его завершении;

д) в процессе выполнения плана пациенту и лечащему врачу могут выдаваться предупреждения и напоминания, например предупреждения об аномальном результате измерений или напоминания о необходимости приема лекарственного препарата;

е) состав информации, передаваемый сервису хранения и обработки результатов измерений, должен быть минимально достаточным для взаимодействия пациента с лечащим врачом в рамках назначенного плана ведения.

Концептуальная диаграмма хореографии данного сценария показана на рисунке 2.

6

ПНСТ 995—2024

V

Рисунок 2 — Диаграмма хореографии сценария взаимодействия

Взаимодействие менеджера ПМП с сервисом может осуществляться не только по подписке, например, с помощью запросов на получение данных, передаваемых сервису по расписанию.

МИС передает сервису запросы на регистрацию подписки участникам взаимодействия (рисунок 3), а затем отправляет сервису план ведения дистанционного мониторинга, который по подписке доставляется менеджеру ПМП (рисунок 4). Взаимодействие участников при выполнении плана ведения показано на рисунке 5.

7

ПНСТ 995—2024

Рисунок 3 — Регистрация подписок

8

Рисунок 4 — Назначение плана ведения

ПНСТ 995—2024

Рисунок 5 — Выполнение плана ведения

ПМП выполняет измерение и передает полученный результат менеджеру ПМП или шлюзу Интернета вещей, который преобразует результат в формат REST API и передает его сервису. Преобразованный результат по подписке или по запросу доставляется МИС. Если результат выходит за пределы целевого диапазона, указанного в плане ведения, то МИС передает сервису соответствующее предупреждение, которое по подписке доставляется менеджеру ПМП и затем пациенту. По событию, предусмотренному в плане ведения, например, по завершению плана ведения или по истечению определенного срока, в МИС формируется этапный эпикриз, который может быть передан сервису и в соответствии с порядком взаимодействия доставляется менеджеру ПМП и затем пациенту.

В процессе выполнения план может быть скорректирован (рисунок 6).

9

ПНСТ 995—2024

Менеджер ПМП

Получена коррекция

Рисунок 6 — Коррекция плана ведения

При реализации этой схемы должна быть использована машина рабочих процессов, контролирующая выполнение мероприятий, назначенных в плане ведения, и инициирующая передачу менеджеру ПМП (а через него пациенту) соответствующих предупреждений и напоминаний. Такая машина может быть развернута в менеджере ПМП, в сервисе, в МИС или в облачном решении. Размещение машины рабочих процессов и взаимодействие с ней не входит в область применения настоящего стандарта.

Персональный медицинский прибор может быть связан с менеджером ПМП, и в этом случае менеджер будет осуществлять преобразование результата измерений в формат REST API и передачу преобразованного результата сервису хранения результатов измерений.

Предупреждение об аномальном результате измерений или ином событии, требующем реакции от пациента, может формироваться автоматически, например, при получении от ПМП статуса ошибки позиционирования датчика, или с участием медицинского работника. Эти детали информационного взаимодействия влияют на содержание передаваемых данных и события передачи, но используемые типы ресурсов могут оставаться теми же самыми.

Для большей части выбранных типов ресурсов рекомендованы профили, которые могут быть доработаны с учетом особенностей реализации сервиса хранения и обработки результатов измерений и потенциального расширения специализаций персональных медицинских приборов и их функций. В связи с этим для выбранных типов ресурсов даются полные описания, которые могут быть использованы для решения более широких задач, и на основе этих описаний предлагаются профили, специфичные для задачи дистанционного мониторинга.

7 Метамодель данных хранилища результатов измерений

7.1 Источник

Метамодель данных хранилища результатов измерений основана на спецификации [22].

7.2 Верхний уровень

Верхний уровень метамодели данных хранилища результатов измерений показан на рисунке 7.

10

ПНСТ 995—2024

Терминологические ресурсы

§ +Набор значений

@ + Система кодирования

«use»

Рисунок 7 — Верхний уровень метамодели данных хранилища результатов измерений

Он представлен следующими пакетами сущностей:

а) ресурсы данных — ресурсы REST, с помощью которых хранилище импортирует и экспортирует результаты измерений;

б) терминологические ресурсы — коллекции кодируемых понятий, представленные в форме систем кодирования и наборов значений;

в) типы данных — простые и комплексные типы данных, используемые при описании элементов ресурсов данных;

г) Rest API — операции над экземплярами ресурсов данных.

7.3 Ресурсы данных

При описании ресурсов данных используются сущности, представленные на рисунке 8.

11

ПНСТ 995—2024

class Ресурсы данных

Рисунок 8 — Описание ресурсов данных

Центральной сущностью является ресурс. Экземпляр ресурса представляет собой информационный объект, обладающий следующими свойствами:

а) имеет определенную идентификацию, по которой его можно адресовать в информационных ресурсах;

б) имеет один из типов, определенных в информационной модели предметной области;

в) содержит совокупность структурированных элементов данных, описанных в определении типа ресурса;

г) имеет определенную версию, которая изменяется при изменении экземпляра ресурса;

д) имеет несколько представлений (XML, JSON).

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

На элементы ресурса могут быть наложены ограничения. Каждое ограничение имеет:

а) уникальный идентификатор;

б) степень строгости (является ли нарушение ограничения ошибкой или предупреждением);

в) место применения ограничения (путь в описании структуры типа ресурса);

г) человеко-читаемое описание;

д) логическое выражение на формальном языке, которое должно быть истинным при выполнении ограничения (инвариант).

Специфическим видом ограничения является привязка элемента с кодированным значением к конкретному набору значений.

Для каждого типа ресурсов (не являющегося абстрактным) задаются параметры поиска его экземпляров. Определение параметра имеет следующие элементы:

а) имя параметра;

б) тип значения параметра;

в) человеко-читаемое описание;

г) индексное выражение.

Определение типа ресурса является рамочным и рассчитано на использование в различном контексте. Для конкретной предметной области обычно требуется адаптировать его определение, в том числе:

а) описать правила использования или неиспользования элементов ресурса;

12

ПНСТ 995—2024

б) добавить элементы, не предусмотренные в определении типа ресурса;

в) указать или изменить терминологические ресурсы, которые могут использоваться для элементов с кодированными значениями.

Такая адаптация называется профилем. Профиль может быть основан на типе ресурса или на другом профиле.

Типы ресурсов, используемые в хранилище результатов измерений, описаны в разделе 11.

7.4 Типы данных

Все типы данных являются потомками абстрактного типа Element. Простые типы данных являются потомками абстрактного типа PrimitiveType, а комплексные — потомками абстрактного типа DataType. В свою очередь комплексные типы данных подразделяются на комплексные типы данных общего назначения, специальные комплексные типы и типы метаданных. Комплексные типы данных могут иметь компоненты простого или комплексного типа общим числом не менее двух (рисунок 9).

Рисунок 9 —Типы данных

Тип Element является базовым для всех сущностей модели данных — типов данных, типов ресурсов, вспомогательных классов. Общие сведения о типе Element приведены в таблице 1, а состав элементов — в таблице 2.

К типу Element применяется ограничение, приведенное в таблице 3. Оно означает, что значение элемента экземпляра ресурса может отсутствовать только в том случае, если у него есть одно или несколько расширений. Пустой элемент должен исключаться из экземпляра ресурса.

13

ПНСТ 995—2024

Таблица 1 —Общие сведения о типе Element

Таблица 2 — Состав элементов типа Element

Таблица 3 — Ограничение типа Element

Идентификатор 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) positivelnt;

15) string;

16) time;

17) unsignedlnt;

18) uri;

19) url;

20) uuid;

б) комплексные типы данных общего назначения:

14

ПНСТ 995—2024

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.

Имя такого элемента заканчивается символами «[х]», вместо которых в конкретном экземпляре ресурса подставляется имя типа данных, у которого первый символ переведен в верхний регистр, например, value[x] может быть заменено на valuestring, и этот вариант элемента value будет иметь тип данных string.

В других случаях допускается только ограниченное подмножество типов данных из приведенного выше списка. В табличном представлении допустимые типы данных перечислены в описании, а в UML-представлении они перечислены в атрибуте стереотипа TypeChoice.

Детальное описание типов данных приведено в разделе 9.

7.5 Терминологические ресурсы

Терминологические ресурсы подразделяются на системы кодирования и наборы значений (рисунок 10). Система кодирования описывает коллекцию кодированных понятий (справочник, классификатор). Каждое понятие имеет код, значение, определение и может иметь дополнительные свойства. Набор значений представляет собой объединение подмножеств, взятых из системы кодирования и других наборов значений. Правила формирования этих подмножеств сформулированы с помощью определения. Для получения полного списка понятий, описываемого набором значений, используется операция $expand (раскрыть).

15

ПНСТ 995—2024

Рисунок 10 — Терминологические ресурсы

Система кодирования описана в форме экземпляра ресурса CodeSystem (пункт 15.1.2), набор значений — в форме экземпляра ресурса ValueSet (пункт 15.2.2).

7.6 REST API

Прикладной программный интерфейс (Application Program Interface) хранилища результатов измерений предоставляет методы, приведенные на рисунке 11.

«utility»

Создать

«utility»

Заменить

«utility»

Исправить

«utility»

Прочитать

«utility»

Получить историю

«utility» Найти

«utility»

Удалить

«utility» Выполнить

операцию

«utility» Выполнить

транзакцию

Рисунок 11 — REST API

Метод Создать используется для создания нового экземпляра ресурса заданного типа. Он вызывается с помощью метода HTTP POST, например POST https://example.com/base/{TnnPecypca}.

Метод Заменить используется для замены всего содержания существующего экземпляра ресурса. Он вызывается с помощью метода HTTP PUT, например PUT https://example.com/base/{TnnPecypca}/ {id}, где id — уникальный логический идентификатор экземпляра ресурса.

Метод Исправить используется для изменения части содержания существующего экземпляра ресурса. Он вызывается с помощью метода HTTP PATCH, например PATCH https://example.com/base/ {™nPecypca}/{id}, где id — уникальный логический идентификатор экземпляра ресурса.

Метод Получить историю используется для получения истории изменения содержания экземпляра ресурса. Он вызывается с помощью метода HTTP GET, например GET https://example.com/base/ {TnnPecypca}/{id}/_history, где id — уникальный логический идентификатор экземпляра ресурса.

16

ПНСТ 995—2024

Метод Прочитать используется для получения текущего содержания экземпляра ресурса. Он вызывается с помощью метода HTTP GET, например GET https://example.com/base/{TnnPecypca}/{id}, где id — логический уникальный идентификатор экземпляра ресурса.

Метод Найти используется для поиска экземпляров ресурсов, удовлетворяющих заданным критериям. Он вызывается с помощью метода HTTP GET например GET https://example.com/base/ {типРесурса}?параметры_поиска....

Метод Вызвать операцию используется для применения операции к содержанию экземпляра ресурса. Он вызывается с помощью метода HTTP GET например https://example.com/base/{TnnPecypca}/ {1Ь}/${имяОперации}.

Метод Выполнить транзакцию используется для согласованного выполнения других методов над несколькими экземплярами ресурсов в одной транзакции. Он вызывается с помощью метода HTTP POST, например POST https://example.com/base/, где тело запроса содержит спецификацию транзакции, составленную из экземпляров ресурсов и действий, выполняемых над этими экземплярами. Спецификация задается с помощью экземпляра ресурса Bundle (контейнер).

Метод Удалить используется для удаления текущего содержания существующего экземпляра ресурса. Он вызывается с помощью метода HTTP DELETE, например DELETE https://example.com/base/ {TnnPecypca}/{id}, где id — уникальный идентификатор экземпляра ресурса.

Детальная спецификация REST API приведена в разделе 12.

8 Компоненты модели данных хранилища результатов измерений

8.1 Правила именования

При описании типов данных и ресурсов используются следующие правила именования:

а) имена типов данных, ресурсов и их элементов должны допускать использование в программном коде. Поэтому для них задан шаблон [A-Za-z0-9\-\.]{1,64}. Кроме того, эти имена не должны совпадать с ключевыми словами языков программирования или языков манипулирования данными;

б) имя типа данных или ресурса должно быть значащим для человека, читающего программный код или составляющего запрос к базе данных. Поскольку шаблон имени допускает только буквы латинского алфавита, цифры, дефисы и точки, то для составления значащих имен следует использовать слова и сочетания слов на английском языке. Так как пробельные символы в именах не разрешены, то словосочетания следует записывать слитно в одном из двух вариантов «верблюжьей» нотации: lowerCamelCase (первое слово начинается в нижнем регистре, следующие слова — в верхнем, например managingOrganization) или UpperCamelCase (каждое слово начинается в верхнем регистре, например StructureDefinition). Все символы слова, кроме первого, должны записываться в нижнем регистре. При именовании должны соблюдаться следующие требования:

1) для имени следует использовать «наиболее широко используемый» термин данной предметной области;

2) имя должно полностью отражать значение моделируемого понятия;

3) существительные должны использоваться в единственном числе, даже если элемент кратный;

4) сокращения должны использоваться в крайних случаях;

5) при использовании сокращение должно трактоваться как слово (например, targetUri для обозначения ссылки на унифицированный идентификатор ресурса URI);

6) имена должны быть краткими (полное описание понятия должно даваться в определении);

7) не следует использовать суффиксы, подчеркивающие тип данных элемента (например, typeCode или nameText);

8) если подбор соответствующего термина на английском языке вызывает затруднение, следует обратиться к толковому словарю Webster (https://www.webster-dictionary.org/), онлайновой платформе ISO (https://www.iso.org/obp/ui) и другим ресурсам сети Интернет;

в) имя простого типа данных записывается в нотации lowerCamelCase. Дефисы и точки в имени простого типа данных не допускаются;

г) имя комплексного типа данных или ресурса записывается в нотации UpperCamelCase. Дефисы и точки в имени комплексного типа данных не допускаются;

д) имя элемента комплексного типа данных или ресурса записывается в нотации lowerCamelCase. Дефисы и точки в имени элемента не допускаются.

17

ПНСТ 995—2024

8.2 Способы описания

Для каждого комплексного типа данных и ресурса дается описание в форме диаграммы классов на языке UML и в форме иерархической таблицы. В общем случае комплексный тип данных или ресурс представляется в виде нескольких классов, включая головной класс с именем типа данных или ресурса и вспомогательные классы, связанные с головным и между собой отношениями направленной композиции. Цель композиции именуется по правилам, принятым для элемента комплексного типа данных, указанным в подразделе 8.1. Имена вспомогательных классов уникальны только в пределах конкретного комплексного типа данных или ресурса.

При описании классов на языке UML используется пользовательский профиль, описанный в приложении А.

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

Таблица 4 — Формат иерархической таблицы

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

Таблица 5 —Формат таблицы ограничений

Для элементов структуры комплексного типа данных или типа ресурса, имеющих кодируемые значения, могут быть заданы привязки наборам значений. Таблица привязок имеет формат, приведенный в таблице 6.

Таблица 6 — Формат таблицы привязок к наборам значений

18

ПНСТ 995—2024

Таблица критериев поиска экземпляров ресурсов имеет формат, приведенный в таблице 7.

Таблица 7 — Формат таблицы критериев поиска

9 Типы данных

9.1 Общие сведения

В настоящем разделе представлены все типы данных, определенные в спецификации [22], вне зависимости от того, включены ли они в определение элементов ресурсов REST, составляющих хранилище результатов измерений. Это позволяет использовать настоящий раздел и для других предметных областей.

В нем приведены основные сведения о каждом типе данных, включая общие сведения, состав элементов (в форме диаграмм UML и в табличной форме), ограничения, наложенные на элементы, привязки к наборам значений. Дополнительные сведения, в том числе примеры, формальные описания в виде экземпляров ресурса StructureDefinition, схемы представлений в XML и JSON, приведены в спецификации [22].

Типы данных, определенные в [22], подразделяются на следующие категории:

а) простые типы данных;

б) комплексные типы данных:

1) типы данных общего назначения;

2) специальные типы данных;

3) типы метаданных.

Простые типы данных являются потомками абстрактного типа данных PrimitiveType, наследуют от него необязательный элемент уникального идентификатора id и возможность расширения.

Комплексные типы данных являются потомками абстрактного типа данных DataType (тип данных), наследуют от него необязательный элемент уникального идентификатора id и возможность расширения.

9.2 Простые типы данных

9.2.1 Общие сведения

Простые типы могут иметь элемент value (значение) и не имеют потомков (однако, как и любой другой тип данных, могут иметь расширения extension). Если расширения отсутствуют, то элемент value обязателен.

При описании простых типов элементу value сопоставляется примитивный тип данных спецификации схем XSD. Возможные значения элемента value могут быть ограничены регулярным выражением (regex), которое имеет рекомендательный характер и может уточняться на стадии реализации.

Диаграмма классов простых типов данных показана на рисунке 12. Перечень простых типов данных приведен в таблице 8.

Таблица 8 — Простые типы данных

19

ПНСТ 995—2024

Окончание таблицы 8

20

ПНСТ 995—2024

Рисунок 12 — Простые типы данных

9.2.2 Тип данных base64Binary

Тип данных base64Binary предназначен для представления двоичного содержания. Общие сведения о типе данных base64Binary приведены в таблице 9, а состав элементов — в таблице 10.

Таблица 9 — Общие сведения о типе данных base64Binary

Таблица 10 — Состав элементов типа данных base64Binary

21

ПНСТ 995—2024

9.2.3 Тип данных boolean

Булевский тип данных (true/false). Общие сведения о типе данных boolean приведены в таблице 11, а состав элементов — в таблице 12.

Таблица 11 — Общие сведения о типе данных boolean

Таблица 12 — Состав элементов типа данных boolean

9.2.4 Тип данных canonical

Тип данных canonical используется для ссылок на экземпляр ресурса по его каноническому URL (для ресурсов, имеющих компонент url). Общие сведения о типе данных canonical приведены в таблице 13, а состав элементов — в таблице 14.

Таблица 13 — Общие сведения о типе данных canonical

Таблица 14 — Состав элементов типа данных canonical

22

ПНСТ 995—2024

9.2.5 Тип данных code

Тип данных code предназначен для представления перечислимых значений (контролируемых строк) и является специализацией строкового типа string. Общие сведения о типе данных code приведены в таблице 15, а состав элементов — в таблице 16.

Таблица 15 — Общие сведения о типе данных code

Таблица 16 — Состав элементов типа данных code

9.2.6 Тип данных date

Тип данных date используется для представления дат в соответствии со стандартом ГОСТ Р 7.0.64. Допускается указание даты с уменьшенной точностью (до месяца или года). Общие сведения о типе данных date приведены в таблице 17, а состав элементов — в таблице 18.

Таблица 17 — Общие сведения о типе данных date

Таблица 18 — Состав элементов типа данных date

23

ПНСТ 995—2024

9.2.7 Тип данных dateTime

Тип данных dateTime используется для представления дат и времени в соответствии со стандартом ГОСТ Р 7.0.64. Допускается указание даты и времени с уменьшенной точностью (до минуты, часа, дня, месяца или года). Общие сведения о типе данных dateTime приведены в таблице 19, а состав элементов — в таблице 20.

Таблица 19 — Общие сведения о типе данных dateTime

Таблица 20 — Состав элементов типа данных dateTime

9.2.8 Тип данных decimal

Тип данных decimal предназначен для представления десятичных значений. Общие сведения о типе данных decimal приведены в таблице 21, а состав элементов — в таблице 22.

Таблица 21 — Общие сведения о типе данных decimal

Таблица 22 — Состав элементов типа данных decimal

24

Окончание таблицы 22

ПНСТ 995—2024

9.2.9 Тип данных id

Тип данных id предназначен для представления идентификаторов. Общие сведения о типе данных id приведены в таблице 23, а состав элементов — в таблице 24.

Таблица 23 — Общие сведения о типе данных id

Таблица 24 — Состав элементов типа данных id

9.2.10 Тип данных instant

Тип данных instant предназначен для представления штампа даты и времени с точностью до секунды или более высокой. Общие сведения о типе данных instant приведены в таблице 25, а состав элементов — в таблице 26.

Таблица 25 — Общие сведения о типе данных instant

25

ПНСТ 995—2024

Таблица 26 — Состав элементов типа данных instant

9.2.11 Тип данных integer

Тип данных integer предназначен для передачи целочисленных значений. Общие сведения о типе данных integer приведены в таблице 27, а состав элементов — в таблице 28.

Таблица 27 — Общие сведения о типе данных integer

Таблица 28 — Состав элементов типа данных integer

9.2.12 Тип данных integer64

Тип данных integer64 предназначен для передачи больших целочисленных значений, которые могут принимать счетчики записей или таймеры. Общие сведения о типе данных integer64 приведены в таблице 29, а состав элементов — в таблице 30.

Таблица 29 — Общие сведения о типе данных integer64

26

Таблица 30 — Состав элементов типа данных integer64

ПНСТ 995—2024

9.2.13 Тип данных markdown

Тип данных markdown предназначен для удобочитаемого представления структурированного текста в соответствии со спецификацией GitHub Flavored Markdown (https://github.github.com/gfm/). Общие сведения о типе данных markdown приведены в таблице 31, а состав элементов — в таблице 32.

Таблица 31 — Общие сведения о типе данных markdown

Таблица 32 — Состав элементов типа данных markdown

9.2.14 Тип данных oid

Тип данных oid представляет глобально уникальные объектные идентификаторы (ОИД), присваиваемые в соответствии с регламентом, описанным в стандарте ГОСТ Р ИСО/МЭК 9834-1. Структура ОИД описана в стандарте ГОСТ Р ИСО/МЭК 8824-1, хранилище верхних уровней дерева ОИД представлено по адресу https://oidref.com/, хранилище верхних уровней российской ветви 1.2.643 — по адресу https://oid.iitrust.ru. ОИД является одним из вариантов унифицированного идентификатора ресурса URI и может быть представлен в форме URI. Это представление используется в типе данных oid. Общие сведения о типе данных oid приведены в таблице 33, а состав элементов — в таблице 34.

Таблица 33 — Общие сведения о типе данных oid

27

ПНСТ 995—2024

Таблица 34 — Состав элементов типа данных oid

9.2.15 Тип данных positivelnt

Тип данных positivelnt используется для представления положительных целых чисел. Общие сведения о типе данных positivelnt приведены в таблице 35, а состав элементов — в таблице 36.

Таблица 35 — Общие сведения о типе данных positivelnt

Таблица 36 — Состав элементов типа данных positivelnt

9.2.16 Тип данных string

Тип данных string представляет собой строковые данные в кодировке Unicode, которые могут быть записаны несколькими строками (то есть могут содержать символы возврата строки и перевода каретки). Общие сведения о типе данных string приведены в таблице 37, а состав элементов — в таблице 38.

28

Таблица 37 — Общие сведения о типе данных string

ПНСТ 995—2024

Таблица 38 — Состав элементов типа данных string

9.2.17 Тип данных time

Тип данных time используется для представления времени. Общие сведения о типе данных time приведены в таблице 39, а состав элементов — в таблице 40.

Таблица 39 — Общие сведения о типе данных time

Таблица 40 — Состав элементов типа данных time

29

ПНСТ 995—2024

Окончание таблицы 40

9.2.18 Тип данных unsignedlnt

Тип данных unsignedlnt используется для представления целых чисел без знака. Общие сведения о типе данных unsignedlnt приведены в таблице 41, а состав элементов — в таблице 42.

Таблица 41 — Общие сведения о типе данных unsignedlnt

Таблица 42 — Состав элементов типа данных unsignedlnt

9.2.19 Тип данных uri

Тип данных uri используется для представления унифицированных идентификаторов ресурсов. Он имеет три основные разновидности: объектные идентификаторы oid, универсальные уникальные идентификаторы uuid и унифицированные адреса ресурсов url. Общие сведения о типе данных uri приведены в таблице 43, а состав элементов — в таблице 44.

Таблица 43 — Общие сведения о типе данных uri

30

Таблица 44 — Состав элементов типа данных uri

ПНСТ 995—2024

9.2.20 Тип данных uri

Тип данных uri представляет унифицированные адреса ресурсов URL. Общие сведения о типе данных uri приведены в таблице 45, а состав элементов — в таблице 46.

Таблица 45 — Общие сведения о типе данных uri

Таблица 46 — Состав элементов типа данных uri

9.2.21 Тип данных uuid

Тип данных uuid представляет универсально уникальные идентификаторы UUID (GUID) в форме URI. Общие сведения о типе данных uuid приведены в таблице 47, а состав элементов — в таблице 48.

Таблица 47 — Общие сведения о типе данных uuid

Таблица 48 — Состав элементов типа данных uuid

31

ПНСТ 995—2024

Окончание таблицы 48

9.2.22 Ограничения простых типов данных

Простые типы данных являются потомками типа данных PrimitiveType и наследуют его ограничение, представленное в таблице 49.

Таблица 49 — Ограничение типа данных PrimitiveType

Применительно к типам данных это ограничение трактуется следующим образом: если значение типа данных не указано, то должно присутствовать как минимум расширение extension, представляющее дополнительное свойство значения (например, причину его отсутствия).

9.3 Комплексные типы данных общего назначения

9.3.1 Общие сведения

Диаграммы классов комплексных типов данных общего назначения показаны на рисунках 13 и 14. Перечень комплексных типов данных общего назначения приведен в таблице 50.

Таблица 50 — Комплексные типы данных общего назначения

32

Окончание таблицы 50

ПНСТ 995—2024

33

ПНСТ 995—2024

class Типы датых общего назначения (начало) ^

Ratio

Attachment

34

«Constraint»

+ numerator Quantify [0.. 1 ]

+ denominator SimpleQuantify [0..1]

Money

+ value: decimal [0..1] «Binding»

+ currency: Coding [0..1]

Coding

+ system: uri [0..1 ]

+ version: string [0..1]

+ userSelected: boolean [0..1]

«Constraint»

+ code: code [0..1]

+ display: string [0..1]

Range

«Constraint»

+ low: SimpleQuantify [0..1 ]

+ high: SimpleQuantify [0..1

RatioRange

«Constraint»

+ lowNumerator SimpleQuantify [0..1]

+ highNumerator SimpleQuantify

+ denominator SimpleQuantify [0..1]

Age

Annotation

authorfx]: DataType [0..1] time: dateTime [0..1] text: markdown

Element

DataType

Quantify

+ value: decimal [0..1]

+ unit: string [0..1]

«Binding»

+ comparator, code [0..1]

«Constraint»

+ system: uri [0..1]

+ code: code [0..11

+ uri: uri [0..1]

+ size: integer64 [0..1]

+ hash: base64Binary [0..1]

+ title: string [0..1]

+ creation: dateTime [0..1]

+ height: positivelnt [0..1]

+ width: positivelnt [0..1]

+ frames: positivelnt [0..1]

+ duration: decimal [0..1]

+ pages: positivelnt [0..1] «Binding, Constraint»

+ contentType: code [0..1] «Binding»

+ language: code [0..1] «Constraint»

+ data: base64Binary [0..1]

Period

«Constraint»

+ start: dateTime [0..1]

+ end: dateTime [0..1]

Codea bl e Concept

+ coding: Coding [0..*]

+ text: string [0..1 ]

Distance

Duration

Count

MoneyQuantify

SimpleQuantify

Рисунок 13 — Комплексные типы данных общего назначения (начало)

HumanName

Address

ПНСТ 995—2024

ContactPoInt

+ text: string [0..1]

+ family: string [0..1]

+ given: string [0..*]

+ prefix: string [0..*]

+ suffix: string [0..*]

+ period: Period [0..1]

«Binding»

+ use: code [0..1]______

Identifier

+ system: uri [0..1]

+ period: Period [0..1] «Binding»

+ use: code [0..1]

text: string [0..1]

line: string [0..*]

city: string [0..1] district: string [0..1] state: string [0..1] postal Code: string [0..1] country: string [0..1] period: Period [0..1]

«Binding» use: code [0..1] type: code [0..1]

+ rank: positivelnt [0..1]

+ period: Period [0..1]

«Constraint, Binding»

+ system: code [0..1]

«Constraint»

+ value: string [0..1]

«Binding»

+ use: code [0..1]

ВаскЬомТура

+ modifierExtension: Extension [0..*]

+ type: Codea bl eConcept [0..1 «Constraint»

+ value: string [0..1]

«RefTarget»

+ assignor Reference [0.. 1 ]

Signature

type: Coding when: instant who: Reference onBehalfOf: Reference [0..1] targetFormat: code [0..1] sig Format: code [0..1] data: base64Binary [0..1]

Element

Data Туре

Timing

+ event: dateTime [0..*] «Binding»

+ code: CodeableConcept [0..1]

+repeat'

SampledData

Л.1

+ origin: SimpleQuantity

+ factor decimal [0..1]

+ lowerLimit: decimal [0..1]

+ upperLimit: decimal [0..1]

+ dimensions: positivelnt

+ data: string

«Constraint»

+ interval: decimal [0..1]

+ offsets: string [0..1]

«Binding»

+ interval Unit: code

«RefTarget»

+ codeMap: canonical [0..1]

Repeat

+ bounds(x]: Quantity [0..1]

+ frequency: positivelnt[0..1]

+ frequencyMax: positivelnt [0..1]

«Constraint»

+ count: positivelnt [0..1]

+ countMax: positivelnt [0..1]

+ duration: decimal [0..1]

+ durationMax: decimal [0..1]

+ period: decimal [0..1]

+ periodMax: decimal [0..1]

+ timeOfDay: time [0..*]

+ offset: unsignedlnt [0..1]

«Constraint, Binding»

+ du rati on Un it: code [0..1]

+ periodUnit: code [0..1]

+ when: code [0..*]

«Binding»

+ dayOfWeek code [0..*]

Рисунок 14 — Комплексные типы данных общего назначения (окончание)

9.3.2 Тип данных Address

Тип данных Address описывает почтовый адрес лица или организации, но может также использоваться для указания мест, куда почта не доставляется. Общие сведения о типе данных Address приведены в таблице 51, а состав элементов — в таблице 52.

35

ПНСТ 995—2024

Таблица 51 — Общие сведения о типе данных Address

Таблица 52 — Состав элементов типа данных Address

Привязки к наборам значений описаны в таблице 53.

Таблица 53 — Привязки к наборам значений

9.3.3 Тип данных Annotation

Тип данных Annotation используется для представления примечаний к содержанию ресурса. Общие сведения о типе данных Annotation приведены в таблице 54, а состав элементов — в таблице 55.

Таблица 54 — Общие сведения о типе данных Annotation

36

Таблица 55 — Состав элементов типа данных Annotation

ПНСТ 995—2024

9.3.4 Тип данных Attachment

Тип данных Attachment используется для представления вложений в содержание экземпляров ресурсов или ссылок на эти вложения. Общие сведения о типе данных Attachment приведены в таблице 56, а состав элементов — в таблице 57.

Примечание —Для свертки данных рекомендуется использовать алгоритм ГОСТ Р 34.11.

Таблица 56 — Общие сведения о типе данных Attachment

Таблица 57 — Состав элементов типа данных Attachment

37

ПНСТ 995—2024

Окончание таблицы 57

Содержание, передаваемое в экземпляре ресурса Attachment, может передаваться по значению в элементе data или по ссылке в элементе url. Если указаны оба элемента, то ссылка должна указывать на те же самые данные, которое переданы в элементе data.

Элемент contentType должен быть заполнен, если данные передаются в элементе data, и может быть заполнен, если данные передаются по ссылке url.

Если элементы data и url отсутствуют, то это означает, что данные с указанным сочетанием типа содержания contentType и языка language отсутствуют.

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

В ряде случаев кратность элемента ресурса, имеющего тип Attachment, может превышать 1. Правильное использование кратного элемента состоит в том, чтобы его экземпляры имели одно и то же содержание, но с разными типами содержания MIME и/или представленные на разных языках.

Ограничения типа данных Attachment описаны в таблице 58. Привязки к наборам значений описаны в таблице 59.

Таблица 58 — Ограничения типа данных Attachment

Таблица 59 — Привязки к наборам значений

38

ПНСТ 995—2024

9.3.5 Тип данных CodeableConcept

Тип данных CodeableConcept предназначен для представления кодированных понятий, при котором допускается указывать код, взятый из классификатора или справочника, код вместе с текстом, который детализирует значение кода (например, кода прочие), или только текст, если никакой код классификатора или справочника не может быть сопоставлен этому тексту. Общие сведения о типе данных CodeableConcept приведены в таблице 60, а состав элементов — в таблице 61.

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

Таблица 60 — Общие сведения о типе данных CodeableConcept

Таблица 61 — Состав элементов типа данных CodeableConcept

9.3.6 Тип данных Coding

Тип данных Coding предназначен для представления кодированных значений. В отличие от CodeableConcept наличие текста, детализирующего значение кода, не предусмотрено. Общие сведения о типе данных Coding приведены в таблице 62, а состав элементов — в таблице 63.

Таблица 62 — Общие сведения о типе данных Coding

39

ПНСТ 995—2024

Таблица 63 — Состав элементов типа данных Coding

Элемент code является кодом понятия. Элемент system в сочетании с версией version (если указана) идентифицирует систему кодирования. Элемент display содержит человеко-читаемый текст, предназначенный для визуализации вместо кода.

Если с течением времени кодированные понятия остаются неизменными, то версия version не нужна. Если система кодирования описывает полную классификацию (например, Международная статистическая классификация болезней и проблем, связанных со здоровьем), то версия version обязательна, поскольку при добавлении нового понятия значение кода, присвоенного «другим и неуточнен-ным» понятиям, изменяется.

Элемент system должен содержать URI системы кодирования, а не набора значений (например, ValueSet.url), поскольку набор значений описывает множество допустимых кодов, но не связывает их с понятиями.

Элемент code должен являться символом, синтаксис которого определен в системе кодирования, идентифицируемой значением элемента system. В некоторых системах кодирования (например, пост-координируемых) коды могут представлять собой выражения, составленные из других заранее определенных кодов. Примером служат системы единиц измерения.

Если элемент display присутствует, то он должен содержать краткий человеко-читаемый текст, идентифицирующий понятие данной системы кодирования. С одним кодом может быть связано несколько текстов:

- основной, указанный в элементе CodeSystem.concept.display;

- дополнительные, указанные в элементах CodeSystem.concept.designation.value (например, переводы основного текста на другие языки).

Ограничения типа данных Coding описаны в таблице 64.

Таблица 64 — Ограничения типа данных Coding

9.3.7 Тип данных ContactPoint

Тип данных ContactPoint предназначен для представления контактной информации лица или организации. Общие сведения о типе данных ContactPoint приведены в таблице 65, а состав элементов — в таблице 66.

40

Таблица 65 — Общие сведения о типе данных ContactPoint

ПНСТ 995—2024

Таблица 66 — Состав элементов типа данных ContactPoint

Ограничения типа данных ContactPoint описаны в таблице 67. Привязки к наборам значений описаны в таблице 68.

Таблица 67 — Ограничения типа данных ContactPoint

Таблица 68 — Привязки к наборам значений

9.3.8 Тип данных HumanName

Тип данных HumanName предназначен для описания именования физического лица (фамилия, имя, отчество или другие имена). Общие сведения о типе данных HumanName приведены в таблице 69, а состав элементов — в таблице 70.

Именование лица может иметь ограниченный срок действия, задаваемый в элементе period.

41

ПНСТ 995—2024

Таблица 69 — Общие сведения о типе данных HumanName

Таблица 70 — Состав элементов типа данных HumanName

В элементе given передаются все имена лица в том порядке, как это указано в свидетельстве о рождении или паспорте. Для российских граждан первый экземпляр элемента given должен содержать имя, второй — отчество (при наличии).

Элемент text (полное именование) предусмотрен на тот случай, если выделить имя, фамилию и другие структурированные компоненты не представляется возможным. Если заполнены и элемент text, и другие компоненты именования, то элемент text не должен содержать иные компоненты.

Привязки к наборам значений описаны в таблице 71.

Таблица 71 — Привязки к наборам значений

9.3.9 Тип данных Identifier

Тип данных Identifier представляет идентификатор сущности (субъекта или объекта) в пространстве имен, идентифицированном элементом system. Общие сведения о типе данных Identifier приведены в таблице 72, а состав элементов — в таблице 73.

Срок действия идентификатора задается элементом period. Компонент period.start указывает дату присвоения (выдачи) идентификатора, компонент period.end — дату прекращения его действия (например, дату выдачи и срок действия загранпаспорта). Элемент assigner содержит идентификатор организации, присвоившей идентификатор. Поскольку он имеет тип Reference, то в компоненте assigner. display можно передать наименование организации.

42

ПНСТ 995—2024

Элемент system содержит абсолютный URI, определяющий схему идентификации (структура идентификатора, правила присваивания и т.д.). Для глобально уникальных идентификаторов ОИД и УУИД (например, Global Unique Identifier) схема идентификации должна иметь значение urn:ietf:rfc:3986. Если system содержит URL, то он, по возможности, должен быть разрешимым. Значение элемента system чувствительно к регистру.

Значение элемента value должно быть уникальным в пространстве имен, определяемом схемой идентификации system. Оно должно быть чувствительным к регистру за исключением тех случаев, когда схема идентификации предусматривает иное. В некоторых случаях значение value известно, а элемент system отсутствует (например, элемент value содержит значение штрих-кода, считанного с упаковки лекарства). В таких случаях уникальность значения value должна обеспечиваться исходя из контекста применения идентификаторов. В качестве паллиатива вместо system можно использовать элемент type (тип идентификатора).

Таблица 72 — Общие сведения о типе данных Identifier

Таблица 73 — Состав элементов типа данных Identifier

Ограничения типа данных Identifier описаны в таблице 74. Привязки к наборам значений описаны в таблице 75.

Таблица 74 — Ограничения типа данных Identifier

43

ПНСТ 995—2024

Таблица 75 — Привязки к наборам значений

9.3.10 Тип данных Money

Тип данных Money предназначен для представления денежной суммы. Общие сведения о типе данных Money приведены в таблице 76, а состав элементов — в таблице 77.

Таблица 76 — Общие сведения о типе данных Money

Таблица 77 — Состав элементов типа данных Money

Привязки к наборам значений описаны в таблице 78.

Таблица 78 — Привязки к наборам значений

Иногда денежная сумма должна представляться как дробь, числителем которой является денежная единица. В этом случае денежная сумма имеет тип данных Quantity с профилем MoneyQuantity, описанным в таблице 93.

9.3.11 Тип данных Period

Тип данных Period предназначен для представления периода времени или (неопределенного) момента времени внутри периода. Общие сведения о типе данных Period приведены в таблице 79, а состав элементов — в таблице 80.

Таблица 79 — Общие сведения о типе данных Period

44

Таблица 80 — Состав элементов типа данных Period

ПНСТ 995—2024

Если элемент start отсутствует, то начало периода не известно. Отсутствие элемента end означает текущий период. В элементе end может быть указана фактическая или планируемая дата завершения периода (включительно).

Ограничения типа данных Period описаны в таблице 81.

Таблица 81 — Ограничения типа данных Period

9.3.12 Тип данных Quantity

Тип данных Quantity предназначен для представления значения физической величины. Может быть указано точное значение или его нижняя либо верхняя оценка (используя свойство comparator). Общие сведения о типе данных Quantity приведены в таблице 82, а состав элементов — в таблице 83.

Таблица 82 — Общие сведения о типе данных Quantity

Таблица 83 — Состав элементов типа данных Quantity

Ограничения типа данных Quantity описаны в таблице 84. Привязки к наборам значений описаны в таблице 85.

45

ПНСТ 995—2024

Таблица 84 — Ограничения типа данных Quantity

Таблица 85 — Привязки к наборам значений

9.3.13 Специализации и профили типа данных Quantity

9.3.13.1 Специализация Distance (расстояние)

Специализация Distance ограничивает тип данных Quantity величинами расстояния.

Специализация Distance описана в таблице 86. Привязки к наборам значений описаны в таблице 87.

Таблица 86 — Специализация Distance

Таблица 87 — Привязки к наборам значений

9.3.13.2 Специализация Аде (возраст)

Специализация Аде ограничивает тип данных Quantity величинами времени.

Специализация Аде описана в таблице 88. Привязки к наборам значений описаны в таблице 89.

Таблица 88 — Специализация Аде

46

Таблица 89 — Привязки к наборам значений

ПНСТ 995—2024

9.3.13.3 Специализация Count (счетчик)

Специализация Count ограничивает тип данных Quantity безразмерными величинами с целочисленным значением.

Специализация Count описана в таблице 90.

Таблица 90 — Специализация Count

9.3.13.4 Специализация Duration (длительность)

Специализация Duration ограничивает тип данных Quantity величинами времени.

Специализация Duration описана в таблице 91. Привязки к наборам значений описаны в таблице 92.

Таблица 91 — Специализация Duration

Таблица 92 — Привязки к наборам значений

9.3.13.5 Профиль SimpleQuantity

В дополнение к специализациям типа данных Quantity определен профиль SimpleQuantity, описанный в таблице 93.

47

ПНСТ 995—2024

Таблица 93 — Профиль SimpleQuantity

Это не отдельный тип данных, а ограничение типа данных Quantity.

9.3.13.6 Профиль MoneyQuantity

В дополнение к специализациям типа данных Quantity определен профиль MoneyQuantity, описанный в таблице 94.

Таблица 94 — Профиль MoneyQuantity

Это не отдельный тип данных, а ограничение типа данных Quantity, используемое при представлении денежных сумм в форме дроби.

9.3.14 Тип данных Range

Тип данных Range предназначен для указания диапазона значений физических величин. Общие сведения о типе данных Range приведены в таблице 95, а состав элементов — в таблице 96.

Таблица 95 — Общие сведения о типе данных Range

Таблица 96 — Состав элементов типа данных Range

48

Окончание таблицы 96

ПНСТ 995—2024

Ограничения типа данных Range описаны в таблице 97.

Таблица 97 — Ограничения типа данных Range

9.3.15 Тип данных Ratio

Тип данных Ratio предназначен для представления отношения двух физических величин в форме дроби. Тип данных может использоваться для представления обычной дроби, например, «2/3». Общие сведения о типе данных Ratio приведены в таблице 98, а состав элементов — в таблице 99.

Таблица 98 — Общие сведения о типе данных Ratio

Таблица 99 — Состав элементов типа данных Ratio

Ограничения типа данных Ratio описаны в таблице 100.

49

ПНСТ 995—2024

Таблица 100 — Ограничения типа данных Ratio

9.3.16 Тип данных RatioRange

Тип данных RatioRange предназначен для представления диапазонов отношений двух физических величин, представленных в форме дроби. Общие сведения о типе данных RatioRange приведены в таблице 101, а состав элементов — в таблице 102.

Таблица 101 — Общие сведения о типе данных RatioRange

Таблица 102 — Состав элементов типа данных RatioRange

Ограничения типа данных RatioRange описаны в таблице 103.

Таблица 103 — Ограничения типа данных RatioRange

50

ПНСТ 995—2024

9.3.17 Тип данных SampledData

Тип данных SampledData предназначен для представления серии считываний, осуществляемых приборами, например, кардиографами. Каждое считывание представляет собой десятичное значение или код. Результат измерения определяется по следующей формуле, содержащей значение i-ro считывания data с поправками на смещение базового значения origin.value и масштабный коэффициент factor:

измеряемое значение^] = SampledData.data[i] * SampledData.factor + SampledData.origin.value

Общие сведения о типе данных SampledData приведены в таблице 104, состав элементов — в таблице 105.

Таблица 104 — Общие сведения о типе данных SampledData

Таблица 105 — Состав элементов типа данных SampledData

51

ПНСТ 995—2024

В дополнение к кодам 'Е', 'U', 'L' могут использоваться другие коды, описанные в ссылочном экземпляре ресурса CodeMap, в котором должна быть только одна группа, не содержащая ни числовые значения, ни коды 'Е', 'U', 'L' (и для безопасности 'е', 'u', Т). Дополнительные коды не должны содержать пробелы и escape-последовательности и не должны начинаться с цифр.

Привязки к наборам значений описаны в таблице 106.

Таблица 106 — Привязки к наборам значений

9.3.18 Тип данных Timing

Тип данных Timing предназначен для представления списка повторяющихся событий. Правила повторения могут задаваться простыми кодом, указанным в поле code, или конструкцией типа Repeat, указанной в поле repeat. Общие сведения о типе данных Timing приведены в таблице 107, а состав элементов — в таблице 108.

Таблица 107 — Общие сведения о типе данных Timing

Таблица 108 — Состав элементов типа данных Timing

52

Окончание таблицы 108

ПНСТ 995—2024

Ограничения типа данных Timing описаны в таблице 109. Привязки к наборам значений описаны в таблице 110.

Таблица 109 — Ограничения типа данных Timing

53

ПНСТ 995—2024

Окончание таблицы 109

Таблица 110 — Привязки к наборам значений

9.3.19 Тип данных Signature

9.3.19.1 Общие сведения и состав элементов

Тип данных Signature предназначен для представления подписи, в том числе образца собственноручной подписи, в виде графического файла или сертификата усиленной квалифицированной электронной подписи. Общие сведения о типе данных Signature приведены в таблице 111, а состав элементов — в таблице 112.

Таблица 111 — Общие сведения о типе данных Signature

Таблица 112 — Состав элементов типа данных Signature

54

Окончание таблицы 112

ПНСТ 995—2024

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 должны использоваться пространства имен по умолчанию;

в) все комментарии должны быть опущены;

55

ПНСТ 995—2024

г) в escape-последовательностях должны использоваться исходные символы Unicode (например, ' вместо ");

д) должна использоваться инструкция <?xml version=» 1.0» encoding=»UTF-8»?>;

е) должен быть применен метод каноникализации Canonical XML 1.1 (http://www.w3.org/TR/xml-c14n11).

Данный метод канонического представления идентифицируется, используя URI http://hl7.org/fhir/ canonicalization/xml. В дополнение к нему определены методы канонического представления, приведенные в таблице 113.

Таблица 113 —Дополнительные методы канонического представления содержания экземпляра ресурса в формате XML

9.3.19.5 Каноническое представление содержания экземпляра ресурса в формате JSON

Каноническое представление содержания экземпляра ресурса в формате JSON должно удовлетворять следующим требованиям:

а) в значениях свойств объектов и в XHTML представлении объекта Narrative не должно быть иных пробельных символов кроме пробела. При этом пробелы не должны быть кратными;

б) внутри каждого объекта свойства сортируются по алфавиту.

Данный метод канонического представления идентифицируется, используя URI http://hl7.org/fhir/ canonicalization/json. В дополнение к нему определены методы канонического представления, приведенные в таблице 114.

Таблица 114 — Дополнительные методы канонического представления содержания экземпляра ресурса в формате JSON

56

ПНСТ 995—2024

9.4 Специальные типы данных

9.4.1 Общие сведения

Специальные типы данных используются для вспомогательных целей. Диаграмма классов, описывающая эти типы данных, показана на рисунке 15.

Рисунок 15 — Специальные типы данных

Перечень специальных типов данных приведен в таблице 115.

Таблица 115 — Специальные типы данных

57

ПНСТ 995—2024

9.4.2 Базовый тип вспомогательных классов BackboneType

Базовый тип вспомогательных классов BackboneType является детализацией типа данных Element, добавляющей к его свойствам еще одно — modifierExtension (модифицирующее расширение). Общие сведения о типе данных BackboneType приведены в таблице 116, а состав элементов — в таблице 117.

Таблица 116 — Общие сведения о типе данных BackboneType

Таблица 117 — Состав элементов типа данных BackboneType

9.4.3 Тип данных CodeableReference

Элемент записи электронной медицинской карты может представлять собой ссылку на конкретный экземпляр данных или на общее понятие. Например, лекарственный препарат может быть прописан в связи с головной болью, что указано кодом R51 классификации МКБ-10, или же в связи с результатами исследования, содержащимися в конкретном экземпляре ресурса Observation (исследование).

Возможность такой вариабельности предусмотрена в типе данных CodeableReference (ссылка на кодированное понятие или экземпляр ресурса). Общие сведения о типе данных CodeableReference приведены в таблице 118, а состав элементов — в таблице 119.

Таблица 118 — Общие сведения о типе данных CodeableReference

Таблица 119 — Состав элементов типа данных CodeableReference

58

ПНСТ 995—2024

Если кодированное понятие и ссылка на экземпляр ресурса присутствуют одновременно, то они должны быть согласованы друг с другом. Например, если в concept.coding.code указан код головной боли, то ссылочный экземпляр ресурса должен описывать головную боль.

9.4.4 Базовый тип данных DataType

Тип данных DataType является базовым для всех типов данных. Общие сведения о базовом типе данных DataType приведены в таблице 120, а состав элементов — в таблице 121.

Таблица 120 — Общие сведения о типе данных DataType

Таблица 121 — Состав элементов типа данных DataType

9.4.5 Тип данных Dosage

Тип данных Dosage используется для представления структурированных сведений о дозировке, указываемой в рецептах и описаниях лекарственных средств. Общие сведения о типе данных Dosage приведены в таблице 122, состав элементов представлен на рисунке 16 и в таблице 123. Ограничения типа данных Dosage описаны в таблице 124.

Таблица 122 — Общие сведения о типе данных Dosage

59

ПНСТ 995—2024

Рисунок 16 — Тип данных Dosage

Таблица 123 — Состав элементов типа данных Dosage

60

Окончание таблицы 123

ПНСТ 995—2024

Таблица 124 — Ограничения типа данных Dosage

9.4.6 Тип данных ElementDefinition

9.4.6.1 Общие сведения, состав, ограничения и привязки к наборам значений

Тип данных ElementDefinition используется в ресурсе StructureDefinition для формализованного описания элементов типов данных, ресурсов и расширений. Общие сведения о типе данных ElementDefinition приведены в таблице 125, состав элементов представлен на рисунке 17 и в таблице 126.

Таблица 125 — Общие сведения о типе данных ElementDefinition

61

ПНСТ 995—2024

dass ElementDeflnMon /

BackboneType

ElementDefinition

♦base

Element

Base

62

+ path: string

+ label: string [0..1]

+ short: string [0..1]

+ definition: markdown [0..1]

+ comment: markdown [0..1]

♦ requirements: markdown [0 -1]

+ alias: string [0..*]

+ condition: id [0..*]

+ mustSupport: boolean [0..1]

+ isSummary: boolean [0..1]

«Binding»

+ representation: code [0..*]

+ code: Coding [0..*]

«Constraint»

+ sliceName: string

+ slicelsConstraining: boolean [0..1]

+ min: unsignedlnt [0..1]

+ max: string [0..1]

+ contentReference: uri [0..1]

+ meaningWhenMissing: markdown [0„1]

♦ orderMeaning: string [0..1]

+ maxLength: integer [0..1]

+ mustHaveValue: boolean [0..1]

+ isModifier: boolean [0..1]

+ isModifierReason: string [0..1]

«TypeChoice, Constraint»

+ defaultValue[x] [0..1]

+ fixed[x] [0..1]

+ pattem[x] [0..1]

+ minValue[x] [0..1]

+ maxValue[x] [0..1]

«RefTarget, Constraint»

+ valueAltematives: canonical

+ path: string

+ min: unsignedlnt

+ max: string

Element

♦slicing.

0..1

+type

o..*

♦exam pieifO..*

Element

Example [Q

+ label: string «TypeChoice»

+ value[x]

♦binding

Element

ElementDefinition Binding

«Binding»

+ strength: code «Constraint»

+ description: string [0..1]

«RefTarget, Constraint»

+ valueSet: canonical [0..1]

♦additionallo..*

Bement

Additional

+ documentation: markdown [0..1]

+ shortDoco: string [0..1]

+ usage: UsageContext [0..*]

+ any; boolean

«Binding»

+ purpose: code

«RefT arget»

+ valueSet: canonical

Slicing

+ description: string [0..1] «Constraint»

+ ordered: boolean [0..1] «Binding, Constraint»

+ rules: code

Element

♦discriminator 0..*

Bement Discriminator

Mapping

+ language: code [0..1]

+ map: string

+ comment: string [0.. 1 ] «Constraint»

+ identity: id

+ path: string «Binding»

+ type: code

Element

Ifo*

+ profile: canonical [0..*] versioning: code [0..1]

«Constraint» code:uri

«RefT arget»

targetProfile: canonical [0..*]

«Binding, Constraint» aggregation: code [0..*]

Constraint

Element

+ requirements: string [0..1]

+ human: string

«Constraint»

+ ley: Id

♦ suppress: boolean [0..1]

+ expression: string [0..1]

«Binding, Constraint»

+ severity: code

«RefTarget»

+ source: canonical [0..1]

Рисунок 17 — Тип данных ElementDefinition

Таблица 126 — Состав элементов типа данных ElementDefinition

ПНСТ 995—2024

63

ПНСТ 995—2024

Продолжение таблицы 126

64

Продолжение таблицы 126

ПНСТ 995—2024

65

ПНСТ 995—2024

Продолжение таблицы 126

66

Продолжение таблицы 126

ПНСТ 995—2024

67

ПНСТ 995—2024

Окончание таблицы 126

Ограничения описаны в таблице 127, привязки к наборам значений — в таблице 128.

Таблица 127 — Ограничения типа данных ElementDefinition

68

Продолжение таблицы 127

ПНСТ 995—2024

69

ПНСТ 995—2024

Окончание таблицы 127

70

Таблица 128 — Привязки к наборам значений

ПНСТ 995—2024

9.4.6.2 Использование пути ElementDefinition.path

Свойство пути path является важнейшим свойством определения элемента. Оно не только именует элемент, но еще и указывает его место в иерархии элементов. Для каждого пути path существует только одно исходное определение. Оно является главным определением, которому должны соответствовать все другие определения с этим же значением пути path.

Каждый элемент данных определен в экземпляре ресурса StructureDefinition, описывающем тип ресурса или тип данных. Он задает идентификацию элемента и представляет контекст, в котором значение элемента обретает определенный смысл. При определении элементов должны соблюдаться следующие правила:

а) имена элементов (части пути path, разделенные символом '.') не должны содержать пробельные символы (то есть символы Unicode, помеченные как пробельные);

б) имена элементов не должны содержать символы ,:;>»/|?!@#$%^Л&*()[]{};

в) имена элементов не должны содержать символы, не входящие в таблицу-ASCII;

г) длина имен элементов не должна превышать 64 символа;

д) пути path не могут подразумевать элементы, не определенные явно (например, путь a.b.c.d не может быть задан, если не определен путь а.Ь.с);

е) по соглашению каждый путь начинается с прописной буквы, но все следующие имена (кроме имен типов) должны начинаться со строчной буквы. Имена всех типов ресурсов и типов данных (кроме примитивных) должны следовать этому соглашению.

Если элемент является полиморфным (может иметь несколько типов данных), то путь должен заканчиваться символами «[х]», означающими, что имя элемента при сериализации может изменяться.

Элементы могут быть определены, используя следующие конструкции:

а) с помощью экземпляра ресурса StructureDefinition, в котором элемент kind = resource, complextype или primitive-type, а элемент derivation = specialization. Это типы ресурсов или типы данных, определенные в спецификации;

б) в элементах данных.

В экземплярах ресурса StructureDefinition, имеющих свойство derivation = ограничение (то есть в профилях ресурсов и типов данных), не разрешается указывать или определять элементы типа ElementDefinition, у которых значение пути path отсутствует в определении базового типа, от которого они произведены.

71

ПНСТ 995—2024

9.4.6.3 Идентификатор ElementDefinition.id

Кроме элемента path, каждый элемент типа ланных ElementDefinition должен содержать унаследованный элемент id (идентификатор), которому должно быть присвоено уникальное значение в соответствии со следующим алгоритмом:

а) значение id должно конструироваться как строка, разделенная точками, у которой каждый компонент соответствует токену в пути path;

б) для каждого компонента пути path в идентификаторе id используется синтаксис pathpart:slicename/reslicename (то есть компонент:имя-варианта/имя-подварианта).

При отсутствии вариантов определения элемента значение идентификатора id должно в точности совпадать со значением пути path.

9.4.6.4 Интерпретация значений элементов типа данных ElementDefinition в разных контекстах

Тип данных ElementDefinition используется в ресурсе StructureDefinition. Способ использования и интерпретации полей типа данных ElementDefinition зависит от контекста в соответствии с таблицей 129.

Таблица 129 — Интерпретация элементов типа данных ElementDefinition в зависимости от контекста

72

Окончание таблицы 129

ПНСТ 995—2024

Примечания

1 Графы Определение типа: экземпляр ресурса StructureDefinition без элемента baseDefinition или имеющий поле derivationType со значением специализация.

2 Графы Определение ограничения типа: экземпляр ресурса StructureDefinition с элементом baseDefinition, имеющий поле derivationType со значением ограничение, то есть описание структуры, ограничивающей другую структуру:

3 В графах Определение ограничения типа используются следующие обозначения:

t: присутствие и семантика элемента должны совпадать с определением в базовой структуре;