Introducing the CommonWell Marketplace: Advancing Interoperability and Data Quality

Stephanie Broderick:
So we’re going to be talking about the CommonWell Marketplace and Advancing Interoperability and Data Quality. I’m Stephanie Broderick, I’m the SVP of Provider Solutions at Clinical Architecture, and I’ve been working with CommonWell Health Alliance and ELLKAY for the last six months on what we’re going to be sharing with you today.

Paul Wilder:
Good afternoon everyone. I’m the person on the left, Paul Wilder, Executive Director of CommonWell. We are a very large data network made up mostly of EHR vendors that share data with each other through our platform about, let’s say a hundred thousand provider sites, 300 million people or so, represented about a billion documents a month or two. It’s a lot of scale and we’re going to talk about today is bringing that scale to the market for things that Interrupt doesn’t do well today to make it better. So, oh, I have a clicker. Clicker. Alright, so we’re going to go over, I’ll start talk a little bit about what our vision was and kind of how we got to where we got to, got to ELLKAY will talk a little bit about the how and what it does, and then we’ll go back to clinical architecture, talk a little bit more about the first thing in the Marketplace, what it does, and go from there.

So first of all, this is brand new. Kind of announced that yesterday. Today. Today, today’s Tuesday. It was today because anybody tired yet? This is a rough conference people, I feel like it’s Wednesday already, so we’re going to make it. So yes, we announced that today that we’ve opened the Marketplace. Now what’s the Marketplace? Why? We have a lot of scale and the reality is there are many vendors you go around this hall that are not yet connected, not sharing and not using data well, but you go around the hall, you also find a lot of vendors that are doing really neat things with data and want to bring those two worlds together. So people that have tools and people that need tools and allow it to happen at scale quickly. So the first use case is related to this problem. First of all, it’s very small type.

That’s not the problem. The problem is on the left, this is the universe of the normal set of inpatient documents that are shared from an inpatient system. So you have discharge summary, HMPs, progress notes, right? Okay, cool. Individually provided to a provider. They tell a story or a portion of the story they’re trying to tell, they’re great. The problem is when you do interop, you’re trying to make a machine understand this stuff, right? So a discharge summary is great for a provider to get a one paragraph overview of what occurred and what to do next. Great. How does a machine read that thing and then deal with all the rest of the content that came. And here’s an example. How many, you might see this right hand side chart, a little hard to read, but there’s different document types at the top. On the left is the kind of elements that are in it.

By the way, it’s actually a whole nother screen of this. This is not the only elements in it, but it’s just an example. The first line, you’ll see all these Rs, RRR required, required, required. That’s allergies. If you get that data set on the left, every one of those documents going to have the same allergies in it, you’re going to get that 20 times and then you’re going to get it from another provider. Practice your allergies don’t change that often. You’re going to get the same 20 things again when you hit a network like ours and get 120 documents for one patient in one click, you’re going to get the same thing repeated over and over and over. And allergies is easy. It’s kind of easy to de-dupe that you’re allergic to dust mites. Great. What about medication, right? So it’s a hundred milligrams of x, I just got it 120 times.

Are they taking 12,000 milligrams or is it just one de-dupe? All that stuff. How do you organize the data? And the reality is the earlier vendors to interrupt, most of them have these tools already, right? They’re absorbing data, they’re duping it, they’re normalizing it, ingesting it, presented in the workflow, but there’s only a couple of those and some of the early ones didn’t develop it. But there are a lot of tools that can including Clinical Architecture. That’s why we’re here today. So we want to make that data easier to use. Think about, I’m not sure if anybody has done this. I recently had a telehealth visit and I clicked a little button and the first part of the telehealth visit was me reconciling my own meds. I spent four minutes before I gave up and said reconciled. And then the provider came over said, you’re taking 250 meds.

I said no. And I said, let me tell you verbally the four that I am, and that’s it. But I had screen after screen. So think about that. You’ve seen it yourself. We have to organize the data to make it more efficient, both for providers, patients, and everybody else. So you key benefits are transform CCDA to FHIR, FHIR to CCDA, whatever it is, changing the format, the function, the payload version. But the big news is, and that’s the general Marketplace theory. So that could be I need a transform for a payer. Payers want data in a different construct than a treatment provider or I want to simplify it. The idea is not this one use case, it’s any tool out there that we can inject into the process of getting data from other parties, whatever that is. Permissions, consent, data, transform, simplification.

