Charl Informonster播客的这一集ie Harp talks with Drew Ivan, Chief Strategy Officer at Lyniate, about cross-organization interoperability, patient interoperability from consumer devices, why we interoperate, and how all of it affects our relationship with trust.

Follow Us

Have a question or topic idea?

Transcript

Charlie Harp :

I’m Charlie Harp and this is the Informonster Podcast. Today on the Informonster Podcast I have with me Drew Ivan, the Chief Strategy Officer at Lyniate. We’re going to talk about one of my favorite topics, interoperability. But before we get started, Drew, why don’t you give the folks at home a little introduction?

Drew Ivan:

Sure. Thanks Charlie. Yeah, I’m Drew Ivan, the Chief Strategy Officer at Lyniate. I’ve been in the space for quite a long time. Lyniate was formed by merging a couple of different companies, some of which have a longer legacy.

The products that we’ve pulled together have been in the market for about 20 years. I got into healthcare interoperability in about 2008, although I was dabbling in it prior to that. Pretty long history with healthcare interoperability, which turns out to be an asset.

Having seen where we came from and the changes that happened over time, turns out to be super useful for helping plot a course for where we’re going and what the new trends will be coming up. I’m pulling from all of that experience to figure out how to pilot the company and the product toward where we want to land in a few years here.

Charlie Harp :

It’s a dubious honor for folks like you and I that have been in the field for a number of years dealing with this problem. When I think about interoperability, and I talk about it from time to time with folks. Just to do a primer for people that aren’t steeped in interoperability.

Interoperability is really allowing two entities to share information in a meaningful way, to be able to exchange information and share it. Typically, we think about interoperability as three different components. I tend to think of it as four.

But we’ll start with the main three, which are physical interoperability, which is taking the data and moving it from one place to another. Syntactic interoperability, which is being able to package the data in a way and unpackage the data in a way where you can make use of the data in the package.

And then semantic interoperability, which is being able to take the things that you’ve removed from the package and leverage them in the receiving environment. But when you and I were talking in preparation for the podcast, Drew, you talked about some other aspects of interoperability that I thought were really fascinating. Do you want to share that?

Drew Ivan:

Yeah. Maybe I’ll start from where you left off on that three part model. The thing that strikes me about it is, physical interoperability used to be a big deal. It used to be not an obvious answer of how you were going to actually connect to computer systems together.

Because you were lucky if you had a network within your company, let alone networks that could connect to other organizations. We tend not to think about physical connectivity that much anymore other than what types of security are you using or encryption or whatever.

But there was a time when it was unclear what method you would use to physically move the bites from point A to point B. My company focuses mostly on the syntactic interoperability. We are experts at the technical and healthcare formats that are in current use today, and we’re good at mapping between them.

And then I think your company is more involved in the semantic interoperability, which I think of it as applying meaning to that structured data that we’re moving back and forth. Within this syntactic interoperability where we focus, I also break it down another way.

Which is to think about interoperability within an organization. For us, this often means a hospital connecting their internal systems together with traditional HL7 Version 2 messages. So they’re connecting their EMR to their registration system and their billing system and so forth.

That’s actually where quite a lot of activity happened for the first 15 years of our products life cycle was solving that problem. More recently, we’ve been interested in what I call cross-organizational interoperability, and that’s what it sounds like.

It’s moving data between two different organizations. It could be from one hospital to another, from a provider organization to a payer, provider to public health. Any kind of interchange between organizations looks different than the internal integration.

这是因为在使用不同的数据标准nd different security models need to be used as well if you’re operating across different networks. There’s also data governance issues which are less of a factor when everything’s happening within a single organization.

And then the third piece that I think about is device integration. That’s a subset of organizational integration, but it’s moving data from devices that are at the patient’s bedside into the hospital network so it can be consumed by let’s say the electronic medical record.

You have this three layer cake of data originating near the patient on the device, moving into the organization’s internal interoperability and then potentially moving across organizations. The reason we break it down into those different categories is because there’s different assumptions that you have going into conversations about each of them.

