Способ и система обработки данных медико-санитарной помощи

Способ и система обработки данных медико-санитарной помощи

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

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

Уровень техники

Ожидается, что усовершенствования в информационных и коммуникационных технологиях принесут большую пользу в области здравоохранения: введение взаимодействующих систем электронной медицинской записи (EHR) могут сократить стоимость системы здравоохранения и улучшить общее качество лечения, так как службы удаленного управления пациентом (RPM) будут ограничивать время, которое пациент находится в больнице. Несмотря на это, на сегодняшний день, EHR и RPM используются в довольно небольшом масштабе. Помимо проблем относительно интеграции различных систем и вопросов материально-технического обеспечения, первичными причинами отсутствия развернутых систем являются вопросы о конфиденциальности и безопасности информации. Например, EHR системы сталкиваются с необходимостью жестких урегулирований безопасности и конфиденциальности (такие как EU директива 95/46 или HIPAA в США), которым они должны подчиниться.

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

Для того чтобы разрешить совместное использование записей среди различных поставщиков услуг медико-санитарной помощи или с внешними сторонами, методики защиты данных в линии передачи, облегчающие защиту центральных данных, могут применяться: данные криптографически защищаются и допускаются быть приобретенными на стороне или даже свободно размещаться в сети. Вместо того, чтобы полагаться на различные сети, чтобы обеспечить конфиденциальность, целостность и подлинность, данные защищаются на конечных точках передачи данных. Это может быть достигнуто путем применения технологий управления правами - управление цифровыми правами (DRM) в сфере бытовой электроники и управления корпоративными правами (ERM) в коммерческой сфере. В таких системах, публикуемые DRM-защищенные данные шифруются, и сервер лицензий лишь выдает лицензии запрашивающим пользователям, если они имеют достаточно прав на осуществление доступа к данным. Однако конкретная проблема, которая не решается этой технологией, состоит в том, чтобы гарантировать немедленный доступ к электронным историям болезней в экстренном случае независимо от используемой модели защиты. Хотя такие DRM/ERM системы очень надежны относительно обеспечения лишь инициатора запросов, выполняющего все необходимые права доступа, доступом к данным медико-санитарной помощи, такие системы не способны к обработке экстренных ситуаций, которые требуют исключения в обычном режиме работы систем, например, когда медицинский работник нуждается в немедленном доступе к медицинским данным.

WO 2008/008009 Al раскрывает управление медицинской информацией в системе концентратора информации о пациентах. Документ описывает систему информации о пациентах, используемую в системе здравоохранения, для управления документами данных пациента, имеющего имплантированное медицинское устройство (IMD). Переносной не имплантированный блок имеет способность осуществления связи с IMD. Получение списка документов от системы для отображения на экране осуществляющего связь блока или передачи внешнему запрашивающему блоку делается зависимым от действенности связи при наличии IMD и не имплантированного блока.

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

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

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

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

- доверенный агент генерирует журнал регистрации, содержащий данные, относящиеся к запросу или инициатору запросов или к тому и к другому, и

- обеспечивают инициатора запросов доступом к данным медико-санитарной помощи.

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

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

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

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

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

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

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

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

В одном варианте осуществления способ дополнительно содержит представление журнала регистрации серверу для анализа.

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

В одном варианте осуществления лицензия содержит ключ дешифровки вместе с ассоциированными правилами лицензии для осуществления доступа к данным медико-санитарной помощи, и инициатор запросов является клиентским приложением управления цифровым правами (DRM) или клиентским приложением управления корпоративными правами (ERM), при этом этап обеспечения клиентского приложения DRM или ERM доступом к данным медико-санитарной помощи представляет собой пересылку ключа дешифровки лицензии вместе с ассоциированными правилами лицензии к клиентскому приложению DRM или ERM.

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

В одном варианте осуществления лицензия прикреплена к защищенным медицинским данным.

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

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

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

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

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

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

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

Согласно еще одному аспекту, настоящее изобретение относится к серверу, содержащему приемник для приема журнала регистрации от упомянутого доверенного агента и память для хранения принятого журнала регистрации,

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

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

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

Краткое описание чертежей

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

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

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

