ГОСТ Р ИСО 13606-1-2011. Национальный стандарт Российской Федерации. Информатизация здоровья. Передача электронных медицинских карт. Часть 1. Базовая модель

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

Утвержден и введен в действие Приказом Федерального агентства

ПЕРЕДАЧА ЭЛЕКТРОННЫХ МЕДИЦИНСКИХ КАРТ

Health informatics. Electronic health record communication. Part 1. Reference model

communication — Part 1: Reference model (IDT)

Группа П85

ОКСТУ 4002

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения»

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

4 Настоящий стандарт идентичен международному стандарту ИСО 13606-1:2008 «Информатизация здоровья. Передача электронных медицинских карт. Часть 1. Базовая модель» (ISO 13606-1:2008 «Health informatics — Electronic health record communication — Part 1: Reference model»).

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

0.1 Преамбула

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

Комплекс стандартов ИСО 13606 не предназначен для определения внутренней архитектуры или структуры баз данных систем ведения ЭМК или их компонентов, а также для спецификации типов медицинских приложений, которым могут требоваться данные ЭМК или которые могут формировать эти данные в конкретных условиях оказания медицинской помощи, в сети медицинских организаций или в специализированных медицинских организациях. Поэтому предложенная в данном комплексе информационная модель называется «выписка из ЭМК», и она может использоваться для определения сообщения, документа или схемы XML либо интерфейса объекта. Информационная модель, определенная в настоящем стандарте, описывает информационную точку зрения на выписку из ЭМК в терминах базовой модели ИСО для открытой распределенной обработки (БМ-ОРО).

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

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

0.2 Технический подход

Комплекс стандартов ИСО 13606 создан на основе практического опыта, накопленного в результате внедрения его европейского предшественника ENV 13606, других стандартов и спецификаций, относящихся к ЭМК, коммерческих систем и демонстрационных пилотных проектов передачи ЭМК пациентов частями или в целом, а также проводившихся исследований в данной области в течение 15 лет. Комплекс стандартов ИСО 13606 является развитием стандарта ENV 13606, обеспечивая более четкую и полную спецификацию, учет вновь выявленных требований, использование надежных средств применения типовых моделей к отдельным медицинским предметным областям и возможность обмена сообщениями, определенными в стандарте HL7, версия 3. Кроме того, для удобства разработчиков систем, соответствующих стандарту ENV 13606, комплекс стандартов ИСО 13606 содержит отображение элементов данных, описанных в стандарте ENV 13606, на настоящий стандарт. При техническом подходе к созданию комплекса стандартов ИСО 13606 были приняты во внимание несколько групп требований.

a) Наряду с применением традиционного обмена информацией в форме сообщений между изолированными медицинскими системами в некоторых случаях система ведения ЭМК будет реализована как компонент промежуточного уровня (сервер приложений) с использованием технологии распределенных объектов и/или веб-сервисов.

b) «Потребителями» таких серверов приложений будут не только другие системы ведения ЭМК, но и другие службы промежуточного уровня, например компоненты безопасности, системы управления рабочими процессами, службы выдачи предупреждений и поддержки принятия решений, а также другие службы предоставления медицинских знаний.

c) К данной работе проявлен широкий международный интерес, и настоящий стандарт является совместной работой комитета CEM и организации ИСО, при этом многие страны-участницы внесли существенный вклад в его формирование.

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

e) Поскольку с 1999 г. научно-исследовательские работы (НИОКР), положенные в основу стандарта ENV 13606, продвинулись далеко вперед, то при разработке настоящего стандарта были приняты во внимание важные новые результаты в данной области. Например платформа «open EHR», интегрирующая результаты НИОКР, проведенных в Европе и Австралии.

Учитывая разнообразие развернутых систем ЭМК, в комплексе стандартов ИСО 13606 большинство характеристик передачи ЭМК определены как факультативные, а не обязательные. Однако для безопасной обработки выписок из ЭМК системой-получателем некоторая степень обязательности все же требуется, что нашло свое отражение в обязательных свойствах объектов, моделируемых в частях 1, 2 и 4 комплекса стандартов ИСО 13606, а также в списках нормативных терминов, определенных в части 3.

На практике комплекс стандартов ИСО 13606 будет согласовываться с другими стандартами в области информатизации здоровья, определяющими конкретные аспекты представления медицинских данных. В приложении B поясняется, как комплекс стандартов ИСО 13606 может использоваться совместно с дополнительными стандартами, включая базовую информационную модель (RIM) стандарта HL7, версия 3, стандарты ЕН 14822-1, ЕН 14822-2, ЕН 14822-3, CEN/TS 14822-4 (GPIC), prEN 12967 (HISA) и prEN 13940 (CONTSYS).

0.3 Подход на основе дуальной модели

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

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

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

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

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

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

0.4 Базис требований настоящего стандарта

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

К числу таких исследований относятся проекты GEHR [41, 48, 57], EHCR-SupA [36 — 38], Synapses [42, 43] и Nora, а также работа, выполненная в Шведском институте развития служб здравоохранения (SPRI). Публикации, посвященные ключевым требованиям, выявленным в этих проектах, перечислены в разделе «Библиография» работы [51]. Эти требования недавно были объединены на международном уровне в документе ИСО/ТС 18308 [9].

В данной базовой модели ключевые контекстно-зависимые требования к достоверному представлению ЭМК связаны с совокупностью базовых логических классов, обладающих необходимыми атрибутами, предложенными для каждого уровня иерархии элементов выписки из ЭМК. В качестве основы для описания свойств данной базовой модели передачи ЭМК были выбраны требования, изложенные в стандарте ИСО/ТС 18308. Отображение формулировок этих требований на конструкции базовой модели представлено в приложении D.

0.5 Обзор иерархии элементов выписки из ЭМК

Содержание медицинской карты, по сути, является иерархическим. Клинические исследования, логические выводы и планируемые действия могут иметь простую или более сложную структуру. Обычно они сгруппированы в разделы и содержатся в «документах», например в заключениях консультантов, направлениях и эпикризах. Данные документы обычно организованы в тома, и в одном медицинском учреждении у пациента может быть несколько томов (например врачебный, сестринский, акушерский). Чтобы обеспечить достоверное представление исходного медицинского контекста и сохранить его смысл при передаче ЭМК между гетерогенными медицинскими системами, базовая модель выписки из ЭМК должна отражать эту иерархическую структуру и организацию информации и удовлетворять поставленным требованиям. Поэтому в предлагаемой модели иерархия элементов ЭМК формально разделяется на компоненты, для которых найдено единообразное отображение на способы организации отдельных ЭМК в гетерогенных системах ведения ЭМК. Эти компоненты представлены в таблице 1.

Таблица 1

Основные компоненты иерархии базовой модели выписки из ЭМК

0.6 Описание основных классов базовой модели

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

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

Класс EHR_EXTRACT содержит данные ЭМК, представленные в трех формах:

1. совокупность композиций COMPOSITION;

2. факультативно каталог томов FOLDER, обеспечивающий верхние уровни группировки и организации композиций COMPOSITION;

3. факультативно совокупность демографических данных каждого лица, сведений об организации, приборе или компоненте программного обеспечения, идентифицированных в формах 1 и 2. Это позволяет включать в ЭМК ссылки на подобные объекты в виде уникального идентификатора, не повторяя каждый раз детали описания этих объектов. При таком подходе любая выписка EHR_EXTRACT может быть интерпретирована изолировано, даже если система получателя не имеет доступа к службам, необходимым для декодирования идентификаторов объектов, использованных поставщиком ЭМК.

Формальный механизм включения информации о политике доступа в выписку EHR_EXTRACT определен в стандарте ИСО 13606-4. Данная информация позволяет ознакомить получателя ЭМК о требованиями субъекта и поставщиков медицинской помощи о том, как должны обрабатываться в будущем запросы на доступ к данным ЭМК.

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

Класс RECORD_COMPONENT

Основными классами строительных блоков, используемых для построения иерархии данных ЭМК в выписке EHR_EXTRACT, являются подтипы абстрактного класса RECORD_COMPONENT, служащего родителем всех конкретных узлов иерархии ЭМК: тома FOLDER, композиции COMPOSITION, раздела SECTION, подраздела ENTRY, кластера CLUSTER, элемента ELEMENT. Он является также родителем двух других абстрактных классов: содержания CONTENT и сущности ITEM.

