ГОСТ Р ИСО 21090-2016

ГОСТ Р ИСО 21090-2016

Группа П85

     

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

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

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

Health Informatics. Harmonized data types for information interchange

ОКС 35.240.80

ОКСТУ 4002

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

Предисловие

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

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

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

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

________________

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

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

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

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 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)]

_______________

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

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

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

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

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

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

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

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

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

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

IETF RFC 2806 - URLs for Telephone Calls (Представление телефонных номеров в форме URL)

_______________

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

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

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

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

_______________

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

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

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

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

_______________

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

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

_______________

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 Сокращения

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

     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 Объявления соответствия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

_______________

* Текст документа соответствует оригиналу. - Примечание изготовителя базы данных.

Наряду с требованиями, что объявления соответствия должны содержать формальные объявления о соответствии требованиям, указанным в пунктах а)-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) определять, каким образом используется свойство controlnformationRootExtension типа данных 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). Это означает, что можно реализовать обмен информацией, основанный на определениях этой спецификации, используя типы данных, определенные в настоящем стандарте. В приложении В показано, как эти типы данных соотносятся с типами данных, определенным в спецификации HL7 V3 Abstract Data Types (R2).

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

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

Некоторые имена этих типов данных имеют чрезвычайное сходство с именами, определенными в других спецификациях. Например, в настоящем стандарте определен вещественный тип данных REAL, в ИСО/МЭК 11404 определен тип Real, в ядре UML тоже есть тип данных с именем Real (см. примечание 1 в В.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.

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

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

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

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

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

_______________

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

В этой таблице все коды понятий после 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-имя.

Примеры

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

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

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

6.7.7 Примеры

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

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

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

     7 Типы данных

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

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

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

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

7.1.2 Равенство

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

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

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

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

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

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 присутствует, то другим атрибутам могут быть присвоены значения, однако при этом не требуется, чтобы элемент обработки информации использовал какое-либо из этих значений, за исключением следующих случаев, которые следует правильно понимать в ситуации, когда они применимы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для атрибутов, имеющих тип коллекций (<dtref ref="dt-COLL"/> и его специализации), кратность указывает, сколько элементов может содержать коллекция. Максимальное значение кратности * означает, что число элементов коллекции не ограничено.

Примечания

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

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

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

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

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

     
Рисунок 1 - Модель верхнего уровня

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

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

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

7.3.1 Введение

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

     
Рисунок 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,

controllnformationRoot : characterstring,

controllnformationExtension : 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 controllnformationRoot: Uid: корень идентификатора события, связанного с присвоением типу данных его указанного значения.

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

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

7.3.2.4 Равенство

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

7.3.2.5 Инварианты

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

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

def: let noHistory : Boolean =

validTimeLow. oclIsUndefined and

validTimeHigh. oclIsUndefined and

controllnformationRoot. oclIsUndefined and

controllnformationExtension. oclIsUndefined

inv "extension requires root":

controllnformationExtension.оclIsDefined implies

controllnformationRoot.oclIsDefined

7.3.2.6 Пример

<example

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

validTimeLow="200506011000" validTimeHigh="200507031500"

controllnformationRoot="1.2.3.4.5.6">

</example>

В этом примере значение атрибута "Это некоторое содержание" было действительно с 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,

controllnformationRoot : characterstring,

controllnformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorld : 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.

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

Синтаксис ИСО/МЭК 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.

Таблица 6 - Перечисление UpdateMode, ОИД: 2.16.840.1.113883.5.57

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

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

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

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

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

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

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

7.3.3.4 Равенство equals

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

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

Таблица 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 и flavorld всегда игнорируются.

7.3.3.5 Инварианты

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

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

def: let isNull : Boolean = nullFlavor.oclIsDefined

def: let isNotNull : Boolean = not isNull

def: let noUpdate : Boolean = updateMode.oclIsUndefined

def: let noUpdateOrHistory() : Boolean = noUpdate and noHistory

def: let noUpdateOrHistory (member : ANY) : Boolean =

member.oclIsDefined implies member.noUpdate and member.noHistory

def: let invalid : Boolean = (nullFlavor = NullFlavor.INV or

nullFlavor = NullFlavor.OTH or nullFlavor = NullFlavor.PINF or

nullFlavor = NullFlavor.NINF or nullFlavor = NullFlavor.UNC or

nullFlavor = NullFlavor.DER)

inv "тип данных ANY разрешен только при наличии причины пустоты nullFlavor": (isNotNull or invalid) implies

not oclIsTypeOf(ANY)

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 Неизвестное значение

<example xsi:type="ANY" nullFlavor="UNK"/>

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

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

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

<example code="784.0" codeSystem="2.16.840.1.113883.6.42">

<displayName value="Headache"/>

</example>

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

<example code="784.0" codeSystem="2.16.840.1.113883.6.42">

<displayName value="Headache"/>

<translation nullFlavor="NI"/>

</example>

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

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

<example code="784.0" codeSystem="2.16.840.1.113883.6.42">

<displayName value="Headache"/>

<translation nullFlavor="NI" codeSystem="2.16.840.1.113883.6.96"/>

</example>

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

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

<example code="784.0" codeSystem="2.16.840.1.113883.6.42">

<displayName value="Headache"/>

<translation nullFlavor="NI" codeSystem="2.16.840.1.113883.6.96"/>

</example>

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

7.3.3.7.3 Атрибут updateMode

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

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

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

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

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

<birthDate value="19750621" updateMode="R"/>

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

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

<birthDate nullFlavor="NI" updateMode="D"/>

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

<birthDate nullFlavor="NI" updateMode="R"/>

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

<birthDate nullFlavor="NI" updateMode="K"/>

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

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

<contacts>

<item value="tel:+11015551234" use="H" capabilities="voice"/>

<item value="tel:+11995556787" use="MC" capabilities="voice sms"/>

<item value="tel:+11015551235" capabilities="fax"/>

<item value="mailto:example@example.com"/>

</contacts>

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

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

<contacts>

<item value="tel:+11015551234" use="H"

capabilities="voice" updateMode="D"/>

<item value="tel:+12315559876" use="H"

capabilities="voice" updateMode="A"/>

</contacts>

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

<contacts>

<item value="tel:+12315559876" use="H"

capabilities="voice" updateMode="R"/>

</contacts>

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

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

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

<contacts>

<item value="tel:+11015551234" use="H"

capabilities="voice" upateMode="D"/>

<item value="tel:+ 11015551234" use="H WP"

capabilities="voice fax" updateMode="A"/>

</contacts>

<contacts>

<item value="tel:+ 11015551234" use="H W"

capabilities="voice fax" updateMode="R"/>

</contacts>

Оба этих экземпляра означают, что существующие детали использования номера +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,

controllnformationRoot : characterstring,

controllnformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorld : 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:

inv "value if not nullFlavored":

isNotNull implies value.oclIsDefined

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

<example xsi:type="BL" value="true"/>

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

<example xsi:type="BL" nullFlavor="UNK"/>

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 Введение

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

    
Рисунок 3 - Текстовые и двоичные типы данных

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,

controllnformationRoot : characterstring,

controllnformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorld : 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 - Перечисление CompressionAlgorithm, ОИД: 2.16.840.1.113883.5.1009

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

Синтаксис ИСО/МЭК 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.

Таблица 10 - Перечисление IntegrityCheckAlgorithm, ОИД 2.16.840.1.113883.5.1010

Синтаксис ИСО/МЭК 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:

def: let hasValue : Boolean = value. oclIsDefined or

data.oclIsDefined or xml.oclIsDefined or hasReference

def: let hasReference : Boolean = reference.isNotNull

inv "если содержание не пусто, то оно требуется": isNotNull implies (hasValue

and canonical. oclIsDefined)

inv "только один из атрибутов value, data, xml": value.oclIsDefined implies

(data.oclIsUndefined and xml.oclIsUndefined) and data.oclIsDefined implies

(value.oclIsUndefined and xml.oclIsUndefined) and xml.oclIsDefined

implies

(value.oclIsUndefined and data.oclIsUndefined)

inv "алгоритм integrityCheckAlgorithm требуется": integrityCheck.oclIsDefined

= integrityCheckAlgorithm.oclIsDefined

inv "эскизы не содержат ссылки": thumbnail.isNotNull implies

not thumbnail.hasReference

inv "эскизы не содержат эскизы": thumbnail.isNotNull implies

thumbnail.thumbnail.oclIsUndefined

inv "сжатие применяется только к двоичным данным":

compression.oclIsDefined implies

(data.oclIsDefined or reference.oclIsDefined)

inv "тип среды mediaType не может быть пуст": isNotNull implies

mediaType.oclIsDefined

inv "наличие атрибута value подразумевает тип среды mediaType, равный text/

plain": value.oclIsDefined implies

mediaType = 'text/plain'

inv "для атрибутов value или xml не должен быть указан атрибут charset":

(value.oclIsDefined or xml.oclIsDefined) implies

charset.oclIsUndefined

inv "режим истории или изменений запрещен ": noUpdateOrHistory(reference)

and noUpdateOrHistory (thumbnail)

inv "no nested translations": translation->forAll(t |

t.translation->isEmpty)

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 Простой текст

<example xsi:type="ED" value="Это простой текст" mediaType="text/plain"/>

<example xsi:type="ED" value="Это простой текст"/>

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

7.4.2.7.2 Язык

<example xsi:type="ED" flavorId="ED.TEXT" value="this is plain text"

language="en" mediaType="text/plain"/>

<example xsi:type="ED" flavorId="ED.TEXT" value="dieses ist normaler Text"

language="de" mediaType="text/plain"/>

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

<example xsi:type="ED" value="this is plain text" language="en">

<translation xsi:type="ED" value="dieses ist normaler Text" language="de"/>

</example>

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

<example xsi:type="ED" value="this is plain text" language="en-ca">

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

language="fr-ca"/>

</example>

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

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

<example xsi:type="ED">

<data>dGhpcyBpcyBiaW5hcnkgY29udGVudA==</data>

</example>

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

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

<example xsi:type="ED" charset="UTF-8">

<data>dGhpcyBpcyBiaW5hcnkgY29udGVudA==</data>

</example>

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

7.4.2.7.4 Ссылка

<example xsi:type="ED" mediaType="image/jpg">

<reference value="http://www.tempuri.org/XXXXXXXXXXX">

</example>

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

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

<example xsi:type="ED" mediaType="image/jpg" compression="GZ">

<reference value="http://www.tempuri.org/XXXXXXXXXXX">

</example>

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

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

<example xsi:type="ED" mediaType="text/xml">

<data>PHBhcmVudD4NCiAgPGNoaWxkPlRoaXMgaXMgc29tZSB0ZXh0lGluIHRoZSBjaGlsZDwvY-2hpbGQ+DQogIFRoaXMgaXMgc29tZSB0ZXh0lGluIHRoZSBwYXJlbnQNCjwvcGFyZW5 0Pg==</data>

</example>

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

<example xsi:type="ED" mediaType="text/xml" charset="ASCII">

<data>PHBhcmVudD4NCiAgPGNoaWxkPlRoaXMgaXMgc29tZSB0ZXh0lGluIHRoZSBjaGlsZDwvY-2hpbGQ+DQogIFRoaXMgaXMgc29tZSB0ZXh0lGluIHRoZSBwYXJlbnQNCjwvcGFyZW5 0Pg==</data>

</example>

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

<example xsi:type="ED" mediaType="text/xml">

<xml>

<parent>

<child>This is some text in the child</child>

This is some text in the parent

</parent>

</xml>

</example>

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

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

<example mediaType="application/pdf" compression="GZ">

<data>/9j/4AAQSkZJRgABAgEAgACAAAD/2wCEAAICAgIC

AQICAglCAglCAwQDAwMDAwUEBAMEBgYHBgYG

BgYHCAoIBwcJBwYGCAsJCQoKCwsLBwgMDQwKDAoLCwoBAgIC

AwMDBQMDBQoHBgcKCgoKCgoKCgoK

CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgo

KCv/AABEIAg4CuQMBIQACEQED

EQH / xAG i AAABBQEBAQEBAQAAAAAAAAAAAQI DBAUGBwg JCgs BAAM

BAQEBAQEBAQEAAAAAAAABAgME

BQYHCAkKCxAAAgEDAwIEAwUFBAQAAAF 9AQIDAAQRBRIhMUEGElF

hByJxFDKBkaEIIOKxwRVSOfAk

…

СigAoоAKKACigAoоAKKACigAoоAKKACigAoоAKKACigAoоAKKAC

gAoоAKKACigAoоAKKACigAoо

AKKACigAoоAKKACigAoоAKKACigAoоAKKACigAoоAKKACigAoоAK

KAC i gAooAKKACi gAooAKKACi

gAoоAKKACigAoоAKKACigAoоAKKACigAoоAKKACigA

oоAKKACigAooAKKACigAooAKKAP/ /Z</data>

</example>

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

<example mediaType="image/png">

<reference value="http://example.org/xrays/128s8d9ej229se32s.png">

<useablePeriod xsi:type="IVL_TS">

<low value="200007200845"/>

<high value="200008200845"/>

</useablePeriod>

</reference>

<integrityCheck>EQH/xAGiAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgsB

AAMBAQEBAQEBAQEAAAAAAAABAgME</integrityCheck>

<thumbnail mediaType="image/jpeg">

<data>/9j/4AAQSk Z JRgABAgEAgACAAAD/2wCEAAICAgIC

AQICAglCAglCAwQDAwMDAwUEBAMEBgYHBgYG

BgYHCAoIBwcJBwYGCAsJCQoKCwsLBwgMDQwKDAoLCwoBAgIC

AwMDBQMDBQoHBgcKCgoKCgoKCgoK

CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgo

KCv/AABEIAg4CuQMBIQACEQED

EQH / xAG i AAABBQEBAQEBAQAAAAAAAAAAAQI DBAUGBwg JCgs BAAM

BAQEBAQEBAQEAAAAAAAABAgME

BQYHCAkKCxAAAgEDAwIEAwUFBAQAAAF 9AQIDAAQRBRIhMUEGElF

hByJxFDKBkaEIIOKxwRVSOfAk

СigAoоAKKACigAoоAKKACigAoоAKKACigAoоAKKACigAoоAKKAC

gAoоAKKACigAoоAKKACigAoо

AKKACi gAooAKKAC i gAooAKKAC i gAooAKKAC i gAooAKKAC i gAooAK

KACigAoоAKKACigAoоAKKACi

gAoоAKKACigAoоAKKACigAoоAKKACigAoоAKKACigAoоAKKACigA

ooAKKACigAooAKKAP//Z </data>

</thumbnail>

</example>

Этот пример содержит ссылку на изображение, хранящееся по определенному адресу 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,

controllnformationRoot : characterstring,

controllnformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorld : 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 tolnteger : 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 Примеры

<example language="en" value="цeллюлит левой ноги"/>

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

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

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

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

type SC = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controllnformationRoot : characterstring,

controllnformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorld : 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 Примеры

<example xsi:type="SC" value="Intestinal nematode infection">

<code code="57540006" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="Snomed-CT">

<displayName value="Intestinal nematode infection (disorder)"/>

</code>

</example>

<example xsi:type="SC" value="Lung nematode infection"/>

Активно используются два примера применения типа данных 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 Описание

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

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

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

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

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

Атрибуты типа 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 обязателен, текст (который становится исходным текстом) должен быть указан непосредственно, а код всегда не обязателен.

     
Рисунок 4 - Кодированные типы данных

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

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

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

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

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

type CD = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controllnformationRoot : characterstring,

controllnformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorld : 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.

Таблица 11 - Перечисление CodingRationale, ОИД: 2.16.840.1.113883.5.1074

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

type CodingRationale = enumeration (О, 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">

<displayName value="Головная боль, БДУ"/>

<originalText value="гoлoвнaя боль"/>

</example>

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

<example code="G44.1" codeSystem="2.16.840.1.113883.6.3"

codeSystemName="ICD-10">

<displayName value="Сосудистая головная боль, не классифицированная в других рубриках"/>

<originalText value="сосудистая головная боль"/>

</example>

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="NI"/>

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

<value nullFlavor="OTH" codeSystem="2.16.840.1.113883.6.96"/>

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

<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:

<value nullFlavor="OTH" codeSystem="2.16.840.1.113883.6.96">

<originalText value="Ожог уха утюгом. Ожог другого уха при звонке в скорую помощь"/>

</value>

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

<value code="ожог" codeSystem="2.16.840.1.113883.19.5.2 ">

<originalText value="Ожог уха утюгом. Ожог другого уха при звонке в скорую помощь"/>

</value>

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

<value code="A10.1" codeSystem="2.16.840.1.113883.6.42">

<originalText value="Oжoг уха утюгом. Ожог другого уха при звонке в скорую помощь"/>

</value>

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

<value nullFlavor="OTH" codeSystem="2.16.840.1.113883.6.96">

<originalText value="Oжoг уха утюгом. Ожог другого уха при звонке в скорую помощь"/>

<translation code="oжoг" codeSystem="2.16.840.1.113883.19.5.2">

</value>

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

<value nullFlavor="OTH" codeSystem="2.16.840.1.113883.6.96">

<originalText value="Ожог уха утюгом. Ожог другого уха при звонке в скорую помощь"/>

<translation id="s1" code="ожог"

codeSystem="2.16.840.1.113883.19.5.2">

<source xref="s1"/>

</value>

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

<value nullFlavor="OTH" codeSystem="2.16.840.1.113883.6.96"/>

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

<value nullFlavor="OTH" valueSet="2.16.840.1.113883.19.11.1" valueSetVersion="20070711"/>

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

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

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">

<originalText value="Целлюлит ноги"/>

</value>

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

Язык композиционных выражений, используемый в номенклатуре SNOMED, в настоящее время находится в стадии рецензирования. Его описание можно найти на сайте организации IHTSDO (International Health Terminology Standards Development Organization). Следующие два примера основаны на версии SNOMED СТ 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" (левый перелом большеберцовой кости), a "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 СТ для понятия "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 СТ определен набор квалифицирующих атрибутов, и только исследования (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 В95.6" codeSystem="2.16.840.1.113883.6.260"

codeSystemName="ICD-10 Dual Code Expression">

<originalText value="Острый бронхиолит, вызванный Staphylococcus aureus "/>

</value>

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

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

<value xsi:type="PQ" value="1" unit="g">

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

<value xsi:type="PQ" value="1" unit="mmol/l">

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

<value xsi:type="PQ" value="1" unit="mmol">

Количество аналита равно 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,

controllnformationRoot : characterstring,

controllnformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorld : 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 Примеры

<code xsi:type="CS" code="NS"/>

Простой код NS в подразумеваемой системе кодирования.

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

7.6.1 Введение

Эти типы данных используются при идентификации объектов, записей и предметов, в особенности для указания адресов URL, идентификаторов URI и телекоммуникационных адресов (см. рисунок 5).

7.6.2 Тип данных TEL (телекоммуникационный адрес)

7.6.2.1 Описание

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

Определение: указатель ресурса, идентифицируемый унифицированным идентификатором ресурсов (URI), например веб-страница, телефонный номер (голосового телефона или факса), либо иной указатель ресурса, воспринимаемый телекоммуникационным оборудованием, адрес электронной почты или другой ресурс местонахождения, который может быть описан унифицированным указателем ресурса (URL).

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

     
Рисунок 5 - Типы данных идентификации и местонахождения

Значения атрибута value в этом типе данных ограничены унифицированными указателями ресурсов, описанными в документах RFC 1738 и RFC 3966 организации IETF.

Примечание - Этот тип данных призван служить указателем, а не идентификатором ресурса; он используется для указания ресурса местонахождения в форме такого указателя URL, знание которого позволяет определить местонахождение объекта. Однако в некоторых сценариях для указания ресурса местонахождения используется идентификатор URI. Хотя тип данных TEL позволяет использовать идентификаторы URI, они всегда должны указывать на ресурсы местонахождения. Типичным примером служит использование идентификаторов URI для указания вложений в сообщения SOAP.

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

type TEL = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controllnformationRoot : characterstring,

controllnformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorld : Set (characterstring),

value : characterstring,

use : Set (TelecommunicationAddressUse),

capabilities : Set (TelecommunicationCapability),

useablePeriod : QSET (TS)

)

7.6.2.3 Атрибуты

7.6.2.3.1 value : Uri: унифицированный идентификатор ресурсов (URI), определенный в соответствии с документом RFC 2396 организации IETF.

Идентификатор URI указывает протокол и контактную точку, определенную этим протоколом для ресурса.

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

Если атрибут value имеет тип пустоты nullFlavor, то он не обязан содержать правильный указатель URL. К примеру, если причина пустоты имеет значение UNK (не известен), то атрибут value может иметь просто значение "tel:", указывающее, что не известен телефонный номер.

7.6.2.3.2 use : Set(TelecommunicationAddressUse): один или несколько кодов, указывающих системе или пользователю, какой из похожих телекоммуникационных адресов следует использовать при определенной потребности во взаимодействии.

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

Непустые значения, присваиваемые атрибуту use, должны браться из системы кодирования HL7 TelecommunicationAddressUse. Текущие значения приведены в таблице 12.

Таблица 12 - Перечисление TelecommunicationAddressUse, ОИД: 2.16.840.1.113883.5.1011

Синтаксис ИСО/МЭК 11404 для типа данных атрибута use:

type TelecommunicationAddressUse = enumeration (H, HP, HV, WP, DIR,

PUB, BAD, TMP, AS, EC, MC, PG)

7.6.2.3.3 capabilities : Set(TelecommunicationCapability): один или несколько кодов, указывающих системе или пользователю, какие возможности взаимодействия доступны по данному телекоммуникационному адресу.

Непустые значения, присваиваемые атрибуту use, должны браться из системы кодирования HL7 TelecommunicationCapability. Текущие значения приведены в таблице 13.

Таблица 13 - Перечисление TelecommunicationCapability, ОИД: 2.16.840.1.113883.5.1118

Синтаксис ИСО/МЭК 11404 для типа данных атрибута capabilities:

type TelecommunicationCapability = enumeration (voice, fax, data, tty, sms)

7.6.2.3.4 useablePeriod : QSET(TS): периоды времени, в течение которых можно пользоваться данным телекоммуникационным адресом.

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

7.6.2.4 Равенство

Два непустых значения типа TEL равны, если их канонические формы имеют одно и то же значение атрибутов value. Атрибуты use и useablePeriod исключаются из проверки на равенство.

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

- атрибут value должен присутствовать.

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

inv "атрибут value требуется": isNotNull implies value.oclIsDefined

def: let scheme(s : String) : Boolean

= value.substring(0, s.size) = s

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

noUpdateOrHistory(useablePeriod)

7.6.2.6 Операции

7.6.2.6.1 canonical : TEL: форма телекоммуникационного адреса, из которого удалены все разделители и другие незначащие символы.

Синтаксис схемы tel: позволяет указывать в номере телефона такие символы, как "(" и ")", представляющие собой синтаксические разделители, не меняющие собственно телефонный номер. Функция canonical вырезает эти символы из адресной части URL. Какие именно символы вырезаются, зависит от схемы.

Синтаксис схемы mailto: позволяет указывать дополнительное имя и данные заголовка. Эта дополнительная информация вырезается из канонической формы схемы mailto:, оставляя только чистый(е) адрес(а) электронной почты.

7.6.2.7 Расширения синтаксиса URL/URI syntax

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

- x-text-tel: - указывает, что принимающим устройством является телетайп; синтаксис адресной части URL тот же, что у TEL;

- x-text-fax: - указывает, что принимающим устройством является факсимильный аппарат; синтаксис адресной части URL тот же, что у TEL. Этот протокол заменяет протокол fax, запрещенный организацией W3C.

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

- hl7ii - ссылка на значение типа II, определенное в настоящем стандарте. Полный синтаксис этого расширения URN имеет следующий вид: urn:hl7ii:{root}[:{extension}], где {root} {extension} (если присутствует) являются компонентами значения типа II, на которое дается ссылка. Полные детали этого протокола определены в спецификации HL7 Abstract Data Types.

7.6.2.8 Примеры

7.6.2.8.1 Веб-адрес

<example xsi:type="TEL" value="http://www.temp.org/example/234232"/>

Ссылка на веб-страницу, доступную по адресу http://www.temp.org/example/234232.

7.6.2.8.2 Телефон, являющийся одновременно домашним и служебным

<example xsi:type="TEL" value="tel:+15556755745"

use="H WP" capabilities="voice fax"/>

Номер домашнего телефона (H) лица, которое работает на дому (WP). Телефон способен принимать голосовые и факсимильные вызовы.

7.6.2.8.3 Неизвестный номер домашнего телефона

<example xsi:type="TEL" nullFlavor="UNK" value="tel:" use="H"/>

Неизвестный номер домашнего телефона (Н).

7.6.2.8.4 Рабочий телефон с дополнительным номером

<example xsi:type="TEL" value="tel:+1(555)6755745;postd=545" use="WP"/>

Указан рабочий телефон с дополнительным номером. Дополнительные номера используются не только в последовательности, набираемой после основного номера. Дополнительные детали приведены в документе RFC 3966 организации IETF. Каноническая форма для этого примера имеет вид <tel va lue="tel:+15556755745;postd=545" use="WP7>.

7.6.3 Тонкость TEL.URL

7.6.3.1 Описание

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

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

7.6.3.2 Инварианты

- код использования отсутствует;

- схема URL должна быть file, nfs, ftp, cid (для вложений в SOAP), http или https.

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

inv "код использования отсутствует": use->isEmpty

inv "схемы": ( scheme ( "file" ) or scheme ( "ftp" ) or

scheme ("cid") or scheme ("http") or scheme ("https")

or scheme ("nfs"))

7.6.4 Тонкость TEL.PERSON

7.6.4.1 Описание

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

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

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

- схема URL должна быть tel, x-text-fax, x-text-tel или mailto.

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

inv "телекоммуникационный адрес физического лица": scheme("tel") or

scheme ("x-text-fax") or scheme ("x-text-tel") or

scheme ("mailto")

7.6.5 Тонкость TEL.PHONE

7.6.5.1 Описание

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

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

7.6.5.2 Инварианты

- схема URL должна быть tel, x-text-fax или x-text-tel.

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

inv "телефон": scheme("tel") or

scheme("x-text-fах") or scheme("x-text-tel")

7.6.6 Тонкость TEL.EMAIL

7.6.6.1 Описание

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

Тонкость TEL.EMAIL ограничивает тип данных TEL адресом электронной почты.

7.6.6.2 Инварианты

- схема URL должна быть mailto.

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

inv "только электронная почта": scheme ("mailto")

7.6.7 Тип данных II (идентификатор экземпляра)

7.6.7.1 Описание

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

Уникальный идентификатор предмета или объекта.

Пример - Объектный идентификатор объектов, определенных в эталонной информационной модели HL7 RIM, номер медицинской карты, идентификатор направления, идентификатор услуги в прейскуранте, регистрационный номер транспортного средства и т.д.

Примечание - Идентификаторы экземпляров обычно определены на основе объектных идентификаторов ИСО.

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

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

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

type II = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controllnformationRoot : characterstring,

controllnformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorld : Set (characterstring) ,

root : characterstring,

extension : characterstring,

identifierName : characterstring,

displayable : boolean,

scope: IdentifierScope,

reliability : IdentifierReliability

)

