AU2015346644A1 - 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

PCT/US2015/059717 wo 2016/077219

SYSTEM AND METHOD FOR SECURELY STORING AND SHARING INFORMATION

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Application Serial No. 14/539,614 filed on. November 12, 2014, which is a conti.nuation-in-pari of U.S. Applicatio.n Serial No- 13/665,861 filed on October 31, 2012, which clai.ms priority to U.S. Provisional Patent Application Serial No. 61/553,883 entitled “System and Method for Securely Storing and Sharing hiformaiiotT’ filed October 3 J, 2011, all 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 enci*>p>ted 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 infoniiation 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 arid retrieves and/or acts upon metadata. The related application programming interlaces 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 enctyption algoritiun, 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 infonnation. Some such systems employ cryptography, such as pubiic/private key enciyption, to protect information and.for identity management. PCT/US2015/059717 wo 2016/077219

Cn'ptography can provide strong protection, but the key exchange process makes sharing encrypted data cinmsy and sometimes insecore. Weak, absent, or disconnected identity verification also degrades the effectiveness. (000S| Accordingly, there is a need for systems, methods, and devices that enable secure exchange of encryption keys among any community of interest. Specificany, 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 infoiTOation only to those who are authorized and that integi'ated 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 commimity 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 softw'are, pre.ferably provisioned as an appliance, to create and manage keys for individuals, handle encryption, and decryption and conduct key exchanges w'ith other members. The cloud lockboxes manage file storage, retrieval, and access control. The related application programming interfaces suppoit with multiple levels of integration and generate metadata specific to the needs of the application. A community of interest establishes operating paiameters including·, selecting an encryption algorithm, establishing identity verification processes, and selecting a security level 10007] According to the second aspect of tire 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 encryirtion 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 featrires, and determining the minimum application integration levels. PCT/US2015/059717 wo 2016/077219 [0008] According to die third aspect of the present application, a method for creating featuies through protocols operating among die parties and metadata is disclosed. The protocols and metadata enable features including·, detection and halting of anomalous access, time-to-liw 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 tburth aspect of the present application, a method for minimizing the exposure of data to system administrators is disclosed. The protected data is encrv'pted prior to reaching tlie cloud lockbox, the cloud lockbo.x never has tlie decryption key, thus the system administrator perfonning duties for perlbnnance optimization and maintenance of the cloud lockboxes has access to the etictypted 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-hased or cloud-based storage of the application itself 1001.0] .According to the fifth aspect of the present application, a method for integrating with applications and creation of hybrid cloud and on-premises data storage solutions is disclosed. The invention provides robust approaches for the integration of an application into the coramimity of interest by providing both published and unpublished application programming interfaces sup|X)rting multiple levels of application integration ranging from native integraiion to the use of industr\'--standard interfaces to simple archiving solutions. The method facilitates die creation of hybrid cloud and on-premises storage solutions with predictive caching; and provides a method to integraie disparate applications within a single enterprise or across multiple enterprises.

[0011 ] According to the si.xth aspect of the present application, a method for offering a variety of security levels is disclosed. The invention can be 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 civiliau standards for protecting confidentiality such as Health information Portability and Accountability Act; c. relatively low level security required for non-sensitive information.

The desigti traverses these various security levels based on: PCT/US2015/059717 wo 2016/077219 d. Deploying the key master as an appliance thus keeping critical processes such as key management, encryption and decrypticm witliin a hardened envircmment rather than nmning this software on a general puipose computer; e. Depth of integration with the applications; f. Optional registered IP address restrictions.

BRIEF DESCRIPTION OF THE DR AWINGS

