21st Century Cures and the CMS Interoperability Rule: What’s Next for Health Plans?

08.05.20 Julian Malinak

We at Moxe have been closely following the 21st Century Cures Act since its fledgling days in Congress in 2015 to when it was eventually enacted on Dec. 13, 2016 — one of the last pieces of legislation President Obama signed into law.

A lot has happened in the US and healthcare industry since then. Just as COVID-19 was coming into the US and rightly overshadowing everything else in healthcare, CMS and ONC issued their final rules on March 9, 2020.

Navigating the Legislation

For HHS (the federal agency which includes CMS and ONC), the high-level vision is about health data flowing seamlessly between providers, payers, and patients — with patients ultimately having the ability to control their data and use it in the third-party applications of their choice.

Impeding the flow of data is the practice of info blocking, which the ONC rule defines as “a practice that, except as required by law or specified by the Secretary of HHS as a reasonable and necessary activity, is likely to interfere with access, exchange, or use of electronic health information (EHI).” The ONC rule, while relevant for health plans, focuses on requirements for health IT developers, health information networks/exchanges, and providers. 

For health plans, the CMS rule drives what needs to be built.

Most insurers have segments that are subject to the regulation, which includes “MA organizations, Medicaid Fee-for-Service (FFS) programs, Medicaid managed care plans, CHIP FFS programs, CHIP managed care entities, and QHP [qualified health plans] issuers on the FFEs [federally-facilitated exchanges]”. Medicaid FFS and CHIP FFS are not subject to Payer-to-Payer Data Exchange, but other than that the requirements are largely the same across plan types.

Cures Compliance for Health Plans

Below is a high-level overview of the requirements for health plans in the 474 page rule with some thoughts on operational and strategic implications. Links to other resources that may be helpful in looking at the rule, including the official resources from HHS, are in the final section.

The rule places three requirements on payers:

    • Patient Access API
      Plans must have the infrastructure in place for members to access certain administrative and clinical data via a third-party application of their choice. This becomes enforceable on 7/1/2021
    • Payer-to-Payer Data Exchange
      Plans must be able to exchange certain clinical data with other plans as patients change carriers and request their data move with them. This becomes enforceable on 1/1/2022
    • Provider Directory API
      Plans must have provider directory information available via API. This becomes enforceable on 7/1/2021

For HHS (the federal agency which includes CMS and ONC), the high-level vision is about health data flowing seamlessly between providers, payers, and patients — with patients ultimately having the ability to control their data and use it in the third-party applications of their choice.

What does this mean for payers?

This blog will focus mainly on the Patient Access API given its high level of complexity and strategic importance.

In practice, we’re seeing that most plans and technology vendors (including Moxe) are looking to solve both Patient Access API and Payer-to-Payer Data Exchange using a unified infrastructure. While the requirements laid out in the rule are different, it’s fundamentally a similar problem of ingesting data from various source systems, transforming to a specified standard, unifying by member, and servicing out via API. So the discussion around infrastructure below largely applies across both. Provider Directory, on the other hand, has mostly distinct challenges and requires a separate build.

Patient Access API

An API (application programming interface) is essentially an intermediary that allows different applications to talk with each other. If I’m creating an app to help companies manage their social media presence, I might use APIs from Facebook and Twitter to put data from those platforms into my app. With Cures, the idea is that if I’m a member and am using a diabetes management smartphone app that wants to ingest data from my health plan (for example), the app can access that data via API.

In addition to defining what data is required, the rule defines technical standards — standards are important so that apps can integrate in a similar manner across different payers.

Data Requirements

The rule lays out the following required areas for data sharing:

  • Claims information must be available one business day after processing. This includes adjudicated claims, provider remittances, and enrollee cost-sharing.
  • Encounter data (for capitated providers) must be available one business day after receipt of data.
  • Clinical information including laboratory data when maintained by the plan must be included one business day after receipt.
  • Formulary data (information on covered outpatient drugs for FFS Medicaid and CHIP) must be included, with timing varying by plan type.