7.6.7.3 Атрибуты

7.6.7.3.1 root : Uid: уникальный идентификатор, гарантирующий глобальную уникальность идентификации объекта.

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

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

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

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

7.6.7.3.2 extension : String: строка символов, представляющая собой уникальный идентификатор в пространстве имен, определенном значением атрибута root.

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

В некоторых схемах идентификации определены определенные стили представления значений идентификаторов. Например, в США номер карточки социального страхования SSN (Social Security Number) обычно записывается с дефисом по шаблону "123-12-1234". Однако дефисы не являются значащими и такой номер SSN может быть представлен в форме "123121234" без дефисов. В том случае, если схемы идентификации предусматривают несколько вариантов представления идентификаторов, рабочая группа HL7 или организация ИСО могут принять правило выбора предпочтительной формы и указать его в документе, описывающем соответствующую внешнюю схему идентификации.

Если атрибут extension отсутствует в непустом значении типа II, то значение атрибута root представляет полный уникальный идентификатор. Если же значение атрибута root не является полным уникальным идентификатором, а значение атрибута extension неизвестно, то значение типа II должно иметь причину пустоты nullFlavor даже в том случае, если атрибут root имеет непустое значение.

7.6.7.3.3 identifierName : String: человеко-итаемое имя пространства имен, представленного атрибутом root.