Абстрактный класс RECORD_COMPONENT определяет характеристики, общие для всех этих строительных блоков, в том числе:

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

При создании выписки EHR_EXTRACT, соответствующей настоящему стандарту, система поставщика ЭМК может в некоторых случая потребовать, чтобы в иерархию данных выписки был включен класс RECORD_COMPONENT, не имеющий прямого соответствия с какими-либо исходными данными в системе ведения ЭМК. Атрибут synthesised класса RECORD_COMPONENT позволяет экспортирующей системе поставщика ЭМК указать, что класс RECORD_COMPONENT был создан в выписке EHR_EXTRACT для этой цели.

Разделы медицинских карт нередко ссылаются на другие, ранее существовавшие разделы и включают их как «копии». Типичным примером является выписной эпикриз, который может включать в себя копии нескольких частей карты стационарного больного, например обстоятельства госпитализации, основные диагнозы, главные вмешательства и лечебные процедуры. В большинстве случаев требуется включать экземпляры подобных классов RECORD_COMPONENT в выписку EHR_EXTRACT по значению, чтобы каждая композиция COMPOSITION могла быть интерпретирована получателем ЭМК. Однако для медико-правового контроля также важно знать, что эти разделы являются копиями разделов другой части ЭМК данного субъекта. Если эти данные являются копией, то для указания идентификатора rc_id исходного родительского класса RECORD_COMPONENT можно использовать необязательный атрибут original_parent_ref.

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

Важно, чтобы каждый экземпляр класса RECORD_COMPONENT был уникально и единообразно идентифицирован в многократных выписках EHR_EXTRACT. Тогда ссылки на такой экземпляр или между экземплярами останутся действительными. Примерами подобных ссылок являются семантические связи, пересмотр и аттестация. Атрибут rc_id имеет тип данных Instance Identifier (II) (идентификатор экземпляра), в который входит объектный идентификатор (ОИД) ветви идентификаторов ИСО. Тип данных II в настоящее время рассматривается международным сообществом как наиболее подходящий для постоянных идентификаторов, которые должны быть глобально уникальными. Как правило, в современных системах ведения ЭМК глобально уникальные экземпляры типа данных II непосредственно не используются в качестве первичных ключей или внутренних идентификаторов объектов. Однако система поставщика ЭМК, которой был присвоен ОИД организации, может использовать свои внутренние идентификаторы для построения уникальных местных расширений этого ОИД и таким способом создавать глобально уникальные значения атрибута rc_id. В качестве альтернативы она может создать совершенно новые значения атрибутов rc_id и сохранять их отображения на каждый внутренний идентификатор, чтобы любые будущие выписки EHR_EXTRACT, которые будут ею извлечены, использовали согласованные значения атрибутов rc_id. Трудно рассчитывать, что система получателя ЭМК сможет использовать полученные значения атрибута rc_id в качестве своих внутренних первичных ключей данных, поскольку каждая система управления базами данных использует немного отличающийся подход к генерации и использованию таких ключей. Поэтому получателю ЭМК может также потребоваться хранить отображение импортированных значений атрибута rc_id на свои первичные ключи, чтобы будущие ссылки на полученные экземпляры класса RECORD_COMPONENT могли быть надлежащим образом разрешены. Кроме того, он может создавать свои выписки EHR_EXTRACT, в которые эти значения атрибута rc_id будут снова включены для целей экспорта. Альтернативный подход в системах ведения ЭМК заключается в прямом хранении значений атрибутов rc_id вместе с медицинскими данными, рассматривая их как часть «полезной» нагрузки, но не используя в качестве первичных ключей. Необходимо также отметить, что в выписке EHR_EXTRACT атрибут rc_id не является эквивалентом первичного ключа, т.е. повторы значений атрибутов rc_id допустимы, если каждый экземпляр действительно ссылается на ту же самую часть медицинских данных в системе ведения ЭМК поставщика.

Класс FOLDER

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

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

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

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

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

Класс COMPOSITION

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

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

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

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

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

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

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

Классы ITEM, CLUSTER и ELEMENT

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

Информация, представленная сущностью ITEM (кластер CLUSTER или элемент ELEMENT), может быть привязана к моменту времени, не совпадающему со временем лечебного действия или его регистрации. Атрибут obs_time позволяет представлять значение даты, времени или периода с любой степенью точности. Эта позволяет, например, датировать операцию только годом, проявление симптома — месяцем и годом, период занятости — точным диапазоном дат или периодом лет, привязать аритмию сердца к точному моменту времени, организовать ангиограмму в виде ряда изображений.

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

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

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

Значения данных

Каждый элемент ELEMENT содержит одно значение данных, представляющее значение реального экземпляра этого класса. Оно должно иметь один из типов данных, определенных комитетом CEN (в стандарте СЕН/ТС 14796):

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

При разработке настоящего стандарта принималось во внимание, что технический комитет ИСО/ТК 215 разрабатывает новый стандарт типов данных, используемых в информатизации здоровья. Предполагается, что после его опубликования комитет CEN отменит стандарт СЕН/ТС 14796 в пользу этого нового стандарта. При этом потребуется обеспечить отображение типов данных CEN на новый стандарт типов данных. Это отображение должно быть также использовано для адаптации положений настоящего стандарта к новым типам данных.

Чтобы обеспечить принятие настоящего стандарта в более широком масштабе, чем юрисдикция СЕН/ТС 14967, описание типов данных атрибутов, действительно используемых в данной базовой модели (отличающихся от типов значений элементов ELEMENT), включено в настоящий стандарт в форме пакета SUPPORT. Это описание должно быть исключено после опубликования стандарта типов данных ИСО. Примечание - Предполагается, что простые типы данных, например, Boolean (булевский), Integer (целый), должны соответствовать стандарту ИСО/МЭК 11404. В настоящем стандарте они не определяются.

0.7 Описание других основных классов базовой модели

Класс AUDIT_INFO

Согласно нормативным актам здравоохранения и защиты персональных данных необходимо документировать и отслеживать, когда и кем данные ЭМК были отправлены в систему ведения ЭМК. Важно также регистрировать изменения данных ЭМК при ее модификации и передавать эти изменения в форме выписки EHR_EXTRACT. Класс AUDIT_INFO используется при представлении этих регистрационных данных:

a) для любого класса RECORD_COMPONENT как постоянная запись о его создании в исходной системе ведения ЭМК;

b) для любой композиции COMPOSITION как запись о ее создании в системе поставщика ЭМК, которая сгенерировала данную выписку EHR_EXTRACT.

Следовательно, композиция COMPOSITION может иметь до двух наборов регистрационных данных — один, относящийся к его исходной системе ведения ЭМК (называемый «feeder_audit»), и второй, относящийся к ее последующей записи в системе поставщика ЭМК (называемый «committal»), если эти две системы разные. Однако настоящий стандарт не требует и не поддерживает передачу неопределенного числа наборов регистрационных данных каждой системе, в которой сохранена композиция COMPOSITION. Это вызвано тем, что накапливаемая совокупность наборов регистрационных данных, лишенная реальной медицинской информации, детально показывающей, какие изменения каждый раз происходили, не считается имеющей медицинское значение. Если требуется передать полную историю изменений, то в выписку EHR_EXTRACT надо включить каждую версию композиции COMPOSITION.

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

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

Для регистрации изменения данных класс AUDIT_INFO содержит статус версии, необязательную причину изменения, идентификатор непосредственно предшествующей версии, к которой были применены эти изменения, и идентификатор совокупности версий, позволяющий связывать друг с другом неупорядоченные версии, созданные в разных системах ведения ЭМК. Необязательный атрибут статуса версии указывает, была ли текущая версия на момент ее отправки черновиком (т.е. предназначалась для замены в ближайшем будущем), обновлением предшествующей черновой версии, исправлением ошибочной старой версии, либо пустой композицией COMPOSITION или разделом ENTRY, означающими логическое удаление предшествующей версии (например при ошибочном сохранении предшествующей версии не в той ЭМК). Если статус не задан, то, данная версия подразумевается определяющей (первой).

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

Класс FUNCTIONAL_ROLE

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

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

Часть этой информации может быть опущена, если исполнитель действует не в медицинском учреждении, например, субъект медицинской помощи вводит данные в свою ЭМК из дома.

Класс ATTESTATION_INFO

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

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

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

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

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

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

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

Класс ATTESTATION_INFO содержит следующие данные об аттестации:

• дата и время проведения аттестации;
• идентификацию лица, осуществившего аттестацию, в форме ссылки на описанный выше класс FUNCTIONAL_ROLE;
• список аттестованных экземпляров класса RECORD_COMPONENT;
• факультативно, причину или юридическую значимость аттестации;
• факультативно, инкапсулированные данные (по значению или по ссылке), представляющие визуальный образ того, что в действительности видел аттестующий; в настоящее время в некоторых странах ЕС требуется, чтобы эти данные хранились в ЭМК наряду с данными в формате, пригодном для обработки.

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

Класс RELATED_PARTY

Иногда бывает, что данные ЭМК описывают медицинское событие или событие оказания медицинской помощи, относящееся к кому-либо, не являющемуся субъектом медицинской помощи. Самым общим примером этого является семейный анамнез, но иногда в ЭМК заносится информация о друге, сожителе, сексуальном партнере, работодателе, ребенке и других близких лиц субъекта медицинской помощи. При этом требуется однозначно отличать такую информацию от основной информации ЭМК, относящейся к субъекту медицинской помощи. Подраздел ENTRY имеет атрибут subject_of_information, использующий класс RELATED_PARTY для представления информации о лице, не являющемся субъектом лечения.

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

a) для идентификации лица в терминах его отношения к субъекту медицинской помощи в форме кодированного значения или текста;

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

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

Класс LINK

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

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

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

Для маркировки каждой связи используются два атрибута:

a) грубая категория связи, которая должна иметь одно из нескольких значений, определенных в ИСО 13606-3;

b) необязательная более тонкая маркировка; справочный список кодов маркировки приведен в части 3, но могут использоваться и другие системы кодирования.

Еще одной важной характеристикой является булевский атрибут follow_link. Если он принимает значение «истина», то это означает, что составитель предполагал, что любая выписка EHR_EXTRACT, включающая в себя композицию COMPOSITION, содержащую начальный объект связи, должна также включать в себя компонент COMPOSITION, содержащий целевой объект связи, и наоборот. Принимающая система должна будет информировать пользователей, получающим доступ к одному из концов связи, о наличии такой дополнительной информации.

0.8 Обсуждение конкретных представлений

Представление ролей и ответственности в выписке EHR_EXTRACT

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

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

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

Участники процесса документирования медицинской помощи в ЭМК

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

Участники, подтверждающие достоверность документов ЭМК

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

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

В настоящем стандарте (а также в других архитектурах ЭМК, например, ENV 13606 и HL7 CDA), используется следующий подход:

• определить небольшое число часто встречающихся однозначно воспринимаемых ролей, которые должны передаваться для обеспечения безопасной интерпретации выписок EHR_EXTRACT системой-получателем;
• предоставить возможность задания других конкретных участников в медицинских службах и системах, а также в отдельных экземплярах ЭМК на уровне композиций COMPOSITION или подразделов ENTRY;
• обеспечить возможность включения в ЭМК любого числа аттестаций для подписи томов FOLDER или композиций COMPOSITION или разрешить аттестацию только частей композиций COMPOSITION.

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

Субъект медицинской помощи

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

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

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

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

Ведение отдельной медицинской карты для каждого плода при многоплодной беременности: этот пример часто рассматривают как ситуацию, при которой одна медицинская помощь может действительно оказываться двум или более субъектам лечения. В этих случаях представляется логичным включать копию соответствующей композиции COMPOSITION в выписку EHR_EXTRACT каждого ребенка вместо того, чтобы пытаться установить сложное соединение двух или нескольких медицинских карт, позволяющее сослаться на единственную композицию COMPOSITION, общую для этих карт. (В самих системах ведения ЭМК могут быть организованы более сложные перекрестные связи, позволяющие пользователям однократно вводить данные, которые будут логически включены в обе медицинские карты.)

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

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

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

Составитель

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

Следовательно, атрибут composer (составитель) идентифицирует лицо, которое составило данные композиции COMPOSITION, невзирая на то, кто отправил их в базу данных или аттестовал их. Композиция COMPOSITION будет считаться порожденной главным образом этим лицом. Смена составителя при редактировании содержания композиции не обязательна, поскольку принятие решения о смене зависит от степени внесенных изменений, а также от того, хочет и способна ли сторона, вносящая изменения, взять на себя основную ответственность за измененную композицию COMPOSITION в качестве ее составителя. При выводе данных на экран прикладные программы могут помечать данные композиции COMPOSITION фамилией составителя. (Роли других членов бригады, не являющихся составителями, могут быть добавлены с помощью атрибута other_participations ко всей композиции COMPOSITION либо к отдельным подразделам ENTRY.)

Отправитель данных

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

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

Субъект информации

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

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

Атрибут subject_of_information (субъект информации) позволяет включить в подраздел ENTRY ссылку на экземпляр класса RELATED_PARTY, описывающего отношение этого субъекта к пациенту с помощью кодируемого значения и факультативно с помощью идентификатора лица (позволяющего получить информацию об этом лице из регистра лиц, являющегося частью системы ведения ЭМК).

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

Поставщик информации

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

Атрибут info_provider связывает подраздел ENTRY с классом функциональной роли FUNCTIONAL_ROLE, позволяющим описать функции участника и способ участия (по телефону, лично и т.д.). Как и в случае с субъектом информации, поставщик информации может быть или не быть формально идентифицирован в зависимости от его согласия и наличия информации о нем в местном регистре лиц. Составитель может указать формальные идентификаторы субъектов информации в некоторых подразделах ENTRY данной композиции COMPOSITION для описания участия других врачей или приборов (альтернативным способом описания является использование атрибута other_participations).

Демографические данные

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

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

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

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

Изменение данных

Изменение данных ЭМК является важной и потенциально сложной областью деятельности. Помимо хорошо известных медико-правовых требований к регистрации и классификации изменений в принятом подходе сформулированы следующие функциональные требования:

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

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

3. в отдельных случаях оказания медицинской помощи требуется пересылать последовательные версии экземпляров класса RECORD_COMPONENT, например для объяснения ошибки;

4. должна обеспечиваться возможность передачи всего содержания ЭМК, включая все версии измененных элементов, например при юридическом оформлении перевода пациента из одного медицинского учреждения в другое;

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

6. эволюция томов FOLDER во времени также может потребовать похожего управления версиями, хотя обычно это делается в рамках систем ведения ЭМК, а журнал регистрации изменений тома FOLDER, скорее всего, редко будет включен в выписку EHR_EXTRACT;

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

8. в некоторых случаях, например по решению суда, данные могут быть физически удалены из системы ЭМК; в таких случаях иногда может быть правильным сохранение пустого заполнителя экземпляра класса RECORD_COMPONENT на том же месте в иерархии, чтобы показать, когда и почему было произведено удаление.

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

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

Передача запросов на извлечение данных из ЭМК

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

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

Некоторые представления данных или выборки могут быть получены с помощью «пользовательского» запроса, специально составленного для извлечения данных из ЭМК конкретного субъекта медицинской помощи. В подобных случаях может быть полезно хранить параметры запроса в ЭМК пациента, чтобы его могли повторить другие врачи. В какой мере полезно разделять эту возможность между учреждениями и системами, зависит от того, насколько интероперабельна спецификация этого запроса. Учитывая, что язык спецификации определений и ограничений архетипов (Archetype Definition Language — ADL) стандартизован (ИСО 13606-2) и сообщество, разрабатывающее методические указания по его применению, также движется в сторону обеспечения интероперабельности своих спецификаций, вполне вероятно появление типовой спецификации запроса на извлечение данных из ЭМК. Хотя до сих пор отсутствует стандартное соглашение по спецификации запросов на извлечение данных из ЭМК, можно предположить, что такие спецификации будут представлять собой массив строковых значений или пар «имя — значение». Спецификация может быть представлена подклассами кластера CLUSTER и элемента ELEMENT класса сущности ITEM со значениями данных типа STRING. Поэтому архетипы подразделов ENTRY могут быть использованы для определения представления любых запросов на извлечение данных из ЭМК, которые должны быть переданы. Преимущество данного подхода в том, что несколько таких спецификаций запросов могут быть определены для использования в медицинских системах, и обновляться со временем без необходимости внесения каких-либо изменений в настоящий стандарт. Ниже приведен пример запроса графика изменения кровяного давления:

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

Обмен информацией о форме представления данных

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

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

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

