allgosts.ru35. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ35.240. Применение информационных технологий

ГОСТ Р ИСО/HL7 27932-2015 Информатизация здоровья. Стандарты обмена данными. Архитектура клинических документов HL7. Выпуск 2

Обозначение:
ГОСТ Р ИСО/HL7 27932-2015
Наименование:
Информатизация здоровья. Стандарты обмена данными. Архитектура клинических документов HL7. Выпуск 2
Статус:
Действует
Дата введения:
11/01/2016
Дата отмены:
-
Заменен на:
-
Код ОКС:
35.240.80

Текст ГОСТ Р ИСО/HL7 27932-2015 Информатизация здоровья. Стандарты обмена данными. Архитектура клинических документов HL7. Выпуск 2



ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ФЕДЕРАЛЬНОЕ АГЕНТСТВО


НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ


ГОСТ Р исо/ HL7 27932— 2015


Информатизация здоровья СТАНДАРТЫ ОБМЕНА ДАННЫМИ

Архитектура клинических документов HL7.

Выпуск 2

(ISO/HL7 27932:2009,

Data Exchange Standards — HL7 Clinical Document Architecture,

Release 2, IDT)

Издание официальное


Предисловие

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

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

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

4    Настоящий стандарт идентичен международному стандарту MCO/HL7 27932:2009 «Стандарты обмена данными. Архитектура клинических документов HL7. Выпуск 2» (ISO/HL7 27932:2009 «Data Exchange Standards — HL7 Clinical Document Architecture. Release 2»).

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

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

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

Информация об изменениях х настоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Национальные стандарты», а текст изменений и поправок — е ежемесячно издаваемых информационных указателях «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты». Соотвелктеу-ющая информация, уведомление и тексты размещаются также в инфюрмационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (iiviviv.gosf.ru)

© Стандартинформ. 2016

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

Содержание

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

in

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

Информатизация здоровья СТАНДАРТЫ ОБМЕНА ДАННЫМИ Архитектура клинических документов HL7. Выпуск 2 Health informatics. Data Exchange Standards. HL7 Clinical Document Architecture. Release 2

Дата введения — 2016—11—01

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

1.1 Архитектура клинических документов HL7, выпуск 2

Областью применения архитектуры клинических документов (АКД) является стандартизация клинических документов для целей обмена.

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

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

В АКД обсуждается не создание документов или управление документами, а только разметка содержания документов в целях обмена. Хотя XML-схему АКД можно непосредственно использовать в программном обеспечении, предназначенном для конструирования документов, эта задача не является первоочередной для стандарта на АКД.

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

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

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

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

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

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

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

Издание официальное

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

В конце настоящего стандарта приведены ссылки на словарь HL7.

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

3.1    архитектура клинических документов (clinical document architecture): Стандарт разметки документа. описывающий структуру и семантику клинических документов для целей их передачи.

3.2    определение типа документа (Document Type Definition. DTD): Определение типа XML-документа, содержащее по значению или по ссылке объявления разметки, задающие грамматику класса документов.

3.3    медицинский работник (healthcare professional): Лицо, наделенное правом прямого или косвенного предоставления определенных медицинских услуг субъекту медицинской помощи или популяции субъектов.

Пример — Квалифицированный медицинский работник, (фармацевт, медицинская сестра, социальный работник, рентаенолаборант. медреаистратор.

(ENV 1613:1995]. ]ИСО 21574-7)

3.4    регуляторный орган или уполномоченный орган [regulatory agency (or authorities)]: Геополитические сущности создают агентства или органы, ответственные за регулирование обращения лекарственных средств и медицинских изделий. Собирательно такие агентства или органы называются регуляторными органами.

3.5    эталонная информационная модель (Reference Information Model. RIM): Информационная модель, разработанная комитетом HL7 и используемая для разработки всех остальных информационных моделей, например. RMIM, а также структуры сообщений.

3.6    уточненная информационная модель сообщений (Refined Message Information Model. RMIM): Информационная структура, описывающая требования к комплексу сообщений.

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

3.8    XML: Расширяемый язык раэметкм XML (extensible Markup Language), представляющий собой простой и очень гибкий формат текста, произведенный от языка SGML (ИСО 8879). Этот язык первоначально разработан для целей широкомасштабной электронной публикации, а затем стал играть все возрастающую роль в обмене разнообразными данными в сети Интернет и других коммуникационных средах.

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

4 Сокращения

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

ISO — International Organization for Standardization (Международная организация no стандартизации. ИСО);

CDA — Clinical Document Architecture (архитектура клинических документов, АКД);

CEN — Comite European de Normalisation (European Committee for Standardization, a federation of 28 national standards bodies that are also ISO member bodies) (Европейский комитет no стандартизации, федерация из 28 национальных органов стандартизации, которые также являются членами ИСО);

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

HL7 — Health Level 7:

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

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

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

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

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

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

SGML — Standardized generalized markup language. An ISO standard for describing structured information in a platform independent manner (стандартизованный обобщенный язык раз* метки. Стандарт ИСО. предназначенный для платформенно-независимого описания структурированной информации);

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

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

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

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

5 Архитектура клинических документов HL7, выпуск 2

ANSI/HL7 CDA. R2-2005 4/21/2005е

Основной/технический редактор: Robert Н. Dolin. MD. . Semantically Yours. LLC

Основной/технический редактор: Liora Alschuler. . Alschuier Associates

Основной/технический редактор: Sandy Boyer. BSP. . Consultant

Основной/технический редактор: Calvin Beebe, . Mayo Clinic

Технический редактор: Fred M. Behlen. PhD, , American College of Radiology

Технический редактор: Paul V. Biron,

Технический редактор: Amnon Shabo (Shvo), PhD. . IBM Research Lab in Haifa

5.1    Обзор АКД

5.1.1    Что такое АКД

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

1)    Постоянство. Клинический документ существует в неизменном состоянии в течение срока, определенного местными требованиями и нормативными документами (срок существования клинического документа не зависит от срока существования его электронной копии, представленной на языке XML в виде АКД-докумекта).

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

3)    Потенциальная юридическая значимость. Клинический документ представляет собой совокупность сведений, предназначенную для придания им юридической значимости.

4)    Контекст. Клинический документ идентифицирует определенный контекст, в котором по умолчанию представлено его содержание.

5)    Целостность. Клинический документ аутентифицируется как единое целое, а не отдельными частями вне полного содержания документа.

6)    Восприятие человеком. Клинический документ должен восприниматься человеком.

АКД-документ является определенным и полным информационным объектом, который может

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

5.1.1.1    Ключевые свойства АКД

АКД характеризуется следующими ключевыми свойствами:

АКД-документы кодируются с использованием расширяемого языка разметки XML.

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

Структура машинно'Обрабатываемого содержания АКД произведена из Эталонной информационной модели HL7 (Reference Information Model — RIM) и использует типы данных HL7 версии 3.

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

5.1.1.2    Область применения АКД

Областью применения АКД является стандартизация передаваемых клинических документов.

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

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

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

Управление документами тесно взаимосвязано со спецификациями АКД. но спецификация сообщений по управлению документами не входит в область ее применения (см. 5.1.2.6).

Примечание — Несколько комитетов разрабатывают спецификации структурированных документов, которые частично перекрываются со спецификацией АКД. Технический комитет Structured Documents в сотрудничестве с комитетом Publishing и другими комитетами готовит главу «УЫфрэст рук тура структурированных документов». поясняющую связи между этими разработками. Ев предполагается вклю-мть в предстоящие издания.

5.1.1.3    Цели и принципы разработки

Разработка АКД преследует следующие цели:

•    дать приоритет предоставлению медицинской помощи;

•    обеспечить экономически эффективную реализацию электронных медицинских документов в максимально широком спектре информационных систем:

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

-    способствовать длительному хранению всей информации, закодированной в соответствии с этой архитектурой;

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

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

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

•    обеспечить возможность достаточно быстрой разработки;

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

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

•    данная архитектура должна быть совместима с языком XML и моделью HL7 RIM;

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

•    технические барьеры по ее использованию должны быть минимизированы;

•    архитектура описывает представление документов, необходимое для их передачи:

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

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

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

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

•    должна быть обеспечена возможность чтения АКД-документов человеком, использующим общедоступные XML-совмвстимые веб-обозреватели, драйверы принтеров и типовую таблицу стилей АКД. написанную на стандартном языке описания стилей;

- должны использоваться открытые стандарты.

5.1.2 Общие понятия АКД

5.1.2.1 Основные компоненты АКД-документа

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

В следующем скелетном примере показаны основные компоненты прототипа АКД-документа. (Для его упрощения многие обязательные компоненты опущены. Подробный пример, соответствующий спецификации, приведен в 5.7.

Содержание АКД-документа вложено в элемент «ClinicalDocument» и состоит из заголовка (см. 5.4.2) и тела (см. 5.4.3). Заголовок лежит между элементами «ClinicalDocument» и «structuredBody». он идентифицирует и классифицирует документ и предоставляет информацию о его аутентификации, о случае медицинской помощи, о пациенте и других лицах и организациях, имеющих отношение к оказанию ему медицинской помощи.

Тело содержит клинические данные. Оно может представлять собой неструктурированный большой объект двоичных данных (BLOB — Binary Large Object Block) или содержать структурированную разметку. В примере показано структурированное тело, помещенное в элемент «structuredBody» и подразделяемое на рекурсивно вложенные разделы документа.

Содержание раздела АКД-документа помещено в элемент «section». Оно может включать в себя единственный повествовательный блок (см. 5.4.3.5). любое количество подразделов АКД (см. 5.4.3.6) и внешних ссылок.

Повествовательный блок размещен в элементе <text> внутри элемента «section» и должен содержать человекочитаемое наполнение. Принципы представления повествовательного блока, требования к соответствию, предъявляемые к создателям его содержания и читающим его получателям см. в подразделах «Человекочитаемость и визуализация документов АКД» (см. 5.1.2.3) и «Соответствие АКД» (см. 5.1.3).

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

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

Пример 1 —

<C!in>cal Document»

... Заголовок АКД-документа...

<structuredBody>

«section»

«text»...«/text»

<observabon»...«/observation> «substanceAdministration»

«supply»...«/supply»

«/substanceAdministration»

«observation»

«externalObservation»...

«/extemaiOtoservation»

«/observation»

«/section»

«section»

<section»...«/section»

«/section»

«/structured Body»

«/CtinicalDocument»

5.1.2.2 «А» e АКД

Для достижения целей, перечисленных е 5.1.1.3, понятие уровней, введенное в первом выпуске АКД. предполагало иерархию определений структуры документа XML DTD или XML-схем. Эта иерархия формировала «архитектуру», отсюда и появилась буква «А» в сокращении АКД.

Хотя смысл понятия уровня во втором выпуске АКД остался прежним, подход к представлению иерархий изменился. Текущая спецификация состоит из единой XML-схемы АКД. а архитектура обе* спечивается возможностью применения одного или нескольких иерархического наборов шаблонов HL7. ограничивающих широту и гибкость АКД.

Примечание — Для ограничения спецификации АКД могут использоваться механизмы, определенные в документе HL7 V3 Refinement and Localization («Уточнение и локализация HL7 V3*). Во время разработки настоящего стандарта технические формализмы HL7 (например, спецификации шаблонов HL7, формата взаимообмена моделями HL7), обеспечивающие возможности ограничения спецификации АКД. находились в стадии разработки.

Класс InfrastructureRoot модели RiM содержит атрибут templatelD. который доступен для использования в АКД. Таким образом, пока шаблоны HL7 находятся в стадии разработки, в АКД уже имеется возможность указать ссылку на шаблон или руководство по реализации, которому был присвоен уникальный идентификатор. Пока не будет составлена формальная спецификация шаблонов HL7. не существует стандартизованного процесса для проверки соответствия шаблонов, на которые даются ссылки.

Не требуется обязательно ограничивать спецификацию АКД. 8 реализациях, использующих элементы структурированных данных для управления автоматизированными процессами, обычно требуется. чтобы либо (1) эти элементы были ограничены с помощью соответствующей уточненной модели или другого языка ограничений, принятым в HL7. либо (2) эти элементы соответствовали детальному руководству по реализации, описывающему способ, которым должны быть представлены структурированные элементы и их предполагаемая интерпретация, в таком объеме, чтобы клиническая безопасность обеспечивалась на уровне, соответствующем конкретному варианту использования.

Существует много типов шаблонов HL7, которые могут быть созданы. Среди них две группы особенно важны для клинических документов: (1) те шаблоны, которые ограничивают разделы документа в зависимости от типа документа (шаблоны уровня раздела): (2) те шаблоны, которые ограничивают подразделы (entries), вложенные в разделы документа (шаблоны уровня подраздела). В таблице 1 приведено сопоставление между определением уровней, приведенном в первом выпуске АКД. и текущим определением, основанном на этих двух типах шаблонов HL7.

Таблица 1 — Эволюция понятий уровня от первого ко второму выпуску АКД

АКД. выпуск 1

АКД. выпуск 2

Уровень 1 (СОА Level One)

Спецификация АКД без дополнительных ограничений.

Уровень 2 (CDA Level Two)

Спецификация АКД. в которой заданы шаблоны уровня разделов.

Уровень 3 (СОА Level Three)

Спецификация АКД. в которой заданы шаблоны уровня подразделов (и необязательно шаблоны уровня разделов).

Ниже приведена иллюстрация одной из возможных иерархий АКДс шаблонами HL7.

Пример 2 — Схема АКД

-    Схема АКД:: применен шаблон "Дневниковая запись» уровня раздела.

-    Схема АКД:: применен шаблон «Дневниковая запись» уровня раздела и шаблон *Жизненно важные показатели» уровня подраздела.

- Схема АКД:: применен шаблон «Дневниковая запись эндокринолога» уровня раздела и шаблон кЖизненно важные показатели» уровня подраздела.

•    Схема АКД :: применен шаблон «Дневниковая запись» уровня раздела и шаблон *Жизненно важные показатели в блохе интенсивной терапии» уровня подраздела.

•    Схема АКД:: применен шаблон «Дневниковая запись кардиолога» уровня раздела.

-    Схема АКД :: применен шаблон "Дневниковая запись кардиолога» уровня раздела и шаблон «Осмотр кардиолога» уровня подраздела.

- Схема АКД:: применен шаблон «Дневниковая запись эндокринолога» уровня раздела.

•    Схема АКД:: применен шаблон «Дневниковая запись эндокринолога» уровня раздела и шаблон «Жизненно важные показатели» уровня подраздела.

5.1.2.3    Человекочитаемость и визуализация документов АКД

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

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

•    получатель произвольного АКД-документа должен иметь определенный способ оценки правильности его содержания;

•    для обеспечения человекочитаемости отправитель не должен передавать особую таблицу стилей вместе с АКД-документом. Должна существовать возможность визуализации АКД-документов с помощью единой таблицы стилей и общедоступных инструментов отображения:

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

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

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

Эти принципы и требования легли в основу текущего подхода, при котором материал, предназначенный для визуализации, помещается в поле Section.text (см. Блок свободного текста секции (см. 5.4.3.5)). Модель содержания этого поля специально сконструирована таким образом, чтобы выполнялись указанные выше требования. Она аналогична модели содержания разделов, использованной в первом выпуске АКД. Структурированные результаты исследований могут содержать ссылки на повествовательное содержание, помещенное в поле Section.text. Мультимедийные результаты исследований передаются вне поля Section.text. а тег <renderMultiMedia>. включаемый в поле Section.text. показывает, где должны отображаться мультимедийные результаты, на которые в кем дается ссылка.

5.1.2.4    XML-разметка АКД-документов

Настоя щаяспецификацияописываетХМЬразметку АКД-документов. Экземпляры АКД-документов проверяются на соответствие XML-схеме АКД и могут быть объектами дополнительных проверок (см. 5.1.3). Не существует запретов на использование различных языков описания схем (например. W3C. DTD. RELAXING), коль скоро экземпляры документов, соответствующие схеме, остаются совместимыми.

При конструировании схемы АКД-документов использовались следующие принципы:

-    использование общих требований: схема АКД-документов соответствует более общим требованиям к АКД (см. 5.1.1.3);

•    согласование схемы АКД-документов со Спецификацией технологии реализации (ITS) V3: схема АКД-документов соответствует общей спецификации технологии реализации стандарта HL7 V3 на языке XML (V3 XML ITS);

•    отображение на модель RIM: схема АКД-документов описывает стиль XML-разметки экземпляров АКД-документов для цели обмена. Ее нельзя понять вне контекста этой определяющей спецификации. В то же время схема АКД-документов самостоятельно применима для целей реализации, хотя и не предназначена для повторения или замещения уточненной информационной модели сообщений (R-MIM) и иерархического описания (HD). Таким образом, схема АКД-документов сама по себе не обеспечивает адекватное соответствие экземпляров документов модели HL7 RIM, Для обеспечения семантической интероперабельности экземпляров АКД-документов необходимо знать и использовать схему АКД-документов. модель R-MIM и иерархическое описание HD. а также соответствующую модель RIM;

•    анализ документов, схема АКД-документов и соответствующие ей документы должны соответствовать требованиям к анализу документов, вытекающим из модели содержания;

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

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

-    прямая и обратная совместимость; схема АКД-документов должна удовлетворять требованиям прямой и обратной совместимости, (см. 5.1.5);

-    присвоение имен: хотя по определению XML-разметка предназначена для машинной обработки, она должна быть оптимизирована для просмотра, отладки и конструирования человеком. Схема АКД-документое не является «самодокументируемой». но смысл содержания должен быть ясен из имени тега и документации (например, из отображения на модель RIM). В то же время человекочитаемое название тега не должно вводить в заблуждение;

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

5.1.2.5    Безопасность, конфиденциальность и целостность данных

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

В схеме АКД-документов предусмотрен статус конфиденциальности, используя который, прикладные системы могут управлять доступом к чувствительным данным. Статус конфиденциальности может применяться ко всему документу или к определенным фрагментам документа.

5.1.2.6    Связь АКД со стандартами передачи сообщений HL7

АКД-документ является определенным и законченным информационным объектом, который может существовать вне контекста сообщений и/или может быть помещен в сообщение HL7 (см. 5.3 Обмен документами АКД в сообщениях HL7). Таким образом. АКД дополняет спецификации сообщений HL7.

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

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

Для минимизации риска просмотра устаревшей информации необходимо использовать системы управления клиническими документами. Если АКД-документы просматриваются вне контекста системы управления документами, то нельзя знать наверняка, был ли просматриваемый документ впоследствии отредактирован. Сообщения HL7. в которых передаются АКД-документы (например, сообщения MDM в стандарте HL7 V2.x и Medical Records в стандарте HL7 V3). содержат критичную информацию о контексте, обеспечивающую точный просмотр клинических данных.

5.1.3 Соответствие стандарту АКД

Примечание — Полное обсуждение соответствия стандарту HL7 V3 см. в документе HL7 V3 Refinement and Localization.

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

Создатель документа — роль приложения, создающего АКД-документ. Такой документ может быть создан с помощью преобразования из какого-либо другого формата, как непосредственный результат программы ввода документов и т. д. Создатель документа нередко ответственен за обмен документами с местом их постоянного хранения, для чего во многих случаях он может использовать сообщения MDM стандарта HL7 V2 или сообщения Medical Records стандарта HL7 V3. Создатель документа отвечает за полное соответствие созданных им АКД-документов настоящей спецификации.

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

Поскольку АКД представляет собой стандарт передачи и АКД-документ может не являться исходной формой документа, то настоящий стандарт не предъявляет никаких требований к постоянному хранению АКД-документов. Однако, как отмечалось выше в 5.1.2.6 «Связь АКД со стандартами передачи сообщений HL7», спецификация АКД существенно увязана с управлением документами. За управление исходным документом, который может храниться в отличной от АКД форме, отвечает владелец, идентифицированный в заголовке АКД-документа (см. S.4.2.2.3).

5.1.3.1 Обязанности получателя

Получатель обязан:

1)    использовать значения по умолчанию там. где они определены этой спецификацией, и где документ не содержит никакого значения: в случае, если в экземпляре АКД-документа отсутствует значение элемента или атрибута, для которого в спецификации АКД определено значение по умолчанию, получатель должен использовать это значение. (Примечание: значения по умолчанию обозначены в основной части этого документа как [по умолчанию));

2)    разбирать и интерпретировать полный заголовок АКД-документа: получатель АКД-документа должен быть способен разбирать и интерпретировать полный заголовок АКД-документа. Поскольку в приложениях демографические или другие данные заголовка АКД-документа могут извлекаться из центрального нормативно-справочного файла, то способ визуализации заголовка оставляется на усмотрение получателя. Кроме того, визуализация заголовка АКД-документа может зависеть от местной практики и контекста его использования (например, электронная медицинская карта, сценарий обезличивания). Если создатель документа хочет предложить свой вариант визуализации, то в дополнение к АКД-документу он может передать одну или несколько таблиц стилей XML. Использование этих таблиц стилей оставляется на усмотрение получателя:

3)    разбирать и интерпретировать тело АКД-документа в объеме, достаточном для его визуализации: получатель АКД-документа должен быть способен разбирать и интерпретировать тело АКД-документа в объеме, достаточном для его визуализации, используя следующие правила:

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

•    если тело документа структурировано, то должно быть отображено название раздела, указанное в элементе Section.title. Отсутствие этого элемента означает, что раздел не имеет названия;

•    если тело документа структурировано, то содержание элемента Section, text должно быть отображено в соответствии с правилами, указанными в 5.4.3.5.

Получатель АКД-документа не обязан:

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

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

5.1.3.2 Обязанности создателя

Создатель обязан:

1) правильно конструировать повествовательные блоки АКД-документое: создатель обязан удостовериться. что заверяемая часть тела документа структурирована таким образом, что получатель, действуя в соответствии с описанными выше обязанностями, правильно отобразит документ. Сюда относятся следующие правила:

2} если тело документа структурировано, то название раздела должно передаваться е элементе Section.title. Отсутствие этого элемента означает, что раздел не имеет названия;

3)    если тело документа структурировано, то заверяемое повествовательное содержание раздела должно быть помещено в элемент Section.text независимо от того, передается ли это содержание еще и в подразделах АКД-документа. Заверяемые ссылки на мультимедийное содержание должны быть включены в подразделы типа ObservationMedia или RegionOflnterest АКД-документа;

4)    если тело документа структурировано, то содержание элемента Section.text должно соответствовать правилам, изложенным в подразделе 5.4.3.5.

Создатель АКД-документа не обязан:

1) полностью кодировать все повествовательные блоки тела АКД-документа в виде его подразделов. По местным соглашениям взаимодействующие стороны могут назначать создателю дополнительные обязанности создания различных подразделов.

5.1.4    Расширяемость АКД

Примечание — Полное обсуждение правил расширения XML-спецификаций стандарта HL7 V3 приведено в документе XML ITS — Informal Extensions.

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

Расширения могут быть включены в документ, используя пространство имен, отличающееся от пространства имен HL7v3, но при этом они не должны помещаться в элементы типа ED (напр.. <text> внутри <procedure>}, поскольку внутри документа, соответствующего стандарту, содержимое значения типа данных ED может быть е другом пространстве имен. Так как все содержание, соответствующее стандарту (внешнее по отношению к элементам с типом данных ED) находится в пространстве имен HL7. то отправитель может включить любое расширенное содержимое в чужое пространство имен (любое пространство имен, отличающееся от пространства имен HL7). При обнаружении таких расширений системы-получатели не должны сообщать об ошибке.

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

5.1.5    Обратная и прямая совместимость

Примечание — Подробный список всех изменений, сделанных в АКД. выпуск 2 по сравнению с АКД. выпуск 1. можно найги в приложении (см. (п. В.4)).

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

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

-    документирование: в новом выпуске АКД будут перечислять все существенные отличия от предыдущего выпуска;

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

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

•    переименование: в новом выпуске АКД компоненты (включая имена XML-элементов и атрибутов) могут быть переименованы. В этом случае будет предоставлена таблица соответствия со списком всех изменений. При переименовании будут соблюдаться сформулированные выше соглашения об именовании, (см. 5.1.2.4);

-    запрещенные компоненты: в новом выпуске АКД могут быть запрещены компоненты, определенные в предыдущем выпуске. Запрещенные компоненты будут удалены из следующего выпуска стандарта, поэтому их использование не рекомендуется:

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

-    изменение словарного домена: в новом выпуске АКД может быть изменен словарный домен компонента. В этом случав будет предоставлена таблица преобразования со списком всех изменений;

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

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

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

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

5.2 Введение в технические артефакты АКД

Для полного понимания АКД необходимо ознакомиться с нормативными артефактами, используемыми в определениях спецификации. Иерархическое описание АКД-документов (Hierarchical Description) является определяющим источником правил соответствия стандарту АКД и служит источником для конструирования схемы АКД-документов. Помимо того, что экземпляр АКД-документа должен соответствовать этой схеме, он должен также удовлетворять правилам соответствия, приведенным в Иерархическом описании АКД, которое выводится из модели R-MIM. построенной для АКД. а та, в свою очередь, выводится из Эталонной информационной модели (RIM) HL7, являющейся наиболее полным источником определений классов и их атрибутов.

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

5.2.1    Эталонная информационная модель HL7

Полное описание Эталонной информационной модели HL7 (Reference Information Model: RIM) можно найти в ГОСТ ИСО/Н17 21731-2013.

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

Стандарт АКД. выпуск 2. получен из версии 2.07 модели HL7 RIM.

При необходимости посмотреть полное определение атрибута или класса модели RIM. следует обратиться к ее спецификации.

5.2.2    Типы данных HL7 V3

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

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

В АКД. выпуск 2. используется абстрактная спецификация типов данных и их представление на языке XML. описанные в документе HL7 V3 Data Types. Release One.

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

5.2.3    Словарные домены HL7

Наиболее полное описание словарных доменов приведено в документе HL7 Vocabulary.

Словарные домены представляют собой наборы допустимых значений кодированных компонентов АКД. Эти домены могут включать в себя как понятия, определенные в стандарте HL7. так и понятия, взятые из систем кодирования, рекомендованных стандартом HL7. например. LOINC или SNOMED. Документ HL7 Vocabulary является наиболее полным справочным источником понятий, определенных в стандарте HL7. Хотя АКД может дополнительно ограничивать словарные домены, определения АКД никогда не будут конфликтовать с определениями документа HL7 Vocabulary.

Словарные домены обладают квалификатором расширяемости, который может принимать значение «Кодировано, без расширений» (CNE). означающий, что дпя компонента АКД доступны только те значения, которые входят в заданном множестве, или «Кодировано, с расширениями» (CWE), означающий. что при необходимости могут использоваться значения, не входящие в заданное множество. Каждый словарный домен имеет уникальный идентификатор, определенный в стандарте HL7. Аналогично, каждому понятию словарного домена присвоен уникальный код.

Если кодированный компонент АКД ассоциирован с набором значений, имеющим квалификатор расширения CNE, то допустимые значения компонента фиксированы стандартом и перечислены, как показано в таблице 2.

Таблице 2 — Набор значений атрибута relatedDocument.typeCode (CNE)

Km

Определение

APND

Текущий документ является дополнением родительского документа (append)

RPLC

Текущий документ является заменой родительского документа (replace)

XFRM

Текущий документ является преобразованием родительского документа (transform)

5.2.4    Модель АКД R-MIM

Наиболее полное описание процесса уточнения моделей, предложенных а стандарте HL7. можно найти в документе HL7 V3 Guide.

Модель АКД R-MIM описана в 5.4.

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

Модель АКД R-MIM является графическим представлением спецификации АКД. Ее форма соответствует нотации и соглашениям по построению диаграмм, разработанным комитетом HL7 для представления специфичных семантических конструкций содержания критичных, «основных» классов модели RIM. Как ее. так и модель RIM. можно представить в нотации Унифицированного языка моделирования (UML). однако та нотация, что предложена комитетом HL7, предоставляет более детальную информацию о конкретных ограничениях и клонах представляемых классов. Соглашения по представлению диаграмм, принятые комитетом HL7. сокращают некоторые описания отношений, что позволяет сократить диаграммы, сделать их более точными и обеспечить большую визуальную информативность.

Модель АКД R-MIM представляет собой графическое средство, предназначенное для облегчения понимания спецификации. Поскольку иерархическое описание АКД и. соответственно, схема АКД-документов являются производными от модели АКД R-MIM. то эта модель является хорошей основой для описания стандарта. Она дополняется повествовательным описанием специфичных клонов, используемых в АКД.

5.2.5    Иерархическое описание АКД

Наиболее полное описание процесса разработки и интерпретации иерархических описаний в стандартах HL7 можно найти в документе HL7 V3 Guide.

Иерархическое описание АКД приведено в 5.5.

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

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

5.2.6    Реализация АКД на языке XML

При конструировании XML-схемы АКД-документов использовалась спецификация технологии реализации на языке XML (HL7 XML ITS). Наиболее полное описание этой технологии и процесса перехода от иерархического описания к схеме приведено в документе XML Implementable Technology Specification for V3 Structures.

Схема АКД-документов описана ниже в 5.6.

Стандарт АКД. выпуск 2 основан на спецификации HL7 V3 XML Implementable Technology Specification forV3 Structures. Release One.

Специальные расширения схемы АКД-документов сверх тех, что определены е документе HL7 V3 XML ITS. описаны ниже в 5.6.

При просмотре модели АКД R-MIM читатель, знакомый с моделью RIM, документом HL7 Development Framework и правилами реализации на языке XML. может идентифицировать соответствующие элементы XML и их атрибуты. Но из-за того, что некоторые имена элементов генерируются автоматически, это соответствие может оказаться не очевидным, и в этом случае читателю следует обратиться к документу HL7 V3 XML ITS.

5.3 Передача АКД-документов в сообщениях HL7

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

Любая стратегия передачи АКД-документое должна включать в себя следующие требования:

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

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

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

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

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

•    при создании пакета передачи не должна возникать необходимость изменения каких-либо значений XML-атрибутов ID;

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

•    в пакет передачи должны быть включены ключевые метаданные АКД-документа. необходимые для управления документами (например, состояние документа, статус архивирования документа). (Полную информацию о метаданных клинического документа, управлении документами, а также о состояниях документа и переходах состояний см. в спецификации HL7 V3 Medical Records.

В контексте сообщений, определенных в стандартах HL7 2.x и V3. АКД-документ можно рассматривать как мультимедийный объект, который может передаваться в поле с типом данных ED (инкапсулированные данные) закодированным в соответствии со спецификацией многоцелевых расширений интернет-почты MIME (Multipurpose Internet Mail Extensions. RFC 2046).

В текущей спецификации MIME рекомендуется следовать подходу, изложенному в Интернет-стандарте RFC 2557 «MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)» (инкапсулирование агрегированных документов, например. HTML (MHTML). в пакет MIME) и предусматривающему инкапсуляцию в пакетах MIME агрегированных документов, передаваемых в соответствии с протоколами ebXML и DICOM.

В любых сообщениях стандарта HL7 V2.X. позволяющих передавать документы (например, в сообщении MDM). АКД-документы должны передаваться в сегментах ОВХ. При этом пакет MIME передается в поле ОВХ-5 (00573 «Результат исследования») как значение типа данных ED. Полю ОВХ-2 (00570 «Тип значения») должно быть присвоено значение «ED». Значения поля ОВХ.З должно быть тем же самым, что и значение компонента ClinicalDocument.code.

Значения многих полей сообщения перекрываются со значениями компонентов АКД-документа. В таблице 3 показано соответствие между полями сегмента ТХА. передаваемого в сообщении HL7 V2 MDM. на компоненты АКД-документа.

Таблица 3 — Отображение полей сегмента HL7 V2 ТХАна компоненты АКД-документа

Пол* сотыми* ТХА

Коыпоиенг АКй-дохуменга

2 Тип документа

ClinicalDocument.code

4 Дата и время действия

ServiceEvent.effectiveTtme

5 Код/ФИО основного лица, ответственного за выполнение действия

ServiceEvent performer

6 Дата и время создания документа

ClinicaiDocument.effectiveTkne

7 Дата и время ввода документа

dataEnterer.time

9 Код/ФИО автора документа

author

11 Кдо/ФИО лица, которое ввело документ

dataEnterer

12 Уникальный номер документа

ClinicalDocument.id

13 Комер документа-родителя

ParentOocument. id

14 Номер заказа у заказчика

Order.kl

16 Статус конфиденциальности документа

ClinicalDocumenl.confidentialityCode

19 Статус доступности документа

authenticator. legalAuthenticator

22 Штамп исполнителя, отвечающего за аутентичность документа

informationRecipient

23 Разосланные копии (коды и ФИО получателей)

ServioeEvent.effectiveTime

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

Пример 3 MSH |...

EVN |...

РЮ |...

PV1 |...

ТХА |...

ОВХ |1|ED|11492-6AHistory and PhysicalALN||

Amultipart''relatedAAA MIME-Version: 1.0

Content-Type: muftipsrt/related: boundary=*HL7-CDA-boundary"; type='text/xmr; start="10.12.45567.43"

Content-Transfer-Enooding: BASE64

-HL7-CDA-boundary

Content-Type: text/xml; charset=4JS-ASCil'

Content-ID: &IU10.12.45567.43>

... Представление базового АКД-документа e кодировке Base64

<observationMedia ctassCode="OBS* moodCode=HEVN'>

«id root='10.23.4567.3457>

«value medtaType='image/jpeg*>

«reference vakie="left_hand_iniage.jpeg7>

</vaiue>

</observationMedia>

-HL7-CDA-bour»dary Content-ID: &Н; Ю.23.4567.345>

Content-Location: canned _left_hand_image.jpeg Content-Type: image/JPEG

... Изображение в кодировке Base64 ...

-HL7-CDA-boundary—

АКД-докумекты могут передаваться в любых сообщениях стандарта HL7 V3. позволяющих передавать документы (например, в сообщении HL7 V3 Medical Records). При этом атрибут Acltext модели RIM должен содержать пакет MIME, закодированный как инкапсулированный тип данных.

Как и в случае сообщений стандарта HL7 V2, значения многих полей сообщения HL7 V3 перекрываются со значениями компонентов АКД-документа. Поскольку спецификация АКД и сообщения HL7 V3 Medical Records произведены от общей информационной модели, соответствие между ними достаточно очевидное (см. таблицу 4).

Таблице 4 — Отображение полей сообщения HL7 V3 Medical Records на компоненты АКД-документа

Коыпомвнт сообщения HL7 V3 Medtcal Records

Компонент A КД-документа

Примечание

ClinicalDocument

ClinicalDocument

Сообщение Medical Records содержит атрибуты, не представленные в АКД-документе (text. statusCode. avaiJabilityTime. reasonCode, comptefioncode. storageCode. copy Time); АКД-докуыент содержит атрибуты, не представленные в сообщении Medical Records (title)

authenticator

authenticator

legalAuthenticator

legalAuthenticator

dataEnterer

dataEnterer

EncounterEvent / encounterPerformer

encompassingEn counter / encounterParticipant: servioeEvent / performer

Атрибут encounterPerformer сообщения Medical Records расщепляется на два участника 8 АКД-документе

responsibteParty

responsibleParty

custodian

custodian

particpant

participant

information Recipient

informabonRecipient

recordTarget

recordTarget

author

author

subject

subject

Атрибут subject сообщения Medical Records представляет собой каталог всех субъектов, указанных в документе

relatedDocument / ParenlDocument

relatedDocument f parentDocument

documentationOf / Event

documentationOf / serviceEvent

inFutfttlmentOf / Order

inFuIRBmentOf / order

componentOf / EncounterEvent

componentOf 1 enoompassingEncounter

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

Пример 4 <someMessage>

<Act.Code code-"11488-4" codeSystem-’‘2.1 б.840.1.113883.6.1” disptayName-''Заключение консультанта”/>

<Act. text type-'multipart/related">

MIME-Version: 1.0

СолГелГ-Гуре; muttipart/related; boundary-"HL7-CDA-boundary": type^text/xml"; start="10.12.45567.43"

Content-Transfer-Encoding: BASE64

--HL7-CDA-boundary

Confenf-Type: texVxml: charset="US-ASCII'’

Content-Ю: &lt;10.12.4S567.43>

... АКД-документ в кодировке Base 64:

<observationMedia classCode-‘fOBSnmoodcode-"EVN">

<id roots"10.23.4S67.34Sn/>

<value mediaType= "image/jpeg ">

<reference value="left_hand_image.jpeg"f>

<A/alue>

</observationMedia>

--HL7-CDA-boundary Content-ID: &lt:10.23.4567.34S>

Content-Location: cannedJeftJhandJmage.jpeg Content-Type: image/JPEG

... Base64 image...

-HL7-CDA-boundary-

</Acltext>

</someMessage>

5.4 Модель АКД R-MIM

Примечание — Наиболее полное описание уточнения модели HL7 V3. разработки и интерпретации модели R-MIM можно найти в документе HL7 V3 Guide.

Графическое представление модели АКД R-MIM (POCD_RM000040) приведено в подразделе 6.2.

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

5.4.1 Класс CllnicalDocument

Класс ClimcalDocument является входной точкой в модель АКД R-MIM и соответствует корневому элементу <ClinicalDocument> АКД-документа.

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