For us, it’s beneficial to establish what layer of interoperability are we talking about when we start a conversation so that we’re not talking with different assumptions than the listener is bringing to the conversation.

但幸运的是,很多的背景the same. A lot of the standards are the same. A lot of the connectivity issues are the same and so it means that our tools are applicable across all three of those scenarios.

Charlie Harp :

Don’t you think there’s also a different notion of trust? It’s interesting when you look at obviously the information coming out of a device in an organization, there’s a high level of trust. That information must be something we take in, we must use it.

I think when you look at interfaces that go, let’s call it intra-enterprise, where you’re going from the [inaudible 00:07:08] to the hospital, from the operating room to the inpatient setting, I think there’s also a high level of trust. The information, it’s almost like it flows more freely.

My experience is when you look at the across organization sharing of data, whether you’re getting data from a health information exchange or you get data directly from another exchange partner, unless it’s like a reference lab, there tends to be some reluctance such as carte blanche let it flow into your system. Do you see that as well?

Drew Ivan:

Yeah, I think that’s right. I think doctors are more trusting of data that originated either within their organization or like you say, from a reference lab, which is an extension of their organization. It’s work for hire that they ordered.

They treat data coming into the organization from other organizations with a lower degree of trust. It’s not always because they think the doctors over that other hospital don’t know what they’re doing. It’s because they don’t know necessarily the context that the patient was seen there.

If they get a visit summary note about a specialist referral, for example, unless they know exactly why that referral was done, they may not have the complete picture of what was going on with that encounter.

And so they treat it as informational, but I don’t even want to say less reliable, but they would think of it as something that’s useful to know, but maybe it has different provenance and so they treat it a little bit differently.

There’s a fourth kind of interoperability that we’re starting to see creep into the scene, which is patient interoperability. Patients are starting to have either medical grade devices sent home with them, or they have consumer devices like Bluetooth scales and blood pressure monitors.

They’re starting to get just about as good as the clinical devices. So they’re bringing this data with them to their doctors. That’s another place where trust comes into play because with data that’s collected outside of the clinician’s supervision, they don’t necessarily know if it was collected correctly, especially if you think of a blood pressure reading.

When the doctor does it, they do it in a controlled way with the patient sitting in a certain position and so forth. But if it was done at home by a non-specialist, they don’t know if it was collected quite the same way.

That’s a place where I think trust is an even bigger issue because increasingly, data is generated outside of a clinical setting. If it’s going to be trusted at a lower level, then we have to question how we want to incorporate that into the care process.

Charlie Harp :

I think that’s one of the things when it comes to interoperability that we so… We don’t really focus a lot of energy on it, at least I haven’t seen it. That is we can share information but whether or not that information makes its way into the data, there’s a lot of factors that could impede it, could be barriers to that.

One of the things, for example, is you see a lot of these initiatives coming out of Silicon Valley where people are doing more and more where they’re putting the patient’s record on a device like their phone.

You would think that at some point patients are going to be able to go in and review their medical record and possibly correct it or adjust it on their phone. I know that happens probably at some to some level with patient portals today.

But I would think that also might cause some concern when people are trying to decide whether or not they let patient-created data go into their official medical record or not without some vetting.

Drew Ivan:

是的,没错。我的意思是,现实情况是,耐心-reported data is already in the medical record because when the patient comes in and says, “I have a backache,” that gets transcribed into the medical record by someone at the doctor’s office, usually verbatim.

So some of that information is already there in a very manual interoperability way. But what you’re talking about is interoperability at scale. As the consumers are generating tons of data from their fitness devices and their in-home devices, how much of that is relevant?

How much of it… It’s not just a trust issue, but it’s like a volume issue. If I have a blood pressure reading from every single day, does my doctor care about every single data point? He’s certainly not going to review them one by one.

Does it make sense to average them? Is that even valid? I don’t know. But some way of managing this increasing flow of data is going to be important if we’re going to hope to incorporate it in any way into a patient’s care plan.

Charlie Harp :

Well, I think there’s also this notion of you have all this data, you have this combination of realtime telemetry coming off of devices, consumer devices, medical devices. You have all this data from the different places, the different types of encounters that patients are having in healthcare.

