Patent Application
20150213570
Electronic Health Records (EHRs) may enable healthcare participants (e.g., patients, healthcare providers, payers, and researchers) to improve coordination of care and access to health information. Although EHRs may facilitate access to healthcare information, the sharing of healthcare information may involve many complex technical and legal issues. These issues may be burdensome for healthcare participants that lack the resources and expertise to enable such sharing while ensuring consistency, privacy, and security of the healthcare information.
In the following detailed description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the disclosed subject matter may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.
Embodiments described herein provide an electronic health record (EHR) store processing environment that enables secure, seamless sharing of EHRs among healthcare participants (e.g., patients, healthcare providers, payers, and researchers). The environment includes an encrypted data store that stores encrypted EHRs of patients and a metadata store that stores a metadata tree for each patient. Each metadata tree provides a mapping to the EHRs of a given patient in the encrypted data store. The metadata tree for each patient may be accessed by authorized healthcare participants, such as healthcare providers, to allow the participants to access and store EHRs of patients.
The environment controls access to EHRs using record keys for encrypted EHRs and node keys for the nodes of metadata trees. Healthcare participants that store encrypted EHRs in the encrypted data store encrypt the EHRs using record keys. These participants also add encrypted nodes for the corresponding encrypted EHRs to the metadata tree. The encrypted nodes include references to the corresponding encrypted EHRs and are encrypted with corresponding node keys.
Each metadata tree also includes separate hierarchical lockbox mechanisms for storing the node keys and the record keys. In particular, each node in the metadata tree includes a node key lockbox (i.e., a first hierarchical lockbox mechanism) to store a corresponding set of node keys and a record key lockbox to store a corresponding record key. Each node key is usable, prior to being revoked, to encrypt and decrypt the corresponding node and to lock and unlock the node key lockbox at each node under the corresponding node. Each record key is usable either to lock and unlock the record key lockbox at each node (i.e., a second hierarchical lockbox mechanism) under the corresponding node or to encrypt and decrypt a corresponding EHR. The separate hierarchical lockbox mechanisms allow access rights to be granted separately for metadata tree nodes and encrypted EHRs.
One or more healthcare participants may manage different subtrees of the metadata tree of a patient. A healthcare participant that manages a subtree maintains node and record keys for a top-most node in the subtree, where the node and record keys are derived from a patient key of the patient. Because the node and record keys for each subtree are derived from the patient key, a patient can unlock the node and record lockboxes at all levels of each subtree to obtain access to all of the patient's EHRs.
To manage a subtree, a participant manages the node and the record keys of the corresponding nodes in the subtree to grant and revoke access to other authorized healthcare participants of a patient. A participant grants access by providing selected node and record keys to another participant. Because node and record keys at a given node of a subtree may be used to unlock corresponding lockboxes at all nodes under the given node, the participant controls the level of access by selecting which node and record keys to share.
A participant revokes access by rotating the node key in the node key lockbox at a revoked node in the subtree. After a key revocation, a participant whose access has been revoked will continue to be able to unlock node key lockboxes corresponding to encrypted nodes that are stored under the revoked node prior the revocation. Thus, the revoked participant will continue to be able to access encrypted EHRs that were stored prior to the revocation. The revoked participant will not, however, be able to unlock node key lockboxes corresponding to encrypted nodes that are stored under the revoked node after the revocation. In particular, the revoked participant will not be able to unlock the node keys for these nodes which are needed to decrypt the references to corresponding encrypted EHRs (i.e., the encrypted EHRs that are stored after the revocation). The revoked participant will also not be able to add new encrypted nodes under the revoked node.
As used herein, the term “healthcare participant” (also referred to as “participant”) refers to a patient, a healthcare provider, a payer, a researcher, or other suitable person involved in a healthcare process of a patient that generates and/or uses healthcare information corresponding to a patient. The term “patient” refers to a person that receives at least one healthcare service from a healthcare provider. The term “healthcare provider” (also referred to as “provider”) refers to a person and/or institution that provide(s) at least one healthcare service to a patient.
The term “electronic health record” (EHR) refers to a set of healthcare information generated by a healthcare participant and stored in an electronic format on at least one machine-readable storage medium. The term “encrypted electronic health record” refers to an electronic health record that has been encrypted with an encryption key such as a record key.
The term “metadata” refers to a set of information that describes at least one record, such as an electronic health record. The term “metadata tree” refers to a set of nodes that include metadata where each node has a specified relationship with at least one other node in the set.
The term “record key” refers to an encryption key that is used to encrypt and decrypt an EHR of a patient. The term “node key” refers to an encryption key that is used to encrypt and decrypt at least a portion of a node in a metadata tree of a patient. The term “metadata tree key” refers to an encryption key that is used to encrypt and decrypt at least a portion of a metadata tree of a patient.
The term “record key lockbox” refers to a data structure that stores a record key corresponding to a node in a metadata tree and may be locked and unlocked only with a corresponding record key from a parent node of the node in the metadata tree. The term “node key lockbox” refers to a data structure that stores a set of one or more node keys corresponding to a node in a metadata tree and may be locked and unlocked only with a corresponding set of one or more node keys from a parent node of the node in the metadata tree.
EHR store 20 includes a data access front 22, an encrypted data store 24, and a metadata store 26. Data access front 22 communicates with participant systems 30 to manage accesses to encrypted data store 24 and metadata store 26 by participant systems 30.
Encrypted data store 24 stores encrypted EHRs of patients that were generated and provided by participant systems 30. The encrypted EHRs are encrypted and decrypted by participant systems 30 using corresponding record keys. Encrypted data store 24 includes any suitable type, number, and/or configuration of machine-readable storage media to store the encrypted EHRs. Because the EHRs are encrypted and because encrypted data store 24 does not store the encryption keys (i.e., record keys) for the EHRs, encrypted data store 24 may or may not be a trusted data store (e.g., encrypted data store 24 may be owned or operated by one or more untrusted third parties).
Metadata store 26 stores a metadata tree 50 for each patient where each metadata tree 50 includes a set of nodes 51 with corresponding node key lockboxes 62 and record key lockboxes 64. Nodes 51 are arranged in a hierarchical tree structure and, as shown in the example of
Patient root node 52 includes information that identifies the patient. Subtree nodes 54 identify corresponding healthcare participants that manage the corresponding subtrees formed by the collection of nodes 56 and 58 under each subtree node 54. Intermediate nodes 56 represent logical groupings of EHRs (e.g., by categories of patient information such as treatment conditions) and include information that describes the groupings. Each leaf node 58 stores metadata that describes a corresponding encrypted EHR 80, where the metadata includes a reference 60 to the encrypted EHR 80 in encrypted data store 24 as indicated by the dotted arrows representing references 60 in
Referring back to
The collection of node and record key lockboxes 62 and 64 in each metadata tree 50 forms separate hierarchical lockbox mechanisms for storing node keys and record keys, respectively. The separate hierarchical lockbox mechanisms allow access rights to be granted separately for metadata tree nodes 51 and encrypted EHRs 80.
Each node key lockbox 62 stores a set of node keys (i.e., a current node key and any revoked node keys) for a corresponding node 51. Each node key is usable to encrypt and decrypt the corresponding node 51 and, prior to being revoked, to lock and unlock each node key lockbox 62 at each node 51 under the corresponding node 51. For example, a node key from a node key lockbox 62 in an intermediate node 56 may be used to lock and unlock each node key lockbox 62 of each leaf node 58 directly under the intermediate node 56 as well as any other node key lockboxes 62 of other intermediate nodes 56 directly under the intermediate node 56 (not shown in
Each record key lockbox 64 stores a record key for a corresponding node 51. Each record key is usable either to lock and unlock the record key lockbox at each encrypted node under the encrypted node or to encrypt and decrypt a corresponding encrypted EHR 80. For example, a record key from a record key lockbox 64 in an intermediate node 56 may be used to lock and unlock each record key lockbox 64 of each leaf node 58 directly under the intermediate node 56 as well as any other record key lockboxes 64 of other intermediate nodes 56 directly under the intermediate node 56 (not shown in
Metadata tree 50 allows unaffiliated healthcare participants (e.g., providers practicing under different, unrelated business entities) to store different encrypted EHRs 80 of a patient to encrypted data store 24 and share those encrypted EHRs 80 with other healthcare participants. Encrypted EHRs 80 are each encrypted with different record keys such that a record key for one encrypted EHR 80 may not be used to decrypt any other encrypted EHR 80. Healthcare participants may use metadata tree 50 to determine which encrypted EHRs 80 they need to access and can request access (i.e., node and record keys) from other healthcare participants that generated the needed encrypted EHRs 80 or the patient.
Participants, including patients, healthcare providers, payers, researchers, and other suitable persons involved in healthcare processes of patients, (not shown) interact with corresponding participant systems 30 to communicate with EHR store 20 using corresponding data access adapters 32 to create, access, store, manage, and share EHRs 80 of patients. Each data access adapter 32 communicates with data access front 22 on EHR store 20 to access encrypted data store 24 and metadata store 26.
One or more healthcare participants may manage different subtrees that stem from each subtree node 54 of metadata tree 50. A healthcare participant that manages a subtree maintains subtree node and subtree record keys for a subtree node 54 (i.e., a top-most node in the subtree), and the subtree node and subtree record keys are derived from a patient key of the patient (e.g. provided to a healthcare participant when a patient registers with the participant). In the example of
Participants manage subtrees of metadata tree 50 using participant systems 30. To do so, participant systems 30 manage the node and the record keys of the corresponding nodes 54, 56, and 58 in the subtree to grant and revoke access to other authorized healthcare participants of a patient using other participant systems 30. A participant system 30 grants access by providing selected node and record keys to another participant system 30. Because node and record keys at a given node 54, 56, or 58 of a subtree may be used to unlock corresponding lockboxes at all nodes 56 and/or 58 under the given node 54, 56, or 58, the participant system 30 controls the level of access by selecting which node and record keys to share with the other participant system 30.
In environment 10, EHR store 20 and participant systems 30 may be implemented with any suitable type, number, and configuration of processing systems that each include one or more processors for executing instructions stored in one or more memories (i.e., computer-readable media). In particular, data access front 22, encrypted data store 24, and metadata store 26 may be implemented using different processing systems in some embodiments. An example of participant system 30 is shown in
Participant system 30 represents any suitable processing device or portion of a processing device such as a server computer, a laptop computer, a tablet computer, a desktop computer, a mobile telephone with processing capabilities (i.e., a smart phone), or another suitable type of electronic device with processing capabilities. Each processor 102 is configured to access and execute instructions stored in memory system 104 and to access and store data in memory system 104. Memory system 104 includes any suitable type, number, and configuration of volatile or non-volatile machine-readable storage media configured to store instructions and data. Examples of machine-readable storage media in memory system 104 include hard disk drives, random access memory (RAM), read only memory (ROM), flash memory drives and cards, and other suitable types of magnetic and/or optical disks. The machine-readable storage media are considered to be part of an article or article of manufacture. An article or article of manufacture refers to one or more manufactured components. Communications devices 106 include any suitable type, number, and/or configuration of communications devices configured to allow participant system 30 to communicate across one or more wired or wireless networks.
Data access adapter 32 includes instructions that, when executed by processors 102, causes processors 102 to perform the functions of data access adapter 32 that will now be described with reference to
Referring to
Data access adapter 32 encrypts EHR 120 using record key 114 to generate an encrypted EHR 80 as indicated by an arrow 144. Data access adapter 32 provides encrypted EHR 80 to encrypted data store 24 through data access front 22 as indicated by an arrow 145. Encrypted data store 24 provides a status to data access adapter 32 through data access front 22 as indicated by an arrow 147. If the status indicates that encrypted EHR 80 was not stored successfully, then data access adapter 32 may retry the store.
Once the store is successful, data access adapter 32 generates and encrypts leaf node 58 using node key 112 as indicated by an arrow 147. Data access adapter 32 generates leaf node 58 to include a reference 60 to the successfully stored encrypted EHR 80 in encrypted data store 24 and encrypts reference 60 as part of encrypting leaf node 58. Data access adapter 32 updates metadata tree 50 to include leaf node 58, a node key lockbox 62 with the node key, and a record key lockbox 64 with the record key as indicated by an arrow 148. Data access adapter 32 locks node key lockbox 62 using a node key from a parent node 56 of leaf node 58 and locks record key lockbox 64 using a record key from the parent node 56 of leaf node 58. Data access adapter 32 provides the updated metadata tree 50 to metadata store 26 through data access front 22 as indicated by an arrow 149. Metadata store 26 provides a status to data access adapter 32 through data access front 22 as indicated by an arrow 150. If the status indicates that the updated metadata tree 50 was not stored successfully, then data access adapter 32 may retry the update until it is successful.
Data access adapter 32 repeats the process shown in
Once an encrypted EHR 80 is stored in encrypted data store 24, a participant who generates or obtains the corresponding node and record keys may access the encrypted EHR 80 from encrypted data store 24 as shown in
Data access adapter 32 accesses a node key 112 and a record key 114 from node key lockbox 62 and record key lockbox 64 corresponding leaf node 58 as indicated by an arrow 154. If data access adapter 32 manages the subtree that includes leaf node 58, then data access adapter 32 uses the subtree node key to successively access node keys from any intermediate nodes 56 and leaf node 58 by unlocking each successive node key lockbox 62 until the node key 112 for leaf node 58 is accessed. If data access adapter 32 does not manage the subtree that includes leaf node 58, then data access adapter 32 receives either node key 112 or a node key from an intermediate node 56 in the subtree from another participant system 30 that manages the subtree. If needed, data access adapter 32 uses the received node key to successively access node keys from any intermediate nodes 56 and leaf node 58 by unlocking each successive node key lockbox 62 until the node key 112 for leaf node 58 is accessed.
Similarly, if data access adapter 32 manages the subtree that includes leaf node 58, then data access adapter 32 uses the subtree record key to successively access record keys from any intermediate nodes 56 and leaf node 58 by unlocking each successive record key lockbox 64 until the record key 114 for leaf node 58 is accessed. If data access adapter 32 does not manage the subtree that includes leaf node 58, then data access adapter 32 receives either record key 114 or a record key from an intermediate node 56 in the subtree from another participant system 30 that manages the subtree. If needed, data access adapter 32 uses the received record key to successively access record keys from any intermediate nodes 56 and leaf node 58 by unlocking each successive record key lockbox 64 until the record key 114 for leaf node 58 is accessed.
After accessing node key 112, data access adapter 32 decrypts leaf node 58 with node key 112 to obtain reference 60 to the desired encrypted EHR 80 as indicated by an arrow 155. Data access adapter 32 accesses the encrypted EHR 80 from encrypted data store 24 through data access front 22 as indicated by an arrow 156. Encrypted data store 24 provides the desired encrypted EHR 80 through data access front 22 as indicated by an arrow 157. Data access adapter 32 decrypts encrypted EHR 80 into a decrypted EHR 120 using record key 114 as indicated by an arrow 158. Data access adapter 32 outputs the decrypted EHR 120 to the participant (e.g., by displaying the decrypted EHR 120) as indicated by an arrow 159.
Data access adapter 32 repeats the process shown in
Because the node and record keys for each subtree are derived from the patient key of the patient in the above examples, a patient can generate subtree node and record keys for each subtree node 54 and use the subtree node and record keys to unlock the node and record key lockboxes 62 add 64 at all levels of each subtree to obtain access to all of the patient's EHRs.
A participant, including the patient, may revoke the access of another participant to EHRs stored after a revocation using the method of
In an example key rotation shown in
Node key lockboxes 62 added under a node 56 are locked using the most recently added node key for the node 56. For a node 58(3) stored after the key revocation for node 56(1) as indicated by an arrow 174, a node key lockbox 62(1)(1) is locked using the node key stored in node key lockbox 62(1) of node 56(1)—i.e., the node key added by the key revocation. The revoked node key in node key lockbox 62(0) is not usable to unlock node key lockbox 62(1)(1) or other node key lockboxes 62 that were stored subsequent to the revocation. Accordingly, the revoked node key does not provide access to the node key stored in node key lockbox 62(1)(1) to allow the reference 60 of node 58(3) to be decrypted.
A node key added as part of a key revocation for a node 56 is usable to unlock all node key lockboxes 62 added under the node 56 after the key revocation. Thus, the node key from node key lockbox 62(1) is usable to unlock node key lockbox 62(1)(1) in node 58(3) to access the node key that allows the reference 60 of node 58(3) to be decrypted. For node key lockboxes 62 added under the node 56 prior the key revocation, the new node key is rotated backwards to obtain the revoked node key. Thus, the node key from node key lockbox 62(1) is rotated backwards to obtain the revoked node key, which is also stored in node key lockbox 62(0), that unlocks node key lockboxes 62(0)(1) and 62(0)(2) for nodes 58(1) and 58(2).
Node keys from all nodes 54 and 56 above a revoked node 56 where a key revocation occurred remain usable to unlock all node key lockboxes 62 at and below the revoked node 56. Thus, key revocation does not affect access for node keys above a revoked node 56.
Referring back to
In
The revoked node key in node key lockbox 62(2) retains the ability to unlock node key lockboxes 62(2)(1) and 62(2)(2) of nodes 56(3) and 56(4), respectively, that were stored prior to time tR as indicated by arrows 182 and 192. Similarly, the node key of node key lockbox 62(2)(1) retains the ability to unlock node key lockboxes 62(2)(1)(1) and 62(2)(1)(2) of nodes 58(4) and 58(5).
Node key lockbox 62(3)(3) of a node 56(5) stored after the key revocation for node 56(2), as indicated by an arrow 184, is locked using the node key stored in node key lockbox 62(3) of node 56(2). Similarly, node key lockbox 62(3)(1)(1) of a node 58(6) stored after the key revocation for node 56(2) and propagation to node 56(3), as indicated by an arrow 194, is locked using the node key stored in node key lockbox 62(3)(1) of node 56(3). The revoked node key in node key lockbox 62(2) is not usable to unlock node key lockboxes 62(3)(1) or 62(3)(3).
The propagated node key from node key lockbox 62(3)(1) is usable to unlock node key lockbox 63(3)(1)(1) in node 58(6) to access the node key that allows the reference 60 of node 58(6) to be decrypted. The node key from node key lockbox 62(3)(1) is rotated backwards to obtain the node key stored in node key lockbox 62(2)(1) that unlocks node key lockboxes 62(2)(1)(1) and 62(2)(1)(2) for nodes 58(4) and 58(5).
With the key revocation method of
Participant systems 30 that manage subtrees of metadata tree 50 use node and record seeds generated from the subtree node and subtree record keys, respectively, of the corresponding subtree nodes 54 to perform the above key rotations. The node seed for a node key lockbox 62 of a node 51 may be computed as a hash of the node identifier 91 (shown in
The above embodiments may advantageously allow healthcare participants to securely manage and share EHRs in a common encrypted data store using a metadata tree with hierarchical lockboxes. Healthcare participants control the ability of others healthcare participants to access and store selected EHRs of a patient using node and record keys for each node in the metadata tree. By providing subtree keys derived from a patient key to selected healthcare providers, a patient maintains the ability to access all of the EHRs of the patient using the patient key. Healthcare participants, including the patient, also retain the ability to selectively revoke access of other healthcare participants using key revocation at any level of the metadata tree.
This application claims priority to U.S. Provisional Patent Application No. 61/683,708, entitled “Hierarchical Lockboxes to Enable Sharing of Metadata and Data Records in the Cloud-Based EHR Store”, and filed Aug. 15, 2012. The disclosure of this application is incorporated by reference herein.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US12/56142 | 9/19/2012 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 61683708 | Aug 2012 | US |
