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

Информатизация здоровья

ГАРМОНИЗИРОВАННЫЕ ТИПЫ ДАННЫХ ДЛЯ ОБМЕНА ИНФОРМАЦИЕЙ

(ISO 21090:2011, ЮТ)

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

Москва

Стандартинформ

2017

Предисловие

1    ПОДГОТОВЛЕН на основе официального перевода на русский язык англоязычной версии указанного в пункте 4 стандарта, который выполнен Федеральным государственным учреждением «Центральный научно-исследовательский институт организации и информатизации здравоохранения Министерства здравоохранения Российской Федерации» (ЦНИИОИЗ Минздрава РФ) и Обществом с ограниченной ответственностью «Корпоративные электронные системы»

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 468 «Информатизация здоровья» при ЦНИИОИЗ Минздрава РФ - постоянным представителем ISO/TC 215

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

4    Настоящий стандарт идентичен международному стандарту ИСО 21090:2011 «Информатизация здоровья. Гармонизированные типы данных для обмена информацией» (ISO 21090:2011 «Health Informatics — Harmonized data types for information interchange», IDT).

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

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2017

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

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

6.2    Определения типов данных

В настоящем стандарте определен комплекс именованных типов данных. С каждым из них связаны и короткое, и длинное имя. Формальным именем типа данных является короткое имя. Каждый тип данных определен двумя разными способами:

-    в терминах языка спецификации типов данных и других типов, определенного в ИСО/МЭК11404;

-    на языке UML, используя примитивные типы данных из пакета, представляющего ядро UML.

Определения в терминах ИСО/МЭК 11404 приведены для обеспечения преемственности между

данным стандартом и документами общего назначения ИСО/МЭК 11404, а определения на языке UML предназначены для облегчения реализации типов данных программными средствами. Определения в терминах ИСО/МЭК 11404 являются по своей природе семантическими и абстрактными, а определения на языке UML являются определениями конкретных структур. В настоящем стандарте акцент сделан на определения конкретных структур, поэтому определения на языке UML обладают приоритетом над определениями в терминах ИСО/МЭК 11404, которые приведены в целях преемственности с этим стандартом.

Типы данных, определенные в настоящем стандарте, представляют собой реализацию спецификации абстрактных типов данных HL7 V3 Abstract Data Types (R2). Это означает, что можно реализовать обмен информацией, основанный на определениях этой спецификации, используя типы данных, определенные в настоящем стандарте. В приложении В показано, как эти типы данных соотносятся с типами данных, определенным в спецификации HL7 V3 Abstract Data Types (R2).

Типы данных, определенные в настоящем стандарте, не ограничены свойствами, описанными в спецификации HL7 V3 Abstract Data Types (R2), и для реализации этих типов указанная спецификация не требуется. Приведенные в ней семантические определения могут использоваться разработчиками для лучшего понимания применения этих типов данных.

6.3    Имена типов данных и повторное использование общераспространенных имен

типов данных

Некоторые имена этих типов данных имеют чрезвычайное сходство с именами, определенными в других спецификациях. Например, в настоящем стандарте определен вещественный тип данных REAL, в ИСО/МЭК 11404 определен тип Real, в ядре иМЬтоже есть тип данных с именем Real (см. примечание 1 в В.2.7, где обсуждаются числовые типы с плавающей точкой).

В настоящем стандарте не делаются попытки переопределить или заменить вещественные типы данных, описанные в ИСО/МЭК 11404 или в языке UML. Вместо этого в нем введен новый тип данных, который представляет собой «обертку» соответствующего «примитивного» типа данных, построенную на основе функциональности этого типа и включающую его в общую базовую архитектуру.

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

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

ГОСТ Р ИСО 21090-2016

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

Такой шаблон «обертки примитивного типа данных» используется для типов данных BL, ST, INT, REAL, SET, LIST и BAG, определенных в настоящем стандарте.

6.4    Отображение на настоящий стандарт типов данных

Подобно ИСО/МЭК 11404, в настоящем стандарте предполагается, что определенные в нем типы данных будут использоваться в других спецификациях. В этих спецификациях должно быть указано, каким образом в реализованы типы данных и свойства, описанные в настоящем стандарте. Эти типы данных могут использовать непосредственно, отображать на другие типы или структуры данных, определенные в разных местах, либо вообще не поддерживаться преобразование данных между спецификациями.

6.5    Соответствие ИСО/МЭК 11404

Настоящий стандарт объявляет соответствие ИСО/МЭК 11404. Хотя настоящий стандарт можно считать поддерживающим все типы данных общего назначения, в действительности в нем использованы только следующие типы данных:

-    boolean;

-    enumerated;

-    characterstring;

-    integer;

-    Real;

-    class;

-    set;

-    bag;

-    sequence;

-    octet.

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

6.6    Ссылки на язык UML 2

В настоящем стандарте типы данных определены, используя язык UML. Все эти типы данных являются специализациями класса Classifier, определенного в этом языке, и определены или построены на следующих типах данных, включенных в ядро Kernel языка UML и определенных в спецификации языка ограничений объектов OCL2:

-    enumeration;

-    boolean;

-    integer;

-    string;

-    collection;

-    sequence;

-    set;

-    bag.

6.7    Моделирование типов данных

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

В настоящем стандарте отношения между отдельными типами данных описаны с помощью Униязыка UML версии 2. Этот способ моделирования обеспечивает следующие возможности:

9

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

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

6.7.2    Определения атрибутов

Если не указано иное, все атрибуты и ассоциации имеют значение по умолчанию nil.

6.7.3    Генерализация/специализация

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

6.7.4    Определения перечислений

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

-    список кодов в форме перечислений, определяемых в соответствии с ИСО/МЭК 11404;

-    список кодов в форме перечислений, определены в соответствии с языком UML;

-    таблица, в которой перечисления определяются в текстовом виде.

Такая таблица имеет четыре столбца: Level (уровень), Code (код), Title (описание) и Definition (определение), описание которых приведено в таблице 1.

Таблица 1 — Структура таблицы перечисления

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

Иерархия внутри перечисления является важной частью спецификации. Хотя в ИСО/МЭК 11404 и в языке UML перечисления определены как линейные списки, каждый элемент обработки информации, объявляющий о непосредственном или косвенном соответствии настоящему стандарту, должен принимать во внимание отношение иерархии при оценке значения (смысла) перечисления. Кроме того, при определении результата некоторых операций настоящий стандарт время от времени использует отношения, определенные в табличных описаниях перечислений.

За исключением перечисления типов частей адреса AddressPartType, иерархии отражают отношения генерализации/специализации (известного также как категоризация). В этих иерархиях дочерние коды имеют более специальное значение по отношению к родительскому. Перечисление AddressPartType по своей природе является композицией; в нем дочерние коды описывают части понятия, представленного родительским кодом.

Для примера в таблице 2 приведено подмножество определения перечисления NullFlavor (причина пустоты).

10

ГОСТ Р ИСО 21090-2016

Таблица 2 — Перечисление NullFlavor, ОИД1): 2.16.840.1.113883.5.1008 (подмножество)

Уровень Код Описание Определение 1 N1 Noinformation Отсутствует какая бы то ни было информация, которую можно вывести из данного исключительного значения. Это наиболее общее исключительное значение, оно также использовано по умолчанию 2 UNK unknown Правильное значение имеется, но оно не известно 3 ASKU asked but unknown Информация запрошена, но ответ не получен (например, пациенту задали вопрос, а ответ он не знает) 4 NAV temporarily unavailable Информация в данное время недоступна, но может стать доступной позже 3 NASK not asked Эта информация не запрашивалась (например, пациенту вопрос не задавался) 2 MSK masked Информация об этом элементе имеется, но не предоставлена отправителем по причине безопасности, конфиденциальности и т. д. Для получения доступа к этой информации могут существовать альтернативные механизмы. Предупреждение: хотя детали информации и не раскрываются, но предоставление такой причины пустоты может привести к нарушению конфиденциальности информации. Такая причина пустоты может быть указана в ситуации, когда получателя необходимо информировать о том, что информация существует, не предоставляя саму информацию 2 NA not applicable В данном контексте правильного значения не существует (например, последний менструальный период у мужчины)

В этой таблице все коды понятий после N1 указаны с отступом и имеют более высокий уровень, т. е. эти понятия являются специализациями понятия с кодом N1. Понятия с кодами ASKU, NAV и MASK являются специализациями понятия с кодом UNK, а понятия с кодами UNK, MSK и NA являются братскими и представляют собой не что иное, как специализации понятия с кодом N1. Соответственно, перечисляемое значение ASKU подразумевает, что может быть использовано также перечисляемое значение UNK.

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

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

6.7.5 Строковые типы данных и кодирование символов

В настоящем стандарте даются ссылки как на тип данных characterstring, определенный в ИСО/МЭК11404, так и на тип String, определенный в ядре языка UML. Для целей настоящего стандарта оба этих типа определяют одну и ту же функциональность, а именно: неизменную последовательность известной длины, состоящую из нуля или большего числа логических символов. В тексте этот тип данных далее обозначается просто как String.

Примечания

1 Как ИСО/МЭК 11404, так и ядро языка UML определяют дополнительные характеристические операции, которые могут быть полезны при реализации типа данных и считаться применимыми, но не представляют непосредственного интереса для настоящего стандарта.

■0 ОИД = объектный идентификатор.

11

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

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

Примечание 3 — Разработчики должны аккуратно учитывать различие между этими двумя понятиями при реализации этих типов данных.

По умолчанию тип данных String содержит символы в кодировке Unicode. Рекомендуется, чтобы все элементы обработки информации, объявляющие непосредственное или косвенное соответствие настоящему стандарту, указывали, что набор символов Unicode используется во всех строковых типах данных, взятых из настоящего стандарта.

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

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

Набор символов, применяемый в конкретной среде реализации, будь то Unicode или какой-либо другой, будет именоваться в настоящем стандарте как «строковый набор символов».

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

6.7.6 Атрибуты тонкости

В дополнение к базовым типам данных настоящий стандарт определяет также ряд атрибутов тонкостей типов данных, которые сами по себе не являются типами данных и не определяются ни как классы UML, ни как типы на языке XML-схем. Вместо этого атрибуты тонкости описывают общие шаблоны ограничений типов данных. Поэтому они не могут быть представлены в виде новых атрибутов, новых кодов, значений по умолчанию или других вновь определяемых элементов. Они могут только описывать правила того, какие существующие свойства класса могут быть использованы и каким образом.

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

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

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