Фиг. 3 показывает зашифрованный файл и лицензию для DICOM (цифровое изображение и связь в Медицине) - совместимая DRM система,

Фиг. 4 показывает улучшенную DRM инфраструктуру с поддержкой экстренного доступа, состоящей из старой DRM инфраструктуры и новой инфраструктуры экстренной ситуации,

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

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

Описание вариантов осуществления

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

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

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

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

В одном варианте осуществления журнал регистрации впоследствии представляется серверу (S3) 105, например, центральный сервер в больнице, для выполнения анализа.

В заключение, инициатору запросов предоставляют доступ к данным медико-санитарной помощи (S4) 107.

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

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

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

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

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

Инициатор 220 запросов содержит генератор (R_G) 221 запросов, который генерирует запрос 223 на осуществление доступа к данным медико-санитарной помощи, и который дополнительно выполнен с возможностью генерирования тега 222 данных, сигнализирующего, что сгенерированный запрос 223 является экстренным запросом. Сгенерированный запрос 223 и тег 222 данных затем пересылаются или передаются через канал 224 связи, который может быть проводным или беспроводным, к доверенному агент 200.

Доверенный агент 200 содержит приемник (R) 203, генератор (L G) 202 журнала регистрации и процессор (P) 201. Приемник (R) 203 выполнен с возможностью приема запроса 220 от инициатора 220 запросов, запрашивающего доступ к данным медико-санитарной помощи. Генератор (L G) 202 журнала регистрации выполняется с возможностью генерирования журнала 204 регистрации, который, как обсуждалось ранее на Фиг. 1, содержит данные, относящиеся к запросу или инициатору запросов или обоим. Процессор выполняется с возможностью обработки принятого запроса 223. Обработка включает в себя осуществление связи с сервером 210, то есть осуществление связи с сервером, например, запрашивая ключ дешифровки для осуществления доступа к данным медико-санитарной помощи. Обработка включает в себя пересылку запрошенного ключа дешифровки инициатору запросов, или пересылку данных о медико-санитарной помощи в дешифрованной форме инициатору запросов (см. обсуждение на Фиг. 1).

Сервер 210, как изображено здесь, осуществляет связь с доверенным агентом 200 через канал 205 связи, который может быть проводным каналом связи или беспроводным. Сервер 210 содержит приемник (R) 211 для приема журнала 204 регистрации от доверенного агента 200 и память 212 для сохранения принятого журнала регистрации. Память 212 также имеет запомненные на ней данные о медико-санитарной помощи, или ключи дешифровки для осуществления доступа к данным медико-санитарной помощи, или ключ дешифровки лицензии, имеющий ассоциированные с ней правила лицензии, для осуществления доступа к данным медико-санитарной помощи, или комбинацию этого. Сервер дополнительно выполнен с возможностью управления множеством упомянутых доверенных агентов, при этом управление включает в себя, в ответ на прием упомянутого журнала регистрации от доверенных агентов, обеспечение доверенных агентов доступом к данным медико-санитарной помощи путем предоставления запрошенных ключей дешифровки. Это будет обсуждаться более подробно позже.

Фигура 3 показывает вариант осуществления согласно настоящему изобретению, изображающему каким образом настоящее изобретение может быть применено к DICOM (цифровое изображение и коммуникации в медицине).

DRM система гарантированно обеспечивает сквозную конфиденциальность медицинской информации и обеспечивает управление источником по назначению. DRM система для DICOM файлов, показанных на Фиг. 3, использует синтаксис криптографического сообщения и ослабленную версию профиля деидентификации DICOM, как раскрывается в «National Electric Manufacturers Association (Национальная ассоциация производителей электрооборудования) (NEMA), Digital Imaging and Communications in Medicine (стандарт цифрового изображения и коммуникаций в медицине) (DICOM), part 15 (часть 15): Security and system management profiles Annex E.1 (приложение E.1 о профилях управления системой и безопасностью), 2007», тем самым включены посредством ссылки. Атрибуты DICOM файла, которые должны быть защищены, таким образом, шифруются с помощью ключа шифрования контента. Затем вкладывается лицензия с материалом необходимого ключа. Поскольку это выполняется способом, при котором используются инструменты, обеспечиваемые стандартом, то по-прежнему гарантируется совместимость с предыдущими версиями. С точки зрения безопасности этот подход DRM представляет собой улучшение относительно управления распределением данных и конфиденциальностью различных пользователей медицинской сферы. Однако для того чтобы решение по обеспечению медицинской безопасности было одобрено медицинскими специалистами, обязательным является включение возможности экстренного доступа.

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

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

