EP3219048A1 - System and method for securely storing and sharing information - Google Patents

Abstract

A method for any community of interest to conduct secure exchange of encrypted data using a three-party security mechanism consisting of key masters, registries and cloud lockboxes. The registries establish unique identities, verify authenticity, and create directories of individuals, members, cloud lockboxes and other registries. The registries manage permissions lists communicated to the cloud lockboxes as well as detecting and halting anomalous activity. The key masters operated by members to manage keys for individuals, handle encryption and decryption and conduct key exchanges with other members. The cloud lockboxes manage file storage, retrieval and access control. Related application programming interfaces support multiple levels of integration and generate metadata specific to the needs of the community of interest. Community of interest establishes operating parameters including: selecting an encryption algorithm, establishing identity verification processes and selecting a security level. The design supports several other key features.

Description

SYSTEM AND METHOD FOR SECURELY

STORING AND SHARING INFORMATIO

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001 ] This application claims priority to U.S. Application Serial No. i 4/539,614 filed on November 12, 2014, which is a continuation-in-part of U.S. Application Serial No. 13/665,861 filed on October 31, 2012, which claims priority to U.S. Provisional

Patent Application Serial No. 61/553,883 entitled "System and Method for Securely Storing and Sharing Information" filed October 31 , 201 1, al l of which are incorporated by reference in its entirety as if fully set forth herein.

TECHNICAL FIELD

[0002] The present application generally relates to systems, devices, and methods to conduct the secure exchange of encrypted data using a three-party security mechanism consisting of the members, the registries, and the cloud lockboxes. Control of the private key required for decryption is maintained by the information owner. More specifically, the mechanism establishes unique identities, verifies authenticity, generates and securely exchanges encryption key pairs, encrypts, transmits, receives and decrypts data to/from cloud lockboxes; creates and appends metadata specific to the applications and retrieves and/or acts upon metadata. The related application programming interfaces support multiple levels of integration and generate metadata specific to the needs of the application . A community of interest establishes operating parameters including; selecting an encryption algorithm, establishing identity verification processes, and selecting a security level. The design supports several other key features using operating protocols and/or metadata,

BACKGROUND

[0003] Certain methods and systems have previously been used for securely storing and sharing confidential information. Some such systems employ cryptography, such as public/private key encryption, to protect information and/or identity management. [Θ004] Cryptography can provide strong protection, but the key exchange process makes sharing encrypted data clumsy and sometimes insecure. Weak, absent, or disconnected identity verification also degrades the effectiveness.

[0005] Accordingly, there is a need for systems, methods, and devices that enable secure exchange of encryption keys among any community of interest. Specifically, a need exists for a system for securely storing and sharing information which manages encryption keys separately from the encrypted information to limit access to underlying information only to those who ate authorized and that integrated identity management and verifica tion as part of the process.

SUMMARY

(0006] According to a first aspect of the present application, a method to conduct secure exchange of encrypted data using a three-party security mechanism consisting of the key masters operated by the members of the community of interest, the registries, and the cloud lockboxes. The registries establish unique identities, verify authenticity, and create directories of individuals, members, organizations, key masters, cloud lockboxes and. other registries. The registries manage permissions lists communicated to the cloud lockboxes, as well as detecting and halting anomalous activity. The members operate key master software, preferabl provisioned as an appliance, to create and manage keys for individuals, handle encryption, and decryption and conduct key exchanges with other members. The cloud lockboxes manage file storage, retrieval, and. access control. The related appiication programming interfaces support with multiple levels of integration aud generate metadata specific to the needs of the application. A community of interest establishes operating parameters including^', selecting an encryption algorithm, establishing identity verification processes, and selecting a security level.

(0007] According to the second aspect of die present application, a method for creating a community of interest is disclosed. Any community of interest can establish its own operating parameters including; selecting a public key encryption algorithm, selecting a registry or registries, establishing related membership requirements and identity verification processes, selecting a cloud storage provider or providers, selecting the optional security features, and determining the minimum application integration levels. [0008] According to the third aspect of the present application, a method for creating features through protocols operating among the parties and metadata is disclosed. The protocols and metadata enable features including: detection and halting of anomalous access, time-to-live settings on the sharing of data; key change and access revocation processes; key and file recovery processes, de-identification of data to feed research databases, and emergency access protocols. The design supports addition of features by leveraging existing design elements and expanding operating protocols and metadata.

[0009] According to the fourth aspect of the present application, a method for minimizing the exposure of data to system administrators is disclosed. The protected data is encrypted prior to reaching the cloud lockbox, the cloud lockbo never has the decryption key, thus the system administrator performing duties for performance optimization and maintenance of the clood lockboxes has access to the encrypted data but does not have the decryption key. Further, when application owners elect to integrate the present application into their native data storage solutions, the benefits of this aspect extend into the premises-based or cloud-based storage of the application itself.

[001.0] According to the fifth aspect of the present application, a method for integrating with applications and creation of hybrid cloud and on-preraises data storage solutions is disclosed. The invention provides robust approaches for the integratio of an application into the community of interest by providing both published and unpublished application programming interfaces supporting multiple levels of application integration ranging from native integration to the use of industry-standard interfaces to simple archiving solutions. The method facilitates the creation of hybrid, cloud and cm-premises storage solutions with predictive caching; and provides a method to integrate disparate applications within a single enterprise or across multiple enterprises.

[00 1 ] According to the sixth aspect of the present application, a method for offering a variety of security levels is disclosed. Th invention can b deployed in various ways to achieve the security level desired by the community of interest ranging from; a. the stringent Federal Information Processing Standards 140-2 Level 4;

b. rigorous civilian standards for protecting confidentiality such as Health

Information Portability and Accountability Act;

c. relatively Sow level securit required for non-sensitive information.

The design traverses these various security levels based on; d. Deploying the key master as an appliance thus keeping critical processes such as key management, encryption and decryption within a hardened environment rather than running this software on a. general purpose computer; e. Depth of integration with the applications; f. Optional registered IP address restrictions.

BR IEF DESCR IPTION OF THE DR AWINGS

10012] The accompanying figures, which are incorporated in and constitute a part of the specification, illustrate various example systems, devices methods, and so on, and are used merely to illustrate various example embodiments. It should be noted that various componenis depicted in the figures may not be drawn to scale, and that the various assemblies and designs depicted in the figures are presented for purposes of illustration only and should not be considered in any way as limiting.

[0013] Figure 1 is a schematic block diagram illustrating an example environment for the systems, devices and methods of the present application.

[0014] Figure 2 is a schematic block diagram further illustrating operation of the UHE of Figure 1.

[0015] Figure 3 is a schematic block diagram illustrating an HCP registration process using the UHE of Figure 1.

[0016] Figure 4 is a schematic block diagram illustrating a patient registration process using the UHE of Figure I .

[8017] Figure 5 is a schematic block diagram illustrating the use of activity logs using the UHE of Figure 1.

[0018] Figure 6 is a schematic block diagram illustrating sharing write-only data using the UHE of Figure 1.

100 J 9 j Figure 7 is a schematic block diagram illustrating communications in an emergency situation using the UHE of Figure 1.

[0020] Figure 8 is a schematic block diagram illustrating mechanisms for identifying fraud, waste and abuse using the UHE of Figure 1. [0021] Figure 9 is a schematic block diagram illustrating the generation of de- identified patient data using the L I If- of Figure 1.

J 0022 J Figure 10 is a schematic block diagram illustrating the key change and/or revocation of access using the UHE of Figure I.

[0023] Figure 11 is a schematic biock diagram illustrating the key recovery process using the UHE of Figure 1 ,

(0024] Figure 12 is a schematic block diagram illustrating the ability to support multiple participant software modules using the UHE of Figure 1.

10025 j Figure 13 is a schematic block diagram illustrating other alteniate en vironments for the systems, devices, and methods of the present appiication.

[0026] Figures 14 A and 1 B are a schematic block diagrams illustrating other alternate environments for the systems, devices, and methods of the present application.

[0027] Figure 15 is a schematic block diagram illustrating other alternate environments for the systems, devices, and methods of the present application.

[0028] Figure 16 is schematic block diagram illustrating an alternate environment for the systems, devices, and methods of the present application for use in the legal industry.

[0029] Figure 17 is a schematic block diagram illustrating an alternate environment for the systems, devices, and methods of the present appi ication for use in the real estate industry.

[0030] Figure 18 is a schematic block diagram illustrating an alternate environment for the systems, devices, and methods of the present application for use in the real estate industry.

DRAWING REFERENCE NUMERALS

[0031] The following reference characters identify the associated elements depicted in the drawings describing the present invention.

100 Exemplary environment

101 Medical Home HCP 1 10 HCP #1 Electronic Health Record Software

1 1 1 Activity Log UHE API

1 12 Key Master (KM)

114 Patient Portal

1 16 Patient

1 18 Longitudinal De -Identified Research Data

120 HIE Reaistrv

130 Cloud Lockbox

140 Secondary HCP

1.41 Other HCPs

142 HCP #2 EHR

143 Other HCP's EHR

H4 Pharmacies

145 Pharmacy Software

146 Write-Only-Members

147 Write-Only Software (e.g. Labs, Mobile Health, etc.)

146 A Mobile Health Monitor Software

I46B Lab Software

146C Other Write-Only Software

148 Metadata-Only Members

149 Metadata-Only Software (e.g. Payers)

150 Payer

151 Payer's Software

152 HCP #3 EHR

210 Encrypted EHR Files

10- A Encrypted HCP #2 Files

21 1 File Handler

212 Permissions Directory

214 Receptors

216 Activity Log Cloud Lockbox

250 Native EHR Files

260 API Engine

Unified Health Exchange (UHE) Application Programming

261 Interface (UHE-API) (U-API)

262 Key Manager and File Broker

264 Activity Log File Broker

281 HCP Director^y

Patient Directory and Permissions

283 Cloud Lockbox Directory

284 Registry Directory

310 Government and industry DBs

412 information Owner Key Master 420-A HIE Registry - Health Care Community-of- Interest

420-B Legal Exchange Registry - Legal Community-of-interest

430-A Cloud Lockbox for Health Care Community-of- interest

430-B Cloud Lockbox for Legal Conmiumiy-of-mterest

460 API Engine

461 Application Programming interface

462-A Key Manager and File Broker- A

462-B Key Manager and File Broker ~B

610 Emergency Room HCP

612 Emergency Room HCP EHR

10A-910E HCPs

920A-920C HIE Registries

loio ecp i

1011 HCP #2

1048 Write-Only Member(s)

1030A Cloud Lockbo #1

I030B Cloud Lockbox #2

DETAI LED DESCRIPTION

[0032] This present application describes systems, devices, and methods for providing secure exchange of encrypted data using a three-party security mechanism consisting of the key masters operated by the members, the registries, and the cloud lockboxes phis the application programming interfaces.

^» A member may be a individual directly participating in a community of interest, an organization participating in a community of interest for its own purposes, or an organization participating in a community of interest to represent multiple individuals in which ease the individual is participating by proxy.

• The members use a key master software {preferably provisioned as an appliance) to:

o Verify the identity and authority of the member in communications with the registry; o Establish a unique identity and verify' authenticity for each individual and organization in communications with the registry; o Generate individual public-private key pairs for each individual being represented by the member and for the organization itself (if applicable ); o Receive an individual's data and related metadata from the application programmi ng kite rfac e ; o Encrypt the data and related metadaia with the individual's public key; o In some uses, encrypt some or all of the metadata with public key of metada ta-only ree ipient; o Create non -sensitive transactional metadata and append to the files; o Transmit the encrypted data, metadata, and transactional metadata to cloud lockbox; o Control of the individual's private key (required for decryption) retained by the member's key master; o Retrieve files from cloud iockbox and decrypt with an individual's private key; o With authorisation by the individual:

Securely transmit an individual's private key to another member's key master to permit decryption of the individual's files;

- Update permissions lists at registries; o Transmit activity records of key creation, file retrieval requests, private key exchanges and. other activities to the registries;

The registries : o Establish identity and verify authenticity of members, organizations, other registries and cioud lockboxes: o Establish unique identities for each individual represented in a. community of interest in communications with the key masters, a process which may include communications with additional registries if more than one registry is operational for the community of interest; o Maintain directories of individuals, members, organizations, and cloud lockboxes and other registries; o Function as a clearinghouse for members to retrieve public keys of other members, organizations, and cloud lockboxes; o Manage individual-level access control lists and communicate lists to cloud lockboxes tor controlling access to data files; o Receive activity records from the key masters, the cloud lockboxes, and the application programming interfaces;

Analyze activity logs to detect and halt anomalous access;

Provide the members with, alerts regarding anomalous access and with routine access to activity logs;

* The cloud lockboxes; o Store encrypted data, metadata, and appended transactional metadata; o Create receptors fo stored data to serve as claim tickets for the members; o Utilize access control lists received from registries to determine which individuals' files a given member may store and retrieve; o Transmit activity records of file retrieval requests to the registries.

^» The related application programming interfaces offer flexibility in adapting to the needs of the specific community of interest and/or of the application owner. The application programming interfaces; o Consist of both pubiically published and private proprietary methods to integrate to the applications being used by members of a community of interest; o Support multiple levels of application integration ranging from native integration, in which this mechanism's encryption and protocols are extended into the data stores of the application, to the use of industry- standard interfaces, and to simple archiving solutions and many gradations in between; o Convert data to/from proprietary to industry standard formats; o Convert data between key- value data stores to/from relational databases; o Generate metadata specific to the application that can either be:

- Appended to the data and encrypted;

Encrypted separately from the data so a member could be granted metadata only access;

- Left unencrypted and added to the transactional metadata created by key master; o Map individuals^" identification numbers in applications to community of interest identification numbers for the same individuals; o Enable the creation of hybrid cloud and on-premises storage solutions; o Transmit log records of file retrieval requests, access revocations and other activities to the registries.

[0033] Digital signatures verify the identity of members, registries, and cloud lockboxes for all communications and protocols. Encryption protects all sensitive data both in motion and a rest. Optional IP address restrictions add another level to the security model. Appliance -based option for the encryption, decryption and key management further bolsters security.

[0034] Any community of interest can establish its own operating parameters including:

" Selecting a public key encryption algorithm; ■ Selecting a registry or registries;

• Establishing reiated membership requirements and identity verification thresholds;

^« Selecting a cloud storage provider or providers at which to establish Cloud Lockboxes;

^» Selecting from among the optional security measures;

• Determining the minimum application integration levels,

[0035] The method also provides protocols and metadata to enable features such as: ^« Time-to-live settings to limit the duration of a member's access to the data of an individual's data;

^■ Key change and file access revocation processes;

* Key and tile recovery processes;

^» Ability to de-identify the individual's files to facilitate academic or business research.

* Emergency access.

* The design supports addition of features by ieveraging existing design elements and expanding operating protocols and related metadata.

[0036] The method minimizes the exposure of data to system administrators because:

" The protected data is encrypted prior to reaching the cloud lockbox;

" The cloud lockbox never has the decryption key;

" The system administrators performing duties for performance optimization and maintenance of the cloud lockboxes and any applications integrating the mechanism have access to the encrypted data but does not have the decryption keys.

[0037] The method can be deployed in various ways to achieve the security level desired by the community of interest ranging from:

^» The stringent Federal Information Processing Standards 140-2 Level 4;

^■ Rigorous civilian standards for protecting confidentiality such as Health Information Portabilit and Accountability Act;

" The relatively low level security required for non-sensitive information snd many levels in between.

* The design traverses these various security levels based on: o Deploying the key master as an appliances thus keeping critical processes such as key management, encryption and decryption within a hardened environment rather than running this software on a genera! purpose computer; o Depth of integration with the applications; o Optional registered IP address restrictions.

[0038] The method provides a solution to integrate disparate applications within a single enterprise or across multiple enteipnses by converting data in the application programming interfaces to either industry standard representations or proprietary common formats.

(0039] The design supports an approach for storing unstructured data in a key-value (object) data, stores to simplify sharing and reduces the need for a relational database, yet retains the ability to transfer such information io/from relational databases,

[0040] The desig supports the ability for the individual to review the contents and audit activity on his/her files.

(0041 ] The design provides the capability to provide a holistic view of the individual's files for individual or authorized member.

[0042] The design supports existence of multiple registries and multiple cloud lockboxes.

[0043 { The design supports use of multiple encryption algorithms simultaneously from a single key master for participation in multiple communiiy-of-interest networks.

[0044] The systems, devices, and methods of the present application are well suited to operate in any industry requiring secure storage and exchange of information. The present application will describe an exemplary embodiment in the health care industry. Of course, one of ordinary skill in the art will appreciate that the systems, devices, and methods of the present application will have applicability in other industries, such as the legal service industry and the real estate industry, for example.

[0045] Recently, the storage requirements with respect to patient files and the Federal mandates to share records with other health care providers and with patients have presented daunting problems for those in the health care industry. The exemplary systems and methods described herein, generall referred to as a unified health exchange ("UHE"),∞ay be used to solve many of the problems created by the increased storage and usage demands in the industry. The operation of the overall mechanism of the UHE will be described with particular applicability to the health care industry. In the health care application of the design consi der the correspondence in the fol lowing Table T

Table I

Problems in the Health Care Industry

(0046] The UHE described herein solves critical and previously intractable challenges in the health care industry while simultaneously providing efficient use of resources and generating cost savings. Health care providers ("HCPs") face mounting expenses and downward pressure on reimbursements. Federal mandates require layers of expensive technology that increase the cost of doing business.

Increased Storage Demands j 0471 Storage demands for Electronic Health Records ("EHR") continue to expand dramatically, driven by factors including high resolution imaging data, structured and unstructured data, longitudinal care needs and regulatory retention requirements. The combination of increased demand and high cost storage results in rapidly growing IT costs for the HCPs.

(0048] Cloud services can dramatically reduce this cost, but cloud providers have been wary of the liability of storing health care records. The Unified Health Exchange solution encrypts records prior to moving them to the cloud lockboxes and the cloud lockboxes and underlying cloud providers never possess the decryption key. This combination eliminates the need for the cloud providers to conduct breach notifications, greatly diminishing their HIPAA exposure.

[0049] By relying on the cloud lockboxes for long-term record retention, the HCPs can dramatically reduce the volume and thus the cost for on~premises computer storage. By leveraging intelligent archiving, the HCPs may elect to retain onsite only the records needed in the short term. With, deployment of a UHE appliance providing predictive caching, the HC Ps could eliminate storage of patient files in their EHRs instead linking the underlying EHR tile management to the UHE model. Further, the UHE approach can eiimiiiate dupiicatioii of records within a single HCP as well as the duplication of records received from other health care providers.

Financially Sustainabie

[0050] Existing models for health information exchange involve cumbersome hierarchies of regional, state, and national exchanges that have failed to gain traction. The iiriaricial models underpinning most HIEs do not offer a sustainabie path, primarily because the current HIEs add incremental costs for HCPs at a time of great budget pressure. Health Care Providers are under increasing deadline pressure to achieve "meaningful use" of health information exchanges.

[0051] The Unified Health Exchange design enables HIE by default as a byproduct of the cost-saving storage arrangement with the cloud lockbox combined with the coordination functions of the HIE Registry. Thus the HCP saves money on storage and avoids the cost of supporting a separate HIE intra structure.

Medical Home

[0052] The emerging "medical home" concept offers tremendous promise for coordination of care to improve wellness and reduce costs. The lack of health information exchange continues to hamper implementation of the "medical home" and other innovations such as Accountable Care Organizations (ACOs), Unified Health Exchange consolidates patient records, offering the "medical home" a holistic picture of the patient, A "patient dashboard" may provide an easy overview of the patient's medical history and quick revie of recent activity and condition.

[8053] Providers and payers struggle to identify fraud, waste, and abuse. The disparate sources of information make compiling a complete view of a patient's care

J.4 difficult. Once widely adopted. Unified Health Exchange can provide a single source of information for a comprehensive utilization review.

[0054] Persona! Health Records ("PHR") have been envisioned as a key technology enabling patient education and involvement. Unfortunately, early PHR efforts have failed to:

* Win support from healt care providers.

* Gain the trust of wary consumers over privacy concerns.

[0055] The Unified Health Exchang gives patients and/or their "medical home" unprecedented con trol over their medical records. Because the records are encrypted with individual keys, no one can decrypt the records until authorized for thai specific individual,

[0056] Computer savvy consumers are able to directly authorize an HCP to access records and also exercise the granularity to only provide permission for specitic classes of information. For instance, a podiatrist may not be allowed access to a patient's cardiac records. With Unified Health Exchange, the patient decides who sees what. Further, an audit log of access gives the patient complete visibility regarding who has accessed what and when.

[0057] For patients unable or not interested in controlling their own health records, the patient's "medical home" can serve as the patient's proxy by obtaining written sign- off similar to existing H1PAA forms to manage the access on behalf of the client.

[0058] The HIPAA and HITECH rules regarding the privacy of health records have created confusion and additional costs across the US health care industry. Unified Health Exchange reduces HIPAA responsibility for cloud lockboxes by encrypting the records. For HCPs, the more of their data they move to UHE, the less vulnerability they retain.

[0059] For the EHR vendors, each of the many HIEs utilize unique interfaces to their software, UHE offers a single interface through industry standard methods to connect to what could serve as a global HIE platform,

HUE Operating Environment

[0060] Referring now to Figure 1, there is illustrated an example operating environment 100 of the UHE. Example environment 100 may comprise a medical home

J.5 HCP 101, an EHR system 10, a patient portal 114, a Key Master 112, an HIE Registry 120, a Cloud Lockbox 130, and various HCPs 141-148. As illustrated, a unified health exchange application programming interface, UHE API 261, and a Key Master 112 may be integrated with medical home's HCP $ 1 EHR 110 to facilitate communication with HIE Registry 120.

[0061] Further, a patient 116 may communicate with Medical Home's EHR 110 via patieni portal 114. In addition, the Patient Portal 114 could utilized mobile interfaces to provide convenient interface to the Patient J 16 via web or mobile app.

[0062] In a typical operation, medical home's HCP #1 EHR 110 using the UHE API 261 and the Key Master 112 assigns a unique public-private key pair and registers patient 116 with HIE Registry 120. The public ke is provided to HIE Registry 120, and the private key is retained by medical home 101 in the Key Master 112 as the only entity initially authorized to decrypt patient files. This activity is depicted by reference numeral 1.

[0063] The HIE Registry 120 updates permissions directory at Cloud Lockbox 130 to authorize medical home^'s HCP 41 EHR 1 0 to write files for patient 114. This activity is depicted by reference numeral 2.

[0064] Medical Home's HCP #1 EHR 110 using the UHE API 261 and the Key Master 112 writes patieni files encrypted with the public key to the Cloud Lockbox 130, retaining onsite only what is needed in the short term. HCP 110 using the UHE API 261 and the Key Master 112 can retrieve files as needed for longitudinal patieni care scenarios. Medical Home HCP 110 using the UHE API 261 and the Key Master 112 can also access, retrieve, and decrypt files written for patient 116 by other participating entities, such as HCPs 141-1 8, This activity is depicted by reference numeral 3.

[0065] Patieni 116 authorizes Other HCP 141 to access files as depicted by reference numeral 4. Medical home HCP 110 using the UHE API 261 and the Key Master 112 updates permissions in HIE Registry 120 as depicted by reference numeral 1. H IE Registry 120 updates permissions at Cloud Lockbox 130 in routine synchronization process as depicted by reference numeral 2. Patient 116 can also audit access to his/her files as depicted by reference numeral 4. 10066] Medical home's HCP #\ EHR 110 using the UHE API 261 and the Key Master 1.12 sends private key of patient 116 directly to Other HCP's EHR 143 using Other HCP's 141 Key Master 112 and the UHE API 261. This exchange of private key is conducted via encrypted transmission verified with digital signatures using the respective organizations public/private key pairs. The key exchange bypasses both the HIE Registry 120 and the Cloud Lockbox 1.30. This activity is depicted by reference numeral 5.

[0067] Other HCP's EHR 143 can now retrieve, decrypt, and read files for the specific patient 1 16 using the patient's unique public/private key combination. Other HCP's EHR 143 can now aiso write files for patient 116 to same Cloud Lockbox 130 encrypted using the patient's public key. These activities are depicted by reference numeral 6. 0068] Participation by pharmacies 144, depicted by reference numeral 7, add a useful function for coordination of medication regimens.

