Redox positions itself to be ahead of curve on expected health data rule

Madison-based Redox is working to get ahead of the curve on data that electronic health record vendors are beginning to provide.

The U.S. Core Data for Interoperability, also known as USCDI, is a set of data elements specified by the Office of the National Coordinator for Health Information Technology to advance health information exchange.

Redox and others expect that the federal government could mandate that EHR vendors make USCDI available over FHIR, a standard for transmitting data used by application programming interfaces, or APIs.

“I think we all know that interoperability has been a challenge in health IT for a long time,” said Paige Goodhew, who does product marketing at Redox. “Things like this are great steps at trying to make some sort of a base expectation across the industry of what data can always be exchanged in a way that’s free and open.”

Goodhew recently spoke to Wisconsin Health News about the work.

WHN: What’s the need for this change?

PG: So one thing I will note is that it hasn’t been formally mandated yet. Everyone is expecting that with the final data blocking rule that USCDI over FHIR is what will be included. The reason for that expectation is that it’s a data set that makes sense because it’s based on the common clinical data set, which was designed to really focus on what’s the information that needs to be exchanged for patient care…the EHR association has really rallied behind that. So that’s why everyone’s expecting that this is what will be in that final rule, but it’s not formalized yet.

From a Redox perspective, part of the reason why we felt it was important to announce support for this was that it makes sense. Because we’re talking about data that is important for providing good patient care. And ultimately in the world of health IT and integration, that’s what we’re thinking about all the time when we think about the data that’s being exchanged.

WHN: How is this data being made available?

PG: The expectation is that it will be required that these are made available, expressed via the FHIR standard. So in terms of having that available, the EHR vendors at a minimum – I think that everyone’s kind of looking at that final rule to make sure that we understand the scope of what health IT products are required – but at a minimum, everyone knows the EHR vendors will be most impacted. So that means that they’ll need to support the FHIR resources that can provide this data and also have a way to implement those across their customer base. This is where things start to differ across the different vendors. There are some groups that use a more centralized API like Athena and Allscripts. And for them, what’s nice is that’s something that they’ll be able to release, ‘Here’s the USCDI on FHIR specifications.’ And because they use a centralized API, that essentially can be made available across their entire base as it’s released.

For other groups that have a more decentralized approach to how their EHRs are implemented and used, like Epic and Cerner, they’ll need to make those FHIR resources available, which Epic has already announced, which is great. But they’re also going to need to have a process to have those implemented across their customers. So for them, they kind of have a two-step process. They need the FHIR resources and then they need to make sure that those FHIR resources are enabled and implemented and available across their customer base. So there is a little bit of that challenge to overcome.

And FHIR is a really great step forward in terms of standards. But one of the challenges, and where there is still a variability that is produced, is that FHIR is kind of a standard that is made up of a set of recommendations of how resources can be used and what the format is for those resources. But each EHR vendor can still make their own decisions about how they’re implementing those FHIR resources. So what that means is that if you have an application, if you have a health IT product, and you want to integrate with the top 10 EHR vendors, which make up about 90 percent of the market, you’re looking at having to support at a minimum potentially 10 different variations of this data set. Redox, inherently, what our big goal is for our software vendor customers is to extract away as much of that variability as possible…so we provide a standardized format so that our customers don’t have to worry about supporting 10 different variations.

WHN: How do these regulations and Redox’s action fit into the wider discussion of interoperability? Is this a small piece of the puzzle or a larger piece?

PG: The USCDI data set, they’re small pieces, but they’re really important ones. Think about it as finding the four corners of your puzzle. You kind of need the four corners to anchor things and to start to create a picture of what is this going to look like and where do the pieces go. The rest of the missing puzzle though, which is kind of that bigger piece, is really the true adoption of industry-wide interoperability and strict standards.

In healthcare, we have standards, but they’re not really strict. I often say standards in quotation marks because we have recommendations with HL7 and with FHIR about how messages should be formatted and how data should be made available. But they still are very open to interpretation.

And each EHR vendor or different health data sources, like you have (health information exchanges) out there, you have (customer relation management systems) like Salesforce, you’ve got all these different groups that potentially are looking at these standards. They can make choices about how those standards are implemented and how they work with their products. And when you have choices like that, that’s where we start to lose on that idea of true industry interoperability. Because now everybody might be able to offer products that you can integrate with. But if you want to integrate with it, you have to conform to their standards. So if you start building in the needs to conform to individual systems, or in some cases even individual healthcare organizations that have customized their system, that’s where interoperability starts to get really hairy…And I think that there is something powerful about being able to set up your integration based on what your system needs and how you operate as a business, but that does pose a challenge when you need to work with other groups.

And that’s where Redox is really kind of trying to be that center piece of the puzzle, to kind of help everybody start to structure around and be able to operate both in what’s the best interests for their companies and their customers – like what’s best for their patients, because patient care is the most important thing that many of these healthcare organizations do – but still be able to easily integrate with other groups that they want to work with.

This article first appeared in the Wisconsin Health News daily email newsletter. Sign up for your free trial here.