ONC Trusted Exchange Common Agreement Framework Comments Page

Back to Security Main Page

HITAC TEFCA Task Force

• Health Information Technology Advisory Committee (HITAC)
• HITAC Calendar
• Trusted Exchange Framework Task Force
• U.S. Core Data for Interoperability

HL7 TECFA Comments 2018

• Final HL7 TEFCA Comments submitted February 20, 2018 and TEFCA Security Appendix

All ONC TEFCA Documents published January 2018

• TEFCA - All Docs ONC site

Trusted Exchange Common Agreement Kick Off July 24, 2017

• Links for ONC Trusted Exchange Common Agreement Kick Off
  • Presentation Recordings
  • ONC Trusted Exchange Common Agreement deck
• 21st Century Cures Act Trusted Exchange Framework and Common Agreement Public Comment Submission site
• Comments due Aug. 25*Links for ONC Trusted Exchange Common Agreement Kick Off
• Trusted Exchange Framework Public Comment
• HL7 Response ONC Exchange Framework and Common Agreement FINAL

HL7 ONC Trusted Exchange Common Agreement Comments on July 24 Kickoff Presentations

Comment Area 1: Standardization

The definition of interoperability that most characterizes the breadth of standards developed by HL7 is the HIMSS 2013 Definition of Interoperability:

“In healthcare, interoperability is the ability of different information technology systems and software applications to communicate, exchange data, and use the information that has been exchanged.1 Data exchange schema and standards should permit data to be shared across clinician, lab, hospital, pharmacy, and patient regardless of the application or application vendor.2 Interoperability means the ability of health information systems to work together within and across organizational boundaries in order to advance the effective delivery of healthcare for individuals and communities.3 There are three levels of health information technology interoperability: 4 “Foundational” interoperability allows data exchange from one information technology system to be received by another and does not require the ability for the receiving information technology system to interpret the data. “Structural” interoperability is an intermediate level that defines the structure or format of data exchange (i.e., the message format standards) where there is uniform movement of healthcare data from one system to another such that the clinical or operational purpose and meaning of the data is preserved and unaltered. Structural interoperability defines the syntax of the data exchange. It ensures that data exchanges between information technology systems can be interpreted at the data field level. “Semantic” interoperability provides interoperability at the highest level, which is the ability of two or more systems or elements to exchange information and to use the information that has been exchanged.5 Semantic interoperability takes advantage of both the structuring of the data exchange and the codification of the data including vocabulary so that the receiving information technology systems can interpret the data. This level of interoperability supports the electronic exchange of patient summary information among caregivers and other authorized parties via potentially disparate electronic health record (EHR) systems and other systems to improve quality, safety, efficiency, and efficacy of healthcare delivery.” HIMSS 2013 Definition of Interoperability

The HIMSS definition differentiates among three types of interoperability, all of which are essential for any consideration of trusted exchange. However the definition discussed by ONC Trusted Exchange Common Agreement Kick-off meeting only discusses foundational interoperability, with the exception of Digital Bridge.

This focus on only foundational interoperability, which does not require the ability for the receiving information technology system to interpret the data is even narrower than the definition of interoperability in the 21st Century Cures Act, which mentions "use", but does not expand on what constitutes use so it is unclear whether the Act encompasses HIMSS definitions for syntactic and semantic interoperability. In any case, it seems broader than that discussed in the ONC Trusted Exchange Common Agreement presentations.

Sec. 4003. Interoperability defines interoperability as HIT that: “Enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user” “Allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable State or Federal law” "Does not constitute information blocking" 21st Century Cures Act Section 3022 Page 390 The Act's definition of Trusted Exchange is narrowed back to foundational interoperability with no mention of use: "In this section, the term ‘trusted exchange’ with respect to certified electronic health records means that the certified electronic health record technology has the technical capability to enable secure health information exchange between users and multiple certified electronic health record technology systems." 21st Century Cures Act Section 3022 Page 390

Interoperability in both the Act and the ONC Trusted Exchange Common Agreement presentations seems narrower than the previous ONC definitions, which are much closer to the HIMSS definition. For example, in the ONC Nationwide Interoperability Roadmap section Standards and Functions Overview, ONC states that "Typically five types of standards, with the accompanying implementation specifications, are necessary and used together to achieve interoperability for a given purpose." The list of standards types encompass all the levels differentiated by HIMSS:

1. Vocabulary/terminology standards are sometimes unique to health care and use case-specific (e.g., codes to represent medications cannot be also used for laboratory tests). 2. Content/format standards are also often unique to health care and may be use case-specific for things like data capture or computation within a specific clinical workflow or domain (e.g., the content/ format standard used for a referral to a specialist would not be used to bill for a procedure). 3. Transport standards are typically not unique to health care because they are used to connect two or more parties together without a focus on the data that is transported from one party to another. 4. Security standards are not unique to health care and often applied in different ways to meet given data protection requirements. However, in health care there are legal minimums for functional security outcomes that are stated in the HIPAA Security Rule. In any event, a security standard supports achieving those security outcomes prescribed by the Security Rule. These standards are discussed in the privacy and security protection sections C through F. 5. Standards for services typically represent technical infrastructure used to connect different systems together.

HL7 recommends that the Trusted Exchange Common Agreement fully adopt a complete definition of interoperability used in the ONC Nationwide Interoperability Roadmap. Without addressing the need to foster full interoperability, trust among trading partners will be impeded no matter how robustly exchange meets foundational interoperability. If receivers cannot interpret and use information shared for health care why would either the senders or the receivers engage in the exchange?

Comment Area 3 - Cooperation and Non-Discrimination

• During discussions on the Comment areas for the Trusted Exchange and Common Agreement, several use cases were raised around what constitutes "information blocking" that impedes cooperation and non-discrimination. It would be helpful to have examples of what is and is not "information blocking" that covers the following use cases:
  • While information blocking by not sending information is one side of the coin, would choosing to avoid receiving or retrieving information, for example to avoid data overload or avoid finding out about previous services in order to get more recent or immediate test results, or to bill for redundant services be considered information blocking as well?
  • Would requiring opt-in consent for health information exchange for purposes of treatment, payment, or operations be considered information blocking because ONC considers this unnecessary?
  • Would permitting opt-out consent directives for health information exchange for purposes of treatment, payment, or operations be considered information blocking because ONC considers this unnecessary?
  • Would data segmentation based on organizational policy or patient consent directive, which is not otherwise required by state or federal privacy law, be considered information blocking?
  • Would an HIO or provider segmentation of what they or patients deem sensitive health information e.g., by means of storing it in a separate data store with more stringent access controls, be considered information blocking if not otherwise required by state or federal privacy law?

Comment Area 4 Security and Patient Safety

• HL7 is concerned that privacy is not included in Comment Area 4: Exchange electronic health information securely and in a manner that promotes patient safety and ensures data integrity.
• In past ONC work in this area, in particular in the Connecting Health and Care for the Nation:

A Ten Year Vision to Achieve Interoperable Health IT Infrastructure paper, privacy was explicitly included:

• Protect privacy and security in all aspects of interoperability. It is essential to maintain public trust that health information is safe and secure. To better establish and maintain that trust, we will strive to ensure that appropriate, strong, and effective safeguards for health information are in place as interoperability increases across the industry. We will also support greater transparency for individuals regarding the business practices of entities that use their data, particularly those that are not covered by the HIPAA Privacy and Security Rules.

Connecting Health and Care for the Nation: A Ten Year Vision to Achieve Interoperable Health IT Infrastructure at page 5.

• Achieving a Trusted Exchange Common Agreement seems unlikely unless such an agreement addresses issues related to preserving the originating discloser's privacy policy governance over information about their patients as this travels through various health information exchange nodes. In addition, policy guidance and technical mechanisms to support the persistence and enforcement of the originator's privacy policy need to be specified. HL7 Privacy, Provenance, and Security standards are being used to effectively ensure this capability in behavioral health HIEs including ONC Funded Colorado Regional Health Information Organization (CORHIO) and Prince George’s County Health Department Consent2Share implementation. HL7 Security Labeling related standards are in the process of being implemented in the Veteran's Administration. These should be leveraged by the Common Agreement.