[0012] The accompanying figures, which are incorporated in and constitute a part of the specification, illustTate various example systems, devices methods, and so on, and are used merely to illustrate various example embodiments. It should be noted that various components 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 wuy as limiting, [0013] Figure 1 is a schematic block diagram illustrating an e,xampie environment for the systems, devices and methods of the present application.

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 registnuion process using the UHE of Figure 1. t>{ Figure 4 is a schematic block diagram illustrating a patient registration process using the UHE of Figure 1. (0017| Figure 5 is a schematic block diagram iilustrating the use of activity logs using the UHE of Figure 1.

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

[0019] Figure 7 is a schematic block diagram illustrating commiraicatious in an emergency simation using the UHE of Figure 1.

[0020] Figure 8 is a schematic block diagram diustrating mechanisms for identifying fraud, waste and abuse using tire LI HE of Figure 1. PCT/US2015/059717 wo 2016/077219 |002lj Figure 9 is a schematic block diagram illustrating the generation of de-identitled patient data using the UHE of Figure 1.

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

[0023j Figure 11 is a schematic block 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.

[0025] Figure 13 is a schematic block diagram illustrating other alternate en virouments for the systems, devices, and methods of the preseui appl icatiou.

[0026] Figures 14A and 14B 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 a scbematic block diagram illustrating an alternate environment for the systems, devices, and methods of the present application for use in the legal industiy.

[0029] Figure 17 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.

Figure 18 is a schematic block diagram illustrating an altemate environment for the systems, devices, and methods of the present application for use in the real estate industrv.

DRAWING REFERENCE NUMERALS 'Hie following reference characters identify the associated elements depicted in the drawings describing the present invention. 100

Exemplary environment 101

Medical Home HCP PCT/US2015/059717 wo 2016/077219 110 HCP #i Elec ironic Health Record Soitware ! 11 Activity Log UHE API 112 Key Master (KM) 114 Patient Portal 116 Patient 118 Longitiidinal De-Identified Research Data 120 HIE Reuisiiw 130 Cloud Lockbox 140 Secondary HCP 141 Other HCPs 142 HCP #2 EHR 143 Odier HCP's EUR 144 Pharmacies 145 Pharmacy Software 146 Write-Only-Members 147 Wriie-Oniy Software (e.g. Labs, Mobile Health, etc.) 146 A Mobile Health Monitor Software 146B Lab Software 146C Otiier VV'rite-Oniy Software 148 Metadata-Only Members 149 M etad ata-Only Software (ε. g. Payers) 150 Payer 151 Payer’s Software 152 HCP #3 EHR 210 Encrypted EHR Files 210-A Encrypted HCP #2 Files 211 File Handler 212 Permissi ons Directory 214 Receptors 216 Activity Log Cloud Lockbox 250 Native EHR Files 260 API Engine 261 LJiiified Health Exchange (UHE) Application Programming Interface (UHE-APl) (ϋ-ΑΡί) " 262 Key Manager and File Broker 264 Activity I,og File Broker 281 HCP Directorv Patient Directory and Permissions 283 Cloud Lockbox Directory' 284 Registiw Directory 310 Government and industry DBs 412 Itiformation Owner Key Master PCT/US2015/059717 420-A HIE Registry - Health Care Commimity-of-iiitei'est 420-B Legal Exchange Registiy*' - Legal C’ommuuiiy-of-Interest 430-A Cloud Lockbox for HeaMt Care Community-of-lnterest 430-B Cloud Lockbox for Legal Comniumiy-of-lnterest 460 API Engine 461 Application Programming interface 462-A Key .Manager and File Broker-.4 462-B Key Manager and File Broker-B 610 Emerge.ucy Room HCP 612 Emergency Room HCP EHR 910A-910E HCPs 920A-920C HIE Registries 1010 EiCP#l 1011 HCP #2 1048 Write-Only Member(s) 1030A Cloud Lockbox #1 1030B Cloud Lockbox #2 wo 2016/077219

DETAI LED DESCRIPTiON

This present application describes systems, devices, and meiliods for providing secure exchange of encrypted data using a three-party security· mechanism consisting of tire key masters operated by the members, the registries, and the cioud lockboxes plus the application programming interfaces. » A member may be an 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 case the individual is participating by proxy. • The merabet:s use a key master software (preferably provisioned as an appliance) to: o Verify die identity and authority of tlie member in communications with the registiy; o Establish a miique identity and verify authenticity for each individual and organization in communications with the registry; PCT/US2015/059717 wo 2016/077219 Ο Generate individual public-private key pairs for each individual being represented by the member and for the organization itself (if applicable ); o Receive an individisars data and related metadata from the application programming interface; o Encrypt the data and related metadata with the individuaFs public key; o In some uses, encrypt some or all of the metadata wttli public key of metadata-only recipient; o Ca eate non-sensiti ve transactional metadata and append to the files; o Transmit tlie encrypted data, metadata, and transactional metadata to cloud lockbox; o Control of the indivddiial's private key' (required for decryption) retained by the member’s key master; o Retrieve fries from cloud lockbox and decrypt with an individuaFs private key; o With auihorization by the individual;

Securely transmit an individual’s private key to another member’s key master to permit decryption of the individuaFs files; - Update pennissions 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 verity authenticity of members, organizations, other registries and cloud lockboxes; o Estabiish unique identities for each individual represented in a. commimity 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; PCT/US2015/059717 wo 2016/077219 Ο Maiilftlin directories of individuals, members, organizations, and cloud lockboxes and other registries; o Fimction 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 for conirolling access to data files; o Receive activity records from the key masters, the cloud lockboxes, and the application programming interlaces; - Analyze activity logs to detect and halt anomalous access; - Provide the members vvitlr 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 for 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 publically 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 medianisnfs 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 bePveen; o Convert, data to./from proprietary to industry standard formats; PCT/US2015/059717 wo 2016/077219 Ο CX'invei't data between key-value data stores to/from reiational databases; o Generate metadata specific to the application that can either be; - Appended to the data and encrypted; - Encrvpted separately trom tire 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 nmnbers in applications to community of interest identification numbers for the same individuais; 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.

[0033j Digital signatures verify the identity of members, registries, and cloud lockboxes for ail communications and protocols. Encryption protects all sensitive data both in motion and at rest. Optional IP address restrictions add another level to the security model. Appliance-based option .for the encryption, decryption and key management ilnther bolsters secuniy. (0034] Any conimuniiy of interest can establish its own operating parameters including: • Selecting a public key encryption algorithm; * Selecting a regisiry or registries; * Establishing related membership requirements and identity verification thresholds; " Selecting a cloud storage provider or providers at which to establish Cloud Lockboxes; • Selecting tfom among the optional security measures; “ Determining the minimum application integration levels.

The method also provides protocois and metadata to enable features such as:

iO PCT/US2015/059717 wo 2016/077219 'rime-to-live settings to limit tiie duration of a member's access to the data of an individuar's data;

Key change and file access revocation processes;

Key and fde recoveTy processes;

Ability to de-identify the individuars files to facilitate academic or business research.

Emergency access.

The design supports addition of features by leveraging e.Kisting design elements and expanding operating protocols and related metadata.

The method minimizes the e,xposure of data to system administrators because:

The protected data is encrypted prior to reaching the doiid lockbox;

The cloud lockbox never has the decryption key;

The system admimstrators perforating 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 ΙΘ037] 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 Sumdards 140-2 Level 4;

Rigorous civilian standaixls for protecting confidentiality such as llealth Intbnnation Portability and Accountability Act; • The relatively low level security required for non-sensitive information snd many levels in between, • The design traverses these v arious 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 general purpose computer; PCT/US2015/059717 wo 2016/077219 Ο Depth of integfaiion with the applications; o Optional registered IP address restrictions. 10038] The method provides a solution to integrate disparate applications within a single enterprise or across multiple entetprises by convening data in the application programming interfaces to either industry standard representations or proprietaiy common formats.

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

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

The design provides the capability to provide a holistic view of the individuars files .for indivtidual or authorized member.

The design supports existence of multiple registries and multiple cloud lockboxes.

The design supports use of multiple encryption algoritlims simultaneously from a single key master for participation in multiple community--of“interest networks.

The systems, devices, and methods of the present application are well suited to operate in any industry requiring secum 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 sendee industry and the real estate industry, for example,

[0045] Recently, the storage requirements wdth 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, generally referred to as a unified health exchange (“UHE”), may be used to solve many of the problems created by the increased storage and usage demands in the indnstiy. 'Hie operation of the overall mechanism of the UFIE i2 PCT/US2015/059717 wo 2016/077219 will be descnbed with paiticular applicability to the health care industry, hi the health care application of the design consi der the correspondence in the following Table Ϊ.

Generalized Health Care Specific System and Method forSecureiy Storing and Sharing information = Unified Health Exchange Registry =: Health Information Exchange (HIE) Registry Membef = Health Care Provider, Pharmacy, Payer, Patient, etc. Individual Patient individuai's Proxy Health Care Provider serving as Patient's "Medical Home"

Table I

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

Increased Storage Demands |0047j Storage demands for Electronic Health Records (“EHR”) continue to expand dramatically, driven by factors inclnding high resolution imaging data, structured and unstructured data, longitudinal care needs and regulatoiy retention requirements. The

V grow ing IT combination of increased demand and high cost storage resuits in costs for the HCPs. 10048] Cloud services can dramatically reduce this cost, but cloud providers have been war\^ 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. litis i,;5 PCT/US2015/059717 wo 2016/077219 conibiiiaiion eliminates the need for tire cloud providers to conciuct breach notificatioiis, greatly diminishing their HIPAA exposure.

[0049] By relying on the cloud lockboxes for long-term record retention, the HCPs can draniaticaily reduce tire volume and thus tire 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 HCPs could eliminate storage of patient files in their EHRs instead linking the underlying EHR, file management to the UHE model. Further, the UHE approach can elirainate duplication of records within a single HCP as well as the duplication of records received from other health care providers.

Financiailv Sustainable [0050] Existing models for health infbnnation exchange involve cumbersome hierarchies of regional, state, and national e.xchanges that have failed to gain traction. The financial models underpinning most HlEs do not offer a sustainable path, primarily because the current HIEs add incremental costs for HCPs at a time of meat budaet pressure. Health Care Providers are under increasing deadline pressure to acliieve “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 iunctions of the HIE Registry. Thus the ffCP saves money on storage and a voids the cost of supporting a separate HIE infrastmcture.

Medical Home I'he 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 odier innovations such as Accountable Cai'e 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 die patient’s medical history and quick review of recent activity and condition.

[0053] Providers and payers struggle to identify fraud, waste, and abuse, fhe disparate sources of information make compiling a complete view of a patient’s care PCT/US2015/059717 wo 2016/077219 difficuit. Once wdeiy adopted. Unified Health Exchange can provide a single source of information for a comprehensive utilization review, f00S4j Personal Healdi Records {‘‘PHR”) Irave been envisioned as a key technology enabling patient education and involvement. Unfortunately, early PHR efforts have failed to; • Win support from health care providers. • Gain the trust of wary consumers over privacy conceras.

[6055] The Unified Health Exchange gives patients and/or dieir “medical home” unprecedented control over their medical records. Because the records are encrypted with individual keys, no one can decrypt the records until authorized for that specific individual.

Computer savvy consumers are able to directly authorize an HCP to access records and also e.xercise the granularity to only provide permission for specific 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. Furtlier, an audit log of access gives tlte patient complete visibility regarding who has accessed what and when.

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 HIPAA forms to manage the acces,s on behalf of the client. 10058] The HIP,A.A and HITECH rules regarding the privacy of health records have created confusion a.ud additional costs across the US health care industry. Unified Health Exchange reduces H1P.AA 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·" Hl Es utilize unique interfaces to their software, UHE offers a single interface tluough industry" standard methods to connect to what could serve as a global HIE platform. UHE Oneratirig Environment 10060] Referring now to Figure 1, there is iilustrated an example operating environment 100 of the UHE. Example environment 100 may comprise a medical home i,5 PCT/US2015/059717 wo 2016/077219 HC’P iOl, an EHR system 116, a patient portal J J4, a Key Master 112, an HIE Registry 120, a Cloud Lockbox 130, and various HCPs 141-148, As illustiated, a unified health exchange application programming interface, UHE API 261, and a Key Master 112 may be integrated with medical home's HOP #1 EHR 110 to facilitate communication with HIE Registry 120. |0061] Further, a patient 116 may communicate with Medical Home’s EHR 110 via patient portal 114, In addition, the Patient Portal 114 could utilized mobile interfaces to provide convenient interface to the Patient 116 via web or mobile app. (0062| In a ty'pical 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. 'fhe public key is provided to HIE Registry 120, and die private key is retained by medical home 101 in die Key Master 112 as the only entity initially authorized to decrypt patient fdes. This activity is depicted by reference numeral 1.

