Healthcare

Interoperability Options To Meet CMS Final Rule

Istock 648272290 Featured Image

The CMS Final Rule has caused a lot of debate among the interoperability team at Perficient. It’s one of the first times payer or health insurers have had to react to these types of rules. The way they treat the data and the location of all the data makes this a different ball game than what you have to follow if you were a hospital. That means that while the basic rules understanding remains the same, the solutions you consider are actually quite different.

The Ask

Earlier this year, CMS / ONC released their much anticipated “Final Rule” which mandates that payers who have anything to do with federally related plans have to do the following:

  • Patient Access API – Provide a FHIR based API that lets patients access their claims and encounter information through 3rd party applications
  • Provider Directory API – Make Provider Directory information available through a publicly available FHIR based API
  • Payer to Payer transfer – Allow members or patients to request you transfer their records to another payer

Payers that meet key criteria must make these capabilities available and must do it following open standards like FHIR, SmartIG, and OpenID.

The Challenge

While many payers already have data and integration platforms available, most are not setup to make this data publicly available. In addition, a lot of this data resides in a range of systems. Those systems also have overlapping data. Therein lies the issue. Overlapping data means you have to find it, transform it, and deduplicate that data.  It’s possible to make a real time call but the more duplicates you have and the higher the overlap of data then the more you need to do.

In other words, Just creating a FHIR API won’t allow you to meet the need

Deciding on Solutions

Most of the debate in our team is what type of architecture will meet the criteria demanded by the CMS Final Rule.  Unfortunately, no one architectural approach will work for every payer.  This allows integration platforms with FHIR support and FHIR server type solutions to enter the mix. They can even co-exist depending on your ecosystem of platforms and data sources. In order to make a decision, you need to take into account the following:

  • Where does your patient / member information reside? Is it in multiple location for claims, eye exams data, clinical data, etc.?
  • Where does your provider information reside?  is it easily accessible via an api?
  • Is there a lot of overlap of data in the various data sources?
  • Do you have a hard time pulling from the data sources and mapping it to the correct member?
  • Do you already have or will soon have an integration and API management platform.  (both can be needed)

A Few Thoughts on Possible Solutions

As noted, not everyone will have the same solution. The larger the organization and the larger the number of data sources drives you to a more complex solution set to meet the Final Rule.  I would put the solution in a few categories:

  1. For those that have few data sources like mainly just claims data, you can consider using an integration and API management vendor to front both provider and patient data and to serve up the FHIR based resources
  2. For more complex, you can consider a FHIR Server or FHIR “solution”.  This may need to be paired with the enterprise integration and API Management platform.  This approach means the following
    1. You pull all the data into one central location
    2. You perform data transformation and de-duplication on it so that patient data is correctly defined
    3. This data will not be real time. By it’s nature there will be some latency
    4. The normalized data can then be called securely by whatever is fronting your API’s
  3. A hybrid option can work if your provider data is easily accessible and already centralized
    1. API platform calls provider data and enables a FHIR API
    2. centralized patient data platform for the more complex patient data scenarios

 

The bottom line is that each organization has a variety of options.  You always have to take into account your systems and your data to create your final architecture. Just remember that FHIR is the standard and not the solution.  Most of the heavy lifting occurs behind the actual FHIR call.

About the Author

Mike Porter leads the Strategic Advisors team for Perficient. He has more than 21 years of experience helping organizations with technology and digital transformation, specifically around solving business problems related to CRM and data.

More from this Author

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to the Weekly Blog Digest:

Sign Up