3. система получателя ЭМК может быть не в состоянии точно отобразить экранные формы, используемые системой поставщика ЭМК;

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

Однако в следующих двух сценариях точная информация о представлении данных может быть важна при передаче данных ЭМК:

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

b) если конкретное представление данных обеспечивает их уникальную интерпретацию, например в виде диаграммы или графика.

В обоих случаях для включения в выписку из ЭМК инкапсулированного визуального представления данных ЭМК любого уровня детализации можно использовать атрибут attested_view класса ATTESTATION_INFO. Например, данный атрибут может быть использован для включения визуального представления документа, составленного в соответствии со стандартом HL7 version 3 CDA Release 1 или Release 2.

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

Передача мультимедийных данных

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

Широкий спектр мультимедийных данных может быть включен в ЭМК в виде специальных значений данных элементов ELEMENT. Следовательно, более сложные структуры мультимедийных данных могут быть представлены как комбинации элементов ELEMENT, возможно, содержащихся в кластерах CLUSTER в виде таблиц, списков или древовидных структур. Конкретные структуры данных или мультимедийные протоколы исследований могут быть представлены как подразделы ENTRY или композиции COMPOSITION, а также в виде архетипов.

Как определено в стандарте СЕН/ТС 14796, тип инкапсулированных данных (сокращенное обозначение ED) позволяет представлять любой тип данных MIME.

0.9 Сравнение настоящего стандарта и EN 13606-1

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

Следующие нормативные положения настоящего стандарта отличаются от приведенных в ЕН 13606-1:

• формулировка раздела 1 «Область применения» была модифицирована (расширена) включением в конец второго абзаца фразы «или для представления данных ЭМК в распределенной (федеративной) системе»;
• подраздел 5.2 «Соответствие в странах — участницах ЕС» был переформулирован для большего соответствия требованиям ИСО и переименован в «Соответствие в странах-участницах»;
• значение атрибута rm_id выписки EHR_EXTRACT было изменено с «EN 13606-1» на «ISO 13606-1».

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

Были внесены следующие редакторские правки:

• фразы «европейский стандарт» заменены фразами «настоящий стандарт»;
• фразы «ЕН 13606» заменены фразами «ИСО 13606»;
• упоминания Европы или предварительных европейских стандартов изменены, где это необходимо, ссылками на настоящий стандарт;
• несколько определений терминов, не соответствовавших правилам ИСО, были отредактированы без изменения их сути, т.е. их техническое толкование осталось неизменным;
• были исправлены замеченные опечатки и несоответствия терминов.

Данная часть введения не имеет аналога в ЕН 13606-1, поскольку точное содержание международного стандарта ИСО не было известно на момент публикации стандарта ЕН 13606-1. Сноски в тексте стандарта, выделенные курсивом, приведены для уточнения оригинала.

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

Настоящий стандарт определяет передачу части или всей электронной медицинской карты (ЭМК) одного идентифицированного субъекта медицинской помощи между системами ведения ЭМК или между системами ведения ЭМК и централизованным хранилищем данных ЭМК.

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

Настоящий стандарт предназначен для информационных систем, обеспечивающих поддержку медицинской помощи идентифицированным лицам или мониторинг состояния здоровья популяции, например для регистров заболеваний или систем контроля общественного здоровья. Использование медицинских карт для других целей, например для обучения, контроля качества медицинской помощи, администрирования и отчетности, управления предоставлением услуг, научных исследований и эпидемиологии, для которых часто требуется псевдонимизация или агрегирование данных отдельных карт, не входит в область применения настоящего стандарта, но и для подобных применений настоящий стандарт также может оказаться полезным. Настоящий стандарт, являющийся частью комплекса стандартов ИСО 13606, представляет информационную точку зрения на выписку из ЭМК в терминах ИСО/МЭК 10746-1 [13]. Настоящий стандарт не предназначен для определения внутренней архитектуры или структуры баз данных систем ведения ЭМК.

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

В настоящем стандарте использована ссылка на следующий европейский стандарт: СЕН/ТС 14796:2004 Информатизация здоровья. Типы данных (CEN/TS 14796:2004, Health Informatics — Data Types)

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

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

3.1 абстрактный класс (abstract class): Виртуальный общий родитель для двух или нескольких классов, который сам не имеет экземпляров.

[ИСО/МЭК 2382-8:1998, статья 08.04.01]

[ИСО/МЭК 2382-8:1998, статья 08.01.10]

3.4 экземпляр архетипа (archetype instance): Экземпляр класса метаданных модели архетипов, определяющий медицинское понятие и ограничения значений, применяемые к одному классу экземпляров элементов в выписке из электронной медицинской карты.

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

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

3.7 аттестующий (attester): Сторона (лицо), сертифицирующая и регистрирующая юридическую ответственность за конкретную единицу информации.

3.8 аттестация (attestation): Процесс сертификации и регистрации юридической ответственности за конкретную единицу информации.

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

3.10 аутентификация (authentication): Процесс надежной идентификации субъекта информационной безопасности путем защищенной ассоциации, установленной между идентификатором и субъектом.

3.11 авторизация (authorization): Предоставление прав.

3.12 клиентское приложение (client application): Медицинское приложение, которое в данный момент запрашивает данные медицинской карты из системы ведения ЭМК общего пользования.

3.13 медицинская информация (clinical information): Информация о лице, относящаяся к его здоровью или лечению.

3.14 отправленные данные (committed): Информация, отправленная в систему ведения электронных медицинских карт на постоянное хранение и составляющая часть электронной медицинской карты субъекта медицинской помощи.

3.15 отправитель (committer): Агент (сторона, прибор или программное обеспечение), результатом прямых действий которого является отправка данных в электронную медицинскую карту.

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

[ИСО 7498-2:1989, статья 3.3.16]

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

[ИСО 7498-2:1989, статья 3.3.26]

3.20 распределенная обработка (distributed processing): Обработка информации, при которой дискретные компоненты могут располагаться в разных местах или при которой связь между компонентами может допускать задержки или пропадать.

3.21 выписка из электронной медицинской карты (electronic health record extract): Вся электронная медицинская карта субъекта медицинской помощи или ее часть, передаваемая в соответствии с настоящим стандартом.

3.22 информационная архитектура электронной медицинской карты (electronic health record information architecture): Спецификация информационной точки зрения на электронную медицинскую карту в терминах открытой распределенной обработки (ОРО).

3.23 поставщик электронной медицинской карты (electronic health record provider): Легитимный обладатель электронной медицинской карты, передающий ее другому заинтересованному субъекту.

3.24 получатель электронной медицинской карты (electronic health record recipient): Субъект, которому поставщик электронной медицинской карты передает электронную медицинскую карту.

3.25 инициатор запроса электронной медицинской карты (electronic health record requester): Объект, инициирующий запрос на передачу электронной медицинской карты от поставщика к получателю электронной медицинской карты.

3.26 система ведения электронных медицинских карт (electronic health record system): Система, предназначенная для записи, извлечения и преобразования информации в электронных медицинских картах.

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

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

3.29 система-источник (feeder system): Хранилище (данных медицинских карт), к которому может быть обращен запрос в рамках федерации систем ведения электронных медицинских карт для пополнения данных в федеративной медицинской карте.

3.30 типовой (generic): Применимый к требованиям или информационным моделям разных медицинских специалистов, предметных областей и стран.

3.31 медицинский агент (healthcare agent): Лицо, прибор или программное обеспечение, выполняющее определенную роль в оказании медицинской помощи.

3.32 медицинский прибор (healthcare device): Прибор или оборудование, прямо или косвенно участвующее в оказании медицинской помощи отдельному лицу или популяции.

3.33 медицинское учреждение (healthcare organization): Учреждение, прямо или косвенно участвующее в оказании медицинской помощи отдельному лицу или популяции.

3.34 участник сферы здравоохранения (healthcare party): Лицо, прямо или косвенно участвующее в оказании медицинской помощи отдельному лицу или популяции.

3.35 медицинская услуга (healthcare service): Услуга, предоставляемая с целью прямо или косвенно улучшить состояние здоровья отдельного лица или популяции, которым она предоставляется.

3.36 унаследованные данные (legacy data): Данные, которые собирались и обрабатывались в «предыдущей» системе, но теперь хранятся в «текущей» системе.

3.37 метаданные (metadata): Данные, определяющие класс объекта и свойства собранной информации.

