How Post Coordination Can Improve Access to Clinical Data

Carol Macumber:
Welcome to Clinical Architecture’s Data Quality Theater. My name is Carol Macumber. I’m the EVP of Client Services. It is my utmost pleasure to be able to introduce our opening act, Dr. Stan Huff, whose intro really can’t be summarized, so I’m going to try to do my best to keep it short. Listing all of his accomplishments would take all day. So Stan is the current CMIO at Intermountain Health and Graphite Health and a professor at the University of Utah. He was a early influencer of the UMLS and a founder of Clinical LOINC. Again, can’t really summarize everything that he’s done. What I can say is that the standards world would not be the same, nor would the folks who have grown up in his shadow would they be influencing the standards world without Stan. He is also a former, I think twice over HL7 board chair. I’m going to keep going. Okay, so he’s also a twice over former HL7 board chair, a role that I’m currently stepping into, and I can only hope to do a justice in the same way. So without any further ado, Dr. Stan Huff.

Dr. Stan Huff:
Thank you so much. It’s a great pleasure to be here and I hope I can say something useful. And my goal is to do my talk and have time for questions. So think about things you might ask. Just to note that the work I’m going to present is also work that Nathan Davis has contributed to, and he’s a coworker at Graphite and a great guy. So we get some value out of him as well. So the goal that I’ve had for a long time is interoperability, and my perception of that has changed over time or my definition of that. We have a good level of interoperability now based on FHIR and LOINC and Yum and RX Norm and a bunch of other standards.

But what I want now is plug and play interoperability. And what I mean by that is that we have a stable enough representation of the data that people can write applications against it and people can certify their system, their backend, their platform against the standard, and those applications can then be plug and play. So if I’m an application developer, then I create one version of my application and it will run anywhere on that semantically interoperable platform. And that’s certainly not the case today. And so that’s what I’m focused on. And when I talk about semantic interoperability, it needs to be like your phone. You can go and download an app and you can immediately begin running it. Now, it might take longer for us to do that. The technical part shouldn’t take any longer, but there’s always training and other kinds of things you need to do if you introduce a new application into the healthcare environment.

But that’s what I mean, that’s what we’re trying to target and what my goal is. So to do that, there are three things that we need to do. You need to have a single preferred representation for the data. Now, when I say that, I don’t mean we all have to do JSON or we have to do something else, but the logical model is the same. The name of the data elements and the value of the data elements and the units of measure you’re using, all of those things have to be consistent. And so to do that, to get that unambiguous representation, you have an information model, and then you have standard codes and terms, and then you have to have, and those first set of terms are the names of slots or nodes in the model. And the second set of things then are codes that take values of those.

And I’ll show examples of that. And my purpose in talking today is really to talk about the value of post coordination. And I’ll say what that is. So here are two representations. This is kind of pseudo pseudo FHIR representation of these things. And there’s a LOINC code here that says means this is a body weight that was estimated as opposed to measured. And then the alternative representation, there’s a different LOINC code that is a more general code that just says body weight. And then you can post coordinate with it, the method that says, oh, this was done as an estimation. And then you have the actual value. In both cases, you have the actual weight there. So this is a pre-coated representation. In other words, two meanings are put together in one code pre-coated. And post coordinated means that in the message I have two different codes with values. And so that’s pre and post coordination. And what I want to talk about today then is the value of doing post coordination as a policy.

So to go back a little bit to just fundamentals of LOINC and what I’m talking about has a lot to do with the principle from the start of LO was that we wanted to make codes for clinical data elements that had the same clinical meaning and different codes for different things. So that seems pretty simple, but if for instance, it’s obvious that a measurement of serum sodium is different than a measurement of serum potassium, it’s also clear that if you’re measuring the mass concentration of something in urine, that’s different than measuring the molar concentration. So those kinds of things. And so there’s a set of things that clearly delineate things that are the same and different. But if you get to things like a bilirubin measurement for instance, one of the challenges we’ve had is that in some situations the bilirubin is a bilirubin and in other cases the bilirubin actually the method by which you did the bilirubin becomes important.

And so there’s this fuzzy ground when you’re trying to implement that rule that says you really understand the use case to know whether these two codes are different or the same. So another couple of principles, just for purposes, and this is kind of just self-serving because I see this as a common error when people are mapping to LOINC and using LOINC, the LOINC code never, ever, ever has all of the information you need to know to unambiguously and correctly compare two different results. You have other things that have to be there. The unit of measure, the reference range, the method is often important. There are all kinds of other provenance information. Who ordered this test? Who was the patient it was done on? I mean, this is pretty clear, but people make errors and think, oh, all I need to do is map it to the closest LOINC code.

