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

Что такое Clinical Document Architecture (CDA) я уже, также кратко, описывал в другом посте — habrahabr.ru/post/255879

Сразу замечу, что «полное» описание CDA займёт целую книжку объёмом страниц так на 300, одна из существующих так и называется "The CDA Book". Поэтому нет ни какой возможности в одной статье рассказать про все особенности данного стандарта.
Напомню, Clinical Document Architecture – один из 20-ти доменов стандарта HL7v3. Если вы знакомы с v3, а я надеюсь большинство читателей хоть немного представляют, что это такое, то знаете, что в данной версии все артефакты строятся на основе HL7 Reference Information Model (RIM).

HL7 и Office of the National Coordinator for Health Information Technology (ONC) устраивают конкурс на разработку средств просмотра HL7 CDA документов. Разработки можно присылать до 31 мая 2016.

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



Призы

1-ое место — $15'000 USD
2-ое меcто — $5'000 USD

Мало кто рассказывает о проблемах внедрения healthcare systems, а уж найти документальные подтверждения и того сложнее. Тем не менее, некоторые данные иногда вылезают. В этот раз другой случай, о том, как медики Cedars Sinai Medical Center единогласно отвергли новую систему.

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

Для затравки, чтобы было желание прочитать дальше: «So far, … has cost … at least $115 million and annual maintenance costs are approximately $14 million. The project is five years late, incomplete, riddled with deficiencies, and much of the technology may already be out dated.»

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

— Иа, я принёс тебе подарок! Воздушный шар.
— Спасибо, Пятачок, ты настоящий друг, не то, что некоторые! Шар, это такой большой, красивый!
— Интересно, что это так громко бумкнуло! И где мой воздушный шарик, и откуда взялась эта тряпочка?

В данной краткой статье про причины возникновения нового стандарта HL7 FHIR (Health Level 7 — Fast Healthcare Interoperability Resources) и ожидаемые на этом пути трудности.

И так, в результате критики со стороны сообщества разработчиков (например тут), а также вероятности сокращения финансирования разработки HL7v3 со стороны US HITECH (Health Information Technology for Economic and Clinical Health), январь 2011 ознаменовался новым веянием со стороны Совета Управляющих HL7 на тему о том, как стандарт обмена сообщениями HL7 может быть улучшен. Это развязало руки (и креативность) независимой группе HL7 архитекторов в обсуждении нового подхода обмена информацией в медицинских системах, что первоначально привело к появлению RFH (Resources for Health) позже переименованного в FHIR (Fast Healthcare Interoperability Resources).

Данный новый подход основан на принципах RESTful, как завещал великий Roy Thomas Fielding в своей 5-ой главе. По идее (разработчиков стандарта), FHIR призван упростить и ускорить внедрение HL7 став гораздо проще в реализации и, в тоже время, надежным, и, насколько возможно, основываться на открытых Интернет стандартах.

В отличие от HL7v2 и, в большей степени, от HL7v3, документация FHIR содержит примеры реализации всех артефактов (ресурсов) и ссылки на их использование в сторонних проектах на разных платформах, включая тестовые сервера доступные в Интернете. Группа HL7 утверждает, что HL7v3 всё же не будет выкинут на помойку мёртвых технологий, подчёркивая, что FHIR был создан учитывая опыт с v3.

Данная небольшая статья написана как комментарий к моей предыдущей статье, в частности в той её части, где BC Holmes рассуждает, что «один из способов количественной оценки сложности HL7v3 в подсчёте уровней вложенности типичного сообщения. Оно, как правило, имеет в 5-10 раз больше XML узлов, чем любые другие стандарты основанные на XML, такие как Interactive Financial eXchange (IFX) или Amazon EC2 SOAP API. Кто-то может сказать, что бизнес процессы в здравоохранении существенно сложнее и семантически богаче, чем в финансовой области и, тем более, в книгоиздательстве.»

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

В этой небольшой статье хотелось бы затронуть некоторые, может быть для кого-то не совсем очевидные, аспекты тестирования интерфейсов медицинских систем. И хотя чаще всего взаимодействие подобных систем строится на основе одного из протоколов Health Level 7 (HL7), это не обязательное условие, могут быть использованы и другие способы коммуникации (как пример, можно назвать ASTM Continuity of Care Records (CCR) до того, как он был адаптирован HL7 под названием CCD).

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

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

Ниже приведённая статья — мой вольный перевод сравнительного (достаточно поверхностного) анализа стандартов HL7 и openEHR опубликованной в electronic Journal of Health Informatics 2010 Vol 5 под названием “Putting Health Record Interoperability Standards to Work”. Сама статья, как это принято говорить, любезно предоставлена одним из авторов, правда, ввиду давности публикации, я воздержался от кучи дополнительных вопросов.

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