[0063] The HIE Registiy'^ 120 updates permissions directory at Cloud Lockbox 130 to authorize medical home's HCP #I EHR 110 to write files for patient 114, This activity is depicted by reference mmieral 2.

[0064] Medical Home's HCP #1 EHR 110 using the UHE API 261 and the Key Master 112 w'rites patient 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 patient care scenarios. Medical Home HCP 110 using the UHE API 261 and the Key Master 112 can also access, retrieve, and decrypt files wTitten for patient 116 by other participating entities, such as HCPs 141-148, This activity is depicted by reference numeral 3, (0065| Patient 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 11.2 updates permissions in HIE Registry 120 as depicted by reference uumerai 1. HIE Registry 120 updates permissions at Cloud Lockbox 130 in routine syncluOnizaiion process as depicted by refereuce numeral 2. Patient 116 can also audit access to his.^her files as depicted by reference numeral 4. PCT/US2015/059717 wo 2016/077219 [6066j Medical home’s HCP #1 EHR 110 using the UHE API 261 and the Key Master 112 sends private key of patient 116 directly to Other HCP’s EUR 143 using Other HCP’s 141 Key Master 112 and die UllE API 261. This exchange of private key is conducted via encrypted txansniission verified with digital signatures using the respective organizations public/private key pairs. The key exchange bypasses both the Ι Π Ε Regishy 120 and the Cloud I..ockbox 130. This activity is depicted by reference numeral 5. f0067J Otlier HCP’s EHR 143 can now retrieve, decrypt, and read flies for the specific patient 116 using the patient’s unique public/private key combination. Other HCP’s EHR 143 can now also wnite 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 pbaimacies 144, depicted by^ reference numeral 7, add a useful function for coordination of medication regimens.

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 files. This reduces ΗΪΡΑΑ 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 ίο review metadata but not detailed file information. This acti vity 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 mm:iber of useful features induding; • Neither Cloud Lockbox 130 nor HIE Registry .1,20 ever have decryption keys, reducing HIPAA liability for these entities. • HCPs 101, 141, 144, 146 and 148 save resources through intelligeni archi ving, enabling them to retain only the files needed in the short term in expensive on-preTnises storage. • Reductions in record duplication within and between HCP EHRs 110,143 and related software 145,147 and 149 also saves resources. Π PCT/US2015/059717 wo 2016/077219 • Design supports multiple cloud lockboxes 130 and multiple HIE Registries 120. • Design supports a ''glass break” scenario for emergency access to patient flies. • Design support key change process, key recovery' process, file recovery process, waste/fimid'abuse detection, use of multiple enciy’ption algorithms, and otlier features.

Unified Health Exchange C’omponents [0073] Referring now to Figure 2, there is illustrated a schematic block diagram fmther depicting operation of the UIIB of Figure 1. Each IICP accessing the storage of Cloud Lockbox 130 may comprise or access an HIE Registry 120. In the illustrated example, medical home’s HCP #1 BHR 110 utili/.es UHB .API 261 and Key Master 112 and secondaiy HCP U2 141 utilises LIME 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 HIE Registry 120 for patient identity matching to minimij?.e duplication. Each HIE Registry 120 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 ail participants.

[0074] Although a single Cloud Lockbox 130 is depicted in the example embodiment, it slioutd 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 HC’Ps Encrypted EHR files 210, which may include file metadata used for the indexing, searching, and features. The cloud lockboxes also retain a Pennissions Directory 212 derived from die HIE Registry 120 for detennining the mapping of which HCPs can read files for specific patients.

[0075] Each of die UHE API 261 comprises software integrated widi the HCPs’ Electionk Health Record (“EHR”) system. The UHE API 261 communicates with the API Engine 260 in die Key Master 112, In turn, the API Engine 260 communicates with PCT/US2015/059717 wo 2016/077219 the Key Manager and File Broker 262, also a cornponent of die Key Master 112. 'fhe API Engine 260 provides a variety of interface options and policy enforcement function. Together these softw-are 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 lockbox(s). Each Key Master 112 also manages private key exchanges with othei: HCPs.

[0076] 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 would conveit standardised formats into proprietar\' formats for local EHR use.

[0077] It should be appreciated diat 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 a stand-alone appliance that can be inserted and integrated into an existing system architecture. In another example, the Registry & doitd Interface M2 can be implemented 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 betw'een two or more applications or computing processes. A computer may be a suitable computing deMce having memory and a processor, and capable of storing program mstruclions in memory and executing the program instructions stored in memoiy' using the processor.

Public Key Encryption 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^er “medical home.” This medical home HCP #1 EHR 110 using UHE API 261 and Key Master 112 generates a unique pair of enctyption 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 112, This activity is depicted by reference numeral 2.

[0079] 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 encsv'ption 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. {'> PCT/US2015/059717 wo 2016/077219 I'he private key, retained by the medical homes would be used to decrypt the data. The Cloud Lockbox would not have the ability to deciy'pt the flies. 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 comm uni catioiis and digital signatures among registrants. ,4ii communications and updates among entities may be secured through digital signatures and encsyption including exchanges between Cloud Lockbox 130 and HIE Registry 120, exchanges between Cloud Lockbox 130 and Key Master 112, between Key Masters 112 of different HCPs, between UHE API 261 and API Emrine 260. IP Address Restrictions

In one example, within a given HCP, commimications among components of the UHE and EHRs are restricted to known machine IP addresses to further kcrease security. Between HCPs, cloud lockboxes, and HIE registries, all communications may ai,so be restricted to known machine IP address to further increase securityc In particutar, an accepted IP addresses list is maintained by the HIE Registrs^ 120 and distributed along with public keys for tliese 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 tire following permissions and file accesses are depicted in Figures 1 and 2: 1. HCP EHR 110, the medical home EHR of patient 116, wnites encrypted files to Cloud I..ockbox 130 using UHE API 261 and Key Master 112. This includes the UHE API 261 converting the file into a UHE-compatible fonnat and transmitting it to the .API Engiue 260 in die 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 *><> PCT/US2015/059717 wo 2016/077219 as for PACS images). This activity is depicted by reference numeral 2,

The API Engine 260 transfers tlie file within the Key Master 112 to the Key Manager and File Broker 262. Hie Key Manager and File Broker 262 encrypts the patient's 116 file widi patient's piibHc key and transmits it to the Cloud Lockbox 130. thus already protected in motion. The files remain encrypted at rest on cloud server of Cloud l.ockbox 130. This activity is depicted by reference mimeral 3.

The Key Manager and File Broker 262 within the Key Master 112 is the sole location at the Patient’s Medical Home 10J where die patient’s 116 puhtic-private key' pair is retained. .Neither Cloud Lockbox 130 nor HIE Registiy 120 nor HCP #1 EHR 110 have the patient’s private key, dius cannot decrypt files, reducing HIPAA liability. HCP EHR #1 110 has the authority to retrieve and decrypt the PatienCs 1.16 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 permission 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,

Upon receipt of Patient 116 file from HCP #1 HO by Cloud ,i..ockbox 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, time-io-live settings (infinity 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 Enciypted EHR Files 210 store. The file ID will not provide a mapping to Patieni 116 identity.

Creation by Cloud Ixickbox 130 of Receptor 214 and writing of EHR File 210 is recorded in Activity Log 216 at the HIE Registry 120 for review' by Patient 116 at will. This activity is depicted by PCT/US2015/059717 wo 2016/077219 reference numeral 5. Figure 5 explains the operation of the acti vity logs m 6. Patient 116 anthorizes Medical Home’s HCP #i EHR 110 to release records to Secondar)^ OCP #2 EHR 141. Aiithorization granted via e-signatuie using patient portal 114 or via signed paper form. Tire Patient 116 also has the option of granting access to metadata only. This activity is depicted by reference numeral 1. 7. The Patient 116 also has the option of setting a time-to-live for files retrieved by HCP #2 141. I'lie time-to-live feature limits the period of time that HCP #2 is authorized to retain the Patient’s 116 files. The time-to4ive 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 avvare of compliance with time-to-live by HCP #2 141 or by HCP #1 110. Time-io-!ive settings for entities originating files will be set to infmity to enable use of UHE for archiving and for minimization or eventual elimination of local EHR files. HCP #1 110 using UHE API 261 and Key Master 112 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 1X0 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 transmitied to HIE Registry 120 by HCP #1 110, This activity is depicted by reference numet'al 4. HIE Registry 120 updates Permissions Directory 212 of C’loud Lockbo.x 130 granting access to Patient’s 116 files to HCP #2 141, Selections by patient 116 of level of access, i.e. metad.ata only vs, full file access, time-to-live settings and other variables, also transmitied to Cloud Lockbox 130 by HIE Registry 120. This activity is depicted by reference numeral 5. PCT/US2015/059717 wo 2016/077219 10. Cloud Lockbox 130 using File Handler 211 creates BC’P #2 J41 specific Receptor 214 for each file of Patient 116 to which HCP #2 has been granted access. The Receptor 214, encrypted with HCP M2’s public key, includes a unique file ID, Patient’s 116 public key, tiiue-to-live settings and other metadata. The Receptor 214 includes whether the Patient 116 granted the HCP #2 141 full access or metadata only access to the file. 11. HCP #1 110 using UHE .API 261 and Key Master 112 sends patient’s private key encr>9ted using public key of HCP fl2 141 to HCP #2’s Key Master 112. The private key exchange process byq'sasses Cloud Lockbox 130 and HIE Registry 120, 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 111 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, die Patient 116 may only want the HCP #2 14J to have access to the metadate. In this case, a variation of the permission process would authorize access to the Receptors 214 bill not sliare die Patient’s private key. 14. HCP #2 EHR 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. flCP #2 EHR 141 can now retrieve existing patient files written by HCP #l EHR .110. Using the UHE API 261 and the Key Master 112, flPC #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 116 if authorization for access by HCP >? PCT/US2015/059717 wo 2016/077219 #2 J,41 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, decty’pts the Receptors with its own private key. HCP #2 EHR 141 can then decide which files to download based on the Receptor metadata. HC’P #2 EHR 140, using the file ID fiom the Receptor 214, requests the pertinent Encrypted EHR Files 210 for Patient 116. This activity is depicted by reference mimeral 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 Γονίολν by patient at will. Patient notification triggers would also be supported This activity is depicted by reference iiuraeral 5. 18. HCP m 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 numera! 7. 19. HIE Registry 120 updates permissions directory 212 of Cloud Lockbox 130, adding access for HCP #1 TIO to files written by HCP #2 141 for Patient 116. Updates may be secured through digital signature based exchanges between Cloud Lockbox 130 and HIE Registn' 120. This activity is depicted by reference numeral 5. 20. Cloud Lockbo.x 130 using File Handler 211 creates HCP #1 TIO specific Receptor 214 for each file for Patient 116 to which HCP #1 has been granted access by HCP #2 EHR. 141. The Receptor 214, encrypted with HCP #Us 110 public key, includes a unique file ID, Patienfs 116 public key, time~to4ive settings and other metadata. 24 PCT/US2015/059717 wo 2016/077219 21. HCP #1 EHR 110 also able to retrieve tiie files generated by HCP #2 EHR 141. This activity is depicted by reference numeral 3,

Access by HCP #1 EHR 110 of Patient’s 116 Receptors 214 and/or EHR File 210 for flies 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.

Encrvotion Algorithm Flexibility [OOSSj The IJHE environment .100 described herein is designed to protect the privacy and confidentiality'· of electronic health records and other fomis of sensitive information while also allow’ing such information to be securely shared rvitli others. As such, the UHE environment 100 does not include a centiai 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. | 0086j Given the modularity and isolation of key creation, enci'y'ption, and decryption within the Key Manager and File Broker 462, a given comm uni t\f~of-interest electing to use the UHE mechanism could elect to use any suitable public key enci'y'ption 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 wdiile 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-interest networks utilizing different encryption aigorithms.

Detaits of the HIE Registry [0088] Listed below are examples of the types of information which may be maintained byr HIE Registry 120, Of course, the examples listed below' are not meant to be exhaustive or prescriptive, but rather merely examples of the ways in w'hich the underlying mechanism may operate. wo 2016/077219 PCT/US2015/059717 HCP Listings

Najme of HCP

of HCP

Public Kev of HCP

Date Registered

Authorization Metlrod

Cloud Lockbox IP Addresses

Table B: HCP Listings HCP Types

Medical (feiUer/Hospital

Outpatient Clinic

Physician Practice

Home HealtlCHospice

Pharmacy

Health Depariment

Lab

Moh i le/Home Telemetrv^'

Table C: HCP Types

Palienl Listings

Public Kev of Patient

Public Kev of Medical Home

Date Registered

Authorization Method

Public. Keys of HCPs Authorized to Read andOr Write Records

Key Demographic Information for identity Matching

Payerfs) 'l abte D* Patient Listings PCT/US2015/059717 wo 2016/077219

Directory of Registries HCP-Re gistry Associa ii ons

Public Keys of Other Registries I P Addresses

Table E: Directory^ of Registries

The activity logs as iUusiratedin Figure 5 contain transactional information to monitor access to patienf s files. Iliese include the Activity Log IJHE API ill. Activity Log File Broker 264 and Actirity Log Cloud Lockbox 216. The activity logs provide an essential cros.s check of file access for security purposes and also provide a rich source of information to inform the patient regai'ding access to and sharing of the EHR files, private key, etc.

The Cloud Lockbox f0089] Listed below are examples of the 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 EUR Files 210 may comprise unstructured key-value data store. • Metadata which may be used as key for gtanular permissions, searchiug and batch retrievais may include, but is not limited to; o Patient's Public Key o HCP's Public Key o Date of .Activity o File Type o Registry Public Key • HCPs may write encounter summaries to Cloud Lockbox 130 drat include pertinent information sucli as daie(s) of encounter, orders, vital signs, medications, histoiy- and physical, radiology report, physicians, discharge summary'· and links to image files also written to Cloud Lockbox 130. These files may adhere to induslry standard formats such as HL7 and be in easily processed fonnats such as XML. PCT/US2015/059717 wo 2016/077219 • iriie Permissions Directory 212 of patients’ public keys mapped to HifPs 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 axe created for each file that an HCP is autborized 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 nieiadata. • 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 ob&amp;scated, requiring the use of the File Handler 211 to retrieve files. HCP Registration Process [0090] Referring now to Figure 3, 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 tire UHE network as a HCP Registrant 101-R may be registered as depicted in Figure 3.

The HIE Registry 120 maintains database of HCPs, labs, telemetry providers, payers and any other entities that may have permission to read and'or write patient files (Registrani). 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 120 may also generate its own public/private key combination for itself as a coiporate entity.

As shown by referettce numeral 2, a Registrant 101-R may verify its identity and authority with the HIE Registry 120 ihrough multi-factor identity verification and exchanae of authori zed IP addresses.

Once verification is completed, tlie Registrani 101-R using HCP #i EHR 110-R, UHE API 261 and Key Master 112 generates its own pubHc/private key combination to identify itself as a corporate entity.

*>X PCT/US2015/059717 wo 2016/077219

As shown by reference muneral 3, the Registrant lOl-R transmits its public key to HIE Registry 120 encrypted using the HIE registry's public key using the UHE API 261. and the Key Master 112. HIE Registry 120 decrypts with own private key.

[009S| As show'n by reference numeral 4, HIE Registry 120 replies with an acknowledgement encrypted with its own private key. The Registrant lOl-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.

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

Patient Resistratitm Process

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. 10098] First, an HCP EHR #I 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 key of the HCP, decry-pted by the HIE Registry 120 with tlie HCP's pubiic 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 identity as shown by reference numeral 2. ird, the HIE Registry' 120 has three possible replies as shown by reference nmneral 3: ic key a. EXISTS: In registry, returns patient public key, medical and cloud lockbox. b. NEW: Created listing, requests public key of patient, c. MORE; indicating that additional information on patient required to detennine whether unique identity. 29 PCT/US2015/059717 wo 2016/077219

|β101] in all tinee cases, the response is encrypted with the HlE's private key for decryption by the OCP with tire HiE registry's piiblic key, coniirming identity' of the HIE registry.

