Informonster Podcast

Episode 15: CommonWell Health Alliance and the Mission to Bring People and Data Together

January 12, 2021 Clinical Architecture Episode 15
Informonster Podcast
Episode 15: CommonWell Health Alliance and the Mission to Bring People and Data Together
Show Notes Transcript

On this episode of the Informonster Podcast, Charlie Harp meets with CommonWell Health Alliance Executive Director, Paul Wilder, and Director of Product, Liz Buckle, to discuss the organization’s mission to provide universal access to data at the point of care for the right clinician and the right patient. While the goal is simple, getting there is incredibly complex. Charlie explains why Clinical Architecture decided to join this alliance, and both Paul and Liz talk about how they’ve been able to connect and share data through their growing nationwide network with the help of their members and initiatives like the CommonWell Connector™ program. The group also shared insights on how federal regulations have affected the push to universal interoperability and the importance of ensuring data quality along the way.

Contact Clinical Architecture

• Tweet us at @ClinicalArch
• Follow us on LinkedIn and Facebook
• Email us at informonster@clinicalarchitecture.com

Thanks for listening!

Speaker 1:

[inaudible]

Speaker 2:

Hi, I'm Charlie harp. And this is the info monster podcast today on the infer monster podcast. I'm going to be talking to the folks from CommonWell health Alliance. So today, who I have with me is Paul Wilder, the executive director of Commonweal and Liz buckle, the product manager of Commonwealth. So if each of you, Paul, you first could take a few minutes to introduce yourselves and tell us a little bit about you.

Speaker 3:

Thank you very much, Charlie. It's a pleasure to be here, uh, against Paul Wilder, been the executive director here at the CommonWell health Alliance for about a year approaching the anniversary of my start next week, actually. And my previous life was in health information technology, primarily New York state working with the health information system that we have over there, which is a network of networks across the regions and the state. Most of my career was in healthcare before that as well. Uh, primarily radiology and cardiology informatics with a brief respite out of healthcare for about two years where I immediately realized I had to come back, which is part of my usual story of how I got to where I am. Which if you give me if I have one minute, I can explain to her if that's okay for you. Absolutely. So I was outside of healthcare for a brief period of my life. And my first daughter got born. She's now 11 years old and everything was fine. She was early about five weeks. So slight risk, uh, to many, many factors, but we got home. Everything's good. She had a little Janice when she was born. Third day of life, we wind up at the pediatrician on, you know, because that's what you do when you have a newborn and John dis has returned. We don't notice this cause it's a gradual thing going on day by day. And I'm, I'm not a clinician, I'm an health it person, right? So he says, Hey, little bit, John Dez, did you have that before? When you at the hospital? We're like, yeah. And he went down and he goes, Ooh, you know, really? That's not supposed to ever go that direction once you're, once John has a Bates for a newborn, uh, it doesn't come back unless there's a problem. So you need to go back to the hospital. So you have this nice little bundle of joy. Your first one, three days old, and this guy says, go to the hospital again. Now, now we didn't go back to our original hospital. We went back to the one that's close to our house, which was walking distance. We live in a urban setting with our stroller, walk down there and they ask us a bazillion questions of which we have no answers. And being a person that formerly was in healthcare and did some informatics and exchange stuff. I say, why don't you go check the system or at least call the people right across there, three miles away, the hospital she was born in right across the Hudson river, give him a call and get the records. They can't get anything. So I call and they say, your records are between floors. Literally the printed copies of whatever the heck it was. It was on a cart in an elevator somewhere. And no one knew which card it was on which elevator and what floor it was on, which is a travesty. What happens then is a bazillion extra tests and tens of pages of additional lab tests. Cause you got a three-day old newborn, which they don't like to make mistakes on. I hear, I get to hear the screams of my daughter getting a spinal tap and our third day of life, which is not a fun experience. And she was set under UV lights for about a week, perfectly fine, healthy child, no big deal. But the inefficiency of that process, the trauma to the parents, the potential trauma to the patient, fortunately, a patient that won't remember it, but you get the idea was horrendous. It was at that moment. I said, I got to get back to health care and someone's got to fix this interrupt stuff. Cause there's a big gap between what we expect as patients, consumers, and clinicians, and the reality of where we are, even as we're moving into electronic health records and trying to operate them better. So here I am doing that on a national scale. Uh, you know, I started here, like I said, a year ago and you know, thrilled to be able to do it at this scale with this kind of Alliance, with the mission-based focused for patients, providers, systems, payers, and all the members of their Alliance that we get to meet with every day.

