專利名稱：保健數(shù)據(jù)處理的方法和系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及一種通過可信代理進行保健數(shù)據(jù)處理的方法，該可信代理擁有或可以 使用用于訪問保健數(shù)據(jù)的解密密鑰。本發(fā)明還涉及一種適于處理保健數(shù)據(jù)的可信代理，其 中所述可信代理擁有或可以使用用于訪問保健數(shù)據(jù)的解密密鑰。本發(fā)明還涉及一種包括 請求發(fā)生器的請求者，其中請求發(fā)生器用于生成訪問由所述可信代理處理的保健數(shù)據(jù)的請 求；以及涉及一種包括接收器的服務器，該接收器用于從所述可信代理接收日志。
背景技術：
在信息和通信技術方面的進步被預期在保健領域帶來巨大益處可共同操作的電 子健康記錄(HER)系統(tǒng)的引入可以減少保健系統(tǒng)的成本并增強治療的整體質(zhì)量，而遠程患 者管理(RPM)服務將限制患者停留在醫(yī)院中的時間。然而，迄今為止，EHR和RPM在相當小 的規(guī)模上使用。除了關于不同系統(tǒng)的整合問題和邏輯問題之外，關于信息安全和隱私的關 注是缺乏部署的系統(tǒng)的主要原因。例如，EHR系統(tǒng)正面臨它們必須遵守的嚴格的安全和隱 私規(guī)則(比如EU規(guī)程95/46或美國的HIPAA)?，F(xiàn)代保健通信架構傾向于開放的、互連的環(huán)境敏感的患者記錄不再存在于保 健提供者內(nèi)部物理隔離的主機上(其中可以采取物理安全措施來保護所述數(shù)據(jù)和所述系 統(tǒng))，相反，患者文件被保持在數(shù)據(jù)被外包到的環(huán)境中或在部分地不可信的服務器上被處理 以便允許供家庭醫(yī)生、醫(yī)學專家以及甚至非醫(yī)護提供者分散訪問。當前采用的以服務器為 中心保護模型(其將數(shù)據(jù)鎖定在數(shù)據(jù)庫服務器中并且使用傳統(tǒng)的訪問控制模型來允許訪 問數(shù)據(jù))不能有效地應付新保健基礎設施的要求。為了允許在不同的保健提供者之間或與外部參與方共享記錄，可以采用有利于以 數(shù)據(jù)為中心保護的端到端安全技術數(shù)據(jù)被加密地保護并且允許被外包或者甚至在網(wǎng)絡上 自由散播。與其依靠不同的網(wǎng)絡提供機密性、完整性和真實性，倒不如在通信的端點處保護 數(shù)據(jù)。這可以通過應用權限管理技術-消費型電子設備領域中的數(shù)字權限管理(DRM)和商 業(yè)領域中的企業(yè)權限管理(ERM)來實現(xiàn)。在這種系統(tǒng)中，公布的DRM保護的數(shù)據(jù)被加密并 且許可證服務器僅僅在請求的用戶具有足夠的權限訪問所述數(shù)據(jù)的情況下才向其發(fā)行許 可證。然而，該技術沒有解決的特定問題是確保在緊急情況下立即訪問電子患者記錄而不 考慮所使用的保護模型。盡管這種DRM/ERM系統(tǒng)在關于僅僅向滿足所有必要的訪問權限的 請求者提供到保健數(shù)據(jù)的訪問方面非常可靠，但是這樣的系統(tǒng)不能處理在所述系統(tǒng)的正常 行為中需要豁免的緊急情況，例如其中保健提供者需要立即訪問醫(yī)學數(shù)據(jù)。