And I can assure clinical comparability of the data, but it’s just not true. So we’re also, my migration of this, or my bias on this too, is that we often think about just the use case of transmitting data from one system to another. I really want LOINC codes to be part of the data when it’s at rest so that it’s part of the definition of that data from its inception. And so part of this is inspired not so much by transmission of data though it’s important there as well, but it’s also to say, I really am talking about the representation of data when it’s in a data repository.

So the challenge then becomes, well, how much information do I put into a LOINC code? And I’ll show examples of this. So this sort of shows the challenge that we have. So in LOINC, there are 122 active codes for systolic blood pressure. Now, that’s not a failing of LOINC. You might think that’s a criticism, but it’s not. It’s important. The codes are different for important reasons. So you have this very generic systolic blood pressure code, but then you have systolic blood pressures that said, this is a blood pressure when the patient was lying down, when they were standing, when they were sitting in a laal or a light. And I’ve got invasive blood pressures versus non-invasive ones that I determined by palpation, ones that are in the left arm and the right arm one and post-exercise, all of those kind of things. And so those are all important distinctions in the use of the data.

But as you can see, these are highly pre-coated codes except for this one. So if you look, and this is just a sample from that 120 codes, what you can see for instance, is you can see that you’ve got names over here. And for instance, these first five codes, six codes, well for the first five, they’re identical except for the method, whether it was invasive, noninvasive by palpation or by CAP, etc. These last two are different based on whether the patient was sitting or standing. So what I’m proposing is that we approach this in a different way and we represent the information that’s in all of these guys as a post coordinated representation rather than a pre-coated representation. Now, the way we would do that is that we would make a link between this generic code and a value set for that blood pressure method.

And so what that’s saying is with this code, we would make a link and we would say, oh, methods are important. And so there would be a value set and it would say invasive. And so these things that are possible values and are changing in this pre-coated codes, those things would be part of a value set. And I’ll show you the data representation here on the next slide. But the same thing would go on for the sitting and standing. So it’d have a patient position attribute and it would have a value set and it would have possible value to sitting, standing, supine, left lateral decubitus, all of those kinds of things. So when you look at the data representation of these things, then what you have is it in a pre-coated representation, you have something that says this is a systolic blood pressure in the sitting position, and then you have the value of that 120, and then the post coordinated representation actually has some more information than the other one.

But you have the generic code that just means I’m a blood pressure. And then you have a method code that said, oh, I’m a noninvasive measurement, and the body position was sitting. So this is the post coordinated representation of that. Now, I’ll describe it here, and I think I mentioned it on another slide. The advantage of this representation is if I go back here, this code, now I can search for this code and I can find all blood pressures, all blood pressures that exist in my database, and then I have, but I haven’t lost any information because the information that we’re making those different codes is now represented as separate attributes in here. So what I do is if I don’t care whether it’s invasive or non-invasive or I don’t care about sitting position, I just retrieve them all and I calculate against that number for the patient’s systolic blood pressure.

On the other hand, if I care and I only want non-invasive or invasive, then it’s like a SQL query. You say, well select all of the data where the code is that and where the method is this or the body position is this or both. And so you have a tremendously simpler way to access data and not lose any of the information that’s in those pre-coated codes. So these names of these attributes are standard LOINC code. So there would be a LOINC code that basically means that this is a blood pressure method and there would be a LOINC code that says this is the body position. And those things are connected then to values from a value set. So when you set this up, the name of the attribute and the name of the value set or the allowed codes that can be used in those positions in the representation.

So just doing one more specific example, if you’re looking for RIA gonorrhea, DNA, same kind of thing is going on here. You’re looking for RIA, gonorrhea, DNA, it’s all presence or threshold whether or not that DNA is present in your sample, the patient. And then you have this very large set of places where the specimen could have come from. It could have come from a genital specimen, from throat, from the urethra, from urine, from vaginal, et cetera. And then you have some variation going on as well in the kind of technique you’re using to detect that DNA in the sample. So it’s really analogous to what we were doing with systolic blood pressure, but with the DNA. And so again, if you look at the actual representation of data, you have this representation and you have RIA gonorrhea, DNA in the genital specimen by NNA, and over here on this side, lemme go back here on this side.