Другое решение для проблемы управления экстренным доступом заключается в не вставлении лицензии в данные в момент шифрования DRM. Однако, по осуществлению экстренного доступа, инициатор 220 запросов, который может быть поставщиком услуг по уходу за больным, связывается с соответствующим сервером 210 (например, сервер 210 лицензий) через доверенный агент 200 и запрашивает экстренную лицензию. Сервер 210 лицензий может реализовать функциональные характеристики доверенного агента 200, то есть некоторые или все функциональные характеристики доверенного агента 200 можно рассматривать как включенные в сервер 210 лицензий, или доверенный агент 200 и сервер 210 лицензий могут взаимодействовать, как изображено на Фиг. 2. Событие регистрируется сервером лицензий, и выдается временная лицензия.

Сценарий, изображенный на Фиг. 2, где доверенные агенты 200, ответственные за обработку экстренных ситуации для обеспечения конфиденциальности данных, могут быть развернуты параллельно DRM системе. Это графически изображается на Фиг. 4, показывающей улучшенную DRM инфраструктуру с поддержкой экстренного доступа, состоящей из старой DRM инфраструктуры 413 и новой инфраструктуры 400 экстренной ситуации.

Хотя Фиг. 4 показывает, каким образом может быть улучшена инфраструктура DRM с экстренным доступом, она не должна рассматриваться не только как ограниченная DICOM, но также и другими системами.

Новая инфраструктура 400 экстренной ситуации содержит упомянутый сервер 210 с Фиг. 2, именуемый здесь экстренным источником (E_A) 401 полномочий, и множество упомянутых доверенных агентов 200, именуемых здесь экстренными агентами (E_A_E1-n) 402-405. Экстренный источник (E_A) 401 полномочий независим от создателей и потребителей данных и может быть доверенным. В конечном счете, он является ответственным за проверку законности экстренных доступов. Источник полномочий управляет некоторыми компонентами, чтобы поддерживать этот процесс.

Экстренные агенты (E_A_E1-n) 402-405 связываются инициатором 406 запросов, когда они запрашивают экстренный доступ. Экстренные агенты (E_A_E1-n) 402-405 являются ответственными за предоставление доступа поставщикам услуг экстренной помощи и регистрацию тех событий. Они являются доверенными экстренным источником (E_A) 401 полномочий, например, через сертификацию. Для этой цели соответствие таких компонентов может быть проверено экстренным источником (E A) 401 полномочий (то есть соответствующий упомянутому серверу 210) прежде, чем принять это доверие. Экстренные агенты (E_A_E1-n) 402-405 (то есть соответствующие упомянутым доверенным агентам 200) могут быть установлены в больницах, где, например, разворачивается DRM система 413.

Экстренный источник (E_A) 401 полномочий может быть выполнен с возможностью генерирования новых пар Kpriv_Em(id) и Kpub_Em(id) экстренных ключей. Он передает секретный ключ Kpriv_Em(id), предпочтительно безлопастным образом, всем его экстренным агентам (E_A_E1-n) 402-405. Как только экстренный источник (E_A) 401 полномочий удостоверится, что этот новый секретный ключ был успешно распределен, он отправляет соответствующий открытый ключ Kpub_Em(id) серверам лицензий (L_S_1-n) 409-412, таким образом, чтобы они могли создать экстренные лицензии для защищенных данных.

