Мечты об ЭИБе. Римэйк.

Всем привет! На днях познакомился со статьей моего коллеги Владимира Марковнина об ЭИБах (электронных историях болезни). Труд очень качественно сделан, благо Владимир имеет отношение как к информационным технологиям, так и к медицине. Мне хотелось бы и вам представить его пост, правда с небольшими моими комментариями (синим), надеюсь, он будет не против, да, Вов? 🙂

Не буду останавливаться на первой части — тут мне делать нечего, Владимир расписал все верно, насколько позволяет оценить мой дилентантский взгляд. Начну с

Как это может выглядеть?

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

Я конечно верю в интернатизацию всей страны, но полагаю, что в отдаленных местах, которые составляют, наверно 90% нашей необъятной, данные как минимум нужно дублировать. Т.е. оставлять и у пациента, и на удаленном ресурсе. Пока пациент лечится в ЛПУ или врачебном кабинете без доступа к интернету, информация аккамулируется локально. Как только пациент попадает туда, где есть доступ к удаленному серверу — происходит синхронизация. Думать о том, что у врача и компьютера нет — грустно. Не буду. 🙂

Учитывая, что информация (а это не только текст, но и снимки и т.д.) предполагает относительно большой объем, для меня логичным выглядит использование для этих целей, например, eToken NG-FLASH (Java) или Rutoken ЭЦП Flash, совмещающие свойства носителя ключевой информации и флешки в обычном понимании. Естественно, информация на флешке защищена, допустим, тем же пин-кодом, что и ключевая информация и имеет стандартизованную структуру.

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

На мой взгляд — это лишнее. Под «вторым экземпляром подписи», видимо, имеется ввиду сертификат ключа подписи, который пациенту получает в удостоверяющем центре. В соответствии с принципами PKI и здравого смысла, сертификаты являются открытой, общедоступной информацией. Сертификат заносится в информационную систему при поступлении больного.

Каждый визит пациента — один новый XML-файл, подписанный ключом врача и зашифрованный ключом пациента. Подпись врача подтверждает его личность и дату записи. — защищает от посторонних глаз.

Тут вот хочу уточнить. ЭЦП врача на файле, конечно нужна. И с ней проблем нет — ЭЦП проставляется с помощью закрытого ключа подписанта (который у врача и только у него), а проверить ее можно с помощью открытого (опять же, общедоступного) ключа. Т.е. речь идет об едином общедоступном реестре сертификатов врачей ЛПУ. Ну или о публичном доступе к реестру ключей УЦ, если он единственный обслуживает всех сотрудников здравохранения нашей страны.

А вот с шифрованием возникает проблема. В документации на СКЗИ «КриптоПро CSP» (самое распространенно, на мой взгляд, СКЗИ в России) указано, что срок действия закрытого ключа не более 1 год 3 месяца, а срок действия открытого ключа (или СКП) не более 30 лет. Причем, при использовании ключевой пары в целях шифрования, срок действия откртого и закрытого ключа делают одинаковым, поскольку шифровать на открытом ключе после окончания срока действия закрытого бессмысленно — не расшифруешь.

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

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

Для обеспечения удаленного доступа и выполнения резервного копирования все записи лечебного учреждения без расшифровки синхронизируются с федеральным сервером. Этим же достигается защита от подделки записей задним числом. На федеральном сервере ключей пациентов и врачей нет, записи там не читают. В случае обращения человека в другое (любое) лечебное учреждение, он берет с собой свой ключ и передает его, в случае госпитализации, на временное хранение в ЛПУ. Это обеспечивает удаленный доступ к записям основной карты. Запрос сначала идет на сервер поликлиники, если он недоступен — к федеральной базе.

Об этом была речь выше. Со всем согласен, но все-таки, я бы сначала работал с локальными записями, хранящимися на носителе пациента, а потом синхронизировал их с федеральным сервером. В любом случае, передача оформляется доверенностью от больного, либо родственников, в случае недееспособности.

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

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

Данные для отчетов извлекаются не из истории болезни, а путем переноса части обезличенных данных о визите пациента в процессе его приема и записи информации в карту. Так можно считать койко-дни, заболеваемость по обращаемости и т.п. То есть срабатывают триггеры — заполнение поля диагноза копирует его без связи с пациентом в отдельную базу ЛПУ, оформленная выписка — увеличивает счетчик благоприятных исходов и т.п.

Сильные места схемы:

  • врачу доступна вся история пациента, а не скудные выписки
  • данные постоянно доступны только медперсоналу поликлиники и пациенту, (при условии хранения ЛПУ третьей копии, наряду с локальной у пациента и удаленной на федеральном сервере)
  • данные резервируются,
  • есть удаленный доступ,
  • достигается неизменяемость записей
  • можно формировать отчеты
  • защита от утечек

Слабые места:

  •  экспертиза — в настоящее время история болезни может пройти до 3-4 экспертиз в обычных условиях и гораздо больше по решению суда. Если давать доступ всем, то это повышает вероятность данных. Если давать доступ только по решению суда, то возникает проблема с контролем деятельности врачей со стороны коллег и страховых компаний. (Опять же, на мой взгляд, вопрос больше юридический, чем технический, хотя…)

В этой статье сознательно не рассматриваются интерфейсы и ПО для ведения ЭИБ — для этого автору не хватает квалификации. Плюс я придерживаюсь точки зрения, что ПО имеет право быть разнородным, а стандартизованы должны быть только форматы и каналы передачи данных. Также, с целью экономии места, не стал останавливаться на модернизации оказания услуг — электронные очереди, регистратуры, анализы через SMS — это тема для отдельного большого разговора.

А я хотел бы поблагодарить Владимира за интересную тему для размышления. Возможно, будет интерес продумать и остальные вопросы из последнего абзаца. Всем спасибо за внимание, буду рад вашим комментариям! 

Связанные записи

Метки: , , , , , , , ,