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

ГОСТ Р исо 13606-1 — 2011

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

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

Часть 1

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

ISO 13606-1:2008 Health informatics — Electronic health record communication — Part 1: Reference model (IDT)

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

Москва

Стандартинформ

2013

Предисловие

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

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

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

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

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

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

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

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

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

© Стандартинформ, 2013

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

ГОСТ Р ИС013606-1 —2011

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

В некоторых случаях тома FOLDER могут создаваться специально для организации данных выписки EHREXTRACT или содержать только избранное подмножество данных из соответствующего тома в системе поставщика ЭМК. При этом тома 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 факультативно документирует любые аттестации (например, электронные цифровые подписи), относящиеся к ней в целом или к любому из содержащихся в ней объектов.

Класс Contribution (вклад)

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

XI

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

Класс SECTION

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

Классы SECTION (разделы) могут использоваться для представления дерева медицинских заголовков, используемых в системе поставщика ЭМК для группировки и организации элементов данных в композиции COMPOSITION. Каждый раздел SECTION может содержать дополнительные разделы SECTION и/или подразделы ENTRY.

Класс ENTRY

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

-    информация в подразделе ENTRY может относиться и не к пациенту (например, к родственнику): подраздел ENTRY определяет субъекта информации;

-    информация в подразделе ENTRY может быть предоставленной или классифицированной конкретным лицом: подраздел ENTRY определяет поставщика информации;

-    к конкретному подразделу ENTRY могут иметь отношение другие участники;

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

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

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

Классы ITEM, CLUSTER и ELEMENT

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

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

XII

ГОСТ Р ИС0 13606-1 —2011

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

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

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

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

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

-    текст и кодированные значения;

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

-    даты и время;

-    графические и другие типы данных MIME (например, изображение, сигнал).

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

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

Примечание — Предполагается, что простые типы данных, например, Boolean (булевский), Integer (целый), должны соответствовать стандарту ИСО/МЭК 11404. В настоящем стандарте они не определяются.

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

Класс AUDITJNFO

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

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

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

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

XIII

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

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

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

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

Класс FUNCTIONAL_ROLE

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

-    функцию, выполненную в документируемой ситуации;

-личность агента, выполнившего данную функцию;

-    способ его участия (например, лично, по телефону);

-    медицинское учреждение, в котором находился агент;

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

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

Класс ATTESTATION JNFO

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

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

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

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

ГОСТ Р ИС013606-1 —2011

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

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

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

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

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

-дата и время проведения аттестации;

-    идентификацию лица, осуществившего аттестацию, в форме ссылки на описанный выше класс FUNCTIONALROLE;

-    список аттестованных экземпляров класса RECORD_COMPONENT;

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

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

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

Класс RELATEDPARTY

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

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

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

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

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

Класс LINK

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

XV

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

XVI

ГОСТ Р ИС013606-1 —2011

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

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

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

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

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

-    обеспечить возможность включения в ЭМК любого числа аттестаций для подписи томов FOLDER или композиций COMPOSITION или разрешить аттестацию только частей композиций COMPOSITION.

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

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

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

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

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

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

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

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

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

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

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

Составитель

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

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

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

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

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

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

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

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

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

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

ГОСТ Р ИС0 13606-1 —2011

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

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

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

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

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

В настоящей базовой модели принят аналогичный подход: специфичные объекты определяются однократно в пакете DEMOGRAPHICEXTRACT, и по мере необходимости остальные части выписки EHREXTRACT ссылаются на них с помощью присвоенных им идентификаторов экземпляров. Идентификатор экземпляра, используемый в выписке 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;

XIX

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

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

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

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

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

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

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

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

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

XX

ГОСТ Р ИС013606-1 —2011

Содержание

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

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

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

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

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

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

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

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

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

6.2    Пакет EXTRACT........................................ 7

6.3    Пакет DEMOGRAPHICS.................................... 19

6.4    Пакет SUPPORT........................................ 25

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

Приложение А (справочное) Профиль UML.............................. 33

Приложение В (справочное) Связь с другими стандартами..................... 35

Приложение С (справочное) Клинический пример.......................... 48

Приложение D (справочное) Отображение на формулировки требований............... 63

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации............. 72

Библиография............................................ 73

ГОСТ Р ИС013606-1 —2011

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

ENTRY Blood Pressure Graph Query

CLUSTER: Query Specification

ELEMENT: Query Syntax: <EHR_OQLvq>

