TEFCA in a Nutshell – Part 2

Compliance
Apr 23, 2019

TEFCA in a Nutshell – Part 2

Written by Dan Golder

Category: Information Blocking - Interoperability - Regulatory

This past Friday (April 19, 2019) Health and Human Services (HHS) released its long awaited update to TEFCA–the “Trusted Exchange Framework and Common Agreement”. This proposed rule builds on HHS’ earlier proposed rule on TEFCA (please refer to our earlier blog post “TEFCA in a Nutshell” for a review of this initial legislation). Today’s blog post will review this new proposed rule, some of its important provisions, and how it may influence and shape our interoperability landscape in the future.

TEFCA: What is it?

To review, as required by the 2016 21st Century Cures Act, TEFCA strives to establish a single “on-ramp” for HIE that will enable providers, hospitals and other healthcare stakeholders to join any health information network (HIN) and then to automatically connect and participate in nationwide health information exchange. ONC’s stated goals for TEFCA are:

  • Provide a single “on-ramp” to nationwide connectivity
  • Electronic Health Information (EHI) securely follows patients when and where it is needed
  • Supports nationwide scalability

Key Changes from Initial Draft TEFCA Specifications

If you’re already familiar with TEFCA (if not, our earlier blog post is a good place to start), the following section will highlight the key changes from the earlier Initial Draft TEFCA Specifications (released January 5, 2018 by ONC):

Exchange Purposes Updated

HHS has defined (and broadened) a specific subset of payment and health care operations purposes for TEFCA, and the exchange of electronic health information it governs:

  • Treatment: the provision, coordination, or management of health care and related services by one or more health care providers
  • Benefits Determination: federal or state agency determination of individual benefits qualification for any purpose other than health care
  • Quality Assessment & Improvement (new): support for various quality initiatives, including outcomes, clinical guidelines, patient safety, population-based activities, protocols, case management, care coordination, etc.
  • Business Planning & Development (new): support for business initiatives such as cost-management, formulary development, payment or coverage policies, etc.
  • Public Health: support for public health activities and purposes as permitted by HIPAA.
  • Utilization Review (new): support for utilization review activities of health plans and providers including premium determinations, reimbursement, precertification, preauthorization, and concurrent & retrospective review of services
  • Individual Access Services: supports an individual’s right to obtain a copy of their EHI, and direct that copy be transmitted to another person or entity.

Note that “Health Care Operations” and “Payment” were earlier purposes that are no longer included in TEFCA, having been incorporated for the most part into the above categories.

QHIN Message Delivery (Push) Added

HHS had included a new “push” capability (i.e. sending a patient’s electronic health information (EHI) to a specific Qualified Health Information Network (QHIN) for delivery) as part of this proposal. They have also removed the requirement for “Population Level” query that was present in the first draft TEFCA rule. Currently proposed exchange modalities include:

  • QHIN Broadcast Query: Request for a patient’s EHI from all QHINs.
  • QHIN Targeted Query: Request for a patient’s EHI from specific QHINs.
  • QHIN Message Delivery (Push): QHIN delivery of a patient’s EHI to one or more specific QHINs.

QHIN Technical Framework Added

Additional information regarding the technical requirements for exchange among QHINs through development of the QHIN Technical Framework – Draft 1 – see the “QHIN Technical Framework (QTF)” section below for additional details.

Security Requirements for Exchange

