3. The QHIN Technical Framework
The QHIN Technical Framework, or QTF, and related Technical Trust Requirements set out the minimum technical requirements a health information network must meet to serve as a QHIN. For example, QHINs must be capable of supporting the following two exchange modalities: (1) QHIN Query (i.e., a data pull/request from one or more QHINs); and (2) QHIN Message Delivery (i.e., a data push to one or more QHINs.)
Some QTF requirements also flow down to or impact Participants and Subparticipants. For example, Participants and Subparticipants can only be attributed to a single QHIN in the RCE Directory. This means a Participant with multiple facilities cannot participate in more than one QHIN.
The RCE has also published a three-year roadmap for FHIR® readiness. FHIR® (Fast Healthcare Interoperability Resources) is a technical standard describing data formats and elements (known as “resources”) and an application programming interface (API) for exchanging health information between different computer systems. FHIR exchange is currently required by the CMS interoperability mandates for certain CMS-regulated payers to satisfy Patient Access API requirements. TEFCA will not be FHIR ready until at least 2025.
4. Standard Operating Procedures
QHINs, Participants and Subparticipants are all also required to comply with the RCE’s SOPs that apply to them. The SOPs detail the specific requirements that must be met to satisfy Common Agreement and QTF obligations, including those obligations that must be flowed down to Participants and Subparticipants. Thus far, the RCE has proposed and/or finalized over a dozen SOPs and is currently drafting several more.
Each SOP’s title page has an applicability statement that indicates to whom the SOP applies. For example, SOP: Exchange Purposes applies to QHINs, Participants and Subparticipants. This SOP requires that all QHINs, Participants and Subparticipants respond to requests for electronic health information for treatment purposes and individual access services.
The TEFCA Difference
TEFCA is not the first or only framework used to support nationwide data exchange of electronic health information. Indeed, TEFCA builds on the lessons learned by entities affiliated with the Sequoia Project that operate networks subject to similar data sharing frameworks, such as the Data Use and Reciprocal Support Agreement (DURSA) and Carequality Interoperability Framework.
TEFCA does not—and is not intended to—replace any existing health information exchanges, networks or solutions in use today. Rather, it is another option that stakeholders may choose to use to access and exchange electronic health information.
But what makes it different? TEFCA is:
- Government endorsed. TEFCA is an ONC initiative. Governmental agencies, such as the Centers for Medicare & Medicaid Services (CMS) and ONC are expected to incentivize TEFCA participation. For example, TEFCA can be selected as an option for meeting CMS’ Promoting Interoperability health information exchange measure.
- RCE approval. TEFCA requires that QHINs demonstrate that they have the technical, administrative and financial resources to support nationwide data exchange. This suggests that networks operating under the TEFCA framework may be more secure and reliable than existing networks operating under other frameworks.
- Mandatory bidirectional data exchange. Although TEFCA participation is voluntary, once an organization chooses to participate in TEFCA, participation in certain use cases is mandatory. For example, all Participants and Subparticipants must respond to requests for electronic health information for treatment purposes and individual access services. Over time, the RCE is expected to mandate participation in all the TEFCA-permitted use cases, including but not limited to payment and healthcare operations.
However, TEFCA is not a silver bullet that will solve any or all of the complexities of nationwide data exchange. TEFCA relies on each QHIN, Participant and Subparticipant to comply with the laws that apply to them. TEFCA does not propose any legal or technical solutions for data segmentation or segregation, consent management, or compliance with laws that impose more restrictive privacy requirements than HIPAA. There is no TEFCA master patient index or identity verification solution for individual access services or authorization-based use cases. It is also unclear at this time what audits and enforcement will look like for this trusted exchange framework.