Improved interoperability enables better transparency and innovation while improving outcomes for healthcare patients. It's often easier in theory than in practice, however, to reach the goal of full interoperability. Healthcare payers and their technology teams have a tall order to navigate healthcare data interoperability mandates, system regulations, and data integration challenges. Is your organization ready to comply? In this article, we look at the history of government mandates, the layers of interoperability, and the best way to implement necessary systems and programs for payers.
Healthcare interoperability is when two or more computer systems or softwares can access, exchange, integrate and use data for the benefit of healthcare.
Government mandates surrounding interoperability have also started playing a larger role in the designation of industry standards for data integrity. These government mandates are constantly evolving and updating to stay up-to-date with the ever-evolving technological advancements in healthcare.
There are a lot of government agencies and non-profit organizations that have added to the finalization and regulation of healthcare data interoperability mandates. While these will continue to evolve, this evaluates the biggest policies that have influenced and will continue to influence other mandates on interoperability.
The Department of Health and Human Services (HHS) created data standardization facts and policies regarding healthcare data interoperability that reside in two of their twelve distinct operating divisions: The Office of the National Coordinator for Health Information Technology (ONC) and The Centers for Medicare & Medicaid Services (CMS). These HHS divisions have created numerous regulations and divisions within themselves to propose and evolve regulations and mandates.
Many of the data standardization regulations reside within the ONC 21st Century Cures Act, specifically the Final Rule. The Cures Act, along with the Health Level Seven International’s (HL7) Fast Healthcare Interoperability Resources (FHIR) standard, was adopted by CMS to support its own API policies. Each of these proposals places requirements and regulations on all aspects of healthcare.
The ONC Cures Act was implemented to allow healthcare members to receive their own healthcare information quickly and without charge.
The ONC Cures Act Final Rule specifically encourages healthcare data interoperability by giving members more authority and transparency over their medical expenditures, including cost and outcomes, by requiring standardized application programming interfaces (APIs). These APIs must be secure and easy to access for users to find their electronic health information (EHI). This Final Rule also touches on the exceptions of information blocking.
As a result of The Cures Act, The United States Core Data for Interoperability (USCDI) and The Interoperability Standards Advisory (ISA) were developed.
The USCDI is a set of standardized data classes and elements that can be used for interoperable health information exchange.
The ISA process is a model which ONC uses to coordinate the identification, assessment, and determination of "recognized" interoperability standards and implementation specifications.
One of the largest government mandates and standards surrounding interoperability for data exchange that impacts payer-to-payer information is The Fast Healthcare Interoperability Resource (FHIR) finalized by HS7. As the name implies, FHIR was designed to enable health data to be quickly and efficiently exchanged. This is done with resources and APIs.
Within FHIR, each part of healthcare is broken up into categories. The categories create an exchangeable patient record. Some categories for payers include insurance claims, insurance applications, and more. Each category has been given different FHIR resource representatives. These resource representatives contain data elements of the most common use cases that lead users to relevant information within other resources. Example being going from specific patient data to a recommendation of a relevant clinician.
These resources are stored within an API. These APIs are meant to be an ‘entry point’ for members to view specific information. FHIR references the Representational State Transfer (REST) approach as their basis for APIs.
The Interoperability and Patient Access Policy gives members more accessible access to their health information by breaking down barriers in the nation’s health system.
The final rule focuses directly on the impact of interoperability and liberating patient/member data for the benefit of accessibility. CMS requires that “at a patient’s request, certain impacted payers must exchange certain patient health information, and maintain that information, creating a longitudinal health record for the patient that is maintained with their current payer.”
There are four main layers of interoperability that each benefit different aspects of healthcare data exchange. For a payers tech team to implement new systems and programs supporting interoperability, it’s necessary to understand these various layers: foundational, structural, semantic, and organizational.
The foundational level of interoperability, also known as simple transport, is the layer of interoperability where interconnectivity requirements are defined for which data can securely be sent from one computer system to another. This is the lowest level of interoperability, where the receiving system does not understand how to interpret the information by itself but can receive the data securely. At this layer, a human or another system can be used to interpret data.
A real-world example of foundational interoperability would be when a member submits a claim to the payer. The information would be delivered securely and would have been filled out properly, but the data would require to be input and interpreted by the insurance agent manually.
The structural level of interoperability, also known as structural transport, is one of the mid-layers of interoperability that defines the syntax/format of data exchange for document management systems to be able to interpret the data at the data field level.
A real-world example of structural interoperability occurs when a member submits their signed policy, and the database is able to securely receive it and then place each of the data values into the proper fields of the database without interpreting what it actually means.
The semantic level of interoperability, also known as semantic transport, is the layer of interoperability where common underlying models and codification can create a shared understanding of the data. Semantic interoperability helps a lot of healthcare elements, including quality improvement, data warehousing, and health management.
A real-world example of semantic interoperability occurs when two claims were accidentally submitted for the same operation although the ‘service’ name is different. One claim references the service as being “hand surgery,” while the other claim references the service as “arthroplasty”. The system can recognize that these two claims were for the same service due to the other information provided. The system now can identify that these two service names mean the same thing.
The organizational level of interoperability is the layer where businesses and organizations define internal and external procedures based on the interpretation of data. This level of interoperability provides a universal standardization of assessing various integral parts of the healthcare system.
An organization interoperability real-world example is when healthcare payers unify the standards of claims for improved outcomes and customer satisfaction.
Each layer of interoperability plays its part in fulfilling data integrity needs. The end goal in implementing systems and programs in healthcare is to achieve all the layers of interoperability for the benefit of payers and their members.
In order to encourage interoperability, a payers tech team will need to update and implement their systems, programs, and IT infrastructure continuously. We review some of the most popular platforms to consider when building your healthcare data interoperability program.
This system is a multi-cluster of shared data architecture that powers the data cloud, also known as a cloud-based data warehouse. Snowflake is built for any cloud infrastructure (IaaS, PaaS, or SaaS) and can help payers create stronger relationships with their members through data integrity.
Snowflake also encourages interoperability with its real-time data ingestion to ensure all users can access the correct data at the time of acquisition. Since Snowflake does not place a hard limit on the number of databases, schemas, or objects you can create, payers can collect, store, analyze, manage, and share a large amount of important information such as data on claims, applications, and member data. This helps payers optimize risk management decisions through big data analytics and insights.
Snowflake also provides an API integration service that helps payers encourage interoperability by feeding information from applications into the data warehouse. Snowflake is FedRAMP Authorized (Moderate) on AWS commercial and Azure Government regions. Snowflake provides a REST API powered by SQL to provide payers with a high level of custom control by allowing them to create and power their own custom applications and integrations to perform queries.
MuleSoft is another necessary integration for payers to encourage healthcare data interoperability. MuleSoft provides toolsets for managing APIs and users, analyzing traffic, monitoring SLAs, fixing underlying integration flows, automating tasks, and more using a single web interface.
MuleSoft's AnyPoint Platform is an integration and API platform that helps payers connect applications, data, and devices. This integration service helps payers increase data transparency and organization by promoting the collection, storage, and handling of data between databases, ERP systems, and SaaS applications. The AnyPoint Platform is the only solution on the market that provides a full API lifecycle management and integration within one product. Payers can also utilize the RPA manager in MuleSoft to intelligently process data in claims and applications, creating a faster information exchange between the members' submittals and the payers' databases.
In our latest eBook, Keep Calm & Data On, we share how to empower data-driven decisions that will turn your data into valuable, usable business currency.
It’s important to identify the challenges prior to implementing a new system or program. This can help with risk management and ensure a more seamless transition.
When implementing systems and programs such as Snowflake and MuleSoft, the entire IT infrastructure can change. This takes a lot of time and resources to implement. While there are easier components that can be implemented internally, it may take hiring an external team or consulting services to seamlessly integrate the more complex aspects of the system. The systems and programs impacting healthcare data interoperability will have some overlap. These intersection points can have potential risks ranging from not urgent to severely urgent that impact the scope of the project.
Data migration is another task that tech teams may need to focus on when encouraging healthcare data interoperability. This also requires specialized research since it opens a lot of avenues for potential vulnerabilities to appear if not done properly. These risks and vulnerabilities include:
Data is the biggest asset that healthcare payers have. In order to protect this data, prevent risks and mitigate vulnerabilities during a data migration project, payers need to delegate resources to properly trained technicians that can cover all aspects of risk management while also communicating at an extremely efficient rate.
Questions to consider when looking for a system to improve healthcare data interoperability include:
Despite the challenges and potential risks of improving payer healthcare data interoperability, it shouldn’t be a deterrent from committing to these changes. Change is vital for the improvement and success of IT infrastructure.
After systems and programs are implemented for the benefit of interoperability, a payers tech team should shift focus onto workflow organization. To preserve the sound structure of their IT architecture and receive the results they are looking for, they need to consider new workflow opportunities that impact performance, communication, and member experience. These opportunities include:
While systems and programs can help guide workflow processes, just implementing them won’t provide all the solutions many payers are looking for. Training is also vital for payers to optimize the potential of their newfound systems. Consider reaching out to consultants to learn more about the specifics of each system and how you can optimize each tool available to your advantage.
Concord USA is a consultancy that combines technology and industry depth with a get-it-done culture to enable resiliency, efficiency, and innovation. Whether you are trying to improve customer satisfaction, data strategies, security, or other technological issues, Concord can help.
Contact us today to learn more about the importance of healthcare data interoperability, our Technology Integration Services, and how we can help your business thrive.
Not sure on your next step? We'd love to hear about your business challenges. No pitch. No strings attached.
