ГОСТ Р ИСО/HL7 27951-2016. Национальный стандарт Российской Федерации. Информатизация здоровья. Общие терминологические службы. Выпуск 1

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

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 30 ноября 2016 г. № 1894-ст

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

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

ОБЩИЕ ТЕРМИНОЛОГИЧЕСКИЕ СЛУЖБЫ

ВЫПУСК 1

Health informatics. Common terminology services. Release 1

(ISO/HL7 27951:2009 Health informatics — Common terminology services, release 1, IDT)

ГОСТ Р ИСО/HL7 27951-2016

Группа П85

ОКС 35.240.80

ОКСТУ 4002

Дата введения 1 января 2018 года

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту ISO/HL7 27951:2009 «Информатизация здоровья. Общие терминологические службы. Выпуск 1» (ISO/HL7 27951:2009 «Health informatics — Common terminology services, release 1», IDT).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (подраздел 3.6)

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

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

1 Область применения. Общие терминологические службы (ОТС)

Содержание настоящего стандарта должно стать основной международной платформы разработки интерфейса прикладных программ API (Application Programming Interface), который может использоваться программным обеспечением обработки сообщений для доступа к терминологическому содержанию. Сам по себе такой интерфейс не обеспечит полную терминологическую службу. Стандарты Health Level Seven (HL7) Версии 3 (использующие язык XML) основаны на эталонной информационной модели RIM (Reference Information Model), обладающей общей и гибкой структурой. Представление информации в этой модели опирается на доступность терминологических ресурсов, которые могут использоваться для наполнения свойств модели требуемым семантическим содержанием. По возможности стандарт HL7 Версии 3 использует существующие терминологические ресурсы, а не создает новые внутри себя.

Поскольку внешние терминологические ресурсы могут значительно различаться как по содержанию, так и по структуре, ОТС идентифицируют общие функциональные характеристики, которые может предоставлять внешняя терминология. Например, терминологическая служба, совместимая со стандартом HL7, должна быть способной определить, является ли данный код понятия действительным в конкретном ресурсе. Вместо описания таблицы, строки которой содержат идентификаторы ресурса и коды понятий, спецификация ОТС описывает вызов интерфейса прикладных программ API (Application Programming Interface), который может на входе получить идентификатор ресурса и код понятия, а на выходе возвратить значение true (истинный) или false (ложный). Каждый разработчик терминологии свободен реализовать этот вызов API по собственному усмотрению.

Спецификация ОТС не рассчитана на нижеследующее:

• текущая версия не предназначена к использованию в качестве полной терминологической службы. Ее область применения ограничена функциональностью, необходимой для конструирования, реализации и развертывания пакетов программ, соответствующих стандарту HL7 Версии 3. В той же степени, как язык XML связан с языком SGML, ОТС HL7 рассчитаны на представление достаточного подмножества функций, которые могут быть предоставлены более сложными API, например, теми, что соответствуют спецификации TQS организации OMG;
• она не предназначена для использования в качестве языка запросов общего назначения. В ней определены только конкретные службы, необходимые для реализации стандарта HL7;
• в ней не задан способ реализации службы. В ней намеренно опущены требования к информированию о службе и к ее обнаружению, к установке соединений и к управлению ими, а также требования к доставке и маршрутизации сообщений. Предполагается, что реализация ОТС будет использовать нижележащую архитектуру, наиболее подходящую для конкретных условий реализации.

Разработка спецификации ОТС HL7 основана на следующих общих принципах:

1. должно быть нетрудно написать программу, использующую ОТС HL7;

2. ОТС HL7 предназначены для описания только базовых требований;

3. конструкция ОТС HL7 должна быть формальной и точной;

4. первичная технология реализации ОТС HL7 должна быть основана на языке XML;

5. ОТС HL7 должны быть совместимы с номенклатурой, моделью и подходом, представленными в документе HL7 Vocabulary, модели RIM стандарта HL7 Версии 3 и производными структурами;

6. по возможности ОТС HL7 должны оставаться согласованным подмножеством Служб терминологических запросов TQS (Terminology Query Services) организации Object Management Group (OMG), пока это не противоречит другим принципам конструирования ОТС HL7. Если будет обнаружено, что модель TQS противоречит принципам конструирования ОТС HL7 или является неполной либо некорректной, то должны быть предприняты все необходимые шаги, чтобы уведомить об этом соответствующую рабочую группу по пересмотру;

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

Хотя общераспространенного стандарта терминологических служб не существует, на эту тему есть несколько источников материала:

• спецификация OMG Terminology Query Services (TQS).

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

• DAML + OIL и язык Web Ontology Language (OWL).

Эти документы не являются спецификациями терминологического сервера, но при этом они содержат элементы представления онтологических аспектов, релевантные некоторым масштабным терминологиям, например, SNOMED Clinical Terms, NHS Clinical Terms Version 3 и GALEN. Однако это предложение, основанное на веб-технологиях, также является тяжеловесным и вряд ли приведет к ранней широко распространенной реализации;

• спецификации API, рассчитанные на конкретные терминологии.

Примером может служить спецификация API «Read Code — Version 3», разработанная по проекту клинической терминологии NHS Clinical Terms в 1996 году и пересмотренная в 1998 году. На основе похожих принципов ведется работа по созданию API SNOMED CT. Неофициально признается, что этот конкретный API сольется с ОТС или будет использовать подходящие элементы ОТС там, где это целесообразно. Реализация этого API на основе технологии COM обеспечивается по меньшей мере одной свободно распространяемой машиной кодирования (CLUE). Спецификации этого типа идентифицируют многие общие функции, необходимые для доступа к терминологии. Однако они неизбежно специфичны для нужд конкретной терминологии. Явная поддержка единственной определенной модели терминологии позволяет обеспечить ее эффективную реализацию в операционной среде в ущерб гибкости, требуемой для доступа к другим терминологиям;

• интерфейсы к системам реляционных баз данных, включая SQL и ODBC.

Для «элементарных» списков кодов простой запрос на языке SQL может оказаться наиболее эффективным способом извлечения кода. Однако многие схемы кодирования в дополнение к парам «значение кода» — «описание значения» имеют другие релевантные свойства, которые могут быть доступными только с помощью вторичной службы. Это не препятствует применению языка SQL, но требует описания общей модели, в соответствии с которой могут исполняться запросы, и эффективных средств, возвращающих требуемые свойства. Такие дополнительные свойства присущи как всей схеме, так и отдельным элементам терминологии;

• язык терминологических запросов TQL (Terminology Query Language).

Язык TQL, ранее основанный на синтаксисе, подобном языку SQL, в настоящее время реализуется на основе унифицированных идентификаторов ресурсов URI, специфичных для терминологических серверов, разработанных Майклом Хогартом (Michael Hogarth) и его коллегами в Калифорнийском университете. В языке TQL предусмотрен богатый механизм, предназначенный для оперирования общими свойствами и отношениями в терминологических моделях. Работающая реализация языка TQL на платформе Java может быть бесплатно загружена из сети Интернет.

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

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

ISO/HL7 21731:2006, Health informatics — HL7 Version 3 — Reference information model — release 1 (Информатизация здоровья. HL7, Версия 3. Эталонная информационная модель. Выпуск 1) <1>

<1> В настоящее время действует версия ISO/HL7 21731:2014.

HL7 2008, Datatype Specification. Abstract Data Types (Спецификация типов данных. Абстрактные типы данных)

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

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

3.1 интерфейс прикладных программ (application programming interface, API): Совокупность функций, процедур, методов или классов, предоставляемых операционной системой, библиотекой или службой для использования во внешних программных продуктах.

3.2 система кодирования (code system): В целях настоящего стандарта под «системой кодирования» понимается система кодов, обозначений, свойств и отношений. К другим общим именам этой сущности относятся «словарь», «терминология», «схема кодирования», «схема классификации» и «онтология».

3.3 ограничение (constraint): Логическое выражение, накладывающее ограничение на значения объектов, принадлежащих некоторому множеству, и тем самым задающее логическое подмножество этого множества.

3.4

3.5 идентификатор объекта (object identifier): Число, постоянное, присвоенное объекту и используемое для его уникальной идентификации в коллекции объектов.

3.6 эталонная информационная модель (reference information model, RIM): Информационная модель, разработанная комитетом HL7, используемая для построения всех других информационных моделей, например, уточненных информационных моделей сообщений RMIM и самих сообщений.

3.7 уточненная информационная модель сообщений (refined message information model, RMIM): Структура информации, используемая в стандарте передачи сообщений HL7 Версии 3, описывающая требования к комплексу сообщений.

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

3.9

[W3C; 2001 [2]]

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

API — интерфейс прикладных программ (Application Programming Interface);

ОТС — общая терминологическая служба (Common Terminology Service, CTS);

CEN — Европейский комитет по стандартизации, федерация из 28 национальных органов стандартизации, которые также входят в ИСО ( Comité Européen de Normalisation);

EU — Европейский союз (European Union);

HL7 — Health Level Seven Inc.;

HMD — иерархическое описание сообщения (Hierarchical Message Description);

IDL — язык описания интерфейсов (Interface Description Language);

ITS — спецификация реализуемой технологии (Implementable Technology Specification);

ICH — Международная конференция по гармонизации технических требований к регистрации лекарственных препаратов для человека (The International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use);

ИСО — International Organization for Standardization, ISO;

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

RIM — эталонная информационная модель (Reference Information Model);

RMIM — уточненная информационная модель сообщений (Refined Message Information Model);

SDO — Организация по разработке стандартов (Standards Development Organization);

SGML — стандартный обобщенный язык разметки (standardized generalized markup language). Стандарт ИСО по платформенно-независимому описанию структурированной информации;

SNOMED — систематизированная номенклатура терминов медицины и ветеринарии (The Systematized Nomenclature of Human and Veterinary Medicine);

SNOMED-CT — систематизированная номенклатура терминов клинической медицины (Systematized Nomenclature of Medicine-Clinical Terms Medicine);

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

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

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

5 Модули ОТС

5.1 API сообщений и словаря

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

Рисунок 1 — API сообщений и словаря

API сообщений специфичен для HL7. Его основная цель — обеспечить широкому спектру программ обработки сообщений удобные и воспроизводимые возможности создания, проверки и преобразования типов данных, произведенных от типа CD (coded data — кодированные данные).

API словаря рассчитан на общее применение <1>. Он позволяет прикладным программам осуществлять запросы к различным терминологиям <2> хорошо определенным, согласованным способом. API сообщений включает в себя применение API словаря. На рисунке 2 показан пример взаимодействия программы обработки сообщений со словарем. В этом примере программа обработки сообщений обращается к службе времени исполнения уровня сообщений для заполнения детальных сведений об атрибуте, имеющем тип данных, произведенный от типа CD. Эта служба, в свою очередь, выполняет несколько обращений к службе уровня словаря для получения обозначений кода понятия, имен системы кодирования, версий ее выпусков и т.д.

<1> Хотя API словаря и рассчитан на общее применение, он представляет некоторое подмножество тех возможностей, которые должен обеспечивать общий словарный API. Кроме того, значительная часть номенклатуры, используемой в API словаря ОТС, так или иначе связана со стандартами HL7, и для более общего применения может потребоваться преобразование этого API.

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

Рисунок 2 — Пример взаимодействия с API сообщений и словаря

5.2 Функции времени исполнения и обозревания

5.2.1 Общие классы пользователей (действующих лиц) ОТС HL7

Классы действующих лиц, предполагаемых пользователями API ОТС HL7, включают в себя:

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

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

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

Разработчики программного обеспечения — люди, создающие программное обеспечение, создающее, проверяющее и обрабатывающее сообщения стандарта HL7 Версии 3.

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

5.2.2 Раздельные профили требований

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

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

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

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

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

5.2.3 Трансляция

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

5.2.4 Отдельные компоненты спецификации

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

Таблица 1

Компоненты спецификации

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

6 Краткий обзор функций модулей

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

6.1 Функции платформы времени исполнения, предназначенной для уровня сообщений

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

Таблица 2

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

6.2 Функции платформы времени исполнения, предназначенной для уровня словаря

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

Таблица 3

Функции платформы времени исполнения, предназначенной для уровня словаря

6.3 Функции отображения кодов

Функции отображения кодов перечислены в таблице 4.

Таблица 4

Функции отображения кодов

6.4 Функции обозревателя уровня сообщений

Функции обозревателя уровня сообщений перечислены в таблице 5.

Таблица 5

Функции обозревателя уровня сообщений

6.5 Функции обозревателя уровня словаря

Функции обозревателя уровня словаря перечислены в таблице 6.

Таблица 6

Функции обозревателя уровня сообщений

7 Модель API сообщений ОТС

7.1 Введение

В настоящем разделе описана модель, положенная в основу API сообщений ОТС. Она определяет отношения между кодированными атрибутами HL7 и словарем. Она основана на метамодели HL7_V3_Meta-Model Version 1.16 и, исключая цветовое кодирование, по возможности остается совместимой с ее нотацией и типами данных. В настоящем стандарте не представлена полная или глубокая модель всех логических сущностей, образующих систему кодирования <1>. Его основная цель - описать классы и отношения, имеющие прямое отношение к содержанию кодированных атрибутов HL7 с точки зрения метамодели.

<1> В настоящем стандарте термин "система кодирования" означает систему кодов, описаний, обозначений, свойств и отношений. К другим общим именам этой сущности относятся "словарь", "терминология", "схема кодирования", "схема классификации" и "онтология".

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

7.1.1 Нотация

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

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

• имена классов выделены полужирным шрифтом (например, VocabularyDomain, ValueSet);
• имена атрибутов выделены курсивом (например, vocabularyDomain_name, valueSet_id);
• имена отношений подчеркнуты (например, экземпляр класса VocabularyDomain @представлен@ нулем или более экземплярами классов VocabularyDomainValueSets).

При необходимости кратности отношений выражаются приведенными ниже формами или близкими к ним:

• 1..1 "экземпляр класса Class 1 должен @иметь отношение@ ровно с одним экземпляром класса Class 2";
• 0..1 "экземпляр класса Class 1 может @иметь отношение@ не более чем с одним экземпляром класса Class 2";
• 1..* "экземпляр класса Class 1 должен @иметь отношение@ с одним или несколькими экземплярами класса Class 2";
• 1..* "экземпляр класса Class 1 может @иметь отношение@ с нулем или несколькими экземплярами класса Class 2".

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

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

На рисунке 3 показано отношение между словарными доменами и атрибутами HL7.

Рисунок 3 - Атрибуты модели RIM и словарные домены

Экземпляр класса Attribute_domain_constraint (ограничение домена атрибута) должен @ограничивать@ допустимые значения ровно одного экземпляра класса Attribute (атрибута модели RIM). Он @ограничивает допустимые значения@ атрибута теми, что описаны ровно одним экземпляром класса VocabularyDomain (словарный домен). Экземпляр класса VocabularyDomain может @описывать допустимые значения@ одного или нескольких экземпляров класса Attribute_domain_constraint (ограничение домена атрибута). Экземпляр класса DIM_attribute_row (строка атрибута модели DIM) должен быть @основан@ ровно на одном экземпляре класса Attribute, взятом из модели HL7, и используется для указания на присутствие атрибута в специфичной информационной модели домена DIM (domain information model). Экземпляр класса DIM_attribute_row наследует все ограничения экземпляра класса Attribute, на котором он @основан@, и, в свою очередь, может быть @ограничен@ нулем или более экземплярами класса DIM_attribute_domain_constraint (ограничение домена атрибута модели DIM).

Иерархическое описание сообщения HMD (hierarchical message description) полностью определяет структуру совокупности сообщений. Экземпляры класса HMD_attribute_row (строка атрибута в HMD) являются компонентами HMD, и каждый экземпляр класса HMD_attribute_row @основан@ ровно на одном экземпляре класса DIM_attribute_row. Экземпляр класса HMD_attribute_row наследует все ограничения соответствующего экземпляра класса DIM_attribute_row и может быть далее @ограничен@ не более чем одним экземпляром класса HMD_domain_constraint (ограничение домена HMD).

Каждый экземпляр класса VocabularyDomain имеет уникальное имя (атрибут vocabularyDomain_name ), а также описание пространства понятий (атрибут description ), которое он представляет. Экземпляры класса VocabularyDomain, которые @описывают допустимые значения@ экземпляров класса DIM_attribute_domain_constraint или класса HMD_domain_constraint, @ограничивают@ пространство понятий соответствующего экземпляра класса DIM_attribute_domain или класса Attribute_domain_constraint, на котором основан домен.

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

Таблица 7

Ограничения словарных доменов

7.2.1 Дополнительные ограничения

Примечание - В этом контексте ограничение относится к самой модели, а не к доменам атрибутов.

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

2. Любой экземпляр класса VocabularyDomain, @описывающий допустимые значения@ экземпляра класса DIM_attribute_domain_constraint, должен быть @основан на@ экземпляре класса VocabularyDomain, соответствующем экземпляру класса Attribute.

3. Любой экземпляр класса VocabularyDomain, @описывающий допустимые значения@ экземпляра класса RIM_attribute_domain_constraint, должен быть @основан на@ экземпляре класса VocabularyDomain, соответствующем экземпляру класса DIM_attribute_row, если таковой существует, либо экземпляру класса Attribute.

7.3 Набор значений

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

Рисунок 4 - Наборы значений

Экземпляр класса VocabularyDomain может быть @представлен@ нулем или несколькими экземплярами класса ValueSet (набор значений). Хотя абстрактные атрибуты моделей RIM и DIM не обязаны быть @представлены@ какими-либо экземплярами класса ValueSet, экземпляр класса VocabularyDomain, описывающий допустимые значения кодированных экземпляров класса Attribute, используемых в фактических сообщениях, должен быть представлен не менее чем одним экземпляром класса Value_set.

7.3.1 Связи между словарными доменами и наборами значений

Экземпляр класса VocabularyDomainValueSet (набор значений в словарном домене) представляет ассоциацию ровно между одним экземпляром класса VocabularyDomain и одним экземпляром класса ValueSet. Каждая ассоциация между экземпляром класса VocabularyDomain и экземпляром класса ValueSet может применяться в нуле или более экземпляров класса ApplicationContext (контекст применения). Экземпляр класса ApplicationContext именует конкретную геополитическую единицу (например, Европейский союз, Канада) и/или отрасль (например, ветеринарную медицину, общественное здоровье) и т.д. и может @служить областью применения@ для нуля или более ассоциаций, представленных экземплярами класса VocabularyDomainValueSet.

7.3.2 Определение наборов данных

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

• все кодированные понятия CodedConcept, @определенные@ ровно в одной системе кодирования CodeSystem;
• конкретный список кодированных понятий CodedConcept, @определенных@ ровно в одной системе кодирования CodeSystem;
• совокупность кодированных понятий CodedConcept, представленных другим набором значений ValueSet.

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

Ожидается, что наборов значений столь много, что просто невозможно присвоить каждому из них уникальную мнемонику или значащее имя. Основным идентификатором экземпляра класса ValueSet является атрибут valueSet_id, имеющий числовое значение, не имеющее смысловой нагрузки <1>. При необходимости атрибут valueSet_name может также содержать уникальный "смысловой" идентификатор набора значений. Этот атрибут предназначен для коммуникаций между углеродными формами жизни.

<1> В качестве такого значения, скорее всего, будет использоваться объектный идентификатор ИСО с корнем, 2.16.840.1.113883.1.11, но это решение окончательно не принято.

Класс ValueSet имеет атрибут description (описание), описывающий назначение и цель создания набора значений. Он имеет также атрибут definingExpression (определяющее выражение), предназначенный для хранения формального машиночитаемого выражения, которое может использоваться для конструирования набора значений. Значение и интерпретация этого выражения в данном документе не обсуждаются. Оба атрибута (description и definingExpression) не обязательны. Еще один атрибут класса ValueSet, а именно, allCodes (все коды), описан ниже.

7.3.3 Определение содержания набора значений

