What do the CMS/ONC Interoperability Mandates really mean for Health Plans?

Mark: People know me on Twitter as @ekivemark. I spent the last five years at CMS, initially as the entrepreneur in Residence and then I was given the title of CMS Blue Button innovator. I was the first person on the Blue Button 2.0 project. I played a key role in the whole design and build out of the platform and then promoting it to the point where there’s now over 3,000 developers from more than a thousand organizations in the sandbox.

I also spent five years working within a health plan before going to 3M Health Information Systems to take their products to the cloud. I’m really excited to be Onyx Health’s Chief Interoperability Officer. It gives us a chance to take the lessons we learned from building Blue Button and bring them out into the payer community that now has to implement Blue Button themselves. Which in turn improves access for consumers, allowing them to get their health data and put it to use, whether it’s for themselves or for research for the people they care about. It is so great to be here!

Mark: Yeah, actually, I was presenting to the HL7 community at the connectathon last week about this and really you need to consider both the ONC rule and the CMS rule. They were both put out on the same day: March 9th, 2020. The ONC rule is looking at this issue of information blocking that came about as a result of the Cures Act. But the CMS rule is the interoperability and patient access Rule and the major focus of that is really on the parts of the healthcare industry that CMS regulates which is primarily the payers where they fall into either Medicare Advantage plans, qualified health plans or chip programs. So it really does impact pretty well every payer out there, at least in some part of their business. I think the longer term threat is if the you don’t deliver on these interoperability requirements, then you’re not going to be licensed to do business. So it really gives some impetus to payers to deliver on these requirements and CMS is not giving them a lot of time. The actual release into the Federal Register extended the deadline to July 1st of 2021 for the first round of implementations. That’s still not very long, it gives us just over 12 months to get systems finally defined and implemented. And some of these specifications are still going through the publishing process in HL7, and I’ve been involved in some of that activity.

It’s pushing towards consumers having a longitudinal health record. I think the payers that really embrace the new regulations, thinking beyond just compliance with the mandate and looking at how interoperability can this help their business, they’re the ones that are going to win. So it’s going to be a really interesting time.

In terms of what’s covered. It really falls into three major areas. There’s the claims information. So that’s really what Blue Button 2.0 demonstrated at CMS. We delivered this to 53 million Medicare beneficiaries allowing them to get their claims information and share it with the applications, services or research programs they trusted. And so, the interoperability rule requires payers to do the same by releasing their claims information.

It also points to them needing to release encounter and clinical data. And that’s where I’ve been working on the DaVinci Payer Data Exchange project. We have an implementation guide that will allow payers to take the clinical data they get such as, the lab results and other clinical content that they receive through various means and make it available in FHIR formats. HL7 FHIR (Fast Healthcare Interoperability Resource) Specification make the data available in those standard formats via APIs.

The other two areas that are touched on in the rule cover the what’s typically called the ‘Provider Directory’ and the formulary. There’s a requirement that these are open APIs. Enabling third-party applications to connect to these APIs to help people understand things like, “Is my doctor in your network?”’ or “Which doctors in your network are within 10 miles of where I live?”; those types of questions or “The drugs that I’m actually taking, which tier are they in your plan?” or “Are they covered in the prescription drug plan that you’re offering me?” These are all things that we’ve seen with Blue Button really help consumers make informed decisions about what’s the right plan for them.

So overall, this is all about getting data and having consumers have the ability to move that either to third-party applications or to other payers. For example, when we move from plan to plan.

Mark: Well, one of the lessons I really learned from Blue Button is it’s not just the FHIR API. There are open source solutions out there to create a FHIR API and that’s great and there are some really good solutions. We use some of those for the building of Blue Button 2.0. But, it’s more than that. You need to be able to deal with the identity management for your members. You don’t want them to have to have yet another user ID and password. That’s just a management nightmare. You need to be able to test the API. You’ve got to be able to register third-party applications and manage that developer community. You’re going to have to make documentation available about how to interact with your API.

You’re also going to have to take data from your data lake, because CMS is requiring you to take data going back to January 1st 2016 and make that available. So you have to ingest that into this API platform. So, it’s far more than just putting together an API server. It’s getting all the data into it and then controlling the access to it, and then managing the community around it. That was a big part of what we did with Blue Button 2.0, it was really thinking of that as a product and really recruiting people and evangelizing , so that we actually got buzz around that and people actually used it.

What I don’t think CMS wants is for payers to invest a lot of money in building these APIs and they sit there not being used. So it’s really about how do we come together as a community to deliver this. If I was an executive I would be looking at the organizations that are actively involved in helping to develop these specifications because they’re understanding them. Some of these implementation guides are still in development. So you want to get as much runway to get these solutions implemented as you can. Also if you think about the need to onboard five years’ worth of data, you’re going to have a growing data store; because it’s not just 5 years of data. In another five years it’s going to be ten years of health history. We really are heading towards this longitudinal record.

