Безопасная передача медицинской информации - от электронной почты Gmail до проекта Direct

/
Проект Direct: передача медицинской информации через облако

Современные клинические решения для безопасной передачи медицинских записей по электронной почте в системах здравоохранения

Поощрение интероперабельного и конструктивного использования систем для работы с электронными медицинскими записями (EHR) является одной из основных целей реформы здравоохранения федерального правительства, и проект Direct ― одна из наиболее перспективных инициатив в этой области. Освойте этот протокол прямого обмена конфиденциальной информацией о пациентах через облако, а затем научитесь использовать Java-клиент с открытым исходным кодом Direct Sender для безопасной передачи электронных сообщений в системах здравоохранения.

Облачные вычисления произвели революцию во взаимодействии систем и сократили ИТ-расходы почти в каждой второй отрасли, но в здравоохранении парадигма облачных вычислений внедряется с трудом. Сегодня медицинские облачные ИТ-услуги ограничиваются главным образом хостингом электронных медицинских записей (EHR) для мелких учреждений, который предлагают такие поставщики, как eClinicalWorks и PracticeFusion. Эти поставщики занимаются лишь размещением услуг и данных (программное обеспечение как сервис, или модель SaaS), но не обменом данными. Крупные клинические системы пока не приняли облачные вычисления в сколько-нибудь значимой мере.

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

В этой статье я представляю проект Direct, весьма перспективный протокол обмена конфиденциальными данными, разработанный и продвигаемый федеральным правительством Соединенных Штатов. Я начну с обзора как необходимости открытого обмена данными в области здравоохранения, так и ограничений традиционных протоколов. Я объясню, как проект Direct восполняет некоторые их этих пробелов безопасности и инфраструктуры, которые до сих пор мешали принятию системами здравоохранения более открытых протоколов обмена данными. Наконец, я приведу простой пример программирования с использованием Direct Sender, Java-клиента с открытым исходным кодом, реализующего протокол Direct.

Проект Direct: передача медицинской информации через облако

ИТ-системы здравоохранения и открытый обмен данными

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

HIE и проект Direct Обмен данными между медицинскими учреждениями ― это одна из проблем, для решения которых государство субсидирует специальные системы обмена информацией в области здравоохранения (Health Information Exchanges - HIE), такие как проект Direct. Health Information Exchange ― это учреждение, которое предоставляет инфраструктуру и услуги для облегчения электронного обмена информацией, связанной со здравоохранением. Каждое HIE обычно обслуживает город с пригородами или часть территории штата. В среднем создание HIE обходится более чем в 15 млн долларов, а затем миллионы в год идут на его содержание. «Закрытость» ИТ-систем здравоохранения дорого обходится всем нам.

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

История проекта Direct

В свое время федеральное правительство США разработало сеть для обмена информацией здравоохранения с целью установления связи между госпиталями Министерства обороны и Ведомства по делам ветеранов, чтобы раненные могли получать наилучший уход. Система называлась "Национальная сеть информации по здравоохранению" (National Health Information Network - NHIN). Она была передана в Национальное управление по координированию ИТ-систем в сфере здравоохранения (National Coordinator of Health IT - ONC) и стала проектом разработки ПО с открытым кодом, который служит моделью обмена информацией в области здравоохранения по всей стране. ONC переименовало проект в Общенациональную информационную сеть здравоохранения (Nationwide Health Information Network - NwHIN), а затем в eHealth Exchange.

Ядром федеральной сети HIE служит система на базе сервис-ориентированной архитектуры (SOA) CONNECT, основанная на Java ESB. Медицинские учреждения могут подключать к этой сети свои системы. Сеть CONNECT организована в виде иерархической структуры. Однако на практике такая система очень сложна для поддержания и масштабирования.

Признавая ограничения CONNECT, ONC разработало упрощенную инфраструктуру HIE, названную Direct. В отличие от CONNECT, система Direct предназначена для прямого обмена сообщениями. Открытая, децентрализованная модель обмена данными peer-to-peer Direct хорошо знакома медицинским учреждениям, привыкшим передавать информацию по факсу, и поэтому, скорее всего, получит широкое распространение.