Примечание - Это описательное имя фактического пространства имен, например, "California, US Driving Licence Number, 1970-". Значение атрибута identifierName не отсылает к организации, присвоившей идентификатор (например, California Department of Motor Vehicles). Оно призвано служить в качестве человекочитаемой метки, если идентификатор должен быть представлен человеку, для которого ОИД не является значащим.

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

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

Вообще говоря, атрибут identifierName рекомендуется указывать только в том случае, если присутствует атрибут extension, что позволяет, например, вывести на экран строку "California, US Driving Licence Number, 1970-: 123456789". Кроме того, что этот текст является исключительно описателем пространства имен, никакие другие указания по его содержанию не даются, например, "Driving Licence" или даже "California Driving Licence" не были бы идеальными значениями этого атрибута. Однако форматирование, преобразование в верхний регистр, пробельные элементы, язык и т.д. полностью оставляются на усмотрение отправителя.

7.6.7.3.4 displayable : Boolean: если идентификатор предназначен для представления человеку и ввода данных, то этот атрибут должен иметь значение true, если только для машинной обработки - значение false.

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

7.6.7.3.5 scope : IdentifierScope: область, в которой идентификатор применяется к ассоциированному с ним объекту.

Непустые значения, присваиваемые атрибуту scope, должны браться из системы кодирования HL7 IdentifierScope. Текущие значения приведены в таблице 14.

