В рамках одного исследования возникла потребность в описании стандарта электронного медицинского документооборота HL7. Как результат появилась эта статья. Делюсь с хабра-сообществом, надеюсь будет интересно.

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

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

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

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

Для затравки, чтобы было желание прочитать дальше: «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.»

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