Speaker 2:

Thank you, Paul. Thanks for sharing that story. I think a lot of us have some kind of intersection with healthcare, especially as we get older and our parents get older and we go through things like, you know, having children, we intersect with the inefficiency, that's kind of baked into the way healthcare has operated for decades. It's interesting that that is something that kind of triggered you to go back and try to focus on fixing the problem. Thank you for sharing that list.

Speaker 4:

So I started out working with actually one of Commonweal's, uh, member companies, one of the founding members and began by working on their interface implementations, kind of the old school version to try and to get out of the point of point space and move towards a more centralized model, which really led us down the path of CommonWell, moved into product management, overseeing all of their interoperability services and solutions. And I've been now with the Alliance for a little over a year and working towards all of the Alliance key, uh, initiatives with Paul and trying to figure out how we can solve this, this big data quality burden.

Speaker 2:

Great, thanks Liz. It's funny. When we joined Commonwealth clinical architecture, joined CommonWell, CommonWell is made up of these folks that actually have the need to share and move data. And to me, it's kind of a, it's kind of a no brainer. People do things more effectively when they do it together instead of, you know, kind of falling into our traditional role in healthcare, where everybody toils away in their individual silos, you know, coming together, making agreements and, and kind of making things work better. And, but people have asked us clinical architecture, why did you join CommonWell? You're you're not a health system. You are not an EHR vendor. But to me, it's one of those things where, when I see an organization doing something that we need to do, I want to, I want to do what I can and I want to do our part because we are a, we kind of live in that interoperability data quality space. That's what we do. So for me, it's kind of a no brainer to be part of something like Commonwealth. But one of the things I would ask you guys, and Paul, if you would, to kind of tell us what you see as the kind of the vision and the mission for Commonwealth, for those that are listening, that may not be familiar with it. Yes.

Speaker 3:

Thank you for that. Uh, the mission is simple. The way to get there is often complex, right? The mission is universal access at the point of care for a clinician, for the patient standing in front of them or sitting in front of them or laying down in front of them, all the available information that is collected throughout the entire ecosystem. All the places that I've seen and, and had services performed on me had maintenance, et cetera, available at that point of care, it has launched some secondary missions, which is use the same data and make it available for other settings, such as for claims, adjudication to payers, for operations, use cases for quality measurement and coordination of care and things like that. But the core mission started out as make sure the right information is available at the right time for the right condition about the right patient. And to do that two things have to happen. Uh, when do you need scale, right? You need to have an environment of participating providers and their vendors willing, ready, and able to meet the Mark. And I believe we have that. We have 110 million people registered to allow the exchange of their records through our framework today. The second thing is that scale is the patient part, right? So I can get the providers engaged, but getting the patient part. And the 120 million is the proof point of that. And growing, it's actually growing a good five to 10% every month or quarter, depending upon what's going on. But it's doubling basically every year we were at that critical mass scale of connectivity to get to that mission. The part we're really attacking now, and the reason why I'm really excited to do this podcast and talk to others about it is now we're moving to, okay, we have quantity. Do we have quality? And that, that difference from the, those couple of little letters makes a big difference. And you of course, and what your company does is very well aware of that. And I think it's important to realize that we're not, we're not saying we have bad quality. I think that's one of the things that people think about when you start adding a measurement rubric or some sort of way of evaluating where you are. It's knowing where we are to know one, is it worth improving? How far are we, maybe we're perfect. Our data is a hundred percent and anything we do to try to improve it is infinite cost and effort and not worth it, or most likely where are the areas we could improve as an Alliance, as a group of members and potentially how the providers themselves are using those products to make sure the quality of the data exchange throughout the system is at the highest level possible for providers to use and rely on

Speaker 2:

