Приложение 4. Система ЭМК и стандарты обмена медицинской информацией

Оглавление

• "Европейский" подход к стандартизации EHR и OpenEHR
• Фонд openEHR
• Проект спецификаций openEHR
  • Стандарты для оценки  openEHR
  • Стандарты, оказавшие влияние на проектирование спецификаций openEHR
  • Стандарты, оказавшие влияние на дизайн архетипов openEHR
  • Стандарты, используемые "внутри" openEHR
  • Стандарты, требующие шлюза для конверсии
  • Общие технологические стандарты
• Методология архетипов и шаблонов

Определение и масштабы создания Единой Государственной Информационной Системы Здравоохранения  (ЕГИСЗ) обуславливают необходимость создания общей архитектуры и применения стандартов взаимодействия между ее различными частями. Общепринятым в мире является пациент-ориентированная общая электронная запись пациента (patient-centric shareable electronic health records, EHR) как ядро системы информатизации здравоохранения. Это утверждение справедливо для любой МИС. И поэтому следует сосредоточиться на стандартах интеграции и интероперабельности приложений и информационных систем, задуманных как ЭМК системы.

"Европейский" подход к стандартизации EHR и OpenEHR

"Европейский" подход к стандартизации EHR с точки зрения структуры клинического содержания и самостоятельного слоя выражения семантики клинической записи обладает несомненными преимуществами, что нашло выражение в появлении openEHR и CEN 13606.

По своему стратегическому значению оба подхода существенно отличаются друг от друга, но, тем не менее, между ними существует тесная связь. Стандарт CEN является продуктом консенсуса по отношению к формату совместного использования EHR информации странами Европейского союза. Это типично для подобных ситуаций: консенсус - это максимальная семантика, принятая всеми участниками, имеющими свои специфические мотивы и позиции. Поэтому данная спецификация является "наименьшим общим знаменателем", основой самого широкого обмена текста и данных EHR между европейскими системами. Техническим языком часть 1 спецификации (информационная модель EHR Эстракта, основанная на ранней версии спецификаций openEHR) содержит ряд компромиссов, вызванных процессом развития стандарта комитетом экспертов. Часть 2 - это снимок модели архетипов openEHR и спецификация языка, а часть 4 выдвигает солидную модель безопасности общих данных EHR. В качестве официального стандарта CEN и ISO, он устанавливает условия для коммуникации между системами различных поставщиков.

Сообщество OpenEHR предлагает набор спецификаций и реализаций ряда сервисов в среде общих EHR, включая EHR систему, EHR Экстракт, демографический сервис, сервисы архетипов и терминологии. Эти продукты принимают форму информационных моделей, сервис моделей и моделей клинического содержания (архетипы). Спецификации openEHR не являются продуктом политического консенсуса, они основаны на открытом проектировании и реализации, этим  они мало чем отличаются от иных известных проектов открытого кода типа Apache.org и Linux. OpenEHR основан на проектировании, имеет большой международный круг членов, рецензентов, исполнителей и пользователей. Все спецификации проходят тест конкретных приложений до их опубликования в окончательной форме. Таким образом, openEHR представляет "живой" комплекс спецификаций, находящийся в активном, управляемом развитии. Процесс этот имеет определенный механизм управления изменениями и план будущего развития. Использование спецификаций и реализаций openEHR гарантирует интероперабельность программного обеспечения и данных в рамках openEHR, возможна также двухсторонняя конверсия в/и из EN13606.

Фонд openEHR

Ocean Informatics  совместно с University College London (UCL) является партнером-основателем Фонда openEHR (созданного в 2001 году), бесприбыльной организации, создавшей вычислительную платформу здравоохранения openEHR. Платформа состоит из технических спецификаций электронной записи и связанной информации. Она реализована в ряде систем открытого кода и коммерческого характера. Это первая в мире вычислительная платформа здравоохранения, предлагающая семантическую интеграцию графического пользовательского интерфейса (GUI), базы данных и запросов, и она является мощным средством создания информационных систем внутри и между организациями, включая межорганизационные бизнес процессы, поддержку принятия решений и медицинские исследования.

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

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

Ocean Informatics расширила платформу openEHR с включением возможности модификации требований в зависимости от конкретной среды. В конечном итоге одни и те же вездесущие архетипы лежат в основе шаблонов, форм, запросов и многих, специфических для данного контекста артефактов. Шаблоны и архетипы, их составляющие, гарантируют стабильность системы против будущих изменений, так как архетипы существуют независимо от программного обеспечения, созданного для их использования. В сочетании с эталонной моделью openEHR они образуют мощное ДНК платформы информатизации здравоохранения. Archetype Query Language, расширение стандартного Standard Query Language (SQL) для EHR создан специально для систем, основанных на openEHR. Archetype Query Language уже выдвинут на роль отраслевого стандарта, следуя примеру ADL - Archetype Definition Language, что явилось признанием со стороны CEN и ISO мощи языка ADL и его объектной модели.

Проект спецификаций openEHR

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

Стандарты для оценки  openEHR

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

• ISO/TR 20514. Информатизация здравоохранения - Электронная запись здоровья – определение, охват и контекст
• ISO/TS 18308. Требования к эталонной архитектуре электронной записи здоровья.

Стандарты, оказавшие влияние на проектирование спецификаций openEHR

