ГОСТ Р 57304-2016/ISO/TS 13582:2015. Национальный стандарт Российской Федерации. Информатизация здоровья. Совместное использование регистра объектных идентификаторов

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

Health informatics. Sharing of OID registry information

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному документу ISO/TS 13582:2015 «Информатизация здоровья. Совместное использование регистра объектных идентификаторов» (ISO/TS 13582:2015 «Health informatics — Sharing of OID registry information», IDT).

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

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

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

Введение

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

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

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

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

В настоящем стандарте в форме информационной модели описана обязательная и необязательная информация, которая должна содержаться в любом регистре ОИД.

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

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

Содержание настоящего стандарта включает в себя:

• информационную модель и соответствующий XML-формат экспорта содержания регистра ОИД, пригодного, например, для его загрузки в иной регистр ОИД;
• обсуждение типичных сценариев использования регистров или хранилищ ОИД;
• описание системы разрешения объектных идентификаторов ORS (Object Identifier Resolution System), обеспечивающей механизм извлечения информации, относящейся к объектному идентификатору, с указаниями по ее использованию.

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

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

ISO 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code (Коды для представления названий языков. Часть 1. Двухбуквенный код)

ISO 3166, Codes for the representation of names of countries — The International Organization for Standardization, 3rd edition, part 1 ISO 3166-1 (Коды для представления названий стран. Международная организация по стандартизации, 3-е издание. Часть 1)

ISO 21090, Health informatics — Harmonized data types for information interchange (Информатизация здоровья. Гармонизированные типы данных для обмена информацией)

ISO/HL7 21731, Health informatics — HL7 version 3 — Reference information model — Release 4 (Информатизация здоровья. HL7 версия 3. Эталонная информационная модель. Выпуск 4)

ITU-T X.660/ISO/IEC 9834-1, Information technology — Open Systems Interconnection — Procedures for the operation of OSI Registration Authorities: General procedures and top arcs of the ASN.1 Object Identifier tree (Информационная технология. Взаимосвязь открытых систем. Процедуры действий уполномоченных по регистрации ВОС. Часть 1. Общие процедуры и верхние дуги дерева идентификатора объекта АСН.1)

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

3 Термины, определения и сокращения

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

В настоящем стандарте применены термины по ИСО 21090, а также следующий термин с соответствующим определением:

3.1.1 свойство (property): Описательная характеристика системы, присущая состоянию или процессу, относящаяся к определяемому компоненту или к множеству элементов данных (систем, компонентов, видов свойств) и являющаяся общей для совокупности конкретных свойств.

3.2 Сокращения

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

HL 7 — Health Level Seven Inc;

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

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

OMG — Object Management Group;

W3C — World Wide Web Consortium (Консорциум Всемирной паутины);

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

ITU — International Telecommunication Union (Международный союз электросвязи);

IEC — International Electrotechnical Commission (Международная электротехническая комиссия, МЭК).

4 Разъяснение терминов

4.1 Регистры и хранилища объектных идентификаторов

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

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

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

4.2 Уполномоченный регистратор

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

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

4.3 Ответственная (управляющая) организация

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

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

4.4 Заявляющая организация (ЗО)

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

4.5 Текущий регистратор

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

4.6 Первичный регистратор

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

Настоящий стандарт настоятельно рекомендует проводить различие между следующими субъектами:

• уполномоченный регистратор (УР) — лицо (если оно известно) или организация, назначившая ОИД (то есть создавшая его экземпляр);
• заявляющая организация (ЗО), подавшая заявку на выделение ОИД (который может оказаться тем же экземпляром). В этом смысле первичный регистратор является и уполномоченным регистратором (УР).

4.7 Первичный уполномоченный регистратор