Набор значений ValueSet может быть построен из одного другого набора значений ValueSet либо может быть основан ровно на одной системе кодирования CodeSystem, либо может быть построен из того и другого <2>. Система кодирования CodeSystem определяет нуль или более кодированных понятий CodedConcepts, которые, в свою очередь, обозначают релевантные классы или сущности в конкретной области интереса. Системы кодирования могут ранжироваться от простой таблицы пола человека до классификаторов типа МКБ-9 и до семантически богатых систем, основанных на логических представлениях, например, OpenGalen или SNOMED-CT. Поскольку многие системы кодирования регулярно пересматриваются, полезно регистрировать версию выпуска ReleaseVersion, @использованную для определения@ данного набора значений ValueSet в конкретный момент времени. Набор значений ValueSet может быть @определен с использованием@ не более одной версии ReleaseVersion. Определение с помощью отношения служит исключительно для справочных целей и для представления содержания набора значений службы ValueSet могут использовать более позднюю версию системы кодирования <3>. Более детальное обсуждение систем кодирования приведено ниже, в подразделе, описывающем API словаря ОТС.

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

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

7.3.3.1 Представление всего содержания системы кодирования

Присвоив значения TRUE атрибуту allCodes, можно указать, что в данный набор значений ValueSet должны быть включены все кодированные понятия CodedConcept, определенные в системе кодирования CodeSystem, на которой основан этот набор. Такой набор значений ValueSet не может дополнительно включать в себя ссылки на кодированные понятия CodeReference. Пример набора значений, представляющего всю систему кодирования, приведен в таблице 8.

Таблица 8

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

7.3.3.2 Представление частей содержания системы кодирования

Набор значений ValueSet может включать в себя нуль или более кодированных понятий CodedConcept, @определенных@ в системе кодирования CodeSystem, на которой он @основан@. Это выполняется с помощью @включения@ в набор значений одной или нескольких ссылок CodeReference. Такая ссылка связывает кодированное понятие CodedConcept с набором значений ValueSet. Она должна @ссылаться@ ровно на одно кодированное понятие CodedConcept. При этом атрибут relation_code подразумевает неявные ссылки на все кодированные понятия CodedConcept, являющиеся @целью@ отношения ConceptRelationship к явно @включенному@ кодированному понятию CodedConcept. В ссылке CodeReference можно указать, что само это ссылочное понятие CodedConcept включено в набор значений или исключено из него. С помощью отношения ConceptRelationship можно включить все целевые коды понятий или только конечные узлы (листья). Эти различные возможности отражены в значениях атрибутов includeReferencedCode, relationship_code и leafOnly, приведенных в таблице 9.

Таблица 9

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

Иные сочетания значений атрибутов, кроме тех, что перечислены в таблице 9, не допустимы. По возможности значения атрибута relation_code должны браться из системы кодирования HL7 RelationshipCode.

7.3.4 Включение в набор значений других наборов значений

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

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

2. Использование этого класса позволяет включать в результирующий набор ValueSet кодируемые понятия CodedConcept, взятые более чем из одной системы кодирования CodeSystem.

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

Таблица 10

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

7.3.5 Головные коды

Набор ValueSet значений ссылается на совокупность кодированных понятий CodedConcept. Нередко ассоциация между набором значений ValueSet и коллекцией кодированных понятий CodedConcept означает категоризацию, отношение "часть - целое" или иное иерархическое отношение, в котором сам набор значений представляет "целое" (родителя), а коды понятий - отдельные "части" (потомки). В этом случае в системе кодирования может существовать соответствующий код понятия, представляющий подобное понятие "целого" или "родителя". Такой код будет именоваться "головным кодом" ассоциированного набора значений. Многие кодированные атрибуты модели HL7 RIM могут иметь разные степени общности. В примере набора значений, указанном в таблице 10, набор значений InclusionNotRequired имеет головной код NR (не требуется) и два подчиненных кода - X (исключен) и RE (требуется, но может быть пустым). Значение True атрибута includeHeadCode, указанное во второй строке этой таблицы, означает, что для этого набора допустимыми значениями могут быть X (исключен), RE (требуется, но может быть пустым) и NR (включение не требуется по неспецифичной причине).

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

7.4 Зарегистрированная система кодирования

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

С точки зрения комитета HL7, регистрация не означает "санкционирование". Она является просто ссылкой. В процессе регистрации системе кодирования присваивается объектный идентификатор (ОИД), если его у нее еще не было. На рисунке 5 показана диаграмма классов зарегистрированной системы кодирования.

Рисунок 5 - Зарегистрированная система кодирования

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

• sponsor - именование, адрес и другие подобные данные лица либо организации, которая официально спонсирует эту систему кодирования для комитета HL7;
• publisher - наименование, адрес и другие подобные данные организации, ответственной за создание и ведение этой системы кодирования;
• versionReportingMethod - описание того, как и сколь часто создаются и распространяются новые версии;
• licensingInformation - описание требуемых лицензий, цены и способа приобретения;
• inUMLS - значение TRUE указывает, что кодированные термины, определенные в этой системе кодирования, включены в Унифицированную систему медицинского языка UMLS (Unified Medical Language System);
• systemSpecificLocatorInfo - информация, специфичная для издателя системы кодирования. Она служит для определения или идентификации конкретной системы кодирования. Комитет HL7 может иногда использовать атрибут systemSpecificLocatorInfo для идентификации соответствующей таблицы стандарта HL7 2.x, если таковая имеется;
• codeSystemType_code - код, имеющий значения I (система кодирования является внутренней, ведется и распространяется комитетом HL7), E (ведется и распространяется третьей стороной), EI (ведется третьей стороной, но распространяется комитетом HL7).

8 Спецификация API сообщений ОТС

8.1 Введение

API сообщений ОТС (CTSMAPI - CTS Message API) состоит из двух разделов - раздел времени исполнения, определяющий комплекс функций, необходимых для каждодневных операций программного обеспечения, обрабатывающего сообщения, соответствующие стандарту HL7 Версии 3, и раздел обозревателя, определяющего функции, предназначенные для разработки и конструирования этих сообщений. Программному обеспечению, использующему функции обозревателя, может понадобиться доступ к функциям времени исполнения, в то время как программное обеспечение времени исполнения может не иметь доступа к функциям обозревателя.

8.2 Общие элементы сообщений ОТС

8.2.1 Основные элементы данных

В следующем пункте определены основные типы данных, используемые в API сообщений ОТС. Все типы, имена которых имеют префикс "types::", основаны на стандарте HL7 Версии 3 Data Types и далее здесь не обсуждаются.

Основные типы данных в API сообщений ОТС включают в себя:

• CTSVersionId - структура, содержащая старшую и младшую части номера версии спецификации ОТС. У текущей версии старшая часть равна 1, младшая - равна 0 (1.0);
• CodeSystemId - уникальный идентификатор системы кодирования. В контексте стандартов HL7 им должен быть объектный идентификатор ИСО (ОИД), присвоенный комитетом HL7, если таковой имеется. Другие виды идентификаторов, например UUID, определенный для среды распределенных вычислений DCE (Distributed Computing Environment), и т.д., могут использоваться в качестве идентификаторов систем кодирования вне среды применения стандартов HL7. В этих случаях разработчик должен предупреждать любые конфликты пространств имен, которые могут возникать между ОИД и другими идентификаторами;
• CodeSystemName - имя системы кодирования. Как идентификатор системы кодирования, так и ее имя уникальны в пространстве имен, контролируемом стандартом HL7 Версии 3, но в общем случае уникальность не гарантируется;
• ConceptCode - код, уникально представляющий класс или понятие в данной системе кодирования;
• VocabularyDomainName - уникальное имя словарного домена HL7;
• ReleaseVersionId - идентификатор, уникально обозначающий выпуск/версию в контексте системы кодирования;
• ValueSetId - объектный идентификатор ИСО (ОИД), уникально идентифицирующий набор значений HL7;
• ValueSetName - уникальное имя или мнемокод набора значений. Не у всех наборов значений есть и идентификатор, и имя, но если таковые имеются, то они должны быть уникальны;
• ConceptId - сочетание идентификаторов системы кодирования и кода понятия, являющееся глобально уникальным именем понятия;
• ReleaseVersionId - уникальный идентификатор версии или выпуска одной или нескольких систем кодирования;
• ExpansionContext - непрозрачный большой двоичный объект, используемый для передачи контекстной информации между сервером и клиентом.

8.2.2 Коды понятий

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

• LanguageCode - код разговорного или письменного языка, конструируемый по правилам, описанным в документе IETF RFC 3066 - Tag for Identification of Languages (теги идентификации языка). Этот код состоит из нескольких субтегов, разделенных дефисами ("-"). Первый субтег идентифицирует основной код языка. По возможности он должен быть взят из ИСО 639-1 "Codes for the representation of names of languages - Part 1: Alpha-2 code" (Коды для представления названий языков. Часть 1. Двухбуквенный код). Если двухбуквенный код отсутствует, то надо взять код из ИСО 639-2 "Codes for the representation of names of languages - Part 2: Alpha-3 code" (Коды для представления названий языков. Часть 2. Трехбуквенный код). Существует также дополнительный механизм спецсимволов, который в настоящем стандарте не описан.

Второй субтег не обязателен. Если он присутствует, то должен иметь длину от 2 до 8 символов. Если его длина равна двум, то он должен содержать двухбуквенный код страны, взятый из ИСО 3166-1 "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes" (Коды для представления названий стран и единиц их административно-территориального деления. Часть 1. Коды стран). Если длина субтега от 3 до 8 символов, то он должен содержать код, взятый из регистра тегов языков организации IANA. Дополнительные субтеги используются, если надо уточнить информацию о языке;

• RelationshipCode - код понятия, уникально определяющего конкретное отношение, имеющее место в системе кодирования. По возможности коды отношений должны браться из системы кодирования HL7 ConceptRelationship;
• ApplicationContextCode - код, идентифицирующий контекст или область применения, например, геополитическое образование, профессию или другую сферу.
• DataTypeCode - код, идентифицирующий тип данных атрибута модели RIM (например, CD, CE, CS, BIN, ST и т.д.).
• CodingStrengthCode - код, указывающий, как должны трактоваться некодированные значения атрибута, определенного в стандарте HL7 (CWE - кодированный с разрешением исключений, CNE - кодированный без исключений);
• ValueSetNodeTypeCode - код, определяющий тип набора значений, возвращаемого в виде иерархического списка. Коды имеют следующие значения: A (абстрактный) означает, что набор значений не может быть выбран; S (специализируемый) означает, что набор значений может быть выбран, но имеет дальнейшие уточнения; L (list) означает, что узел представляет выбираемый код понятия, которое не имеет дальнейших уточнений;
• CodeSystemTypeCode - код, имеющий значения I (система кодирования является внутренней, которая ведется комитетом HL7), E (ведется третьей стороной), EI (ведется третьей стороной, но в распоряжение комитета HL7 предоставлена внутренняя копия);
• MatchAlgorithmCode - код, идентифицирующий алгоритм совпадения строк, используемый во внутренних функциях поиска.

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

Таблица 11

Идентификаторы ОИД и имена кодируемых элементов данных

8.2.2.1 Алгоритмы совпадения строк

Некоторым описанным ниже функциям могут передаваться строковые значения в качестве критериев поиска. Этим значениям сопутствует "код алгоритма совпадения", определяющий, как будут применяться эти значения. В таблице перечислен список предопределенных алгоритмов совпадения. Если в графе "Обязателен" указано значение TRUE, то все реализации службы, объявляющие совместимость с данным стандартом, должны использовать этот алгоритм. Если в графе "Обязателен" указано значение FALSE, то служба не обязательно должна реализовать этот алгоритм, но если реализует, то в качестве его идентификатора должна использовать код, указанный в таблице 12. Данный список алгоритмов совпадения не является исчерпывающим. При необходимости реализация службы может расширить этот список собственными алгоритмами совпадения, но в целях будущей интероперабельности разработчикам службы настоятельно рекомендуется зарегистрировать код алгоритма в комитете HL7.

Таблица 12

Коды алгоритмов совпадения

8.2.3 Идентифицирующий раздел службы

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

• getServiceName - возвращает имя, присвоенное службе ее поставщиком;
• getServiceVersion - возвращает идентификатор версии, зависящий от реализации службы;
• getServiceDescription - возвращает описание службы, сведения о ее авторе, назначении и т.д.;
• getHL7ReleaseVersion - возвращает идентификацию наиболее позднего выпуска словаря HL7 (а не модели RIM), предоставляемого службой;
• getCTSVersion - возвращает специфичную версию ОТС, реализуемую службой (например, 1.0).

8.2.4 Исключения

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

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

Исключения, генерируемые API сообщений:

• возникла ошибка, не предусмотренная в настоящей спецификации. К примеру, ошибки оперативной памяти, ошибки ввода-вывода, ошибки доступа к базе данных и любые другие неожиданные события, препятствующие нормальному завершению вызова API. В атрибуте possible_cause может передаваться более детальная информация о том, что произошло на самом деле;
• служба не распознала значение параметра vocabularyDomain_name;
• служба не распознала значение параметра applicationContext_code. Возможны следующие варианты:

1. идентификатор набора значений передан, но служба не распознала его;

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

3. не переданы ни имя, ни идентификатор;

• при вызове метода переданы оба параметра - valueSet_id и valueSet_name. Параметр valueSet_id правильно идентифицирует набор значений, но он отличается от того, что указан в параметре valueSet_name, который может идентифицировать другой набор значений или вообще не указывать на существующий набор значений;
• параметр concept_id.concept_code не распознан как правильный код понятия, принадлежащий системе кодирования, идентифицированной значением параметра concept_id.codeSystem_id;
• служба не поддерживает проверку категоризации для системы кодирования, идентифицированной значением параметра codeSystem_id;
• переданный квалификатор отношения не распознан службой;
• служба не может выполнить требуемую трансляцию:

1. параметр codeSystem_id передан, но не распознан службой;

2. параметр codeSystem_id не передан, а параметр codeSystem_name передан, но его значение не распознано службой;

3. ни один из параметров codeSystem_id и codeSystem_name не передан;

• клиент предоставил неправильный параметр ExpansionContext. Это может означать, что контекст каким-то образом поврежден либо превышены ограничения по времени и контекст перестал быть действительным;
• служба не поддерживает проверку категоризации посткоординируемого выражения;
• служба не может определить по значениям параметров vocabularyDomain_name и applicationContext_code, какой набор значений следует использовать;
• значение параметра codeSystem_name не идентифицирует ту же систему кодирования, что и значение параметра codeSystem_id, либо вообще не именует систему кодирования;
• превышены ограничения по времени, заданные при вызове функции;
• текст, переданный в параметре matchText, синтаксически не корректен по отношению к указанному алгоритму совпадения;
• служба не поддерживает алгоритм совпадения, заданный при ее вызове.

8.3 API времени исполнения уровня сообщений

8.3.1 Идентифицирующий раздел API времени исполнения уровня сообщений

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

Раздел API времени исполнения наследует идентифицирующую информацию от раздела идентификации и имеет два дополнительных метода:

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

Параметры:

• matchText - если присутствует и имеет непустое значение, то возвращается идентификация только тех словарных доменов, чьи имена совпадают с этим значением. Если же этот параметр отсутствует или пуст, то возвратится идентификация всех словарных доменов;
• matchAlgorithm_code - если параметр matchText присутствует и имеет непустое значение, то параметр matchAlgorithm_code указывает, каким образом определяется совпадение имен со значением параметра matchText. Детали см. в 8.2.2.1 "Совпадение строк";
• timeout - время в миллисекундах, в течение которого клиент готов ждать завершения операции. Значение 0 параметра timeout указывает, что на время ее выполнения ограничения не накладываются;
• sizeLimit - максимальное число элементов, которое служба может вернуть. Если число возвращенных элементов совпадает с sizeLimit, то клиент предполагает, что существуют дополнительные элементы, которые не были возвращены. Значение 0 параметра sizeLimit указывает, что число элементов, которые могут быть возвращены, не ограничивается.

Исключения:

• BadlyFormedMatchText;
• UnknownMatchAlgorithm;
• TimeoutError;
• UnexpectedError.

8.3.2 Проверка кодированного атрибута

8.3.2.1 Структура объекта ValidateCodeReturn

Класс ValidationDetail содержит детальное описание ошибки или предупреждения. Она имеет следующие поля:

• codeInError - код понятия, с которым связана данная ошибка или предупреждение. Если ошибка обнаружена в квалификаторе понятия или в его трансляции, то этот код содержит то, в чем найдена ошибка: имя квалификатора, значение квалификатора либо значение трансляции;
• isError - значение TRUE указывает, что элемент ValidationDetail описывает ошибку. Значение FALSE указывает, что он описывает предупреждение;
• error_id - идентификатор ошибки (см. коды возврата методов validateCode и validateTranslation, перечисленные в таблице);
• errorText - текст описания ошибки или предупреждения.

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

• nErrors - число обнаруженных ошибок. Если оно больше нуля, то код или трансляция ошибочны;
• nWarnings - число возвращенных предупреждений. Если результат проверки кода или трансляции содержит только предупреждения, то код или трансляцию можно передавать и обрабатывать, даже если у них какие-то атрибуты могут быть некорректными;
• detail - список отдельных ошибок и/или предупреждений.

8.3.2.2 Описание метода validateCode

Метод validateCode определяет, является ли значение кодированного атрибута допустимым представлением понятия для заданного словарного домена и прикладного контекста. Если параметр errorCheckOnly имеет значение false, то этот метод также проверяет поля codeSystemName и displayName, если они присутствуют. Он рекурсивно проверяет квалификаторы, используя те же самые критерии. Коды понятий, у которых заполнено поле исходного текста originalText, а поле code отсутствует, всегда признаются ошибочными. Метод validateCode не проверяет трансляции.

Входные параметры:

• vocabularyDomain_name - имя словарного домена, используемого для переданного кодированного атрибута;
• codeToValidate - подлежащий проверке код понятия, определенный в стандарте HL7. Как минимум этот код должен содержать поле кода и поле системы кодирования;
• applicationContext_code - контекст или "область применения", где должен использоваться код;
• activeConceptsOnly - значение TRUE (используемое по умолчанию) указывает, что допустимыми считаются только коды понятий, которые в настоящее время активны. Значение FALSE указывает, что код считается допустимым все то время, пока он присутствует в системе кодирования;
• errorCheckOnly - значение TRUE указывает, что код понятия проверяется только на наличие ошибок. Предупреждения в этом случае не возвращаются.

Исключения:

• UnknownVocabularyDomain;
• UnknownApplicationContextCode;
• UnexpectedError.

8.3.3 Проверка трансляций кодированного атрибута

8.3.3.1 Метод validateTranslation

Метод validateTranslation проверяет основной код и все трансляции кодированного атрибута, определенного в стандарте HL7. Обнаруженные ошибки и предупреждения возвращаются в экземпляре класса ValidateCodeReturn.

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

Входные параметры:

• vocabularyDomain_name - имя словарного домена, используемого для переданного кодированного атрибута;
• codeToValidate - подлежащий проверке код понятия, определенный в стандарте HL7. Как минимум этот код должен содержать поле кода и поле системы кодирования;
• applicationContext_code - контекст или "область применения", где должен использоваться код;
• activeConceptsOnly - значение TRUE (используемое по умолчанию) указывает, что допустимыми считаются только коды понятий, которые в настоящее время активны. Значение FALSE указывает, что код считается допустимым все то время, пока он присутствует в системе кодирования;
• errorCheckOnly - значение TRUE указывает, что код понятия проверяется только на наличие ошибок. Предупреждения в этом случае не возвращаются.

Исключения:

• UnknownVocabularyDomain;
• UnknownApplicationContextCode;
• UnexpectedError.

8.3.3.2 Коды возврата методов validateCode и validateTranslation

В таблице 13 перечислены идентификаторы и текст ошибок, которые могут быть возвращены методами validateCode и validateTranslation.

Таблица 13

Коды возврата методов validateCode и validateTranslation

8.3.4 Трансляция кодированного атрибута

Метод translateCode преобразует значение параметра fromCode в код понятия, если таковой имеется, который допустим для целевой системы кодирования или прикладного контекста. Он возвращает полную копию значения параметра fromCode с новой трансляцией (если таковая имеется), добавленной в конец последовательности трансляций CD.translation. Если значение fromCode уже содержит трансляцию, допустимую для целевой системы кодирования или прикладного контекста, то возвращаемая копия параметра fromCode будет совпадать с исходной.