HHS also specifically included clarifying information on TEFCA’s Security requirements for exchange, including:

  • Identity Proofing: Ensures identification of individual persons. The Common Agreement will adhere to Identity Assurance Level (IAL2 minimum) as specified in NIST SP 800-63A.
  • User Authentication: Establishes remote user identity using NIST draft SP 800-63B, to a minimal standard of Authenticator Assurance Level (AAL2) and Federation Assurance Level (FAL2) for federated environments.
  • Breach Notification: QHINs, Participants, and Participant Members are required to comply with Breach as per HIPAA rules (45 CFR 164.400-414), regardless of whether or not they are a covered entity or business associate. Additionally QHINs are required to notify the RCE and other QHINs in the event of a Breach.
  • No EHI Disclosure outside the US: QHINs are explicitly prohibited from using or disclosing EHI outside the United States, unless required by an individual user.
  • Meaningful Choice: QHINs must provide a mechanism for individuals to request that their EHI not be used or disclosed, except as permitted by Applicable Law (essentially an “opt-out” for patients). Note that HHS specifies that this choice will be administered on a prospective basis (so that data, once shared, is not required to be “revoked” if a patient chooses to opt out at a later date).
  • Written Privacy Notification: QHINs must publicly publish their privacy practices regarding the access, exchange, use, and disclosure of EHI, including information how individuals can opt out via Meaningful Choice.
  • Security Labels: ONC is considering including requirements for security labels (complying with various industry standards) that enable entities to allow only authorized users access to EHI. Standards potentially include SAMHSA Consent2Share, Value Set Authority Center (VSAC), HL7 Version 3, Data Segmentation for Privacy (DS4P), Release 1 (DS4P IG), Part 1: CDA R2 and Privacy Metadata.

QHIN Definition Broadened

HHS has expanded the definition to allow for a larger application pool to be leveraged for QHIN selection. Concurrent with this HHS has developed a more robust application process, that is designed to help ensure that the most qualified and experienced candidates are selected to become QHINs.

Applicants must be currently operating an existing HIE (with participants exchanging data in a live clinical environment), must meet applicable federal/state laws and submit a formal proposal describing their plan to meet all QHIN requirements.

Timelines Extended

When a new version of the Common Agreement is published, entities that have signed a Framework Agreement would have 18 months to implement updates instead of 12.

TEFCA Components: The “TEF” and the “CA” of TEFCA (and the RCE)

The Trusted Exchange Framework (the “TEF”)

Established within the 21st Century Cures Act, the Trusted Exchange Framework represents a set of six common principles, serving as “rules of the road” for information exchanges, that are designed to facilitate trust among Health Information Networks (HINs):

  • Standardization: Adhere to industry and federally recognized standards, policies, best practices, and procedures.
    • Adhere to interoperability standards of HHS, ONC and Interoperability Standards Advisory (ISA)
    • Implement technology that is easy to use and allows individuals to connect and share information
  • Transparency: Conduct all exchange and operations openly and transparently.
    • Make terms, conditions and agreements that govern exchange publicly available
    • Require all participating HINs to agree to the uses and disclosures for exchanging EHI
    • Publish and ensure participating HINs’ privacy practices are publicly available
    • Conduct any arbitration processes with other HINs in an equitable, transparent manner
  • Cooperation and Non-Discrimination: Collaborate with stakeholders across the continuum of care to exchange EHI, even when a stakeholder may be a business competitor.
    • Do not limit access to individuals’ EHI in order to gain a competitive advantage
  • Privacy, Security, and Safety: Exchange EHI securely and in a manner that promotes patient safety, ensures data integrity, and adheres to privacy policies.
    • Ensure that EHI exchange promotes safe care, including accurately matching EHI to an individual
    • Ensure individuals have the opportunity to exercise meaningful choice, if and when it is needed, prior to the exchange of EHI
  • Access: Ensure that individuals and their authorized caregivers have easy access to their EHI.
    • Do not impede or establish barriers to individuals wishing to access their EHI, or direct their EHI to designated third parties.
  • Population-Level Data: Exchange multiple records for a cohort of individuals at one time in accordance with applicable law to enable identification and trending of data to lower the cost of care and improve the health of the population.
    • Enable participants to request and receive multiple patient records at one time.

Note that exchange involves EHI (Electronic Health Information) which is defined more broadly than PHI (Protected Health Information).

The Common Agreement (the “CA”)