But the other type of data that I still think as an industry we structure it in our operate with is the unstructured data. You have all these clinical notes, these procedure notes, all these things that are not designed in a way that are intended for software to ingest and process.

I think it still represents between 16% and 80% of what we know about patients in healthcare. I think that’s going to be another challenge we have to deal with over time until we either figure out ambient healthcare or we figure out how to do a better job of doing a more organic clinical documentation process that results in structured data.

Drew Ivan:

Yeah. It’s tricky because when you use a specialist like a radiologist or a pathologist to interpret a finding, they put a lot of detail into the English language description of what they found.

That nuance is what’s really important to the physicians that are treating patient. Unfortunately, there’s a little space for nuance in structured data. Because it’s structured and it’s not as flexible, it needs to discard some of the information.

It discards the nuance and you end up with a description of a tumor in structured data that might describe the size or the appearance, but you lose quite a lot of the impressions that came through the unstructured report. I mean, there’s ways of trying to recapture some of that.

There’s natural language processing that makes an attempt to go through a block of text and mark it up with data that can then turn into structure. But at the end of the day, you’re losing something by putting it into a database.

I feel like that’s inevitable. The best you can do is capture as much as possible and keep the text in its original format so that if a human needs to read it and act upon it, they have what was actually written in the first place.

But that’s the problem. I mean, artificial intelligence can’t do a great job of parsing out that detail that’s in the clinical note and so it relies on the structured data to do its work.

Charlie Harp :

Yeah. I think the trick is, if you’re dealing with unstructured data, you’re right, there’s a lot of specificity that you’re going to lose if you turn that into structured data because terminologies themselves being pre-coordinated, can only handle things they anticipate.

I think the trick there is to boil out the big pieces. To be able to know that the patient has an ejection fraction or to be able to know of 25% or to know that they’re a diabetic, that maybe someone didn’t put in the structured data.

Because the challenge I think we have in healthcare, the reason we interoperate is because we want to have a complete picture. We want to know everything we can know so that when we use analytics or AI or machine learning, we’ve got all the data that’s necessary to make the right decisions.

I think that’s one of the reasons why when you look at the industry and some of the struggles we’ve had applying some of these more advanced analytical machines to looking at healthcare data, the output is only as good as the input.

I think that’s why we still endeavor to improve the quality of the things that we’re feeding into those types of mechanisms. One of the other things that you and I talked about in the pre-call was some of the changes in the industry is to how we’re interoperating.

Because historically, back in my day at SmithKlein, I was building these ASTM interfaces which evolved into HL7. But I think now we’re seeing a lot of shifting in… We have these types of interoperability, we have the roles of interoperability, but we also now have these different mechanisms for sharing information. You want to chat about that for a minute?

Drew Ivan:

Yeah. This is where it’s helpful to have been around the industry a long time. The first generation of healthcare interoperability was HL7 messages, which they did a great job of what they were intended for.

Which is establishing a standard for systems to communicate with one another in a way that was easy on the sending system. In other words, if the sending system had something to say, it said it and it would put it out there on the wire.

Anybody who needed to know about it had to be listening in order to receive that message because 10 minutes from now, that data’s gone. It’s ephemeral. The other thing is, if it’s important for that message to get to its destination, there needs to be queuing mechanisms in between, store and forward mechanisms.

So it really is a standard that’s… I see two main things about HL7 that are important. One is this emphasis on the convenience of the sending system. The other is that the messages that are sent are triggered by events in the real world.

For example, if a patient is admitted to the hospital, that admission triggers an admission message in this interoperability ecosystem that the system you register the patient in, sends this message to anyone else who might be interested.

That got us really far, that started in the early nineties, and it’s still in use today. I forecasted it’ll be in use forever because that event-based model of healthcare is too useful to discard and we don’t have a replacement for it.

Even as other forms of interoperability came along, HL7v2 continued to live side by side with it. The second generation of interoperability that came along was document-based interoperability. This coincided with the rise of cross-organizational interoperability.

