For years, payers have built their data strategies largely around claims, a valuable source of information about cost, utilization and patient activity. But claims alone provide only part of the picture. Bringing clinical data into the equation can give payers a more complete view of patients and populations, helping uncover insights that would otherwise remain hidden.
Realizing that potential requires more than connecting additional data sources. It requires an interoperability strategy built around a rich, longitudinal view of each patient.
Becker’s Healthcare recently spoke with Mike O’Neill, CEO of MedicaSoft, about what it takes to build that foundation and turn more connected data into actionable insight.
Editor’s note: Responses have been edited for length and clarity.
Q: Payers have been investing in data infrastructure for years. What has changed about what they need from their infrastructure and where are existing systems starting to show limitations?
Mike O’Neill: The problem isn’t really that payer infrastructure has failed. Requirements are now outgrowing initial architectures that were built around claims data. Claims are tremendously valuable. But increasingly, payers need to supplement that with clinical data that tells you not just what care was executed, but what some of the results were: lab results, clinical documentation and whether medications were actually picked up.
What they have today isn’t bad; it was just designed in a different environment. You can build something for each new use case, but over time, that ends up with a really complicated architecture.
A better solution is a common, longitudinal data foundation that combines claims data and clinical information and makes it available consistently across all those use cases. The HL7 FHIR standard gives us a really good data model for implementing this kind of architecture.
Q: FHIR comes up in nearly every interoperability conversation, often in the context of meeting a requirement. How do you think about the difference between supporting FHIR as a standard and building on it as a platform? Where does that distinction show up for payers?
MO: Often what it means is that FHIR has been implemented for compliance with a CMS or ONC regulation. That’s not a bad thing. You have your existing systems, you transform some of that data into FHIR format, you share it via an API and that meets the requirement.
But that’s how you end up with FHIR at the edge of what you’re doing, like an interface problem.
What we do at MedicaSoft is use FHIR as the underlying data model. We normalize clinical and claims information from different sources into a common FHIR-based representation and maintain it that way.
That’s the distinction between being FHIR-compatible and being FHIR-native. In one case, FHIR is primarily an interface for exchanging data. In the other, it’s fundamental to how you organize, store and use healthcare data.
Then you just go to your longitudinal data and ask your question, instead of first figuring out what system that data probably came from, what its unique format is and how to join it to your other data.
Q: Can you provide a practical example of something that payers can do differently when claims and clinical data are organized into a common longitudinal member record?
MO: Quality measures are one where it’s easy to see the difference. Let’s say you’re evaluating how a practice performs treating patients with diabetes. Claims data can tell you whether a patient has been diagnosed with diabetes, whether they saw a provider and whether certain laboratory tests were performed. But clinical data tells you the actual results of those tests, such as the patient’s A1C level and how it has changed over time. But you need the clinical data to tell you what the lab results were, whether that’s an A1C reading in a certain encounter or the trend over time. The quality measure is more accurate and usable if you can supplement the claims data with clinical data. As quality measurement becomes increasingly digital, having both claims and clinical data organized in a consistent structure makes it much easier to calculate measures accurately and efficiently.
The right data underpinning is the thing that helps you to do this efficiently. Without a common data foundation, each application has to do much of the same work: collect data from different systems, reconcile it and assemble a longitudinal view of the patient.
If you organize that information into a common longitudinal record, you solve much of that problem once. The same data foundation can then support quality measurement, care management, identifying gaps in care, population health analytics and even prior authorization.
Q: Prior authorization and other coverage decisions increasingly depend on clinical information that may sit outside of the payer’s systems. What does a payer need from its data infrastructure to make those processes more efficient?
MO: We look for data infrastructure to reduce the need to chase down clinical documentation and clinical data, not to automate the clinical or business judgment that gets made in something like prior authorization. The payer often needs to know not just that a certain therapy was tried, but what the results were, what medications were ordered and how lab values changed over time, to see if the procedure is really the best next step in treatment.
That information exists electronically, but it’s usually distributed across multiple systems. The payer will often have to make individual queries, it still happens a lot these days by phone and fax, to pull this data together. This is where interoperability and data infrastructure can help, by organizing that data into a clinical record.
That reduces administrative work for both the payer and the provider, helps avoid unnecessary delays for patients, and allows the people making coverage decisions to focus on evaluating the clinical evidence rather than chasing down the information.
Q: Looking at the next two to three years, what should payer leaders do with their data architecture now to prepare for where interoperability, analytics and AI are headed?
MO: I would focus less on trying to predict what the next application is and more on making the underlying data truly usable for whatever comes next. We’re going to continue to see new requirements, more automation and all kinds of experimentation with AI. The common thing across all of those is that they depend on data.
AI can do remarkable things with healthcare information, including extracting useful information from unstructured clinical data. But AI doesn’t eliminate the underlying challenge of fragmented healthcare data.
To get reliable results, you still need to understand the structure of the data, its clinical meaning, where it came from and how trustworthy it is. That’s why a common data architecture, with appropriate governance and data quality, becomes even more important as organizations adopt AI.
The investment I would make over the next couple of years is creating that standard longitudinal data layer that separates individual applications from the complexity of the underlying data.
Our objective at MedicaSoft isn’t just to help organizations exchange more healthcare data. It’s to help them get that data organized, so they’re actually ready to do more with it as applications evolve. The next challenge in healthcare isn’t simply getting more data. It’s making the data we already have usable.
At the Becker's 5th Annual Fall Payer Issues Roundtable, taking place November 2–3 in Chicago, payer executives and healthcare leaders will come together to discuss value-based care, regulatory changes, cost management strategies and innovations shaping the future of payer-provider collaboration. Apply for complimentary registration now.