[0069] Other entities such as labs and patient telemetry providers 146 can write files encrypted with the patient's public key, but cannot retrieve or decrypt, f ies. This reduces HIPAA liability for these entities, and such activities are depicted by reference numeral 8,

[0070] Patient-authorized payers 148 are provided limited access to patient files. For example, payers 148 may to review metadata but not detailed file information. This activity is depicted by reference numeral 9.

(0071] Further, patient's medical homes HCP #1 EHR 110 may securely contribute records to de-identified research databases 118, as depicted by reference numeral 10.

[0072] The exemplary system 100 provides a number of useful features including:

* Neither Cloud Lockbox 130 nor HIE Registry 120 ever have decryption keys, reducing H1PAA liability for these entities,

* HCPs 101 , 141, 144, 146 and 148 save resources through intelligent archiving, enabling them to retain only the files needed in the short term in expensive on-premises storage.

* Reductions in record duplication within and between HCP EHRs 1 0, 143 and related software 145, 147 and 149 also saves resources. * Design supports multiple cloud lockboxes 130 and multiple HIE Registries 120,

* Design supports a "glass break" scenario for emergency access to patient files.

* Design support key change process, key recovery process, file recovery process, waste/fraud/abuse detection, use of multiple encryption algorithms, and other features.

Unified Health Exchange Components

[0073] Referring now to Figure 2, there is illustrated a schematic block diagram further depicting operation of the UH E of Figure 1. Each HCP accessing the storage of Cloud Lockbo 130 may comprise or access an HIE Registry 120. In the illustrated example, medical home's BCP #.1 EHR. 110 utilizes UHE API 261 and Key Master 112 and secondary HCP 2 141 utilizes UHE API 261 and Key Master 112. The HIE Registry 120 provides the mechanisms and trust relationships for verifying unique identities, creating and updating patient -to-HCP and patient-to-cloud lockbox associations, and modifying permissions tables. Each HCP communicates with its associated H IE Registry 120 for patient identity matching to minimize duplication. Each H I E Registry 1 0 also retains mappings of public keys for patients, HCPs, payers and any other entities involved in UHE. Each HIE Registry 120 also catalogs authorized IP addresses for participating components for all participants.

[0074] Although a single Cloud Lockbox 130 is depicted in the example embodiment, it should be clear to those of ordinary skill in the art that multiple cloud lockboxes and/or multiple cloud storage servers may be employed. The cloud lockboxes, such as Cloud Lockbox 130, offer low cost, yet responsive storage for the HCPs Encrypted EHR files 210, which may include file metadata used for the indexing, searching, and features. The cloud lockboxes also retain a Permissions Directory 212 derived from the HIE Registry 1 0 for determining the mapping of which HCPs can read files for specific patients,

[0075] Each of the UHE API 261 comprises software integrated with the HCPs' Electronic Health Record ("EHR") system. The UHE API 261 communicates with the API Engine 260 in tire Key Master 112. In turn, the API Engine 260 communicates with the Key Manager and File Broker 262, also a component of the Key Master 112. The API Engine 260 provides a variety of interface options and policy enforcement function. Together these software modules cooperate with the HCP EHRs for issuing and/or managing patient public-private key combinations, interacting with the HIE registries and for reading/writing of files to the cloud ioekbox(s). Each Key Master J .1.2 also manages private key exchanges with other HCPs.

[0076J The UHE API 261 and the API Engine 260 may also convert proprietary data formats into standards-based formats. Likewise, when reading files from the cloud storage, the key master wouid convert standardized formats into proprietary formats for local EHR use.

10077] it should be appreciated that the Key Master 112 can be implemented as hardware, software, or a combination of both hardware and software. For example, the Key Master 112 can be implemented, preferably, as stand-alone appliance that can be inserted and integrated into an existing system architecture. In another example, the Registry & cioitd Interface 1 12 can be impiemented or installed onto a computer or other hardware identified and configured by a user. Such a computer may be a dedicated computer, for example, or may share resources between two or more applications or computing processes. A computer may be a suitable computing device having memory and a processor, and capable of storing program instructions in memory and executing the program instructions stored in memory using the processor.

Public Key Encry^ption and Digital Signatures

[0078] In a proxy operation of the design, the patient 116 selects one HCP. HCP 101 in the illustrated embodiment, to serve as his/her "medical home." This medical home HCP #1 EHR 110 using UHE API 261 and Key Master 112 generates a unique pair of encryption keys using a public -private key combination for the patient. The public key is shared with the HCP #1 EHR 110 but the private key is retained only in the Key Manager and File Broker 262 component of the Key Master J .1.2. This activity is depicted by reference numeral 2. j0 79j The '"public key" would not actually be shared with the general public, but rather it would be shared among HCPs participating in the HIE for file encryption and as a mechanism for identifying the unique patient 116. The public key would also be appended as unencrypted transactional metadata to the files, linking the file to the patient.

J. [0080] The private key, retained by the medical home, would be used to decrypt the data. The Cloud Lockbox would not have the ability to decrypt the files. Only HCPs authorized by the patient would receive the patient's private key,

(00811 HCPs, cloud lockboxes, and HIE registries also have organization-specific public-private keys utilized for secure communications and digital signatures among registrants.

[0082] Ail communications and updates among entities may be secured through digital signatures and encryption including exchanges between Cloud Lockbox 130 and HI E Registry 120, exchanges between Cloud Lockbox 130 and Key Master 112, between Key Masters 112 of different HCPs, between UHE API 261 and API Engine 260,

IP Address Restrictions

10083] In one example, within a given HCP, communications among components of the UHE and EHRs are restricted to known machine IP addresses to further increase security. Between HCPs, cloud lockboxes, and HIE registries, all communications may also be restricted to known machine ΪΡ address to further increase security. In particular, an accepted IP addresses list is maintained by the HIE Registry 1.20 and distributed along with public keys for these entities. When an individual patient elects to own and operate his/her own Key Master 112 as depicted in Figure 18, IP restrictions may also be utilized to provide one method to control access.

Unified Health Exchange Operation

[0084] The flow of the following permissions and file accesses are depicted in Figures 1 and 2:

1. HCP EUR 110, the medical home EH of patient 116, writes encrypted files to Cloud Lockbo 130 using UHE API 261 and Key Master 112. This includes the UHE API 261 converting the file into a UHE-eompatible forma and transmitting it to the API Engine 260 in the Key Master 112. The file may include metadata such as, but not limited to. Patient's 116 public key, type of file, and format of file { e.g. what type of reader might be required such as for PACS images). This activity is depicted by reference numeral 2.

2. The API Engine 260 transfers the file within the Key Master 112 to the Key Manager and File Broker 262. The Key Manager and File Broker 262 encrypts the patient's 1.16 file with patient's public key and transmits it to the Cloud Lockbox 1.3ft, thus already protected in motion. The files remain encrypted at rest on cloud server of Cloud Lockbo 130. This activity is depicted by reference numeral 3.

3. The Key Manager and File Broker 262 within the Key Master 12 is the sole location at the Patient's Medical Home 101. where the patient's 116 public-private key pair is retained. Neither Cloud Lockbo 130 nor HIE Registry 120 nor HCP #1 EHR 11.0 have the patient's private key, thus cannot decrypt files, reducing HIPAA liability. HCP EHR #1 110 has the authority to retrieve and decrypt the Patient's 1 6 files, but in order to do so must process the request through the Key Master 112 in which the private keys are retained in the Key Manager and File Broker 262. Further, the pennission to read and write files for the Patient 116 was initially established in the HCP and Patient registration processes detailed in sections describing Figure 3 and Figure 4.

4. Upon receipt of Patient 116 file from HCP #1 110 by Cloud Lockbo 130, File Handler 211 creates a HCP #1 110 specific Receptor 214 for the file. The Receptor 214, encrypted with HCP #1 's public key, includes a unique file ID, Patient's 116 public key, iirae-to-live setti gs (i nfi nity for creator of file) and other metadata. The file ID is used by the File Handler 211 as a storage location pointer of the file in Encrypted EHR Fi les 210 store. The file ID will not provide a mapping to Patient 116 identity,

5. Creation by Cloud Lockbox 130 of Receptor 214 and writing of EHR File 210 is recorded in Activity Log 216 at the HIE Registry 120 lor review by Patient 116 at will. This activity is depicted by reference numeral 5, Figure 5 explains the operation of the activity logs in detail.

Patient 116 authorizes Medical Home's HCP #1 EHR 110 to release records to Secondary HCP #2 EHR 141. Authorization granted via e-signature using patient portal 114 or via signed paper form. The Patient .1.16 also has the option of granting access to metadata only. This activity is depicted by reference numeral 1.