One of the things that I encounter all the time. And it's, it's one of the things that amazes me to this day is that we live in a time when, on this, you know, glass rectangle, I keep in my pocket, I can check the weather and I can navigate from point to point and have it route me around, you know, accidents. And, and so we have all this information we've become so accustomed to having technology assist us and be aware of things when people intersect with healthcare, it just, it just makes it that much worse. It feels so broken that if I go to see one doctor that the other doctor doesn't have that information, or if I go, if I go somewhere several times that they don't incorporate that information into what's going on today, a lot of people, when you talk to them, you know, the consumers, the people that aren't in healthcare, it, they really struggle with that problem. And I think when it comes to the quality, you said, it really well, quality and quantity are not the same thing. And I think one of the things we struggle with in healthcare is this thing that I call uncalibrated uncertainty, where sometimes we have data that isn't really meant to do what we're trying to do with it. It's not that the data's bad, we're trying to use it for an unintended purpose. It conflates things so that when we try to apply technology like machine learning and analytics, it adds a little extra bit of confusion. So a big part of solving that problem is us recognizing it, because if you value something, you measure it, right. You look at how you can work together to take actions, to make it better instead of, you know, trying to do it in a, in a silo, because if we're truly going to share data across all those silos, no single silo can fix it. Right?

Speaker 3:

Yeah. And I think interestingly, the idea of quantity in a treatment scenario where humans are reading the documents or reading the exchange actually does have a bit of quality embedded in it because a lot of it is do I have enough data points available to me that the likelihood that a key piece of information is missing is low, right? So if I see five primary care doctors in my last, in my 20 years of being an adult in, in medicine, 25 to 27, for me, whatever it is, and I've actually probably seen about eight personally, as long as one of them gets the right piece of data in the right place, that I'm either that I'm hypertensive or have diabetes or whatever that data point is likely to get through. But what we're looking for now is now that we have so much quantity, we need better tools to go through the data, right? We need suggestion algorithms that say, not necessarily diagnosis, but suggestions. Hey, you might want to be aware that in the fourth document that you haven't opened yet, it said that this person has a history of near diabetes, right? And today the record you have in front of you doesn't show that, but I thought you might want to go look at that and the computer can help do that. Suggestion. The problem really comes with bad data or bad quality data and documents is the computer. Can't do that, right? If it's not codified the right way, it can't guess it can't make a conjecture and help that suggestion to say you human, you M D D O or the person that's caring for this person. Here's some advice you might want to know about with the amount of quantity, the quantity of stuff coming through now is so large that they can't read it all. So now that we have the quantity, we have to go, okay, where the tools are needed to make the data more actionable. And the quality isn't there, it's really hard to build those tools. That's why we're here now. Right now we have the data probably filled in enough. Let's make sure it bubbles up to the top and the right workflows we set in place to help provide better care for patients and for the population as a whole.

Speaker 2:

Absolutely. Right. I mean, as you, as you look at the, one of the challenges that we have in healthcare is that we've got, uh, a shrinking provider, population providers, I think experienced time famine. There's not enough time while the quantity is good, their ability to having the time for them to kind of sift through it all because 80% of what we capture about patients is not intended for software to understand it's intended for a human to understand, but the human doesn't have the time to go through the 1800 pages of healthcare records to get accumulated for a single patient. So you're absolutely right. We need to find ways going forward to either capture the data in a way that the computer can actually do that. Cause the computer manufacturers time through computational effectiveness. If we can put it in a format, the computer can understand and do some of that heavy lifting. That's good. We can make sure that the data we're getting there is the right data and not the wrong data that obviously helps too. So with the work that CommonWell has been doing, Liz, what are some of the things that have been accomplished that people should know about since you guys started?

Speaker 4:

It's pretty incredible to see just how far Commonwealth has come since its inception. You know, a little over seven years ago, we now are exchanging data with over 17,000 provider organizations. We're in all 50 States, DC, Puerto Rico. Paul mentioned, um, a little bit earlier where we just probably about a month ago hit over 100 million unique individuals enrolled in our, in our record locator service, which is huge, right? That's, you know, one third of the us population. And I wanted to talk just briefly, just so that folks who are listening can get a better understanding of what our network is, what it looks like, what our services are that we offer. There's three different ways that we connect and exchange data. We obviously have our core membership, our service adopters that adopt and deploy CommonWell services to their clients. We also connect directly to care, quality organizations and other external organizations through collaboration agreements. And then finally we have this cool program that is relatively new called the CommonWell connectors. And those connectors are interoperability intermediaries, or they're certified to be serviced adopters on our network, but they're able to connect some smaller organizations that may not have the technical capacity or time or ability to invest in connecting directly to the network. So we have three of those certified connectors available now that are actively checking. So it's been a pretty awesome period of time over the past several years, I've watched it grow now for many years. Um, and we have, I think about 80 members across the healthcare continuum. So from a forward looking perspective, I think, you know, Paul brings a really fresh take and we're continually brainstorming back and forth a variety of new use cases that we can bring to the Alliance. We've already brought three or four through the approvals process this year, getting continuing to work on what's next, what's at the forefront of, of what we can be doing. Especially when we look at having the transactional volume, having the quantity, what, what can we use? How can we use that to, to further our mission of allowing this data to be wherever it needs to be when it needs to be in the right hands. It was pretty exciting to see the progress you guys have made over the last seven years. And a lot of your members are also clients or associates with clinical architecture. And just as an aside, they they're all seem to be pretty excited about what you guys are doing. And they really kind of see where you're going and look forward to the collaboration, the innovation and the types of things that can happen when a bunch of smart people get together and work hard to solve a problem that plagues all of them, my anecdotal feedback on that. So one of the things that obviously impacts how we do these things in health care is health policy regulations and things that are, that are coming out of, out of the federal government. When you think about those things like, you know, tough information blocking rules, um, what's your perspective on that and how that's going to impact us going forward.