Data sharing requirements are applicable to data from dates of service on or after Jan 1, 2016.

The requirements around clinical data have the most ambiguity in my reading of the rule and in conversations with health plans, regulatory experts, and other health IT developers. In the rule, clinical data included in USCDI Version 1 must be made available if the data is received and maintained by the payer as a part of its normal operations. 

We’re actively seeking additional guidance from CMS on this issue — payers receive and store a great deal of clinical data for a variety of use cases. Is all of this clinical data maintained as a part of normal operations, or only some subset of it? I do want to acknowledge that as a company with a lot of infrastructure and expertise around clinical data exchange among other areas, Moxe has an interest in the clinical data sharing requirements applying broadly. And I certainly don’t claim certainty on when future guidance will come from CMS and what it will look like. With all that said, however, I do think it’s likely that regulators will be fairly aggressive in pushing health plans to include all their clinical data.

Technical Standards

Generally, the rule identifies HL7 FHIR Release 4.0.1 (FHIR R4) as the foundation for data sharing. The rule also details when plans can use updated standards in the future and specifies that sharing non-required data can be done using any standard the plan chooses.

The rule specifies the following content and vocabulary standards:

For most plans, there is a significant build required to source the required data from the appropriate homegrown and vendor-based systems and transform it to the required specifications. This data then needs to be serviced out via API using OAuth 2.0 and OpenID Connect authorization and identify frameworks. Plans must make API documentation available and routinely test and monitor the API to ensure proper functioning, including conformance with HIPAA requirements and related privacy and security features.

What Needs to Be Built

At a high level, we’re tackling the Patient Access API with the following components. While there is variation in how different health plans and vendors categorize the work required, most that we’re talking to are aligned on the core capabilities required. Differentiation will be around rigor of execution, time to build, and cost.

  1. Acquire data from source systems
    This includes the extraction of claims, encounters, payments, pharmacy, formulary, and clinical data via API / ETL / other methods. It would be great if data was always available from source systems using clean, well-documented APIs, but that’s simply not the case here — so the key ability here is infrastructure and experience extracting messy healthcare data.
  2. Transform data to FHIR R4 specification
    The core ability here is being able to convert a host of clinical and administrative data sources (HL7 v2/3, C-CDA, X12 and EDI formats, PDFs, proprietary vendor formats, etc.) to FHIR. I don’t think any vendor has every adapter a plan will need out of the box (there are always customizations and niche formats to deal with), but a well-equipped vendor should have a broad range of adapters already built and expert staff on hand to quickly build new ones.
  3. Validate, unify, and store data
    Data needs to be validated against specific FHIR profiles/value sets and de-duplicated given the potential for overlapping source systems (although it’s important to try to solve for this upstream by mapping out the correct source systems to use). Once this is complete, data needs to be unified into a longitudinal record for a given member. Finally, there needs to be a scalable storage platform or the ability to deploy a managed environment on a plan’s infrastructure.
  4. Data Servicing, Member Consent, Third-Party App Management, and Developer Portal
    Data needs to be serviced out via API using OAuth 2.0 and OpenID Connect authorization and identify frameworks. Members should be given information on benefits/risks in the consent flow. Third-party attestation to security and privacy standards needs to be managed, along with a developer console and API documentation.

Other Components to Consider

Beyond these required tools, there are a few other areas to highlight:

Regarding clinical data, we recommend that plans/vendors go upstream and try to obtain higher quality data in the first place from source systems like providers and labs.

This is step 0 that makes everything else downstream more robust. If, for example, a plan has lab data in unstructured / PDF formats but can instead obtain FHIR-native data directly from the labs, this eliminates the burden of transforming unstructured data. One strong tailwind to focusing on clinical data acquisition is that elements of the ONC rule for providers and health IT developers help facilitate more standardized data sharing from providers to payers. Nonetheless, this approach takes time to scale, so it’s still crucial to have strong tooling for data transformation.

