RU2530303C2 - Способ и система обработки данных медико-санитарной помощи - Google Patents
Способ и система обработки данных медико-санитарной помощи Download PDFInfo
- Publication number
- RU2530303C2 RU2530303C2 RU2010154666/08A RU2010154666A RU2530303C2 RU 2530303 C2 RU2530303 C2 RU 2530303C2 RU 2010154666/08 A RU2010154666/08 A RU 2010154666/08A RU 2010154666 A RU2010154666 A RU 2010154666A RU 2530303 C2 RU2530303 C2 RU 2530303C2
- Authority
- RU
- Russia
- Prior art keywords
- health care
- data
- access
- request
- care data
- Prior art date
Links
- 230000036541 health Effects 0.000 title claims abstract description 111
- 238000000034 method Methods 0.000 title claims abstract description 28
- 238000012545 processing Methods 0.000 title claims abstract description 16
- 239000003795 chemical substances by application Substances 0.000 claims abstract description 76
- 239000003999 initiator Substances 0.000 claims abstract description 21
- 230000011664 signaling Effects 0.000 claims abstract description 8
- 230000008569 process Effects 0.000 claims description 7
- 230000004044 response Effects 0.000 claims description 4
- 238000004458 analytical method Methods 0.000 claims description 3
- 239000003814 drug Substances 0.000 abstract description 3
- 239000000126 substance Substances 0.000 abstract 1
- 238000004891 communication Methods 0.000 description 10
- 238000013475 authorization Methods 0.000 description 4
- 239000002131 composite material Substances 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 229940079593 drug Drugs 0.000 description 2
- 238000003384 imaging method Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 239000000344 soap Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/107—License processing; Key processing
- G06F21/1075—Editing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Software Systems (AREA)
- Medical Informatics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Public Health (AREA)
- Primary Health Care (AREA)
- Epidemiology (AREA)
- Databases & Information Systems (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Storage Device Security (AREA)
- Measuring And Recording Apparatus For Diagnosis (AREA)
Abstract
Изобретение относится к области обработки данных медико-санитарной помощи. Техническим результатом является обеспечение безопасного и гибкого способа обработки данных медико-санитарной помощи, предоставляющего исключение в обычном режиме работы системы, когда поставщик услуг экстренной помощи нуждается в немедленном доступе к данным медико-санитарной помощи и когда недоступны регулярные права, которые предоставляют доступ поставщику услуг медицинской помощи к данным медико-санитарной помощи. Способ обработки данных медико-санитарной помощи доверенным агентом, обладающим или имеющим доступ к ключам дешифровки для осуществления доступа к данным медико-санитарной помощи, характеризуется тем, что принимается запрос от инициатора запросов, запрашивающего осуществление доступа к данным медико-санитарной помощи, содержащий тег данных, сигнализирующий, что принятый запрос является экстренным запросом. Генерируется журнал регистрации, содержащий данные, относящиеся к запросу или инициатору запросов или к тому или другому. Предоставляют инициатору запросов доступ к данным медико-санитарной помощи. 3 н. и 6 з.п. ф-лы, 6 ил.
Description
Область техники, к которой относится изобретение
Настоящее изобретение относится к способу обработки данных медико-санитарной помощи доверенным агентом, обладающим или имеющим доступ к ключам дешифровки для осуществления доступа к данным медико-санитарной помощи. Настоящее изобретение дополнительно относится к доверенному агенту, выполненному с возможностью обработки данных медико-санитарной помощи, причем доверенный агент обладает или имеет доступ к ключам дешифровки для осуществления доступа к данным медико-санитарной помощи. Настоящее изобретение дополнительно относится к инициатору запросов, содержащему генератор запросов для генерирования запроса на осуществление доступа к данным медико-санитарной помощи, обработанных упомянутым доверенным агентом, и к серверу, содержащему приемник для приема журнала регистрации от упомянутого доверенного агента.
Уровень техники
Ожидается, что усовершенствования в информационных и коммуникационных технологиях принесут большую пользу в области здравоохранения: введение взаимодействующих систем электронной медицинской записи (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.
В одном варианте осуществления данные медико-санитарной помощи защищены при помощи ключа документа, и лицензия содержит ключ документа, зашифрованный с помощью экстренного ключа KEm, к защищенным данным медико-санитарной помощи, при этом экстренный ключ KEm затем распространяется ко всем доверенным агентам.
В одном варианте осуществления лицензия прикреплена к защищенным медицинским данным.
В одном варианте осуществления, экстренные лицензии и защищенные данные медико-санитарной помощи пересылаются к DRM или ERM, причем при экстренном запросе, DRM или ERM дополнительно обеспечиваются экстренным ключом KEm, который выполнен с возможностью дешифровки ключа дешифровки документа.
Согласно другому аспекту настоящее изобретение относится к компьютерному программному продукту для предписания блоку обработки выполнять вышеупомянутые этапы способа, когда продукт запущен на компьютере.
Согласно еще другому аспекту настоящее изобретение относится к доверенному агенту, выполненному с возможностью обработки данных медико-санитарной помощи, при этом доверенный агент обладает или имеет доступ к ключам дешифровки для осуществления доступ к данным медико-санитарной помощи, содержащий:
приемник для приема запроса от инициатора запросов, запрашивающего осуществление доступа к данным медико-санитарной помощи, причем принятый запрос содержит тег данных, сигнализирующий, что принятый запрос является экстренным запросом,
генератор журнала регистрации для генерирования журнала регистраций, содержащего данные, относящиеся к запросу или инициатору запросов или к тому и к другому, и
процессор для обработки принятого запроса, причем обработка приводит в результате к обеспечению инициатора запросов доступом к данным медико-санитарной помощи.
Согласно еще одному аспекту, настоящее изобретение относится к инициатору запросов, содержащему генератор запросов для генерирования запроса на осуществление доступа к данным медико-санитарной помощи, обработанным упомянутым доверенным агентом, причем генератор запросов дополнительно выполнен с возможностью генерирования тега данных, сигнализирующего, что сгенерированный запрос является экстренным запросом.
Согласно еще одному аспекту, настоящее изобретение относится к серверу, содержащему приемник для приема журнала регистрации от упомянутого доверенного агента и память для хранения принятого журнала регистрации,
причем память дополнительно имеет сохраненные данные медико-санитарной помощи, или ключи дешифровки для осуществления доступа к данным медико-санитарной помощи, или лицензию, содержащую ключ дешифровки вместе с ассоциированными правилами лицензии для осуществления доступа к данным медико-санитарной помощи, или их комбинацию,
при этом доверенный сервер выполнен с возможностью обеспечения функционирования, обеспечения и управления множеством упомянутых доверенных агентов, при этом обеспечение функционирования включает в себя, в ответ на прием упомянутого журнала регистрации от доверенных агентов, предоставление доверенным агентам доступа к данным медико-санитарной помощи путем предоставления запрошенных ключей дешифровки.
Каждый из аспектов настоящего изобретения могут быть объединены с любым из других аспектов. Эти и другие аспекты изобретения станут очевидными из и будут разъяснены со ссылкой на варианты осуществления, описанные в дальнейшем.
Краткое описание чертежей
Варианты осуществления изобретения будут описаны лишь в качестве примера со ссылкой на чертежи, на которых
Фиг. 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 данные шифруются, и сервер лицензий выдает лицензии (в том числе, права использования на контент) запрашивающим пользователям, если они имеют достаточно прав для осуществления доступа к данным. Таким образом, экстренный доступ является сложным для обработки в том смысле, что он представляет исключение нормального режима работы системы. Поставщику услуг по неотложной помощи предпочтительно должна быть предоставлена лицензия для декодирования данных, к которым он желает осуществить доступ, даже если он не имеет никакого обычного права на них. Следовательно, законность такого доступа должна быть доказана позже, чтобы в конечном итоге гарантировать конфиденциальность данных. И затем требуется регистрация в журнале экстренного доступа.
Как обсуждалось ранее, решение для проблемы управления экстренным доступом заключается в выдаче экстренных лицензии и регистрации таких событий. Это может быть выполнено путем распределения экстренного ключа KEm ко всем доверенным агентам 200 (см. Фиг. 2) сервером 210 лицензий (см. Фиг. 2). Экстренная лицензия, состоящая из шифрования ключа контента с помощью KEm, может быть вставлена с каждыми недавно защищенными данными медико-санитарной помощи. По осуществлению экстренного доступа, доверенный агент 200 регистрирует событие, как обсуждалось ранее, и дешифрует данные с помощью KEm, даже если инициатор запросов, например, запрашивающий пользователь, не получал одобрения, например, от сервера лицензий.
Другое решение для проблемы управления экстренным доступом заключается в не вставлении лицензии в данные в момент шифрования 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 полномочий может быть выполнен с возможностью генерирования новых пар KprivEm(id) и KpubEm(id) экстренных ключей. Он передает секретный ключ KprivEm(id), предпочтительно безлопастным образом, всем его экстренным агентам (E_A_E1-n) 402-405. Как только экстренный источник (E_A) 401 полномочий удостоверится, что этот новый секретный ключ был успешно распределен, он отправляет соответствующий открытый ключ KpubEm(id) серверам лицензий (L_S_1-n) 409-412, таким образом, чтобы они могли создать экстренные лицензии для защищенных данных.
Генерирование ключей экстренным источником (E_A) 401 полномочий может придерживаться различных политик; например, одна пара ключей на каждую больницу, по паре ключей в день и т.д. В качестве другой альтернативы, общий экстренный ключ может использоваться для всех данных на национальном уровне. Впрочем, все эти ключи должны быть известны для каждого экстренного агента (E_A_E1-n) 402-405 таким образом, чтобы обеспечивалась доступность данных, независимо от контактируемого экстренного агента или файла при осуществлении экстренного доступа. Важным является то, чтобы секретные ключи KprivEm(id) оставались в пределах доверенной среды экстренной инфраструктуры. Конфиденциальность всех DRM-защищенных данных, содержащих экстренную лицензию на основе раскрытого секретного ключа, ставится под угрозу.
При шифровании исходного файла F DRM-сервером (Publ.) 408 публикаций, экстренная лицензия LFEm вставляется в получаемый в результате файл. Он создается сервером лицензий, ответственным за DRM-защищенный файл, используя его осведомленность об экстренных открытых ключах KpubEm(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) дешифрует принятую экстренную лицензию с помощью надлежащего секретного ключа. Восстановив ключ-контент, создается новая временная лицензия, которая предназначается для использования только инициатором (C_C) 406 запросов, с использованием открытого ключа инициатора запросов.
Затем, новая временная лицензия (S3') 504 посылается инициатору (C_C) 406 запросов. В DICOM, это может быть реализовано как команда N-E VENT-REPORT, содержащая временную лицензию, которая, таким образом, представляет собой не что иное, как DICOM лицензию как изображено на Фиг. 3.
Инициатор (C_C) 406 запросов теперь способен просмотреть контент файла F (S4') 505, дешифруя временную лицензию с помощью своего секретного ключа.
Вполне возможно, что стороны в медицинской сфере будут использовать несовместимых инициаторов запросов. Следовательно, процедура экстренной ситуации должна предпочтительно быть адаптирована таким образом, чтобы эти несовместимые инициаторы запросов могли все же осуществлять доступ к данным в контексте экстренной ситуации, не имея возможности изменять общую безопасность системы. Предложенное решение обеспечивает предоставления полного доступа к запрошенным данным.
В таком случае, регистрация экстренного доступа является еще более важным действием, поскольку эти инициаторы запросов могли бы разгласить полученные данные без каких-либо ограничений. По этой причине, также может быть предпочтительным включать «водяной знак» для дальнейшего судебного отслеживания.
Следующее дополнение может быть использовано для предоставления доступа к данным несовместимым равноправным участникам при нормальной (то есть не обязательно экстренной) работе.
Фигура 6 показывает обмены между инициатором запросов, который является несовместимым клиентом (N_C_C) 601, осуществляющим доступ к файлу F 501 в контексте экстренной ситуации, и самым близким доступным экстренным агентом (E_A_E1-n) 402-405. Несовместимый клиент (N_C_C) 601 отправляет файл F наряду с его вставленной экстренной лицензией (S1") 602 к экстренному агенту (E_A_E1-n) 402-405. Экстренный агент (E_A_En) 402-405 использует свою осведомленность обо всех частных экстренных ключах для дешифрования экстренной лицензии (S2") 603 и, следовательно, восстановления контента ключа контента. Таким образом, он может затем дешифровать файл F и получить исходный файл. Экстренный доступ регистрируется, и дешифрованная версия файла F отправляется (S3") 604 несовместимому клиенту (N_C_C) 601, который может затем свободно осуществить доступ к исходному файлу (S4") 605.
Определенные характерные подробности раскрытого варианта осуществления формулируются для целей объяснения, а не ограничения, чтобы обеспечить четкое и полное понимание настоящего изобретения. Однако специалистам в данной области техники следует понимать, что настоящее изобретение могло бы быть реализовано в других вариантах осуществления, которые не соответствуют точно подробностям, сформулированным здесь, не отступая в значительной степени от существа и объема этого раскрытия. Более того, в этом контексте, и в целях краткости и ясности, подробные описания известных устройств, схем и методологий были опущены, чтобы избежать ненужной подробности и возможной путаницы.
Не смотря на то что в пункты формулы изобретения включены ссылочные символы, включение ссылочных символов выполнено лишь в целях ясности и не должно быть истолковано как ограничение объема притязаний.
Claims (9)
1. Способ обработки данных медико-санитарной помощи доверенным агентом, обладающим или имеющим доступ к ключам дешифровки для осуществления доступа к данным медико-санитарной помощи, характеризующимся тем, что лицензия содержит ключ дешифровки вместе с ассоциированными правилами лицензии для осуществления доступа к данным медико-санитарной помощи, и инициатор запросов представляет собой клиентское приложение управления цифровыми правами (DRM) или клиентское приложение управления корпоративными правами (ERM), при этом этап обеспечения клиентского приложения DRM или ERM доступом к данным медико-санитарной помощи заключается в пересылке ключа дешифровки лицензии вместе с ассоциированными правилами лицензии к клиентскому приложению DRM или ERM, данные медико-санитарной помощи защищены с помощью ключа документа, и лицензия содержит ключ документа, зашифрованный при помощи экстренного ключа KEm к защищенным данным медико-санитарной помощи, при этом способ состоит в том, что
- принимают запрос от инициатора (101) запросов, запрашивающего осуществление доступа к данным медико-санитарной помощи, причем принятый запрос содержит тег данных, сигнализирующий, что принятый запрос является экстренным запросом,
- доверенный агент генерирует журнал (103) регистрации, содержащий данные, относящиеся к запросу или инициатору запросов или к тому и к другому,
- обеспечивают инициатора запросов доступом к данным (107) медико-санитарной помощи и
- распространяют впоследствии экстренный ключ KEm всем доверенным агентам.
- принимают запрос от инициатора (101) запросов, запрашивающего осуществление доступа к данным медико-санитарной помощи, причем принятый запрос содержит тег данных, сигнализирующий, что принятый запрос является экстренным запросом,
- доверенный агент генерирует журнал (103) регистрации, содержащий данные, относящиеся к запросу или инициатору запросов или к тому и к другому,
- обеспечивают инициатора запросов доступом к данным (107) медико-санитарной помощи и
- распространяют впоследствии экстренный ключ KEm всем доверенным агентам.
2. Способ по п.1, в котором запрос, принятый от инициатора запросов, включает в себя запрос ключа дешифровки для осуществления доступа к данным медико-санитарной помощи, при этом этап обеспечения инициатора запросов доступом к данным медико-санитарной помощи заключается в пересылке запрошенного ключа дешифровки инициатору запросов.
3. Способ по п.1, в котором запрос, принятый от инициатора запросов, содержит упомянутые запрошенные данные медико-санитарной помощи в зашифрованной форме, при этом этап обеспечения инициатора запросов доступом к данным медико-санитарной помощи заключается в пересылке данных медико-санитарной помощи в дешифрованной форме инициатору запросов.
4. Способ по п.1, в котором вслед за принятым запросом агент получает данные медико-санитарной помощи в зашифрованной форме от сервера и дешифрует данные медико-санитарной помощи, причем этап обеспечения инициатора запросов доступом к данным медико-санитарной помощи заключается в пересылке дешифрованных данных медико-санитарной помощи инициатору запросов.
5. Способ по п.1, дополнительно содержащий представление журнала регистрации серверу (105) для анализа.
6. Способ по п.1, в котором лицензия прикреплена к защищенным данным истории болезни.
7. Способ по п.1, в котором экстренная лицензия и защищенные данные медико-санитарной помощи пересылаются к DRM или ERM, причем при экстренном запросе DRM или ERM дополнительно обеспечиваются экстренным ключом KEm, который выполнен с возможностью дешифровки ключа дешифровки документа.
8. Доверенный агент (200), выполненный с возможностью обработки данных медико-санитарной помощи, при этом доверенный агент обладает или имеет доступ к ключам дешифровки для осуществления доступа к данным медико-санитарной помощи, характеризующимся тем, что лицензия содержит ключ дешифровки вместе с ассоциированными правилами лицензии для осуществления доступа к данным медико-санитарной помощи, и инициатор запросов представляет собой клиентское приложение управления цифровыми правами (DRM) или клиентское приложение управления корпоративными правами (ERM), при этом этап обеспечения клиентского приложения DRM или ERM доступом к данным медико-санитарной помощи заключается в пересылке ключа дешифровки лицензии вместе с ассоциированными правилами лицензии к клиентскому приложению DRM или ERM, данные медико-санитарной помощи защищены с помощью ключа документа, и лицензия содержит ключ документа, зашифрованный при помощи экстренного ключа KEm к защищенным данным медико-санитарной помощи, при этом доверенный агент содержит:
- приемник (203) для приема запроса от инициатора запросов, запрашивающего осуществление доступа к данным медико-санитарной помощи, причем запрос содержит тег (222) данных, сигнализирующий, что запрос (223) является экстренным запросом,
- генератор (220) журнала регистрации для генерирования журнала регистрации, содержащего данные, относящиеся к запросу или инициатору запросов или к тому и другому, и
- процессор (201) для обработки принятого запроса, причем обработка приводит в результате к обеспечению инициатора запросов доступом к данным медико-санитарной помощи, и доверенный агент сконфигурирован для распространения впоследствии экстренного ключа KEm всем доверенным агентам.
- приемник (203) для приема запроса от инициатора запросов, запрашивающего осуществление доступа к данным медико-санитарной помощи, причем запрос содержит тег (222) данных, сигнализирующий, что запрос (223) является экстренным запросом,
- генератор (220) журнала регистрации для генерирования журнала регистрации, содержащего данные, относящиеся к запросу или инициатору запросов или к тому и другому, и
- процессор (201) для обработки принятого запроса, причем обработка приводит в результате к обеспечению инициатора запросов доступом к данным медико-санитарной помощи, и доверенный агент сконфигурирован для распространения впоследствии экстренного ключа KEm всем доверенным агентам.
9. Сервер (210), содержащий приемник (211) для приема журнала (204) регистрации от доверенного агента (200) по п.8 и память (212) для хранения принятого журнала регистрации,
причем память (212) дополнительно имеет сохраненные данные медико-санитарной помощи, или ключи дешифровки для осуществления доступа к данным медико-санитарной помощи, или ключ дешифровки лицензии, имеющий ассоциированные с ним правила лицензии для осуществления доступа к данным медико-санитарной помощи, или их комбинацию,
причем сервер (210) выполнен с возможностью обеспечения функционирования, обеспечения и управления множеством упомянутых доверенных агентов (200), при этом обеспечение функционирования включает в себя в ответ на прием упомянутого журнала регистрации от доверенных агентов обеспечение доверенных агентов доступом к данным медико-санитарной помощи путем предоставления запрошенных ключей дешифровки.
причем память (212) дополнительно имеет сохраненные данные медико-санитарной помощи, или ключи дешифровки для осуществления доступа к данным медико-санитарной помощи, или ключ дешифровки лицензии, имеющий ассоциированные с ним правила лицензии для осуществления доступа к данным медико-санитарной помощи, или их комбинацию,
причем сервер (210) выполнен с возможностью обеспечения функционирования, обеспечения и управления множеством упомянутых доверенных агентов (200), при этом обеспечение функционирования включает в себя в ответ на прием упомянутого журнала регистрации от доверенных агентов обеспечение доверенных агентов доступом к данным медико-санитарной помощи путем предоставления запрошенных ключей дешифровки.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP08157571.4 | 2008-06-04 | ||
| EP08157571 | 2008-06-04 | ||
| PCT/IB2009/052263 WO2009147598A1 (en) | 2008-06-04 | 2009-05-29 | Method and a system of healthcare data handling |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| RU2010154666A RU2010154666A (ru) | 2012-07-20 |
| RU2530303C2 true RU2530303C2 (ru) | 2014-10-10 |
Family
ID=40872319
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2010154666/08A RU2530303C2 (ru) | 2008-06-04 | 2009-05-29 | Способ и система обработки данных медико-санитарной помощи |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US9881128B2 (ru) |
| EP (1) | EP2291784B1 (ru) |
| JP (1) | JP5711117B2 (ru) |
| KR (1) | KR101698555B1 (ru) |
| CN (1) | CN102057379B (ru) |
| BR (1) | BRPI0909975A2 (ru) |
| MX (1) | MX2010013189A (ru) |
| RU (1) | RU2530303C2 (ru) |
| WO (1) | WO2009147598A1 (ru) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101468379B1 (ko) * | 2012-06-29 | 2014-12-02 | 인텔렉추얼디스커버리 주식회사 | 암호화 데이터의 복호화를 위한 접근 방법 |
| US20140108046A1 (en) * | 2012-10-12 | 2014-04-17 | Ruben Gerardo Echeverria Cabrera | Sharing healthcare information on private collaborative networks |
| DE102016207145A1 (de) * | 2016-04-27 | 2017-11-02 | Siemens Healthcare Gmbh | Steuersystem für eine Verarbeitung von Bilddaten |
| EP3480774A4 (en) * | 2016-06-30 | 2019-11-27 | Olympus Corporation | MEDICAL INFORMATION PROVIDING SYSTEM AND METHOD FOR PROVIDING MEDICAL INFORMATION |
| US11908553B2 (en) | 2019-02-11 | 2024-02-20 | Rapidsos, Inc. | Apparatus and method for emergency response data acquisition and retrieval |
| WO2023154912A1 (en) * | 2022-02-11 | 2023-08-17 | Jigneshkumar Patel | System for tracking patient referrals |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2171492C1 (ru) * | 2000-06-26 | 2001-07-27 | Хазанов Михаил Евгеньевич | Способ предоставления данных, относящихся к пациентам медицинского учреждения |
| RU65669U1 (ru) * | 2007-01-09 | 2007-08-10 | Наталия Алексеевна Фурсенко | Централизованная модель муниципального центра скорой медицинской помощи |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09282393A (ja) | 1996-04-12 | 1997-10-31 | Hitachi Ltd | 保健医療カードとオンラインデータベースの連携方法 |
| US5995965A (en) | 1996-11-18 | 1999-11-30 | Humetrix, Inc. | System and method for remotely accessing user data records |
| AU7745000A (en) * | 1999-09-30 | 2001-04-30 | United States Postal Service | Systems and methods for authenticating an electronic message |
| JP2001338058A (ja) * | 2000-05-30 | 2001-12-07 | Nippon Telegr & Teleph Corp <Ntt> | 救急医療支援サービスセンタおよび救急医療支援サービスプログラムを記録した記録媒体 |
| AU7182701A (en) | 2000-07-06 | 2002-01-21 | David Paul Felsher | Information record infrastructure, system and method |
| JP2002041359A (ja) * | 2000-07-26 | 2002-02-08 | Nomura Holding Inc | ログ記録装置、許可データ書き込み装置、ログ記録方法、許可データ書き込み方法および記録媒体 |
| WO2002021389A1 (en) * | 2000-09-07 | 2002-03-14 | United States Postal Service | Occupational safety system and method |
| US20020120472A1 (en) * | 2000-12-22 | 2002-08-29 | Dvorak Carl D. | System and method for integration of health care records |
| US7181017B1 (en) * | 2001-03-23 | 2007-02-20 | David Felsher | System and method for secure three-party communications |
| US7103776B1 (en) * | 2002-01-31 | 2006-09-05 | Acuson | Emergency logon method |
| JP2004054817A (ja) * | 2002-07-24 | 2004-02-19 | Mitsui Sumitomo Insurance Co Ltd | 健康情報管理サーバ及びプログラム |
| JP2004229128A (ja) * | 2003-01-24 | 2004-08-12 | Sony Corp | 暗号データ配信システム、および情報処理装置、情報処理方法、並びにコンピュータ・プログラム |
| GB0309182D0 (en) | 2003-04-23 | 2003-05-28 | Hewlett Packard Development Co | Security method and apparatus using biometric data |
| US7508941B1 (en) * | 2003-07-22 | 2009-03-24 | Cisco Technology, Inc. | Methods and apparatus for use in surveillance systems |
| US20050216314A1 (en) * | 2004-03-26 | 2005-09-29 | Andrew Secor | System supporting exchange of medical data and images between different executable applications |
| US7865735B2 (en) * | 2004-10-19 | 2011-01-04 | George Yiachos | Method and apparatus for managing personal medical information in a secure manner |
| ITTO20050076A1 (it) | 2005-02-10 | 2006-08-11 | Vitop Moulding Srl | Rubinetto erogatore per contenitore elastici per liquidi e applicazioni asettiche |
| US20070027715A1 (en) | 2005-06-13 | 2007-02-01 | Medcommons, Inc. | Private health information interchange and related systems, methods, and devices |
| JP2009512096A (ja) * | 2005-10-18 | 2009-03-19 | インタートラスト テクノロジーズ コーポレイション | デジタル著作権管理エンジンのシステムおよび方法 |
| JP2007241914A (ja) * | 2006-03-13 | 2007-09-20 | Nec Corp | 救急受付・搬送時における個人医療情報照会システム，方法，救急受付センターサーバおよびプログラム |
| US8015032B2 (en) | 2006-05-16 | 2011-09-06 | General Electric Company | Broadcasting medical image objects with digital rights management |
| JP5137474B2 (ja) * | 2006-06-23 | 2013-02-06 | 株式会社半導体エネルギー研究所 | 個人情報管理システム及び管理システム |
| EP2043731A4 (en) | 2006-07-13 | 2010-07-21 | St Jude Medical | MEDICAL INFORMATION MANAGEMENT IN A PATIENT INFORMATION HUD SYSTEM |
-
2009
- 2009-05-29 EP EP09757949.4A patent/EP2291784B1/en active Active
- 2009-05-29 US US12/993,870 patent/US9881128B2/en active Active
- 2009-05-29 MX MX2010013189A patent/MX2010013189A/es active IP Right Grant
- 2009-05-29 CN CN200980120695.4A patent/CN102057379B/zh active Active
- 2009-05-29 BR BRPI0909975A patent/BRPI0909975A2/pt not_active IP Right Cessation
- 2009-05-29 JP JP2011512253A patent/JP5711117B2/ja active Active
- 2009-05-29 WO PCT/IB2009/052263 patent/WO2009147598A1/en active Application Filing
- 2009-05-29 RU RU2010154666/08A patent/RU2530303C2/ru active
- 2009-05-29 KR KR1020117000055A patent/KR101698555B1/ko active IP Right Grant
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2171492C1 (ru) * | 2000-06-26 | 2001-07-27 | Хазанов Михаил Евгеньевич | Способ предоставления данных, относящихся к пациентам медицинского учреждения |
| RU65669U1 (ru) * | 2007-01-09 | 2007-08-10 | Наталия Алексеевна Фурсенко | Централизованная модель муниципального центра скорой медицинской помощи |
Also Published As
| Publication number | Publication date |
|---|---|
| US9881128B2 (en) | 2018-01-30 |
| EP2291784A1 (en) | 2011-03-09 |
| MX2010013189A (es) | 2010-12-20 |
| KR20110038013A (ko) | 2011-04-13 |
| WO2009147598A1 (en) | 2009-12-10 |
| KR101698555B1 (ko) | 2017-01-20 |
| EP2291784B1 (en) | 2019-12-04 |
| JP2011524564A (ja) | 2011-09-01 |
| BRPI0909975A2 (pt) | 2015-10-20 |
| CN102057379A (zh) | 2011-05-11 |
| CN102057379B (zh) | 2015-11-25 |
| JP5711117B2 (ja) | 2015-04-30 |
| US20110066846A1 (en) | 2011-03-17 |
| RU2010154666A (ru) | 2012-07-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Fabian et al. | Collaborative and secure sharing of healthcare data in multi-clouds | |
| KR100971854B1 (ko) | 보안 서버 키 동작을 제공하기 위한 시스템 및 방법 | |
| RU2344469C2 (ru) | Публикация цифрового содержания в определенном пространстве, таком, как организация, в соответствии с системой цифрового управления правами (цуп) | |
| CN101065768B (zh) | 分布网络中的数字权利管理 | |
| US8613102B2 (en) | Method and system for providing document retention using cryptography | |
| JP4750352B2 (ja) | デジタルコンテンツに対応するデジタルライセンスを取得する方法 | |
| US7849512B2 (en) | Method and system to create secure virtual project room | |
| US20140006512A1 (en) | Methods for Exchanging User Profile, Profile Mediator Device, Agents, Computer Programs and Computer Program Products | |
| EP1457860A1 (en) | Publishing digital content within a defined universe such as an organization in accordance with a digital rights management (DRM) system | |
| KR101696447B1 (ko) | 디지털 콘텐트를 관리하기 위한 방법 및 디바이스 | |
| JP2016513840A (ja) | データセキュリティを保護するための方法、サーバ、ホスト、およびシステム | |
| JP2009526322A (ja) | 変化識別子を使用するセキュアなデジタル・コンテンツ管理 | |
| RU2530303C2 (ru) | Способ и система обработки данных медико-санитарной помощи | |
| CN102271124A (zh) | 数据处理设备和数据处理方法 | |
| KR20230041971A (ko) | 분산적 컴퓨터 네트워크 상에서 안전한 데이터 전송을 위한 방법, 장치 및 컴퓨터 판독가능 매체 | |
| WO2022001683A1 (en) | Database access control service in networks | |
| Garcia et al. | Blockchain-aided and privacy-preserving data governance in multi-stakeholder applications | |
| Thummavet et al. | Privacy-preserving emergency access control for personal health records. | |
| JP4437310B2 (ja) | 公衆ネットワークを用いて専用仮想ネットワークを生成する方法 | |
| US7457964B2 (en) | Trusted path for transmitting content thereon | |
| US20230177209A1 (en) | Distributed Communication Network | |
| EP4322470A1 (en) | Data encryption system and method | |
| JP4125454B2 (ja) | オブジェクト連携装置 | |
| EP1544705A1 (en) | Method for software protection | |
| Cho et al. | Home Network Framework Based on OSGi Service Platform Using SSL Component Bundle |