Comment Area 4: Security and Patient Safety Sharing with Privacy Protections A Learning Health System is not achievable if health information is siloed due to concerns related to ensuring privacy protection of patient deemed or policy prescribed restrictions on the collection, access, use, and disclosure of sensitive protected health information. If the Common Agreement supported the use of security labels to persist privacy protections assigned by the originating discloser, then we could move closer to a paradigm of sharing with protections rather than just protecting from sharing. This requires use of HL7 security labeling and consent directive standards in combination with data provenance to convey the privacy, security, and patient consent directive policies with which an end user must comply. Applicable security labels are derive from computable privacy, security and consent directive policies, which use the same HL7 Healthcare Privacy and Security Classification system vocabulary, Data provenance provides the stamp of authenticity, integrity, and reliability. Data provenance, if a required to remain associated with disclosed information can form the basis for accounting of disclosure. This would enable originating disclosers and their patients to track where their information is flowing, and would help ensure that health information collectors and processors are adhering to the collection, access, use and disclosure requirements in privacy, security, and patient consent directive policies. If combined with digital ledger technology, a chain of provenance would support non-repudiable accounting of disclosures. Robust provenance used for accounting of disclosures would increase the confidence in the authenticity, integrity, and reliability of health information that is essential for patient safety. Combined with evidence of compliance with privacy, security, and patient consent directive policies, these components of a Common Agreement would do much to assuage the currently high level of healthcare consumer concern with sharing sensitive health information. If sensitive health information is shared with protections, this would greatly improve patient safety and address concerns about segmenting data. Comment Areas 1 and 2: Standardization and Transparency

• It is critical to:
  • Adhere to industry and federally recognized technical standards, policies, best practices, and procedures (Comment Area 1);
  • Conduct all exchange openly and transparently (Comment Area 2) .
• These comments are in reference to the ONC assessment that "some have established a single set of permitted purposes that apply across all data exchanges while others align the permitted purposes by use case."

Comment Summary

• Trust issues related to both permitted purposes and participants is at the heart of any effort to establish a workable Trusted Exchange Common Agreement. Attempting to harmonize different HIE specific sets of permitted purposes with different HIE supported use case permitted purposes seems difficult at best given state and organizational policy differences even with respect to HIPAA treatment, payment, and operations purposes of use. Attempting to do so without establishing mechanisms for conveying permitted purposes and participants intended by the discloser will likely result in a lowest common denominator set of permitted purpose sets to be used in a homogenized set of use cases.
• The missing policy issue in this equation is that organizations are accountable for their purpose of use and minimum necessary policies. The HIPAA Privacy Rules in this area were written for a world of bilateral exchange, perhaps mediated by a clearinghouse for payment transactions. HITECH changes to the HIPAA Privacy Rule began to address issues related to exchanges within HIEs and across a single eHealth Exchange Network. Unaddressed are the complexity of the evolving exchanges among HIEs with much different trust frameworks and exchange policies linked together across multiple nodes with vastly different infrastructure and exchange paradigms. This complexity and its impact on open and transparent exchange must be adequately addressed by the ONC Trusted Framework Common Agreement if the result is confident, willing partners in this exchange. See The Regional ADT Exchange Network Infrastructure Models Brief, HIE Bright Spots: Health Information Exchange as a Key Enabler of Care Coordination – Part 1, and ONC HIE Bright Spots: How ADT Messages Support Care Coordination – Part II

Considerations and Concerns HIPAA Privacy Rule – Purpose of Use and Minimum Necessary

• Under HIPAA Privacy Rule, organizations must develop their own minimum necessary policies for internal access and purposes of use, and for external disclosure permitted purposes. These rules continue to serve the spirit of HIPAA despite the changing landscape since HIPAA’s enactment, and deserve to be fully respected despite the complexity of enforcement due to a somewhat erratic evolution of sharing exchange paradigms. If anything, these rules may be the driver for rationalizing that evolution into a more cogent approach for complying with those rules. Describing how that might be accomplished is the objective of the following comments.

Disclosure under HIPAA Privacy Rule

• It is clear that a request or disclosure to a provider for purpose of treatment is exempt from the HIPAA Privacy rules on purpose of use and minimum necessary, and that a disclosing covered entity may reasonably rely on another covered entity’s disclosure request for purpose payment and operations, there are salient parameters to reliance on the latter.
• With respect to disclosure for payment purpose of use, the definition of payment at § 164.501 does not include activities that would extend PHI sharing beyond payment activities related to a period of coverage or an encounter under that coverage in which both the provider and the payer were involved with the same patient. The minimum necessary requirements apply, and failing to do so may result in liability for breach.
• With respect to disclosure for operations purpose of use, the discloser is accountable for ensuring both that the recipient has or had a relationship with the patient who is the subject of the information being considered for disclosure and that only the minimum necessary is being disclosed, and failing to do so may result in liability for breach: "A covered entity may disclose protected health information to another covered entity for certain health care operation activities of the entity that receives the information if: Each entity either has or had a relationship with the individual who is the subject of the information, and the protected health information pertains to the relationship. HHS Uses and Disclosures for Treatment, Payment, and Health Care Operations