Входные параметры:

• vocabularyDomain_name - словарный домен кодированного атрибута, подлежащего трансляции;
• fromCode - транслируемый код;
• toCodeSystem_id (не обязателен) - если этот параметр указан, то код должен быть транслирован в код понятия (или коды понятий), взятый из системы кодирования, идентифицированной этим параметром, а не из системы кодирования, определяемой целевым контекстом;
• toApplicationContext_code (не обязателен) - прикладной контекст транслированного кода. Используется для определения целевого набора значений, по которому, в свою очередь, определяется целевая система кодирования. Может быть указан только один из параметров toCodeSystem_id и targetContext. Если ни одного из них не указано, то генерируется исключение UnableToTranslate.

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

Исключения:

• UnknownVocabularyDomain;
• UnknownCodeSystem;
• UnknownApplicationContextCode;
• UnableToTranslate;
• UnexpectedError.

8.3.5 Заполнение детальных сведений о кодируемом атрибуте

Метод fillInDetails возвращает полную копию значения параметра codeToFillIn, в которую добавлены поля codeSystemName, codeSystemVersion и displayName, заполненные по базовому значению кода и его квалификаторам, если таковые имеются. Квалификаторы заполняются рекурсивно - если квалификаторы вложены или имеют другие квалификаторы, то детальные сведения о них также заполняются. Метод fillInDetails не изменяет трансляции кода.

Входные параметры:

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

Исключения:

• UnknownCodeSystem;
• UnknownConceptCode;
• UnknownLanguage;
• UnexpectedError.

8.3.6 Проверка, является ли один кодированный атрибут категорией другого

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

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

Параметры:

• parentCode - кодированный атрибут, предполагаемый родителем;
• childCode - кодированный атрибут, предполагаемый его потомком.

Метод subsumes должен возвращать значение TRUE, если значение параметра childCode является подтипом значения атрибута parentCode. Он должен также возвращать значение TRUE, если значения параметров childCode и parentCode эквивалентны. Трансляции этим методом игнорируются.

Исключения:

• UnknownCodeSystem;
• UnknownCode;
• SubsumptionNotSupported;
• UnrecognizedQualifier;
• QualifiersNotSupported;
• UnexpectedError.

8.3.7 Проверка, являются ли два кодированных атрибута эквивалентными

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

Параметры:

• code1 - первый код, проверяемый на эквивалентность;
• code2 - второй проверяемый код.

Исключения:

• UnknownCodeSystem;
• UnknownCode;
• SubsumptionNotSupported;
• UnrecognizedQualifier;
• QualifiersNotSupported;
• UnexpectedError.

8.3.8 Раскрытие словарного домена

8.3.8.1 Структура класса ValueSetDescriptor (описатель набора значений)

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

• valueSet_id - уникальный идентификатор набора значений;
• valueSet_name - уникальное имя набора значений (необязательное).

8.3.8.2 Структура класса ValueSetExpansion (раскрытие набора значений)

Класс ValueSetExpansion имеет следующие поля:

• pathLength - целое значение, определяющее расстояние от корневого набора значений. У корневого набора значений это поле всегда имеет значение 0;
• nodeType_code - код понятия, взятый из системы кодирования HL7 ConceptGenerality (2.16.840.1.113883.5.24). Допустимы следующие коды:

"S" - специализируемый узел. Идентификатор concept_id этого узла может быть выбран, но узел может иметь дальнейшее раскрытие;

"A" - абстрактный узел. Идентификатор concept_id этого узла (если имеется) не может быть выбран. Чтобы можно было сделать выбор, к этому узлу должно быть применено дальнейшее раскрытие;

"L" - конечный узел (лист). Идентификатор concept_id этого узла может быть выбран, но дальнейшее раскрытие невозможно;

• valueSet - идентификатор и имя (если имеется) набора значений, ассоциированного с данным узлом;
• concept_id - система кодирования и код понятия, ассоциированные с данным узлом (если имеются);
• displayName - изображаемое имя, используемое для представления этого узла;
• isExpandable - значение TRUE указывает, что этот узел можно далее раскрыть с помощью функции expandValueSetExpansionContext. Поле isExpandable будет иметь значение TRUE только для специализируемых и абстрактных узлов, и то только в том случае, если в исходном вызове метода lookupValueSetExpansion параметр expandAll (раскрыть все) имел значение FALSE;
• expansionContext - если параметр isExpandable имеет значение TRUE, то параметр expansionContext содержит те сведения, которые необходимы конкретной реализации службы для дальнейшего раскрытия узла при следующих вызовах. Он непрозрачен для клиентского программного обеспечения.

Ниже приведены варианты раскрытия различных типов наборов значений.

Вариант 1 (таблица 14): набор значений A ссылается на все коды неиерархической системы кодирования, содержащей коды понятий 1,2, ..., N.

Таблица 14

Значения полей класса ValueSetExpansion для варианта 1

Вариант 2 (таблица 15): набор значений B ссылается на все коды иерархической системы кодирования. Коды понятий в поле concept_id отражают иерархию (1 - корень, 1.1 - первый потомок корня, 1.2 - второй потомок, 1.2.1 - первый потомок первого потомка и т.д.).

Таблица 15

Значения полей класса ValueSetExpansion для варианта 2

Вариант 3 (таблица 16): набор значений C ссылается на конкретные коды понятий 1, 2, 3 из некоторой системы кодирования. Ни одна из ссылок не включает в себя код отношения. Головного кода также нет.

Таблица 16

Значения полей класса ValueSetExpansion для варианта 3

Вариант 4 (таблица 17): набор значений D ссылается на конкретные коды понятий 1, 2, 3, 4 из некоторой системы кодирования. Ни одна из ссылок не включает в себя код отношения. Код понятия 4 является головным.

Таблица 17

Значения полей класса ValueSetExpansion для варианта 4

Вариант 5 (таблица 18): набор значений E ссылается на описанный выше набор значений D, но при этом поле includeHeadCode (включить головной код) имеет значение TRUE.

Таблица 18

Значения полей класса ValueSetExpansion для варианта 5

Вариант 6 (таблица 19): набор значений F ссылается на описанный выше набор значений D, но при этом поле includeHeadCode (включить головной код) имеет значение FALSE.

Таблица 19

Значения полей класса ValueSetExpansion для варианта 6

Вариант 7 (таблица 20): набор значений G ссылается на коды понятий 1.1, 2.1 и 3.1 из иерархической системы кодирования. Все три ссылки используют код отношения hasSubtype. Ссылка на код 1.1 включает ссылочный код. Ссылка на код 1.2 исключает ссылочный код. У ссылки 3.1 поле leafOnly имеет значение TRUE. Набор значений G не имеет головного кода.

Таблица 20

Значения полей класса ValueSetExpansion для варианта 7

8.3.8.3 Метод lookupValueSetExpansion

Метод lookupValueSetExpansion возвращает раскрытие набора значений, ассоциированного с заданным словарным доменом и необязательным контекстом. Весь словарный домен может быть раскрыт сразу (если параметр expandAll имеет значение TRUE) или может быть раскрыт на один уровень за один раз (если параметр expandAll имеет значение FALSE). В последнем случае каждый узел может быть раскрыт далее, если у него поле isExpandable имеет значение TRUE, указывающее, что поле expansionContext может быть передано методу expandValueSetExpansionContext для дальнейшего раскрытия.

Параметры:

• vocabularyDomain_name - раскрываемый словарный домен;
• applicationContext_code - контекст, в котором должен раскрываться словарный домен (не обязателен);
• language_code - код языка, используемый для возвращаемых изображаемых имен;
• expandAll - значение TRUE указывает, что все узлы раскрываются на их полную глубину, значение FALSE означает раскрытие на один уровень (по умолчанию используется значение TRUE);
• timeout - время в миллисекундах, в течение которого клиент готов ждать завершения операции. Значение 0 параметра timeout указывает, что на время ее выполнения ограничения не накладываются;
• sizeLimit - максимальное число элементов, которое служба может вернуть. Если число возвращенных элементов совпадает с sizeLimit, то клиент предполагает, что существуют дополнительные элементы, которые не были возвращены. Значение 0 параметра sizeLimit указывает, что число элементов, которые могут быть возвращены, не ограничивается.

Исключения:

• UnknownVocabularyDomain;
• UnknownApplicationContextCode;
• UnknownLanguage;
• TimeoutError;
• UnexpectedError.

8.3.8.4 Метод expandValueSetExpansionContext

Метод expandValueSetExpansionContext использует непрозрачное значение параметра expansionContext, которое ранее было возвращено в экземпляре класса ValueSetExpansion, для дальнейшего раскрытия соответствующего узла на дополнительный уровень. Возвращаемое значение идентично тому, что возвращает метод lookupValueSetExpansion, и к вызову применяются все начальные ограничения последнего, включая значение параметра timeout.

Входные параметры:

• expansionContext - контекст, возвращенный предшествующим вызовом метода lookupValueSetExpansion или expandValueSetExpansionContext.

Исключения:

• InvalidExpansionContext;
• TimeoutError;
• UnexpectedError.

8.4 API обозревателя на уровне сообщений

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

8.4.1 Идентифицирующая информация обозревателя сообщений

Обозреватель сообщений наследует идентифицирующую информацию от интерфейса, описанного в 8.2.3 "Идентифицирующий раздел службы".

8.4.2 Раздел описания обозревателя сообщений

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

8.4.2.1 Строительные блоки описания обозревателя

8.4.2.1.1 Структура RIMCodedAttribute

Класс RIMAttributeId уникально идентифицирует кодированный атрибут модели RIM. Он имеет следующие поля:

• model_id - идентификатор модели RIM;
• class_name - имя класса модели RIM;
• attribute_name - имя атрибута в этом классе.

Класс RIMCodedAttribute описывает атрибут модели RIM. Он имеет следующие поля:

• RIMAttribute_id - уникальный идентификатор атрибута;
• dataType_code - код, идентифицирующий тип данных атрибута. Берется из системы кодирования HL7 DataType;
• codingStrength_code - сила кодирования атрибута. Берется из системы кодирования HL7 VocabularyDomainQualifier;
• vocabularyDomain_name - имя словарного домена, ассоциированного с атрибутом.

8.4.2.1.2 Класс CodeSystemDescriptor

Класс CodeSystemDescriptor состоит из идентификатора системы кодирования, ее имени, информации об авторских правах и списка доступных версий:

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

8.4.2.2 Описание обозревателя

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

Метод getSupportedAttributes возвращает список атрибутов модели RIM, известных службе и удовлетворяющих заданным критериям.

Входные параметры:

• matchText - если присутствует и не пуст, то возвращаются сведения только о тех атрибутах модели RIM, имена которых совпадают с текстом, переданным в этом параметре. Если параметр matchText отсутствует или пуст, то возвращаются сведения обо всех атрибутах модели RIM;
• matchAlgorithm_code - если параметр matchText присутствует и не пуст, то значение параметра matchAlgorithm_code указывает, каким образом определяется совпадение имени атрибута со значением параметра matchText. Детальные сведения см. в 8.2.2.1 "Алгоритмы совпадения строк";
• timeout - время в миллисекундах, в течение которого клиент готов ждать завершения операции. Значение 0 параметра timeout указывает, что на время ее выполнения ограничения не накладываются;
• sizeLimit - максимальное число элементов, которое служба может вернуть. Если число возвращенных элементов совпадает с sizeLimit, то клиент предполагает, что существуют дополнительные элементы, которые не были возвращены. Значение 0 параметра sizeLimit указывает, что число элементов, которые могут быть возвращены, не ограничивается.

Исключения:

• BadlyFormedMatchText;
• UnknownMatchAlgorithm;
• TimeoutError;
• UnexpectedError.

Метод getSupportedVocabularyDomains возвращает список словарных доменов, известных службе и удовлетворяющих заданным критериям.

Входные параметры:

• matchText - если присутствует и не пуст, то возвращаются сведения только о тех словарных доменах, имена которых совпадают с текстом, переданным в этом параметре. Если параметр matchText отсутствует или пуст, то возвращаются сведения обо всех словарных доменах;
• matchAlgorithm_code - если параметр matchText присутствует и не пуст, то значение параметра matchAlgorithm_code указывает, каким образом определяется совпадение имени словарного домена со значением параметра matchText. Детальные сведения см. в 8.2.2.1 "Алгоритмы совпадения строк";
• timeout - время в миллисекундах, в течение которого клиент готов ждать завершения операции. Значение 0 параметра timeout указывает, что на время ее выполнения ограничения не накладываются;
• sizeLimit - максимальное число элементов, которое служба может вернуть. Если число возвращенных элементов совпадает с sizeLimit, то клиент предполагает, что существуют дополнительные элементы, которые не были возвращены. Значение 0 параметра sizeLimit указывает, что число элементов, которые могут быть возвращены, не ограничивается.

Исключения:

• BadlyFormedMatchText;
• UnknownMatchAlgorithm;
• TimeoutError;
• UnexpectedError.

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

Параметры:

• matchText - если присутствует и не пуст, то возвращаются сведения только о тех наборах значений, имена которых совпадают с текстом, переданным в этом параметре. Если параметр matchText отсутствует или пуст, то возвращаются сведения обо всех наборах значений;
• matchAlgorithm_code - если параметр matchText присутствует и не пуст, то значение параметра matchAlgorithm_code указывает, каким образом определяется совпадение имени набора значений со значением параметра matchText. Детальные сведения см. в 8.2.2.1 "Алгоритмы совпадения строк";
• timeout - время в миллисекундах, в течение которого клиент готов ждать завершения операции. Значение 0 параметра timeout указывает, что на время ее выполнения ограничения не накладываются;
• sizeLimit - максимальное число элементов, которое служба может вернуть. Если число возвращенных элементов совпадает с sizeLimit, то клиент предполагает, что существуют дополнительные элементы, которые не были возвращены. Значение 0 параметра sizeLimit указывает, что число элементов, которые могут быть возвращены, не ограничивается.

Исключения:

• BadlyFormedMatchText;
• UnknownMatchAlgorithm;
• TimeoutError;
• UnexpectedError.

Метод getSupportedCodeSystems возвращает список систем кодирования, известных службе и удовлетворяющих заданным критериям.

Параметры:

• matchText - если присутствует и не пуст, то возвращаются сведения только о тех системах кодирования, имена которых совпадают с текстом, переданным в этом параметре. Если параметр matchText отсутствует или пуст, то возвращаются сведения обо всех системах кодирования;
• matchAlgorithm_code - если параметр matchText присутствует и не пуст, то значение параметра matchAlgorithm_code указывает, каким образом определяется совпадение имени системы кодирования со значением параметра matchText. Детальные сведения см. в 8.2.2.1 "Алгоритмы совпадения строк";
• timeout - время в миллисекундах, в течение которого клиент готов ждать завершения операции. Значение 0 параметра timeout указывает, что на время ее выполнения ограничения не накладываются;
• sizeLimit - максимальное число элементов, которое служба может вернуть. Если число возвращенных элементов совпадает с sizeLimit, то клиент предполагает, что существуют дополнительные элементы, которые не были возвращены. Значение 0 параметра sizeLimit указывает, что число элементов, которые могут быть возвращены, не ограничивается.

Исключения:

• BadlyFormedMatchText;
• UnknownMatchAlgorithm;
• TimeoutError;
• UnexpectedError.

8.4.3 Обозревание словарного домена

8.4.3.1 Класс VocabularyDomainDescription

Класс VocabularyDomainValueSet содержит описание набора значений (см. 8.3.8 "Раскрытие словарного домена") и код контекста, в котором применяется этот набор значений (если таковой контекст имеется). Он имеет следующие поля:

• definedByValueSet - набор значений, определяющий словарный домен в конкретном прикладном контексте;
• applicationContext_code - код контекста, в котором применяется этот набор значений.

Класс VocabularyDomainDescription описывает структуру, возвращаемую методом lookupVocabularyDomain. Он имеет следующие поля:

• vocabularyDomain_name - уникальное имя словарного домена;
• description - описание домена;
• restrictsDomain_name - словарный домен, ограниченный данным доменом, если таковой имеется;
• basisOfDomains - список доменов, являющихся ограничениями данного домена, если таковые имеются;
• constrainsAttributes - список атрибутов модели RIM, использующих данный словарный домен, если таковые имеются;
• representedByValueSets - список наборов значений и контекст, которые могут представлять данный словарный домен, если таковые имеются.

8.4.3.2 Метод lookupVocabularyDomain

Метод lookupVocabularyDomain возвращает детальные сведения о словарном домене. Он имеет следующий входной параметр:

• vocabularyDomain_name - имя обозреваемого словарного домена.

Исключения:

• UnknownVocabularyDomain;
• UnexpectedError.

8.4.4 Обозревание набора значений

8.4.4.1 Класс FullValueSetDescriptionstructure

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

Класс ValueSetConstructor имеет следующие поля:

• includedValueSet - идентификатор и имя набора значений, считающегося частью данного набора, если таковой имеется;
• includeHeadCode - значение TRUE указывает, что головной код набора значений, включенного в данный набор (если таковой имеется), входит в состав данного набора. Значение FALSE указывает, что не входит.

Класс ValueSetCodeReference имеет следующие поля:

• referenced_code - код понятия, на который ссылается данный набор;
• relationship_code - код отношения. Если присутствует, то все потомки ссылочного кода также считаются частью набора значений, с поправкой на ограничение, задаваемое описанным ниже параметром leafOnly. Если отношение транзитивно, то все потомки также включаются в набор значений. Если оно не транзитивно, то рассматриваются только прямые потомки ссылочного кода;
• includeReferencedCode - значение TRUE указывает, что сам ссылочный код является частью набора значений. Значение FALSE указывает, что в набор значений включаются только его дети или потомки. Параметр includeReferencedCode обязательно имеет значение TRUE, если код отношения relationship_code не задан;
• leafOnly - значение TRUE указывает, что в набор значений включаются только конечные узлы (листья) отношения. Значение FALSE указывает, что в набор значений включаются все потомки, возможно, за исключением самого ссылочного кода. Параметр leafOnly обязательно должен иметь значение FALSE, если код отношения relationship_code не задан.

Класс ValueSetDescription имеет следующие поля:

• idAndName - идентификатор и имя (если таковое имеется) набора значений;
• description - текстовое описание набора значений и его применения;
• definingExpression - выражение, используемое для построения содержания набора значений (если таковое имеется);
• basedOnCodeSystem - идентификатор, имя и версия системы кодирования, используемой для построения набора значений;
• allCodes - значение TRUE указывает, что все коды данной системы кодирования включаются в набор значений. Если значение этого параметра не равно TRUE, то набор значений не должен ссылаться на какие-либо дополнительные коды;
• head_code - код понятия, представляющий весь набор значений (если таковой имеется).

Класс FullValueSetDescription имеет следующие поля:

• description - идентификатор, имя и другие атрибуты набора значений;
• constructedUsingValueSets - список дополнительных наборов значений и включений головных кодов, если таковые имеются, используемых для построения данного набора значений;
• usedToDefine - список других наборов значений, при построении которых используется данный набор значений;
• referencesCodes - список кодов понятий, на которые в данном наборе значений имеются прямые ссылки. Он будет пустым, если параметр allCodes имеет значение TRUE, и не будет содержать те коды, которые косвенно включены из других наборов значений и/или отношений между кодами понятий.

8.4.4.2 Метод lookupValueSet

Метод lookupValueSet извлекает полное описание набора значений по идентификатору или имени набора.

Входные параметры:

• valueSet_id - идентификатор обозреваемого набора значений;
• valueSet_name - имя обозреваемого набора значений.

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

Исключения:

• UnknownValueSet;
• ValueSetNameIdMismatch;
• UnexpectedError.

8.4.5 Обозревание детальной информации о системе кодирования

8.4.5.1 Структура данных, возвращаемая методом lookupCodeSystem

Класс CodeSystemRegistration имеет следующие поля:

• sponsor - член комитета HL7 или организация, выступающая спонсором регистрации системы кодирования;
• publisher - наименование официального издателя системы кодирования;
• versionReportingMethod - описание того, как и сколь часто создаются и распространяются новые версии;
• licensingInformation - описание требуемых лицензий, цены и способа приобретения;
• inUMLS - значение TRUE указывает, что кодированные термины, определенные в этой системе кодирования, включены в Унифицированную систему медицинского языка UMLS (Unified Medical Language System);
• systemSpecificLocatorInfo - информация, специфичная для издателя системы кодирования. Она служит для определения или идентификации конкретной системы кодирования. Комитет HL7 может иногда использовать атрибут systemSpecificLocatorInfo для идентификации соответствующей таблицы стандарта HL7 2.x, если таковая имеется;
• codeSystemType_code - код, имеющий значения I (система кодирования является внутренней, ведется и распространяется комитетом HL7), E (ведется и распространяется третьей стороной), EI (ведется третьей стороной, но ради удобства комитет HL7 поддерживает ее внутренний образ).

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

Класс CodeSystemInfo имеет следующие поля:

• description - базовое описание системы кодирования. См. описание класса CodeSystemDescriptor в 8.4.2.1.2;
• registrationInfo - регистрационная информация о системе кодирования (если таковая имеется).

8.4.5.2 Метод lookupCodeSystem

Метод lookupCodeSystem возвращает детальную информацию о системе кодирования по ее идентификатору (ОИД) или имени.

Входные параметры:

• codeSystem_Id - уникальный идентификатор системы кодирования, которым обычно служит ИСО ОИД;
• codeSystem_name - имя системы кодирования.

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

Исключения:

• UnknownCodeSystem;
• CodeSystemNameIdMismatch;
• UnexpectedError.

8.4.6 Обозревание наборов значений в словарном домене и контексте

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

Входные параметры:

• vocabularyDomain_name - имя обозреваемого словарного домена;
• applicationContext_code (не обязателен) - код прикладного контекста.

Исключения:

• UnknownVocabularyDomain;
• UnknownApplicationContextCode;
• NoApplicableValueSet;
• UnexpectedError.

8.4.7 Установление принадлежности кода понятий к набору значений

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

Входные параметры:

• valueSet_id - идентификатор обозреваемого набора значений;
• valueSet_name - имя обозреваемого набора значений;
• includeHeadCode - значение TRUE указывает, что головной код (если таковой имеется) считается частью данного набора. Значение FALSE указывает, что головной код (если таковой имеется), исключается из набора;
• codeToValidate - код проверяемого понятия и идентификатор его системы кодирования.

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

Исключения:

• UnknownValueSet;
• ValueSetNameIdMismatch;
• UnknownConceptCode;
• UnknownCodeSystem;
• UnexpectedError.

9 Модель API словаря

9.1 Введение

В следующих подразделах описана модель, положенная в основу API словаря ОТС. В настоящем стандарте не представлена полная или глубокая модель всех возможных сущностей, образующих систему кодирования <1>. Его основная цель - описать классы и отношения, имеющие прямое отношение к содержанию кодированных атрибутов HL7 с точки зрения словаря.

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

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

Структура классов, образующих систему кодирования, представлена на рисунке 6.

Рисунок 6 - Классы, образующие систему кодирования

Система кодирования CodeSystem может @определять@ нуль или более кодированных понятий CodedConcept. Кодированное понятие представляет класс объектов или понятие в конкретной области суждений. Каждое кодированное понятие CodedConcept должно быть @определено@ ровно в одной системе кодирования CodeSystem. Будучи однажды определенным, значение кодированного понятия не может изменяться. Существующие кодированные понятия могут отзываться, а новые - добавляться, но, будучи определенным, значение кодированного понятия должно оставаться статическим.

Класс CodeSystem имеет следующие атрибуты:

• codeSystem_id - глобально уникальный идентификатор системы кодирования. В контексте стандартов HL7 он должен принимать форму объектного идентификатора ИСО (ОИД). Комитет HL7 ведет регистр идентификаторов ОИД систем кодирования, и пользователям стандарта настоятельно рекомендуется регистрировать в этом регистре все ОИД, используемые ими в этих службах;
• codeSystem_name - краткая символьная метка, уникально идентифицирующая систему кодирования в контексте модели HL7 RIM. Комитет HL7 включает имена систем кодирования в "систему кодирования систем кодирования", ассоциированную со словарным доменом CodeSystem. Атрибут codeSystem_name используется исключительно в целях коммуникации углеродных форм жизни, а при взаимодействии компьютеров должен использоваться атрибут codeSystemId;
• fullName - официальное имя системы кодирования CodeSystem. Для тех систем, что зарегистрированы в словарном домене HL7 CodeSystem, значением этого имени является предпочтительное английское обозначение ConceptDesignation кодированного понятия CodedConcept, совпадающего с атрибутом codeSystem_name системы кодирования CodeSystem;
• codeSystemDescription - описание назначения и содержания системы кодирования CodeSystem. Для тех систем, что зарегистрированы в словарном домене HL7 CodeSystem, значением этого имени является английское описание ConceptDescription кодированного понятия CodedConcept, совпадающего с атрибутом codeSystem_name системы кодирования CodeSystem;
• copyright - необязательная информация об авторских правах на систему кодирования. Если присутствует, то эта информация должна предоставляться всякий раз, когда система кодирования используется или к ней осуществляется доступ.

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

• supportedLanguages - список всех языков, которые полностью или частично поддерживаются системой кодирования. "Поддерживаемый" язык распознается системой кодирования и на нем доступна хотя бы часть обозначений или свойств понятий. Все системы кодирования должны поддерживать хотя бы один язык. В то время как служба должна возвращать перечисление всех субтегов основного языка, который она поддерживает, она не обязана перечислять вторичные языки. (Например, если она поддерживает язык "en-UK", она должна возвращать тег "en", но может возвращать или не возвращать "en-UK");
• supportedRelations - отношения (роли), представленные в системе кодирования. В данной модели отношение подтипа (subtype) трактуется как отношение первого класса (код отношения: hasSubtype). Код отношения имеет и идентификатор системы кодирования, и код понятия, что позволяет брать коды отношений из многих источников. Для целей интероперабельности коды отношений должны по возможности браться из системы кодирования HL7 ConceptRelationship (ОИД 2.16.840.1.113883.5.1088);
• supportedProperties - коды свойств, поддерживаемых системой кодирования. Однако по возможности коды свойств должны браться из системы кодирования HL7 ConceptProperty (ОИД 2.16.840.1.113883.5.1087);
• supportedMimeTypes - список типов среды MIME, используемых системой кодирования в обозначениях, описаниях или свойствах. Эти коды должны браться из системы кодирования типов среды MediaType, официально предназначенной для этих целей комитетом HL7 (в настоящее время - ОИД 2.16.840.1.113883.5.79). Тип среды text/plain (неформатированный текст) должен поддерживаться всеми системами кодирования;
• supportedRelationshipQualifiers - список квалификаторов отношений, распознаваемых системой кодирования.

Система кодирования CodeSystem может @представлять@ нуль или одну версию CodeSystemVersion в каждый момент времени <1>.

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

9.3 Кодированное понятие CodedConcept

Кодированное понятие CodedConcept уникально в системе кодирования CodeSystem, где оно @определено@. Кодированное понятие CodedConcept должно быть @обозначено@ по меньшей мере одним экземпляром класса ConceptDesignation. Обозначение ConceptDesignation должно @представлять значение@ одного или более кодированных понятий CodedConcept <2>. Кодированное понятие CodedConcept может @характеризоваться@ нулем или более свойств ConceptProperty. Свойство ConceptProperty может @представлять или определять@ одно или более кодированных понятий CodedConcept.

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

Кодированное понятие CodedConcept может @служить источником@ или @служить целью@ нуля или более отношений ConceptRelationship. Отношения описаны более детально в следующем подпункте.

Класс CodedConcept имеет следующие атрибуты:

• code - идентификатор, однозначно задающий класс или "понятие" в контексте определяющей системы кодирования CodeSystem. Будучи присвоенным, "смысл" кода понятия никогда не должен меняться. В настоящем стандарте не делается никаких предположений о тех или других способах присвоения в системе кодирования одного и того же "смысла" нескольким кодированным понятиям;
• status - текущий статус кодированного понятия CodedConcept в системе кодирования CodeSystem. Значения статусов понятий должны браться из системы кодирования HL7 ConceptStatus (ОИД 2.16.840.1.113883.5.1086). К возможным значениям статуса относятся "proposed" (предложен), "active" (активный), "deleted" (удален) и "retired" (устарел). В настоящем стандарте проводится только различие между статусами "active" (активный) и "not active" (неактивный). Статусы и версионность понятий будут более полно рассмотрены в следующих версиях настоящего документа.

9.4 Обозначение понятия ConceptDesignation

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

Класс ConceptDesignation имеет следующие атрибуты:

• designation - строка текста, являющаяся внешним представление кодированного понятия CodedConcept;
• languageCode - код языка, конструируемый по правилам, описанным в IETF RFC 3066 - Tag for Identification of Languages (теги идентификации языка). Этот код состоит из нескольких субтегов, разделенных дефисами ("-"). Первый субтег идентифицирует основной код языка. По возможности он должен быть взят из ИСО 639-1 "Codes for the representation of names of languages - Part 1: Alpha-2 code" (Коды для представления названий языков. Часть 1. Двухбуквенный код). Если двухбуквенный код отсутствует, то надо взять код из ИСО 639-2 "Codes for the representation of names of languages - Part 2: Alpha-3 code" (Коды для представления названий языков. Часть 2. Трехбуквенный код). Существует также дополнительный механизм спецсимволов, который в настоящем стандарте не описан.

Второй субтег не обязателен. Если он присутствует, то должен иметь длину от 2 до 8 символов. Если его длина равна двум, то он должен содержать двухбуквенный код страны, взятый из ИСО 3166-1 "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes" (Коды для представления названий стран и единиц их административно-территориального деления. Часть 1. Коды стран). Если длина субтега от 3 до 8 символов, то он должен содержать код, взятый из регистра тегов языков организации IANA. Дополнительные субтеги используются, если надо уточнить информацию о языке;

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

9.5 Свойство понятия ConceptProperty

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

• propertyCode - сочетание идентификаторов системы кодирования и кода понятия, идентифицирующее тип свойства. По возможности коды свойств должны браться из системы кодирования HL7 ConceptProperty (ОИД 2.16.840.1.113883.5.1087);
• propertyValue - текстовое значение ассоциированного свойства;
• language_code - код языка, взятый из системы кодирования, официально предназначенной для этих целей комитетом HL7 (в настоящее время - ОИД 2.16.840.1.113883.6.84 - IETF RFC 3066 - Tag for Identification of Languages). Не у всех свойств понятий ConceptProperty есть коды языка. Если код языка опущен, то предполагается, что характер этого свойства таков, что понятие языка к нему неприменимо;
• mimeType_code - код, взятый из системы кодирования типов среды MediaType, официально предназначенной для этих целей комитетом HL7 (в настоящее время - ОИД 2.16.840.1.113883.5.79). Не у всех свойств ConceptProperty есть код среды. По умолчанию используется тип среды text/plain (неформатированный текст).

9.6 Отношение понятий ConceptRelationship

Класс ConceptRelationship представляет бинарные отношения на множестве кодированных понятий CodedConcept, принадлежащих одной системе кодирования CodeSystem <1>. Каждое отношение ConceptRelationship должно иметь ровно один экземпляр класса CodedConcept в качестве источника и ровно один экземпляр класса CodedConcept в качестве цели. Атрибут relationship_code идентифицирует направленное отношение. Система кодирования HL7 ConceptCodeRelationship (ОИД 2.16.840.1.113883.5.1088) определяет типы отношений, используемых в словаре стандарта HL7 Версии 3. В этой системе кодирования описано, какой код понятия является источником, какой целью, характеризуются транзитивность, симметричность и рефлексивность отношения, а также термин, используемый для представления инверсии отношения.

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

Список кодов отношений приведен в таблице 21.

Таблица 21

Основные коды отношений

10 Спецификация API словаря

10.1 Введение

API словаря ОТС (CTS Vocabulary API - CTSVAPI) состоит из двух разделов - раздел времени исполнения, определяющий комплекс функций, необходимых для каждодневных операций программного обеспечения, обрабатывающего сообщения, соответствующие стандарту HL7 Версии 3, и раздел обозревателя, определяющего функции, предназначенные для разработки и конструирования словаря HL7 и содержания наборов значений/словарных доменов. Предполагается, что функции раздела обозревателя имеют доступ к API времени сообщений, поэтому функциональность этого API не воспроизводится в разделе обозревателя. В обоих разделах используется описанный ниже общий комплекс определений базовых типов данных.

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

Ниже перечислены базовые типы данных, используемые в API времени исполнения на уровне словаря, API обозревателя словаря и API трансляции:

• OID - объектный идентификатор ИСО (ОИД);
• Description - текстовое описание объекта или сущности. При реализации следует иметь в виду, что некоторые описания могут быть довольно длинными;
• CTSVersionId - идентификатор версии реализации Общих терминологических служб (ОТС). В версии 1.0 поле major имеет значение 1, а поле minor - значение 0;
• CodeSystemId - уникальный идентификатор системы кодирования. В контексте стандартов HL7 им должен быть объектный идентификатор ИСО (ОИД), присвоенный комитетом HL7, если таковой имеется. Другие виды идентификаторов, например UUID, определенный для среды распределенных вычислений DCE (Distributed Computing Environment), и т.д., могут использоваться в качестве идентификаторов систем кодирования вне среды применения стандартов HL7. В этих случаях разработчик должен предупреждать любые конфликты пространств имен, которые могут возникать между ОИД и другими идентификаторами;
• CodeSystemName - краткая мнемоника или имя системы кодирования. Как идентификатор системы кодирования, так и ее имя уникальны в пространстве имен, контролируемом стандартом HL7 Версии 3, но в общем случае уникальность не гарантируется;
• ConceptCode - код, уникально представляющий класс или понятие в контексте системы кодирования;
• ConceptId - сочетание идентификаторов системы кодирования и кода понятия, являющееся глобально уникальным именем понятия;
• VersionId - уникальный идентификатор версии. Обычно идентификаторы версий имеют определенную упорядоченность, позволяющую людям или программам определить, в какой последовательности идут эти идентификаторы;
• CodeSystemVersion - идентификатор версии системы кодирования;
• ExpansionContext - непрозрачный большой двоичный объект, используемый для передачи контекстной информации между сервером и клиентом.

10.2.1 Кодируемые элементы данных

Ниже описаны кодируемые элементы данных, используемые в API словаря:

• LanguageCode - код разговорного или письменного языка, конструируемый по правилам, описанным в документе IETF RFC 3066 - Tag for Identification of Languages (теги идентификации языка). Этот код состоит из нескольких субтегов, разделенных дефисами ("-"). Первый субтег идентифицирует основной код языка. По возможности он должен быть взят из ИСО 639-1 "Codes for the representation of names of languages - Part 1: Alpha-2 code" (Коды для представления названий языков. Часть 1. Двухбуквенный код). Если двухбуквенный код отсутствует, то надо взять код из ИСО 639-2 "Codes for the representation of names of languages - Part 2: Alpha-3 code" (Коды для представления названий языков. Часть 2. Трехбуквенный код). Существует также дополнительный механизм спецсимволов, который в настоящем стандарте не описан.

Второй субтег не обязателен. Если он присутствует, то должен иметь длину от 2 до 8 символов. Если его длина равна двум, то он должен содержать двухбуквенный код страны, взятый из ИСО 3166-1 "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes" (Коды для представления названий стран и единиц их административно-территориального деления. Часть 1. Коды стран). Если длина субтега от 3 до 8 символов, то он должен содержать код, взятый из регистра тегов языков организации IANA. Дополнительные субтеги используются, если надо уточнить информацию о языке;

• MimeTypeCode - тип среды MIME, взятый из документа организации IETF RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies (Многоцелевые расширения почты Интернет (MIME). Часть первая: формат тел сообщений Интернет). Комитет HL7 ведет подмножество MediaType типов среды MIME, имеющее ОИД 2.16.840.1.113883.5.79;
• ConceptStatusCode - статус понятия в системе кодирования (активное, устарело и т.д.);
• PropertyCode - свойство, которое может быть ассоциировано с понятием в системе кодирования;
• RelationshipCode - идентифицирует конкретное отношение, имеющее место в системе кодирования. Коды отношений должны по возможности браться из системы кодирования HL7 ConceptRelationship (ОИД 2.16.840.1.113883.5.1088);
• MapQualityCode - общее "качество" отображения понятия (точное, шире, уже и т.д.);
• RelationQualifierCode - квалификатор отношения понятий;
• MatchAlgorithmCode - кодированное обозначение алгоритма, используемого для определения совпадения строк и сравнения.

В таблице 22 перечислены системы кодирования и их идентификаторы ОИД, используемые в сообщениях API словаря ОТС.

Таблица 22

ОИД и имена кодируемых элементов данных

10.2.2 Раздел идентификации службы

API времени исполнения на уровне словаря и API обозревателя наследуют общий интерфейс идентификации.

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

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

• getServiceName - возвращает имя, присвоенное службе ее поставщиком;
• getServiceVersion - возвращает идентификатор версии, специфичный для конкретной реализации службы;
• getServiceDescription - описание службы, сведения об авторе, назначении и т.д.;
• getCTSVersion - конкретная версия ОТС, реализованная службой (например, 1.0).

10.2.3 Исключения

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

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

Исключения, генерируемые API словаря:

• идентификатор системы кодирования не распознан службой;
• идентификатор системы кодирования распознан службой, но код понятия concept_code не определен в этой системе;
• значение кода свойства property_code не поддерживается системой кодирования;
• язык с кодом language_code не поддерживается системой кодирования;
• отношение с кодом relationship_code не поддерживается системой кодирования;
• значение квалификатора отношения с кодом relationQualifier_code не поддерживается системой кодирования;
• тип среды MIME с кодом mimeType_code не поддерживается системой кодирования;
• у понятия с кодом concept_id нет обозначения на языке с кодом language_code;
• значение параметра codeSystem_name не идентифицирует ту же систему кодирования, что и значение параметра codeSystem_id, либо вообще не именует систему кодирования;
• служба не может осуществить разбор текста, переданного в параметре matchText.

10.3 API времени исполнения на уровне словаря

В настоящем подразделе описаны атрибуты и методы раздела времени исполнения API словаря ОТС.

10.3.1 Системы кодирования, поддерживаемые API

10.3.1.1 Структура класса CodeSystem

Класс CodeSystem имеет следующие поля:

• codeSystem_id - уникальный идентификатор системы кодирования, которым обычно служит объектный идентификатор ИСО (ОИД);
• codeSystem_name - официальное имя системы кодирования;
• copyright - информация об авторских правах на систему кодирования, если таковые имеются;
• codeSystem_versions - версия или версии системы кодирования, поддерживаемые службой. Этот список может быть пуст, если система кодирования не имеет отдельных идентификаторов версий.

10.3.1.2 Метод getSupportedCodeSystems

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

Входные параметры:

• timeout - время в миллисекундах, в течение которого клиент готов ждать завершения операции. Значение 0 параметра timeout указывает, что на время ее выполнения ограничения не накладываются;
• sizeLimit - максимальное число элементов, которое служба может вернуть. Если число возвращенных элементов совпадает с sizeLimit, то клиент предполагает, что существуют дополнительные элементы, которые не были возвращены. Значение 0 параметра sizeLimit указывает, что число элементов, которые могут быть возвращены, не ограничивается.

Исключения:

• TimeoutError;
• UnexpectedError.

10.3.2 Обозревание идентифицирующей информации системы кодирования

10.3.2.1 Структура, возвращаемая методом lookupCodeSystemInfo

Структура, возвращаемая методом lookupCodeSystemInfo, имеет следующие поля:

• codeSystem - идентификатор системы кодирования, ее имя и поддерживаемая версия (версии);
• fullName - полное имя системы кодирования;
• codeSystemDescription - описание содержания системы кодирования;
• supportedLanguages - список всех языков, которые полностью или частично поддерживаются системой кодирования. "Поддерживаемый" язык распознается системой кодирования и на нем доступна хотя бы часть обозначений или свойств понятий. Все системы кодирования должны поддерживать хотя бы один язык. В то время как служба должна возвращать перечисление всех субтегов основного языка, который она поддерживает, она не обязана перечислять вторичные языки. (Например, если она поддерживает язык "en-UK", она должна возвращать тег "en", но может возвращать или не возвращать "en-UK");
• supportedRelations - список всех отношений, поддерживаемых службой в системе кодирования. "Поддерживаемое" отношение распознается системой кодирования, которая способна определить, являются ли два принадлежащих ей кода понятий связанными этим отношением. Неиерархическая система кодирования не нуждается в поддержке каких-либо отношений. Отношение подтипа представлено кодом отношения hasSubtype;
• supportedProperties - список всех свойств, поддерживаемых системой кодирования. Свойство считается "поддерживаемым", если система кодирования распознает его и по меньшей мере одно кодированное понятие ассоциировано с этим свойством и необязательным значением;
• supportedMimeTypes - список типов среды MIME, поддерживаемых системой кодирования. Все системы кодирования должны поддерживать тип среды text/plain (неформатированный текст), даже если в ней нет ни одного свойства с этим типом;
• supportedRelationshipQualifiers - список квалификаторов отношений, распознаваемых системой кодирования (если таковые имеются).

10.3.2.2 Метод lookupCodeSystemInfo

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

Входные параметры:

• codeSystem_Id - идентификатор ИСО ОИД, присвоенный системе кодирования;
• codeSystem_name - уникальное имя системы кодирования.

Исключения:

• UnknownCodeSystem;
• CodeSystemNameIdMismatch;
• UnexpectedError.

10.3.3 Проверка идентификатора понятия

Метод isConceptIdValid определяет, является ли переданный ему идентификатор понятия действительным.

Входные параметры:

• concept_id - проверяемый код понятия и его система кодирования;
• activeConceptsOnly - значение TRUE указывает, что действительными считаются только активные понятия. Значение FALSE указывает, что действительным считается любой код понятия, известный системе кодирования.

Исключения:

• UnknownCodeSystem;
• UnexpectedError.

10.3.4 Обозревание обозначения идентификатора понятия

10.3.4.1 Класс StringAndLanguage

Класс StringAndLanguage содержит поле текста и поле кода языка, ассоциированного с текстом. Такая структура, состоящая из двух частей, существует по той причине, что код языка, возвращаемый методом lookupDesignation и другими операциями, может отличаться от кода языка, указанного во входных параметрах. Например, клиент мог запросить обозначение на языке с кодом "en-scouse" (ливерпульский диалект английского языка), а служба может вернуть обозначение на английском языке без указания диалекта (с кодом "en"). Программному обеспечению клиента может потребоваться информация о том, что возвращенное значение не точно совпадает с запрошенным.

В некоторых языках программирования связь с языком может являться частью возвращаемого значения (например, при использовании протокола XML/SOAP). Для единообразия поле кода языка language_code должно всегда передаваться в таких значениях, даже если оно избыточно.

10.3.4.2 Метод lookupDesignation

Метод lookupDesignation возвращает обозначение полученного им идентификатора понятия, наиболее подходящее для заданного языка и контекста. Метод lookupDesignation сперва пытается найти обозначение, которое в точности соответствует заданному языку. Если такое обозначение не найдено, то метод удаляет из кода языка крайний правый субтег, если таковой имеется, и повторяет процедуру поиска. Этот процесс повторяется до тех пор, пока будет найдено требуемое обозначение либо останется только основной тег языка. Например, для кода языка "en-UK-south" будут сделаны попытки поиска для языков "en-UK-south", "en-UK" и "en" в указанном порядке. Обозначения на языках с кодами "en-US" и "fr" будут игнорироваться при поиске.

Входные параметры:

• concept_id - код понятия и его система кодирования;
• language_code - желательный код языка для возвращаемого обозначения.

Исключения:

• UnknownLanguageCode;
• UnknownCodeSystem;
• UnknownConceptCode;
• NoApplicableDesignationFound;
• UnexpectedError.

10.3.4.3 Правила совпадения в методе lookupDesignation

В документе RFC 3066 "Tag for Identification of Languages" (теги идентификации языка) описаны коды языков, состоящие из нескольких частей. Первая часть берется из списков двух- или трехсимвольных кодов, определенных в ИСО 639, при этом двухсимвольный код имеет приоритет по сравнению с трехсимвольных, если у языка есть оба кода. Вторая часть кода языка, субтег, идентифицирует страну, регион или другой вариант.

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

1. Определить, поддерживает ли система кодирования основной код языка. Если нет, сгенерировать исключение UnknownLanguageCode;

2. Если обнаружено обозначение, у которого код языка точно совпадает с заданным, а признак предпочтительности preferredForLanguage имеет значение TRUE, возвратить его;

3. Если существуют обозначения, язык которых точно совпадает с заданным, а признак предпочтительности preferredForLanguage имеет значение FALSE, возвратить обозначение, самое раннее в алфавитном порядке;

4. Если код языка имеет один или более вторичных субтегов, удалить крайний правый тег, и повторить шаги 1 и 2;

5. Если у кода языка вторичный субтег отсутствует, сгенерировать исключение NoApplicableDesignationFound.

10.3.5 Определение наличия отношения между двумя кодами понятий

Метод areCodesRelated определяет наличие отношения между двумя переданными ему кодами понятий.

Входные параметры:

• codeSystem_id - система кодирования родительского и дочернего кодов;
• source_code - код понятия, предполагаемый источником отношения;
• target_code - код понятия, предполагаемый целью отношения;
• relationship_code - код понятия, идентифицирующий отношение;
• relationQualifiers - необязательный список кодов квалификаторов отношения. Если список relationQualifiers содержит один или несколько кодов квалификаторов, то рассматриваются только сведения о тех отношениях, квалификаторы которых совпадают со всеми квалификаторами, включенными в этот список;
• directRelationsOnly - значение TRUE указывает, что должны проверяться только непосредственные отношения. Значение FALSE указывает, что должно проверяться транзитивное замыкание отношения, если оно является транзитивным. Если отношение не транзитивно, то значение признака directRelationsOnly никакого влияния на результат не оказывает.

Метод areCodesRelated возвращает значение TRUE, если выполняется одно из следующих условий:

1. В заданной системе кодирования существует прямое отношение типа relationship_code между кодами понятий source_code и target_code;

2. В заданной системе кодирования существует прямое отношение типа relationship_code между кодами понятий target_code и source_code, при этом отношение является симметричным;

3. Коды понятий source_code и target_code эквивалентны и отношение рефлексивно;

4. Параметр directRelationsOnly имеет значение FALSE, отношение relationship_code транзитивно и в прямом транзитивном замыкании отношения relationship_code, начинающегося с кода понятия source_code, существует отношение типа relationship_code между кодами понятий source_code и target_code;

5. Параметр directRelationsOnly имеет значение FALSE, отношение relationship_code транзитивно и симметрично, и в обратном транзитивном замыкании отношения relationship_code, начинающегося с кода понятия source_code, существует отношение типа relationship_code между кодами понятий target_code и source_code.

Исключения:

• UnknownConceptCode;
• UnknownCodeSystem;
• UnknownRelationshipCode;
• UnknownRelationQualifier;
• UnexpectedError.

10.4 API обозревателя на уровне словаря

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

API обозревателя на уровне словаря использует те же самые базовые типы данных, что и API времени исполнения. Они определены в подразделе 10.2 "Базовые типы данных". В настоящем подразделе описаны атрибуты и методы раздела обозревателя API на уровне словаря.

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

10.4.1 Системы кодирования, поддерживаемые API

Метод getSupportedCodeSystems предоставляет список всех систем кодирования и их версий, поддерживаемых службой, в форме класса CodeSystemIdAndVersionsList, описанной в 10.3.1 "Системы кодирования, поддерживаемые API".

Входные параметры:

• timeout - время в миллисекундах, в течение которого клиент готов ждать завершения операции. Значение 0 параметра timeout указывает, что на время ее выполнения ограничения не накладываются;
• sizeLimit - максимальное число элементов, которое служба может вернуть. Если число возвращенных элементов совпадает с sizeLimit, то клиент предполагает, что существуют дополнительные элементы, которые не были возвращены. Значение 0 параметра sizeLimit указывает, что число элементов, которые могут быть возвращены, не ограничивается.

Исключения:

• TimeoutError;
• UnexpectedError.

10.4.2 Поиск кодов понятий по тексту обозначения

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

Входные параметры:

• codeSystem_id - идентификатор системы кодирования, в которой осуществляется поиск;
• matchText - если присутствует и не пуст, то возвращаются сведения только о тех кодах понятий, обозначения которых совпадают с текстом, переданным в этом параметре. Если параметр matchText отсутствует или пуст, то возвращаются сведения обо всех обозначениях;
• matchAlgorithm_code - если параметр matchText присутствует и не пуст, то значение параметра matchAlgorithm_code указывает, каким образом определяется совпадение обозначения со значением параметра matchText. Детальные сведения см. в 8.2.2.1 "Алгоритмы совпадения строк";
• language_code - если этот параметр указан, то ограничивает поиск обозначений только на этом языке. (По умолчанию - поиск на всех языках.) Совпадающий код языка должен быть не более общим, чем значение, заданное этим параметром. Например, если этот параметр имеет значение "en", то должны считаться совпадающими обозначения, имеющие коды языка "en", "en-UK", "en-UK-south" и т.д. Если же параметр language_code имеет значение "en-UK-south", то будут возвращены идентификаторы только тех понятий, у которых язык обозначений совпадает с заданным;
• activeConceptsOnly - значение TRUE (используемое по умолчанию) указывает, что допустимыми считаются только коды понятий, которые в настоящее время активны. Значение FALSE указывает, что допустимыми считаются все коды понятий, содержащиеся в системе кодирования;
• timeout - время в миллисекундах, в течение которого клиент готов ждать завершения операции. Значение 0 параметра timeout указывает, что на время ее выполнения ограничения не накладываются;
• sizeLimit - максимальное число элементов, которое служба может вернуть. Если число возвращенных элементов совпадает с sizeLimit, то клиент предполагает, что существуют дополнительные элементы, которые не были возвращены. Значение 0 параметра sizeLimit указывает, что число элементов, которые могут быть возвращены, не ограничивается.

Исключения:

• UnknownCodeSystem;
• BadlyFormedMatchText;
• UnknownMatchCode;
• UnknownLanguageCode;
• TimeoutError;
• UnexpectedError.

10.4.3 Поиск кодов понятий по их свойствам

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

Входные параметры:

• codeSystem_id - идентификатор системы кодирования, в которой осуществляется поиск;
• matchText - искомый текст. Формат и синтаксис этого текста зависит от значения параметра matchAlgorithmCode;
• matchAlgorithm_code - указывает алгоритм, с помощью которого определяется совпадение свойства со значением параметра matchText. Детальные сведения см. в 8.2.2.1 "Алгоритмы совпадения строк";
• language_code - если этот параметр указан, то ограничивает поиск свойств только на этом языке. (По умолчанию - поиск на всех языках.) Совпадающий код языка должен быть не более общим, чем значение, заданное этим параметром. Например, если этот параметр имеет значение "en", то должны считаться совпадающими обозначения, имеющие коды языка "en", "en-UK", "en-UK-south" и т.д. Если же параметр language_code имеет значение "en-UK-south", то будут возвращены идентификаторы только тех понятий, у которых язык свойств совпадает с заданным;
• activeConceptsOnly - значение TRUE (используемое по умолчанию) указывает, что допустимыми считаются только коды понятий, которые в настоящее время активны. Значение FALSE указывает, что допустимыми считаются все коды понятий, содержащиеся в системе кодирования;
• properties - список кодов свойств, участвующих в поиске (по умолчанию искать по всем свойствам);
• mimeTypes - список типов среды MIME, участвующих в поиске (по умолчанию искать по всем типам среды MIME);
• timeout - время в миллисекундах, в течение которого клиент готов ждать завершения операции. Значение 0 параметра timeout указывает, что на время ее выполнения ограничения не накладываются;
• sizeLimit - максимальное число элементов, которое служба может вернуть. Если число возвращенных элементов совпадает с sizeLimit, то клиент предполагает, что существуют дополнительные элементы, которые не были возвращены. Значение 0 параметра sizeLimit указывает, что число элементов, которые могут быть возвращены, не ограничивается.

Исключения:

• UnknownCodeSystem;
• BadlyFormedMatchText;
• UnknownMatchCode;
• UnknownLanguageCode;
• UnknownPropertyCode;
• UnknownMimeTypeCode;
• TimeoutError;
• UnexpectedError.

10.4.4 Возвращение полного описания кодированного понятия

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

10.4.4.1 Класс ConceptDesignation

Класс ConceptDesignation имеет следующие поля:

• designation - обозначение кодированного понятия;
• language_code - язык обозначения;
• preferredForLanguage - значение TRUE указывает, что это обозначение следует предпочесть для представления назначения кодированного понятия CodedConcept на заданном языке, если иные критерии отсутствуют. Для каждого заданного языка и заданного понятия только одно обозначение может быть указано предпочтительным.

10.4.4.2 Класс ConceptProperty

Класс ConceptProperty имеет следующие поля:

• property_code - код понятия, идентифицирующий конкретное свойство;
• propertyValue - значение этого свойства у данного понятия;
• language_code - язык значения propertyValue (необязательный);
• mimeTypeCode - тип среды MIME значения propertyValue (по умолчанию text/plain).

10.4.4.3 Класс CompleteCodedConceptDescription

10.4.4.3.1 Класс ConceptRelationship

Класс ConceptRelationship имеет следующие поля:

• sourceConcept_id - идентификатор понятия (идентификатор системы кодирования и код понятия), являющегося источником отношения;
• relationship_code - код отношения;
• relationQualifiers - необязательный список кодов квалификаторов, уточняющих или иным образом характеризующих отношение;
• targetConcept_id - идентификатор понятия (идентификатор системы кодирования и код понятия), являющегося источником отношения.

10.4.4.3.2 Класс CompleteCodedConceptDescription

Класс CompleteCodedConceptDescription имеет следующие поля:

• concept_id - идентификатор системы кодирования и код понятия, информация о котором должна быть извлечена;
• conceptStatus_code - статус понятия в заданной системе кодирования;
• codeSystem_version - версия системы кодирования, из которой берется описание понятия;
• designatedBy - список всех обозначений кодированного понятия;
• hasProperties - список всех свойств кодированного понятия за исключением свойств обозначения ConceptDesignation;
• sourceFor - список всех отношений, в которых данное понятие выступает в роли "источника";
• targetOf - список всех отношений, в которых данное понятие выступает в роли "цели".

10.4.4.3.3 Метод lookupCompleteCodedConcept

Метод lookupCompleteCodedConcept возвращает структурированную информацию, содержащую все известные сведения о заданном коде понятия (с точки зрения CTS).

Входные параметры:

• concept_id - идентификатор системы кодирования и код понятия.

Исключения:

• UnknownCodeSystem;
• UnknownConceptCode;
• UnexpectedError.

10.4.5 Просмотр обозначений конкретного кода понятия

Метод lookupDesignations возвращает избранные обозначения заданного понятия. Правила совпадения, используемые методом lookupDesignations, идентичны тем, что определены в 10.4.2 "Поиск кодов понятий по тексту обозначения". Возвращаемые значения имеют тип данных списка ConceptDesignationList, элементы которого описаны в 10.4.4.1 "Класс ConceptDesignation".

Входные параметры:

• codeSystem_id - идентификатор системы кодирования, в которой осуществляется поиск;
• matchText - искомый текст. Формат и синтаксис этого текста зависит от значения параметра matchAlgorithmCode;
• matchAlgorithm_code - указывает алгоритм, с помощью которого определяется совпадение обозначения со значением параметра matchText. Детальные сведения см. в 8.2.2.1 "Алгоритмы совпадения строк";
• language_code - если этот параметр указан, то ограничивает поиск свойств только на этом языке. (По умолчанию - поиск на всех языках.)

Исключения:

• UnknownCodeSystem;
• UnknownConceptCode;
• BadlyFormedMatchText;
• UnknownMatchAlgorithm;
• UnknownLanguageCode;
• UnexpectedError.

10.4.6 Просмотр свойств кода понятия

Метод lookupProperties возвращает избранные свойства заданного понятия. Обработка параметров properties, matchText language_code и mimeTypes следует тем же правилам, что используются методом lookupConceptCodesByProperty. Возвращаемые значения имеют тип данных списка ConceptPropertyList, элементы которого описаны в 10.4.4.2 "Класс ConceptProperty".

Входные параметры:

• codeSystem_id - идентификатор системы кодирования, в которой осуществляется поиск;
• properties - список кодов свойств, участвующих в поиске (по умолчанию искать по всем свойствам);
• matchText - искомый текст. Формат и синтаксис этого текста зависит от значения параметра matchAlgorithmCode;
• matchAlgorithm_code - указывает алгоритм, с помощью которого определяется совпадение свойства со значением параметра matchText. Детальные сведения см. в 8.2.2.1 "Алгоритмы совпадения строк";
• language_code - если этот параметр указан, то ограничивает поиск свойств только на этом языке. (По умолчанию - поиск на всех языках.);
• mimeTypes - список типов среды MIME, участвующих в поиске (по умолчанию искать по всем типам среды MIME).

Исключения:

• UnknownCodeSystem;
• UnknownConceptCode;
• BadlyFormedMatchText;
• UnknownMatchAlgorithm;
• UnknownLanguageCode;
• UnknownPropertyCode;
• UnknownMimeTypeCode;
• UnexpectedError.

10.4.7 Возвращение списка связанных кодов понятий

10.4.7.1 Структура данных, возвращаемая методом lookupCodeExpansion

Структура данных, возвращаемая методом lookupCodeExpansion, имеет следующие поля:

• pathLength - целое значение, определяющее расстояние в уровнях от раскрываемого кода, для которого это поле всегда имеет значение 0;
• concept_code - связанный код понятия;
• designation - предпочтительное обозначение кода на подходящем языке в прикладном контексте либо обозначение по умолчанию, если ни одно из обозначений явно не объявлено предпочтительным;
• relationQualifiers - список кодов квалификаторов отношения, применяемых к данному узлу;
• canExpand - значение TRUE указывает, что существуют дополнительные коды понятий, непосредственно связанные с кодом понятия concept_code, которые могут быть далее раскрыты;
• expansionContext - если параметр canExpand имеет значение TRUE, то параметр expansionContext содержит непрозрачный контекст, который может использоваться для дальнейшего раскрытия кода в этом узле.

10.4.7.2 Просмотр иерархического раскрытия кода

Метод lookupCodeExpansion возвращает линеаризованный список кодов, имеющих отношение типа relationship_code с понятием, имеющим код expandConcept_id.concept_code в системе кодирования с идентификатором expandConcept_id.codeSystem_id.

Входные параметры:

• expandConcept_id - идентификатор системы кодирования и раскрываемый код понятия. Если параметр relationship_code имеет значение "hasSubtype" и признак sourceToTarget имеет значение TRUE, то код понятия может быть опущен. В этом случае должны возвращаться сведения обо всех "корневых" понятиях отношения подтипа, то есть всех понятиях, которые не являются целью одного или нескольких отношений типа "hasSubtype";
• relationship_code - код раскрываемого понятия;
• sourceToTarget - значение TRUE указывает, что раскрытие осуществляется от источника к цели. Значение FALSE указывает, что раскрытие осуществляется от цели к источнику;
• directRelationsOnly - если этот параметр имеет значение TRUE или отношение, заданное параметром relationship_code, не является транзитивным, то возвращаются только прямые цели (или источники, если параметр sourceToTarget имеет значение FALSE) раскрываемого понятия с идентификатором expandConcept_id. Если он имеет значение FALSE и отношение, заданное параметром relationship_code, является транзитивным, то возвращаются также потомки или предшественники этого понятия;
• designationLanguage_code - код языка, который должен был использоваться для возвращаемых обозначений понятий;
• timeout - время в миллисекундах, в течение которого клиент готов ждать завершения операции. Значение 0 параметра timeout указывает, что на время ее выполнения ограничения не накладываются;
• sizeLimit - максимальное число элементов, которое служба может вернуть. Если число возвращенных элементов совпадает с sizeLimit, то клиент предполагает, что существуют дополнительные элементы, которые не были возвращены. Значение 0 параметра sizeLimit указывает, что число элементов, которые могут быть возвращены, не ограничивается.

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

