ГОСТ Р ИСО 21090-2016. Национальный стандарт Российской Федерации. Информатизация здоровья. Гармонизированные типы данных для обмена информацией

(утв. и введен в действие Приказом Росстандарта от 29.11.2016 № 1840-ст)

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

ИНФОРМАТИЗАЦИЯ ЗДОРОВЬЯ

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

Health Informatics. Harmonized data types for information interchange

(ISO 21090:2011, IDT)

ГОСТ Р ИСО 21090-2016

Предисловие

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)

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)] <1>

<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) <1>

<1> Заменен на документ IETF RFC 3966.

IETF RFC 3066 — Tags for the Identification of Languages (Теги для идентификации языков)

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

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

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

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

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 Унифицированные коды единиц измерения) <3>

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

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

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

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

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

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

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

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

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

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

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

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

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 — Comité Européen de Normalisation (European Committee for Standardization, a federation of 28 national standards bodies that are also ISO member bodies) (Европейский комитет по стандартизации, федерация из 28 национальных органов стандартизации, которые также являются членами ИСО);

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

CWE — Coded with exceptions (кодированный с исключениями);

GPD — General-Purpose Datatypes (типы данных общего назначения);

HL7 — Health Level 7;

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

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

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

UML — Unified Modelling Language (унифицированный язык моделирования);

W3C — World Wide Web Consortium (консорциум World Wide Web);

XML — eXtensible Markup Language (расширяемый язык разметки).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

h) описание, в какой мере приемлем формат XML и указание используемого в нем пространства имен (см. A.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) определять, каким образом используется свойство controInformationRootExtension типа данных 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 Объявления соответствия

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

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

Наряду с требованиями, что объявления соответствия должны содержать формальные объявления о соответствии требованиям, указанным в пунктах a) - d) 5.3.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);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Такой шаблон «обертки примитивного типа данных» используется для типов данных 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 и определенных в спецификации языка ограничений объектов OCL 2:

• enumeration;
• boolean;
• integer;
• string;
• collection;
• sequence;
• set;
• bag.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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-имя.

Примеры

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

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

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

6.7.7 Примеры

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

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

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

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

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

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

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

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

7.1.2 Равенство

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• значение OTH из перечисления NullFlavor для кодируемого типа данных CD;
• значения NINF и PINF для типа данных CD из перечисления NullFlavor соответственно для нижней и верхней границы интервала;
• значение OTH из перечисления NullFlavor для типа данных идентификатора II, у которого нет корня root, но есть расширение extension.

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

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

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

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

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

этого атрибута тонкости;
    - <a id="p100439"></a>если у операции есть параметры и какой-либо из них имеет значение
null, определенное в языках UML/OCL, то результатом является null;
    - <a id="p100440"></a>если в выполнение операции вовлечено значение null  или значение,

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

несколько исключений для специфичных операций;

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

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

несколько исключений для специфичных операций;
    - <a id="p100444"></a>в остальных случаях операция выполняется, как предписано.

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

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

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

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

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

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

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

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

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

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

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

Таблица 4

Примеры выбора значений причин пустоты

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

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

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

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

В контексте использования может также задаваться кратность атрибута. Кратность состоит из минимального значения, выраженного целым числом, и максимального значения, выраженного целым числом или символом «». Кратность обычно представляется в виде «[минимальное значение]..[максимальное значение]», например, 0..1 или [1..]. Смысловые значения кратности у атрибутов, основанных на коллекциях, и других атрибутов отличаются.

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

Примечания

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

2 В случае коллекции, имеющей атрибут «обязательна», коллекция должна содержать не менее одного непустого элемента (то есть не равного null и не имеющего какой-либо причины пустоты nullFlavor).

Другим атрибутам могут быть присвоены только значения кратности 0..0, 0..1 или 1..1. Кратность 0 означает, что атрибут не должен быть представлен в экземпляре и неявно имеет значение причины пустоты NI. Кратность 1 означает, что атрибут имеет значение, хотя оно может иметь некоторое значение пустоты, но только в том случае, если этот атрибут не объявлен обязательным.

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

Примечание — Такое использование кратности несколько отличается от стандартного описания кратности атрибутов в языке UML. Если в этом языке атрибуту присвоены тип DSET(CS) и кратность 2..3, то это означает, что должно быть два или три множества значений типа данных. Эти варианты использования кратности не являются несовместимыми, оба могут использоваться элементами обработки информации, объявляющими непосредственное или косвенное соответствие. Из документации должно точно следовать, какой именно из этих вариантов использован.

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

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

7.3.1 Введение

Базовые типы данных обеспечивают инфраструктурную поддержку специфичных типов данных, определенных в следующих подразделах (см. рисунок 2).

7.3.2 Тип данных HXIT

7.3.2.1 Описание

Абстрактный и частный (private) — этот тип данных не должен быть использован вне типов данных, определенных в настоящем стандарте.

Информация об истории значения: срок действия и ссылка на идентифицируемое событие, которое ввело данное значение в действие.

Вследствие способа определения типов данных ряду их атрибутов присвоены типы данных, произведенные от HXIT. В этих случаях атрибуты HXIT ограничены пустыми значениями. Единственным случаем, когда атрибуты HXIT разрешены в типе данных, служит элемент коллекции (DSET, LIST, BAG, HIST).

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

7.3.2.2 Синтаксис ИСО/МЭК 11404

type HXIT = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controlInformationRoot : characterstring,

controlInformationExtension : characterstring

)

7.3.2.3 Атрибуты

7.3.2.3.1 validTimeLow: String : момент времени, когда данная информация стала или станет действительной.

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

7.3.2.3.2 validTimeHigh: String : момент времени, когда данная информация перестала или перестанет быть правильной.

Оба атрибута validTimeLow и validTimeHigh должны быть допустимыми штампами времени, представленными в формате, описанном в 7.8.10.3.1 (значение TS.value).

7.3.2.3.3 controlInformationRoot: Uid: корень идентификатора события, связанного с присвоением типу данных его указанного значения.

7.3.2.3.4 controlInformationExtension : String: расширение идентификатора события, связанного с присвоением типу данных его указанного значения.

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

7.3.2.4 Равенство

Поскольку тип данных HXIT является абстрактным и частным, равенство его экземпляров не определено. Атрибуты класса HXIT (validTimeLow, validTimeHigh, controlInformationRoot, controlInformationExtension) никогда не участвуют в определении равенства специализаций этого класса.

7.3.2.5 Инварианты

Если атрибут controlInformationExtension присутствует, то должен присутствовать и атрибут ControlInformationRoot.

Представление инвариантов на языке OCL:

def: let noHistory : Boolean =

validTimeLow.oclIsUndefined and

validTimeHigh.oclIsUndefined and

controlInformationRoot.oclIsUndefined and

controlInformationExtension.oclIsUndefined

inv «extension requires root»:

controlInformationExtension.oclIsDefined implies

controlInformationRoot.oclIsDefined

7.3.2.6 Пример

<example

xsi:type=«ST» value=«Это некоторое содержание»

validTimeLow=«200506011000» validTimeHigh=«200507031500»

controlInformationRoot=«1.2.3.4.5.6»>

В этом примере значение атрибута «Это некоторое содержание» было действительно с 10:00 1 июня по 15:00 3 июля 2005 года. Значение «Это некоторое содержание» было присвоено в связи с событием, идентифицируемым ОИД 1.2.3.4.5.6. Некоторая где-то находящаяся информационная система (определение ее местонахождения должно быть описано в применимом профиле соответствия) способна преобразовать этот ОИД в ссылку, которая может использоваться для идентификации пользователя, осуществившего ввод данного значения в систему.

7.3.3 Тип данных ANY

7.3.3.1 Описание

Специализация типа данных HXIT

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

Однако исключительные значения (имеющие причину пустоты nullFlavor) могут иметь тип данных ANY, кроме исключительных значений, у которых подразумевается причина пустоты INV, поскольку для них тип данных должен быть значащим. Следует обратить внимание на то, что не все значения причины пустоты допустимы в типе данных ANY (дополнительные детали см. в 7.1.4).

7.3.3.2 Синтаксис ИСО/МЭК 11404

type ANY = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controlInformationRoot : characterstring,

controlInformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorId : Set(characterstring)

)

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

7.3.3.3 Атрибуты

7.3.3.3.1 nullFlavor : NullFlavor: если значение не является правильным, в этом атрибуте указана причина.

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