Because when you’re communicating with another organization about a patient, oftentimes you want to send a patient summary or the complete patient record from one organization to another. And so packaging up that data as a document in CCD or later in CCDA format makes a lot of sense.

It’s a structured document that can encapsulate everything you need to know about the patient and send it to a destination. This has the opposite problem of the HL7 messages. The HL7 messages are quite granular in terms of what they’re talking about, whereas the CCD documents are extremely large.

They have a ton of data and they talk about everything to do with the patient. You have both extremes right there. And then the current generation of interoperability is based around FHIR resources, which in that sense it strikes a balance between too small and too large.

The resources are intended to be useful size chunks of data about a patient. They can be transferred individually. So it’s a little bit in between, but it doesn’t use the event model. It uses a request response model primarily, which puts the onus on the consuming system.

而不是发送者能够发送他们convenience, the consumer is able to ask for the information on demand at the consumer’s convenience, which puts a little more burden on the server or the source of the data because they have to be always ready to receive these inbound requests and service them whether they’re getting one at a time or a hundred at a time.

Charlie Harp :

That’s an excellent point. I think that one of the misnomers that I hear from folks in healthcare from time to time is that FHIR is everything. I think you make an excellent point that HL7 is a very specific type of message.

It can be as granular as it has to be or it can be more expansive. You can send a patient summary with HL7 if you want it to based on a trigger. I think that CCDA… I mean when CCDA first came out, the CCD came out.

There were these competing standards, there was a little bit of controversy around that, and we ended up with what we have today, which is the CCD or the CCDA, which is a little text heavy. HL7, nothing wrong with the good old delimiter. It’s nice and parsimonious, you get it.

All of these standards, and I don’t know if FHIR’s going to fall into the same trap, but the whole idea, if you’ve seen one format, you’ve seen one format. I think there’s still enough variability, especially when it comes down to the vocabularies.

There is no magical answer to the question of how do I exchange data? I think in some ways because people gravitate towards, well, why aren’t we doing this with FHIR? I don’t know. When you look at the stuff that we’re doing with FHIR casting and all the other things that are moving down, do you think that FHIR will supplement the CCDA or replace it?

Do you think that… ? You’ve already stated what you thought about HL7, and I agree with you that I think HL7, it’s a relatively mature thing. I don’t know that we need to do a bunch of rework to replace it with some FHIR mechanism, but what are your thoughts on FHIR and CCDAs?

Drew Ivan:

Yeah, good question. The easy answer is it’s too soon to tell. The other easy answer is the one that I’ve been giving which is, all three generations of standards will continue to live in perpetuity. But you’re right.

I mean, FHIR has a shot at replacing CCDA as the standard for transferring documents because you can assemble much more interesting documents in FHIR versus CCDA, which it prescribes the different templates that you’re allowed to send.

And then you fill it up with the appropriate data and send it. As long as you’re thinking about the documents as documents and you treat them as an entire XML document, they’re reasonably easy to work with.

But wow, if you have to get into the XML and find specific data, or heaven forbid, you want to map every field that was sent, it’s drudgery to get into those XML structures and pull the data out. It’s not something that you do for fun. I think FHIR has that advantage too, of being a little bit easier to work with as an interface analyst.

Charlie Harp :

嗯,我认为FHIR,当你思考为什么Grahame Grieve created it originally, it’s almost like it was designed for a very different type of interoperability. It was really meant for, I want to build an application or interface that consumes resources from a system, and I don’t want to really have to worry about the canonical structures of that system.

I want to be able to do a quick query, say, give me this information about the lab results for John Doe because I want to do this clinical display or I want to do this thing. I think what happened was people realized just how useful that canonical normalization was.

I also think frankly, it was fueled by the disappointment with the HL7 Version 3 and the RIM model activity that we’d been toiling over in healthcare for a number of years and really not advancing that at all.

I mean a lot of people were talking about it. There was a lot of debate about the standard, I don’t know how much you got involved in that. I was peripherally involved in it, but it was just one of those things where people just did not want to execute on it.

