С точки зрения разработчика мед стандартов, 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).
Кроме самого руководства разработчика, стандарт включает CCD и HL7 core XML схемы, CCD CSS стили и ненормативные примеры правил Schematron для валидации документов.
Прежде чем переходить дальше, небольшое отступление, как, в общем случае, разрабатываются стандарты HL7 и их артефакты. В HL7 это происходит следующим образом, на примере CCD:
- CDA документ наследует классы от HL7 RIM (Reference Information Model) в тесном взаимодействии с типами данных HL7v3.
- Далее, CCD документ наследует свои классы от CDA R-MIM (Refined Message Information Models).
- Далее, на CCD классы накладываются дополнительные ограничения требуемые ASTM CCR.
- Далее, на основе CCD R-MIM, генерируют все необходимые по стандарту HL7 артефакты, такие как XML схемы, MIF файлы и HMD (Hierarchical Message Descriptor) представления.
- На последнем шаге CCD XML схема корректируется вручную, чтобы включить требования первоначально отсутствующие в HL7 RIM, но необходимые по стандарту ASTM CCR.
Графически это может быть представлено следующим образом (в данном примере моя собственная локализация для генерации XML схем и всех требуемых описаний отдельно для заголовка и тела CCD документа):
Далее, прочие организации или бизнес требования могут наложить дополнительные ограничения на стандарт, например, это происходит в США с их Meaningful Use (MU) Stage 1 и Stage 2.
Шаблоны
«Поскольку спецификация CDA излишне гибкая и многофункциональная» (цитата из HL7 Normative Edition в моём вольном переводе), то следующий уровень ограничений для стандарта CDA назван шаблонами или паттернами, которые определяются на уровне документов, секций и записей. Шаблоны «должны следовать детальному руководству разработчика, содержащим детальное описание как элементы документа должны быть структурированы и представлены для обеспечения клинической безопасности». Опять же, первоначальная гибкость стандарта позволяет создавать множество различных шаблонов.
Так, в настоящий момент, на уровне документов определены девять шаблонов документов. Кроме CCD туда входят Consultation Note, Diagnostic Imaging Report, Procedure Note, Discharge Summary и др. На уровне секций определено около 65 шаблонов и их количество, скорее всего, будет увеличиваться. Примерами шаблонов на уровне секций могут быть Allergies, Encounters, Medications, Problem List и т.д.
Следующая картинка схематично показывает, как группируются шаблоны документов и шаблоны секций, а также как налагаются дополнительные ограничения, например, Meaningful Use (MU).
Так, некоторые шаблоны секций могут использоваться как эксклюзивно какими-то шаблонами документов, так и входить в несколько шаблонов документов. Естественно, что на картинке показана только малая часть шаблонов документов и секций.
Как упоминалось выше, CDA не останавливается на секциях и определяет около сотни шаблонов записей. К таким шаблонам относятся, например, Age, Observation, Encounter Diagnosis, Immunization Activity и т.п. Шаблоны записей характеризуют одно из клинических состояний и подразумевают только компьютерную обработку (т.е. не предназначены для чтения представленной информации человеком). Также как и с секциями, некоторые шаблоны записей используются исключительно в одном типе документа, в то время как другие могут встречаться в нескольких типах документов. Например, шаблон записи Discharge Diet используется только в документе Discharge Summary. А шаблон запись Reason for Referral только в Referral Summary (также известном как HITSP C48). В отличие от них записи Allergies или Diagnostic Results встречаются во всех типах документов.
Вся дополнительная информация по CDA, CCD или HL7 доступна, в первую очередь, на сайте HL7.org.
Комментарии (17)
Wayfarer15 Автор
18.04.2015 23:23Если есть идеи какие темы из области HL7 стоит рассмотреть, предлагайте. Попробую что-то написать. Про FHIR пока не заикаться.
tarasius
19.04.2015 20:56Было бы интересно почитать про фичи и возможности того же Mirth.
К примеру, мне нужно было вытаскивать процедуры назначенные пациенту из БД и отдавать их в массиве BAR записей одним месседжом (один рекорд из БД = один BAR). Пришлось скриптиками писать, хотя я почти уверен что был и путь попроще.
Ну и прочие типичные задачи. Если с примерами реализации будет, то вообще супер.Wayfarer15 Автор
20.04.2015 01:21Mirth вполне с таким справляется, только шаблон твоего BAR сообщения тебе всё равно придётся самому делать, он за тебя его не слепит.
NetMozg
19.04.2015 11:15Всё это здорово, но кому это нужно? Google Health умер, так и не сумев достучаться до широких масс.
googleblog.blogspot.ru/2011/06/update-on-google-health-and-google.html
Утечка такой информации — это вам даже не номер кредитки! Кто захочет, чтобы его болячки стали достоянием гласности?hardsome
19.04.2015 13:30Мне это нужно.
Системы приходится стыковать, и правильно делать это, используя стандартный протокол, как бы ни хотелось сделать это по-своему. Если ваша система поддерживает коммуникации с одной внешней системой — то это ничего — делайте что хотите. Если с десятью — двадцатью: уже имеет смысл некоей стандартизации между ними. Если при этом они меняются (в год, скажем, пять новых приходит и пять старых уходит) — другого выхода нет, кроме как использовать отраслевой стандарт. Так что потребность в стандартах есть. Стандарты вроде тоже есть, а на русском языке публикаций немного. Так что есть польза от статей как эта.
И вы правы в том, что отрасль сама по себе очень консервативная, да еще и законами со всех сторон ограничена. Организации предпочитают хранить данные, связанные с пациентами строго у себя, никогда их не терять, пусть даже и переплачивая за это.
Google health не гарантировал вечного хранения, не объяснил как будет обеспечиваться приватность, не предложил прорывных интерфейсов, протоколов. Продукт умер, поскольку пользы в нем было немного.
Скорее всего Google обкатывал какой-то продукт, где Google health был частью, или просто собирал информацию. А поскольку это Google а не разработчик Вася Пупкин из Петушков, они и выкатили продукт в Internet, просто потому что могут. Жизненный цикл этого продукта к жизненному циклу HL7 никакого отношения не имеет пока.NetMozg
19.04.2015 20:40Безусловно, с точки зрения технологии вопросов к актуальности такой работы нет. Но вот с мета-уровня, с точки зрения конечных целей (обмен медицинской информацией)…
Я сам с интересом возился с Google health — там можно было вести историю различных жизненных показателей, анализов, диагнозов, выбирать врачей или целые медучереждения (были подстыкованы сотни больниц), услуги… предоставлять им доступ ко всей или части накопленной информации… то есть очень красивая и, казалось бы, интересная и нужная система.
И когда Google заявил о прекращении проекта, мне, честно говоря, было совсем не понятно, что там не срослось и почему проект был закрыт. Казалось бы такой интересный и нужный!
Именно поэтому движение в сходном направлении и вызывает опасение в его потенциальной бесполезности — потому что Гугл пробовал и несмотря на свою мощь ничего с этим сделать не смог :(
tarasius
19.04.2015 20:53Так ведь тут речь о стандарте, а не продукте одной компании. Если стандарт уже много где используют, то он так просто не умрёт.
Wayfarer15 Автор
20.04.2015 01:28+1Тут надо понимать, что в той стране, где живёт Google, существуют медицинские системы трёх типов — EHR, EMR и PHR. Отличия и схожесть я описывал в своём блоге (ссылку давать не буду). Так вот, Google пытался реализовать PHR и, естественно, это ни кому не нужно, потому что пользователь, тем более в штатах, о своих болезнях почти ни чего не знает, ему, кроме температуры, давления, роста-веса, больше ни чего измерять не приходится и ни каких особых данных, акромя демографических, он по определению ввести не может. А зачем Google эти данные, их и так на каждом углу как гуталлина (там есть агрегаторы, которые совершенно легально, по номеру телефона, позволяют вытащить все остальные данные о человеке).
NetMozg
20.04.2015 08:20О! Туман начинает проясняться!
Wayfarer15 Автор
20.04.2015 16:41Ага. Более того, подозреваю у каждого штата и провинции в Северной Америке (а в первую очередь на них был направлен сервис) есть свои собственные законы, запрещающие медицинской информации покидать пределы юрисдикции. Хотелки Google могли натолкнутся на жестские правила понаписанные в HIPAA Privacy Rule для каждого штата, либо в PIPEDA для провинций.
tarasius
20.04.2015 18:35Да в Штатах, по сравнению с Европой, вообще средневековье. У них для многих медицинских областей почти нет стандартов. И пользуются бумажками. К примеру, в реанимацию и анестезию софт продать не получилось, так как нет стандарта, регулирующего работу софта в этих департаментах.
Wayfarer15 Автор
20.04.2015 19:17Там может быть 1000 и одна причина почему сторонний софт отказались брать. Например, в одном из тендеров (для западного рынка) представленный некой компанией продукт был хорош во всех отношениях и бил таких конкурентов как Oracle в своей узкой нише. Но финансовый аналитик посетовал, что доходы этого вендора меньше, чем всего лишь одного из подразделений, не говоря о всей организации, куда они хотят поставить свой софт. Компанию завернули.
igor_suhorukov
Используется HL7 в РФ федеральных сервисах интеграции медучреждений?
Когда я 1.5 дня в медлайнсофт проработал, то я видел лишь очередной велосипед для передачи данных между ЛПУ, свои форматы для хранения данных пациентов и т.п.
Wayfarer15 Автор
Подобное явление уникально не только для РФ, особенно когда речь идёт о внутреннем взаимодействии систем. Приходилось видеть реализацию, как утверждалось, HL7v2.1, где от всего стандарта взят MSH, да и тот с грубыми нарушениями, а всё остальное Z-сегменты. Всё это помноженное на свои собственные типы данных. От того, что в сообщении используются «крышечки» и «палочки», сообщение не становится автоматически v2.
Что самое интересное, эта реализация достаточно успешно работает, выполняет все необходимые бизнес требования и менять её на «правильный» стандарт ни кто не собирается. Ещё раз, это не в РФ.
igor_suhorukov
vendor lock-in в чистом виде)
Спасибо вам за статьи! Очень интересная тема, хоть и не особо популярная
tarasius
Согласен. Стыкался с таким же. В один продукт приходится вставлять костыли для разных госпиталей. Речь скорее о значениях полей так как один разработчик воспринимает это поле для одних целей, а другой разработчик — совсем для других.
Есть госпитали, которые не купят продукт без поддержки HL7 и CЄ-mark или аналога, а другим пофиг.