Около года назад я задавал вопрос Председателю Комитета по охране здоровья Государственной Думы ФС РФ Д.А. Хубезову о независимости и закрытости не просто персональных, а медицинских персональных данных, медицинской статистики граждан России для третьих лиц (ссылка на видео). Это актуально помнить, особено в аспекте создания США биолабораторий в разных странах мира.
Нижеприведенная статья – выжимка сущности опубликованной в 2015 году (8 лет назад) и некоторых реплик, ответов, мнений читателей статьи, как видно по высказываниям – также пишущих программы для ЕГИСЗ на CDA. Статья и обсуждение ее было на одном из сайтов рунета, где общаются программисты.
Обзор Clinical Document Architecture ﴾CDA﴿
Clinical Document Architecture ﴾CDA﴿ — один из стандартов HL7, разработанный для стандартизации структуры и обеспечения семантической совместимости мед систем при обмене медицинской информацией и/или медицинскими документами.
Определенные характеристики делают CDA крайне гибким к использованию в различных областях. И даже несмотря на то, что в среде разработчиков медицинских систем CDA считается крайне сложным стандартом, он стал одним из наиболее успешных разработанных HL7 для интеграции медицинских данных и согласуется с требованиями Meaningful Use 1 и 2 принятыми в США. Большинство медицинских систем в настоящее время кодируют информацию в одном из девяти возможных шаблонов документов CDA.
Упрощённое описание основных компонентов CDA
Как показано на следующей картинке, в заголовоке CDA включена некоторая административная информация на основе классов и сущностей RIM (Reference Information Model ) модели HL7 (американской компании – разработчике).
Основной класс в заголовке CDA (в приведенной выше блок-схеме – в центре, “CDA Header”) так и называется — Clinical Document, и, в соответствии с его названием, содержит кроме всего прочего информацию для идентификации документа, заголовок, используемый язык, версию, дату публикации и уровень конфиденциальности. Далее рассмотрим назначение некоторых из выше приведённых классов. Чтобы избежать путаницы названия классов будут даны в их английской транскрипции.
Давайте рассмотрим что входит в CDA – ведь там находятся наши данные, данные крови, заболеваний, медицинских состояний, рецептов … 143 млн. граждан РФ!
Обратим внимание на описание поля “Patient” и “Non-structured Body”.
Authenticator
Этот класс включен в документ для идентификации лица и/или организации, которые могут использоваться для проверки подлинности всего содержимого документа CDA.
Recipient
Здесь всё просто, в заголовке документа recipient используется для идентификации получателя (лица и/или организации) документа и может включать такие данные как имя, адрес и прочую информацию. Получателей может быть множество.
Author
В данном классе кодируется информация для идентификации и проверки лица или устройства, а также организации их представляющих, которые ответственны за данные в CDA документе.
Custodian
Данные класс используется для идентификации и проверки организации ответственной за сохранность документа. Подобная организация отвечает за сохранность всех данных в документе (за весь документ).
Source
В данном классе кодируется информация о лице и/или организации поместившим данные в медицинскую систему, на основе которых и был создан документ. Подобным лицом может быть, например, Data Entry clerk.
Parent CDA
Поскольку документ CDA может быть частью другого документа CDA, подобная информация должна быть где-то представлена. В данном классе как раз кодируется информация о взаимосвязях между двумя и более документами.
Patient
Используя данный класс в заголовке CDA документа представлена информация о главном участнике всех событий – пациенте. Имя, адрес, опекуны и всякая прочая информация для полной идентификации пациента. Стоить заметить, что некоторые типы данных запрещены в некоторых странах. Например, информация о расовой и религиозной принадлежности требуется в США, но недопустима в Европе.
CDA Body
Тело документа или CDA Body может быть как неструктурированным для данных, которые не кодируются в XML, так и структурированным для представленных в формате XML данных. С особенностями такого кодирования тесно связано понятие уровней семантической совместимости CDA (в данной статье не рассматриваются).
В описании ниже также будут использоваться английские названия компонентов или классов.
Non-structured Body
Неструктурированное тело документа может содержать только одно вложение со ссылкой на данные вне этого CDA документа, либо Base64 кодированное бинарное вложение (PDF, изображение, аудио, видео и т.п.).
Structured Body
Структурированное тело документа разработано как крайне гибкий механизм для включения разнообразных клинических и административных данных. Именно это делает CDA настолько мощным в концептуальном плане, что теоретически его можно использовать для кодирования всей истории болезни пациента, какой бы сложности она не была. Обратная сторона подобной гибкости в сложности реализации всех имеющихся особенностей стандарта. Одна из причин этого в неправильности или неполноте понимания самого стандарта различными организациями.
Для устранения подобного разногласия были придуманы шаблоны CDA документов. Создание шаблонов и различных руководств разработчика нацелено на упрощение реализации и ограничения разночтений стандарта для одних и тех же клинических областей. К таким шаблоном относятся Clinical Notes, CCD, Discharge Summary и прочее). Все они представлены на официальном сайте HL7. Кроме того, существует около 70-ти шаблонов секций и ещё больше шаблонов записей.
А теперь посмотрим блок-схему, содержание полей CDA-Body (т.е. содержание полей тела CDA, передающего данные через XML и включающего в себя и “Structured Body“, и “Non-structured Body“).
…
Автор статьи (далее – “Автор”, ключевая фраза после долгого диалога)
Я бы сказал «Дело и в людях, и в стандартах». Менять устоявшиеся бизнес процесс мало кому хочется, даже если в какой-то организации полный бардак. Тем не менее, этот бардак как-то же работает. Проблемы начинаются, когда они хотят обмениваться неполными данными с другой подобной организацией, у которой свой такой же конкретный бардак. В результате тратится по полгода только чтобы согласовать как должен называться показатель в каком-то отчёте только потому, что каждая из организацией (их ведь может быть больше чем две участвующих в обмене данными) хочет его видеть таким, какой он у них в данный момент.
Разработчики стандарта тоже особо ни куда не торопятся. У ведущих HL7 Education Working Group я как-то спрашивал, что мешает им написать понятнее какие секции Normative Edition нужны для сертификации, ибо их «Data Types» в стандарте встречается в двух местах – абстрактное описание типов данных и описание реализации (ITS). Неужели двух-страничный листок с описанием этапов подготовки к сертификации трудно написать четко и ясно? Нет, так и не захотели исправить.
Читатель
Происходит примерно следующее:
— Эй, давайте по стандарту работать! Интероперабельность, дружба, клиент пойдет, от ошибок избавимся все дела…
— А давайте.
— Так, почему на то чтобы записать «платифиллин 30мг внутримышечно» уходит полчаса?
— А про 20мг мы вообще не можем ничего подобрать! Как теперь детей лечить?
— Стоп, первая запись касалась побочных эффектов, а назначения — это в другом списке.
— Да ну нафиг эти стандарты!
Или так: в двух клиниках одного города установлен Медиалог одинаковых версий, поддерживающий HL7. Клиники часто направляют больных друг к другу. И те в общем порядке заполняют от руки анкету в регистратуре. Что, передать данные электронно? Нет, не можем. Можем сделать выписку — 300р, 3 дня, а там вам ее вобьют заново.
При этом анкеты работают. Жалкие 10 пунктов неподтвержденного анамнеза снижают смертность и осложнения в несколько раз.
Автор
Так может стоит начинать с тех аспектов, которые не требуют ручного ввода: лаб данные, финансовый биллинг, расписания и прочее подобное?
Читатель
А лабораторные данные они сплошным текстом записывают:)
Я так понимаю, не хватает единиц измерения для части показателей, особенно из старых лабораторий.
Автор
Отобрать карандаши и ручки. :))))
Если серьёзно, у нас несколько десятков дополнительных локальных словарей для каждой реализации.
ЭПИЛОГ
HL7 – американская компания, за деньги которой российские программисты пишут программное обеспечение для российской системы здравоохранения, хранящей данные о всех гражданах России. Не напоминает ли это Вам что-то? Не кажется ли это странным?
Конечно, российскими системами шифрования органов ФСБ РФ можно зашифровать данные и передавать их – но что-то мне подсказывает, что это не будет внедрено во всех 20 846 муниципальных образованиях 89 субъектов России, где поликлинники, больницы, госпитали, санатории, центры ФМБА РФ, отделения и учреждения Роспотребнадзора, Росздравнадзора…
Почему-то при выборах депутатов Государственной Думы РФ и регионов России, мы не используем американские системы голосования!
Из вышеперечисленной стаьти видно, что фактически в ядре структуры CDA (Clinical Document Architecture), базовой в ЕГИСЗ есть ссылки на “внешние объекты/документы”, это видно из блок схем, предоставляемых самим производителем – компанией HL7. И на предложение, просьбу сделать описание более понятным (ред. – на официальных курсах для программистов которые проводит сам HL7) – разработчики так и не делают этого… Ведь очевидно, что закладки есть!
Может все-таки задумаемся?
