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, but 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, dates-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?
Regarding Metadata Standards to Support Nationwide Electronic Health Information Exchange
Comments provided on RIN 0991–AB78: http://ow.ly/6vj4w
Regarding Metadata Standards to Support Nationwide Electronic Health Information Exchange
In this response, we do not address the specific questions posed in the metadata ruling proposal, but rather we argue that these metadata standards solve nothing while creating major security risks for patients. The PCAST Report argues for tagged data elements for many important reasons:
The best way to manage and store data for advanced data-analytical techniques is to break data down into the smallest individual pieces that make sense to exchange or aggregate. These individual pieces are called “tagged data elements” (TDEs), because each unit of data is accompanied by a mandatory “metadata tag” that describes the attributes, provenance, and required security protections of the data. Universal exchange languages for metadata-tagged data, called “extensible markup languages” are widely and successfully used.
One important feature of such a universal exchange language (UEL) is that they can securely hide associations among the data, since the TDEs can be disassociated from other TDEs making them impossible to be aggregated again without adequate authorization which provides the tools for rebuilding the linkages among the TDEs which adds an additional level of security above and beyond that provided by encryption alone. Putting metadata tags at the document level simply makes the information easier to find, but it also makes it easier to identify who the information describes since once the document is located, decryption alone gives full access to a set of information about the individual. If the metadata is the actual patient identifier information, how can this data be maintained as deidentified?