發(fā)明內(nèi)容
本發(fā)明的目的是通過提供一種處理保健數(shù)據(jù)的安全的但同時又靈活的方式來克 服上述缺陷，所述方式的意義在于它表示所述系統(tǒng)的正常行為中的豁免并且可以應付以下 情況其中例如緊急救護提供者(比如醫(yī)院)需要立即訪問保健數(shù)據(jù)，但是沒有可用的準許 所述救護提供者訪問所述保健數(shù)據(jù)的常規(guī)權限。4
根據(jù)一個方面，本發(fā)明涉及一種通過擁有或可以使用用于訪問保健數(shù)據(jù)的可信代 理來進行保健數(shù)據(jù)處理的方法，包括-從請求訪問保健數(shù)據(jù)的請求者接收請求，-生成包括與所述請求或所述請求者或二者相關的數(shù)據(jù)的日志，以及-向所述請求者提供對所述保健數(shù)據(jù)的訪問。因此，在任何時間，所述請求者可以訪問醫(yī)學數(shù)據(jù)，而同時有效地保護保健數(shù)據(jù)的 機密性。所述醫(yī)學數(shù)據(jù)被加密并且所述可信代理可以基于請求者的身份決定是否將允許訪 問(解密)。例如，所述訪問策略可以是醫(yī)學數(shù)據(jù)只能被保健提供者訪問。而且，訪問被 記錄，這使得訪問數(shù)據(jù)的保健提供者對他的行為負責。所述可信代理可以例如是來自可信 商家的物理設備或軟件應用并且可以具有標準接口。這使得多個商家能夠進行實施并且也 要求醫(yī)學應用實現(xiàn)單個接口。在一個實施例中，所接收的請求包括表示所接收的請求是緊急請求的數(shù)據(jù)標記。因此，不同于如前所討論的現(xiàn)有技術的應用，比如數(shù)字權限管理(DRM)客戶端應 用，其中使用不能夠處理訪問保健數(shù)據(jù)的緊急請求的許可證服務器、順從的(compliant) 客戶端等等，所述緊急救護(例如醫(yī)院)將被授予許可證，該許可證將允許他訪問他想要訪 問的數(shù)據(jù)，即使他沒有正常的權限訪問它。盡管這種緊急訪問可能以保健數(shù)據(jù)的安全為代 價(這確實是一個重要特征)，但是與患者的安全相比，它仍然不太重要，因為這種對保健 數(shù)據(jù)的緊急訪問可能挽救患者的生命。在一個實施例中，從所述請求者接收的請求包括請求用于訪問保健數(shù)據(jù)的解密密 鑰，向所述請求者提供對保健數(shù)據(jù)的訪問的步驟將所請求的解密密鑰轉(zhuǎn)發(fā)給請求者。因此，避免了以下瓶頸其中所述可信代理不需要解密所接收的請求所源自的所 有客戶端的數(shù)據(jù)。所述解密在客戶端應用處發(fā)生。在一個實施例中，從所述請求者接收的請求包括加密形式的所述請求的保健數(shù) 據(jù)，向所述請求者提供對保健數(shù)據(jù)的訪問的步驟將解密形式的保健數(shù)據(jù)轉(zhuǎn)發(fā)給所述請求者ο這允許所述可信代理與不支持數(shù)字權限管理和數(shù)據(jù)解密的傳統(tǒng)系統(tǒng)交互操作。在 這種情況下，所述加密的數(shù)據(jù)被離線存儲在客戶端應用處。在一個實施例中，在所接收的請求之后，所述代理從服務器獲得加密形式的保健 數(shù)據(jù)并且對所述保健數(shù)據(jù)進行解密，向所述請求者提供對保健數(shù)據(jù)的訪問的步驟將所述解 密的保健數(shù)據(jù)轉(zhuǎn)發(fā)給所述請求者。該實施例提供與先前一個實施例相同的優(yōu)點。然而，該實施例中的所述醫(yī)學數(shù)據(jù) 被存儲在集中式數(shù)據(jù)庫中。在一個實施例中，所述方法進一步包括將所述日志提交給服務器以供復查。因此，所述可信代理可以記錄關于所述請求、請求者的所有必要的細節(jié)。這可以是 背景(context)數(shù)據(jù)(比如日期和時間)、包含在所述請求中的信息(比如所請求的數(shù)據(jù))、 關于所述請求者的信息(比如正在使用的醫(yī)學應用或設備的注冊憑證)、關于設備的信息 (比如IP地址)等等。在一個實施例中，許可證包括所述解密密鑰連同用于訪問保健數(shù)據(jù)的相關許可證 規(guī)則，并且其中所述請求者是數(shù)字權限管理(DRM)客戶端應用或企業(yè)權限管理(ERM)客戶端應用，向DRM或ERM客戶端應用提供對保健數(shù)據(jù)的訪問的步驟將所述許可證解密密鑰連 同相關的許可證規(guī)則轉(zhuǎn)發(fā)給DRM或ERM客戶端應用。在一個實施例中，利用文本密鑰保護保健數(shù)據(jù)，并且其中所述許可證包括針對受 保護的保健數(shù)據(jù)的利用緊急密鑰KEm加密的文本密鑰，所述緊急密鑰KEm隨后被分發(fā)給所有可信代理。在一個實施例中，所述許可證被附加到受保護的保健數(shù)據(jù)。在一個實施例中，所述緊急許可證和所保護的保健數(shù)據(jù)被轉(zhuǎn)發(fā)給DRM或ERM，其中 在緊急請求時，所述DRM或ERM進一步被提供適于解密所述文本解密密鑰的緊急密鑰Ka。根據(jù)另一方面，本發(fā)明涉及一種計算機程序產(chǎn)品，其用于當該產(chǎn)品在計算機上運 行時指令處理單元執(zhí)行上述分方法步驟。根據(jù)又一個方面，本發(fā)明涉及一種適于處理保健數(shù)據(jù)的可信代理，其中所述可信 代理擁有或可以使用用于訪問保健數(shù)據(jù)的解密密鑰，所述可信代理包括接收器，用于從請求者接收請求訪問保健數(shù)據(jù)的請求，日志發(fā)生器，用于生成包括與所述請求或所述請求者或二者有關的數(shù)據(jù)的日志， 以及處理器，用于處理所接收的請求，所述處理導致向所述請求者提供對保健數(shù)據(jù)的 訪問ο根據(jù)又一個實施例，本發(fā)明涉及一種請求者，其包括用于生成訪問由所述可信代 理處理的保健數(shù)據(jù)的請求的請求發(fā)生器，其中所述請求發(fā)生器進一步適于生成表示所生成 的請求是緊急請求的數(shù)據(jù)標記。根據(jù)又一方面，本發(fā)明涉及一種服務器，其包括用于從所述可信代理接收日志的 接收器以及用于存儲所接收的日志的存儲器，其中所述存儲器進一步存儲保健數(shù)據(jù)、或用于訪問保健數(shù)據(jù)的解密密鑰、或包括 解密密鑰連同用于訪問保健數(shù)據(jù)的相關許可證規(guī)則的許可證，或它們的組合，其中所述可信服務器適于操作、提供和管理多個所述可信代理，所述操作包括響 應于從所述可信代理接收所述日志，通過提供所請求的解密密鑰向所述可信代理提供對保 健數(shù)據(jù)的訪問。本發(fā)明的每一個方面可以與任何其他方面相結合。本發(fā)明的這些和其他方面將根 據(jù)下文描述的實施例而變得清楚并且參照這些實施例而被闡明。