And then FHIR came out nowhere almost as something that just was very… Initially it was very simple, it was very clean, it leveraged a nice structured way of communicating. I feel that’s why it took off. One of my fears is that sometimes people take something good and they try to use it for something that it’s not intended for and it ends up being a bit of a struggle.

Drew Ivan:

Your history is exactly right. I think Version 3, the way I perceive it is they tried to model all of healthcare so that no matter what you wanted to do, there was a home for it. And that turned out to be an insurmountable task. The standard almost collapsed under its own weight.

What we were left with is the CCDA format, which is the part of V3 that survived and it’s still complicated. I think you’re right. FHIR was in part a response to the… So everything that they did in V3, they did the opposite in FHIR thinking that if V3 was a big failure, that the opposite must be a big success.

They turned out to be largely correct. I think where you’re right is that it can be overloaded with jobs to do. The danger of that is FHIR, I think by intention, is built around the same standards that everyone uses to build other web solutions, other API solutions.

FHIR uses REST-based API calls, which that’s what everybody uses. So it will attract developers from outside of healthcare because it’s familiar. The advantage of being inside of healthcare is really not knowing these arcane formats from the nineties.

The value of healthcare is knowing what’s going on in the workflows and the data schemes and understanding the business of healthcare to such an extent that you can build proper interfaces. We see that from time to time of, you try to apply the Silicon Valley startup model to healthcare and it fails because it’s a different business.

It’s qualitatively different from other businesses and you can’t use the same tactics. I think your concern is justified in that respect that if healthcare outsiders come in and try to build healthcare solutions on FHIR without understanding the business first, then they could have some trouble.

It’s not to be exclusive or protective of our domain, but just to caution newcomers that it is a different industry from others and you need to spend some time understanding it in order to work productively here.

Charlie Harp :

嗯,我认为我的一件事lways tell people when I’m working with a client or I’m out there talking to people in the industry. I’ve been in healthcare for almost 35 years and I’ve worked in other industries, not as long as healthcare obviously, because I’m not a hundred years old.

But healthcare is different because it’s one of those industries where it doesn’t evolve from the center, it evolves from the edges. Healthcare is constantly reinventing itself from the edges.

I think every attempt we make to control it or standardize it or do things from the center without having the flexibility to let the edges inform us, it resists that. When people try to do that, I think ultimately they fail.

One of the nice things about FHIR and the way FHIR came about was it was pragmatic. It was very straightforward and very pragmatic. That’s where I think when I look at HL7 and V3, I think you’re right. What they tried to do is say, “Well, this is how healthcare works.”

这将工作if we were an industry that evolved from its center based upon some ideology. But in reality, healthcare is constantly shifting and changing because the people on the front lines are practicing medicine. They’re not just executing instructions. I think it’s a very different industry compared to a lot of the other things we see.

Drew Ivan:

Yeah. It has a lot of specific regulations. It has a lot of big established players that they bring competitive forces to the industry, that they have the things that they do well that they want to protect, and at the same time they want to attack the other parts of the industry because those are also big.

So you get a lot of, I call them sneak attacks. You’ll get a payer trying to do a project that solves a clinical problem because it’s going to lower their costs, but maybe it takes over a piece of what has traditionally belonged to providers and vice versa.

They all do it to each other. And so you end up with a lot of interesting innovations that happen all over the place all the time and both drive and slow down the progress of the technology and the standards.

Charlie Harp :

Well, I think you’re absolutely right. I think that historically in our industry, a lot of what we did was track activities. A lot of the terminologies we work with, a lot of the things we do were really built to track transactions in healthcare.

I think that more recently, because I always struggle with when I would talk to people about data quality and why the quality and interoperability is really important, and sometimes people struggle to understand that.

I think a lot of it was because traditionally, we track transactions in healthcare and schedules. I think Covid and our shift to value-based care shine a big spotlight on the data and what we can tell from the data.

Because if all of a sudden I’m at risk or I’m trying to figure out what’s happening with folks or why certain people are succumbing to Covid and others aren’t, if we have good data, it’s invaluable to help me make good decisions about what’s going on. I think that is…

