How to Take the Pain Out of New Interoperability Regulations by Enabling Legacy Systems

Authored by: Charlie Provenzano

The CMS Rule on Interoperability and Patient Access and the ONC’s proposed rule for Interoperability are creating some pain for payers. Though health plans traditionally have been proficient at sharing information with providers and members, the new rules mandate an industry-wide standard approach with deadlines that could prove very difficult for some payers. One of the key challenges payers face right now is making all their data accessible to patients, providers, other payers, and third parties in a secure fashion regardless of the disparate systems and diverse formats in which that data is stored. Broadly speaking, payers have two options: Wholeheartedly adopt the new standards and re-architect how they share information (i.e., high expense and disruptive) or enable legacy systems to meet the new standards without modifying tried and tested processes for claims, care management, and other functions. The second approach is typically more viable both financially and in terms of minimizing disruption to payer business systems and processes.


The initial 2020 deadline may be extended, and there’s a lot of uncertainty around the final form of the new rules as well as the effective date for those rules. Still, payers have to begin to act now in order to be compliant whenever the regulations come into effect. Regardless of deadlines, it seems HL7 FHIR (Fast Healthcare Interoperability Resources) will be the standard by which payers will achieve clinical data sharing, given its traction within the industry and support within the regulations themselves. Deployment of FHIR interfaces for existing systems will be the only option for many as it enables the creation of a set of FHIR-compliant services where new interfaces are mandated, without disturbing existing integrations that still work. 

For payers’ immediate focus, we recommend an incremental approach that works with existing infrastructure and still exposes FHIR resources to meet upcoming mandatory use cases. Some first steps to take:

FHIR-enable your existing clinical repository – Most payers already have some form of unified clinical repository built from existing claims and other data. Often there is also an elaborate set of programs in place to keep this repository in sync with all of its source systems.  All of this can be preserved with the addition of a FHIR-compliant layer for read requests, and with much less effort and rework than a project to build an entire new repository. The major decisions revolve around which data sets to use when duplicate data has been preserved from multiple sources. In addition, having a separate FHIR read layer allows the mapping of FHIR requests to the correct system of record/provenance data.

FHIR-enable other systems - Read-enable those additional systems needed to round out the mandated interchange use cases. Even if you have a repository established, there may be data needed in other systems that does not reside in that repository. You could update your repository schema and add the existing data, or you could choose to again create a read-only FHIR layer that can filter requests to pull data from other systems that is not found in the repository. This is a strategic option if the other systems aren’t FHIR-enabled at all, or if upgrading to the FHIR-enabled version doesn’t fit your timetable.

Enable systems to receive FHIR data - Once you’re able to respond to data requests via FHIR, it’s time to start looking at storing data that is returned from your own requests. If your central repository is already FHIR-based, you will probably just store the updates there. If not, you may want to build a new FHIR-based repository to hold this data. You might also want to add to your in-house synchronization logic so that it updates other systems as appropriate.

If you find you need help with rapid deployment of FHIR interfaces, or run into roadblocks with your interoperability planning, contact us. In our experience, that last mile of interoperability is always the most challenging. We have the expertise and the platform to help you set and meet the right interoperability goals.

18 views0 comments