Таблица 14 - Перечисление IdentifierScope, ОИД: еще не присвоен

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

type IdentifierScope = enumeration (BUSN, OBJ, VER, VW)

7.6.7.3.6 reliability : IdentifierReliability: известная надежность идентификатора. Значение этого атрибута может использоваться в алгоритмах сопоставления идентификаторов.

Непустые значения, присваиваемые атрибуту reliability, должны браться из системы кодирования HL7 IdentifierReliability. Текущие значения приведены в таблице 15.

Таблица 15 - Перечисление IdentifierReliability, ОИД: еще не присвоен

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

type IdentifierReliability = enumeration (ISS, VRF, UNV)

7.6.7.4 Равенство

Два идентификатора экземпляра равны только в том случае, если у них нет причины пустоты nullFlavor, значения атрибутов root равны, а значения атрибутов extension либо оба пусты, либо равны. Атрибуты displayable, identifierName, scope и reliability игнорируются, хотя свойства scope и reliability могут быть использованы для определения того, насколько равенство значимо в данном контексте.

7.6.7.5 Инварианты

- если значение типа II не имеет причины пустоты nullFlavor, атрибут root должен присутствовать.

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

inv "атрибут root требуется": isNotNull implies root.oclIsDefined

7.6.7.6 Комментарии к технической спецификации ИСО/ТС 22220