Speaker 3:

So I'll take that the policy work going on right now are the policies in place are important to make sure there's a level playing field. And that access is as easy as, right. Especially when we start talking about making sure patients have safe, secure, and easy access to their data. And I think that's where information blocking is really trying to hit the Mark and say, we've we have it available, but it needs to be a little bit easier for it to be impactful for myself or anybody else to access the data as a consumer. I will say though, that from a effort perspective, the mission CommonWell and our partnership, our partners at care quality and others have really been ahead of the game here. You know, so the, the regulations come out when you've mentioned blocking and others, when we've already built a very robust system to do all this stuff, right? So we are a hundred percent in favor of making sure that information blocking never occurs and you can make that a regulation. And they did, uh, I would say the organizations and vendors and our network would say that was unnecessary because they were already on that mission and on path. But that being said, I do think at the edge, it is important to have those rules of the road. More importantly, what it did is actually set a different target for us. We were doing something we call query based document exchange. And we often abbreviate that QBD because everybody abbreviated something. And that's a document-based form of exchange where you have, you know, an encounter or a visit a bunch of data warehoused in a thing that passes around like a fax with a whole bunch of data in it. And it's good. It actually works relatively well, but the new target has set towards fire. You know, that's a different standard for getting access to kind of more discrete data, coded data like your procedures and diagnosis and your labs and your meds versus a full document that houses, all that stuff. So we're excited to actually to kind of have that almost forcing function to accelerate our work on that side of the world. And we are working on that right now. So all the things that Liz talked about about a record locator now we're not a record locator just for documents, but we're working on being a record locator for individual discrete data elements that will come out of a fire resource. Uh, so we're excited about the rule because it's directly in line with what we want to do, and now it align the industry towards the next target that we expect the lead on from here forward as well.

Speaker 2:

Having that makes a lot of sense. I think if you go back and look at the different regulations over the last 20 years, I don't know that they magically fix anything. There's a regulation, can't magically fix things, but it does act as a motivator and a driver for people to kind of put their heads together and figure out how they can adhere to, you know, hopefully not just the letter of the law, but the spirit of the law. And I think that you're right. A lot of the stuff that we've done historically is about sharing documents. And I think that the spirit of interoperability is, is sharing more than just a physical piece of paper. I think you're right. And where you guys are going with fire and sharing data that is portable and computable could lead to some pretty amazing things happening in healthcare, really improving our ability to, you know, reduce the number of stories like the one you told about your daughter at the beginning of this podcast. I also think that, you know, what's interesting is when you create these connections, um, and you create these thoroughfares to share information today, they might be sharing X, but in the future, once those connections are established and you have people that are, you know, forward-thinking and innovating new ways to accomplish better things, just having those pipelines increases the likelihood that you'll be able to use them for something interesting to something new as you evolve over time. So, uh, I think it's very exciting. And I do think that the fact that the federal government kind of focuses on standardization interoperability and kind of sees that there's a problem is good because it does help us move things in a particular direction.

Speaker 3:

Yes, it's, it's surely creates a level of focus. Um, the industry on whole, I'm not gonna say there's this profit made from things not being standardized, but the reality is that it's efficient agency to work with the thing that you like the best, right? And that doesn't necessarily mean that's the thing that works as the community as whole. It's just the thing you work best on by focusing everyone that now becomes that the thing that is easiest for you to work with and everybody else to work with, right? And now it becomes useful, both internal and external for the internal parts of the products and things that where you interoperate amongst business lines and amongst products you create as well as how do you go between products and industries. So, you know, it's, it's a, win-win when we start thinking about a common target and the regulations did do that, right? It's set a standard for, you may be talking this and you may be talking that, but we decided that this is the one we're going to talk about from Huron let's focus and not create a environment of non homogeneity that, that we can't, we can't get out of. So we think that that's exciting. Does anybody love regulation? No. I thought that not the most exciting thing in the world, but it does have a purpose when there's something broken at the edge, right. Where you're, the decisions are easier to make and you know what you're targeting. If you know the other person, the other exchange Anthony and their side is going to be hitting the same thing. You're not wasting your effort. There's more focus.

Speaker 2:

I think you're right. I think that when you think about things like interoperability and sharing data, I always think it's interesting that when you receiving data, you know, sometimes there's trust issues, but you care about the data you're receiving when data's going out, that's you doing work? Um, and it also, some people might feel like, Hey, I worked hard to create that data. Why do I have to share it or me giving that data introduced to some kind of risk and people start to get protective. And so sometimes you need something that, that forces you to prioritize that. Cause even if you might want to do it with all the stuff you have going on, it's very easy to deprioritize something that benefits the future. Does that make sense? You think I'm off base there?

Speaker 3:

I don't think so at all. I think that that's, that's, well-said inaccurate.

Speaker 2:

The other thing too is, you know, I always make a joke about standards where I'd say that standards are kind of like the pirates code and pirates of the Caribbean. They're more like guidelines. The other nice thing about organizations like Commonwealth. It's almost like, yeah, there's a standard, but here's how we choose to interpret the standard. So it's almost like you're, there's a standard on the standard to help make sure that people are doing things in a way that's compatible because you know, we all, we've all dealt with HL seven in the past. And the fact that, you know, you can follow the HL seven, two X standard and still have something that you can't consume, uh, because it's not your flavor of the standard. And that's another thing that I like about Commonweal is it's people coming together and saying, this is how we're going to do this.

Speaker 3:

I think that's right. I also, I think I was in a room, you know, this is going back about 10, 12 years ago, right? At the beginning of meaningful use, or maybe in the middle of the first phases, me few stage one, working on getting to stage two as a bunch of vendors in the room. And it was a precursor like to, EHRA trying to just, you know, work on interoperability and how we could work with his. And it was a great conversation, but one vendor was very honest. And I, and I, and I learned a lot from this statement or w what do you described? He said, look, we are perfectly happy adopting a standard. And don't mind if it's forced upon us. The problem is I'm not moving unless everybody else moves. Right. So until that happens, whether it's efficient or not, I am going to, unfortunately for the efficiency of the ecosystem at whole, I'm going to make money on the professional services that bridge the gap between the way I work and the way someone else works. What I prefer as that everybody in this room agrees to a standard and if not, force it on us so that everything's more efficient. And he said, this is the interesting part from a commercial perspective. I think this is important for vendors to think about. It will likely make me my company more money when I don't have that revenue, because the amount of time I'll spend on the help desk side and the break fix side, having to work with interfaces that change break don't interoperate anymore. All the downstream costs should decrease. So I'm happy to move, but I can't do it unless other people in this room do it. Cause then I don't get advantage of having gone to that standard in the first place. And that's definitely when information said, it's fire USDA, reversion, three of fire run. And I think that changes a lot of the variability. It makes it easier and faster to be able to inter operate to iterate from there and brings down costs overall.

Speaker 2:

No, I think that's a great point. And I think it's one of those things that, you know, I've been in healthcare for 30 years, developing systems in all different segments. And it's always astounded me. How, how often we all solve the same exact problem in our own little silo. And, you know, in clinical architecture, one of the things we've tried to do is put some tooling and technology in place so that, you know, we can accumulate solutions and solve problems in a standard way so that other people can leverage that and not feel like they have to reinvent the wheel because that allows for the uplift of healthcare and allows people to focus on specific problems that are directly in their wheelhouse and not have to all go out and solve the same problem. But you're right. We, we've kind of been stuck in that rut and you're afraid sometimes you're afraid to. I mean, in some ways I would argue that what you just talked about, it's not possible unless everybody does it. It's it's, you all have to come to agreement for anybody to step away from the old way of doing it, or the person who steps away is liable to fail for the very reasons you stated.

Speaker 3:

That's right. Yeah. The it's hard to adopt a standard is actually a first movers disadvantage because you're the one that has to make it work in practice and that's not normally, so thank you.

Speaker 2:

So, Paul, one of the things you talked about earlier is you kind of talked about the shift from quantity to quality, and I was wondering if you or Liz could talk about the Commonwealth data quality project.

Speaker 4:

Yeah. I can take that one. So we have, um, been working over the course of the past year to put some smart people together in a room and kind of do something similar to what Paul's talking about. Right. So how do we solve for something that, you know, everyone is kind of addressing in their own unique way, by no fault of their own. We just go in the direction that makes the most sense at the time. And so we did that. We brought some, you know, smart people together with experience in the data quality area. And we came up with this use case really that we're calling the CommonWell data quality framework, collaborative effort. We worked with, uh, your team, Charlie few members of your team. Who've been excellent to work with, um, the VA of HIE system and, uh, Meditech among other members, um, within the Alliance to figure out how to mitigate the challenges associated with incomplete or inconsistent, or I guess what we would call poor clinical data, but really to define that, what does that actually mean? And figure out a way to incrementally improve the quality of data on the network. So we came up with this, this thing, this framework, and we, we framed this framework around four key pillars, improving things like miscoded data or data that's not in the right place, then tags violation. So for example, we want to, we want the ability to evaluate the conformance to required fields. So required codes required code sets versus the use of local codes bringing together that technical component, but also layering on top of it, the business aspect, why is this clinically important? Why is this, why should a provider care? Why should a hospital administrator care? And we talked about documents and the usefulness of documents moving to fire, really, regardless of whether it's documents or fire resources, it doesn't matter when you're thinking about quality. It's all about how the data gets into the system, how it gets wrapped up, how it gets transformed, how it gets ingested, you know, extra bold emphasis on that last step. And it's a problem that has to be addressed kind of either way, as we mentioned, kind of at the top, the Alliance has been definitely focused on ramping up and broad network availability and getting to that critical mass. And now that we feel like we're getting to that point, it is time I think to start addressing, you know, what's inside the envelope. And so this framework is a bit of a game changer. In my opinion, it jumps right into evaluating production data. I've worked with test systems in the past, and it's easy for someone like me or someone like Paul or someone like you, Charlie, to go in and make this beautiful record with everything in the right place, using all the right codes and code sets. But in reality, that's not what's happening. And we know that anecdotally and we know that through our own experiences. And so we wanted to skip that step altogether and move right to evaluating what's happening in the real world, analyzing it against our four key pillars and digging into what's going on through a clinical lens, through a business lens. And so what we've done is presented in an incremental and phased approach to doing this. And so I think Paul touched on this earlier. We kind of don't know what we don't know. And so the first step, and really the only step that we intend to take until we can prove it out and move forward is allowing the data to speak for itself, moving into an observation and education phase, where we do pull back the curtain and take a look at, you know, subset of the data that's moving across our network to figure out what the problem areas are. In my experience, we, we do make some assumptions and they're probably right, most of the time, right around what the most prevalent issues are. And that's great. And I think that there's definitely been a lot of other industry initiatives that have worked to, um, move us forward and we participate in those gladly. But I think when you do pull back the curtain and start evaluating, what's really going on from a production standpoint, it gives more teeth to the output. So how can I drive real meaningful change? Anecdotes are great, but when you have the true output from the analysis of this is my health system and 30% of the time my RX norm code is missing. That says a lot, you know, that's really powerful. So it's a flexible approach probably in our top three. I don't know, Paul can say for sure, right? Key initiatives moving into 2021 for us to drill into, um, exactly what's going on, uh, and truly understand what's going on in our network and allow our members the same opportunity.

Speaker 2:

No, very well said, Liz, I think that, you know, the quality issue in healthcare information, that's kind of what puts the T in the trusted exchange framework acronym, right? It's one of those things where if we go back 20 years, we were still very siloed in healthcare. And I know I've used a lot in this podcast, but we had systems that purchase data when people left. So it was very episodic. It was not a longitudinal way of managing data. We had more providers, the providers seem to have more time. Um, it was a very different world than the world we live in today and the world we live in now. And, and this is a question I have for you guys in my experience, people are still reluctant to take information that come from somewhere else and just incorporate it into what they're doing in their environment. And I think that some of that is this idea that I've now that I built this longitudinal record for Fred Smith. I don't want something that I don't trust to come in and break that data or to introduce something that that might not be correct. And I think that part of what you guys are doing around the quality can go a long way to help make that less of a concern for people that are trying to integrate data that came from elsewhere into the data that they've been curating and managing for that patient in their own system. You feel like that reluctance is still out there a little bit.