-    пространства имен используются для предотвращения конфликта между именами атрибутов тонкостей, описанных разными источниками; пространство имен должно представлять собой или код страны согласно ИСО 3166-1, или допустимый идентификатор территории применения (realm), определенный организацией HL7, или DNS-имя.

Примеры

TS.CA.BIRTH Правила для дат рождения, опубликованные соответствующим уполномоченным органом Канады.

ГОСТ Р ИСО 21090-2016

TS.NPFIT.NHS_NUMBER    Атрибут    тонкости    идентификатора    пациента    (NHS Number

flavor, фиксированный корень имени), опубликованный в документации по программе NPFIT в Великобритании.

ED.AU.KESTRAL.DOCUMENT    Правила    формата    документов,    допустимого для австралий

ской фирмы Kestral.

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

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

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

6.7.7 Примеры

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

Все примеры приведены в виде XML-фрагментов в соответствии с формой, документированной в приложении А. Примеры составлены в предположении, что содержащий их документ или элемент XML использует набор символов UTF-8. Для явного указания типа данных в большинстве примеров использована спецификация типа xsi:type, но это не требуется, если тип данных полностью определен контекстом использования или XML-схемой.

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

7 Типы данных

7.1    Общие свойства

7.1.1    Неизменность

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

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

7.1.2    Равенство

Существуют два аспекта равенства, а именно: «являются ли эти два значения данных одним и тем же экземпляром?» и «представляют ли эти два значения данных одно и то же семантическое понятие?».

Для отражения этих двух аспектов равенства в языках UML/OCL использовано два свойства. Первое обозначается как «=» и означает, что эти два значения являются одним и тем же экземпляром, а второе обозначается «equals» и означает, что эти типы представляют одно и то же понятие. Для примитивных типов данных языка OCL, например integer, эти два свойства имеют одно и то же значение. Для классов языка UML значения этих свойств могут различаться.

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

рефлексивность: «х equals х» должно быть истинно;

симметричность: если «х equals у» истинно, то «у equals х» должно быть истинно;

транзитивность: если «х equals у» истинно и «у equals z» истинно, то «х equals z» должно быть истинно.

13

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

Атрибуты тонкости типов данных не влияют на определение равенства.

7.1.3    История и журнал изменений

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

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

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

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

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

7.1.4    Пустые значения и атрибут причины пустоты nullFlavor

В описании базового типа ANY введено понятие, называемое nullFlavor (атрибут тонкости, описывающий причину пустоты). Хотя это понятие имеет некоторую связь с пустым значением null, определенным в языках UML и OCL, это не одно и то же, и для правильной реализации настоящего стандарта необходимо понимать связь и различия между этими двумя понятиями.

Любой экземпляр класса, определенного в настоящем стандарте, может быть пустым. Это соответствует понятию null, определенному в языках UML и OCL. Пустой экземпляр представляет собой экземпляр типа OcIVoid и соответствует всем типам данных. Он не несет никакой другой информацию кроме той, что факт отсутствует. Для задания ограничений на использование этой формы пустоты в атрибутах типов данных, определенных в настоящем стандарте, использованы операции ocllsDefined и ocllsUndefined языка OCL.

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

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

ГОСТ Р ИСО 21090-2016

Поскольку для наличия причины пустоты nullFlavor экземпляр типа данных должен быть создан, его другим атрибутам могут быть присвоены значения. Тем самым этот экземпляр отличается от пустого объекта null, определенного в языках UML/OCL. Этот объект не существует и не может иметь непустые атрибуты. Если причина пустоты nullFlavor присутствует, то другим атрибутам могут быть присвоены значения, однако при этом не требуется, чтобы элемент обработки информации использовал какое-либо из этих значений, за исключением следующих случаев, которые следует правильно понимать в ситуации, когда они применимы:

-    значение ОТН из перечисления NullFlavor для кодируемого типа данных CD;

-    значения NINF и PINF для типа данных CD из перечисления NullFlavor соответственно для нижней и верхней границы интервала;

-    значение ОТН из перечисления NullFlavor для типа данных идентификатора II, у которого нет корня root, но есть расширение extension.

Перечисление NullFlavor описано в таблице 3.

Таблица 3 — Перечисление NullFlavor, ОИД: 2.16.840.1.113883.5.1008

Уровень Код Описание Определение 1 N1 Noinformation Отсутствует какая бы то ни было информация, которую можно вывести из данного исключительного значения. Это наиболее общее исключительное значение, оно также используется по умолчанию 2 INV Invalid Значение, представленное в экземпляре, не принадлежит ограниченному домену значений переменной 3 ОТН Other Фактическое значение не является элементом ограниченного до-мена значений переменной (например, в используемой системе кодирования данное понятие отсутствует) 4 PINF Positive infinity Положительная бесконечность чисел 4 NINF Negative infinity Отрицательная бесконечность чисел 3 UNC Unencoded Попытки правильной кодировки информации не предпринимались, но некодированное исходное значение представлено (обычно в атрибуте originalText) 3 DER Derived Фактическое значение может существовать, но оно должно быть произведено из предоставленной информации (обычно выражение задается непосредственно) 2 UNK Unknown Правильное значение имеется, но оно неизвестно 3 ASKU Asked but unknown Информация запрошена, но ответ не получен (например, пациенту задали вопрос, а ответ он не знает) 4 NAV Temporarily unavailable Информация в данное время недоступна, но может стать доступной позже 3 NASK Not asked Эта информация не запрашивалась (например, пациенту вопрос не задавался) 3 QS Sufficient quantity Конкретная величина неизвестна, но известно, что она ненулевая и не указана, поскольку образована из большого объема вещества. «Добавить 10 мг ингредиента X, 50 мг ингредиента Y и достаточное количество воды до 100 мл». Эта причина пустоты может использоваться для представления количества воды 3 TRC Trace Содержание отлично от нуля, но слишком мало, чтобы можно было узнать его количество 2 MSK Masked Информация об этом элементе имеется, но не предоставлена отправителем по причине безопасности, конфиденциальности и т. д. Для получения доступа к этой информации могут существовать альтернативные механизмы.

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