ELEMENT: Query String: “Select...

where Cluster.meaning = «Кровяное давление> and containing.Entry.subject_of_information = <Пациент> and containing.Composition.Clinical_Session.session_time.start > (текущая_дата>-365дней)”

ELEMENT: Datetime first authored: 20 февраля 2003

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

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

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

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

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

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

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

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

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

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

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

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

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

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

XXI

Введение

Комплекс стандартов ИСО 13606 состоит из следующих частей под общим заголовком «Информатизация здоровья. Передача электронных медицинских карт»:

-    часть 1: «Базовая модель»;

-    часть 2: «Спецификация передачи архетипов»;

-    часть 3: «Базовые архетипы и списки терминов»;

-    часть 4: «Безопасность»;

-часть5: «Спецификация интерфейсов».

0.1 Преамбула

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

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

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

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

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

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

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

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

ГОСТ Р ИС0 13606-1 —2011

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

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

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

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

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

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

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

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

V

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

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

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

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

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

-достоверное представление исходного смысла, который имел в виду автор подраздела ЭМК или совокупности подразделов;

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

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

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

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

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

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

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

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

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

Компонент иерархии элементов ЭМК Описание Примеры EHR_EXTRACT (выписка из ЭМК) Контейнер верхнего уровня для части или всей ЭМК одного субъекта медицинской помощи, предназначенный для передачи данных получателю ЭМК от системы поставщика ЭМК Нет FOLDER (том) Организация верхнего уровня иерархии элементов ЭМК, подразделяющая ее на части, относящиеся к лечению в конкретных условиях, одной медицинской бригадой или учреждением, либо в течение фиксированного периода времени, например, эпизода лечения Лечение диабета, шизофрении, холецистэктомия, педиатрия, в госпитале Св. Мунго, папка врача общей практики, эпизоды лечения в 2000—2001 гг., в Италии COMPOSITION (композиция) Совокупность данных, отправленных в ЭМК одним агентом в результате одного приема у врача или сеанса документирования Дневниковые записи, документ с результатом лабораторного анализа, протокол лучевого исследования, направление, посещение клиники, этапный эпикриз, выписной эпикриз, оценка функционального состояния, оценка течения диабета SECTION (раздел) Данные ЭМК, содержащиеся в композиции COMPOSITION, сгруппированные под одним клиническим заголовком, обычно отражающие поток информации, собранной во время одного обращения к врачу, или структурированные для улучшения будущего восприятия человеком Причина обращения, анамнез заболевания, семейный анамнез, сведения об аллергии, субъективные симптомы, объективные данные, анализ, план, лечение, диета, осанка, обследование брюшной полости, исследование сетчатки глаза ENTRY (подраздел) Информация, записанная в ЭМК как результат одного медицинского действия, одного обследования, одной клинической интерпретации или планирования одного действия. Ее также называют клиническим утверждением Симптом, обследование, результат одного теста, назначенное лекарство, аллергическая реакция, диагноз, дифференциальный диагноз, дифференциальный счетчик лейкоцитов, измерение кровяного давления CLUSTER (кластер) Способ организации вложенных структур данных, состоящих из нескольких частей, например, временных рядов, а также способ представления граф таблицы Результаты аудиограммы, расшифровка электроэнцефалограммы, взвешенные дифференциальные диагнозы ELEMENT (элемент) Конечный узел иерархии элементов ЭМК, содержащий одно значение данных Систолическое кровяное давление, частота пульса, название лекарства, симптом, масса тела

Объект EHR EXTRACT содержит данные ЭМК в форме композиций COMPOSITION, которые могут быть организованы как иерархия томов FOLDER.

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

Подразделы ENTRY содержат элементы ELEMENT, которые могут быть сгруппированы в форме иерархии кластеров CLUSTER.

Рисунок 1 — Схема иерархии элементов выписки из ЭМК (часть 1)

Рисунок 2 — Схема иерархии выписки из ЭМК (часть 2)

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

Класс EHREXTRACT

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

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

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

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

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

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

VIII

ГОСТ Р ИС0 13606-1 —2011

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

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

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

Класс RECORDCOMPONENT

Основными классами строительных блоков, используемых для построения иерархии данных ЭМК в выписке 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 для этой цели.

IX

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

части ЭМК данного субъекта. Если эти данные являются копией, то для указания идентификатора гс_id

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

Любой класс 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 не по значению, а по ссылке, с помощью списка уникальных иден-