Способ и система обмена медицинскими данными

Изобретение относится к области вычислительной техники. Технический результат заключается в повышении безопасности передачи медицинских данных пациента. Компьютерно-реализуемый способ обмена медицинскими данными между клиникой, пациентом и страховой службой, содержащий этапы, на которых: посредством Electronic Health Records сервера (EHR-сервера) осуществляют запрос медицинских данных пациента из медицинской информационной системы клиники, причём при осуществлении запроса медицинских данных пациента используются идентификаторы пациентов (ID) и индексы пациентов и клиник; посредством OneTimePassword-сервера (OTP-сервера) осуществляют проверку запрашивающей стороны на предмет разрешённого доступа к медицинским данным; осуществляют замену идентификаторов пациента (ID) из исходного запроса на соответствующие им идентификаторы (ID) данных из медицинской информационной системы клиники; направляют запрос в медицинскую информационную систему клиники, содержащий только ID пациента, используемый в клинике, причём передачи персональных данных пациента при этом не происходит; посредством EHR-сервера запрошенные медицинские данные извлекаются из медицинской информационной системы клиники и отправляются запрашивающей стороне по защищённому каналу связи. 2 н. и 2 з.п. ф-лы, 2 ил.

 

ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

Из уровня техники известно решение, выбранное в качестве наиболее близкого аналога, RU 2299470 (C2), опубл. 20.05.2007. В данном решении осуществляют создание базы медицинских данных на основе историй болезни и постоянно пополняют их в процессе информационной поддержки практических врачей; выявляют информативные показатели состояния здоровья пациентов на основе анализа высококвалифицированными специалистами историй болезни, сохраненных в базах медицинских данных; формируют по выявленным информативным показателям решающие правила, представляющие собой модели причинно-следственных связей во времени между данными медицинских и биологических исследований и объективного осмотра пациентов и биологическим возрастом пациентов, состоянием здоровья пациентов, прогнозом предполагаемых у пациентов заболеваний или патологических процессов, клиническим диагнозом, имеющихся у пациентов заболеваний; оснащают клиентские узлы практических врачей программными средствами, обеспечивающими применение сформированных решающих правил для информационной поддержки врачей, вводят на конкретном клиентском узле данные анамнеза пациента и результаты его медицинских и биологических исследований и объективного осмотра, применяют в клиентском узле соответствующие решающие правила, чтобы на основе введенных данных установить биологический возраст пациента, оценить состояние здоровья пациента с учетом установленного его биологического возраста по трем группам: здоров, относится к группе риска и болен; спрогнозировать при отнесении пациента к группе риска течение заболевания или патологического процесса как на ранних сроках заболевания, так при уже развившейся патологии, поставить при отнесении пациента к группе «болен» клинический диагноз с учетом характера и степени тяжести изменений в основных системах жизнеобеспечения, индивидуальных особенностей организма и конституционного фактора пациента.

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

Технический результат заключается в повышении безопасности передачи медицинских данных пациента.

Заявленный результат достигается за счет осуществления компьютерно-реализуемого способа обмена медицинскими данными между клиникой, пациентом и страховой службой, содержащего этапы, на которых:

посредством Electronic Health Records сервера (EHR-сервера), располагаемого в информационном контуре клиники, осуществляют запрос медицинских данных пациента из медицинской информационной системы клиники, причём при осуществлении запроса медицинских данных пациента используются идентификаторы пациентов (ID) и индексы пациентов и клиник;

посредством OneTimePassword-сервера (OTP-сервера) осуществляют проверку валидности транзакции, а именно осуществляют проверку запрашивающей стороны на предмет разрешённого доступа к медицинским данным;

осуществляют замену идентификаторов пациента (ID) из исходного запроса на соответствующие им идентификаторы (ID) данных из медицинской информационной системы клинки с целью сопоставления пациента в медицинской информационной системе клиники с идентификатором (ID) пациента в страховой организации;

направляют запрос в медицинскую информационную систему клиники, содержащий только ID пациента, используемый в клинике, причём передачи персональных данных пациента при этом не происходит;

посредством EHR-сервера запрошенные медицинские данные извлекаются из медицинской информационной системы клиники и отправляются запрашивающей стороне по защищённому каналу связи.

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

EHR-сервер, располагаемый в информационном контуре клиники и выполненный с возможностью предоставления медицинских данных пациента из медицинской информационной системы клиники;

OTP-сервер, выполненный с возможностью осуществления верификации личности пользователя, запрашивающего медицинские данные пациента;

сервер аутентификации пользователей, размещённый на EHR-сервере, и позволяющий аутентифицировать пользователей, запрашивающих медицинские данные пациента, при условии их успешной верификации посредством OTP-сервера;

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

В частном варианте реализации описываемой системы, располагаемый в информационном контуре клиники EHR-сервер может быть реализован в качестве физического сервера.

В другом частном варианте реализации описываемой системы, располагаемый в информационном контуре клиники EHR-сервер может быть реализован в качестве виртуального сервера.

ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг. 1, иллюстрирует пример обмена медицинскими данными.

Фиг. 2, иллюстрирует пример общей схемы вычислительного устройства.

ДЕТАЛЬНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

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

Особенностями настоящего технического решения при осуществлении обмена медицинскими данными являются:

1. Отсутствие необходимости в централизованном хранилище данных у сторон, участвующих в обмене, поскольку медицинские данные продолжают храниться локально там, где и были изначально (в общем случае – в медицинской информационной системе (МИС) Клиники);

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

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

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

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

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

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

Electronic Health Records сервер (EHR-сервер/ЭМК-сервер) на стороне МИС производит поиск, извлечение и нормализацию данных, оставляя в них только медицинскую информацию. Персональная информация не передается за рамки контура МИС. В данном случае под контуром МИС понимается информационный контур (например, информационный контур клиники). Контур МИС — это сетевой периметр, управляемый, непосредственно, учреждением, в котором он располагается, и входящий в состав информационных систем учреждения.

После нормализации данных происходит сверка хеша и отправка по защищенному каналу деперсонифицированных медицинских данных конечному пользователю.

Система обмена медицинскими данными в своем составе содержит следующие технические элементы:

EHR-сервер, располагаемый в информационном контуре клиники и выполненный с возможностью предоставления медицинских данных пациента из медицинской информационной системы клиники;

OTP-сервер, выполненный с возможностью осуществления верификации личности пользователя, запрашивающего медицинские данные пациента;

сервер аутентификации пользователей, размещённый на EHR-сервере, и позволяющий аутентифицировать пользователей, запрашивающих медицинские данные пациента, при условии их успешной верификации посредством OTP-сервера;

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

Осуществление аутентификации.

При осуществлении аутентификации (шаг 1) на сервере аутентификации выполняются запросы на OTP-сервер для проверки клиента (под клиентом подразумевается как клиент клиники, так и сторонняя система, например, страховая компания, или любой другой объект, участвующий в процессе обмена данными).

В случае успешной аутентификации клиенту выдаются ключи доступа.

На 2-м шаге выполняется запрос к серверу аутентификации на получение ключа обмена (exchange token). При этом сервер аутентификации отдаёт данный ключ доступа EHR серверу для запроса на аутентификацию на стороне EHR сервера.

На 3-м шаге выполняется запрос к EHR серверу на аутентификацию в базу данных учреждения. В качестве ключа доступа для этого запроса выступает «ключ обмена» (exchange token), полученный на 2-м шаге. В случае успешного выполнения данный запрос возвращает «подпись клиента». Клиент сохраняет подпись для упрощения аутентификации клиента на стороне EHR, во избежание повторного ввода данных.

При повторной аутентификации клиент имеет «подпись клиента», которая автоматически отправляется в запрос на сервер аутентификации (шаг 1).

На сервере аутентификации:

формируется hash от «подписи клиента», серверной части пароля и «соли» (модификатора входа хэш-функции — строки данных, которая передаётся хеш-функции вместе с входным массивом данных (прообразом) для вычисления хэша (образа));

отправляется запрос на сохранение ключей доступа на сервер EHR (hash отправляется туда же). Поскольку EHR-сервер ранее выдал «подпись клиента», он имеет серверный пароль, аналогичный тому, что есть на сервере аутентификации. Далее EHR-сервер проверяет по переданному хешу наличие прав доступа у данного запроса и сохраняет ключи доступа.

Сервер аутентификации возвращает в ответ ключи доступа, за счет чего пользователь имеет возможность осуществлять запросы на сторону EHR-сервера. При повторной аутентификации шаги 2 и 3 исключаются.

Полученные ключи доступа используются для выполнения безопасного соединения для обмена данными между EHR сервером и клиентом.

Кеширующий EHR-сервер, с точки зрения клиента, выполняет роль EHR-сервера (имеет аналогичное API и поведение) однако для получения данных обращается к другим EHR-серверам и агрегирует их (например, объединяет полученные массивы данных и сортирует их по дате создания записей). Кеширующий EHR-сервер также выполняет индексацию данных для ускорения выполнения запросов поиска.

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

В процессе обмена данных участвуют 3 стороны:

1. EHR (ЭМК) сервер — сервер, предоставляющий пользовательскому приложению медицинские данные пользователя, чья личность сопоставлена с пациентом клиники. Данный сервер не выполняет операций записи (добавления, изменения или удаления) в БД МИС — только чтение.

2. Пользовательское приложение — мобильное приложение пациента и/или личный кабинет пациента.

3. Сервер авторизации.

В закрытом контуре клиники выделяется DMZ-сервер (Demilitarized Zone — демилитаризованная зона, ДМЗ-сервер). Это может быть как виртуальный сервер, так и физический. На вышеуказанном сервере устанавливается EHR-сервер (например, сервер MedMe).

При настройке технических элементов необходимо выполнить следующие действия: получить публичный IP-адрес; осуществить проброс порта от маршрутизатора до DMZ (по умолчанию это порт 9443); поднять uplink между DMZ и сервером с копией центральной базы данных медицинской информационной системы.

Для гибкости существует возможность использовать домен. В этом случае необходим подписанный в сертификационном центре SSL-сертификат. Домен или IP-адрес «зашиваются» во внутреннюю конфигурацию приложения (не передаются извне).

Схема авторизации и аутентификации.

Авторизация пользователя (предоставление параметров доступа) выполняется на отдельном сервере авторизации, который может находиться вне закрытого контура. По умолчанию могут использоваться сервера GBooking/MedMe. Параметры доступа передаются EHR (ЭМК) серверу. По этим параметрам приложение имеет доступ к данным.

Сервер авторизации реализует протокол обмена параметров доступа с EHR (ЭМК) - сервером. В рамках данного протокола следующие RPC-запросы отправляются из сервера авторизации на сторону EHR (ЭМК)-сервера:

embedded_storage.save_exchange_token;

embedded_storage.save_auth_info.

При этом, сервер авторизации, при необходимости, может находится на другой инфраструктуре, в т.ч. и на инфраструктуре самой клиники.

Авторизация выполняется с помощью отправки OTP (one-time password) сообщения на телефонный номер пользователя. Таким образом, определяется, что номер телефона пользователя реально существует и принадлежит именно данному пользователю.

Аутентификация (сопоставление пользователя и учетной записи пациента) выполняется на стороне EHR (ЭМК) сервера, на котором можно выделить 2 сценария аутентификации, а именно первичная аутентификация и повторная аутентификация.

