Getting Started
Summary: Understanding the history of interoperability can shed some light on why EHR integrations can be so complicated.
What is interoperability?
Interoperability refers to the ability of different systems, devices, applications, or products to connect and communicate in a coordinated way, without effort from the end user.
Interoperability in healthcare information technology (health IT) has a more nuanced connotation, and there are many uses for interoperability. Interoperability in health IT means two or more systems can exchange patient health information and use the information immediately once it is received. Interoperability’s objective is to optimize and standardize the quality of medical care. Although many government regulations have pushed the industry to become more interoperable, and since one size does not fit all, health IT interoperability is still far from where it needs to be to truly impact healthcare across the nation.
Why is interoperability important?
It is no surprise that the health IT industry continues to grow steadily. With the constant innovation of products, interoperability is essential. A tool can be useful to hospitals on its own but may become a burden to users when their suite of products cannot integrate or connect. If a company's goal is to improve healthcare, it must be prepared to understand interoperability standards.
Improved Patient Care
Interoperability can reduce the burden on healthcare workers and create better outcomes for the patient. A 2021 survey of physicians by Google Cloud found:
- 91% of physicians say the ability to efficiently incorporate patient data into care plans is critical to care coordination. Enabling healthcare providers to access and exchange relevant patient data quickly and easily improves quality and efficiency. This can help to reduce the risk of errors and improve the coordination of care between different providers and organizations.
- 92% say the use of inefficient electronic health records systems (which require excessive scrolling, pop-ups, manual data entry, etc.) has had a negative impact on their ability to deliver quality care.
- 86% say interoperability enables faster diagnoses.
Reduced Costs
Interoperability can reduce the costs of healthcare by eliminating the need for manual data entry and other inefficient processes. It can also help to reduce the risk of errors, which can have costly consequences in terms of additional treatment or legal costs. One study found that the lack of healthcare data interoperability costs the U.S. health system over $30 billion a year.
Improved Public Health
Interoperability can help improve public health by enabling the easy exchange of population health data between different organizations. This exchange of data would help to identify trends, patterns, and potential issues that may not be apparent at the individual patient level. In 2021, the CDC announced a new center that aims to accelerate public health data exchange interoperability to support public health forecasting.
Improved Patient Engagement
Interoperability can also help to improve patient engagement by enabling patients to access and manage their health information more easily through apps and patient portals. This can help to empower patients to take an active role in their care and make more informed decisions about their health.
History of Interoperability
Several key pieces of legislation led to the introduction of the term interoperability as we know it.
2004
President George W. Bush established the Office of the National Coordinator for Health Information Technology (ONC) by Executive Order. This introduced the idea that health information technology needed to be coordinated nationally. ONC’s objectives are “advancing the development and use of health IT capabilities; and establishing expectations for data sharing.”
2009
The Health Information Technology for Economic and Clinical Health Act (HITECH Act) set aside $27 billion in financial incentives for healthcare providers and facilities to implement electronic health record (EHR) systems.
The 2009 HITECH Act was the first step towards a more accessible healthcare system for patients and providers alike, but it would take seven more years until the next step was taken.
2016
The 21st Century Cures Act (Cures Act) was passed to accelerate medical product development and bring innovations to patients faster and more efficiently. It hoped to improve clinical trial processes, mental health services, EHI interoperability, and research initiatives.
Notably, the Cures Act first defined “interoperability” for health IT:
The term ‘interoperability’, concerning health information technology, means such health information technology 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 [and] allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable State or Federal law.
Interoperability was meant to represent the promise of better care, improved patient access, and more efficient practices. Unfortunately, the definition and scope of interoperability have failed to be consistent over time. This has left its meaning open to interpretation and its success open for debate, whether we achieved the outcomes attributed to interoperability or not.
2020 - Present
ONC released the Cures Act Final Rule, further specifying the patients’ rights to access their EHI without being hindered by information blocking practices. There will be more on information blocking and interoperability later in this piece.
Due to the COVID-19 pandemic, the Cures Act Final Rule compliance deadline for healthcare providers and health IT developers was moved to October 6, 2022.
How Interoperability Works
If interoperability was simple there would not be much to dissect, but achieving interoperability takes a coordinated effort to work. ONC creates and enforces standards for interoperability. Standards provide a common language and a common set of expectations that enable interoperability between systems and permit clinicians, labs, hospitals, pharmacies, and patients to share data regardless of application or market supplier. We will dive deeper into interoperability standards in a later section.
What systems are involved in interoperability?
There are multiple sources of information, such as laboratories, clinics, pharmacies, hospitals, and primary care providers, which use multiple systems to record this information. Essentially any point in the care continuum that records patient data is involved in interoperability. These are referred to as Health Information Systems (HIS).
Common Interoperability Use Cases
EHR - Lab Vendor
Laboratory interfaces must be interoperable between lab vendors and EHR vendors and back. Lab results are an essential part of diagnostic care and the ease of sharing data can, when applicable, increase the speed with which patients receive medication or therapies for their ailments.
EHR - MRI Machines
Similar to the above use case, interoperability between an EHR and MRI machines, and other imaging interfaces, is essential for quality care. MRI machines and other imaging modalities interface with a PACS system and the PACS system can interface with the EHR system to link the orders and results. This is especially important in more rural areas where patients may have to visit several places in their care journey as opposed to robust hospital campuses in more urban areas.
Practice Management Software - PM
The main function of a PM system is appointment scheduling, billing, and all other related parts of managing a medical practice. This use case focuses on interoperability within a singular medical practice. It ensures the Office Managers and Receptions are using products that can communicate with the products utilized by nurses, doctors, etc for daily operations.
Types of Health Information Systems
.webp)
A HIS is any system that manages healthcare data. HISs can take many forms. Some of the main types of HISs include:
- Electronic Health Record (EHR) or Electronic Medical Record (EMR): EHRs and EMRs collect, store, and share data related to a patient’s health history. Although these terms are often used interchangeably, an EMR is simply a patient’s digital health record (chart), while an EHR is a digital record of all patient health information.
- Practice Management Software: This type of HIS manages the daily operations of a practice, such as scheduling and billing. It can help automate many administrative tasks.
- Pharmacy Management System: This software includes all data related to a patient’s prescriptions and is found in pharmacy settings, including retail, hospital, and long-term care.
- Population Health Management Software: Population health management software aggregates data across healthcare systems and stores patient data for population health analysis.
- Clinical Decision Support (CDS): CDSs analyze data from clinical and administrative systems. The analysis enables clinicians to make the best clinical decisions.
- Patient Portals: Portals allow patients to access their health data like medications and lab results. Portals can also be used to communicate with physicians and track appointments.
Note that electronic health records on their own may not contain all of the necessary RWD, so researchers may be required to seek additional sources of data.
Types of Health Information Systems
Up until now, we’ve referred to interoperability as the ability for software to share data without needing to be formatted by the receiver. Is this act a data exchange or data integration? And what’s the difference?
Data exchange is the exchange of data related directly to patient care. It refers to the process of transferring data between two or more systems, technologies, or organizations. Data exchange may involve the transfer of entire databases or tables of data, or the exchange of specific data elements or messages.
Data integration, on the other hand, refers to the process of combining data from multiple sources into a single, cohesive whole. Data integration may involve the consolidation of data from different systems, the transformation of data to ensure compatibility, or the creation of new data by combining existing data in different ways.
In general, data exchange is a step in the process of data integration, but data integration involves additional steps beyond the exchange of data. Data integration requires a more comprehensive approach to integrating data from multiple sources and may involve the use of specialized tools, processes, or technologies to ensure that the data is consistent, accurate, and useful.
Information Blocking and Interoperability
Information blocking is the practice of restricting the access, exchange, or use of EHI from patients, on an unfair basis. Unfair restrictions include fees exceeding costs, inability to share data, and slow turnaround times.
Information blocking can occur between numerous actors. It can occur between a patient and a healthcare provider or between a healthcare provider and a health IT developer. If information is blocked between a physician and a vendor, essential medical treatments for patients could be delayed.
The Cures Act definition of interoperability implies that the practice of information blocking is incongruent with interoperability, and in 2020 ONC released the Cures Act Final Rule, further specifying the patients’ rights to access their EHI without being hindered by information blocking practices.
For everything you need to know about information blocking, whom it impacts, penalties, and compliance you can read “Information Blocking: What No One Is Talking About.”
Interoperability Standards
Standards refer to common practices for people to abide by. Interoperability standards exist in several categories:
- Terminology Standards - or the way we name things
- Content Standards - or what we send
- Transport Standards - or how we send it
- Privacy Standards - or how we protect the data
Unfortunately, since healthcare IT as an industry is large and complex, there are MANY standards that have been implemented and are competing for dominance.
Terminology Standards
Terminology standards set the foundation for effective communication. In healthcare IT, many terms refer to a concept, and having a standard vocabulary for these concepts removes some of the ubiquity in interoperability. Most communication between HISs relies on structured vocabularies, terminologies, code sets, and classification systems to represent medical concepts.
Having standard terminology sounds simple enough, but the complexity of diagnoses and medical coding and billing systems are only the tip of the iceberg in what complicates and slows down effective terminology standards.
Examples of Terminology Standards
- LOINC - Universal code system for identifying health measurements, observations, and documents.
- CPT - A code set, maintained by the American Medical Association (AMA) used to bill outpatient and office procedures
- ICD-10 - Medical classification code used by the World Health Organization (WHO)
- RxNORM - Normalized names for clinical drugs based on many of the drug vocabularies commonly used in pharmacy management and drug interaction software.
Content Standards
Content standards relate to the data (content) that is exchanged between HIS platforms. These standards define the structure and organization of the electronic message or document’s content. This standard category also includes the definition of common sets of data for specific message types.
Types of Content Standards
HL7
Health Level Seven (HL7) is a set of international standards used to provide guidance with transferring and sharing data between various healthcare providers. Created by Health Level Seven International, the adoption of these standards supports clinical practice and the management, delivery, and evaluation of health services. HL7 does not provide standards for system architecture or how data is stored in an application.
Two common content standards put forth by HL7 include:
- HL7 V2: Created in 1989, HL7 V2 was designed to support hospital workflows. It is a messaging standard that allows the exchange of clinical data between systems. Its design supports both a central patient system and a decentralized system where data is housed in a different system for each department.
- HL7 V3 (CDA): Created in 1995, HL7 V3 was designed to support all healthcare workflows, not just those in a hospital. It is an XML-based document markup that standardizes clinical documents for data exchange. It defines a clinical document as having the following six characteristics: persistence, stewardship, potential for authentication, context, wholeness, and human readability. Although HL7 V3 was an update on V2, it was widely considered complex.
C-CDA
Consolidated Clinical Document Architecture (C-CDA) is a library of templates that incorporate and synthesize previous content standard efforts a complete architecture used to create documents and template methodologies for medical documents. The C-CDA library is created and maintained by HL7 International. The primary function is to standardize the content and structure of clinical care summaries. With C-CDA, products can do a point-to-point import of patient data, sending critical and real-time patient data. This exchange model is based on HL7 V3 standards.
FHIR
Fast Healthcare Interoperability Resources (FHIR) is the latest generation of standards framework created by HL7. FHIR combines the best features of HL7 v2, HL7 v3, and C-CDA while leveraging the latest web standards and focusing greatly on implementability. FHIR quickly grew in popularity as it brings together disparate systems and holds promise for interoperability. FHIR refers to both the technology and the agreement on the meaning of the data in healthcare.
FHIR is distinct from, but related to, previous HL7 standards (HL7 CDA, V2, and V3) but FHIR uses a broader range of technologies. FHIR leverages RESTful web services and open web technologies such as XML, JSON, and RDF, while HL7 only supports XML.
SMART on FHIR
Substitutable Medical Applications and Reusable Technologies (SMART) was created in 2010 and funded with the purpose of developing standards that would allow any API to run anywhere in a healthcare system, solving the data fragmentation problem. SMART builds on FHIR, and has been snappily named “SMART on FHIR.” Any technology built with SMART will work with any SMART-compatible EHR database. The result is more interchangeable healthcare IT and empowers health systems to choose an API that best suits their needs instead of being limited to the applications that only work with their EHR database.
What EHRs are currently built with SMART?
- Allscripts
- athenahealth - athenaOne
- Cerner - Provider and Patient Facing Apps
- Epic Provider Facing Apps
- Epic Patient Facing Apps
- Intersystems
- Meditech
Transport Standards
Transport standards address the format that data gets exchanged in. The format must be compatible between computer systems, document architecture, clinical templates, user interface, and patient data linkage. Transport standards aim to ensure that data is transported securely, in acceptable formats, and with integrity.
Types of Content Standards
DICOM
Digital Imaging and Communications in Medicine (DICOM) standardizes the communication and management of medical imaging information and data. DICOM is used in almost every imaging device and is updated and republished throughout the year. Transferring medical images present its own challenges for how these large files can be transferred, stored, and archived. It is a great example of the necessity of Transport Standards.
Direct Standard
Direct standards, created and maintained by DirectTrust, standardize protocols to allow participants to send authenticated, encrypted health information directly to known, trusted recipients over the internet. Two primary specifications are the Applicability Statement for Secure Health Transport v1.2 and the XDR and XDM for Direct Messaging. DirectTrust Standards seeks to foster standards that enhance healthcare interoperability and identity or that have applicability to a Trust Framework.
Security Standards
Given that healthcare IT deals with the sensitive health data of millions of people, privacy and security standards are required of all actors. In the U.S., the Health Insurance Portability and Accountability Act (HIPAA) outlines standards that protect the privacy and security of an individual's protected health information (PHI). HIPAA gives patients the right to determine if, when, and how their PHI is collected, accessed, used, or disclosed.
Security standards define a set of administrative, physical, and technical actions to protect the confidentiality, availability, and integrity of health information.
Types of Content Standards
HIPAA
The Department of Health and Human Services’ 1996 HIPAA legislation has evolved to establish four security rules: Privacy, Security, Enforcement, and Breach Notification Rules. There is no single path, certification, or technology to being “HIPAA compliant,” actors must actively remain in compliance with its rules.
HIPAA’s Privacy and Security Rules deal directly with interoperability, as these rules were created in response to the digitization and exchange of EHI. The Privacy Rule was published in 2000 and set national standards for individually identifiable health information by health plans, healthcare clearinghouses, and healthcare providers who conduct standard healthcare transactions electronically. The Security Rule was published in 2003 and set national standards for protecting the confidentiality, integrity, and availability of electronic protected health information.
HITRUST
As previously stated, one cannot become certified for “HIPAA Compliance.” That’s where the Health Information Trust Alliance (HITRUST) comes in. HITRUST is a certifiable framework that provides health IT organizations globally with a comprehensive, flexible, and efficient approach to regulatory/standards compliance and risk management. The HITRUST r2 Certification proves organizations comply with HITRUST security standards, which include HIPAA’s Privacy and Security Rules. HITRUST certifications bring a promise of security to the interoperability ecosystem.
ISO 27001 / ISO 27799
ISO is an independent, international, non-governmental organization that creates international security standards to protect PHI. ISO has almost 25,000 sets of standards covering almost all aspects of technology, management, and manufacturing. ISO 27001 and 27799 are the two primary ISO standards influencing health IT. ISO 27001 establishes information security management system requirements, and ISO 27799 establishes a set of best practices specifically created for health data. It applies to health information in all its aspects, including the form the information takes, how it is stored, and how it is transmitted, ensuring the information is always appropriately protected.
SOC 2
Vendors can also demonstrate that they practice privacy and security by seeking SOC 2 Compliance. Health tech vendors should be focused on SOC 2 Type II rather than SOC 2 Type I, as that is what potential healthcare buyers are looking for. SOC 2 defines criteria for managing customer data based on five Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy. SOC 2 was developed by the American Institute of Certified Public Accountants to help protect data that was beginning to be stored in the cloud.
Challenges of Interoperability and Standards
The benefits of interoperability are clear; however, if achieving interoperability were easy it would have been achieved by now. Reaching interoperability presents five key challenges:
Inconsistent Information
Inconsistent information across the network is a huge problem, particularly for healthcare IT vendors who service large health networks. Care providers record different pieces of data in multiple - often disparate - places and health IT departments waste countless hours searching for all the necessary pieces.
Privacy and Security
As previously stated, maintaining the privacy and security of patient health records is critically important and led the US government to create HIPAA rules for privacy and security. These rules are essential but do pose a barrier to interoperability as HIPAA provides the rules but other standards organizations are filling in the gap to prove the technology is meeting privacy and security standards. For example, how do care providers know when it is okay to process electronic requests for patient information? You need more than a simple nod of approval from your EHR vendor and, unfortunately, most providers are left to rely on the approval of their EHRs when sharing patient data.
Organizational Resistance
Certain actors in the healthcare industry have a vested interest in not sharing data with other providers. For example, hospital systems compete for patients with urgent care clinics. When a request for patient data comes from an urgent care clinic to a hospital’s EHR system, the motivation to share the data is slim at best because they don’t want to lose the patient (and therefore money) to the urgent care. Thankfully the law calls for health data to be available and accessible across organizational boundaries and to patients themselves thanks to the information blocking restrictions in the Cures Act; however, that doesn’t eliminate actors and their selfish interests from hindering full interoperability.
High Costs
Achieving interoperable EHRs is a lot of work. In most healthcare settings, no single person has the time — much less the qualifications — to keep up with this daily task. Hiring someone, or a team of people, who are qualified to maintain EHR interoperability is expensive, especially for smaller organizations. This leads to health IT vendors either failing, or falling extremely short of, interoperability.
Maintaining Data Availability
If your data is not as readily available as is called for in the Cures Act, you could be reported and fined for information blocking. An outdated EHR certification is not enough to give peace of mind that you are keeping up with the new requirements of the Cures Act Final Rule on data availability for patients and other care providers.
Looking for solutions to these challenges? Check out our Top 5 Challenges with Healthcare Interoperability (& How to Solve Them) blog.
Ways To Ensure Interoperability of Data
ONC Health IT Certification Program
The Office of the National Coordinator for Health Information Technology (ONC) Health IT Certification Program is a certification program established by the ONC to provide for the certification of health IT. It is a voluntary certification that assesses health IT on ISO and IEC standard frameworks. The Certification Program was launched in 2010 with the aim of encouraging other federal, state, and private programs, like the Center for Medicare and Medicaid Services (CMS), to require health providers to use an ONC-certified piece of technology.
ONC sets the Certification Program’s requirements, capabilities, standards, and interoperability requirements for health IT that pursues this certification. The Cures Act Final Rule made several updates to the Certification Program on the lines of interoperability and information blocking for health IT vendors.
Certified Health IT Developers must successfully test the real-world use of their technology for interoperability in the setting(s) in which such technology would be marketed. To meet the requirements, developers must submit publicly available annual Real World Testing plans, as well as annual Real World Testing results to maintain certification. Thus, ONC’s Certification Program ensures interoperability among health IT that is used to follow most government programs.
Healthcare Effectiveness Data and Information Set (HEDIS)
The Office of the National Coordinator for Health Information Technology (ONC) Health IT Certification Program is a certifiIn 2001, NCQA released the Healthcare Effectiveness Data and Information Set (HEDIS®). HEDIS is a set of measures designed to gauge the quality of healthcare services and is used by more than 90% of U.S. health plans to measure care and service performance. HEDIS is arguably one of the more important activities health plans engage in because measure rates dictate financial rates.
NCQA added a new reporting method to HEDIS: Electronic Clinical Data Systems (ECDS) in 2015. ECDS is a reporting standard that encourages the use and sharing of electronic clinical data across healthcare systems. ECDS reporting builds on the successful HEDIS quality reporting framework to encourage interoperability of health data systems and collection and use of clinical and patient-reported outcomes data.
NCQA’s Data Aggregator Validation Program
Launched in 2021, NCQA’s Data Aggregator Validation Program evaluates clinical data streams to help ensure that health plans, providers, government organizations, and others can trust the accuracy of aggregated clinical data for reporting and other initiatives.
The NCQA DAV also saves time and money during the HEDIS reporting process. Data streams validated by NCQA through the NCQA Data Aggregator Validation program can be used as standard supplemental data in HEDIS reporting, eliminating the need for primary source verification during the HEDIS audit process and saving time and money for provider organizations and health plans.
The directory lists entities that have validated clinical data streams or are in the process of validating data streams with NCQA. NCQA DAV adds a layer of quality assurance to healthcare data platforms as they continue to make strides toward interoperability and data liquidity.
Current State of Interoperability
Interoperability as we know it today has been evolving towards its current state for most of the 21st century and will continue to evolve and adapt to the changing digital technology landscape.
What is eHealth Exchange?
In 2004, ONC created the Nationwide Health Information Network (NHIN) to establish standards, services, and policies for a health information exchange (HIE). Federal agencies, HIEs, and healthcare providers agreed to adopt NHIN standards for secure HIE at a local and national level. In 2012, NHIN became known as the eHealth Exchange.
Today, eHealth Exchange is a group of federal and non-federal organizations that came together under a common mission and purpose to improve patient care, streamline disability benefit claims, and improve public health reporting through secure, trusted, and interoperable health information exchange. It is an independent, non-profit health information network and has blossomed into a rapidly growing community of exchange partners.
The primary objective of eHealth Exchange is to de-centralize data exchanges, including the ability of Federal agencies with the private sector. eHealth Exchange promotes interoperability by enabling participants to securely and seamlessly share data over the internet.
What are CommonWell and Carequality?
Two main interoperability actors, also known as plug-and-play networks, on the national level are CommonWell Health Alliance and Carequality. CommonWell is a trade association founded to create a “vendor-neutral” platform that eliminates the barriers - both technological and bureaucratic - that hinder interoperability. It was founded in 2013 and today is one of the largest health data networks in the US.
Founded in 2014, Carequality is a non-profit that promotes a contractual and operational framework for interoperability. They bring together EHR vendors, record locator service providers, and other private and government actors together to create a consensus-based interoperability framework. It is worth noting that eHealth Exchange has also adopted the Carequality Interoperability Framework.
In 2016, CommonWell and Carequality announced a formal collaborative partnership to advance interoperability. The partnership, which began to be actualized in 2018, includes:
- CommonWell becoming a Carequality implementer on behalf of its members and their clients, enabling CommonWell subscribers to engage in health information exchange through directed queries with any Carequality participant.
- Carequality working with CommonWell to make a Carequality-compliant version of the CommonWell record locator service available to any provider organization participating in Carequality.
- CommonWell and The Sequoia Project, the non-profit parent under which Carequality operates, agree to these initial connectivity efforts and will explore additional collaboration opportunities in the future.
Despite their efforts towards interoperability, a 2019 KLAS Report found that their partnership is not automatically generating value because the incoming data is not easy to consume, as they create unnecessary steps in the workflow. Organizations are making connections to CommonWell and Carequality, but they are not consuming the data from them.
What is TEFCA?
On January 19, 2022, ONC published the Trusted Exchange Framework Common Agreement (TEFCA). The goal of TEFCA is to establish a “universal floor” for interoperability in the United States. TEFCA is (quite literally) comprised of two parts: the Trusted Exchange Framework, and the Common Agreement. The former describes a common set of non-binding, foundational principles for trust policies and practices that help facilitate exchange among health information networks (HINs). The latter establishes the infrastructure model and governing approach for users to securely share basic clinical information regardless of what network they are in.
Qualified Health Information Networks
TEFCA only works when provider organizations become a part of a Qualified Health Information Network (QHIN), which facilitates data sharing between participants and end users. Participants are a person or entity that participates in the QHIN. Participants can be HINs, EHR vendors, and other types of organizations. An end user is an individual or organization using the services of a participant to send and/or receive EHI.
The QHIN will ensure interoperability between participants in the network, but not necessarily an end user. QHINs connect via connectivity brokers. A Connectivity Broker is a service provided by a QHIN that provides all of the following functions with respect to all Permitted Purposes: master patient index (federated or centralized); Record Locator Service; Broadcast and Directed Queries, and EHI return to an authorized requesting QHIN.
Recognized Coordinating Entity
The Recognized Coordinating Entity (RCE) is the entity responsible for developing, implementing, and maintaining the Common Agreement component of TEFCA. The Common Agreement creates the baseline technical and legal requirements for health information networks to share EHI.
In addition to upholding the Common Agreement, the RCE collaborates with ONC to designate and monitor QHINs, modify and update an accompanying QHIN Technical Framework, engage with stakeholders through virtual public listening sessions, adjudicate noncompliance with the Common Agreement, and propose sustainability strategies to support TEFCA beyond the cooperative agreement’s period of performance.
The Sequoia Project was awarded the cooperative agreement to serve as the RCE for TEFCA. Recognized as a trusted advocate for a nationwide health information exchange, The Sequoia Project works with industry and government experts to identify and eliminate barriers to interoperability and create solutions to data exchange problems.
How will TEFCA exchange data?
The current exchange of data in health IT is still primarily performed using HL7 C-CDA standards; however, The Sequoia Project has acknowledged that the landscape is evolving and has released a three-year roadmap to accelerate the adoption of FHIR APIs so as not to hold back industry progress. The initial versions of the Common Agreement do not explicitly incorporate FHIR-based exchange as FHIR enablement is still maturing.
As of January 2023, TEFCA is still on its published timeline to be operationalized and RCA intends to release multiple sets of Standard Operating Procedures in CY23.
Can TEFCA solve interoperability?
It is expected that TEFCA will help to facilitate interoperability by establishing a common set of standards and protocols that can be used by a wide range of healthcare organizations and systems. However, it is important to note that interoperability is a complex issue, and many factors can impact the ability of healthcare systems to exchange and use EHI effectively. As such, TEFCA will be just one piece of the puzzle in terms of solving interoperability challenges in the healthcare industry and the benefits of TEFCA are several years from being seen.
What is IHE?
The last contemporary effort to expand to interoperability worth noting is IHE (Integrating the Healthcare Enterprise) International. IHE is an initiative by the healthcare industry to improve the way computer systems share information. IHE promotes the use of existing standards like DICOM and HL7 for optimal care. IHE recognizes that optimal care happens when care providers have access to all relevant patient information.
IHE is a process-oriented approach to interoperability and occurs in four phases:
Problem Identification - Identification of integration problems that hinder access to data by care providers and IT experts
Integration Profile Specification - Relevant actors choose standards that would aid in solving the integration problem
Implementation and Testing - Vendors implement the standards from phase 2 and test their interoperability with other systems at an in-person Connectathon
Integration Statements and RFPs - Vendors publish Integration Statements with IHE to document the integration profiles that are supported by their product(s).
IHE eases this burden by offering a clear path toward acquiring integrated systems. Referring to IHE Integration Profiles in RFPs and purchasing agreements allows purchasers and vendors to agree on the interoperability of systems being acquired or upgraded, making multi-vendor, best-of-breed solutions more feasible. It enables information technology specialists to concentrate on improving the core functionality of systems, rather than developing and maintaining redundant, point-to-point interfaces. Finally, it makes it possible to implement a streamlined workflow so that care providers can make more efficient use of their time.
Conclusion
Some see the logical conclusion of interoperability as data liquidity. Interoperability focuses on the ability of systems to connect and exchange data without extra steps, while data liquidity is the ability of data to flow throughout the healthcare system easily and securely.
By bringing health data out of the application and into a data layer, our entire industry can bring new solutions into the market faster and with fewer resources and overhead. It doesn’t require the same level of network access that we’ve needed to put in place in the past, and more importantly, we can stop saying that lack of interoperability is the excuse for not being able to move forward.
Until then, developers can focus on intra-operability or the exchange of data between systems used in the same organization or by the same vendor. Intra-operability is an important consideration for healthcare organizations, as it can help to improve the efficiency and effectiveness of patient care and administrative processes. For example, an organization with good intra-operability may be able to exchange patient data between different EHR systems or clinical departments more easily, reducing the risk of errors and improving the quality of care for the patient. At the end of the day, improving the patient experience and patient care should be the motivating factor for all health IT.
EHR Data Management
Managing EHR data often requires a completely separate technological entity. Collect, standardize, and deliver health data through Datavant. Datavant's software connects directly to your customer's EHR or PM system database.
We are a company on a mission to improve healthcare by delivering data that matters.
Here are some of the capabilities of Datavant:
- Quick and easy integrations with tons of EHRs with only a few clicks.
- Data translation to a standard data model.
- Easily accessible application for managing connections and quality control
- API-enabled data accessibility
- Compliance to regulations
.svg)
