A health information cloud (HICloud) doesn’t need Protected Health Information (PHI) to support health information exchange. You can keep PHI private and locked away in your private, secure databases. Then you can use a portion of that PHI (e.g. First Name, Last Name, Birth Date and Last Four Digits of Social Security Number), if you are authorized, or you can input your own PHI with a password, to get all the health information that is in the cloud.
Such a HICloud is highly secure from abuse by individuals who want to link health information to PHI, for insurance purposes or employment evaluation, etc., because the PHI is not there to be found linked to anything. You have to provide the PHI to make the link, but more importantly, even with the PHI (so you know Name, Birth Date and Last Four Digits of SSN) you still have to be authorized to be receiving information from any PHI you might enter. You can’t find everyone with a particular symptom, nor can you find everyone who lives in a particular place of a certain age, and you can’t associate that information with health information because that identifying information is not in the HICloud.
A few challenges arise from such HICloud, but they are surmountable. For instance, date-related information is needed for proper aggregation of health information, but using relative information such as a stamp that indicates that a particular “chunk” of health information created today was created 20 days after the previous chunk of health information. Age information can be hidden within categories like 0-4, 5-9, 10-14…older than 80.
The biggest challenge is the use case in which a care provider needs to get health information about an unconscious individual who needs emergency health intervention. If the individual has the necessary PHI on their person, then there is no problem, but what if all that is known about the individual is where they live, how tall they are, the color of their hair, and the location of a birthmark. A service could be provided, on a separate system, not directly connected to the HICloud, that allows emergency medical personnel to do searches for PHI. Â When the PHI is thought to be found, special authorization could be provided to use that PHI to aggregate that individual’s health information from HICloud.
Secure and privately maintained PHRs, EHRs, and EMRs can contain the necessary PHI for accessing all the health information in the HICloud, but only those with official authorization from the individual who owns the PHI. Even access to deidentified information about each individual requires a consent from that individual, in case that individual feels insecure sharing even deidentified information.
Such a capability makes sense and is possible. Furthermore, it makes health information exchange much easier that through a network of health information exchanges, and it provides a means of paying for the costs of the health information storage and health information exchange since those with authorized access to the consented deidentified information can be paying for that access. Furthermore, a portion of the funds received from organizations searching the consented deidentified information can flow back to the individual providing that information as a further incentive for sharing. Entire business models can be built around payment for access, health information exchange, and individual consent.
What’s holding us back from building a HICloud that contains NO PHI?