Примечание — Понятие причины пустоты nullFlavor включает в себя понятие пустого значения null, определенного в языке UML, а также потенциально полностью заполненные экземпляры, не соответствующие требованиям, предъявляемым к экземпляру (называемые также «исключительными экземплярами»).

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

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

Синтаксис ИСО/МЭК 11404 атрибута nullFlavor:

type NullFlavor = enumerated (NI, INV, OTH, NINF, PINF, UNC, DER, UNK, ASKU, NAV, QS, NASK, TRC, MSK, NA)

При этом, не все значения причины пустоты nullFlavor применимы ко всем типам данных. Причины NINF, PINF, QS и TRC должны использоваться только с типами данных количества QTY. Причина пустоты UNC должна использоваться только с типом данных, у которого есть свойство originalText, и если UNC используется, то свойство originalText должно быть непустым. Если используется причина пустоты DER, то должно непустым выражение expression.

7.3.3.3.2 updateMode : UpdateMode: это свойство позволяет системе-отправителю идентифицировать роль, которую этот атрибут играет в обработке экземпляра, которому он принадлежит.

Если это свойство не пусто, то его значение должно быть взято из системы кодирования HL7 UpdateMode. Текущие значения приведены в таблице 6.

Синтаксис ИСО/МЭК 11404 атрибута updateMode:

type UpdateMode = enumerated (A, D, R, AR, N, U, K)

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

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

7.3.3.3.3 flavorId : Set(String): сигнализирует о наложении на тип данных одного или нескольких множеств ограничений. Единственное назначение указания того, что существует дополнительное ограничение типа данных, заключается в обеспечении проверки экземпляра: средства контроля могут найти правила, заданные с помощью атрибута flavorId, и подтвердить, что экземпляр удовлетворяет этим правилам. Никакая другая обработка не должна зависеть от значения атрибута flavorId.

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

Дополнительное обсуждение использования атрибутов тонкостей типов данных и атрибута flavorId приведены в разделе A.3.

7.3.3.4 Равенство equals

7.3.3.4.1 По умолчанию равенство equals определяется в соответствии с нижеизложенным. Отдельные специализации типа данных ANY переопределяют равенство equals в целях указания семантики вычисления равенства для этих специализаций. Для каждого типа данных точно документируется вычисление равенства equals.

7.3.3.4.2 В таблице 7 суммируются отношения между значениями null, nullFlavor и равенством equals.

Согласно общему алгоритму равенства equals два значения равны, если они имеют одинаковый типа данных и если равны все атрибуты, не унаследованные от типов данных HXIT и ANY. Если какой-либо из приравниваемых атрибутов имеет пустое значение null или причину пустоты nullFlavor, то результат равен пустому значению null или первой общей генерализации причин пустоты (см. комментарии к сравнению причин пустоты в 7.1.4.

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

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

Операции равенства equals не переопределяют ни операцию «=», определенную в языке OCL, ни обычный эквивалент последней, используемой в любой платформе реализации. Она определяет семантическое равенство.

Примечание — При проверке равенства атрибуты updateMode и flavorId всегда игнорируются.

7.3.3.5 Инварианты

Экземпляр может иметь тип данных ANY (а не его специализацию), если у него есть причина пустоты nullFlavor, у которой не подразумевается значение INV.

Представление инвариантов на языке OCL:

7.3.3.6 Операции

7.3.3.6.1 equals(other : ANY) : BL: указывает, считается ли это значение данных семантически равным другому значению данных (other), то есть имеют ли одинаковый смысл. Обсуждение определения этой операции см. в 7.3.3.4.

7.3.3.6.2 isNull() : Boolean: указывает, имеет ли это значение причину пустоты nullFlavor или нет.

Эта операция является исключением из общих правил, описанных для операций и для причин пустоты: она возвращает true, если значение имеет причину пустоты nullFlavor, и false в противном случае.

7.3.3.6.3 notNull() : Boolean: указывает, имеет ли это значение причину пустоты nullFlavor или нет.

Эта операция является исключением из общих правил, описанных для операций и для причин пустоты: она возвращает true, если значение не имеет причину пустоты nullFlavor, и false в противном случае.

7.3.3.7 Примеры

7.3.3.7.1 Неизвестное значение

Значение не известно, и не известен также тип значения (он не указан в экземпляре и не определяется контекстом).

7.3.3.7.2 Пустое значение null и причина пустоты nullFlavor

Ниже приведено представление кодированного понятия как значения простого типа данных (см. 7.5.1).

У этого значения заданы атрибуты code, codeSystem и displayName. Все другие атрибуты пусты. В смысловых терминах это значение идентично следующему:

Они имеют один и тот же смысл, поскольку в случае пустоты атрибута о нем можно сказать только то, что о его значении нет информации и причина этого неизвестна, то есть утверждать ровно то, что предусмотрено в значении пустоты nullFlavor.NI: нет информации, почему это значение не является правильным.

Аналогичным образом тот же смысл имеет следующее значение:

< example code=«784.0» codeSystem=«2.16.840.1.113883.6.42»>

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

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

< example code=«784.0» codeSystem=«2.16.840.1.113883.6.42»>

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

7.3.3.7.3 Атрибут updateMode

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

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

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

В первом наборе примера рассмотрен простой случай, когда объектная модель имеет простой атрибут даты рождения лица birthDate:TS.

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

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

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

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

означающему, что дата рождения должна быть заменена на пустое значение с причиной пустоты NI. Как видно из этого примера, в подобных случаях в атрибуте updateMode нет особой необходимости. Он становится полезным, когда необходимо различать информацию, переданную в связи с ее изменением (UpdateMode.R), от информации, переданной для обеспечения идентификации. Для иллюстрации этого предположим, что в соглашении о транзакционной обработке было указано, что при изменении записи о пациенте в качестве идентификационных данных всегда должны передаваться фамилия, имя, отчество, пол и дата рождения. В этом случае экземпляр всегда содержит дату рождения. Используя значение атрибута updateMode, равное «K» (ключ), можно отметить, что атрибут даты рождения birthDate передан для идентификации, а не в связи с его изменением:

Атрибут updateMode начинает приносить реальную пользу при управлении списками. В следующей группе примеров это демонстрируется на списке контактной информации пациента.

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

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

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

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

с инструкцией о замене существующего номера. Однако какой номер следует заменить? На это нет ответа, поскольку совпадение основано на равенстве, значит, этот фрагмент означает замену номера домашнего телефона +12315559876 на номер +12315559876.

Поэтому лучше использовать операции удаления (D) и добавления (A), указывая значения типа данных. Операции замены (R) и добавления/замены (AR) не очень полезны: поскольку совпадение основано на равенстве, все, что можно сказать, это заменить значение A на значение A, что не имеет особого смысла. В общем случае полезнее использовать сложные объекты, включаемые в список допустимых значений типа данных, тем самым обеспечивая удовлетворение всех известных вариантов транзакционной обработки.

Существует пример, в котором можно использовать значение UpdateModel.R. Поскольку совпадение основано на равенстве, в котором используется передаваемый номер, то следующие два экземпляра несут один и тот же смысл:

Оба этих экземпляра означают, что существующие детали использования номера +12315559876, а именно use (назначение) и capabilities (функции), надо заменить на новые.

7.3.4 Тип данных BL

7.3.4.1 Описание

Специализация типа данных ANY

Тип данных BL используется для значений двузначной логики. Значение типа BL может быть равно true или false либо может иметь причину пустоты nullFlavor.

7.3.4.2 Синтаксис ИСО/МЭК 11404

type BL = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controlInformationRoot : characterstring,

controlInformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorId : Set(characterstring),

value : boolean

)

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

Таблица 8

Таблица истинности

В этой таблице null означает либо настоящее пустое значение null, либо пустое значение с причиной пустоты nullFlavor. Если это настоящее пустое значение (или одно из нескольких настоящих пустых значений), то результатом будет настоящее пустое значение. Если булевская операция выполняется над двумя значениями типа данных BL с разными причинами пустоты nullFlavor, то значением причины пустоты результата должно быть значение какого-либо общего родителя двух различных причин пустоты nullFlavor. Рекомендуется в качестве результата использовать первого общего родителя.

7.3.4.3 Атрибуты

7.3.4.3.1 value : Boolean: значение типа BL

Это пример шаблона обертки примитивного типа. Дополнительная информация приведена в 6.3.