[ИСО/ТС 17090-1:2002 <*>, статья 3.2.21]

<*> Отменен. Действует ИСО 17090-1:2008. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.

3.39 пациент (patient): Синоним термина «субъект медицинской помощи».

3.40 постоянные данные (persistent data): Данные, хранящиеся на постоянной основе.

3.41 персональная медицинская карта (personal health record): Медицинская карта, содержание которой контролирует субъект медицинской помощи или его законный представитель.

[ИСО/МЭК 2382-8:1998, статья 08.01.23]

3.43 элемент записи (record component): Часть выписки из электронной медицинской карты одного субъекта медицинской помощи, представленная как узел в иерархической структуре данных, соответствующей настоящему стандарту.

[ИСО/ТС 17090-1:2002 <*>, статья 3.2.24]

<*> Отменен. Действует ИСО 17090-1:2008. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.

[ИСО/ТС 18308-2004 <>, статья 3.38]**

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

[ИСО/ТС 20514:2005, статья 2.33]

[ИСО/МЭК Руководство 2:2004, статья 3.2]

[ИСО/ТС 18308-2004 <**>, статья 3.39]

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

3.49 субъект медицинской помощи (subject of care): Лицо, которому запланирована медицинская помощь, получающее или получившее медицинскую помощь.

3.50 точка зрения (view): Альтернативное представление данных для другого пользователя или другой цели.

4 Обозначения и сокращения

В настоящем стандарте использованы следующие Comité о Européen бозначения и сокращения:

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

CEN/TC 251 — Технический комитет 251 CEN, разрабатывающий стандарты по информатизации здоровья (CEN Technical Committee 251);

CMET — общий тип элементов сообщения (формализм, определенный в HL7) (Common Message Element Type);

ЭИБ (EHCR) — электронная история болезни (Electronic Healthcare Record);

ЭМК (EHR) — электронная медицинская карта (Electronic Health Record);

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

GEHR — Исследовательский проект 1992 — 1995 гг. (Good European Health Record);

GP — врач общей практики (general practitioner);

HISA — архитектура сервисов информатизации здоровья (акроним, использованный в [17]) (Health Informatics Service Architecture);

HL7 — Health Level Seven;

IANA — Комитет по присвоению адресов в Интернете (Internet Assigned Numbers Authority);

IETF — Инженерная группа по развитию Интернета (Internet Engineering Task Force);

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

ОРО (ODP) — открытая распределенная обработка (используется для описания распределенных систем [13]) (Open Distributed Processing);

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

НИОКР (R&D) — научно-исследовательские и опытно-конструкторские работы (Research and Development);

RFC — рабочие предложения (request for comments);

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

W3C — Консорциум по всемирной сети (World Wide Web Consortium); XML — расширяемый язык разметки (Extensible Markup Language).

5 Соответствие

5.1 Соответствие системы ведения ЭМК

5.1.1 Система передачи данных ЭМК удовлетворяет требованиям настоящего стандарта, если вся подлежащая обмену информация, соответствующая области применения настоящего стандарта, может быть представлена в форме, в которой существует прямое соответствие между структурой обмениваемых данных и информационной моделью EHR_EXTRACT, определенной в разделе 6 с использованием языка UML. Другие модели обмена определены в ИСО 13606-5.

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

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

a) обозначение продукта/системы;

b) целевое назначение или назначения системы ведения ЭМК (например, является ли она специализированной, используемой при оказании первичной медицинской помощи, предназначенной для стационаров или ограниченной конкретной медицинской специальностью);

c) способность передавать или принимать выписки EHR_EXTRACT, либо выполнять оба действия;

d) объявление реализованного подмножества классов стандарта;

e) объявление используемых типов данных;

f) объявление используемых ассоциированных терминологических систем;

g) спецификацию синтаксиса или синтаксисов, применяемых для представления выписки EHR_EXTRACT (например, могут быть указаны конкретные XML-схемы).

5.2 Соответствие стран-участниц

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

5.2.3 Данный национальный профиль должен использоваться для проверки на соответствие в данной стране-участнице.

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

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

5.2.6 Комитет ИСО/ТК 215 должен опубликовать уведомление о данном национальном профиле.

6 Базовая модель

6.1 Указатель к пакетам

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

6.2 Пакет EXTRACT

6.2.1 Общая информация

Класс

Рисунок 3 — Диаграмма классов UML пакета EXTRACT

6.2.2 Класс EHR_EXTRACT

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

6.2.3 Класс EXTRACT_CRITERIA

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

6.2.4 Класс RECORD_COMPONENT{Abstract}

Непосредственные подклассы: CONTENT, COMPOSITION, ITEM и FOLDER. Данный абстрактный класс является суперклассом для всех конкретных узлов иерархии ЭМК: тома FOLDER, композиции COMPOSITION, раздела SECTION, подраздела ENTRY, кластера CLUSTER, элемента ELEMENT, а также для двух абстрактных классов: содержания CONTENT и сущности ITEM.

\frac{RECORDCOMPONENT}{| + - - FOLDER} 6.2.5 Класс FOLDER

Класс тома FOLDER может использоваться для организации и группировки классов COMPOSITION в выписке EHR_EXTRACT. Иерархия томов может соответствовать или иметь сходство с верхними уровнями организации данных ЭМК в системе ЭМК поставщика, либо быть созданной специально для данной выписки EHR_EXTRACT.

\frac{RECORDCOMPONENT}{| + - - COMPOSITION} 6.2.6 Класс COMPOSITION

Класс композиции COMPOSITION представляет собой совокупность элементов RECORD_COMPONENT, составленную (созданную) в течение одного врачебного приема или сеанса документирования и отправленную в одну ЭМК.

\frac{RECORDCOMPONENT}{| + - - CONTENT} 6.2.7 Класс CONTENT{Abstract}

Непосредственные подклассы: ENTRY и SECTION.

Данный класс является абстрактным родителем для классов SECTION и ENTRY, представляющих содержание данных ЭМК в композиции COMPOSITION.

\frac{CONTENT}{| + - - SECT} ION 6.2.8 Класс SECTION

Класс раздела SECTION содержит совокупность подразделов ENTRY и факультативно, другие разделы SECTION, сгруппированные под одним медицинским заголовком.

\frac{CONTENT}{| + - - ENTR} Y 6.2.9 Класс ENTRY

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

\frac{ITEM}{| + - - E} LEMENT 6.2.12 Класс ELEMENT

6.2.13 Класс AUDIT_INFO

Данный класс содержит элемента RECORD_COMPONENT. С помощью ассоциации committal, идущей от композиции COMPOSITION, этот класс позволяет указать данные об отправке и изменении содержания композиции COMPOSITION в системе поставщика ЭМК. С помощью ассоциации feeder_audit, идущей от элемента RECORD_COMPONENT, данный класс позволяет указать сведения об отправке и изменениях этого элемента RECORD_COMPONENT в той системе ведения ЭМК, в которую он был впервые отправлен.

6.2.14 Класс ATTESTATION_INFO

6.2.15 Класс FUNCTIONAL_ROLE

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

6.2.16 Класс RELATED_PARTY

Класс RELATED_PARTY является базовым классом атрибута subject_of_information подраздела ENTRY. Этот атрибут позволяет идентифицировать лицо в терминах его связи с субъектом медицинской помощи.

6.2.17 Класс LINK

Класс LINK определяет семантику нелокализованной связи между двумя компонентами RECORD_COMPONENT. Исходный компонент RECORD_COMPONENT может иметь связи с произвольным числом конечных компонентов RECORD_COMPONENT.

6.3 Пакет DEMOGRAPHICS

6.3.1 Общая информация

6.3.2 Класс IDENTIFIED_ENTITY{Abstract}

Непосредственные подклассы: SOFTWARE_OR_DEVICE, ORGANIZATION, PERSON. Этот класс может содержать информацию о любой идентифицируемой стороне, например об учреждении, лице, приборе или программном обеспечении.

\frac{IDENTIFIEDENTITY}{| + - - SOFTWARE_O} R_DEVICE 6.3.3 Класс SOFTWARE_OR_DEVICE

Данный класс представляет описание оборудования или прибора (соответствует компоненту GPIC 2.055).

\frac{IDENTIFIEDENTITY}{| + - - ORGANIZATIO} N 6.3.4 Класс ORGANIZATION

Данный класс представляет информацию об организации (соответствует компоненту GPIC 2.008).

