Global Interoperability Challenges
The lack of interoperability in healthcare ecosystems is a critical issue for US and global healthcare systems. At present, patients cannot easily access their healthcare information in an interoperable manner. Moreover, healthcare providers and patients cannot access complete pictures of patients’ healthcare statuses as their histories and parts of healthcare records reside in several disconnected, siloed systems.
The time has come to address this challenge.
The Healthcare Information and Management Systems Society (HIMSS) defines interoperability as the ability of different information systems, devices, and applications to access, exchange, integrate, and cooperatively use data in a coordinated manner, within and across organizational, regional, and national boundaries, to provide timely and seamless portability of information and optimize the health of individuals and populations globally. Moving towards interoperability will create a comprehensive, longitudinal view of a patient’s health history and prevent siloed healthcare data by liberating patient data. Eventually, it will enable patients to move on from different payers and providers, along with providing enhanced mobility for digital health data.
Since the late 1980s, interoperability has been at the center of attention in healthcare messaging standards. As a result, in 1987, the Health Level Seven (HL7) organization was formed to address this. HL7 came up with a comprehensive framework and a set of standards for healthcare interoperability to enable the exchange, integration, sharing, and retrieval of electronic health information.1
HL7 v2 has been used for over 30 years and has predated the widespread use of the internet. Today, in this new digital ecosystem, the need to share and access healthcare information is key. As patients take a more active role in their healthcare, they want the ability to view and monitor key details such as their electronic health records (EHRs), benefits, and other information.
HL7 released its first version of Fast Healthcare Interoperability Resources (FHIR®) in 2011. This is the next generation by which EHRs, digital health applications, and consumers use and exchange structured healthcare data. The FHIR® standards framework combines the strengths of past versions (i.e., HL7 v2 and HL7 v3), utilizes current web standards (APIs), and focuses on fast implementation. FHIR® R4, which was released in 2019, provides the first set of normative FHIR® resources with backward-compatibility and addresses the challenges of interoperability in modern healthcare systems.
Figure 01: The evolution of FHIR®
Recognizing the challenges and opportunities around interoperability, government institutions, centers, and regional organizations around the world are introducing new rules and standards. One such rule is the recent CMS Interoperability and Patient Access final rule (CMS-9115-F), which was issued by the Centers for Medicare & Medicaid Services (CMS), an agency of the US Department of Health and Human Services (HHS). The rule mainly focuses on driving interoperability and patient access to health information by providing autonomy to patient data. It aims to put patients first, giving them access to their health information when they need it most and in a way they can best use it.2
The CMS Ruling and Its Impact
On March 9, 2020, the CMS finalized and issued CMS-9115-F, which consists of three main policies, namely the Patient Access API, the Provider Directory API, and the Payer-to-Payer Data Exchange. These policies are mandated by the CMS and are to be implemented no later than July 1, 2021, and January 1, 2022, respectively, as shown in Figure 2.
The CMS’s Patient Access API and Provider Directory API policies require CMS-regulated payers to implement and maintain a set of secure standards-based on APIs. The Payer-to-Payer Data Exchange policy focuses on allowing secure data exchange between CMS-regulated payers. Through these policies, the CMS rule aims to enable better access to health information for patients, improve interoperability, and unleash innovation.
Figure 02: A high-level timeline of the CMS rule
- Patient Access API: CMS-regulated payers, are required to implement and maintain a secure, standards-based (HL7 FHIR® Release 4.0.1) API that allows patients to easily access their claims and view information, including costs, as well as a defined subset of their clinical information through third-party applications of their choice. Claims data, used in conjunction with clinical data, can offer a broader and more holistic understanding of an individual’s interactions with the healthcare system, leading to better decision-making and better health outcomes.
- Provider Directory API: CMS-regulated payers are required by this rule to make provider directory information publicly available via a standards-based API. Making this information broadly available stands to encourage innovation by allowing third-party application developers to access information so they can create services that help patients find providers for care and treatment, as well as help clinicians find other providers for care coordination, in the most user-friendly and intuitive ways possible. Making this information more widely accessible is also a driver for improving the quality, accuracy, and timeliness of this information. MA organizations, Medicaid and Children's Health Insurance programs (CHIP) and fee-for-service FFS programs, Medicaid-managed care plans, and CHIP managed care entities are required to implement the Provider Directory API.
- Payer-to-Payer Data Exchange: CMS-regulated payers are required to exchange certain patient clinical data (specifically the US Core Data for Interoperability [USCDI] version 1 data set) at the patient’s request, allowing the patient to take their information with them as they move from payer to payer over time to help create a cumulative health record with their current payer. Having a patient’s health information in one place will facilitate informed decision-making, efficient care, and ultimately can lead to better health outcomes.
The above policies have been adopted and passed by the CMS to empower patients to access their health and claims data and costs. Patient data, with the patient's consent, can be viewed by APIs provided by third-party entities and associated apps. The rules will also assist in the coordination of patient treatment with the ability for a provider to search for other providers.3
What Do These New Policies Mean?
Healthcare providers, with the use of APIs, will improve the usability of electronic healthcare records with the assistance of third-party software for medical staff. These APIs will enable physicians to easily access and search for patient health records.
Healthcare payers now are required to make health information available to patients and patient-consented third-party apps via APIs by the Patient Access API rule. Also, with a deadline of July 1, 2021, healthcare payers will maintain and publish provider directories data through APIs
Healthcare systems, with the use of APIs, can integrate with and access multiple systems to consolidate a complete patient electronic healthcare record (EHR). APIs and consolidated EHRs allow patients to easily move from one facility to another, without spending time and resources to request for their EHRs to be sent to another facility. Additionally, patients can review their EHRs on their electronic devices. Patients and their healthcare providers will have better visibility and be better informed about health information, which can lead to better care and improved patient outcomes.
Who Does the CMS Rule Apply to?
The payer provisions of the CMS rule apply to:
- Medicare Advantage (MA) plans
- Medicaid managed care plans
- Children’s Health Insurance Programs (CHIP) managed care plans
- CHIP state agencies (CHIP FFS)
- Qualified Health Plan (QHP) issuers on Federally Facilitated Exchanges (FFEs)
- State Medicaid agencies (Medicaid fee-for-service [FFS])
How Can You Prepare and Comply with the CMS Rule?
When preparing for the CMS rule, payers and providers have to overcome obstacles such as aggressive timelines, the lack of clarity on compliance requirements, not enough in-house expertise, limited budgets, and not having a clear internal strategy beyond the CMS rule. We have identified four steps to address these challenges.
Figure 03:How to prepare for the CMS rule
Analyze Compliance Readiness
Healthcare payers must understand the different provisions and requirements to access data in their environment according to the CMS rule. Payers must understand and analyze any internal gaps that their current technologies may have. Are there any process barriers for sharing such data with outside entities? Payers should also be prepared for new rules in the future. These are the first rules put into place by the CMS with many more to follow.
Alleviate Data Mapping Risks
Healthcare payers will need to assess the risks and impacts of the broadest interpretation of the rule and come up with a contingency plan for those risks along with readiness and complexity assessments plans. They will have to recognize uncertainties that may have been identified in the data requirement assessment and always assume a high complexity effort when estimating data mapping.
Foresee Data Quality Issues
Healthcare payers will need to expose their records of inputs, entities, systems, and processes that influence data of interest, providing a historical record of the data and its origins. This is important to confirm the authenticity of data and enable it to be reused. It also provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility. Data quality concerns will still arise and healthcare payers will need data quality process teams in place to manage and escalate any issues.
Evaluate Vendor Solutions
Healthcare clients will require different deployment options; they will need the flexibility of being able to run in on-premise, hybrid cloud, or multiple cloud environments. The deployments could be deployed on bare-metal, VMs, or containers.
Healthcare identity systems need to handle healthcare API security through protocols such as OpenID Connect, while advanced end-user consent management for apps and data becomes a core requirement.
Vendor solutions should be built on purpose-built API integration platforms to enable organizations to participate in the API economy, which is key for healthcare companies looking at building a competitive edge. Strong healthcare API platforms provide capabilities such as API marketplaces, API products, API monetization, rate limiting, and throttling.
A critical part of the implementation is connectivity to new and existing source systems. While integration is fairly predictable when well-known commercial off-the-shelf (COTS) systems for claim management and EMR/EHRs are used, the reality is that there are a number of homegrown systems with data residing in databases or spreadsheets. Teams need a purpose-built integration engine that can handle current and future simple or complex integration requirements. In addition to FHIR based on REST/JSON, healthcare integration involves HL7,X12, EDI, CDA, XML, custom formats, and direct database connectivity.
API-Driven Healthcare Integration
Owing to CMS-9115-F, the use of APIs in healthcare has become a mandated requirement of a digital healthcare integration solution. Its success is central to managing the relationship between API providers and API users.
When evaluating a healthcare integration solution, there are different options and types of vendors. Vendor healthcare solutions can be mainly broken down into three types:
- API integration solutions
- Niche solutions
- Hybrid solutions
API integration vendor solutions should be based on their healthcare integration solution expertise, the ability to execute, and market presence in enterprise integration and API management. An experienced vendor’s core business should be in integration and APIs and have demonstrated many years of success with clients in the integration and API market. These API integration vendors should truly understand integration and have proven success in integration. The vendors should also have experienced healthcare integration & FHIR®-focused teams to support their vendor solution. These integration teams should include integration developers, professional integration services, and integration support teams with a 24 x 7 x 365 model.
Niche solutions vendors usually provide a specialized function in the healthcare environment, and they typically build solutions as the need arises. These vendors can pose a risk due to their lack of expertise, technologies, and support for the healthcare integration solution vendor space.
Healthcare clients will require different deployment options. They will need the flexibility of being able to run in on-premises, hybrid clouds, or multiple cloud environments. The deployments could be deployed on bare-metal, VMs, or containers. Deployment flexibility is a key question that should be asked of vendors. The vendor you select should have the flexibility to deploy the healthcare integration solution, where you, the client, needs it to be deployed for the present and the future.
What are the key questions you should ask? And what features should you be concerned about when selecting a healthcare integration solution? The three focus areas for core capabilities should be API management, application integration, and authentication and authorization security. The following diagram highlights key capabilities in an ideal FHIR® solution.
Figure 04: Key capabilities in an ideal FHIR® solution
Introducing WSO2’s Open Healthcare Platform
The WSO2 Open Healthcare Platform is a solution built on top of our industry-leading, open-source integration platform. It supports API-driven interoperability, seamless and secure health data exchange, and health data transformation with pre-built FHIR® accelerators for rapid implementation by meeting regulatory compliance requirements.
Figure 05: WSO2’s Open Healthcare Platform: A reference architecture
The platform allows you to quickly transform your data and expose secure APIs to meet interoperability requirements mandated by governments. It supports building a FHIR® R4 server with pre-built API definitions; securing FHIR® APIs using OpenID Connect; authorizing APIs using OAuth2.0; transforming various data models to the FHIR® format; integrating with EMR systems, wearable devices, health databases, SaaS applications, in-house services, etc.; registering third-party application providers; and collecting statistical and real-time insights of your APIs. The platform can be deployed on-prem, in multiple clouds, in VMs, and in containers. The following diagram depicts its key features.
Figure 06: WSO2 Open Healthcare Platform: key features
How Can We Help You to Become Compliant with the CMS Rule?
WSO2 has partnered with some of the best healthcare domain knowledge partners in the world. By combining WSO2’s world-class advanced security enforced API integration technology and our partners’ healthcare domain knowledge and expertise, we can provide you with a turnkey solution for the fast approaching Interoperability and Patient Access final rule (CMS-9115-F). With our implementation timeline, we can have you compliant within three to six months.
Moreover, compliance with CMS-9115-F will lay the groundwork for future requirements, such as those for the Provide Directory API and Payer-to-Payer Data Exchange and many others.
Building an integrated healthcare platform is crucial for healthcare payers and providers in their interoperability journey. It is important to strategize and plan this effort step-by-step to meet regulatory requirements and advance the care experience. WSO2 is ready to facilitate this with our industry-leading Healthcare Integration Platform. The solution will enable you to quickly transform your data and expose secure APIs to meet interoperability and modern digital transformation requirements. Our dedicated team will work closely with you from the start and help you to implement the solution in a short time.
Do you want to simply start consuming secured FHIR® APIs? Then, request access to our sandbox environment here. You can also contact us for more information.