Первичным уполномоченным регистратором ОИД является самое первое лицо или организация, которой этот ОИД был выделен уполномоченным регистратором вышестоящего ОИД. В соответствии с рекомендациями ITU-T X.660/ИСО/МЭК 9834-1, первичный УР не может быть изменен (если ответственность за данный ОИД была передана кому-то другому, то информация о нем сохраняется в разделе «Текущий уполномоченный регистратор», а в раздел «Первичный уполномоченный регистратор» изменения не вносятся.

Обсуждение: это уполномоченный регистратор (УР), выделивший данный ОИД.

4.8 Рекомендации ITU-T X.660/ИСО/МЭК 9834-1

В рекомендациях ITU-T Recommendation X.660 приведены следующие определения:

• 3.6.8 уполномоченный регистратор: Субъект, например, организация, стандарт или автоматизированная система, выполняющая регистрацию одного или нескольких типов объектов (см. также «международный уполномоченный регистратор»);
• 3.6.2 административная роль (уполномоченного регистратора): Присваивание однозначных имен в соответствии с Рекомендациями/международным стандартом, определяющим процедуры, выполняемые регистратором;
• 3.6.14 техническая роль (уполномоченного регистратора): Запись определений объектов, которым присвоены имена, и проверка, что эти определения соответствуют Рекомендациям/международному стандарту, определяющему форму таких определений.

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

5 Объектные идентификаторы в здравоохранении

5.1 Общие положения

Объектные идентификаторы (ОИД) представляют собой уникальные идентификаторы, назначаемые любым типам объектов. Они определены в документах ITU-T X.660/ИСО/МЭК 9834-1. Такая система идентификации объектов и понятий обеспечивает возможность надежного электронного обмена информацией. Администрирование и регистрация ОИД регулируются сводом правил.

Точное обозначение объектов и понятий является обязательным требованием для стандартизованного обмена информации. Применение глобально уникального идентификатора объекта будет способствовать международной интероперабельности различных приложений (например, информационных систем здравоохранения). Например, объектные идентификаторы часто используются в документах HL7 и в сообщениях, соответствующих стандартам HL7, а также в сертификатах, соответствующих рекомендациям ITU-T X.509.

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

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

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

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

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

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

5.2 Дополнительные описания

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

В приложении Б описаны сценарии использования регистров или хранилищ ОИД, а также система разрешения объектных идентификаторов ORS (Object Identifier Resolution System), предназначенная для доступа к ОИД, используемым в информационных системах здравоохранения, с помощью веб-служб REST.

В приложении В описана XML-схема представления содержания регистров.

5.3 Сопутствующая работа

Эта работа связана с обсуждениями объектных идентификаторов в рамках рабочей программы комитетов ИСО/ТС 215, HL7 International, ИСО/МЭК JTC 1/SC 6, ITU-T SG 17 и других организаций, имеющих дело с ОИД и регистрами ОИД.

6 Метод

6.1 Анализ требований

Базовый набор данных и соответствующее его представление на языке XML, представляющее формат обмена, требуемый для регистрации ОИД и передачи метаданных, разработаны на основе тщательного анализа международных регистров ОИД, используемых в информационных системах здравоохранения, например, регистр комитета HL7 International (http://hl7.org) и несколько европейских хранилищ (France Telecom-Orange, см. http://www.oid-info.com, Германский регистр ОИД, который ведется организацией DIMDI, см. http://www.dimdi.de) (см. таблицу 1). При этом анализировались содержание регистров, атрибуты и даже правила присваивания ОИД.

Таблица 1

Анализ некоторых элементов данных в разных регистрах и хранилищах ОИД (по состоянию на 2009 год)

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

6.2 Подготовительная работа

Настоящий стандарт подготовлен техническим комитетом ИСО/ТК215 в сотрудничестве с организацией HL7 International, а также с подкомитетами ИСО/МЭК JTC 1/SC 6 и ITU-T SG 17.

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

7 Информационная модель

7.1 Общие положения

Для обмена объектными идентификаторами и их метаданными между разными регистрами и прикладными программами кроме собственно ОИД целесообразно использовать следующие дополнительные элементы данных (см. также рекомендации ITU-T X.667/ИСО/МЭК 9834-8, http://www.itu.int/rec/T-REC-X.667/en, и раздел часто задаваемых вопросов на сайте oid-info, http://www.oid-info.com/fag.htm#iri):

• описания;
• информация о статусе;
• категорирование;
• временные рамки;
• примечания;
• версии;
• связи;
• отношения к другим ОИД и внешним источникам;
• уполномоченные регистраторы и ответственные организации;
• ассоциированные лица.

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

Ниже приведены дополнительные примечания:

• цвета классов позаимствованы из ИСО/HL7 21731, классы «Person» и «Organization», выделенные светло-зеленым цветом, являются точными копиями классов «Person» и «Organization», выделенных зеленым цветом. Это сделано, чтобы избежать повторение атрибутов классов. Полужирным шрифтом выделены имена обязательных ассоциаций (см. также 7.2.1);
• обозначение «<=» используется для указания привязки кодированного атрибута к словарному домену. Например, в классе уполномоченного регистратора RegistrationAuthority атрибут code должен использовать словарь, определенный в наборе значений (перечислении) «RoleCodes».

7.2 Описание таблиц и обозначений

7.2.1 Таблицы атрибутов классов и таблицы ассоциаций

Таблицы атрибутов классов (в информационной модели) имеют следующий заголовок:

Графы имеют следующее содержание:

• «Атрибут класса» — имя атрибута класса;
• «Описание» — описание (назначение) атрибута;
• «Тип данных» — имя типа данных (или тонкости типа данных), определенного в стандарте ИСО 21090;
• «Кратность» — кратность значений атрибута, например, «0..1» или «1..*»;
• «Обяз.» — обязательность атрибута, принимающая одно из следующих трех значений:

1. «О» (обязательный), указывающее, что информация ДОЛЖНА присутствовать в каждом экземпляре выборки из регистра (хранилища) ОИД;

2. «Т» (требуемый), указывающее, что информация ДОЛЖНА присутствовать, если только из соображений конфиденциальности она не должна быть скрыта;

3. «Н» (необязательное), указывающее, что информация необязательна;

• «Длина» — рекомендованная длина значения (как указание для реализации, например, ограничения длины строк, хранящихся в базе данных).

Кроме того, таблицы ассоциаций (в информационной модели) имеют следующий заголовок:

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

• «Ассоциация» — имя ассоциации с классом;
• «Класс» — имя ассоциированного класса.

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

Некоторые атрибуты классов или ассоциации могут иметь дополнительные ограничения, указанные в отдельной строке, начинающейся сокращением «CONF» (conformance — соответствие), дополненным суффиксом, являющимся сокращенным идентификатором ограничения (например, «rg-vt»), за которым следует объявление соответствия.

Пример - «CONF rg-vt: элемент validTime ДОЛЖЕН присутствовать и у его типа данных IVL_TS хотя бы один дочерний элемент должен иметь значение».

7.3 Формат обмена XML

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

В следующих подразделах детально обсуждаются классы и их атрибуты.

7.4 Класс Registry

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

Рисунок 2 — Класс Registry

7.4.1 Атрибуты

Атрибуты класса Registry представлены в таблице 2.

7.4.1.1 Атрибут validTime

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

CONF rg-vt: элемент validTime должен присутствовать и иметь тип данных IVL_TS, у которого задана, по крайней мере, нижняя граница интервала.

7.4.1.2 Атрибут scopedOIDs

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

CONF rg-so: если регистр ОИД отвечает за выделение или регистрацию корневого ОИД, то этот ОИД должен быть указан в атрибуте scopedOIDs.

7.4.1.3 Атрибут name

Атрибут name содержит официальное наименование регистра ОИД.

7.4.1.4 Атрибут description

Атрибут description содержит описание регистра ОИД (возможно, на нескольких языках).

CONF rg-ds: если хотя бы один элемент description присутствует, то один из кодов языка описания должен обозначать английский язык («en», «en-US» и т.д.).

7.4.1.5 Атрибут lastModifiedDate

Атрибут lastModifiedDate используется для указания даты и времени последнего изменения регистра ОИД.

7.4.2 Ассоциации

Ассоциации класса Registry представлены в таблице 3.

7.5 Класс Oid

Этот класс содержит зарегистрированный ОИД и ассоциированные с ним метаданные (см. рисунок 3).

Рисунок 3 — Класс Oid

7.5.1 Атрибуты

Атрибуты класса Oid представлены в таблице 4.

7.5.1.1 Атрибут dotNotation

Атрибут dotNotation содержит ОИД в точечной нотации (SNMP) или в представлении ASN.1/XER.

Пример -

2.16.528

7.5.1.2 Атрибут asn1Notation

Атрибут asn1Notation содержит ОИД в нотации АСН.1 с (необязательными идентификаторами и номерами.

Пример -

{joint-iso-itu-t(2) country(16) nl(528)} {itu-t(0) recommendation(0) a(1)}

Примечания

1 Окаймляющие фигурные скобки могут быть опущены.

2 Эта информация не обязательно должна вводиться человеком; она может заполняться алгоритмически.

7.5.1.3 Атрибут iriNotation

Атрибут iriNotation содержит ОИД в нотации IRI (Internationalized Resource Identifier — международный идентификатор ресурса) notation.

Пример -

oid:/Country/528

Примечание - Эта информация не обязательно должна вводиться человеком; она может заполняться алгоритмически.

7.5.1.4 Атрибут symbolicName/вторичный идентификатор дуги

Атрибут symbolicName содержит краткое символьное имя ОИД, уникальное для всех сестринских ОИД данной дуги.

Правила ИСО по вторичным идентификаторам дуги, изложенные в 6.2.2 документа ITU-T/ИСО/МЭК 9834-1:2012, гласят:

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

Пример -

nl

7.5.1.5 Атрибут category

Атрибут category содержит тип (категорию) ОИД; имеет перечисляемые значения, которые должны быть взяты из словаря OIDcategories.

В сущности, существует два основных типа ОИД: лист (идентификатор объекта) и узел, представляющий онтологическую ветвь.

Узловые ОИД могут иметь следующие типы:

• уполномоченный регистратор (УР);
• структура для управления объектными идентификаторами.

Предложены следующие подкатегории листовых ОИД:

• идентификатор экземпляра объекта (например, организации);
• идентификатор пространства имен (например, идентификатор системы кодирования или набора значений).

Примечание - Кроме того, у ОИД есть свойства, которые могут отражать другие деловые потребности, например, теги (простой текст), другая категоризация ОИД в виде кода или текста, «подтипы» ОИД. Дополнительную информацию см. в описании класса AdditionalProperty.

7.5.1.6 Атрибут status

Атрибут status содержит статус ОИД; имеет перечисляемые значения, которые должны быть взяты из словаря OIDstatusCodes.

7.5.1.7 Атрибут creationDate

Атрибут creationDate используется для указания даты первой регистрации ОИД. Это не дата представления описания ОИД в регистр. Будучи задано, значение атрибута creationDate больше не изменяется.

7.5.1.8 Атрибут lastModifiedDate

Атрибут lastModifiedDate используется для указания даты последнего изменения информации о данном ОИД.

7.5.1.9 Атрибут realm

В некоторых случаях ОИД может быть действительным только для определенной страны или сферы, например, номер карточки социального страхования SSN (Social Security Number) в США, или голландский номер обслуживания гражданина BSN (Dutch Citizen Service Number), или система кодирования, представляющая версию Международной классификации болезней 10-го пересмотра, предназначенную для использования только в Германии (ICD10gm). Это может быть указано с помощью атрибута realm, содержащего или код страны, или код «UV», обозначающий универсальное применение. Допустимые значения указаны в системе кодирования CountryCodes.

7.5.1.10 Атрибут description

Этот элемент содержит произвольное текстовое описание ОИД («что это за ОИД?»). Обычно такой текст содержит комментарий, но может содержать и следующую информацию:

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

Этот элемент повторяется для каждого языка.

Тип данных ED позволяет задавать дочерний элемент эскиза (thumbnail). Эскиз может быть заполнен кратким описанием ОИД (иногда называемым именем идентификатора).

Пример -

Примечание - Тип данных ED позволяет указать для описания информацию о языке (код языка).

CONF oi-ds: хотя бы один из экземпляров атрибута description ДОЛЖЕН иметь код английского языка («en», «en-US» и т.д.).

7.5.2 Ассоциации

Ассоциации класса Oid представлены в таблице 5.

7.6 Класс RegistrationAuthority

Этот класс представляет уполномоченного регистратора (УР). См. рисунок 4.

7.6.1 Атрибуты

7.6.1.1 Атрибут code

Атрибут code содержит информацию о типе роли уполномоченного регистратора (УР). Допустимые коды перечислены в словаре RoleCodes (см. 8.6).

7.6.2 Ассоциации

Ассоциации класса RegistrationAuthority представлены в таблице 6.

7.7 Класс ResponsibleAuthority

7.7.1 Атрибуты

Атрибуты класса ResponsibleAuthority представлены в таблице 7.

7.7.1.1 Атрибут code

Атрибут code содержит информацию о типе роли ответственной организации. Допустимые коды перечислены в словаре RoleCodes (см. 8.6).

7.7.1.2 Атрибут statusCode

Атрибут statusCode содержит информацию о статусе роли ответственной организации. Допустимые коды перечислены в словаре RoleStatus (см. 8.7).

7.7.1.3 Атрибут validTime

Атрибут validTime указывает интервал действия, то есть дату и время начала (и конца) ответственности за объект, идентифицированный данным ОИД. Если ответственность все еще имеет место, то заполняется только компонент начала действия validTme.low.

7.7.2 Ассоциации

Ассоциации класса ResponsibleAuthority представлены в таблице 8.

7.8 Класс SubmittingAuthority

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

Рисунок 6 — Класс SubmittingAuthority

Примечание - Во избежание избыточности, классы Organization и Person показаны здесь с атрибутами; во всех других местах показаны только «тени» этих двух классов.

7.8.1 Атрибуты

Атрибуты класса SubmittingAuthority

7.8.1.1 Атрибут code

Атрибут code содержит информацию о типе роли заявляющей организации. Допустимые коды перечислены в словаре RoleCodes.

7.8.1.2 Атрибут applicationDate

Дата заявления (представления или сертифицированного представления заявки) на получение ОИД.

7.8.2 Ассоциации

Ассоциации класса SubmittingAuthority представлены в таблице 10.

7.9 Класс HistoryAnnotation

Этот класс отражает историю примечаний к ОИД и регистрирует изменения любых данных с течением времени (см. рисунок 7).

7.9.1 Атрибуты

Атрибуты класса HistoryAnnotation представлены в таблице 11.

Таблица 11

Примечание — Тип данных ED позволяет указать для описания информацию о языке (код языка).

7.10 Класс Reference

Этот класс (см. рисунок 8) обеспечивает возможность ссылки на следующие объекты:

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

7.10.1 Атрибуты

Атрибуты класса Reference представлены в таблице 12.

Таблица 12

7.10.1.1 Атрибут ref

Ссылочный URI.

7.10.1.2 Атрибут type

Тип ссылки передается в кодированном атрибуте type. Допустимые коды перечислены в словаре ReferenceType (см. 8.5).

7.10.1.3 Атрибут lastVisitedDate

Атрибут lastVisitedDate указывает дату последнего посещения адреса URI.

7.11 Класс AdditionalProperty

В этом классе (см. рисунок 9) передаются дополнительные свойства ОИД, которые могут быть использованы в деловых правилах, которые не могут быть (или не должны быть) стандартизованы. К ним относятся:

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

Этот класс представляет собой пару атрибутов:

• attribute, описывающий вид дополнительного свойства;
• value, содержащий значение дополнительного свойства.

7.11.1 Атрибуты

Атрибуты класса AdditionalProperty представлены в таблице 13.

7.12 Класс Person

7.12.1 Атрибуты

Атрибуты класса Person представлены в таблице 14.

7.13 Класс Organization

7.13.1 Атрибуты

Атрибуты класса Organization представлены в таблице 15.

7.13.1.1 Атрибут id

Атрибут id содержит идентификатор организации, предпочтительно ОИД, который передается в свойстве root типа данных II.

Пример -

Примечание - Некоторые организации, которые могут быть указаны с помощью экземпляров данного класса, могут вместо ОИД иметь другой вид идентификатора (номер в системе Data Universal Numbering System, номер Global Location Number, индивидуальный номер налогоплательщика и т.д.). В этом случае идентификатор передается одним из следующих двух способов:

• присвоением значения и свойству extension («номер») и свойству root («пространство имен»),
• присвоением значение только свойству extension типа данных II, опуская свойство root и передавая причину его пустоты nullFlavor = «UNK».

Пример -

<id extension=«16574jc9848» nullFlavor=«UNK»/ >

7.13.1.2 Атрибуты name, addr, telecom

Эти атрибуты класса Organization аналогичны одноименным атрибутам класса Person, см. выше.

8 Словарные домены и перечисления

В следующих подразделах приведены словарные домены и перечисления, используемые в настоящем стандарте. В графах «Уровень» соответствующих таблиц указан иерархический уровень кода, например, код «NRA» в списке категорий ОИД «OIDcategories» является дочерним кодом (специализацией) кода «N».

8.1 Словарный домен CountryCodes

Словарный домен CountryCodes содержит буквенные коды стран, взятые из стандарта ИСО 3166-1 alpha-2. Он содержит названия стран в том виде, как они указаны в стандарте ИСО 3166-1, а также соответствующие им элементы, указанные в этом стандарте.

8.2 Словарный домен LanguageCodes

Словарный домен LanguageCodes содержит коды языков, соответствующие документу RFC 3066 (теги для идентификации языков). Коды имеют следующий формат:

ss[-CC],

где ss — код языка, взятый из ИСО 639-1, а CC — код страны, соответствующий ИСО 3166-1.

Пример -

en-US

8.3 Перечисление OIDcategories

Перечисление OIDcategories содержит категории ОИД (узел, лист) и возможные подкатегории (см. таблицу 16).

Таблица 16

Перечисление OIDcategories

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

8.4 Перечисление OIDstatusCodes

Перечисление OIDstatusCodes описывает возможные статусы ОИД. Допустимые значения приведены в таблице 17.

Таблица 17

Перечисление OIDstatusCodes

8.5 Перечисление ReferenceType

Перечисление ReferenceType описывает тип ссылки. Допустимые значения приведены в таблице 18.

8.6 Перечисление RoleCodes

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

8.7 Перечисление RoleStatus

Перечисление RoleStatus описывает статус роли. Допустимые значения приведены в таблице 20.

Таблица 20

Перечисление RoleStatus

9 Типы данных

Для XML-представления данных используется подмножество типов данных, определенных в ИСО 21090. В некоторых случаях к ним добавлены дополнительные тонкости или ограничения.

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

9.1 Тип данных AD — адрес

9.2 Тип данных CS — кодированное простое значение

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

Пример -

9.3 Тип данных ED — инкапсулированные данные

В настоящем стандарте требуется, чтобы инкапсулированные данные были либо неформатированным текстом (тип среды «text/plain»), либо текстом в формате HTML (тип среды «text/html»). Код языка требуется.

CONF ed-lc: элемент с типом данных ED должен иметь код языка представленный на языке.

CONF ed-mt: свойство mediaType элемента с типом данных ED должно иметь значение «text/plain» или «text/html».

Пример -

9.4 Тип данных EN.PN — фамилия, имя, отчество лица

9.5 Тип данных EN.ON — наименование организации

Пример -

LLC

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

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

- root представляет собой уникальный идентификатор, гарантирующий глобальную уникальность идентификации экземпляра объекта. Если свойству root присвоено значение и нет ни причины пустоты nullFlavor, ни свойства extension, то значение свойства root само по себе является глобально уникальным идентификатором. В присутствии непустого свойства extension значение свойства root является уникальным идентификатором «пространства имен», из которого берутся значения идентификатора, содержащегося в свойстве extension. В настоящем стандарте требуется, чтобы это свойство имело значение объектного идентификатора (ОИД);

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

Примеры приведены в описании атрибута id класса Organization (см. 7.13.1.1).

9.7 Тип данных IVL_TS — интервал штампов даты и времени

Интервал штампов даты и времени используется для указания начальной и конечной дат, например:

- дата, когда объект стал активным или действительным (компонент «low»);

- дата, когда объект перестал быть активным или действительным (компонент «high»).

9.8 Тип данных ST — строка символов

Строковый тип данных, у которого могут быть переводы (в свойстве translation).

Пример -

9.9 Тип данных ST.NT — строка символов без переводов

Строковый тип данных, у которого переводы (в свойстве translation) не разрешены.

9.10 Тип данных ST.OID — объектный идентификатор в точечной нотации

В действительности это строка символов без переводов (тип данных ST.NT), удовлетворяющая определенному шаблону. Этот шаблон можно найти в XML-схеме (см. приложение C).

Пример -

9.11 Тип данных ST.ASN1 — объектный идентификатор в нотации АСН.1

В действительности это строка символов без переводов (тип данных ST.NT), удовлетворяющая определенному шаблону. Этот шаблон можно найти в XML-схеме (см. приложение C).

9.12 Тип данных ST.IRI — объектный идентификатор в нотации IRI

В действительности это строка символов без переводов (тип данных ST.NT), удовлетворяющая определенному шаблону. Этот шаблон можно найти в XML-схеме (см. приложение C).

9.13 Тип данных ST.SYMB — символьное имя

В действительности это строка символов без переводов (тип данных ST.NT), удовлетворяющая определенному шаблону. Этот шаблон можно найти в XML-схеме (см. приложение C).

9.14 Тип данных TEL — телекоммуникация

Пример -

9.15 Тип данных TEL.URL — ресурс местонахождения

Значения этого типа указывают на ресурс местонахождения, например, содержат адрес в сети Интернет.

Пример -

9.16 Тип данных TS — штамп даты и времени

Пример -

Приложение A (справочное)

ТИПЫ ОИД И ПОДДЕРЕВЬЯ

A.1 Общие положения

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

A.2 Типы ОИД

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

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

Таким образом, типы ОИД могут использоваться как дополнительные свойства; если тип ОИД используется, рекомендуется присвоить атрибуту AdditionalProperty.attribute значение «OIDType», а атрибуту AdditionalProperty.value — перечисляемое значение или строковый код, представляющий тип ОИД.

A.3 Точка зрения комитета HL7

Комитет HL7 International разработал для своего регистра онтологию типов ОИД, облегчающую пользователям поиск нужных им ОИД. Эту онтологию можно найти на сайте http://hl7.org.

A.4 Рекомендации по выбору типов ОИД

С точки зрения политики, принятой в нескольких регистрах ОИД, относящихся к взаимодействию медицинских информационных систем (Регистр ОИД комитета HL7 International, см. http://hl7.org; Германский регистр ОИД, см. http://www.dimdi.de; Швейцарский регистр ОИД, см. http://oid.refdata.ch; Австрийский регистр ОИД, см. https://www.gesundheit.av.at/OID_Frontend), целесообразно различать, по меньшей мере, типы ОИД, перечисленные в таблице A.1.

B.1 Общие положения

В настоящем приложении описан перечень вариантов использования регистра (хранилища) ОИД и Системы разрешения объектных идентификаторов ORS (Object Identifier Resolution System) для ОИД, предназначенных для медицинских прикладных программ, с помощью веб-сервисов RESTful.

B.2 Варианты использования

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

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

• создание нового ОИД в стандартной онтологической структуре;
• создание нового ОИД в подчиненной структуре.

Вариант 2. Регистрация ОИД:

• регистрация ОИД, созданного владельцем регистра;
• регистрация ОИД, созданного в другом месте.

Вариант 3. Отмена или замена ОИД:

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

Вариант 4. Изменение или редактирование метаданных ОИД:

• модель разрешений;
• модель распределенного взаимодействия;
• агенты для программ редактирования.

Вариант 5. Публикация информации об ОИД:

• присутствие в сети Интернет;
• интерфейс прикладных программ API, доступный в сети Интернет (присутствие веб-служб в сети Интернет);
• полная выгрузка регистра в машиночитаемой форме;
• полная выгрузка регистра в человекочитаемой форме;
• частичная выгрузка регистра в машиночитаемой форме;
• частичная выгрузка регистра в человекочитаемой форме.

Вариант 6. Запрос информации об ОИД:

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

B.3 Веб-службы RESTful, предназначенные для системы разрешения объектных идентификаторов

«Передача состояния представления» (Representational state transfer, REST) — архитектурный стиль взаимодействия распределенных гипермедиа-систем, например, Всемирной паутины. Этот термин был введен и определен в 2000 году Роем Филдингом (Roy Fielding) в его докторской диссертации [18].

Веб-сервис RESTful реализуется с помощью принципов REST на основе протокола HTTP. Он представляет коллекцию ресурсов с тремя следующими аспектами:

• базовый адрес URI веб-сервиса, например, http://oid.server.org/;
• тип среды Интернет данных, поддерживаемый веб-сервисом, в данном случае только XML или HTML;
• совокупность операций, поддерживаемых веб-сервисом с помощью методов HTTP, в данном случае только GET.

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

Вызовы, которые должны быть реализованы как веб-службы RESTful, и их параметры описаны в таблице B.1.

Таблица ДА.1

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