I’m seeing a lot of activity, a lot of trends moving in the direction of people waking up about why they need good quality data. Why they need to understand what’s happening across their organization and at other organizations with the patients that they share responsibility for. It makes me feel optimistic about where we’re going as an industry.

Drew Ivan:

The Coronavirus vaccine is both sides of that coin. It’s like the highest most amazing achievement of interoperability. At the same time, the worst failure because the industry developed a vaccine in whatever it was, 15 or 18 months. Some of the companies at least did it without ever having a sample of the virus.

They sequenced the virus’s RNA, and that’s all they needed to build an mRNA vaccine. On that side of it, it’s like a technological miracle that we’re in a place where we can develop vaccinations for a virus that the vaccine maker has never even had in their possession. So that’s the good side of it.

But our vaccination records are on paper and you have to keep track of this little card and have your doctor fill out the date that he gave you the shot and the lot number and everything. Why isn’t that interoperable? It’s like both extremes of the interoperability landscape in a single event.

Charlie Harp :

Well, when you look at that, the latter example, when we look at our healthcare data, I think that’s one of the things that I, as a patient or as a consumer, struggle with. I’ve got this rectangle in my pocket that can tell me down to the minute, the best route to get me from here to New Jersey.

But at the same time, I can’t seem to get my lab results in a meaningful way. And so it is one of those things where we do have such amazing capabilities to share information, but these barriers we have in healthcare, it is a little frustrating.

I think that it’s one of those things where it’d be nice if we could nail some of these things around semantic interoperability, syntactic interoperability, drop some of these barriers, improve how we share things.

Because it’d be pretty slick if you could look at your phone and see all your up-to-date information, know whether or not you’re eligible for a clinical trial, know that the medication you’re on, maybe there’s a better opportunity for you or a better option for you.

It just seems like there’s so much we should be able to do if we could just nail down some of these issues we have with sharing and improving the quality of our data. But like you, I’ve been around long enough to know that it’s not that simple.

It’s not just as simple as, if we could apply this technology, if we could do this thing over here, then it would magically fix the problem. There’s a lot of moving parts in healthcare.

Drew Ivan:

Yeah, we’re starting. I’ve been experimenting with Apple Health and for me, I’m able to download my entire medical record, but that’s only because I get all my healthcare from the same institution and it happens to be connected to Apple Health.

It’s pretty nice, but it is just all the facts parsed out into an easy to read way. It doesn’t apply any insights like, “Hey, you’re eligible for a clinical trial or you’re overdue for a procedure.” I mean, all of that still has to come from the doctor.

这不是应用程序的一部分,但我们有冷杉t step, which is at least in some special cases for people who are fortunate to have all their healthcare at a single provider that’s connected to Apple Health, you can at least get the data onto your phone.

Charlie Harp :

That’s very true. Before we sign off, any interoperability stories, any fun stories you want to share with folks at home?

Drew Ivan:

I was thinking this morning about something. Maybe this is a big question, it’s a topic for its own podcast, but it’s more in your area of expertise which is, when I think about code sets that are in use in healthcare, the participants in the healthcare solution are not using different code sets because they don’t want other participants to not understand what they’re saying.

They’re doing it because they’ve chosen the code set that is optimized for their business use cases. Payers use ICD codes to represent diagnoses. Researchers might use SNOMED, laboratories use LOINC codes to report results.

In some ways, these are all translatable to one another. In other ways, it’s a very difficult task to translate a LOINC code to a SNOMED code. It’s because the way that they are describing the real world is coming at it from a different point of view.

It seems like that translation process isn’t just like a dictionary translation or a code crosswalk. It really is having to understand both points of view, both the laboratories’ point of view and the researcher’s point of view.

And then the interface that you build to make that translation is really a business solution of how do I translate the operational lab data into research data, which seems like a heavy lift for an integration engineer.

This occurred to me this morning when I was preparing for today’s podcast. I thought I’d bring it up and see what your take was on that. Is that off base? Is it a crazy thought to have, or is it the case that we’re actually asking interface engineers to solve these complicated clinical and business problems?

Charlie Harp :