Speaker 4:

Yeah, I do. I can completely understand where that reluctance is coming from. You know, when you talk about ingesting data into your system, but at least from what I've seen the majority of the time, this is happening through some manual process. And I think that that manual process exists mostly because there is so much reluctance and is this accurate? And I don't want for my problem list to be altered. This is my evaluation of my patient. And I don't want this outsider information coming in to alter what I have as my, my truth, my source of truth. And I get that, you know, this is one of the key things that our partners at the VA have drilled in on is the data ingestion side is a risk. If the data is not good enough. And I think we're in this interesting place where now we want to move so much to automation and allow for data ingestion to happen without, you know, so many clicks who wants to go in and do a bunch of clicks right in the EHR. That's the opposite of what clinical staff, you know, has time or wants to do. And we hear that over and over and over again, but how do you marry the reluctance to incorporate external data? When in fact it could be significantly beneficial to the, to the clinician at the point of care and beyond how do you marry that with moving towards automation? And the only answer is, you know, resolving the consistency and the completeness concerns of the data that we exchange today.

Speaker 3:

I think that that's right. I also think it's important to think about the workflow. I was on a industry task force, something on a similar topic, and someone was talking about ingesting data. And I said, well, just a devil's advocate position. If all the data's available, if I interrupt connection, why are you ingesting it? It's available in the EHR with connections to the outside world. And that devil's advocate position was not taken well by all their clinicians on the call who said, but if I relied on it, I have to ingest it. And I said, hold on. I agree. The thing is we have to be careful with the vendor side and how we build products. That there's a difference between data. I've seen data. I took action on and data that's available. And if we just think of ingests, is that data good enough to ingest now? That's that does mess up a lot of the flows of did I make that decision? Did I make that call or did someone else make that call? But if I relied on a piece of data to help me make a decision, I better keep it. So in the event, that data goes away, for whatever reason that servers turned off that provide a practice is no longer in business or they're in drop something doesn't work. I need to remember that I use some piece of data, right? Maybe in my system, I had no evidence of diabetes. Basically. I didn't have a one C levels. I didn't have all the things that I would need to know that, and the patient wasn't quite clear because for whatever reason, they were unable to explain their H and P the way we'd expect them to. But the data I got from bombs, primary care practice clearly had a showing diabetes. And I need to understand that for the care of the person in front of me, that data, I should probably remember in my own system. So the rest of the care I do, I can remember, Oh yeah, that's right. I don't have primary data on this, but I did have primary data from someone else about that. And here's where I got it from. That's who I call if I have any questions, right. It's not just interrupt. Some interop is about having the breadcrumbs to know who to work with next. And I think that's where we have to be careful when we talk right. In just that there's the data quantity to the quality leads to a quality workflow of how you operate that data.

Speaker 2:

Yeah, no, I think that's a good point. I think one of the things we're still challenged with today is that a lot of the systems we use in healthcare are geared more towards episodic data and not longitudinal data. And they don't also, they weren't designed to receive external data. So they don't have good mechanisms for firewalling things based on Providence, on where it came from. We ended up with this issue where for us to accept data from elsewhere, you know, we might get, you know, 4,000 indications that they were taking Coumadin, or we might get 40 different, you know, codes that indicate that they had, you know, diabetes with some co-morbidity. And then that basically, you know, we run the risk of having this thing. That's really geared to be an episodic thing, uh, become a junk drawer of information. That's almost impossible to find anything. So we, we need to, number one, I think, look at how our systems work so that we can firewall data, just like you described where you don't have to slam the data in to be able to take advantage of the data. And the other thing is when I look at information, I kind of, I tend to look at information as is something in motion. You have the history of where it's been. You have the current state, what, you know. So if I look at everything across the history of this thing, I can surmise a current state of what's going on. Yeah. They had a broken arm 22 years ago, but it's not still broken, but they still have diabetes. That's something that's persistent. And then you can also look at information and look to the future, which I think is really exciting. Or you can look at, at the trend in the data and say, well, they're not diabetic today, but they're headed in that direction if we don't do something. And so part of what I think we need to do to really take advantage of the ability to share data and do meaningful things with that data is we need to rethink how we, how we store and think about the data in terms of the history of the current state and where we're going and how we manage things like data problems.