Очевидно, что сколько людей столько и сравнений (можно глянуть «Какими должны быть стандарты» от Адам Босворт), для меня ниже приведённое больше похоже на сравнение мягкого и зелёного, т.к. HL7 и openEHR преследуют разные цели, их развитие строилось на разных принципах, и, если удалось углядеть какое-то соответствие между ними, то это вовсе не означает, что они равнозначны. Тем не менее, данное сравнение имеет место быть, авторы сами занимаются разработкой стандарта (openEHR), поэтому их мнение должно быть интересным. Мои редкие комментарии в квадратных скобках. Если что-то не совсем понятно, рекомендую обращаться к первоисточнику, возможно ваш перевод будет лучше. Также, статья содержит положительные и отрицательные стороны CDA и CEN EN13606, на мой взгляд эти сравнения не столь существенные, т.к. ссылаются на свои стандарты-предки.

Ниже приведённая статья опять же мой вольный перевод сравнения, а точнее указания на недостатки HL7v3 и достоинства HL7 FHIR (Fast Healthcare Interoperability Resources). Статья «The HL7 Games: Catching FHIR» написана BC Holmes (именно так, но поскольку я с ней лично не знаком, то не было возможности спросить, что значит имя «BC»), человеком, которая не на абстрактных примерах, а очень даже конкретно знает об HL7v3, причём с точки зрения реализации многих из его доменов и сообщений. Тем более, что она была менеджером одного из средств разработки HL7v3.

В связи с этим статья изобилует деталями, так что, если ваш опыт в этой области мал или, тем более, если вы вообще не знакомы с v3, то, зачастую, понять, о чём она говорит, будет весьма трудно. Например, если вы ни когда не использовали средства моделирования RMIM и дальнейшей сериализации в XML схемы, то будет трудно понять, почему возникают проблемы с именованием, когда в модели ActRelationships класс называется «componentOf2», а в XML схеме он же имеет тип «Component6». (Как это сделано, например, в CMET COCT_RM360000UV01 — MedicationOrder Universal. Там же можно найти другие подобные примеры, «subjectOf1» имеет тип «Subject4» и т.д.)

Ранее в комментариях и в статье я упоминал, что в западном мире принято три обозначения ЭМК – Electronic Health Record (EHR), Electronic Medical Record (EMR) и Personal Health Record (PHR).

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

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

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

На это раз статья, которая должна быть многим гораздо ближе, чем просто описание каких-то там EHR-S FM стандартов, так что комменты welcome. Если всё ниже сказанное кому-то покажется из серии «я вообще не понимаю о чём это», предлагаю прочитать несколько моих ранних статей про Health Level 7.

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

Можно выделить следующие три:
Electronic Patient Record-centric – сюда входит то, что относится к конкретному пациенту. Приложения не ограничиваются только хранением демографических данных пациента и его истории болезни. В эту же категорию можно отнести телемедицину, медицинские порталы и т.д.
Public Health Information Networks – системы этого уровня абстрагируются от индивида и агрегируют количественные данные со множества систем ориентированных на пациента для прогноза развитие событий таких как эпидемии, биотероризм и т.п.
Clinical Research Support – в этой группе системы для принятия решений, моделирования лекарств и т.п.

Между категориями нет явной границы, данные перетекают из одной в другую, обрабатываются, дополняются и возвращаются обратно. Не имея опыта в конкретной области или категории зачастую весьма трудно предположить, какие данные могут быть в ней использованы, и в этом случае HL7 Reference Information Model (RIM) предлагает неоценимую помощь предоставляя опыт множества экспертов денно и нощно корпевших над структурой классов и их отношениями.

В связи с этим, когда FHIR ещё даже на горизонте не было, возникла такая тема – если стандарт HL7 такая классная вещь и описывает всё что нужно для обмена мед данными, почему бы не использовать её как структуру базы данных, тогда точно всё что будет принято в сообщении от любой другой системы можно будет как-то сохранить. Бери весь RIM, или RMIM или DMIM относящийся к нужному домену, и используй для проектирования базы данных только нужные для разрабатываемой системы классы.

Данная короткая статья мой вольный перевод поста на блоге Rene Spronk на тему “Analysis of CDA R2 testing tools — most requirements are neither tested nor respected” [1], которая сама по себе основана на презентации сделанной во время конференции IHIC (International HL7 Interoperability Conference) в Праге в начале 2015 года. [2]

PS. Ссылки на видео и прочие материалы в конце статьи.

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

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

Clinical Document Architecture ﴾CDA﴿ — один из стандартов HL7, разработанный для стандартизации структуры и обеспечения семантической совместимости мед систем при обмене медицинской информацией и/или мед документами. Первая версия стандарта была одобрена ANSI ещё в 2001 году. Вторая версия, котороя используется и по сей день, была утверждена ANSI в 2005. Третья версия, CDA R3, находится в стадии разработки и согласования.