Уровень Код Описание Определение Предупреждение: хотя детали информации и не раскрываются, но предоставление такой причины пустоты может привести к нарушению конфиденциальности информации. Такая причина пустоты может быть указана в ситуации, когда получателя необходимо информировать о том, что информация существует, не предоставляя саму информацию 2 NA not applicable В данном контексте правильного значения не существует (например, последний менструальный период у мужчины)

В стандарте ИСО/МЭК 11404 определено понятие сигнального значения (sentinel value), представляющего собой значение в пространстве значений типа данных, к которому применимы не все характеристические операции этого типа. Хотя между значениями nullFlavors и sentinel существуют определенные концептуальные сходства, экземпляры типа данных ANY, у которых заданы причины пустоты nullFlavor, не являются сигнальными значениями. Характеристические функции к этим экземплярам применимы, однако результатом их применения будет некоторая разновидность (flavor) пустого значения null. Вследствие сходства с поведением значения null, определенного в языке OCL, данное свойство получило имя «nullFlavor».

Если специально не оговорено, все операции, определенные в настоящем стандарте, имеют одинаковое поведение,а именно:

-    если операция выполнена над пустым значением null, определенным в языках UML/OCL, то результатом является null;

-    если операция выполнена над значением, имеющими причину пустоты nullFlavor, то имеет место следующее:

-    если у операции нет параметров, то она возвращает значение nullFlavor. Обычно этим значением будет NA (не применимо), но в зависимости от семантики причины пустоты nullFlavor могут возвращаться и другие значения. При выполнении операций над значениями, имеющими причину пустоты nullFlavor, следует рассматривать семантический смысл этого атрибута тонкости;

-    если у операции есть параметры и какой-либо из них имеет значение null, определенное в языках UML/OCL, то результатом является null;

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

-    если операция выполняется над правильным значением:

-    если у операции есть параметры и какой-либо из них имеет значение null, определенное в языках UML/OCL, то результатом является null;

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

-    в остальных случаях операция выполняется, как предписано.

Некоторые специфичные операции отклоняются от этих правил. Эти отклонения документируют для каждой такой операции.

Один из особых случаев возникает при сравнении различных значений, имеющих причину пустоты nullFlavor, на предмет равенства. Два значения, у которых причина пустоты nullFlavor имеет значение NA (не применимо), считаются равными. В то же время два значения, у которых причина пустоты имеет значение NINF (отрицательная бесконечность), не равны, равно как и два значения, у которых причина пустоты имеет значение PINF (положительная бесконечность), поскольку фактическое значение неизвестно. Очевидно также, что значение, у которого причина пустоты имеет значение NINF (отрицательная бесконечность), не равно значению, у которого причина пустоты имеет значение PINF. В остальных

ГОСТ Р ИСО 21090-2016

вариантах обычно небезопасно возвращать что-либо, кроме значения с причиной пустоты nullFlavor (обычно N1 — нет информации).

Значение любого типа, имеющее причину пустоты nullFlavor, равную N1, у которого все другие атрибуты имеют пустое значение null или которое удовлетворяет данному условию рекурсивно, семантически эквивалентно значению null, определенному в языках UML/OCL, и при необходимости эти формы могут быть взаимно преобразованы. Большинство простых атрибутов объявлено, используя типы данных языков UML или OCL, например, строковый тип String, и при необходимости они могут быть преобразованы в соответствующие комплексные эквиваленты, например ST, у которых причина пустоты nullFlavor будет иметь значение N1.

Поскольку атрибут может быть или пустым, или обладать причиной пустоты nullFlavor, многие инварианты приобретают форму (x.ocllsDefined and x.isNotNull) implies {условие}. Для некоторых инвариантов такое правило не является необходимым, поскольку из промежуточного результата null (которому равно значение x.isNotNull, если х равен null) следует, что окончательный результат также null, и такой инвариант благополучно не будет выполнен, но в других случаях должна осуществляться защита от пустого значения null, чтобы во всех случаях можно было получить правильный результат.

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

Не все значения причины пустоты nullFlavor могут использоваться с любыми типами данных. Значения PINF и NINF могут использоваться только со специфичными типами (INT, REAL, PQ и TS). Значение UNC может использоваться только в типах данных, имеющих атрибут исходного текста originalText (CD, QTY, QSET и их специализации). Значения QS и TRC могут использоваться только в типе данных PQ.