В технической спецификации ИСО/ТС 22220 определены четыре поля идентификаторов субъекта медицинской помощи: обозначение, географическая область, источник и тип. Из них только первый, обозначение, относится к области применения типа данных II. Обозначение определено как число или код, присваиваемый лицу организацией, учреждением, агентством или местными властями в целях уникальной идентификации субъекта здравоохранения в пределах этой организации здравоохранения, учреждения, агентства или территории.

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

Примечание - В типе данных II предусмотрено поле имени идентификатора (identifierName), но оно не обеспечивает формальную поддержку идентификации источника идентификатора.

7.6.7.7 Примеры

7.6.7.7.1 Водительские права

<example xsi:type="II" root="2.16.840.1.113883.12.333"

extension="45634353344"

reliability="UNV" scope="BUSN"/>

ОИД 2.16.840.1.113883.12.333 был создан рабочей группой HL7 как общий идентификатор уполномоченных организаций по выдаче водительских прав. Конкретный номер водительских прав содержится в атрибуте extension. Атрибут надежности имеет значение UNV - номер водительских прав был введен в систему, но она не может его проверить. Атрибут scope для водительских прав имеет значение BUSN, поскольку номер водительских прав может использоваться для идентификации нескольких разных объектов, ассоциированных с одним и тем же пациентом. В примере использован общий ОИД уполномоченных организаций по выдаче водительских прав, но его не рекомендуется использовать на практике, поскольку таких организаций много и выданные ими номера могут пересекаться.