So to do it, how do you get involved? If you’re one of those members, one of those vendors that has cool tools, call us. Hi, paul@commonwellalliance.org. We are a membership organization. We’re a trade association 501(c)(6) in case you want to look up the tax code. And so everything that connects to our framework and does work either for others or for themselves is a member. And from there, your access to the Marketplace is kind of a baseline technology fee to be part of here and then rip at it, right? And we’re talking about lighting up tens of thousands of endpoints. Think of the sales channel that comes from, I have a tool, how do I scale it to all of this in one shot? And that’s the goal. So we’re pretty excited about this and my board is ridiculously excited about it and we look forward to more entrances and really look forward to our first being clinical architecture. And we do appreciate, she said six months. That’s a serious lack of exaggeration. It’s actually been about six years. So clinical architecture has been a member of the alliance for years at the edge trying to figure out what to do, how to help. And we finally said, we got an idea, let’s put you right in the middle. So we’re thrilled to have you as a partner for all these years. The last six months was the part to get the final bit done, but it’s been a fun ride. So thank you.

Stephanie Broderick:
I-

Paul Wilder:
Kind of did that part.

Stephanie Broderick:
Oh, can I throw in a question?

Paul Wilder:
No.

Stephanie Broderick:
It feels fitting. I was going to ask you anyways, but it feels fitting right now. So as you said, we’ve been a member of CommonWell Health Alliance for years and years and years and talked about the concept of opening up the envelope and uplifting the quality of the data. And the answer was always no. Why now? What’s different?

Paul Wilder:
Stroke of genius.

G.P. Singh:
Because of ELLKAY.

Paul Wilder:
Well actually that’s an important factor. So when you change partners, different opportunities emerge, right? And we are in the middle and we’ll say the end of converting from a legacy platform over to our ELLKAY partners platform and it opened up the opportunity to add things that we could not add before. We’ve actually been talking to clinical architecture for years, more about measuring the quality of the data. The reality is all that stuff I showed, if you go back here like all this, there’s a chart of what you’re supposed to do. The how not exactly consistent. So what we wanted to do is help our members and their customers know what their own data look like. You don’t tend to look at the data you give to someone else, it just happens automatically in this kind of scale. So we want to say the quality of your data is great or not great and what you can work on.

And that goal still exists, I think we’re still going to do that. But when we flipped it and said, wait a second, what about the data you’re getting? Because let’s face it, that is the data you’re more interested in. What can I work with versus what am I giving out? We’ll fix both sides and make ’em both better. But in talking and going through the Clinical Architecture like wait a second, you have a different tool. We can do this real time, we can do it in volatile memory, we can do it in line to exchange and we have a better partner to do it with. So the timing just added up and PIVOT exists. So it’s awesome.

Stephanie Broderick:
That’s great. Okay.

Paul Wilder:
I’m off.

G.P. Singh:
Alright, can you guys hear me alright? I am going to stand, I speak better when I’m standing. So my name’s Gurpreet Singh saying also known as G.P. Some people also call me Terminator. I’m the VP of Interop Solutions at ELLKAY. All things interop have my hands in it from a business perspective. And really ELLKAY is a company that’s been in the forefront of interoperability and data management for a long time. And as Paul pointed out, we are the technical service provider for CommonWell, which basically in short means that we are the infrastructure and the technology on the backend on which CommonWell really runs. And as Paul pointed out, the first problem that was being solved through CommonWell was the fact that look, there’s got to be access to data. Data has got to be exchanged. So now the good news is that there is data and it’s coming from a lot of places out there.

And then obviously it made sense to answer the question that Stephanie was asking why now is because the data access is the first part of the problem. The second problem is now saying, okay, we have the data, but how do we add value and usability and really make it worth it to get that data? Because there are lots of organizations that actually say that, look, we are getting a lot of data now our problem is how do we make it better? How do we get insights? How do we make it usable? And that is the concept out of which we’ve got the CommonWell Marketplace that’s been created out of that. Everything is about member experience. So all my slides, I’m not going to get into the technology aspect of it because I do a horrible job at it and it’s not something that I think we want to discuss over here.

We’re obviously providing the backend services for really enabling the Marketplace, but it’s all about the member experience. How can we actually get everybody that’s looking for value added services on CommonWell to really be able to find them quickly, to be able to navigate to them quickly? Obviously that’s an important part. So you should be able to, the idea is that you should be able to browse, you should be able to search, you should be able to look at the Marketplace and really be able to find any sort of value added services that you’re looking for from there. And then obviously for folks to be able to connect to those value added services. So let’s assume clinical architecture, not assume they are in the Marketplace. And if somebody wants to be able to connect to clinical architecture, it’s got to be really simple. So it’s got to be the ability to go ahead and really accept and activate a service for a customer that buys into the value added services.