Well, Drew, I think you’re completely mad. I’m going to terminate. No. I think it’s interesting because I’ve spent a lot of time looking at SNOMED, LOINC, RxNorm, ICD-10, ICD-9, and you’re absolutely correct. ICD-9 and 10 are classifications. SNOMED is a clinical terminology. LOINC is hyper granular when it comes to…

There are 812 codes for glucose and [inaudible 00:38:40]. What I always tell people is a terminology was built for a purpose and it has an editorial policy. If you try to go from one to the other, there’s a certain amount of, I call it editorial impedance where they’re not exactly the same.

We try to cope with that in our products through this thing called the cognition engine, which takes a term and breaks it down semantically just so that it exists in an information model. One of the most challenging areas where people struggle is allergy classes, because I can say an allergy class, but the knowledge of what I mean by that word is it’s not semantically rich.

I could call drugs Charlie doesn’t like, and that could have 15 drugs in it. The person trying to map that is like, “Whoa, I better get Charlie on the phone and find out exactly what drugs these are” because you can’t semantically transition from one Charlie to another Charlie.

The thing that we struggle with even more than that though, is that a lot of systems still today use proprietary codes where somebody, when they were setting up the system, sat down and said, these are the drugs, these are the labs.

For example, with labs, when people name labs in a proprietary code system, they tend to not worry about the method and all these other things unless they’re relevant to how the clinician is going to interpret the result.

So when they go to map that to LOINC, they start out with a code called glucose serum and it’s got a result unit of nanograms per deciliter, and then they have 812 LOINC codes to choose from. You run the risk of them mapping it without really a full contextual understanding of the target.

And then if you have a bunch of different people mapping a code called glucose serum to LOINC, the very same person can map to a different LOINC code on a different day just because they didn’t have their coffee that day. So I think you’re right.

I think that what we try to do when we’re dealing with the semantic interoperability is look for semantic consistency and try to understand when the information that’s missing, when you’re going from A to B, when it’s relevant.

What really has to happen is somebody has to pick up the phone to say, “My target is very specific and I don’t know enough based upon what you sent me, to be able to pick something that I feel confident in if it’s going to be part of some kind of clinical reasoning.”

But I think that we’ve made really good strides in creating things that helped reduce that. Because in the old days, the way you dealt with that was it wasn’t necessarily an interface.

I would never put that on somebody who doesn’t have the clinical experience. So what you end up with is this sweat shop of clinical people that are toiling away mapping acetaminophen to acetaminophen and that’s no fun.

Drew Ivan:

Not why they went to medical school.

Charlie Harp :

Exactly.

Drew Ivan:

是的,你是对的。因为也有情况时re you don’t really care. I don’t care which glucose it was. I just care that this patient is getting tested regularly because I put them on a diet management plan. There are cases where the nuance that’s built into those 800 codes doesn’t matter.

But you can’t make that assumption that the user doesn’t care because it could equally be important that it’s an endocrinologist who actually does care about the exact way that the sample was collected. You have to do the job for the most strictest used case and hope that that’s satisfactory for all the others that are less strict.

Charlie Harp :

Well, but there’s actual interesting… What’s the word I’m looking for? There’s another version of that story, which is sometimes going exact. Imagine if I’ve got a bunch of lab results and they have a certain amount of granularity and I’m mapping it to LOINC and I map it perfectly to LOINC. But the person who’s receiving the data wants to look at trends in the data over time.

We tend to do that with value sets, but they have to have the ability to line that data up. If everything is mapped to a hyper specific, even though it might not be clinically relevant LOINC code, I can’t really use that data to look for the trends unless I have a mechanism for broadening that information.

The same thing is true when you look at people’s clinical records. We have value sets because we have to periodically go in and roll things up so we can create a clinical summary. Instead of having 28 different codes for diabetes, I just want to know that the patients has type two diabetes mellitus.

We tend to do that after the fact with value sets to roll things up. But it is interesting, and it’s one of the things that we run into. When we help clients with mapping, they’re like, “Why isn’t there just a big map in the sky? Or why can’t you just have a room full of people somewhere else doing this for me?”