CDA R2 (Release 2) гарантирует наличие следующих семи характеристик в CDA документе:
• Сохранность представленной информации;
• Управление представленной информацией;
• Поддержка требований к аутентификации всей представленной информации;
• Поддержка контекста представленной информации;
• Поддержка цельности информации;
• Возможность чтения представленной информации человеком;
• Поддержка бинарной информации, таких как мультимедийные компоненты, PDF, изображения и прочее.

Подобные характеристики делают CDA крайне гибким к использованию в различных областях. И даже несмотря на то, что в среде разработчиков мед систем CDA считается крайне сложным стандартом, он стал одним из наиболее успешных разработанных HL7 для интеграции мед данных и согласуется с требованиями Meaningful Use 1 и 2 принятыми в США. Большинство мед систем в настоящее время кодируют информацию в одном из девяти возможных шаблонов документов CDA, например, Continuity of Care Document (CCD) один из таких шаблонов.

В данной статье представлен обзор или упрощённое описание основных компонентов CDA. И так, как и любой документ, CDA содержит заголовок документа (CDA Header) и тело документа (CDA Body).

Согласно определению в wiki, Continuity of Care Document или CCD, это стандарт, основанный на XML, и направленный на кодирования структуры и семантики медицинской карты пациента для последующего обмена.

С точки зрения разработчика мед стандартов, CCD это совместное детище комитетов HL7 International и ASTM (American Society for Testing and Materials). С семантической точки зрения, CCD есть руководство разработчика по реализации стандарта ASTM CCR (Continuity of Care Record) на основе CDA R2 (HL7 Version 3 Clinical Document Architecture Release 2). Вот такая вот запутанная история.

Проще говоря, встретились два комитета, которые долго бодались по поводу стандартов, и решили, что все те данные, которые используются в ASTM CCR (также известного как ASTM E2369-05), будут закодированы, с небольшими дополнениями, в стандарте CDA. То, что получилось, было названо Continuity of Care Document.

Стандарт описан в следующих двух документах, доступных на сайте HL7.org:

• HL7v3 Normative Edition — HL7 Clinical Document Architecture, Release 2.0;
• HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD).

В данной небольшой статье, ни в коей мере не претендующей на полноту охвата, перечислены некоторые средства разработки для разных версий HL7 и CDA. Критерии, по которым библиотеки, фреймворки или сопутствующие средства попали в этот список следующие: средство должно быть бесплатное или условно бесплатное, поддерживаться организацией или устоявшимся сообществом разработчиков и, желательно, open-source. По этой причине не перечислены всякие хорошие вещи вроде Trifolia или Mirth CDAPI, о которых многие из читателей вряд ли слышали или сталкивались, и вряд ли когда-нибудь столкнутся, если только родная компания вдруг не решит прикупить парочку подобных средства. Так же не попали, например, HL7SDK, множество HL7 редакторов и средства разработки для DICOM.

И так, по порядку с очень кратким описанием.

HL7v2 Software Development Frameworks

• HAPI (Java)

«HAPI (HL7 application programming interface) is an open-source, object-oriented HL7 2.x parser for Java». Данный набор библиотек можно считать стандартом де-факто для разработки HL7v2 приложений на Java. HAPI может быть расширен генерацией своих профилей HL7. Доступен по адресу – hl7api.sourceforge.net

Среди стандартов Health Level 7 (HL7), не смотря на название организации, есть такие, которые не относятся напрямую к передаче медицинских данных. Стандарт «HL7 EHR-System Functional Model» или «HL7 Функциональная Модель системы ЭМК», вторая версия которого с существенными дополнениями опубликована в апреле 2014 года, относится именно к таким стандартам. Данный стандарт носит нормативный, а не рекомендательный характер, одобрен ANSI в 2007, в 2009 первая версия стандарта, после ревизии ISO и CEN, опубликована как ISO/HL7 10781. Стандарт можно свободно скачать на сайте HL7.org под названием HL7 EHR-System Functional Model, Release 2. В стандарт входит описание стандарта и как им пользоваться, и приложение со списком функций.

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

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

Если научиться без запинки произносить эту самую «интероперабельность», то можно выдавать фразы, вроде «Наша компания успешно консолидирует ещё бОльшие аспекты интероперабельности квази и мультидоменных гетерогенных систем и средств кастомизации к условиям конкретного применения» и дуть щёки. Все вокруг будут многозначительно кивать головами — ну как же, интероперабельность, это же совершенно понятно, плавали, знаем.

Попробуем всё так разобраться, что же означает это слово и почему HL7 считает это понятие таким важным. Для начала, заменим его на равноценное по значению, но русское слово. Мне кажется, «совместимость» вполне подходит. Тогда получается, что HL7 озабочена совместимостью медицинских систем. Звучит не так заумно, щёки дуть уже не получится, зато сам термин становится гораздо проще и понятнее.