Класс ClinicalDocument наследует различные атрибуты класса InfrastructureRoot модели RIM. в том числе ClimcalDocument.templateld и ClinicalDocument.typeld. Значение атрибута ClinicalOocument. templateld. передаваемое в экземпляре АКД-документа, служит признаком наложения ряда ограничений. определяемых в шаблоне документа в целом. Кроме того, этот атрибут присутствует во всех других классах модели АКД. Если он задан, то служит признаком наложения ряда ограничений, определяемых в шаблоне соответствующего уровня детализации. Значение этого атрибута является уникальным идентификатором конкретного шаблона.

Атрибут ClinicalDocument.typeld является технологически нейтральной ссылкой на данную спецификацию второго выпуска АКД. Его компонентам должны быть присвоены следующие значения: CtinicalDocument.typeld.root = «2.16.840.1.113883.1.3» (объектный идентификатор (ОИД) зарегистрированных моделей HL7); CtinicalDocumenttypeld.extension = «POCD_HD000040» (уникальный идентификатор иерархического описания АКД. выпуск 2).

5.4.2 Заголовок

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

5.4.2.1 Атрибуты заголовка

В этом разделе описаны атрибуты корневого класса ClinicalDocument.

Таблица 5 — Допустимые значения атрибута CliricalDocument.ctassCode (CNE)

Код

Описание

DOCCIIN (клинический документ) (по умолчанию]

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

Таблица 6 — Допустимые значения атрибута ClinicaiDocument.moodCode (CNE)

Кол

Описание

EVN (событие) [по умолчанию]

Фактически произошедшее событие (event), то есть состоявшееся действие документирования тол», что уже произошло, а не требование, намерение, планирование или обещание подготовки документа

5.4.2.1.1    ClinicalDocument.id (идентификатор)

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

5.4.2.1.2    ClinicalDocument.Code (тип документа)

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

Начиная с версии базы данных LOINC 2.09 (май 2003 года), коды типов документов описаны в тех записях, которые имеют значение "DOC" в компоненте Scale. Это подмножество LOINC включено в приложение (см. 5.8.2).

Примечание — Построение иерархии кодов документов е классификации LOINC все еще развивается, В руководстве по классификации LOINC, версия 2.14 (декабрь 2004} указано, что 8 максимально короткие сроки термины компонентов, используемые для создания имен кодов типов документов, будут отображены либо в термины метатезауруса UMLS Metathesaurus, либо в термины номенклатуры SNOMED СТ. Это отображение поможет установить значения терминов и позволит объединить и классифицировать коды типов документов на основе определений, вычисляемых отношений и иерархий, уже существующих в справочной терминологии.

5.4.2.1.3    ClinicalDocument.title (название)

Содержит название документа. Клинические документы часто не имеют отдельного названия. В этом случае в качестве общего названия используется отображаемое значение свойства display атрибута ClinicalDocument.code (например, «Заключение консультанта» или «Дневниковая запись»). Если предполагается отображать название клиницисту, или же если документ имеет уникальное название, то следует использовать компонент ClinicalDocumenuitle. В примере документа, приведенном в 5.7.1. атрибут ClinicalDocument.title имеет значение «Good Health Clinic Consultation Note».

5.4.2.1.4    ClinicalDocument.efFectiveTime (дата и время создания)

Содержит время создания документа, то есть момент появления документа на свет. Если АКД-документ является преобразованием исходного документа в какой-либо иной формате, то CtinicalDocumenteffectiveTime должен содержать время создания исходного документа. Время преобразования в настоящий момент не представлено в модели АКД.