Speaker 3:

Absolutely agree. No, it does absolutely agree. And the example you gave with the broken arm is an example I use all the time. And it's funny when you do these stories and you, you've kind of got the frame, the idea, I once sat back and said, but even that broken arm is important when the person has pre arthritic conditions later on, you're like, you know, that could be nerve damage. Like the differences, you know, my arm, like, something's not right. It's just like, Oh, might say with no history, you might be developing arthritis. Do you have other pains around there? Or you say, you know, I had a break there five years ago, or the data says that, well, now we have a different, different path. We're going to take in terms of investigation and think about whether there was nerve damage that wasn't present in the initial break, but might be there now manifesting itself through other causes that caused it to trigger. So all these data points are important now and potentially later. So a lot of them are not thrown. That's a lot of the noise and why we look for data quality, helping us build the better tools to be able to do the right things with that data. So we have CommonWell, the mission has the right data at the right patient, for the right patient in front of the right provider at the right time. Now it's micro-segmentation of that data, right. Actionable pieces. And then it's operational with the EHR is, and other tools, what do I store? What do I know where to get if I want to get it later? And what do I ignore completely? Because it's not important. It's really hard. Humans are bad at this. I mean, I have you look on my phone today. I back up the pictures on my phone to three different locations, too. I have a Google photo. I have an Amazon and I have a one drive location. What's my problem. When I curate that stuff, when I deleted from one, it still exists in all the others, right? I've created that guy, garbage bin of stuff. And I can't get out of it just from taking pictures of my kids. And we do the same thing with this day. It's not, it's normal for us to accumulate data and things and not know how to purge it. So this is a normal problem, but we do have to work on it to the benefit of patients and population in general.

Speaker 2:

Well, absolutely. And the quality to get to the point where we want to be as an industry and solve some of these high class problems, we've got to get through the basic problems. And then Liz mentioned this earlier with interoperability. Just a basic example is if you can't move the data from point a to point B, you can't solve any other problems relating to the data. Once you move it, if you can't have a syntax and it's not packaged and formatted in a way where people can understand it, you can't solve the next problem, which might be semantic interoperability. So we have to, it's like a pyramid. We have to solve these foundational problems to be able to get to the high class problem of doing some of these things that we're talking about. I totally agree. And I think that the work that Commonweal is doing moves us a long way in that direction. And so I really appreciate all the stuff that you guys are doing and your members are doing to help make that kind of progress in healthcare. We have a ways to go, to get to the point where we're like some of these other things that we look at our phone every day, and I think we'll get there, but to get there, we're going to need organizations and groups like the CommonWell health Alliance to make it happen. So I appreciate what you guys do. All right. Before we, uh, we wrap up today, anything you guys would like to share or anything else you'd like to say?

Speaker 3:

Uh, well, first of all, thank you. I do appreciate the time. Uh, it's always every conversation about things that we do that we get to educate others. Uh, we always learned in the process, you know, it's like being a great teacher is also about being a great student, right? CommonWell is here to not quite solve the problem in that drought marks. I think we have interoperability at a base level linked in some respects, right? It's now advanced that to the next layer of how we have actual data at the right time. And that micro-segmentation, and, and quality is important. You know, what CommonWell does at its core is matched patients across disparate systems so that we can collect that together. Without that record locator thing that Liz talked about, you're not going to be able to find that patient's data. And so that's what we do at a core is make sure that it's available. The next step is for all of us to make sure that the data we're getting is actionable and that it has the right Providence, as you mentioned as well, so that we know how to go back to it, ignore it, store it, but keep it generally available for someone else that might need things that we were not aware were important at the time. So interoperability is important today and the data is going to stick around to be important later, too, for new care paths that are yet to be developed and super excited to be here. I think our members are as well as our customers and I greatly appreciate the time you spend with us today.

Speaker 2:

It's been my pleasure. So, uh, Paul Weiler, Liz buckle from CommonWell health Alliance. Thank you so much for your time today. If, uh, anybody out there wants to check out the CommonWell health Alliance, it's a CommonWell alliance.org, check it out. Be part of the collaborative solution, if you can. Uh, thanks again, everybody for listening. This is Charlie Hartman's has been the him for monster podcast.

Speaker 1:

[inaudible].