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

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

Группа П85

     

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

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

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

Выпуск 1

Health informatics. Common terminology services. Release 1

ОКС 35.240.80

ОКСТУ 4002

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

Предисловие

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 30 ноября 2016 г. N 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 г. N 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 СТ. Неофициально признается, что этот конкретный API сольется с ОТС или будет использовать подходящие элементы ОТС там, где это целесообразно. Реализация этого API на основе технологии СОМ обеспечивается по меньшей мере одной свободно распространяемой машиной кодирования (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)

_______________

В настоящее время действует версия 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

3.10

     4 Условные обозначения и сокращения

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

     5 Модули ОТС

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

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

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

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

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

_______________

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

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

     
Рисунок 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 и, исключая цветовое кодирование, по возможности остается совместимой с ее нотацией и типами данных. В настоящем стандарте не представлена полная или глубокая модель всех логических сущностей, образующих систему кодирования. Его основная цель - описать классы и отношения, имеющие прямое отношение к содержанию кодированных атрибутов HL7 с точки зрения метамодели.

_______________

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

Модель 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 имеет уникальное имя (атрибут vocabularvDomain_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.

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

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

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

_______________

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

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

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

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

_______________

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

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

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

- licensinglnformation - описание требуемых лицензий, цены и способа приобретения;

- inUMLS - значение TRUE указывает, что кодированные термины, определенные в этой системе кодирования, включены в Унифицированную систему медицинского языка UMLS (Unified Medical Language System);

- systemSpecificLocatorlnfo - информация, специфичная для издателя системы кодирования. Она служит для определения или идентификации конкретной системы кодирования. Комитет HL7 может иногда использовать атрибут systemSpecificLocatorlnfo для идентификации соответствующей таблицы стандарта HL7 2.x, если таковая имеется;

- codeSystemType_code - код, имеющий значения I (система кодирования является внутренней, ведется и распространяется комитетом HL7), Е (ведется и распространяется третьей стороной), 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 сообщений ОТС включают в себя:

- CTSVersionld - структура, содержащая старшую и младшую части номера версии спецификации ОТС. У текущей версии старшая часть равна 1, младшая - равна 0 (1.0);

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

- CodeSystemName - имя системы кодирования. Как идентификатор системы кодирования, так и ее имя уникальны в пространстве имен, контролируемом стандартом HL7 Версии 3, но в общем случае уникальность не гарантируется;

- ConceptCode - код, уникально представляющий класс или понятие в данной системе кодирования;

- VocabularyDomainName - уникальное имя словарного домена HL7;

- ReleaseVersionld - идентификатор, уникально обозначающий выпуск/версию в контексте системы кодирования;

- ValueSetld - объектный идентификатор ИСО (ОИД), уникально идентифицирующий набор значений HL7;

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

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

- ReleaseVersionld - уникальный идентификатор версии или выпуска одной или нескольких систем кодирования;

- 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, СЕ, CS, BIN, ST и т.д.).

- CodingStrengthCode - код, указывающий, как должны трактоваться некодированные значения атрибута, определенного в стандарте HL7 (CWE - кодированный с разрешением исключений, CNE - кодированный без исключений);

- ValueSetNodeTypeCode - код, определяющий тип набора значений, возвращаемого в виде иерархического списка. Коды имеют следующие значения: А (абстрактный) означает, что набор значений не может быть выбран; S (специализируемый) означает, что набор значений может быть выбран, но имеет дальнейшие уточнения; L (list) означает, что узел представляет выбираемый код понятия, которое не имеет дальнейших уточнений;

- CodeSystemTypeCode - код, имеющий значения I (система кодирования является внутренней, которая ведется комитетом HL7), Е (ведется третьей стороной), 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 содержит детальное описание ошибки или предупреждения. Она имеет следующие поля:

- codelnError - код понятия, с которым связана данная ошибка или предупреждение. Если ошибка обнаружена в квалификаторе понятия или в его трансляции, то этот код содержит то, в чем найдена ошибка: имя квалификатора, значение квалификатора либо значение трансляции;

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

- Unexpected Error.

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 Заполнение детальных сведений о кодируемом атрибуте

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

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

- codeToFillln - кодированный атрибут, о котором заполняются сведения;

