четверг, 29 сентября 2011 г.

Мечты об ЭИБе

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

В чем смысл истории болезни? 
  1. для лечащего врача это документ, представляющий собой структурированный дневник состояния пациента и позволяющий проследить динамику течения болезни и вспомнить необходимые факты из прошлого. Главных форм хранения сведений две - это амбулаторная карта в поликлинике и по одной истории болезни на каждую госпитализацию. Карта и истории связаны выписками. Следовательно для ЭИБ необходима возможность просмотра лечащим врачом полной медицинской информации о пациенте. 
  2. для другого врача - это способ получить информацию о пациенте. Сейчас реализовано через справки, выписки, запросы, звонки коллегам, зачаточную телемедицину. В идеале информация с разрешения пациента.должна быть доступна любому врачу в необходимом объеме. 
  3. для пациента - изначально врачебные записи не предназначены для больного - для него есть специальные документы - справки и врачебные рекомендации. Однако современное законодательство разрешает доступ к своим медицинским данным в присутствии мед. персонала. 
  4. для контролирующих органов - это не только прокуратура и суд. Сюда входят и зав. отделениями, и администрация лечебных учреждений, и страховые компании. для органов статистики - сводные данные для различных отчетов. 
Упомянутый выше ГОСТ, являясь на настоящий момент единственным нормативным документом, по сути, не описывает техническую сторону электронной истории болезни, лишь указывает на ряд требований, касающихся, преимущественно, безопасности данных. Плюс есть пресловутый 152 ФЗ.
Подводя промежуточный итог можно сформулировать ряд требований к ЭИБ. 
Электронная история болезни должна обладать: 
  1. полнотой данных - в идеале быть единственным источником сведений о здоровье пациента 
  2. возможностью доступа со стороны пациента и мед. персонала лечебных учреждений 
  3. неизменяемостью записей (защита от фальсификации) 
  4. логированием доступа к записям (даже для чтения) 
  5. возможностью удаленного доступа 
  6. предоставлением данных для отчетов 
  7. доступностью для проведения экспертизы 
Главные проблемы ограничивающие ведение истории в электронном виде, это сложность разграничения доступа, обеспечения неизменяемости записей задним числом, легитимность записей (нужно всегда знать, кто, что и когда записал), защищенность от утечек.
Как это может выглядеть? 
Ключевое звено - поликлиника - главное место формирования записей о пациенте. Каждый пациент обладает личной ЭЦП, зашитой в материальном носителе (USB-ключ, смарт- или социальная карта). Там же хранятся сведения о мед. страховании. Второй экземпляр подписи находится в электронном виде в зашифрованном хранилище поликлиники. Каждый врач обладает личным ключом на материальном носителе, обеспечивающим ему доступ к хранилищу сертификатов пациентов. Каждый случай доступа фиксируется записью в базе данных. Каждый визит пациента - один новый XML-файл, подписанный ключом врача и зашифрованный ключом пациента. Подпись врача подтверждает его личность и дату записи. Шифрование - защищает от посторонних глаз. 
Для обеспечения удаленного доступа и выполнения резервного копирования все записи лечебного учреждения без расшифровки синхронизируются с федеральным сервером. Этим же достигается защита от подделки записей задним числом. На федеральном сервере ключей пациентов и врачей нет, записи там не читают. 
В случае обращения человека в другое (любое) лечебное учреждение, он берет с собой свой ключ и передает его, в случае госпитализации, на временное хранение в ЛПУ. Это обеспечивает удаленный доступ к записям основной карты. Запрос сначала идет на сервер поликлиники, если он недоступен - к федеральной базе. В случае госпитализации пациента без ключа - генерируется временный, для ведения текущей истории с последующим импортом. Схема, как в поликлинике - xml-файлы, подписанные ключом врача и зашифрованные ключом пациента. Синхронизация с федеральной базой - ежесуточно. 
Данные для отчетов извлекаются не из истории болезни, а путем переноса части обезличенных данных о визите пациента в процессе его приема и записи информации в карту. Так можно считать койко-дни, заболеваемость по обращаемости и т.п. То есть срабатывают триггеры - заполнение поля диагноза копирует его без связи с пациентом в отдельную базу ЛПУ, оформленная выписка - увеличивает счетчик благоприятных исходов и т.п. 
Сильные места схемы 
  • врачу доступна вся история пациента, а не скудные выписки 
  • данные постоянно доступны только медперсоналу поликлиники и пациенту 
  • данные резервируются есть 
  • удаленный доступ 
  • достигается неизменяемость записей 
  • можно формировать отчеты 
  • защита от утечек 
Слабые места 
  • экспертиза - в настоящее время история болезни может пройти до 3-4 экспертиз в обычных условиях и гораздо больше по решению суда. Если давать доступ всем, то это повышает вероятность утечки данных. Если давать доступ только по решению суда, то возникает проблема с контролем деятельности врачей со стороны коллег и страховых компаний. 
В этой статье сознательно не рассматриваются интерфейсы и ПО для ведения ЭИБ - для этого автору не хватает квалификации. Плюс я придерживаюсь точки зрения, что ПО имеет право быть разнородным, а стандартизованы должны быть только форматы и каналы передачи данных. Также, с целью экономии места, на стал останавливаться на модернизации оказания услуг - электронные очереди, регистратуры, анализы через SMS - это тема для отдельного большого разговора.

Комментариев нет: