способ для обмена данными

Формула изобретения

1. Способ для обмена данными между по меньшей мере двумя серверами с использованием шлюза (2), при этом каждый сервер может действовать в качестве запрашивающего сервера (10) или предоставляющего сервера (12) и обладает уникальным федеративным идентификатором, такой идентификатор идентифицирует одиночного пациента (Р), содержащий этапы, на которых:

отправляют исходный запрос, запрашивающий данные пациента, с запрашивающего сервера на шлюз;

разрешают федеративные идентификационные данные, имеющие отношение к пациенту, с использованием шлюза;

создают посредством шлюза один псевдоним сеанса для каждой пары предоставляющего сервера, хранящего релевантные данные пациента, и запрашивающего сервера;

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

передают массивы идентификаторов на каждый сервер соответственно;

заменяют посредством каждого предоставляющего сервера идентификатор пациента (Р) псевдонимом сеанса;

пересылают данные пациента с по меньшей мере одного предоставляющего сервера на запрашивающий сервер и

заменяют посредством запрашивающего сервера все псевдонимы сеанса идентификатором запрашивающего сервера для пациента (Р).

2. Способ для обмена данными по п.1, в котором исходный запрос содержит первый федеративный идентификатор для пациента.

3. Способ для обмена данными по п.1, в котором исходный запрос содержит спецификацию требуемого типа данных пациента.

4. Способ для обмена данными по п.2, в котором исходный запрос содержит спецификацию требуемого типа данных пациента.

5. Способ для обмена данными по п.1, где создание псевдонимов сеансов производится запрашивающим сервером, а передача массивов идентификаторов происходит на предоставляющий сервер и шлюз.

6. Способ для обмена данными по п.2, где создание псевдонимов сеансов производится запрашивающим сервером, а передача массивов идентификаторов происходит на предоставляющий сервер и шлюз.

7. Способ для обмена данными по п.3, где создание псевдонимов сеансов производится запрашивающим сервером, а передача массивов идентификаторов происходит на предоставляющий сервер и шлюз.

8. Способ для обмена данными по любому из пп.1-7, при этом этап передачи дополнительно содержит этапы, на которых:

подготавливают выходящий запрос для каждого предоставляющего сервера,

прикрепляют массив выходящих идентификаторов к запросу и

передают запрос на его соответственный предоставляющий сервер.

9. Способ для обмена данными по п.3, при этом этапы разрешения и передачи дополнительно содержат этапы, на которых:

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

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

отправляют ответ на запрашивающий сервер.

10. Способ для обмена данными по п.9, в котором запрашивающий сервер по приему первого ответа повторно отправляет запрос на данные пациента внеполосным образом, непосредственно на соответственный предоставляющий сервер со ссылкой на соответственный псевдоним сеанса, идентификатор запрашивающего сервера и шифрованный идентификатор.

11. Способ для обмена данными по п.10, где предоставляющий сервер по приему запроса разрешает идентификатор посредством шифрованного идентификатора, извлекает запрошенные данные пациента и отправляет их в ответе со ссылкой на псевдоним сеанса.

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

Описание изобретения к патенту

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

Во многих применениях центральная сторона действует в качестве шлюза, когда данные обмениваются между разными серверами в сети. Примеры включают в себя архитектуры персональной медико-санитарной документации (PHR), например, такие как архитектуры WebMD, DOSSIA, Microsoft HealthVault, архитектуры электронных медико-санитарных документаций (EHR), например NICTIZ в Нидерландах и Infoway в Канаде, и веб-службы, например, для электронной коммерции. Шлюзы могут просто передавать данные или агрегировать данные, которые имеют место в типичном приложении PHR или EHR. Еще одно использование шлюзов привлекает их только в качестве ссылочных указателей для разрешения идентификаторов без непосредственной передачи или агрегирования данных.

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

Эти применения типично используют концепцию, названную управлением федерированной идентификацией, часто перенимая стандарты, подобные SAML (языку разметки для систем обеспечения безопасности), Liberty Alliance или WS-Federation. Это означает, что каждая сторона владеет своим собственным идентификатором и другой идентификационной информацией для одного и того же объекта, такого как пациент или потребитель. Идентификаторы логически связываются - федерируются - на промежуточном шлюзовом поставщике услуг, которым может быть EHR, шлюз электронной коммерции и т.д.