The Patient 116 also has the option of setting a time-to-live for files retrieved by HCP #2 141. The time-to-live feature limits the period of time that HCP #2 is authorized to retain the Patient's 116 files. The time-to-iive setting provides another layer of privacy protection that is included in the hierarchy of levels of integration of UHE into the EHR described later. Patient 116 may be made aware of compliance with time-to-live by HCP #2 141 or by HCP #1 110. Time-to-live settings for entities originating files will be set to infinity to enable use of IJ HE for archiving and for minimization or eventual elimination of local EHR files,

HCP #1 110 using IJHE API 261 and Key Master 11.2 updates HIE Registry 120 with additional access rights of HCP 141 to read specific patient's files. Updates may be secured through digital signature based exchanges between HCP #1 110 and HIE Registry 120. Selections by patient 116 of level of access, i.e. metadata only vs. full file access, tirne-to-live settings and other variables, also transmitted to HIE Registry 120 by HCP #1 110. This activity is depicted by reference numeral 4.

HIE Registry 120 updates Permissions Directory 212 of Cloud Lockbox 130 granting access to Patient's 116 files to HCP #2 141. Selections by patient 116 of level of access, i.e. metadata only vs. ful l file access, time-to-live settings and other variables, also transmitted to Cloud Lockbox .130 by HIE Registry 120. This activit is depicted by reference numeral 5. 10. Cloud Lockbox 130 using File Handler 21.1 creates HCP #2 .141 specific Receptor 214 for each f le of Patient 1.16 to which HCP #2 has been granted access. The Receptor 214, encrypted with HCP #2's public key, includes a unique file ID, Patient's 116 public key, time-io-live settings and other metadata. The Receptor 214 includes whether the Patient 116 granted the HCP #2 1.41 fuSi access or metadata only access to the file.

1 1. HCP #1 110 using UHE API 261 and Key Master 112 sends patient's private key encrypted using publ ic key of HCP #2 14.1 to HCP #2's Key Master 1 2. The private key exchange process bypasses Cloud Lockbox 130 and H IE Registry 20, thus only HCPs possess private keys. This activity is depicted by reference numeral 6.

12. The transmission of the Patient's 116 private key is recorded to the Activity Log 1 1 1 for review by patient at will. Patient notification triggers would also be supported. This activity is depicted by reference numeral 4.

13. In some situations, the Patient 116 may only want the HCP #2 141.

to have access to the metadata, in this case, a variation of the permission process would authorize access to the Receptors 2.14 but not share the Patient's private key.

14. HCP #2 1:11 R 141 can now write their own generated content to Cloud Lockbox 130 for the same patient 116. For files written by HCP #2 .141, time-to-live settings are set to infinite. This activity is depicted by reference numeral 8.

15. HCP #2 EHR 1.4.1 can now retrieve existing patient files written by HCP #1 EHR 110. Using the UHE API 261 and the Key Master 112, HPC #2 EHR transmits a digitally signed request for list of Receptors for Patient 116 identifying individual based on public key of Patient 116, Cloud Lockbox 130 responds with package of Receptors 214 for Patient 1.16 if authorization for access by HCP #2 141 is already in Permissions Directory 212. This activity is depicted by reference numeral 8.

16. HCP #2 EHR 141, using the UHE API 261 and the Key Master 112, decrypts the Receptors with its own private key. HCP #2 EHR 14.1 can then decide which files to download based on the Receptor metadata. HCP #2 EHR 140, using the file ID from the Receptor 214, requests the pertinent Encrypted EHR Piles 210 for Patient 116. This activity is depicted by reference .numeral 8.

17. Access by HCP #2 141 of Patient's 116 Receptors 214 and/or Encrypted EHR Files 210 for files written by any other entity, as well as, for instance, HCP #2 writing files to Cloud Lockbox 130 for Patient, are written to the Activity Log 216 at HIE Registry 120 for review by patient at will.. Patient notification triggers would also be supported. This activity is depicted by reference numeral 5.

18. HCP #2 141 using UHE API 261 and Key Master 112 updates HIE Registry 120 with additional access rights of HCP #1 110 to read patient files written by HCP #2 141 for patient 116, This activity is depicted by reference numeral 7.

19. HIE Registry 120 updates permissions director}_'- 212 of Cloud Lockbox 130, adding access for HC #1 110 to files written by HCP #2 1.41. for Patient 116. Updates may be secured through digital signature based exchanges between Cloud Lockbox 130 and HIE Registry 120. This activity is depicted by reference numeral 5.

20. Cloud Lockbox 130 using Fife Handler 211 creates HCP #1 110 specific Receptor 214 for each file for Patient 116 to which HCP #1 has been granted access by HCP #2 EHR 1.41. The Receptor 214, encrypted with HCP #l 's 110 public key, includes a unique file I D, Patient's 116 public key, time-to-live settings and other metadata. 21. HCP #1 EHR. 110 also able to retrieve the files generated by HCP #2 EHR 141. This activity is depicted by reference numeral 3.

22. Access by HCP #1 EHR 110 of Patient's 116 Receptors 214 and or EHR File 210 for files written by any other entity are written to the Activity Log 216 at HIE Registry 120 for review by patient at will Patient notification triggers would also be supported. This activity is depicted by reference numeral 5.

Encryption Algorithm Flexibility

[0085] The UHE environment 100 described herein is designed to protect the privacy and confidentiality of electronic health records and other fomis of sensitive information while also allowing such information to be securely shared with others. As such, the UHE environment 100 does not include a central key authority governing the UHE encryption. Rather, each independent Key Master 112 operates a Key Manager and File Broker 462 that generates public-private key pairs and retains the private keys.

10086] Given the modularity and isolation of key creation, encryption, and decryption within the Key Manager and File Broker 462, a given coniiinmity-ot-interest electing to use the UHE mechanism could elect to use any suitable public key encryption algorithm of its choosing without impacting the operation of the UHE environment. For example, a first key master may operate a key master and file broker using a first public key encryption algorithm while a second key master may operate a key master and file broker using a second and different public key encryption algorithm.

[0087] in one example, as illustrated in Figure 18, a Key Master 412 may operate multiple Key Manager and File Broker 462 modules in order to participate in multiple community-of-interesi networks utilizing different encryption algorithms.

Details of he_^HIE- Registry

[0088] Listed below are examples of the types of information which may be maintained by HIE Registry 120. Of course, the examples listed below are not meant to be exhaustive or prescriptive, but rather mereiy examples of the ways in which the underlying mechanism may operate. HCP Listings

Name of HCP

Type of HCP

Public K ey of HCP

Date Registered

Authorization Method

Cloud Lockbox

IP Addresses

Table B: HC Listings

HCP Types

Medical Center/Hospital

Outpatient Clinic

Physician Practice

I I ome H ealth Hospice

Pharmacy

Health Department

Lab

Mobile/Home Telemetry

Table C: HCP Types

Patient Listings

Public Key of Patient Public Key of Medical Home

Date Registered

Authorization Method Public Keys of HCPs Authorized to Read and/or Write Records Key Demographic Information for identity Matching

Payerfs)

Table D^* Patient Listings Directory of Registries

HCP-Re gistry Associa li oris

Public Keys of Other Registries

IP Addresses fable E: Directory of Registries

The activity logs as illustrated in Figure 5 contain transactional information to monitor access to patient's files. ^"These include the Activity Log UHE API ill. Activity Log File Broker 264 and Activity Log Cloud Lockbox 216. The activity logs provide an essential cross check of file access for security purposes and also provide a rich source of

information to inform the patient regarding access to and sharing of the EHR files, private key, etc.

The C loud Loc kb x

[0089] Listed below are examples of the types of information that may be stored by the Cloud Lockbox 130, The list is not meant to be exhaustive or prescriptive, but rather an example of one way in which the underlying mechanism may operate.

* Encrypted EHR Files 210 may comprise unstructured key- value data store.

* Metadata which ma be used as key for granular permissions, searching and batch retrievals may include, but is not limited to: o Patient's Public Key

o BCP's Public Key

o Date of Activity

o File Type

o Registry Public Key

* HCPs may write encounter summaries to Cloud Lockbox 130 that include pertinent information such as date(s) of encounter, orders, vital signs, medications, history and physical, radiology report, physicians, discharge summary and links to image files also written to Cloud Lockbox 130. These files may adhere to industry standard formats such as HL7 and be in easily processed formats such as * The Permissions Directory 212 of patients' public keys mapped to HCPs allowed to retrieve information provides an additional level of security to the mechanism beyond the data encryption. All HCP access may be verified via digital signature.

* Receptors 214 are created for each file that an HCP is authorized to access. The Receptors 214 are encrypted with the specified HCPs public key. The Receptors include file ID, patient's public key, time-to-live settings, permissions settings, type of file, format of file (e.g. what type of reader might be required such as for PACS images) and other metadata,

* File Handler 211 provides the mapping of file ID in the Receptor to the actual storage location of the file at the Cloud Lockbox 130. Thus the physical file location has been obfuscated, requiring the use of the File Handler 211 to retrieve files.

HCP Registration Process

[0090] Referring now to Figure i, there is a schematic block diagram illustrating an HCP registration process using the UHE of Figure 1 and Figure 2. An entity seeking to participate in the UHE network as a HCP Registrant 101-R may be registered as depicted in Figure 3,

(0091 ] The HIE Registry 120 maintains database of HCPs, labs, telemetr providers, payers and any other entities that may have permission to read and/or write patient files (Registrant). As shown by reference numeral 1, HIE Registry 120 utilizes government sources and other trusted databases to assemble and verify entries in the HIE registry database. HIE Registry 1.20 may also generate its own public/private key combination for itself as a corporate entity.

(0092] As shown by reference numeral 2, a Registrant 101-R may verily its identity and authority with the HIE Registry 120 through multi-factor identity verification and exchange of authorized IP addresses.

