CMS and ONC recently finalized rules around interoperability that require qualified health plans to publicly expose a provider directory API and to allow members to access their claims and clinical information through a Patient Access API by 2021. Since 2012, HealthSparq has been delivering provider search as part of our health care transparency and guidance platform, HealthSparq One. Our intake and processing of provider and claims data prepared us well for the new rules and allowed us to get right to work with the interoperability community after the rules were first proposed.
In that work, our team gained insights that added to our existing API and data experience to help health plans prepare for the implementation of interoperability solutions. Below I share some key takeaways from the first and most crucial step in a health plan’s interoperability journey: planning. I then share a bit more detail about the solutions that HealthSparq has developed over the last year of work on interoperability. If you’re interested in hearing more about all the steps we took beyond these initial research and planning stages, take a look at our recent webinar, FHIR and Provider Directories: Lessons Learned and Ways Forward.
From the beginning, focus on the end result
After the proposed rules were announced in early 2019, we focused in on the specific implementation guides that would support compliance. Our SMEs worked directly with the implementation guide developers to really understand, test and then deliver feedback. We built out our MVP APIs to participate in connectathons to share our work and test connections with others in the community. From there, we continued to iterate and built out a scalable solution.
Having attended a lot of connectathons, I noticed a lot of “stub API” solutions. These can, at a basic level, do the things that are required for the interoperability APIs. But what’s missing is a solid back end. A stub API can be a great way to get up to speed on the FHIR resources and show off the power of interoperability. A simple stub API can meet initial requirements, but the hardest challenge will be how to develop a performant, scalable API. For the Provider Directory API in particular, it requires a public facing API, which for most health plans will require investment in new foundational technology to support a scalable solution. The requirements to build a fully scalable solution go above and beyond bare minimum, but we believe it’s worth it. This is the overarching lesson learned that I’d like to share: remain laser focused on building out a fully scalable solution.
Get deep in planning
The first thing that you need to understand as you get started are your organization’s goals, and how those goals relate to the interoperability rules. Then your organization should plan to map your data into the implementation guide.
My tips to get started:
- Understand your plan’s goals and how they relate to the interoperability rules. As you’ll learn, the required data for the FHIR resource, especially when it comes to the provider directory requirement, is actually pretty lightweight. Basically, it’s: name, phone number, location and specialties. So, if you just want to meet the mandate, hopefully you don’t have too much difficulty there. But, as you should be thinking about long-term scalability, you can also use the interoperability rules to help meet other goals that you have. For example, most plans have preferred providers. There’s going to be a lot of consumer apps, and they’re now going to basically have an opinion on what provider to guide your members to see. Consider leveraging those consumer apps to guide your members to preferred providers. But the consumer apps are only going to be able to do that if you’re sharing the right data with them. That could be tier information, or providers’ Areas of Focus. If you want to leverage interoperability to support your organization’s strategic goals, you’re probably going to have to go above and beyond the mandate. That means mapping more of your data into that FHIR resource.
- Dedicate efforts for mapping data. Make sure your organization has planning cycles for mapping data into your FHIR resource. HealthSparq started this effort by bringing our experts into a room, studying the implementation guide, asking a ton of questions and mapping the data, and we did all of that before trying to engineer a solution or standing something up. Get as many of your questions as possible out of the way early on, before you start building things out.
- Join the community to ensure the guides actually meet needs. My third recommendation here is really more a recommendation for us as a community. As I mentioned, HealthSparq worked extensively with the implementation guide authors in 2019, providing them feedback to evolve and improve the guides. Some of our feedback was around how data is actually structured in the real world. Some of it was about gaining clarity so the guides are usable. We’re going to need to continue to iterate and evolve. This is a standards-based community, so it very much requires your involvement. I recommend providing feedback on the implementation guides to make sure that it’s meeting the consumers’ needs. The implementation guide developers are very engaged and want feedback. Take advantage of that.
- Develop a data quality strategy and execution plan. One of the top pain points for health plans is data quality and completeness. The interoperability mandates don’t solve your data quality problems, but they could expose them publicly. You’re going to want to make sure that you take this seriously because it can be a competitive differentiator as more and more players get access to your data. CMS leverages large fines for inaccurate provider data. Do you have a data quality strategy and an execution plan? It should take into account some of the requirements from these mandates about how quickly data needs to be updated. How exactly are you getting accurate data? If you have data conflicts, how are you resolving those and how are you doing that in a timely fashion?
If this is an area that’s new to you, it is best to get started thinking about it now. If it’s something that you’ve already been working on for quite a while, make sure that you consider the new requirements within the mandate for how to deal with the situation.
Getting ahead of the interoperability mandate with HealthSparq
With our long history in provider directories and price transparency, we launched our HealthSparq Interoperability Services offering. This includes two FHIR APIs to support health plans: a Provider Directory FHIR API and a Patient Claims Access FHIR API. Through our learnings from our work with the interoperability community, we developed our infrastructure with security and scalability in mind. HealthSparq can help existing clients by leveraging the provider and claims data that is used in the member-facing application, HealthSparq One. HealthSparq’s robust data transformation process transforms health plan data into the necessary FHIR-based resources. Claims and encounter data is held in a secure, HIPAA-compliant data store. A consumer authorizes an application to access their digital claims data via an OAuth2 authorization flow within the SMART on FHIR open standards. Our microservices distribute the provider- or claims-based resources via REST API queries that can scale with your needs. HealthSparq’s services follow the Da Vinci PDex Plan-Net Implementation Guide  for provider directory and CARIN Consumer-Directed Payer Data Exchange Implementation Guide (formerly Blue Button 2.0) for patient access requirements.
CMS rules require a unified consumer experience for the Patient Access API. Claims and encounters, formularies and clinical data often reside in disparate systems. To help plans minimize the burden of compliance, HealthSparq also has the ability to provide unified access to support a plan hosted FHIR servers. HealthSparq manages the access and identity management, OAuth, analytics, etc. for distribution with our Proxy Services. HealthSparq will then proxy to the plan hosted FHIR servers when necessary.
We take an even deeper dive into the mandates and steps to take after planning, including building a solid infrastructure to deliver mandated public-facing APIs and really focusing in on ensuring data quality and completeness in the webinar here. I’d encourage you to take look and let me know where your organization currently is as you prepare for mandates in the comments below.