Инфраструктура федерации идентичности (ID-FF) является стандартом, созданным посредством Liberty Alliance Project, чтобы дать возможность федерации идентичности между многочисленными предприятиями через веб-службы. Архитектура инфраструктуры федерации Liberty Alliance дает основанное на псевдониме решение, которое использует псевдонимы в качестве ключей для связи федерированных учетных записей между предприятиями, так что одному предприятию не нужно знать реальный идентификатор пользователя на другом предприятии. Это, наряду с поддержкой для псевдонимов, дает возможность построения гибких федераций, которые могут придерживаться законов и положений о конфиденциальности, а также решений по конфиденциальности отдельных пользователей.

В решении Liberty Alliance шлюз типично имеет роль администратора идентичности, тогда как запрашивающий сервер и предоставляющий сервер имеют роль исполнителя услуг.

Документ «Connecting for health» на http://www.connectingforhealth.org/resources/final_phwg_reportl.pdf описывает типичное приложение PHR, где промежуточный шлюз помогает собирать и организовывать персональную медико-санитарную информацию в PHR. Эта архитектура предоставляет возможность обмена данными в и из PHR. Есть два основных варианта этой модели.

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

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

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

Поскольку большинство решений EHR основаны на стандартах, подобных HL7, которые используют XML (расширяемый язык разметки) для обмена данными, это является тяжелой задачей, особенно, если псевдонимы расположены в произвольных местах в пределах XML-документов. Наибольшее время обработки в веб-службах тратится на декодирование и обработку XML-структур.

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

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

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

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

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

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

Эти и другие аспекты, признаки и преимущества, по которым изобретение является правоспособным, будут очевидны и ясны из последующего описания вариантов осуществления настоящего изобретения, приводится ссылка на прилагаемые чертежи, на которых:

Фиг.1 показывает, как пользователи разных систем EMR соединяются друг с другом через шлюзовой сервер.

Фиг.2 показывает разные этапы первого варианта осуществления способа согласно настоящему изобретению.

Фиг.3 показывает разные этапы второго варианта осуществления способа согласно настоящему изобретению.

Фиг.4 показывает разные этапы третьего варианта осуществления способа согласно настоящему изобретению, в котором запрашивающий сервер использует URL для повторной отправки запроса внеполосным образом на предоставляющий сервер.

ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

Фиг.1 показывает систему EHR, построенную из пользователей, имеющих индивидуальные системы электронной медицинской документации (EMR), соединенные друг с другом через шлюзовой сервер 2. Пользователями на Фиг.1 являются врач 4 общего профиля (GP), аптека 6 и специализированное стационарное лечебное учреждение 8. Фиг.1 дополнительно показывает пациента P, чья медицинская документация могла храниться в некоторой или всех из систем EMR. Системы EMR могли бы быть идентичного типа для всех пользователей, но обычно имеют разные типы. Независимо от того, какая, каждая система EMR имеет свой собственный идентификатор для пациента P. Шлюзовой сервер 2 способен разрешать все существующие федерированные идентификаторы, владея их реестром.

Первый вариант осуществления способа далее будет описан подробно со ссылкой на Фиг.2. Этот вариант осуществления будет описан в соединении с системой электронной медико-санитарной документации (EHR). Однако он может использоваться в любой серверно-шлюзовой системе, где каждый сервер обладает уникальным федерированным идентификатором для одного и того же одиночного пациента.

EHR ссылается на один медицинский документ одного отдельного физического лица в цифровом формате. Системы EHR координируют компьютеризованное хранение и извлечение индивидуальных EHR. EHR построены из электронной медицинской документации (EMR) от многих поставщиков. Многообразие типов связанной со здравоохранением информации может храниться и подвергаться доступу этим способом.

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

Согласно одному из вариантов осуществления способа, локальный сервер EMR называется и действует в качестве запрашивающего сервера, который обозначен 10 на Фиг.2. Фиг.2, более того, показывает шлюз 2 и три предоставляющих сервера 12, которые соответствуют системам EMR разных поставщиков, которые хранят запрашиваемые данные.

В еще одном варианте осуществления запрашивающий сервер взамен может быть внутренним ПК (персональным компьютером, PC), присоединенным к предоставляющим серверам.