(0093 j Once verification is completed, the Registrant 101- using HCP #1 EHR 110- R, UHE API 261 and Key Master 112 generates its own public/private key combination to identify itself as a corporate entity. [0094] As shown by reference numeral 3, the Registrant 10I-R transmits its public key to HIE Registry 120 encrypted using the HIE registry's public key using the UHE API 26.1. and the Key Master 112. HIE Registry 120 decrypts with own private key.

[0095] As shown by reference numeral 4, HIE Registry 120 replies with an acknowledgement encrypted with its own private key. The Registrant 101-R verifies HIE Registry .1.20 transmission by decrypting with HIE registry's public key using the UHE API 261 and the Key Master 112.

[0096] As show by reference numeral 5, the Registrant completes registration with an acknowledgement to the HIE Registry 120 encrypted wit its own private key using the UHE API 261 and the Key Master 1 12. HIE Registry 120 verifies the registrant transmission by decrypting with the registrant's public key.

Patient Registration Process

[0097] Referring now to Figure 4, there is a schematic block diagram illustrating a patient registration process using the UHE of Figure 1 and Figure 2. Once an entity is registered, as described above, it can then serve as a "Patient's Medical Home" 101 for the patient and conduct the registration process as depicted in Figure 4.

[0098] First, an HCP EHR #1 110 using UHE API 261 and Key Master 112 sends identifying patient demographic information to HIE Registry 120 as shown by reference numeral 1. The payload may be encrypted with the private ke of the HCP, decrypted by the HIE Registry 120 with the HCP's public key, confirming the identity of the HCP.

[0099] Second, the HIE Registry 120 communicates to its network of HIE Registries if applicable, to verify uniqueness of patient 116 identi ty as shown by reference numeral 2,

[0100] Third, the HIE Registry 120 has three possible replies as shown by reference numeral 3: a. EXISTS: in registry, returns patient public key, medical home public key and cloud lockbox. b. NEW: Created listing, requests public key of patient c. MORE: Indicating that additional information on patient required to determine whether unique identity. Ι^'ΘΙΟΙ] ϊ^η ail three cases, the response is encrypted with the HIE's private key for decryption by the HCP with the HIE registry's public key, confirming identity of the HIE registry.

[0102] Fourth, the HCP replies as shown by reference numeral 4 depending on response in received in step 2: a. ACKNOWLEDGE: HCP acknowledges receipt and session terminates. b. REGISTER: HCP generates public/private key combination for patient.

Transmits public key, ID of cloud lockbox and Payer(s) to HIE registry. c. Identity confirmation process continues.

[0103] In al! three eases, the response is encrypted with the HCP's private key fo decryption by the HIE registry with the HCP's public key, confirming identity of the HIE registry.

[0104] Fifth, the HIE Registry 120 replies as shown by reference numeral 5 depending on response received in step 3 ; a. Session completed in step 3. b. HIE registry acknowledges receipt and session terminates. c. identity confirmation process continues.

[0105] In all three cases, the response is encrypted with HIE's private key for decryption by the HCP with the HIE registry's public key, confirming identity of the HIE registry.

J 0106] Sixth, if the Patient 116 is a new patient to the HIE Registry network, then the HIE Registry 120 updates Cloud Lockbox 130 regarding registration of new Patient 116 as shown by reference numeral 6.

[0107] Seventh, the Patient's Medical Home 101 is now able to write and read files to the Cloud Lockbox 130 for Patient 116 using the HCP #1 EHR 110, the UHE API 261 and the Key Master 112. Activity Logs Mechanism for Patient Information and for Detecting and Hailing Unauthorized Access

[0108] Referring now to Figure 5, a schematic block diagram illustrates creating and comparing Activity Logs using the LJHE of Figure 2. Creation and comparison of Activity Logs are also supported by the example UHE environment

[0109] An Activity Log UHE API 111, an Activity Log File Broker 264 and an Activity Log Cloud Lockbox 216 capture information representative of writing and reading of UHE files as well as information representative of changes to access by different members. For improved security, the Activity Logs are maintained at the HIE Registry 120 separate from the sources of Activit Log records. For example. Activit Logs may be maintained in a first data store while UHE files may be maintained in a second distinct data store. An Activity Logs Compare module 280 at the HIE Registry 120 provides a method for detecting and halting unauthorized access to Files. The Activit Logs also provide a record of actions for review by the Patient 116.

[01 10] Activity Log data may be obtained from one or more of a variety of sources. For example, when the UHE API 261 that is integrated with HCP #1 EH 110 sends a fi!e write or read request to the API Engine 260 in the Key Master 112 as depicted by reference numeral 1, the UH E API 261. simultaneously sends a report of the request to the Activity Log UHE API 111 at the HIE Registry 120 as depicted by reference numeral 2,

[0111 ] In one example, when the Key Manager and File Broker 262 in the Key Master 112 sends a file write or read request to the Cloud Lockbo 130 as depicted by reference numeral 3, the Key Manager and File Broker 262 simultaneously sends a report of the request to the Acti vity Log File Broker 264 at the HIE Registry 120 depicted by reference numeral 4.

(Oi l 2] in one example, when the File Handler 211 in the Cloud Lockbox 130 responds to a file write or read request depicted by reference numeral 3, the File Handler 211 simultaneously sends a report of the request to the Activity Log Cloud Lockbox 216 at the HIE Registry 120 depicted by reference numeral 5.

[0113] Periodically, the HIE Registry 120 will analyze activity logs, using Activity Log Compare module 280, to detect anomalies that could indicate unauthorized access to Encrypted EHR Files 210 stored at the Cloud Lockbox 130 depicted by reference numeral 6. if such an anomaly is detected, then the BIE Registry 120 may alter the Pemiissions Directory 212 of the Cloud Lockbox 130 in order to halt file retrieval from the suspect Key Master 112 depicted by reference numeral 7. In one example, a Permission Directory 212 setting may indicate to the Key Manager and File Broker 262 the reason for the denial of file retrieval depicted by reference numeral 3. In one example, the HIE Registry 120 may also notify responsible members at the Participating HCP about the detected anomaly and denial of file retrieval. The notification may be performed via a suitable method established at the time of registration depicted by reference numeral 8. For example, a notification may include an email message, a text message, a telephone call, a pager alert, and so on.

[01.14] Even in a proxy situation, the patient 116 could also receive notification of the anomalous access and the actions taken to halt such access.

[0115] In one example, the File Handler 211, Key Manager and File Broker 262, and the UHE API 261 may send periodic "heartbeat" messages to HIE Registry 120 to confirm ability to communicate. In such an example, the Activity Log Compare module 280 is able to detect the absence of heartbeat entries and generate a notification accordingly.

Inclusion of Write-Onlv-Members

[0116] Referring now to Figure 6, there is a schematic block diagram illustrating sharing mite -only data using the UHE of Figure 1 and Figure 2. Receiving and sharing lab results and home/mobile telemetry is also supported by the example UHE environment.

[0117] Certain providers in the health care field provide patient data without being allowed to receive patient data. Such providers, generally referred to generally as Write- Only Members, may include participating vendors providing home or Mobile Health Monitor Software 146A, participating labs running Lab Software 146B and other participating entities with Write-Only Software 146C.

[0118] Like other HCPs, these W rite-Only-Members may also associate to and register with an HIE Registry 120 in the UHE network by following the entity registration process described above in reference to Figure 3. [0119] By following a process similar to patient registration described in reference to Figure 4, the write-only Mobile Health Monitor Software I46A, using the UP1 API 261 and the Key Master 112, may retrieve a patient's public key and the I D of Cloud Lockbox .130 from the H IE Registry 120 as depicted by reference numeral 1. The Write-Only Participant J 46 A could then commence writing files encrypted with patient's public key to Cloud Lockbox 130 as depicted by reference numeral 1.

[0120] Only HCPs authorized by the patient would have the private key to decrypt the files written by Write-Only-Members. Write-Only-Members 146A, 146B and 1.46C would not possess any patients⁵ private keys nor would such participants be authorized to retrieve files from the Cloud Lockbox 130.

"Glass Break¹" Emergency Care Scenario

10121] Referring now to Figure 7, there is a schematic block diagram illustrating communications within the UHE environment in an emergency situation.