將僅僅通過實例并參照附圖描述本發(fā)明的實施例，在附圖中圖1示出根據(jù)本發(fā)明的方法的流程圖，圖2圖示地描繪根據(jù)本發(fā)明的可信代理、請求者和服務器，圖3示出DIC0M(醫(yī)學數(shù)字成像和通信)_順從的DRM系統(tǒng)的加密文件和許可證，圖4示出支持緊急訪問的增強的DRM基礎設施，其由舊DRM基礎設施和新緊急基 礎設施構成，圖5描繪了可被認為是順從的客戶端的請求者所進行的緊急數(shù)據(jù)訪問，和圖6描繪了可被認為是非順從客戶端的請求者所進行的緊急數(shù)據(jù)訪問。
具體實施例方式圖1示出根據(jù)本發(fā)明的通過擁有或可以使用用于訪問保健數(shù)據(jù)的解密密鑰的可 信代理進行保健數(shù)據(jù)處理的方法的流程圖。所述保健數(shù)據(jù)可以是標識患者和患者的病歷的 數(shù)據(jù)。所述可信代理可以是來自例如可信商家的物理設備或軟件應用。優(yōu)選地，它具有使 多個商家能夠進行實施并且還需要醫(yī)學應用實現(xiàn)單個接口的標準接口。所述醫(yī)學應用可以 被認為是正常醫(yī)學應用或被認為是緊急醫(yī)學應用。正常的醫(yī)學應用必定能夠訪問受保護的 健康數(shù)據(jù)并且具有決策和實施功能，例如訪問控制引擎、數(shù)字權限管理(DRM)客戶端等等。 而且，典型地所述正常的醫(yī)學應用具有憑證(即身份、解密密鑰等等)，其使得所述決策和 實施功能準許或不準許對所保護的數(shù)據(jù)的訪問。應當注意，所述可信代理不必需要被部署 在與所述醫(yī)學應用相同的設備上。所述緊急醫(yī)學應用是需要對保健數(shù)據(jù)進行緊急或“加速”的訪問的地方。所述緊 急醫(yī)學應用典型地可以使用受保護的數(shù)據(jù)，但是它沒有準許訪問的憑證。隨后的步驟處理 這種情況。在步驟(Si) 101中，請求者(即在這種情況下為所述緊急醫(yī)學應用)發(fā)送請求到 所述可信代理，所述可信代理如上所述地擁有或可以使用訪問保健數(shù)據(jù)的解密密鑰。所接 收的請求可以包括表示所接收的請求是緊急請求或“加速”訪問的請求的數(shù)據(jù)標記。在步驟(S》103中，所述可信代理生成包括與所述請求或所述請求者或二者相關 的數(shù)據(jù)的日志。所述日志中所包含的信息可以例如是背景數(shù)據(jù)(比如進行請求的日期和時 間)、所述請求中所包含的信息(比如所請求數(shù)據(jù)的類型)、關于請求者的信息(例如用于 醫(yī)學應用的注冊憑證或請求者或正被使用的設備的ID號)、關于所述設備的信息(比如IP 地址)等等。在一個實施例中，所述日志隨后被提交到服務器(S3) 105，例如醫(yī)院中的中央服務器，以供復查。最后，所述請求者被提供對保健數(shù)據(jù)的訪問(S4)107。在一個實施例中，所接收的請求包括請求用于訪問保健數(shù)據(jù)的解密密鑰，并且其 中向請求者提供對保健數(shù)據(jù)的訪問的步驟(S4)107是通過將所請求的解密密鑰轉(zhuǎn)發(fā)給所 述請求者來完成的。因此，所述可信代理不需要解密所接收的請求所源自的所有客戶端的 數(shù)據(jù)，因為解密在所述客戶端應用處發(fā)生并且避免了瓶頸。在另一個實施例中，從所述請求者接收的請求包括被請求的加密形式的保健數(shù) 據(jù)，并且向請求者提供對保健數(shù)據(jù)的訪問的步驟包括將解密形式的保健數(shù)據(jù)轉(zhuǎn)發(fā)給請求 者。這允許所述可信代理與不支持數(shù)字權限管理和數(shù)據(jù)解密的傳統(tǒng)系統(tǒng)互操作。在這種情 況下，所述加密數(shù)據(jù)被離線存儲在客戶端應用處。在一個實施例中，所述請求者是DRM客戶端應用或企業(yè)權限管理(ERM)客戶端應 用，其中許可證包括解密密鑰連同用于訪問保健數(shù)據(jù)的相關的許可證規(guī)則。所述向DRM或 ERM客戶端應用提供對保健數(shù)據(jù)的訪問的步驟可以包括將所述許可證解密密鑰連同相關的 許可證規(guī)則轉(zhuǎn)發(fā)到DRM或ERM客戶端應用。這將在稍后更詳細地討論。在一個實施例中，在所述日志的交換過程中獲得新密鑰。這確保了系統(tǒng)不被對手 “斷開”以獲得不受限的訪問并提供額外的安全，因為所述服務器僅僅在它接收到新鮮的和7可靠地日志信息時才將緊急密鑰分發(fā)給可信代理。圖2圖示地描繪了適于處理保健數(shù)據(jù)并擁有或可以使用用于訪問保健數(shù)據(jù)的可 信代理200、請求者220和服務器210。請求者220包括請求發(fā)生器(R_G) 221，該請求發(fā)生器(R_G) 221生成用于訪問保健 數(shù)據(jù)的請求223并且進一步適于生成表示所生成的請求223是緊急請求的數(shù)據(jù)標記222。 所生成的請求223和數(shù)據(jù)標記222隨后經(jīng)由通信信道224(可以是有線或無線的)而被轉(zhuǎn) 發(fā)或傳輸?shù)娇尚糯?00。可信代理200包括接收器(R) 203、日志發(fā)生器(L_G) 202和處理器(P) 201。接收 器(R) 203適于從請求者220接收請求訪問保健數(shù)據(jù)的請求220。日志發(fā)生器(L_G) 202適 于生成如先前圖1中所討論的日志204，其包括與所述請求或所述請求者或二者相關的數(shù) 據(jù)。所述處理器適于處理所接收的請求223。所述處理包括與服務器210進行通信，及通過 例如請求用于訪問保健數(shù)據(jù)的解密密鑰來與所述服務器通信。所述處理包括將所請求的解 密密鑰轉(zhuǎn)發(fā)給請求者或?qū)⒔饷苄问降谋＝?shù)據(jù)轉(zhuǎn)發(fā)給請求者(參見圖1的討論)。這里所描繪的服務器210經(jīng)由可以是有線通信信道或無線的通信信道205與可信 代理200通信。服務器210包括用于從可信代理200接收日志204的接收器(R)211和用 于存儲所接收的日志的存儲器212。存儲器212中還存儲了保健數(shù)據(jù)、或用于訪問保健數(shù)據(jù) 的解密密鑰、或具有用于訪問保健數(shù)據(jù)的相關許可證規(guī)則的許可證解密密鑰，或它們的組 合。所述服務器進一步適于操作多個所述可信代理，該操作包括響應于從可信代理接收所 述日志，通過提供所請求的解密密鑰向可信代理提供對保健數(shù)據(jù)的訪問。這將在稍后更詳 細地討論。圖3示出根據(jù)本發(fā)明的實施例，其示出本發(fā)明可以應用于DICOM(醫(yī)學數(shù)字成像和fflfn )。DRM系統(tǒng)確保了醫(yī)學信息的端到端機密性并且提供在目的地上的源控制。圖 3中所示的用于DICOM文件的DRM系統(tǒng)使用加密消息語法和如在“National Electric Manufacturers Association (NEMA), Digital Imaging and Communications in Medicine (DICOM), part 15 :Security and system management profiles Annex E.I, 2007”中公開的DICOM去標識簡檔的放寬版本(relaxed version)，所示文獻通過引用合并 于此。必須被保護的DICOM文件的屬性因此利用內(nèi)容加密密鑰來加密。隨后，具有所需的 密鑰材料的許可證被嵌入。這是通過使用所述標準提供的工具的方式完成的，因此仍然確 保了向后兼容性。根據(jù)安全的觀點，該DRM方法是關于數(shù)據(jù)分發(fā)和醫(yī)學界的不同用戶的隱私的控制 的改進。然而，為了使得醫(yī)學安全解決方案被醫(yī)療專業(yè)人員接受，必要的是包括緊急訪問的 可能性。假設一個針對保健數(shù)據(jù)(醫(yī)學數(shù)據(jù))的DRM保護的環(huán)境，其中使用許可證服務器、 順從的客戶端等。所公布的DRM保護的數(shù)據(jù)被加密并且許可證服務器向請求用戶發(fā)行許可 證(包括對所述內(nèi)容的使用權限)，如果他們具有足夠的權限訪問所述數(shù)據(jù)。因此，緊急訪 問表示所述系統(tǒng)的正常行為的例外，在這個意義上它難以處理。所述緊急救護提供者應當 優(yōu)選地被授予用于解碼他想要訪問的數(shù)據(jù)的許可證，即使他沒有正常的權限訪問它。因此， 這種訪問的合法性必須稍后被證實以最終確保數(shù)據(jù)隱私。于是需要緊急訪問的記錄。
如前所討論，所述緊急訪問控制問題的解決方案是發(fā)行緊急許可證并記錄這種事 件。這可以通過由許可證服務器210(參見圖幻將緊急密鑰Kai分發(fā)給所有的可信代理 200(參見圖幻來完成。由利用KEm加密內(nèi)容密鑰構成的緊急許可證可以嵌有每個新近保 護的保健數(shù)據(jù)。在緊急訪問時，可信代理200記錄如前所討論的事件并利用KEm解密所述數(shù) 據(jù)，即使所述請求者(例如請求用戶)沒有從例如許可證服務器獲得許可。所述緊急訪問控制問題的另一個解決方案是在DRM加密時間不將許可證嵌入到 數(shù)據(jù)中。然而，當緊急訪問時，可以是救護提供者的請求者220經(jīng)由可信代理200接觸適當 的服務器210(例如許可證服務器210)并且請求緊急許可證。許可證服務器210可以實現(xiàn) 可信代理200的特征，及可信代理200的一些或所有特征可以被認為被并入到許可證服務 器210，或者可信代理200和許可證服務器210可以如圖2所描繪的那樣進行交互。所述事 件由所述許可證服務器記錄并且臨時許可證被發(fā)行。圖2所描繪的場景(其中可信代理200負責處理緊急情況以加強數(shù)據(jù)機密性)可 以與DRM系統(tǒng)并行地部署。這在圖4中圖示地被描繪，該圖4示出了支持緊急訪問的增強 型DRM基礎設施，其由舊DRM基礎設置413和新緊急基礎設施400構成。盡管圖4示出如何可以增強具有緊急訪問的DRM基礎設施，但是不應當認為其限 于DIC0M，而是不限于各種系統(tǒng)。所述新緊急基礎設施400包括來自圖2的所述服務器210 (這里被稱為緊急權威 機構(E_A)401)和多個所述可信代理200(這里被稱為緊急代理(Ε_Α_Ε1_η) 402-405。所述 緊急權威機構(E_A)401獨立于數(shù)據(jù)創(chuàng)建器(creator)和消費者，并且可以被信任。最后， 它負責證實緊急訪問的合法性。所述權威機構操作一些部件以支持該過程。在請求者406請求緊急訪問時緊急代理(E_A_El_n) 402-405被請求者406接 觸。緊急代理(Ε_Α_Ε1_η)402-405負責準予訪問緊急救護提供者并且記錄這些事件。它們 例如通過證書被緊急權威機構(E_A)401信任。為此目的，這種部件的順從性可以在假設 (assume)該信任之前由緊急權威機構(E_A)401 (及對應于所述服務器210)來檢查。緊急 代理(E_A_El_n) 402-405(即對應于所述可信代理200)可以安裝在部署了 DRM系統(tǒng)413的 醫(yī)院中。緊急權威機構(E_A)401可以適于生成新緊急密鑰對KprivEm(id)和KpubEm(id)。 它優(yōu)選安全地將私鑰KprivEm(id)傳輸給所有其緊急代理(Ε_Α_Ε1_η) 402-405。一旦緊急 權威機構(E_A) 401確信該新私鑰已被成功地分發(fā)，則它將對應的公鑰KpubEm (id)發(fā)送給許 可證服務器(L_S_l-n)409-412，使得它們可以創(chuàng)建用于受保護數(shù)據(jù)的緊急許可證。由緊急權威機構(E_A)401生成密鑰可以遵循不同的策略例如每個醫(yī)院一個密 鑰對、每天一個密鑰對等。作為另一個可替代方案，共同的緊急密鑰可以在國家水平上用 于所有數(shù)據(jù)。然而所有這些密鑰必須是每個緊急代理(Ε_Α_Ε1_η)402-405已知的，使得 確保數(shù)據(jù)的可用性，而與緊急訪問時所接觸的緊急代理或文件無關。重要的是，所述私鑰 KprivEffl(id)停留在緊急基礎設施的可信環(huán)境中。即，基于公開的私鑰的包含緊急許可證的 所有DRM保護的數(shù)據(jù)的機密性是折中的。當通過DRM發(fā)布者(Publ. ) 408對原始文件F加密時，緊急許可證LFEm被嵌入在所 得的文件中。它是由負責DRM保護文件的許可證服務器使用其緊急公鑰KpubEm(id)的知識 創(chuàng)建的。所得的加密的DRM容器(container)包含加密形式的原始數(shù)據(jù)。
當諸如緊急救護提供者之類的請求者要求緊急訪問已經(jīng)下載的文件F時，他優(yōu)選 地接觸最近的可用緊急代理(Ε_Α_Ε1_η)402-405。圖4中所示的實施例聚焦在DICOM上。因此，所述交換消息被定義為新DICOM緊 急訪問服務對象對(SOP)類。一般地，DICOM定義了可以應用于服務對象對(SOP)類中的信息對象定義(IOD)的 服務集。SOP類可以是被標準化的或者是復合的，這依賴于它們是應用于標準化的還是復合 的I0D。標準化的IOD是通常表示真實世界的DICOM模型中單個實體的信息對象定義。復 合的IOD是個信息對象定義，其表示真實世界的DICOM模型中所包含的若干個實體的一部 分。SOAP類由下面的唯一標識符來識別SOP類UID。對于要被描述的SOP類內(nèi)的服務，首 先有必要為每個參與者分配角色。一方(peer)可以是服務類用戶(SCU ；即客戶端)或服 務類提供者(SCP 卩服務器)或同時假設兩個角色。服務描述還定義了可以應用于所關注 的 IOD 的命令?，F(xiàn)有命令類型包括 C-STORE、C-FIND, C-MOVE, C-GET, C-CANCEL 和 C-ECH0。當將命令從一個DICOM節(jié)點發(fā)送到另一個節(jié)點時，該命令包括對SOP類和所述命 令關注的IOD實例的參考，并且可以附加額外的數(shù)據(jù)集(所述命令的有效載荷)。所述目 的地有可能回答命令執(zhí)行情況(例如，失敗、成功等)還連同可選的附加的有效載荷。當兩 個應用(應用實體)想要通信時，它們必須就它們將要使用的服務(SOP類)達成一致。因 此，所述通信建立過程包括被稱為關聯(lián)談判的所支持的SOP類的談判。如果通信應用實體 之一不支持SOP類，則所關注的服務不能被使用。為了在DICOM文件中包含策略，加密的屬性數(shù)據(jù)集(S卩，CMS信封)被嵌入在DICOM 文件中。新屬性也被引入公開密鑰(disclosureKey)。它包括將被用于保護屬性的對稱 密鑰。下面的過程在加密時發(fā)生-必須要保護的所有屬性被加擾，包括disclosureKey密鑰；-創(chuàng)建包含除了disclosureKey的屬性的加密版本的CMS信封。它的文本加密密 鑰是使用原始的disclosureKey屬性的密鑰加密的。-當用戶請求訪問數(shù)據(jù)時，所述許可證服務器生成新的CMS信封，其與DICOM標準 兼容，包含原始disclosureKey屬性。它的文本加密密鑰是使用順從的客戶端或用戶的公 鑰來加密的。當創(chuàng)建新許可證時，散布的(disseminated)DICOM內(nèi)容不被修改所述許可證可 以只是附加到文件以供稍后使用。所述策略被存儲在CMS信封內(nèi)作為不受保護的屬性。因 此，不同的策略可以針對不同的用戶進行設置。該解決方案在以下意義下是非常靈活的每 個保護不同屬性的信封可以具有不同的策略規(guī)范。圖5圖示地描繪了一種協(xié)議其中可以被認為順從的客戶端(C_C)406的請求者 406通過向緊急代理(Ε_Α_Ε1-η) 402-405發(fā)送嵌入在F中的緊急許可證(Si，)502來請求對 文件F 501的訪問。在DICOM中，這可以被實現(xiàn)為包括緊急許可證的N-ACTION命令。如前 所述，術語緊急代理(Ε_Α_Ε1-η)402-405只是如圖2所描繪的可信代理210的實施例。而 且，如前所述，緊急權威機構(E_A)401可以操作一個或多個緊急代理(Ε_Α_Ε1-η) 402-405， 其尤其響應于請求者406的請求執(zhí)行所述記錄操作。再次參照圖5中所描繪的協(xié)議，在檢查請求者406(C_C)確實是順從的客戶端之 后，生成針對請求者(C_C) 406 (S2’)503的日志.緊急權威機構(E_A)401(圖5中未示出)使用適當?shù)乃借€解密所接收的緊急許可證。在恢復內(nèi)容密鑰之后，使用請求者的公鑰構造 新臨時許可證，其意圖是僅僅被請求者(C_C)406使用。隨后，新臨時許可證(S3，)504被發(fā)送給請求者(C_C)406.在DICOM中，這可以被 實現(xiàn)為包括所述臨時許可證的N-EVENT-REP0RT命令，因此所述臨時許可證僅僅是如圖3所 描繪的DICOM許可證。請求者(C_C)406現(xiàn)在能夠通過利用他的私鑰解密所述臨時許可證來觀看文件內(nèi) 容 F(S4，)505。可能的是，醫(yī)學界中的各方將使用非順從的請求者。所述緊急過程應當因此優(yōu)選 地被調(diào)試，使得這些非順從請求者仍然可以訪問緊急上下文中的數(shù)據(jù)，而不能改變系統(tǒng)的 總體安全。所提出的解決方案提供準許到請求的數(shù)據(jù)的完全訪問。隨后，緊急訪問的記錄甚至更加重要，因為這些請求者可以不受任何限制地公開 所獲得的數(shù)據(jù)。為此，還可優(yōu)選地包括水印以用于進一步的法庭跟蹤。下面的擴展可以用于在正常的操作(即，不必是緊急情況)中為非順從端(peer) 提供數(shù)據(jù)訪問。圖6示出為訪問緊急背景中的文件F 501的非順從客戶端(N_C_C)601的請 求者與它的最近的可用緊急代理(Ε_Α_Ε1-η)402-405之間的交換。所述非順從客戶 端(N_C_C)601將文件F連同它的嵌入的緊急許可證(Sl”)602發(fā)送到緊急代理(E_A_ El-n)402-405。緊急代理(E_A_En)402-405使用它了解的對所有私有緊急密鑰，以便解密 緊急許可證(S2”)603，并且因此恢復內(nèi)容密鑰內(nèi)容。因此，隨后，它可以解密文件F并獲得 原始文件。所述緊急訪問被記錄并且文件F的解密版本被發(fā)送(S3”)604到非順從客戶端 (N_C_C) 601，其隨后可以自由地訪問原始文件(S4 ”)605。為了解釋而不是限制的目的，所公開的實施例的某些特定細節(jié)被提及，從而提供 對本發(fā)明的清楚和透徹的理解。然而，本領域技術人員應當理解，本發(fā)明可以在與本文所敘 述的細節(jié)不完全一致的其他實施例中實踐，而不足以脫離本公開的精神和范圍。而且，在該 上下文中并且為了簡短和清楚的目的，省略了眾所周知的裝置、電路和方法的詳細描述，以 避免不必要的細節(jié)和可能的混淆。權利要求中包含附圖標記，然而所包含的附圖標記僅僅是為了清楚，不應當被解 釋為限制權利要求的范圍。
權利要求
1.一種通過擁有或可以使用用于訪問保健數(shù)據(jù)的可信代理來進行保健數(shù)據(jù)處理的方 法，包括-從請求訪問保健數(shù)據(jù)的請求者(101)接收請求，-生成包括與所述請求或所述請求者或二者相關的數(shù)據(jù)的日志(10 ，以及-向所述請求者提供對所述保健數(shù)據(jù)(107)的訪問。
2.根據(jù)權利要求1的方法，其中所接收的請求包括表示所接收的請求是緊急請求的數(shù) 據(jù)標記。
3.根據(jù)權利要求1的方法，其中從所述請求者接收的請求包括請求用于訪問保健數(shù)據(jù) 的解密密鑰，向所述請求者提供對保健數(shù)據(jù)的訪問的步驟將所請求的解密密鑰轉(zhuǎn)發(fā)給請求者ο
4.根據(jù)權利要求1的方法，其中從所述請求者接收的請求包括加密形式的所述請求的 保健數(shù)據(jù)，向所述請求者提供對保健數(shù)據(jù)的訪問的步驟將解密形式的保健數(shù)據(jù)轉(zhuǎn)發(fā)給所述 請求者。
5.根據(jù)權利要求1的方法，其中在接收的請求之后，所述代理從服務器獲得加密形式 的保健數(shù)據(jù)并且對所述保健數(shù)據(jù)進行解密，向所述請求者提供對保健數(shù)據(jù)的訪問的步驟將 所解密的保健數(shù)據(jù)轉(zhuǎn)發(fā)給所述請求者。
6.根據(jù)權利要求1的方法，進一步包括將日志提交給服務器(105)以供復查。
7.根據(jù)權利要求1的方法，其中許可證包括解密密鑰連同用于訪問保健數(shù)據(jù)的相關許 可證規(guī)則，并且其中所述請求者是數(shù)字權限管理(DRM)客戶端應用或企業(yè)權限管理(ERM) 客戶端應用，向DRM或ERM客戶端應用提供對保健數(shù)據(jù)的訪問的步驟將許可證解密密鑰連 同相關的許可證規(guī)則轉(zhuǎn)發(fā)給DRM或ERM客戶端應用。
8.根據(jù)權利要求7的方法，其中利用文本密鑰保護保健數(shù)據(jù)，并且其中所述許可證包 括針對受保護的保健數(shù)據(jù)的利用緊急密鑰KEm加密的文本密鑰，所述緊急密鑰KEm隨后被分 發(fā)給所有可信代理。
9.根據(jù)權利要求8的方法，其中所述許可證被附加到所保護的保健數(shù)據(jù)。
10.根據(jù)權利要求8的方法，其中所述緊急許可證和所保護的保健數(shù)據(jù)被轉(zhuǎn)發(fā)給DRM或 ERM，其中在緊急請求時，所述DRM或ERM進一步被提供適于解密該文件解密密鑰的緊急密 鑰 KEmo
11.一種計算機程序產(chǎn)品，其用于當該產(chǎn)品在計算機上運行時指令處理單元執(zhí)行權利 要求1的方法步驟。
12.一種適于處理保健數(shù)據(jù)的可信代理000)，其中所述可信代理擁有或可以使用用 于訪問保健數(shù)據(jù)的解密密鑰，所述可信代理包括-接收器O03)，用于從請求者接收請求訪問保健數(shù)據(jù)的請求，-日志發(fā)生器020)，用于生成包括與所述請求或所述請求者或二者有關的數(shù)據(jù)的日 志，以及-處理器001)，用于處理所接收的請求，所述處理導致向所述請求者提供對保健數(shù)據(jù) 的訪問。
13.—種請求者，包括用于生成訪問由如權利要求12中所述的可信代理(200)處理的 保健數(shù)據(jù)的請求023)的請求發(fā)生器021)，其中所述請求發(fā)生器進一步適于生成表示所生成的請求(22 是緊急請求的數(shù)據(jù)標記022)。
14. 一種服務器010)，包括用于從如權利要求12所述的可信代理(200)接收日志 (204)的接收器011)和用于存儲所接收的日志的存儲器012)，其中所述存儲器(21 進一步存儲保健數(shù)據(jù)、或用于訪問保健數(shù)據(jù)的解密密鑰、或具 有用于訪問保健數(shù)據(jù)的相關許可證規(guī)則的許可證解密密鑰，或它們的組合，其中所述服務器(210)適于操作、提供和管理多個所述可信代理000)，所述操作包 括響應于從所述可信代理接收所述日志，通過提供所請求的解密密鑰而向所述可信代理 提供對保健數(shù)據(jù)的訪問。
全文摘要
本發(fā)明涉及一種通過擁有或可以使用用于訪問保健數(shù)據(jù)的解密密鑰的可信代理進行保健數(shù)據(jù)處理的方法。從請求者接收請求訪問保健數(shù)據(jù)的請求。生成包含與所述請求或所述請求者或二者相關的數(shù)據(jù)的日志。最后，向所述請求者提供對保健數(shù)據(jù)的訪問。
文檔編號G06F19/00GK102057379SQ200980120695
公開日2011年5月11日 申請日期2009年5月29日 優(yōu)先權日2008年6月4日
發(fā)明者J·孔齊, M·佩特科維克, R·P·科斯特 申請人:皇家飛利浦電子股份有限公司