Любым способом запрос отправляется, указано стрелкой 100, в шлюз 2 системы EHR, который разрешает федерированные идентификаторы, имеющие отношение к пациенту P, и создает, смотрите стрелку 102, один псевдоним сеанса для каждой пары предоставляющего сервера 12, хранящего релевантные данные пациента, и запрашивающего сервера 10.

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

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

Шлюз 2 ожидает всех ответных данных, указанных исходным запросом, и агрегирует их в один ответ, указано стрелкой 108. После этого он прикрепляет входящий массив идентификаторов к ответу и передает его обратно, смотрите стрелку 110, на запрашивающий сервер 10. Запрашивающий сервер 10 в результате заменяет, см. стрелку 112, все псевдонимы сеансов исходным идентификатором перед обработкой EMR пациента P, например отображением ее конечному пользователю, который изначально запрашивал данные.

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

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

Шлюз 2 системы EHR разрешает входящий массив идентификаторов, смотрите стрелку 202. Разрешение влечет за собой извлечение идентификатора пациента для пациента P на запрашивающем сервере из входящего массива идентификаторов, поиск соответствующего идентификатора пациента для предоставляющего сервера и ассоциативное связывание последнего идентификатора с псевдонимом сеанса, который также извлечен из входящего массива идентификаторов. Если есть больше, чем один предоставляющий сервер 12, шлюз 2 создает один дополнительный уникальный псевдоним сеанса для каждого дополнительного предоставляющего сервера 12. Перед передачей, смотрите стрелки 204, запроса на каждый предоставляющий сервер 12 шлюз 2 форматирует один выходящий массив идентификаторов для каждого предоставляющего сервера 12 с использованием идентификатора пациента предоставляющего сервера и пары псевдонимов сеансов, и прикрепляет его к своему соответственному запросу.

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

Шлюз 2 ожидает всех ответных данных, указанных исходным запросом, и агрегирует их в один ответ. Он затем передает их на запрашивающий сервер 10. Запрашивающий сервер 10 в результате заменяет все псевдонимы сеанса исходным идентификатором перед обработкой EMR пациента P, например отображением ее конечному пользователю, который изначально запрашивал данные. В разновидности этого варианта осуществления шлюз прикрепляет входящий массив идентификаторов к ответу и передает его непосредственно на запрашивающий сервер 12, смотрите стрелки 206. Запрашивающий сервер 12 затем выполняет агрегацию.

В третьем варианте осуществления, который показан на Фиг.4, запрашивающий сервер отправляет запрос, смотрите стрелку 300, в шлюз 2, который разрешает входящие федерированные идентификаторы и для каждого предоставляющего сервера 12 создает один псевдоним сеанса и шифрует идентификатор для пациента P на предоставляющем сервере 12, так что он является дешифруемым только его соответственным предоставляющим сервером 12. После этого шлюз 2 возвращает, смотрите стрелку 302, для каждого предоставляющего сервера 12 один промежуточный ответ, содержащий псевдоним сеанса, сам идентификатор для запрашивающего сервера 10, шифрованный идентификатор для пациента P на предоставляющем сервере 12 и адрес, например один унифицированный указатель ресурса (URL), для каждого предоставляющего сервера 12.

По приему промежуточного ответа запрашивающий сервер 10 использует адрес(а), например URL, для повторной отправки, смотрите стрелки 304, запроса внеполосным образом на каждый предоставляющий сервер 12, соответственно. Запрос содержит псевдоним сеанса и шифрованный идентификатор для пациента P на предоставляющем сервере.

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

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

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

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

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

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

В формуле изобретения термин «содержит/содержащий» не исключает присутствия других элементов или этапов. Более того, хотя и перечислены по отдельности, множество средств, элементов или этапов способа могут быть реализованы, например, одиночным блоком или процессором. Дополнительно, хотя отдельные признаки могут быть включены в разные пункты формулы изобретения, таковые, возможно, могут преимущественно комбинироваться, а включение в разные пункты формулы изобретения не подразумевает, что комбинация признаков не является осуществимой и/или полезной. В дополнение, упоминания в единственном числе не исключают множественности. Выражения единственного числа, «первый», «второй» и т.п. не устраняют множественности. Символы ссылок в пунктах формулы изобретения предусмотрены только в качестве проясняющих примеров и не должны трактоваться как ограничивающие объем формулы изобретения каким бы то ни было образом.