The Privacy and Security Tiger Team is continuing its efforts to flesh out a comprehensive privacy and security policy framework for electronic health information exchange. The framework is intended to build on current law (HIPAA, Health Insurance Portability and Accountability Act) and is based on the fair information practice principles articulated by the Office of the National Coordinator for Health Information Technology (ONC) in its “Nationwide Privacy and Security Framework for Electronic Exchange of Individually Identifiable Health Information” (first released on December 15, 2008).
The document linked here includes a brief summary of what HIPAA provides for each of the principles and the Tiger Team’s recommendations to date. The Tiger Team is eager to hear from the public about gaps in this framework that still need to be addressed.
Please use the comment section below to provide your feedback via the Federal Advisory Committee (FACA) Blog. Comments will be accepted on a rolling basis. However, the Tiger Team is in the process of setting their agenda for the summer, and comments submitted by May 11 will assist the Tiger Team in building the agenda.
Privacy & Security Tiger Team Chairs, Deven McGraw and Paul Egerman
Tags: FACA, Privacy and Security
May 11, 2011
Paul Egerman, Co-Chair
Deven McGraw, Co-Chair
C/O HIT Policy Privacy and Security Tiger Team Blog
RE: Comment on Policy and Technology Framework for Health Information Exchange
Ms. McGraw and Mr. Egerman:
The purpose of this letter is to respond to the Framework from the Tiger Team as requested. The American Health Information Management Association (AHIMA) is a non-profit professional association made up of more than 62,000 individuals who are educated and certified in health information management (HIM) and have been engaged in the confidentiality and security of health information for over 83 years.
Since AHIMA members are very interested in the use of electronic health information exchange (HIE), we have standing policy councils focused both on HIE as well as privacy and security. Members of these councils have been involved in the development of this response. Members of the councils as well as technical staff have reviewed the proposed Framework.
Page 1 of 14: Comments on Policy Principles:
• Correction: While the term “correction” may have public meaning, changes to the content of a health record is usually referred to “amendment” in the healthcare industry. When a record is amended, the information in error is identified as such but left in the record for a number of purposes. The correct information is added to the record. AHIMA recommends that when referring to this issue you use the term Correction/Amendment or note the use of the term “amendment” for better understanding.
• Individual choice: HIPAA addresses the use and disclosure of health information. There is limited if any ability for a provider to modify the collection of information – information is either collected or not collected. Where it is stored and the use of the information is a different issue. Record collection is important in the provider’s ability to render care. The health record is also a legal and business record for the provider. To withhold information from the record could result in harm to the individual or an accusation of fraud made against the provider. We recommend that the term “collection” not be included in this section.
Page 4 or 14: “Correction”
• See comment on Correction above.
• The discussion under Policy-Current Law/Regulation: the Team needs to define:
o When it is referring to paper versus electronic.
o How a provider (record holder) would notify “persons” identified by the patient of an amendment. Normally the provider would notify those to whom the amended information had been sent, by the provider not the patient.
• The Team needs to consider education and training regarding the notification of amendments. AHIMA members have no direct evidence, but given the current hybrid nature of healthcare we believe that amendments are not always conveyed as they should be.
• There needs to be a consideration of where amendments should be considered and adjudicated. AHIMA believes they should not take place in the network: rather, the amendment should be handled at the originator (provider) location. This then presumes a tagging of data for origination and an accompanying nomenclature for such tags.
• Under Notes/Considerations – Bullet #2:
o It should be clearly stated that total obliteration of a health record entry is not appropriate. The health record is a business record and falls under the Business Record Rule of the Rules of Evidence. Consumers often have the false expectation that an amended or corrected health record entry can be totally obliterated. HL7 and ASTM standards provide guidance on how to establish directories for the original incorrect entry, with flagging models for amended or corrected entries.
o When an entry belongs to a different patient and is removed before any action is taken based on that entry, documentation of such an event should exist but should not be part of the patient’s record and should not be visible except in the audit trail. To leave such an entry visible but labeled as an error:
Puts the patient at risk if the provider misses the notation that it is an error
Creates potential problems for the patient particularly with insurance carriers that often believe that “where there is smoke there is fire.”
Page 5 of 14: Openness and Transparency-Current Law/Regulation
• Currently, accounting of disclosures is rarely requested and in general tracking for TPO is not a HIPAA requirement. Accordingly, very few EHR systems have such capability for all disclosures. ARRA-HITECH proposed rules have not been released and there has been little industry discussion regarding how disclosures can be tracked especially in larger organizations where disclosure may occur for TPO from a number of locations and different HIPAA entities. This is both a policy and a technology issue.
Page 5 of 14: Openness and Transparency- Recommendations
• Bullet #1: AHIMA recommends provider and consumer education on definition and use of de-identified data. The concepts are not understood by a number of healthcare providers let alone patients and third party service organizations.
• Bullet#2: AHIMA suggests that it is time to extend HIPAA requirements to all holders of protected health information if consumer trust is to be met. There should be no category of healthcare provider that is not covered by the HIPAA privacy and security rules.
• Bullet #3: Define “indirect exchange model.”
• Bullet #3: Purposes for which exchange can occur are being changed constantly, as are exchange participants and technology partners, a definite issue in keeping hard copy information available – web site info with the ability for the patient to print should cover it, and maybe an annual signoff indicating they know where to find it if they want it. There is no way that a NwHIN participant can reasonably keep a listing of all the potential indirect participants. If the level of HIEs gets to 225-250-plus keeping a list of the possible exchange partners becomes illogical and probably complicated for the individual to understand.
• Bullet #4: AHIMA suggests changing “anticipate exchange activities” to “reasonably anticipated exchange activities.”
• Bullet #6: This item needs to be expanded in some way to cover other entities such as OCAs and Medical Homes. Given that there could be even more entities in the not too distant future OHCA may be too narrow an approach.
Page 8 of 14: Individual Choice – Notes/Considerations
• Bullet #2:
o Define “independent consent.”
o There should be a defined list of “common” exchanges so that the provider can better communicate with the individual.
o Is there a potential for a third party – say Medicare or Medicaid – to require consent?
Page 10 of 14: Notes/Considerations
• General Comment: Presuming that data can be de-identified then data collection could change over time especially if one of the goals of electronic health records and interoperable health terminologies and classifications is to improve population health and gaining a body of knowledge to improve treatment, patient safety, etc. These types of secondary data use are different than that associated, perhaps, with treatment, payment, or operations. Programs like genomics and organizations of data like ACOs are moving so rapidly that being able to define all the purposes (to what degree) becomes almost impossible, especially if science is going to be able to look at legacy data. There needs to be some flexibility in the approach to specification and there needs to be a reduction in the silos that surround public health and medical studies that are necessary to address health and treatment improvement and outcomes.
Page 13 of 14: Safeguards – Recommendations
• Bullet #2: How will a provider attest to their relationship with a patient? Each time the provider makes a request? Will this vary with emergency department physicians? Will this vary in an ACO network or within an HIEO (but not for requests outside of that HIEO)?
AHIMA and its members appreciate this opportunity to comment on the Policy and Technology Framework for Health Information Exchange and the efforts of the Tiger Team to address this complicated and changing subject. We hope these comments are helpful. If you have further questions on these comments or on the subject of privacy and security in HIEs, please contact me (dan.rode@ahima.org), or in my absence either Harry Rhodes, AHIMA’s director for practice leadership at harry.rhodes@ahima.org, or Allison Viola, AHIMA’s director for federal affairs at allison.viola@ahima.org.
Thank you for your review and consideration of these comments.
Sincerely,
Dan Rode, MBA, CHPS, FHFMA
Vice President, Policy and Government Relations
Cc: Harry Rhodes, MBA, RHIA, CHPS, CPHIMS, FAHIMA
Allison Viola, MBA, RHIA
Like or Dislike:
2 
0 (+2)
1. The “Don’t let ‘perfect’ be the enemy of ‘good enough’” principle:
Request that the TT add “procedures” in the list: “(meds, procedures, problems, allergies, labs)”.
We would reword this to “Go for 80% of the feature set…”. Eighty percent of a “full” HIE may be acceptable, but eighty percent of a trust model, or eighty percent of the patient records being matched correctly, are insufficient.
Where alternative solution designs exist, interoperability between solutions should be a requirement.
2. “Separate content and transmission standards” principle: While we agree with this separation, it is essential that the government leverage their role and specify sufficient content standards to achieve semantic interoperability.
3. “Create publicly available vocabularies & code sets” principle:
Where appropriate, we should leverage existing, publically and readily available vocabularies and codes sets and avoid proprietary and expensive code sets (e.g., CPT4), which will add a significant burden to participation.
Recommend renaming the principle to “Adopt publicly available vocabularies and code sets”.
4. “Position quality measures so they motivate standards adoption” principle:
We agree that the ability to measure and report quality should be an automated by-product of certified technologies. To that end, the quality measures used in current technologies do not use all available code sets and vocabularies to support the reporting of these measures.
For example, numerators that can only be satisfied by SNOMED codes will result in underreporting or increase the burden for providers and vendors to support since most of current technologies do not currently use SNOMED codes.
Revisit existing quality measures and ensure they are viable to capture. For example, most hospices don’t have an EMR.
5. “Individual Access” principle:
Agree with the principle, but “Readable form and format”, as an objective doesn’t go far enough. The industry should adopt semantically interoperable standards, such as C32 (or CDA “level 3”) documents.
We urge the TT to include in its Policy column “Adopt semantically interoperable standards” and to recommend specific standards, thus making interoperability a strategy for standardization.
Recommend the TT amend the description to be “human readable form and format”.
6. Correction principle:
We agree with the need for the ability of individuals to dispute the accuracy or integrity of PHR. The larger issue is the downstream implication of reporting or notifying others who need to be aware of the correction. How do we envision that technologies should facilitate the downstream propagation of the correction?
Such a system may require attribution of the authoritative source of the IIHI. The question is whether the Privacy-Security Framework would, could, or should enable such a potentially massive record-lookup system. We would like to see TT list their choice of alternatives in their recommendations.
7. Openness and Transparency principle:
We agree with the principle, but don’t agree that the ‘technologies’ should be included in the list, due to security reasons – transparency in which technologies are used may be divulging too much – putting IT systems at risk.
In Openness and Transparency > Tiger Team Recommendations page > Policy > bullet 2: “Requesting providers who are not covered…should disclose this…”: Instead of having the non-covered entity disclose itself as “non-covered”, has the TT considered a selection of valid recipient roles (e.g. Covered Entity / Business Associate / Law Enforcement / etc.) for status attestation to occur before the exchange?
In Openness and Transparency > Tiger Team Recommendations page > Policy: In bullet 6, “Patients…ability to obtain more detailed information…including a list of other entities in the OHCA that “have access to” their information” (a priori). Those that already have accessed their information (a posteriori) is the “ideal” that is specified in bullet 4.
It would be best to describe the objective here. These are potentially enormously expensive to retrofit and coordinate. Is the objective only to identify who has access in the OHCA only? Or is the ideal to have complete traceability through the chain of access? We would like to see scope clarification, and a Technology Implementation listed for a priori and a posteriori access.
8. Collection, Use and Disclosure Limitation: This topic, like many of the topics covered herein, should be regarded as a “living topic” that should evolve over time to reflect new requirements, not as a one-time, static, issue. Organizations change the way data is used on a regular basis and those new uses should be tied back to the disclosure agreements. For example, the use of existing data for ACOs is a new use for many organizations and should trigger a review of the adequacy of existing consent processes. Our concern is the lack of consistent state and federal law related to collection, use and disclosure
9. Data Quality and Integrity: Agreed. Suggest that data integrity should be defined as including “completeness of the medical record”. The data integrity and quality principal seems at odds with the current fundamental design of the Direct Project, but is a primary use case of the NHIN/NwHIN Exchange.
The TT Recommendations list “Five categories of recommendations for patient matching” but provide no technologies or enforcement levers. Given the level of fraud and the complex nature of human identity, the “Technology Implications” and the “Accountability and Oversight” columns should include those standards that address patient/identity matching. One possible candidate is the National Strategy for Trusted Identities in Cyberspace (NSTIC).
10. Safeguards principle:
Agreed. Some small physician offices have a critical lack of IT support, and an associated lack of awareness of proper risk assessments, mitigation, etc. See the State of California CalOHii for a template of what can be done in this regard (where they’ve created a state-wide template for all participants in HIE to follow related to basic risk mitigation).
11. Accountability Policy Principle:
Agreed. Suggest that IHE standards such as ATNA be leveraged as they are globally accepted and implemented widely.
The Accountability principle’s description isn’t very clear. It could say something like “Perform appropriate oversight, logging, monitoring, and detection (automated or manual) of non-adherence and breaches, to enable triggering a mitigation response”, or something similar. Consider adding TT Recommendations for Accountability specifying the as minimum floor requirements that enable breach forensics: logging to capture the requesting identity, date, system accessed, subject, etc.
Like or Dislike:
2 
0 (+2)