[0122 J It is important for an HIE solution to provide emergency rooms with access to patient data in the event of an emergency that occurs outside of the patient's normal care community. The so-called "glass break" scenario outlined in the Figure 7, shows how such functionality may work within the UHE framework.

1 , Patient 116 presents to an emergency room 610, unable to provide authorization for access to his/her medical records depicted by reference numeral 1. The emergency room 610 is not one of the patient's normal HCPs.

2, Emergency room 610 using ER HCP EHR 612, UHE API 261 and Key Master

112 attempts to register patient 116 with HIE Registry 120 and, as a result, receives patient's medical home 101 public key and Cloud Lockbox 130 depicted by reference numeral 2 .

3, Emergency room 61 sends request to HCP #1 EH 110 for emergency-based release of private key using UHE API 261 and Key Master 112. Message to HC P 110 is encrypted with emergency room's private key. HCP 110 is able to decrypt message with emergency room's public key, verifying identity. Encrypted key exchange proceeds. These activities are depicted by reference numeral 3. 4. HCP ΙΊβ using UHE API 261 and Key Master 112 updates permission directory 220 at HIE Registry 120 allowing access to Patient's 116 EHR files 210 stored at Cloud Lockbox 130 for ER HCP EHR 612 depicted by reference numeral 4.

5. HIE Registry 1 0 updates permissions directory 212 at Cloud Lockbox 130 This activity is depicted by reference numeral 5,

6. Emergency room 610 using ER HCP EHR 612, UHE API. 261 and Key Master

112 can now retrieve and decrypt patient files from Cloud Lockbox 130. Emergency room 610 also writes encounter summary and other files generated during encounter to the Cloud Lockbox 130 for later review by HCP 110. This activity is depicted by reference numeral 6.

If Emergency room 610 has not yet joined, an applicable community of interest, then a similar mechanism would support emergency access to the records through the use of existing methods for sharing records such as the Direct Project or Blue Button.

Detecting and

[0123] In addition to the coordination of care and HIE benefits of UHE, the mechanisms a! so support anaiytica! methods to detect and prevent waste, fraud and abuse as illustrated in Figure 8.

1. HCP 101, medical home of patient 11.6, using HCP #1 EHR 110, UHE AP 261 and Key Master 112, generates a summary digest of all flies written to Cloud Lockbox 130 and of all other HCP reads of files for its patients. Such a summary supports coordination of care, and triggers alerts to duplicated prescriptions, and redundant tests, among other things. Further, HCP EHR #1 110 provides data for patient review of activity on his/her health records. These activities are depicted by reference numeral 1.

2. Payer 150 also registers with HIE Registry 120 in a process similar to .registration of HCPs depicted by reference numerals 2 and 3.

3. Payer 150, identified by HIE Registry 120 as Payer for the Patient 116, is able to review metadata for patients' files stored by Cloud Lockbox 130 by using UHE API 261 integrated with the Payer's Software 151 and Key Master 112. Payer 150 is not able to decrypt the contents without further authorization and related private key exchange. Thus payer 150 can identify some utilization trends with minimized HIPAA exposure. These activities are depicted by reference numeral 4.

4. Payer 150 and Patient's Medical Home 101 may collaborate to identify cases of waste, fraud and abuse depicted by reference numeral 5.

5. insurance form submittals may also be written to Cloud Lockbox 130 by HCP #1 EHR 110, encrypted with the payer's public key, providing a simple mechanism for securely submitting and cataloging the reimbursement paperwork. The same document may also be written to the Cloud Lockbox 130 encrypted with the patient's public key. These activities are depicted by reference numeral 1.

6. Payer ISO using Payer's Software 151, IJHE API 261 and Key Master 112 may retrieve reimbursement paperwork and write updates to such paperwork for review by Patient's Medical Home 101 as depicted by reference numeral 5.

7. Patient 116 is able to review all access to their files via patient portal 114 depicted by reference numeral 6.

Support for Medical Research

[0124] Using the UHE environment 100 described herein, one or more HCPs may elect to generate coordinated and longitudinal de-identified patient care research databases 1 j.8. Permission to extract such information may be solicited at the time the patient 116 is authenticated at his/her medical home 101. The coordinated care benefits would ripple into the research database, providing a compieie picture of the individuaFs health history without any personal identifiers remaining. The communication mechanisms that support the generation of de-identified patient data is illustrated in Figure 9,

^■ Patient's medical home 101 using the HPC #1 EHR 11 , UHE API 261 and Key Master 1.1.2 provides a full view of the medical status and activities of patient 116.

• Files may be written to a de-identified patient database 11.8 with a "scramble" of the patient's 116 private key to replace the public key as a patient identifier with this new number.

" The relationship of the new "scrambled" identifier to the actual patient public key may be known only to the Patient's medical home 101. " Patient's Medical Home 10.1 may retain the mapping so that additional data for the patient can be added over time for Longitudinal studies.

Key Change and Access Revocation

[0125] Circumstances may arise in which the need for a change of the Patient^'s 116 pub Lie-private key pair is required. This need could arise from circumstances such as: compromise of the privacy of the public-private key pair; detection of unauthorized access to EHR files 210 at Cloud Lockbox 130; decisions to revoke decryption authority previously granted to one or more HCPs; or decision of Patient 116 to switch to a different HCP as its medical home. Regardless of the reason the mechanism to change or revoke access remains the same and is illustrated in Figure 10,

(0126] Upon receiving a request to change or revoke access, HCP #1 EHR 110 using UHE API 26.1 and Key Master 112 generates a new key pair and updates HIE Registry 120 with the change via a digitally signed transaction including both the old. and new public keys of Patient 16 depicted by reference numeral 1.

[0127] HIE Registry 1.20 updates Permissions Directory 21.2 with the change and with an indication that key change process is about to commence for Patient 116 via digitally signed transaction depicted by reference numeral 2.

[0128] Permissions Directory 212 and File Handler 211, both at Cloud Lockbox 130, prepare a new set of Receptors for Patient's .1.16 files.

[0129] Patient's Medical Home 101 , using HCP #1 110, UHE API 261 and Key Master 112, then transmits the digitally signed request for the current and new list of Receptors 214 for Patient 116. HCP #1. EHR 142 identifies Patient 116 based on both the old and new public keys of Patient 116. Cloud Lockbox 130 responds with two packages of Receptors 214 for the Patient 116, both the old and the new, each encrypted with HCP #l 's 110 public key. These activities are depicted by reference numeral 3,

[0130] HCP m 110 using Key Master 112 retrieves all Encrypted EHR Files 210 for Patient 116, decrypts the files with the Patieni's 116 old private key and re-encrypts the files with the Patient's 116 new public key. HCP #1 EHR 110, using UHE API 261 and Key Master 112, then writes Encrypted EHR Files 210 for Patient 116 back to Cloud Storage 130 as managed by the File Handler 211. These activities depicted by reference numeral 3. 10131] HCP #1 EHR 110, using the UHE API 261 and Key Master 112, erases the old version of the Patient's 116 Encrypted EHR Files 210. However, the files written to Cloud Storage 130 by HCP #2 EHR 142, now designated at 210- A, the entity whose access is being revoked, are not erased. This measure is necessary so that HCP #2's internal operations are not compromised in terms of retaining patient files. These activities depicted by reference numeral 3.

[0132] Cloud Lockbox 130 records the activity in the Activity Log Cloud 216 maintained at HIE Registry 120 as depicted by reference numeral 2.

[0133] HCP #1 EHR 110, using UHE API 261 and Key Master 112, notifies other HCPs still authorized to write to Patient's files such as HCP #3 EHR 152 of the Patient's new public ke depicted by reference numeral 4. HCP 41 EHR 110, using Key Master 112, a!so notifies other HCPs still authorized to read and decrypt Patient's files such as HCP #3 EHR 152 of the Patient's 116 new private key depicted by reference numeral 4,

[0134] HCP #1 EHR. 110, using UHE API 261 and Key Master 112_., also issues a file revocation request to the Key Master 112 of HCP #2 EHR 142 for all files that HCP #2 142 has downloaded for Patient 116 other than those file written by HCP #2 EHR 142 depicted by reference numeral 5.

[0135] If HCP #2 EHR 142 software is compliant with this feature of UHE, then it can acknowledge using Key Master 112 the destruction of Patient's 116 Encrypted EH R Files 210 that it had downloaded but not created as depicted by reference numeral 5.

(0136} HCP #1 EHR 110, using UHE API 261 and Key Master 112, writes to Activity Log R&tT 216 maintained at the HIE Registry 120 the outcome of revocation requests and the notification of HCPs still authorized to write and/or read files depicted by reference numeral 1.

[0137] It should be appreciated that, although the file revocation process has been described as occurring in combination with a key change request, a file revocation request can also occur independently of a key change process.

[0138] in one example, HCP #2 142, using UHE API and Key Master 112, can continue to retrieve and decrypt the files it wrote to Patient's 116 record using the old private key now shown a HCP #2 Encrypted EHR Files 210-A. This measure allows HCP #2 EHR 142 to continue to use the Cloud Lockbox 130 for archival purposes of its own activity. However, HCP #2 EHR 142 will no longer be able to retrieve or learn of the existence of other Encrypted EHR Files 210 for the Patient 116. These activities depicted by reference numeral 6.

Key Recovery and/or File Recovery

[0139] The UHE environment 1 0 described herein is designed to protect the privacy and confidentiality of electronic health records and other forms of sensitive in.fo.rma.tio» while also allowing suc information to be securely shared with others. As such, there is no central key authority governing the UHE design. Each Key Master 112 operates a Key Manager and File Broker 262 that generates public-private key pairs and retains the private keys. Thus a complete loss of the private key(s) would render the information protected inaccessible without massive computational, effort to recover the private key. Only files remaining in local EHR storage would be recoverable directly from within UHE,

[0140] This aspect of potential loss of private keys of UHE is a privacy-enhancing design feature but does call out the importance of sharing the private keys with at least one other member with its Key Master 112 operating at sufficient physical distance to provide for disaster recovery scenarios. Alternatively, HCP #1 EHR 110 may install and register a second Key Master 112 that is automatically granted read and write access for any Patient 116 selecting HCP #1 as its Medical Home 101.

10141 ] In the event that a Key Master 112 becomes damaged, corrupted or otherwise loses private keys under its control, the key recovery process would in most cases resolve the loss of private keys as illustrated in Figure 11.

[0142] In the worst case scenario, the Patient's Medical Home 101 has suffered a corruption of the Key Master 112 such that the private key of one or more patients has been lost. Thus, the entire operation of the Key Master 112 may have failed.

[0143] First the Patient's Medical Home 101 rectifies operational problem affecting the Key Master 112 and re-establishes registration of tire new software instance with the HIE Registry 120 as depicted by reference numeral 1.

[0144] The U-API 261 initiates through die Key Master 112 the key recovery process using the public key of affected patients. [Θ145] The Key Master 112 then initiates the key recovery process wit the HIE Registry 120, HIE Registry replies with a private key holder, e.g. HCP #2 EHR, for one or more patients based on the Patient Directory and Permissions 282, These activities are depicted by reference numeral 1.

|0146] The HIE Registry 120 sends to the Key Master 112 of HCP #2 EHR 142 a list of patients for whom HCP #1 EHR 110 needs private key recovery as depicted by reference numeral 2, Alternatively, if Patient's Medical Home 101 had installed and registered a second Key Master 112, the HIE Registry 120 initiates the key recovery process with this backup Key Master 112 first. The remainder of the process would remain as follows,

[0147] Key Master 112 of HCP #2 EHR 142 transmits private keys for patients in a list from HIE Registry 120 to the Key Master 112 of HCP #1 EHR 110 as depicted by reference numeral 3. This conimvmi cation would be further secured by digital signatures and optiona!iy IP address restrictions.

[0148] Key Masters 112 HCP EHR #2 142 records this activity in the Activity Log File Broker 264 as depicted by reference numeral 2,

[0149] The HIE Registry 20 then sends to the Key Masters 1 2 HCP #3 EH 152 a list of patients for whom the Key Masters 112 of HCP #1 EHR 110 needs private key recover as depicted by reference numeral 4.

[01 SO] Key Master 112 of HCP #3 EHR 152 transmits private keys for patients in a list from HIE Registry 120 to the Key Master 112 of HCP #1 EHR 110 as depicted by- reference numeral 5. This communication would be further secured by digital signatures and optionally IP address restrictions.

1015 J Key Masters 112 HCP EHR #3 152 records this activity in the Activity Log- File Broker 264 as depicted by reference numeral 4.

[0152] The described process repeats until Patient's Medical Home retrieves private keys for all affected patients.

[0153] Should the key for a patient 1 6 be unrecoverable, the Patient's Medical Home 101 may initiate a f le recovery process that seeks to restore to the UHE network whatever EHR files for the Patient 116 remain in local storage of the HCP EHR

; participating in the care of the given Patient 116. The key change process from Figure 10 and a modification of the key recovery process from Figure 11 that focuses on files instead of keys are then invoked.

Multiple UHE APIs at a Participating HCP

[0154] A Participating HCP will in most cases operate multiple EHR software systems as well as other auxiliary systems requiring data feeds from EHR systems. These software systems are likely to include but not be limited to an inpatient EHR, I -EHR 110- A; an ambulatory EHR, A -EHR 110-B; and a picture archiving and communication system, PACS 110-C as illustrated in Figure 12, These various systems often function independently within a health care organization, requiring internal integration to create a unified view of a given patient.

[0155] Each of the E HR software systems will need to run. an interface to participate in UHE called the UHE API 261. However only a single Key Master 112 would be required, with the API Engine 260 able to communication with multiple UHE APIs 261.

[0156] in such a configuration, UHE can support internal HCP integration efforts by providing the common interface among all systems. For vendors of EHR systems, UHE presents a single interface to develop that would serve HCPs with any blend of EHR systems.

Multiple HIE Registries

[0157] While it would be simpler to have a single HIE registry to serve ail patients, this outcome seems unlikely in our highly competitive health care and IT markets. One of ordinary ski!! in the art will recognize that the LIHE described herein may be embodied in alternate configurations, including an environment having multipie HIE registries as illustrated by Figure 13.

[0158] In such an embodiment, each HCP 910A-910E associates with only one HIE registry' 920A-92OC. The HIE registries 920A-920C communicate with each other during;

• Patient registration process to confirm uniqueness.

♦ Exchange of HCP registrations. • Exchange of patient record permissions changes, e.g. new HCP authorized by patient.

Multiple Cloud Lockboxes

(0159] While it would be simpler to have a single provider of cloud lockboxes to serve all HCPs. one of ordinary skill in the ar will recognize that suc a configuration may not. accommodate the highly competitive health care and IT markets. Thus, the UHE design accommodates the existence of multiple providers of cloud lockboxes as illustrated in Figures 14 A and 14B.

[0160] As illustrated in Figure 14A, HCP 1010 is the medical home for patient A. HCP 1010 designates cloud lockbox 1030A for patient A. The association is identified during HIE registration of the patient. Patient A authorizes HCP 1011 to read/write files. HCP 101 writes Fries tor patient A to cloud lockbox 1030A to keep ail. patient files in one source. Similarly, write-only input for patient A, such as lab results from HCP .1048, are also written to cloud lockbox 1 30 A.