Два значения причины пустоты ОТН и INV, а также другие их специализации отражают различие между действительным значением и значением, представленным в экземпляре. Некоторые из типов значений могут использоваться в качестве представления значения, которое требует последующего преобразования, генерирующего действительное значение. Например, может быть предоставлено выражение, обеспечивающее генерацию фактического значения, принадлежащего требуемому домену значений экземпляра. Другим примером служит некодированное значение типа CD, у которого задан только атрибут originalText. При значениях причины пустоты INV, DER и UNC существует возможность, что некоторое преобразование, основанное на дополнительной информации или дополнительном знании, может сгенерировать правильное значение. А значение причины пустоты ОТН и его специализации представляют собой утверждение, что никакого лучшего значения, скорее всего, не существует. Отсюда возникают вопросы доверия — насколько надежен источник, утверждающий, что лучшей информации нет, насколько надежна обработка, доверяющая такому источнику? Однако эти вопросы не разрешимы. Поэтому различие не должно приниматься как абсолютное, его надо трактовать как заявление о намерении со стороны источника.

Хотя значение причины пустоты INV и его специализации представляют исключительные значения в контексте их использования, оно является исключительным только в параметрах, определенных настоящим стандартом. Фактические значения всегда должны соответствовать правилам, определенным настоящим стандартом.

Значение причины пустоты DER должно использоваться только в том случае, когда из контекста, в котором оно применяется, точно известно, как фактическое значение может быть получено из представленной информации. В настоящем стандарте предусмотрено свойство QTY.expression (см. 7.8.2.3.1). В других элементах обработки информации могут быть сделаны иные описания использования значения DER, включенные в их объявления соответствия.

Примечание — Чаще всего правильным значением причины пустоты будет N1, и на разработчиков не возлагается дополнительная обязанность выбора или сохранения правильного значения причины пустоты. Во всех случаях сомнения, какое значение причины пустоты применимо за пределами тех технических требований, которые точно прописаны в настоящем стандарте в части использования значений NA, INV, DER, ОТН, PINF и NINF, разработчики вполне безопасно могут использовать значение N1. В частности, если пользователь не ввел значение в поле ввода процедуры сбора данных или данные отсутствуют по какой-то неизвестной причине, значение N1 может оказаться наиболее подходящим.

17

ГОСТ Р ИСО 21090-2016

Содержание

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

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

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

4    Сокращения.........................................................................3

5    Соответствие........................................................................4

5.1    Общие сведения..................................................................4

5.2    Непосредственное соответствие.....................................................4

5.3    Косвенное соответствие............................................................6

6    Обзор типов данных..................................................................7

6.1    Что такое тип данных?.............................................................7

6.2    Определения типов данных.........................................................8

6.3    Имена типов данных и повторное использование общераспространенных

имен типов данных...................................................................8

6.4    Отображение на настоящий стандарт типов данных....................................9

6.5    Соответствие ИСО/МЭК 11404 ......................................................9

6.6    Ссылки на язык UML 2.............................................................9

6.7    Моделирование типов данных.......................................................9

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

7.1    Общие свойства.................................................................13

7.2    Модель верхнего уровня..........................................................21

7.3    Базовые типы данных............................................................21

7.4    Текстовые и двоичные типы данных.................................................31

7.5    Кодированные типы данных (терминология)..........................................45

7.6    Типы данных идентификации и местонахождения.....................................58

7.7    Типы данных фамилии, имени, отчества и адреса.....................................68

7.8    Количественные типы данных......................................................90

7.9    Коллекции типов данных.........................................................113

7.10    Типы непрерывных множеств....................................................128

7.11    Типы данных, описывающие неопределенность.....................................145

7.12    Структурированный текст.......................................................148

Приложение А (обязательное) Представление на языке XML..............................165

Приложение В (обязательное) Вспомогательные типы данных UML...........................168

Приложение С (справочное) Отображение на точки зрения БМ-ОРО..........................171

Приложение D (справочное) Отображение на абстрактные типы данных документа HL7 V3.......172

Приложение Е (справочное) Схема для представления на языке XML.........................184

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

и документов национальным и    межгосудартсвенным стандартам...............185

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

ГОСТ Р ИСО 21090-2016

В таблице 4 приведены примеры выбора значений причин пустоты.

Таблица 4 — Примеры выбора значений причин пустоты

Сценарий	Выбранное значение причины пустоты
Пользователь не ввел значение в поле ввода экранной формы	N1
Источник не сконфигурирован для кодирования текстового значения в требуемой системе кодирования (codeSystem)	UNC
Источник не способен закодировать данное введенное текстовое значение в требуемой системе кодирования, поскольку в ней нет кодов, эквивалентных этому значению	ОТН
Пациент в бессознательном состоянии и не может назвать свою фамилию	NAV
Система не поддерживает данный элемент	N1
Дозировка не указана, но предоставлено выражение, с помощью которого система-получатель может вычислить правильную дозировку по весу пациента	INV
У пациента нет адреса — нет постоянного места жительства или бездомный	NA
Отчет о длительности продолжающегося побочного действия с помощью типа данных IVL<TS>	IVLhigh = NA, поскольку действие продолжается — понятие даты завершения неприменимо
Отчет о длительности побочного действия с помощью типа данных IVL<TS>, если неизвестно, завершилась ли она	IVLhigh = UNK — дата завершения неизвестна
Система-источник возвращает персональные данные пациента, но в соответствии с примененной политикой безопасности/конфиденциальности исключает из них адрес. Следует учитывать, что согласно обычной практике безопасности/конфиден-циальности получатель не уведомляется, что по уважительной причине какая-то информация от него закрыта. Однако в некоторых случаях рабочий процесс требует, чтобы пользователю было сообщено о закрытии информации. Значение причины пустоты MSK как раз и рассчитано на эти немногочисленные случаи	MSK