Для сохранения сопоставления — пары PublicID (публичный ID пользователя, выданный сервером авторизации), InternalID (приватный ID пациента, полученный из БД МИС) — используется sqlite db, расположенная на том же сервере, что и сам EHR сервер.

В случае повторной аутентификации происходит «сквозная» авторизация — параметры доступа передаются от сервера авторизации на сторону сервера EHR (ЭМК)-сервера в момент самой авторизации. Поддерживается несколько стратегий сопоставления профиля пользователя с учетной записью пациента: Поиск по номеру телефона и сопоставление по данным пациента (ФИО, пол, дата рождения); Поиск по номеру медицинской карты и сопоставление по номеру телефона.

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

На Фиг. 1 можно рассмотреть пример обмена медицинскими данными, где данные, имеющиеся в медицинской информационной системе Клиники, запрашиваются Страховой компанией.

1. Страховая компания запрашивает доступ к медицинским данным из Клиники, при этом использует собственные идентификаторы (ID) пациентов и клиник, например, [ClinicID]_IGS или [PatientID]_IGS (и другие). За счет использования идентификатора при запросе медицинских данных, передачи персональных данных не происходит.

2. Осуществляется проверка валидности транзакции (есть ли у получателя доступ к запрашиваемым данным). Например, пациент может поделиться частью данных своей электронной медкарты (ЭМК), покрытых его программой страхования, но при этом запретить доступ к персональным данным в ЭМК.

3. Осуществляется замена идентификаторов (ID) и индексов из исходного запроса на соответствующие им ID и индексы данных из Клинки. В базе данных МИС располагается таблица с перечнем пациентов клиники. ID пациента — это уникальный признак пациента в таблице пациентов в БД МИС клиники, по которому можно отличить одного пациента от другого (за счёт строгого уникального соответствия между пациентом и его ID).

4. Запрос в Клинику модифицируется и содержит только индексы, используемые в Клинике, за счет чего передачи персональных данных также не происходит.

5. На финальном шаге, запрошенные медицинские данные извлекаются из МИС Клиники и отправляются в страховую компанию по защищённому каналу (на схеме протокол IPSec используется в качестве примера конкретной реализации данного процесса). На данном этапе также не происходит передачи персональных данных, поскольку пересылаемые данные не имеют привязки к конкретному пациенту.

На Фиг. 2 далее будет представлена общая схема вычислительного устройства (200), обеспечивающего обработку данных, необходимую для реализации заявленного решения.

В общем случае устройство (200) содержит такие компоненты, как: один или более процессоров (201), по меньшей мере один модуль оперативной памяти (202), средство хранения данных (203), интерфейсы ввода/вывода (204), средство ввода/вывода (205), средства сетевого взаимодействия (206).

Процессор (201) устройства выполняет основные вычислительные операции, необходимые для функционирования устройства (200) или функциональности одного или более его компонентов. Процессор (201) исполняет необходимые машиночитаемые команды, содержащиеся в оперативной памяти (202).

Модуль оперативной памяти (202), как правило, выполнен в виде ОЗУ и содержит необходимую программную логику, обеспечивающую требуемый функционал.

Средство хранения данных (203) может выполняться в виде HDD-, SSD-дисков, рейд-массива, сетевого хранилища, флэш-памяти, оптических накопителей информации (CD, DVD, MD, Blue-Ray дисков) и т.п. Средство (203) позволяет выполнять долгосрочное хранение различного вида информации, например, вышеупомянутых файлов с наборами данных пользователей, базы данных, содержащих записи измеренных для каждого пользователя временных интервалов, идентификаторов пользователей и т.п.

Интерфейсы (204) представляют собой стандартные средства для подключения и работы с серверной частью, например, USB, RS232, RJ45, LPT, COM, HDMI, PS/2, Lightning, FireWire и т.п.

Выбор интерфейсов (204) зависит от конкретного исполнения устройства (200), которое может представлять собой персональный компьютер, мейнфрейм, серверный кластер, тонкий клиент, смартфон, ноутбук и т.п.