5.4.2.1.5    Clinica[Document.confidentialityCode (код конфиденциальности)

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

Таблице 7 — Допустимые значения атрибута CliricalDocument.contidentiatityCode (С WE)

Код

Описание

N (обычный) (codeSystem = 2.16.840.1.11386.5.25)

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

R (средний) (codeSystem = 2.16.840.1.11388.5.25)

Средние ограничения доступа, например, документ могут читать только медицинские работники, имеющие непосредственное отношение к текущей медицинской помощи пациенту

V (высокий) (codeSystem = 2.16.840.1.11388.5.25)

Высокие ограничения доступа, заданные политикой конфиденциальности

5.4.2.1.6    ClinicaiDocument.languageCode (код языка)

Указывает код языка, на котором представлены строковые данные клинического документа (применяется как к содержанию, так и к значениям атрибутов). Значениями атрибута являются идентификаторы языка, определенные в документе IETF (Internet Engineering Task Force) RFC 3066 (no ред. H.AIvestrand. 1995). заменяющем устаревший документ RFC 1766. В стандартах HL7 для этих кодов используется система кодирования 2.16.840.1.113683.6.121. Значение кода языка, указанное в заголовке, применяется к документу в целом, но может быть переопределено для его части (см. 5.4.4).

5.4.2.1.7    ClinicalDocument.setld (идентификатор группы)

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

5.4.2.1.8    ClimcalDocument.versionNumber (номер версии)

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

5.4.2.1.9    ClinicaiDocument.copyTime (запрещен)

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

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

5.4.2.2 Участники, указанные в заголовке АКД-документа

В этом подразделе описаны классы, связанные с корневым классом ClinicatDocument с помощью класса Participation.

5.4.2.2.1 Участник authenticator (контролер)

Содержит сведения о контролере документа, то есть о лице, которое заверяет точность документа, но не несет за него юридическую ответственность. Примером может служить врач-ордикатор. который осматривает пациента и диктует запись, а затем подписывает ее. (см. 5.4.2.2.8).

Клинический документ может не иметь контролера, иметь одного или нескольких контролеров. Хотя в АКД-документе не предусмотрена электронная подпись, как контролер, так и лицо, юридически ответственное за содержание документа, должны подписать документ вручную или электронным способом. Для контролера обязательно должны быть указаны время аутентификации (authenticator.time) и код подписи (authenticator.signatureCode). указывающий, что подпись получена и связана с документом.

Таблица 8 — Допустимые значения атрибута aulhenticator.typeCode (CNE)

Код

Описание

AUTHEN (контролер) (по умолчанию)

Лицо- которое заверяет точность документа, но не несет за него юридическую ответственность

Таблица 9 — Допустимые значения атрибута authenticator.signatureCode (CNE)

Код

Описание

S (подписан)

Документ подписан и сохранен

X (подпись требуется) (запрещен)

В первом выпуске АКД контролер мог быть фактическим (S) или планируемым (X). Во втором выпуске АКД предусмотрен только фактический контролер, поэтому значение X запрещено

Контролером является лицо в роли представителя организации (класс AssignedEntity). то есть лицо, которому контролирующая организация назначила определенную роль. Сущностью, выполняющей роль, является физическое лицо (класс Person). Сущностью, контролирующей роль, является организация (класс Organization), (Описание отношений «роль исполнителя» (player role) и «роль контролера» (scoper role) приведено в модели HL7 RIM).

Таблица 10 — Допустимые значения атрибута AssignedEntity.classCode (CNE)

Код

Описание

ASSIGNED {уполномочен} [по умолчанию]

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

Таблица 11 —Допустимые значения атрибута Person.classCode (CNE)

Код

Описание

PSN {физическое лицо) [по умолчанию]

Живой организм вида homo sapiens

Таблица 12 —Допустимые значения атрибута Person.determine rCode (CNE)

Код

Описание

INSTANCE (экземпляр) [no умолчанию]

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

Таблица 13 — Допустимые значения атрибута Organizabon.classCode (CNE)

Код

Описание

ORG (организация) [по умолчанию]

Социальная структуре или юридическое лицо, созданное людьми

Код

Описание

INSTANCE (экземпляр) [по умолчанию]

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

Контролирующая организация может быть частью более крупной организации. Если необходимо указать отношение «целое-часты». то можно использовать роль OrganizationPartOf. Атрибут Organi2ationPartOf.statusCo<Je содержит код состояния этого отношения (например, «активное», «завершенное»). В атрибуте OrganizationPartOf.effectiveTime указан интервал времени, в течение которого действует отношение «целое-часть», если он применим и известен.

Таблица 15 — Допустимые значения атрибута OrganizationPartOf.classCode (CNE)

Код

Описание

PART (часть) [по умолчанию]

Отношение двух сущностей, при котором исполняющая сущность является частью контролирующей сущности

Таблица 16 — Допустимые значения атрибута OrganizabonPartOf.statusCode (CNE)

Код

Описание

normal (нормальная)

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

active (активна)

Это состояние указывает, что сущность в настоящий момент активна в данной роли

cancelled (отмененное)

Терминальное состояние, возникающее при отмене роли до того, как она стала активной

pending (в ожидании)

Это состояние указывает, что роль еще не стала активной

suspended

(приостановлена)

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

terminated (завершена)

Это состояние указывает, что выполнение роли успешно завершено

nullified (аннулирована)

Это состояние является терминагъным состоянием экземпляра роли, созданного по ошибке

5.4.2.2.2 Участник author (автор)

Содержит сведения о физическом лице или устройстве (программном обеспечении), создавшем содержание документа.

В некоторых случаях роль или функция автора вытекает из типа документа, содержащегося в атрибуте ClinicalDocument.coOe. например. «Дневниковая запись студентз-медика». Роль автора может быть также указана в атрибутах Author.functionCode или AssignedAuthor.code. Если какой-либо из них присутствует, то его значение должно быть эквивалентно роли, вытекающей из типа документа, или служить ее дальнейшим уточнением (например, атрибут ClinicalDocument.code имеет значение «Врачебная дневниковая запись», а атрибут Author.functionCode — значение «Лечащий врач»), но отнюдь не конфликтовать с ней. поскольку это может создать двусмысленную ситуацию.

Таблице 17 — Допустимые значения атрибута author.typeCode (CNE)

Код

Описание

А1ГТ (автор)

[по умолчанию]

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

Код

Описание

ОР (замещающая, распространяемая) [по умолчанию)

Ассоциация участника, замещающая ассоциацию с гем же значением атрибута typeCode. Эта замещающая ассоциация будет распространяться на действия-потомки, которые связаны с данным экземпляром класса Act с помощью экземпляра класса ActRelabonship (см. ниже CDA Context)

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

Таблица 19 — Допустимые значения атрибута AssignedAuthor.classCode (CNE)

Ков

Описание

ASSIGNED (уполномочен) [по умолчанию)

Роль агента, в которой исполняющая сущность выступает как служащий или как представитель контролирующей организации

Таблица 20 — Допустимые значения атрибута AuthoringDevrce.classCode (CNE)

Код

Описание

DEV (устройство) [по умолчанию)

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

Таблица 21 —Допустимые значения атрибута AuthoringOevice.determinerCode (CNE)

Код

Описание

INSTANCE (экземпляр) [по умолчанию)

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

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

Таблица 22 — Допустимые значения атрибута MaintainedEntity.classCode (CNE)

Код

Описание

MNT (эксплуатируемая сущность) [по умолчанию]

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

5.4.2.2.3 Участник custodian (обладатель документа)

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

Участие обладателя удовлетворяет определению ответственности, приведенному в данном стандарте (см. 5.1.1 «Что такое АКД»). Поскольку АКД является стандартом передачи документов, а форма передаваемого документа может отличаться от исходной формы заверенного документа, то под обладателем понимается организация, несущая ответственность за исходный документ.

Код

Описание

CST (обладатель) [по умолчанию]

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

Обладателем является организация, исполняющая роль назначенного обладателя (класс AssignedCustodian). Ответственной организацией (класс CustodianOrganization) является сущность, контролирующая роль назначенного обладателя. Атрибут CustodianOrganization.id обязателен.

Таблица 24 —Допустимые значения атрибута AssignedCustodian.classCode (CNE)

Код

Описание

ASSIGNED (уполномочвтзя) [по умолчанию]

Роль, в которой исполняющая сущность выступает как служащий или как представитель контролирующей организации

Таблица 25 — Допустимые значения атрибута CustodianOrganization.classCode (CNE)

Код

Описание

ORG (организация) [по умолчанию]

Социальная структура или юридическое лицо, созданное людьми

Таблица 26 — Допустимые значения атрибута CustodianOrganization.determinerCode{CNE)

Код

Описание

INSTANCE (экземпляр) [по умолчанию]

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

S.4.2.2.4 Участник dataEnterer (оператор по вводу данных)

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

Таблица 27 — Допустимые значения атрибута dataEnterer. type Code (CNE)

Код

Описание

ENT (оператор по вводу данных)

[по умолчанию]

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

Таблица 28 — Допустимые значения атрибута dataEnterer.contextControlCode (CNE)

Код

Описание

ОР (замещающая, распространяемая) [по умолчанию]

Ассоциация участника, замещающая ассоциацию с тем же значением атрибута typeCode. Эта замещающая ассоциация будет распространяться на действия-потомки. которые связаны с данным экземпляром класса Act с помощью экземпляра класса AdRelationship (см. ниже СОА Context)

5.4.2.2.5    Участник encounterParticipant (участник посещения)

Описание класса encounterParticipant см. в 5.4.2.3.5.

5.4.2.2.6    Участник informant (информатор)

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

Коя

Описание

INF (информатор) [по умолчанию]

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

Табл ииа 30 — Допустимые значения атрибута >nformant.contextControlCode (CNE)

Коя

Описание

ОР (замещающая, распространяемая) [по умолчанию]

Ассоциация участника, замещающая ассоциациюс тем же значением атрибута typeCode. Эта замещающая ассоциация будет распространяться на действия-потомки, которые связаны сданным экземпляром класса Act с помощью экземпляра класса ActRelabonship (см. ниже CDAContext)

Источником информации может быть лицо е одной из двух ролей. Роль RelatedEnbty используется для того, чтобы представить информатора, которому не присвоен идентификатор rote.id (например, родителя или человека с улицы). В этом случае информатор имеет некоторое формальное или персональное отношение к пациенту. Для этой роли нет контролирующей сущности, поскольку подразумевается, что пациент всегда является неявным контролером. Для описания характера отношения информатора к пациенту может быть использован атрибут RelatedEntity.code. Роль AssignedEntity используется для идентифицированного информатора, и должна контролироваться какой-либо организацией.

Таблица 31 —Допустимые значения атрибута RelatedEntity.classCode (CNE)

Код

Описание

Любой подтип домена RoleClassMutual Relationship

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

Допустимые значения составляют домен RoleClassMulualRelationship

5.4.2.2.7 Участник informationRecipient (получатель информации)

Содержит информацию о получателе документа.

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

Таблица 32 — Допустимые значения атрибута informationReciptent.typeCode (CNE)

Коя

Описание

PRCP (основной получатель) [по умолчанию]

Основной получатель документа

TRC (вторичный получатель)

Вторичный получатель документа

Если получателем является лицо, исполняющее роль назначенного получателя (класс IntendedRedpient), то сущностью, исполняющей эту роль, является физическое лицо (класс Person), которое может контролироваться организацией (класс Organization). Если получателем является организация. то атрибуту IntendedReapient.tiassCode присваивается значение «ASSIGNED*, и признаком такого получателя является указание контролирующей организации без указания исполнителя роли. Если е качестве получателя должна быть указана медицинская карта, то атрибуту IntendedRecipient. classCode присваивается значение «HLTHCHRT». В этом случае исполнитель роли не указывается, а указание контролирующей организации не является обязательным.

Коя

Описание

ASSIGNED (уполномоченная) [по умолчанию]

Роль, а которой исполняющая сущность выступает как служащий или как представитель контролирующей организации

HLTHCHRT (медицинская карта)

Роль, в которой исполняющей сущностью является медицинская карта, принадлежащая контролирующей организации

5.4.2.2.8 Участник legalAuthenticator (юридически ответственное лицо)

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

Стандарт АКД определяет структуру передаваемых клинических документов. Если в целях пере* дачи исходный документ был преобразован в АКД-документ. то заверяется исходный документ и этот факт отражается в передаваемом АКД-документе. АКД-документ может быть не заверенным, заверенным или юридически заверенным. Не заверенное состояние имеет тот документ, в котором отсутствует информация о заверении (то есть отсутствует информация о контролере и юридически ответственном лице).

Хотя электронные подписи не передаются в АКД-документе. для заверения и юридического заверения требуется, чтобы документ было подписан ответственным лицом вручную или электронным способом. У атрибута legalAuthenticator есть обязательное свойство legalAuthenticator .time. означающее дату и время заверения, а также обязательное свойство legalAuthenticator.signatureCode. которое служит признаком наличия подписи и сохранения подписанного документа.

Таблица 34 —Допустимые значения атрибута legalAuthenticator.typeCode (CNE)

Коя

Описание

1_А (юридически ответственное лицо) [по умолчанию]

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

Таблица 35 — Допустимые значения атрибута iegalAuthenticator.signatureCode (CNE)

Код

Описание

S (подписан)

Документ подписан и сохранен

X (подпись требуется) (запрещен)

В первом выпуске АКД контролер мог быть фактическим («S») или планируемым («X»). Во втором выпуске АКД предусмотрен только фактический контролер, поэтому значение «X» запрещено

Таблица 36 — Допустимые значения атрибута tegalAuthenticator.contextControlCode (CNE)

Км

Описание

ОР (замещающая, распространяемая) [по умолчанию]

Ассоциация участника, замещающая ассоциацию с тем же значением атрибута typeCode. Эта замещающая ассоциация будет распространяться на действия-потомки. которые связаны с данным экземпляром класса Act с помощью экземпляра класса ActReiationship (см. 5.4.4)

Юридически ответственным является лицо в роли представителя организации (класс AssignedEntity). то есть лицо, которому контролирующая организация назначила определенную роль. Сущностью, выполняющей роль, является физическое лицо (класс Person). Сущностью, контролирующей роль, является организация (класс Organization).

5.4.2.2.Э Участник participant (другой участник)

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

Код

Описание

Любой подтип домена Partici pationType

Допустимые значения составляют домен ParticipabonType

Таблица 38 — Допустимые значения атрибута parttcipant.contextControTCode {CNE)

Код

Описание

ОР (замещающая, распространяемая) (по умолчанию]

Ассоциация участника, замещающая ассоциацию с тем же значением атрибута typeCode. Эта замещающая ассоциация будет распространяться на действия-потомки. которые связаны с данным экземпляром класса Act с помощью экземпляра класса ActRelationship (см. 5.4.4)

Участником является физическое лицо или организация в роли участвующей сущности {класс AssociatedEntity). Сущностью, выполняющей роль, является физическое лицо (класс Person). Сущностью. контролирующей роль, является организация (класс Organization).

Таблица 39 — Допустимые значения атрибута AssociatedEntity.classCode (CNE)

Код

Описание

Любой подтип домена RoleClassAssociative

Допустимые значения составляют домен RoleClassAssociative

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

5.4.2.2.10    Участник performer (исполнитель)

Описание участника-ислолнителя см. в 5.4.2.3.2.

5.4.2.2.11    Участник recordTarget (целевая медицинская карта)

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

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

Значение атрибута recordTarget задается в заголовке документа, распространяется на вложенное содержание и замещению не подлежит (см. 5.4.4).

Таблица 40 — Допустимые значения атрибута recordTarget.typeCode (CNE)

Код

Описание

RCT (целевая медицинская карга) [по умолчанию]

Целевая медицинская карта, в которую помещается информация о данном действии

Таблица 41 —Допустимые значения атрибута recordTarget-contextControtCode (CNE)

Код

Описание

ОР (замещающая, распространяемая) [по умолчанию]

Ассоциация участника, замещающая ассоциацию с тем же значением атрибута typeCode. Эта замещающая ассоциация будет распространяться на действия-потомки. которые связаны с данным экземпляром класса Act с помощью экземпляра класса ActRelabonships (см. 5.4.4)

Целевая медицинская карта (recordTarget) представлена как отношение между физическим лицом и организацией, в котором лицо выполняет роль пациента. Сущностью, выполняющей роль, является пациент (класс Patient). Сущностью, контролирующей роль, является организация (класс Organization). Уникальным идентификатором пациента является значение атрибута PatientRoie.id.

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

Таблица 42 — Допустимые значения атрибута PatientRote.classCode {CNE)

Коя

Описание

РАТ (пациент) [по умолчанию]

Лицо, получающее медицинскую помощь у медицинской организации

Таблица 43 — Допустимые значения атрибута Pabent.dassCode (CNE)

Коя

Описание

PSN (физическое лицо) [по умолчанию]

Живой организм вида homo sapiens

Таблица 44 —Допустимые значения атрибута Patient.deterrmnerCode (CNE)

Коя

Описание

INSTANCE (экземпляр) [по умолчанию]

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

Способности пациента к общению на определенном языке могут быть представлены ассоциированным классом LanguageCommunication. Место рождения пациента представляется как отношение пациента к определенному месту. Класс Birthplace (место рождения) является ролью места (класс Place), контролируемой пациентом (класс Patient).

Таблица 45 — Допустимые значения атрибута Birthptace.dassCode (CNE)

Коя

Описание

BIRTHPL (место рождения) (по умолчанию]

Связывает экземпляр класса Place. 8 котором указано место рождения, с экземпляром класса LivingSubject. описывающим живой организм

Таблица 46 — Допустимые значения атрибута Place.classCode (CNE)

Коя

Описание

PLC (место)

[по умолчанию]

Физическое место или участок с содержащимися в них структурами

Таблица 47 —Допустимые значения атрибута Place.determ in erC ode (CNE)

Коя

Описание

INSTANCE

(экземпляр)

[по умолчанию]

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

Опекун пациента — это физическое лицо или организация в роли опекуна (класс Guardian). Сущностью, выполняющей рольопекуна. является лицо (класс Person) или организация (класс Organization). Контролирующей сущностью является пациент (класс Patient).

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

Код

Описание

GUARD (опекун) [по умолчанию]

Сущность (исполнитель), действующая или уполномоченная действовать в качестве опекуна пациента

5.4.2.2.12    Участник responsibteParty (ответственная сторона)

Описание участника responsibleParty (ответственная сторона) см. в 5.4.2.3.S.

5.4.2.2.13    Сценарии участия

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

В других случаях участниками, указанными в заголовке АКД-документа. являются разные лица. В таблице 49 приведены примеры разных сценариев с разными участниками.

Таблица 49 — Сценарии выполнения ролей, идентифицированных в заголовке АКД-документа

1 Лечащий врач осматривает пациента как консультант, диктует результат осмотра, затем подписывает напечатанный текст

Автор

Лечащий врач

Участник посещения

Лечащий врач (typeCode = «CONS»)

Юридически ответственное лицо

Лечащий врач

2 Лечащий врач осматривает пациента, диктует результат осмотра. Заведующий отделением подписывает напечатанный текст

Автор

Лечащий врач

Юридически ответственное лицо

Заведующий отделением

3 Ординатор осматривает пациента вместе с лечащим врачом. Ординатор диктует результат осмотра и подписывает напечатанный текст. Лечащий врач ставит на документе вторую подпись

Автор

Ординатор

Контролер

Контролер

Участник посещения

Лечащий врач (typeCode = «ATND»)

Юридически ответственное лицо

Лечащий врач

4 Ординатор осматривает пациента вместе с лечащим врачом. Лечащий врач диктует результат осмотра и подписывает напечатанный текст. Заведующий отделением ставит вторую подпись

Автор

Ординатор

Контролер

Ординатор

Участник посещения

Лечащий врач (typeCode = «ATND»)

Юридически ответственное лицо

Заведующий отделением

5. Ординатор осматривает пациента вместе с лечащим врачом. Ординатор диктует результат осмотра и уходит в отпуск. Заменяющий его ординатор подписывает напечатанный документ. Лечащий врач ставит вторую подпись

Автор

Ординатор

Контролер

Заменяющий ординатор

Участник посещения

Лечащий врач (typeCode = «ATND»)

Юридически ответственное лицо

Лечащий врач

Окончание таблицы 49

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

Автор

Ординатор

Контролер

Другой ординатор

Участник посещения

Лечащий врач (typeCode = «ATND»)

Юридически ответственное лицо

Заведующий отделением

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

Автор

Лечащий врач

Юридически ответственное лицо

Лечащий врач

Ассистент оперирует пациента вместе с хирургом. Хирург диктует дневник операции и подписывает напечатанный текст

Автор

Хирург

Контролер

Отсутствует (не должен быть указан)

Юридически ответственное лицо

Хирург

Исполнитель

Хирург (typeCode = «PPRF»}

Исполнитель

Ассистент (typeCode = «SPRF»)

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

5.4.2.3 Отношения, указанные е заголовке

В этом подразделе описаны классы, связанные с корневым классом ClimcalDocument с помощью ассоциации ActRelationship.

5.4.2.3.1 ParentDocument (родительский документ)

Атрибут ParentDocument используется для указания документа-источника, к которому были применены действия пересмотра, дополнения или преобразования. Свойство ParentDocumenUext имеет тип данных ED. С его помощью можно указать тип MIME родительского документа, но содержание этого документа не должно в него вкладываться, поэтому использование свойства ParentDocument.text.BIN запрещено.

Допустимые значения кода отношения текущего документа к родительскому (relatedDocument. typeCode) приведены в таблице 50.

Таблица 50 — Допустимые значения атрибута relatedDocument.typeCode (CNE)

Код

Описание

APND

Текущий документ является дополнением родительского документа (append)

RPLC

Текущий документ является заменой родительского документа (replace)

XFRM

Текущий документ является преобразованием родительского документа (transform)

К родительскому документу, совместимому со спецификацией АКД. может идти от других документов единственная связь типа «APND». единственная связь типа «RPLC». единственная связь типа «XFRM». пара связей типа «XFRM» и «RPLC» либо пара связей «XFRM» и «APND». Никакие другие сочетания связей не допускаются.

Код

Описание

DOCCUN (клинический документ) [по умолчанию)

Клинический документ

Таблица 52 — Допустимые значения атрибута ParentDocumentmoodCode (CNE)

Код

Описание

EVN (событие) [по умолчанию]

Фактически произошедшее событие

Идентификация документа, его пересмотры и дополнения

Клинический документ может быть заменен новым документом или дополнен им.

Заменяющий документ представляет собой новую версию родительского документа. Родитель* ский документ считается устаревшим, но система может сохранить его для истории или для отчет* ности. На замененный родительский документ делается ссылка relatedDocument. у которой свойство relatedDocumenUypeCode имеет значение «RPLC» (замена). Примером может служить протокол исследования. содержащий ошибку и затем замененный на исправленный протокол.

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

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

АКД-документы могут содержать также атрибуты идентификатора группы документов (ClinicalDocument.setld) и номера версии (ClinicalDocument.versionNumber). которые в совокупности обеспечивают поддержку схемы идентификации документа и его версионности. используемой е некоторых системах управления документами. В соответствии с этой схемой все документы в цепочке замен имеют одинаковый идентификатор группы документов ClinicalDocument.setld и отличаются последовательно возрастающими номерами версий ClinicalDocument.versionNumber. 8 исходном документе кроме уникального идентификатора самого документа. ClinicalDocument.id. должен быть указан новый уникальный идентификатор группы документов ClinicalDocument.setld. а номер версии ClinicalDocument. versionNumber должен иметь значение 1. (Необходимо иметь в виду, что при замене документа номер версии должен увеличиться на 1. но по местным требованиям приращение номера может быть иным.)

Примеры этих отношений между документами показаны на рисунке 1. Типичным сценарием являются простая замена (например, документ с идентификатором ClinicalDocument.id «1.2.345.6789.266» заменяет документ с идентификатором C!inicalDocument.id «1.2.345.6789.123») и простое дополнение (например, документ с идентификатором Clinical Documented «1.2.345.6789.456» дополняет документ с идентификатором ClinicalDocument.id «1.2.345.6789.123»). Можно предвидеть и более сложные сценарии, например, замену дополнения (документ с идентификатором ClinicalDocument. id «1.2.345.6789.224» заменяет документ с идентификатором ClinicalDocument.id «1.2.345.6789.456». который в свою очередь является дополнением документа с идентификатором ClinicalDocument. id «1.2.345.6789.123»). В этом случае для чтения заменяющий документ с идентификатором CtinicalDocumentid «1.2.345.6789.224» должен быть показан как дополнение документа с идентификатором ClinicalDocument.id «1.2.345.6789.123». Другим примером служит дополнение замененного документа (документ с идентификатором ClinicalDocumentid «1.2.345.6789.456» дополняет документ с идентификатором ClinicalDocumentid «1.2.345.6789.123», который заменен на документ с идентификатором ClinicalDocument.id «1.2.345.6789.266». В этом случае для чтения дополняющий документ должен быть показан вместе с заменяющим документом (например, документ с идентификатором ClinicalDocumentid «1.2.345.6789.456» должен быть показан как дополнение документа с идентификатором CtinicalDocumentid «1.2.345.6789.266».

Преобразования документа

АКД-документ может быть получен в результате преобразования другого документа, то есть был получен в результате машинного отображения из какого-либо иного формата (например, из формата структурированного протокола лучевого исследования DICOM SR). 6 этом случае атрибут relatedDocument.typeCode должен иметь значение «XFRM».

При правильном преобразовании человеко-читаемое содержание документа не должно претерпеть никаких изменений. По местным правилам преобразованный протокол может заменить исходный, но обычно это не практикуется. Если это все же произошло, то должна использоваться дополнительная связь с типом «RPLC». Отношение «XFRM» может использоваться и в том случае, если документ в местном формате преобразуется в АКД-документ для передачи последнего. В этом случае целевым значением связи «XFRM» будет идентификатор местного документа.

Id- "1.2.349.6789.123' ««id = *1.2.345.6789.35*

>ti*ia*Runliei — *J*

etiectiveiune - '19990903'


змею


Допо/ы«мис

Ids *1.2.319.6709.136" 8«LId - '1.2. JO.*789.689* *s«rsion№Mber -•ffartivaTi»» = "19990901 • relationship - APR»* parent

Id - "1.2.345.8709.123" eetld - *1.2.319.6709.39* vereionHasdxrr — *1'


Ids *1.2.313.6709.2(90* 8etld> *1.2.349.6789.39* rcrstanBamb^r - '7' eHeetieeTu»? = *19990901' relationship - 'RPLC parent

Id - *1.2.345.6789.123' setld- *1.2.319.6789.39' versionlhsnber — *1"


Замен*


Допо/мсмие


Id = *1.2.919.0709.224* •etld - *1.2.349.6789.689" eersionNanber - '2" effectieeTuw = *19990905" relationship - *RPI.C* parent

Id- *1.2.345.6789.436* •etld «*1.2.319.6789.609 vereionlhssber — "1‘



Ids *1.2.319.6789.997 •etld - “1.2.343.«789.398* versionHunber - "1* effective?!»* - "19990905' relationship = "АРКО* parent

Id - "1.2.349.6709.496" eetld - *1.2.345.6709.689' eerstonBtanber -


id - "1.2.345.6709.448' •etld- '1.2.343.6709.33' «etsionMuafcer = '3' effectloeTLme - *10098903* relationship = 'ftPLC" parent

1d - '1.2.343.6789.266' «etld s *1.2.349.6789.35* vecstanffianber — '2"


Рисунок 1 — Отношения дополнения и замены

5.4.2.3.2 ServiceEvent (событие медицинской помощи)

Этот класс представляет основное документируемое действие, например, колоноскопию или ап-пемдэктомию.

В некоторых случаях содержание класса ServiceEvent производится от типа клинического документа. указанного в атрибуте ClinicalDocument.code. например, этот атрибут имеет значение «Сбор анамнеза и физикальный осмотр» и документируемой процедурой является сбор анамнеза и физи-кальный осмотр. Содержание класса ServiceEvent может представлять собой дальнейшую специализацию действия, подразумеваемого типом документа, например, атрибут Clinical Document.code имеет значение «Протокол процедуры», а документируемой процедурой является колоноскопия. Если класс ServiceEvent присутствует, то его значение должно быть эквивалентно типу документа, или служить его дальнейшим уточнением, но отнюдь не конфликтовать с ним. поскольку это может создать двусмысленную ситуацию.

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

Таблица 53 — Допустимые значения атрибута documentaUonOf.typeCode (CNE)

Код

Описание

DOC (документ) [по умолчанию]

Текущий документ является документированием события, идентифицированного в классе ServiceEvent

Таблица 54 —Допустимые значения атрибута SecviceEventxIassCode (CNE)

Код

Описание

ACT (действие) [по умолчажю]

Медицинская помощь

Любой подтип типа ACT

Допустимые значения берутся из словарного домена ActClassRoot

Таблица 55 — Допустимые значения атрибута ServiceEvenlmoodCode (CNE)

Код

Описание

EVN (событие) [по умолчанию]

Фактически произошедшее событие (event), то есть состоявшееся действие документирования того, что уже произошло, а не требование, намерение, планирование или обещание подготовки документа

Участником performer (исполнитель) является медицинский работник, который фактически оказал медицинскую помощь, указанную в классе ServiceEvent. Свойство performer.time может использоваться для указания того времени, в течение которого исполнитель принимал непосредственное участие в документируемом действии. Свойство performer.functionCode может использоваться для указания дополнительных деталей о функции исполнителя (например, медсестра, которая берет мазок, третий ассистент и т. д.). Значения этого свойства берутся из словарного домена ParticipationFunction, имеющего квалификатор расширяемости CWE.

Таблице 56 — Допустимые значения атрибута performer.typeCode (CNE)

Код

Описание

PRF (исполнитель)

Лицо, фактически оказавшее медицинскую помощь

PPRF (основной исполнитель)

Основной исполнитель медицинской помощи, указанной в классе ServiceEvent

SPRF (другой исполнитель)

Лицо, непосредственно присутствующее при оказании медицинской помощи, указанной в классе ServiceEvent. и существенно участвующее в ней. например, ассистент, инженер, помощник или иной исполнитель

Исполнителем является сущность в роли ассоциированной сущности (класс AssignedEntity). Ассоциированной сущностью является лицо, которому эта роль назначена контролирующей сущностью. Сущностью, исполняющей роль, является физическое лицо (класс Person), а контролирующей сущностью — организация (класс Organization).

5.4.2.3.3 Order (заказ)

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

Рентгенолог анализирует рентгеновский снимок и составляет протокол исследования. Идентификатор заказа исследования передается в классе Order, код выполненного рентгенологическое исследования передается в классе ServiceEvent. а код документа ClinicalDocument.code должен иметь значение «Про* токол рентгенологического исследования».

Таблица 57 — Допустимые значения атрибута inFulfillmentOf.typeCode (CNE)

Код

Описание

FLS (выполнение) [по умолчанию]

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

Таблица 58 — Допустимые значения атрибута Order.classCode (CNE)

Код

Описание

ACT (действие) [по умолчанию]

Медицинская помощь

Любой подтип типа ACT

Допустимые значения берутся из словарного домена ActClassRool

Таблица 59 — Допустимые значения атрибута Order.moodCode (CNE)

Код

Описание

RQO (заказ)

[по умолчанию]

Требование или заказ документированного действия

5.4.2.3.4 Consent (согласие)

В экземплярах этого класса передается информация о согласиях, ассоциируемых с данным до* кументом. Тип согласия (например, согласие на выполнение медицинской помощи, указанной в связан* ном классе ServiceEvent. согласие на передачу третьей стороне информации, содержащейся в данном документе) передается в атрибуте Consent.code. Согласия, информация о которых передается в заголовке документа, должны быть свершившимся фактом (атрибут Consent.statusCode должен иметь значение «completed») и должны быть сохранены.

Таблица 60 — Допустимые значения атрибута authonzabon.typeCode (CNE)

Код

Описание

AUTH (разрешает) [по умолчанию]

Согласие разрешает или сертифицирует действия, указанные в текущем документе

Таблица 61 —Допустимые значения атрибута Consent.dassCode (CNE)

Код

Описание

CONS (согласие)

Класс Consent представляет информированные согласия и законные медицинские со*

[по умолчанию]

глашения

Таблица 62 —Допустимые значения атрибута Consent.mo odCode (CNE)

Код

Описание

EVN (событие) [по умолчанию]

Фактически произошедшее событие

Таблица 63 — Допустимые значения атрибута ConsenlstatusCode (CNE)

Код

Описание

completed

Согласие, информация о котором передается в АКД-докуменге, является свершившимся фактом и сохранено

5.4.2.3.5 EncompassingEncounter (посещение)

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

В некоторых случаях идентификация места оказания медицинской помощи вытекает из типа документа. передаваемого в атрибуте Clinical Document.code, например «Дневниковая запись Клиники диабета». Идентификация места оказания медицинской помощи может быть также передана в атрибуте HealthCareFacility.code. Если этот атрибут присутствует, то его значение должно быть эквивалентно значению. вытекающему из типа документа, или служить его дальнейшим уточнением (например, атрибут ClinicalDocumentcode имеет значение «Дневниковая запись», а атрибут HealthCareFacility.code — значение «Клиника кардиологии»), но отнюдь не конфликтовать с ним. поскольку это может создать двусмысленную ситуацию.

Атрибут EncompassingEncounter.dischargeDispositionCode может использоваться для указания типа выписки пациента из больницы (например, выписан домой, скончался, отказался от медицинской помощи и т. д.).

Таблица 64 —Допустимые значения атрибута compooentOf.typeCode (CNE)

Код

Описание

COMP (компонент) [no умолчанию]

В текущем документе документируются события, произошедшие при посещении, идентифицируемом классом EncompassingEncounter

Таблица 65 — Допустимые значения атрибута EnoompassingEncounter.classCode (CNE)

Код

Описание

ENC (посещение} [по умолчанию]

Контакт пациента с одним или несколькими медицинскими работниками, в процессе которого пациенту оказана медицинская помощь или проведена оценка состояния его здоровья

Таблица 66 — Допустимые значения атрибута EnoompassingEncounter.moodCode (CNE)

Код

Описание

EVN (событие) [по умолчанию]

Фактически произошедшее событие

УчастникЮса(1ол(местонахождение)связывает медицинскуюорганиэацию (KnaccHealthCareFaciiity) и посещение для указания, где оно имело место. Сущностью, исполняющей роль медицинской организации. является местонахождение (класс Place). Сущностью, контролирующей эту роль, является организация (класс Organization).

Место посещения (например, клиника кардиологии, поликлиника, реабилитационный центр, дом престарелых) может быть передано в атрибуте HealthCareFacility.code. Место посещения и физическое местонахождение — не одно и то же. Между местом посещения и физическим местонахождением существует отношение многие-ко-многим. Например, конкретный кабинет может оказаться местом посещения клиники кардиологии в один день и местом посещения поликлиники — в другой. А клиника кардиологии сегодня может иметь одно физическое местонахождение, а завтра — другое.

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

Таблица 67 — Допустимые значения атрибута location, type Code (CNE)

Код

Описание

LOC (местонахождение) [по умолчанию]

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

Км

Описание

SDLOC (место оказания медицинской помощи) [по умолчанию]

Роль места, в котором может быть оказана медицинская помощь

Любой подтип домена RoieCtassSa-rvfceDeliveryLocabon

Допустимые значения берутся из словарного домена RoleClassService-DeliveryLocation

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

Таблица 69 — Допустимые значения атрибута responsibteParty.typeCode (CNE)

Км

Описание

RESP Ответственная сторона)

[по умолчанию]

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

Ответственной стороной (класс responsibleParty) является лицо или организация в роли ассоциированной сущности (класс AssignedEntity). Ассоциированной сущностью является лицо, которому эта роль назначена контролирующей сущностью. Сущностью, исполняющей роль, является физическое лицо (класс Person), а контролирующей сущностью — организация (класс Organization).

Если ответственной стороной является организация, то признаком этого является значение атрибута AssignedEntity.classCode. равное «ASSIGNED», и указание контролирующей организации без указания исполнителя роли.

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

Таблица 70 — Допустимые значения атрибута encounterPartiopanLtypeCode (CNE)

Км

Описание

АДМ (принимающий врач)

Врач, принимающий пациента при поступлении в стационар

ATND (лечащий врач)

Основной врач, координирующий лечение пациента во время посещения

CONS (консультант)

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

DIS (выписывающий врач)

Врач, отвечающий за выписку пациента из стационара

REF (направляющий врач)

Лицо, которое по итогам посещения направляет пациента к другому врачу для оказания медицинской помощи

Участником encounterParticipant (участник посещения) является сущность в роли уполномоченной сущности (класс AssignedEntity). Уполномоченной сущностью является лицо, которому контролирующая организация назначила эту роль. Сущностью, исполняющей роль, является физическое лицо (класс Person). Сущностью, контролирующей роль, является организация (класс Organization).

5.4.3 Тело документа

5.4.3.1 Варианты структуры тела документа

Тело АКД-документа может представлять собой неструктурированный блок двоичных данных или содержать структурирующую разметку. Каждый АКД-документ имеет ровно одно тело, ассоциируемое с классом ClinicalDocument с помощью связи component.

Код

Описание

СОМР (компонент) [по умолчанию]

Ассоциированное тело документа является компонентом документа

5.4.3.1.1 NonXMLBody (тело, не являющееся XML-фрагментом)

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

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

Таблица 72 — Допустимые значения атрибута NonXMLBody.classCode (CNE)

Км

Описание

DOCBODY (тело документа) [по умолчанию]

Контекст, отличающий тело документа от заголовка документа

Таблица 73 — Допустимые значения атрибута NonXMLBody.moodCode (CNE)

Км

Описание

EVN (событие) [по умолчанию]

Фактически произошедшее событие

Таблица 74 —Допустимые значения атрибута NonXMLBody.confidenbatityCode (CWE)

Км2

Описание

N (обычный) (codeSystem = 2.16.840.1.11388.5.25)

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

R (средний) (codeSystem = 2.16.840.1.11388.5.25)

Средние ограничения доступа, например, документ могут читать только медицинские работники, имеющие непосредственное отношение к текущей медицинской помощи пациенту

V (высокий) (codeSystem = 2.16.840.1.11388.5.25)

Высокие ограничения доступа, заданные политикой конфиденциальности

5.4.3.1.2 StructuredBody (структурированное тело)

Класс StructuredBody представляет тело АКД-документа. состоящее из одного или нескольких разделов (класс Section).

Таблица 75 — Допустимые значения атрибута StruciuredBody.classCode (CNE)

Км

Описание

DOCBODY (тело документа) [по умолчанию]

Контекст, отличающий тело документа от заголовка документа

Таблица 76 — Допустимые значения атрибута Structured Body.mood Code (CNE)

Км

Описание

EVN (событие) [по умолчанию]

Фактически произошедшее событие

Код31

Описание

N (обычный) (codeSystem = 2.16.840.1.11388.5.25)

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

R (средний) (codeSystem = 2.16.840.1.11388.5.25)

Средние ограничения доступа, например, документ могут читать только медицинские работники, имеющие непосредственное отношение к текущей медицинской помощи пациенту

V (высокий) (codeSystem = 2.16.840.1.11388.5.25)

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

Класс StructuredBody ассоциируется с одним или несколькими экземплярами класса Section с по* мощью связи component.

Таблица 78 — Допустимые значения атрибута component, typeCode (CNE)

Код

Описание

СОМР (компонент) [по умолчанию]

Ассоциированное тело документа является компонентом документа

5.4.3.2 Атрибуты класса Section

Разделы документа могут быть вложенными. В разделе может быть переопределен контекст, наследуемый от заголовка (см. 5.4.4). Раздел может содержать повествовательный блок и подразделы.

В схеме АКД-докумемтов к элементу section добавлен атрибут Ю. имеющий тип данных XML ID. Этот атрибут является целевым в ссылках <linkHtml> (см. 5.4.3.5.2). Все значения атрибута типа XML ID должны быть уникальны в пределах документа (в соответствии со спецификацией XML организации W3C).

Таблица 79 — Допустимые значения атрибута Secbon.dassCode (CNE)

Км

Описание

DOCSECT (раздел документа) [по умолчанию]

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

Таблица 80 — Допустимые значения атрибута Section, mood Code (CNE)

Км

Описание

EVN (событие) [по умолчанию]

Фактически произошедшее событие

5.4.3.2.1    Атрибут Section.id

Содержит уникальный идентификатор конкретного экземпляра раздела документа.

5.4.3.2.2    Атрибут Section.code

Содержит код. указывающий вид раздела (например, «Жалобы», «Осмотр», «Оценка состояния»). Допустимый набор значений берется из классификатора LOINC и имеет квалификатор расширяемости CWE.

5.4.3.2.3    Атрибут Section.tide

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

5.4.3.2.4    Атрибут Section.text

Содержит повествовательное содержание, предназначенное для визуализации. Его называют также повествовательным блоком АКД-документа. Детальные сведения см. в 4.3.5.

5.4.3.2.5    Атрибут Section.confidentiatityCode

Значение атрибута Sectton.confidentialityCode переопределяет код конфиденциальности, наследуемый от класса StructuredBody (структурированное тело). Детальные сведения см. в 5.4.4.

Таблице 81 —StructuredBody.confidentialilyCode(CWE)

Код4"

Описание

N (обычный) (codeSystem = 2.16.840.1.11388.5.25)

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

R (средний) (codeSystem = 2.16.840.1.11388.5.25)

Средние ограничения доступа, например, документ могут читать только медицинские работники, имеющие непосредственное отношение к текущей медицинской помощи пациенту

V (высокий) (codeSystem = 2.16.840.1.11388.5.25)

Высокие ограничения доступа, заданные политикой конфиденциальности

5.4.3.2.6 Атрибут Section.languageCode

Указывает код языка, на котором представлены строковые данные раздела (применяется как к содержанию, так и к значениям атрибутов). Значениями атрибута являются идентификаторы языка, определенные в документе IETF (Internet Engineering Task Force) RFC 3066 (no ред. H. Atvestrand. 1995). заменяющем устаревший документ RFC 1766. В стандартах HL7 для этих кодов используется система кодирования 2.16.840.1.113883.6.121.

Значение атрибута Section.languageCode переопределяет код языка, наследуемый от класса StructuredBody (структурированное тело). Детальные сведения см. в 5.4.4.

5.4.3.3 Участники раздела

5.4.3.3.1    Участник author (автор)

Участник author, описанный выше в подразделе 0

«Участник author (автор)» может быть приписан разделу. В этом случае он переопределяет авторство. наследуемое от заголовка АКД-документа.

5.4.3.3.2    Участник informant (информатор)

Участник informant, описанный выше в подразделе 5.4.2.2.6 «Участник informant (информатор)», может быть приписан разделу. В этом случае он переопределяет источники информации, наследуемые от заголовка АКД-документа.

5.4.3.3.3    Участник subject (субъект)

Участник subject представляет основной субъект содержания подразделов документа. В большинстве случаев им будет то лицо, чья медицинская карта указана в атрибуте recordTarget (см. подраздел 5.4.2.2.11 «Участник recordTarget (целевая медицинская карта)»), но он может и отличаться, как. например. при акушерском ультразвуковом исследовании, когда субъектом является плод.

Участник subject может быть приписан как разделу, так и подразделу АКД-документа. Он наследуется вложенными компонентами, если только не переопределен в них. Субъектом документа считается пациент.

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

Таблица 82 — Допустимые значения атрибута subject.typeCode (CNE)

Код

Описание

SBJ (субъект) [по умолчанию]

Основной субъект документированных действий

Код

Описание

ОР (замещающая, распространяемая) [по умолчанию)

Ассоциация участника, замещающая ассоциацию с тем же значением атрибута typeCode. Эта замещающая ассоциация будет распространяться на действия-потомки. которые связаны с данным экземпляром класса Act с помощью экземпляра класса ActRelationships (см. 5.4.4}

Таблица 84 —Допустимые значения атрибута RelatedSubject.classCode {CNE)

Код

Описание

PRS (персональное отношение)

[по умолчанию]

Субъект имеет персональные отношения с пациентом. Тип персональных отношений передается в атрибуте SubjectRole.code и берется из расширяемого словарного домена PersonalRelationshipRoleType (с квалификатором CWE). Контролирующей сущностью всегда предполагается пациент

РАТ (пациент)

Субъектом раздела является пациент, идентифицированный в атрибуте recofdTargel заголовка АКД-докумвнта

Таблица 85 — Допустимые значения атрибута SubjectPerson.classCode (CNE)

Код

Описание

PSN (физическое лицо) [по умолчанию)

Живой организм вида homo sapiens

Таблица 86 — Допустимые значения атрибута SubjectPerson.determinefCode (CNE)

Код

Описание

INSTANCE (экземпляр) [по умолчанию)

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

5.4.3.4 Отношения, указанные е разделе Section

5.4.3.4.1 Отношение component (компонент)

Отношение «компонент» используется для вложения одного раздела е другой. Контекст распространяется на вложенный раздел (см. 5.4.4).

Таблица 87 — Допустимые значения атрибута componenltypeCode (CNE)

Код

Описание

СОМР (компонент) [по умолчанию]

Вложенный раздел является компонентом внешнего раздела.

5.4.3.4.2 Отношение entry (подраздел)

Отношения между разделами и его подразделами кодируются с помощью промежуточного отношения entry.

Примечание — Обсуждение ссылок внутрь повествовательного блока и ссылок из лоеествовагвгъного блока приведены в 5.4.3.5.12.

Повествовательный блок каждого раздела, включая мультимедийное содержание, на которое есть ссылки в этом блоке, образует полное заверяемое содержание раздела. Мультимедийное содержание образуется подразделами ObservationMedia и RegionOflnterest. на которые есть ссылки в тегах <renderMuttimedia>. включенные в повествовательный блок Section.texl Это единственная ситуация, когда подразделы содержат заверяемое содержание, которое должно выводиться вместе с содержанием повествовательного блока.

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

По умолчанию отношение мееду разделом и подразделом имеет код «СОМР» (компонент). Этот вариант рассчитан на общий случай, когда единственное утверждение об отношении состоит в том. что связанные подразделы содержатся в подразделе и никакая другая семантика не подразумевается. В этом случае исходным заверяемым содержанием является повествовательный блок раздела. Подразделы АКД-документа создаются разными способами (например, автоматизированная обработка текста на естественном языке, ручная кодировка, структурированный ввод данных, при котором одновременно создаются подразделы и блок текста). Метод создания подраздела может быть указан в атрибуте участника подраздела (содержащего, например, идентификацию алгоритма обработки или лица, которое обеспечило создание подраздела). Отношения между различными подразделами (например, между двумя подразделами Observation (результат исследования) или подразделом Observation и подразделом ObservationMedia (мультимедийный результат исследования)) могут быть представлены с помощью типов отношений, определенных в 4.3.8.4.

Если подразделы содержат информацию, не являющуюся частью клинического документа, то раздел, в который они вложены, может не иметь повествовательного блока. Протокол исследования может содержать вложенную информацию, идентифицирующую подтверждающие данные, реагенты, калибраторы, а также другие сведения, которые могут использоваться для дальнейшей обработки, но не являются частью клинического содержания. Такие подразделы также связаны с разделом, используя код типа отношения «СОМР».

Код отношения «DRIV» (является производным) может использоваться в том особом случае, когда повествовательный блок полностью произведен из содержания подразделов entry. Когда протокол исследования. полностью состоящий из структурированных подразделов, преобразуется в АКД-документ. то приложение, выполняющее это преобразование, должно гарантировать, что заверяемое содержание (повествовательный блок и мультимедийные данные) является правильным и полностью обеспечивает отображение клинического содержания структурированных данных первоисточника. Тем самым, как и во всех АКД-документах. обеспечивается полнота представления повествовательного блока и мультимедийных данных как заверяемого содержания раздела. В этом случае повествовательный блок и мультимедийные данные не содержат никакой клинической информации, которой не было бы в подразделах. Примером может служить структурированный протокол акушерского ультразвукового исследования, соответствующий стандарту DICOM Structured Reporting, предоставляемый результаты в табличной форме с помощью программы, преобразующей формат DICOM Structured Reporting в повествовательный блок АКД-документа. Если атрибут typeCode отношения, связывающего такие подразделы с разделом, имеет значение «DRIV». то приложение-получатель должно исходить из того, что: 1) источником повествовательного блока являются подразделы: 2) содержание подразделов и повествовательного блока эквивалентно.

У подразделов, вложенных в один раздел, могут быть разные типы отношения с разделом. В этом случае объединение подразделов, являющихся целевыми в отношении типа «DRIV». используется для генерирования содержания повествовательного блока и эквивалентно ему по содержанию. Дополнительные подразделы, имеющие тип отношения «СОМР» и содержащиеся в том же самом разделе, не добавляют к содержанию раздела отдельную семантику.

Таблица 88 — Допустимые значения атрибута entry.typeCode (CNE)

Км

Описание

СОМР (компонент) [по умолчанию]

Соответствующий подраздел является компонентом раздела. Никакие семантические отношения не подразумеваются

DRIV (является производным)

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

5.4.3.5 Повествовательный блок раздела

Как указано в 5.1.3 «Соответствие стандарту АКД». для хранения отображаемого повествовательного содержания используется атрибут Section.text. Поэтому он называется повествовательным блоком АКД-документа.

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

Модель содержания этой схемы специально доработана вручную, чтобы обеспечить изложенные выше требования к визуализации повествовательного блока {см. подраздел 5.1.2.3 «Человекочитае-мость и визуализация документов МД»). Схема зарегистрирована в качестве типа MIME с идентификатором «text/x-til7-text+xml», являющегося фиксированным типом среды атрибута Sectton.text. Компоненты этой схемы описаны в следующих подразделах.

5.4.3.5.1 Элемент <content>

Элемент <content> используется для включения в повествовательный блок строки или текста, доступный для внешних ссылок или отображаемый специальным образом. Элемент <conten!> может быть рекурсивно вложенным, что позволяет разбивать строку или неформатированный текст на любые желаемые порции.

Элемент <content> содержит необязательный идентификатор, который может служить целью ссылки. Все значения атрибута типа XML ID должны быть уникальны в пределах документа (в соответствии со спецификацией XML организации W3C). В компоненте onginalText (исходный текст) атрибута модели RIM, входящем в любой подраздел АКД-документа. может быть указана явная ссылка на идентификатор элемента <content>. тем самым обозначающая ту часть повествовательного блока, которая ассоциируется с этим атрибутом подраздела.

Пример 5 —

<section>

<сode code=”10153-2" codeSystem-"2.1 б.840.1.113863.6. f ” codeSystemName=”LOINC”/>

<Ш1е>Анамнез заболевания </M/e>

<text>

Имеющееся заболевание; <сол(ел( Ю="а1">Астма</соп1епТ>

</text>

<entry>

<observatton classCode="OBS" moodCodes"EVN”>

<code code= "195967001" codeSystem-"2.16.840.1. f 13883.6.96" codeSystemName="SNOMED CT" display Name="Asthma”>

<originalText>

<reference value="8a1"/>

</originalText>

</code>

<statusCode codes"completed”/>

</observation>

</entry>

</section>

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

Элемент <content> содержит необязательный атрибут revised, который может содержать значения «insert)» (вставлен) или «delete» (удален). Его можно использовать для указания изменений повествовательного содержания, сделанных в последней версии АКД-документа. Назначение этого атрибута ограничено отражением изменений предыдущей версии документа. Его применение, если оно имеет место, должно сочетаться со стандартным механизмом отслеживания изменений документа, предложенным в настоящем стандарте. Изменения в АКД-документе, переданном в использование при оказании медицинской помощи пациенту, требуют формального пересмотра и отслеживания версий. В повествовательные блоки пересмотренного документа могут включаться необязательные атрибуты revised, помечающие внесенные изменения. Получатели документа должны интерпретировать атрибут revised при отображении повествовательного блока и визуально отличать удаленную часть блока или скрывать его содержание.

5.4.3.5.2 Элемент <linkHlml>

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

Для описания мультимедийных данных, являющихся неотъемлемой частью документа и заверяемого содержания, необходимо использовать подраздел, содержащий класс ObservaoonMedia. В повествовательный блок должен включаться элемент <renderMuttiMedia> со ссылкой на этот подраздел (см. 5.4.3.5.6). Для ссылки на мультимедийные данные, не являющиеся неотъемлемой частью документа, можно использовать тег <linkHtmi>.

Идентификатор связанного содержания указывается в атрибуте linkHtml.href. При внутренних ссылках его значением является ректификатор типа XML ID. уже существующий в другом элементе того же или иного повествовательного блока или добавленный в элементы <sect>on>, <Observat»onMedia> или <renderMiritiMedia> XML-схемы. Атрибут linkHtml.name запрещен, поскольку атрибуты типа XML ID представляют собой альтернативные и более согласованные цели ссылок. Следуя соглашениям, принятым в HTML, значению внутренней ссылки должен предшествовать знак фунта, как это показано в следующем примере.

Пример 6 —

<section /0="SeC7Wr>

<code code="10164-2” codeSystem=”2.16.840.1.113883.6.1 ” codeSystemName="LOINC’Y>

<М1е>Анамнез заболевания<ЛШе>

<text>r•« Смит, 57 лет, мужчина, жалуется на боль в груди 3 года назад он перенес инфаркт миокарда....

<ftext>

</section> <section ID="SECT003’>

<code code=”10f53-2” codeSystems"2.16.840.1.113883.6.1" codeSystemName="LOINC"/>

<М1е>Предшестеующие заболевания^title*

<text>Заболевание коронарных артерий в анамнезе, см. <JinkHtm1href="#SECT00r‘>eb/uje</i;nkHtmf>.</text>

</section>

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

5.4.3.5.3    Элементы <sub> и <sup>

Элементы <sub> и <sup> используются для выделения в повествовательном блоке нижних и верхних индексов соответственно.

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

5.4.3.5.4    Элемент <Ы>

Элемент <Ьг/> используется в АКД-документе для указания принудительного перехода к началу следующей строки. Он отличается от элемента <paragraph> тем. что не имеет содержания. При отображении получатели должны интерпретировать этот элемент как переход к началу следующей строки.

5.4.3.5.5    Элементы <footnote> и <footnoteRef>

Элемент <footnote> используется в АКД-документе для указания сноски. Он содержит текст сноски. включаемый внутрь потока текста, к которому она применяется.

С помощью элемента <footnoteRef> можно сослаться на уже существующую сноску, включенную е тот же или иной повествовательный блок данного документа. Он нужен в том случае, если одна и та же сноска используется несколько раз. Атрибуту footnoteRef.lDREF должно быть присвоено значение атрибута footnote.lD сноски, существующей в данном документе.

При отображении получатели документа должны интерпретировать их, визуально отличая текст сноски. Точный способ отображения оставляется на усмотрение получателя, например, пометка текста в месте сноски с гиперссылкой на содержание сноски, простое выделение, к примеру. «Это текст со сноской [это текст сноски]» и т. д.

5.4.3.5.6    Элемент <renderMultiMedia>

Элемент <renderMultiMedia> используется в АКД-документе для ссылки на внешние мультимедийные данные, являющиеся неотъемлемой частью документа и его заверяемого содержания. Он показывает. в какое место отображения повествовательного блока должны быть включены эти мультимедийные данные.

В элемент <renderMultiMedia> может быть вложен необязательный элемент <caption> (заголовок). Элемент <renderMuttiMedia> имеет обязательный атрибут referencedObject (типа XML IDREFS). значение которого должно быть равно значению XML-атрибута ID подраздела типа ObservationMedia или RegionOflnterest. содержащегося в том же самом документе.

Пример 7—

<section>

<сode code="8709-8" codeSyslem="2.16.840.1.113883.6.1" codeSystemName-”LOINC"f>

<title>Skin exam</title>

<text>3pumeMHaя сыпь на внутренней поверхности левого указательного пальца. <renderMuttiMedia referencedObject=pMM1»/>

</text>

<entry>

<observationMedia classCodes’’OBS” moodCodes"EVN" ID-’‘MM1‘>

<id roof= ”2.16.840.1.113883.19.2.1 "/>

<value xsi:types"ED” mediaType= "image/jpeg”>

■Reference value=”teft_hand_image.jpegr'f>

<Svalue>

</observationMedia>

</entry>

</section>

Для ссылки на те мультимедийные данные, которые не являются неотъемлемой частью документа, должен использоваться элемент <linkHtml>.

Ожидается, что мультимедийные данные, на которые есть ссылка в повествовательном блоке, будут отображены или обозначены на месте ссылки. Элемент <renderMuttiMedia> может содержать ссылку на один класс ObservationMedia (среда результата исследования) или на один либо несколько классов RegionOflnterest (область интереса). Если этот элемент ссылается на класс ObservationMedia. то содержание этого класса должно быть отображено или обозначено на месте ссылки. Если элемент <renderMuttiMedia> содержит ссылку на один либо несколько классов RegionOflnterest, то все области интереса должны быть отображены или обозначены на месте ссылки поверх тех мультимедийных данных. к которым они относятся. Если этот элемент ссылается на несколько областей интереса, то каждая из них должна относиться к тем же самым мультимедийным данным.

5.4.3.5.7    Элемент <paragrapti>

Элемент <paragraph> аналогичен тегу <р> в HTML. Он позволяет разбивать повествовательные блоки на логически связанные структуры. В элемент <paragraph> может быть вложен необязательный элемент <caption> (заголовок). Если он присутствует, то должен предшествовать всем остальным строковым данным.

5.4.3.5.8    Элемент <list>

Элемент <list> аналогичен списку в HTML. В элемент <list> может быть вложен необязательный элемент <caption> (заголовок), а также один или несколько элементов строк списка <item>. В элемент «item» может быть вложен необязательный элемент «сарйоп». Если он присутствует, то должен предшествовать всем остальным строковым данным. В обязательном атрибуте listType должно быть указано, является ли список упорядоченным или неупорядоченным (по умолчанию он считается не* упорядоченным). Строки неупорядоченных списков обычно маркируются кружочками, а упорядоченных — номерами, хотя это и не обязательно.

5.4.3.5.9    Элемент «table»

Элемент <tabie> аналогичен таблице в HTML. Таблица размечается только для целей отображения и, в отличие от таблицы базы данных, не содержит значащие имена столбцов.

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

Атрибуты рамок таблицы table.border, отступов в ячейке table.cellpadding и промежутков между ячейками tabfe.celtspacing запрещены, поскольку с помощью атрибута styleCode (см. 5.4.3.5.11) отправители документа могут более подходящим способом задать характеристики отображения таблицы.

5.4.3.5.10    Элемент «caption»

Элемент <caption> задает заголовок абзаца «paragraph», списка <list>. строки списка <item>. таблицы «table» или ячейки таблицы. Он может также использоваться в элементе «renderMultiMedia» в качестве заголовка изображения (класс ObservationMedia) или области интереса (класс RegionOflnterest). Элемент caption содержит неформатированный текст и может содержать ссылки и сноски.

5.4.3.5.11    Атрибут styleCode

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

Значения кодов стилей берутся из словарного домена HL7 styleType и допускают расширение (квалификатор расширяемости CWE).

Таблица 89 — Допустимые значения атрибута styleCode (CWE)

Код

Описание

Стиль шрифта (определяет характеристики отображения шрифта)

Bold

Полужирный шрифт

UnderUne

Подчеркнутый шрифт

Italics

Курсивный шрифт

Emphasis

Некоторый способ выделения текста

Стиль обрамления таблицы (определяет характеристики отображения ячеек)

Lrute

Выравнивание содержания ячейки по левому краю

Rrule

Выравнивание содержания ячейки по правому краю

Toprule

Выравнивание содержания ячейки по верхнему краю

Botrule

Выравнивание содержания ячейки по нижнему краю

Стиль упорядоченного списка (определяет характеристики отображения упорядоченных списков)

Arabic

Нумерация списка арабскими цифрами (1.2. 3....)

UtteRoman

Нумерация списка строчными римскими цифрами (i. it. it*....)

B*g Roman

Нумерация списка прописными римскими цифрами (1. II. III....)

UttteAlpha

Нумерация списка строчными латинскими буквами (а.Ь. с,...}

B*g Alpha

Нумерация списка прописными латинскими буквами (А. В. С....)

Стиль неупорядоченного списка (определяет характеристики отображения неупорядоченных списков)

Окончание таблицы 89

Код

Описание

Oise

Маркировка списка маленьхими сплошными кружками

Circle

Маркировка стека маленькими окружностями

Square

Маркировка стека маленьхими сплошными квадратами

Местные расширения словарного домена styleType должны придерживаться следующего шабло-на в формате кода: [xj[A-Za-z](A-Za-zO-9]‘ (первый символ «х». второй прописная или строчная буква из диапазона A-Z. остальные символы могут быть любой комбинацией прописных или строчных букв из диапазона A-Z и цифр).

Атрибут styieCode может содержать несколько кодов стиля, разделенных пробельным символом. Если элемент, содержащий непустой атрибут styleCode. вложен в другой элемент, который также со* держит этот атрибут, то. как показано в следующем примере, стили должны объединиться.

Пример 8 —

<section>

<text><content styleCode=*Bold»>Omo6pa>KaemcH полужирным шрифтом.

<content styleCode=»ltalics»>omo6pa»:aemcB полужирным курсивом, </сотеШ>отображается полужирным шрифтом. </сол(елГ>

<content styleCode= "Bold ftalics”>TaioKe отображается полужирным курсивом. </content>

<ttext>

</section>

5.4.3.5.12 Ссылки внутрь повествовательного блока и из него

Примечание — Обсуждение связей между разделом и входящими е него подразделами приведено в подразделе 0 «

Отношение entry (подраздел)».

Ниже перечислены способы ссылок внутрь повествовательного блока АКД-документа и из него:

-    в подразделе entry может быть указана ссылка на элемент <oontent> повествовательного блока (см. подраздел 5 4,3.5.1 «Элемент «content»»);

-    в элементе «linkHtml» повествовательного блока АКД-документа могут быть указаны ссылки на внешние или внутренние источники (см. подраздел 5.4.3.5.2 «Элемент «linkHtml»»};

•    элемент «footnoteRef» повествовательного блока АКД-документа может содержать ссылку на элемент «footnote», содержащийся в тот же самом или другом повествовательном блоке данного документа (см. подраздел 5.4.3.5.5 «Элементы «footnote» и «footnoteRef»»);

•    элемент «renderMultiMedia» повествовательного блока АКД-документа может содержать ссылку на подраздел типа ObservationMedia или RegionOflnterest. содержащийся в данном документе (см. подраздел 5.4.3.5.6 «Элемент «renderMultiMedia»»).

5.4,3.6 Типы подразделов entry

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

Содержание клинических документов включает в себя широкий спектр информации, для полного и завершенного кодирования которой необходимо использовать значительную часть информационных объектов, описанных в модели RIM. Текущие типы подразделов АКД-документа разработаны в соответствии с заданными требованиями и сценариями, входящими в область применения АКД. В стандарте принят подход, согласно которому с помощью анализа похожих требований вместо большого числа узкоспециализированных подразделов entry, разработанных для каждого сценария, определены достаточно универсальные структуры, которые могут быть специализированы с учетом национальных или местных условий. Аналогичные подходы использованы в стандартах организации CEN и стандарте DICOM. а также в проекте OpenEHR.

Модель подразделов entry АКД-документа произведена от общей модели HL7 Clinical Statement, для разработки которой были объединены усилия нескольких комитетов, предпринятые в целях обе» спечения согласованного представления результатов клинических исследований и действий в различных спецификациях стандартов V3.

5.4.3.6.1 Класс Act (действие)

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

Если атрибут Act.negationlnd (признак отрицания) имеет значение «true», то это означает отрицание всего содержания класса Act. за исключением таких атрибутов, как Act.id и Act.moodCode. а также участников действия. Эти атрибуты сохраняют свое значение, к примеру, автор остается автором и у отрицательных сведений. Содержание класса Act. для которого указан атрибут negationlnd. по-прежнему остается утверждением о конкретном факте, описываемом этим классом. Например, отрицание утверждения «1 июля наблюдалась одышка» означает, что автор определенно отрицает, что одышка наблюдалась 1 июля, и берет на себя ту же ответственность за это утверждение и придерживается тех же требований к его доказательству, как если бы он не использовал отрицание.

Таблица 90 — Допустимые значения атрибута ActclassCode (CNE)

Код

Описание

ACT (действие)

Медицинская помощь.

АССМ (размещение)

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

CONS (согласие)

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

CTTEVENT (событие клинического испытания)

Момент времени при проведении клинического испытания, когда планируется выполнение одного или нескольких действий (moodCode = «INT») или когда такие действия фактически выполнены (moodCode = «EVN»)

INC (инцидент)

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

INFRM (информирование)

Акт передачи субъекту определенной информации или знаний в некоторой предметной области (или запрос на ее передачу)

PCPR (оказание медицинской помощи)

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

RE6 (регистрация)

Регистрация информации о сущности или ее роли

SPCTRT (обработка образца)

Процедура или обработка, необходимая для подготовки образца к выполнению анализа

Таблица 91 —Допустимые значения атрибута Act.moodCode (CNE)

Код

Описание

EVN (событие)

В лею разделе описано фактически произошедшее событие

INT (намерение)

В подразделе описано намерение или план

APT (действие, запланированное в расписании)

Действие, описанное в подразделе, запланировано на определенное время е определенном месте

ARQ (запрос на планирование в расписании)

Содержание подраздела представляет собой запрос на планирование в расписании

PRMS (подтверждение)

Подтверждение возможности выполнения действия, описанного е подразделе

PRP (предложение)

Предложение выполнения действия, описанного в подразделе

Окончание таблицы 91

Код

Описание

RQO (требование)

Требование или заказ выполнения действия, описанного в подразделе

OEF (описание)

Подраздел представляет собой описание услуги в нормативно-справочной информации

5.4,3.6.2 Класс Encounter (посещение)

Структура класса Encounter произведена от класса PatientEncounter модели RIM. Подразделы этого типа используются для идентификации связанных посещений, например, ранее состоявшихся или повторных посещений.

Примечание — Класс EncompassingEncounter. используемый в заголовке АКД-документа (см. подраздел 5.4.2.3 «Отношения, указанные в заголовке»}, предназначен для указания места посещения, во время которого произошло документируемое действие. Класс Encounter в теле документа используется для представления информации о других связанных посещениях.

Табл ииа 92 — Допустимые значения атрибута Enoounter.classCode (CNE)

Код

Описание

ENC (посещение)

Контакт пациента с одним или несколькими медицинскими работниками, в процессе которого пациенту оказана медицинская помощь или проведена оценка состояния его здоровья

Таблица 93 — Допустимые значения атрибута EnoompassingEncounter.moodCode (CNE)

Код

Описание

INT (намерение)

В подразделе описано намерение или план

EVN (событие)

В подразделе описано фактически произошедшее событие

APT (действие, запланированное в расписании)

Действие, описанное в подразделе, запланировано на определенное время в определенном месте

ARQ (запрос на планирование в расписании)

Содержание подраздела представляет собой запрос на плакирование е расписании

PRMS (подтверждение)

Подтверждение возможности выполнения действия, описанного в подразделе

PRP (предложение)

Предложение выполнения действия, описанного в подразделе

RQO (требование)

Требование или заказ выполнения действия, описанного в подразделе

5.4.3.6.3 Класс Observation (исследование)

Структура класса Observation произведена от одноименного класса модели RIM. Подразделы этого типа используются для представления кодируемых и других исследований.

Если атрибут Observation.negationlnd (признак отрицания) имеет значение «true», то это означает отрицание всею содержания класса Observation, за исключением таких атрибутов, как Observation. м3 и Observabon.moodCode, а также участников действия. Эти атрибуты сохраняют свое значение, к примеру, автор остается автором и у отрицательных сведений об исследовании. Содержание класса Observation, для которого указан атрибут negationlnd. по-прежнему остается утверждением о конкретном факте, описываемом этим классом. Например, отрицание утверждения «1 июля наблюдалась одышка» означает, что автор определенно отрицает, что одышка наблюдалась 1 июля, и берет на себя ту же ответственность за это утверждение и придерживается тех же требований к ею доказательству, как если бы он не использовал отрицание.

Код

Описание

OBS (исследование)

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

Любой подтип типа OBS

Допустимые значения берутся из словарного домена ActClassObservabon

Таблица 95 — Допустимые значения атрибута EnoompassingEncounter.moodCode {CNE)

Код

Описание

EVN {событие)

В подразделе описано фактически произошедшее событие

OEF (описание)

Подраздел представляет собой описание исследования в нормативно-справочной информации

GOAL (цель)

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

INT (намерение)

В подразделе описано намерение или план

PRMS (подтверждение)

Подтверждение возможности выполнения действия, описанного в подразделе

PRP (предложение}

Предложение выполнения действия, описанного в подразделе

RQO (требование)

Требование или заказ выполнения действия, описанного в подразделе

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

Таблица 96 — Допустимые значения атрибута referenceRange.dassCode (CNE)

Код

Описание

REFV (имеет справочные значения) (по умолчанию]

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

Таблица 97 —Допустимые значения атрибута ObservationRange.dassCode (CNE)

Код

Описание

OBS (исследование) [по умолчанию]

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

Любой подтип типа OBS

Допустимые значения берутся из словарного домена ActClassObservation

Таблица 98 — Допустимые значения атрибута Observation Range, mood Coda (CNE)

Код

Описание

EVN.CRT (критерий события)

[по умолчанию]

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

5.4.3.6.4 Класс ObservationMedia (мультимедийный результат исследования)

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

В схеме АКД-докумемгов к элементу ObservationMedia добавлен атрибут ID. имеющий тип данных XML ID. Этот атрибут является целевым в ссылках <renderMultiMedia> {см. подраздел 5.4.3.5.6 «Эле» мент <renderMultiMedia>»). Все значения атрибута типа XML ID должны быть уникальны в пределах документа (в соответствии со спецификацией XML организации W3C).

Различие между классами ObservationMedia и ExtematObservation состоит в том. что подразде-лы entry типа ObservationMedia являются частью заверяемого содержания, а подразделы entry типа ExtemalObservaUon — нет. Например, если клиницист начертит рисунок как часть дневниковой записи, этот рисунок должен быть представлен с помощью класса ObservationMedia. А если он составляет описание рентгеновского снимка грудной клетки, то ссылка на рентгеновский снимок представляется с помощью класса ExternalObservation.

Таблице 99 — Допустимые значения атрибута ObseivationRange.dassCode (CNE)

Код

Описание

OBS (исследование)

Мультимедийный результат исследования

Таблица 100 — Допустимые значения атрибута ObservationRange.moodCode (CNE)

Код

Описание

EVN (событие)

В подразделе описано фактически произошедшее событие

5.4.3.6.5 Класс Organizer (группировка)

Класс Organizer является производным от класса Act модели RIM. Он может использоваться для группировки других подразделов АКД-документа. объединенных общим контекстом. С помощью отношений component (компонент) в подраздел типа Organizer могут быть включены другие подразделы типа Organizer или иных типов. С помощью отношений reference (ссылка) в подраздел типа Organizer может быть включена информация о внешних действиях. Подраздел типа Organizer не может быть источником отношения entryRelationship (связь между подразделами).

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

Таблица 101 — Допустимые значения атрибута Orgarvzer.classCode (CNE)

Код

Описание

BATTERY (панвгъ)

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

CLUSTER (кластер)

Группа подразделов entry, имеющих логическую общность. С помощью класса Cluster их можно агрегировать в комплексное утверждение

Таблица 102 — Допустимые значения атрибута Organizer.moodCode (CNE)

Код

Описание

EVN (событие)

В подразделе описано фактически произошедшее событие

5.4.3.6.6 Класс Procedure (процедура)

Класс Procedure является производным от одноименного класса модели RIM. Он используется для представления информации о процедурах.

Если атрибут Procedure.negationlnd (признак отрицания) имеет значение «true», то это означает отрицание всего содержания класса Procedure, за исключением таких атрибутов, как Procedures и Procedure.moodCode. а также участников действия. Эти атрибуты сохраняют свое значение: к примеру, автор остается автором и отрицательных сведений о процедуре. Содержание класса Procedure, для которого указан атрибут negationlnd. по-прежнему остается утверждением о конкретном факте, олисы-ваемом этим классом. Например, отрицание утверждения «выполнена аппендэктомия» означает, что автор определенно отрицает, что аппендэктомия выполнялась, и берет на себя ту же ответственность за это утверждение и придерживается тех же требований к ею доказательству, как если бы он не использовал отрицание.

Таблица 103 — Допустимые значения атрибута Procedure.classCode (CNE)

Код

Описание

PROC (процедура)

Непосредственным и основным результатом процедуры (постусловие) является измененное физическое состояние субъекта

Таблица 104 — Допустимые значения атрибута Procedure.moodCode (CNE)

Код

Описание

EVN (событие)

В подразделе описано фактически произошедшее событие

INT (намерение)

В подразделе описано намерение или план

APT (действие, запланированное в расписании)

Действие, описанное в подразделе, запланировано на определенное время в определенном месте

ARQ (запрос на планирование в расписании)

Содержание подраздела представляет собой запрос на планирование в расписании

PRMS (подтверждение)

Подтверждение возможности выполнения действия, описанного в подразделе

PRP (предложение)

Предложение выполнения действия, описанного в подразделе

RQO (требование)

Требование или заказ выполнения действия, описанного в подразделе

OEF (описание)

Подраздел представляет собой описание услуги 8 нормативно-справочной информации

5.4.3.6.7 Класс RegionOflnterest (область интереса)

Класс RegionOflnterest является производным от класса Observation модели RIM. Он представляет область интереса, выделенную на изображении с помощью наложения некоторой формы. Она используется для указания некоторых частей изображения, например для указания места физикально-го исследования, заключая в «окружность» часть схематическою образа тела человека. Координаты, передаваемые в атрибуте RegionOflnterest.value. задаются в пикселах в виде массива целых чисел. Началом координат служит левый верхний угол, положительная часть оси X идет направо, а положительная часть оси Y — вниз. С помощью отношений entryRelationship может быть установлена связь между подразделом типа RegionOflnterest и подразделом типа ObservationMedia, а с помощью отношений reference — между подразделом типа RegionOflnterest и подразделом типа ExternalObservation (внешний результат исследования). При этом атрибут typeCode должен иметь значение «SUBJ». Подраздел типа RegionOflnterest может ассоциироваться ровно с одним подразделом типа ObservationMedia или с одним подразделом типа ExternalObservation. Если подраздел типа RegionOflnterest является целью ссылки, указанной в элементе <renderMultimedia>, то он может ассоциироваться только с подразделом типа ObservationMedia. а не ExternalObservation.

В схеме АКД-документов к элементу RegionOflnterest добавлен атрибут 10. имеющий тип данных XML ID. Этот атрибут является целевым в ссылках <renderMultiMedia> (см. подраздел 5.4.3.5.6 «Элемент <renderMultiMedia>»}. 8се значения атрибута типа XML 10 должны быть уникальны в пределах документа (в соответствии со спецификацией XML организации W3C).

Таблица 105 — Допустимые значения атрибута RegionOflnterest.dassCode (CNE)

Код

Описание

ROIOVL (наложение области интереса)

Область интереса выделяется на изображении с помощью наложения формы

Код

Описание

EVN (событие)

В подразделе описано фактически произошедшее событие

Таблица 107 — Допустимые значения атрибута RegionOflnterest.code (CNE)

Код

Описание

CIRCLE (крут)

Круг задается двумя парами чисел (столбец, строка). Первая пара задает центр круга, а вторая — точку на его окружности

ELLIPSE (эллипс)

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

POINT (точка)

Одна точка, задаваемая парой чисел (столбец, строка), или несколько точек, задаваемых такими парами

POLY (полилиния)

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

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

Пример 9 —

<section>

<code code="8709-8” codeSystem-"2.16.840.1.113883.6.1" codeSystemName= "LOINC"/>

<Htle>Skin Exam</titfe>

<text> Эритемная сыпь на внутренней поверхности левого указательного пальца.<геп<1егМиШМе<На referencedObjects»MM2»/>

</text>

<entry>

<observadon classCode="OBS” moodCode="EVN’>

<code code-”271807003" codeSystem- "2.16.840.1.113883.6.96” codeSystemNames”SNOMED CT" displayNames ”,Rash nf>

<statusCode code-"comp!eted”f>

<targetSiteCode code-"48856004” codeSystem-”2.16.840.1.113883.6.96” codeSystemName=”SNOMED CT” displayNames"Skin of palmer surface of index finger">

<qualifier>

<name code-"7861S007" codeSystem-"2.16.840.1.113883.6.96” displayName-"with laterality”f>

<value codes "7771000” codeSystem="2.16.840.1.113883.6.96" displayName~”left”/>

</qualifier>

</targetSiteCode>

<entry Relationship typeCode= "SPRT">

<regionOflnteres t classCode^ROIOVL" moodCode="EVN" ID="MM2">

<id root="2.16.840.1.113883.19.3.1”/>

<codo code="ELUPSE"f>

<value value="3"/>

<valuevalu9-n1''/>

<value value=n3"/>

<valuo value-'7'V>

<value valu9-n2"/>

<valu9 value=”4’’/>

<valu9 valu9="4"f> cvalue value="4"/>

<entryRelationship typ9Cod9-”SUBJ”>

<observationMedia classCode=”OBS" moodCode="EVN">

<id root*'2.16.840.1.113883.19.2.1n/>

<valu9 mediaTyp9="imag9/]p9g">

<ref9rence value= "Isfthand.jpeg "t>

</value>

</observationM9dia>

</9ntryRelationship>

</r9gionOflnt9resf>

</entryRelationship>

</obs9rvation>

</9ntry>

</s9ction>

5.4.3.6.8 Класс SubstanceAdministration (прием лекарства)

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

Если атрибут SubstanceAdministration.negationlnd (признак отрицания) имеет значение «true», то это означает отрицание всего содержания класса SubstanceAdministration. за исключением таких атрибутов. KaxSubstanceAdministration.id и SubstanceAdministration.moodCode. а также участников действия. Эти атрибуты сохраняют свое значение; к примеру, автор остается автором и отрицательных сведений о процедуре. Содержание класса SubstanceAdministration, для которого указан атрибут negationlnd. по-прежнему остается утверждением о конкретном факте, описываемом этим классом. Например, отрицание утверждения «принимается аспирин» означает, что автор определенно отрицает, что аспирин принимается, и берет на себя ту же ответственность за это утверждение и придерживается тех же требований к его доказательству, как если бы он не использовал отрицание.

Таблица 108 — Допустимые значения атрибута SubstanceAdministration.dassCode (CNE)

Код

Описание

SBAOM {применение субстанции)

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

Таблица 109 — Допустимые значения атрибута SubstanceAdministration.moodCode (CNE)

Км

Описание

EVN {событие)

В подразделе описано фактически произошедшее событие

INT (намерение)

В подразделе описано намерение или план

Окончание таблицы 108

Код

Описание

PRMS {подтверждение)

Подтверждение возможности выполнения действия, описанного в подразделе

PRP (предложение)

Предложение выполнения действия, описанного в подразделе

RQO (требование)

Требование или заказ выполнения действия, описанного в подразделе

Атрибут SubstanceAdministration.priority Code характеризует срочность применения субстанции. б атрибуте SubstanceAdministration.doseOuantity указана разовая доза препарата, а в атрибуте SubstanceAdministration rateQuantity может быть указана частота применения или скорость введения (для внутривенных инфузий).

Атрибут SubstanceAdministration.maxDoseQuantity используется для указания максимальной дозы препарата, который может быть применен в заданном интервале времени (например, максимальная суточная доза морфина, максимальная жизненная доза доксорубицина). Атрибут SubstanceAdministration. effectiveTime используется для указания времени применения. Его значение задается согласно Общей спецификации времени GTS (General Timing Specification), позволяющей описать разные сценарии дозировки. как показано в следующем примере.

Пример 10—

<section>

<text>npuHUMamb каптоприл по 25 мг перорально каждые 12 часов, начиная с 1-го января 2002 года и заканчивая 1-м февраля 2002 года.

</text>

<entry>

<substanceAdministration classCode="SBADM" moodCode=”RQO'>

<effectiveTime xs»:(ype=7W._7S">

<low value=”20020101”/>

<high value=”20020201"/>

<feffe c tiveTime*

<effectiveTime xsi:types”PIVL_TSn operator- "A ”>

<period value="12" unrt=”h"/>

</effective Time>

<routeCode codes"PO" codeSystem- ”2.16.840.1.113883.5.112” codeSystemName= "RouteOfAdministration "f>

<doseQuantity value-”1'V>

<consumable>

<manufacturedProduct>

<manufacturedLabeledDrug>

<code code=”318821008" codeSystem= ”2.16.840.1.113883.6.96” codeSystemName=”SNOMED CV displayNames”Captopril 25mg tablet”/*

</manufacturedLabeledDrug>

</manufacturedProduct>

</consumable>

<JsubstanceAdministration>

</entry>

</section>

Для представления информации, относящейся к применению лекарственных препаратов, предусмотрены отношения класса SubstanceAdministration с несколькими другими классами. Отношение consumable (расходуемый) используется для связи с разделами типа LabeledDrug (маркированное лекарство) или Material (вещество), описывающими применяемую субстанцию. Класс LabeledDrug. являющийся клоном класса Entity и исполняющий роль произведенного продукта (класс Manufactured Product), используется для идентификации лекарственного препарата, расходуемого при применении субстанции. Лекарственный препарат идентифицируется кодом, передаваемым в атрибуте LabeledDrug. code, или наименованием, передаваемым в атрибуте LabeledDrug.name. Класс Material используется для идентификации веществ, не являющихся лекарственными препаратами, например вакцин и продуктов крови.

Таблица 110 — Допустимые значения атрибута consumable.typeCode (CNE)

Код

Описание

CSM (расходуемый) [по умолчанию]

Субстанция, расходуемая или потребляемая при ее применении

Таблица 111 —Допустимые значения атрибута ManufacturedProduclclassCode (CNE)

Код

Описание

MANU (произведенный) [по умолчажю]

Произведенный продукт

Таблица 112 —Допустимые значения атрибута LabeledDrug.classCode (CNE)

Код

Описание

ММАТ (произведенный) [по умолчанию]

Произведенное вещество

Таблица 113 — Допустимые значения атрибута LabeledDrug .deterrmnerCode (CNE)

Код

Описание

KIND (вид)

[по умолчанию]

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

Таблица 114 — Допустимые значения атрибута Material.dassCode (CNE)

Код

Описание

ММАТ (произведенный) [по умолчанию]

Произведенное вещество

Таблица 115 — Допустимые значения атрибута Mater ial.determinerCode (CNE)

Код

Описание

KIND (вид)

[по умолчанию]

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

5.4.3.6.9 Класс Supply (поставка)

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

Таблица 116 — Допустимые значения атрибута Suppty.classCode (CNE)

Код

Описание

SPLY (поставка)

Действие отпуска или доставхи продукта

Koa

Описание

EVN (событие)

В подразделе описано фактически произошедшее событие

INT (намерение)

В подразделе описано намерение или план

PRMS (подтверждение)

Подтверждение возможности выполнения действия, описанного в подразделе

PRP (предложение)

Предложение выполнения действия, описанного в подразделе.

RQO (требование)

Требование или заказ выполнения действия, описанного в подразделе

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

Таблица 118 — Допустимые значения атрибута product.typeCode (CNE)

Код

Описание

PRD (продукт) (по умолчанию]

Целевой материал, который предоставляется (производится) при выполнении услуги

Класс Supply представляет отпуск, а класс SubstanceAdministration — применение. Лекарственные назначения являются сложными видами деятельности, охватывающими требования применения к пациенту (например, «принимать дигоксин таблетки 0.125 мг перорально 1 раз в день») и требования отпуска из аптеки (например, «отпустить 30 таблеток с 5 повторениями). Подобное назначение представляется в АКД с помощью подраздела entry типа SubstanceAdministration (применение субстанции), в который с помощью отношения component вложен подраздел типа Supply (запас). Атрибут Supply, independents (признак независимости) у вложенного подраздела может иметь значение false, указывающее. что соответствующая поставка не должна осуществляться отдельно от того, что указано в содержащем их подразделе типа SubstanceAdministration.

Пример 11 —

«section*

«text*fluaoKcuH таблетки диаоксим таблетки 0,125 ма перорально 1 раз в день, N30. 5 повторений.«/ text>

<entry>

SubstanceAdministration classCode="SBADM" moodCodes”RQO”>

<effectiveTime xs/:(ypee”PfVL_75">

«period value="24 " unit=”h"/*

<feffe c tive Tme>

«routeCode code="PO” codeSystem-”2.16.840.1.113883.5.112codeSystemNames”RouteOfAdministration”/*

<doseQuantity value-"1”/>

<consumable>

<manufacturedProduct>

<manufacturedLabeiedDrug>

<code code* "317896006" codeSystem-n2.16.840.1.113883.6.96” codeSystemNames”SNOMED CT” displayName= "Digoxin 125micrograms tablet”/*

«/manufacturedLabeledDrug>

</manufacturedProduct*

«/consumable*

<entry Relationship typeCode="COMP~>

<supply classCode-”SPLYn moodCodes"RQO‘>

<repeatNumber>

<iow valua~nOn/>

<high value=”5"/>

</repeatNumber>

<independentJnd value="false"/>

<quantity value=”30”/>

</supply>

</entryRelationship>

</substanceAdministration>

</entry>

</section>

5.4.3.7 Участники подразделов entry

Структуры и подразделы АКД-докумвнтов могут включать в себя информацию о различных участниках. некоторые из которых указаны также в заголовке АКД-документа. Как указано в описании контекста АКД-документа (см. 5.4.4). участники, наследуемые от заголовка, могут быть переопределены е теле документа.

5.4.3.7.1    Участник author (автор) Описанный выше участник author (см. подраздел 0 «

Участник author (автор)») может быть приписан разделу section, чтобы переопределить значения,

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

5.4.3.7.2    Участник consumable (расходуемый)

Участник consumable описан выше в подразделе 5.4.3.6 «Тилы подразделов entry».

5.4.3.7.3    Участник informant (информатор)

Участник informant описан выше в подразделе 5.4.2.2.6 «Участник informant (информатор)». Он может быть приписан разделу section, и в этом случае он переопределяет значения, наследуемые от заголовка АКД-документа. Он может быть приписан также подразделу entry. Тогда он переопределяет значения, наследуемые от раздела, и распространяется на все вложенные подразделы, пока не будет там переопределен.

5.4.3.7.4    Участник participant (другой участник)

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

Таблица 119 — Допустимые значения атрибута partxapanltypeCode (CNE)

Код

Описание

Любой подтип домена PartidpationType

Допустимые значения составляют домен PartidpationType

Таблица 120 — Допустимые значения атрибута partictpant.cootextControlCode (CNE)

Код

Описание

ОР (замещающая, распространяемая) [по умолчанию]

Ассоциация участника, замещающая ассоциацию с тем же значением атрибута typeCode. Эта замещающая ассоциация будет распространяться на действия-потомки. которые связаны с данным экземпляром класса Act с помощью экземпляра класса ActReiationship (см. 5.4.4)

Участником participant является сущность, выполняющая одну из нескольких возможных ролей (ParticipantRole). Сущностью, исполняющей роль, является устройство (класс Bevice) или другая сущность (класс PlayingEntity). Контролером может являться любая сущность (класс Entity).

Код

Описание

Любой подтип типа ROL (из домена RoleClassRoot)

Допустимые значения составляют домен RoleClassRoot

Таблица 122 — Допустимые значения атрибута Device .dassCode (CNE)

Код

Описание

DEV {устройство) [по умолчанию]

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

Любой подтип типа DEV

Допустимые значения берутся из словарного домена EntityClassDevice

Таблица 123 — Допустимые значения атрибута Device .determinerCode (CNE)

Код

Описание

INSTANCE (экземпляр) [по умолчанию]

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

Таблица 124 — Допустимые значения атрибута PlayingEntity.classCode (CNE)

Код

Описание

ENT (сущность) [по умолчанию]

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

Любой подтип типа ENT

Допустимые значения берутся из словарного домена EntityClassRoot

Таблица 125 — Допустимые значения атрибута PtayingEntity.determinerCode (CNE)

Код

Описание

INSTANCE (экземпляр) [по умолчанию]

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

Таблица 126 — Допустимые значения атрибута Entity.classCode (CNE)

Код

Описание

ENT (сущность) [по умолчанию]

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

Любой подтип типа ENT

Допустимые значения берутся из словарного домена EntityClassRoot

Таблица 127 — Допустимые значения Entity Device.determinerCode (CNE)

Код

Описание

INSTANCE (экземпляр) [по умолчанию]

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

5.4.3.7.5 Участник performer (исполнитель)

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

Код

Описание

PRF (исполнитель) [по умолчанию]

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

5.4.3.7.6    Участник product (продукт)

Участник product описан выше в подразделе 5.4.3.6 «Типы подразделов entry».

5.4.3.7.7    Участник specimen (образец)

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

Таблица 129 — Допустимые значения атрибута specimen.typeCode (CNE)

Код

Описание

SPC (образец) [по умолчажю]

Предмет не клинического (например, лабораторного) исследования

Таблица 130 — Допустимые значения атрибута Specimen Role.ciassCode (CNE)

Код

Описание

SPEC (образец) [по умолчанию]

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

5.4.3.7.8    Участник subject (субъект)

Участник subject описан выше в подразделе 5.4.3.3.3 «Участник subject (субъект)». Он может быть приписан разделу section, а также подразделу entry. 8 последнем случае он переопределяет значения, наследуемые от раздела, и распространяется на все вложенные подразделы, пока не будет там пере* определен.

5.4.3.8    Отношения между подразделами

5.4.3.6.1 Отношение component (компонент)

Источником отношения component является подраздел entry типа Organizer (см. подраздел О «Класс Organizer (группировка)»), а целью — другой подраздел АКД*документа. Это отношение ис* пользуется для группировки подразделов АКД*документа путем вложения а подраздел типа Organizer.

Таблица 131 —Допустимые значения атрибута componentry peCode (CNE)

Код

Описание

СОМР (компонент) [по умолчанию]

Вложенный подраздел является компонентом подраздела типа Organizer

5.4.3.8.2 Отношение precondition (предварительное условие)

Класс precondition является производным от класса ActRelationship (отношение между действия* ми) и используется вместе с классом Criterion (критерий) для описания условия, которое должно быть удовлетворено до начала некоторой деятельности.

Таблица 132 — Допустимые значения атрибута precondition.typeCode (CNE)

Код

Описание

PRCN (предварительное условие) [по умолчанию]

Условие, которое должно быть удовлетворено до начала предоставления услуги

Код

Описание

OBS (исследование) [по умолчанию]

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

Любой подтип типа OBS

Допустимые значения берутся из словарного домена ActClassObservation

Таблица 134 —Допустимые значения атрибута Criterion.mood Code (CNE)

Км

Описание

EVN.CRT (критерий события) (по умолчанию]

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

5.4.3.8.3    Отношение referenceRange (справочный диапазон)

У отношения referenceRange (описанного выше в подразделе 0 «Класс Observation (исследование)») источником является подраздел типа Observation, а целью — подраздел типа ObservationRange.

5.4.3.8.4    Отношение entryRelationship (связь между подразделами)

В настоящем стандарте идентифицированы и смоделированы различные сценарии связей и ссылок. Реализация этих сценариев обеспечивает семантическую связь подразделов entry АКД-докуменга с подразделами, содержащимися в том же самом документе (с помощью отношения entryRelationship). и с объектами, внешними по отношению к этому документу (с помощью отношения reference).

Примечание — Спецификация АКД позволяет установить отношения любого подраздела АКД-дохумента с любым другим его подразделом, задавая любой из типов отношений, указанных 8 таблице 135. Во многих случаях такие отношения окажутся лишенными смысла. Таблица 135 может служить руководством по разумным типам отношений между подразделами, но приведенная в ней информация не является нормативным требованием соответствия стандарту.

Таблица 135 — Типы отношений entryRelationship между подразделами entry

Тип отношения

Разумные типы источников и целей отношения

Примечания

CAUS (является этиологией)

[Act | Observation | Procedure | SubstanceAdmintstration] CAUS [Observation]

Указывает, что источник отношения вызвал целевой результат исследования (например, источник «сахарный диабет» вызвал «заболевание почек»)

СОМР (содержит компонент)

[Act | Observation | Procedure | SubstanceAdmintstration | Supply] COMP (Act | Observation | Procedure | SubstanceAdminislration | Supply]

Указывает, что цель отношения является компонентом источника (например, «анализ содержания гемоглобина» является компонентом «общего анализа крови»)

GEVL (оценка

соответствия

(цели))

[Observation] GEVL [Observation]

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

MFST

(проявление)

[Observation] MFST [Observation]

Указывает, что источник является проявлением цели (например, источник «крапивница» является проявлением цели отношения «аллергия на пенициллин»)

REFR

(ссылается на)

[Act | Observation | Procedure | SubstanceAdminislration j Supply] REFR (Act |

Observation | ObservationMedia | Procedure | RegionOflnterest | SubstanceAdmintstration | Supply]

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

Окончание таблицы 135

Тип отношения

Разумные типы источников и целей отношения

Примечания

RSON

(имеет причину)

[Act | Encounter | Observation | Procedure | SubstanceAdministration | Supply] RSON [Act | Encounter j Observation | Procedure | SubstanceAdministration | Supply)

Указывает причину или основание выполнения услуги (например, источник «тредмил-тест» обусловлен наличием «боли в груди»)

SAS (начинается после начала)

[Act | Encounter | Observation | Procedure | SubstanceAdministration | Supply] SAS [Act | Encounter j Observation | Procedure | SubstanceAdministration | Supply)

Действие-источник начинается после начала действия-цели отношения (например, источник «потоотделение» начинается после начала «боли в груди»)

SPRT

(подтверждается)

[Observation] SPRT [Observation | ObservationMedia | RegionOftnterest]

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

SUBJ (относится к предмету)

[Observation | RegionOflnterest] SUBJ [Observation | ObservationMedia]

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

Тил отношения «относится к предмету» (класс ActRetationshipType) похож на тип отношения «субъект» (класс ParticipationType). В подразделах, содержание которых относится к физическим объектам, используется отношение Participation (участив), а е подразделах, которые в основном оперируют другими подразделами. — отношение ActRelabonship (связь действий)

XCRPT (выписка из)

[Act | Observation) XCRPT [Act | Observation | Procedure | SubstanceAdministration | Supply)

Указывает, что источник является выпиской из цели отношения (например, источник «показатель гемоглобина = 12» является выпиской из цели отношения «общий анализ кроеи»).

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

Если атрибуту entryRelationship.inversionlnd (признак обращения) присвоено значение «true», то это означает, что отношение должно быть обращено, как если бы источник и цель отношения поменя* лись ролями. Выше был приведен пример отношения «тредмил-тест» (RSON обусловлен наличием «боли в груди»}. Будучи обращенным, оно примет вид «боль в груди» (обращение RSON) «тредмил-тест». Обращение отношения полезно в том случае, когда текущий контекст описывает цель отношения, которую надо проследить до ее источника.

Использование атрибута entryRelationship.contextConductionlnd (признак распространения контекста) отличается от его обычного использования в других случаях (см. 5.4.4) тем. что во всех других слу-

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

5.4.3.8.5 Отношение reference (ссылка)

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

Каждый объект должен иметь идентификатор и код типа объекта и содержать атрибут Act.text, описанный в модели RIM. Он может использоваться для хранения адреса URL и типа среды MIME этого объекта. Классы ссылок на внешние объекты должны иметь атрибут moodCode с фиксированным значением «EVN».

Класс отношения reference имеет атрибут reference.seperatablelnd. который указывает, должен ли источник отношения интерпретироваться независимо от цели отношения. Наличие этого атрибута не может воспрепятствовать лицу или приложению отделить обработку источника от обработки цели, он указывает только пожелания автора и готовность заверить содержание источника, если оно отделено от цели. Обычно е тех случаях, когда атрибут seperatablelnd имеет значение «false», в пакет передаваемых данных включается также целевой объект ссылки с тем. чтобы получатель мог обеспечить его визуализацию.

В таблице 136 приведено описание допустимых значений атрибута reference.typeCode. Как и таблица 135 (типы отношений entryRelationship). она служит руководством по разумным типам отношений между подразделами АКД-документа и внешними ссылками, но приведенная в ней информация не является нормативным требованием соответствия стандарту.

Таблица 136 — Типы отношений reference в АКД-документе

Тип отношения

Разумные типы источников и цепей отношения

Примечания

ELNK

(отождествляет

эпизоды)

(Observation) ELNK [ExtemalObservation]

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

REFR

(ссылается на)

[Act | Observation | Procedure | SubstanceAdminrstration | Supply)

REFR [ExternalAct | ExtemalDocument ( ExtemalObservation | ExternalProcedure]

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

RPLC

(заменяет)

[Act | Encounter | Observation | ObservationMedia | Organizer j Procedure | SubstanceAdministration | Supply]

RPLC [ExternalAct | ExtemalDocument | ExtemalObservation [ ExternalProcedure]

Указывает, что подраздел—источник отношения заменяет документирование целевого внешнего действия

SPRT (подтверждается)

[Observation] SPRT [ExtemalDocument [ ExtemalObservation]

Указывает, что источник отношения подтверждается целью отношения

SUBJ (относится к предмету)

[Observation | RegionOflnterest] SUBJ [ExtemalObservation]

Используется для привязки области интереса (источника отношения) к целевому изображению или для привязки результата исследования к его предмету

XCRPT (выписка из)

[Act | Observation) XCRPT (ExternalAct | ExtemalDocument | ExtemalObservation | External Procedure]

Указывает, что источник является выпиской из цели отношения (например, источник «показатель гемоглобина = 10.7» является выпиской из цели отношения «общий анализ крови»)

Целевыми классами отношения ссылки reference могут быть ExtemalAct (внешнее действие), ExtemalDocument (внешний документ). ExtemalObservation (внешний результат исследования) и External Procedure (внешняя процедура).

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

Таблица 137 — Допустимые значения атрибута ExtemalAct.classCode (CNE)

Кол

Описание

ACT (действие) [по умолчанию]

Медицинская помощь

Любой подтип типа ACT

Допустимые значения берутся из словарного домена ActClassRoot

Таблица 136 — Допустимые значения атрибута ExtematActmoodCode (CNE)

Км

Описание

EVN (событие) (по умолчанию]

Фактически произошедшее событие

Класс ExtemalDocument является производным от класса Document модели RIM и предназначен для представления внешних документов. Атрибут ExtemalDocumenttext должен иметь значение с типом данных ED. позволяющее указать тип среды MIME внешнего документа.

Таблица 139 — Допустимые значения атрибута Extema)Document.classCode (CNE)

Км

Описание

DOC (докуменг)[по умолчанию]

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

Любой подтип типа DOC

Допустимые значения берутся из словарного домена ActClassDocument

Таблица 140 — Допустимые значения атрибута ExtemalDocument.moodCode (CNE)

Ков

Описание

EVN (событие) [по умолчанию]

Фактически произошедшее событие

Класс ExtemalObservation является производным от класса Observation модели RIM и предназначен для представления внешних кодируемых и других результатов исследований.

Таблица 141 —Допустимые значения атрибута ExtemalObservation .classCode (CNE)

Ков

Описание

OBS (исследование) [по умолчанию]

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

Любой подтип типа OBS

Допустимые значения берутся из словарного домена ActClassObservabon

Таблица 142 — Допустимые значения атрибута ExtemalObservation.moodCode (CNE)

Ков

Описание

EVN (событие) [по умолчанию]

Фактически гфоиэошедшее событие

Класс ExtemalProcedure является производным от класса Procedure модели RIM и предназначен для представления внешних процедур.

Таблица 143 — Допустимые значения атрибута ExtemaiProcedure.dassCode (CNE)

Код

Описание

PROC (процедура) (по умолчанию)

Непосредственным и основным результатом процедуры (постусловие) является измененное физическое состояние субъекта

Таблица 144 — Допустимые значения атрибута ExtemaiPfOcedure. mood Code (CNE)

Код

Описание

EVN (событие) (по умолчанию]

Фактически произошедшее событие

5.4.4 Контекст АКД-документа

Контекст АКД-документа задается в его заголовке и распространяется на весь документ. Контекст может быть переопределен на уровне тела, раздела section или подраздела entry.

5.4.4.1 Общие сведения о контексте АКД-документа

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

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

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

1)    в АКД используется механизм контекста, предложенный в модели RIM (управляется атрибутом contextControICode классов, произведенных от класса Participation, и атрибутом contextConductionlnd классов, произведенных от класса ActRelatkmship). Для достижения приведенных ниже целей разработки этим атрибутам присваиваются фиксированные значения, ограничивающие модель контекста, описанную в модели RIM. Для определенных атрибутов заголовка АКД-документа расширено свойство раслространения контекста, которое также распространяется через отношения ActRelafonship. у которых атрибут contextConductionlnd имеет значение «true»;

2)    заголовок АКД-документа задает контекст для всего документа. Значения признака распространения. указанные в заголовке документа, сохраняются ео всем документе, если только явно не переопределяются. Этот принцип применяется как к отношениям участия (класс Participation), так и к определенным атрибутам заголовка АКД-документа. Контекстуальные компоненты заголовка (то есть те. чьи значения распространяются на компоненты тела) включают в себя следующие атрибуты:

-    author (автор).

•    confidentialityCode (код конфиденциальности).

•    dataEnterer (оператор по вводу данных).

-    languageCode (код языка),

-    informant (информатор),

-    legalAuthenticator (юридически ответственное лицо).

-    participant (другой участник),

•    recordTarget (целевая медицинская карта);

3)    на уровне тела документа могут быть переопределены следующие атрибуты:

•    confidentialityCode (код конфиденциальности),

•    languageCode (код языка};

4)    на уровне раздела документа section могут быть переопределены следующие атрибуты:

•    author (автор).

•    confidentialityCode (код конфиденциальности),

•    languageCode (код языка),

•    informant (информатор),

•    subject (субъект);

5)    на уровне подраздела АКД-документа entry могут быть переопределены следующие атрибуты:

•    author (автор).

•    languageCode (код языка),

•    informant (информатор),

•    participant (другой участник).

•    subject (субъект);

6)    контекст распространяется от внешних тегов к вложенным тегам. Контекст, специфичный для внешнего тега, распространяется на все вложенные теги, если только не переопределен во вложенном теге. Контекст, заданный для тега в теле АКД-документа. всегда переопределяет контекст, наследуемый от внешнего тега. Например, указание автора на уровне раздела документа section переопределяет всех авторов, наследуемых от внешнего тега;

7)    контекст иногда известен точно, а иногда неизвестен, как. например, в том случае, когда документ состоит из большого не структурированного повествовательного блока, который потенциально может содержать утверждения, противоречащие внешнему контексту. Поскольку в АКД-документ контекст всегда распространяется, пока не переопределен, то для указания неопределенности контекста его атрибутам надо присвоить пустые значения.

5.4.4.2 Технические аспекты контекста АКД-документа

В модели RIM контекст действия определяется как совокупность участников этого действия, которая может распространяться на вложенные действия. Согласно модели RIM. возможность распространения участников контекста на вложенные действия зависит от того, разрешает пи отношение между родительским и дочерним действием распространение контекста. Явное представление контекста и его возможности распространения на вложенные действия выражается в модели RIM через атрибуты Participation.contextControlCode и ActRelationship.contextConductionlnd. В настоящем стандарте общий механизм контекста, принятый в модели RIM, ограничивается таким образом, что контекст всегда переопределяется и распространяется (таблица 145).

Таблица 145 — Ограничения атрибутов контекста RIM. принятые е АКД

Атрибут модели RIM

Кратность

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

Фиксированное мачение

Participation.

1..1

Обязателен (пустые значения

«ОР» (замвшаккцая. раслро-

contextControtCode

не допускаются)

страняемая)

Act Relationship.

1..1

Обязателен (пустые значения

«true»*

contextConductionlnd

не допускаются)

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

Таблица 146— Блокировка распространения контекста пустьми значениями

Атрибут (омтеаста

Представление пустого значения

author

Assigned Author, id = NULL: исполняющая сущность не задана, контролирующая сущность не задана

confidentialityCode

confidentialityCode = NULL

languageCode

languageCode = NULL

informant

Ass>gned£ntity.id = NULL: исполняющая сущность не задана, контролирующая сущность не задана

participant

ParlictpantRole.id = NULL: исполняющая сущность не задана, контролирующая сущность не задана

Модель контекста АКД-документа иллюстрируется следующим примером. Для экземпляра класса ClinicalDocument заданы атрибуты контекста author (автор), confidentialityCode (код конфиденциальности) и languageCode (код языка), которые будут распространяться на вложенные действия. Атрибут contextConducbonlnd отношения ActRelabonship. связывающего класс ClinicalDocument с классом bodyChoice. имеет фиксированное значение «true», разрешающее распространение контекста. Подклассы NonXML8ody и StructuredBody класса bodyChoice имеют атрибуты confidentialityCode и languageCode. которые могут использоваться для переопределения значений, указанных в заголовке. Атрибут contextConductionlnd отношения component, связывающего класс StructuredBody с классом Section, имеет фиксированное значение «true», разрешающее контексту класса StructuredBody распространиться на класс Section. Этот класс имеет атрибуты confidentialityCode. languageCode и author, которые могут быть переопределены. Пустое значение, присвоенное атрибуту author, означает, что автор данного конкретного раздела не известен.

Модель примера контекста показана на рисунке 2.

О)

о


Огеашмпоп

UaaaCcda ' <• ол®

ммтиис>«*

>я seKioto 'I пмгж ££Г<ОН» |0..*1 W««en 6ET«tEL>(9 1 •Mi:«r«#o»to .*| дочлчгчиаггФдеФоо» СЕ CwE р <• 0'9»#,г'41*л*ЛчЛ) СЛ«


Ого*ч t/m»


taspwdft utter

сК«сСо«* * «габДОмГО 14 «Т»|1»(1 Т СОЯ CECwe(0.1)«:*6"«W» •4» 86КА9»КП »аемп SCKICL» Р •)


> aumor

•ураСаа* — aur

UNla-C «» СЕ C*vE to i)«^XbOiMtnafMWi» «oaioxiConMOiCoea^CME |1.1)<=Сэ» '.Вт»» 1g II 11


амееОкитвл!

clauCixb ' • • OOCCtM wv*dC»di <• EVN

V 'H> .1[

ndsCC (VIE (1 ,.1|

Ilia ST p.l| ifklioTiRi. Г8 11.1 j »mocf>>»<rC99) CE C«E p l)«s \.eav«c«л«*л»^хлг

v^IJi^iteda CS CMC (0 .11 SCtO II [0 I)

«•rurfllUTMr ИГ (О 11


1 .1 MdiCicw


component

typaCed* •- COVP g»da>tCam»jelnrti»a » B41-1l*wr


boiVCIioice



Parsen

d»5«* *оР«ЛГ d»tmitaiiC»M <-№СЛ»«СС >иг<а:Зег«ГМ>П.’|


NonXMLOO*/

4«в»0м» '.oOOetWV mtodCdM <=£</«

IWfOli 1]

Kditertian;<«fe C6 civg |a t| <• «.4»<sC*«fc*M«arA44< >*гф1»а»Сав> CCCMC p i|--Л*ПМ«** ague®*


ГОСТ Р HC0/HL7 27932—2015


OiaantttiiM

' о

•Xrl«mw(M»C*4<l «з hvSTonCe 14 8ЕК|1»РЛ лата CCKOM> p.*|

Weoom 8ET«T6i»p.T »W СЕКЛО* (Ol

•ОлЛлкапЭиИг/СихаСаАаСе CIVC |4 | <• C'r»«tfad,MiaNU)dyCd4i


S*nKturMeody

аасс&ма ' ecooceoov

m»»«C»M *-CVW

ccrricaroaitrCoda ce ewe p i|

Oa.dmCMftfiiMa/.wii

'апдоггСоя 06046 p.lje:


component ty?«C»<M «♦ cow* «qrtV^Coroxl'dnoa * &111.ЧТ1А'


ft.1


iltPiiinadiit


BSif


I. * arigadAutBi


•oocsecr . etvr


А*ЗДП«МЦ*ЮГ

eiaaaCM» * I4-SCI'II»|I •)

<0* CE С1ЛЕ P X» СЕКЛО* p.*]

»«ati $ET«rso|a 1


1 auttior

typaCoUfc <*Л</Г

\nrt«nCoesr« олс rail ООПЮм(С*(Мго1С««Ав CwEfi ,i|*»Cfc»

«Ипе» Т8П -П_


dMtCtf* m*o4Co# « «

6fttcE we p. 11«e»su>t*rrs»jK«« fyt* K8T (0.11 ilfteo |o.i|

«л(4в44Н>С«4«.С€ OWE |0..1|v-> амкСалгАлккуСаМ *4ГфА»9»СФС1В CSCN6 P. 1) •


X.


V


о


1    шЪзс


Patton


Рисунок 2 — Модель примера контекста АКД-документа


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

Пример 12—

(ancestor-or-setf::‘/author) [position^ )=tast( )}

5.5    Иерархическое описание структуры АКД-документов

Примечание — Наиболее полное описание процесса разработки и интерпретации иерархических описаний е стандартах HL7 можно найти в документе HL7 V3 Guide.

Иерархическое описание структуры АКД-документов приведено в 6.1. таблица 151.

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

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

Во втором выпуске АКД признаки соответствия «требуемый» и «обязательный» применяются следующим образом:

а)    требуемые атрибуты:

1)    Section.text.

2)    все атрибуты с ненулевым нижним пределом кратности:

б)    обязательные атрибуты:

1)    ClinicaiDocument.typeld.