- 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 этого узла может быть выбран, но узел может иметь дальнейшее раскрытие;

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

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

- valueSet - идентификатор и имя (если имеется) набора значений, ассоциированного с данным узлом;

- concept_id - система кодирования и код понятия, ассоциированные с данным узлом (если имеются);

- displayName - изображаемое имя, используемое для представления этого узла;

- isExpandable - значение TRUE указывает, что этот узел можно далее раскрыть с помощью функции expandValueSetExpansionContext. Поле isExpandable будет иметь значение TRUE только для специализируемых и абстрактных узлов, и то только в том случае, если в исходном вызове метода lookupValueSetExpansion параметр expandAII (раскрыть все) имел значение FALSE;

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

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

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

Таблица 14 - Значения полей класса ValueSetExpansion для варианта 1

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

Таблица 15 - Значения полей класса ValueSetExpansion для варианта 2

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

Таблица 16 - Значения полей класса ValueSetExpansion для варианта 3

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

Таблица 17 - Значения полей класса ValueSetExpansion для варианта 4

Вариант 5 (таблица 18): набор значений Е ссылается на описанный выше набор значений 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 возвращает раскрытие набора значений, ассоциированного с заданным словарным доменом и необязательным контекстом. Весь словарный домен может быть раскрыт сразу (если параметр expandAII имеет значение TRUE) или может быть раскрыт на один уровень за один раз (если параметр expandAII имеет значение FALSE). В последнем случае каждый узел может быть раскрыт далее, если у него поле isExpandable имеет значение TRUE, указывающее, что поле expansionContext может быть передано методу expandValueSetExpansionContext для дальнейшего раскрытия.

Параметры:

- vocabularyDomain_name - раскрываемый словарный домен;

- applicationContext_code - контекст, в котором должен раскрываться словарный домен (не обязателен);

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

- expandAII - значение 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

Класс RIMAttributeld уникально идентифицирует кодированный атрибут модели 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;

- ValueSetNameldMismatch;

- Unexpected Error.

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

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

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

- sponsor - член комитета HL7 или организация, выступающая спонсором регистрации системы кодирования;

- publisher - наименование официального издателя системы кодирования;

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

- licensinglnformation - описание требуемых лицензий, цены и способа приобретения;

- inUMLS - значение TRUE указывает, что кодированные термины, определенные в этой системе кодирования, включены в Унифицированную систему медицинского языка UMLS (Unified Medical Language System);

- systemSpecificLocatorlnfo - информация, специфичная для издателя системы кодирования. Она служит для определения или идентификации конкретной системы кодирования. Комитет HL7 может иногда использовать атрибут systemSpecificLocatorlnfo для идентификации соответствующей таблицы стандарта HL7 2.x, если таковая имеется;

- codeSystemType_code - код, имеющий значения I (система кодирования является внутренней, ведется и распространяется комитетом HL7), Е (ведется и распространяется третьей стороной), EI (ведется третьей стороной, но ради удобства комитет HL7 поддерживает ее внутренний образ).

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

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

- description - базовое описание системы кодирования. См. описание класса CodeSystemDescriptor в 8.4.2.1.2;

- registrationlnfo - регистрационная информация о системе кодирования (если таковая имеется).

8.4.5.2 Метод lookupCodeSystem

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

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

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

- codeSystem_name - имя системы кодирования.

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

Исключения:

- UnknownCodeSystem;

- CodeSystemNameldMismatch;

- UnexpectedError.

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

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

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

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

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

Исключения:

- UnknownVocabularyDomain;

- UnknownApplicationContextCode;

- NoApplicableValueSet;

- UnexpectedError.

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

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

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

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

- valueSet_name - имя обозреваемого набора значений;

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

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

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

Исключения:

- UnknownValueSet;

- ValueSetNameldMismatch;

- UnknownConceptCode;

- UnknownCodeSystem;

- UnexpectedError.

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

     9.1 Введение

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

_______________

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

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

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

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

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

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

- codeSystem_id - глобально уникальный идентификатор системы кодирования. В контексте стандартов HL7 он должен принимать форму объектного идентификатора ИСО (ОИД). Комитет HL7 ведет регистр идентификаторов ОИД систем кодирования, и пользователям стандарта настоятельно рекомендуется регистрировать в этом регистре все ОИД, используемые ими в этих службах;

