Interoperability: The Unreachable Dream

Interoperability

by Kristin Rowan, Editor

Interoperability

The Unreachable Dream

Healthcare and care at home have been reaching for interoperability for decades. When I started working in the care at home industry, there was a learning curve for terminologies, abbreviations (oy! with the abbreviations already!), and the pain points experienced by agencies and vendors. Interoperability was at the top of that list. 2009, the first full year I worked in care at home, was the year Congress mandated EHRs and data exchange. The mandate did not accomplish much. Incompatible data structures limit post-acute care data to the most recent health event, not the patient’s full medical record.

Data Exchange

Interoperability

Following the EHR mandate, Congress continued to add regulations and rules to advance data exchange. Starting with HIPAA in 1996, interoperability advanced as follows:

Health Insurance Portability and Accountability Act ensures patient data stays private both within a healthcare system and during data exchange

Congress mandated the use of EHRs throughout healthcare

HITECH Act launched Health Information Exchanges (HIEs) that support secure exchange of information between health systems

Health Level 7 (HL7) designed a framework that establishes protocols for data exchange

Fast Healthcare Interoperability Resources (FHIR), an updated of HL7, enables processes in 84% of hospitals and 61% of clinician offices

21st Century Care Act allows patients to access their own medical information and requires developers to publish APIs and ensure all data in the patient health record is accessible through that API

Trusted Exchange Framework and Common Agreement (TEFCA) lists principles, terms, and conditions to standardize data

CMS Interoperability Framework pushes interoperability nationwide through improved data quality; advanced technology; data aggregation; and alignment of data, tools, and measures

Following the EHR mandate, Congress continued to add regulations and rules to advance data exchange. Starting with HIPAA in 1996, interoperability advanced as follows:Interoperability

  • Health Insurance Portability and Accountability Act ensures patient data stays private both within a healthcare system and during data exchange
  • Congress mandated the use of EHRs throughout healthcare
  • HITECH Act launched Health Information Exchanges (HIEs) that support secure exchange of information between health systems
  • Health Level 7 (HL7) designed a framework that establishes protocols for data exchange
  • Fast Healthcare Interoperability Resources (FHIR), an updated of HL7, enables processes in 84% of hospitals and 61% of clinician offices
  • 21st Century Care Act allows patients to access their own medical information and requires developers to publish APIs and ensure all data in the patient health record is accessible through that API
  • Trusted Exchange Framework and Common Agreement (TEFCA) lists principles, terms, and conditions to standardize data
  • CMS Interoperability Framework pushes interoperability nationwide through improved data quality; advanced technology; data aggregation; and alignment of data, tools, and measures

Thirty Years Later

Despite the laws, regulations, frameworks, and mandates, interoperability is not much better than it was in 1996. I had an experience this year that both enlightened and infuriated me. I switched health insurance plans for a variety of reasons. My new plan didn’t cover most of the doctors, hospitals, and health systems I had been using for many many years. So in February, I found a new PCP and had the standard start of care visit to establish my health history: current conditions, past conditions, past surgeries & procedures, current medications, etc. I requested referrals to new specialists and updates to prescriptions. My PCP performed a “complete physical” that was nothing more than a cursory overview. And then I waited.

Interoperability

The Waiting Game

And waited…and waited…. I thought all these organizations and standards were supposed to make this easier. Still, I waited.

  • I waited for an “invitation” to my PCPs portal to see my visit notes and test results
  • I waited for my PCP to send referrals to new specialists
  • I waited for my health insurance provider to inevitably tell me the specialist wasn’t covered under my plan
  • I waited for a new referral from my PCP
  • I waited for appointments, results, and recommendations
  • I waited for access to new patient portals
  • I waited for the portal to figure out how to give me access to three different providers in the same app
    • (spoiler alert: I have to log in to the same app three different ways to access three different providers; my providers can see all the information in one place, but I can’t)
  • I waited for test results to appear in each portal; some I had to call and request, some I’m still waiting for

Data Exchange "Advancements"

According to my research, 84% of hospitals and 61% of clinicians are currently using FHIR, designed to improve interoperability between different health systems using standard data formats and APIs.