7.1.5 Соответствие

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

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

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

18

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

Информатизация здоровья ГАРМОНИЗИРОВАННЫЕ ТИПЫ ДАННЫХ ДЛЯ ОБМЕНА ИНФОРМАЦИЕЙ

Health Informatics. Harmonized data types for information interchange

Дата введения — 2018—01—01

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

Настоящий стандарт:

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

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

-    определяет семантику этих типов данных с помощью терминологии, нотации и типов данных, определенных в ИСО/МЭК 11404, тем самым расширяя комплекс типов данных, специфицированных в этом стандарте;

-    приводит определения этих же типов данных на языке UML, используя терминологию, нотацию и типы данных, определенные в спецификации унифицированного языка моделирования (Unified Modeling Language, UML) версии 2.0;

-    приводит представления этих типов данных на языке XML (extensible Markup Language).

Требования, определяющие область применения, в основном позаимствованы из HL7 версии 3,

ИСО/МЭК 11404, а также из CEN/TS 14796, ИСО 13606 (все части) и предшествующей работы в ИСО над типами данных, используемых в сфере здравоохранения.

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

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

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

ISO 4217, Codes for the representation of currencies and funds (Коды для представления валют и фондов)

ISO/IEC 8601 Data elements and interchange formats — Information interchange — Representation of dates and times (Элементы данных и форматы для обмена информацией. Обмен информацией. Представление дат и времени)

ISO/IEC 8824:1990 Information technology — Open Systems Interconnection — Specification of Abstract Syntax Notation One (ASN.1) [Информационные технологии. Взаимодействие открытых систем. Нотация абстрактного синтаксиса версии 1 (ASN.1)]¹)

^ Это издание было заменено на серию стандартов ИСО/МЭК 8824:2008 (все части).

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

ISO/IEC 11404:2007, Information technology — General-Purpose Datatypes (GPD) [Информационные технологии. Типы данных общего назначения (GPD)]

ISO/TS 22220, Health informatics — Identification of subjects of health care (Информатизация здоровья. Идентификация субъектов медицинской помощи)

IETF RFC 1738 — Uniform Resource Locators (URL) (Унифицированные указатели ресурсов)

IETF RFC 1950 — ZLIB Compressed Data Format Specification version 3.3 (Спецификация формата сжатия данных ZLIB версии 3.3)

IETF RFC 1951 — DEFLATE Compressed Data Format Specification version 1.3 (Спецификация формата сжатия данных DEFLATE версии 1.3)

IETF RFC 1952 — GZIP File Format Specification version 4.3 (Спецификация формата сжатия файлов GZIP версии 4.3)

IETF RFC 2045 — Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [Многоцелевые расширения электронной почты в Интернете (MIME). Часть 1. Формат тела сообщений в Интернете]

IETF RFC 2046 — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types [Многоцелевые расширения электронной почты в Интернете (MIME). Часть 2. Типы среды]

IETF RFC 2396 — Uniform Resource Identifiers (URI): Generic Syntax [Унифицированные идентификаторы ресурсов (URI). Общий синтаксис]

IETF RFC 2806 — URLs for Telephone Calls (Представление телефонных номеров в форме URL)¹) IETF RFC 3066 — Tags for the Identification of Languages (Теги для идентификации языков)

FIPS PUB 180-1 — Secure Hash Standard (Стандарт безопасной хеш-функции)

FIPS PUB 180-2 — Secure Hash Standard (Стандарт безопасной хеш-функции)²)

Open Group, CDE 1.1 — Remote Procedure Call specification, Appendix А (Спецификация вызова удаленной процедуры. Приложение А)

HL7 V3 Standard, Data Types — Abstract Specification (R2) (Типы данных. Абстрактная спецификация. Выпуск 2)

Regenstrief Institute, Inc. and the UCUM Organization The Unified Code for Units of Measure (Regenstrief Institute, Inc. and the UCUM Organization Унифицированные коды единиц измерения)³)

XML W3C Recommendation, XML Digital Signature (Рекомендации консорциума W3C. Электронная

ПОДПИСЬ)⁴)

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

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

3.1    атрибут (attribute): Характеристика объекта, которому присвоены тип и имя.

Примечание — Значение атрибута может меняться в течение жизненного цикла объекта.

3.2    класс (class): Дескриптор множества объектов, обладающих аналогичной структурой, поведением и связями.

3.3    код (code): Кодированное представление, опубликованное автором системы кодирования в качестве части системы кодирования и являющееся элементом данной системы кодирования.

3.4    система кодирования (code system): Управляемая коллекция идентификаторов понятий (обычно кодов), но иногда являющаяся более сложной системой правил и ссылок.

Примечание — Нередко системы кодирования описываются как коллекции уникально идентифицируемых понятий и ассоциированных с ними представлений, отношений и смысловых значений.

Примеры — МКБ-9, LOINC и SNOMED.

ГОСТ Р ИСО 21090-2016

3.5    понятие (concept): Унитарное мысленное представление реальной или абстрактной сущности; атомарная единица мышления.

Примечания

1    Понятие должно быть уникальным в данной системе кодирования.