Непосредственные подклассы: IDENTIFIED_HEALTHCARE_PROFESSIONAL, SUBJECT_OF_CARE_PERSON_IDENTIFICATION. Данный класс представляет общие демографические данные лица (соответствует компоненту GPIC 2.006).

\frac{PERSON}{| + - - IDE} NTIFIED_HEALTHCARE_PROFESSIONAL 6.3.6 Класс IDENTIFIED_HEALTHCARE_PROFESSIONAL

6.3.7 Класс HEALTHCARE_PROFESSIONAL_ROLE

Данный класс описывает роль, исполняемую лицом, являющимся медицинским работником (основан на одноименном классе GPIC, но с добавлением ассоциации с идентифицированным классом ORGANIZATION).

\frac{PERSON}{| + - - SUB} JECT_OF_CARE_PERSON_IDENTIFICATION 6.3.8 Класс SUBJECT_OF_CARE_PERSON_IDENTIFICATION

6.3.9 Класс TELECOM

(Соответствует группе Common Access Group компонентов GPIC.) Указатель местонахождения некоторого ресурса (информации или сервисов), доступного с помощью телекоммуникационного оборудования. Ответчиком по указанному телекоммуникационному адресу может быть автоматическая служба, возвращающая информацию (например, служба FTP или HTTP). В таких случаях телекоммуникационный адрес служит ссылкой на информацию, доступную с помощью этого адреса. Использование телекоммуникационного адреса может быть ограничено во времени, иметь ограниченный период действия и может иметь определенное предназначение (код, указывающий обстоятельства, при которых данный телекоммуникационный адрес является предпочтительным среди других адресов). Телекоммуникационный адрес является расширением универсального указателя ресурса (URL), определенного в стандарте Интернета [23].

6.3.10 Класс POSTAL_ADDRESS

6.3.11 Класс POSTAL_ADDRESS_PART

Данный класс представляет строку адреса (соответствует группе Common Access Group компонентов GPIC).

6.3.12 Класс ENTITY NAME

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

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

6.3.13 Класс ENTITY_NAME_PART

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

6.4 Пакет SUPPORT

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

Данный пакет содержит подмножество типов данных, определенных в СЕН/ТС 14796 и используемых в качестве типов данных атрибутов в пакетах EHR_EXTRACT и DEMOGRAPHICS. Более подробные сведения об этих типах данных, включая допустимые специализации классов, определенных в данном пакете, представлены в стандарте СЕН/ТС 14796.

Класс

Примечание - Показанные на рисунке подтипы типа данных DATA_VALUE использованы в базовой модели в качестве типов данных атрибутов. Более полный набор подтипов типа данных DATA_VALUE, подходящих для типов значений элемента ELEMENT, приведен в СЕН/ТС 14796.

Рисунок 5 — Диаграмма классов UML пакета SUPPORT

6.4.2 Класс DATA_VALUE{Abstract}

\frac{DATAVALUE}{| + - - CS} 6.4.3 Класс CS

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

\frac{DATAVALUE}{| + - - TEXT} 6.4.5 Класс TEXT

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

\frac{DATAVALUE}{| + - - ED} 6.4.6 Класс ED

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

\frac{DATAVALUE}{| + - - TS} 6.4.7 Класс TS

временнуй

Момент в интервале времени, рассматриваемый как безразмерный. Точки времени определяются заданием их положения (т.е. их «расстоянием» по времени от нулевой точки) во системе отсчета.

\frac{DATAVALUE}{| + - - URI} 6.4.8 Класс URI

Данный класс предназначен для представления ссылки на объект, которая соответствует стандарту универсальных идентификаторов ресурсов (URI), описанному в документе RFC 2936 [27]. Описание универсальных идентификаторов ресурсов, подготовленное Тимом Бернерс-Ли (Tim Berners-Lee), представлено в Интернете по адресу http://www.ietf.org/rfc/rfc2396.txt. Начальные сведения об идентификаторах URI представлены по адресу http://www.w3.org/Addressing. Новые типы идентификаторов URI, например номеров телефонов, факсов и модемов, представлены по адресу http://www.ietf.org/rfc/rfc2806.txt.

\frac{DATAVALUE}{| + - - II} 6.4.9 Класс II

Данный класс представляет глобально уникальный идентификатор объекта.

6.4.10 Класс OID

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

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

6.5 Примитивные типы данных

Рисунок 6 — Диаграмма классов UML пакета примитивных типов данных

A.1 Введение

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

A.2 Общая часть

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

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

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

В средней секции, если таковая есть, указаны атрибуты, включая имя, тип и кратность атрибута. Кратность может быть помечена признаком 'ordered' (упорядоченная). Имена атрибутов представлены строчными буквами. Имена базовых типов данных атрибутов начинаются с прописной буквы, остальные буквы строчные. Если типом данных является другой класс, то его имя указано всеми прописными буквами.

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

B.1 Связь со стандартом HL7, версия 3

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

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

1. признать значимость работы, предпринятой для разработки настоящего стандарта, и добиться одобрения совместимой с ним статической модели HL7, описывающей передачу данных ЭМК по стандарту HL7, версия 3;

2. принять нормативную модель из раздела 6 в качестве модели анализа предметной области в терминах «Основы разработки стандарта HL7» (HDF); это будет способствовать разработке модели предметной области, достоверно отражающей требования, предъявляемые как комитетом HL7, так и ИСО, а в дальнейшем обеспечит отображение этой модели либо на базовую информационную модель (RIM), либо на соответствующую уточненную информационную модель сообщений HL7 (RMIM);

3. объявить «Шаблон медицинских утверждений HL7» (информационную модель сообщений предметной области) наиболее подходящей целью отображения для всех типовых медицинских представлений, включая модель передачи данных ЭМК.

Для реализации этого подхода на основе шаблона медицинского утверждения HL7 была разработана статическая модель (HL7 ISO 13606-1 RMIM), логически согласованная с моделью, определенной в разделе 6 настоящего стандарта. Следовательно, эта модель соответствует настоящему стандарту. Кроме того, разрабатывается «Руководство по реализации модели HL7 13606».

B.2 Связь со стандартом ЕН 13940 (стандарт CONTSYS)

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

Некоторые части стандарта CONTSYS относятся непосредственно к клинической информации, в то время как другие его части, хотя и реализованные с помощью систем управления лечебно-диагностическим процессом, относятся к созданию в ЭМК записей об очередности действий при совместном оказании медицинской помощи. Настоящий стандарт определяет выписку EHR_EXTRACT в очень общих терминах, а ИСО 13606-2 определяет средства обмена структурами знаний (архетипами), пригодных для отражения содержания современных лечебных руководств, подготовленных в соответствии с положениями доказательной медицины. Большинство конструкций стандарта CONTSYS, относящихся к клинической информации, будут представлены в базовой модели настоящего стандарта скорее как особые архетипы, а не классы и атрибуты. Однако некоторые фундаментальные понятия стандарта CONTSYS имеют аналогию с настоящей базовой моделью. Эти понятия приведены ниже, чтобы показать, каким образом разработчик системы ЭМК должен отобразить понятия стандарта CONTSYS в выписке EHR_EXTRACT.

Таблица B.1

B.3 Связь со стандартом prEN 12967 HISA

Стандарт prEN 12967 определяет типовую архитектуру сервисов информатизации здоровья (HISA) в качестве логической структуры информационных систем, обслуживающих потребности больших и малых учреждений здравоохранения. Спецификация информационной точки зрения в ИСО 13606-2 определяет основные классы информации, которой надо управлять в медицинском учреждении и, возможно, использовать совместно с другими вычислительными ресурсами. Один из пакетов, описанных в данном международном стандарте, определяет типовое представление медицинской информации. Кроме того, в нем определено множество типовых классов, общих для всей информационной точки зрения стандарта HISA. Чтобы можно было обеспечить передачу данных ЭМК в соответствии с настоящим стандартом, большая часть медицинской информации, содержащейся в системе, соответствующей стандарту HISA и относящейся к указанному субъекту медицинской помощи (в отличие от терминологии или других источников знаний), должна быть отображена на выписку EHR_EXTRACT. Однако в стандарте HISA некоторые общие классы содержат атрибуты, которые необходимы для управления целостностью хранилища физических данных, но которые не надо передавать в другое хранилище ЭМК. В таблице B.2 представлены основные классы, определенные в стандарте HISA и относящиеся к обмену данными ЭМК, и показано, какие значения данных соответствуют классам и атрибутам базовой модели, описанной в настоящем стандарте. Поскольку некоторые классы HISA являются даже более общими, чем классы данной базовой модели, в некоторых случаях показан список вариантов; выбор точного отображения будет зависеть от медицинских понятий, представленных этими данными. Классы и атрибуты HISA, которые не требуется включать в передаваемые данные ЭМК, в таблице B.2 не представлены.