7.3.4.4 Равенство

Два булевских значения равны, если они не пусты (свойство nonNull равно true) и имеют одно и то же значение.

7.3.4.5 Инварианты

Если причина пустоты nullFlavor не указана, то экземпляр типа данных BL должен иметь значение.

Представление инвариантов на языке OCL:

7.3.4.6 Операции

7.3.4.6.1 and(other : BL) : BL: результат равен true, если оба значения равны true Результат равен false, если хотя бы одно из значений равно false. В остальных случаях результат равен null или имеет причину пустоты nullFlavor.

7.3.4.6.2 or(other : BL) : BL: результат равен true, если данное значение или значение параметра other равно true Результат равен false, если оба значения равны false. В остальных случаях результат равен null или имеет причину пустоты nullFlavor.

7.3.4.6.3 xor(other : BL) : BL: результат равен true, если данное значение и значение параметра other различны. Результат равен false, если оба эти значения одинаковы. В остальных случаях результат равен null или имеет причину пустоты nullFlavor.

7.3.4.6.4 implies(other : BL) : BL: результат равен true, если данное значение равно false или данное значение и значение параметра other равны true. Результат равен false, если данное значение равно true, и значение параметра other равно false. В остальных случаях результат равен null или имеет причину пустоты nullFlavor.

7.3.4.6.5 not() : BL: результат равен false, если данное значение равно true. Результат равен true, если данное значение равно false. В остальных случаях результат равен null или имеет причину пустоты nullFlavor.

Примечание — В силу особой природы этих логических операций они не всегда следуют общим правилам, описанным для значений причин пустоты nullFlavor и операций. Например, выражение «(null/nullFlavored) or true» всегда имеет значение true, поскольку безразлично, равно ли отсутствующее значение true или false: результат будет одинаков. Кроме того, с точки зрения реализации эти операции строго симметричны, и для предотвращения ошибок реализации при выполнении операций над пустыми объектами null может потребоваться некоторая специальная обработка.

7.3.4.7 Примеры

7.3.4.7.1 Простое значение true

7.3.4.7.2 Неизвестное значение

7.3.5 BL.NONNULL

7.3.5.1 Описание

Атрибут тонкости, ограничивающий тип данных BL

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

7.3.5.2 Инварианты

BL.NONNULL не может иметь причину пустоты nullFlavor.

Представление инвариантов на языке OCL:

inv «cannot have a nullFlavor»: not isNull

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

7.4.1 Введение

7.4.2 Тип данных ED (Encapsulated Data — инкапсулированные данные)

7.4.2.1 Описание

Специализация типа данных ANY

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

Инкапсулированные данные могут присутствовать в двух формах: по значению или по ссылке. Их содержание является тем же самым вне зависимости от того, присутствуют ли они как местные, по значению, или как удаленные, по ссылке. Местные данные передаются или перемещаются как часть значения инкапсулированных данных, в то время как ссылочные данные могут находиться в другом месте: в качестве ссылки на эти данные используется идентификатор URL или URI. Данные, передаваемые по значению, могут быть представлены тремя разными способами:

• как последовательность символов (в атрибуте value);
• как двоичные данные (последовательность байтов) (в атрибуте data);
• как xml-содержание (в атрибуте xml).

Если у значения типа данных ED не задан атрибут причины пустоты nullFlavor, то оно должно иметь непустое содержание. Оно может быть предоставлено по значению (в одном из атрибутов value, data или xml) или по ссылке. Содержание может быть представлено одновременно и по ссылке, и по значению, в этом случае оба экземпляра содержания должны быть идентичными. Элементы обработки информации не обязаны проверять это условие, но могут рассматривать несовпадение как ошибку.

7.4.2.2 Синтаксис ИСО/МЭК 11404

type ED = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controlInformationRoot : characterstring,

controlInformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorId : Set(characterstring),

value : characterstring,

data : Sequence(Octet),

xml : XML,

reference : TEL.URL,

mediaType : characterstring,

charset : characterstring,

language : characterstring,

compression : Compression,

integrityCheck : Sequence(Octet),

integrityCheckAlgorithm : IntegrityCheckAlgorithm,

description : ST,

thumbnail : ED,

translation : Set(ED)

)

7.4.2.3 Атрибуты

7.4.2.3.1 value : String: простая последовательность символов, представляющая содержание.

Если используется атрибут value, то атрибут mediatype имеет фиксированное значение text/plain и набор символов должен быть совместим с набором символов типа данных String. Дополнительная информация представлена в 6.7.5.

7.4.2.3.2 data : Binary: простая последовательность байтов, представляющая содержание.

7.4.2.3.3 xml : XML: содержание в формате XML.

Данный атрибут имеет непосредственное представление на языке XML. Это обусловлено тем, что настоящий стандарт предусматривает сериализацию данных на языке XML, и этот атрибут xml специально предназначен для обработки в сериализованной форме. Семантически значение атрибута xml ничем не отличается от представления тех же данных в атрибуте value или data.

Примечание — Эти три представления данных типа ED — как последовательность символов, последовательность байтов или на языке XML в нативном формате XML format — взаимно несовместимы и должны были бы быть реализованы как три специализации абстрактного родительского типа ED. Однако это значительно усложнило бы определение и реализацию тонкостей типа данных ED, а также соответствующий XML-формат (его потребовалось бы дополнить обязательным атрибутом xsi:type) и при этом не упростило бы заметно общую реализацию типа данных ED.

7.4.2.3.4 reference: TEL.URL: адрес URL, по которому находится двоичное содержание.

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

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

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

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

7.4.2.3.5 mediaType : Code: идентифицирует тип среды инкапсулированных данных и может использоваться для определения метода интерпретации или изображения содержания этих данных.

Домен типов среды, определенных организацией IANA, описан в документах RFC 2045 и 2046 организации IETF. По умолчанию атрибут mediaType имеет значение text/plain и не может быть пустым. Если тип среды отличается от text/plain, то атрибут mediaType должен иметь значение.

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