7.6.7.7.2 Номер карточки социального страхования SSN в США

<example xsi:type="II" root="2.16.840.1.113883.4.1" extension="123456789"

reliability="UNV" scope="BUSN"/>

Хотя этот идентификатор часто форматируют по шаблону 123-45-6789, дефисы "-" следует удалить, поэтому правильный формат - 123456789.

7.6.7.7.3 Номер пациента, присвоенный организацией NHS

<example xsi:type="II" root="2.16.840.1.113883.2.1.4.1"

extension="9999999484"

reliability="VRF" scope="BUSN"/>

Это пример номера пациента, присваиваемого организацией NHS в Англии и Уэльсе. ОИД для атрибута root, идентифицирующий организацию NHS, равен 2.16.840.1.113883.2.1.4.1.

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

Как правило, атрибут scope имеет значение BUSN. В большинстве информационных систем учреждений, управляемых организацией NHS, предусмотрены программные интерфейсы к главному регистру пациентов, который ведет эта организация, или к другим системам, взаимодействующим с этим регистром, поэтому в этих случаях атрибут надежности reliability имеет значение "VRF" (проверен системой).

7.6.7.7.4 Номер пациента в австралийской системе medicare

<example xsi:type="II" root="1.2.36.174030967" extension="1234567892"

reliability="VRF" scope="OBJ"/>

Это пример номера пациента в австралийской системе medicare. Значением атрибута root служит корневой ОИД организации HIC, присваивающей такие номера. (Следовало бы указать более детальный ОИД, но в настоящее время эта организация еще не опубликовала схему своей ветви ОИД.) Атрибут надежности reliability имеет значение "VRF", поскольку система-отправитель проверила правильность номера пациента в организации HIC с помощью одного из ее электронных интерфейсов. Атрибут scope имеет значение OBJ, так как этот номер используется только для идентификации лицевого счета семьи пациента, который ведет организация HIC.

7.6.7.7.5 Идентификатор записи

<example xsi:type="II" root="D6A7AB37-4220-4D80-9052-8A4959A203E3"

reliability="ISS" scope="VER"/>

Идентификатор UUID, присвоенный системой-отправителем конкретной версии записи, представленной значением типа II.

7.6.7.7.6 Номер результата лабораторного анализа

<example xsi:type="II" root="2.16.840.1.113883.19.5.34" extension="2345344"

reliability="ISS" scope="OBJ"/>

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

7.6.7.7.7 Идентификатор компонента медицинской карты, соответствующего стандарту ИСО 13606

<example xsi:type="II" root="2.16.840.1.113883.19.5.462" extension="976295765"

reliability="VRF" scope="VER"/>

В этом примере показано значение идентификатора rc_id, определенного в ИСО 13606-1 (идентификатор компонента медицинской карты), остающегося неизменным в различных хранилищах электронных медицинских карт, однако меняющегося для различных версий компонента и не сохраняющегося в рабочем процессе перехода состояний компонента. Поэтому атрибут scope имеет значение "VER" (идентификатор версии).

Значение атрибута надежности reliability равно VRF; в контексте ИСО 13606 использование значения ISS не рекомендовано, поскольку оно может быть использовано только системой, которая его присвоила, а это создает сложности для аттестации содержания компонента.

Значение ISS в основном используется при управлении идентификацией пациентов, поскольку может способствовать процессу объединения/разъединения/слияния идентификаторов пациента.

7.6.7.7.8 Сообщение с моментальным снимком

<example xsi:type="DSET_II">

<item root="2.16.840.1.113883.19.5.971" extension="763491"

reliability="VRF" scope="OBJ"/>

<item root="2.16.840.1.113883.19.5.972" extension="351324"

reliability="VRF" scope="VER"/>

<item root="0282CA34-2E4E-4B9D-82A5-BD2BF8497940"

reliability="ISS" scope="VW"/>

</example>

В этом примере показано полное использование типа данных DSET (II) в сообщении. В этом сообщении передается моментальный снимок объекта, являющегося экземпляром класса, у которого атрибут идентификатора имеет тип DSET (II). Информация об идентификаторе экземпляра класса, имеющего атрибут DSET (II), основана на объекте с идентификатором 763491 в пространстве имен ОИД 2.16.840.1.113883.19.5.971. Версия объекта, для которого сделан моментальный снимок, имеет идентификатор 351324 в пространстве имен ОИД 2.16.840.1.113883.19.5.972. Наконец, моментальному снимку присвоен свой собственный идентификатор UUID 0282CA34-2E4E-4B9D-82A5-BD2BF8497940, который может использоваться при регистрации данного моментального снимка в системном журнале.

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

7.7.1 Введение

Эти типы данных предназначены для передачи фамилий, имен, отчеств и адресов (см. рисунок 6).

7.7.2 Тип данных ХР (name or address part)

Абстрактный частный тип

7.7.2.1 Описание

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

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

type ХР = class (

nullFlavor : NullFlavor,

value : characterstring,

code : characterstring,

codeSystem : characterstring,

codeSystemVersion : characterstring,

language : characterstring,

)

7.7.2.3 Атрибуты

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

Дальнейшая информация о причине пустоты nullFlavor приведена в 7.3.3.3.1.

     
Рисунок 6 - Типы данных фамилии, имени, отчества и адреса