Безопасность электронной почты и ИТ-системы здравоохранения

Данные о пациентах, хранящиеся в ИТ-системах медицинских учреждений, подчиняются строгим правилам защиты и конфиденциальности, таким как Акт о передаче данных медицинского страхования и возможности их учета (HIPAA) и Акт об использовании информационных технологий в системе здравоохранения (HITECH). В совокупности эти правила определяют, как должны храниться и передаваться данные и кто несет ответственность за нарушения.

Электронная почта ― наиболее широко используемый инструмент обмена документами через Интернет. Но несмотря на широкое распространение, электронная почта не обеспечивает достаточной безопасности для передачи конфиденциальных данных, таких как медицинские записи и направления. Адреса электронной почты можно подделать, а данные, прежде чем попасть в папку «Входящие» получателя, проходят через несколько сторонних почтовых серверов в Интернете в незашифрованном виде. Это несовместимо с правилами безопасности HIPAA и HITECH.

HIPAA и HITECH Подробнее о правовом контексте законов HITECH и HIPAA и их влиянии на ИТ-системы здравоохранения можно прочесть в статье Конфиденциальность и безопасность медицинских данных в облаке (Erin Gilmer, developerWorks, октябрь 2012 г.) (EN). Однако распространенность электронной почты оказалась большим соблазном, который первой ощутила финансовая индустрия. Задолго до выхода на сцену здравоохранения финансовая отрасль начала применять безопасную электронную почту для обмена конфиденциальной финансовой информацией с пользователями систем онлайн-банкинга. Стандарт IETF RFC 3851 —Спецификация сообщений Secure/Multipurpose Internet Mail Extensions (S/MIME) — определяет способ шифрования вложений электронной почты с использованием протокола Public Key Infrastructure (PKI). Как указано в RFC 3851, вложения S/MIME могут содержать полные сообщения электронной почты, которые затем пересылаются через открытый Интернет.

Хотя PKI ― широко признанный стандарт интернет-безопасности, использование безопасной электронной почты на основе PKI наталкивается на серьезные препятствия.

  1. PKI требует, чтобы у отправителя и получателя сообщения был цифровой сертификат, выданный уполномоченным органом. Цифровой сертификат содержит ключи для шифрования и дешифрования сообщений. Еще важнее, что он удостоверяет личность отправителя и получателя, так что сообщение невозможно подделать. Получение такого сертификата часто ― длительный и дорогостоящий процесс.

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

  3. Отправитель и получатель должны использовать почтовый клиент, поддерживающий шифрование S/MIME и обнаружение сертификатов на DNS-серверах.

В совокупности эти препятствия значительно затруднили внедрение безопасной электронной почты. Между тем протокол Direct хорошо подходит для безопасного документооборота между медицинскими учреждениями и пациентами в отдельных конкретных случаях.

Проект Direct: передача медицинской информации через облако

Применение в ИТ-системах здравоохранения

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

Другой типичный вариант использования ИТ-систем в сфере здравоохранения ― это передача медицинскими учреждениями документов непосредственно пациентам. Здесь проект Direct перенимает опыт финансовой индустрии. Вместо того чтобы отправлять электронное сообщение непосредственно пациенту, для каждого пациента создается учетная запись электронной почты в ИТ-системе здравоохранения, а затем по обычной электронной почте ему направляются уведомления о поступлении защищенных сообщений. Пациент должен войти на портал системы здравоохранения для пациентов и прочесть свои безопасные сообщения через интерфейс, напоминающий интерфейс Web-почты. В этом случае сообщения безопасной электронной почты передаются в рамках внутренней системы электронной почты учреждения здравоохранения.

Использование Direct для передачи защищенных сообщений

