In one of our previous posts, we said that step one in avoiding the “wall of shame” is to identify any Protected Health Information, or PHI, that your organization may have.
Step two is to protect those PHI elements, rendering them unusable, unreadable, or indecipherable to unauthorized individuals.
Isolation of PHI can be multifaceted. First ask yourself, “Do we really need to collect this? Why?” You might be surprised to learn that the real answer is “No”. One method of isolation may be not collecting the data at all.
For those instances where the PHI must be collected, you need to utilize encryption — likely multiple modes of encryption depending upon whether the data is at rest (within a database and/or on computer media), or is in motion (moving between computers). The National Institute of Standards and Technology (NIST) has guidelines that can be used as a starting discussion point for data that is at rest, and for data that is in motion.
You can also come up with a consistent method of sharing de-identified equivalents by removal of information which links medical information to a particular individual. Using a patient chart ID, for example, might sufficiently identify a record without needing to use the patient’s name and address.
You might find that for the majority of occasions where the PHI is really not needed for the task at hand, then de-identified substitutes can be used. While coming up with these equivalents, ask yourself again if the de-identified element alone is enough for all of the tasks without having to collect the actual PHI behind it.
For example, we have clients who regularly need to share lab data (CD4, HIV Viral Load, etc.) among healthcare providers. Some of this same data must also be shared with government entities charged with tracking disease progression, statistics, and outbreaks. The community-based organizations (CBO) may need a way to verify individuals to whom they provide care, while the government entities may only need to know some basic demographic data about the individual (while still isolating each individual).
For the CBOs, we might use a de-identified client code comprised of a few letters of their first and last name in combination with the individual’s date of birth and gender. The CBOs could then use an agreed upon method of comparing that client code against physical identification that the individual provides at the time they receive services — maybe requiring the individual show a government issued ID.
For the government entities who need the lab information, we might just associate some auto-incremented serial number with those same individuals when the lab and demographic information are passed along.
The key to PHI isolation and protection here is to identify those elements that must be collected, identify with whom to share those elements, and identify what form that sharing takes place.
Need help clarifying, isolating and protecting your PHI data? Give us a call.