7.4.2.3.6 charset : Code: код, присвоенный набору символов и кодировке символьной информации организацией Internet Assigned Numbers Authority (IANA) и положениями документа RFC 2978 [http://www.ietf.org/rfc/rfc2978.txt].

Свойство charset должно быть известно, если значение типа ED представляет собой символьные данные в любой форме. Если данные присутствуют непосредственно в атрибуте value, то набор символов должен быть известным и совместимым с набором символов типа данных String (дополнительную информацию см. в 6.7.5). Если эти данные предоставляются по ссылке и метод доступа не обеспечивает идентификацию набора символов содержания (обычно возвращаемую в заголовке MIME), то эта идентификация должна быть указана как компонент типа данных ED.

7.4.2.3.7 language : Code: человеческий язык содержания. Допустимые коды берутся из документа RFC 3066 организации IETF. Если этот атрибут пуст, то язык может быть идентифицирован откуда-то еще, например, из содержания или из тега языка в кодировке unicode.

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

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

7.4.2.3.8 compression : Compression: алгоритм сжатия, если таковой был применен к исходным байтовым данным. Если этот атрибут пуст, то данные не являются сжатыми. Сжатие применяется только к двоичной форме содержания. Если он имеет значение, то оно должно быть взято из системы кодирования HL7 CompressionAlgorithm (см. таблицу 9).

Таблица 9

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

Синтаксис ИСО/МЭК 11404 атрибута сжатия:

type Compression = enumeration (DF, GZ, ZL, Z, BZ, Z7)

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

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

Контрольная сумма integrityCheck вычисляется с помощью алгоритма, указанного в атрибуте integrityCheckAlgorithm. По умолчанию должен использоваться алгоритм Secure Hash Algorithm-1 (SHA-1). Контрольная сумма представляется в двоичном виде в соответствии с правилами, принятыми в алгоритме контрольного суммирования.

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

7.4.2.3.10 integrityCheckAlgorithm : IntegrityCheckAlgorithm: алгоритм, использованный для вычисления значения атрибута integrityCheck.

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

Синтаксис ИСО/МЭК 11404 атрибута integrityCheckAlgorithm:

type IntegrityCheckAlgorithm = enumeration (SHA1, SHA256)

7.4.2.3.11 description : ST: альтернативное описание мультимедийных данных, используемое, если контекст не позволяет отобразить эти данные.

Например, краткое текстовое описание изображения или аудиоклипа и т.д. Этот атрибут не предназначен для полной подстановки вместо оригинала. Для полной подстановки используйте свойство «translation» (перевод).

Этот атрибут предназначен для удовлетворения требований передачи информации о нетрудоспособности, например, тех, которые описаны в законе Americans with Disability Act (известном также как «Section 508»), требующем, чтобы вложенные мультимедийные данные сопровождались кратким текстовым описанием, которое может быть прочтено в экранной форме. Это похоже на очень краткий «эскиз» для типа среды mediaType = text/plain.

7.4.2.3.12 thumbnail : ED: сокращенная форма полного содержания. Этот атрибут содержит сокращенное представление полных данных (эскиз), требующее гораздо меньше ресурсов, нежели полные данные, но при этом обладающее отличительными способностями полных данных. Обычно эскизы используются для ссылочных инкапсулированных данных. Они позволяют пользователю выбирать нужные данные, не загружая по ссылке их полное представление.

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

Эскиз не может содержать вложенный эскиз.

7.4.2.3.13 translation : Set(ED): перевод, то есть альтернативное представление того же самого содержания на другом языке или в другом типе среды mediaType.

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

7.4.2.4 Равенство

Два значения типа ED равны только том случае, если у них одинаковы типы среды mediaType и данные. Если значения типа ED содержат ссылочные или сжатые (упакованные) данные, то в проверке на равенство должны участвовать данные, извлеченные по ссылке и распакованные (каноническое содержание, см. 7.4.2.6.1). Свойства сжатия compression, эскиза thumbnail и ссылки reference в проверке на равенство не участвуют. Кроме того, из этой проверки исключается свойство языка language (см. 7.4.2.7.2). Если типом среды mediaType являются символьные данные и при этом свойства набора символов (charset) не одинаковы, то перед проверкой надо отобразить данные на общий набор символов.

Значение типа данных ED, у которого содержание имеет тип среды mediaType, равный text/plain, может быть также равно значению типа данных ST при условии выполнения описанных выше правил.

7.4.2.5 Инварианты:

• один из атрибутов reference, data, value или xml должен присутствовать, и хотя бы один байт данных должен быть доступен по ссылке, если значение типа ED не имеет причины пустоты nullFlavor;
• может присутствовать только один из атрибутов data, value или xml.
• атрибут integrityCheckAlgorithm должен быть указан только в том случае, если присутствует атрибут integrityCheck;
• если присутствует атрибут эскиза thumbnail, то он не должен включать в себя атрибут ссылки reference;
• если присутствует атрибут эскиза thumbnail, то он не должен включать в себя атрибут эскиза thumbnail;
• атрибут сжатых данных compression может быть указан только в том случае, если данные являются двоичными или предоставляются по ссылке;
• атрибут типа среды mediatype не может быть пустым;
• если значение передается в атрибуте value, то атрибут типа среды имеет значение plain/text;
• набор символов не должен объявляться для содержания, передаваемого в виде текста или в формате XML (описание текстового формата см. в 6.7.5, а в формате XML предусмотрено внутреннее указание набор символов).

Представление инвариантов на языке OCL:

7.4.2.6 Операции

7.4.2.6.1 canonical : Binary: последовательность байтов, представляющая фактические данные.

Примечания

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

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

3 Если значение типа данных ED имеет причину пустоты nullFlavor, то операция возвращает пустое значение.

7.4.2.7 Примеры

7.4.2.7.1 Простой текст

Эти значения типа ED являются примерами простого текста. Типу среды mediaType присвоено значение text/plain. Поскольку оно является значением этого атрибута по умолчанию, то его не надо указывать, когда данные представляются на языке XML, и второй пример также правилен. Набор символов не указан; в данном случае набор символов не должен задаваться, он определяется заголовком XML.

7.4.2.7.2 Язык

В первом случае язык явно задан как английский, во втором — как немецкий. Если атрибут language отсутствует, то язык не известен, хотя обычно безопасно считать, что используется наиболее широко распространенный местный язык. Типу присвоен атрибут тонкости ED.TEXT, то есть только текст.

Здесь немецкая версия присутствует как перевод английской версии.

translation xsi:type=«ED» value=«ce ci est du texte non structure»

language=«fr-ca»/>

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

7.4.2.7.3 Двоичное содержание

dGhpcyBpcyBiaW5hcnkgY29udGVudA==

ЭТО значение типа ED содержит простой текст «this is binary content» (это двоичное содержание). Поскольку атрибут типа среды mediaType имеет значение text/plain, то его указывать не надо, так как он имеет это значение по умолчанию.

Примечание — Набор символов в этом примере не известен; он не обязательно совпадает с тем, который использован в XML-значении, и предположение такого совпадения не является безопасным.

dGhpcyBpcyBiaW5hcnkgY29udGVudA==

По этой причине при использовании элемента данных data обычно стоит указывать набор символов, как это показано выше в примере.

7.4.2.7.4 Ссылка

Содержание этого значения типа ED находится по адресу «http://www.tempuri.org/XXXXXXXXXXX». При загрузке данных по этой ссылке возвращается двоичный поток байтов, в заголовке ответа HTTP будет указан тип среды «image/jpg».

Примечание — Протокол http непосредственно поддерживает сжатие данных. Однако атрибут compression типа данных ED имеет отношение не к тому сжатию, информация о котором возвращается в заголовке ответа HTTP, а к тем данным, которые получатся после того, как ответ HTTP будет завершен и интерпретирован.

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

7.4.2.7.5 Содержание на языке XML

PHBhcmVudD4NCiAgPGNoaWxkPlRoaXMgaXMgc29tZSB0ZXh0IGluIHRoZSBjaGlsZDwvY-

2hpbGQ+DQogIFRoaXMgaXMgc29tZSB0ZXh0IGluIHRoZSBwYXJlbnQNCjwvcGFyZW50Pg==

Это значение типа ED представляет собой некоторое содержание на языке XML, представленное в двоичной форме. Как и в предыдущем примере, набор символов XML-содержания не известен; оно не обязательно совпадает с тем, и которое используется в данном значении типа ED, и предположение о таком совпадении не является безопасным.

PHBhcmVudD4NCiAgPGNoaWxkPlRoaXMgaXMgc29tZSB0ZXh0IGluIHRoZSBjaGlsZDwvY-

2hpbGQ+DQogIFRoaXMgaXMgc29tZSB0ZXh0IGluIHRoZSBwYXJlbnQNCjwvcGFyZW50Pg==

В данном примере набор символов задан явно. Он не обязательно совпадает с кодировкой, указанной в XML-документе.

В этом примере xml-содержание представлено в виде значения элемента xml. Значение атрибута типа среды mediaType этого содержания должно быть представлено (оно не может быть равно text/plain). Набор символов не может быть задан, поскольку он должен совпадать с тем, который указан в заголовке xml.

7.4.2.7.6 Другие типы содержания

/9j/4AAQSkZJRgABAgEAgACAAAD/2wCEAAICAgIC

AQICAgICAgICAwQDAwMDAwUEBAMEBgYHBgYG

BgYHCAoIBwcJBwYGCAsJCQoKCwsLBwgMDQwKDAoLCwoBAgIC

AwMDBQMDBQoHBgcKCgoKCgoKCgoK

CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgo

KCv/AABEIAg4CuQMBIQACEQED

EQH / xAG i AAABBQEBAQEBAQAAAAAAAAAAAQI DBAUGBwg JCgs BAAM

BAQEBAQEBAQEAAAAAAAABAgME

BQYHCAkKCxAAAgEDAwIEAwUFBAQAAAF 9AQIDAAQRBRIhMUEGE1F

hByJxFDKBkaEIIOKxwRVSOfAk

...

CigAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKAC

gAooAKKACigAooAKKACigAoo

AKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAK

KAC i gAooAKKACi gAooAKKACi

gAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACigA

ooAKKACigAooAKKAP//Z

В этом примере показано содержание документа в формате Acrobat фирмы Adobe, которое было сжато с помощью алгоритма GZip.

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

7.4.3 ED.IMAGE

7.4.3.1 Описание

Тонкость, ограничивающая тип данных ED

Тонкость ED.IMAGE ограничивает тип данных ED таким образом, что содержание этого типа должно быть изображением.

7.4.3.1.1 Инварианты:

• значение атрибута типа среды mediaType должно начинаться со строки «image/»;
• содержание не может быть представлено как текст или XML-документ — оно должно быть двоичным и представляться по значению и/или по ссылке.

Представление инвариантов на языке OCL:

inv «fixed to image»: mediaType.substring(0,6) = «image/»

inv «no text»: value.oclIsUndefined

inv «no xml»: xml.oclIsUndefined

7.4.4 ED.TEXT

7.4.4.1 Описание

Тонкость, ограничивающая тип данных ED

Тонкость ED.TEXT ограничивает тип данных ED таким образом, что содержание этого типа должно быть простым текстом.

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

7.4.4.2 Инварианты:

• значение атрибута типа среды mediaType должно быть равно text/plain;
• содержание не может быть представлено как XML-документ или двоичные данные — оно должно быть текстом и представляться по значению и/или по ссылке;
• эскиз, сжатие и переводы не разрешены.

Представление инвариантов на языке OCL:

inv «text only»: mediaType = «text/plain»

inv «no xml»: xml.oclIsUndefined

inv «no data»: data.oclIsUndefined

inv «no thumbnail»: thumbnail.oclIsUndefined

inv «no compression»: compression.oclIsUndefined

inv «no translations»: translation->isEmpty

7.4.5 ED.SIGNATURE

7.4.5.1 Описание

Тонкость, ограничивающая тип данных ED

Тонкость ED.SIGNATURE ограничивает тип данных ED таким образом, что содержание этого типа должно быть электронной подписью XML, соответствующей рекомендациям XML Signature Syntax and Processing Recommendation организации W3C.

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

7.4.5.2 Инварианты:

• атрибуты value, data, reference, integrity check, thumbnail, compression, language и translation не разрешены;
• атрибут типа среды mediaType должен иметь значение text/xml.

Представление инвариантов на языке OCL:

inv «no reference» : reference.oclIsUndefined

inv «no value» : value.oclIsUndefined

inv «no data» : data.oclIsUndefined

inv «no integrityCheck»: integrityCheck.oclIsUndefined

inv «no thumbnail»: thumbnail.oclIsUndefined

inv «no compression»: compression.oclIsUndefined

inv «no language»: language.oclIsUndefined

inv «mediaType»: mediaType = «text/xml»

inv «no translations»: translation->isEmpty

7.4.6 Тип данных ST (строка символов)

7.4.6.1 Описание

Специализация типа данных ANY

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

Значение типа данных ST должно содержать как минимум один символ либо иметь причину пустоты nullFlavor.

7.4.6.2 Синтаксис ИСО/МЭК 11404

type ST = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controlInformationRoot : characterstring,

controlInformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorId : Set(characterstring),

value : characterstring,

language : characterstring

translation : Set(ST.NT)

)