Мы немного рассказали о подоплеке проекта Direct и безопасной электронной почте и надеемся, что преимущества реализации протокола и инфраструктуры Direct в ИТ-системах учреждений здравоохранения очевидны. Так что давайте посмотрим, как создать инфраструктуру для передачи защищенных сообщений. Для этого понадобится отдельный адрес email, на который можно принимать сообщения электронной почты Direct. К счастью, существует служба Microsoft HealthVault, которая обеспечивает поддержку Direct. Начните с создания учетной записи на промежуточном сервере Microsoft HealthVault http://direct.healthvault-stage.com. Когда учетная запись будет готова, вы получите адрес безопасной электронной почты с поддержкой Direct your_id@healthvault-stage.comна этом сервере. Его можно проверить, отправив на этот адрес сообщение.

О службе Microsoft HealthVault Microsoft HealthVault — это система персональных медицинских записей(PHR). Она позволяет пациентам/потребителям самостоятельно управлять своими медицинскими записями. Система HealthVault подключена к системам медицинских записей нескольких крупных клинических сетей.

Далее, нужно создать цифровой сертификат с открытым ключом, который будет использоваться для цифровой подписи сообщений электронной почты. Цифровой сертификат с открытым ключом гарантирует получателям электронной почты, что сообщение действительно отправлено вами. Для каждого адреса отправителя понадобится свой цифровой сертификат. Одним из вариантов является получение удостоверенного цифрового сертификата полномочного центра сертификации, такого как Verisign, и размещение его для обнаружения получателем в своей учетной записи DNS. HealthVault еще больше упрощает этот процесс, позволяя легко создать самозаверенный сертификат и переслать его на hvbd@microsoft.com Сотрудники HealthVault загрузят сертификат как удостоверенный. Самозаверенные сертификаты значительно облегчают разработчикам экспериментирование с системой Direct.

Пару секретного/открытого ключей и цифровой сертификат легко сгенерировать с помощью такого инструмента, как "Связка ключей" Apple. А в листинге 1 приведены команды популярного инструмента openssl, доступного почти во всех распространенных операционных системах.

Листинг 1. Создание пары открытого и секретного ключей с помощью openssl

openssl req -new -newkey rsa:2048 -nodes -keyout private.key openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout private.key -out public.crt openssl pkcs12 -export -in public.crt -inkey private.key -out bundle.p12

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

Передача по электронной почте файла public.crt в Microsoft HealthVault предписывает системе доверять сообщениям, подписанным вашим секретным ключом.

Direct Sender

Direct Sender ― это библиотека ПО с открытым исходным, которую я разработал для облегчения отправки почтовых сообщений Direct. Она размещается на GitHub, куда я поместил также краткое руководство. Библиотека поддерживает несколько способов отправки электронной почты, от использования локального SMTP-сервера до серверов Gmail и специализированных служб электронной почты, таких как Amazon Web Service Simple Email Service и SendGrid. При использовании библиотеки достаточно нескольких строк кода, чтобы отправлять защищенные сообщения электронной почты через службу Gmail, как показано в листинге 2.

Листинг 2. Отправка безопасных сообщений через Gmail

Client client = new GmailClient ( username, password, "/bundle.p12", keyname, keypass); client.sendMessage(from, to, subject, body);

В листинге username и password относятся к учетной записи Gmail, используемой для отправки защищенного сообщения электронной почты. bundle.p12 — это файл PKCS12, созданный в листинге Листинг 1. Убедитесь, что этот файл включен в classpath вашего приложения. keyname и keypass ― это имя и пароль секретного ключа.

Отправив безопасное сообщение, вы должны получить по электронной почте уведомление от HealthVault о прибытии нового сообщения в папку «Входящие». Войдите в HealthVault, чтобы увидеть это сообщение.

Проект Direct: передача медицинской информации через облако

Содержание Direct Sender