Таблица B.2

Отображение элементов данных HISA на элементы данных настоящего стандарта

B.4 Связь со стандартами ЕН 14822-1, ЕН 14822-2, ЕН 14822-3 и СЕН/ТС 14822-4

В стандартах ЕН 14822-1 — ЕН 14822-3 и СЕН/ТС 14822-4 определено множество информационных компонентов общего назначения (GPIC), являющихся фрагментами моделей UML, представляющими разные бизнес-объекты информатизации здоровья, часто встречающиеся в медицинских сообщениях. Каждая из этих моделей ограничена подмножествами классов и атрибутов базовой информационной модели (RIM) стандарта HL7, версия 3, в целях будущего развития сообщений, разрабатываемых комитетом CEN в соответствии с этим стандартом. Стандарты ЕН 14822 определяют множество компонентов GPIC как медицинского, так и немедицинского назначения.

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

Данные, передаваемые с помощью компонентов GPIC медицинского назначения, могут быть потом сохранены в системе ведения ЭМК и включаться в выписки EHR_EXTRACT. При необходимости для представления таких структур медицинских данных могут использоваться архетипы.

a) в настоящее время спецификация XDS поддерживает только один уровень иерархии класса томов FOLDER;

b) в хранилище, удовлетворяющем спецификации XDS, могут храниться целые композиции COMPOSITION, но без возможности поиска внутри этих композиций. В таблицах B.3 — B.5 представлены основные атрибуты регистра документов, определенного в спецификации XDS, и показано их соответствие классам и атрибутам базовой модели настоящего стандарта. Данные таблицы соответствия могут использоваться при импорте выписки EHR_EXTRACT в хранилище, удовлетворяющем спецификации XDS, или при передаче одного или нескольких документов из этого хранилища в форме выписки EHR_EXTRACT. В спецификации регистра документов XDS для передачи данных предлагается использовать протокол ebXML, и для обеспечения правильных типов данных значений атрибутов, передаваемых в этот регистр, может потребоваться некоторое дополнительное отображение и преобразование данных.

Таблица B.3

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

Таблица B.4

Отображение набора документов, определенного в спецификации XDS, на классы и атрибуты, определенные в настоящем стандарте

Таблица B.5

Отображение элемента тома, определенного в спецификации XDS, на классы и атрибуты, определенные в настоящем стандарте

B.6 Связь с предшествующим стандартом ENV 13606 Данный раздел содержит указания по отображению элементов, определенных в стандарте ENV 13606-1, на элементы, определенные в настоящем стандарте. Эти указания помогут разработчикам, знакомым с предшествующим европейским стандартом ENV 13606, выявить области соответствия и облегчат процесс разработки интерфейсов, предназначенных для перехода на международный стандарт. Следует отметить, что отображения атрибутов и ассоциаций подклассов класса RECORD_COMPONENT, определенных в стандарте ENV 13606-1, не повторяются, если эти атрибуты и ассоциации те же, что у класса RECORD_COMPONENT.

Таблица B.6

Отображение атрибутов и ассоциаций, определенных в стандарте ENV 13606-1, на атрибуты и ассоциации, определенные в настоящем стандарте

КЛИНИЧЕСКИЙ ПРИМЕР

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

28-недельное обследование проведено 12.07.96 г. в 13:42 доктором Д. Калра.

Беременность 27 недель

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

Живот:

ehr_system.extension = Whittington

ehr_system.assigningAuthorityName = NHS

ehr_system.root.oid = 9876543211

ehr_id.extension = WH.1234

ehr_id.assigningAuthorityName = NHS

ehr_id.valid_time = 1/1/1990 — 1/1/3000

ehr_id.root.oid = 9876543211

subject_of_care.assigningAuthorityName = NHS

subject_of_care.root.oid = 9876543211

time_created.time = 16/07/2004 17:32

rm_id = EN13606-1.0

rc_id.extension = 0001

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

name = Дородовая помощь

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codeValue = CENarch-asdyz

meaning.displayName = Дородовая помощь

COMPOSITION

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = 28-недельное обследование

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codeValue = CENarch-xvwyz

synthesised = FALSE

sensitivity = 3

composer.performer.extension = KALRA194

committal.ehr_system.extension = Whittington

committal.ehr_system.assigningAuthorityName = NHS

committal.ehr_system.valid_time = 1/1/1990 — 1/1/3000

committal.time_committed = 12.07.1996 13:42

committal.committer.extension = KALRA194

committal.committer.valid_time = 1/1/1990 — 1/1/3000

rc_id.extension = 0114

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

meaning.codingScheme = 1234567890

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzA

meaning.displayName = Срок беременности

synthesised = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codeValue = DS0

ELEMENT

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = Оценка срока беременности

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzAA

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

synthesised = FALSE

value.PQ.value = 27

value.PQ.units = Неделя

ENTRY

rc_id.extension = 0116

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

meaning.codingSchemeName = CEN

meaning.codeValue = CENarch-xvwyzB

meaning.displayName = Симптомы при беременности

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS0 0

uncertainty_expressed = FALSE

ELEMENT

rc_id.extension = 0117

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

name = Симптом

meaning.codingScheme = 1234567890

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwabcA

synthesised = FALSE

ELEMENT

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

meaning.codingScheme = 1234567890

meaning RC_UID = 0012

meaning.codingSchemeVersion = 1.1

meaning.displayName = Описание симптома

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codeValue = IC01

synthesised = FALSE

value.CODED_TEXT.codingScheme = ICD-12

value.CODED_TEXT.codingSchemeVersion = 12

value.CODED_TEXT.codeValue = D1234

value.CODED_TEXT.displayName = Рефлюкс-эзофагит, сильный

links.nature = LINK-C0

links.follow_link = FALSE

links.target.rc_id.assigningAuthorityName = NLONDON-NHS

links.target.rc_id.valid_time = 1/1/1990 — 1/1/3000

links.target.rc_id.root.oid = 9876543213

SECTION

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

name = Абдоминальное обследование

ENTRY

rc_id.extension = 0121

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = Предлежание

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzF

meaning.displayName = Предлежание плода

synthesised = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS00

uncertainty_expressed = FALSE

ELEMENT

rc_id.extension = 0122

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = Lie

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzF1

meaning.displayName = Ориентация плода

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.CV.codingSchemeName = NHS Clin. Terms

value.CV.codeValue = 635284

ELEMENT

rc_id.extension = 0123

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = Предлежание

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzF2

meaning.displayName = Предлежание плода

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.CV.codingScheme = CTV3

value.CV.codingSchemeName = NHS Clin. Terms

value.CV.codingSchemeVersion = 1.0

value.CV.codeValue = 635288

value.CV.displayName = Головное

ENTRY

rc_id.extension = 0131

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = Пульс

meaning.codingScheme = 1234567890

meaning.codingSchemeVersion = 1.1

meaning.displayName = Измерение пульса плода

subject_of_information_category = DS02

uncertainty_expressed = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS002

subject_of_information.relationship.codeValue = «Плод»

ELEMENT

rc_id.extension = 0133

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = FH

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzHA

meaning.displayName = Частота сокращения сердца плода в минуту

item_category.codingScheme =987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.PQ.value = 140

value.PQ.units = Удар в минуту

value.PQ.property = Частота

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

name = Диагностический прибор

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzHD

meaning.displayName = Прибор для измерения пульса плода

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codeValue = IC04

value.CV.codingSchemeName = CEN device registry

value.CV.codingSchemeVersion = 6.8

value.CV.codeValue = 5621

value.CV.displayName = УЗ аппарат Sonicaid doppler deluxe

ELEMENT

rc_id.extension = 0136

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

name = Ритм пульса плода

meaning.codingSchemeName = CEN

meaning.codeValue = CENarch-xvwyzHR

item_category.codingScheme = 987654334

item_category.codingSchemeVersion = 1.0

synthesised = FALSE

value.CV.codingScheme = CTV3

value.CV.codingSchemeVersion = 1.0