Last month I had an appointment. Correction: I thought I had an appointment for an imaging scan. I thought this because the scheduling nurse called me to confirm the appointment day, time, and location. When I arrived, the check-in nurse couldn’t find me in their system.

It wasn’t just that she didn’t see my appointment. No, it was that she couldn’t find me at all. (We later discovered it was still pending because the imaging department never confirmed the appointment after the scheduling nurse added it.) 

She could see no current or future appointments. She could see no past appointments because they were booked a different way. She couldn’t find any record of me at all. You see, my record started in the next building over.

Error 404: Not Found

Every one of these facilities is in the same healthcare system. (Think ACME hospital, ACME imaging, ACME specialist doctor, and ACME lab) Every office is part of the same healthcare system and none of them can see each other’s information. ACME hospital can’t see the schedule for ACME imaging and can’t schedule imaging appointments outside the hospital. For that, I have to call ACME imaging.

  • But wait! The doctor wrote my referral for ACME hospital, not ACME imaging. I need a new referral.
  • But wait! Neither the healthcare system nor the specialist can write a new referral. My payer will only accept a referral from my PCP.
  • But wait! My PCP has no idea what the referral is for, how it was written, or where it’s supposed to go because my PCP can’t access my records from the healthcare system.

This is advanced data exchange using FHIR, HIE, TEFCA, and QHIN. My health system uses our local HIE and CommonWell Health Alliance, an interoperability network designated as a federal QHIN. Apparently, this ensures the health system can share data with participating providers, but not with themselves.

Home Health is Even Further Behind the Curve

After so many years, so many advancements, and so many regulations, interoperability is no more “solved” than it was in 2009. Even the health systems that are using all the tools aren’t even internally interoperable.

Home Health has an even harder time attaining interoperability. 

  • It is more difficult for HHAs to access patient information, which usually has to be manually imported into the home health EHR
  • Patient consent is required, but HHAs often deal with patients who don’t have the capacity to consent
  • Despite the requirement of APIs, most health information is spread out across multiple systems and the HHA only get information from the referring facility
  • Nearly 80% of HHAs use an EHR
  • Only 28% of HHAs are electronically exchanging information with outside facilities
  • Only 18% can integrate shared data into automated workflows
  • HHAs did not receive the financial incentives that larger healthcare systems got to push interoperability
  • TEFCA participation is not mandatory, slowing down the process of approving a data connection and exchange

Many legacy EHRs have met significant challenges moving into interoperability. Competitors in the space had no financial incentive to create standard languages and formatting designed to share information. HHAs are left with two choices: 

The costly, time-consuming task of reviewing, selecting, and onboarding an entirely new EHR –or–

Piece together workarounds with multiple 3rd party or internal solutions haphazardly strung together to resemble interoperability

Time is Up

The call for interoperability started in 1996. With little advancement and not much hope on the horizon, we (your patients) are looking for other ways to get what we need. Next week, I’ll talk about my predictions for how interoperability will progress for the next generation.

# # #

Kristin Rowan, Editor
Kristin Rowan, Editor

Kristin Rowan has been working at The Rowan Report since 2008. She is the owner and Editor-in-chief of The Rowan Report, the industry’s most trusted source for care at home news, and speaker on Artificial Intelligence and Lone Worker Safety and state and national conferences.

She also runs Girard Marketing Group, a multi-faceted boutique marketing firm specializing in content creation, social media management, and event marketing.  Connect with Kristin directly kristin@girardmarketinggroup.com or www.girardmarketinggroup.com

©2025 by The Rowan Report, Peoria, AZ. All rights reserved. This article originally appeared in The Rowan Report. One copy may be printed for personal use: further reproduction by permission only. editor@therowanreport.com

 

Implementing QHINs Interoperability Part 4

Admin

by Ben Rosen, Sr. Client Success Manager, Netsmart

Interoperability

What You Need to Know About Interoperability and How it Affects You: Part 4

For over two decades, tech companies and government agencies have been moving toward the goal of interoperability in healthcare technology. At long last, standards and protocols are in place—and continually being improved—to support open data exchange networks. As a result, healthcare providers, including human services, post-acute providers and specialty practices, have more opportunities to participate in alternative payment models and adapt more readily to the evolving payment landscape.