10161] As illustrated in Figure 14B, HCP 1011 is the medical home for patient B. HCP 1011 designates cloud lockbox 1Θ3ΘΒ for patient B. The association is identified during H IE registration of the patient. Patient B authorizes HCP 1010 to read write f ies. HCP 1010 writes files for patient B to cloud lockbox 1.030B to keep all patient files in one source. Similarly, write-only input for patient B, such as lab results from HCP 1048, are also written to cloud lockbox 1030B.

Levels of Integration

[0162] It should be appreciated different levels of integration may be possible between EHRs and the UHE. For example, evolution and extension of the interfaces will progress over time. All levels of integration may be supported by a single API Engine 260 in the Key Master 112. An example delineation of the le vels of integration is depicted in the following table.

4ί Level 1 Method for backlog up or archiving EHR flies.

Level 2 Engaged in a network of providers for health information exchange.

Level 3 Honor incoming revocation requests. Honor tkne-to-!ive settings in meta data.

Retain full metadata m native EHR file storage. Provide identity of individual

Level 4

who accesses patient files for additional . detail in activity logs.

Level 5 Use of UHE with local caching as primary file store.

Table 2: Levels of EHR Integration with UHE Data A ccess Options

| 0163 j In some situations, it may not be necessary to access complete data records but rather to only access partial record of a patient, such as basic patient information. Fo example, an insurer may need to know that a certain diagnostic test was performed but the insurer does not need to have access to a full patient file. In another example, a physician specializing in one field, such as podiatrist, may not need to have access to patient information pertaining to another medical field, such as the patient^'s records about a patient's heart condition. Thus, in one example, a partial data record such as metadata may be provided rather than the entire patient data file.

[0164] in some situations, it may be undesirable to provide data from which specific patient identities can be determined. For example, an organization performing research may be interested in patient outcomes in relation to a specitic treatment of a disease. However, the organization performing the research may not be permitted to know the identities of the patients. Thus, in one example, patient data may be anonymized in order to eliminate information such as names, addresses, and social security numbers.

Patient Dashboard

(0165) in one example, the patient portal 114 may further provide patient 116 with a patient dashboard. In particular, the patient dashboard may provide an overview of the patient's 116 medical history as well as an overview of recent activity and medical conditions. Such a patient dashboard provides a single source of information from which a patient 116 may obtain a personal medical summary as well as a comprehensive medical review. Alternative Business Models in Health Care

[0166] Given the flexibility of the described systems, devices and methods, the UHE business mode! could take other forms. Figure 15 illustrates one such alternate embodiment. Figure 15 depicts an environment similar to that of Figure 1 except that an entity other than a health care provider may become a patient's medical home for the purposes of medical record aggregation, called a "Medical Home" Health Record Represeniati ve f'HR ").

[0167] The HCPs are or will soon be required by Federal mandate to be able to share patient records through a set of HIE standards. Thus, the ΗΪΕ goals of UHE could be met even if the HCP did not directly participate in the UHE mechanism. Such an HCP would sacrifice the cost savings inherent in the UHE design in terms of reducing storage costs unless they transferred their long-term record retention responsibilities to the HRR,

[0168] The HRR could also operate a blended architecture offering a choice between the standards-based HIE-interface solutions and the full UHE implementation.

Othe ifidnstries

[0169] The systems, devices and methods of the present application have been described primarily in relation to an example health care system. The systems, devices and method are also applicable in a wide variety of other industries in which confidential information needs to be selectively and securely shared among multiple business entities.

Legal Industry

[0170] Referring now to Figure 16, there is illustrated a schematic block diagram depicting a system supporting the legal industry, using a similar design as in Figure 1 for the medical industry, but with different entities. Following the concept of the "medical home" this model addresses the creation of a 'legal home" for the client. Such a "home" selection does not preclude the use of other lawyers, but the " home" lawyer does become the initial issuer and owner of the public private key set. Similar to the health care industry, other business entities could provide the "legal home" other than law firms.

[0171 J Other law firms, prosecutors and courts may be granted granular read-write access on a ciieni-by-c!ient basis. Write-only participants such as court reporters and labs could securely write flies to the client's case file without gaining the ability to retrieve

4.? and/or decrypt any other files related to the case. The client would have a complete view of all files related to his/her case and the ability to audit access.

Real Estate Industry

[0172] Referring now to Figure 17, there is illustrated a schematic block diagram depicting a system supporting the real estate industry, using a similar design as in Figure 1 for the medical industry, but with different entities. Once again following the concept of the "medical home" this model addresses the creation of a "real estate home" for the client. Such a "home" selection does not preclude the use of other realtors, but the "home" realtor does become the initial issuer and owner of the public/private key set Similar to the health care industry, other business entities may provide the 'Yea! estate home" other than real estate firms.

[0173] Other realtors, mortgage brokers, lawyers, developers, etc. may be granted granular read-write access on a client-by-client basis. Write-only participants such as appraisers and inspectors could securely write files to the client's file without gaining the ability to retrieve and/or decrypt any other files related to the business situation. The client may have a complete view of all files related to his/her business situation and the ability to audit access.

Information _l Owner ontr oiled

101.741 The preceding depictions of the system have assumed the presence of a proxy acting on the information owners request to manage the owner's information. However, as shown in Figure 18, an example design also supports a stand-alone use of the mechanism operated b the owner to directly manage multiple types of information using a similar design as in Figure I . in this scenario there is no "medical home" or "legal home" with default access, instead, the information owner originates the key- pairs and all permissions. In this scenario, all activities including registration, sharing of private keys, revocation requests and key pair changes would originate with the owner using his/her own Key Master 41.2.

f0! 75] The API Engine 460 could support APIs 461 for a variety of desktop and mobile applications running on any suitable operating system.

101 6) In one example, information owner may elect to run multiple Key Manager and File Broker modules 462 in the Key Master 412. in this way, the Information Owner can participate in multiple community ~of~interesi networks operating with different encryption algorithms. In this example, the Key Master 412 contains two Key Manager and File Brokers, 462-A and 462-B each operating a. different encryption algorithm specific to the two specific eoro i ities-of-interest depicted. In particular, Key Manager and File Broker-A 462-A uses an encryption algorithm shared by all members of the commimity-of-mierest participaiing in the health care network represented by Cloud Lockbox Health Care 43 -A and HIE Registry 420- A. Key Manager and File Broker-B 462-B uses an encryption algorithm shared by all members of the commimity-of-interest participating in the legal network represented by Cloud Lockbox Legal 430-B and Legal Exchange Registry 420-B. Thus, a single Key Master 412 could support multiple Key Manager and File Broker 462 modules for participation in multiple eommnnity-of-interest networks.

Wide Applicability

(0177] With three examples of industries that can utilize the described systems, devices and methods, one can easily imagine other applications of this flexible system in any situation in which multiple members need to have access to confidential information regarding an individual, such as the insurance industry, social service agencies, commercial research and development, scientific research, and finance, for example.

[0178} From the information contained herein, those skilled in the art will perceive improvements, changes and modifications to the systems, devices and methods disclosed herein. Such improvements, changes, and modifications within the skill of the art are intended to be covered by the present application.

[0179] Notwithstanding that tire numerical ranges and parameters setting forth the broad scope of the invention are approximations, the numerical values set forth in the specific examples are reported as precisely as possible. Any numerical value, however, inherently contains certain errors necessarily resulting from the standard deviation found in their respective testing measurements.

[0180] Furthermore, while the systems, devices, methods, and so on have been illustrated by describing examples, and while the examples have been described in considerable detail, it is not the intention of the applicants to restrict or in any way limit the scope of the appended claims to such detail. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing t e devices, systems, methods, and so on provided herein. Additional advantages and modifications will readily appear to those skilled in the art. Therefore, the invention, in its broader aspects. Is not limited to the specific details and illustrative examples shown and described. Accordingly, departures may be made from such details without departing from the spirit or scope of the applicant's general inventive concept. Thus, this application is intended to embrace alterations, modifications, and variations that fall within the scope of the appended claims. The preceding description is not meant to limit the scope of the invention. Rather, the scope of the invention is to be determined by the appended claims and their equivalents.

}0181 j Finally, to the extent that the term "includes" or "including" is employed in the detailed description or the claims, it is intended to be inclusive in a manner similar to the term "comprising," as that term is interpreted when employed as a transitional, word in a claim. Furthermore, to the extent that the term "or" is employed in the claims (e.g., A o B) it is intended to mean "A or B or both." When the applicants intend to indicate "only A or B, but not both," then the term "only A or B but not both" will be employed. Similarly, when the applicants intend to indicate "one and only one" of A, B, or C, the applicants will employ the phrase "one and only one." Thus, use of the term "or" herein is the inclusive, and not the exclusive use. See Bryan A. Garner, A. Dictionary of Modern Legal Usage 624 (2d. Ed, 1995).

Claims

What is claimed is:

1. A system for conducting a secure exchange of encrypted data within a

community of interest using a three-party security mechanism consisting of key masters operated by members of the community of interest, registries, and cloud lockboxes, wherem the three-party security mechanism is configured to be integrated with via application programming interfaces.

2. The system of claim 1 , wherein a customized community of interest is

generated based on a selection of at least one of a plurality of options among built-in operating parameters, comprising:

a. selecting a public key encryption algorithm;

b. selecting a registry or a plurality of registries;

c. establishing membership requirements and identity verification thresholds; d. selecting a cloud storage provider at which to establish the cloud lockboxes;

e. selecting from among a plurality of optional security measures; f. determining a minimum application integration level; and

g. determining initial metadata structure, purpose, and meaning.

3. The system of claim 1 , wherein the three-party security mechanism is vendor- neutral, thereby enabling underlying software to security -enable any records management, file sharing, document management or similar application software.

4. The system of claim 1, wherein the three-party security mechanism as a

standalone service.

5. The system of claim 1 , wherein the member of the community of interest comprises at least one of:

a. an individual participating directly;

b. an organization participating for its own purposes; and

c. an organization participating to represent multiple individuals, whereby the multiple individuals are participating by proxy.

4? , The system of claim 5, wherein the three-party security mechanism provides the multiple individuals participating by proxy the ability to access data; to review activity logs; and to receive alerts regarding anomalous access, , The system of claim I , wherein a key master is configured to:

a. verify identities, authenticity, and authority of the members in communication with the registries;

b. establish a unique identity and verify authenticity for each individual and organization in communications with the registries:

c. generate a public-pri ate key pair for each individual and organization; d. receive individuals' data and related metadata from the application programming interfaces;

e. encrypt the data and related metadata with the individuals' public keys; f. encrypt the metadata with public keys of metadata -only recipients;

g. create non-sensitive transactional metadata and associate the non-sensitive transactional metadata with existing data files;

h. transmit the encrypted data, metadata, and transactional metadata to the cloud lockboxes;

i. control individuals' private keys required for decryption;

j. retrieve data from the cloud lockboxes and decrypt data with the individuals" private keys;

k. securely transmit the individuals' private keys to other members' key masters to permit decryption of the individuals' files;

1, update permissions lists at the registries;

m. transmit log records of key creation, file retrieval requests, private key exchanges, and other activities to the registries. , The system of claim I , wherein the three-party security mechanism is configured to use unencrypted transaction metadata as indexing elements, to provide information representative of transactional information as defined by the community of interest, including information about data source and date of storage.