Then you have the more generic code that just says, I’m attest for RIA gonorrhea, DNA. And then I say, and it was on a genital specimen. And oh, by the way, this is the probe method that was used, which is a synonym for this, a thing positive in both cases. So same thing going on, same situation in terms of most clinical cases. All you’re going to care about is if I find RIA gonorrhea, DNA in any fluid of the patient, I’m going to say the patient has RIA gonorrhea. Now how you treat it may depend on where the infection is, and that will be really important, but it means that I can do a query, a very simple query for one code and find all of the RIA gonorrhea DNA results, and then I can take that additional information into consideration if that’s important for my use case.

Now, one of the things, and this is about the data at rest, if I get this code as incoming data, then as a good practice, I want to retain that code in my output so that I know the pre-coated code that this information came from now. And most of that just comes from my experience that I’ve made mistakes before and if some reason I didn’t represent all of the information accurately for this code, this is a link so I can get back to what I had as an incoming input and I can fix my error and then move forward. Now, all of this is presumed basically and implies that you have an information model or a logical model in the background that is saying everything. You can see everything that is needed to represent that kind of RIA gonorrhea data. And so you have, this is the model if you will, that says, this is the LOINC code and this is the original LOINC code from the value set.

And then you have the value. So this is saying, I’m looking for RIA gonorrhea or whatever, and then I’ve got, this is the value set binding that says the values that are allowed for this test are positive and negative units of measure aren’t used in this test. The threshold or cutoff is not used in this particular test. The interpretation can be normal or abnormal. That’s optional. And then the method is optional screen confirm, so I won’t go through the rest of it. You also have the provenance data down here, but what it says is this is overall, and if there’s some element of this kind of data that is important for understanding what it means, then we would put it in here. So this is just an example, and there might be other things that I haven’t thought of or that I haven’t seen in data yet that would say, oh, there’s additional information that we need to make part of this model. But the primary representation here is to say you need a model like this that describes exactly how you send data. This is the kind of model, for instance, that you would use to create applications. This is the basis for creating plug and play interoperability because everything that you would share or everything that is contained in the data would be described against a formal model with terminology, bindings and all kinds of other constraints that say what’s required and what’s optional in the representation of that data.

Again, I’ve said these things before, but the real purpose of this post coordination is that I can do easier querying using subception logic on the LOINC code. And then when you want a specific subtype, then you look for what the specimen type was. And if you care about general people using the data then can decide whether for their purpose. I mean, for instance, in routine clinical use, you may never care about the method. On the other hand, if what I’m doing is actually comparing two methods to see if they’re the same, then that method would have to be required. But it’s all part of a common model from which you then can say which things to use. The other thing is that one of the challenges in how it came about in LOINC is that people have a hard time choosing the right code in lo, and they see this long list of pre-coated codes and they see the generic code. And if they don’t see the method that they’re using in their particular laboratory as a pre-coated code, then they use the general code and they don’t send the method. And so then they have a hard time choosing which code and then being able to send all of the information that’s really needed. And it makes maintenance easier as well because we just have fewer codes and all we’re doing is maintaining some value sets instead of maintaining or making longer and longer lists of pre-coated codes.

Just in terms of what LOINC is doing as an organization at Regenstrief, what we want to do is make then, if there are a whole list of these more specific codes, we want to make the general parent code that subsumes all of those codes. So that’s what this thing says is that we would make that generic and then we would make the coded value set for the attributes that are post coordinated. So that’s like the method and the specimen type and all of those kind of things. We would make those also, we would make LOINC codes for those things and attach the value set to those items. We won’t delete or inactivate any of the pre-coated codes that already exists. We won’t automatically make pre-coated concepts when nobody asks for it, but we’ll make free for use mappings between the pre and post coordinated codes.

So the way that looks like this would be publicly available and freely available. This is what the work that Nathan and I are doing, specifically at Graphite, we’re making these codes that say, oh, if you have this pre-coated code, that means erythrocytes number count and blood manual count, that can be broken down into the more general ER site code and the method code with this particular value that says this is a manual and these guys are coming from SNOMED and similar. Now you could make it maybe a more convenient file format for this, make these guys all columns or something. But the idea is that this map allows you to say, oh, if I get this code, I know I can represent exactly that same data with this combination of codes. And likewise, and would come into play sometimes is if I get the data in this form, I can actually assert that this is true as well.

And so that’s a public map then from one side to the other. So the whole idea then is that if you’re trying to create semantically interoperable data, you don’t start thinking, what LOINC code do I use? Whatever I do, you query against that library of models, models that look like that iria gonorrhea, DNA model, and you’re not looking at a library of codes and terms because those things are already incorporated into the model. And so you select the model that’s appropriate for their use, they see the attributes that are available and they pick the ones that they are interested in or that are important for their use case. And then you use that model then to refine and define queries to find data and to fill out the values for the storage of the new data in a database. So that’s the way it fits into the workflow of application development. So that’s it now. So I’m ready for questions or thoughts or comments. Yes.

