The HITRUST Alliance is a trusted cybersecurity institution that develops frameworks to help organizations optimize their cybersecurity programs, often with the help of a managed security services provider (MSSP). One of the most useful guidance documents HITRUST publishes is the HITRUST De-Identification Framework, which standardizes practices that apply primarily to healthcare institutions but are easily adaptable and scalable to organizations in any industry.
Understanding The HITRUST De-Identification Framework
The HITRUST De-Identification Framework v1 (2015) is available for free download from HITRUST, pending a service agreement. The guide is designed to work alongside the institution’s primary offering, the HITRUST CSF. Of all the HITRUST guidelines and other components laid out across the De-Identification Framework, three are most essential:
- The initial definitions of data in identifiable, de-identified, and unidentifiable states
- The guidance on de-identification methodology and overall program methodology
- The methods provided for de-identifying data in accordance with legal regulations
Below, we’ll cover all of these segments in detail, then also look into how implementing the broad protections in the HITRUST CSF streamlines all data de-identification and protection.
Defining Categories of Identifiable Data for Healthcare
The primary reason HITRUST developed the De-Identification Framework was to address areas of confusion in the healthcare community regarding personally identifiable information (PII).
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) defines all personal patient data as “protected health information” (PHI). Any organization designated as a covered entity, such as a health provider, plan administrator, or clearinghouse, must protect PHI per the Privacy and Security Rules. These rules also apply to PHI under the control of covered entities’ business associates.
However, HIPAA’s protections apply exclusively to paper PHI files and their electronic equivalent (ePHI). This means that when data that would normally be considered PHI or ePHI is rendered unidentifiable, it is no longer subject to HIPAA protections. There is, however, a bit of dissensus in the healthcare and security communities as to what exactly should qualify as unidentifiable.
Hence the need for clear definitions that the HITRUST De-Identification Framework provides.
Request a Free Consultation
Patient Identifiable Data: Definition and Use Cases
This first category of information is the kind that HIPAA rules apply to: any data that contains personal information or PII or that could reasonably be expected to identify an individual. In particular, HIPAA specifies that files must relate to past, current, or future medical procedures, or payment for them, to qualify as PHI.
Use cases for all such protected information include:
- Direct treatment of and billing for the patients who are the subjects of the PHI
- Overall case management, including consultation and analysis, for the subject
- Assessment or inquiries into data subjects’ adherence to prescriptions or orders
- Various HIPAA-approved Institutional Review Board (IRB) or Privacy Board studies
These use cases correspond to some but not all of the Permitted Uses defined within the HIPAA Privacy Rule. See the Department of Health and Human Services (HHS) Privacy Rule Summary for further guidance on other uses allowed by HIPAA. One reason HITRUST’s list of uses is less expansive is that the framework is designed to cover broader considerations, beyond HIPAA.
Patient De-Identified Data: Definition and Use Cases
Next up is Patient-Identifiable data that has been De-Identified. This is data for which the risk of re-identification is deemed to be low, by expert or legal standards. Herein lies one ambiguous area that can lead to HIPAA compliance issues, depending on how that risk is calculated.
The HITRUST De-Identification Framework breaks this category down into two subcategories:
- De-Identified patient data – Data that cannot reasonably be expected to identify an individual patient or for which the probability of identification is low. Use cases include:
-
-
- Research into detection and other characteristics for early disease outbreaks
- Research for reducing medical errors to improve outcomes and patient safety
- Select commercial uses, such as healthcare product development and marketing
-
- Longitudinally De-Identified data – Data that corresponds to a large number of an individual’s transactions over time and yet still carries a low identification risk. Uses are:
-
- Comparative Effectiveness Research (CER), Health Economics and Outcomes Research (HEOR), and other long-term studies requiring individual patient data
Confusion about this term stems from HIPAA’s Privacy Rule provision that certain permitted uses are allowed with a “limited data set” of PHI. The only kinds of usages in which it is not beneficial to de-identify are direct disclosures to the subject of the data, which are required. Thus, these are among the only uses to which the minimum necessary requirement doesn’t apply.
Patient Non-Identifiable Data: Definition and Use Cases
The last category of information HITRUST defines is fully depersonalized, such that it could not possibly be used to identify an individual patient. This is because the information retained has no associations to the patient and could not be used to uncover their identity by any process.
With respect to HIPAA proper, the use cases for this data would not be restricted. However, HITRUST does specify recommended use cases, above and beyond HIPAA’s restrictions:
- Research and analysis regarding healthcare cost management and comparison
- Aggregated, large-scale research across populations (on infections, diseases, etc.)
- Federal Drug Administration Risk Minimization Action Plans (RiskMAPS) research
“Depersonalized” is not a permanent characteristic of any piece of data, as information added to it after this status has been achieved can cause it to revert to either de-identified or identifiable information. Therefore, as a best practice, organizations should exercise caution with all information related to patients, regardless of HIPAA applicability and irrespective of how thoroughly it has been de-identified.
Evaluating Efficacy of De-Identification Methodologies
Another major area of confusion with respect to HIPAA’s de-identification requirements stems from the fact that the HHS does not provide much regarding the explicit criteria by which to determine whether a piece of information is sufficiently de-identified. Expanded upon below, the HHS does provide two general de-identification methodologies: Safe Harbor and Expert Determination.
However, covered entities must develop their own specific processes in accordance with those guidelines. Organizations’ approaches to de-identifying data vary widely, which in many cases complicates communication and general collaboration between entities that share patient information.
After analyzing various methods used in the US and abroad, HITRUST determined that there is no one-size-fits-all method sufficient for all organizations. Instead, there are relatively objective criteria, based on HIPAA, that can be used to determine the efficacy of a program conducting the de-identification of PHI. The first four of these criteria pertain to overall program design and management, whereas the last eight criteria measure de-identification methodologies proper.
Program Methodology: Four Primary Criteria to Evaluate
The HITRUST De-Identification Framework criteria for evaluating De-ID programs are:
- Governance – Effective management and clear delegation of responsibilities are critical to secure de-identification. Organizations should optimize the following, at a minimum:
-
-
- Identification and assignment of responsibilities and areas of responsibility
- Development, dissemination, and deployment of policies and procedures
- Training and mandatory transparency for all de-identification processes
- Regular assessment of data and practices, ideally with external validation
- Examination and adjustment for changing laws and regulatory requirements
-
- Documentation – All elements of the de-identification process and programs governing it must be documented, with regular assessments and analyses of all documentation.
- Identification – Data custodians, recipients, and all other parties who may come into contact with PHI must be identified and documented, along with all potential use cases.
- Scrutiny – All processes within the data program must come under scrutiny by experts or regulatory bodies at regular intervals. HITRUST recommends undergoing partial reviews at least annually, with deeper system-wide analysis every three years.
Appendix B of the guide provides a sample scoring methodology using these criteria.
De-Identification Methodology: Twelve Criteria to Evaluate
The HITRUST De-Identification Framework criteria for evaluating De-ID methodologies are:
- Re-Identification (Risk Thresholds) – Organizations must define clear re-identification risk thresholds based on the context surrounding the data (recipients, controls, etc.).
- Measurement (Re-Identification Risks) – Once clear thresholds are established, the organization must identify methods for objectively measuring all data against them.
- Identification and Management (Identifiers) – Organizations must establish methods for identifying and managing identifiers and quasi-identifiers, including the following:
-
-
- Names, geographic locations smaller than states, and dates (except for years)
- Unique, personal, or identifying numbers (e.g., telephone, fax, license, accounts)
- Photographic images and biometric identifiers (e.g.,retina scans, fingerprints)
-
- Identification (Plausible Adversaries / Attacks) – Organizations must also identify any possible attackers or adversaries who have a motive or ability to compromise the data.
- Identification (Transformation Methods) – In most cases, data must be transformed to become de-identified. Some of the transformation processes used most often include:
-
-
- Suppression, pseudonymization, and generalization of data
- Perturbation or application of the k-anonymity principle
- Substitution or deletion of specific names or identifiers
-
- Process and Templates (De-Identification) – A manual or automated process for data de-identification, per re-identification risk analysis, must be developed and deployed.
- Mitigation (Controls for Residual Risks) – Organizations must implement technical, administrative, and physical controls, such as those detailed in the HITRUST CSF.
- Ultimate Utility (of De-Identified Data) – Finally, the de-identifying methodology must also determine the ultimate utility of the information to all parties who will access it.
Appendix B of the guide provides a sample scoring methodology using these criteria.
Implementing De-Identification Methods for Compliance
The last major component of the HITRUST De-Identification Framework comprises the guidances issued on actually implementing a successful de-ID methodology. These are based on HHS’s similar guidance on de-identifying PHI. However, HHS presents these as equivalent alternatives, whereas HITRUST argues convincingly in favor of the second.
The two methodologies are:
- The Safe Harbor method – Per HIPAA, information that would be considered PHI is de-identified if any identifiers (or quasi-identifiers; see above) have been removed.
- The Expert Determination method – Also per HIPAA, information that would be PHI is de-identified if an expert determines that the possibility of re-identification is so small as to be negligible, and the methods by which de-identification happened are documented.
While the second method is ostensibly more open to interpretation than the first, the simplicity of “safe harbor” belies the fact that it, too, requires some form of external verification. HITRUST’s detailed criteria for program and methodology assessment make expert determination more accessible for most organizations—especially with the help of a compliance partner.
Moving Beyond the HITRUST De-Identification Framework
Organizations in healthcare and other fields have many different cybersecurity needs beyond data de-identification—even de-identified data can potentially harm an organization if it falls into the wrong hands or is used inappropriately. HITRUST CSF implementation can solve all of them.
The HITRUST CSF’s Controls cover for HIPAA and various other regulatory compliance needs, along with many other concerns. These correspond to its various Control Categories, which all house individual Objectives, or aims, and References, or means by which Objectives are met.
As of the most recent edition of the framework, HITRUST v9.5, its core breaks down as follows:
- Category 0.0: Security Management – One Objective and one Reference
- Category 0.1: Access Control – Seven Objectives and 25 References
- Category 0.2: Human Resources Security – Four Objectives and nine References
- Category 0.3: Risk Management Policy – One Objective and four References
- Category 0.4: Information Security Policy – One Objective and two References
- Category 0.5: Information Security Organization – Two Objectives and 11 References
- Category 0.6: Regulatory Compliance – Three Objectives and 10 References
- Category 0.7: Asset Management Security – Two Objectives and five References
- Category 0.8: Physical Environmental Security – Two Objectives and 13 References
- Category 0.9: Communications and Operations – 10 Objectives and 32 References
- Category 0.10: Information System Management – Six Objectives and 13 References
- Category 0.11: Incident Management – Two Objectives and five References
- Category 0.12: Continuity Management – One Objective and five References
- Category 0.13: Privacy Security Practices – Seven Objectives and 21 References
Implementing all the HITRUST guidelines, up to Implementation Levels applicable to your organization, is the best way to protect all digital assets and streamline compliance needs.
De-Identify and Protect Your Data with Professional Help
If your organization is directly involved in healthcare, or adjacent to the field, you’ll need to comply with HIPAA.
On the one hand, HITRUST CSF certification may not be a legal mandate. But on the other hand, the comprehensive protection for PHI and other classes of sensitive data can optimize your security ROI.
To implement a robust cyberdefense program informed by the HITRUST De-Identification Framework or the HITRUST CSF, contact RSI Security today!