2    Понятие может иметь синонимы в терминах представления и может быть простым или составным термином.

3.6    соответствие (conformance): Выполнение указанного требования; соответствие элемента обработки информации требованиям одной или нескольких специфичных спецификаций стандарта.

3.7    тип данных (datatype): Множество различных значений, характеризуемое свойствами этих значений и операциями над этими значениями.

3.8    перечисление (enumeration): Тип данных, экземпляры которого являются множествами литералов перечисления, задаваемых пользователем.

Примечание — Литералы имеют относительное упорядочение, но никакая алгебра над ними не определена.

3.9    генерализация (generalization): Отношение таксономии между более общим классом, интерфейсом или понятием и менее общим классом, интерфейсом или понятием.

Примечания

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

2    Более специфичный элемент полностью совместим с более общим элементом и содержит дополнительную информацию.

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

3.10    элемент обработки информации (information processing entity): Любая сущность, обрабатывающая информацию и содержащая понятие типа данных, включая другие стандарты, спецификации, средства и службы обработки данных.

3.11    наследование (inheritance): Механизм, с помощью которого более специфичные элементы наследуют структуру и поведение более общих элементов.

3.12    интерфейс (interface): Спецификация внешне видимой операции класса, не включающая в себя описание внутренней структуры.

3.13    инвариант (invariant): Правило о свойстве класса, которое всегда должно быть истинным.

3.14    операция (operation): Услуга, которая может быть запрошена у экземпляра класса.

Примечание — Операция имеет имя и список аргументов, которым присвоены имена и типы. Операция возвращает значение определенного типа.

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

3.16    набор строковых символов (string character set): Набор символов, используемых в стандарте для всего строкового содержания.

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

Примечание — Понятие может быть представлено с помощью отдельного кода или с помощью пост-координируемого сочетания кодов.

4 Сокращения

Для целей настоящего документа применяются следующие сокращения терминов:

CEN — Comite Europeen de Normalisation (European Committee for Standardization, a federation of 28 national standards bodies that are also ISO member bodies) (Европейский комитет по стандартизации, федерация из 28 национальных органов стандартизации, которые также являются членами ИСО);

CNE — Coded no exceptions (кодированный без исключений); ⁵

Coded with exceptions (кодированный с исключениями); General-Purpose Datatypes (типы данных общего назначения);

Health Level 7;

Internet Engineering Task Force (Инженерный совет Интернета);

Object Identifier (объектный идентификатор);

Object Management Group (группа управления объектами);

Unified Modelling Language (унифицированный язык моделирования); World Wide Web Consortium (консорциум World Wide Web); extensible Markup Language (расширяемый язык разметки).

5 Соответствие

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

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

Примечание — Термин «элемент обработки информации» используется в соответствии с определением 3.10. Аналогичным образом он описан в разделе 4 ИСО/МЭК 11404:2007, а именно: это определение охватывает прикладные программы, а также другие стандарты и спецификации.

5.2    Непосредственное соответствие

5.2.1 Определение непосредственного соответствия

Элемент обработки информации, непосредственно соответствующий данному стандарту, должен:

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

предусмотрены;

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

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

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

e)    если для представления этих типов данных в элементе применяется язык XML, то использовать XML-представления, приведенные в настоящем стандарте;

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

Приведенные выше требования препятствуют использованию спецификатора типа, определенного в настоящем стандарте в целях обозначения любого другого типа данных (однако следует учесть обсуждение области применения имен типов данных, приведенное в 6.2). Другие ограничения на определение элементом обработки информации дополнительных типов данных из них не вытекают. Например, элемент обработки информации, непосредственно соответствующий настоящему стандарту, может продолжать использовать типы данных общего назначения, определенные в ИСО/МЭК 11404, в дополнение к типам данных, предназначенным для здравоохранения.

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

Примерами элементов, для которых может быть обеспечено непосредственное соответствие, служат языковые определения или спецификации, выпускаемые для сферы здравоохранения, их на-

ГОСТ Р ИСО 21090-2016

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

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

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

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

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

5.2.2 Объявления соответствия

Для элемента обработки информации, объявляющего непосредственное соответствие настоящему стандарту, должно быть составлено объявление соответствия.

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

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

Наряду с требованиями, что объявления соответствия должны содержать формальные объявления о соответствии требованиям, указанным в пунктах а) — d) 5.2.1, настоящий стандарт дополнительно устанавливает следующие правила о том, что в этих объявлениях должно быть упомянуто, или рекомендуется упомянуть, или может быть выбрано.

Следующие правила обязательны для объявлений непосредственного соответствия:

a)    указание используемого набора символов и кодировки; по умолчанию — Unicode (см. 6.7.5);

b)    если для ведения истории изменений и аудита данных использован альтернативный способ, то описание его отображения на информацию об изменении и аудите типов данных (см. 7.1.3);

c)    пояснение способа указания кратности атрибутов и коллекций (см. 7.1.5);

d)    описание применения атрибутов nullFlavor, updateMode и flavorld типа данныхАЫУ (см. подраздел 7.3.3);

e)    если использованы типы данных физических величин, приведение точного описания того, как и когда в типе данных QTY применены атрибуты expression, originalText и атрибуты различных неопределенностей;

f)    пояснение, какие методы могут быть использованы для альтернативных определений уникальности дискретного множества (см. 7.9.3);

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