Current State of Inter-Organizational and HIE Exchange Determination of Permitted Purposes/Participants Payment and Operations Disclosures There are marked differences in how organizations, in particular, HIEs, determine whether the recipient has or had a relationship with the patient either for payment or operations purpose of use disclosures. The criteria used to determine that relationship is vague (for example, a claim in a state claims data base) and difficult to substantiate, especially where patients are not afforded a choice about having their information sent to the HIE or given an opportunity to specify the relationships they have or have had with HIE participants. With respect to transparency under this regime, patients must request accounting of disclosure to be made aware of the parties with which their information is share or chose to opt-out the exchange altogether assuming they know that their information is being shared.

For example, the fact that a Visiting HIE has a patient home address in the zip code of another "home" HIE does not indicate that any covered entity in the home HIE actually has a relationship with the patient, yet this is a commonly used approach for determining the HIEs to which the patient's information should be pushed using HL7 Admission, Discharge, Treatment messages (ADT) to notify unknown end users about a patient's health status. Once arrived, the criteria for determining that any participant actually has or had a relationship with the patient for treatment purposes could be tenuous based on date of any healthcare services and patient matching issues. For payment purposes, this is not at all clear given lack of clarity in HIPAA Privacy Rule about what constitutes a payment relationship. In addition, there’s insufficient incentive for making that decision deterministic as there are business models that depend of free flow of this information, for example the Medical Information Bureau use as this information is used for informing employers, credit agencies, and every type of insurance about health status of data subjects. As for operations purpose of use, criteria for determining whether a downstream recipient has or has had a relationship becomes even more difficult to discern given variances in how relationships are defined.

For example, where there are multiple connected HIEs with different governance, the provider in an opt-in for treatment purpose of use may be very uncomfortable with the breadth of multiple Beacon Community Data Use Agreement (DUA) provisions about permitted purposes and participants. In particular, the Beacon Community DUA indicates that any of the HIEs may be permitted to collect the patient's information for their "purpose of health care operations including quality assessment and improvement activities of the Covered Entities" to be shared with any intermediating HIEs participants based on vague notions of whether any of those participants has or had a relationship with the patient." Further, although the DUA states that: “Any further use of the data for publication or research will be undertaken only upon satisfaction of appropriate regulatory compliance including IRB waiver or approval, as applicable, and express written authority of Hospital Practice”, that practice may be the holder of a patient encounter record that was forwarded through multiple HIE nodes, and its authority to authorize disclosure for research overrides the originating opt-in HIE provider’s authorization to disclose only for treatment purposes. Improving Hospital Transitions and Care Coordination Using Automated Admission, Discharge and Transfer (ADT) Alerts Appendix C: Beacon Sample Data Use Agreement Data Use p. 52.

One of the concerns raised by legal analysts of the 21st Century Cures Act is that disclosing providers may find themselves between a "rock and a hard place" by what seems to be a mandate to eliminate any barriers to universal access to patient records either by the lowest common denominator rules for what counts as permissible purpose and/or permissible participant and the notion of "information blocking": Information Blocking The Cures Act also escalates existing tension between government initiatives intended to promote the efficient exchange of health information (such as the Meaningful Use program) and legal restrictions on disclosing PHI, including those proscribed by HIPAA. In most cases, HIPAA permits but does not require disclosures of PHI. In contrast, the Cures Act prohibits or restricts "information blocking" by providers, HIT developers, health information exchanges (HIEs) or networks. For healthcare providers, "information blocking" involves conduct known by the provider to be unreasonable and "likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information." The Cures Act authorizes the Inspector General of the U.S. Department of Health and Human Services (OIG) to investigate and penalize providers, HIT developers, HIEs or networks for information blocking. Providers may be faced with choosing between (1) disclosing PHI with the risk of enforcement by OCR if the provider is viewed after the fact as having disclosed the PHI to the wrong recipient or without appropriately verifying the recipient’s authority to receive the PHI and (2) declining to make a disclosure but being second guessed as unreasonable with the risk of enforcement by the OIG. The Cures Act authorizes the OIG to refer providers found to have engaged in information blocking to the appropriate agency for "appropriate disincentives" and allows the OIG to "consult" with OCR regarding HIPAA to resolve an information blocking claim. In contrast, developers, exchanges and networks may face penalties of up to $1,000,000 per violation. Time will tell how this provision will be enforced. 21st Century Cures Act - HIPAA & Other Privacy Considerations