[0i02| Fourth, the OCP replies as shown by reference mnnerd! 4 depending on response in received in step 2; a. ACKNOWfl.EDGE: HCP acknowledges receipt and session terminates. b. REGISTER; HCP generates public.^rivate key combination for patient. Transmits public key, ID of cloud lockbox and Payer{s) to HIE registry . c. Identity confirmation process continues, [0103j In all three cases, the response is eiicTypted with the HCP's private key for decryption by the HIE registry with the HCP's public key, confirming identity of the HIE registry. 1, the HIE Registry 120 replies as shown by reierence 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 continuation process continues.

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

[0.106] Sixth, if the Patient 116 is a new' patient to the HIE Registry network, then the HIE Registry 120 ‘s Cloud Lockbox 130 regarding registration of new Patient T16 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. 'M) PCT/US2015/059717 wo 2016/077219

Activity Loss Mechanism for Patient Information and for Detecting and Halting Unauthorized Access

Refenitig now to Figure 5, a schematic block diagi'aTn illiistTates creating and comparing Activity Logs using the IJHE of Figure 2. Creation and comparison, of Activity Logs are also supported by the example UHE environment. 10109] 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 separ'ate from the sources of Activity Log records. For example, Activity Logs .may be maintained in a ftrsi data store wdiile UFIE 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 ΛActivity Logs also provide a record of actions for review by the Patient 116. (0110] Activity Log data may be obtained from one or more of a variety of sources. For example, when the UI IE .API 261 that is integrated with HCP #1 EFiR 110 sends a file write or read reciuest to the API Engine 260 in the Key Master 112 as depicted by reference numerai 1, the UH E API 261 simidtaneously sends a report of the request to the Activity Log UHE API 1 11 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 Lockbox 130 as depicted by reference numeral 3, the Key Manager and File Broker 262 simultaneously sends a report of the request to the Activity I-og File Broker 264 at the H.I.E Registry 120 depicted by reference numeral 4. (0112] 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.

Periodically, the HIE Registry 120 will analyze activity logs, using Activity Log Compare module 280, to detect anomalies tlrat could indicate unauthorized access to Encrypted EUR Files 210 stored at the Cloud Lockbox 130 depicted by reference numeral PCT/US2015/059717 wo 2016/077219 6. if sucb an anomaly is detected, then the HIE Registty 120 may alter the Permissions Director 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 luimeral 3. in one example, the filE Registry' 120 may also notily responsibie members at the Participating HCP about the detected anomaly and denial of file retrieval. The notification may be perfonned 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.

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

In one example, the File Handler 211, Key Manager and File Broker 262, and the UHE API 261 may send periodic “heartbear messages to HIE Registry 120 to confinn ability to commrmicate. In such an e,Kample, the Activity Log Compare module 280 is able to detect the ab.sence of heartbeat entries and genemte a notification accordingly.

Inclusion of Write-Onlv-Members [01161 Refening now to Figure 6, there is a schematic block diagram illustrating sharing WTite-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

Certain providers in the health care field provide patient data without being allowed to receive patient data. Such providers, generally reierred to generally as Write-Only Members, may include participating vendors providing home or Mobile Health Monitor Software 146.Λ, participating labs running I..ab Software 146B and other participating entities with Write-Only Software 146C. fOilSj Like other HCPs, these Write-Only-Menibers 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. PCT/US2015/059717 wo 2016/077219

By fbilowing a process similar to patient registration described in reference to Figure 4, the write-only Mobile Health Monitor Software 146A, using tire UPI API 261 and the Key Master 112, may reirieve a patient's public key and the ID of Cloud f.ockbox 130 from the HIE Registry 120 as depicted by reference numeral 1. The Write-Only Participant I46A could then commence writing files encrypted with patient’s public key to Cloud Lockbox 130 as depicted by reference niimeral 1. f 0120j 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 146C would not possess any patients' private keys nor would such participanis be authorized to retrieve files from the Cloud Lockbox 130. “‘Glass Break^* Emergeucv Care Scenario

Referring now to Figure 7, there is a schematic block diagram illustrating communications within the UHE environment in an emergency situation. 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 iunctionality may work within the UH E framework. 1, Patient 116 presents to an emergency room 610, unable to provide authorization for access to hts/lier medical records depicted by reference numeral 1, The emergency room 610 is not one of the patient’s norma! HCP.s. 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 pubiic key and Cloud Lockbox 130 depicted by reference numeral 2 . 3, Emergency room 610 sends request to HCP #1 EHR 110 for emergency-based release of private key using UHE API 261 and Key Master 112. Message to HCP 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. PCT/US2015/059717 wo 2016/077219 4, HCP 110 using UHE AP! 261 and Key Master 11,2 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 6,12 depicted by reference numeral 4. 5, HIE Registry 120 updates permissions directory 212 at Cloud Lockbox 130 This activity' is depicted by reference numeral 5, 6, Emergency room 61.0 using ER HCP EHR 612, UHE API 261 and Key Master T12 can now retrieve and decrypt patient files from Qoud Lockbox 130. Emergeticy room 610 also writes encounter suinmary'· and otlier files generated during encounter to the Cloud Lockbox 130 for later review by HCP 110. Hiis activity is depicted by reference numeral 6,

If Emergency room 610 has not yet joined an applicable coniimmity 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.

Detectiitg and Preventing Waste, Fraud and Abuse [0123j In addition to the coordination of care and HIE benefits of UHE, the mechanisms also support analytical methods to detect and prevent waste, fraud and abuse as illustrated in Figure 8. 1. HCP 101, medical home of patient 116, using HCP #1 EHR 110, UHE API 261 and Key Master 112, generates a summary' digest of all files 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 prescriptioms, and redundant tests, among other things. Further, HCP EHR if 'l 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 [.ockbox 130 by using UHE API 261 integrated with the Payer’s Software 151 and Key Master 112. Payer 150 is not able to deciypt the contents without further authorization and related PCT/US2015/059717 wo 2016/077219 private key exchange. Ilius payer J50 can identify some utilization ti'ends wiA minimized HiPAA exposure. These activities are depicted by reference numeral 4, 4. Payer ISO and Patient's Medical Home 101 may conaborate 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 tlie 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 ISl, UHE API 261 and Key Master 112 may retrieve reimbursement paperwork and tvrite updates to such paperw'ork for review by Patienf 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.

Suoport for Medtcai Research [0124] Using the UHE environment 100 described herein, one or more HCPs may elect to generate coordinated and longitudinal de-identi.fied patient care research databases 118. Permission to extract such information may be solicited at the time the patient 116 is autheniicated at his/her medical home 101. The coordinated care benefits would ripple into the research database, providing a complete pictura of the individuars health histoty without any personal identifiers remaining, fhe comnuimcation 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 110, UHE API 261 and Key Master 112 provides a fiill view of the medical status and activities of patient 116. * Files may be written to a de-identified patient database 118 with a "scramble" of the patient’s 116 private key to replace the public key as a patient identifier with this new number. I'lie relationship of the new "scrambled" identifier to tlie actual patient public key may be known onlv to the Patient’s medical home 101, PCT/US2015/059717 wo 2016/077219 • Patient's Medical Home 101 may retain the mapping so that additional data for tire 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 public-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 unauthorivied access to EfOl tries 210 at Cloud Lockbox 130; decisions to revoke dectypition 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 die reason the mechanism to change or revoke access remains the same and is illustrated in Figure 10.

[0126j Upon receiving a request to change or revoke access, HCP #1 EHR 110 using UH E API 261 and Key Master 112 generates a new key pair and updates HIE RegistTV 120 with the change via a digitally signed transaction including both the old and new public keys of Patient 116 depicted by reference numeral 1.

[0127] HiE Registry 120 updates Pennissions Directory 212 with the change and with an mdication that key change process is about to commence for Patient 116 via digitally signed transaction depicted by reference numeral 2.

[0128] Permissions Director}· 212 and File Handier 211, both at Cloud Lockbox 130, prepare a new set of Receptors for Patient’s 116 files, [0129] Patient’s Medical Home 101, using BCP #1 110, UHE API 261 and Key Master 112, then transmits tiie 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 Patiem 116, both the old and the new, each encrypted with HCP #l's lie public key. These activities are depicted by reference numeral 3, [0130] HCP #1 110 using Key Master 112 retrieves ail Encrypted EHR Files 210 for Patient 116, deciypts the files with the Patient’s 116 old private key and re-enciypts the files with the Patient’s T16 new public key. HCP #1 EHR 110, using UHE API 261 and Key Master 112, then writes Encry'pted 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. PCT/US2015/059717 wo 2016/077219 BC:P #1 EH R 110, using the UOE API 261 and Key Masier 112, erases the old version of the Patient’s 116 Encrypted EHR Files 210. Oowever, the files written to Cloud Storage 130 by HCP #2 EilR. 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 intenial operations are not coTiipromised in terms of retaining patient files. These activities depicted by reference numeral 3, f0l32j Cloud Lockbox 130 records the aciivit\· in the Activity Log Cloud 216 maintained at HIE Registry 120 as depicted by reference numeral 2.

[0133j HCP #i EHR 110, using UHE API 261 and Key .yaster 112, notifies other HCPs still authorized to write to Patient’s files such as HCP h-3 EHR 152 of the Patient’s new public key depicted by reference numeral 4. HCP #1 EHR 110, using Key Master 112, also notifies other HCPs still authorized to read and decrypt Patient’s files such as HCP #3 EHR 152 of the Patient’s 116 new prh'ate 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 tor Patient 116 other than those file written by HCP #2 EHR 142 depicted by reference mmieral 5.

[0135] If HCP #2 EHR 142 software is compliant with this feature of UHE, then it can acknowledge using Key Master 112 the destaiction of Patient’s 116 Encrypted EHR 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&amp;Cl 216 maintained at the HIE Registry 120 the onicome 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 tliat, altliough 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 kev^ 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 tlie old private key now shown as 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 PCT/US2015/059717 wo 2016/077219 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 i(li39| The UHE environment ί 00 described herein is designed to protect the privacy and cordMentiality of electronic health records and other fonns of sensitive information while also allowing such inforniation to be securely shared rvith others. As such, diere is no central key authority gowming the UHE design. Each Key Master 112 operates a Key Manager and File Bfoker 262 ttiat 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 withont massive computational effort to recover the private key. Only files remaining in local EHR storage would be recoverable directly from witliin UHE, register a sei any Patient 116 ,selectina HCP #1 as its Medical Home 101.

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 scenaiios. Alternatively, HCP #1 EHR 1 JO may install and Kev Master ί 12 that is automaticaliy granted read and wnite access for

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, in the w'orst case scenario, the Patient’s Medical ISome 101 has suffered a comiption 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 the new so-ftware instance with the HIE Registry· 120 as depicted by reference numeral 1. |6144j The U-APi 261 initiates through tire Key Master 112 the key recovery· process using the public key of affected patients. PCT/US2015/059717 wo 2016/077219

The Key Master 112 then initiates the key recovery process with 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 mimeral I. 10146] 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 mimeral 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. |0J47] Key Master i ll of HCP #2 EHR 142 transmits private keys for patients in a list from HIE Registiy 120 to foe Key Master 112 of HCP #1 EHR 110 as depicted by reference mimeral 3. This communication would be further secured by digital signatures and optionally 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 muneral 2, 10149] The HIE Registry 120 then sends to the Key Musters 112 HCP #3 EHR 152 a list of patients for whom the Key Masters 112 of HCP #1 EHR 110 needs private key recovery' 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 Registiy 120 ίο the Key Master 112 of HCP #1 EHR Π0 as depicted by reference numeral 5, This communicaiion would be further secured by digital signatures and optionaliy IP address restrictious. (0151] 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 116 be unrecoverable, the Patient’s Medical Horne 101 may initiate a file recovery process that seeks to restore to the UHE network whatever EHR files for foe Patient 116 remain in local storage of foe HCP EHR PCT/US2015/059717 wo 2016/077219 participating in the care of the given Patient 116. llie key change process from Figure 10 and a modification of the key recovery process from Figure 11 that focuses on instead of keys are then invoked.

Multiple UIIE APIs at a Participating HCP A Participating HCP will in most cases operate muitipie EHR software systems as tvell as other auxihary systems requiring data feeds from EHR systems. These software systems are iikely to include hut not be limited to an inpatieni EHR, 1~EHR 110-A; an ambnlatoiy EHR, .Λ-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.

Each of the EHR 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 conitguraiion, U HE can support internal EICP 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 HEIR, systems.

Multiple ME Registries [01.57] While it would, be simpler to have a single HIE registry to serve all patients, this outcome seems unlikely in our highly competitive health care and IT markets. One of ordinary skill in the art will recognize that the UHE described herein may be embodied in alternate configurations, including an environment having multiple HIE registries as illustrated by Figure 13.

[0158] In such an embodiment, each HCP 910A-910E associates vvith only one HIE registiy· 920A-920C. The ΗΪΕ registries 920.A-920C communicate with each other during; • Patient registration process to confimr uniqueness. • Exchanae of HCP registrations. 40 PCT/US2015/059717 wo 2016/077219 * Exchairge of patient record pemiissions changes, e.g. new HCP anihodzed by patient.

Multiple Cloud Lockboxes [0159] Wliiie it WOidd be simpler to have a single provider of cloud lockboxes to serve all HCPs, one of ordinary skill in the art vvill recognize that such a configuration may not accommodate the highly competitive healtb care and IT markets. Thus, tbe UHE design accommodates the existence of multiple providers of cloud lockboxes as illustrated in Figures 14A and 14B, [0160] As iilustrated in Figure 14A, HCP 1010 is the medical home for patient A. HCP 1010 designates cloud lockbox 1030A for patient A. fhe association is identified during H I E registration of the patient. Patient A authorizes HCP 1011 to read./write tiles, HCP 1011 writes files for patient A to cloud lockbox 1030.Λ to keep all 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 1030.Λ.

[0161] As illustrated in Figure 14B, HCP 1011 is tbe medical home for patient B. HCP 1011 designates cloud lockbox 1030B for patient B. The association is identified during HIE registration of the patient. Patient B authorizes HCP 1010 to read/write files. HCP 1010 writes files for patient B to cloud lockbox 1030B to keep all patient files in one source. Similarly, write-only input tor 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 vvill 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 levels of integration is depicted in the following table. 4i PCT/US2015/059717

Level 1 Method for backsig up or archiving EHR files. Level 2 Engaged m a network of providers for health information exchange. Level 3 Honor incoming revocation requests. Honor time-to-live settings in meta data. Level 4 Rete io full metadata m native .EHR file storage. Provide identity' of indivki.oal who accesses patient files tor additional detail "m activity logs. Level 5 Use of UHE with local caching as primary file store. wo 2016/077219 l"ab!e 2; Levels of EHR Integration with IJHE Data Access Ontioris 10163] In some situations, it may not be necessaty to access complete data records but rather to only access a partial record of a patient, such as basic patient information. For 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. |6J64] In some situations, it may be undesirable to provide data from which specific patient identities can be determined. For example, an organization performing reseai'ch may be interested in patient outcomes in relation to a specific treatment of a disease. Fiowever, the organization performing the research may not be permiited to know the identities of the patients, fhus, in one example, patient data may be anonymized in order to eliminate infonnation such as names, addresses, and social security numbers.

Patient Dashboard (0165] In one example, the patient portal 114 may fuitlier provide patient 116 witli a patient dashboard. In particular, the patient d^hboard may provide an overview of the patient’s 116 medical histoi7 as w^ll as an overview of recent activity and medical conditions. Such a patient dashboard provides a single source of information from which a patient Π6 may obtain a personal medical summary as well as a comprehensive medical review. 42 PCT/US2015/059717 wo 2016/077219

Alternative Busioess Models in Heaith Care

Given the tlexibilitv' of the described systems, devices and methods, the UflE business model could take other forms. Figure 15 illustiates one such alternate embodiment. Figure 15 depicts an euvironnient similar to that of Figure 1 except that an entity other tlian a health erne provider may become a patient's medical home for the purposes of medical record aggregation, called a “Medical Home” Health Record Representative (“HRR”). f0167j The HCPs are or will soon be required by Federal mandate to be able to share patient records dirough a set of HIE standards, f hus, the HIE goals of IJHE could be met even if the ffCP did not directly participate in the UHE mechanism. Such an HCP would saciifice the cost savings inherent in the UHE design in terms of reducing storage costs unless they transfened their long-term record retention responsibilities to the HRR, f0168] The HRR could also operate a blended architecture oiTering a choice between the standards-based HlE-interface solutions and the full UHE implemeniation.

Other Industries (>yj 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 tvide variety of other industries in which confidential infonnation needs to Ire selectively and securely shared among multiple business entities.

Legal Industry |0i70j 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 owmer of tlie public/private key set. Similar to the health care industry, other busines,s entities could provide the “legal home” other than law firms. (01711 Other law firms, prosecutors and courts may be granted granular read^vrite access on a ciieiit-by-ciient basis. Write-only participants such as court reporters and labs i securely write files to the client’s case file wnthout gaining die ability to retrieve 4.5 PCT/US2015/059717 wo 2016/077219 and/or decrypt any other files related to the case. The client rvould have a contpiete view of all files related to his/her case and the ability to aodit access.

Real Estate Industry

Refening now to Figure 17, there is iilustrated 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 entides. Once again following the concept of the “medicai home” this model addresses the creation of a “real estate home” for the client. Such a “home” selection does not preciude 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 “real estate home” other than real esiate firms.

Other realtors, mortgage brokers, lawyers, developers, etc. may be granted granular read-write access on a client-by-dient 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 to audit access.

Information Owner Controlled 10174] The preceding depictions of die system have assumed the presence of a proxy acting on the information owners request to manage die owner’s information. However, as shown in Figure 18, an example design also supports a stand-alone use of the mechanism operated by the owner to directly manage multiple types of infonnation 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 owmer 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 wdth the owner using his/lier own Key Master 412. |0175| The API Engine 460 could support APIs 461 for a variety of desktop and mobile applications running on any suitable operating system. 10176] In one example, information owmer inair elect to run multiple Key Manager and File Broker modules 462 in the Kev Master 412. In this w'av, the Infomiation PCT/US2015/059717 wo 2016/077219

Ov\^er call paiticipate in multiple communii>"-of~interest networks operating witii different enci/yption algorithms. In this example, the Key Master 412 contains t\\x> Key Manager and File Brokers, 462-A and 462-B each operating a different encryption algorithm specific to tlie two specific comiminhies-of-interest depicted. In particular. Key Manager and File Broker-A 462-A uses an encryption algorithm shared by all members of the comrainiity-of-mterest participating in the health care network represented by Cloud Lockbox Health Care 430-A and HIE Registry 420-A. Key Manager and File Broker-B 462-B uses an encry''ption algoritlun shaied by all members of the community-of-interest participating in the legal network represented by Cloud Lockbox Legal 430-B and Legal Exchange Registry 420-B. 'rhus, a single Key Master 412 could support multiple Key Manager and File Broker 462 modules for participation in multiple commnnity-of-interest networks.

Wide ApoHcafatliW ((H77j 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 infonnation regarding an individuai, such as the insurance industry, social service agencies, commercial research and development, scientific research, and finance, for example. (0178) From the iiifomration contained herein, those skilled in the art will perceive improvements, changes and modifications to die 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. f0179j NotwitlistancUng that die numerical ranges and parameters setting forth the broad scope of the invention are approximations, the numerical values set forth in the specific examples ai'e reported as precisely as possible, /\ny numerical value, however, ihherendy contains certain errors necessarily resulting from the standard deviation found in their respective testing measurements.

[6180] Furtliermore, w'hile 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 4,5 PCT/US2015/059717 wo 2016/077219 every conceivable combination of components or methodologies for purposes of describing the devices, systems, metliods, 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 Αόπι such details without departing from the spirit or scope of the applicant’s general inventive concept. Thus, this application is intended to embrace alterations, raodificaiions, and variations that fall within the scope of the appended claims. The preceding description is not meant to limit tire scope of the invention. Rather, the scope of the in vention is to be determined by the appended claims and their equivalents, 10.18.1.] Finally, to the extent that the term “Includes” or “inclnding” is employed in the detailed description or the claims, it is intended to be inclusive in a manner similar to the tenn “comprising,” as that term is interpreted when employed as a transitional word in a claim. Furthermore, to the extent that the tema “or” is employed in the claims (e.g., A or 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. Gamer, A Dictionary of Modem Legal Usage 624 (2d. Ed 1995),

Claims (32)

1. 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, a nd cloud lockboxes, wherein the three-party security mechanism is configured to be integrated with via application programming interfaces.
2. 2. The system of claim I , 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. 3. The system of claim 1, wherein tire 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. 4. The system of claim 1, wherein the three-party security mechanism as a standalone service.
5. 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.
6. 6, 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.
7. 7, The system of claim 1, 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-private key pair for each individual and organization; d. receive individuals5 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; II 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; l. 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.
8. 8, Hie system of claim 1, 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.
9. 9, The system of claim 1, wherein a registry is configured to: a. establish a unique 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 interest; d. maintain a directory of individuals, members, organizations and cloud lockboxes, and other registries, wherein die registry is configured to function as a clearinghouse for members to retrieve public keys of other members, individuals, organizations and cloud lockboxes; e. record the ΪΡ 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 togs from the key masters, the application program interfaces, and the cloud lockboxes to: i, analyze activity logs to detect and halt anomalous access; and if 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, tire cloud lockboxes, and other registries to verify accessibility of activity reporting module.
10. 10. The system of claim I, wherein a cloud lockbox comprises software operating at a cloud provider, die 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.
11. 11. The system of claim 1. wherein an application programming interface is configured to: a. offer flexibility in adapting to the needs of the communi ty of interest; b. consist of publicaliy published and private proprietary methods to integrate to applications being used by the members of a c ommuni ty 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 solution; and i. transmit activity records of file retrieval requests and access revocations to the registries.
12. 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. 13. The system of claim 1. wherein the three-party security mechanism is configured to offer a plurality of security levels bv: a, deploying the key masters as an appliance; h. integrating applications deeply with the mechanism to provide additional information such as the internal application username 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. 14. The system of claim 3 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 die permissions of a key master for a first member to store data in the cloud lockbox for a first individual; h. 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 metadata-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. wherein 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 tire key master of first member; and i, wherein 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. 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 data of die first individual as authorized by the first member; d. wherein the key master of die first member is configured to transmit a private key of die first individual, to a key master of the second member, encrypted with die second member ’s public key; e. wherein die key master of the second member is configured to decrypt and store the first individual’s private key; and f. wherein the ka v master of the sec ond member is configured to retr ieve and decrypt data of the first individual from cloud lockbox.
16. 16, Hie 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 individuaTs 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. 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. 18, The system of claim 1, wherein the three-party security 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 lockbox of the first indi vidual; 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 is c onfigured to retrieve and decrypt the data originated by write-only member for the first individual.
19. 19. 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 registry 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 die metadata-only to retrieve only metadata of the first individual.
20. 20. The system of claim 1, wherein the three-partv 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.
21. 21. The system of claim 1, 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 with 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 lack of ability to honor the time-to-live setting.
22. 22. 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 registry' 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 first individual’s affected data; e, wherein the key master of the first member is configured to decrypt the first individuaFs 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 reencrypted 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.
23. 23. The system for claim 1, 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 individuaFs private key from key master of a second member with access to the private key, the process being mediated by the registry.
24. 24. The system of claim 1. wherein die community of interest spans a plura lity of cloud providers for provisioning cloud lockboxes.
25. 25. The system of claim 1, wherein die 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.
26. 26. The system of claim £ wherein the community of interest comprises one of; a. a small group of individuals; b. all individuals residing in a given country; and c. a number of individuals connected through any type of affiliation.
27. 27. 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 e. utilizes different cloud lockboxes.
28. 28. The system for claim I, wherein the three-party security mechanism is configured to minimize exposure of data to system administrators: a, wherein data stored in a cloud lockbox is encrypted; b. wherein the cloud lockbox does not have the decryption key; and e. wherein a system administrator is provided with access to encrypted data but is not provided with access to the decryption key.
29. 29. 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 provide authorization; b. wherein tire 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 have a previously registered member act on its behalf; c. wherein the three-party security mechanism is configured to provide the emergency-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. 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 alerts regarding a first individual, given access to data from all members for a first individual,
31. 31. The system of claim 1, wherein 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. 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 hv converting disparate data models to a common data model with sharing of data occurring across the mechanism.