7.7.2.3.2 value: String : фактическое строковое значение части. Если причина пустоты nullFlavor отсутствует, то в этом атрибуте должно присутствовать некоторое содержание.

7.7.2.3.3 code: String : код, присвоенный части в некоторой системе кодирования при ее наличии.

7.7.2.3.4 codeSystem : String: система кодирования, из которой взято значение атрибута code. Выбор системы кодирования зависит от типа части, определенного в конкретной специализации.

Если атрибут code имеет значение, то должен иметь значение и атрибут codeSystem.

7.7.2.3.5 codeSystemVersion : String: версия системы кодирования, если таковая должна быть указана.

Если атрибут codeSystemVersion имеет значение, то должен иметь значение и атрибут codeSystem.

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

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

7.7.2.4 Равенство

Для значений типа ХР понятие равенства не определено.

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

- если атрибут code имеет значение, то атрибут codeSystem должен иметь значение;

- атрибут codeSystemVersion может иметь значение только в случае, если атрибут codeSystem имеет значение.

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

def: let isNull : Boolean = nullFlavor.oclIsDefined

def: let isNotNull : Boolean = not isNull

inv "при наличии атрибута code требуется атрибут codeSystem":

code.oclIsDefined implies

codeSystem.oclIsDefined

inv "атрибут codeSystemVersion разрешен только при наличии атрибута

codeSystem": codeSystemVersion.oclIsDefined implies

codeSystem.oclIsDefined

7.7.3 ADXP (компонент адреса)

7.7.3.1 Описание

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

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

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

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

type ADXP = class (

nullFlavor : NullFlavor,

value : characterstring,

code : characterstring,

codeSystem : characterstring,

codeSystemVersion : characterstring,

language : characterstring,

type : AddressPartType,

)

7.7.3.3 Атрибуты

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

Непустые значения, присваиваемые атрибуту type, должны браться из системы кодирования HL7 AddressPartType. Текущие значения приведены в таблице 16.

Таблица 16 - Перечисление AddressPartType, ОИД: 2.16.840.1.113883.5.16

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

type AddressPartType = enumeration (AL, ADL, UNID, UNIT, DAL, DINST,

DINSTA, DINSTQ, DMOD, DMODID, SAL, BNR, BNN, BNS, STR, STB, STTYP,

DIR, INT, CAR, CEN, CNT, CPA, CTY, DEL, РОВ, PRE, STA, ZIP)

7.7.3.4 Равенство

Два значения типа ADXP равны, если попарно равны значения их атрибутов type и value. Атрибуты code и language игнорируются.

Примечание - Разъяснение: два пустых значения атрибутов type считаются равными.

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

- если атрибут type не пуст, то атрибут value может быть пустым только в том случае, когда значение атрибута type равно DEL.

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

inv "атрибут value требуется": isNotNull implies value.size > 0

7.7.3.6 Привязка

В компоненте адреса, у которого атрибут type имеет значение CNT (страна), пара свойств code+codeSystem, унаследованная от типа данных ХР, должна быть привязана к двухбуквенным, трехбуквенным или числовым кодам стран, определенным в ИСО 3166. В объявлениях соответствия могут быть указаны привязки других типов компонентов адреса или ограничения выбора кодов стран.

7.7.4 Тип AD (адрес)

7.7.4.1 Описание

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

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

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

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

type AD = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controllnformationRoot : characterstring,

controllnformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorld : Set (characterstring),

part : Sequence (ADXP),

use : Set (PostalAddressUse),

useablePeriod : QSET (TS),

isNotOrdered : boolean

)

7.7.4.3 Атрибуты

7.7.4.3.1 part : Sequence(ADXP): последовательность компонентов адреса, например, названия улицы или номера почтового ящика, города, почтового индекса, страны и т.д.

7.7.4.3.2 Свойство use : Set(PostalAddressUse): один или несколько кодов, информирующих систему или пользователя о том, какой из адресов следует выбрать для данной цели.

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

Непустые значения, присваиваемые атрибуту type, должны браться из системы кодирования HL7 PostalAddressUse. Текущие значения приведены в таблице 17.

Таблица 17 - Перечисление PostalAddressUse, ОИД: 2.16.840.1.113883.5.1012

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

type PostalAddressUse = enumeration (H, HP, HV, WP, DIR, PUB, BAD,

TMP, ABC, IDE, SYL, PHYS, PST, SRCH, SNDX, PHON)

7.7.4.3.3 useablePeriod : QSET(TS): общая спецификация времени GTS (General Timing Specification), задающая периоды времени, в течение которых можно пользоваться данным адресом. Используется для указания различных адресов для различных дней недели или года.

7.7.4.3.4 isNotOrdered : Boolean: булевское значение, указывающее, известен порядок компонентов адреса или нет. Хотя компоненты адреса всегда передаются в определенном порядке, тем не менее порядок, в котором они должны быть представлены пользователю, может быть, а может и не быть важным или значимым. Это можно указать с помощью свойства isNotOrdered. По умолчанию этот атрибут имеет значение false.

7.7.4.4 Равенство

Два адресных значения считаются равными, если они имеют одинаковые компоненты адреса вне зависимости от их упорядочения.

Атрибуты use, useablePeriod и isNotOrdered исключаются из проверки на равенство.

Примечания

1 Даже если атрибут isNotOrdered имеет значение false, то есть известно, что порядок представления компонентов адреса важен, при проверке на равенство его не учитывают.

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

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

- значение типа AD или имеет причину пустоты nullFlavor, или по меньшей мере один компонент.

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

inv "пуст или имеет компоненты": isNull xor part->notEmpty

inv "атрибуты типа данных AD не имеют истории или режима изменения":

noUpdateOrHistory(useablePeriod)

7.7.4.6 Комментарии к технической спецификации ИСО/ТС 22220

Различные компоненты адреса, определенные в технической спецификации ИСО/ТС 22220, отображаются на типы компонентов адреса, и тип адреса отображается на атрибут use. Признаки точности дат начала и завершения частично отображаются на точность предоставляемых дат.

7.7.4.7 Примеры

7.7.4.7.1 Адрес с расположением компонентов

<example xsi : type="AD" use="WP">

<part value="1050 W Wishard Blvd" />

<part type="DEL"/>

<part value="RG 5th floor"/>

<part type="DEL"/>

<part value="Indianapolis, IN 46240"/>

</example>

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

7.7.4.7.2 Адрес с типами компонентов

<example xsi : type="AD" use="WP">

<part type="AL" value="1050 W Wishard Blvd"/>