This is part four of a four-part series covering the forces that are driving interoperability, as well as the future vision of open networks, and what it all could mean to your organization. Read Part One HereRead Part Two Here; Read Part Three Here.

Interoperability in Healthcare

QHIN Implementation, Use Cases, and Benefits

Qualified Health Information Networks (QHIN) can support a range of use cases, including treatment, payment, healthcare operations, public health reporting and patient access to their records. These are referred to as Exchange Purposes (XPs), and all QHINs must facilitate a request for this data. The difference lies with how QHINs facilitate those requests and provide that information to you as a participant. The data uses the same network that all QHINs have built too, but there is value in what your current technology vendor can do with the data.

Complete Information Supports Decision-Making and Compliance

By enabling data exchange, QHINs help ensure providers have access to complete, up-to-date information that has the potential to improve decision-making and reduce redundant tests. The Trusted Exchange Framework and Common Agreement™ (TEFCA) network also supports the exchange of more robust types of data than before, offering participants more holistic views of individuals to support a whole-person care approach.

A QHIN can help your organization stay compliant with interoperability mandates designed to align technology with regulatory requirements, such as the 21st Century Cures Act and TEFCA. As the data exchange landscape shifts toward a more regulatory-based landscape with TEFCA at the core, remaining in compliance with certification requirements becomes increasingly important.

Complete Information Interoperability QHIN

Preparing for TEFCA and QHIN Participation

As outlined in Part 3 of this blog series, getting the most out of joining a QHIN starts with assessing your current interoperability capabilities:

  • Identify gaps in your data exchange processes and data needs
  • Collaborate with your EHR vendor to ensure technical readiness and ensure they can accommodate the QHIN data to be used with your EHR
  • Explore QHIN options and compare their offerings for your current EHR features and functionality
  • Understand and create a plan for your organization to use or increase the use of FHIR-based integrations

Once you’ve determined which QHIN will work best for your organization, you can begin nailing down specifics and start planning implementation.

Costs, Implementation and Onboarding

Costs vary by QHIN vendor and may include membership fees, transaction fees and additional charges for optional services.

Onboarding typically includes:

  • Technical integration into your EHR
  • Staff training
  • Testing and validation of data exchange
  • Establishing compliance with TEFCA requirements/signing agreements to participate

Joining the TEFCA network is built into some existing integration processes and capabilities. There are legal agreements specific to TEFCA to sign, but all technical implementations are much easier to facilitate as an already existing EHR client, assimilating into already existing workflows.

Security and Privacy

QHINs are required to meet strict security and privacy standards under TEFCA, including compliance with HIPAA and other relevant regulations. All QHINs are HITRUST-certified and ensure robust security backing for all network transactions and therefore must have incident response and mitigation procedures in place in case of a security incident. It’s important to understand the full enterprise security plan for the QHIN you decide to use and how they protect all of their solutions/programs, not just QHIN.

It’s important to understand the full enterprise security plan for the QHIN you choose and how they protect all their solutions/programs, not just QHIN. Choose a partner with a robust history as an ONC-certified EHR vendor so your data is protected in all facets of exchange. Verify enterprise-wide security procedures and incident response plans.

Regulatory Benefits and Use Cases

By selecting a QHIN and participating in a nationwide interoperability framework, your organization can stay ahead of regulatory changes, improve patient outcomes and reduce the administrative burden of managing multiple data exchange partners. With the changing regulatory landscape, including the HTI-1 and HTI-2 rules, all ONC-certified vendors must abide by those parameters. TEFCA is taking a more central role in helping to prep organizations and users to be compliant with those regulatory standards. For this reason, QHINs with a rich history of ONC certification and who have regulatory staff will have an advantage.

Exchange Purposes

Under TEFCA, QHINs will facilitate the exchange of multiple types of data, referred to as Exchange Purposes (XPs). Initially, there were six core XPs that were revealed for TEFCA:

  • Treatment –To support the provision, coordination or management of healthcare among providers
  • Payment–For activities related to billing, claims and reimbursement under HIPAA
  • Healthcare Operations–For administrative, quality improvement and other operational functions
  • Public Health–To support public health authorities in disease surveillance, reporting and response
  • Government Benefits Determination – To help determine eligibility for government programs, such as Medicaid
  • Individual Access Services – To empower individuals to access their own health data securely and conveniently