Генерирование ключей экстренным источником (E_A) 401 полномочий может придерживаться различных политик; например, одна пара ключей на каждую больницу, по паре ключей в день и т.д. В качестве другой альтернативы, общий экстренный ключ может использоваться для всех данных на национальном уровне. Впрочем, все эти ключи должны быть известны для каждого экстренного агента (E_A_E1-n) 402-405 таким образом, чтобы обеспечивалась доступность данных, независимо от контактируемого экстренного агента или файла при осуществлении экстренного доступа. Важным является то, чтобы секретные ключи Kpriv_Em(id) оставались в пределах доверенной среды экстренной инфраструктуры. Конфиденциальность всех DRM-защищенных данных, содержащих экстренную лицензию на основе раскрытого секретного ключа, ставится под угрозу.

При шифровании исходного файла F DRM-сервером (Publ.) 408 публикаций, экстренная лицензия LF_Em вставляется в получаемый в результате файл. Он создается сервером лицензий, ответственным за DRM-защищенный файл, используя его осведомленность об экстренных открытых ключах Kpub_Em(id). Получающийся в результате зашифрованный DRM контейнер содержит исходные данные в зашифрованной форме.

Когда инициатор запросов, например, поставщик услуг экстренной помощи, запрашивает экстренный доступ для файла F, который он уже загрузил, он предпочтительно связывается с самым близким доступным экстренным агентом (E_A_E1-n) 402-405.

Вариант осуществления, показанный на Фиг. 4, фокусируется на DICOM. Таким образом, сообщения обмена определяются как новый класс пары объект-обслуживание (SOP) экстренного доступа DICOM.

Обычно, DICOM определяет набор служб, которые могут быть применены к определению информационного объекта (IOD) в классах пары объект-обслуживание (SOP). SOP класс может быть либо стандартизованным, либо составным, в зависимости от того, применяются ли они к стандартизованному или составному IOD. Стандартизованный IOD является определением информационного объекта, которое обычно представляет единственный объект в DICOM модели реального общества. Составной IOD является определением информационного объекта, которое представляет части нескольких объектов, включенных в DICOM модель реального общества. SOAP класс идентифицируется уникальным идентификатором: UID SOP класса. Для того чтобы описать службу в пределах SOP класса, сначала необходимо назначить роли каждому из участников. Равноправный участник может быть либо пользователем класса обслуживания (SCU; то есть клиент), либо поставщиком услуг класса обслуживания (SCP; то есть сервер), или принимает обе роли одновременно. Описание службы также определяет команды, которые могут быть применены к заинтересованному IOD. Существующие типы команды включают в себя C-STORE, C-FIND, C-MOVE, C-GET, C-CANCEL и C- ECHO.

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

Чтобы включать политики в DICOM файл, наборы данных зашифрованных атрибутов (то есть оболочки CMS) вставляются в DICOM файл. Также вводится новый атрибут: disciosureKey (ключ раскрытия). Он содержит симметричный криптографический ключ, который будет использоваться для защиты атрибутов. Следующий процесс происходит при шифровании:

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

оболочка CMS, содержащая зашифрованные версии атрибутов, за исключением disciosureKey, создается. Ее ключ шифрования документа шифруется при помощи ключа исходного атрибута disciosureKey.

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

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

Фигура 5 графически изображает протокол, где инициатор 406 запросов, который может рассматриваться как совместимый клиент (C_C) 406, запрашивает доступ к файлу F 501 путем отправки к экстренному агенту (E_A_E1-n) 402-405 экстренной лицензии (S1') 502, которая вставляется в F. В DICOM это может быть реализовано в качестве команды N-ACTION, содержащей экстренную лицензию. Как было упомянуто ранее, термин экстренный агент (E_A_E1-n) 402-405 является попросту вариантом осуществления доверенного агента 210 как изображено на Фиг. 2. Кроме того, как упоминалось ранее, экстренный источник (E_A) 401 полномочий может управлять одним или более множеством экстренных агентов (E_A_E1-n) 402-405, которые, помимо всего прочего, выполняют упомянутые операции регистрации в ответ на запросы инициаторами 406 запросов.

Ссылаясь снова на протокол, изображенный на Фиг. 5, после проверки того, что инициатор 406 (C_C) запросов является действительно совместимым клиентом, журнал регистрации генерируется для инициатора (C_C) 406 запросов (S2') 503. Экстренный источник (E_A) 401 полномочий (не показанный на Фиг. 5) дешифрует принятую экстренную лицензи