7.4.6.3 Атрибуты

7.4.6.3.1 value : String: фактическое содержание строки. Обсуждение кодировки символов строк приведено в 6.7.5.

Это пример шаблона обертки примитивного типа данных. Более детальные сведения приведено в 6.3.

7.4.6.3.2 language : Code: человеческий язык содержания. Допустимые коды берутся из документа RFC 3066 организации IETF. Если этот атрибут пуст, то язык может быть идентифицирован откуда-то еще, например, из содержания или из тега языка в кодировке unicode.

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

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

7.4.6.3.3 translation: Set(ST.NT): перевод, то есть альтернативное представление того же самого содержания на другом языке. Переводы не могут содержать другие переводы.

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

7.4.6.4 Равенство

Два непустых (nonNull) значения типа ST равны только в том случае, если одинаковы последовательности символов, которые они представляют (то есть они не имеют причины пустоты nullFlavor и значения их атрибутов value равны). Свойство translation исключается из проверки на равенство. Кроме того, из этой проверки исключается свойство языка language, иначе было бы непонятно, как сравнивать значения типа ST, когда язык не указан.

Значение типа данных ED, содержащее простой текст, может быть также равно значению типа данных ST, имеющего то же символьное содержание, при условии выполнения правил, определенных для типа данных ED (см. 7.4.2.4).

7.4.6.5 Инварианты:

• если атрибут value присутствует, он должен содержать по меньшей мере один символ;
• переводы не могут содержать переводы.

Представление инвариантов на языке OCL:

inv «вложенные переводы не допускаются»: translation->

forAll(t | t.translation->isEmpty)

inv «содержание, если нет причины пустоты nullFlavor» : isNotNull implies

(value.oclIsDefined and value.size > 0)

7.4.6.6 Операции

7.4.6.6.1 mediaType : String: возвращает значение text/plain.

7.4.6.6.2 size : Integer: число символов в строке.

7.4.6.6.3 concat(other : ST) : ST: конкатенация данного значения со значением other.

7.4.6.6.4 substring(lower: INT, upper : INT) : ST: подстрока данного значения, начинающаяся символом с номером lower и завершающая символом с номером upper.

Символы нумеруются от 1 до значения this.size().

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

7.4.6.6.5 toInteger : INT: если содержание строки представляет допустимую запись целого числа, то возвращается его значение как целое число типа INT. Если содержание не представляет допустимую запись целого числа, то возвращается причина пустоты NullFlavor со значением NI (нет информации).

Строка представляет допустимую запись целого числа, если она соответствует формату литерала целого числа, определенному в ИСО/МЭК 11404, или лексическому представлению числа типа integer, определенному в XML-схеме.

7.4.6.6.6 toReal : REAL: если содержание строки представляет допустимую запись числа с плавающей точкой, то возвращается его значение как число типа REAL. Если содержание не представляет допустимую запись числа с плавающей точкой, то возвращается причина пустоты NullFlavor со значением NI (нет информации).

Строка представляет допустимую запись числа с плавающей точкой, если она соответствует формату литерала вещественного числа, определенному в ИСО/МЭК 11404, или лексическому представлению числа типа double, определенному в XML-схеме.

7.4.6.6.7 toTimestamp : TS: если содержание строки представляет допустимую запись штампа даты и времени, то возвращается его значение как значение типа TS. Если содержание не представляет допустимую запись штампа даты и времени, то возвращается причина пустоты NullFlavor со значением NI (нет информации). Строка представляет допустимую запись штампа даты и времени, если она соответствует формату, приведенному в описании типа данных TS.

7.4.6.7 Примеры

7.4.7 ST.NT

7.4.7.1 Описание

Тонкость, ограничивающая тип данных ST

Тонкость ST.NT ограничивает тип данных ST таким образом, что переводы недопустимы.

7.4.7.2 Инварианты:

• переводы недопустимы.

Представление инвариантов на языке OCL:

inv «переводы недопустимы»: translation->isEmpty

7.4.8 ST.SIMPLE

7.4.8.1 Описание

Тонкость, ограничивающая тип данных ST.NT

Тонкость ST.SIMPLE ограничивает тип данных ST.NT таким образом, что язык недопустим.

7.4.8.2 Инварианты:

• язык недопустим.

Представление инвариантов на языке OCL:

inv «язык недопустим»: language.oclIsUndefined

7.4.9 Тип данных SC (кодированная строка)

7.4.9.1 Описание

Специализация типа данных ST

Символьная строка, с которой может быть связан необязательный код. Если код присутствует, то обязательно должна присутствовать символьная строка.

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

Любое непустое значение типа I SC может иметь код, однако код не должен существовать без текста.

Сходство и различия между типами данных SC и CD рассмотрены 7.5.2.2.

7.4.9.2 Синтаксис ИСО/МЭК 11404

type SC = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controlInformationRoot : characterstring,

controlInformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorId : Set(characterstring),

value : characterstring,

language : characterstring,

translation : Set(ST.NT),

code : CD

)

7.4.9.3 Атрибуты

7.4.9.4 code : CD: кодированное значение, ассоциируемое со строкой. Если значение пусто или имеет причину пустоты nullFlavor, то никакой код с данной строкой не ассоциируется.

7.4.9.5 Равенство

Определение равенства для типа данных SC то же самое, что и для типа данных ST. Коды исключаются из проверки на равенство, и значения типа SC могут быть равны значениям типа ST (и, следовательно, значениям типа ED при условии выполнении правил, документированных для типа данных ST в 7.4.6.4).

7.4.9.6 Инварианты:

• если код присутствует, то у значения типа должно быть и некоторое содержание SC (следовательно, значение типа SC не должно иметь причину пустоты nullFlavor);
• значение атрибута originalText значения типа SC должно быть пустым (в качестве атрибута originalText выступает значение SC.value).