The Common Agreement establishes the governance necessary to scale TEFCA. The proposed architecture (a “network of networks”) will allow stakeholders the opportunity to participate as Participants, Participant Members, or Individual Users. The Common Agreement furthermore promotes a public/private partnership with HHS, and will administer three layers of governance necessary to scale the proposed system of connected HINs and QHINs:

Minimum Required Terms & Conditions (MRTCs)

ONC will develop the MRTCs, which establish the mandatory minimum required terms and conditions with which Qualified Health Information Networks (QHINs) may voluntarily agree to comply.

ONC is seeking to leverage the MRTCs as a mechanism to help remedy weaknesses inherent to existing trust agreements that are perceived to impede nationwide interoperability.

Additional Required Terms & Conditions (ARTCs)

In addition to the MRTCs, the Common Agreement will include additional required terms and conditions that are designed to facilitate the day-today operation of an HIE. These potential could include items such as fee schedules, QHIN application and onboarding, oversight and testing of QHIN compliance with the Common Agreement (along with processes for suspending and termination of non-compliant QHINs, and other terms and conditions as determined by the RCE.

Note that while the Recognized Coordinating Entity (RCE) will develop the ARTCs, ONC will have final approval of the Common Agreement.

QHIN Technical Framework (QTF)

The QHIN Technical Framework (QTF) describes the functional and technical requirements that a Health Information Network needs to fulfill in order to function as a QHIN under the Common Agreement. To establish the QTF, the RCE will work with ONC to develop and document standards which will then be incorporated (by reference) in the Common Agreement. Signatories to the Common Agreement must agree to abide by the QTF, and the associated technical requirements for exchange.

The QTF will focus on the technical components for exchange, including security-related items such as identity proofing and authentication (see the section above on “Security Requirements for Exchange”).

Note that the QTF intentionally does not specify individual standards QHINs must use, as these are regarded as internal design decisions for individual QHIN implementations. Instead multiple standards are suggested or recommended, yet each QHIN remains free to promote and leverage the operational flexibility necessary to manage, select and implement appropriate standards and approaches that best align with its business model.

Currently, the QTF describes in general the following components:

Functions Included
Certificate Policy, Secure Channel, Mutual QHIN Server Authentication, User Authentication, Authorization & Exchange Purpose, Query, Message Delivery, Patient Identity Resolution, Record Location, Directory Service, Individual Privacy Preferences, Auditing, and Error Handling.

Technical Detail
Focuses directly on information exchange between QHINs. As noted above, for most interactions within a QHIN’s network, the QHIN may determine how best to implement its responsibilities, given the guidelines available within the QTF.

Functions Enabled
QHIN Broadcast Query, QHIN Targeted Query, and QHIN Message Delivery.

Significant additional details for the MRTCs, ARTCs, and especially the QTF are included in the proposed rule, and readers are encouraged to independently review those specifics, as they may apply to their specific needs and interests.

Recognized Coordinating Entity (RCE)

The Recognized Coordinating Entity is the “third leg” of the TEFCA stool, and will establish a public / private partnership for HHS, in that it will be a privately owned entity, competitively selected by HHS to administer TEFCA. The RCE’s will be a key component of TEFCA, as it will have responsibility for virtually all of the key components for adminstration and implementation of TEFCA, including:

  • Develop, update, implement, and maintain the Common Agreement.
  • Identify, designate, and monitor QHINs.
  • Modify and update the QHIN Technical Framework.
  • Virtually convene public listening sessions.
  • Develop and maintain a process for adjudicating QHIN noncompliance.
  • Propose strategies to sustain the Common Agreement at a national level after the initial cooperative agreement period.

Selecting an RCE is a key prerequisite for the implementation of TEFCA. HHS had originally targeted spring 2018 for release of the Funding Opportunity Announcement (FOA) now targetd for April 2019. Applications will then be due June of 2019, with HHS targeting August / September of 2019 for award of the RCE – a surprisingly accelerated timeline.


Helpful Links

Information Sheets

Public Information

Historical Documents