- codeSystem_name - краткая символьная метка, уникально идентифицирующая систему кодирования в контексте модели HL7 RIM. Комитет HL7 включает имена систем кодирования в "систему кодирования систем кодирования", ассоциированную со словарным доменом CodeSystem. Атрибут codeSystem_name используется исключительно в целях коммуникации углеродных форм жизни, а при взаимодействии компьютеров должен использоваться атрибут codeSystemld;

- fullName - официальное имя системы кодирования CodeSystem. Для тех систем, что зарегистрированы в словарном домене HL7 CodeSystem, значением этого имени является предпочтительное английское обозначение ConceptDesignation кодированного понятия CodedConcept, совпадающего с атрибутом codeSystem_name системы кодирования CodeSystem;

- codeSystemDeschption - описание назначения и содержания системы кодирования 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 в каждый момент времени.

_______________

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

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

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

_______________

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

Кодированное понятие 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). He у всех свойств понятий ConceptProperty есть коды языка. Если код языка опущен, то предполагается, что характер этого свойства таков, что понятие языка к нему неприменимо;

- mimeType_code - код, взятый из системы кодирования типов среды MediaType, официально предназначенной для этих целей комитетом HL7 (в настоящее время - ОИД 2.16.840.1.113883.5.79). Не у всех свойств ConceptProperty есть код среды. По умолчанию используется тип среды text/plain (неформатированный текст).

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

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

_______________

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

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

Таблица 21 - Основные коды отношений

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

     10.1 Введение

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

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

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

- OID - объектный идентификатор ИСО (ОИД);

- Description - текстовое описание объекта или сущности. При реализации следует иметь в виду, что некоторые описания могут быть довольно длинными;

- CTSVersionld - идентификатор версии реализации Общих терминологических служб (ОТС). В версии 1.0 поле major имеет значение 1, а поле minor - значение 0;

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

- CodeSystemName - краткая мнемоника или имя системы кодирования. Как идентификатор системы кодирования, так и ее имя уникальны в пространстве имен, контролируемом стандартом HL7 Версии 3, но в общем случае уникальность не гарантируется;

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

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

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

- 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 Структура, возвращаемая методом lookupCodeSystemlnfo

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

- codeSystem - идентификатор системы кодирования, ее имя и поддерживаемая версия (версии);

- fullName - полное имя системы кодирования;

- codeSystemDescription - описание содержания системы кодирования;

- supportedLanguages - список всех языков, которые полностью или частично поддерживаются системой кодирования. "Поддерживаемый" язык распознается системой кодирования и на нем доступна хотя бы часть обозначений или свойств понятий. Все системы кодирования должны поддерживать хотя бы один язык. В то время как служба должна возвращать перечисление всех субтегов основного языка, который она поддерживает, она не обязана перечислять вторичные языки. (Например, если она поддерживает язык "en-UK", она должна возвращать тег "en", но может возвращать или не возвращать "en-UK");

- supportedRelations - список всех отношений, поддерживаемых службой в системе кодирования. "Поддерживаемое" отношение распознается системой кодирования, которая способна определить, являются ли два принадлежащих ей кода понятий связанными этим отношением. Неиерархическая система кодирования не нуждается в поддержке каких-либо отношений. Отношение подтипа представлено кодом отношения hasSubtype;

- supportedProperties - список всех свойств, поддерживаемых системой кодирования. Свойство считается "поддерживаемым", если система кодирования распознает его и по меньшей мере одно кодированное понятие ассоциировано с этим свойством и необязательным значением;

- supportedMimeTypes - список типов среды MIME, поддерживаемых системой кодирования. Все системы кодирования должны поддерживать тип среды text/plain (неформатированный текст), даже если в ней нет ни одного свойства с этим типом;

- supportedRelationshipQualifiers - список квалификаторов отношений, распознаваемых системой кодирования (если таковые имеются).

10.3.2.2 Метод lookupCodeSystemlnfo

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

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

- codeSystem_ld - идентификатор ИСО ОИД, присвоеный системе кодирования;

- codeSystem_name - уникальное имя системы кодирования.

Исключения:

- UnknownCodeSystem;

- CodeSystemNameldMismatch;

- UnexpectedError.

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

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

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

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