These XPs have now been expanded to include subtypes that can be read about here, via the RCE approved resource and SOP. As mentioned previously, all QHINs will be required to support the exchange of these XP’s, and all participants of QHINs will be required to respond to Treatment and Individual Access Services. An important deciding factor when choosing a QHIN is to understand the workflows to receive this information into your EHR, as well as the capabilities to persist and action the information.

# # #

Interoperability Ben Rosen Netsmart
Interoperability Ben Rosen Netsmart

Ben Rosen is a senior client success manager and business unit owner for the interoperability solution suite at Netsmart. With more than a decade of healthcare experience, Ben has led numerous initiatives to integrate healthcare systems and enhance data sharing across the care continuum. His dedication to advancing healthcare interoperability drives his active involvement in industry initiatives and standards organizations, where he provides insight for frameworks such as HL7 FHIR, USCDI and others. Ben holds a Bachelor of Science in kinesiology from Kansas State University and a Bachelor of Science in nursing degree from the University of Nebraska Medical Center.

©2025 by The Rowan Report, Peoria, AZ. All rights reserved. This article originally appeared in the Netsmart blog and is reprinted here with permission. For more information or to request permission to print, please contact Netsmart.

Evaluating QHINs Interoperability 3

Admin

by Ben Rosen, Sr. Client Success Manager, Netsmart

Interoperability

What you need to know and how it affects you Part 3

For over two decades, tech companies and government agencies have been moving toward the goal of interoperability in healthcare technology. At long last, standards and protocols are in place—and continually being improved—to support open data exchange networks. As a result, healthcare providers, including human services, post-acute providers and specialty practices, have more opportunities to participate in alternative payment models and adapt more readily to the evolving payment landscape.

This is part three of a four-part series covering the forces that are driving interoperability, as well as the future vision of open networks, and what it all could mean to your organization. Read Part One Here; Read Part Two Here.

Interoperability in Healthcare

Evaluating QHINs for your Organization

As outlined in Part Two of this series, all Qualified Health Information Networks (QHINs) must apply and be accepted according to the baseline requirements outlined by the Trusted Exchange Framework and Common Agreement (TEFCA). While the rigorous testing and project tasks for each QHIN are the same, they may differ in services offered, geographic focus, technical capabilities, pricing and specific target markets. This blog will explore similarities and differences between QHINs, to provide insights that will arm organizations with the knowledge needed to make informed decisions about selecting a QHIN.

How to choose the right QHIN for your organization

As with any major business decision, consider what your organization is currently doing for data exchange and connectivity and how these factors are likely to change in the next 18 to 24 months:

  • The services you provide today and with whom you exchange data.
  • The communities you serve.

Prospective QHINs should have experience in serving the technology needs of the communities you serve and exhibit an understanding of how your service lines could impact the types of data transactions you use. If your strategic plan calls for expanding your services or community footprint – either organically or through partnerships with other providers – you’ll need to consider how your current needs will evolve and how that will affect your QHIN criteria.

QHIN candidates should have experience working with your electronic health record (EHR) vendor and be able to manage a smooth integration with your existing technology. Compatibility with your

EHR will help simplify implementation and further establish the network as a good fit for your organization. Integration capabilities of the QHIN should lend well to your current EHR build, such as being able to integrate the QHIN data directly to your EHR workflows.

Consider technical requirements

Each QHIN will have to build to and abide by the same standards for exchange via TEFCA. These requirements are outlined in the Common Agreement and the QHIN Technical Framework documents. Differentiation among QHINs will come from doing an analysis of your organization’s data exchange requirements and then determining how well they match up with the technical infrastructure and capabilities of the QHINs.

If your service lines require special consent practices or you do business in a state with strict data laws, it is paramount that your QHIN be technically capable of handling your most complicated information sharing needs from day one. Network 

Technology

size and geographic coverage should also factor into your decision as well as the QHIN business itself. QHINs today fall into categories such as developer platforms, data exchanges, and EHRs.

Questions to ask your QHIN short list candidates

