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

ГОСТ Р ИСО/HL7 27932-2015

Группа П85

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

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

СТАНДАРТЫ ОБМЕНА ДАННЫМИ

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

Health informatics. Data Exchange Standards. HL7 Clinical Document Architecture, Release 2

ОКС 35.240.80
ОКСТУ 4002

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

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО/HL7 27932:2009* "Стандарты обмена данными. Архитектура клинических документов HL7. Выпуск 2" (ISO/HL7 27932:2009 "Data Exchange Standards - HL7 Clinical Document Architecture. Release 2").
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . - .


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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

ANSI/HL7 CDA, R2-2005 4/21/2005

Основной/технический редактор: Robert H. Dolin, MD, [email protected], Semantically Yours, LLC

Основной/технический редактор: Liora Alschuler, [email protected], Alschuler Associates

Основной/технический редактор: Sandy Boyer, BSP, [email protected], Consultant

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

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

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

Технический редактор: Amnon Shabo (Shvo), PhD, [email protected], 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 -

<ClinicalDocument>
... Заголовок АКД-документа ...
<structuredBody>
<section>
<text>...</text>
<observation>...</observation>
<substanceAdministration>
<supply>...</supply>
</substanceAdministration>
<observation>
<externalObservation>...
</externalObservation>
</observation>
</section>
<section>
<section>...</section>
</section>
</structuredBody>
</ClinicalDocument>

5.1.2.2 "А" в АКД

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Настоящая спецификация описывает 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). В то же время человекочитаемое название тега не должно вводить в заблуждение;

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

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

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

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

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

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

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

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

Для минимизации риска просмотра устаревшей информации необходимо использовать системы управления клиническими документами. Если АКД-документы просматриваются вне контекста системы управления документами, то нельзя знать наверняка, был ли просматриваемый документ впоследствии отредактирован. Сообщения 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", спецификация АКД существенно увязана с управлением документами. За управление исходным документом, который может храниться в отличной от АКД форме, отвечает владелец, идентифицированный в заголовке АКД-документа (см. 5.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 или RegionOfInterest АКД-документа;

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, можно найти в приложении (см. (п.B.4)).


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полное описание Эталонной информационной модели HL7 (Reference Information Model; RIM) можно найти в ГОСТ ИСО/HL7 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)

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-схеме, но еще и удовлетворять правилам соответствия, объявленным в иерархическом описании АКД. Иерархическое описание второго выпуска АКД однозначно идентифицируется строкой "POCD_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 for V3 Structures, Release One.

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

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

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

Примечание - Точный метод упаковки и передачи экземпляра АКД-документа в сообщении не входит в область применения настоящего стандарта. Описанный в этом подразделе метод кодирования по стандарту 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), АКД-документы должны передаваться в сегментах OBX. При этом пакет MIME передается в поле OBX-5 (00573 "Результат исследования") как значение типа данных ED. Полю OBX-2 (00570 "Тип значения") должно быть присвоено значение "ED". Значения поля OBX.3 должно быть тем же самым, что и значение компонента ClinicalDocument.code.

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


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

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

Пример 3

MSH |...
EVN |...
PID |...
PV1 |...
TXA |...
OBX |1|ED|11492-6^History and Physical^LN||
^multipart^related^A^
MIME-Version: 1.0
Content-Type: multipart/related; boundary="HL7-CDA-boundary";
type="text/xml"; start="10.12.45567.43"
Content-Transfer-Encoding: BASE64

--HL7-CDA-boundary
Content-Type: text/xml; charset="US-ASCII"
Content-ID: &lt;10.12.45567.43>

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

...

<observationMedia classCode="OBS" moodCode="EVN">
<id root="10.23.4567.345"/>
<value mediaType="image/jpeg">
<reference value="left_hand_image.jpeg"/>
</value>
</observationMedia>

…

--HL7-CDA-boundary
Content-ID: &lt;10.23.4567.345>
Content-Location: canned_left_hand_image.jpeg
Content-Type: image/JPEG

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

--HL7-CDA-boundary-

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

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


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

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

Пример 4

<someMessage>
<Act.Code code="11488-4"
codeSystem="2.16.840.1.113883.6.1"
displayName="Заключение консультанта"/>
<Act.text type="multipart/related">
MIME-Version: 1.0
Content-Type: multipart/related; boundary="HL7-CDA-boundary";
type="text/xml"; start="10.12.45567.43"
Content-Transfer-Encoding: BASE64

--HL7-CDA-boundary
Content-Type: text/xml; charset="US-ASCII"
Content-ID: &lt;10.12.45567.43>

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

...

<observationMedia classCode="OBS" moodcode="EVN">
<id root="10.23.4567.345"/>
<value mediaType="image/jpeg">
<reference value="left_hand_image.jpeg"/>
</value>
</observationMedia>

…

--HL7-CDA-boundary
Content-ID: &lt;10.23.4567.345>
Content-Location: canned_left_hand_image.jpeg
Content-Type: image/JPEG

... Base64 image ...

--HL7-CDA-boundary--

</Act.text>
</someMessage>

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

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


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

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

5.4.1 Класс ClinicalDocument

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

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

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

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

5.4.2 Заголовок

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

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

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


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

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

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

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

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

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

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

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

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


Таблица 7 - Допустимые значения атрибута ClinicalDocument.confidentialityCode (CWE)

________________
Значение свойства codeSystem указано здесь в связи с тем, что атрибут confidentialityCode имеет тип данных CE и, следовательно, в нем должны быть указаны и код (code), и система кодирования (codeSystem).

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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


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

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

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

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

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


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

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

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


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

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

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

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


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

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

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

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


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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

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


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

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

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

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


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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

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


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

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

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)

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