For use cases beyond Cures compliance (e.g., quality, risk adjustment), we recommend that plans dedicate resources to API integration assistance and other add-on tools.

For internal plan users and contracted vendors, an API for access to standardized, longitudinal member data presents rich possibilities. For instance, a care management platform could integrate with the API and generate more useful insights for care managers. Payers and interoperability vendors should be ready to provide technical resources to support these integrations. Beyond this, pre-built utilities on top of the API can add value even in the absence of such integrations. A chart viewer allowing a non-technical user to examine a patient’s longitudinal FHIR record would be useful in areas from care management to risk adjustment to prior auth. An interface to query and export aggregated data sets would be useful for clinical and business analytics teams.

Many plans we’re talking to are concerned about access to data by apps that either have poor security or are likely to be poor stewards of member data in other ways.

I share this concern, although I can see why CMS didn’t want to give plans much leeway in gatekeeping. The rule is explicit that plans need a strong justification with objective, verifiable criteria to deny access, showing how the security of protected health information on the plan’s systems would be at risk. The rule is also clear that plans will not be accountable for what happens to data once in the systems of a third-party. Even so, we think plans should focus on educating and informing members, letting them know the risks of using third-party apps in general, and giving guidance on security/privacy standards of specific apps when available. For the internet in general, data use policies/warnings are overwhelmingly not read — but we think there could be true utility for members if education is done in a manner which is authentic and digestible across educational and social backgrounds. The rule has some general requirements and specifications around member education, but plans have a fair amount of leeway on how they approach this.

One strong tailwind to focusing on clinical data acquisition is that elements of the ONC rule for providers and health IT developers help facilitate more standardized data sharing from providers to payers.

Industry Implications

By fall of 2021, we might start to have a sense of the impact of this provision. What will the volume of data requests look like? What type of apps will make use of the data in a manner which is truly useful for patients?

For claims and encounter data, members should absolutely have access to this information in an easily digestible format to help them understand what they are spending on care, and I think many third-party apps will step up here. There may be other consequences that are unintended and hard to predict. For instance, some commenters on the rule were concerned about the aggregation of payers’ negotiated rates through third-party apps. I could see this happening, and potentially in a more rigorous manner than through the price transparency requirements from HHS which may face continuing legal challenges.

There is particular uncertainty around how clinical data sharing will evolve. I think (anecdata warning) that what most patients want is the opportunity to unify and utilize their clinical data (including labs, prescriptions, immunizations, procedures, physician notes, etc.). At the risk of being overly idealistic, there is a lot of upside here for patients. I think of my own experience with low back pain, where I saw various specialty/primary care clinicians, physical therapists, labs/imaging, etc. My case isn’t nearly as complex as that of many patients plus I have some knowledge in this space, but it still took me a lot of effort to organize my records into anything close to a useful format. It would have been quite helpful to have access to a clinical data ecosystem that actually worked. Beyond the general utility of “personal health record”-type apps for patients, other apps and tech-enabled services could use this data to level up their offerings — including behavioral health and symptom management apps, tech-enabled primary care and specialty clinics, provider-facing decision support tools, and many more.

The regulatory interpretation issues mentioned previously (what clinical data truly needs to be included in the API) will have an important role in determining whether we reach this promised land. Beyond this, there are plenty of other factors, including how the ONC info blocking regulations play out and other industry dynamics beyond Cures.

Responding Strategically

Much will be determined based on how health plans respond from a strategic perspective: Beyond avoiding regulatory penalties, Cures is an opportunity for health plans to take compliance work and extend it to serve broader goals. This is a big area to explore, so we’ll just mention a few elements here.

Using the interoperability infrastructure for core plan functions can generate return-on-investment far beyond compliance with the CMS regulation.

Member engagement.