2)    Структурные атрибуты модели RIM:

-    ClassCode.

-    MoodCode.

•    TypeCode,

•    DeterminerCode:

3)    атрибуты контекста:

•    contextControlCode.

•    ContextConductionlnd.

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

5.6    Реализация АКД на языке XML

Примечание — Наиболее полное описание технологии реализации стандартов HL7 на языке XML приведено в документе HL7 XML Implementation Technology Specification (XML ITS).

XML-схема АКД-документа cda.xsd приведена в приложении F.

XML-схема Datatypes.xsd приведена в припожении F.

XML-схема Datatypes-base.xsd приведена в приложении F.

XML-схема POCD_MT000040.xsd приведена в приложении F.

XML-схема повествовательного блока NarrativeBlock.xsd приведена в приложении F.

XML-схема voc.xsd приведена е приложении F.

Сама по себе XML-схема АКД не является нормативной. Проверка на соответствие этой схеме является суррогатом проверки соответствия нормативной спецификации XML ITS.

XML-схема повествовательного блоха, представляющая собой модель содержания атрибута section.text на языке XML, разработана вручную, как описано в подразделе 0 «Повествовательный блок раздела». 8 отличие от XML-схемы АКД-документа cda.xsd. XML-схема повествовательного блока NarrativeBlock.xsd является нормативной.