And it’s like, well, because what you want to do with the data matters because I’ve had people that go through and they build a map and they haven’t really thought it out ahead of time and they end up having to do it again.

Because they didn’t really sit down and think about what is the purpose of why I’m mapping and what should I be mapping to? They just map because they think they’re supposed to map, and that doesn’t always end well.

Drew Ivan:

Yeah, and that’s the perfect example of what happens when a non-healthcare developer comes into healthcare and starts building API-based integrations. They see a field that says diagnosis or procedure code, and they just map it into the one with the same name on their side and doing it naively like that.

Or not being able to do it and then asking that question, “Why isn’t there a dictionary in the sky that I could consult?” These are the types of questions that can turn out to be showstoppers for those who are new to the healthcare space.

Charlie Harp :

So here’s a fun story. Years ago I worked for First Databank. First Databank has terminologies for drugs. In their allergy suite, they have multi ingredient products, allergy classes and cross sensitivity groups. I was working with a company that did the emergency room software, and they were working with a group of developers that were contractors.

They were not healthcare, they had no healthcare experience. I was meeting with them and they said, “Hey, you don’t have an interface, an API that brings me back a list of all the cross sensitivity codes.” And I said, “Yeah, we don’t because a cross sensitivity is part of the algorithm for checking to see if you have an allergy in a cross sensitivity situation.”

And they said, “Well, we really want an API to get us all the cross sensitivity codes.” And I’m like, “Why do you want that?” They said, “Well, because it’s the shortest list and we want that to be the pick list when people are selecting allergies.”

Drew Ivan:

Oh, no.

Charlie Harp :

I said, “No, you can’t do that. That’s crazy talk.” Just because it’s the shortest list. But they were so focused on the interface and trying to simplify the interface with no understanding of how the underlying data was meant to function.

I just wonder how many times those things squeak out the door before people realize, wow, that’s totally inappropriate. We shouldn’t have done that.

Drew Ivan:

In my experience, they don’t squeak out the door. They march proudly out the door, but they get sent right back home when the doctor sees it because in this case, the users are highly trained people who care about these things and they’ll look at that and they’ll send it right back. That’s our safety net is that we have smart users even in cases where we don’t have smart developers.

Charlie Harp :

No, I think that’s very true and they’re very passionate too. It’s one of the great things about… It’s one of the reasons why I love healthcare. The users, the people that are delivering care to patients are very passionate.

My first healthcare job, I hate to admit this, but I was working in a hospital lab and I had an emergency room doc coming in and yell at me and really impress upon me that, “Hey, if we don’t get these results, if these things don’t make it out the door, people are going to get hurt.”

It’s one of the things that I remind everybody that works for me is that we’re not just building software to move widgets around or to make sure people get paid for things. We’re really doing something that ultimately helps people. It’s one of the other really cool things about being in this healthcare space that I appreciate every day.

Drew Ivan:

Yeah, me too. That’s why I’m here. I bounced around between jobs in a few industries before I quite accidentally got into healthcare IT and thought I could make the next video game. I could make the next Angry Birds and become rich.

But in 40 years, if we don’t have a healthcare system because it’s all collapsed around us, then people are going to ask me what I was doing when I could have been avoiding that.

If there’s a reason to be in this space, it’s because it’s something that everybody needs and is in a lot of ways badly broken and needs the attention of smart engineers to help fix it.

Charlie Harp :

Yep. And you’ve also got to be patient with the fact that we’ve been more disruptive in the last 10 years, but healthcare resists change just because of the critical nature of what we’re doing.

It’s not something you can just pivot on a dime, and so you have to be patient to a certain degree. Hey, Drew, I really appreciate you taking the time. Anything else you want to share?

Drew Ivan:

No, thanks. This has been great. I loved it.

Charlie Harp :

Me too. We’ve just started working with you guys, but I got to tell you, clinical architecture, we’ve really enjoyed the spirit of partnership with Lyniate and we’re really looking forward to continue to work with you guys going forward.

Thanks again for today and thank you everybody for tuning in and listening to the Informonster Podcast. I’m Charlie Harp with Drew Ivan. Thank you very much and have a great one.