Представление инвариантов на языке OCL:

inv «если нет значения, то нет и кода» : code.isNotNull implies

isNotNull

inv «у атрибутов типа данных SC нет истории или режима обновления»:

noUpdateOrHistory(code)

inv «нет исходного текста» : code.isNotNull implies

code.originalText.isNull

7.4.9.7 Примеры

<code code=«57540006» codeSystem=«2.16.840.1.113883.6.96»

codeSystemName=«Snomed-CT»>

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

7.4.10 SC.NT

7.4.10.1 Описание

Тонкость, ограничивающая тип данных SC

Тонкость SC.NT ограничивает тип данных SC таким образом, что переводы недопустимы.

7.4.10.2 Инварианты:

• переводы недопустимы.

Представление инвариантов на языке OCL:

inv «переводы недопустимы»: translation->isEmpty

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

7.5.1 Введение

Эти типы данных обеспечивают использование кодов и терминов из терминологий и классификаций (см. рисунок 4).

7.5.2 Тип данных CD (дескриптор понятия)

7.5.2.1 Описание

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

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

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

Значение типа CD, не имеющее причины пустоты nullFlavor, должно иметь атрибут code или непустой (nonNull) атрибут исходного текста originalText. Значение типа CD, имеющее атрибуты code, codeSystem или originalText, но не удовлетворяющее внешним ограничениям на допустимый набор значений, должно иметь атрибут причины пустоты nullFlavor со значением «OTH» (другой).

Атрибуты типа CD обычно связаны внешними ограничениями, наложенными на кодированные понятия, которые могут быть значениями этих атрибутов. Эти ограничения могут быть квалифицированы как «расширяемое» (CWE) или «не расширяемое» (CNE). Если ограничение не расширяемое (CNE), то значение типа CD, у которого нет причины пустоты nullFlavor, должно содержать код, удовлетворяющий этому ограничению. Если ограничение расширяемое (CWE), то значение типа CD, у которого нет причины пустоты nullFlavor, должно содержать или код, существующий в домене, с которым связан атрибут, или код из местной системы кодирования, или атрибут originalText, описывающий понятие. Если код взят из местной системы кодирования, то она должна быть указана в свойстве codeSystem.

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

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

7.5.2.2 Типы данных CD и SC

Типы данных CD и SC имеют очень схожие структуры. У типа данных CD есть пара атрибутов code:codeSystem с переводами и атрибут исходного текста originalText, имеющий тип данных ED.Text, то есть простой текст, который может быть доступен по значению или по ссылке. У типа данных SC есть строки и код: тип данных CD позволяет строкам быть кодированными. У типа данных SC код не имеет атрибута originalText — его значение приравнено к значению атрибута value типа данных SC. Следовательно, оба типа данных имеют пару code:codeSystem с переводами и исходный текст.

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

Когда очевидно, какой аспект кодированного текста обязателен — код или текст, то становится очевидным, использовать тип данных CD или SC. С другой стороны, если ни один из аспектов не обязателен либо обязательны оба, то выбор из этих типов данных становится не очевиден.

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

Обычно в случаях, когда текст кодируется постфактум, очевидным выбором является тип данных CD, поскольку он позволяет сослаться на существующий текст. В других случаях правильный выбор между типами SC и CD неоднозначен. При выборе пользователям рекомендуется рассмотреть иерархию специализации, которая может диктовать конкретный выбор (может оказаться полезным, что тип данных SC является специализацией типа данных ST, а может и нет), а также рассмотреть ограничения, накладываемые на тип данных контекстом его использования; они также могут диктовать конкретный выбор.

В некоторых ситуациях выбор типа так и остается неоднозначным. При наличии сомнений разработчикам рекомендуется выбрать тип данных CD по умолчанию.

7.5.2.3 Синтаксис ИСО/МЭК 11404

type CD = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controlInformationRoot : characterstring,

controlInformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorId : Set(characterstring),

code : characterstring,

codeSystem : characterstring,

codeSystemName : characterstring,

codeSystemVersion : characterstring,

valueSet : characterstring,

valueSetVersion : characterstring,

displayName : ST,

originalText : ED,

codingRationale : CodingRationale,

translation : Set(CD),

source : CD

)

7.5.2.4 Атрибуты

7.5.2.4.1 code : String: простой символьный код, определенный в системе кодирования, или выражение, соответствующее синтаксису, определенному в системе кодирования, описывающей это понятие.

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

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

7.5.2.4.2 codeSystem: Uid : идентификатор системы кодирования, в которой определено значение атрибута code, или, если код не найден, идентификатор системы кодирования, в которой код не был найден.

Для идентификации систем кодирования должны использоваться уникальные идентификаторы, обеспечивающие однозначные ссылки на стандартные системы кодирования и другие местные системы. Если или организация ИСО, или организация HL7 уже присвоили такой идентификатор системе кодирования, то должен использоваться этот идентификатор. В остальных случаях в качестве глобально уникального идентификатора местной системы кодирования должен использоваться либо подходящий объектный идентификатор ИСО (ОИД), либо универсально уникальный идентификатор UUID.

Значение типа CD, имеющее атрибут code, должно иметь также и атрибут codeSystem, указывающий систему кодирования, в которой определено значение атрибута code.

7.5.2.4.3 codeSystemName : String: общее имя системы кодирования.

Имя системы кодирования не используется для вычислений. Оно не должно модифицировать значение свойства codeSystem и не может существовать без значения свойства codeSystem.

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

Примечание — Имя системы кодирования предназначено для облегчения интерпретации человеком значений свойств code и codeSystem.

7.5.2.4.4 codeSystemVersion : String: если применим, дескриптор версии, специально определенный для данной системы кодирования.

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

Если система кодирования изменена несовместимым образом, то она представляет собой другую систему кодирования, а не другую версию, как бы издатель это ни называл. Например, издатель классификаций МКБ-9 и МКБ-10 назвал эти системы кодирования «9-м пересмотром» и «10-м пересмотром». Однако классификация МКБ-10 представляет собой полное изменение кодов МКБ и не является обратно совместимой. Поэтому в целях настоящего стандарта типы данных классификации МКБ-9 и МКБ-10 рассматриваются как разные системы кодирования, а не как разные версии одной системы кодирования. Напротив, когда версия «1.0j» системы кодирования LOINC была обновлена до версии «1.0k», она должна была рассматриваться как другая версия, поскольку версии LOINC обратно совместимы.

7.5.2.4.5 valueSet : Uid: набор значений, использованный при кодировании данного значения типа CD.

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

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

Во многих случаях значение типа CD создается из набора значений — либо оно выбирается из набора значений, либо задается не входящим в этот набор, и тогда значение типа CD является исключительным с причиной пустоты NullFlavor.OTH (другое). Если код не выбран, то в общем случае нельзя задавать систему кодирования, из которой выбран код, поскольку набор значений может не совпадать с системой кодирования (он может быть подмножеством системы кодирования или включать в себя дополнительные термины из других систем кодирования); вместо этого надо указывать набор значений. Кроме того, известны некоторые сценарии, в которых набор значений, предложенный пользователю или системе при выборе кода, влияет на интерпретацию этого кода.

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

7.5.2.4.6 valueSetVersion : String: версия набора значений valueSet, в которой код был найден.

Атрибут valueSetVersion должен присутствовать, если присутствует атрибут valueSet. В противном случае он должен быть пустым. Значение атрибута valueSetVersion должно идентифицировать конкретную версию набора значений в соответствии с правилами, определенными издателем этого набора.

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

7.5.2.4.7 displayName : ST: имя, заголовок или представление кода либо выражения в том виде, как оно указано в системе кодирования.

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

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

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

Примечание — Местные соглашения могут влиять на то, что требуется для представления этого исходного текста.

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

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

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

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

Значения типа CD могут иметь непустое свойство исходного текста, даже если свойство code имеет пустое значение. Данное значение считается исключительным. В этом случае свойство originalText является именем или описанием понятия, которое не было закодировано. Такие значения типа CD могут также содержать переводы translation.

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

7.5.2.4.9 translation: Set(CD): множество других значений типа CD, которые представляют переводы данного значения типа CD в эквивалентные коды внутри той же системы кодирования или в соответствующие понятия, описанные в других системах кодирования.

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