5.7 Примеры

5.7.1 Пример документа

Заключение консультанта клиники Good Health Clinic Консультант: Роберт Долин, д.м.н.

Дата: апрель 7. 2000

Пациент: Генри Левин. 7-й; М/карта: 12345; Пол: Муж Дата рождения: сентябрь 24.1932 История текущего заболевания

Генри Левин. 7-й. 67 лет. обратился за дальнейшим лечением от астмы. Заболел, когда был подростком. 8 прошлом году был дважды госпитализирован и уже дважды в этом году. Последние несколько месяцев не может обходиться без стероидов.

История заболеваний Астма

Гипертензия (детали см. в документе HTN.cda)

Остеоартрит правого колена Медикаментозная терапия Теодур. 200 мг два раза в день

Альбутерол ингалятор. 2 вдоха. 4 раза в день, по необходимости

Предниэон. 20 мг в день

Гидрохлортиазид, 25 мг в день

Аллергии и непереносимость

Пенициллин — крапивница

Аспирин — одышка

Кодеин — зуд и тошнота

Семейный анамнез

Отец умер от инфаркта миокарда чуть старше 50 лет.

Рака или диабета не было.

Социальный анамнез

Курение: 1 пачка в день с 20 до 55 лет. затем бросил.

Алкоголь: изредка Физикальиый осмотр Жизненно важные показатели

7 апреля 2000 15:30


36.9 по Цельсию 84 / мин Регулярный 14/мин 135 mmHg 88 mmHg Левая рука


Дата / время

Рост

8ес

ИМТ

ППТ

Температура

Пульс

Ритм

Дыхание

Систолическое АД Диастолическое АД Положение / манжета


7 апреля 2000 14:30 177 см

88.0    кг

28.1    кг/м2.05 м2

36.9 по Цельсию 86 / мин Регулярный

16 / мин. незатрудненное 132 mmHg 86 mmHg Левая рука


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

Легкие: чистые, без одышки: дыхание хорошее.

Аускультация сердца: нормальный ритм без шумов, нет S3, нет S4.

Лабораторные и диагностические исследования

Рентген грудной клетки 02/03/1999: легкие растянуты. Нормальные очертания сердца, легкие чистые.

Пикфлоу сегодня: 260 л/мин

Выполненные процедуры

Снятие швов на левом предплечье.

Заключение

Астма, с предшествующей историей курения. С трудом отвыкает от стероидов. Попробует постепенный отказ.

Гипертензия, хорошо контролируемая.

Контактный дерматит пальца.

Рекомендации

Полное исследование ФВД с определением объема легких.

Панель Chem-7 завтра.

Обучение измерению пикфлоу.

Уменьшить преднизон до 20 мг через день, чередуя с 18 мг через день.

Гидрокортизон, крем для пальца. 2 раза в день.

Повторный визит через неделю.

Подпись: Роберт Долин, д. м. н. Дата: апрель 8. 2000

5.7.2    Пример АКД-документа

Приведен корректный пример АКД-документа. соответствующий настоящему стандарту.

Примечание — Рекомендуется иметь в виду руководство по реализации «Using SNOWED СТ in HL7 Version 3». которое пока что находится на стадии разработки. Эго руководство, разрабатываемое совместно комитетом HL7 и Институтом американских патологоанатомов (College of American Pathologists), будет представлено на утверждение в комитет HL7 как справочный документ. Шаблоны использования SNOMED СТ. приведенные в настоящем примере, будут переработаны в соответствии с рекомендациями окончательной версии этого руководства.

5.7.3    Пример XSLT-преобразования для визуализации АКД-документа

В подразделе приложения приведен пример XSLT-преобразования АКД-документа е формат HTML. Его можно использовать как отправную точку для местной разработки, аналогичной преобразованию. Ему присущи некоторые известные ограничения, в том числе:

•    при местной разработке могут предъявляться другие требования к отображению заголовка АКД-документа:

•    не поддерживается отображение области интереса;

- не поддерживается отображение вложенных мультимедийных данных (например, закодированных в формате Base 64 внутри АКД-документа);

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

5.8 Указания по реализации

5.8.1 Создание АКД-документов

Введение

Для создания АКД-документов используется все более возрастающее разнообразие средств и методов:

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

•    системы ведения электронных медицинских карт: многие производители систем ведения электронных медицинских карт обеспечивают экспорт документов в формате АКД. Обычно это не является стандартной функцией и делается по запросу. Для этих систем формат АКД представляется относительно простым форматом вывода;

•    XML-формы: новое поколение средств конструирования XML-форм позволяет создавать формы ввода, при заполнении которых создаются АКД-документы:

•    база знаний; по крайней мере один из основных поставщиков медицинской помощи США разработал редактор АКД-документов поверх базы знаний, предназначенный для структурированного ввода с доступом к базе;

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

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

Прежде чем начать: соответствие модели RIM:

•    структуры, словарь, типы данных.

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

Модель RIM. однако, является очень абстрактной и позволяет использовать много обширных словарных доменов. Хотя возможность отображения на модель RIM является необходимым условием генерации АКД-документов. для создания документов недостаточно выбрать метод генерации или вид пользовательского интерфейса.

АКД является спецификацией обмена документами, а не конструирования документов:

•    спецификация АКД не является определяющей для создания документов.

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

Например, для удовлетворения требования АКД к человекочитаемости необходимо создать единую таблицу стилей, с помощью которой можно отобразить заверяемое клиническое содержание любого АКД-документа. Если бы элементы общей схемы АКД-документов были определены соответствующими разделами документа, к примеру. <historyOfPresentlllness> (история текущего заболевания) или <Subjective> (жалобы), то в таблицу стилей мог бы быть включен код. распознающий их как теги уровня раздела и обеспечивающий их адекватный вывод. Но подход АКД. при котором разделам соответствуют элементы section, а типы разделов задаются с помощью кодированного слова, означает, что расширяемость АКД обеспечивается не только за счет применения внешних словарных доменов, управляемых другими организациями, но и разработчики документов получают гибкие возможности создания иерархий разделов и присвоения им имен и тегов в соответствии с местными требованиями, которые позволяют сохранить совместимость в контексте обмена. Таким образом, использование специфичных имен тегов облегчает местную разработку графических интерфейсов пользователя, но там. где практика накладывает более жесткие требования, для АКД требовалось использовать более общий подход.

Необходимо учитывать оба комплекса требований — для конструирования документов и для их передачи. При определенной общности интересов, например в единой корпорации, в профессионал fa-ных ассоциациях и в некоторых случаях в местных и региональных органах управления адравоохране-нием, может быть достигнуто твердое соглашение о форме документа, и определения структуры до» кументов для их конструирования и передачи совпадут. Учитывая разнообразие местных требований, можно утверждать, что универсального обмена документами не будет до тех пор. пока не будет выработано универсальное соглашение. Скучно повторять, что АКД останется общим стандартом обмена документами, и должны быть предложены другие подходы к разработке требований по проверке ввода данных и создания документов.

Общие подходы: ограничение или преобразование:

•    ограничение: получение правильного АКД-документа непосредственно из системы конструирования документов с использованием схемы, отличающейся от схемы АКД-документов:

•    преобразование: использование местной XML-схемы. преобразование в АКД-документ.

Первый способ состоит в наложении ограничений на схему АКД-документое. в результате которого будет получена спецификация конкретного типа документа (см. приведенное ниже обсуждение создания АКД-документов с использованием местной схемы). Существует несколько способов наложения ограничений. Один из них состоит в модификации самой схемы АКД-документов. превращающей ее в местный вариант (см. local.cda.xsd на рисунке 3). Модификации могут включать в себя ограничение уровней вложения, ограничение словарей данных и последовательности компонентов: например, можно потребовать, чтобы раздел section с кодом LOINC. соответствующим «жалобам», был первым в теле документа, а за ним следовал раздел section с кодом LOINC. соответствующим «результатам осмотра». Такие модификации могут быть отражены в самой XML-схеме или с помощью выражений XPath е местной схеме. Экземпляры документов, которые будут соответствовать этой ограниченной, местной версии схемы АКД-документов. будут, по определению, также и правильными АКД-документами.

Создание: проверка соответствия экземпляра документа местной схеме


Местная схема local. CDA.xsd

Используе


я проверки


CDA.xml

Создание

Рисунок 3 — Использование ограниченной местной схемы


Одним их типов ограничений схемы являются шаблоны. В настоящее время комитет HL7 работает над созданием формального способа описания шаблонов (см. 5.1.2.2).

Второй подход состоит в создании местной схемы и преобразовании местного экземпляра XML-документа в АКД-документ (см. рисунок 4).

Получение: проверка соответствия экземпляра документа схеме CDA.xml


Создание: проверка соответствий экземпляра документа местной схеме

Ислольз^гё^для проверки


local.xml


Преобразован ие местного экземпляра документа в АКД* документ

local.xml

CDA.xml


Необязательно: проверка соответствия экземпляра документа C0A.xml

И спол ьзуетс|»да|^п ровер


CDA.xsd


Ислользу


я проверки


Создание


Преобразование


CDA.xml


Передача

Рисунок 4 — Использование местной схемы и местного экземпляра XML-документа

5.8.2 Коды документов в классификации LOINC

Содержание таблицы 147 позаимствовано из версии 2.14 классификации LOINC (декабрь 2004 года). Оно представляет собой подмножество, состоящее из строк, у которых атрибут SCALE (шкала) имеет значение «DOC» (и статус не равен «DEL»). Модель документа в этой классификации включает в себя компоненты «тип услуги» (столбец COMPONENT), «условия медицинской помощи» (столбец SYSTEM), «предметная область» (столбец METHOD.TYP) и «профессиональный уровень» (также в столбце METHOD_TYP).

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

Совокупность кодов условий медицинской помощи представляет собой умеренное расширение грубой классификации, используемой организацией CMS (Centers for Medicare and Medicaid Services — центры услуг Medicare и Medicaid). Понятие условий оказания медицинской помощи не эквивалентно месту ее оказания, смысл которого обычно более вольно трактуется местными правилами.

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

Таблица 147 — Коды документов в классификации LOINC

LOINC.

HUM

COMPONENT (тип услуги)

SYSTEM (условия медицинской помощи)

METHOO.TYP (предметная область имли профессиональный уровень)

34862-3

Оценка состояния при поступлении (ADMISSION EVALUATION NOTE)

Стационар (INPATIENT)

Лечащий врач — врач общей практики (ATTENDING PHYSICIAN.GENERAL MEDICINE)

34744-3

Оценка состояния при поступлении (ADMISSION EVALUATION NOTE)

Различные ((SETTING))

Сестринское дело (NURSING)

LOINC

NUM

COMPONENT <тяп услуги)

SYSTEM {условия медицинской помощи)

METHOO_TYP (предметная область и/ипи профессиональный уровень)

34873-0

Оценка состояния при поступлении (ADMISSION EVALUATION NOTE)

Различные ((SETTING})

Хирургия (SURGERY)

34094-3

Анамнез и фнзикальное обследование при госпитализации (осмотр при поступлении) (ADMISSION HISTORY AND PHYSICAL NOTE)

Стационар (HOSPITAL)

Кардиология (CARDIOLOGY)

34763-3

Анамнез и фнзикальное обследование при госпитализации (осмотр при поступлении) (ADMISSION HISTORY AND PHYSICAL NOTE)

Различные ({SETTING})

Общая медицинская практика (GENERAL MEDICINE)

28615-3

Обследование логопедом (AUDIOLOGY STUDY)

Различные ({SETTING})

18743-5

Протокол вскрытия (AUTOPSY NOTE)

Различные {{SETTING})

Исполнитель ({PROVIDER))

33720-4

Заключение банка крови (BLOOD BANK CONSULT)

Различные ({SETTING})

34095-0

Подробный анамнез и фнзикальное обследование (первичный осмотр) (COMPREHENSIVE HISTORY & PHYSICAL NOTE)

Разгонные ({SETTING})

Исполнитель ({PROVIDER})

34096-8

Подробный анамнез и фнзикальное обследование (первичный осмотр) (COMPREHENSIVE HISTORY & PHYSICAL NOTE)

Клиника сестринского ухода (NURSING НОМЕ)

34098-4

Коллвгиагъная оценка состояния (CONFERENCE EVALUATION NOTE)

Различные ({SETTING})

Исполнитель ({PROVIDER})

34097-6

Коллегиальная оценка состояния (CONFERENCE EVALUATION NOTE)

Клиника сестринского ухода (NURSING НОМЕ)

Исполнитель ({PROVIDER})

24611-6

Подтверждающая консультация (CONFIRMATORY CONSULTATION NOTE)

Амбулатория

(OUTPATIENT)

Исполнитель ({PROVIDER})

11488-4

Консультация (CONSULTATION NOTE)

Различные ({SETTING})

Исполнитель ({PROVIDER})

34100-8

Консультация (CONSULTATION NOTE)

Отделение интенсивной терапии (CRITICAL CARE UNIT)

Исполнитель ({PROVIDER})

34104-0

Консультация (CONSULTATION NOTE)

Стационар (HOSPITAL)

Исполнитель ({PROVIDER})

34749-2

Консультация (CONSULTATION NOTE)

Амбулатория

(OUTPATIENT)

Анестезия (ANESTHESIA)

34099-2

Консультация (CONSULTATION NOTE)

Разгонные ({SETTING})

Кардиология (CARDIOLOGY)

34756-7

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Стоматология (DENTISTRY)

34758-3

Консультация (CONSULTATION NOTE)

Разгонные {{SETTING})

Дерматология

(DERMATOLOGY)

34760-9

Консультация (CONSULTATION NOTE)

Различные ({SETTING})

Диабетология (DIABETOLOGY)

34879-7

Консультация (CONSULTATION NOTE)

Разгонные {{SETTING})

Эндокринология

(ENDOCRINOLOGY)

Продолжение таблицы 147

LOINC

NUM

COMPONENT {тяп услуги)

SYSTEM {условия ыедициискон помощи)

METHOO_TYP (предиетиая область и/ипи профессиональный уровень)

34761-7

Консультация (CONSULTATION NOTE)

Различные ({SETTING})

Гастроэнтерология (GASTROENTEROL OGY)

34764-1

Консультация (CONSULTATION NOTE)

Различные ({SETTING})

Общая медицинская практика {GENERAL MEDICINE)

34101-6

Консультация (CONSULTATION NOTE)

Амбулатория

(OUTPATIENT)

Общая медицинская практика {GENERAL MEDICINE)

34771-6

Консультация (CONSULTATION NOTE)

Различные ({SETTING})

Общая хирургия (GENERAL SURGERY)

34776-5

Консультация (CONSULTATION NOTE)

Различные ({SETTING})

Геронтология

(GERONTOLOGY)

34777-3

Консультация (CONSULTATION NOTE)

Различные

{{SETTING})

Гинекология (GYNECOLOGY)

34779-9

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Онкогематология

(HEMATOLOGY+ONCOLOGY)

34781-5

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Инфекционное заболевание (INFECTIOUS OISEASE)

34783-1

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Лечебная физкультура (KINESIOTHERAPY)

34785-6

Консультация (CONSULTATION NOTE)

Различные ({SETTING})

Психологическое здоровье (MENTAL HEALTH)

34795-5

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Нефрология (NEPHROLOGY)

34797-1

Консультация (CONSULTATION NOTE)

Различные ({SETTING})

Нейрология (NEUROLOGY)

34798-9

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Нейрохирургия

(NEUROSURGERY)

34800-3

Консультация (CONSULTATION NOTE)

Разгонные {{SETTING})

Питание и диета (NUTRITION+DIETE TICS)

34803-7

Консультация (CONSULTATION NOTE)

Разгонные {{SETTING})

Трудотерапия (OCCUPATIONAL THERAPY)

34855-7

Консультация (CONSULTATION NOTE)

Разгонные {{SETTING})

Трудотерапия (OCCUPATIONAL THERAPY)

34805-2

Консультация (CONSULTATION NOTE)

Различные ({SETTING})

Онкология (ONCOLOGY)

34807-8

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Офтальмология

(OPHTHALMOLOGY)

34810-2

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Оптомегрия (OPTOMETRY)

34812-8

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Челюстно-лицевая хирургия (OROMAXILLOFACJ AL SURGERY)

34814-4

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Ортопедия (ORTHOPEDICS)

34816-9

Консультация (CONSULTATION NOTE)

Различные ({SETTING})

Отоларингология

(OTORHINOLARYNGOLOGY)

34820-1

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Фармакология (PHARMACY)

34822-7

Консультация

Различные

Физиотерапия и

LOINC

NUM

COMPONENT {тяп услуги)

SYSTEM {условия медицинской помощи)

METHOO_TYP (предметней область и.'ипи профессиональный уровень)

{CONSULTATION NOTE)

{{SETTING})

реабилитация (PHYSICAL MEDICINE AND REHABILITATION)

34824-3

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Физиотерапия (PHYSICAL THERAPY)

34826-8

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Пластический хирург (PLASTIC SURGERY)

34828-4

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Педиатрия (PODIATRY)

34788-0

Консультация (CONSULTATION NOTE)

Разгонные {{SETTING})

Психиатрия (PSYCHIATRY)

34102-4

Консультация (CONSULTATION NOTE)

Стационар (HOSPITAL)

Психиатрия (PSYCHIATRY)

34791-4

Консультация (CONSULTATION NOTE)

Различные ({SETTING})

Психология (PSYCHOLOGY)

34103-2

Консультация (CONSULTATION NOTE)

Разгонные {{SETTING})

Пульмонология (PULMONARY)

34831-8

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Онкологическая лучевая терапия (RADIATION ONCOLOGY)

34833-4

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Санаторно-курортное лечение (RECREATIONAL THERAPY)

34835-9

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Реабилитация

(REHABILITATION)

34837-5

Консультация (CONSULTATION NOTE)

Различные ({SETTING})

Дыхательная терапия (RESPIRATORY THERAPY)

34839-1

Консультация (CONSULTATION NOTE)

Разгонные {{SETTING})

Ревматология

(RHEUMATOLOGY)

34841-7

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Социальная работа {SOCIAL WORK)

34845-8

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Логопедия (SPEECH THERAPY ♦AUDIOLOGY)

34847-4

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Хирургия (SURGERY)

34849-0

Консультация (CONSULTATION NOTE)

Разгонные {{SETTING})

Торакальная хирургия (THORACIC SURGERY)

34851-6

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Урология (UROLOGY)

34853-2

Консультация (CONSULTATION NOTE)

Различные {{SETTING})

Сосудистая хирургия {VASCULAR SURGERY)

34864-9

Консультация (COUNSELING NOTE)

Разгонные {{SETTING})

Психологическое здоровье (MENTAL HEALTH)

34869-8

Консультация (COUNSELING NOTE)

Различные ({SETTING})

Фармакология (PHARMACY)

34865-6

Консультация (COUNSELING NOTE)

Разгонные ({SETTING})

Психиатрия (PSYCHIATRY)

34866-4

Консультация (COUNSELING NOTE)

Различные {{SETTING})

Психология (PSYCHOLOGY)

34872-2

Консультация (COUNSELING NOTE)

Различные ({SETTING})

Социальная работа (SOCIAL WORK)

28622-9

Оценка состояния при выписке (DISCHARGE ASSESSMENT NOTE)

Различные ({SETTING})

Сестринское дело (NURSING)

28574-2

Выписной эпикриз (DISCHARGE NOTE)

Разгонные {{SETTING})

Исполнитель ({PROVIDER})

Продолжение таблицы 147

LOINC

NUM

COMPONENT <тяп услуги)

SYSTEM {условия медицинской помощи)

METHOO_TYP (предиетиая область и/ипи профессиональный уровень)

18842-5

Выписной эпикриз (DISCHARGE SUMMARIZATION NOTE)

Различные ((SETTING})

Исполнитель ({PROVIDER))

34105-7

Выписной эпикриз (DISCHARGE SUMMARIZATION NOTE)

Стационар (HOSPITAL)

Исполнитель ({PROVIDER))

28655-9

Выписной эпикриз (DISCHARGE SUMMARIZATION NOTE)

Различные {{SETTING})

Лечащий врач (ATTENDING PHYSICIAN)

29761-4

Выписной эпикриз (DISCHARGE SUMMARIZATION NOTE)

Различные ({SETTING})

Стоматология (DENTISTRY)

34745-0

Выписной эпикриз (DISCHARGE SUMMARIZATION NOTE)

Различные ({SETTING})

Сестринское дело (NURSING)

11490-0

Выписной эпикриз (DISCHARGE SUMMARIZATION NOTE)

Различные {{SETTING})

Терапевт (PHYSICIAN)

34106-5

Выписной эпикриз (DISCHARGE SUMMARIZATION NOTE)

Стационар (HOSPITAL)

Терапевт (PHYSICIAN)

34895-3

Запись о санитарном просвещении пациента (EDUCATION NOTE)

Различные {{SETTING})

Исполнитель ({PROVIDER})

34897-9

Запись о санитарном просвещении пациента (EDUCATION NOTE)

Различные {{SETTING})

Диабетология (DIABETOLOGY)

34902-7

Запись о санитарном просвещении пациента (EDUCATION NOTE)

Амбулатория

(OUTPATIENT)

Геронтология

(GERONTOLOGY)

34107-3

Запись о санитарном просвещении пациента (EDUCATION PROCEDURE NOTE)

Лечение на дому (HOME HEALTH)

Исполнитель ({PROVIDER))

34108-1

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT)

Амбулатория

(OUTPATIENT)

Исполнитель ({PROVIDER})

34109-9

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Исполнитель ({PROVIDER})

34111-5

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Служба скорой помощи (EMERGENCY DEPARTMENT)

Исполнитель ({PROVIDER))

34112-3

Оценка состояния и план лечения (EVALUATION ANO MANAGEMENT NOTE)

Стационар (INPATIENT)

Исполнитель ({PROVIDER))

34113-1

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Клиника сестринского ухода (NURSING НОМЕ)

Исполнитель ({PROVIDER))

34750-0

Оценка состояния и план лечения (EVALUATION ANO MANAGEMENT NOTE)

Различные ({SETTING})

Анестезия (ANESTHESIA)

34856-5

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Антмкоагуляционная терапия (ANTICOAGULATIO N)

34769-0

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Лечащий врач — врач общей практики (ATTENDING PHYSI-CIAN.GENERAL MEDICINE)

LOINC

NUM

COMPONENT <тяп услуги)

SYSTEM {условия медицинской помощи)

METHOO_TYP (предметная область и/ипи профессиональный уровень)

34773-2

Оценка состояния и плен лечения (EVALUATION AND MANAGEMENT NOTE)

Разгонные ((SETTING})

Лечащий врач — хирург {ATTENDING PHYSIC IAN.GENER-AL SURGERY)

34752-6

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ((SETTING})

Кардиология (CARDIOLOGY)

34753-4

Оценка состояния и план лечения (EVALUATION ANO MANAGEMENT NOTE)

Амбулатория

(OUTPATIENT)

Кардиология (CARDIOLOGY)

34754-2

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ((SETTING})

Интенсивная терапия (CRITICAL CARE)

34757-5

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Разгонные {{SETTING})

Стоматология (DENTISTRY)

34759-1

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Разгонные {{SETTING})

Дерматология

(DERMATOLOGY)

34661-5

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Диабетология (DIABETOLOGY)

34110-7

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Амбулатория

(OUTPATIENT)

Диабетология (DIABETOLOGY)

34678-9

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Скорая медицинская помощь (EMERGENCY MEDICINE)

34898-7

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Разгонные {{SETTING})

Эндокринология

(ENDOCRINOLOGY)

34762-5

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Гастроэнтерология

(GASTROENTEROLOGY)

34765-8

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Разгонные {{SETTING})

Общая медицинская практика (GENERAL MEDICINE)

34766-6

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Амбулатория

(OUTPATIENT)

Общая медицинская практика (GENERAL MEDICINE)

34772-4

Оценка состояния и план лечения (EVALUATION ANO MANAGEMENT NOTE)

Различные ({SETTING})

Общая хирургия (GENERAL SURGERY)

34778-1

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Гинекология (GYNECOLOGY)

34780-7

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Онкогематология

(HEMATOLOGY+ONCOLOGY)

Продолжение таблицы 147

LOINC

NUM

COMPONENT <тяп услуги)

SYSTEM {условия медицинской помощи)

METHOO_TYP (предметная область и/ипи профессиональный уровень)

34859-9

Оценка состояния и плен лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ((SETTING})

Гиперлипидемия (HYPERLIPIDEMIA)

34860-7

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ((SETTING})

Артериальная гипертензия (HYPERTENSION)

34782-3

Оценка состояния и план лечения (EVALUATION ANO MANAGEMENT NOTE)

Разгонные {{SETTING})

Инфекционное заболевание (INFECTIOUS DISEASE)

34784-9

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Лечебная физкультура (KINESIOTHERAPY)

34767-4

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Студент медицинского ВУЗа. Общая медицинская практика (MEDICAL STUDENT.GENERAL MEDICINE)

34786-4

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Психическое здоровье (MENTAL HEALTH)

34794-0

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Многодисциплинарный

(MULTIDISCIPLINARY)

34796-3

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Нефрология (NEPHROLOGY)

34905-0

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Нейрология (NEUROLOGY)

34799-7

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Нейрохирургия

(NEUROSURGERY)

34768-2

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Медсестра общей медицинской практики (NURSE.GENERAL MEDICINE)

34746-8

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различны ({SETTING))

Сестринское дело (NURSING)

34801-1

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Питание и диета (NUTRI-TION+DIETE TICS)

34802-9

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Трудотерапия (OCCUPATIONAL THERAPY)

34804-5

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Трудотерапия (OCCUPATIONAL THERAPY)

LOINC

NUM

COMPONENT <тяп услуги)

SYSTEM {условия медицинской помощи)

METHOO_TYP (предметная область и/ипи профессиональный уровень)

34806-0

Оценка состояния и плен лечения (EVALUATION AND MANAGEMENT NOTE)

Разгонные ((SETTING})

Онкология (ONCOLOGY)

34808-6

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ((SETTING})

Офтальмология

(OPHTHALMOLOGY)

34811-0

Оценка состояния и план лечения (EVALUATION ANO MANAGEMENT NOTE)

Разгонные {{SETTING})

Олтомегрия (OPTOMETRY)

34813-6

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Челюстно-лицевая хирургия (OROMAX1LLOFAC1AL SURGERY)

34815-1

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Разгонные {{SETTING})

Ортопедия (ORTHOPEDICS)

34817-7

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Разгонные {{SETTING})

Отоларингология

(OTORHINOLARYNGOLOGY)

34858-1

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Введение обезболивания (PAIN MANAGEMENT)

34819-3

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Патология (PATHOLOGY)

34821-9

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Фармакология (PHARMACY)

34823-5

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Разгонные {{SETTING})

Физиотерапия и реабилитация (PHYSICAL MEDICINE AND REHABILITATION)

34825-0

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Физиотерапия (PHYSICAL THERAPY)

34827-6

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Разгонные {{SETTING})

Пластический хирург (PLASTIC SURGERY)

34829-2

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Разгонные ({SETTING})

Педиатрия (PODIATRY)

34789-8

Оценка состояния и план лечения (EVALUATION ANO MANAGEMENT NOTE)

Различные ({SETTING})

Психиатрия (PSYCHIATRY)

34792-2

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Психология (PSYCHOLOGY)

34830-0

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Пульмонология (PULMONARY)

Продолжение таблицы 147

L0INC

NUM

COMPONENT <тяп услуги)

SYSTEM {условия медицинской помощи)

METHOO_TYP (предметная область и/ипи профессиональный уровень)

34832-6

Оценка состояния и плен лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ((SETTING})

Онкологическая лучевая терапия (RADIATION ONCOLOGY)

34834-2

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ((SETTING})

Санаторно-курортное лечение (RECREATIONAL THERAPY)

34836-7

Оценка состояния и план лечения (EVALUATION ANO MANAGEMENT NOTE)

Разгонные {{SETTING})

Реабилитация

(REHABILITATION)

34838-3

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Дыхательная терапия (RESPIRATORY THERAPY)

34640-9

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Разгонные {{SETTING})

Ревматология

(RHEUMATOLOGY)

34842-5

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Социальная работа (SOCIAL WORK)

34646-6

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Логопедия (SPEECH THERAPY-+AUDIOLOGY)

34857-3

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Злоупотребление сильнодействующими и веществами (SUBSTANCE ABUSE)

34648-2

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Хирургия (SURGERY)

34850-8

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Амбулатория

(OUTPATIENT)

Торахальная хирургия (THORACIC SURGERY)

34852-4

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Урология (UROLOGY)

34854-0

Оценка состояния и план лечения (EVALUATION AND MANAGEMENT NOTE)

Амбулатория

(OUTPATIENT)

Сосудистая хирургия (VASCULAR SURGERY)

34114-9

Консилиум (GROUP COUNSELING NOTE)

Стационар (HOSPITAL)

Исполнитель ({PROVIDER})

34787-2

Консилиум (GROUP COUNSELING NOTE)

Разгонные ({SETTING})

Психическое здоровье (MENTAL HEALTH)

34790-6

Консилиум (GROUP COUNSELING NOTE)

Разгонные {{SETTING})

Психиатрия (PSYCHIATRY)

34793-0

Консилиум (GROUP COUNSELING NOTE)

Психология (PSYCHOLOGY)

34843-3

Консилиум (GROUP COUNSELING NOTE)

Разгонные {{SETTING})

Социальная работа (SOCIAL WORK)

LOINC

NUM

COMPONENT {тяп услуги)

SYSTEM {условия медицинской помощи)

METHOO_TYP (предметная область и/ипи профессиональный уровень)

11492-6

Анамнез и фнзикальное обследование {HISTORY & PHYSICAL NOTE)

Стационар (HOSPITAL)

Исполнитель ({PROVIDER))

34774-0

Анамнез и фнзикальное обследование {HISTORY & PHYSICAL NOTE)

Различные ({SETTING})

Общая хирургия (GENERAL SURGERY)

34115-6

Анамнез и фнзикальное обследование {HISTORY & PHYSICAL NOTE)

Стационар (HOSPITAL)

Студент медицинского ВУЗа {MEDICAL STUDENT)

28626-0

Анамнез и фнзикальное обследование {HISTORY & PHYSICAL NOTE)

Различные ({SETTING})

Терапевт (PHYSICIAN)

34116-4

Анамнез и фнзикальное обследование {HISTORY & PHYSICAL NOTE)

Клиника сестринского ухода (NURSING НОМЕ)

Терапевт (PHYSICIAN)

34117-2

Анамнез и фнзикальное обследование {HISTORY AND PHYSICAL NOTE)

Различные ({SETTING})

Исполнитель ({PROVIDER})

18841-7

Консультация в стационаре (HOSPITAL CONSULTATIONS)

Различные ({SETTING})

28636-9

Первичная оценка состояния (INITIAL EVALUATION NOTE)

Различные ({SETTING})

Исполнитель ({PROVIDER})

34118-0

Первичная оценка состояния (INITIAL EVALUATION NOTE)

Лечение на дому (HOME HEALTH)

Исполнитель ({PROVIDER})

34119-8

Первичная оценка состояния (INITIAL EVALUATION NOTE)

Клиника сестринского ухода (NURSING НОМЕ)

Исполнитель ({PROVIDER})

34120-6

Первичная оценка состояния (INITIAL EVALUATION NOTE)

Амбулатория

(OUTPATIENT)

Исполнитель ({PROVIDER})

28654-2

Первичная оцвнха состояния (INITIAL EVALUATION NOTE)

Различные {{SETTING})

Лечащий врач (ATTENDING PHYSICIAN)

28581-7

Первичная оцемса состояния (INITIAL EVALUATION NOTE)

Различные {{SETTING})

Мануальный терапевт (CHIROPRACTOR)

18763-3

Первичная оцемса состояния (INITIAL EVALUATION NOTE)

Разтчные {{SETTING})

Врач-консультант {CONSULTING PHYSICIAN)

28572-6

Первичная оцвнха состояния (INITIAL EVALUATION NOTE)

Разтчные {{SETTING})

Стоматология (DENTISTRY)

28621-1

Первичная оцвнха состояния (INITIAL EVALUATION NOTE)

Разтчные {{SETTING})

Фельдшер (NURSE PRACTITIONER)

29753-1

Первичная оцвнха состояния (INITIAL EVALUATION NOTE)

Различные {{SETTING})

Сестринское дело (NURSING)

18734-4

Первичная оцвнха состояния (INITIAL EVALUATION NOTE)

Различные {{SETTING})

Трудотерапия

(OCCUPATIONAL THERAPY)

18735-1

Первичная оцвнха состояния (INITIAL EVALUATION NOTE)

Разтчные {{SETTING})

Физиотерапия {PHYSICAL THERAPY)

18736-9

Первичная оцвнха состояния (INITIAL EVALUATION NOTE)

Разгонные {{SETTING})

Терапевт (PHYSICIAN)

18737-7

Первичная оцвнха состояния {INITIAL EVALUATION NOTE)

Разгонные {{SETTING})

Педиатрия (PODIATRY)

Продолжение таблицы 147

LOINC

NUM

COMPONENT {тип услуги)

SYSTEM {условия медицинской помощи)

METHOO_TYP (предметная область и/ипи профессиональный уровень)

28635-1

Первичная оценю состояния (INITIAL EVALUATION NOTE)

Различные ((SETTING})

Психиатрия (PSYCHIATRY)

18738-5

Первичная оценю состояния (INITIAL EVALUATION NOTE)

Различные ({SETTING})

Психология (PSYCHOLOGY)

18739-3

Первичная оценю состояния (INITIAL EVALUATION NOTE)

Различные {{SETTING})

Социальная служба (SOCIAL SERVICE)

18740-1

Первичная оценка состояния (INITIAL EVALUATION NOTE)

Различные ({SETTING})

Логопедия (SPEECH THERAPY)

34121-4

Протокол вмешательства (INTERVENTIONAL PROCEDURE NOTE)

Разгычные {{SETTING})

34896-1

Протокол вмешательства (INTERVENTIONAL PROCEDURE NOTE)

Различные {{SETTING})

Кардиология

(CARDIOLOGY)

34899-5

Протокол вмешательства (INTERVENTIONAL PROCEDURE NOTE)

Различные ({SETTING})

Гастроэнтерология

(GASTROENTEROLOGY)

34903-5

Запись (NOTE)

Различные {{SETTING})

Психическое здоровье (MENTAL HEALTH)

34906-8

Запись (NOTE)

Различные ({SETTING})

Духовная помощь (PASTORAL CARE)

11536-0

Записи (NOTES)

Различные {{SETTING})

Сестринское дело (NURSING)

34868-0

Протокол операции (OPERATIVE NOTE)

Различные {{SETTING})

Ортопедия (ORTHOPEDICS)

34818-5

Протокол операции (OPERATIVE NOTE)

Разтчные {{SETTING})