Use the previously mentioned factors to focus on your top candidates, then it’s time to start asking about specifics:

  • Cost structure and pricing
  • QHINs may charge a per-transaction fee for their connectivity services. The specific services they can charge for are outlined by TEFCA, but the amount they can charge is not. Be sure to ask about ongoing costs and transaction fees so you can accurately project costs.

  • Additional services, such as analytics or public health reporting
  • All QHINs can provide you with connectivity for data exchange. But you should also explore each QHIN’s ability to provide reporting, analytics and other value-added services that will help you relate that data to your organizational goals.

  • Customer support and ease of onboarding
  • Ask about the onboarding process, how long it typically takes and the level of support you can expect from start to finish.

  • Plans to implement FHIR
  • QHINs will all be held to the same FHIR (Fast Healthcare Interoperability Resources) standards for exchange via TEFCA. When evaluating FHIR capabilities for QHINs, it’s important to understand what the QHIN’s strategy is around subscription services and bulk data access. This also ties into the consideration that even though a QHIN may support FHIR standards, you need to evaluate how well those pieces of information are actually integrated so you receive the information in a usable form.

  • Ongoing compliance with TEFCA and security standards
  • Technology companies must meet strict standards to become a QHIN. But you should also inquire about further monitoring and safety measures that guard against breeches of security and other concerns.

  • Total transactions and how different kinds of transactions are managed
  • Ask vendors for metrics around total transactions facilitated on their network and how they manage the different exchange types that are available via TEFCA. You also should find out ratio of errors to successes they have with their current network participants.

Final Thoughts

Due diligence is always essential whenever you choose technology. Scrutinizing all the factors outlined above for QHINs is particularly important because of the potential they will have for enhancing data sharing throughout your organization. In the final part of this blog series, we will explore actual QHIN use cases and the benefits they may offer.

Coming soon in Interoperability Part 4:QHIN implementation, use cases, and benefits.

# # #

Interoperability Ben Rosen Netsmart
Interoperability Ben Rosen Netsmart

Ben Rosen is a senior client success manager and business unit owner for the interoperability solution suite at Netsmart. With more than a decade of healthcare experience, Ben has led numerous initiatives to integrate healthcare systems and enhance data sharing across the care continuum. His dedication to advancing healthcare interoperability drives his active involvement in industry initiatives and standards organizations, where he provides insight for frameworks such as HL7 FHIR, USCDI and others. Ben holds a Bachelor of Science in kinesiology from Kansas State University and a Bachelor of Science in nursing degree from the University of Nebraska Medical Center.

©2025 by The Rowan Report, Peoria, AZ. All rights reserved. This article originally appeared in the Netsmart blog and is reprinted here with permission. For more information or to request permission to print, please contact Netsmart.

Patient Data Access

Artificial Intelligence

by Kristin Rowan, Editor

Access to Patient Data

Tighter than Fort Knox

Access to patient data has always been tricky, even for the patient. Every doctor’s office, hospital, urgent care center, home health agency, and nursing facility uses their own system to house medical records. With concerns over HIPAA violations, that data is secured, sometimes in several ways simultaneously. A breach in that system could spell big trouble for the medical agency and the software company that provided it. Even in the age of electronic medical records, it is difficult to access those records without proof of identity, a signature in triplicate, and an oath punishable by death that you are allowed access to the information. (Okay, I may be exaggerating on that last one just a bit.)

3rd Party Access

Even more difficult than accessing patient data as the patient or the patient’s doctor or caregiver is accessing the data as a service provider:

  • Consultants who help agencies with operational efficiency, documentation, software implementation, etc.
  • QAPI advisors who help with reporting and training
  • Data analytics companies who interpret information and provide meaning behind numbers.

Who Owns the Data?

One of the big questions in these cases is who owns the data. Each party seems to claim some ownership. Medical agencies believe they own the data because the information doesn’t exist without inputing it during a patient visit. Electronic medical records claim ownership based on housing the information in the system they created, designed, and built. I, along with many others I assume, believe the data belongs to the patient. It is being used by the medical agency to perform services and housed by the software company much like a storage facility. But, the information should travel with the patient. 

It's a Bot!