Even where a sender can rely on the waiver of minimum necessary, the receiver remains accountable for limiting internal access and use to the minimum necessary for treatment, payment, and operations, as well as for other types of permitted purposes. It would be extremely difficult to align the different interpretations of what constitutes the minimum necessary with respect to any of these activities given that the law puts the onus of accountability of senders and receivers for internal use. Although HITECH instructed HHS to provide more guidance in this area, as has been repeatedly pointed out by NCVHS Subcommittee on Privacy, Confidentiality and Security.

Open and transparent exchange should not allow the discloser’s permitted use policies to be lost as the information moves among receivers, and should not allow the discloser’s intended use policies, for which the discloser remains accountable, to be overridden by downstream discloser’s less restrictive permitted use policies. To do otherwise by setting the lowest common denominator in a Common Agreement homogenized set of permitted purposes and use cases risks forfeiting the trust of originating covered entities and the patients whose preferences may have been factored into their disclosure purpose of use policies.

In the alternative, open and transparent exchange, which does not undermine the discretion of disclosers to decide their permitted purposes policies, would employ standard, interoperable purpose of use codes in security labels on the disclosed information, and require that downstream disclosers honor the originating discloser’s purpose policies. This is distinct from and is not suggesting a change to the current eHealth Exchange DURSA purpose of use policy, which stipulates that a recipient’s purpose of use within its own enterprise governs. This is only about the recipient’s purpose of use for further disclosure of information it did not originate. It would be best if permitted purposes were determined by applicable jurisdictional, organizational, and patient consent policies, and that these are the basis for determining which purposes apply to a given exchange.

Permissible Purposes and Downstream Participants If the provider/receiver incorporates the upstream treatment information into their records as a basis for their own records, e.g., medication list, the redisclosure of the medication list should mark any medication sourced elsewhere as for treatment only. If the HIE limits disclosure to participants based on each participant’s permissible purposes, then any provider would not be redisclosing to any payer based only on the fact that each may have had an independent relationship with the patient, which is stretching the HIPAA limitation for providers to share with payers when their relationship with the patient was in the context of shared encounters.

In addition, if business associate agreements with participants limited the redisclosure of pooled information shared through HIE to the original purpose of use codes on collected information, then there would be no situation in which that collected information should be repurposed for uses unintended by the upstream originator (even an originator from an upstream HIE) as long as the original purpose of use code governed. That is, there is no situation in which a provider/receiver of disclosed information for e.g., purpose of treatment, would need to redisclose it for any other purpose, including payment and operations, to another covered entity. The same business associate agreement should apply to other business associates that pool covered entity information such as PBMs and cloud EHR vendors. If the Common Agreement required compliance with originating discloser purpose of use, this would eliminate the need for originating disclosers and their patients from worrying about secondary and unexpected uses of this information, making sharing truly open and transparent.

This approach would make permitted purpose policy bridging possible, but only if a standardized interoperable set of "purpose of use" codes from the HL7 Privacy and Security Classification System (HCS) is adopted. The use of simple privacy tagging to inform downstream users about the minimum necessary and purpose of use requirements that a discloser intends them to comply has been demonstrated repeatedly by ONC, SAMHSA, VA, and HL7. All of HL7 product families either already or could readily leverage these codes as privacy tags in their respective "security label" syntax. For an ADT message, these privacy tags are simply codes in the MSH Security element, which should be easily read by any HIEs access control system to indicate the permissible purposes and participants. For C-CDA, the Data Segmentation for Privacy Implementation Guide provides the means for assigning these privacy tags at the header or at a granular level. FHIR Resources have had security labels from the beginning and can carry privacy tags at a granular level or as a high water mark in a bundle.

The security label confidentiality, purpose of use, the HIPAA minimum necessary obligations, and prohibitions about redisclosure without consent, in particular where a patient has not opt-ed in to a downstream HIE's "opt-out" scheme, would assure disclosers that downstream end users are informed about the sharing agreement under which they received this information, and provide at least some liability relief to the disclosers for operating under the minimum necessary policies they have adopted for different permitted purposes and participants. Given that the technology is readily available, there is no need to devolve to the lowest common denominator for permitted purposes and participants. Protected sharing is possible at the highest common denominator. The impact to HIEs is that they would need evaluate the permissible purposes and participants with which they are allowed to share this information based on the privacy tags. If this isn't possible, then upstream HIEs should be permitted to decline to share without concern that this decision would be viewed as “information blocking”.