Отоларингология

(OTORHINOLARYNGOLOGY)

34870-6

Протокол операции (OPERATIVE NOTE)

Разтчные {{SETTING})

Пластический хирург (PLASTIC SURGERY)

34871-4

Протокол операции (OPERATIVE NOTE)

Разгычные {{SETTING})

Педиатрия (PODIATRY)

34874-8

Протокол операции (OPERATIVE NOTE)

Разгычные {{SETTING})

Хирургия (SURGERY)

34877-1

Протокол операции (OPERATIVE NOTE)

Разгычные {{SETTING})

Урология (UROLOGY)

34122-2

Протокол диагностического исследования (PATHOLOGY PROCEDURE NOTE)

Различные ({SETTING})

Диагностика (PATHOLOGY)

34863-1

Постоперационная оценка состояния и план лечения (Постоперационный эпикриз) (POST-OPERATIVE EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Общая хирургия (GENERALSURGERY)

LOINC

NUM

COMPONENT {тип услуги)

SYSTEM {условия медицинской помощи)

METHOO_TYP (предметная область и/иои профессиональный уровень)

34880-5

Постоперационная оценка состояния и план лечения {Постоперационный эпикриз) (POST-OPERATIVE EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Операционная сестра (NURSE.SURGERY)

34867-2

Постооерационная оценка состояния и план лечения {Постоперационный эпикриз) (POST-OPERATIVE EVALUATION AND MANAGEMENT NOTE)

Амбулатория

(OUTPATIENT)

Офтальмология

(OPHTHALMOLOGY)

34875-5

Постооерационная оценка состояния и план лечения {Постоперационный эпикриз) (POST-OPERATIVE EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Хирургия (SURGERY)

34751-В

Предоперационная оценка состояния и план лечения (предоперационный эпикриз) (PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE)

Разгонные {{SETTING})

Анестезия (ANESTHESIA)

34123-0

Предоперационная оценка состояния и план лечения {предоперационный эпикриз) (PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE)

Стационар (HOSPITAL)

Анестезия (ANESTHESIA)

34775-7

Предоперационная оценка состояния и план лечения (предоперационный эпикриз) (PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Общая хирургия (GENERAL SURGERY)

34881-3

Предоперационная оценка состояния и план лечения (предоперационный эпикриз) (PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Операционная сестра (NURSE.SURGERY)

34747-6

Предоперационная оценка состояния и план лечения (предоперационный эпикриз) (PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Сестринское дело (NURSING)

34809-4

Предоперационная оценка состояния и план лечения (предоперационный эпикриз) (PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE)

Различные {{SETTING})

Офтальмология

(OPHTHALMOLOGY)

34876-3

Предоперационная оценка состояния и план лечения (предоперационный эпикриз) (PRE-OPERATIVE EVALUATION AND MANAGEMENT NOTE)

Различные ({SETTING})

Хирургия (SURGERY)

28570-0

Протокол (PROCEDURE NOTE)

Различные {{SETTING})

Исполнитель ({PROVIDER})

вз

Продолжение таблицы 147

LOINC

NUM

COMPONENT {тип услуги)

SYSTEM {условия ыедициискон помощи)

METHOO_TYP (предиетмоя область и.'ипи профессиональный уровень)

28577-5

Протокол (PROCEDURE NOTE)

Различные ({SETTING})

Стоматология (DENTISTRY)

11505-5

Протокол (PROCEDURE NOTE)

Различные ({SETTING})

Терапевт (PHYSICIAN)

28625-2

Протокол (PROCEDURE NOTE)

Различные ({SETTING})

Педиатрия (PODIATRY)

28580-9

Дневниковая запись (PROGRESS NOTE)

Различные ({SETTING})

Мануальный терапевт (CHIROPRACTOR)

28575-9

Дневниковая запись (PROGRESS NOTE)

Различные {{SETTING})

Фельдшер (NURSE PRACTITIONER)

18744-3

Протокол исследования (STUDY REPORT)

Респираторная система

(RESPIRATORY

SYSTEM)

Бронхоскопия

(BRONCHOSCOPY)

11506-3

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Различные {{SETTING})

Исполнитель ({PROVIDER})

34126-3

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Отделение интенсивной терапии (CRITICAL CARE UNIT)

Исполнитель ({PROVIDER))

15507-7

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Служба скорой ломо(ци

(EMERGENCY

DEPARTMENT)

Исполнитель ({PROVIDER})

34129-7

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Лечение на дому (HOME HEALTH)

Исполнитель ({PROVIDER})

34130-5

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Стационар (HOSPITAL)

Исполнитель ({PROVIDER})

34131-3

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Амбулатория

(OUTPATIENT)

Исполнитель ({PROVIDER})

18733-6

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Различные {{SETTING})

Лечащий врач (ATTENDING PHYSICIAN)

34124-8

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Амбулатория

Кардиология

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

(OUTPATIENT)

(CARDIOLOGY)

34125-5

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Печение на дому (HOME HEALTH CARE)

Менеджер медицинских услуг (CASE MANAGER)

18762-5

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Разгонные {{SETTING})

Мануальный терапевт (CHIROPRACTOR)

28569-2

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Различные {{SETTING})

Врач-консультант (CONSULTING PHYSICIAN)

34127-1

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Амбулатория

(OUTPATIENT)

Стоматолог-гигиенист (DENTAL HYGIENIST)

28617-9

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Разгонные {{SETTING})

Стоматология (DENTISTRY)

34128-9

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Амбулатория

(OUTPATIENT)

Стоматология (DENTISTRY)

34900-1

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Различные

{{SETTING})

Общая медицинская практика (GENERAL MEDICINE)

LOINC

NUM

COMPONENT {тяп услуги)

SYSTEM {условия медицинской помощи)

METHOO_TYP (предметная область и/ипи профессиональный уровень)

34901-9

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Амбулатория

(OUTPATIENT)

Общая медицинская практика (GENERAL MEDICINE)

34904-3

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Различные ({SETTING})

Психическое здоровье (MENTAL HEALTH)

18764-1

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Различные {{SETTING})

Фельдшер (NURSE PRACTITIONER)

28623-7

Очередная оцемса состояния (SUBSEQUENT EVALUATION NOTE)

Различные ({SETTING})

Сестринское дело (NURSING)

11507-1

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Различные ({SETTING})

Трудотерапия (OCCUPATIONAL THERAPY)

34132-1

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Амбулатория

(OUTPATIENT)

Фармакология (PHARMACY)

11508-9

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Различные {{SETTING})

Физиотерапия (PHYSICAL THERAPY)

11509-7

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Различные {{SETTING})

Педиатрия (PODIATRY)

28627-8

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Различные {{SETTING})

Психиатрия (PSYCHIATRY)

11510-5

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Различные ({SETTING})

Психология (PSYCHOLOGY)

28656-7

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Различные {{SETTING})

Социальная служба (SOCIAL SERVICE)

11512-1

Очередная оценка состояния (SUBSEQUENT EVALUATION NOTE)

Различные {{SETTING})

Логопедия (SPEECH THERAPY)

34133-9

Заключение по эпизоду лечения (этапный эпикриз) (SUMMARIZATION OF EPISODE NOTE)

Различные ({SETTING})

Исполнитель ({PROVIDER))

34134-7

Контрольная запись (SUPERVISORY NOTE)

Амбулатория

(OUTPATIENT)

Лечащий врач (ATTENDING PHYSICIAN)

34135-4

Контрольная запись (SUPERVISORY NOTE)

Амбулатория

(OUTPATIENT)

Лечащий врач — кардиолог (ATTENDING PHYSICIAN.CAR-DIOLOGY)

34136-2

Контрольная запись (SUPERVISORY NOTE)

Амбулатория

(OUTPATIENT)

Лечащий врач — гастроэнтеролог (ATTENDING PHYSICIAN.

G ASTROENTE ROLOGY)

11504-8

Протокол хирургического вмешательства (SURGICAL OPERATION NOTE)

Разтчные ({SETTING})

Исполнитель ({PROVIDER})

34137-0

Протокол хирургического вмешательства (SURGICAL OPERATION NOTE)

Амбулатория

(OUTPATIENT)

Исполнитель ({PROVIDER})

28583-3

Протокол хирургического вмешательства (SURGICAL OPERATION NOTE)

Разгычные {{SETTING})

Стоматология (DENTISTRY)

28573-4

Протокол хирургического вмешательства (SURGICAL OPERATION NOTE)

Разгычные {{SETTING})

Терапевт (PHYSICIAN)

Окончание таблицы 147

LOINC

ним

COMPONENT {тяп услуги)

SYSTEM {условия медицинской помощи)

METHOO_TYP (предметная область и/ипи профессиональный уровень)

28624-5

Протокол хирургического вмешательства (SURGICAL OPERATION NOTE)

Различные ((SETTING})

Педиатрия (PODIATRY)

34138-8

История заболевания и фискальное исследование (TARGETED HISTORY AND PHYSICAL NOTE)

Разгычные {(SETTING})

Исполнитель ({PROVIDER})

34748-4

Загысь об обращении по телефону (TELEPHONE ENCOUNTER NOTE)

Различные {(SETTING})

Исполнитель ({PROVIDER))

34139-6

Загысь об обращении по телефону (TELEPHONE ENCOUNTER NOTE)

Различные {(SETTING})

Сестринское дело (NURSING)

34844-1

Запись об обращении по телефону (TELEPHONE ENCOUNTER NOTE)

Амбулатория

(OUTPATIENT)

Социальная работа (SOCIAL WORK)

34140-4

Заключение при переводе пациента (переводной эпикриз) (TRANSFER SUMMARIZATION NOTE)

Разгычные {{SETTING})

Исполнитель ({PROVIDER})

18761-7

Заключение при переводе пациента (переводной эпикриз) (TRANSFER SUMMARIZATION NOTE)

Разгычные ({SETTING})

Исполнитель ({PROVIDER})

34755-9

Заключение при переводе пациента (переводной эпикриз) (TRANSFER SUMMARIZATION NOTE)

Разгычные {{SETTING})

Интенсивная терапия (CRITICAL CARE)

34770-8

Заключение при переводе пациента (переводной эпикриз) (TRANSFER SUMMARIZATION NOTE)

Разгычные {{SETTING})

Общая медицинская практика (GENERAL MEDICINE)

28651-8

Заключение при переводе пациента (переводной эпикриз) (TRANSFER SUMMARIZATION NOTE)

Разгычные {{SETTING})

Сестринское дело (NURSING)

28616-1

Заключение при переводе пациента (переводной эпикриз) (TRANSFER SUMMARIZATION NOTE)

Разгычные ({SETTING})

Терапевт (PHYSICIAN)

28618-7

Запись о посещении (VISIT NOTE)

Разгычные ({SETTING})

Стоматология (DENTISTRY)

28578-3

Запись о посещении (VISIT NOTE)

Разгычные {{SETTING})

Трудотерапия

(OCCUPATIONAL THERAPY)

28579-1

Загысь о посещении (VISIT NOTE)

Разгычные {{SETTING})

Физиотерапия (PHYSICAL THERAPY)

28568-4

Загысь о посещении (VISIT NOTE)

Служба скорой помощи (EMERGENCY DEPARTMENT)

Терапевт (PHYSICIAN)

28571-8

Загысь о посещении (VISIT NOTE)

Разгычные ({SETTING})

Логопедия (SPEECH THERAPY)

28628-6

Запись о посещении (VISIT NOTE)

Разгычные ({SETTING})

Психиатрия (PSYCHIATRY)

5.8.3 АКД и семантическая интероперабельность

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

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

Хотя теоретические основы, заложенные в модель RIM, в спецификацию АКД и в общую модель клинических утверждений (HL7 Clinical Statement Model), являются критичными компонентами семантической интероперабельности, они пока что не являются достаточными, в особенности из-за отсутствия глобального решения по терминологии и того факта, что каждая терминология различным способом пересекается с моделью RIM. Такие терминологические решения лежат вне области применения АКД и должны обсуждаться на различных национальных и международных форумах.

5.8.4 Изменения по сравнению с первым выпуском АКД

Первый выпуск АКД (CDA, Release One) был одобрен организацией ANSI в ноябре 2000 г. и представлял собой первую спецификацию, произведенную от модели RIM (Reference Information Model). С тех пор модель RIM перешла в более зрелое состояние, равно как и методология, используемая для создания спецификаций, производных от модели RIM. Кроме того, первые разработчики, принявшие АКД на вооружение, предоставили новые варианты использования для включения в спецификацию.

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

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

Во втором выпуске АКД нашли свое отражение новые достижения комитета HL7 по разработке стандартов, использующих модели, основанные на языке XML. Вследствие эволюции модели RIM и методологии комитета HL7 по разработке стандартов, произошедшей с ноября 2000 г. во второй выпуск АКД был внесен ряд изменений по сравнению с первым выпуском.

5.8.4.1    Запрещенные компоненты

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

•    ClinicalDocument/copyTime.

•    ClinicalDocument/authenticator/signatureCode/@code=''X".

- ClinicalDocument/tegalAuthenticator/signatureCode/@code='X'.

•    ClinicalDocument/assignedAuthor/assignedAuthoringDevice/MaintainedEntity.

•    ClinicalDocument/recordTarget/patientRole/patient/id.

•    linkHtml.name,

•    table.border, table.cellspacing. tabie.cellpadding.

Дальнейшее использование этих компонентов не рекомендовано.

5.8.4.2    Соответствие между первым и вторым выпусками АКД

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

Табп ица 148 — Соответствие словарей первого и второго выпуска АКД

Словарь АКД. выпуск 1

Соответствующий словарь АКД. выпуск 2

Примечания

clinical_document_header / document type cd <= OocumentType (2.16.840.1.113883.6.1.10870)

(CWE)

ClinicaiOocument / code <= OocumentType (2.16.840.1.113883.6.1) (CWE)

clfnical_document_header / oonfidentia!ity_cd <= ServKeConfidentiality (2.16.840.1.113883.5.10228) (CWE)

ClinicaiOocument / confidenbalityCode <= x BasicConfidentialrtyKind (2.16.840.1.113883.5.25) (CWE)

Из набора качений удалены «С». «О». «I». «S». «Т». К набору значений добавлено «V»

clinical_document_header / document_relaUonship / document_relationship. type od <= ServiceRetationship (2.16.840.1.113883.5.10317) (CNE)

ClinicaiOocument / related Document / @typeCode <= x ActRelabonshipOocument (2.16.840.1.113883.5.1002) (CNE)

К набору значений добавлено «XFRM*

clinical_document_header i fulftls_order / fidfills_order. type od <= ServiceRetationship (2.16.840.1.113883.5.10317) (CNE)

ClinicaiOocument / inFuHHImentOt

/ @typeCode <= FLFS

(2.16.840.1.113883.5.1002) (CNE)

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

clinical_document_header / patient_encounter / practice, setting cd <= PracticeSetting (2.16.840.1.113883.5.10588) (CWE)

ClrnicalDocument / componentOf/ encompassing Encounter / location / healthCareFacility / code <= ServioeDeliveryLocationRoleType (2.16.840.1.113883.5.111) (CWE)

clinical_document_header / authenticator / authenticator, type cd <= Service Act or (2.16.840.1.113883.5.10246) (CNE)

ClinicaiOocument / authenticator / ©typeCode <= AUTHEN (2.16.840.1.113883.5.90) (CNE)

Фиксированное значение изменено с «VRF*на «AUTHEN»

clinical_document_header / authenticator / signature.cd <= ServiceActorSignature (2.16.840.1.113883.5.10282) (CNE)

ClinicaiOocument / authenticator t signatureCode <= ParticipationSignature (2.16.840.1.113883.5.89) (CNE)

Значение «X» запрещено

clinical_document_header / authenticator / person / person.name / person.name. type od <= PersonNamePurpose (2.16.840.1.113883.5.200) (CWE)

ClrnicalDocument / authenticator/ assignedEntity / assignedPerson / name / @use <= PersonNameUse (2.16.840.1.113883.5.45) (CNE)

Квалификатор расширяемости изменен с CWE на CNE. Во втором выпуске АКД набор значений включает в себя следующие перечисляемые значения, определенные в первом выпуске («А». «С». «I». «L». «R»). Для преобразования из первого выпуска во второй может потребоваться местная разметка в тех случаях, когда набор значений, взятых из первого выпуска, был расширен

ClinicaiOocument / legalAuthenticator / ©typeCode <= LA (2.16.840.1.113883.5.90) (CNE)

Фиксированное значение изменено с *SPV»на«AUTHEN»

clinical_document_header / legal.authenticator / signature, cd <= ServiceActorSignature (2.16.840.1.113883.5.10282) (CNE)

ClinicaiOocument / legalAuthenticator / signatureCode <= ParticipationSignature (2.16.840.1.113883.5.89) (CNE)

Значение «X» теперь запрещено

Словарь АКД. выпуск 1

Соответствующий словарь АКД. выпуск 2

Примечания

clinical_document_header / intended_recip*ent / intended, recipient.type cd <= ServiceActor (2.16.840.1.113883.5.10246) (CNE)

ClinicaiOocument / intendedRecipient / @typeCode <= x InformabonRecipient (2.16840.1.113883.5.90) (CNE)

К набору значений добавлено «PRCP*

clinical_document_header / originator / originator.type cd <= ServiceActor (2.16.840.1.113883.5.10246) (CNE)

ClinicaiOocument / author / @typeCode <= AUT (2.16.840.1.113883.5.90) (CNE)

Набор значений кв изменен

dinical_document_header i originating_organization / originating, organization .type cd <= ServiceActor (2.16.840.1.113883.5.10246) (CNE)

ClinicaiOocument / custodian / @ type Code <= CST (2.16.840.1.113883.5.90) (CNE)

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

clinical.document.header / transcriptionist l transcnptionist. type cd <= ServiceActor (2.16.840.1.113883.5.10246) (CNE)

ClinicaiOocument / dataEntsrer / @ type Code <= ENT (2.16.840.1.113883.5.90) (CNE)

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

clinical.document.header / provider / provider.type cd <= ServiceActor (2.16.840.1.113883.5.10246) (CNE) (Value set «ASS». «CON». «PRF»)

ClinicaiOocument / serviceEvent / performer / @typeCode <= x ServweEventPerformer

(2.16840.1.113883.5.90)    (CNE) (набор значений "PRF*. *PPRF\ *SPRF*)

ClinicaiOocument / encom-passingEncounterf responsi-bieParty / @typeCode <= RESP

(2.16.840.1.113883.5.90)    (CNE) ClinicaiOocument/ encom passin-gEncounter / encounterParticrpant i @typeCode <= x Encounter Participant (2.16.840.1.113883.5.90) (CNE) (набор значений «ADM». «ATND*. «CON» . «DIS* . «REF»)

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

Значение «ASS» в первом выпуске АКД коррелирует со значением «SPRF» во втором выпуске

clinical.document.header / provider / function od <= ServiceActorFunction (2.16.840.1.113883.5.10267) (CWE)

ClinicaiOocument / serviceEvent / performer / functionCode <= ParticipationFunction (2.16.840.1.113883.5.88) (CWE)

clinical.document.header / service.actor / service.actor. type cd <= ServiceActor (2.16.840.1.113883.5.10246) (CWE)

ClinicaiOocument / participant / @ typeCode <= ParticipabonType (2.16.840.1.113883.5.90) (CNE)

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

clinical.document.header / service.actor / signature.cd <= ServiceActorSignature (2.16.840.1.113883.5.10282) (CNE)

ClinicaiOocument l authenticator l signatureCode <= ParbcipationSignature (2.16.840.1.113883.5.89) (CNE)

Значение «X» теперь запрещено

clinical.document.header / patient / administrative.gender. cd <= AdministrabveGender (2.16.840.1.113883.5.1) (CWE)

ClinicaiOocument / recordTarget / pabentRote / patient / administrativeGenderCode <= AdministrativeGender (2.16.840.1.113883.5.1) (CWE)

Продолжение таблицы 148

Словарь АКД. выпуск 1

Соответствующий словарь АКД. выпуск 2

Примечания

clinical_document_header / originating_device / originating, device.type cd <= ServiceTargetType (2.16.640.1.113883.5.10285) (CNE)

ClrnicalDocument l author / @typeCode <= AUT (2.16.840.1.113883.5.90) (CNE)

Значение «ODV». определенное в первом выпусхе АКД. отображается на значение «AUT» во втором выпуске

dinical_document_header / originating_device / device / responsibility / responsibility, type cd <= MaterialResponsibilrty (2.16.840.1.113883.5.10416) (CWE)

ClrnicalDocument / author / assignedAuthor / assignedAuthoringDevice / asMaintainedEnbty/ @classCode <= MNT (2.16.840.1.113883.5.110) (CNE)

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

clinical_document_header / service.target / service.target. type od <= ServiceTargetType (2.16.840.1.113883.5.10285) (CWE)

ClinicalDocument / participant / @ typeCode <= ParbcipabonType (2.16.840.1.113883.5.90) (CNE)

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

section / caption / capbon.cd (CWE)

section / code <=

DocumentSecbonType

(2.16.840.1.113883.6.1) (CWE)

См. также элемент caption/caption_ cd в следующей строке. Соответствие заголовка раздела во втором выпуске АКД отличается от соответствия других заголовков.

caption / capbon.cd (CWE)

@styleCode <= StyleType (2.16.840.1.113883.19.5.1) (CWE)

См. также элемент section'caption/ caption_cd в предыдущей строке. Соответствие заголовка раздела во втором выпуске АКД отличается от соответствия других заголовков

Таблица 149 — Соответствие заголовков документа в первом и втором выпусхе АКД

Компонент АКД. выпуск 1

Соответствующий компонент АКД. выпуск 2

Применения

leveione

ClrnicalDocument

levetone i din*cal_document_header

ОТСУТСТВУЕТ

Тег оболочки заголовка в настоящее время отсутствует.

clinical_document_header / id

ClinicalDocument / id

clinical_document_header / setjd

ClrnicalDocunrent / setld

clinical_document_header / version_nbr

ClinicalDocument / versionNumber

clinical_document_header / document_type_cd

ClinicalDocument / code

Компонент АКД, выпуск 1

Соответствующий компонент АКД. выпуск 2

Примечания

clinical.document.header / service.tmr

ClinicalDocument / documentationOf / serviceEvent / effectiveTime

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

clinical.document.header / origination.dttm

ClinicalDocument / effectiveTime

clinical.document.header / copy_dltm

ClinicalDocument / copy Time

clinical.document.header / confidentiality_cd

ClinicalDocument / confidentialityCode

Кратность изменена с [0..*] на [0..1]. В первом выпуске АКД признак конфиденциальности задается в заголовке и используется в теле. Во втором выпуске признак конфиденциальности задается в заголовке и может быть переопределен в тепе

clinical.document.header / document.relationship

ClinicalDocument / related Document

document.relationship / document. relaUonship.lype.cd

related Document / @typeCode

document.relationship / related, document

related Document / parentDocument

document.relationship / related, document / id

related Document / parentDocument f id

document.relationship / related, document / set.id

related Document / parentDocument / setld

document.relationship / related, document / version.nbr

related Document / parentDocument / verstonNumber

chnical.document.header/

fulfills.order

ClinicalDocument l inFulfillmentOf

fulfills.order / fulfills.order.type.cd

inFulfillmentOf / @typeCode

fulfills.ordef / order

inFulfillmentOf / order

fulfills.order / order / id

inFulfillmentOf / order / id

clinical.document.header / patient, encounter

ClinicalDocument / comportentOf / encompassingEncounter

patient.encounter / id

encompassing Encounter / id

fulfills.order / order

inFulfillmentOf / order

fulfills.order / order t id

inFulfillmentOf / order / id

clinical.document.header / patient, encounter

ClinicalDocument / componentOf i encompassingEncounter

patient.encounter / id

encompassingEncounter / id

Продолжение таблицы 149

Компонент АКД, выпуск 1

Соответствующий компонент АКД. выпуск 2

Примечания

patient.encounter / practice, setting.cd

encompassing Encounter! location f healthCareFaciiity f code

patient.encounter l encounter.tmr

encompassingEncounter / effect! veTime

patient.encounter / servioe.tocation

encompassingEncounter / location f healthCareFaciiity

patient.encounter / service, location / id

encompassingEncounter i location f healthCareFaciiity f id

patient.encounter / servioe.tocation /addr

encompassingEncounter / location f healthCareFaciiity f location / addr

clinical.document.header / authenticator

ClrnicalDocument / authenticator

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

authenticator / authenticator.type.od

authenticator / @typeCode

authenticator / participation.tmr

authenticator 1 time

authenticator / signature.cd

authenticator / signatureCode

В первом выпуске АКД можно указать либо планируемую подпись контролера (код подписи «X») или наличие его подписи {код подписи «S»). Во втором выпуске разрешен только факт подписи, поэтому значение «X» запрещено

authenticator / person

authenticator / assigned Entity / assignedPerson

authenticator / person 1 id

authenticator / assigned Entity / id

authenticator / person / person.name

authenticator / assignedEntity / assignedPerson / name

authenticator / person / person.name / effective.tmr

authenticator / assignedEntity / assignedPerson / name / validTime

authenticator / person / person.name / nm

authenticator l assignedEntity / assignedPerson / name

authenticator / person / person.name / person.name.type.cd

authenticator / assignedEntity / assignedPerson / name / @use

authenticator / person / addr

authenticator / assignedEntity l addr/

authenticator / person / telecom

authenticator / assignedEntity / telecom

clinical.document.header / legal, authenticator

ClinicalOocument / legalAuthenticator

legal.authenticator / legal, authenticator.type.od

legalAuthenticator / @typeCode

Компонент АКД, выпуск 1

Соответствующий компонент АКД. выпуск 2

Примечания

legal.authenticator 1 participation.tmr

legalAuthenticator / time

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

legal.authenticator l signalure.od

legalAuthenticator / signatureCode

В первом выпуске АКД можно указать либо планируемую подпись контролера (код подписи «X») или наличие его подписи (ход подписи <cS>). Во втором выпуске разрешен только факт подписи, поэтому значение «X» запрещено

legal.authenticator l person

legalAuthenticator / assignedEntity / assignedPerson

clinical.documenl.header / intended, recipient

ClinicaiOocument / intended Recipient

intended.recipient / intended, recipient, type.cd

intendedRecipient / @typeCode

clinical.document.header / originator

ClinicalDocument / author

originator / originator.type.cd

author / @typeCode

originator / partidpation.tmr

author / time

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

clinical.document.header / originating_organization

ClinicalDocument l author ClinicalDocument l custodian

Участник originating.organization. определенный в первом выпуске АКД. соответствует атрибуту s со per элемента author И контролирующей организации, поскольку он охватывает оба этих понятия в первом выпуске

originating.organization / originating, organization .type.cd

custodian l @typeCode

originating_organtzation / organization

author I assignedAuthor / representedOrganization custodian t assignedCustodian i rep resentedCustodianOrganization

originating.organization / organization / id

author / assignedAuthor / representedOrganization / id custodian 1 assignedCustodian / rep resentedCustodianOrganization / id

Продолжение таблицы 149

Компонент АКД, выпуск 1

Соответствующий коыпоиент АКД. выпуск 2

Примечания

originatingjxganization / organization l organization.nm

author / assignedAuthor / representedOrganizabon / name custodian / assignedCustodian / re presentedCustodianOrganizabon / name

originating_organization / organization / addr

author I assignedAuthor / representedOrganizabon / addr custodian f assignedCustodian / re presentedCustodianOrganizabon l addr

clinical_document_header / transcriptionist

ClinicalDocument l dataEnterer

transcriptionist / transcriptionist type.cd

dataEnterer / @typeCode

transcriptionist / participation Jmr

dataEnterer / time

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

transcriptionist / participation_tmr

dataEnterer / time

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

clinical_document_header / provider

ClinicalDocument / serviceEvent / performer ClinicalDocument! encompassingEncounter / responsibleParty ClinicalDocument / encompassingEncounter / encounterParbcipant

Участник provider, определенный в перво*) выпуске АКД. расщеплен на три разных участника. Для определения точного соответствия необходимо учесть местное использование элемента provider в перво*) выпуске

clinical_document_header / service, actor

ClinicalDocument / participant

В зависимости от местного использования первого выпуска АКД может также отображаться на одного из нескольких более специфичных участников (например, informant, performer, responsibleParty. enco-unterParticipant)

service.actor / service_actor.type_cd

participant / @typeCode

service.actor / participation.tmr

participant / time

Компонент АКД, выпуск 1

Соответствующий коыпоиент АКД. выпуск 2

Примечания

service_actor У signatured

authenticator У signatureCode

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

clinical_document_header / patient

ClmicaiOocument У recordTarget

patient У patient.type_od

recordTarget У @typeCode

patient / participation.tmr

NOT PRESENT

При необходимости для отображения может использоваться местная разметка

patient / person

recordTarget У patientRole У patient

patient i person У id

recordTarget У patientRole / patient У id

patient У is_known_by

recordTarget У patientRole

patient У is_known_by l id

recordTarget У patientRole / id

patient У is_known_by / is_known_to

recordTarget У patientRole У providerOrganization

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

patient У rs_known_by / is_known_ to У id

recordTarget У patientRole У providerOrganization У id

patient У birth.dttm

recordTarget У patientRole У patient У birthTime

patient У administrabve_gendef_cd

recordTarget У patientRole У patient У administrativeGenderCode

clinical_document_header У originating_device

ClinicalDocument У author

originating_device У originating, device.lype.cd

author У @typeCode

originating_device У participabon.trnr

author У time

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

Окончание таблицы 149

Компонент АКД. выпуск Т

Соответствующий коыпоиент АКД. выпуск 2

Примечания

originating_device / device

author / assignedAuthor

originating_device1 device / id

author / assignedAuthor / id

origtnating_device / device / responsibility

author / assignedAuthor / assignedAuthohngDevice 1 asMaintainedEntity

originating_device / device / responsibility / responsibility.type_od

author / assignedAuthor l assignedAuthohngDevice / asMaintainedEntity / ©classCode

originating_device l device / responsibility / responsibility_tmr

author / assignedAuthor / assignedAuthohngDevice / asMaintainedEntity l effectiveTme

clinieal_document_header / service, target

ClinicalDocument / participant

В зависимости от местного использования первого выпуска АКД может также отображаться на одного из нескольких более специфичных участнике» (например, informant, performer, responsibteParty. enco-unterParticipant}

service.target 1 service.target. type.cd

participant / @typeCode

service.target 1 partidpatioo.lmr

participant t time

Табл ицв 150 — Соответствие тел документа в первом и втором выпуске АКД

Компонент АКД. выпуск 1

Соответствующий компонент АКД. выпуск 2

Примечания

levetone / body 1 non.xml

ClinicalDocument / component! nonXMLBody

levelone / body / section

ClinicalDocument / component! structuredBody i section

section ( ©originator

section / author

В первом выпуске АКД все авторы перечисляются в заголовке, а в теле на них даются ссылки. Во втором выпусхе авторы, ухазанные в заголовке, распространяются на тело и могут быть там переопределены (как описано в подразделе «CDA Context»)

section / ©confidentiality

section / conRdenbalityCode

В первом выпуске АКД все ходы конфиденциальности перечисляются в заголовке, а в теле на них даются ссылки. Во втором выпусхе коды конфиденциальности, указанные в заголовке, распространяются на тело и могут быть там переопределены {как описано в подразделе «СОА Context»)

section / @xmi:lang

section l languageCode

section / caption

section / title

Компонент АКД, выпуск 1

Соответствующий компонент АКД. выпуск 2

Примечания

section / caption / link

ОТСУТСТВУЕТ

Or местных правил может зависеть. надо пи отображать этот элемент на тег linkHtml е повествовательном блоке, определенный во втором выпуске АКД.

section / caption / caption.cd

section l code

См. также ниже строку с описанием отображения элемента caption/ caption.cd. Соответствие заголовка раздела во втором выпуске АКД отличается от соответствия других заголовков

©originator

См. примечания

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

©confidentiality

ОТСУТСТВУЕТ

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

@xmi:lang

©language

Атрибут language во втором выпуске АКД используется гак же. как атрибут xmktang в первом выпуске

content

content

link

linkHtml

В первом выпуске АКД элемент link более не существует. Он имеет обязательный дочерний элемент link.html. который соответствует тесу linkHtml во втором выпуске

coded_entry

section l entry У act

coded.entry У coded_entry.id

section / entry / act / id

coded.entry У coded_entry. value

section l entry / act / code

observation.media

section 1 entry У observationMedia

Для ссылки на подраздел типа observationMedia используйте в повествовательном блоке тег render MultiMedia

observation.media/ observation, media.id

section / entry У observationMedia У id

observation.media/ observation, media.value

section / entry У observationMedia / value

Окончание таблицы 150

Компонент АКД. выпуск 1

Соответствующий компонент АКД. выпуск 2

Примечания

local_markup

См. примечания

Местная разметка запрещена в повествовательном блоке второго выпуска АКД. поскольку она препятствует возможности распознания разметки, необходимой для правильного отображения документа. Другие пространства имен можно использовать вне повествовательного блока (как описано в подразделе «СОА Extensibility»)

caption

caption

caption / caption_cd

@styleCode

См. также выше строку с описанием отображения элемента section/ caption/capt»n_cd. Соответствие заголовка раздела во втором выпуске АКД отличается от соответствия других заголовков

paragraph

paragraph

List

list

Table

table

Во втором выпусхе АКД модель содержания элемента table более не содержит элемент «1г». Он теперь включен в элемент «(body»

6 Иерархическое описание АКД-документов и графическое представление модели R-MIM

6.1 Иерархическое описание АКД-документов (POCD_HD000040)

Иерархическое описание АКД-документов (POCD_HD000040) приведено а таблице 151.

Таблица 151— Иерархическое описание АКД-документов (Р000_н0000040)

Имя информационного объекте

крат

ность

Обяза

тель

ность

Coot-

вот-

отвив

Описание

Класс RM

Тип данных

Исто**

НИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

Примечания

CDA (POCDJHD000040) Иерархическое описание

Clinical

Document

0..1

Клинический

документ

Docu

ment

Chnical Document

н

1

typeld

1.1

О

02

Тип предметной области

Infrastructure Root

II

т

По умолчанию:

@root»»2.16.840.l

113883.1.3»;

©extension»»

POCD_HD000040»

2

ciassCode

1..1

О

02

Тип информационного объекта

Act

CS

т

DOCCIIN

CNE

По умолчанию: DOCCIIN

3

moodCode

1.1

О

02

Код завершенности

Act

CS

т

EVN

CNE

По умолчанию: EVN

4

id

1.1

02

Идентификатор

документа

Act

II

т

5

code

1.1

02

Тил документа

Act

CE

т

DocumentType

CWE

6

trite

0..1

Наименование

документа

Act

ST

т

7

effect veTime

1.1

02

Дата и время создания

Act

TS

т

в

corrfkJenlalflyCode

1.1

02

Код конфиденциальности

Act

CE

т

x_Bas»c

ConWenteMyKnd

CWE

9

tanguageCode

0..1

Язык

документа

Act

CS

т

HumanLanguage

CNE

По умолчанию: ©code System»» 2.16.840.1. 113883.6.121»

ГОСТ Р HCO/HL7 27932—2015

100


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

класс я ы

Тип данник

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

Примечания

10

setld

0..1

Идентификатор

набора

документов

Context-

Structure

II

т

11

versonN umber

0..1

Номер версии

Context-

Structure

INT

т

12

copyTme

0..1

Время

копирования

Docu

ment

TS

т

В текущей версии запрещен

13

reoordTarget

1..’

Целевая медицинская карта

Ас\

SET<RecordTar-

get>

н

14

lypeCode

1..1

О

02

Категория

объекта

Participa

tion

CS

т

RCT

CNE

По умолчанию: RCT

15

comexControtCode

1..1

О

02

Код управления контекстом

Participa

tion

CS

т

ОР

CNE

По умолчанию: ОР

16

patient Rote

1..1

Роль пациента

Ранка pa-

1ЮП

PatentRoie

н

17

ctessCode

1..1

О

02

Класс объекта

Rote

CS

т

РАТ

CNE

По умолчанию: РАТ

16

id

1..*

Идентификатор

пациента

Role

SET<II>

т

19

addr

0..*

Адрес места жительства

Role

SET<AD>

т

20

teteoom

0..*

Телекомму

никационный

адрес

Rale

SET<TEL>

т

21

patient

0..1

Пациент

Role

Patient

н

22

ctassCode

1..1

О

02

Класс объекта

Entty

CS

т

PSN

CNE

По умолчанию: PSN

23

determine rCode

1..1

О

02

категория

объекта

Entty

CS

т

INSTANCE

CNE

По умолчанию: INSTANCE

ГОСТ Р HCO/HL7 27932—2015


Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

класс яы

Тип данник

Исгоч-

МИК

Домен

Сто-

лень

кодиро

вания

Абс

трак

тный

примечания

24

id

0..1

Идентификатор

Enfety

II

т

В текущей версии запрещен

25

name

0..*

ФИО

EnSty

SET<PN>

т

26

admmsfrative Gender Code

0..1

Административный пол

Living-

Subject

CE

т

AdmnslralrveGender

CWE

27

birthTime

0..1

Дата и время рождения

с/> г-

i!

TS

т

28

mantalStatusCode

0..1

Семейное

положение

Person

CE

т

MarflaiSiafcJS

CWE

29

religious

Aff*a*onCode

0..1

Be ро исповедование

Person

CE

т

RebgiousAffiJ talon

CWE

30

race Code

0-1

Раса

Person

CE

т

Raoe

CWE

31

elhmcG roup Code

0..1

Этническая

группа

Person

CE

т

Ethnicity

CWE

32

guardian

0..*

Представитель пашен та

Entity

SET<Guardan>

н

33

ciassCode

1..1

О

02

Класс объекта

Role

CS

т

GUARD

CNE

По умолчанию: GUARD

34

id

0..*

Идентификатор

гфедстааителя

Role

SET<II>

т

35

code

0..1

Отношение к пациенту

Role

CE

т

Role Code

CWE

36

addr

0..*

Адрес

Role

SET<AD>

т

37

lefecom

0..*

Телекомму

никационный

адрес

Role

SET<TEL>

т


ГОСТ Р HC0/HL7 27932—2015


102


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

класс яы

Тип денник

Исгоч-

МИК

Домен

Сте-

лень

кодиро

вания

Абс

трак

тный

Примечания

38

guard ianChoioe

1..1

Выбор организации или физического лица

Role

Person | Organization

н

Да

Э9

guardianP arson

1..1

Представит ел ь-

фиэическое

лицо

Living-

Subject

Person

н

40

dassCode

1..1

О

02

Класс объекта

Entity

CS

т

PSN

CNE

По умолчанию: PSN

41

determine rCode

1..1

О

02

Категория объекта

Enlty

CS

т

INSTANCE

CNE

По умолчанию: INSTANCE

42

name

0..*

ФИО

Entity

SET<PN>

т

43

guardian

Organization

1..1

Представитель-

организация

Enlty

Organization

и

44

birth place

0..1

Место рокде-

Hifl

Enlty

Birthplace

н

45

ctessCode

1..1

О

02

Кпаос объекта

Role

CS

т

BIRTH PL

CNE

По умолчанию: BIRTH PL

46

place

1..1

Место

Rde

Race

н

47

ciassCode

1..1

О

02

Класс объекта

Entity

CS

т

PLC

CNE

По умолчанию: PLC

48

determine rCode

1..1

О

02

Категория объекта

Enlty

CS

т

INSTANCE

CNE

По умолчанию: INSTANCE

49

name

0..1

Название

Entity

EN

т

50

addr

0..1

Адрес места

Plaoe

AD

т

51

language

Commumcalon

0..*

Язык общения

Enlty

SET<Lan*

guageCommum-

caton>

н


ГОСТ Р HC0/HL7 27932—2015


103

Имя информационного объекте

крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клессйы

Тип денник

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

применения

52

ianguageCode

0..1

Язык

Language

Commu

nication

CS

т

HumanLanguage

CNE

По умолчанию: @codeSystem=» 2.16.840.1. 113883.6.121»

53

modeCode

0..1

Код завершенности

Language

Commu

nication

CE

т

LanguageAbiktyMode

CWE

54

proficiency

LeveiCode

0..1

Степень владения языком

Language

Commu

nication

CE

т

Lan диаде AbetyP го fi-dency

CWE

55

prefer© ncelnd

0..1

Предпочти

тельный

Language Communed lion

BL

т

56

provider

Organization

0..1

Поставщик

медицинской

помощи

Role

Organization

н

57

ctessCode

1..1

О

02

Класс объекта

Entity

CS

т

ORG

CNE

По умолчанию: ORG

58

determine rCode

1..1

О

02

Категория

объекта

Entity

CS

т

INSTANCE

CNE

По умолчанию: INSTANCE

59

id

0..*

Идентификатор

поставщика

Enfety

SET<II>

т

60

name

0..*

Название

организации

Enfety

SET<ON>

т

61

teiecom

0..*

Телекомму

никационный

адрес

Enfety

SET<TEL>

т

62

addr

0..*

Почтовый

адрес

Organiza

tion

SET<AD>

т

63

stand ardlndusfry CtassCode

0..1

ОКОНХ

Organiza

tion

CE

т

Orgamzationlndustry-

Cfass

CWE

ГОСТ Р HC0/HL7 27932—2015

frOl


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

класс я ы

Тип денник

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

применения

64

asOrgamzaton

PartOf

0-1

Вышестоящая

организация

Enfty

OrganeationPaf-

tOf

н

65

dassCode

1..1

0

02

Класс объекта

Role

CS

т

PART

CNE

По умолчанию: PART

66

id

0..‘

02

Идентификатор

организации

Rote

SET<II>

т

67

code

0..1

Код роли

Role

CE

т

Rote Code

OWE

66

stalisCode

0..1

Код отношения к поставщику

Role

CS

т

Rote Status

CNE

По умолчанию: @codeSystem=» 2.16.840.1. 113883.5.14»

69

effect veTme

0..1

Дата и время установления отношения

Role

IVL<T$>

т

70

wtiokeOrgarKzaton

0-1

Сведения об организации

Role

Organization

р

71

author

1..*

Автор документа

Act

$ET<Auttror>

н

72

typeCode

1..1

О

02

Тип объекта

Participa

tion

CS

т

AUT

CNE

По умолчанию: AUT

73

functionCode

0..1

Код функции

Participa

tion

CE

т

Partiapa ton Function

CWE

74

со ntexIC antral Code

1..1

О

02

Код управления контекстом

Participa

tion

CS

т

OP

CNE

По умолчанию: ОР

75

time

1..1

02

Participation

Participa

tion

TS

т

76

assignedAuttior

1..1

Назначенный

автор

Participa

tion

AssignedAuthor

н

77

dassCode

1..1

О

02

Код класса объекта

Role

CS

т

ASSIGNED

CNE

По умолчанию: ASSIGNED

ГОСТ Р HC0/HL7 27932—2015


105


Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

класс яы

Тип денник

Исгоч-

МИК

Домен

Сто-

лень

кодиро

вания

Абс

трак

тный

примечания

78

id

1..*

02

Идентификатор

автора

Role

SET<II>

т

79

oode

0..1

Код роли

Rde

CE

т

Rate Code

CWE

80

addr

0..*

Адрес

Role

SET<AD>

т

81

leteoom

0..*

Телекомму

никационный

адрес

Role

SET<TEL>

т

82

assigned Author Choice

0..1

Выбор фиыче-сжого лица или устройства

Rde

Person | Au-tiortngOevioe

н

Да

83

assignedPerson

1..1

Назначенное

шцо

Living-

Subject

Person

и

84

assigned Authoring Device

1..1

Назначенное

устройство

Manufactured Material

AuthomgDevce

н

85

dassCode

1..1

О

02

Кэд класса объекта

Entity

CS

т

DEV

CNE

По умолчанию: DEV

86

determine rCode

1..1

О

02

Мод категории объекта

Entity

CS

т

INSTANCE

CNE

По умолчанию: INSTANCE

87

code

0..1

Код роли

Enfety

CE

т

EntityCode

CWE

88

manufacfcjrer

ModeiName

0..1

Модель устройства

Device

SC

т

89

so ft* are Name

0..1

Наименование

грограммного

обеспечения

Device

SC

т

90

asMamtaned Entity

0..*

Управляемое

устройство

Enlty

SET<Ma attained* Entty>

н

8 текущей версии запрещен

91

dassCode

1..1

О

02

Класс роли

Rde

CS

т

MNT

CNE

По умолчанию: MNT

ГОСТ Р HC0/HL7 27932—2015


106


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клессяы

Тип денник

Источ

ник

Домен

Сто-

лень

кодиро

вания

Абс

трак

тный

примечания

92

effect veTime

0-1

Время использования

Role

M-<TS>

T

93

mainlanngPerson

1..1

Оператор

устройства

Rde

Person

и

94

represented

Organization

0..1

Место работы

Role

Organization

и

95

data Enterer

0..1

Оператор по ееоду данных

Act

DataEnterer

н

96

lypeCode

1..1

О

02

Тил объекта

Регистра-

lion

CS

т

ENT

CNE

По умолчанию: ENT

97

contexiContfdCode

1..1

О

02

Код управления контекстом

Participa

tion

CS

т

ОР

ONE

По умолчанию: ОР

96

t«ne

0..1

Время участия

Participa

tion

T$

т

99

assrgnedEntity

1..1

Назначенный

субъект

Pa rtx> patron

AssignedEntty

н

100

ciassCode

1..1

О

02

Класс роли

Rde

CS

т

ASSIGNED

CNE

По умолчанию: ASSIGNED

101

id

1..*

02

Идентификатор

субъекта

Rde

SET<II>

т

102

code

0..1

Код роли

Rde

CE

т

Role Code

CWE

103

addr

0..*

Адрес

Rde

SET<AD>

т

104

letecom

0..*

Телекомму

никационный

адрес

Rde

SET<TEl>

т

105

assrgne «Person

0..1

Назначенное

/ыцо

Rde

Person

и

106

represented

Organization

0..1

Место работы

Rde

Organization

и

ГОСТ Р HCO/HL7 27932—2015


107


Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клесслы

Тип денник

Исгоч-

МИК

Домен

Сте

пень

КОДИрО-

еания

A6c-тре*-тны Й

применения

107

informant

0..*

Инфоризтор

Act

SET<lnfor-

mant12>

н

10В

typeCode

1..1

О

02

Тип объекта

Ра Пю pa-ban

CS

т

INF

ONE

По умолчанию: INF

109

оо ntextC antral Code

1..1

О

02

Кэд управления контекстом

Participa

tion

CS

т

OP

ONE

По умолчанию: OP

110

nformartChoioe

1..1

Выбор типа участника

Participa

tion

Assigned Entity | RelatedEntity

н

ДЭ

111

assignedEnWy

1..1

Назначенный

субъект

Role

Assigne<£ntty

и

112

related Entity

1..1

Близкое лицо илиорганиза-

(*Я

Rote

RelatedEntity

н

113

ctessCode

1..1

О

02

Класс роли

Role

CS

т

RoieCtassMutuai Relation ship

ONE

114

code

0..1

Код

Role

CE

т

PersonalRetation-

shipRoleType

CWE

115

addr

0..*

Адрес

Role

SET<AD>

т

116

telecom

0..*

Телекомму

никационный

адрес

Role

SET<TEL>

т

117

effect veTme

0..1

Время участия

Role

IVL<rS>

т

118

related Person

0..1

Близкое лицо

Rale

Person

и

119

custodian

1..1

Обладатель

документа

Act

Custodian

н

120

typeCode

1..1

О

02

Тип объекта

Participa

tion

CS

т

CST

CNE

По умолчанию: CST

ГОСТ Р HC0/HL7 27932—2015


106


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клессяы

Тип денных

Источ

ник

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

применения

121

assignedCustodian

1..1

Уполномоченный обладатель

Participa

tion

AssignedCusto-

dian

H

122

dassCode

1..1

О

02

Класс роли

Rote

CS

T

ASSIGNED

CNE

По умолчанию: ASSIGNED

123

representedCustod a nOrg animation

1..1

Организация-

обладатель

Role

CustodianOrgani-

zation

H

124

dassCode

1..1

О

02

Класс роли

Entty

CS

T

ORG

CNE

По умолчанию: ORG

125

determ nerCode

1..1

О

02

Категория объекта

Entty

CS

T

INSTANCE

CNE

По умолчанию: INSTANCE

126

id

1..*

О

02

Идентификатор

Entty

$ET<II>

T

127

name

0..1

Наименование

Entty

ON

T

126

tetecom

0.1

Телекомму

никационный

адрес

Entty

TEL

T

129

addr

0..1

Адрес

Organiza

tion

AD

T

130

nformafon

Recipient

0..*

Получатель

информации

Act

SET<lnformation-

Recipient>

H

131

typeCode

1..1

О

02

Код типа субъекта

Participa

tion

CS

T

xJnformationRecipient

CNE

По умолчанию: PRCP

132

ntendedRedpient

1..1

Предполагаемый получатель

Participa

tion

IntendedRedp-

ienl

H

133

dassCode

1..1

О

02

Класс роли

Role

CS

T

x InformationReapieni Rote

CNE

По умолчанию: ASSIGNED

134

id

0..*

02

Идентификатор

получателя

Role

SET<II>

T

ГОСТ Р HCO/HL7 27932—2015


109


Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

классам

Тип данник

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

примечания

135

8ddr

0..*

Адрес

Role

SET<AD>

т

1Э6

tetecom

0..*

Телекомму

никационный

адрес

Role

SET<TEL>

т

137

nformaton

Recipient

0..1

Получатель

информации

Role

Person

и

138

reoerved Organize Uon

0..1

Организация-

получатель

Role

Organization

и

139

tegatAutienticator

0..1

Юри диче он

ответственное

шцо

Act

н

140

typeCode

1..1

0

02

Код типа объекта

Participa

tion

CS

т

LA

CNE

По умолчанию: 1А

141

oomexiConttoiCode

1..1

0

02

Код управления контекстом

Participa

tion

CS

т

ОР

CNE

По умолчанию: ОР

142

time

1..1

02

Время участия

Participa

tion

TS

т

143

signatureCode

1..1

02

Код подписи

Participa

tion

CS

т

Partiopaton Signature

CNE

По умолчанию: @code System=» 2.16.840.1. 113863.5.89»

144

assignedEntity

1..1

Vtion помоченный субъект

Participa

tion

AssignedEntity

и

145

authenticator

0..‘

Контролер

Act

SET<Authenfc-

cator>

н

146

typeCode

1..1

0

02

Код типа субъекта

Participa

tion

CS

т

AUTHEN

CNE

По умолчанию: AUTHEN

147

lime

1..1

02

Время участия

Participa

tion

TS

т

ГОСТ Р HC0/HL7 27932—2015


110


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клессяы

Тип денник

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

A6c-

трак-

тный

примечания

148

signal иг еС ode

1..1

02

Код подтем

Participa

tion

CS

т

Partidpaton Signature

CNE

По умолчанию: @codeSystem=» 2.16.840.1. 113883.5.89»

149

assignedErrirty

1..1

Полномочен-ный субъект

Participa

tion

AssignedEnfety

и

150

partcvent

0..*

Участник

Act

SET«^anK>

pant1>

н

151

typeCode

1..1

О

02

Кэдтипа

объекта

Ра riiopa-lion

CS

т

PartidpationType

CNE

152

funclionCode

0..1

Код функции

Partidpatron

CE

т

Part dpaton Function

CWE

153

contexlControlCode

1..1

О

02

Код управления контекстом

Participa

tion

CS

т

OP

CNE

По умолчанию: ОР

154

tme

0..1

Время участия

Participa

tion

IVl<TS>

т

155

assoaatedEnuiy

1..1

Связанный

объект

Participa

tion

AssocetedEntrty

н

156

dassCode

1..1

О

02

Класс роли

Rde

CS

т

RdeCtassAssodative

CNE

157

id

0..*

Идентификатор

Rote

SET<II>

т

158

code

0..1

Кэд

Role

CE

т

Rde Code

CWE

159

addr

0..*

Адрес

Role

SET<AD>

т

160

telaoom

0..*

Телекомму-

никациотъм

адрес

Role

SET<TEL>

т

161

assoc» atedPerson

0..1

Связанное

лицо

Role

Person

и

162

scoping

Organization

0..1

Контролирующая органиэа-тя

Role

Organization

и

ГОСТ Р HCO/HL7 27932—2015


Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клессяы

Тип денных

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

применения

163

mFutMmentOf

0..’

Для выпоте-ния направления

Act

SET<lnFutfii-

nrentOf>

н

164

lypeCode

1..1

О

02

Код типа объекта

ActReta-ton ship

CS

т

FLFS

CNE

Do умолчанию: FLFS

165

order

1..1

Направление

Act Re talon ship

Order

н

166

dassCode

1..1

О

02

Код роли

Act

CS

т

ACT

CNE

По умолчанию: ACT

167

moodCode

1..1

О

02

Код завершенности

Act

CS

т

RQO

CNE

По умолчанию: RQO

168

•d

1..*

02

Идентификатор

Act

$ET<II>

т

169

code

0..1

Код

Act

CE

т

Act Code

CWE

170

priorityCode

0..1

Срочность

Act

CE

т

Actf*rionty

CWE

171

documentatonOf

0..*

Для документирования

Act

SET<Oocumen-

tatonOf>

н

172

lypeCode

1..1

О

02

Код типа объекта

ActRela-

fonsfrp

CS

т

DOC

CNE

По умолчанию: DOC

173

service Event

1..1

Медиштнсхая

услуга

AclReta-

ionsrtp

ServiceE vent

н

174

ciassCode

1..1

О

02

Код роли

Act

CS

т

ACT

CNE

По умолчанию: ACT

175

moodCode

1..1

О

02

Код завершенности

Act

CS

т

EVN

CNE

По умолчанию: EVN

176

id

0..*

Идентификатор

обращения

Act

SET<II>

т

177

code

0..1

Код

Act

CE

т

Act Code

CWE

ГОСТ Р HC0/HL7 27932—2015

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

класс я ы

тип данных

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

примечания

178

effect veTroe

0..1

Время обращения

Act

(VL<TS>

т

179

performer

0..*

Исполнитель

Ad

SET«Perform-

er1>

н

180

lypeCode

1..1

О

02

Кэдтипаобь-

«та

Participa

tion

CS

т

x_ServioeEvenlPer-

former

ONE

181

lunclionCode

0..1

Код функции

Participa

tion

CE

т

Part cipalion Function

OWE

182

Ume

0..1

Время участия

Participa

tion

IVL<TS>

т

183

assignedEntrty

1..1

Полномочен-ный субъект

Participa

tion

AssignedEntty

и

184

related Document

0..*

Связанный до* кумент

Act

SET<Rete«ed-

Document»

н

185

typeCode

1.1

О

02

Код типа объекта

ActReta-ton ship

CS

т

x_ActReteton$hipOoc-

ument

ONE

Родительский документ может иметь следующие связи со своими потомками: одну связь дополнения (APND);

одну связь замены (RPIC);

одну связь преобразования (XFRM); одну связь преобразования (XFRM) и одну связь дополнения (APND): одну связь преобразования (XFRM) и одну связь замены (RPLC)

ГОСТ Р HC0/HL7 27932—2015

113


Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

класс лы

Тип данных

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

примечания

186

par ел (Document

1..1

Родительский

документ

AdRete-tr an ship

Parent Document

н

187

dassCode

1..1

О

02

Класс роли

Act

CS

т

DOCCLIN

CNE

По умолчанию: DOCCUN

188

moodCode

1..1

О

02

Класс завершенности

Act

CS

т

EVN

ONE

По умолчанию: EVN

189

id

1..*

02

Идентификатор

Act

SET<II>

т

190

code

0..1

Кэд

Act

CD

т

Documontiype

CWE

191

text

0..1

Текст

Act

ED

т

Элемент Ра rent Document text может быть ис-по/ъ эо ван. чтобы указать тип среда родительского документа (MIME Ме<Ьа Туре). Его нельзя использовать. чтобы включить родительский документ внутрь ото го элемента, поэтому элемент Parent Document, text.BIN запрещен

192

setld

0..1

Идентификатор фуппы документов

Context-

Structure

II

т

193

vetsio nN umber

0..1

Номер версии

Context-

Structure

INT

т

194

authorization

0..*

Автор иэататя

Act

SET<Authoriza-

tion>

н

ГОСТ Р HC0/HL7 27932—2015


114


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

классам

Тип данных

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

Примечания

195

typeCode

1..1

О

02

Код типа объекта

AdReta-

fonship

CS

т

AUTH

CNE

Do умолчанию: AUTH

196

consent

1..1

Информированное оо гласив

ActReta-1 on ship

Consent

н

197

dassCode

1..1

О

02

Класс роли

Act

CS

т

CONS

CNE

По умолчанию: CONS

198

moodCode

1..1

О

02

Код эае ершен-мости

Act

CS

т

EVN

CNE

По умолчанию: EVN

199

id

0..*

Идентификатор

Act

SET<II>

т

200

code

0. 1

Кэд

Act

CE

т

Act Code

CWE

201

stabsCode

1..1

02

Код статуса

Act

CS

т

completed

CNE

По умолчанию: @code$ystem»» 2.16.840.1. 113883.5 14»

202

oomponentOf

0..1

Компонент

обращения

пациента

Act

Componentl

н

203

typeCode

1..1

О

02

Код типа объекта

ActReia-

fionship

CS

т

COMP

CNE

По умолчанию: СОМР

204

encompassing

Encounter

1..1

Обращение пашен та

ActReta-I on ship

En com passings ncounter

н

205

dassCode

1..1

О

02

Класс роли

Act

CS

т

ENC

CNE

По умолчэжю: ENC

206

moodCode

1..1

О

02

Act

Act

CS

т

EVN

CNE

По умолчажю: EVN

207

id

0..*

Идентификатор

Act

SET<II>

т

206

code

0..1

Код

Act

CE

т

ActEnoounterCode

CWE

ГОСТ Р HC0/HL7 27932—2015


115

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клессяы

Тип денник

Исгоч-

МИК

Домен

Cre-

лень

кодиро

вания

Абс

трак

тный

примечания

209

effect veTnre

1..1

02

Время посещения

Act

IVL<TS>

т

210

discharge

DispositionCode

0..1

Код места выписки

Patien-tEncounter

CE

т

EncounterOischarge-

Disposition

CWE

211

re$pon$*ieParty

0..1

Ответственная

сторона

Act

ResponsWeParty

н

212

lypeCode

1..1

О

02

Код типа объекта

Partio patron

CS

т

RESP

CNE

По умолчанию: RESP

213

assigns (£лШу

1..1

Наэ маненная сторона

Participa

tion

Assigns dEntty

и

214

encounter

Participant

0..*

Участник

посещения

Act

SET<£ncounter-

Participant>

н

215

typeCode

1..1

О

02

Код типа объекта

Participa

tion

CS

т

x_EncounterPartcipant

ONE

216

lime

0..1

Время участия

Participa

tion

IVL<TS>

т

217

assignedEnUty

1..1

Назначенная

сторона

Participa

tion

Assigns dEnfcty

и

21S

locafon

0..1

Место

посещения

Act

Location

н

219

typeCode

1..1

О

02

Подтипа

объекта

Parties pa-tion

CS

т

IOC

CNE

По умолчанию: LOC

220

heafthCareFadrty

1..1

Отделение

Participa

tion

Heal fi Care Facility

н

221

dassCode

1..1

О

02

Класс роли

Rote

CS

т

SDL ОС

CNE

По умолчанию: SDLOC

222

id

0..*

Идентификатор

Role

SET<II>

т

223

code

0..1

Код

Role

CE

т

ServiceDetvery

LocatonRoteType

CWE

ГОСТ Р HC0/HL7 27932—2015

116


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

класс лы

Тип данных

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

Примечания

224

location

0..1

Место оказэ* тмя медицинской помощи

Rde

Race

и

225

service Provide г Organization

0..1

Медицинская

организация

Rote

Organization

и

226

component

1..1

Компонент

документа

Act

Component2

н

227

typeCode

1..1

О

02

Кэдтипа

объекта

Act Re talon ship

CS

т

СОМР

CNE

По умолчанию: СОМР

228

context Conduct onlnd

1..1

О

02

Кэд управления контекстом

Act Re talon ship

Bl

т

По умолчанию: true

229

bodyChoee

1..1

Выбор типа тела документа

ActReta-

lonship

NonXMLBody | Struct uredBody

н

Да

2Э0

nonXMLBody

1..1

Неструкту

рированный

документ

Act

NonXMLBody

н

231

ctassCode

1..1

О

02

Класс роли

Act

CS

т

DOCBODY

ONE

По умолчанию: DOCBODY

232

moodCode

1..1

о

02

Код завершенности

Act

CS

т

EVN

CNE

По умолчанию: EVN

233

text

1..1

Текст

Act

ED

т

234

corrfiderUaMyCode

0..1

Код конфиденциальности

Act

CE

т

x_BasicConfidenUafc-

tyKind

CWE

235

tanguageCode

0..1

Язык

Act

CS

т

HumanLanguage

CNE

По умолчанию: @codeSystem=» 2.16.840.1. 113883.6.121»

236

structured Body

1..1

Структурированный документ

Act

StructuredBody

н

ГОСТ Р HC0/HL7 27932—2015


117


Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клессяы

Тип денник

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

применения

237

dassCode

1..1

О

02

Класс роли

Ad

CS

т

DOCBODY

CNE

Do умолчанию: DOCBODY

238

moodCode

1..1

О

02

Кэд завершенности

Act

CS

т

EVN

CNE

По умолчанию: EVN

239

confidentaSlyCode

0..1

Кэд конфиденциальности

Act

CE

т

х BasicConfidentiat-tyKind

CWE

240

tanguageCode

0..1

Язык

Act

CS

т

Humanlanguage

CNE

По умолчанию: @oodeSysiem=» 2.16.840.1. 113683.6.121»

241

component

1..*

СтруктурньЛ

компонент

Act

SET<Compo-

nent3>

н

242

typeCode

1..1

О

02

Кэд типа объекта

ActReta-ton Ship

CS

т

COMP

CNE

По умолчанию: COMP

243

context

Conductonlnd

1..1

О

02

Кэд управления контекстом

ActReta-ton ship

8L

т

По умолчанию: true

244

section

1..1

Раздел

ActReta-t on ship

Section

н

245

dassCode

1..1

О

02

Класс роли

Act

CS

т

DOC SECT

CNE

По умолчанию: DOCS ЕСТ

246

moodCode

1..1

О

02

Код завершенности

Act

CS

т

EVN

CNE

По умолчанию: EVN

247

id

0..1

Идентификатор

Act

II

т

248

code

0..1

Код

Act

CE

т

DocumenISectionType

CWE

249

title

0..1

Название

Act

ST

т

250

text

0..1

02

Текст

Act

EO

т

По умолчанию: @medraType=»tex-lAc«N7 -text* xml»

ГОСТ Р HC0/HL7 27932—2015


811


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клессяы

Тип денник

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

Применения

251

confidenliafclyCode

0..1

Код конфиден-дальности

Act

СЕ

т

x_Basc

Confide ntialrtyKind

CWE

252

languageCode

0..1

Язык

Act

CS

т

HumanLanguage

CNE

По умолчанию: @codeSystem=» 2.16.840.1. 113883.6.121»

253

subject

0..1

Субъект

Act

Sutject

н

254

lypeCode

1..1

О

02

Подтипа

объекта

Participa

tion

CS

т

S8J

CNE

По умолчанию: SBJ

255

oontexlC on trot Code

1..1

О

02

Код управления контекстом

Participa

tion

CS

т

OP

CNE

По умолчанию: ОР

256

awareness Code

0..1

Степень озабоченности субъекта

Participa

tion

CE

т

TargetAwareness

CWE

257

related Subject

1..1

Субъект оадер-хвния раздела

Parte* paten

Related Subject

н

258

ctassCode

1..1

О

02

Класс роли

Role

CS

т

x_DocumentSubject

CNE

По умолчанию: PRS

259

code

0..1

Код

Role

CE

т

Per son alR elation-ship RoteType

CWE

260

addr

0..*

Адрес

Role

SET<AD>

т

261

telecom

0..*

Телекомму

никационный

адрес

Rale

SET<TEL>

т

262

subject

0..1

Субьэст

Role

SubjectPerson

н

263

ctassCode

1..1

О

02

Клаос роли

Entty

CS

т

PSN

CNE

По умолчанию: PSN

264

determine rCode

1..1

О

02

Вид объекта или экземпляр объекта

Enlty

CS

т

INSTANCE

CNE

По умолчанию: INSTANCE

ГОСТ Р HC0/HL7 27932—2015


119

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

Класс R ы

Тип денных

Исгоч-

МИК

Домен

Cre-

лень

кодиро

вания

A6c-

трэк-

гний

Применения

265

name

0..*

ФИО

Entity

SET<PN>

т

266

adminisfrative Gender Code

0..1

Пол

Living-

Subject

CE

т

AdmmcslratfveGender

CWE

267

bithTime

0..1

Дата и время рождения

Living-

Subject

TS

т

266

author

0..*

Автор

Act

SET<Aulhor>

и

269

tfiformart

0..*

Информатор

Act

SET<lntor-

mantl2>

и

270

entry

0..*

Подраздел

Act

SET<Entry>

н

271

typeCode

1..1

О

02

Код типа объекта

ActReta* ton ship

CS

т

x_Act Re talon sh<) Entry

CNE

По умолчанию: СОМР

272

context Conduct onlnd

1..1

О

02

Код управления контекстом

ActReta-ton sinp

BL

т

По умолчанию: true

273

cJmica (Statement

1..1

Клиническое

утверждение

ActReta-t on ship

Act | Encounter | Observation | ObservationMe-da | Organizer | Procedure | Reg io nOf Interest | Substance Admires tretion | Supply

н

Да

274

subject

0..1

Субъект

Act

Subject

и

275

specimen

0..*

Биоматериал

Act

SET<Spedmen>

н

276

typeCode

1..1

О

02

Кэдтипа

объекта

Participa

tion

CS

т

SPC

CNE

По умолчажю: SPC

277

sped men Rote

1..1

Роль биоматериала

Participa

tion

SpecmenRoie

н

278

ctassCode

1..1

О

02

Класс роли

Role

CS

т

SPEC

CNE

По умолчанию: SPEC

ГОСТ Р HC0/HL7 27932—2015

120

пра

оЛтние таблицы 1

Имя информационного объекта

л-

крат

ность

Обяза

тель

ность

Свет

ает-

стена

Описание

Класс RU

Тип данных

Источ

ник

Домен

Сте-

ЛОНЬ

кодиро

вания

Абс

трак

тный

Примечания

279

id

0..’

Идентификатор

Role

SET<II>

T

280

specimen

PlayingEntity

0..1

Вид биоматериала

Rote

PteytngEnitty

H

261

ctassCode

1..1

0

02

Класс роли

Enity

CS

T

ENT

CNE

По умолчанию: ENT

262

determine rCode

1..1

0

02

Вид объекта или экземпляр объекта

Enfety

CS

T

INSTANCE

CNE

По умолчанию: INSTANCE

263

code

0..1

Тип био матери ал а

Entity

CE

T

EntityCode

CWE

264

quantity

0..*

Количество

биоматериала

Entity

SET<PQ>

T

265

name

0..*

Наименование

Enfety

SET<PN>

T

266

desc

0..1

Описание био-материала

Enity

ED

T

267

performer

0..*

Исполнитель

Act

SET^erform-

er2>

H

266

typeCode

1..1

0

02

Кэд типа объекта

Participa

tion

CS

T

PRF

CNE

По умолчанию: PRF

269

tme

0..1

Время участия

Participa

tion

IVt<T$>

T

290

modeCode

0..1

Код завершенности

Participa

tion

CE

T

Participation Mode

CWE

291

assignedEntity

1..1

Назначенная

сторона

Participa

tion

AssignedEntity

и

292

author

0..‘

Автор

Act

SET<Aulhor>

и

293

nformant

0..*

Информатор

Act

SET<lnfor-

mant12>

и

ГОСТ Р HCO/HL7 27932—2015

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клесслы

Тип денных

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

применения

294

participant

0..*

Участнис

Act

SET<PartK>-

pant2>

н

295

typeCode

1..1

О

02

Кэдтипаобь-

еста

Participa

tion

CS

т

РаПкарэОопТуре

CNE

296

оо ntextC antral Code

1..1

О

02

Кэд управления контекстом

Participa

tion

CS

т

OP

CNE

По умолчанию: OP

297

Ume

0..1

Время участия

Participa

tion

IVL*rS>

т

298

awarenessCode

0..1

Степень озабоченности субъекта

Participa

tion

CE

т

TargetAwareness

CWE

299

partcapantRoie

1..1

Роль участника

Ранка pa-

1ЮП

Partx>pantRote

н

300

dassCode

1.1

О

02

Класс роли

Rote

CS

т

ROL

CNE

301

id

0..*

Идентификатор

Role

SET<II>

т

302

code

0..1

Иэд

Role

CE

т

Role Code

CWE

303

addr

0..*

Адрес

Role

SET<AD>

т

304

telecom

0..*

Телекомму

никационным

адрес

Rale

SET<TEL>

т

305

playingEntityChoioe

0..1

Выбор типа участника

Rale

Device | Piayin-g Entity

н

Да

306

playng Device

1.1

Мдройство

Manufactured Material

Device

н

307

ctassCode

1.1

О

02

Класс роли

Entty

CS

т

DEV

CNE

По умолчанию: DEV

ГОСТ Р HC0/HL7 27932—2015

122


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клвссяы

Тип денник

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

применения

308

determine rCode

1.1

О

02

Вид объекта или экземпляр объекта

Entity

CS

т

INSTANCE

CNE

По умолчанию: INSTANCE

309

code

0..1

№эд

Enfty

CE

т

EnWyCode

CWE

310

manutactirer

ModetName

0..1

Про из водитель

Device

SC

т

311

software Name

0..1

Наименование

программного

обеспечения

Device

SC

т

312

playngEntdy

1..1

Участвующий

объект

Entty

PtayingEntdy

и

313

scoping Entity

0..1

Ответственная

сторона

Rote

Entity

н

314

ctassCode

1..1

О

02

Класс роли

Enity

CS

т

ENT

CNE

По умолчанию: ENT

315

determine rCode

1..1

О

02

Вид объекта или экземпляр объекта

Entity

CS

т

INSTANCE

CNE

По умолчанию: INSTANCE

316

id

0..*

Идентификатор

Entity

SET<II>

т

317

code

0..1

Код

Entty

CE

т

EntityCode

CWE

318

desc

0..1

Описание

Entty

ED

т

319

entiyRetationship

0..*

Связь с компонентам подраздела

Act

SET< Entry Relationship»

н

320

typeCode

1..1

О

02

Код типа объекта

ActRela-Ion ship

CS

т

x.ActRelaUonshipEn-

IryRelaUonshfi

CNE

321

nversionlnd

0..1

При знак обращения связи

ActRela-Ion ship

BL

т

ГОСТ Р HC0/HL7 27932—2015


123


Имя информационного объекте

крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клессяы

Тип денник

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

применения

322

context Conduct onlnd

1..1

О

02

Код управления контекстом

ActReta-

fonship

BL

T

По умолчанию: true

323

sequence Number

0..1

Порядковый

номер

ActRela-

fianshp

I NT

т

324

negationlnd

0..1

Признак

отрицания

ActRela-

fanship

BL

т

325

seperatabtelnd

0..1

Признак

независимого

использования

ActReta-

tonshrp

BL

т

326

dnica (Statement

1..1

Клиническое

утверждение

ActReta-ton ship

dnicatStatement | Act | Enoounter | Observation | ObservationMe-cba | Organizer | Prooedure | RegionOflnterest | SubslanceAd-mmistraiion | Supply

р

Да

327

reference

0..*

Ссылка

Act

$ET<Reference>

н

328

typeCode

1..1

О

02

Кэд типа объекта

ActReta-ton ship

CS

т

x_ActRetation$hipEx'

ternatReferenoe

CNE

329

seperatablelnd

0..1

Признак независимого использования

Act Re talon ship

BL

т

ЗЭО

extemalActChoice

1..1

Выбор типа внешнего действия

ActReta-t on ship

ExIemetAct | Ex-temalObsefvaton | External Procedure | External-Document

н

Да

331

exIematAct

1..1

Внешнее действие

Act

ExtemalAct

н

ГОСТ Р HC0/HL7 27932—2015


124


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клессяы

Тип данных

Источ

ник

Ломан

Ста-

лань

кодиро

вания

Абс

трак

тный

Примечания

332

dassCode

1..1

О

02

Класс роли

Act

CS

T

ACT

CNE

Do умолчанию: ACT

333

moodCode

1..1

О

02

Код завершенности

Act

CS

T

EVN

CNE

По умолчанию: EVN

334

id

0..*

Идентификатор

Act

SET<II>

T

335

oode

0..1

Кэд

Act

CD

T

ActCode

CWE

336

text

0-1

Текст

Act

ED

T

337

extematObservaion

1..1

Внешнее исследование

Act

Exiema*

Observation

H

336

dassCode

1..1

О

02

Класс роли

Act

CS

T

OBS

CNE

По умолчанию: OBS

339

moodCode

1..1

О

02

Код завершенности

Act

CS

T

EVN

CNE

По умолчанию: EVN

340

id

0..*

Идентификатор

Act

SET<II>

T

341

code

0..1

Код

Act

CD

T

ActCode

CWE

342

text

0..1

Текст

Act

ED

T

343

ext ematProoe dure

1..1

Внешняя

процедура

Act

Extern^

Procedure

H

344

dassCode

1..1

О

02

Класс роли

Act

CS

T

PROC

CNE

По умолчанию: PROC

345

moodCode

1..1

О

02

Код завершенности

Act

CS

T

EVN

CNE

По умолчанию: EVN

346

•d

0..*

Идентификатор

Act

$ET<II>

T

347

code

0..1

Код

Act

CD

T

ActCode

CWE

346

text

0-1

Текст

Act

ED

T

349

ext emaiDo current

1..1

Внешний

документ

Context-

Structure

External

Document

H

ГОСТ Р HC0/HL7 27932—2015


125


Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

класс вы

Тип данник

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

примечания

350

classCode

1..1

О

02

Класс роли

Act

CS

т

DOC

CNE

Do умолчанию: DOC

351

moodCode

1..1

О

02

Код завершенности

Act

CS

т

EVN

CNE

По умолчанию: EVN

352

id

0..*

Идентификатор

Act

SET<II>

т

353

oode

0..1

Кэд

Act

CD

т

DocumenlType

CWE

354

text

0..1

Текст

Act

ED

т

355

setld

0..1

Идентификатор группы документов

Context-

Structure

II

т

356

versionN umber

0-1

Номер версии

Context-

Structure

INT

т

357

precondition

0..*

YtnoBMe выполнения

Act

SET<Preco edition»

н

358

typeCode

1..1

О

02

Код типа объекта

ActReta-

tonsrtp

CS

т

PRCN

CNE

По умолчанию: PRCN

359

criterion

1..1

Критерий

ActReta-ti on ship

Criterion

н

360

dassCode

1..1

О

02

Класс роли

Act

CS

т

OBS

CNE

По умолчанию: OBS

361

moodCode

1..1

О

02

Код завершенности

Act

CS

т

EVN.CRT

CNE

По умолчанию: EVN.CRT

362

code

0..1

Код

Act

CD

т

Act Code

CWE

363

text

0..1

Текст

Act

ED

т

364

value

0..1

Знамение

Observa

tion

ANY

т

365

act

1..1

Действие

Act

Ad

н

ГОСТ Р HC0/HL7 27932—2015


126


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клессяы

Тип денных

Источ

ник

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

применения

366

dassCode

1..1

О

02

Класс роли

Act

CS

T

x _Act Cta ssDocu me n-tEntryAct

CNE

367

moodCode

1..1

О

02

Кэд завершенности

Act

CS

T

x.DocumentAcMood

CNE

36В

id

0..*

Идентификатор

Act

SET<II>

T

369

oode

1..1

02

Кэд

Act

CD

T

ActCode

CWE

370

negatonlnd

0..1

Признак

отрицания

Act

BL

T

371

text

0..1

Текст

Act

ED

T

372

stafcsCode

0..1

Кэд статуса

Act

CS

T

ActStatus

CNE

По умолчанию: @codeSystem*» 2.16.840.1. 113883.5.14»

373

effect veTene

0..1

Время исполнения

Act

(Vl<TS>

T

374

prioniyCode

0..1

Срочность

Act

CE

T

Aetf*rionty

CWE

375

languageCode

0..1

Язык

Act

CS

T

HumanLanguage

CNE

По умолчанию:

@codeSystem=»

2.16.840.1.

1138В 3.6.121»

376

encounter

1..1

Обращение

патента

Act

Encounter

H

377

ctassCode

1..1

О

02

Класс роли

Act

CS

T

ENC

CNE

378

moodCode

1..1

О

02

Кэд завершенности

Act

CS

T

x_DocumentEncoun-

terMood

CNE

379

id

0..*

Идентификатор

Act

SET<II>

T

380

code

0..1

Кэд

Act

CD

T

ActEncounterCode

CWE

381

text

0..1

Текст

Act

ED

T

ГОСТ Р HC0/HL7 27932—2015


127

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клесслы

Тип денных

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

применения

362

statusCode

0..1

Код статуса

Act

CS

т

Act Status

CNE

По умолчанию: @codeSystem=» 2.16.840.1. 113663.5.14»

383

effect veTime

0..1

Время обращения

Act

(VL<TS>

т

384

priontyCode

0..1

Срочность

Act

CE

т

ActPnonty

CWE

385

observation

1..1

Исследование

Act

Observation

н

Design Note: Observation, value has cardKiatrty p..'J. which doesn't show up tntheMsio representation.

386

dassCode

1.1

О

02

Кпаос роли

Act

CS

т

OBS

CNE

367

moodCode

1..1

О

02

Код завершенности

Act

CS

т

x_Act Mood Docu men-tObservation

CNE

366

id

0..’

Идентификатор

Act

SET<II>

т

369

code

1..1

02

Иэд

Ad

CO

т

ObservatonType

CWE

390

negstionlnd

0..1

Признак отрицания

Ad

BL

т

391

derivalonExpr

0..1

Метод вычислений

Ad

ST

т

392

text

0..1

Текст

Ad

ED

т

393

siatisCode

0..1

Код статуса

Ad

CS

т

Act Status

CNE

По умолчанию: @codeSystem=* 2.16.840.1. 113863.5.14»

394

effect veTime

0..1

Время последования

Ad

ivi*rs>

т

395

pnorttyCode

0..1

Срочность

Ad

CE

т

ActPnonty

CWE

ГОСТ Р HC0/HL7 27932—2015

QZl


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клвсслы

Тип денных

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

Применения

396

repeatNumber

0..1

Номер повторения

Ad

IVL<INT>

т

397

languageCode

0..1

Язык

Ad

CS

т

HumanLanguage

CNE

По умолчанию: @codeSystem=» 2.16.840.1. 113883.6.121»

398

value

0..‘

Знамение

Observa

tion

SET<ANY>

т

399

inter prelationCode

0..’

Код интерпретации

Observa

tion

SET<CE>

т

Observalon Interpretation

CNE

400

methodCode

0..*

Код метода

Observa

tion

SET<CE>

т

Obseoration Method

CWE

401

targetSueCode

0.Л

Код исследуемого места

Observa

tion

SET<CO>

т

ActSite

CVYE

402

refer enceR an ge

0..*

Референты нй предел

Ad

SET<Refer-

enoeRange>

н

403

typeCode

1..1

0

02

Код типа объекта

AdReta-ton ship

CS

т

REFV

CNE

По умолчанию: REFV

404

observation Range

1.1

Предельное

значение

AdReta-t on ship

Observabon-

Range

н

405

ciassCode

1..1

0

02

Класс роли

Ad

CS

т

OBS

CNE

По умолчанию: OBS

406

moodCode

1..1

о

02

Код завершенности

Ad

CS

т

EVN.CRT

CNE

По умолчажю: EVN.CRT

407

code

0..1

Код

Ad

CD

т

Ad Code

CWE

408

text

0..1

Текст

Ad

ED

т

409

value

0..1

Значение

Observa

tion

ANY

т

ГОСТ Р HC0/HL7 27932—2015


129


Имя информационного объекте

крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

класс яы

Тип денных

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

Применения

410

inter pretationCode

0..1

КОД ИНТврЛре-Та 1*1И

Observa

tion

СЕ

т

Observation Interpretation

CNE

411

observation Media

1..1

Мультимедийные данные

Ad

Observation

Media

н

412

dassCode

1..1

О

02

Класс роли

Act

CS

т

OBS

CNE

413

moodCode

1..1

О

02

Код завершенности

Act

CS

т

EVN

CNE

414

id

0..*

Идентификатор

Act

SET<II>

т

415

tanguageCode

0..1

Язык

Act

CS

т

HumanLanguage

CNE

По умолчанию: @codeSy$tem«» 2.16.640.1. 113683.6.121»

416

value

1..1

02

Знамение

Observa

tion

EO

т

417

organizer

1.1

Органайзер

Act

Organizer

н

Элемент organizer может быть истопником ссылки на другие компоненты подраздела и гы внешние действия. но не мо-нет содержать ссылку entiyReta-tionship

416

ciassCode

1..1

О

02

Класс роли

Act

CS

т

x_ActCJassDocumen-

tEntryOrganizer

CNE

419

moodCode

1..1

О

02

Код завершенности

Act

CS

т

EVN

CNE

420

id

0..*

Идентификатор

Act

SET<II>

т

421

code

0..1

Код

Ad

CD

т

Act Code

CWE

ГОСТ Р HC0/HL7 27932—2015


130


Продолжение таблицы 151

Имя информационного объекте

крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

класс я ы

Тип данник

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

Примечания

422

statusCode

1..1

02

Код статуса

Act

CS

т

AdStatus

CNE

По умолчанию: @codeSystem=» 2.16.840.1. 113683.5.14»

423

effect veTime

0..1

Время действия

Ad

(VL<TS>

т

424

component

0..*

Компонент

подраздела

Act

SET<Compo-

nenW>

н

425

lypeCode

1..1

О

02

Код типа объекта

AclReta-t on ship

CS

т

COMP

CNE

По умолчанию: СОМР

426

oontexl Conduct onlnd

1..1

О

02

Код управления контекстом

^Rela

tionship

BL

т

По умолчанию: true

427

sequence Number

0..1

Порядковый

номер

ActReta-ton ship

INT

т

426

seperatabteind

0..1

Признак

независимого

использования

ActReta-ton ship

BL

т

429

cknca (Statement

1..1

Клиническое

утверждение

ActReta-ton ship

dmi cats tatement | Act | Encounter | Observation | ObservationMe-do | Organizer | Procedure | RegonOflnterest | SubstanceAd-mirnstration | Supply

р

Да

430

procedure

1..1

Процедура

Ad

Procedure

н

431

dassCode

1..1

О

02

Класс роли

Ad

CS

т

PROC

CNE

432

moodCode

1..1

О

02

Код заверши-ности

Act

CS

т

x_Do current ProcedureMood

CNE

ГОСТ Р HC0/HL7 27932—2015


Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клесслы

Тип денник

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

применения

433

id

0..*

Идентификатор

Act

SET<II>

т

434

code

0..1

Кэд

Ad

CD

т

ActCode

CWE

435

negalionhd

0..1

Признак отрицания

Act

BL

т

436

text

0..1

Текст

Ad

ED

т

437

statu sCode

0..1

Код статуса

Ad

CS

т

Act Status

CNE

По умолчанию: @codeSystem=» 2.16.840.1. 113883.5.14»

438

effectveT*ne

0..1

Время исполнения

Act

IVl<TS>

т

439

pnofflyCode

0-1

Срочность

Act

CE

т

AcPnonty

CWE

440

tanguageCode

0..1

Язык

Act

CS

т

HumanLanguage

CNE

По умолчанию: @codeSystem=» 2.16.840.1. 113883.6.121»

441

methodCode

0..*

Код метода

Proce

dure

SET<CE>

т

ProcedureMethod

CWE

442

appro acfcSrteCode

0..*

Место применения

Proce

dure

SET<CO>

т

ActSite

CWE

443

largetSteCode

0..*

Места цели гфименения

Proce

dure

SET<CD>

т

ActSrte

CWE

444

regionOf Interest

1..1

Область интереса

Act

RegionOflnterest

н

445

class Code

1..1

О

02

Класс роли

Act

CS

т

ROIOVL

CNE

446

moodCode

1..1

О

02

Код завершенности

Act

CS

т

EVN

CNE

447

id

1..*

02

Идентификатор

Act

$ET<II>

т

ГОСТ Р HC0/HL7 27932—2015

132


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клесслы

Тип денных

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

A6c-

трэк-

ТНЫЙ

применения

448

code

1..1

02

Код

Act

CS

т

ROIOveriayShape

CNE

По умолчанию: @codeSystem=» 2.16.840.1. 113883.5.4»

449

value

1..*

02

Знамение

Observa

tion

LIST<INT>

т

450

substance

Administration

1..1

Применение

субстанции

Act

SubstanceAdmin-

istraton

н

451

ctassCode

1..1

О

02

Класс роли

Act

CS

т

SBADM

CNE

452

moodCode

1..1

О

02

Код завершенности

Act

CS

т

x_DocumentSiAstanc-в Mood

CNE

453

id

0..*

Идентификатор

Act

SET<II>

т

454

code

0..1

Код

Ad

CO

т

SubstanoeAdmmstra-

tionActCode

CWE

455

negatonlnd

0..1

Признак отрицания

Ad

8L

т

456

text

0..1

Текст

Act

ED

т

457

statusCode

0..1

Код статуса

Act

CS

т

ActStatus

CNE

По умолчанию: @codeSystem=» 2.16.640.1. 113883.5.14»

458

effect veTime

0..1

Продолжительность или частота применения

Ad

GTS

т

459

priorilyCode

0..1

Срочность

Act

CE

т

ActPnority

CWE

460

repeatNumber

0..1

Число повторений

Act

IVL<INT>

т

ГОСТ Р HC0/HL7 27932—2015


133


Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

класс лы

Тип данных

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

Примечания

461

route Code

0..1

Способ применения

Subs

tance

Admini

stration

СЕ

т

RouteOfAd ministration

CWE

462

appro actiSiteCode

0..’

Место применения

Sub s-tan се Admim-staton

SET<CD>

т

ActSite

CWE

463

doseQuantity

0..1

Дозировка

Subs

tance

Admin-

station

(VL<PQ>

т

464

rateQuantrty

0..1

Скорость введения

Subs

tance

Admmi-

stralion

(VI.<PQ>

т

465

maxDoseQuanuty

0..1

Максимальная

доза

Subs

tance

Admm-

station

RTO<PQ.PO>

т

466

admtfBstraion Unit Code

0..1

Единиц» применения

Substance Adm mi-station

CE

т

AdnvntstrabteDrug-

Form

CWE

467

consumable

1.1

Способ изготовления

Act

Consumable

н

468

typeCode

1..1

О

02

Код типа объекта

Participa

tion

CS

т

CSM

CNE

По умопчашю: CSM

469

manufactjred

Product

1.1

Готовая форма

Participa

tion

Manufactured-

Praduct

н

470

ciassCode

1.1

О

02

Класс роли

Rote

CS

т

MAKIU

CNE

По умолчанию: MANU

ГОСТ Р HC0/HL7 27932—2015


134


Продолжение таблицы 151

Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

к лесс яы

тип денник

Исгоч-

МИК

Домен

Ct«-

лень

кодиро

вания

Абс

трак

тный

применения

471

id

0..*

Идентификатор

Role

SET<II>

т

472

manufackjred

DrugOrOther

Material

1..1

Выбор готового лекарства или другого материала

Rde

LabeledDrug | Material

н

Да

473

manufackjred Labeled Drug

1..1

Готовое лекарство

Material

LabeledDrug

н

474

classCode

1..1

О

02

Класс роли

Enkty

CS

т

ММАТ

CNE

По умолчанию: ММАТ

475

determine rCode

1..1

О

02

Вид объекта или экземпляр объекта

Enkty

CS

т

KIND

CNE

По умолчанию: KIND

476

code

0..1

Кэд

Entity

CE

т

DrugEntity

CWE

477

name

0. 1

Наименование

Enkty

EN

т

478

manufackjred

Material

1.1

Готовый материал

Material

Material

н

479

dassCode

1..1

О

02

Класс роли

Enkty

CS

т

ММАТ

CNE

По умолчанию: ММАТ

480

determine rCode

1..1

О

02

Вид объекта или экземпляр объекта

Enkty

CS

т

KIND

CNE

По умолчанию: KIND

481

code

0..1

Кэд

Enkty

CE

т

Mater ialEn tityCiass-Type

CWE

482

name

0..1

Наименование

Enkty

EN

т

483

tolNumberText

0..1

Текстовый номер партии

Manufactured Material

ST

т

484

manufackirer

Organization

0..1

Производитель

Role

Organization

и

ГОСТ Р HC0/HL7 27932—2015


135


Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

клесслы

тип денник

Исгоч-

МИК

Домен

Сте

пень

кодиро

вания

Абс

трак

тный

примечания

465

supply

1..1

Отпуск лекарства или материале

Act

Supply

н

486

dassCode

1..1

О

02

Класс роли

Ad

CS

т

SPLY

CNE

487

moodCode

1..1

О

02

Код зав ер идейности

Ad

CS

т

x_DocumentSubstanc-

eMood

CNE

488

id

0..*

Идентификатор

Ad

SET<II>

т

489

code

0..1

Кэд

Act

CD

т

Act Code

OWE

490

text

0..1

Текст

Act

ED

т

491

stafcsCode

0..1

Код статуса

Act

CS

т

ActStatus

CNE

По умолчанию: @code$ystem*» 2.16.840.1. 113683.5.14»

492

effect veTene

0..1

Время отпуска

Ad

GTS

т

493

priorityCode

0..*

Срочность

Ad

SET<CE>

т

AcPriority

CWE

494

repeatNumber

0..1

Номер повторения

Ad

IVL<INT>

т

495

indepen denllnd

0..1

Признак независимого использования

Ad

BL

т

496

quantity

0..1

Количество

Supply

PO

т

497

expected UseTene

0..1

Ожидаемое время применения

Supply

IVL<TS>

т

498

product

0..1

02

Лекарство или субстанция

Ad

Produd

н

499

typeCode

1..1

О

02

Код типа объекта

Participa

tion

CS

т

PRD

CNE

По умолчанию: PRD

ГОСТ Р HC0/HL7 27932—2015


136


Оомчамиэ табшцы 151


Имя информационного объекте

Крат

ность

Обяза

тель

ность

Соот

вет

ствие

Описание

класс лы

Тип данник

Исгоч-

МИК

домен

Сте

пень

кодиро

вания

Абс

трак

тный

примечания

500

manufactired

Product

1..1

02

Произведенный продукт

Participa

tion

Manufactured-

Product

и

501

component

0..*

Компонент документа

Ad

SET<Compo-

nent5>

н

502

typeCode

1..1

О

02

Кэдтипаобь-

«та

ActRela-

fconsfrp

CS

т

СОМР

CNE

По умолчанию: СОМР

503

oontext

Conductonlnd

1..1

О

02

ActRetatonship

AclReta-

tonsftp

BL

т

По умолчанию: true

504

section

1..1

Раздел

AdReta-

lonship

Section

р


ГОСТ Р HC0/HL7 27932—2015


6.2 Графическое представление модели АКД R-MIM Графическое представление модели АКД R-MIM показано на рисунке 5.

со


Рисунок 5 — Графическое представление модели АКД RMIM


ГОСТ Р HCO/HL7 27932—2015


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

Эталонная информационная модель HL7

Версия: январь 2009 г.

Отвественная рабочая группа комитета HL7: Modeling and Methodology Work Group.

A.1 Введение

A.1.1 Примечание для голосования в ИСО

Эта версия модели RIM предназначена для обеспечения интерпретации стандарта ISO 27932 — HL7 Clinical Document Architecture. Release 2 {Архитектура клинических документов HL7. выпуск 2). Эта модель HL7 RIM версии 2.07 служит основой стандарта Архитектуры клинических документов (АКД). Она произведена от стандарта ИСО/ HL7 21731:2000.

А. 1.2 Основные сведения

Эталонная информационная модель RIM (Reference information Model) комитета Health Level Seven (HL7) представляет собой статическую модель информации о здоровье и медицинской помощи в соответствии с областями применения деятельности по развитию стандартов HL7. Она является информационной точкой зрения, согласованной комитетом HL7 и его национальными филиалами. RIM служит основным источником, из которого производится все содержание стандартных спецификаций протокола HL7 версии 3. связанное с информацией.

А.1.2.1 История разработки модели RIM

Развитие модели RIM началось в апреле 1996 г Первый выпуск модели RIM был принят Техническим руководящим комитетом HL7 (Technical Steering Committee) на заседании рабочей группы в январе 1997 г Этот выпуск был известен как проект RIM версии 0.80.

На следующих двух заседаниях рабочей группы основное внимание уделялось ознакомлению с проектом модели RIM и реализации процесса получения и согласования предложений по развитию модели. Процесс сопровождения модели RIM стал известен как «гармонизация модели RIM». Между 1998 г. и 2000 г. было девять заседаний, посвященных гармонизации, на которых рассматривались предложения по улучшения проекта RIM. Кульминацией этой работы стала модель HL7 RIM версии 1.0. обнародованная на заседании рабочей группы в январе 2001 г. На заседаниях по гармонизации основное внимание уделялось следующим пяти основным темам:

•    гарантия охвата стандарта HL7 версии 2.x. Этот набор предложенных изменений привносил в проект модели все информационное содержание стандарта HL7 версии 2.x:

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

•    объединенная модель обслуживания. Этот набор предложенных изменений представлял хрэтхий. точно определенный набор структур и словарей, отвечавший информационным потребностям широкого крута клинических сценариев. Эта коллекция предложений, известная как USAM (Unified service action model), явилась плодом объединенных усилий ряда технических комитетов:

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

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

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

Содержание настоящего документа представляет собой выпуск 1.22 модели HL7 RIM. Тонкая подгонка этой модегы продолжается по мере ее использования техническими комитетами для все более расширяющейся области применения семейства разрабатываемых стандартов HL7. основанных на применении моделей. Это семейство получило название HL7 версия 3.0. В настоящее время модель RIM является весьма стабильной. В то же время процесс гармонизации обеспечивает ее постоянную релевантность и соответствие информационным потребностям разрабатываемым стандартам HL7

А.1.2.2 Использование RIM в комитете HL7

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

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

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

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

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

А.1.2.Э Использование RIM вне HL7

В основном модель RIM предназначена для использования комитетом HL7 и его международными филиалами. Однако эта модель может использоваться и вне структур комитета HL7. Первые разработчики, принявшие на вооружение методологию разработки стандартов Версии 3. использовали RIM для конструирования спецификаций сообщешй. похожих на описанные в стандарте HL7. в своих собственных средах. К этим разработчикам относятся производители информационных систем, большие сети интегрированных медицинских организаций и правительственные агентства как в США. гак и в других странах. Эти же самые первые разработчики крайне активны в комитете HL7 и вносят практические предложения по усовершенствованию RIM и других аспектов процесса разработки Версии 3.

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

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

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

А.1.3 Утверждение модели RIM

Утверждение модели RJM 8 соответствии с принятыми процедурами голосования позволило вывести эту модеть за рамки внутренних артефактов комитета HL7. Как утвержденный стандарт она будет представлена для принятия в качестве стандарта Американского института стандарте» (American National Standards Institute — ANSI), а затем, возможно, для принятия 8 качестве стандарта ИСО. Другие организации-разработчики стандартов, аккредитованные 8 ANSI или ИСО. в том числе организация ASC XI2 и ТК 251 «Медицинская информатика» Европейского комитета по стандартизации (CEN ТС 251), выразили интерес в использовании модели RIM или е ссылках на эту модель при разработке своих собственных стандартов. Появление модели RIM в качестве стандарта значительно облегчает ее использование другими организациям и-разработчиками стандартов (standards development organizations — SDO). Наличие обшей эталонной информационной модели, используемой разными разработчиками стандартов информатизации здоровья, сулит значительные выгоды.

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

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

А. 1.3.1 Нормативные части модели RIM

Модель RIM состоит из классов, включенных в один или несколько пакетов предметных областей. Атрибуты, отношения и машины состояний связаны с классами.

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

Модель RIM представлена на языке UML, расширенном с помощью тегов, специфичных для стандартов HL7 и включенных в метаданные элементов UML-модели. Все стандартные значения метаданных элементов модели UML нормативны, но нормативны также и следующие расширения HL7;

•    Class.slateAtiribute;

•    Class.clessCode:

•    Attribute.mandatorylnclusion;

-    Attribute.cardinality:

•    Attribute.vocabOomain;

-    Attribute. vocabSlrength,

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

А.1.3.2 Нормативные ссылки

А.1.3.3 Смысл нормативности

А.1.4 Понимание модели RIM

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

А.1.4.1 RIM как абстрактная модель

RIM содержит б «базовых» классов:

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

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

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

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

-    класс ActRelastiionship (связь действий), представляющий связь одного действия с другим, например, связь между направлением на исследование и состоявшимся исследованием:

-    класс RoteUnk (связь ролей), представляющий отношения между отдельными ролями.

Три из этих классов — Act Entity и Rote (действия, сущности и роли) — детализируются в виде множества классов-специализаций, или подтипов. В представлении стандарта HL7 подтипы добавляются к модели RIM только в том случае, если требуется определить один или более атрибутов или ассоциаций, которые не могут быть унаследованы от родительского класса. Классы, описывающие отдельными понятия, не нуждающиеся ни в каких дальнейших атрибутах или ассоциациях, представлены исключительно как уникальный код в контролируемом словаре. Поэтому эги три базовых класса имеют следующие кодируемые атрибуты, используемые для дальнейшего определения моделируемого понятия:

•    classCode (в классах Act. Entity и Role), уточняющий назначение класса или соответствующего ему понятия независимо от того, представлен ли он как класс в иерархии R1M;

•    moodCode (в классе Act) и determmerCode (в классе Entity), с помощью которых можно указать, представляет ли класс экземпляр или разновидность класса Act или Entity. Если класс является специализацией класса Act. то атрибут moodCode позволяет указать, описывает ли экземпляр класса Act свершившееся или планируемое действие:

-    code (в классах Act. Entity и Role), обеспечивающий более детальную классификацию значения атрибута classCode. например, конкретный вид исследования в классе Observation (исследование).

Другие три базовых класса модели RIM — Participation. ActReiationship и RoteLink — не представлены иерархиями обобщения-специализации. Тем не менее эти классы представляют разнообразные понятия, например, разные формы участия или разные типы отношений между действиями. Эти отличия представлены атрибутом typeCode. который должен быть определен 8 каждом из этих классов.

А.1.4.2 Представление структуры класса в модели RIM

Как упоминалось ранее, модель RIM сконструирована с использованием подмножества семантики языка UML. Она представляет собой набор UML-классое. содержащих один или более атрибутов, которым присвоены типы данных, основанные на независимой спецификации типов данных Версии 3. Классы связаны редом отношений ассоциации, идентифицируемых уникальными именами ролей, или отношениями обобщения-специализации.

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

А.1.4.Э Представление контролируемого словаря

Ряд атрибутов в модели RIM имеют тип данных CS. Это означает, что множество значений такого атрибута должно быть выбрано из множества кодов, определенных в стандарте HL7. Упомянутые ранее атрибуты classCode и typeCode являются примерами атрибутов с типом данных CS.

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

А.1.4.4 Связанные спецификации

Как отмечено ранее, каждому атрибуту 8 модели RIM присвоен тип данных. Формальной спецификацией этих типов данных служат нормативная спецификация «HL7 V3 Data Types Implernen table Technology Specification for XML» (Реализуемая технологическая спецификация типов данных Версии 3 для XML) и справочный документ «HL7 Data Types Abstract Specification» (Абстрактная спецификация типов данных HL7. Оба этих документа е настоящее время находятся е процессе утверждения комитетом HL7. Справочная таблица свойств релевантных типов данных включена в Приложение В.

A.1.S Спецификация модели RIM и диаграммы

А.1.5.1 Предметные области и классы модели RIM

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

А.1.5.2 Нормативный словарь структурных атрибутов модели RIM

Словарные домены HL7 детализированы в отдельно*! документе. Избранное подмножество этих таблиц является частью нормативной спецификации модели RIM. Оно образовано из таблиц значений структурных атрибутов (тех. что имеют тип данных «CS») нормативных классов. В спецификации модели RIM приводятся гиперссылки на эти таблицы е тех местах, где они упоминаются. Кроме того, ниже приведен полный перечень ссылок на эти таблицы.

Parties pationType

RelabonshipConjuncbon

RoleClass

RoleLinkType

RoleStatus


ActClass    ActStatus

ActMood    ContextControl

ActRelationshipChecfcpotnt    EntrtyClass

ActRelabonshipJoin    Entity Determiner

ActRelabonshipSpJit    EntrtySlatus

ActRelabonshipType    ManagedParticipationStatus

А.1.5.Э Общие диаграммы модели RiM

Модель RiM представлена диаграммами классов для большинства предметных областей и диаграммами состояний перехода экземпляров классов. Кроме того, полная диаграмма классов модели RIM предоставлено в виде «плаката» в файле формата PDF. обеспечивающего удобные возможности ее увеличения. Ниже приведены диаграммы классов для отдельных предметных областей и диаграммы перехода состояний.

А.1.5.4 Графические диаграммы нормативного содержания модели RiM

Диаграммы классов, включенных е нормативное содержание RIM. представлены на рисунках А.—А.4.

142


А.1.5.4.1 Предметная область FoundatonGasses


_oigrzato*

ЭОС- SAG<A> бахэяпг^кгусаксаое

-;-^—

_1


К


pace not-e тс at »Cf ad ■есда-s-eit e: IWttrTfct ED p&T»t ST


Агееы


Реют


ЭОС* ВАС-*А> гита*амСое* СЕ

есхг-очелэж се

эеесме sst<s>

СЫйГ ОЖ SET<E>

w-gft-i-jene-sccoe се

«^o.sA'tate'eoeB СЕ

«т*ссю.рсоое ss’<ce>


к


apsoasTSteCcoe CD aaetssecoce CD epjgeQjarT' PC

Pairs

evnpota

nPtso-coo* cs

1К*ЛМС6ТГГ 1

s«sr>5a:»'T~* ts

SL


УВтаасРатсрэгсп


e ser<»>

«stusCoe* CS


xctraaionnp


Eftfr


i


Oj)


1 so.ee


n/nos.&iecr


acnr&meGnoeoxe ce егттгте ts oeceasecx SL

CKejsWT* Ts т.Чр<В(Г-о 8C

ruc.pe&iroioe^ifrttf »nt С1£р*сепатк sl

A


ebttCoo*:cs

•ferminorOca»: CS

и: &ет<*>

CCO* . CC

<uartfy: ser<pQ> ram* :BAG*£it»

•e :ED

*t«coo* :cs

utM»rc*Time ,IVL*T-

. * a cam: bas<tel> >in*coo* :ce andtngco®: ce


p:»y«r


1.1


ettsecoa* :cs

lo: S£T<t>

coo* :ce


0_„п*да*оп:м:В1

рв<есчоё^вт* - вьо'е'*'

y • aoor: BAG<40>


expect

tt-1


>»p*:



1


t*i*oonn: blg<tel> »totu«Coa*:C4 *ff*Ctrw»TVn* : WL<TS> *raec*»mi. m оом*(««ъсо0*: set' usntty: rto poettontlufrMr: u$T<rf. L


0_n


p*maw«or>


Vp*CoO* :Ct An«ttonC40*:CD eor*xtCoftracaJ*:. •qu»ne*Huf»Der: IUT negation ne: DL not*T*xt:EC

*t** : ivl<t*> rroo»cod*: ce a*»r*n*wCoo*:CE

ttgnatutvCoo». CC

tgnatureltx;: S p*rt>rm:no: BL srMtutonCainton


Act


AT


1 tag»


4c»‘Pefwnu)-<fr.B?ea


«raffct ED

g*Toerssr.*cooe ce


)Л*Я»1


ютйож ce J


>.'a---*r_EcviaxrB‘ «unoerkit st eip'eicrTn* пл.<те> rab"r. Tire. m.<ts>


0.1


Erpo/ee ooccoe ce

ОЭТ"*Чвп*

oociaucoce ce Ka.patcrcco* ce иэггурессое ce саатС-агС’ wo

Mjaoe-fCi.eT^i» ED

actegveEapne-rra £D


ecutce

Q.’.K>.‘V.rt


Qj


Htucoo* :cs moooc*o*:cs id:SET<r>

md*:co

**0*Bontno * BL 1 MRwattorCxpr: ST 91* :E0 t*it:E0 setueoo*:c$

»ff*c««*Ttn» • CTi icSv^nm*: GTS iv*toDltjTlm*:T$

pnortqooo*: set<ce>

X? aonioeitaitrcod»: set<c

-rtf*p»«tKimD»r: М.<КГ»

,    nrerrupf Btini: BL


0.П


trp*coo*: cs tnv»rsionino:BL

ИПЬЛСОПЬОКОО» . CS eontoxtCwouGttoflne: BL •9*«x*NumD*r ikt prtontf Number :ikt peuwOantly: PQ en*«aancar* .cs qXttCto* :CS jorneco* :CS negetonlnq: BL eonjuicOonCoo* :CS toarvimweierm: ST


ГОСТ P HCO/HL7 27932—2015


■voi)rq.K , .

S / . unc*ramqcoo* :ce

>' r»»eonCoe«: *£T<ce>

/ langiBjaCod*: CE


z


ГРО..Х1.

Roaunt

L tjpeoo® :cs ,-t pnorrqHunMr: »(T rffectvenm*: ML-

■ojsccoe ce

appoarsnecoo* set<d> Joseaart. vl-«c> газеолгер,. ivl<pg> >»*с«*аатр/ set-i'to/’ тгвзиеолтягу set-asmnsatKiT^RCcc*

1


rpouxRearorr fj 0.л arc^



Dev«e


'ASY

)«(39CrC00* SET<C£>

ferwoco» set<e> caigetstecooe set<o>

T

(Ргхеол

пгтмфое SET<£

apcrca^sseCcoe se

:ageS!|6Ccoe sr<

<c&-

>


I-ioe'fcCoo* set<ce>

-Ttoar-ty ^PDPQP>

-TtPreeAnt rto«wopo>

«АП 1Л0 iQNjtttur =£A. tsvuroer 4EAL


патлсс.вт.рое'ете sc ю^аавмте sc

io«sRcmmCor<«)Sta«Coo aene«:coo* CE акат&жюг-тп* ts

RIM 2 07

Oecemoer 9. 2004


~T


Lartaagcom-jca:^

angjageo* ce

тксие ce роюетс'.ееСоо* CE раЧаосё.х BL

coram:

/

eapKtyO-ar"/ PO negro.Jtf- pq свте«с.а-п< pq еаГ/Р«ооое cs

KnwT'pcccee CE

ватеоеьслпу pq Dee3nDetac.ars. pq

PaoerEicojTier

>reAenir%stre Bi а5~нг!о*че%г8£о.сесосе CE r^'OSta)Qja*st’ PQ з»этэд«ЭЙро»(с>*С«в« CE

»реево».пе»)еессое set<c& аресвАтатдепгсСоэе SET<CE>


Dagrostmaea


^Mctox-^r; trCcce ce

Pxitt'eaecaee

SJCl

oe»c»*».KTocC5oe cs (атепв«>о‘).>ооеСсое CE евезбегфшеоске ce

qa*sC; PQ

BpscseewseTse wl<ts>

Л



ACCOJTt

taarcfcAmt »AO

о.пвхАОмо CS

Р!**«яаеслгс/ ftr><mdpo> aK-AeoBarceCantty vl<>a>


ЭК


r*rejQ,arpi pc arto-rycetsC-axt.


P3


Devceia»


paramaavaij* lst<asy!


Рисунок A. 1 — Диагрэлма классов предметной области FoundalonClasses


впагк81ггаг»акю‘


at wo :«cttxnrgiwi«c^c. ^eal ;*01Е>статде^с*о^ат!1.. seal


А.1.5.4.2 Предметная область Acts (действия)

_р»тммво!

ваассес :ci RatfotCod*: СО witoitCotf г»1Сов* :С I

mimmNikim ::мт аа«ав«аМ4 :В1

и««г*1|. ес

а«»: ш<г«>

■cdcCsd* :С€

•«arcictiCoJ» :С£ явааИчСсвс :СЕ •e*»ta*»r»at гее

wifennid :8i

•>iM«io>C«idBie>Cod* :CS

,_L_

la :40'i'

MkiCeM : Cl

AMRaaQoaRto

ЛИ

kcaCedc • Cl

M«Co<t :С t

wantoalad :Bi

в*о«Се<* :CI

Hctaii0oatrd)C«6a: Cl

Ю . tet«l**

)Mk(K4»«MaiH« . к

aeda : CO

0.^

мнимшнг: ИГ

■ntttikt :ei

xtortYKcnccr :int

: IT

паявпаВВг: PQ

K»:EC

,

ttoafcaelatCcia :Ct

bi* : SC

вие** s о »

stttc»C«3c :CI

MeCo* : Cl

tfbaBvarin» ОТ l

ia«rflatfa« :*l

жмут*: «ТI

MaJaacdMCed* : Cl

мЯаЫМуТИ* : TI

waatva-iacicwma IT

cnc>l«rCc«* - 16Т<С6»

riktuui • ei

иааваМШфСов» : 1Э<С£>

MaatCce* : Cl

r*> c at Hi m в »r: i VI «WT > N»in>»a»ic»i .et t»v»iC«ec :CS BdaaaMaatM : 8L •MaitfcfcCM» :CE raiBcCcdc :I0<C£> :C6

z



РГ0С4ЯВ Г»

■•MCOM ' IET<CC> iNBMttliOeM : №T<CO> bmRMaCcd» : IEr<tO


ItVOlOCEHBlCCl меяаюм»: KT<CS* •«••«Sir :RTO<FO.PO> —-ere<M«.ee'« ■aMnt :HO tafeittoaiar: REAL >e«wwwt. глАх.

Щ«М111ГИ1ИЯ«1

Ш:КО

■Ht№l«r>«|a9iliOuiiai - aSLJU

М>СмМ1««М«вмЯа : REAi


CoitrolAit

FtaaariaiCoitrtct

|ядиша(Гamcfot* • CC

Рисунок A.2 — Диаграмма классов предметной области Acts {действия)

А.1.5.4.3 Предметная область Entities (сущности)

Entity

•ЕйсДГГо

Lingtug»CMrwnu<iica*on langm grCode . CE •OdtCode CE pratMWMy LeveCMe : CE preference Ind: BL


deteeninerCode . CS И SFKU» мае : СЕ

— quanta • SET<PQ> мя« ; №0«Elt* d*se:E0 tttsCMi : CS tiifenocTime : IVL'T&> fcfecom .ttO<TEl> dttCodtCE banaftngCM» • C6


Рисунок A.3 — Диаграмма клэосоа предметной области Entities {сущности}

144

Значение свойства codeSystem указано здесь в связи с тем. что атрибут confidentialityCode имеет тип данных СЕ и. следовательно, в нем должны быть указаны и код (oode), и система кодирования (codeSystem).

1 Единственное исключение из этого правила состоит в том. что атрибуту entryRelabonshtp. contextConductionlnd. который по умолчанию имеет значение «true», может быть присвоено значение «false» (см. подраздел 5.4,3.8.4 «Отношение entryRelationship (связь между подразделами)».