Параметры designationLanguage_code и usageContext_code используются при определении того, какое именно обозначение должно быть возвращено в структуре с типом данных RelatedCode. Для определения подходящего обозначения используются те же правила, что и в методе lookupDesignation, только данный метод не генерирует исключение NoApplicableDesignationFound. Если у конкретного узла нет подходящих обозначений, то поле обозначения должно содержать пустую строку.

Исключения:

• UnknownCodeSystem;
• UnknownConceptCode;
• UnknownRelationshipCode;
• UnknownLanguageCode;
• TimeoutError;
• UnexpectedError.

10.4.7.2.1 Детальные сведения о методе lookupCodeExpansion

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

Рисунок 7 - Пример графа отношений для демонстрации применения метода lookupCodeExpansion

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

Таблица 23

Результат вызова метода lookupCodeExpansion с параметрами lookupCodeExpansion (expandConcept_id=D, sourceToTarget=TRUE, directRelationsOnly=TRUE)

Таблица 24

Результат вызова метода lookupCodeExpaionsion (expandConcept_id=D, sourceToTarget=TRUE, directRelationsOnly=FALSE)

Примечание - В таблице 24 узел 2 K возвращен как раскрываемый, поскольку был обнаружен цикл.

Таблица 25

Результат вызова метода lookupCodeExpansion (expandConcept_id=D, sourceToTarget=FALSE, directRelationsOnly=FALSE)

Таблица 26

Результат вызова метода lookupCodeExpansion (expandConcept_id=, sourceToTarget=TRUE, directRelationsOnly=TRUE)

Таблица 27

Результат вызова метода lookupCodeExpansion (expandConcept_id=, sourceToTarget=TRUE, directRelationsOnly=FALSE)

Таблица 28

Результат вызова метода lookupCodeExpansion (expandConcept_id=, sourceToTarget=FALSE, directRelationsOnly=FALSE)

Таблица 29

Результат вызова метода lookupCodeExpansion (expandConcept_id=L, sourceToTarget=TRUE, directRelationsOnly=FALSE)

10.4.8 Дальнейшее раскрытие возвращенного узла

Метод expandCodeExpansionContext обеспечивает дальнейшее раскрытие элемента списка RelatedCodeList, возвращенного предшествующим вызовом метода lookupCodeExpansion или expandCodeExpansionContext.

Входные параметры:

• contextToExpand - непрозрачный идентификатор, возвращенный в поле expansionContext элемента списка RelatedCodeList, возвращенного предшествующим вызовом метода lookupCodeExpansion или expandCodeExpansionContext.

Исключения:

• InvalidExpansionContext.

Примечание - Контексты раскрытия не обязательно постоянны. Обеспечение действительности контекста раскрытия в определенном интервале времени является функцией конкретной реализации службы;

• NoApplicableDesignationFound;
• TimeoutError;
• UnexpectedError.

10.4.8.1 Детальные сведения о методе expandCodeExpansionContext

В таблицах 30 - 32 показаны сведения, возвращаемые методом expandCodeExpansionContext при использовании информации, описанной в 10.4.7 "Возвращение списка связанных кодов понятий".

Таблица 30

Результат вызова метода expandCodeExpansionContext (expandContext=ecE) для раскрытия контекста, возвращенного в примере, показанном в таблице 23

Примечание - Длина пути продолжает ту, что была получена при предшествующем вызове.

Таблица 31

Результат вызова метода expandCodeExpansionContext (expandContext=ecG) для раскрытия контекста, возвращенного в примере, показанном в таблице 30

Таблица 32

Результат вызова метода expandCodeExpansionContext (expandContext=ecG) для раскрытия контекста, возвращенного в примере, показанном в таблице 31

11 Модель отображения кодов

11.1 Введение

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

Рисунок 8 - Модель отображения кодов в ОТС

11.2 Отображение кодов

11.2.1 Класс CodeMap

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

Класс CodeMap "\text{содержит}" один или несколько экземпляров класса MapEntry. В настоящем стандарте представление этого отображения является чисто символическим и не предназначено для описания способов реального отображения кодов.

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

11.3 Класс MapEntry

Класс TranslationEntry представляет трансляцию кода понятия fromCode из системы кодирования-источника в соответствующий код понятия toCode, принадлежащий целевой системе кодирования. Поле mapQuality_code задает "качество" трансляции исходного кода в целевой и может принимать одно из значений "точная", "уже", "шире" или "частичное перекрытие".

12 Спецификация отображения кодов

12.1 Введение

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

12.2 Идентификация службы отображения

Служба отображения наследует общий интерфейс идентификации.

12.3 Отображение кода

12.3.1 Класс CodeMap

Класс CodeMap описывает идентификацию конкретного отображения. Он имеет следующие поля:

• map_name - уникальное имя конкретного отображения;
• fromCodeSystem_id - идентификатор ИСО ОИД системы кодирования-источника;
• fromCodeSystem_name - имя системы кодирования-источника;
• fromCodeSystem_version - версия системы кодирования-источника, используемая при отображении (необязательная);
• toCodeSystem_id - идентификатор ИСО ОИД целевой системы кодирования;
• toCodeSystem_name - имя целевой системы кодирования;
• toCodeSystem_version - версия целевой системы кодирования, используемая при отображении (необязательная);
• description - описание отображения (источник, версия, дата, местонахождение и т.д.).

12.3.2 Метод getSupportedMaps

Метод getSupportedMaps возвращает список отображений кодов, поддерживаемых данной конкретной службой. Отображения кодов не симметричны. Из того факта, что служба поддерживает отображение из системы кодирования A в систему кодирования B, не следует, что она также поддерживает отображение в обратном направлении.

12.4 Исключения

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

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

Исключения, генерируемые при отображении кодов:

• служба не поддерживает трансляцию системы кодирования с идентификатором fromCodeSystem_id в систему кодирования с идентификатором toCodeSystem_id;
• служба не в состоянии выполнить требуемое отображение;
• заданное имя отображения не распознано службой;
• между заданной системой кодирования-источника и целевой системой кодирования существует несколько возможных отображений. В параметре possible_maps передается список имен этих отображений;
• идентификатор системы кодирования, указанный в параметре fromConcept_id, не совпадает с идентификатором системы кодирования, указанным в отображении с именем, переданным в параметре map_name;
• идентификатор системы кодирования, указанный в параметре toCodeSystem_id, не совпадает с идентификатором системы кодирования, указанным в отображении с именем, переданным в параметре map_name.

12.5 Отображение кода понятия

12.5.1 Структура выходных данных метода mapConceptCode

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

• mappedConcept_id - идентификатор системы кодирования и код понятия;
• mapQuality_code - код, характеризующий "качество" операции отображения, например, "точное", "шире", "уже" и т.д.

12.5.2 Метод mapConceptCode

Метод mapConceptCode отображает заданный код понятия, принадлежащий заданной системе кодирования, в соответствующий код целевой системы кодирования (если таковой имеется). Параметру fromConcept_id должно быть присвоено значение. Если указано только имя отображения map_name, то значение параметра toCodeSystem_id выводится из полей этого отображений. Если оба эти параметра имеют значения, то они должны быть согласованными.

Входные параметры:

• fromConcept_id - имя системы кодирования и код отображаемого понятия;
• toCodeSystem_id - идентификатор целевой системы кодирования;
• map_name - имя используемого отображения.

Исключения:

• UnknownCodeSystem;
• UnknownConceptCode;
• MappingNotAvailable;
• UnknownMapName;
• AmbiguousMapRequest;
• MapNameSourceMismatch;
• MapNameTargetMismatch;
• UnableToMap;
• UnexpectedError.

13 Привязка ОТС к языкам программирования

13.1 Преобразование спецификации на языке IDL в программный код на языке Java

Спецификация интерфейсов ОТС написана на языке определения интерфейсов IDL (interface definition language), описанном в ИСО/МЭК 14750:1999 - Open Distributed Processing - Interface Definition Language (IDL) (Информационные технологии. Открытая распределенная обработка. Определение интерфейсов. Язык). Организация Object Management Group (OMG) описала отображение языка IDL на многие широко распространенные языки программирования, включая ADA, C, C++, COBOL, Java, Lisp, PL/1, Python и Smalltalk. Существует также привязка языка IDL к объектной модели Microsoft Common Object Model (COM).

К сожалению, эти отображения на языки программирования частично зависят от архитектуры CORBA (Common Object Request Broker Architecture - общая архитектура брокера объектных запросов). Например, отображение на язык программирования Java имеет следующие особенности:

• классы исключений расширяют объект org.omg.CORBA.UserException и вызывают его как суперкласс с аргументом [class]Helper.id();
• классы Struct реализуют интерфейс org.omg.CORBA.portable.IDLEntity;
• классы интерфейсов именуются [class]Operations.java;
• создаются многие дополнительные вспомогательные файлы [class]Holder.java, [class]Helper.java, _[class]Stub.java, [class]POA.java, [class]POATie.java.

Однако не очень сложно удалить эти пережитки платформы CORBA и тем самым получить спецификацию интерфейса, нейтральную по отношению к реализации.

Для перехода от языка IDL к целевым языкам SOAP и Java используются следующие шаги:

1. Преобразовать IDL в Java:

java com.sun.tools.corba.se.idl.toJavaPortable.Compile -fallTIE -pkgPrefix types org.hl7 -pkgPrefix CTSMAPI org.hl7 -pkgPrefix CTSVAPI org.hl7 CTSVAPI.idl

2. Удалить базовые интерфейсные файлы - те, у которых есть соответствующие файлы "xxxOperations.java". Например, файл "Browser.java" удаляется, поскольку существует соответствующий ему файл "BrowserOperations.java".

3. Удалить все выходные файлы, имена которых заканчиваются на "Holder.java", "Helper.java", "Stub.java", "POA.java" and "POATie.java".

4. Заменить "extends org.omg.CORBA.UserException" на "extends java.lang.Exception" и удалить все вызовы с ключевым словом "super" из конструкторов класса исключений.

5. Изменить обозначения комментариев с "/*" на "/**", чтобы они включались в документацию, создаваемую с помощью утилиты javadoc.

Ссылки на класс org.omg.CORBA.portable.IDLEntity не удаляются, поскольку они указывают на пустой класс, который тем не менее может быть полезен для различения разных типов.

Ниже показаны примеры этих преобразований:

Примеры

1 Объявление структуры на языке IDL.

2 Объявление структуры на языке Java.

3 Объявление исключения на языке IDL.

4 Объявление исключения на языке Java

5 Объявление интерфейса на языке IDL.

6 Объявление интерфейса на языке Java.

13.2 Преобразование спецификации на языке IDL в описание на языке WSDL

Для преобразования объявлений на языке Java в описание на языке WSDL используется компилятор Apache Axis 1.1 java2wsdl. Ниже приведен пример его вызова для преобразования CTSVAPI:

java org.apache.axis.wsdl.Java2WSDL -n urn://HL7.org/CTSVAPI -i

org.hl7.refImpl.CTSVAPI -lhttp://localhost:8080/axis/services/CTSVAPIService

org.hl7.CTSVAPI

Пример - Объявления интерфейса на языке WSDL:

14 Сводные требования к службам

14.1 Введение

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

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

14.2 Информационные службы сервера

14.2.1 Введение

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

14.2.2 Предоставление информации о версии сервера и его возможностях

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

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

14.2.3 Предоставление информации о терминологиях, доступных с помощью сервера

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

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

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

14.3 Службы, предоставляющие метаданные терминологий

14.3.1 Введение

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

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

14.3.2 Получение информации о терминологии, доступной с помощью сервера

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

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

14.3.3 Получение детальных сведений о свойствах понятий или терминов, содержащихся в данной терминологии

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

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

14.3.4 Получение сведений о типах отношений, используемых в данной терминологии

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

Некоторые терминологии поддерживают разнообразные типы отношений между терминами и/или понятиями. Например:

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

14.3.5 Получение сведений о критериях поиска, поддерживаемых данной терминологией

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

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

14.4 Службы, предоставляющие доступ к содержанию терминологии

14.4.1 Введение

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

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

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

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

14.4.2 Получение свойств понятия или термина

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

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

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

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

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

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

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

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

14.4.3.1 Общий вариант использования

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

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

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

14.4.3.2 Критерии текстового поиска

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

Совпадение с фразой:

• полное совпадение с фразой - полное словесное совпадение фразы и термина;
• совпадение фразы с началом термина - совпадение фразы с началом термина;
• совпадение фразы с термином - совпадение фразы с какой-либо частью термина.

Совпадение со словом:

• полное совпадение со словом - сравниваемое слово является частью термина;
• совпадение слова с началом слова в термине - слово (или его часть) совпадает с началом слова в термине;
• совпадение слова, дополненное шаблоном - совпадение с шаблоном проверяется только в контексте слова;
• совпадение словоформ (например, «туберкулез» и «туберкулезный»).

Совпадение с несколькими словами:

• применение одного из критерия совпадения со словом к каждому слову.

Вариации совпадения с несколькими словами:

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

Совпадение с шаблоном:

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

Модификации, применимые к большинству типов текстового поиска:

• поиск, зависящий/не зависящий от регистра;
• обработка диакритических и специальных знаков;
• определение разрывов слова при поиске по словам;
• фонетический поиск;
• совпадение слов/фраз/сокращений с аналогичным значением (например, «ренальный» и «почечный», «ИМ» и «инфаркт миокарда»).

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

14.4.3.3 Дополнительные критерии, модифицирующие текстовый поиск

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

Критерии статуса

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

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

Критерии словарного домена

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

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

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

Критерии отношений

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

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

14.4.4 Получение совокупности понятий или терминов, заданной отношениями

14.4.4.1 Получение всех отношений заданного понятия или термина

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

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

14.4.4.2 Получение типов отношений, применяемых к идентифицированному понятию или термину

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

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

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

14.4.4.3 Получение понятий/терминов, имеющих заданный тип отношения с понятием/термином

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

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

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

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

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

14.4.5 Получение всех понятий или терминов, принадлежащих заданному словарному домену

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

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

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

14.4.6 Проверка уникального идентификатора

14.4.6.1 Проверка действительности уникального идентификатора в терминологии

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

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

14.4.6.2 Дополнительные критерии, применимые при проверке идентификаторов

Критерии статуса

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

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

Критерии словарного домена

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

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

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

Критерии отношений

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

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

14.4.7 Отображение и преобразование кодов и кодовых фраз

14.4.7.1 Получение идентификатора с тем самым значением в другой терминологии

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

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

14.4.7.2 Декомпозиция понятия в посткоординируемое выражение

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

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

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

14.4.7.3 Преобразование посткоординированного выражения в прекоординированное понятие

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

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

15 Системы кодирования, используемые в API ОТС

В таблицах 33 и 34 приведены системы кодирования, используемые в API ОТС.

Таблица 33

Перечень систем кодирования

Таблица 34

Основные коды отношений

16 Спецификация API ОТС на языке IDL

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

Ниже приведено определение на языке IDL базовых типов данных HL7, используемых в ОТС.

/* Исходный файл: types.idl */

#ifndef _types_IDL #define _types_IDL

/*

• Определение на языке IDL подмножества типов данных HL7 Версии 3.

• Версия: V3 Ballot Cycle 5

• В настоящее время этот модуль специально предназначен для

• использования в API Централизованных терминологических служб,

• хотя это формальное отображение спецификации типов

• может найти более широкое применение.

• Примечание - Некоторые целевые языки не чувствительны к регистру.

• Как следствие, язык IDL не позволяет записывать несколько представлений

• одного и того же имени в разных регистрах. Чтобы максимально следовать

• этому правилу, к именам в нижнем регистре, конфликтующим с именами в

• верхнем регистре, добавляется суффикс «_value».

• Примечание - Из базовых типов данных удалены аспекты причины пустоты

• nullFlavor. */

module types {

    typedef boolean bl_value;
    struct BL {
     bl_value v;
    };

    typedef long int_value;
    struct INT {
     int_value v;
    };

    typedef string uid_value;
    struct UID {
     uid_value v;
    };
    typedef sequence <UID> LIST_UID;

    typedef string st_value;
    struct ST {
     st_value v;
    };

    typedef string ts_value;
    struct TS {
     ts_value TS;
    };

typedef sequence<octet> bin_value;

    enum cs_BinaryDataEncoding {
            B64,
            TXT
    };

    typedef string cs_value;

/* Следующий фрагмент в действительности является объединением, но для простоты вместо него дано явное представление union binary_or_text switch (cs_BinaryDataEncoding) { case B64: bin_value binaryValue; case TXT: st_value textualValue; }; */ struct binary_or_text { cs_BinaryDataEncoding itemType; bin_value binaryValue; st_value textualValue; };

/* Примечание — Неуклюжее объявление sequence позволяет компилятору выполнить рекурсию. Кратность 0..1 */ struct ED { binary_or_text this; cs_value encoding; cs_value mediaType; cs_value compression; bin_value integrityCheck; cs_value reference; cs_value ingegrityCheckAlgorithm; cs_value charset; cs_value language; sequence thumbnail; };

    struct CS {
 cs_value code;
            ED originalText;
            cs_value codingRationale;
    };


    struct CV {
            cs_value code;
            uid_value codeSystem;
            st_value codeSystemName;
            st_value codeSystemVersion;
            st_value displayName;
            ED originalText;
            CS codingRationale;
    };

    typedef sequence <CV> SET_CV;

/* Примечание — Фактически значение имеет тип данных CD, но из-за рекурсии такое объявление здесь не используется */ struct CR { CV name; CV value; BL inverted; }; typedef sequence LIST_CR;

    struct CD {
            cs_value code;
            uid_value codeSystem;
            st_value codeSystemName;
            st_value codeSystemVersion;
            st_value displayName;
            LIST_CR_qualifiers;
            ED originalText;
            sequence <CD> translation;
            CS codingRationale;
    };
    typedef sequence <CD> SET_CD;

    struct CE {
            cs_value code;
            uid_value codeSystem;
            st_value codeSystemName;
            st_value codeSystemVersion;
            st_value displayName;
            ED originalText;
            SET_CD translation;
            CS codingRationale;
    };

};

#endif

16.2 Определение API сообщений ОТС на языке IDL

Ниже приведено определение API сообщений ОТС на языке IDL (файл CTSMAPI.idl).

/* Source file: CTSMAPI.idl */

#ifndef __CTSMAPI_DEFINED #define __CTSMAPI_DEFINED

#include «types.idl»

/* API Централизованных терминологических служб на уровне сообщений

• Этот модуль определяет интерфейс между приложением, обрабатывающим

• сообщения HL7, и терминологическими службами. */

