This application claims priority to U.S. Provisional Patent Application No. 61/683,694, entitled “Secure Storing and Sharing of Electronic Medical Records in the Cloud Environment”, and filed Aug. 15, 2012. The disclosure of this application is incorporated by reference herein.
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) storage 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 tree for each patient that provides a mapping to the EHRs of a given patient in the encrypted data store. Each EHR is uniquely encrypted using a patient key, a provider key, and a location corresponding to the EHR in the metadata tree prior to being stored in the encrypted data store. The metadata tree for each patient is visible to healthcare participants, such as healthcare providers, to allow the participants to store and access EHRs of patients.
To allow EHRs to be stored in the encrypted data store, each healthcare provider uses a unique provider key for each patient (referred to herein as Kpatient, provider) that is generated based on a corresponding patient key (referred to herein as Kpatient) of a patient and a provider identifier (referred to herein as provider-id). To store an EHR of a patient, a provider accesses the metadata tree for the patient and determines a location for the EHR in the metadata tree. The provider then generates a record key (referred to herein as Krecord) based on the provider key and the location in the metadata tree, encrypts the EHR using the record key, stores the encrypted EHR in the encrypted data store, and updates the metadata tree to include a reference to the EHR at the determined location. The provider may also generate and share a record key with another healthcare participant to allow the participant to store EHRs on behalf of the provider.
To access an EHR of a patient, a provider accesses the metadata tree for the patient and determines the location that corresponds to the EHR in the metadata tree. If the provider generated the EHR (e.g., if the EHR is one of the provider's records), then the provider accesses the EHR from the encrypted data store, generates the record key based on the provider key and the location of the reference to the EHR in the metadata tree, and decrypts the EHR using the record key. If the provider did not generate the EHR (e.g., if the EHR was generated by another provider), then the provider requests and receives the record key from the other provider or the patient, accesses the EHR from the encrypted data store, and decrypts the EHR using the record key.
Because provider and record keys are generated based on patient keys, patients have the ability to access all records from all providers using the metadata tree. Patients, as well as providers that generate EHRs, may share EHRs with other providers by generating the record keys for selected EHRs and providing the record keys to the other providers. The other providers may select EHRs in which to request access using the metadata tree for the patient. Accordingly, the processing environment described herein enables providers from different healthcare institutions to directly store EHRs of a patient in a common data store and provide access to selected EHRs to other providers.
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 provides 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 “patient key” refers to an encryption key of a patient. The term “provider key” refers to an encryption key that is generated based on a patient key and a provider identifier. The term “record key” refers to an encryption key that is generated based on a provider key and a location in a metadata tree of a patient that corresponds to an EHR of the patient. The term “shared key” refers to a record key that is provided from a patient to a provider that did not generate a given EHR or from a provider that generated a given EHR to another, unaffiliated provider.
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.
Environment 10 provides the ability to create and manage EHRs of patients including a patient 12 that corresponds to patient system 20 (other patients and patient systems not shown). In one embodiment, patient 12 interacts with patient system 20 to register with EHR manager 40 using a patient manager 42. Patient manager 42 causes patient information of patient 12 to be received and stored in a patient database 44 and initializes a metadata tree 70 (shown in
Patient 12 communicates with EHR store 50 using a data access adaptor 24 in patient system 20 to access, store, manage, and share encrypted EHRs 80 of patient 12 (shown in
Providers (not shown) interact with corresponding provider systems 30 to register with EHR manager 40 and receive a corresponding provider identifier 31. A provider manager 46 causes provider information of providers to be received and stored in a provider database 48. Provider manager 46 assigns a provider identifier (provider-id) to each provider and stores the provider-ids in provider database 48. Each provider-id represents information that may be used in combination with a patient key to generate a provider key (Kpatient, provider) for each patient of the provider. Provider manager 46 may provide provider-ids 31 to provider systems 30 in any suitable way such as by transmitting provider-ids 31 to provider systems 30 using communications network 60.
Provider keys for each patient may be generated by patients (e.g., patient 12). To generate a provider key 32, patient system 20 or another suitable processing system (not shown) generates a unique provider key 32 for patient 12 based on patient key 22 and a corresponding provider-id 31. For example, patient system 20 generates a provider key 32(1) based on patient key 22 and provider-id 31(1) and provides provider key 32(1) to provider system 30(1) in any suitable secure way such as via a smart card or via communications network 60. In one embodiment, patient system 20 generates provider keys 32 for each provider using a cryptographic keyed, one-way hash function that generates provider keys 32 as a function of patient key 22 and corresponding provider-ids 31. In other embodiments, other suitable functions may be used to generate provider keys 32 based on patient keys 22 and provider-ids 31. As may be seen, each provider maintains a single provider key 32 for each patient (e.g., each provider system 30 stores a provider key 32 for patient 12).
Provider keys 32 allow a provider to generate encrypted EHRs 80 for patient 12 and store encrypted EHRs 80 in encrypted data store 54. Providers access EHR store 50 using a corresponding data access adaptor 34 to access, store, manage, and share encrypted EHRs 80 of patient 12. Data access adaptor 34 communicates with data access front 52 on EHR store 50 using communications network 60 to access encrypted data store 54, metadata store 56, and audit log 58 in EHR store 50 as described in additional detail below.
In EHR store 50, encrypted data store 54 stores encrypted EHRs 80 of patient 12 as well as encrypted EHRs of other patients (not shown). Encrypted data store 54 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 54 does not include encryption keys (i.e., record keys) for the EHRs, encrypted data store 54 does not need to be a trusted data store (e.g., encrypted data store 54 may be owned or operated by one or more untrusted third parties).
Metadata store 56 includes metadata tree 70 for patient 12 as well as metadata trees of other patients (not shown). As shown in
Metadata tree 70 allows unaffiliated providers (e.g., providers practicing under different, unrelated business entities) to store different encrypted EHRs 80 of patient 12 to encrypted data store 54. 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. Providers may use metadata tree 70 to determine which encrypted EHRs 80 they need to access and can request access (i.e., record keys) from other providers that generated the needed encrypted EHRs 80 or patient 12 as described in additional detail below.
EHR store 50 maintains audit log 58 to log all data accesses to encrypted data store 54 and metadata store 56. Audit log 58 may be used for audit or other suitable purposes.
Communications network 60 includes any suitable type, number, and combination of wired and/or wireless communications devices that allow patient system 20, provider systems 30, EHR manager 40, and EHR store 50 to communicate with one another.
Environment 10 including, patient system 20, provider systems 30, EHR manager 40, and EHR store 50 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. In addition, data access front 52, encrypted data store 54, metadata store 56, and audit log 58 may be implemented using different processing systems in some embodiments. Embodiments of patient system 20 and provider systems 30 are shown in
Provider 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 provider system 30 to communicate across one or more wired or wireless networks such as communications network 60 (shown in
Data access adaptor 34 includes instructions that, when executed by processors 102, causes processors 102 to perform the functions of data access adaptor 34 that will now be described with reference to
Referring to
Data access adaptor 34 provides encrypted EHR 120 to encrypted data store 54 through data access front 52 as indicated by an arrow 146. Encrypted data store 54 provides a status to data access adaptor 34 through data access front 52 as indicated by an arrow 147. If the status indicates that encrypted EHR 120 was not stored successfully, then data access adaptor 34 may retry the store. Once the store is successful, data access adaptor 34 updates metadata tree 70 to add a leaf node 76 to include a reference 78 to the successfully stored encrypted EHR 80 in encrypted data store 54 and provides the updated metadata tree 70 to metadata store 56 through data access front 52 as indicated by an arrow 148. Metadata store 56 provides a status to data access adaptor 34 through data access front 52 as indicated by an arrow 149. If the status indicates that the updated metadata tree 70 was not stored successfully, then data access adaptor 34 may retry the update.
Data access adaptor 34 repeats the process shown in
Once a provider stores an encrypted EHR 80 to encrypted data store 54, the provider may access the encrypted EHR 80 from encrypted data store 54 as shown in
Referring to
Data access adaptor 34 accesses the encrypted EHR 80 from encrypted data store 54 through data access front 52 as indicated by an arrow 156. Encrypted data store 54 provides the desired encrypted EHR 80 through data access front 52 as indicated by an arrow 157. Data access adaptor 34 stores the encrypted EHR 80 (shown as encrypted EHR 120) and decrypts encrypted EHR 120 into a decrypted EHR 110 using record key 114 as indicated by an arrow 158. Data access adaptor 34 displays decrypted EHR 110 to the provider as indicated by an arrow 159.
Data access adaptor 34 repeats the process shown in
Patient system 20 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 202 is configured to access and execute instructions stored in memory system 204 and to access and store data in memory system 204. Memory system 204 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 206 include any suitable type, number, and/or configuration of communications devices configured to allow patient system 20 to communicate across one or more wired or wireless networks such as communications network 60 (shown in
Data access adaptor 24 includes instructions that, when executed by processors 202, causes processors 202 to perform the functions of data access adaptor 24 that will now be described with reference to
Referring to
Data access adaptor 24 accesses the encrypted EHR 80 from encrypted data store 54 through data access front 52 as indicated by an arrow 167. Encrypted data store 54 provides the encrypted EHR 80 through data access front 52 as indicated by an arrow 168. Data access adaptor 24 stores the encrypted EHR 80 (shown as encrypted EHR 220 in
Data access adaptor 24 repeats the process shown in
As described above, both providers that generate encrypted EHRs 80 and patient 12 may generate record keys 114 and 214, respectively, which are used to decrypt the encrypted EHRs 80. To share an encrypted EHR 80 with another provider, either the provider that generates the encrypted EHR 80 or patient 12 shares record key 114 or 214, respectively, to allow the other provider to access and decrypt the encrypted EHR 80.
Referring back to
Referring to
Data access adaptor 34 accesses the encrypted EHR 80 from encrypted data store 54 through data access front 52 as indicated by an arrow 186. Encrypted data store 54 provides the desired encrypted EHR 80 through data access front 52 as indicated by an arrow 187. Data access adaptor 34 stores the encrypted EHR 80 (shown as encrypted EHR 120) and decrypts encrypted EHR 120 into a decrypted EHR 110 using shared key 116 as indicated by an arrow 188. Data access adaptor 34 displays decrypted EHR 110 to the provider as indicated by an arrow 189.
Data access adaptor 34 repeats the process shown in
Providers may also store encrypted EHRs 120 on behalf of other providers by using shared key 116 in a variation of the embodiment of
The above embodiments may advantageously allow patients to securely manage access to EHRs created by different healthcare providers in a common encrypted data store. The embodiments allow a patient to maintain a single encryption key and allow providers to maintain a single encryption key per patient. The patient may access all EHRs using the patient key, and providers may access all EHRs using either a provider key or a shared key from another provider or the patient. In addition, the metadata tree provides the patient and providers with the ability to navigate a patient's entire health history while preserving privacy and security. As a result, the embodiments may shift the primary responsibility of making record access decisions to the providers while ensuring that the patient has access to all EHRs at any time.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/US2012/053215 | 8/30/2012 | WO | 00 | 2/13/2015 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2014/028035 | 2/20/2014 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
20030033169 | Dew | Feb 2003 | A1 |
20030074564 | Peterson | Apr 2003 | A1 |
20030200213 | Charlot et al. | Oct 2003 | A1 |
20050256742 | Kohan et al. | Nov 2005 | A1 |
20080172737 | Shen et al. | Jul 2008 | A1 |
20090112882 | Maresh | Apr 2009 | A1 |
20090150289 | Joe et al. | Jun 2009 | A1 |
20090150292 | Trinh et al. | Jun 2009 | A1 |
20090193267 | Chung | Jul 2009 | A1 |
20100030690 | Herlitz | Feb 2010 | A1 |
20130006865 | Spates | Jan 2013 | A1 |
Number | Date | Country |
---|---|---|
102331998 | Jan 2012 | CN |
102457508 | May 2012 | CN |
H09-114741 | May 1997 | JP |
2005-115565 | Apr 2005 | JP |
2005-539423 | Dec 2005 | JP |
2006-099548 | Apr 2006 | JP |
2008-237426 | Oct 2008 | JP |
10-2002-0026284 | Apr 2002 | KR |
Entry |
---|
International Search Report and Written Opinion of the International Searching Authority, dated Feb. 27, 2013; issued in related PCT Application No. PCT/US2012/053215. |
Li, Z-R et al, “A Secure Electronic Medical Record Sharing Mechanism int he Cloud Computing Platform”, Jun. 14-17, 2011. |
Zhang, R et al, “Security Models and Requirements for Healthcare Application Clouds”, Jul. 5-10, 2010. |
Extended European Search Report dated Mar. 6, 2017 for EP Application No. 12891380.3; pp. 12. |
Josh Benaloh et al: “Patient Controlled Encryption: Ensuring Privacy of Electronical Medical Records” , CCSW '09: Proceedings of the 2009 ACM Workshop on Cloud Computing Security, ACM, US, Nov. 13, 2009 (Nov. 13, 2009), pp. 103-114, XP058150172. |
Shivaramakrishnan Narayan et al: “Privacy preserving EHR system using attribute-based infrastructure”, Proceedings of the 2010 ACM Workshop on Cloud Computing Secruity Workshop, CCSW, '10, ACM Press, New York, New York, USA, Oct. 8, 2010 (Oct. 8, 2010), pp. 47-52, XP058182232. |
Number | Date | Country | |
---|---|---|---|
20150220746 A1 | Aug 2015 | US |