Skilled nursing facilities and other providers often hire data analytics companies to help assess their business. One such company, Real Time, provides data analytics services using facility and patient data. Real Time accesses this data using log-in credentials provided by the facilities. Due to the volume of data and the time it takes to sift through a robust EHR system, Real Time uses bots to comb through the system and download the necessary information. 

Roadblock

This system works well for analytics companies and consultants to access more data quickly and provide faster, more thorough answers to their clients. The system doesn’t work well when the software housing the data enables CAPTCHA on its log-in page. CAPTCHA is specifically designed to keep bots out. In 2022, PointClickCare started using CAPTCHA on users they thought were bots. In 2023, PointClickCare used images so indecipherable that even humans couldn’t solve.

Request Denied

Real Time was losing access to its accounts. Agencies were losing the data analytics they contracted to receive. Real Time and PointClickCare entered discussion to provide access to the data. Real Time alleges that the solutions PointClickCare agreed to would only allow access to 30% of the data needed. Additional negotiations ended without an agreement. It seems PointClickCare ended the negotiations.

Fight for Your Right to...Data

In January of 2024, Real Time sued PointClickCare claiming unfair competition and tortious interference, among others. A district court issued an injunction to stop PointClickCare from using indecipherable CAPTCHA images and from deactivating Real Time’s accounts. PointClickCare appealed the decision to the Fourth Circuit.

Interpreting the Law

The Fourth Circuit upheld the district court ruling. The significance in the ruling is that the court interpreted some previously ambiguous language in the Cures Act exceptions to the information blocking rules. Specifically, the court interpreted the phrase “cannot reach agreeable terms” to mean that both parties attempt to reach an agreement in “good faith” using “reasonable” and “genuine” effort. The court also stated that the parties must have “articulable reasons why the parties cannot come to an agreement.” While this may seem like a minor ruling, the impact of the interpretation of the exceptions could reach much farther than this law suit.

I Object!

PointClickCare requested a rehearing after the Fourth Circuit decision. The American Hospital Assocition and Electronic Health Record Association filed briefs supporting PointClickCare in the lawsuit and in the petition for a rehearing. On April 23, 2025, The US Court of Appeals for the Fourth Circuit denied the petition for review. 

Paving the Way for Interoperability

The Fourth Circuit decision upholds the final rule from HHS implementing the Cures Act disincentives for information blocking. This decision and the denial of the petition for en banc review could have widespread implications. EHR companies must use the same access rules for every user. No more tricky images to stump consultants. No limiting access to 30% of the data.

The use of artificial intelligence-based software that can access EHR data without standard API connectivity could be the next step. Without needing permission to access and download data, switching software companies becomes easier. Sharing patient data with other medical providers is now a simple task. A patient could access their medical records with a single log-in.

Final Thoughts

I anticipate this will not be a decision that is accepted easily. I see more objections, lawsuits, and arguments from the AHA, the EHRA, and individual software providers and consultants. The decision has the potential to reach into other industries. AI will continue to evolve in ways we haven’t even anticipated. This certainly will not solve the issues of access to data or interoperability, but it’s a good first step.

Read the related articles on interoperability from Netsmart. Part 1 | Part 2

# # #

Kristin Rowan, Editor
Kristin Rowan, Editor

Kristin Rowan has been working at The Rowan Report since 2008. She is the owner and Editor-in-chief of The Rowan Report, the industry’s most trusted source for care at home news, and speaker on Artificial Intelligence and Lone Worker Safety and state and national conferences.

She also runs Girard Marketing Group, a multi-faceted boutique marketing firm specializing in content creation, social media management, and event marketing.  Connect with Kristin directly kristin@girardmarketinggroup.com or www.girardmarketinggroup.com

©2025 by The Rowan Report, Peoria, AZ. All rights reserved. This article originally appeared in The Rowan Report. One copy may be printed for personal use: further reproduction by permission only. editor@therowanreport.com

 

TEFCA and QHINs: Interoperability 2

Admin

by Ben Rosen, Sr. Client Success Manager, Netsmart

Interoperability

What you need to know and how it affects you Part 2

For over two decades, tech companies and government agencies have been moving toward the goal of interoperability in healthcare technology. At long last, standards and protocols are in place — and continually being improved — to support open data exchange networks. As a result, healthcare providers, including human services, post-acute providers, and specialty practices, have more opportunities to participate in alternative payment models and adapt more readily to the evolving payment landscape.

This is part two of a four-part series covering the forces that are driving interoperability, as well as the future vision of open networks, and what it all could mean to your organization. Read Part One Here.

Interoperability in Healthcare

The creation of TEFCA and QHINs

TEFCA (Trusted Exchange Framework and Common Agreement) is a national framework designed to enable seamless, secure sharing of health information across organizations. With respect to EHRs, this framework simplifies data exchange with other providers, payers and public health entities while enhancing compliance with interoperability requirements. TEFCA is touted as a nationwide federal and private data exchange network.

End goal

One of TEFCA’s main goals is to standardize data sharing, therefore reducing the complexity of managing multiple connections and enhancing the interoperability of your EHR with other systems nationwide.

TEFCA was created by the U.S. Department of Health and Human Services’ Assistant Secretary for Technology Policy (ASTP). The ASTP is contracting with the Recognized Coordinating Entity (RCE), The Sequoia Project. The RCE is tasked with governing and maintaining the operations of the entities who are electing to implement the TEFCA network, these entities are referred to as Qualified Health Information Networks (QHINs).

Interoperability
Interoperability TEFCA QHIN

QHINs

The certification process

QHINs are the entities that build the frameworks to allow data exchange as specified by TEFCA and facilitate the national exchange of health information. A single QHIN may represent dozens or even hundreds of healthcare providers, referred to as participants or sub-participants, across sectors (i.e., acute, human services, post-acute) public health agencies, health IT vendors and payers.

Applicants must build their TEFCA connection, which is then subjected to rigorous technology and security testing. QHIN applicants must also sign the Common Agreement that is countersigned by The Sequoia Project. These rigorous standards have a time limit: Each QHIN who applies must have their network built, tested and designated by the ASTP and RCE within 12 months of the application acceptance date. As of this writing there are eight designated QHINs and two candidate QHINs.

Benefits of participating in a QHIN

  • Streamlined Data Exchange
  • Compliance with Federal Interoperability Mandates
  • Access to Broader Patient Data
  • Improved Care Coordination

The market is already seeing regulatory rules and guidance tied directly to TEFCA. For instance, HTI 1 rule laid the groundwork for TEFCA and the HTI 2 rule is expanding on the process for designation, as well as codifying definitions and use cases to be exchanged via QHINs. Overwhelmingly, one of the biggest benefits to using a QHIN will be the increased types of data exchanged via the network.

The Same, but Different

Data exchange via TEFCA will look different than what we are used to with other nationwide networks today, such as Carequality, EHealthExchange or CommonWell. Via TEFCA, QHINs will exchange more robust types of data, referred to as Exchange Purposes, and will deal with higher volumes as a network. A few examples of these Exchange Purposes are clinical documentation (CCD-A), benefits determination data, public health research data, and even lab data, just to name a few.

Another benefit will be seamless connectivity. Other QHINs should integrate with EHRs to facilitate data exchange, acting as a hub that connects your system with other networks, providers and stakeholders.

Coming soon in Interoperability Part 3: Not all QHINs are created equal. How to choose the one that’s right for you.

# # #

Interoperability Ben Rosen Netsmart
Interoperability Ben Rosen Netsmart

Ben Rosen is a senior client success manager and business unit owner for the interoperability solution suite at Netsmart. With more than a decade of healthcare experience, Ben has led numerous initiatives to integrate healthcare systems and enhance data sharing across the care continuum. His dedication to advancing healthcare interoperability drives his active involvement in industry initiatives and standards organizations, where he provides insight for frameworks such as HL7 FHIR, USCDI and others. Ben holds a Bachelor of Science in kinesiology from Kansas State University and a Bachelor of Science in nursing degree from the University of Nebraska Medical Center.

©2025 by The Rowan Report, Peoria, AZ. All rights reserved. This article originally appeared in the Netsmart blog and is reprinted here with permission. For more information or to request permission to print, please contact Netsmart.

Interoperability

Clinical

by Ben Rosen, Sr. Client Success Manager, Netsmart

Interoperability

What you need to know and how it affects you

For over two decades, tech companies and government agencies have been moving toward the goal of interoperability in healthcare technology. At long last, standards and protocols are in place — and continually being improved — to support open data exchange networks. As a result, healthcare providers, including human services, post-acute providers, and specialty practices, have more opportunities to participate in alternative payment models and adapt more readily to the evolving payment landscape.

Interoperability in Healthcare

What's driving the need for change?

Government regulatory agencies, together with payers and healthcare organizations, have long recognized the need to improve care coordination among healthcare providers. Making it easier to share information via a nationwide data sharing network is a critical component of this effort.

End Game

The ultimate goal of providing access to complete, accurate patient information is to help drive down costs to providers and electronic health record (EHR) users. Through exhaustive work and years of innovation, we’re seeing the tangible outcome of this effort. Information now flows seamlessly across multiple healthcare networks. Using a concise view of the data, we can focus on broader population health initiatives that improve outcomes for chronic conditions, reduce emergency department (ED) visits, and prevent hospitalizations. The interoperability market is moving ahead at blazing speeds. Therefore, we must understand the players who are the driving forces behind the movement.

Interoperability

The Interoperability Highway

Who are the players and how do they work together?

Healthcare technology is complex. It’s not surprising, then, that getting the disparate systems to share information seamlessly and securely is a complicated process. In the last decade an increasing number of vendors, organizations, and healthcare players started working together to advance a useful interoperability market.

Some of the larger players in this space include government and regulatory agencies. To understand the role these entities play and how they coordinate with other organizations and efforts, let’s compare the process to building a national highway system.

Building an open data exchange network

  • Assistant Secretary for Technology Policy and Office of the National Coordinator for Health (ASTP/ONC): This federal agency sets the vision, rules and regulations for health information technology policy. Compare it to the Federal Highway Administration (FHWA), the federal agency that provides stewardship over the construction, maintenance, and preservation for all interstate highways.
  • Trusted Exchange Framework and Common Agreement (TEFCA): Established by the ASTP/ONC, TEFCA sets the rules for health data exchange over the network. This is similar to plans or blueprints for highway construction. This would also include engineering, construction and safety standards for the highway.
  • The Sequoia Project (RCE): The Sequoia Project is the Recognized Co-ordinating Entity (RCE) for TEFCA and is appointed by the ASTP/ONC. The Sequoia Project is a non-profit, public-private collaborative that leads the implementation project for nationwide data exchange. They approve and help regulate the TEFCA exchange, via QHINs. The Sequoia Project can be compared to a construction manager that approves contractors and oversees quality control measures to ensure standards are met.
  • Qualified Health Information Networks (QHIN)s: QHINs are data sharing networks built to operate the exchange network as outlined by TEFCA. In our analogy, QHINs are the highways, and the companies that build QHINs can be compared to the construction companies that physically build and maintain the roadways themselves.

Now that you’re familiar with the entities involved in developing the standards for interoperability and building the data exchange networks that make it a reality, we will next look at how these enhanced capabilities can impact your organization.

This is part one of a four-part series covering the forces that are driving interoperability, as well as the future vision of open networks, and what it all could mean to your organization. Check back for part 2, “How TEFCA affects your technology and what the heck is a QHIN?” coming soon.

# # #

Interoperability Ben Rosen Netsmart
Interoperability Ben Rosen Netsmart

Ben Rosen is a senior client success manager and business unit owner for the interoperability solution suite at Netsmart. With more than a decade of healthcare experience, Ben has led numerous initiatives to integrate healthcare systems and enhance data sharing across the care continuum. His dedication to advancing healthcare interoperability drives his active involvement in industry initiatives and standards organizations, where he provides insight for frameworks such as HL7 FHIR, USCDI and others. Ben holds a Bachelor of Science in kinesiology from Kansas State University and a Bachelor of Science in nursing degree from the University of Nebraska Medical Center.

©2025 by The Rowan Report, Peoria, AZ. All rights reserved. This article originally appeared in the Netsmart blog and is reprinted here with permission. For more information or to request permission to print, please contact Netsmart.