module CTSMAPI { /************************************************

• Соглашение о суффиксах:

• Xxx — суффикс типа

• _xxx — суффикс атрибута

Суффиксы

• Id — уникальный идентификатор сущности

• Name — уникальное имя

• Code — код понятия */

/************************************************

• Базовые идентификаторы сущностей * ************************************************/

/* HL7SpecBlock:basicData */

/* Спецификация идентификатора версии ОТС */ struct CTSVersionId {

    types::INT  major;
    types::INT  minor;

};

/* ИСО ОИД, уникально обозначающий систему кодирования */ typedef types::UID CodeSystemId;

/* Уникальное имя системы кодирования */ typedef types::ST CodeSystemName;

/* Код понятия, уникальный в системе кодирования */ typedef types::ST ConceptCode;

/* Уникальное имя словарного домена */ typedef types::ST VocabularyDomainName; typedef sequence VocabularyDomainNameList;

/* Идентификатор набора значений */ typedef types::UID ValueSetId;

/* Имя набора значений */ typedef types::ST ValueSetName;

/* Уникальный идентификатор понятия, состоящий из идентификатора системы кодирования и кода понятия */ struct ConceptId {

     CodeSystemId   codeSystem_id;
     ConceptCode    concept_code;

};

/* Конкретный выпуск системы кодирования */ typedef types::ST ReleaseVersionId; typedef sequence ReleaseVersionIdList;

/* Непрозрачный контекст для итерационного раскрытия кода */ typedef types::bin_value ExpansionContext;

/* HL7SpecBlockEnd */

/************************************************

•  <a id="p102535"></a>Кодированные элементы                  *
  

************************************************/

/* Идентификатор языка

• Синтаксис основан на IETF RFC 3066 — теги для идентификации языков

• Состоит из основного субтега , за которым следуют

• нуль или более вторичных субтегов

• - по возможности берется из ИСО 639 часть 1

•                   (2 символа), иначе берется трехсимвольный код
  

•                 - в этой спецификации коды "i-" и "x-" не разрешены
  

• <secondary subtag 1> — 2-8 символов

•         - двухсимвольные коды берутся из ИСО 3166 alpha-2 коды стран
  

•           коды длиной 3-8 символов берутся из регистра IANA - см.
  

• http://www.iana.org/assignments/language-tags

• <secondary subtag 2-n> — общих правил нет, некоторые субтеги

•                        зарегистрированы в IANA
  

/ / HL7SpecBlock:conceptCodes */ typedef ConceptCode LanguageCode;

/* Идентификатор отношения

• Система кодирования: отношения, определенные в стандарте HL7,

• берутся из системы кодирования ConceptCodeRelationship

• (2.16.840.1.113883.5.1088)

• Если в ней нет нужного эквивалента, можно использовать внешнюю

• систему. */ typedef ConceptCode RelationshipCode;

/* Область применения словарного домена (сфера, геополитическая единица,

• специальность и т.д.

• Система кодирования : VocabularyDomainQualifier (2.16.840.1.113883.5.147)

• (подтипы словарного домена RealmOfUse) */ typedef ConceptCode ApplicationContextCode;

/* Data type code (CD, CE, CS, etc) *Code System: DataType (2.16.840.1.113883.5.1007) */ typedef ConceptCode DataTypeCode;

/* Сила кодирования (CNE, CWE)

• Система кодирования: VocabularyDomainQualifier (2.16.840.1.113883.5.147) */ typedef ConceptCode CodingStrengthCode;

/* Тип узла набора значений (A, L, S)

• Система кодирования: ConceptGenerality (2.16.840.1.113883.5.24) */ typedef ConceptCode ValueSetNodeTypeCode;

/*

• Тип системы кодирования (E, EI, I)

• Система кодирования: CodeSystemType (2.16.840.1.113883.5.1085) */ typedef ConceptCode CodeSystemTypeCode;

/*

• Алгоритм совпадения

• Система кодирования: MatchAlgorithm (2.16.840.1.113883.5.1094) / typedef ConceptCode MatchAlgorithmCode; typedef sequence MatchAlgorithmCodeList; / HL7SpecBlockEnd */

/****************************************

• Сущности, представленные в UML-модели* ***************************************/

/* HL7SpecBlock:codeSystemDescriptor */

/* CodeSystemDescriptor — описатель системы кодирования

• codeSystem_id — ОИД системы кодирования

• codeSystem_name — мнемоническое имя системы кодирования

• copyright — авторские права на систему кодирования

• availableReleases — выпуск представленной системы кодирования */ struct CodeSystemDescriptor {

     CodeSystemId     codeSystem_id;
     CodeSystemName   codeSystem_name;
     types::ST   copyright;
     ReleaseVersionIdList     availableReleases;

}; typedef sequence CodeSystemDescriptorList;

/* HL7SpecBlockEnd */

/* HL7SpecBlock:RIMCodedAttribute */

/* RIMAttributeId — идентификатор кодированного атрибута модели RIM.

•              Для его уникальности необходимы все три элемента:
  

•  model_id              - идентификатор модели RIM
  

•  class_name            - имя класса
  

•  attribute_name        - имя атрибута в модели
  

*/ struct RIMAttributeId {

                types::ST   model_id;
                types::ST   class_name;
                types::ST   attribute_name;

    };

/* RIMCodedAttribute — кодированный атрибут модели RIM

• RIMAttribute_id — уникальный идентификатор атрибута (модель,

•                        класс, атрибут)
  

• dataType_code — специфичный тип данных атрибута (CD, CE, CS, ...)

• codingStrength_code — кодированное значение, представляющее силу кодирования атрибута (CWE и т.д.)

• vocabularyDomain_name — словарный домен атрибута (если есть) */ struct RIMCodedAttribute {

    RIMAttributeId      RIMAttribute_id;
    DataTypeCode     dataType_code;
    CodingStrengthCode  codingStrength_code;
    VocabularyDomainName      vocabularyDomain_name;

}; typedef sequence RIMCodedAttributeList;

/* HL7SpecBlockEnd */

/* HL7SpecBlock:valueSetDescriptor / / ValueSetDescriptor — описатель набора значений. Набор значений может быть

•                    уникально идентифицирован своим идентификатором
  

•                    или именем. Имена присвоены не всем наборам значений.
  

• valueSet_id — уникальный идентификатор набора значений

• valueSet_name — уникальное имя набора значений (есть не у всех

•                    наборов значений)
  

*/ struct ValueSetDescriptor {

    ValueSetId  valueSet_id;
    ValueSetName  valueSet_name;

}; typedef sequence ValueSetDescriptorList;

/* HL7SpecBlockEnd */

/* HL7SpecBlock:vocabularyDomainDescription / / VocabularyDomainValueSet — ассоциация словарного домена с набором

•                          значений в необязательном контексте
  

• definedByValueSet — идентификатор набора значений и необязательно имя,

•                          идентифицирующие словарный домен
  

• appliesIncontext — контекст, в котором применим набор значений */

   struct VocabularyDomainValueSet {
  

                ValueSetDescriptor         definedByValueSet;
                ApplicationContextCode            applicationContext_code;

    };
    typedef sequence<VocabularyDomainValueSet> VocabularyDomainValueSetList;

/* VocabularyDomainDescription — полное описание словарного домена

• для целей просмотра

• vocabularyDomain_name — уникальное имя домена

• description — описание цели и назначения домена

• restrictsDomain_name — словарный домен, являющийся суперклассом

•                            данного домена (если имеется)
  

• basisOfDomains — словарные домены, являющиеся подклассами данного домена

• (если имеется)

• constrainsAttributes — атрибуты, непосредственно ограничивающие данный

• домен

• representedByValueSets — список ссылок на наборы значений */ struct VocabularyDomainDescription {

                VocabularyDomainName            vocabularyDomain_name;
                types::ST                 description;
                VocabularyDomainName            restrictsDomain_name;
                sequence  basisOfDomains;
                sequence     constrainsAttributes;
                VocabularyDomainValueSetList    representedByValueSets;

    };

/* HL7SpecBlockEnd / / HL7SpecBlock:valueSetDescription / / ValueSetConstructor — набор значений, используемый как часть другого

•                   набора значений
  

• includeHeadCode — TRUE указывает, что головной код head_code является

•                   частью конструируемого набора значений
  

•                   FALSE указывает, что не является
  

• includedValueSet — набор значений, используемый для определения

•                   конструируемого набора
  

*/ struct ValueSetConstructor { ValueSetDescriptor includedValueSet; types::BL includeHeadCode; }; typedef sequence ValueSetConstructorList;

/* ValueSetCodeReference — ссылка на код понятия, включаемого в набор

•                      значений
  

• referenced_code — код из системы кодирования, содержащей включаемое

•                      значение
  

• includeReferencedCode — TRUE указывает, что ссылочный код является частью

•                      набора значений. FALSE указывает, что не сам
  

•                      является, а только связанные с ним понятия
  

• leafOnly — TRUE указывает, что включаются только конечные узлы (листья).

•            FALSE указывает, что промежуточные узлы тоже включаются
  

• relationship — код, идентифицирующий используемое отношение. Если указан,

•            то все потомки ссылочного кода referencedCode включаются
  

•            в набор (если не отфильтрованы ограничениями, задаваемыми
  

•            полями includeReferencedCode и leafOnly)
  

*/ struct ValueSetCodeReference {

    ConceptCode      referenced_code;
    RelationshipCode    relationship_code;
    types::BL   includeReferencedCode;
    types::BL   leafOnly;

}; typedef sequence ValueSetCodeReferenceList;

/* ValueSetDescription — описание набора значений

• idAndName — идентификатор и имя набора значений (если таковое имеется)

•  description           - описание набора значений и его применения
  

•  definingExpression    - полуформализованное выражение, определяющее
  

•                          содержание набора значений (если таковое
  

•                          имеется)
  

•  basedOnCodeSystem - идентификатор, имя и версия базовой системы
  

•                      кодирования, используемой для конструирования
  

•                      этого набора данных
  

•  allCodes          - TRUE указывает, что набор включает в себя все
  

•                      коды названной системы кодирования
  

•                      FALSE указывает, что берется избранное
  

•                      подмножество
  

*head_code — код понятия из системы кодирования, представляющий весь

•           набор значений (если таковой код имеется)
  

*/ struct ValueSetDescription { ValueSetDescriptor idAndName;

    types::ST   description;
    types::ST   definingExpression;
    CodeSystemDescriptor      basedOnCodeSystem;
    types::BL   allCodes;
    ConceptCode      head_code;

};

/* FullValueSetDescription — полное описание набора значений, используемое

•                        для просмотра
  

• description — описание набора значений

• constructedUsing — наборы значений, используемые для определения

•                данного набора
  

• usedToDefine — наборы значений, в определении которых участвует

•                данный набор
  

• referencesCodes — конкретные коды, которые включаются в данный набор

•                или исключаются из него
  

*/ struct FullValueSetDescription {

     ValueSetDescription             description;
     ValueSetConstructorList   constructedUsingValueSets;
     ValueSetDescriptorList          usedToDefine;
     ValueSetCodeReferenceList       referencesCodes;

};

/*  HL7SpecBlockEnd */

/*  HL7SpecBlock:codeSystemRegistration */

/*

• CodeSystemRegistration — регистрационная запись системы кодирования

• sponsor — член комитета HL7 или организация, выступающая спонсором

•           системы кодирования
  

• publisher — лицо или организация, публикующая систему кодирования

• versionReportingMethod — метод обновления системы кодирования

• licensingInformation — описание требуемых лицензий и способа приобретения

• inUMLS — TRUE указывает, что система кодирования включена в

•         Унифицированную систему медицинского языка UMLS
  

• systemSpecificLocatorInfo — сведения, используемые для дальнейшей

•                         идентификации системы кодирования в контексте
  

•                         издателя. Могут представлять собой номер
  

•                         таблицы, подраздела и т.д.
  

• codeSystemType_code — одно из значений E (внешняя), I (внутренняя),

•                   EI (внешняя, но управляется комитетом HL7)
  

*/ struct CodeSystemRegistration {

     types::ST   sponsor;
     types::ST   publisher;
     types::ST   versionReportingMethod;
     types::ST   licensingInformation;
     types::BL   inUMLS;
     types::ST   systemSpecificLocatorInfo;

 CodeSystemTypeCode codeSystemType_code;

};

/*

• CodeSystemInfo — полная информация о системе кодирования

• description — имя, идентификатор и поддерживаемые версии

•                  системы кодирования
  

• registrationInfo — дополнительная информация о регистрации,

•                  предоставленная комитетом HL7
  

*/

struct CodeSystemInfo {

     CodeSystemDescriptor     description;
     CodeSystemRegistration   registrationInfo;

};

/* HL7SpecBlockEnd */

/*************************************************

• <a id="p102537"></a>Конструкции, специфичные для сообщений    *
  

*************************************************/

/*  HL7SpecBlock:validateCodeBlock */

/*  ValidationDetail - сведения об ошибке проверки кода

• codeInError — часть кодированного атрибута, в которой обнаружена ошибка

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

•   isError          - TRUE указывает, что эта ошибка считается достаточно
  

•                      существенной, чтобы признать сообщение, содержащее
  

•                      этот атрибут, неправильным
  

•                      FALSE указывает, что ошибка не является фатальной,
  

•                      но представляет потенциальную угрозу для построения
  

•                      сообщения
  

•   error_id         - уникальный идентификатор ошибки
  

•   errorText        - текст, ассоциированный с идентификатором ошибки
  

*/ struct ValidationDetail { types::CD codeInError; types::BL isError; types::ST error_id; types::ST errorText; };

     typedef sequence<ValidationDetail> ValidationDetailList;

/* ValidateCodeReturn — структура возвращаемого значения

• nErrors — число обнаруженных ошибок

• nWarnings — число обнаруженных предупреждений

• detail — список отдельных ошибок и/или предупреждений */ struct ValidateCodeReturn { types::INT nErrors; types::INT nWarnings; ValidationDetailList detail; };

/*  HL7SpecBlockEnd */

/*  HL7SpecBlock:valueSetExpansion */
/*  ValueSetExpansion    - раскрытие набора значений в режиме реального времени

•   pathLength      - целое значение, определяющее расстояние от
  

•                     корневого набора значений
  

• nodeType_code — тип узла набора значений (A, L или S)

•   valueSet - идентификатор и имя (если оно имеется) набора значений,
  

•              ассоциированного с данным узлом
  

•   concept_id        - система кодирования и код понятия, используемые
  

•                       для этого узла (если имеются)
  

•   displayName       - текст, ассоциированный с записью (если имеется)
  

•   isExpandable      - TRUE, если этот узел можно раскрыть дальше
  

•   expansionContext  - (непрозрачный) контекст, используемый для
  

•                       дальнейшего раскрытия, если параметр isExpandable
  

•                       имеет значение TRUE
  

*/ struct ValueSetExpansion {

                 types::INT          pathLength;
                 ValueSetNodeTypeCode      nodeType_code;
                 ValueSetDescriptor  valueSet;
                 ConceptId           concept_id;
                 types::ST           displayName;
                 types::BL           isExpandable;
                 ExpansionContext    expansionContext;

     };
     typedef sequence<ValueSetExpansion> ValueSetExpansionList;

/* HL7SpecBlockEnd */

/**********************************************************************

•    <a id="p102538"></a>Исключения                                                   *
  

**********************************************************************/ / HL7SpecBlock:exceptions */

/*

• Не специфичная ошибка, воспрепятствовавшая успешному завершению вызова */ exception UnexpectedError { types::ST possible_cause; };

/*

• Имя словарного домена не распознано службой

• vocabularyDomain_name — переданное имя, которое не распознано */ exception UnknownVocabularyDomain { VocabularyDomainName vocabularyDomain_name; };

/*

• Код контекста не распознан службой

• context_code — не распознанный код */ exception UnknownApplicationContextCode { ApplicationContextCode applicationContext_code; };

/*

• Переданная идентификация набора значений не распознана

• valueSet — идентификатор и/или имя набора значений */ exception UnknownValueSet { ValueSetDescriptor valueSet; };

/*

• В запросе переданы и имя, и идентификатор набора значений, но имя

• не соответствует идентификатору

*/ exception ValueSetNameIdMismatch {

         ValueSetId   valueSet_id;
         ValueSetName   valueSet_name;

    };

exception UnknownConceptCode { ConceptId concept_id; };

exception SubsumptionNotSupported { CodeSystemId codeSystem_id; };

exception UnrecognizedQualifier { types::CR qualifier; };

exception UnableToTranslate { };

exception UnknownCodeSystem { CodeSystemId codeSystem_id; };

exception UnknownLanguage { LanguageCode language_code; };

exception InvalidExpansionContext { };

exception QualifiersNotSupported { };

exception NoApplicableValueSet {

    VocabularyDomainName     vocabularyDomain_name;
    ApplicationContextCode   applicationContext_code;

};

exception CodeSystemNameIdMismatch {

    CodeSystemId     codeSystem_id;
    CodeSystemName   codeSystem_name;

};

/*

• Время выполнения операции превысило заданный лимит */ exception TimeoutError { };

/*

• Формат искомого образца не может быть разобран */ exception BadlyFormedMatchText { types::ST matchText; };

/*

• Код алгоритма совпадения не поддерживается службой */ exception UnknownMatchAlgorithm { MatchAlgorithmCode matchAlgorithm_code; };

/*

• Для заданного кода и критериев языка не может быть найдено

• подходящее обозначение */ exception NoApplicableDesignationFound { types::CD codeToFillIn; types::ST displayLanguage_code; };

/* HL7SpecBlockEnd */

/***********************************

• Раздел модуля идентификации * **********************************/ / HL7SpecBlock:identification */

interface Identification { types::ST getServiceName() raises (UnexpectedError); types::ST getServiceVersion() raises (UnexpectedError); types::ST getServiceDescription() raises (UnexpectedError); types::ST getHL7ReleaseVersion() raises (UnexpectedError); CTSVersionId getCTSVersion() raises (UnexpectedError); };

/* HL7SpecBlockEnd */

/**********************************

• API времени исполнения * *********************************/ / HL7SpecBlock:runtime */

  interface Runtime : Identification {
  

/* getSupportedMatchAlgorithms — возвратить список поддерживаемых алгоритмов

• совпадения */