- match Text - искомый текст. Формат и синтаксис этого текста зависит от значения параметра 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" и признак souceТоTarget имеет значение 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 описывают отображение некоторых или всех кодов понятий из системы кодирования-источника в наиболее близкие коды понятий в целевой системе кодирования. Отображение CodeMap является однонаправленным - из наличия отображения системы кодирования-источника не вытекает возможность обратного отображения. В экземпляре класса CodeMap может быть указана необязательная идентификация версий системы кодирования-источника и целевой системы кодирования, используемых при отображении.

Класс CodeMap "содержит" один или несколько экземпляров класса 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 возвращает список отображений кодов, поддерживаемых данной конкретной службой. Отображения кодов не симметричны. Из того факта, что служба поддерживает отображение из системы кодирования А в систему кодирования В, не следует, что она также поддерживает отображение в обратном направлении.

     12.4 Исключения

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

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

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

- служба не поддерживает трансляцию системы кодирования c идeнтификaтopoм 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++, 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.lDLEntity;

- классы интерфейсов именуются [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 CTSVAPl.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.h17.reflmpl.CTSVAPI - lhttp://localhost:8080/axis/services/CTSVAPIService

org.h17.CTSVAPI

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

<?xml version="1.0" encoding="UTF-8"?>

<wsdl : definitions targetNamespace="urn: //h17 .org/CTSVAPI"

xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-

soap"

xmlns:impl="urn://h17.org/CTSVAPI"

xmlns:intf="urn://h17.org/CTSVAPI"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<wsdl:types>

<schema targetNamespace="urn://h17.org/CTSVAPI"

xmlns="http://www.w3.org/2001/XMLSchema">

<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>

<complexType name="SupportedMap">

<sequence>

<element name="map_name" nillable="true" type="xsd:string"/>

<element name="mapDescription" nillable="true" type="xsd:string"/>

<element name="fromCodeSystem_id" nillable="true" type="xsd:string"/>

<element name="fromCodeSystem_name" nillable="true" type="xsd:string"/>

<element name="fromCodeSystem_version" nillable="true" type="xsd:string"/>

<element name="toCodeSystem_id" nillable="true" type="xsd:string"/>

<element name="toCodeSystem_name" nillable="true" type="xsd:string"/>

<element name="toCodeSystem_version" nillable="true" type="xsd:string"/>

</sequence>

</complexType>

<complexType name="ArrayOfSupportedMap">

<complexContent>

<restriction base="soapenc:Array">

<attribute ref="soapenc:arrayType"

wsdl:arrayType="impl:SupportedMap[]"/>

</restriction>

</complexContent>

</complexType>

<complexType name="UnexpectedError">

<sequence>

<element name="possible_cause" nillable="true" type="xsd:string"/>

</sequence>

</complexType>

<complexType name="ConceptId">

<sequence>

<element name="codeSystem_id" nillable="true" type="xsd:string"/>

<element name="concept_code" nillable="true" type="xsd:string"/>

</sequence>

</complexType>

<complexType name="MappedConceptCode">

<sequence>

<element name="mappedConcept_id" nillable="true" type="impl:ConceptId"/>

<element name="mapQuality_code" nillable="true" type="xsd:string"/>

</sequence>

</complexType>

<complexType name="MappingNotAvailable">

<sequence>

<element name="fromCodeSystem_id" nillable="true" type="xsd:string"/>

<element name="toCodeSystem_id" nillable="true" type="xsd:string"/>

</sequence>

</complexType>

<complexType name="UnableToMap">

<sequence/>

</complexType>

<complexType name="UnknownConceptCode">

<sequence>

<element name="concept_code" nillable="true" type="xsd:string"/>

</sequence>

</complexType>

<complexType name="UnknownCodeSystem">

<sequence>

<element name="codeSystem_id" nillable="true" type="xsd:string"/>

</sequence>

</complexType>

<complexType name="UnknownMapName">

<sequence>

<element name="map_name" nillable="true"type="xsd:string"/>

</sequence>

</complexType>

<complexType name="AmbiguousMapRequest">

<sequence>

<element maxOccurs="unbounded" name="possible_maps" nillable="true" type="xsd:string"/>

</sequence>

</complexType>

<complexType name="CTSVersionId">

<sequence>

<element name="major" type="xsd:short"/>

<element name="minor" type="xsd:short"/>

</sequence>

</complexType>

</schema>

</wsdl:types>

<wsdl:message name="UnknownMapName">

<wsdl:part name="fault" type="impl:UnknownMapName"/>

</wsdl:message>

<wsdl:message name="AmbiguousMapRequest">

<wsdl:part name="fault" type="impl:AmbiguousMapRequest"/>

</wsdl:message>

<wsdl:message name="getServiceDescriptionResponse">

<wsdl:part name="getServiceDescriptionReturn" type="xsd:string"/>

</wsdl:message>

<wsdl:message name="MappingNotAvailable">

<wsdl:part name="fault" type="impl:MappingNotAvailable"/>

</wsdl:message>

<wsdl:message name="getServiceVersionRequest">

</wsdl:message>

<wsdl:message name="getSupportedMapsResponse">

<wsdl:part name="getSupportedMapsReturn" type="impl:ArrayOfSupportedMap"/>

</wsdl:message>

<wsdl:message name="UnknownConceptCode">

<wsdl:part name="fault" type="impl:UnknownConceptCode"/>

</wsdl:message>

<wsdl:message name="UnexpectedError">

<wsdl:part name="fault" type="impl:UnexpectedError"/>

</wsdl:message>

<wsdl:message name="UnknownCodeSystem">

<wsdl:part name="fault" type="impl:UnknownCodeSystem"/>

</wsdl:message>

<wsdl:message name="UnableToMap">

<wsdl:part name="fault" type="impl:UnableToMap"/>

</wsdl:message>

<wsdl:message name="getCTSVersionReguest">

</wsdl:message>

<wsdl:message name="getServiceNameResponse">

<wsdl:part name="getServiceNameReturn" type="xsd:string"/>

</wsdl:message>

<wsdl:message name="getServiceNameReguest">

</wsdl:message>

<wsdl:message name="getServiceDescriptionReguest">

</wsdl:message>

<wsdl:message name="mapConceptCodeReguest">

<wsdl:part name="fromConcept_id" type="impl:ConceptId"/>

<wsdl:part name="toCodeSystem_id" type="xsd:string"/>

<wsdl:part name="map_name" type="xsd:string"/>

</wsdl:message>

<wsdl:message name="mapConceptCodeResponse">

<wsdl:part name="mapConceptCodeReturn" type="impl:MappedConceptCode"/>

</wsdl:message>

<wsdl:message name="getSupportedMapsReguest">

</wsdl:message>

<wsdl:message name="getCTSVersionResponse">

<wsdl:part name="getCTSVersionReturn" type="impl:CTSVersionId"/>

</wsdl:message>

<wsdl:message name="getServiceVersionResponse">

<wsdl:part name="getServiceVersionReturn" type="xsd:string"/>

</wsdl:message>

<wsdl:portType name="CodeMappingOperations">

<wsdl:operation name="getSupportedMaps">

<wsdl:input message="impl:getSupportedMapsReguest"

name="getSupportedMapsRequest"/>

<wsdl:output message="impl:getSupportedMapsResponse"

name="getSupportedMapsResponse"/>

<wsdl:fault message="impl:UnexpectedError" name="UnexpectedError"/>

</wsdl:operation>

<wsdl:operation name="mapConceptCode" parameterOrder="fromConcept_id

toCodeSystem_id map_name">

<wsdl:input message="impl:mapConceptCodeRequest"

name="mapConceptCodeRequest"/>

<wsdl:output message="impl:mapConceptCodeResponse"

name="mapConceptCodeResponse"/>

<wsdl:fault message="impl:AmbiguousMapRequest" name="AmbiguousMapRequest"/>

<wsdl:fault message="impl:UnexpectedError" name="UnexpectedError"/>

<wsdl:fault message="impl:UnableToMap" name="UnableToMap"/>

<wsdl:fault message="impl:MappingNotAvailable" name="MappingNotAvailable"/>

<wsdl:fault message="impl:UnknownMapName" name="UnknownMapName"/>

<wsdl:fault message="impl:UnknownConceptCode" name="UnknownConceptCode"/>

<wsdl:fault message="impl:UnknownCodeSystem" name="UnknownCodeSystem"/>

</wsdl:operation>

<wsdl:operation name="getCTSVersion">

<wsdl:input message="impl:getCTSVersionRequest" name="getCTSVersionRequest"/>

<wsdl:output message="impl:getCTSVersionResponse" name="getCTSVersionResponse"/>

<wsdl:fault message="impl:UnexpectedError" name="UnexpectedError"/>

</wsdl:operation>

<wsdl:operation name="getServiceDescription">

<wsdl:input message="impl:getServiceDescriptionRequest"

name="getServiceDescriptionRequest"/>

<wsdl:output message="impl:getServiceDescriptionResponse"

name="getServiceDescriptionResponse"/>

<wsdl:fault message="impl:UnexpectedError" name="UnexpectedError"/>

</wsdl:operation>

<wsdl:operation name="getServiceName">

<wsdl:input message="impl:getServiceNameRequest" name="getServiceNameRequest"/>

<wsdl:output message="impl:getServiceNameResponse"

name="getServiceNameResponse"/>

<wsdl:fault message="impl:UnexpectedError" name="UnexpectedError"/>

</wsdl:operation>

<wsdl:operation name="getServiceVersion">

<wsdl:input message="impl:getServiceVersionRequest" name="getServiceVersionRequest"/>

<wsdl:output message="impl:getServiceVersionResponse"

name="getServiceVersionResponse"/>

<wsdl:fault message="impl:UnexpectedError" name="UnexpectedError"/>

</wsdl:operation>

</wsdl:portType>

<wsdl:binding name="CodeMappingServiceSoapBinding"

type="impl:CodeMappingOperations">

<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="getSupportedMaps">

<wsdlsoap:operation soapAction=""/>

<wsdl:input name="getSupportedMapsRequest">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:input>

<wsdl:output name="getSupportedMapsResponse">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:output>

<wsdl:fault name="UnexpectedError">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

</wsdl:operation>

<wsdl:operation name="mapConceptCode">

<wsdlsoap:operation soapAction=""/>

<wsdl:input name="mapConceptCodeRequest">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:input>

<wsdl:output name="mapConceptCodeResponse">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:output>

<wsdl:fault name="AmbiguousMapRequest">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

<wsdl:fault name="UnexpectedError">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

<wsdl:fault name="MapNameSourceMismatch">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

<wsdl:fault name="MapNameTargetMismatch">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

<wsdl:fault name="UnableToMap">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

<wsdl:fault name="MappingNotAvailable">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

<wsdl:fault name="UnknownMapName">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

<wsdl:fault name="UnknownConceptCode">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

<wsdl:fault name="UnknownCodeSystem">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

</wsdl:operation>

<wsdl:operation name="getCTSVersion">

<wsdlsoap:operation soapAction=""/>

<wsdl:input name="getCTSVersionReguest">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:input>

<wsdl:output name="getCTSVersionResponse">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:output>

<wsdl:fault name="UnexpectedError">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

</wsdl:operation>

<wsdl:operation name="getServiceDescription">

<wsdlsoap:operation soapAction=""/>

<wsdl:input name="getServiceDescriptionReguest">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:input>

<wsdl:output name="getServiceDescriptionResponse">

<wsdlsoap:body encodingstyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:output>

<wsdl:fault name="UnexpectedError">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

</wsdl:operation>

<wsdl:operation name="getServiceName">

<wsdlsoap:operation soapAction=""/>

<wsdl:input name="getServiceNameReguest">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:input>

<wsdl:output name="getServiceNameResponse">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:output>

<wsdl:fault name="UnexpectedError">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

</wsdl:operation>

<wsdl:operation name="getServiceVersion">

<wsdlsoap:operation soapAction=""/>

<wsdl:input name="getServiceVersionReguest">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:input>

<wsdl:output name="getServiceVersionResponse">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:output>

<wsdl:fault name="UnexpectedError">

<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn://hl7.org/CTSVAPI" use="encoded"/>

</wsdl:fault>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="CodeMappingOperationsService">

<wsdl:port binding="impl:CodeMappingServiceSoapBinding" name="CodeMappingService">

<wsdlsoap:address location="http://localhost:8080/axis/services/CodeMappingService"/>

</wsdl:port>

</wsdl:service>

</wsdl: definitions>

     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 Получение сведений о критериях поиска, поддерживаемых данной терминологией