В качестве средств ввода/вывода данных (205) в любом воплощении системы, реализующей описываемый способ, должна использоваться клавиатура. Аппаратное исполнение клавиатуры может быть любым известным: это может быть как встроенная клавиатура, используемая на ноутбуке или нетбуке, так и обособленное устройство, подключенное к настольному компьютеру, серверу или иному компьютерному устройству. Подключение при этом может быть, как проводным, при котором соединительный кабель клавиатуры подключен к порту PS/2 или USB, расположенному на системном блоке настольного компьютера, так и беспроводным, при котором клавиатура осуществляет обмен данными по каналу беспроводной связи, например, радиоканалу, с базовой станцией, которая, в свою очередь, непосредственно подключена к системному блоку, например, к одному из USB-портов. Помимо клавиатуры, в составе средств ввода/вывода данных также может использоваться: джойстик, дисплей (сенсорный дисплей), проектор, тачпад, манипулятор мышь, трекбол, световое перо, динамики, микрофон и т.п.

Средства сетевого взаимодействия (206) выбираются из устройства, обеспечивающего сетевой приём и передачу данных, например, Ethernet-карту, WLAN/Wi-Fi модуль, Bluetooth-модуль, BLE-модуль, NFC-модуль, IrDa, RFID-модуль, GSM-модем и т.п. С помощью средств (205) обеспечивается организация обмена данными по проводному или беспроводному каналу передачи данных, например, WAN, PAN, ЛВС (LAN), Интранет, Интернет, WLAN, WMAN или GSM.

Компоненты устройства (200) сопряжены посредством общей шины передачи данных (210).

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

1. Компьютерно-реализуемый способ обмена медицинскими данными между клиникой, пациентом и страховой службой, содержащий этапы, на которых:

посредством Electronic Health Records сервера (EHR-сервера), располагаемого в информационном контуре клиники, осуществляют запрос медицинских данных пациента из медицинской информационной системы клиники, причём при осуществлении запроса медицинских данных пациента используются идентификаторы пациентов (ID) и индексы пациентов и клиник;

посредством OneTimePassword-сервера (OTP-сервера) осуществляют проверку валидности транзакции, а именно осуществляют проверку запрашивающей стороны на предмет разрешённого доступа к медицинским данным;

осуществляют замену идентификаторов пациента (ID) из исходного запроса на соответствующие им идентификаторы (ID) данных из медицинской информационной системы клиники с целью сопоставления пациента в медицинской информационной системе клиники с идентификатором (ID) пациента в страховой организации;

направляют запрос в медицинскую информационную систему клиники, содержащий только ID пациента, используемый в клинике, причём передачи персональных данных пациента при этом не происходит;

посредством EHR-сервера запрошенные медицинские данные извлекаются из медицинской информационной системы клиники и отправляются запрашивающей стороне по защищённому каналу связи.

2. Система обмена медицинскими данными между клиникой, страховой службой и пациентом, выполненная с возможностью реализовывать этапы способа по п. 1, содержащая взаимосвязанные между собой:

EHR-сервер, располагаемый в информационном контуре клиники и выполненный с возможностью предоставления медицинских данных пациента из медицинской информационной системы клиники;

OTP-сервер, выполненный с возможностью осуществления верификации личности пользователя, запрашивающего медицинские данные пациента;

сервер аутентификации пользователей, размещённый на EHR-сервере и позволяющий аутентифицировать пользователей, запрашивающих медицинские данные пациента, при условии их успешной верификации посредством OTP-сервера;

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

3. Система по п. 2, в которой располагаемый в информационном контуре клиники EHR-сервер может быть реализован в качестве физического сервера.

4. Система по п. 2, в которой располагаемый в информационном контуре клиники EHR-сервер может быть реализован в качестве виртуального сервера.