N , The system of claim 1, wherein a registry is configured to:

a. establish a imiqoe identity, authenticity, and authority of the member of the community of interest through communications with the members' key masters and the application programming interfaces;

b. establish a unique identity and authenticity of the cloud lockboxes and the registries;

c. establish unique identities for each individual with the key master operated by the member, wherein the registry is configured to communicate with additional registries if more than one registry is operational for the community of intere t;

d. maintain a directory of individuals, members, organizations and cloud lockboxes, and other registries, wherein the registr is configured to function as a clearinghouse for members to retrieve public keys of other members, individuals, organizations and cloud lockboxes;

e. record the IP address of the key masters, cloud lockboxes and other

registries for selectively restricting communications;

£ manage individual-level access control lists and communicate lists to cloud lockboxes for controlling access to data files;

g. receive activity logs from the key masters, the application program interfaces, and the cloud lockboxes to;

i. analyze activity logs to detect and halt anomalous access; and ii, provide the members with alerts regarding anomalous access and with routine access to activity logs; and

h. conduct polling at random intervals of the key masters, the application programming interfaces, the cloud lockboxes, and other registries to verify accessibility of activity reporting module.

10. The system of claim I, wherein a cloud lockbox comprises software operating at a cloud provider, the cloud lockbox being configured to:

a, store encrypted data, encrypted metadata, and -unencrypted metadata;

b. create receptors for stored data to serve as claim tickets for the members; wherein the receptor obfuscates the physical location of the file in the cloud lockbox; c. utilize access control lists received from the registries to determine which individuals' files a given member may store and retrieve;

d. enable push notifications to members of new receptor availability; and e. transmit activity records of file retrieval requests to the registries. 1. The system of claim 1 , wherein an application programming interface is configured to:

a. offer flexibility in adapting to the needs of the community of interest; b. consist of publically published and private proprietary methods to integrate to applications being used by the members of a community of interest; c. support a plurality of levels of integration with an application including native integration, in which the mechanism's encryption and protocols are extended into data stores of the application, industry-standard interfaces, and simple archiving solutions;

d. convert data from a proprietary format to an industry standard format and convert data from an industry standard format to a proprietary format: e. convert data between a key-value data store and a relational database; f. generate metadata specific to the application, wherein the metadata is one of

i. appended to data and encrypted;

ii. encrypted separately from the data so a member could be granted metadata only access; and

iii. left unencrypted and added to the transactional .metadata created by a key master by:

1. using unencrypted metadata as indexing elements, information about the source of the data; and

2. using unencrypted metadata to enable granular access control;

g. map individuals' identification numbers in applications to community of interest identification numbers for the same individuals;

h. enable the creation of a hybrid cloud and on-premises storage sohiiion; and i. transmit activity records of file retrieval requests and access revocations to the registries.

12. The system of claim I , wherein the three-party security mechanism is configured to:

a. change keys;

b. revoke access;

c. recover keys;

d. recover files;

e. de-identify individual's files;

f. provide emergency access; and

g. add features leveraging existing design elements and expand operating protocols.

13. The system of claim 1 , wherein the three-party security mechanism is configured to offer a plurality of security levels by:

a, deploying the key masters as an appliance;

b. integrating applications deeply with the mechanism to provide additional information such as the internal application usemame of the person requesting data;

c. requiring two-factor authentication for access to the key master; and d, applying IP address communications restrictions based on information gathered by the registry.

14. The system of claim 1 wherein the three-party security mechanism is

configured to enable adding data to a. cloud lockbox of the cloud lockboxes: a. wherein a registry is configured to communicate to a cloud lockbox the permissions of a key master for a first member to store data in the cloud lockbox for a first individual;

b. wherein the registry is configured to communicate to the cloud lockbox the public key of the first individual and the first member's key master;

c. wherein the registry is configured to selectively communicate to the cloud lockbox the IP addresses of first member's key master;

d. wherein a key master of the first member is configured to encrypt the data and metadata with first individual 's public key; e. wherein the key master of the first member is configured to encrypt at least a portion of the metadata with a first metadafa-only-member's public key;

£ wherein the key master of the first member is configured to submit the encrypted data to the cloud lockbox;

g. wherei the cloud lockbox, is configured to store the encrypted data and to create a receptor providing transactional metadata and a file identification; h. wherein the cloud lockbox is configured to acknowledge the receipt of the encrypted data by returning the receptor to the key master of first member; and

i. wherei the key master of the first member is configured to retrieve the encrypted data and encrypted metadata submitting the receptor to the cloud lockbox.

15. The system of claim 1 , wherein the three-party security mechanism is

configured to enable sharing encrypted data between members:

a. wherein a registry is configured to receive data indicative of a first

member's request to share a first individual's encrypted data stored on cloud lockbox with a second member, wherein the first member previously verified its identity with the registry;

b. wherein the registry is configured to update permissions for the second member specific to the first individual using the key master of the first member;

c. wherein the registry is configured to update a cloud lockbox with

permissions for the second member for specified dat of the first individual as authorized by the first member;

d. wherein the key master of the first member is configured to transmit a •private key of the first individual, to a key master of the second member, encrypted with the second member '$ public key;

e. wherein the key master of the second member is configured to decrypt and store the first individual's private key; and

f. wherein the kay master of the second member is configured to retrieve and decrypt data of the first individual from cloud lockbox.

16. The system of claim 1, wherein the three-party security mechanism is

configured to enable reciprocal sharing of encrypted data:

a. wherein a key master of a second member is configured to originate data about a first individual; encrypting the first individual's data and metadata with the public encryption key of the first individual, and add the encrypted data and metadata to a cloud lockbox; and

b. wherein a key master of a first member is configured to retrieve and

decrypt the data originated by second member for first individual.

17. The system of claim 1 , wherein a key master is configured to verify identities of other key masters, registries and cloud lockboxes during transactions using digital signatures.

18. The system of claim 1, wherei n the three-party securit mechanism is

configured to enable write-only access;

a. wherein a key master of a first member is configured to update

permissions for a write-only member requiring write-only access to enable the write-only member to add files to a cloud lockbox for a first individual; b. wherein a registry is configured to update a cloud lockbox with

permissions for the write-only member, to store data in, but not retrieve data from, cloud lockbo of the first individual;

c. wherein a key master of the write-only member is configured to encrypt data with the public key of first individual and add the data to cloud lockbox of the first individual;

d . wherein the key master of the first member i s c onfigured to retrieve and decrypt the data originated by write-only member for the first individual.

1 . The system of claim 1 , wherein the three-party security mechanism is

configured to enable metadata-only access:

a. wherein a key master of a first member is configured to update a registr with permissions for a metadata-only member to retrieve metadata only for a fist individual; b. wherein the a registry is configured to update a cloud lockbox with permissions for the metadata-only to retrieve only metadata of the first individual.

The system of claim I , wherein the three-party security mechanism is configured to enable detecting and halting anomalous access:

a. wherein the registries are configured to collect activity records from each key master, each application programming interface, and each cloud lockbox for actions associated with each individual's files, keys or metadata;

b. wherein the registries are configured to analyze the activity logs to detect anomalous access to data;

c. wherein the registries are configured to communicate with the cloud

lockboxes to halt access to the affected individuals' data responsive to detecting anomalous access to data;

d. wherein the registries are configured to notify the members and the

individuals of anomalous access and halting of access;

e. the members and the individuals reviewing activity logs at will.

The system of claim I, wherein the three-party security mechanism is configured to enable a time-to-live feature:

a. wherein an application programming interface in combination with a key master of a member is configured to enable the member to create metadata including a time-to-live value for the data in accordance with an agreement within the community of interest; and

b. wherein the key master in combination wit the application programming interface is configured to enable the member to retrieve data with time-to- live metadata and to acknowledging one of ability and Sack of ability to honor the time- to-live setting.

The system of claim 1 , wherein the three-party security mechanism is configured to enable changing a key pair:

a. wherein a key master of a first member is configured to generate a new public-private key pair for a first individual responsive to receiving a request from the first member to change the first individual's public- private key pair;

b. wherein the key master of the first member is configured to notify a

registry of new public key for the first individual;

c, wherein the registr is configured to notify a cloud lockbox of a key

change for the first individual ;

d. wherein the cloud lockbox is configured to facilitate the retrieval of all of the firsi individua s affected data;

e, wherein the key master of the first member is configured to decrypt the first individual's data with an old private key and re-encrypt, the data with the new public key;

£ wherein the key master of the first member is configured to transmit the re-encrypted files of the first individual to the cloud lockbox;

g. wherein the cloud lockbox is configured to acknowledge receipt of re- encrypted files of the first individual and to provide new receptors to the first member's key master; and

h. wherein the key master of the first member is configured to transmit the new private key to a key master of a second member.

The system for claim I , wherein the three-party security mechanism is configured to enable recovery of a private key;

a. wherein a key master of a first member is configured to recover a first individuars private ke from key master of a second member with access to the private key, the process being mediated by the registry.

The system of claim 1, wherein the community of interest spans a plurality of cloud providers for provisioning cloud lockboxes.

The system of claim 1 , wherein the community of interest spans multiple registries, wherein the multiple registries are configured to communicate among one-another in the community of interest to maintain unique identities.

The system of claim I, wherein the community of interest comprises one of: a. a smal l group of indi viduals; b. all individuals residing in a given country; and

c. a number of individuals connected through any type of affiliation.

The system for claim L wherein a key master is configured to participate in a plurality of communities of interest, wherein each of the plurality of communities of interest'.

a. requires a different encryption algorithms;

b. requires a different identity verification processes; and

c. utilizes different cloud lockboxes.

The system for claim i, wherein the three-party security mechanism is configured to minimize exposure of data to system administra tors:

a. wherein data stored in a cloud lockbox is encrypted;

b. wherein the cloud lockbox does not have the decryption key; and c. wherein a system administrator is provided with access to encrypted data but is not provided with access to the decryption key.

The system of claim 3 , wherein the three-party security mechanism is configured to enable emergency access to an individual's data:

a. wherein the three-party security mechanism is configured to enable access encrypted data of a first, individual from a first member by an emergency- member in the event of an emergency in which the first individual cannot pro ide a uthorizatkm ;

b. wherein the three -party security mechanism is configured to require the emergency-member to at least one of ha ve previously registered as a member of the community of interest and ha ve a previously registered member act on its behalf

c. wherein the three-party security mechanism is configured to provide the emergenc -member a private key of the first individual responsive to receiving a request for emergency access from the first member; and d. wherein the three-party security mechanism is configured to log all activity for review by the first individual.

30. The system of claim 1, wherein the three-party security mechanism is configured to create a holistic view of any given individual participating in a community of interest

by generating summaries, comparisons and aierts regarding a first individual, given access to data from all members for a first individual

31. The system of claim i , wherei n the three-party security mechanism is

configured to enable a hybrid cloud and on-premises storage solution with a key master offering predictive caching and application programming interfaces deeply integrated into the application.

32. The system of claim 1 , wherein the three-party security mechanism is

configured to enable application integration across a single enterprise or multiple enterprises by converting disparate dat models to a common data model with sharing of data occurring across the mechanism.