So you need to think realistically about putting this solution into the cloud, so that you’ve got the capability to expand as you go forward. You really want people/partners that have thought about how you’re going to deliver this at scale, how you’re going to wrap all of these services together into a cohesive solution. Not to brag but that is really what we’ve set out to do at Onyx health. Take all those lessons that we learnt in building Blue Button 2.0 and apply it. We partnered with Microsoft, one of the leading Cloud vendors in the world to be able to deliver this scalable platform as an entire solution to allow payers to really accelerate their time to compliance.

Mark: There’s a number of things. First, don’t underestimate the effort that’s going to be involved in mapping. Particularly, if you’re probably looking at a facade type implementation, where your APIs need to, in real time, reach back into your data services to present data to your consumers. You need to make sure that if you’re going that route that you’ve got the ability to service that 24 by 7 potentially high demands in a really sort of peaky type manner. At CMS, we extracted the data and put it into its own repository. Because the sheer challenge, of making the petabyte and more of data that we had available for those beneficiaries, to make that available on a 24 /7 basis was going to be cost prohibitive.

You can leverage the work that’s being done by the CARIN alliance with their Blue Button 2.0 or consumer-directed exchange IG. They’ve done a lot of work in some of the mapping of FHIR to the data elements in your data lake into files that can then be converted to FHIR. There’s still work to be done in that space. But people that have been actively engaged in that area are people you should probably look to work with.

At Onyx we’ve been actively involved in helping define what’s known as the CPCDS specification for this standard data feed.

You also going to need to think about how you can leverage open standards. You don’t want to be rolling your own security, leveraging things like OAuth 2.0, which is an implicit part of the specification for FHIR and SMART on FHIR. These are just some of the things you want to think about and leverage as you develop your solution.

There’s a lot to be done and you really want to find people that have done this before if you’re going to achieve the aggressive timelines that CMS has laid out.

Mark: Onyx (www.onyxhealth.io) is actually a sister company of NewWave (www.newwave.io). NewWave is a premier systems integrator. We’ve done work over 15 years with CMS. NewWave has a pretty massive pipeline of work to do with CMS and with other Federal agencies. The thing with a Federal systems integrator is they have a lot of rules that they have to deal with. I personally have lived inside CMS for five years, we understand what it takes to be successful.

With Onyx, we have developed a series of platforms and products. We have SAFHIR, which is our secure architecture for FHIR, a cloud-based implementation for things like the current Blue Button and DaVinci project implementations. We also have a consumer app – myCareAI. It was one of the first that was actually connected to the CMS Blue Button 2.0 API.

At Onyx, we are laser focused on really delivering products that are geared for FHIR-based interoperability to help the healthcare industry as a whole. At NewWave, we have a tagline that we think about every day and that is “Solving for the greater good”. And we feel that by creating Onyx and having this laser focus on FHIR-based interoperability where we’re helping to write the next generation of implementation guides, we’re building products that meet the requirements of those guides, we’re hoping to do our bit to help payers meet their compliance obligations.

Mark: Recently I was talking to a group of Community Health plans. They’re all grappling with how they deal with the challenge that CMS has laid down. In many ways it takes them into new areas that they’ve not had to deal with. They’re not used to dealing with third-party commercial applications. They’re not used to dealing with the fact that a consumer is going to be able to say I want to be able to connect my data to this application. You can choose to go it alone and run the risk of not actually following the standards. One of the core messages I give out to people is that we are stronger as a community. We need to be participating in the FHIR specification setting.

Last week, there were over 600 people from across the world engaged in a Virtual Connectathon, testing out the specification. These are events that provide teams an opportunity to really play with the specification and refine the implementation approaches.

I’d encourage any health plan out there to get involved in these and to really think about how we work as a community. Don’t try and reinvent the wheel on your own. If you can leverage things that have been done by other organizations in helping to do that data mapping, or in working with organizations that are building Cloud solutions that can be applied across multiple pages, you’re going to benefit from the experience.

So the bottom line I would say is get engaged, find the people that are really active in this community and start working with them. Come to us, come talk to us. We’ve been living this for a few years now.

Mark: There’s lots of ways. People often recognize me if I’m at conference with my brown leather jacket, that’s a “Walking Gallery of Healthcare” jacket and that’s attached to my Twitter handle, which is @ekivemark.

You can also reach me by our company Twitter handle, which is @Onyxinterop. You can go to our website www.onyxhealth.io or you can also find me on LinkedIn. Look me up anyway, reach out to me. I’d be happy to help on this really complex challenge that we’re all facing.