The CMS Final Rule sparked some interesting conversations and problem-solving among the interoperability team at Perficient. It’s one of the first times payer or health insurers 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 transfer of 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.
READ MORE: Fast Healthcare Interoperability Resources (FHIR) Explained
The Challenge
While many payers already have data and integration platforms available, most are not set up 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.
YOU MAY ALSO ENJOY: Healthcare PowerByte: Interoperability – Make Data a Strategic Business Asset
Deciding on Solutions
Most of the early debate in our team was what type of architecture would 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 you soon have) an integration and API management platform? (NOTE: Both can be needed.)
A Few Thoughts on Possible Solutions
As noted, not everyone will land on the same solution.
Larger organizational structures and larger numbers of data sources drives you toward a more complex solution set. 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
SUCCESS STORY: Empowering Healthcare Consumers and Their Care Ecosystems With Interoperable Data
The bottom line is that each organization has a variety of options. You always have to take your systems and your data into account 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.
Have questions about your near- or long-term integration and interoperability goals. Our experts can help. Contact us to get started.