How many plans will be able to provide members with a picture of their healthcare journey that the member — particularly those with multiple, complex conditions — sees as truly comprehensive and up-to-date? Capabilities here will fall into three broad buckets:

  1. Data sharing is deficient to a large extent, risking regulatory action. Examples include major gaps in both administrative and clinical data or API frequently not functional.
  2. Data sharing is sufficient to avoid regulatory scrutiny but still lacks completeness from the member’s perspective. Examples include significant gaps in clinical data or frequent data formatting bugs.
  3. Data sharing offers members a truly complete picture of their health data. In our view, the major hurdle for most plans in reaching this from level (2) will be around sourcing and transforming data at scale to FHIR.

Beyond having a highly functional API, plans can build additional stickiness with members by offering useful plan-owned apps and tools and/or partnering with select companies behind the third-party apps to offer added services.

Other Core Plan Use Cases

Improving clinical data acquisition and data usability is important in key areas like an evaluation of provider performance in value-based contracts, executing population health/quality initiatives, risk adjustment, care management, and more. The capabilities noted earlier — improving upstream acquisition of data and offering support for API integration / other add-on tools beyond the API — are critical here. Using the interoperability infrastructure for core plan functions can generate return-on-investment far beyond compliance with the CMS regulation.

Payer-to-payer data exchange

The scope of data for payer-to-payer data sharing requirements are the USCDI Version 1 referenced in the Patient Access API. CMS cites various use cases and benefits of data following members from payer to payer, including utilization review, risk assessments, and more.

There are two capabilities that a plan needs to have:

  1. Receive information on a member from another payer and incorporate that information into its records.
  2. Send data to another payer that currently covers a former member upon request from that member.

The requirements cover a five-year timeframe (i.e. both incorporate data from the preceding 5 years and send data for up to 5 years after disenrollment). Data exchange is only done upon the direction of a current/former member.

Unlike for the Patient Access API, the precise standards for exchange are not specified. To reduce burden given the potential for various exchange/data standards involved, if a plan (Payer A) receives data from another plan (Payer B) and then later is requested to share that data with a different plan (Payer C), the requirement is that Payer A shares with Payer C in the electronic form and format it was originally received from Payer B — so there is no burden on Payer A to transform the data they receive. Along these lines, CMS clarifies: “…incorporating the data into the payer’s records under this specific regulation would not require that the payer treat or rely on these data as its own, but that the payer must include these data in the record it maintains for each enrollee.” 

Despite this allowance, however, we think payers should endeavor to incorporate shared data into day-to-day systems, rather than siloing it off. For care management programs, for example, data shared by another payer needs to flow through to the tool(s) used by the payer’s care management staff to be broadly useful. This is why Moxe’s approach with this provision is to put in place architecture to convert incoming data to FHIR so it can be unified with the other data available in the longitudinal record serviced out in the Patient Access API. (In terms of sending information, we are also using the same API architecture as for the Patient Access API).

This increased access to data also means that plans which are siloing data shared from other payers off rather than integrating it into their operations could be at an increasing competitive disadvantage over time.

One important thread to pull on with this provision (and the Patient Access API) is that as data flows more freely, access to data in itself could become less of a competitive advantage than it historically has been. This could take at least a few years to come to fruition, I think. If and when it does, it means that differentiation will be more about how plans use this data to engage members as well as augment internal programs across areas like network, payment innovation / value-based payment, risk adjustment, quality, and more. This increased access to data also means that plans which are siloing data shared from other payers off rather than integrating it into their operations could be at an increasing competitive disadvantage over time.

Provider Directory API

While previous regulations “already require that provider directories be made available to enrollees and potential enrollees in hard copy and on the plan’s website”, CMS believes that having directories available via API would help support development of a variety of useful applications for beneficiaries and providers. This seems like a reasonable argument to me, with use cases including the obvious ones like EHR-embedded referrals for providers and consumer-facing “find a doctor” sites, but I expect a number of non-obvious use cases to emerge over time.

The provider directory must include the following data:

  • Provider Name, Addresses, Phone numbers, Specialties
  • For MA organizations that offer Part D prescription drug benefits, pharmacy directory must include Name, Address, Phone number, Number of pharmacies in the network, and Pharmacy mix (e.g., retail, specialty)

The directory must be updated within 30 days of network changes occurring.

As far as data standards, this also references FHIR R4, in particular the DaVinci PDEX Plan Net IG.

There are essentially two compliance challenges here:

  1. Transforming provider directory data from its current format to the specified API
  2. Making sure the provider directory is accurate and up-to-date (see this 2018 survey from CMS showing over 50% in deficiency rates for provider directory accuracy)

(1) is certainly not trivial — plans often have multiple sources for provider directories, each requiring work to access and transform. But this is still far simpler than the data integration work required for the other provisions. (2) is more challenging. If data from the source systems is inaccurate and does not get updated correctly as network and provider information changes, the information serviced out via API will continue to be inaccurate. Making sure data is reflective of reality and kept up-to-date is a broader, longstanding problem — and solving it requires rethinking how the provider directory is being maintained across the enterprise. 

Here at Moxe, while the two other requirements fit perfectly with our focus over the past 5+ years, Provider Directory is a newer area for us. So we have been taking a pragmatic approach with a combination of insourced and outsourced tooling. I’m cautiously optimistic that Cures will live up to its promise here and level up transparency and access around provider networks.

Closing thoughts

Plans we’re talking to are looking at a variety of solutions for Cures, from fully outsourced with a single vendor to mostly insourced with niche support from point solution vendors when needed. I want to highlight a few considerations when choosing a vendor or planning insourced efforts — and map these to what we’re doing at Moxe.

Cures presents both defensive (avoid regulatory penalties) and offensive (member engagement/data analytics) opportunities.

Tech Assets

We have core infrastructure built for converting clinical and administrative data to the FHIR R4 specification, plus identity matching, access controls and data provisioning engine, data provenance and auditing tools, and much more. There are some new things we’re building for the rule, but in the most complex areas, we largely have what is needed.

Healthcare Data Integration Experience

Our team has expertise around API deployment in healthcare and experience with large data integration projects. We find that the technology infrastructure component is often less complex than accounting for the people and processes that underpin any effort of this type: synthesizing input from various internal and third-party vendor stakeholders, communicating expectations effectively, and ensuring a streamlined support process. We’ve focused on building these up through our work with large health plans over the past years.

Usefulness beyond Cures Compliance

The Interoperability rule presents opportunities to differentiate on member engagement and level up work around clinical data acquisition and analytics, quality of care, risk adjustment, and more. We have experience augmenting data exchange to support a wide range of important health plan functions.

Cures presents both defensive (avoid regulatory penalties) and offensive (member engagement/data analytics) opportunities. It will be a long road to get there, but we believe that access to data will become more commoditized over time — so our long-term aim here at Moxe is to help plans differentiate by acquiring data even beyond the regulatory scope and using that data to level up internal functions and engage providers and members in new ways.

 

Preparing for Cures compliance? If you’re interested in learning more about our approach or have questions on the regulations and its implications, please contact Us or schedule some time on my calendar to learn more about how Moxe can help. 


Julian Malinak is VP Business Development at Moxe, where he focuses on helping health plans acquire, manage, and utilize clinical and administrative data. He previously co-founded Canvas Medical focusing on improving EHR workflows for primary care providers and worked at the CMS Innovation Center designing accountable care organization and other value-based payment models.

References
CMS Interoperability and Patient Access Final Rule resources. Contains links to the different technical standards/implementation guides for the CMS rule.
ONC Cures Act Final Rule resources. Contains rule summaries and resources for the ONC rule.
CMS Final Rule. Official regulatory document.
ONC Final Rule. Official regulatory document.
HFMA Final Rule Summary. HFMA (Healthcare Financial Management Association) put together a document that goes more into more detail on the regulatory details than this post.

Join Our Network

Start connecting with millions of patients, health systems, and health plans.

  • * required