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.
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.
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:
- 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
- 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
- You pull all the data into one central location
- You perform data transformation and de-duplication on it so that patient data is correctly defined
- This data will not be real time. By it’s nature there will be some latency
- The normalized data can then be called securely by whatever is fronting your API’s
- A hybrid option can work if your provider data is easily accessible and already centralized
- API platform calls provider data and enables a FHIR API
- 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.