Audience Member:
Hi, I am Dave Parker. I work with the VA. Hi, I am Dave Parker. I work with the VA and I do an awful lot with LOINC. And lemme tell you, I would love this implementation. What do you see as the barriers to making it happen in practice? Perhaps incentives for people to do it. I’m not sure what it.

Dr. Stan Huff:
Technically you have to have a lot of models. I didn’t say that, but even to cover maybe the top 99% of data that we see would probably require 15,000 models or so. Now in Graphite, we’ve made a bunch of those. Those are publicly open free for use, but I don’t know what we’d have to do to incentivize it. I mean, some people would probably just use it because, hey, that makes my job easier. And I think the application developers would want to use it because it’s going to make their software semantically interoperable and it’s going to decrease the cost of them producing and implementing their software probably by 60% to be able to make one version of their software and move on and let somebody else worry about standardizing to this standard. But I am better at technical stuff than I am figuring out human motivation. So I need your help with that. Other questions? Yeah.

Audience Member:
I’m old VAAs NCQA. I really love this talk. So I used to be an enterprise architect in my previous life focusing on information modeling. And so this is all just gold for me. What I would really like to know is terminologies are at the heart of Symantec interoperability. What if the post coordinated scheme was something that the source system adopted? Say that again. What if the post coordinated terminology, it is something that we can influence the source systems of record to adopt.

Dr. Stan Huff:
So that’s like heaven. And I mean, my thoughts about that are that I want to make it, I want to enable it, and I want to be able to have working systems that are showing the value of it. And then what I assume is the architects that are existing in the EHR guys will go, Hey, that looks good. That would help us. And again, it becomes political because right now I think a lot of them treat that internal model that they’re using in the internal terminology as their proprietary special sauce. And that’s kind of bad for everyone.

But I think I would try and do it by example by showing implementations that have value. And then I don’t think you’ll have to nudge them very much and they’ll go, yeah, we can do that. Or at a minimum they could go, well, it’s an easy map from our internal pre-coated codes or whatever. A lot of them are already trying to map to LOINC and SNOMED because they’re putting things into public databases that are where you can do federated queries or do other things. But I think I’m not going to go on the bandwagon trying to convince them to do it until we have things working that are useful.

Audience Member:
I think that’s the right way to go to influence showcasing the good things that happen. But I think one of the good things that can happen is the overall increase in the quality of data. I think that’s the one thing that we can definitely use.

Dr. Stan Huff:
And we’re in the right place for that. A lot of you there meetings will be meetings about the PIQI Framework and other things, but that’s, see, if somebody had asked, well, what doesn’t this help with? Number one, this doesn’t say anything about what data you should collect and you have to have agreement. And that comes from clinical experts, not from technical representation. I got to ask cardiologists, if somebody comes in with chest pain, what are the things that you need to know to make an accurate decision? So that’s one thing. The second thing is knowing comparably how to do the other parts. What I mean by that we say glibly in patients with asthma, then something. And people rarely define what they mean by asthma in a computable sense. So we know what it means from what I call a textbook representation where you say it’s restrictive airway disease that causes this and the patient coughs and other stuff.

No, when I say computable representation, I mean, what can I measure and see about this patient that I can classify them without doubt as a diabetic or as an asthmatic or as a somebody else. Again, that is all coming from clinical people that have to do it. And then there has to be a commitment once the data elements, there has to be a commitment to actually send that data in an accurate format. And that’s a challenge as well. And I’m maybe stealing thunder, but Charlie and clinical architecture did some work. They were just looking at what is the data quality of things? And there was one institution that, I don’t know who it was, every single piece of lab data was labeled with the LOINC code for glucose.

I only, I don’t know. I know that’s not good for patients, but I was trying to think of their motivation, and I guess the motivation would be the regulations say that I have to use LOINC codes in my lab data. I guess the regulation didn’t say, you need to use the right LOINC code in my lab data. So they just put glucose LOINC code in for every single hematocrit, hemoglobin, glucose, everything. So you got to do that too. You’ve got to have a commitment to actually try and use the data the way that it’s been specified. But there just a whole, this is just one part of the problem of creating real interoperability as an ecosystem, if you will. So I think my time is up. I don’t know, is that, so I think I’m done, but thank you so much for attending. I hope it was useful. And absolutely feel free to get ahold of me if I can be of value in any way in the systems and things that you’re doing. So thank you.