Вы видели, как использовать библиотеку Direct Sender. Но что происходит внутри, когда мы шифруем и отправляем сообщение в Direct-совместимом формате? Всю тяжелую работу в Direct Sender выполняют несколько Java-библиотек с открытым исходным кодом:

  • Bouncy Castle ― широко известная реализация с открытым исходным кодом библиотеки Java Cryptography Extension (JCE), которая обеспечивает основные инструменты для поддержки инфраструктуры открытых ключей на платформе Java. Она также обеспечивает дополнения, такие как утилиты шифрования S/MIME;

  • javamail.crypto ― поддерживает включение S/MIME-вложений в API JavaMail Transport;

  • dnsjava ― DNS-клиент на базе Java, способный запрашивать цифровые сертификаты для адресов электронной почты, хранящихся в записи DNS.

Абстрактный класс Java Client поддерживает основные функциональные возможности для подписания, шифрования и создания сообщений электронной почты S/MIME. В листинге 3 обратите внимание на то, что я сначала подписал сообщение секретным ключом, а затем использовал сертификат с открытым ключом получателя для шифрования сообщения. Когда сообщение будет доставлено получателю, HealthVault сначала использует секретный ключ получателя для его расшифровки, а затем открытый ключ отправителя (если он был передан в HealthVault) для проверки подлинности и идентификации отправителя.

Листинг 3. Клиент создает подпись и шифрует сообщение

