On September 23, 2025, HealthLX and Flexpa came together to present their recent open source releases aimed at enabling vendor-neutral, standards-aligned translation of healthcare data into FHIR, specifically in the payer consumer data space.
Open Sourcing Payer Consumer Data: A Joint HealthLX and Flexpa Webinar explored the journey of consumer data from payer systems through FHIR implementation guides, introducing HealthLX's CoCo canonical schema and Flexpa's new reference documentation for CARIN Blue Button claims data.
Transcript
Joshua Kelly (Flexpa): Today's presentation is a joint presentation from HealthLX and Flexpa, and we're here to discuss some of the mutual efforts that we've both been making to enable vendor-neutral, standards-aligned translation of healthcare data into FHIR, and specifically the payer consumer data space.
So HealthLX and Flexpa are both here to present two recent releases that we've made separately, but that tell a story I think a little bit about the journey from consumer data inside of a payer system. Its origins in some of the older transactional HIPAA standards, how that data gets to FHIR, how it passes through implementation guides like the CARIN Blue Button IG and ultimately how payer consumer data can be useful in different use cases for claims data. HealthLX and Flexpa together have developed things that touch upon different parts of that journey and so today is really just a sharing of resources in the space.
And establishing I think a point of discussion for everyone who's working on payer consumer data. That's a little bit of an introduction to the webinar, but I'd love to and I'm proud to introduce Chief Strategy Officer at HealthLX, Tone.
Tone Southerland (HealthLX): Great. Thanks so much, Josh. Glad to be here. And just a quick note, if you have questions, feel free to drop 'em in the chat as we go. We are gonna do questions at the end. We'll get through both presentations and then we'd love to have your questions and entertain a little discussion at the end.
To follow on to Josh's intro, just a quick introduction for those who don't know us. We are an enabling company. We enable health plans to be compliant with CMS-9115 and soon CMS-0057. We are well invested in standards. We do interoperability. We have for many years. We're founding members of the Da Vinci Project. We built a couple of reference implementations there. And this is what drives us. This is what we're passionate about, right? We're trying to help health plans advance, not just to be compliant, but also to be fruitful, right?
So that burden can be reduced so that workflows can be more efficient and effective. And so ultimately patients can have better health outcomes. So that's what we're all about. One of the big challenges we've seen that Josh alluded to in the intro is that healthcare organizations and specifically health plans really face this challenge of fragmented data in their source. And it could be that the data models in their databases aren't structured correctly. Or it could be that the tools that they use to export that data for downstream use and consumption are not really up to par. And maybe they're limited on their ability to export it in a format that's semantically interoperable between systems. And we see this in our customers today, right? A lot. So these are a lot of the problems that we're dealing with for our customers. We try to solve for these problems, and there's really no unified field-level canonical schema across the industry to help manage this.
And this would be an intermediary schema, right? That sits in between the source data and the target, which is FHIR in this case. So it's any of the many FHIR IGs and profiles that are required or recommended for CMS compliance. And this creates a lot of costly integration barriers, right? And that cost could come in the form of needing to hire more implementation engineers that are specialized in the standards, which are not cheap.
It could come in the form of downstream, lack of patient care, right? If data doesn't flow through and the meaning of it changes in the transformation process, when it goes from source to target, which is FHIR and is available in the APIs, then we have significant risk of patients not having or clinicians not having the data they need to effectively apply care to their patients.
And so it's really just insufficient to drive standards adoptions. I've been doing this for many years in different verticals and healthcare and implementation is always harder than what it looks like from the standards standpoint because organization systems, people interpret standards differently, so that's a huge problem in the industry. And then how do you resolve those different interpretations? And you can do it through testing like HL7, connectathons through great and real world testing events. But how do you really take that and harness what you learn there and what you learn outside of those connectathons and real world testing events and drive it back into the standards organizations so that we can have a more seamless interoperability experience.
Introducing CoCo
So what is CoCo? So CoCo is besides the hair on fire CoConut logo we have here. We're really open sourcing our canonical schema and our canonical data elements. So we have a canonical schema that we use with our customers today. And it enables them to achieve compliance, right? Because they send us their source data, we map it into FHIR, and we're open sourcing that. We feel that it would be better if we shared that with the world. And for the, really, we have a few goals, and I'll go through in a minute, but really the primary goal here is to enable community behind it, right?
So we can create a channel that goes back into the FHIR implementation guides and the standards to help fix issues there that we find in real world implementations, right? If you look at the 10,000 foot view, that's really what we're trying to do with this. And just to note that this is, it's not just theoretical. This is something we use today. So we have error report. We have validation and error reporting built in that we, when errors come in, we report those back to our customers and they fix 'em and rent and repeat and try guess. So these are schemas that we've been using for several years. So there's some proof in the pudding here.
So the vision for CoCo is to democratize healthcare interoperability, and by healthcare we really mean payer but it's also part of the broader spectrum, right? If you look at what the federal government's doing, it's really driving payers, providers, and consumers all to be interoperable, right? So it really does broaden out into that broader healthcare interoperability focus. But the concrete piece of this right now is the payer regulation. So democratize healthcare interoperability by enabling vendor-neutral, standards-aligned translation of healthcare data into FHIR through a community maintained CMS regulations, open source, canonical schema. A bit of a mouthful, but you'll see some themes in there. Vendor Neutral, community Standard Salon. So it really gets to this idea that it's not about one vendor trying to succeed over another.
"It's not about one vendor trying to succeed over another. It's about how do we come together and solve the problem together?"
There's plenty of problems out there that we can all solve. And if we don't work together then it just won't work.
Goals of CoCo
So what are the goals of CoCo? One of our goals is to accelerate compliance. We want to provide ready to use canonical schemas that can shorten the implementation time for CMS rules, this could be for a startup. We want to reduce fragmentation. So the opportunity to replace one-off mappings with a community governed schema, and that goes two ways, right? So we certainly recognize that there's a lot of organizations that are well established and they have a canonical schema already, right? And there's no expectation that they're gonna, oh, adopt our, just 'cause we open sourced it and said it was great, right? Because they already have things coded to that map, to that. It all works, but it's about they have things, they have lessons they've learned, we have lessons we've learned so they can bring their lessons learned into the open source model. And therefore we all benefit. So it's that it's reducing fragmentation going both ways, if that makes sense.
We also need to enable innovation. It's not just about CMS-9115 many of you're probably familiar with 0057 and how it builds on top of CMS-9115 adds more APIs, adds significantly more complexity with also significantly more opportunity, right? To reduce burden across the ecosystem. So we need a way to move into that, right? So having this community governed and community driven open source intermediary schema gives us a way to do that. Then finally, and this is, I'll go back to this theme of community fostering community is extremely important. We really wanna build an ecosystem that has contributors that are contributing in different ways, right? Maybe it's contributing to some of the code base, maybe it's contributing in terms of conversation or feedback. So there's many different ways to contribute. And then that feedback then goes back, it goes both ways, right? It goes to health plans, but it also goes back into the standards communities like HL7, FHIR with IGs and profiles.
Features of CoCo
So what are the features of CoCo? I like to say FHIR tells us how to speak, but CoCo tells us what to say or how to say it. So you have the canonical model in the middle, and that canonical model has the capability to generate samples. So we have some code that will read the canonical model. It recurses through the model and it auto generates fake data. If you're familiar with Cynthia, similar to that. So Cynthia is focused on FHIR. And this is just focused on our canonical and samples or samples of fake data lead to testing and validation, right? If we can't set up some type of unit integration testing in our CI CD pipelines.
Then it's really hard to maintain quality, especially in a community contribution type of environment like this. So validation is part of this as well. Unit test, we're contemplating integration test and what that looks like like in an end-to-end flow. I'll touch on that a little bit more later.
And then the third piece here, the third feature here is documentation. So we all know that documentation is out of date the minute you write it and publish it. I'm a big fan of documenting the source as close to the source as you can. So we have some tooling that will do the similar thing as a sample tooling. It reads the schema files, it auto generates documentation and markdown publishes it in a GitHub pages' website. So this is another piece of the feature set of CoCo. So we really wanted to wrap, it's not just a schema. It's how can we think about how to use that schema to enable all of us to be better?
Use Cases
So what are a few use cases? So I'm just gonna run through these quickly. One use case could be a startup accelerator. As you're getting started in the industry, you're trying to build something you're thinking about everything else. And then the last thing you wanna think about is, what do I need from my canonical model? Or how, what do I pick? And this could be used as a component to jumpstart that, to get to a place of CMS compliant APIs faster.
Another use case could be testing and validation services, whether that's like internal, which is probably less of a use case and more just internal tooling. But the external use case is about how you could provide that as a service to customers. Like I know that's one challenge we're solving through right now is how do we provide better and faster feedback to our customers, right? How do we provide errors, warnings, and successes. And are there different levels of warnings? And what do those mean? In context of the FHIR profiles? There's a lot to translate and work through there in terms of mapping and translating from the source data into FHIR. So that's another use case.
And then the third use case here is education and onboarding. So this could be used as a teaching tool, right? With the community factor here of multiple inputs coming in and providing their experiences. We see this as an opportunity to teach others how to do implementations. Implementations are hard, right? And especially in a changing environment like we have where the standards are still almost finalized, but not quite right. I sit on the WGM where we're reviewing like, buckets of issues that are being approved for the next version of Da Vinci PDex or CRD or whatever the profile or IG is. So there's still changes that are coming that we have to handle that we have to account for. So that leads into continued education and onboarding lessons learned around that.
Value Proposition for the Ecosystem
So what is the value prop for the ecosystem? So payers, Health IT vendors and implementers can all benefit from this payers through faster CMS compliance. Integration costs can be lowered. We touched on that a little bit earlier about how the integration costs are high, right? So you have more efficient interoperability, you can lower integration costs ultimately leading to higher data quality and higher levels of data consistency. Which then leads to scalable partner onboarding. So we're not in a world where there's one system that's gonna rule everything. Certain parts of the healthcare ecosystem are that way. We're not seeing the payer system that way. There's a lot of different players in a lot of different systems. And so we need intermediaries to help with the communication between 'em.
Then health IT vendors, you can have a clear standardized spec. Really, this is an intermediary spec—and that's an important distinction. We're not trying to replace FHIR standards, we're really trying to compliment them, right? We're not trying to replace, necessarily any health plan source schema, right? We're trying to compliment it. We're trying to create a connection there to make things smoother. Health IT vendors also benefit from having some built in validation tools which can be a market differentiator. They can provide that as a service back to their customers. And then, the goal for that is to really future proof for new CMS rule changes as well.
And then implementers can recognize or get accelerated development, right? Because they can get the jumpstart interoperability out of the box. I don't think we'll ever truly be to a hundred percent interoperability outta the box, but we can get a lot closer. Josh, you've been doing this a long time too. Like it's really hard. > "It's really hard. And it is never gonna be perfect, but if we can get like 80 or 90% of the way there, or maybe 93 or 95, like we've achieved a lot."
And we can celebrate that less custom mapping work. And then there's that, community driven support focus again.
Enterprise Architecture View
So a quick logical view of kind of enterprise logical architecture view. Or maybe this is maybe more conceptual of what the flow might look like on data flows from left to on this screen. So the payer source data, these are actually the canonicals we have today. We have one file called roster, one called Provider directory. One called clinical, which has a whole bunch of clinical data in it of all different clinical sections. And then the claims are EOB we also have a formulary canonical. So these are all—this is the structure and the model—that the health plan or the payer source data is sent to. Canon, sent to CoCo in versus MA two, and then from there it can be mapped into multiple different FHIR servers. It can be mapped into an analytics server using an adapter like Snowflake. It can be mapped into a data warehouse solution or maybe even TEFCA, right? There's a lot of interesting conversations going on with TEFCA and coming out. I think it's February, somebody can probably check me. February 26th, I think. That's operations. That's not payers. Sorry. A different part of TEFCA. There's lot, lots of TEFCA but I know there's a lot of efforts going on with TEFCA to try to drive forward payer usage of TEFCA. How can TEFCA be leveraged to help solve some of the problems that payers have in terms of interoperability? So we don't wanna we don't want to pass on that one.
A slightly different view on the data flow. This is really more looking at the functional scopes. You'll see CoCo in the middle. It's really all about the schema and the model. Right now we have it in XML schema, so XSD. So when we release, that'll be what we release with we have JSON schema on the roadmap and we'd love to have somebody contribute that. Somebody who has experience in JSON schema is using that today. Maybe we could collaborate on that.
As data moves to the right in this diagram, you have transforms and outputs. So you could use XSLT for your transform, jQuery, python, whatever. And then your outputs will be your CARIN as mentioned earlier, US core or PE or whichever FHIR profile and IG is appropriate.
One note we also, we presented this at the HL7 Connectathon last weekend, and we got some feedback on why would you just provide the schema and not provide the transforms? And our response to that was this, we're, that's part of the secret sauce, right? But we started thinking about that and we started thinking maybe it makes sense to provide a transform for, say, the roster canonical. So we're contemplating that would allow us to collaborate as an industry to do an end-to-end flow. So you generate a sample file. You send it through that translator to have an output FHIR resource set of FHIR resources on the other end, and you can run those through the open source available FHIR validators, like Inferno or Happy or whatever. So we're contemplating that just as a way to say, okay let's get some more value out of this and show the end to end. It is important to know CoCo's not an API layer. It's really just, it's the schema and it's the tools around that canonical schema.
Standards Compatibility and Roadmap
Standards, compatibility matrix, this just shows what we support today. FHIR R4. We support US Core 3.1.1, which is part of CMS-9115. And then what's upcoming, of course, is US Core 6.1 oh for CMS-0057. That's in progress. We're working through those canonicals. Then in the future, prior auth and then TEFCA.
Quick development roadmap. So we're looking at what our how we're gonna license the IP. We're leaning towards like an Apache two oh license. We really want this to be open and available. We're in the process of refining a lot of these canonicals, just cleaning things up making sure they're up to date finishing up the tooling that's built around them.
And then we're planning for a public GitHub launch by next month—in the next four to six weeks. And then phase four would move us into community engagement. So we're planning on probably doing another webinar, maybe two by the end of the year, moving towards the end of the year to have a demo and look a little bit deeper into some of the things that we have.
And then phases five and six focus on contributor onboarding: what does it look like, how do you become a contributor? How are PRs managed? And then governance launches about, creating this technical steering committee so we have more formal roadmaps and that sort of thing. So we're pretty excited about this from the standpoint of building this up and really trying to do it, on behalf of the community. So that's it. So I've got, I won't read all this off, but if you wanna reach out to us and let us know and get on our list you'll have the slide decks after the webinar. So drop us an email. We also have a website, CoCo data.org and I think that wraps up my session and now we can dive into what it looks like from the implementer standpoint on how to navigate CARIN and the documentation that documentation tooling that Josh and team have.
Flexpa's Perspective
Joshua Kelly: Thanks so much for that overview. I think one of the pieces of that really stood out to me, and we've had this conversation for the better part of this year together is how payers are starting to think about delivering 0057 solutions, and in particular, the work that you have to do to make consumer data available in the payer patient access API inside of CMS-9115 today, and how that same data schema is now for the very first time going to be ingested in payer to payer exchange. And I thought the TEFCA reference there was also related in whether or not payers will adopt TEFCA as a network layer for the exchange. But that does bring us up to Flexpa and me.
Hi, in case we haven't met. I'm Josh, I'm one of the founders, and I'm the CTO at Flexpa. But, and I've spent a lot of time looking at FHIR implementation guides—probably too much time—including CARIN Blue Button and the consumer payer data set and the various CARIN efforts in this space. And I'll get deeper into that in a moment. Where Flexpa starts is really where that HealthLX story ends: at the moment of making useful this data that a payer has had to make available. So we're trying to tell the story of, okay, we had a lot of work to do as an industry to get to the point where consumer data is available inside of a FHIR API. What's the story after that? What's next? Because a lot of folks that I talk to, really look at, in particular in the payer space, look at interoperability purely as a cost center. Where's the opportunity here? Where's the member experience improvement? When are we getting to that part? That's an area and a question that I'm very interested in. What does Flexpa do?
Just very briefly, in case you haven't heard of us. Flexpa is obsessed with making patient access data useful, making patient-consented healthcare records easy to get, easy to use, and for patients easy to give. Historically that's meant we focused a lot on CMS-9115. You've probably, if you've heard of us before, you've probably heard of us inside of the claims context and we're talking about claims today, but Flexpa is really a three in one network of patient access. So we work on CMS-9115. We work on the ONC HTI-1 patient access APIs.
We announced today at the Commonwealth Fall Summit that we have become an IAS provider. So a little bit of a coincidence for announcements, but we are obsessed with patient access and we are obsessed with how to navigate the different consent mediums from IAL2 digital credentials, consent flows with CLEAR or ID.me, all the way to the payer OAuth login. So being able to log in and retrieve your claims history from a CMS-9115 API, maybe that's on medicare.gov through the CMS Blue Button API, maybe it's on a Medicare Advantage payer or State Medicaid and even some commercial payers. Shout out to Kaiser Permanente, the sort of largest broadly available.
All consumer patient data is available through their patient access API, and at the end of that, so we handle the consent, we handle connecting to all of these patient access networks. We make records available at the end, including a claims history. We make those records available in a standard FHIR API.
Two New Launches
So we are obsessed with the details of these APIs, including CMS-9115, and how to consume data out of them. It's something that we've been working on for years at this point. Two launches today that tell the story. We're making publicly and freely available reference documentation guides. So these are things that we've had to develop internally to understand the diversity of payer data because when you look at the end result of all of this process and look at claims data in terms of the FHIR ExplanationOfBenefit resource, for example, the story of how it got from its origin points in a CMS 1500 or CMS 1450, or UB-04 claim or NCPDP transaction.
The story of how it got from those data sources and how it's represented ultimately inside of the ExplanationOfBenefit really requires an in-depth understanding and research of that origin schema. And as we've worked with this data, we've had to develop resources independent of the great ones made available by the HL7 standards development process we've had to support ourselves internally in figuring out what is in this data. And we're making all of those internal resources available for free and public today on our documentation.
So there's two parts of that. There's a claims data guide, which covers more broadly what's in the claims data and how to get down to the level of health informatics with that question. And then the second is detailed CARIN BB reference documentation for the ExplanationOfBenefit. And I'll explain and show you. What that is and why that might be helpful. First of all, though: We've got claims data in a FHIR API. Why? What's it useful for?
There's a few ideas here. Flexpa has worked with all of these examples we've seen different folks using claims data for different reasons. In general, those stories boil down to things like care coordination, cost transparency, population health analytics, quality measurement of course, but also use cases that you'd think patient access would be helpful for—and it is today. That's clinical trial participation or legal record retrieval. Things that a patient wants to do. So they want to participate in a clinical trial. They want to help the law firm retrieve their records for the legal settlement that they're a part of. Claims data is extremely useful for these types of things.
Claims Data Guide
So we built a claims data guide from scratch, again to educate ourselves about what the heck claims data is and what's in it, how to think about it, and then also to prepare ourselves to answer, far deeper questions about it. This guide contains three broad components that help paint the picture of what is claims data, what is it useful for, how is it coded? What are the different types that lead you up to the point of being able to then consume reference documentation that is specific to the ExplanationOfBenefit resource. And basically this helps you get to the point where, yes, you can understand the difference between an institutional and a professional claim. What types of codes you'll see in either one, for example, or how a pharmacy claim is differentiated. So this guide takes you on the journey of individual patient and individual patient examples. And highlights the moments in those journeys when a coded medical event or healthcare service would happen, and ultimately how that would be represented in a claim.
Because one of the things we found is that claims contain such, such a rich, longitudinal sort of perspective on patients that a lot of the time, yeah, you can answer a question that you have by looking at claims data. You're just trying to piece it together in the right way. And then lastly, the guide is also an introduction, a little bit to medical terminology, to the idea of terminology and how those are used inside of claims.
So if you want to give yourself a 101 level coder course, a medical coder course, this claims data guide probably gets you the pretty close to the starting point, at least of that career option. So we'll dig into this and I'll talk through the first sort of highlighted story, which is Sarah's story.
Sarah's Story
And this is an example of one of the three journeys in the claims data guide. And these are all illustrated by specific examples. We'll start with Sarah's story. Sarah's story is representative of a physical lab appointment. So Sarah arrives at Dr. Martinez's office. They have a 45 minute physical exam. They discuss health goals and she gets some routine lab work ordered. During that visit, we can represent the visit itself with a CPT code.
We've all heard of CPT codes, I'm sure. At this point that's also known as a HCPCS level one code. We can also represent it as an ICD 10. Yeah, and we might also attach other sort of metadata about that visit, like the place of visit. So a place of visit code, for example. The claim itself is submitted by the provider, so that doctor's office, they submit the claim. The claim has over 30 different individual fields describing every aspect of the visit, right? In this case, it's submitted for $350 as a submitted amount. In addition, this claim contains really a really important piece of information, which is the NPI for the submitting provider. So we've got the Dr. Martinez here. That claim is processed almost instantly. There's a deductible applied. There's a payment approved amount is classified as in-network or out of network. A sequence of policy decisions are basically enacted at this moment of adjudication. And then ultimately that claim joins millions of others.
It joins millions of others in a de-identified claims data set or data warehouse that can be used to do, population health or quality measures or other care coordination activities. A pretty straightforward story, I think, but it highlights this: This happens hundreds of thousands of times a day. This very straightforward claim highlights, in a timeline sense, the important coded events that might happen during the course of a claim. So how does that relate? This claims data guide, and we'll share the link for it as well.
CARIN BB Reference Documentation
How does this relate, and what does this lead us up to as far as getting access to the ExplanationOfBenefit resource and understanding how these elements are actually represented? A really good starting point for that is actually in this CPT code and place of visit. How do we go to the ExplanationOfBenefit resource and find where this code appears, where that place of visit code appears? I think maybe that was one of the very first questions that I was ever asked about the CARIN BB profiled claims data. Does it have CPT codes? That might have been literally the first data-level question that was asked about it.
When first touching it, looking at it, or working on it, the CARIN Blue Button IG is, like all HL7 IGs, formatted in a particular way, has a particular manner of speech, particular vocabulary, even a particular interface—it can be difficult to navigate and understand. How to map that to the question: where do I find the value set? That might help me answer that question where's the value set binding, which element of which com, which profile might actually have this data?
So the second part of our release today is what we were discussing here. Brand new reference documentation hosted on flexpa.com/docs for the CARIN BB ExplanationOfBenefit. This is a from-scratch reference document that walks through in detail the most common 80% of the elements that are profiled in the ExplanationOfBenefit resource by the CARIN Blue Button IG.
So at a high level, we break down the EOB into three primary claim types. So we have institutional, professional, and pharmacy claims, and each of those claim types further breaks down. Of course, the institutional claim type breaks down into both inpatient and outpatient institutional profiles.
But we try to give a sense in this reference documentation, just in general, Hey, what is an institutional claim? And then also, what are the important terminologies and codeable concepts that are typically associated with an institutional claim. One of those might be the point of origin or type of bill code DRG codes present on admission codes in addition to the, expected CPT codes or ICD-10-CM codes. These are codes that are present on the CMS 1450 standard or the UB-04 standard. But trying to map those up is quite difficult, especially with the available documentation in the implementation guide.
So this reference documentation walks through every element that is unique to the institutional claims profile. So let's go down here. So we have diagnosis, which is a codeable concept, and we highlight here the available systems that are part of the value set binding for the diagnosis codeable concept. So here the type can be marked as principal, admitting, other, external cause of injury or patient reason for visit. That's a pretty straightforward example. Here's another one here where there's a binding on the diagnosis, codeable concept itself. And there's a binding to either ICD-10-CM or ICD-9-CM. And we explain that there are two possible systems here with example codes.
So this is structurally very similar to a FHIR implementation guide and is in fact based on the FHIR implementation guide and derived from the FHIR implementation guide, but it expands in usefulness by including example codes in particular as well as rewritten narrative on every individual element, and that rewritten narrative is not normative narrative. Flexpa has no normative definition for these things, but these are narratives that we've developed based on our real world understanding of how people are actually using that particular element.
In reviewing we've made over 200, or I think it's over 300 different payer connections at this point and seeing 300 different examples of how an institutional claim can be represented. And we've taken those lessons and narrowed them down all the way down to the individual FHIR element level to provide descriptions of how these things are actually used. So another good example here for institutional would be the on admission codeable concept. This actually comes from the CMS 1450. It's the field 67 present on admission. And by stitching together the narrative from CARIN BB as well as independent research and sort of network analysis we've done, we've basically put together a dictionary, if you will, that acts as a compliment to the normative standard and the implementation guide itself.
So really, who is this useful for? It's useful for anyone who's consuming data from a CARIN BB API today, and that today means CMS-9115, but in the future for payer to payer exchange will also mean 0057 payer to payer exchange APIs.
"Flexpa has, in some sense, seen the future of what you will see if you are going to consume CARIN BB profiled claims data from payer to payer exchange."
We see that today from our perspective on patient access. So this reference documentation is designed to navigate it in the way that we wish would've been provided when we got started. So that's a little bit about the two launches today.
There's one more thing. And just highlighting again, there's institutional claims, professional claims and pharmacy claims in this reference documentation.
SMART Health Links API
There's one more thing though, which is SMART Health Links. As a sort of secret bonus, we've also launched a SMART Health Links API. This is a fully featured SMART Health Links API. We're gonna do a larger sort of announcement, but you're hearing it here first, that we have released a SMART Health Links API that can be used to create QR codes for any FHIR data. You can bring your own keys or you can trust us to handle the encryption for you. We support passcodes, we support the entire spec end to end. And so if you're working on, for example, a digital insurance card project, we'd certainly love to talk to you about it and how to get those into the hands of real people. Here's a couple emails if you want to ask additional questions after this, and we don't have the time to get to your question, happy to receive it as a group at partnerships@flexpa.com. Or you can always email me individually at josh@flexpa.com. Thanks so much.
Q&A Session
Tone Southerland: So we'll take some questions. I think we have a few in the chat. The first question was from Scott Marsh. I responded to it in chat, but happy to continue the conversation here. Scott, you're asking about the process for vocabulary normalization, semantic disambiguation of concepts, and this CoCo model. How do you see this compared to the work Tuva is doing? Complementary or competitive? I'm not familiar with Tuva, so maybe if you could highlight what Tuva is. We could dig into that a little bit. Any comments there? Scott, if you wanna come off mute.
Scott Marsh: Yes. Tuva is a similar open source approach to democratizing access to data. They have some of their own project models, data models, and have different modules that do things like the vocabulary normalization was one of the things I was thinking about. Testing terminology sets extensions to those terminology sets all based on care and FHIR and some other standards.
Tone Southerland: Okay. We're not, right now, we're not really looking to do that. So I think we'd look to maybe, take advantage of that or leverage what's already been done. We're, we really wanna stay in our lane of working directly with the canonical models and trying to enable testability, enable sample generation and collect, collect feedback from the community to feedback into the standards. But I think it's a great, yeah, thanks for bringing that up.
I threw another question there, and it goes back to that question about semantic disambiguation because and Josh, you were talking about present on admission as an indicator in the FHIR data. The problem that I've seen sometimes is the semantic meaning of that is different depending on the organization. Some might take, for example, present on admission to mean it was a diagnosis that was present with the patient before they arrived to the facility. So if they were triaged in the ER and eventually admitted—the diagnosis means to that specific hospital organization that it was a diagnosis that was present before they were seen either in the ER or admitted. Other organizations, other hospitals consider it before they were officially admitted—if it was a diagnosis that developed in the ER before admission, some people will flag that as a POA and some won't. And that's the kind of thing—the meaning of present on admission within the FHIR specification has a standardized meaning, but the application of that standard is very nuanced by organization. Wondering if Flexpa is starting to look at maybe identifying the semantic differences based on their experience in capturing all this FHIR data from a variety of institutions to say, here's what we're understanding from this, the semantic meaning of this field from one organization versus how it might different from differ to another.
Joshua Kelly: Definitely, that's ultimately the origin of this effort—trying to do that. The place of admission is almost a best-case example, so I'll highlight a couple of worst-case examples for folks. But it's a best-case example in the sense that at least the place of admission is part of and clearly defined in the UB-04 claims data spec. So if you go and buy the AHA data sheet for UB-04, you can go and look what I think it's FL 67. I think that's the right one. You can go look at what that field code definition is supposed to be. So there is an external reference, but it's still a best case in the sense of at least it's a common field that has a commonly accepted external definition. That external definition is not necessarily clearly available or referenced in the FHIR IG itself. And I think there are understandable licensing reasons for that. But the worst case examples I think are actually the adjudication codes, so exactly in the financial adjudication code. Exactly what we mean by "submitted"—I can tell you from firsthand experience in the standards development process for that particular value set—is pretty hotly debated. People disagree about what exactly we all mean by the submitted amount. So I think that there's something there is definitely a worst case scenario there that we have spent time dealing with that we will continue to be as transparent as possible in, in sort of network analysis level. Because I, I think there's a lot of shared value in publishing information about it.
Tone Southerland: Yeah. Scott, just to piggyback on that a little bit, it's a great question. We're all taught that semantic interoperability is our goal, right? But you're bringing up a point that semantic interoperability has variations in lots of gray and based on the context. And one of the conversations we had at the HL7 Connectathon when we were talking about CoCo, somebody came up and said, 'Hey, what if we used FHIR metatags to indicate the intent of the data, as a kind of way to communicate between canonical somehow or real world implementations, as a non-normative way?' So the metatag is used to describe the payload, but it's not normative in the sense of here's the value set that's required or recommended or whatever. I don't know exactly what that looks like. It's a bit of a non-answer, but it's an interesting problem space and those are the kind of things that, that we want to dig into as we explore this.
Joshua Kelly: We had another question from Mark Roberts. Just to be clear, the CARIN BB IG is not normative. It is still an STU 2.1 0.0, and I'll just correct what I said. I did say normative. What I meant was, of course, just that the reference documentation that Flexpa has written is not part of the HL7 standards development process. So we're not an official release of anything. But yes, it's KBB is correctly still part of trial use, a standard for trial use. And I think we got Scott's sort of second question there. There was another last one for me, I think, and then we might be at the end of the questions. An open floor.
Tone Southerland: Josh, can you briefly talk about your IAS announcement?
Joshua Kelly: Yes. So Flexpa has become and is becoming a TEFCA IAS provider. We announced this today at the Commonwealth Fall Summit. Basically we've joined a QH and we've signed agreements with two identity providers, so two CSPs, and we hope to provide CCDA documents on TEFCA through Patient Access Exchange within a couple weeks. So we're getting ready to release a new patient access flow to support that. And on that note, we're very excited about the prospect of payers, of course, joining TEFCA. I think that would really enable even more data exchange of this sort.
Joshua Kelly: Maybe a question for you, Tone. Having launched CoCo at the HL7 working group in plenary, what was the reaction? Did this, does this connect with a lot of folks? What did people think?
Tone Southerland: Yeah, we had about 15 to 18 people in the room. We had a separate breakout room and it was Will and I announced and it will's our owner of our company and it was really a discussion. We had 30 minutes scheduled. We were in the room for an hour and 15 minutes. And there was a lot of a lot of my industry colleagues were there. A lot of people that are experts and various different organizations and projects they work within asked a lot of great questions. Some supportive, some challenging, which is great, and like I think I mentioned earlier, one of the feedback points we got was we'll release the transforms too. And but that's great. Let's talk about it, right? And figure out how that works. A lot of questions about whether this competes with FHIR, or questions that kind of alluded to that. So we got some clarification around that. In an ideal world, it wouldn't even really be needed, but we don't live in an ideal world, and I don't think we ever will because of the complexity of things. And yeah, it was great. It was great engagement and we're excited about it.
Joshua Kelly: Looking a little bit forward, what do you think? There were different types of barriers to adoption in the development of CMS-9115 and the release of payer patient access APIs, the provider directory API, and pharmacy formulary APIs. What do you see and what are you seeing from the HealthLX perspective on the CMS-0057 APIs?
Tone Southerland: Yeah, it's a paradigm shift, right? Because you're moving from just straight ingestion to orchestration. You're, you have a lot of workflows when you start talking about the payer to payer. It's not just about making data available in API, so somebody consume it. It's like, how does that, what's the life the life of that data, right? And the life cycle of that data as it moves between systems. And this kind of gets back to the point Scott made earlier—as it moves between systems, does the semantic interoperability stay intact or not? So that's how we're looking at it, and we're also looking at the landscape in the health plan space. We have folks that have been doing this for years in our organization and are well versed in it. And it's complicated and it's messy, and like CQL is a great path forward, but it's not gonna be available on day one for all these rules. And just to communicate with the rest of the health plan, payer prior authorization space. And so there's gonna be, we foresee a lot of orchestration needed and a lot of translation and transformations needed at diff, not at one part, but like different parts in those workflows.
Joshua Kelly: Do you think that the message of the payer to payer exchange being the sort of the first opportunity to get clear business value here, do you think that in comparison to seeing the other interoperability efforts as more of just cost centers, do you think that message is being heard? Do you think that's do you think that's becoming a common view? Or are people maybe moving a little bit slower or dragging their feet?
Tone Southerland: I'll answer from our standpoint, not necessarily from the whole industry, because I think if you ask different health plans that same question, they're gonna have different answers depending on where they are, depending on how large they are. A lot of our customers are not really understanding the value yet. They're starting to see it but they see it as a compliance thing. But that's also not, this isn't unusual, right? I did EHR stuff back in the meaningful use days, and it was very similar in that, our provider organizations didn't wanna do meaningful use. Some of 'em, in fact, opted out of it. They said, we're not gonna do it. We'll just pay the penalties when they come. Whatever, it's not worth it. Or, our Medicare population ain't big enough to worry about it. We're not making money on it. But it was a lot of extra clicks. And those early implementations were clumsy, right? And we had to refactor and as an industry and iterate over that and make those workflows better, those interoperability workflows better. And as they became better, things became more smooth. And then the value started to be seen. So you have to, you gotta escape to where the puck's going. And that's really what we're doing right now, right? I really, I what we're seeing is a parallel.
Joshua Kelly: We're seeing the parallel maybe to that in terms of there's so much direct possibility. I think there's a possibility that we will flip from prioritizing these efforts as just a compliance checkbox into something that's maybe more about member experience, that's about patient engagement, that's about driving value-based care outcomes. All of these kinds of things that sometimes sound maybe futuristic from a business perspective—hey, we've been hearing about those types of things for a while, but how are they becoming real with interoperability efforts? Payer to payer exchange is a real way, and I think it's hard for people in the position of a payer, it's hard for the payers today to exactly see this yet. But Flexpa, and I think together with HealthLX, we've seen the shape of how to get all of this. We've seen how to shape this data into FHIR and we've seen what it's gonna look like. We've seen how we're gonna represent the institutional professional and pharmacy claims and how those get transformed ultimately into different FHIR resources. Not just individually in the times that, Flexpa has integrated with a HealthLX payer. But with all of the variety of implementations that we've seen in production, all of that kind of knowledge—payers are gonna see that landscape soon. They're gonna see those data differences. Yeah. They're gonna see the canonization problems. They're gonna see the sort of documentation issues or gotchas that have been produced. And I think we're about to see—we hope and we believe—a lot of renewed interest in claims data in FHIR, in these APIs, and in the way that these APIs are going to be reused for payer to payer exchange. I think that's something that we just think is gonna be a big unlock and yeah, basically transition interoperability from just being, the cost center that we're doing it just to check the box into something that actually can change outcomes and drive and drive some change.
Joshua Kelly: Thanks for the amazing connect and introduction to CoCo. Looking forward to using and exploring it.
To watch the full webinar recording, register here.