value.CV.displayName = Ритмичный

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

meaning.codingScheme = 1234567890

meaning.codingSchemeVersion = 1.1

meaning.displayName = Кровяное давление

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codeValue = DS00

uncertainty_expressed = FALSE

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

meaning.codingScheme = 1234567890

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvbnhS

meaning.displayName = Измерение систолического давления крови

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codeValue = IC01

value.PQ.value = 100

value.PQ.units = мм рт. ст.

ELEMENT

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

name = Диастолическое

meaning.codingScheme = 1234567890

meaning.codingSchemeVersion = 1.1

meaning.displayName = Измерение диастолического давления крови

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codeValue = IC01

value.PQ.units = мм рт. ст.

COMPOSITION

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = 28-недельное обследование

meaning.codingSchemeName = CEN

meaning.codeValue = CENarch-xvwyz

synthesised = FALSE

composer.performer.extension = KALRA194

committal.ehr_system.extension = Whittington

committal.ehr_system.valid_time = 1/1/1990 — 1/1/3000

committal.time_committed = 13.07.1996 09:11

committal.committer.assigningAuthorityName = NHS

committal.committer.root.oid = 9876543211

committal.version_status.codingSchemeName = EN13606-3 VERSION_STATUS

committal.version_status.codingSchemeVersion = 1.0

committal.version_status.codeValue = VER03

committal.previous_version.rc_id.extension = 0113

committal.previous_version.rc_id.valid_time = 1/1/1990 — 1/1/3000

committal.previous_version.rc_id.root.oid = 9876543213

committal.version_set_id.rc_id.extension = 0113

committal.version_set_id.rc_id.valid_time = 1/1/1990 — 1/1/3000

committal.version_set_id.rc_id.root.oid = 9876543213

rc_id.extension = 0114

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.displayName = Срок беременности

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS00

original_parent_ref.rc_id.extension = 0113

original_parent_ref.rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.extension = 0115

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.displayName = Оценка срока беременности в неделях

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codeValue = IC01

synthesised = FALSE

value.PQ.units = Неделя

rc_id.extension = 0116

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

name = Текущие симптомы

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.displayName = Симптомы при беременности

synthesised = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codeValue = DS00

original_parent_ref.rc_id.extension = 0113

original_parent_ref.rc_id.assigningAuthorityName = NLONDON-NHS

original_parent_ref.rc_id.root.oid = 9876543213

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

name = Симптом

meaning.codingScheme = 1234567890

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwabcA

meaning.displayName = Описание симптома

synthesised = FALSE

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

meaning.codingScheme = 1234567890

meaning RC_UID = 0012

meaning.codingSchemeVersion = 1.1

meaning.displayName = Описание симптома

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

value.CODED_TEXT.codingScheme = ICD-12

value.CODED_TEXT.codingSchemeName = Класс внутренних заболеваний

value.CODED_TEXT.codingSchemeVersion = 12

value.CODED_TEXT.displayName = Рефлюкс-эзофагит, сильный

value.CODED_TEXT.originalText = Сильная изжога

links.nature = LINK-C0

links.follow_link = FALSE

links.target.rc_id.extension = 0008

links.target.rc_id.valid_time = 1/1/1990 — 1/1/3000

SECTION

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = Абдоминальное обследование

original_parent_ref.rc_id.assigningAuthorityName = NLONDON-NHS

original_parent_ref.rc_id.root.oid = 9876543213

ENTRY

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.displayName = Предлежание плода

synthesised = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codeValue = DS00

uncertainty_expressed = FALSE

rc_id.extension = 0122

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codeValue = CENarch-xvwyzF1

meaning.displayName = Ориентация плода

item_category.codingScheme = 987654334

item_category.codingSchemeVersion = 1.0

synthesised = FALSE

value.CV.codingSchemeName = NHS Clin. Terms

value.CV.codeValue = 635284

ELEMENT

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

meaning.codingScheme = 1234567890

meaning.codingSchemeVersion = 1.1

meaning.displayName = Предлежание плода

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codeValue = IC01

value.CV.codingSchemeName = NHS Clin. Terms

value.CV.codeValue = 635288

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.root.oid = 9876543213

meaning.codingScheme = 1234567890

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzH

meaning.displayName = Измерение пульса плода

subject_of_information_category = DS02

uncertainty_expressed = FALSE

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codeValue = DS002

ELEMENT

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = FH

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

'

meaning.codeValue = CENarch-xvwyzHA

meaning.displayName = Частота сокращения сердца плода в минуту

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.PQ.value = 140

value.PQ.units = Удар в минуту

value.PQ.property = Частота

ELEMENT

rc_id.extension = 0135

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = Диагностический прибор

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzHD

meaning.displayName = Прибор для измерения пульса плода

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC04

synthesised = FALSE

value.CV.codingScheme = CEN DEV REG

value.CV.codingSchemeName = CEN device registry

value.CV.codingSchemeVersion = 6.8

value.CV.codeValue = 5621

value.CV.displayName = УЗ аппарат Sonicaid doppler deluxe

ELEMENT

rc_id.extension = 0136

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = Ритм пульса плода

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzHR

meaning.displayName = Описание ритма пульса плода

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codeValue = IC01

synthesised = FALSE

value.CV.codingSchemeName = NHS Clin. Terms

value.CV.codingSchemeVersion = 1.0

value.CV.codeValue = 635700

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = BP

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvbnh

meaning.displayName = Кровяное давление

synthesised = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS00

uncertainty_expressed = FALSE

committal.ehr_system.extension = Whittington

committal.ehr_system.assigningAuthorityName = NHS

committal.ehr_system.valid_time = 1/1/1990 — 1/1/3000

committal.ehr_system.root.oid = 9876543211

committal.time_committed = 13.07.1996 09:11

committal.committer.extension = LLOYD345

committal.committer.assigningAuthorityName = NHS

committal.committer.valid_time = 1/1/1990 — 1/1/3000

committal.committer.root.oid = 9876543211

committal.version_status.codingScheme = 987654338

committal.version_status.codingSchemeName = EN13606-3 VERSION_STATUS

committal.version_status.codingSchemeVersion = 1.0

committal.version_status.codeValue = VER03

committal.previous_version.rc_id.extension = 0151

committal.previous_version.rc_id.assigningAuthorityName = NLONDON-NHS

committal.previous_version.rc_id.valid_time = 1/1/1990 — 1/1/3000

committal.previous_version.rc_id.root.oid = 9876543213

committal.version_set_id.rc_id.extension = 0151

committal.version_set_id.rc_id.assigningAuthorityName = NLONDON-NHS

committal.version_set_id.rc_id.valid_time = 1/1/1990 — 1/1/3000

committal.version_set_id.rc_id.root.oid = 9876543213

ELEMENT

rc_id.extension = 0155

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = Систолическое

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvbnhS

meaning.displayName = Измерение систолического давления крови

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

original_parent_ref.rc_id.extension = 0151

original_parent_ref.rc_id.assigningAuthorityName = NLONDON-NHS

original_parent_ref.rc_id.valid_time = 1/1/1990 — 1/1/3000

original_parent_ref.rc_id.root.oid = 9876543213

value.PQ.value = 100

value.PQ.units = мм рт. ст.

value.PQ.property = Давление

ELEMENT

rc_id.extension = 0258

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 — 1/1/3000

rc_id.root.oid = 9876543213

name = Диастолическое

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvbnhD

meaning.displayName = Измерение диастолического давления крови

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.PQ.value = 60

value.PQ.units = мм рт. ст.

value.PQ.property = Давление

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

ОТОБРАЖЕНИЕ НА ФОРМУЛИРОВКИ ТРЕБОВАНИЙ

Как указано во введении, в качестве основы для формулировки требований настоящего стандарта был принят стандарт ИСО/ТС 18308 [9]. В данном приложении представлено отображение формулировок последнего на основные конструкции базовой модели. Это отображение неизбежно не является взаимно-однозначным. Приведенная ниже таблица D.1 предназначена для углубления понимания подхода, принятого при разработке базовой модели.

Таблица D.1

Отображение требований стандарта ИСО/ТС 18308 на требования настоящего стандарта

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

СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ ССЫЛОЧНЫМ НАЦИОНАЛЬНЫМ СТАНДАРТАМ РОССИЙСКОЙ ФЕДЕРАЦИИ

Таблица ДА.1

БИБЛИОГРАФИЯ