public abstract class Client { protected String p12KeyStore; protected String priKeyName; protected String priKeyPass; public void sendMessage (String from, String to, String subject, String body) throws Exception { byte [] pubKeyCer = lookupCertificate (to); if (pubKeyCer == null || pubKeyCer.length == 0) { throw new Exception ("Cannot find public key certificate for " + to); } Session session = createSession (); MimeMessage msg = new MimeMessage(session); msg.setFrom(new InternetAddress(from)); msg.setSender(new InternetAddress(from)); msg.addRecipient(javax.mail.Message.RecipientType.TO, new InternetAddress(to)); msg.setSubject(subject); msg.setText(body); msg = signMsg(session, msg); msg = encryptMsg(session, msg, pubKeyCer); msg.saveChanges(); transport(session, msg); } public void sendMessage (String from, String to, String subject, Multipart multipart) throws Exception { byte [] pubKeyCer = lookupCertificate (to); if (pubKeyCer == null || pubKeyCer.length == 0) { throw new Exception ("Cannot find public key certificate for " + to); } Session session = createSession (); MimeMessage msg = new MimeMessage(session); msg.setFrom(new InternetAddress(from)); msg.setSender(new InternetAddress(from)); msg.addRecipient(javax.mail.Message.RecipientType.TO, new InternetAddress(to)); msg.setSubject(subject); msg.setContent(multipart); msg = signMsg(session, msg); msg = encryptMsg(session, msg, pubKeyCer); msg.saveChanges(); transport(session, msg); } protected byte [] lookupCertificate (String email) { try { String domain = email.replaceAll("@", "."); CERTRecord cx = null; Record [] records = new Lookup(domain, Type.CERT).run(); for (int i = 0; i < records.length; i++) { cx = (CERTRecord) records[i]; } if (cx == null) { return null; } else { return cx.getCert (); } } catch (Exception e) { e.printStackTrace (); return null; } } protected MimeMessage encryptMsg(Session session, MimeMessage msg, byte [] pubKeyCer) throws Exception { EncryptionUtils encUtils = EncryptionManager.getEncryptionUtils (EncryptionManager.SMIME); CertificateFactory cf = CertificateFactory.getInstance("X.509"); X509Certificate cert = (X509Certificate)cf.generateCertificate (new ByteArrayInputStream(pubKeyCer)); // Обертывание сертификата в BouncySMIMEEncryptionKey BouncySMIMEEncryptionKey smimekey = new BouncySMIMEEncryptionKey(); smimekey.setCertificate(cert); return encUtils.encryptMessage(session, msg, smimekey); } protected MimeMessage signMsg(Session session, MimeMessage mimeMessage) throws Exception { // Получение EncryptionUtilities S/MIME. EncryptionUtils encUtils = EncryptionManager.getEncryptionUtils (EncryptionManager.SMIME); // Загрузка ключей S/MIME из файла (хранится как ресурс). char[] keystorePass = priKeyPass.toCharArray(); EncryptionKeyManager encKeyManager = encUtils.createKeyManager(); encKeyManager.loadPrivateKeystore(Client.class.getResourceAsStream(p12KeyStore), keystorePass); // Получение секретного ключа S/MIME для подписания. Key privateKey = encKeyManager.getPrivateKey(priKeyName, keystorePass); // Подписание сообщения. return encUtils.signMessage(session, mimeMessage, privateKey); } protected abstract Session createSession (); protected abstract void transport (Session session, MimeMessage msg) throws Exception; }

Далее, класс GmailClient, показанный в листинге 4, реализует методы Java createSession() и transport(), которые поддерживают возможность отправки сообщений электронной почты через серверы Gmail.

Листинг 4. Безопасная пересылка электронной почты через Gmail

public class GmailClient extends Client { String username, password; public GmailClient (String username, String password, String p12KeyStore, String priKeyName, String priKeyPass) { super.p12KeyStore = p12KeyStore; super.priKeyName = priKeyName; super.priKeyPass = priKeyPass; this.username = username; this.password = password; } protected Session createSession() { Properties props = new Properties(); props.put("mail.smtp.host", "smtp.gmail.com"); props.put("mail.smtp.socketFactory.port", "465"); props.put("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory"); props.put("mail.smtp.auth", "true"); props.put("mail.smtp.port", "465"); return Session.getDefaultInstance(props, new javax.mail.Authenticator() { protected PasswordAuthentication getPasswordAuthentication() { return new PasswordAuthentication(username, password); } } ); } protected void transport(Session session, MimeMessage msg) throws Exception { Transport transport = session.getTransport("smtp"); transport.connect(); Transport.send(msg); transport.close(); } }

Получение электронной почты Direct

Использование протокола Direct для безопасной электронной почты вместе с клиентом Direct Sender позволяет сотрудникам регистратуры легко и надежно отправлять направления и результаты анализов в другие клиники и пациентам. Его можно также использовать в приложениях мобильного здравоохранения (mHealth), чтобы вводить данные, собранные от пациентов, в их медицинские карты. Для многих приложений здравоохранения единственным требованием является способность передавать сообщения Direct. Возможность принимать безопасные сообщения может потребоваться в гораздо более редких случаях.

Большинство систем EHR крупных клиник не передает записи о пациентах без широкой административно-технической проверки, поэтому ИТ-системы мелких медицинских учреждений редко поддерживают получение безопасной электронной почты. Получать безопасные электронные сообщения из другой системы электронных медицинских записей труднее, чем только отправлять их. Чтобы получать медицинские записи из EHR клиники, скорее всего, придется установить прямое соединение XML поверх HTTPS с использованием стандартной технологии, такой как среда HL7 (Health Level Seven International).

Чтобы разработать собственную инфраструктуру для получения сообщений Direct от другого медицинского учреждения, понадобится по крайней мере следующее.

  1. Заключить деловое партнерское соглашение с медицинским учреждением, которое будет отправлять вам данные. Это может быть длительный процесс, и это налагает ответственность на обе стороны.

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

Первое требование является административным, а второе ― техническим. Чтобы помочь администраторам в создании собственной инфраструктуры электронной почты Direct, проект Direct поддерживает эталонные реализации с открытым кодом шлюзов электронной почты, способных обрабатывать сообщения Direct. Имеются эталонные реализации для Java EE, Microsoft.net и PHP.

Заключение

При поддержке федерального правительства и многих систем здравоохранения проект Direct вполне может стать стандартом де-факто обмена простыми медицинскими документами, такими как направления, страховая информация, результаты анализов и истории болезни. Он построен на базе существующей, вездесущей инфраструктуры электронной почты, однако его принятие зависит от медицинских учреждений, модернизирующих свои ИТ-системы для поддержки стандартов безопасной электронной почты. Разработчики программного обеспечения, работающие в сфере здравоохранения, быстро оценят протокол Direct как незаменимый инструмент для безопасной отправки электронных медицинских записей.