Переводы не должны содержать другие переводы. Корневое значение типа CD обладает одним множеством переводов, в котором перечислены все переводы. Главным переводом обычно является тот, который наилучшим образом удовлетворяет критериям соответствия типу данных CD. Из выбора корневого значения не должно следовать никаких выводов о происхождении перевода. Для прослеживания происхождения следует использовать атрибуты codingRationale и source.

В отсутствие модели ограничений домена значений типа данных CD любой из переводов может быть корневым значением типа CD. Если существует модель, ограничивающая домен значений типа CD, и существует перевод, который удовлетворяет этим ограничениям, то этот перевод рекомендуется выбрать в качестве корневого значения типа CD. Если существует модель, ограничивающая домен значений типа CD, но при этом ни один из переводов не удовлетворяет этим ограничениям, то корневым значением может быть любой перевод при условии, что ему присвоена причина пустоты nullFlavor. Может использоваться альтернативный вариант, при котором ни один из переводов не объявляется корневым значением, самому значению типа CD присваивается одна из причин пустоты, описанных в словарном домене NullFlavor, а все переводы помещаются в свойство translation корня.

7.5.2.4.10 codingRationale : CodingRationale: причина, по которой конкретное значение типа CD было представлено или как корневое понятие, или как один из переводов.

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

Синтаксис ИСО/МЭК 11404 атрибута codingRationale:

type CodingRationale = enumeration (O, P, R, OR, PR)

Код считается присвоенным постфактум, если пользователь не задал код, когда впервые ввел данные. Атрибут codingRationale не должен рассматриваться в качестве признака контроля качества процессов кодирования или перевода.

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

7.5.2.4.11 source : CD: если данное значение типа CD было создано как перевод другого значения типа CD, то атрибут source содержит ссылку на то значение типа CD, которое послужило источником для данного перевода.

Это свойство является ссылкой. Источник, на который оно указывает, должен быть представлен из числа корневого значения типа CD и его переводов; другими словами, оно должно быть другим представлением того же понятия в том же атрибуте.

Значение типа CD состоит из единственного корневого кода и множества переводов, которые не имеют других переводов. Используя свойство codingRationale, отправитель может указать, какой код является оригинальным. Бывают обстоятельства, при которых полезно знать, какое значение типа CD является переводом какого значения типа CD. С помощью атрибута source можно представить последовательность от одного перевода к другому. Каждый элемент множества переводов был получен из исходного значения типа CD. Однако каждый перевод также может иметь переводы. Таким образом, когда код переводится несколько раз, будет сохранена информация о том, какой код послужил входным значением для какого перевода.

7.5.2.5 Равенство

Равенство двух значений типа CD определяется исключительно на основе сравнения их атрибутов code и codeSystem. Атрибуты codeSystemVersion, originalText, codingRationale, source, информация о наборе значений и переводах не участвуют в проверке на равенство. Значения, имеющие причину пустоты nullflavor, не равны, даже если у них одинаковые коды причины пустоты или значения атрибутов исходного текста.

Равенство основано на литеральных значениях атрибутов code и codeSystem. Элементы обработки информации не должны рассматривать семантическое значение пары code+codeSystem для определения того, идентифицирует ли она то же самое понятие.

Примечания

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

2 Значения типа CD могут быть также равны значениям типа CS. Детальная информация приведена в 7.8.6.4.

7.5.2.6 Инварианты:

• если значение не пусто, то либо атрибут code, либо атрибут originalText должны иметь значение;
• если атрибут code имеет значение, то атрибут codeSystem тоже должен иметь значение;
• присутствие атрибута valueSet требует присутствия атрибута valueSetVersion;
• атрибут codeSystemName может иметь значение только в том случае, если атрибут codeSystem имеет значение;
• атрибут codeSystemVersion может иметь значение только в том случае, если атрибут codeSystem имеет значение;
• атрибут displayName может иметь значение только в том случае, если атрибут code имеет значение;
• у переводов не может быть исходного текста;
• переводы не могут иметь переводы.

Представление инвариантов на языке OCL:

def: let hasCode : Boolean = code.oclIsDefined

def: let hasCodeSystem : Boolean = codeSystem.oclIsDefined

def: let hasOriginalText : Boolean = originalText.isNotNull

codeSystem = system or translation->select(t |

t.fromCodeSystem(system))->notEmpty

Примечание — Определена система кодирования fromCodeSystem, являющаяся источником, поэтому можно задать ограничения извне системы кодирования codeSystem, к которой принадлежат тип данных CD или один из его переводов, например, inv: code.fromCodeSystem(«2.16.840.1.113883.6.42»).

def: let noOriginalText : Boolean = originalText.oclIsUndefined

inv «null или code и/или originalText»:

sNotNull implies (hasCode or hasOriginalText)

inv «other требует codeSystem или valueSet»:

(nullFlavor = NullFlavor.OTH) implies

(codeSystem.oclIsDefined or valueSet.oclIsDefined)

inv «code требует codeSystem»: code.oclIsDefined

implies codeSystem.oclIsDefined

inv «codeSystemName, только если codeSystem»:

codeSystemName.oclIsDefined implies codeSystem.oclIsDefined

inv «codeSystemVersion, только если codeSystem»:

codeSystemVersion.oclIsDefined implies codeSystem.oclIsDefined

inv «displayName, только если code»: displayName.oclIsDefined

implies code.oclIsDefined

inv «valueSet требует valueSetVersion»:

valueSet.oclIsDefined implies (valueSetVersion.oclIsDefined)

inv «исходный текст в переводах недопустим»:

translation->forAll(t | t.noOriginalText)

inv «Переводы не могут иметь переводы»:

translation->forAll(t | t.translation->isEmpty)

inv «у элементов CD нет истории или режима изменения»:

noUpdateOrHistory(displayName) and

noUpdateOrHistory(originalText)

and translation->forAll(t | noUpdateOrHistory(t))

7.5.2.7 Операции

7.5.2.7.1 implies(other : CD) : BL: является следствием, то есть имеет значение true, если данная пара code+codeSystem специализация другой пары code+codeSystem или имеет то же самое значение.

Примечания

1 В номенклатуре SNOMED, к примеру, две изоморфные формы одного и того же выражения являются следствием друг друга.

2 Для вычисления этого отношения может понадобиться терминологическая служба.

7.5.2.8 Примеры

7.5.2.8.1 Примеры кодов МКБ

Простым примером кода может служить шифр головной боли в классификации МКБ-9, а именно «784.0».

<example code=«784.0» codeSystem=«2.16.840.1.113883.6.42»

codeSystemName=«ICD-9»>

Возможным эквивалентом этого кода в МКБ-10 является «G44.1» (классификации МКБ-10 слегка отличаются).

<example code=«G44.1» codeSystem=«2.16.840.1.113883.6.3»

codeSystemName=«ICD-10»>

7.5.2.8.2 Примеры невозможности кодирования

Достаточно часто при использовании типа данных CD фактически используемое понятие не может быть правильно представлено в конкретной системе кодирования. Обычно это происходит, когда ожидается, что понятие присутствует в конкретной системе кодирования. Для целей настоящих примеров предполагается, что все они относятся к результату исследования типа CD, принадлежащего к полному набору значений Snomed-CT (в примере использован ОИД набора значений, равный 2.16.840.1.113883.19.11.1 по состоянию на 11 июня 2007 года, фактический ОИД системы кодирования SNOMED-CT равен 2.16.840.1.113883.6.96). Важно отметить следующее: корневой ОИД 2.16.840.1.113883.19 определен рабочей группой HL7 только для использования в примерах, и те ОИД, которые принадлежат этой ветви, никогда не должны использоваться в реальных экземплярах. Вместо ОИД, использованных в приведенных ниже примерах, в реальных экземплярах надо использовать пространства имен ОИД 2.16.840.1.113883.6, 2.16.840.1.113883.5 и 2.16.840.1.113883.11.

В простейшем случае значение типа CD вообще не представлено в экземпляре или представляется как отсутствие информации:

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

Возможен и такой вариант:

<value nullFlavor=«OTH» valueSet=«2.16.840.1.113883.19.11.1»

valueSetVersion=«20070711»/>

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

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

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

Если кодирование имеет квалификатор CWE, местные расширения разрешены и система-источник может попросту использовать свое собственное значение атрибута codeSystem (идентифицирующее систему кодирования с ОИД «2.16.840.1.113883.19.5.2», предназначенную для примеров) для расширения другой системы кодирования. В действительности система-источник может также использовать код из другой широко распространенной системы кодирования, например, МКБ-9. Если бы в МКБ-9 был код «A10.1», означающий тоже самое понятие, то следующее представление значения типа CD было бы правильным:

Если же использование набора значений SNOMED CT помечено квалификатором CNE, то код должен быть взят только из SNOMED. В этом случае та же самая информация, которая приведена выше, должна быть передана иным образом:

Теперь код точно помечен причиной пустоты OTH (другой): код не может быть взят из SNOMED CT, но предусмотрен перевод понятия в другой системе кодирования. Хотя в данном случае это избыточно, система-источник могла бы следующим образом указать с помощью атрибута source, из какой системы получен какой перевод:

<translation id=«s1» code=«ожог»

codeSystem=«2.16.840.1.113883.19.5.2»>

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

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

7.5.2.8.3 Примеры выражений

Выражения обычно возникают при использовании сложных медицинских терминологий, например, SNOMED. К примеру, в SNOMED CT определены понятие целлюлита «cellulitis (disorder)» (128045006), атрибута места исследования «finding site» (363698007) и понятие структуры ноги «foot structure (body structure)» (56459004). Номенклатура SNOMED CT позволяет составить из этих кодов следующее предложение, означающее целлюлит ноги:

128045006|cellulitis (disorder)|:{363698007|finding site|=56459004|foot structure|}

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

<value code=«128045006:{363698007=56459004}»

codeSystem=«2.16.840.1.113883.6.42» codeSystemName=«Snomed-CT»>

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

Язык композиционных выражений, используемый в номенклатуре SNOMED, в настоящее время находится в стадии рецензирования. Его описание можно найти на сайте организации IHTSDO (International Health Terminology Standards Development Organization). Следующие два примера основаны на версии SNOMED CT Core Edition 2007-01-31.

В первом примере используется код SNOMED для понятия «fracture of left tibia» (перелом левой большеберцовой кости). Он демонстрирует аспекты группировки и вложения.

31978002|fracture of tibia|: 272741003|laterality|=7771000|left|

Строго говоря (в нормальной форме), «fracture of left tibia» означает не «left fracture of a tibia bone» (левый перелом большеберцовой кости), а «fracture of the left tibia bone» (перелом левой большеберцовой кости), то есть квалификатор «left» (левый) применяется к кости, а не к перелому. Кроме того, в этом примере перелом и кость сгруппированы; это может показаться не существенным, но потенциально имеет значение для сочетанных переломов, когда для разных костей может быть указана разная морфология. Альтернативное представление этого же понятия имеет следующий вид:

64572001|disease|:{116676008|associated morphology|=72704001|fracture|,

363698007|finding site|=(12611008|bone structure of

tibia|:272741003|laterality|=7771000|left|)}

Второй пример демонстрирует более сложную группировку и вложенную структуру. Выражение SNOMED CT для понятия «past history of fracture of left tibia» (история лечения перелома левой большеберцовой кости) включает в себя вложенность даже в ее простейшей форме, поскольку понятие стороны применяется не к истории лечения, а к нарушению здоровья:

417662000|past history of clinical finding|: 246090004|associated finding|=

(31978002|fracture of tibia|: 272741003|laterality|=7771000|left|)

Альтернативное представление использует еще большую вложенность:

243796009|situation with explicit context|:246090004|associated finding|=

(64572001|disease|:{116676008|associated morphology|=72704001|fracture|,

363698007|finding site|=(12611008|bone structure of tibia|:

272741003|laterality|=7771000|left|)}),408729009|finding context|=

410515003|known present|,408731000|temporal context|=410513005|past|,

408732007|subject relationship context|=410604004|subject of record|

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

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

Классификация МКБ-10 допускает двойное кодирование (см., например, 3.1.3 руководства по МКБ-10). Хотя в классификации МКБ-10 описаны точные правила, являющиеся семантической основой двойного кодирования, в ней не приводится конкретная литеральная форма выражения, пригодная для использования в типе данных CD. В связи с этим рабочая группа HL7 самостоятельно определила подходящую литеральную форму выражения и присвоила ей ОИД 2.16.840.1.113883.6.260. В этой системе кодирования указано, что два кода МКБ-10 разделяются пробелом:

value code=«J21.8 B95.6» codeSystem=«2.16.840.1.113883.6.260»

codeSystemName=«ICD-10 Dual Code Expression»>

Шифр J21.8 в МКБ-10 соответствует понятию «Острый бронхиолит, вызванный другими уточненными агентами», а шифр B95.6 — понятию «Staphylococcus aureus как причина болезней, классифицированных в других рубриках».

Выражения возникают также в системе единиц измерения UCUM. Поскольку эта система стабильна, выражения кодов из системы UCUM обычно встречаются в атрибуте единиц измерения, определенном в типе данных PQ (см. 7.8.9.3.2). Хотя этот атрибут имеет тип данных CS, все равно это служит примером указания выражения в коде (тип данных CS может быть преобразован в тип данных CD с помощью явного указания атрибута системы кодирования codeSystem). Ниже приведено простое выражение из системы UCUM, которое фактически является прямой ссылкой на простое понятие, определенное в системе UCUM:

Единица g (г) непосредственно определена в системе UCUM. Типичное выражение, соответствующее системе UCUM, является более сложным:

Концентрация аналита равна 1 mmol/l (ммоль/л); здесь mmol/l — выражение, соответствующее системе UCUM, как и следующее более простое выражение:

Количество аналита равно 1 mmol (ммоль); mmol также является выражением, соответствующим системе UCUM, а именно, сочетанием приставки m (милли) и единицы mol (моль).

7.5.3 Тонкость CD.CV (кодированное значение)

7.5.3.1 Описание

Ограничение типа данных CD

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

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

7.5.3.2 Инварианты:

• переводы недопустимы;
• источник недопустим.

Представление инвариантов на языке OCL:

inv «переводы недопустимы»: translation.size = 0

inv «источник недопустим»: source.oclIsUndefined

7.5.4 Тип данных CS (кодированное простое значение)

7.5.4.1 Описание

Специализация типа данных ANY

Кодированные данные в простейшей форме, где только код не предопределен.

Система кодирования и версия системы кодирования подразумеваются и фиксированы в контексте использования значения типа CS.

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

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

7.5.4.2 Синтаксис ИСО/МЭК 11404

type CS = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controlInformationRoot : characterstring,

controlInformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorId : Set(characterstring),

code : characterstring

)

7.5.4.3 Атрибуты

7.5.4.3.1 code : String: простой символьный код, определенный в системе кодирования. Если значение кода является пустой строкой или пустым значением, то в системе кодирования нет кода, представляющего понятие.

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

7.5.4.4 Равенство

Равенство двух значений типа CS определяется исключительно на основе явно заданного кода и неявно используемой системы кодирования codeSystem.

Значение версии системы кодирования codeSystemVersion не участвует в проверке на равенство. Значения, имеющие причину пустоты nullFlavor, не равны, даже если коды причины пустоты nullFlavor у них одинаковые.

Равенство основано на литеральных значениях атрибутов code и codeSystem. Элементы обработки информации не должны рассматривать семантическое значение пары code+codeSystem для определения того, идентифицирует ли она то же самое понятие.

Примечание — Значения типа CS могут быть равны значениям типа CD, если у них одинаковы коды и системы кодирования.

7.5.4.5 Инварианты:

• если у значения нет причины пустоты nullFlavor, то код должен присутствовать.

Представление инвариантов на языке OCL:

inv «code is required»: isNotNull implies

code.oclIsDefined

7.5.4.6 Операции

7.5.4.6.1 codeSystem() : Uid: хотя у типа данных CS нет атрибута codeSystem, всегда должна существовать система кодирования, определяемая контекстом использования типа данных CS. Эта операция возвращает значение системы кодирования codeSystem, заданной контекстом.

Эта операция всегда должна возвращать допустимое значение системы кодирования codeSystem, даже в том случае, когда значение типа CS имеет причину пустоты nullFlavor, поскольку система кодирования определяется контекстом использования.

7.5.4.6.2 codeSystemVersion() : String: хотя у типа данных CS нет атрибута codeSystemVersion, тем не менее может существовать версия системы кодирования, определяемая контекстом использования типа данных CS.

Эта операция возвращает значение версии системы кодирования codeSystemVersion, если оно известно из контекста.

7.5.4.7 Примеры