5

h) опишисание, в какой мере приемлем формат XML и указание используемого в нем пространства имен (см. А.1).

Следующие правила рекомендованы для объявлений непосредственного соответствия:

a)    определение правил по умолчанию языка (см. 7.4.2.3.7);

b)    указание, какие языки могут быть использованы в свойстве QTY.expression (см. 7.8.2.3.1);

c)    указание, какие коды могут быть использованы в свойстве QSC.code (см. 7.10.8.3);

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

В объявлениях непосредственного соответствия можно также придерживаться следующих правил:

a)    определять дополнительные атрибуты тонкости типов данных или указывать дополнительные уполномоченные органы в определениях атрибутов тонкости (см. 6.7.6);

b)    приводить дополнительные описания применения производныхданных и интерпретации значения DER свойства nullFlavor (см. 7.1.4);

c)    определять, каким образом используется свойство controlnformationRootExtension типа данных HXIT (см. 7.3.2.3.4);

d)    пояснять, как выбираются телекоммуникационные и почтовые адреса, предназначенные для конкретных целей (см. 7.6.2.3.2);

e)    указывать системы кодирования, используемые для различных компонентов типов данных фамилии, имени, отчества и адреса (см. 7.7.3.6 и 7.7.5.6).

5.3 Косвенное соответствие

5.3.1    Определение косвенного соответствия

Элемент обработки информации, косвенно соответствующий настоящему стандарту, должен:

a)    предусматривать отображение своих внутренних типов данных на типы данных, используемые в здравоохранении и соответствующие спецификациям раздела 7;

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

c)    указывать, используется ли представление типов данных в формате XML, описанное в настоящем стандарте, если типы данных представляются в этом формате, или, что не обязательно, предложить в XML-представлении альтернативное пространство имен;

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

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

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

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

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

5.3.2    Объявления соответствия

Для элемента обработки информации, объявляющего косвенное соответствие настоящему стандарту, должно быть составлено объявление соответствия.

ГОСТ Р ИСО 21090-2016

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

Наряду с требованиями, что объявления соответствия должны содержать формальные объявления о соответствии требованиям, указанным в пунктах а) — d) 5.3.1, настоящий стандарт устанавливает следующие дополнительнз1: правила о том, что в этих объявлениях должно быть упомянуто, или рекомендуется упомянуть, или может быть выбрано:

a)    указание используемого набора символов и кодировки; по умолчанию — Unicode (см. 6.7.5);

b)    описание, какие применяются отношения эквивалентности и каким способом (см. 7.1.2);

c)    поясание способа указания кратности атрибутов и коллекций, если таковое имеет место (см. 7.1.5);

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

Следующие правила рекомендованы для объявлений косвенного соответствия:

a)    определение правил по умолчанию языка (см. 7.4.2.3.7);

b)    описание отображения между электронной подписью, определенной в спецификации организации W3C, и альтернативными реализациями, если таковые имеют место (см. 7.4.5.1).

В объявлениях непосредственного соответствия можно также придерживаться следующих правил:

a)    определять дополнительные атрибуты тонкости типов данных или указывать дополнительные уполномоченные органы в определениях атрибутов тонкости (см. 6.7.6);

b)    приводить дополнительные описания применения производныхданных и интерпретации значения DER свойства nullFlavor (см. 7.1.4);

c)    определять, каким образом используется свойство controInformationRootExtension типа данных HXIT (см. 7.3.2.3.4);

d)    пояснять, как выбираются телекоммуникационные и почтовые адреса, предназначенные для конкретных целей (см. 7.6.2.3.2);

e)    указывать системы кодирования, используемые для различных компонентов типов данных фамилии, имени, отчества и адреса (см. 7.7.3.6 и 7.7.5.6);

f)    указывать, какие языки могут использоваться в свойстве QTY.expression (см. 7.8.2.3.1);

д) указывать, какие коды могут использоваться в свойстве QSC.code (см. 7.10.8.3);

h) если используются типы данных структурированных документов, описывать, каким образом обеспечивается версионность в том контексте, где она применяется (см. 7.12.12.2.1).

6 Обзор типов данных

6.1 Что такое тип данных?

В ИСО/МЭК 11404 тип данных определен как множество различных значений, характеризуемое свойствами этих значений и операциями над этими значениями (ИСО/МЭК 11404:2007, подраздел 3.12).

Тип данных образован тремя основными свойствами:

-    пространство значений;

-    множество свойств;

-    множество характеристических операций.

В общем случае определения области применения типа данных вращаются вокруг того или иного из следующих понятий;

-    неизменность (свойства типа данных не могут меняться, если только не создан новый экземпляр: у типов данных нет жизненного цикла);

-    тождество эквивалентности и идентичности (если два типа данных эквивалентны, то они являются одним и тем же экземпляром);

-    связность отдельного понятия (каждый тип данных должен представлять пространство отдельных понятий).

7

1

^ Заменен на документ IETF RFC 3966.

2

)    Редакция документа FIPS PUB 180-1.

3

)    Regenstrief Institute, Inc. and the UCUM Organization, Indianapolis, Indiana, USA. — http://aurora.regenstrief. org/ucum (ссылка от 23 августа 2010 г.).

4

)    World Wide Web Consortium (W3C). — http://www.w3.org/TR/xmldsig-core/ (ссылка от 23 августа2010 г).

5