So that’s an important part of it. So the ability to enable and configure is been paid a lot of attention to. We made sure that that’s going to be friendly, it’s going to be quick, it’s going to be something that doesn’t require a lot of handholding and doesn’t require for folks to really have to get a computer science degree, be able to turn that on. So it’s got to be simple from that perspective. And turnkey zero development adoption for members, right? Zero development adoption is a big phrase that everybody talks about and is important to a lot of folks out there. So that’s something that’s important. And then if somebody is on CommonWell, they shouldn’t have to actually go ahead and add new API calls or new parameters that need to be added in. It should be the same methods of getting the data or being able to interact with the value added services. And that’s part of the member experience. You’re seeing this thing around the extension point call, right? And that’s an important part that we’ll talk about a little later. And then how does the data come in and how does it get enriched and enabled is where the entire workflow sort of interacts, right? Paul, do you want to add something to that or

Paul Wilder:
Yeah, what’s important here? The extension call is interesting. The part on the left already existed for years, right? That’s CommonWell we’re getting data. All we’re doing is in the normal flow, literally zero code, the vendor who connects to us says, I want to do this too. I want get this in enrich data format and we automatically inject it. So from today to tomorrow or now to five seconds from now, the whole service changes. Instead of getting 30 documents, you’ll get 31 and the 31st document’s going to be this normalized fancy thing that is much easier to work with. So the idea is zero code development, every member has access instantaneously.

G.P. Singh:
And that’s actually critical, right? Because this hasn’t happened in the network industry for a long time. Is data coming from there? What about 250 million patients out there that are available through CommonWell? The record locator service exists. The EMPI exists now we take this to the next level is to how to make it usable, how to provide value added services that the end users want to really be able to have meaningful insights to really be able to impact care at the point of care. So that’s the idea over here around that. And the initial use case is about document exchange. That’s what we’re doing. And obviously everything is compatible with FHIR and HCA, I won’t get into all of this, but I think you get the idea around the high level perspective around the fact that the Marketplace is all about member experience, zero development to be able to really enable you to go ahead and work with a Marketplace vendor to be able to get enriched data and capabilities available through that.

The first member is obviously clinical architecture and they’re a very valuable member of the CommonWell community and really being part of the entire Marketplace. And I think the services that they’re offering are going to be really valuable to a lot of folks out there. And then they’re going to be more members that get added on to the Marketplace and it’s all about any Marketplace vendor that’s coming on and it’s got additional functionality and how do they reach out through the extension point and really are able to provide that value to the end customers of there. I try to have it in a concise manner, basically not get you lost in all sort of technical jargon. The idea is that Marketplace is all about ease of use, value added services that you’re looking for, the ability to find what you’re looking for and the ability to go ahead and connect without having to do a lot of new development from that perspective. With that, I’m going to turn it over to Stephanie. Stephanie, over to you.

Stephanie Broderick:
Thank you G.P.. Thanks Paul. So what I want to talk about now is what are we actually really putting into the Marketplace? So you’ve heard Paul and G.P. talk about Pivot and so I’m going to talk a little bit more about Pivot and what Pivot does, but I want to talk a little bit more about the problem. And this is kind of a busy slide, but I think you get the point. It’s basically information overload, right? Causing cognition issues, physician burden. And I wanted to recount a story that I heard at this last year’s NCQA conference. I was listening to another talking about an experience where she had a physician call her and say, you just delivered a 270 page document to me for a patient and that patient’s going to be here in 10 minutes. What exactly do you expect me to do with this? And to me it really hit home the challenge around this. So the goal with this is to create streamlined, relevant, and intelligently presented data to a clinician so that they can actually make use of it. And right now there just is tremendous information overload and so we’re going to try to make the information easier to consume and more usable.

So Pivot is a product that we introduced in 2019. It actually sits on top of our healthcare terminology management platform, Symedical. Symedical is very well known for its ability to do mapping and automates a lot of the work that a mapper would need to do very, very effectively. And we call that normalization. And so with Pivot, you can see that pivot can take in data from a bunch of different sources. In this particular use case, we’re going to be taking in data from ELLKAY through the CommonWell Network. Pivot has the ability to take that information, understand it, normalize it, consolidate it, deduplicate it, do some level of validation. And then we also have a rules. And for purposes of our use case with CommonWell, we’re really focused on transforming from one format to another, consolidating data. So we can take in multiple documents and consolidate them into one single output, which is what Paul was talking about, that 31st document. We can deduplicate the data within the message. So as he talked about the pages and pages and pages of meds, we have the ability to look at meds to normalize those meds and then to remove the redundancies and then produce an output then that could be consumed by ELLKAY and passed on to the recipient.