<part type="AL" value="RG 5th floor"/>

<part type="CTY" value="Indianapolis"/>

<part type="STA" value="IN"/>

<part type="ZIP" value="46240"/>

</example>

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

Примечание - Хотя в этом представлении адреса предполагается, что после первых двух строк адреса следуют дополнительные строки, это не вытекает из данного примера (см. 7.7.4.8).

7.7.4.7.3 Типы строк

<example xsi:type="AD" use="WP">

<part type="SAL" value="1050 W Wishard Blvd"/>

<part type="ADL" value="RG 5th floor"/>

<part type="CTY" value="Indianapolis"/>

<part type="STA" value="IN"/>

<part type="ZIP" value="46240"/>

</example>

Это тот же самый адрес, но предназначенный для системы, различающей разные типы строк.

7.7.4.7.4 Полностью типизированные адреса

<example xsi:type="AD" use="WP">

<part type="BNR" value="1050"/>

<part type="DIR" value="W"/>

<part type="STB" value="Wishard"/>

<part type="STTYP" value="Blvd"/>

<part type="ADL" value="RG 5th floor"/>

<part type="CTY" value="Indianapolis"/>

<part type="STA" value="IN"/>

<part type="ZIP" value="46240"/>

</example>

Тот же самый адрес, в котором выделен каждый компонент; такую форму не используют в США. Однако она полезна в Германии, где многие системы хранят номер дома в отдельном поле.

<example xsi:type="AD" use="HP">

<part type="STR" value="Windsteiner Weg"/>

<part type="BNR" value="54a"/>

<part type="CNT" code="DEU" codeSystem=" 1.0.3166.1.2"

value="D"/>

<part type="ZIP" value="14165"/>

<part type="CTY" value="Berlin"/>

</example>

Это домашний адрес в стандартном формате, принятом в Германии. Для обеспечения интероперабельности страна закодирована в соответствии с ИСО 3166.

7.7.4.7.5 Неизвестные адреса

<example xsi:type="AD" use="WP" nullFlavor="UNK"/>

Служебный адрес неизвестен.

7.7.4.8 Представление адресов

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

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

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

7.7.5 Тип данных ENXP (часть именования сущности)

7.7.5.1 Описание

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

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

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

type ENXP = class (

nullFlavor : NullFlavor,

value : characterstring,

code : characterstring,

codeSystem : characterstring,

codeSystemVersion : characterstring,

language : characterstring,

type : EntityNamePartType,

qualifier : Set (EntityNamePartQualifier)

)

7.7.5.3 Атрибуты

7.7.5.3.1 type : EntityNamePartType: указывает, является ли данный компонент именем, фамилией, префиксом, суффиксом и т.д.

Не каждый компонент именования должен иметь код типа type. Если этот код не известен, не применим или просто не определен, то это выражается пустым значением (partType.isNull). Например, по именованию "Rogan Sulma" нельзя сделать уверенное заключение, что является именем, а что фамилией. Может даже оказаться, что "Rogan" - титул.

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

Таблица 18 - Перечисление EntityNamePartType, ОИД 2.16.840.1.113883.5.1010

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

type EntityNamePartType = enumeration (FAM, GIV, TITLE, DEL)

Если имя пишется через дефис, например, Mary-Ann, то возникает неоднозначность, надо ли использовать два компонента имени с разделителем, или один компонент имени, в котором указан дефис. Можно использовать следующий эмпирический подход: если каждая часть имени или отчества должна превращаться в инициал, то надо использовать два компонента и разделитель.

7.7.5.3.2 qualifier: Set(EntityNamePartQualifier): этот квалификатор содержит ряд кодов, каждый из которых указывает определенную подкатегорию компонента именования, дополняющую основной тип компонента.

Пример - Можно указать, что имя является прозвищем (код CL), фамилия может быть присвоена при вступлении в брак (код SP) или данной при рождении (код BR).

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

Таблица 19 - Перечисление EntityNamePartQualifier, ОИД 2.16.840.1.113883.5.1122

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

type EntityNamePartQualifier = enumeration (LS, AC, NB, PR, HON, BR,

AD, SP, MID, CL, IN, PFX, SFX)

Скандинавские понятия "Mellomnavn/Mellannamn" переводятся как "среднее имя", но не совпадают с английским понятием "middle name", которое попросту означает все имена после первого. Квалификаторы префикса (PFX) и суффикса (SFX) взаимно несовместимы. Не допускается указывать их оба применительно к одному и тому же компоненту. Нет необходимости помечать компонент именования, следующий за префиксом, как суффикс, или наоборот.

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

7.7.5.4 Равенство

Два значения типа EXNP считаются равными, если они имеют попарно равные атрибуты type и value. Атрибуты code, language и qualifier игнорируются.

Атрибуты use, useablePeriod и isNotOrdered исключаются из проверки на равенство.

Примечание - Разъяснение: два пустых значения атрибутов type считаются равными.

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

- если атрибут part не пуст, то атрибут value не может быть пустым.

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

inv "атрибут value требуется": isNotNull implies value.size > 0

7.7.5.6 Привязка

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

7.7.5.7 Примечания к реализации

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

Таблица 20 - Отношения между типами компонентов и квалификаторами

7.7.6 Тип данных EN (именование сущности)

7.7.6.1 Описание

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

Именование лица, организации, места или предмета.

Пример - "Джим Боб Уолтон, мл.", "Health Level Seven, Inc.", "Озеро Tahoe" и т.д. Именование объекта может быть простой строкой символов или состоять из нескольких компонентов, например, "Джим", "Боб", "Уолтон" и "мл."; "Health Level Seven" и "Inc."; "Озеро" и "Tahoe".

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

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

type EN = class (

validTimeLow : characterstring,

validTimeHigh : characterstring,

controllnformationRoot : characterstring,

controllnformationExtension : characterstring,

nullFlavor : NullFlavor,

updateMode : UpdateMode,

flavorld : Set (characterstring) ,

part : Sequence(ENXP),

use : Set (EntityNameUse)

)

7.7.6.3 Атрибуты

7.7.6.3.1 part : Sequence(ENXP): последовательность компонентов, например, имени или фамилии, префикса, суффикса.

7.7.6.3.2 use : Set(EntityNameUse): один или несколько кодов, информирующих систему или пользователя о том, какое из именований следует выбрать для данной цели.

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

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

Таблица 21 - Перечисление EntityNameUse, ОИД 2.16.840.1.113883.5.1120