  MatchAlgorithmCodeList getSupportedMatchAlgorithms() raises (UnexpectedError);

/* getSupportedVocabularyDomains — возвратить список словарных доменов,

•                             известных модулю времени исполнения
  

• matchText — искомый образец. Формат зависит от алгоритма совпадения.

•            Пустая строка означает возвращение всех имен
  

• matchAlgorithm_code — код алгоритма совпадения.

• timeout — время ожидания завершения операции в миллисекундах

•            (0 - не ограничено)
  

• sizeLimit — максимальное число возвращаемых элементов

•            (0 - не ограничено)
  

• Возвращаемое значение — список словарных доменов

• Примечание — Если указан параметр sizeLimit и число записей в возвращенном

• списке совпадает с его значением, то клиент должен предполагать, что

• список не полон.

• Исключения

• TimeoutError — превышен лимит времени

• BadlyFormedMatchText — искомый образец не может быть разобран для

•                          заданного алгоритма
  

• UnknownMatchAlgorithm — алгоритм совпадения не распознан службой */ VocabularyDomainNameList getSupportedVocabularyDomains(

       in types::ST     matchText,
       in MatchAlgorithmCode  matchAlgorithm_code,
       in long     timeout,
            in long     sizeLimit

        )
        raises (BadlyFormedMatchText,
         UnknownMatchAlgorithm,
         TimeoutError,
         UnexpectedError
        );

/* HL7SpecBlockEndElipsis / / HL7SpecBlock:validateCode */

/* validateCode — проверить значение элемента с типом данных CD на

•            соответствие заданному словарному домену
  

• vocabularyDomain_name — словарный домен атрибута

• codeToValidate — проверяемый код

• applicationContext_code — прикладной контекст (не обязателен)

• activeConceptsOnly — TRUE указывает, что код должен быть активным

•                        в целевой системе кодирования
  

•                        FALSE указывает, что неактивные коды также
  

•                        учитываются (Примечание - Если код неактивен,
  

•                        то в этом случае должно генерироваться
  

•                        предупреждение)
  

• errorCheckOnly       - TRUE указывает ограниченную проверку (только
  

•                        на ошибки)
  

•                        FALSE указывает расширенную проверку (на
  

•                        ошибки и предупреждения)
  

• Возвращаемое значение — структура, содержащая счетчик ошибок nErrors,

•                        счетчик предупреждений nWarnings, за которыми
  

•                        следует детальная информация
  

• Примечание — Этот метод обеспечивает проверку текущего кода и

•           квалификаторов. Для проверки трансляций кода используйте
  

•           метод validateTranslations
  

• Исключения:

• UnknownVocabularyDomain — словарный домен не распознан службой

• UnknownApplicationContextCode — прикладной контекст не распознан

• NoApplicableValueSet — не существует набора значений, относящегося

•                                к этому домену в данном контексте
  

*/ ValidateCodeReturn validateCode(

                        in VocabularyDomainName       vocabularyDomain_name,
                        in types::CD                  codeToValidate,
                        in ApplicationContextCode     applicationContext_code,
                        in types::BL                  activeConceptsOnly,
                        in types::BL                  errorCheckOnly

                    )
                    raises (UnknownVocabularyDomain,
                          UnexpectedError,
                          UnknownApplicationContextCode,
                          NoApplicableValueSet);

/* HL7SpecBlockEnd / / HL7SpecBlock:validateTranslation */

/* validateTranslation — проверить совокупность трансляций значения типа CD

• vocabularyDomain_name — словарный домен атрибута

•   codeToValidate          - проверяемый код
  

•   applicationContext_code - прикладной контекст (не обязателен)
  

• activeConceptsOnly — TRUE указывает, что код должен быть активным

•                         в целевой системе кодирования
  

•                         FALSE указывает, что неактивные коды также
  

•                         учитываются (Примечание - Если код неактивен,
  

•                         то в этом случае должно генерироваться
  

•                         предупреждение)
  

•  errorCheckOnly       - TRUE указывает ограниченную проверку (только
  

•                         на ошибки)
  

•                         FALSE указывает расширенную проверку (на
  

•                         ошибки и предупреждения)
  

• Возвращаемое значение - структура, содержащая счетчик ошибок nErrors,
  

•                         счетчик предупреждений nWarnings, за которыми
  

•                         следует детальная информация
  

• Исключения:

• UnknownVocabularyDomain — словарный домен не распознан службой

• UnknownApplicationContextCode — прикладной контекст не распознан службой */ ValidateCodeReturn validateTranslation(

                        in VocabularyDomainName       vocabularyDomain_name,
                        in types::CD                  codeToValidate,
                        in ApplicationContextCode     applicationContext_code,
                        in types::BL                  activeConceptsOnly,
                        in types::BL                  errorCheckOnly

                    )
                    raises (UnknownVocabularyDomain,
                          UnknownApplicationContextCode,
                          UnexpectedError);

/* HL7SpecBlockEnd / / HL7SpecBlock:translateCode */

/* translateCode — транслировать кодированный атрибут. Если указана целевая

• система кодирования, то переданный код транслируется в эту систему. Если

• она не указана, то код транслируется в форму, применимую в целевом

• контексте

•  vocabularyDomain_name       - словарный домен кода и трансляции
  

•  fromCode                    - транслируемый код
  

•  toCodeSystemId              - идентификатор целевой системы кодирования
  

•                                (не обязателен)
  

•  toApplicationContext_code   - контекст, идентифицирующий целевую среду
  

• Возвращаемое значение — новый элемент типа CD, содержащий трансляцию

*Исключения:

• UnknownVocabularyDomain — словарный домен не распознан службой

• UnknownCodeSystem — система кодирования в параметре fromCode или

•                        toCodeSystemId не распознана службой
  

• UnknownApplicationContextCode — прикладной контекст не распознан службой

• UnableToTranslate — трансляция не состоялась по указанной причине

*/ types::CD translateCode(

                       in VocabularyDomainName       vocabularyDomain_name,
                       in types::CD                  fromCode,
                       in CodeSystemId               toCodeSystemId,
                       in ApplicationContextCode     toApplicationContext_code

                   )
                   raises (UnknownVocabularyDomain,
                           UnknownCodeSystem,
                           UnknownApplicationContextCode,
                           UnableToTranslate,
                           UnexpectedError);

/*  HL7SpecBlockEnd */
/*  HL7SpecBlock:fillInDetails */

/* fillInDetails — заполнить необязательные поля в значении типа CD,

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

•              имя кода
  

•   codeToFillIn          - заполняемый код
  

•   displayLanguage_code  - язык, используемый для имени системы
  

•                           кодирования и обозначения кода
  

• Возвращаемое значение — код с заполненными полями

• Исключения:

• UnknownCodeSystem — часть кода, означающая систему кодирования,

•                     не распознана службой
  

• UnknownConceptCode — код понятия не действителен в заданной системе

•                     кодирования либо код не действителен
  

• UnknownLanguage — код языка не распознан

• NoApplicableDesignationFound — для заданного значения типа CD не найдено

•                            обозначение на заданном языке
  

*/ types::CD fillInDetails(

                         in types::CD                  codeToFillIn,
                         in LanguageCode         displayLanguage_code

           )
                     raises (UnknownCodeSystem,
                           UnknownConceptCode,
                             UnknownLanguage,
                             UnexpectedError,
                             NoApplicableDesignationFound);

/*  HL7SpecBlockEnd */
/*  HL7SpecBlock:subsumes */

/*  subsumes            - проверить, является первый код категорией второго

•   parentCode     - код родителя
  

•   childCode      - код потомка
  

•   Возвращаемое значение  - TRUE, если первый код является родительским
  

•                            для второго
  

•                          - FALSE, если не является
  

• Примечания

• 1 Трансляции игнорируются этим методом

• 2 Если оба кода эквивалентны, метод возвращает значение TRUE

• 3 Если один из кодов или оба кода являются исключениями из

•  кодирования (CWE) и при этом не эквивалентны, то метод
  

•  возвращает значение FALSE
  

• Исключения:

• UnknownCodeSystem — система кодирования родителя или потомка не распознана

• UnknownConceptCode — код parentCode или childCode не распознан службой

• SubsumptionNotSupported — проверка родительского отношения не

•                       поддерживается службой или системой кодирования
  

• UnrecognizedQualifier — один из квалификаторов понятия не распознан

•                       службой
  

• QualifiersNotSupported — квалифицированные понятия не поддерживаются

•                       службой
  

*/ types::BL subsumes(

                          in types::CD  parentCode,
                          in types::CD  childCode

                      )
                      raises (UnknownCodeSystem,
                            UnknownConceptCode,
                              SubsumptionNotSupported,
                              UnrecognizedQualifier,
                              QualifiersNotSupported,
                              UnexpectedError);

/*  HL7SpecBlockEnd */
/*  HL7SpecBlock:areEquivalent */


/*  areEquivalent  - определить, являются ли два кода эквивалентными

• code1 — первый код

• code2 — второй код

• Возвращаемое значение — TRUE, если определено, что коды эквивалентны,

•                       FALSE в противном случае
  

• Исключения:

• UnknownCodeSystem — система кодирования кодов code1 или code2 не

•                           распознана службой
  

• UnknownConceptCode — код code1 или code2 не распознан службой

• SubsumptionNotSupported — проверка родительского отношения не

•                           поддерживается службой или системой кодирования
  

• UnrecognizedQualifier — один из квалификаторов понятия не распознан

•                           службой
  

• QualifiersNotSupported — квалифицированные понятия не поддерживаются

•                           службой
  

*/ types::BL areEquivalent (

       in types::CD   code1,
       in types::CD   code2

   )
                     raises (UnknownCodeSystem,
                           UnknownConceptCode,
                             SubsumptionNotSupported,
                             UnrecognizedQualifier,
                             QualifiersNotSupported,
                             UnexpectedError);

/*  HL7SpecBlockEnd */
/*  HL7SpecBlock:lookupValueSetExpansion */

/*  ValueSetExpansionList - возвратить иерархический список значений,

•                     допустимых для заданного словарного домена и
  

•                     контекста
  

•   vocabularyDomain_name   - раскрываемый словарный домен
  

•   applicationContext_code - контекст, используемый для выборки
  

•                             набора значений (не обязателен)
  

•   language_code        - язык, используемый для визуализации списка
  

•   expandAll        - TRUE указывает, что все узлы раскрываются
  

•                      на полную глубину, FALSE - на один уровень
  

• timeout — время ожидания завершения операции в миллисекундах

•            (0 - не ограничено)
  

• sizeLimit — максимальное число возвращаемых элементов

•            (0 - не ограничено)
  

•   Возвращаемое значение   - список допустимых кодов
  

• Примечание — Если указан параметр sizeLimit и число записей в возвращенном

• списке совпадает с его значением, то клиент должен предполагать, что

• список не полон

• Исключения

• UnknownVocabularyDomain — домен не распознан службой

• UnknownApplicationContextCode — прикладной контекст не распознан службой

• UnknownLanguage — код языка не распознан службой

• NoApplicableValueSet — не существует набора значений, относящегося

•                      к этому домену в данном контексте
  

• TimeoutError — превышен лимит времени */

         ValueSetExpansionList lookupValueSetExpansion(
  

                        in VocabularyDomainName       vocabularyDomain_name,
                        in ApplicationContextCode     applicationContex_code,
                        in LanguageCode               language_code,
                        in types::BL                  expandAll,
                        in long                 timeout,
                        in long                       sizeLimit

                    )
                    raises (UnknownVocabularyDomain,
                          UnknownApplicationContextCode,
                            UnknownLanguage,
                            NoApplicableValueSet,
                            TimeoutError,
                            UnexpectedError);

/* HL7SpecBlockEnd / / HL7SpecBlock:expandValueSetExpansionContext */

/* expandValueSetExpansionContext — раскрыть узел, который не до конца

•                              раскрыт предыдущим вызовом описанного
  

•                              выше метода lookupValueSetExpansion
  

• expandContext — начальный контекст, используемый для раскрытия

• Возвращаемое значение — список допустимых кодов для данного контекста

*/ ValueSetExpansionList expandValueSetExpansionContext( in ExpansionContext expansionContext ) raises (InvalidExpansionContext, TimeoutError, UnexpectedError);

/* HL7SpecBlockEnd */ };

/**********************************

• <a id="p102541"></a>API обозревателя           *
  

*********************************/ / HL7SpecBlock:browser */

    interface Browser : Identification {

/* HL7SpecBlockEndElipsis / / HL7SpecBlock:browserDescription */

/* getSupportedMatchAlgorithms — возвратить список поддерживаемых алгоритмов

• совпадения */ MatchAlgorithmCodeList getSupportedMatchAlgorithms() raises (UnexpectedError);

/* getSupportedAttributes — возвратить кодированные атрибуты, известные

•                      обозревателю, чьи имена соответствуют заданным
  

•                      критериям
  

• matchText — искомый образец. Формат зависит от алгоритма

•                    совпадения. Пустая строка означает возвращение
  

•                    всех имен
  

• matchAlgorithm_code — код алгоритма совпадения

• timeout — время ожидания завершения операции в миллисекундах

•                    (0 - не ограничено)
  

• sizeLimit — максимальное число возвращаемых элементов

•                    (0 - не ограничено)
  

• Возвращаемое значение — список кодированных атрибутов

• Примечание — Если указан параметр и число записей в возвращенном

• списке совпадает с его значением, то клиент должен предполагать, что

• список не полон

• Исключения:

• TimeoutError — превышен лимит времени

• BadlyFormedMatchText — искомый образец не может быть разобран

•                     указанным алгоритмом
  

• UnknownMatchAlgorithm — алгоритм совпадения не распознан службой */

         RIMCodedAttributeList      getSupportedAttributes(
           in types::ST      matchText,

   in MatchAlgorithmCode matchAlgorithm_code,

           in long      timeout,
            in long     sizeLimit

        )
        raises (BadlyFormedMatchText,
                UnknownMatchAlgorithm,
                TimeoutError,
                UnexpectedError);

/* getSupportedVocabularyDomains — возвратить словарные домены, известные

•                             обозревателю, чьи имена соответствуют
  

•                             заданным критериям
  

• matchText — искомый образец. Формат зависит от алгоритма

•                    совпадения. Пустая строка означает возвращение
  

•                    всех имен
  

• matchAlgorithm code — код алгоритма совпадения

• timeout — время ожидания завершения операции в миллисекундах

•                    (0 - не ограничено)
  

• sizeLimit — максимальное число возвращаемых элементов

•                    (0 - не ограничено)
  

• Возвращаемое значение — список словарных доменов

• Примечание — Если указан параметр sizeLimit и число записей в возвращенном

• списке совпадает с его значением, то клиент должен предполагать, что

• список не полон

• Исключения:

• TimeoutError — превышен лимит времени

• BadlyFormedMatchText — искомый образец не может быть разобран

•                      указанным алгоритмом
  

• UnknownMatchAlgorithm — алгоритм совпадения не распознан службой */ VocabularyDomainNameList getSupportedVocabularyDomains(

      in types::ST     matchText,
      in MatchAlgorithmCode  matchAlgorithm_code,
           in long     timeout,
            in long    sizeLimit

        )
        raises (BadlyFormedMatchText,
                UnknownMatchAlgorithm,
                TimeoutError,
                UnexpectedError);

/* getSupportedValueSets — возвратить список наборов значений, известных

•                     обозревателю, чьи имена совпадают с переданным
  

•                     искомым образцом
  

• matchText — искомый образец. Формат зависит от алгоритма

•                     совпадения. Пустая строка означает возвращение
  

•                     всех имен
  

• matchAlgorithm_code — код алгоритма совпадения

• timeout — время ожидания завершения операции в миллисекундах

•                     (0 - не ограничено)
  

• sizeLimit — максимальное число возвращаемых элементов

•                     (0 - не ограничено)
  

• Возвращаемое значение — список наборов значений

• Примечание — Если указан параметр sizeLimit и число записей в возвращенном

• списке совпадает с его значением, то клиент должен предполагать, что

• список не полон

• Исключения:

• TimeoutError — превышен лимит времени

• BadlyFormedMatchText — искомый образец не может быть разобран

•                      указанным алгоритмом
  

• UnknownMatchAlgorithm — алгоритм совпадения не распознан службой */

    ValueSetDescriptorList   getSupportedValueSets(
      in types::ST     matchText,
      in MatchAlgorithmCode  matchAlgorithm_code,
           in long     timeout,
            in long    sizeLimit

        )
        raises (BadlyFormedMatchText,
         UnknownMatchAlgorithm,
         TimeoutError,
               UnexpectedError);

/* getSupportedCodeSystems — возвратить список систем кодирования, известных

•                       обозревателю, чьи имена совпадают с заданными
  

•                       критериями
  

• matchText — искомый образец. Формат зависит от алгоритма

•                     совпадения. Пустая строка означает возвращение
  

•                     всех имен
  

• matchAlgorithm code — код алгоритма совпадения

• timeout — время ожидания завершения операции в миллисекундах

•                     (0 - не ограничено)
  

• sizeLimit — максимальное число возвращаемых элементов

•                     (0 - не ограничено)
  

•  Возвращаемое значение     - список систем кодирования
  

• Примечание — Если указан параметр sizeLimit и число записей в возвращенном

•          списке совпадает с его значением, то клиент должен
  

•          предполагать, что список не полон
  

• Исключения

• TimeoutError — превышен лимит времени

• BadlyFormedMatchText — искомый образец не может быть разобран

•                      заданным алгоритмом
  

• UnknownMatchAlgorithm — алгоритм совпадения не распознан службой */ CodeSystemDescriptorList getSupportedCodeSystems(

      in types::ST     matchText,
      in MatchAlgorithmCode  matchAlgorithm_code,
           in long     timeout,
            in long    sizeLimit

        )
        raises (BadlyFormedMatchText,
         UnknownMatchAlgorithm,
         TimeoutError,
               UnexpectedError);

/* HL7SpecBlockEnd / / HL7SpecBlock:lookupVocabularyDomain */

/* lookupVocabularyDomain — просмотреть полное описание словарного домена

• domain — идентификатор просматриваемого словарного домена

• Возвращаемое значение — полное описание словарного домена */ VocabularyDomainDescription lookupVocabularyDomain( in VocabularyDomainName vocabularyDomain_name ) raises (UnknownVocabularyDomain, UnexpectedError);

/* HL7SpecBlockEnd / / HL7SpecBlock:lookupValueSet */

/* lookupValueSet — возвратить полное описание набора значений

• valueSet — уникальный идентификатор или имя набора значений

• Возвращаемое значение — полное описание набора значений

• Исключения:

• UnknownValueSet — идентификатор набора значений задан, но не распознан

•                  службой, либо задано только имя набора значений, но
  

•                  не распознано службой, либо не заданы ни
  

•                  идентификатор, ни имя набора значений
  

• ValueSetNameIdMismatch — заданы и идентификатор набора значений, и его

•                        имя, но они не соответствуют друг другу
  

*/ FullValueSetDescription lookupValueSet(

           in ValueSetId           valueSet_id,
           in ValueSetName         valueSet_name

            )
         raises (UnknownValueSet,
           ValueSetNameIdMismatch,
           UnexpectedError);

/* HL7SpecBlockEnd / / HL7SpecBlock:lookupCodeSystem */

/* lookupCodeSystem — возвратить описание и имя системы кодирования

• codeSystem — уникальный идентификатор системы кодирования

• Возвращаемое значение — описание системы кодирования

• Исключения:

• UnknownCodeSystem — идентификатор системы кодирования задан, но не

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

•                      кодирования и не распознано службой, либо не
  

•                      заданы ни идентификатор, ни имя системы
  

•                      кодирования
  

• CodeSystemNameIdMismatch — заданы и идентификатор системы кодирования, и

•                         ее имя, но они не соответствуют друг другу
  

*/ CodeSystemInfo lookupCodeSystem (

      in CodeSystemId       codeSystem_id,
      in CodeSystemName     codeSystem_name

  )
  raises (UnknownCodeSystem,
    CodeSystemNameIdMismatch,
    UnexpectedError);

/* HL7SpecBlockEnd / / HL7SpecBlock:lookupValueSetForDomain */

/* lookupValueSetForDomain — возвратить описатель набора значений, который

•                       может использоваться для словарного домена в
  

•                       заданном контексте (если такой набор имеется)
  

• vocabularyDomain_name — имя словарного домена

• applicationContext_code — код прикладного контекста (не обязателен)

• Возвращаемое значение — идентификатор и имя (если оно имеется)

•                         набора значений, который можно использовать
  

•                         в данном контексте
  

• Исключения:

• UnknownVocabularyDomain — словарный домен не распознан службой

• UnknownApplicationContextCode — прикладной контекст не распознан

•                              службой
  

• NoApplicableValueSet — не существует набора значений,

•                              относящегося к этому домену в данном
  

•                              контексте
  

*/ ValueSetDescriptor lookupValueSetForDomain(

                        in VocabularyDomainName       vocabularyDomain_name,
       in ApplicationContextCode    applicationContext_code

                    )
                    raises (UnknownVocabularyDomain,
                          UnknownApplicationContextCode,
                          NoApplicableValueSet,
                          UnexpectedError);

/* HL7SpecBlockEnd / / HL7SpecBlock:isCodeInValueSet */

/* isCodeInValueSet — определить, входит ли данный код понятия в набор

•                значений
  

• valueSet_id — идентификатор набора значений (не обязателен, но или

•                 идентификатор, или имя набора должны быть указаны)
  

• valueSet_name — имя набора значений (не обязательное)

• includeHeadCode — TRUE указывает, что «головной код» набора

•                 значений, если таковой имеется, должен считаться
  

•                 частью набора
  

• codeToValidate — система кодирования и проверяемый код понятия

• Возвращаемое значение — TRUE, если понятие входит в набор значений

•                       FALSE, если не входит
  

• Исключения:

• UnknownValueSet — идентификатор набора значений (если указан) не

•                       распознан службой или, если идентификатор
  

•                       отсутствует, имя набора не распознано службой
  

• ValueSetNameIdMismatch — идентификатор набора значений распознан

•                       службой, но имя набора не соответствует этому
  

•                       идентификатору
  

• UnknownCodeSystem — система кодирования не распознана службой

• UnknownConceptCode — код понятия не действителен в системе

•                       кодирования
  

*/ types::BL isCodeInValueSet(

                        in ValueSetId           valueSet_id,
                        in ValueSetName         valueSet_name,
                        in types::BL            includeHeadCode,
                        in ConceptId            codeToValidate

                    )
                    raises (UnknownValueSet,
                          ValueSetNameIdMismatch,
                          UnknownConceptCode,
                          UnknownCodeSystem,
                          UnexpectedError);

/* HL7SpecBlockEnd */ };

};

#endif

16.3 Определение API словаря ОТС на языке IDL

Ниже приведено определение API словаря ОТС на языке IDL (файл CTSVAPI.idl).

/*

• Исходный файл: CTSVAPI.idl

• Версия: 1.0

• Дата: 10/31/03 */ #ifndef __CTSVAPI_DEFINED #define __CTSVAPI_DEFINED

/*

• API уровня словаря Централизованных терминологических служб

• Этот модуль определяет интерфейс между приложением, обрабатывающим

• сообщения, соответствующие стандарту HL7, и терминологическими службами */ module CTSVAPI {

/***********************************************

• Соглашения о суффиксах:

• Xxx — суффикс типа

• _xxx — суффикс атрибута

• Суффиксы

• Id — уникальный идентификатор сущности

• Name — уникальное имя

• Code — код понятия

• Version — идентификатор версии */