• OMG HDTF Стандарты - общий дизайн. Object Management Group, это организация, сыгравшая определенную роль в развитии стандартов в области информатизации здравоохранения - цикл работ, связанных с так называемым  Corbamed (позднее, Health Domain Taskforce, или HDTF), включая следующие стандарты:
  • PIDS (Person Identification Service) – Служба идентификации физических лиц. Эта спецификация определяет интерфейс, который организует функциональность управления ID физических лиц на нужды здравоохранения. Это спецификация сервиса идентификации личности с моделями UML и полной спецификацией CORBA IDL. Это включает в себя большую часть функций по управлению идентификацией пациента. Используется в качестве основного источника для многих идей в спецификации нового сервис стандарта идентификации субъектов - Entity Identification Service (EIS);
  • RAD (Resource access decision service) – Служба разрешений доступа к ресурсам; RAD является механизмом для получения разрешения в области авторизации и административного доступа. Предлагает общий механизм для приложений запрашивать и получать авторизацию.
  • HILS (Health Information Location Service) – Служба нахождения информации здравоохранения; Справочный сервис не был завершен до конца.
  • COAS (Clinical Observations Access Service) - Служба доступа к клиническим наблюдениям. Спецификация COAS является набором интерфейсов и структур данных для предоставления клинических наблюдений. COAS обеспечивает механизм поиска клинического содержания на основе установленных интерфейсов. На практике COAS предлагает генерические средства поиска, независимые от информационной модели. Будущая спецификация сервиса Поиска, нахождения и обновления сервисов (Retrieve, Locate, and Update Service, RLUS) заменит COAS. Это связано с тем, что отсутствие информационной модели препятствовало принятию COAS рынком.
  • TQS (Terminology Query Service) – Служба терминологических запросов.
• Проект спецификации сервисов в здравоохранении (Healthcare Services Specification Project - HSSP) Второй цикл работы Object Management Group начался в 2006 г. созданием Проекта спецификации сервисов в здравоохранении.
• CEN EN 13606:2006: Коммуникации электронной записи здоровья. Electronic Health Record Communication
• CEN HISA 12967-3: Стандартная архитектура информационных систем в области здравоохранения - Вычислительная точка зрения.

Стандарты, оказавшие влияние на дизайн архетипов openEHR

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

• CEN HISA 12967-2: Стандартная архитектура информационных систем в области здравоохранения - Информационная точка зрения;
• CEN ENV 13940: Непрерывный уход (Continuity of Care).

Стандарты, используемые "внутри" openEHR

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

• SO 8601: Синтаксис для выражения дат и времени (используется в пакете openEHR Quantity);
• SO 11404: Типы данных общего назначения (карта соответствия openEHR assumed_types package в Support Information Model);
• HL7 UCUM: Единая кодировка единиц измерения - Unified Coding for Units of Measure (используется для openEHR Quantity). Кодекс единиц измерения в здравоохранении (UCUM) исчерпывающий. Он улучшенный вариант стандартов ISO 2955 и ANSI X3.50. Поддерживается Институтом Регенстриф (Regenstrief Institute) и используется в сообщениях о лабораторных результатах HL7 версии 2. Кодекс стабилен, имеет хорошую документацию и доступен с многих веб сайтов;
• HL7v3 GTS: Синтаксис определения общего расчета времени - General Timing Specification syntax (используется при спецификации типов данных openEHR Time - Время);
• Некоторые предметные словари HL7v3 с установлением соответствия терминологии openEHR;
• IETF RFC 2440 - openPGP.

Стандарты, требующие шлюза для конверсии

Следующие стандарты, находящие применение, требуют конверсии данных для использования в openEHR:

• CEN EN 13606:2005: Electronic Health Record Communication - почти прямая конверсия возможна, так как и openEHR, и CEN EN 13606 активно поддерживаются на цели совместимости;
• HL7v3 CDA: Архитектура клинического документа (CDA) релиз 2.0 - довольно близкая конверсия возможна;
• HL7v3 сообщения. Качество конверсии неясно из-за постоянных изменений в спецификациях сообщений HL7v3 и разнообразия схем сообщений;
• HL7v2 сообщения. Импорт сообщений HL7v2 является трудной технической проблемой, но уже используется в некоторых системах openEHR. Экспорт из openEHR также возможен;

Общие технологические стандарты

openEHR использует или ссылается на следующие стандарты:

• ISO RM/ODP
• OMG UML 2.0
• W3C XML schema 1.0
• W3C XPath 1.0

Методология архетипов и шаблонов

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

Sam Heard и Thomas Beale, Ocean Informatics, создали подход к моделированию на двух уровнях, сочетающий онтологию и информационную модель (программное обеспечение) во второй половине 1990-х годов. Этот прорыв в информатике здравоохранения предлагает новый способ создания программного обеспечения в духе семантического веба.

Язык определения архетипов - Archetype Definition Language (ADL) - созданный Томасом Билем, включен в стандарт CEN13606 в качестве формального языка выражения архетипов. Объектная модель архетипов openEHR (Archetype Object Model) описывает завершенную семантическую модель архетипов в форме объектной модели. Синтаксис ADL является одним из возможных способов реализации архетипа. Система архетипов openEHR описана в терминах определений архетипов, принципов и системы архетипов ADL.

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

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

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

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

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

Рассмотрим пример описания шумов сердца. В самом простом случае (медсестра) отмечается его наличие. В более продвинутом случае (терапевт) — набор шумов и их краткое описание. В самом подробном заполняется полное описание каждого шума (врач-кардиолог). Кроме того, специализированные учреждения могут быть «впереди» принятых стандартов, и заполнять дополнительные поля.

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

И наконец, в архетипах можно использовать маршруты местоположения, которые превращаются в Xpath выражения, наподобие данных XML.