I’m not going to go through all of this, but certainly the problems that we’re trying to solve are the duplication in the data, the semantic issues with the data, making sure that things are coded properly and we have to do that in order to be able to remove the redundancies. And then also dealing with the different formats of the data. And I wanted to give just some data examples so that you kind of know what I’m talking about when I talk about normalization. And I want to give a call out to 4medica. This is 4medica, it’s clinical viewer. So we did a proof of concept with them to kind of illustrate data normalization. And so what we have here is the tale of two patients, our male patient, which you’ll see next is normalized de duplicated, consolidated. And our female patient is not, it’s essentially the same data, but you’ll see what I’m talking about when I talk about deduplication of the data.

So in this first example we’re showing that the patient has two encounters. One is for an ambulatory surgery center and the other one is for primary care. We’ve got the vitals up on the right hand side. You’ll see a little bit later what’s actually happening in the data in terms of normalization. Now we’ve got our male patient. The data largely looks the same here, which you don’t see in the back, is what’s actually happened with the vital signs where they’ve been normalized to loin coats. And now we go into the meds and allergies. And so we can see over here a Paula, our female patient has got two pen VKs on her history. So again, as Paul was showing, as those documents come in, you see a lot of redundancy. And this is a very simple example, but imagine the number of records that can be coming in for a patient and then this patient has seven meds. Now as we go to our male patient, now that we’ve normalized the data and de-duplicated it, we can see that that pen V went down to one and the medications collapsed to the four unique medications that the patient is actually on.

Now if we look at labs and problems, this patient has seven lamps and they have 13 problems. And the thing that I wanted to point out is you’ll notice that it’s highlighted onto the hemoglobin A1C. And notice that even though there are multiple hemoglobin A1Cs over here on their trend line, you only see one, right? So this data has local codes and because of that, the data cannot be trended. Now as we move to our male patient, now we’re able to see that everything now is quoted to loin. We can now see that we’ve got the same lab but on different dates and now we’re able to trend that making it a much better experience, right? For the clinician who’s trying to treat this patient. Additionally, over in the problem list, we were able to reduce the number of problems from 13 down to nine.

And then finally we’ll look at immunizations and social history. So we’ve got two immunizations and one social history, but the immunizations are not coded to CVX codes. Says we go to our next patient, same data, now it’s been normalized, now it’s normalized to CVX codes. We’ve got normalized descriptions. Social history also has been normalized, although the description didn’t really change. And so what’s really happening behind the scenes here, we can see the original data with a lot of local codes. And over here we can see the normalized codes normalized to the USCDI standards. Okay? Same thing for the medications normalized to RX norm as we go on to our labs now, normalized to loin codes, our immunizations normalized to CVX codes and that’s essentially what’s happening to the data. And again, once you’ve done that, then you have the ability to then remove the duplicates because you’ve now aligned your data so you can actually see what a duplicate is. And I’m going to turn this back to Paul. What are you?

Paul Wilder:
Hi, I’m back. Hello. I think this is our last slide, right?

Stephanie Broderick:
Just one more.

Paul Wilder:
Yeah. Okay, good. Sorry. So again, to get involved, very simple. We are a small organization, just a handful of people. So we’re just a name at the best way to get in touch with the membership at. That’s where we get all of our ingest for people looking to join. If you have tools, show up. If you have an EHR that needs to be supercharged, happy to do that too. I’m listening to the presentation already, thinking of new things to add. Some of ’em are going to involve you. So get ready. There’s more to do. The main thing, by the way, just so you preview that we talked about getting data from the outside, maybe we can help people provide better data in the first place, right? So let’s talk about that next, about the data going out so that we can make other people’s lives better and do exchange better. So happy to have everybody join. I don’t know what tools are out there. Someone asked me before, do you know what you want next? No, I don’t. I don’t know what people are doing. So come and tell us. Come on board and let’s have some fun.

G.P. Singh:
Also make sure we know what we want next, which is the happy hour. The ELLKAY happy hour is happening. The CommonWell ELLKAY happy hour is happening at 2825. So Paul’s obviously going to be there right after this. So if you guys want to talk to Paul, you should be able to do that at the happy hour.

Paul Wilder:
If you want to hear this story slightly differently tomorrow. That one’s in the interop, what do they call it? Showcase now? Yeah, Interop Smart Experience over the bridge and through the woods to grandma’s house you go. It’s 11 o’clock tomorrow. We’ll be going through this a little more detail and more Q and A. I think from here it’s show up to the happy hour and what, 2825? 2825 ELLKAY booth. That’s fun. And do we have any questions? Yeah, I got that right. Question slide.

Stephanie Broderick:
Paul. I want to go back to what you said because I did actually, I do think that there are applications. We’ve done a lot of talking here about the picky framework and the data quality scoring. And I do think that it’s got some potential applications exactly to what you were talking about is can we score the data at the source, identify the sources of data and what challenges they might have, and then go back to the source to see if we can improve the data as it’s coming out. I definitely think that there are some potential applications there.