Episode 8: What is the USCDI? In this episode of the Informonster Podcast, Charlie Harp talks about the United States Core Data for Interoperability (USCDI), how the 21st Century Cures Act brought it into being, an overview of the data classes and elements, and some considerations that could impact its success.
Contact Clinical Architecture
• Tweet us at @ClinicalArch
• Follow us on LinkedIn and Facebook
• Email us at informonster@clinicalarchitecture.com
Thanks for listening!
Episode 8: What is the USCDI? In this episode of the Informonster Podcast, Charlie Harp talks about the United States Core Data for Interoperability (USCDI), how the 21st Century Cures Act brought it into being, an overview of the data classes and elements, and some considerations that could impact its success.
Contact Clinical Architecture
• Tweet us at @ClinicalArch
• Follow us on LinkedIn and Facebook
• Email us at informonster@clinicalarchitecture.com
Thanks for listening!
[inaudible]
Speaker 2:And this is the infer monster podcast. In this episode of the infant master podcast, we're going to talk about the United States core data for interoperability or us CDI. Now, before we get into the USDA itself, it's probably a good idea to talk about the 21st century cures act that brought it into being the 21st century cures act was signed into law by Congress in December of 2016, the intent of the act was to, and I quote, accelerate the discovery development of 21st century cures. And for other purposes, it represents an official recognition that healthcare can do better and establishes a roadmap of priorities to drive its evolution. Now like many things passed by Congress. It covers a lot of ground concepts like combating opioid abuse, advancing precision medicine, supporting young emerging scientists, medical device innovation, and advancing drug therapies. Just to name a handful. Now there is a section called title for delivery. Now within it are subsections that cover among other topics, quality of care, transparency, information blocking and interoperability. What's that interoperability you say yes, as we've discussed on this podcast words like quality quote unquote and interoperability quote unquote can mean different things. Now, do they happen to define what they mean by interoperability in the cures act? Why? Yes. As a matter of fact they do. And here's what it says. The term interoperability with respect to health information technology means such health information technology that AE enables the secure exchange of electronic health information with and use of electronic health information from other health information technology without special effort on the part of the user B allows for complete access exchange and use of all electronically accessible health information for authorized use under the applicable state or federal law. And C does not constitute information blocking as defined previously. Now for brevity's sake, I'm going to set aside the ambiguous nature of the term, a user and not scoff at the concept of without special effort relative to interoperability, because I fully recognize that their heart is in the right place. Suffice it to say that despite the Panglossian nonchalance of this particular definition, the mandate for inter-operability establishes abroad and aggressive goal for the sharing of patient information across systems silos and the intent being to improve the quality of care delivery. So it's all good. I would also argue that interoperability is generally an important part of data quality and data quality, significantly impacts discovery, population health, and it doesn't have other powerful initiatives in healthcare, not just delivery of care, but as long as we get there, I don't care what our reasons for getting there are. Now in order to achieve the objectives of interoperability in healthcare is defined. You need to establish rules for how the data is moving from place to place, how data is packaged and what data you require earlier this year, the office of the national coordinator released the 21st century cures act, colon inter-operability information blocking and ONC health it certification program. Final rule. Now this final rule is intended to implement many of the provisions of title. Four of the cures act included in this final rule, our mandates on the establishment of a trusted exchange framework or Tesco, the availability of software interfaces or API APIs to access patient data, the use of fast health, interoperability, resources, or fire to articulate the data and the United States core data for interoperability or us CDI, which describes a baseline set of required data elements. And that's what we're talking about today. Now, one way to think about the U S CDI is it's like a cast of characters or list of people that you'd want to invite to a party at your house. It doesn't articulate how they get there, because technically you can deliver these data classes and elements either by fire or by CCDA. But what it really tries to say is these are the people that must attend the party. These are the people that have to be on the show. And so I'm going to go through them. I'm going to go through them alphabetically. And I'm going to talk a little bit about the ones that there's something to talk about and just kind of share some thoughts about them and familiarize you with them if you haven't heard about them. So I
Speaker 3:Want to be shuffling through papers here
Speaker 2:Like that. So enjoy. So this is from the February, 2020 version one edition of the U S CDI. And it all starts with allergies and intolerances. So if those of you that haven't read any of my blogs or heard me talk about allergies or intolerances, they're all kind of intolerances. It's a distinction between what's an allergy and intolerance, but the bottom line is an intolerance, follows a pattern. The pattern is the thing you can't tolerate. And typically when you found this out, what the reaction was, and in some cases how severe the reaction is the things that are required in the U S CDI under allergies and intolerances are the substance and the reaction. Now, when you look at the U S CDI and its definition of allergies and intolerances in the USDA documentation, it tells you, here are the data classes and the elements we want you to deliver. And if you deliver it through fire, there are certain requirements and the same thing with CCDA, but they also can talk about what standards are applicable. Now, the interesting thing about allergies and intolerance under us CDI version one is they say that the way you communicate and tolerance is either for a medication or a drug class. If it's a medication use RX, norm of it's a drug class, you snowman, then there's the reaction, which they're also suggesting they use snowman to articulate the reaction. Now, what that means though, is that means things that are environmental allergies or substance allergies are not medications or food allergies are not really covered. At least not the way it's written, not the way I interpret it. And a lot of times systems that host these things well, they usually differentiate the type of allergy, but what they're really saying is you need to tell me if it's a drug or a class allergy, and here are the applicable standards to do that. The other thing that it talks about is this whole notion of articulating no known allergy, which you could use a snowman class to articulate no known allergy, and then the status as verified or unverified as to whether or not the patient told you they don't have any allergies. And I have a whole diatribe about no known allergies as a coded thing that I'm not going to get into. But the bottom line is using snowmen for the drug class. A lot of people are either use a third-party terminology, like first DataBank, Metta span, multiple to articulate class. And what this is basically saying is you have to map that to snomad. Since Andy FRT has been deprecated and retired and men are T is still a little fuzzy. So there's
Speaker 4:Mapping required here, and there's also mapping
Speaker 2:To get to medication as well. And they also specify the Yukon nomenclature for unit of measure under medication, but typically with an allergy, it's not the amount that you're allergic to it's the substance itself. So not sure why that's there. And by the way, if anybody listening to this knows the answer to these questions that I throw out or wants to comment, please send me a note and I'll include it. So the next day to class in alphabetical order is assessment and plan of treatment. They do list a couple of standards here, but it basically represents a health professionals, conclusions and working assumptions that will guide the treatment of the patient. I would argue that this is probably going to be unstructured data. So this is going to be texts because typically assessment and plan is not highly codified in a way that we can grapple with, from a terminology perspective, you might codify the plan of treatment condition, what you're doing. You might articulate a procedure in there, but I think as far as the structures go, if we're spanning both CCDA and fire, there are going to be limitations, what you can do. So I think the expectation for assessment and plan of treatment is going to be a note as opposed to structured data. The next thing is care team members, which is basically a list of specific persons who participate or expected to participate in the care team. And this is going to be a collection of individuals, ideally with their names specialty, but it doesn't say anything more than that. And there are no applicable standards. So I guess the idea is whether you're sending the data via CCDA or fire, you're using their requirements to articulate the care team members as part of that payload.
Speaker 4:The next one we've got is clinical notes now of clinical notes
Speaker 2:Collection of them. And basically each have a link code associated with the type of note that they are, and I'm just going to go through them. But really clinical notes represents narrative, patient data relevant to the respective note types. And so the types of notes are consultation notes, which contains a response to a request from a clinician for an opinion, or advice from another clinician, a discharge summary note, which is a synopsis, the patient's admission, and course in a hospital or post-acute care setting history and physical, which documents the current and past conditions and observations of the patient imaging narrative, which contains a consulting specialist, interpretation of image data, a laboratory report narrative, which contains a consulting specialist interpretation of the laboratory report pathology report narrative, which contains a consulting specialist interpretation of the pathology report, a procedure note, which encompasses non-operative procedures, including interventional cardiology, gastrointestinal endoscopy, osteopathic manipulation, and other specialty procedures, and a progress note, which represents a patient's interval status during hospitalization outpatient, visit treatment with an LTE PAC provider or other healthcare encounter. Now some of these have wine codes, the lab report and the pathology report narratives do not. And I'm not going to read off link codes because that would be even more boring than me going through this with you. The bottom line is what they're really saying is if you have a clinical notes of these types, you should share them. Now, part of that is because the receiving system, the provider might want to be able to look through them and look up the details of the note. They might want to try to NLP or sifting of that note to pull out some clinical structured specifics. The bottom line is they're basically saying these things are important and they should be shared. And as we all know, 60 to 80% of what an EHR knows about a patient is probably locked up in a note. So sharing those notes, even though it creates a lot of stuff that the receiver has to sift through, it's still information that's better to be there and available than hidden from view. The next thing is goals. Now goals is an express desired health state to be achieved by a subject of care over a period of time, or at a specific point of time, the applicable standards for patient goals, they have our link and snowman. And this is kind of a fuzzy thing that I would argue could also show up as a narrative because I don't know how many systems out there have structured goals. I think some of these things documenting an allergy, a medication or a lab result is pretty easy to do with structured data. The structured data kind of lends itself to those quantifiable observations. Some things like goals every now and then I'll see somebody kind of Rube Goldberg together, a post coordinated expression designed to articulate a goal. But a goal is usually less quantifiable that, no, that sounds bad. But what I mean is, if my goal is for you to manage your diabetes, that's actually not just a Boolean indicator, diabetes managed. There's a bunch of variables that I'm trying to measure to identify that you're managing that. And there are levers that I'll use, or I wouldn't use because I'm not a doctor, but the physician would use to help with different treatment modalities or exercise or diet. So, you know, I think goals and outcomes can be challenging to model as structured data. I think a lot of times what you're going to see is somebody articulating my goal for the patient is this that might come through as a note. Or I do know that in standards like fire, you could have a goal, but I think that's also probably something that's evolving. The next is health concerns. So it's a health related matter that is of interest importance or worry to someone who may be the patient patient's family or a patient's healthcare provider. Now, when you look at most models for health concern, it's really just a condition. And it's got a status of health concern, which I think is interesting because if you're getting a fire object and you have a condition that comes through, that just means you have to pay attention to determine whether it's a health concern or an active problem. And when is one another. So if I'm concerned that I might get diabetes, that's a health concern. If I have diabetes, it's a problem. But in a lot of these systems that are modeled and contained in the same type of resource, it's just interesting. You have to pay close attention. And then you also have to kind of decide with the person putting it in the health concern bucket. Is it really a problem that they're concerned about getting worse? Or is it something that they don't have that they're concerned about? Do I have a history of diabetes in my family? Therefore it's a health concern. And so that's another area that I think is kind of still evolving. It just means that when you package this up or you get it, you want to be able to send it through in a way that you can differentiate from a problem or a diagnosis. The next thing is immunity. Immunization is interesting because it's basically a record of an administrator, the vaccine, or a record of a vaccination as reported by a patient, a clinician or another party. And the terminology is applicable standards. They put out there are CBX and NDC. So CVX is a code system managed by the CDC and the NDC is a code system. That's really not managed by anybody in DCS are created by manufacturers, according to a pattern and a set of identifiers, but there is a NDC directory for vaccines also provided by the CDC. Now, when you get an immunization, when you have an immunization data, yeah, we might have an NDC and you might have to normalize it. You might actually have it listed as a third-party terminology, like Metta span code that you then have to walk to a CVX code. CVX codes tend to be a little bit broader than an NDC because they're really more about the immunization itself, as opposed to the package product. It should be pretty straightforward. We're really saying here is that data element is the immunization. Anybody that's worked with immunization data knows that there's a things like if you get an immunization, you could even get a record of an immunization that was denied or declined by the patient. So when you're getting that data, you just have to make sure that you're looking at all the available context so that you're not recording an immunization. That actually was declined by patient. The next data class is labs. Now labs have been around and been in motion for a long time. It's labs and meds. And, you know, allergies for that matter have been shared across systems for a long time. So the lab test itself and there the applicable standards for the lab test for Lynx nomad and you come four units of measure, and then some lab results, think of the test as a container of a result. And then you have the lab order, which could be a panel or an individual test. There are some things, however, where the result itself is a code and it could be a loin code. It could be a snowman code or something else. It's the outcome of an, of a test as specimen, lab results, pretty straight forward. We've been exchanging them forever via HL seven version two fire CCDA. And of course, as test reports as well. But I would think that the lab results are something that you probably should be able to get as coded data. Now, the challenge might be depending upon where you're getting it from, it might need to be mapped to link, or it might have been mapped loin. And whenever you take a local code and you map it to something that is a standard, you always run the risk of some semantic drift where the person mapping it, didn't map it correctly. And so it's always a good idea to get the original data element. And that's another thing I'm just going to put out there. And I always say this, but you always want to get the original data. So when you're getting data with fire, when you're getting data with CCDA, you know, I know our goal is to have the data be available without special effort. But the truth of the matter is if you're trusting somebody else's map, most systems do not record things using standards, whether it's problems or lab results or medications, or using some proprietary or local terminology, that means to get it to you to a standard, somebody had to map it somewhere. It's always a good idea in my opinion, to be able to have available that original data so that if you ever come to question how it was mapped by someone else, you can go in and look at that original data and maybe fix it as the receiver. Because as I've said in this podcast before, really the onus is on you as the receiver of the data, the person sending the data, their jobs, and do a good job and normalize it. But it's leaving the building for them. They're not trying to use it. They have a requirement to deliver it out. And so the ramifications of a mismatch or something doesn't impact them directly impacts you as the receiver. So you should always have checks and balances in place to verify that the data you're getting is correct. If it's been mapped to a standard, the next one on the list is medications. Now medications are typically medications that have been administered or are medications. The patient is known to be taking, and that uses RX norm. And if you're looking at the dosage amount, they are suggesting the YouCam nomenclature, the unified code of units for measure. They also tend to put versions out there. And this is the thing that people do when it comes to terminology. So they say, for example, it's RX norm January six, 2020, that version is now old. So I kind of feel like when you're talking about certain standards that are not administrative like CPT and ICD 10, just saying our X, Norman snowmen is sufficient. Cause if you lock in on a version, you're basically abandoning any additions or updates or fixes that are happened in the intervening period. And so I would say for these, I'm assuming if I'm wrong, someone calls it to question. I'm assuming that I don't have to use the January 6th version of RX norm that I can use the version that came out last month, which has more current data and the same thing for YouCam. And not that we're inventing new units of measure, they're not flying off the shelves, but if we were to come up with a new unit of measure, I would think we'd want that to be available to us. All right, patient demographics, these are just fields that are readily available. So the first name, last name, previous name of available, the middle name, suffix birth sex, and they name a standard for that. The date of birth, the race, ethnicity, preferred language, current address, previous address, phone number, phone number type, and email address. I'm not going to get into the weeds on those are pretty basic. And of course, if you want to get more into the standards, they require for articulating a phone number, you can look that up. All right, the next thing is problems. Now problems. It says information about a condition diagnosis or other events, situation, issue, or clinical concept that is documented except for health concern, because that goes in the health concern bucket. So this kind of follows the same model in most things as a health concern. And a problem is defined in the U S CDI does include conditions, diagnoses, and situations, and it does use snomad as a terminology. And this point they say the September, 2019 release. Once again, I'm assuming that they're really just saying use nomad. The other thing to keep in mind when you start looking at things like problems and other things in snowmen, particularly you want to make sure that you're looking at things under clinical finding and not things that could be qualifiers when you're doing normalization to snowman. All right, the next date of class is procedures and procedures as articulated as an activity performed or on a patient as part of the provision of care. Now for procedure, they list a number of applicable standards. One is hick picks the health care financing administration, common procedure coding system, as maintained and distributed by health and human services. They also suggest CPT or the current procedure terminology provided by AMA. They suggest snowman and optionally ICD 10 PCs, and for dental procedures, the code on dental procedures and nomenclature or CDT provided by the American dental association. These are the codes that they're requesting. And if you look at the fire Corp, for example, it actually suggest which other fields are necessary for a procedure. Cause obviously if you're getting data on a procedure, it's very important to know when the procedure was performed and other metadata about the procedure, the goal of the U S CDI is not just a deliverable load of terms it's intended to deliver actionable and useful information that allows the receiving party to do the calculus necessary, to give the patient the best care they can. And that requires a complete picture of what's going on. So you can't just deliver a bucket full of terminologies. You've got to deliver the additional metadata that makes it useful. The next thing is Providence. Now prominence is basically the metadata or existing information about the data that you're receiving. So if I'm telling you something about a patient, where did it come from? Where was it created? So you have kind of an author timestamp and an author organization. Now, one of the interesting bits about this is when you have a large conflagration of data about a patient, and this is one of the things I'm not really sure about. I'll probably have to follow up, but if we're all sharing data and somebody asked me for data, am I sharing all the data that was shared with me? And when I share all the data that was shared with me, am I obligated to share all the Providence data for all that data? The challenge you have is I might've heard from seven different exchange partners that Fred Smith had an appendectomy because, you know, they told two friends and so on and so on. And so I now have seven different notifications that Fred had an appendectomy. And so when I go to share that, do I share that as data coming from me, it's my author timestamp and my author organization, or do I have to give you seven bits of data that says, why heard her from this person on January 1st and this person on this date? And that's just an example of the kind of complexity we get into when we start talking about aggregating and then redistributing data. And so that's something I actually don't know the answer to. I'm going to ask around and I'll try to get an update on that. The next thing is smoking status, and that's just representing the patient's smoking behavior. And they're suggesting that you use snow med as a standard. There's a standard set of terms and snowman around smoking status for that. The next thing is the unique device identifier for patients, implantable devices. There's something called the UDI. And it is basically a unique device identifier, which is kind of like an NDC code for implantable device. It's a structured code that includes data about the manufacturer labeler the product itself, and then the serial number or specific piece of data. These are things that are implanted in that patient, like a pacemaker or a artificial hip joint or heart valve or something of that nature. But there are now requirements for those things to have identifiers that obviously helps people track what parts have been replaced in their patients. And if there's an issue or a recall or something, I would imagine that would make it very easy to identify and notify those folks that they need to talk to somebody. The next thing on the list. And it's the last thing on the list is vital signs. So vital signs are observations just like lab results or observations, but vital signs tend to be things that are very specific and they tend to be things that are used in telemetry or body measurements. So some things like blood pressure actually specify the vital signs that they specifically want people to track, and they are diastolic blood pressure, systolic, blood pressure, body height, body, weight, heart rate, respiratory rate, body temperature, pulse oximetry, inhaled oxygen, concentration of BMI for patients between two and 20 years old. Wait for length percentile for patients that are from birth through 36 months and had occipital frontal circumference, which is birth to 36 months. Those things are all codafide with Lloyd codes and for things that have units of measure the YouCam nomenclature. And this is the kind of thing where you could imagine there would be lists of those. And you would also imagine, I don't know what the limits are in terms of amount of data, but obviously if you are in an ICU, they're going to have a lot of heart rate, respiratory rate, et cetera, data, or they're going to have a constant stream of your blood pressure. So I'm imagining this is probably about a patient encounter. So the last time you were at the doctor, when the care provider came in and measured these things, what were they? So you can graph and analyze things over time and look for patterns. Those are the data elements and data classes in the USC. And I guess it doesn't surprise me a lot of these things, you know, we call it Pammy problems, allergies, medications, immunizations, or Pamela to throw labs into the mix. And these are things that typically have been exchanged in a clinical summary for a long time. Things like health concerns and the clinical notes are kind of new. And it also, the other challenging thing about clinical notes is not everybody wants their notes to go out the door. Sometimes notes contain sensitive things. The other thing that I don't see articulated in the U S CDI and, and once again, it's something that's probably worth a follow-up is what about consent? And what about things that are sensitive, like information about HIV, mental health concerns and whether or not they're excluded and how you manage those exclusions, but that's not the topic of this podcast. It was a kind of provide the summary of the U S CDI. And I think we have done it. I guess the only thing I would say is establishing these kinds of rules. These kind of requirements I think is good. I think it drives our industry forward and it lets people know that at the very least, if you have this data, you need to share it. And I know that a big part of what was in the final rule was about information blocking and making sure that people have access to their data because like many I'm a firm believer that you are the owner of your healthcare information and the providers and organizations that insure you and care for you are stewards of that information. But the information at the end of the day is yours. Not everybody takes advantage of that. And I think it's something that we should not just the fact that we should have access to our data, but we, as patients should be able to, you know, look at the validity of that data. And if we feel it's not right, or we feel it's misrepresenting us, we should be able to articulate that and make it look right. Because once again, as time goes by the healthcare automates artificial intelligence engages. And if our electronic picture is fuzzy, the advice we're going to get is going to be fuzzy. The opportunities to help us are going to be missed. And so the quality of that data is going to be important. And if you're a large healthcare enterprise, and I know a lot of these large healthcare enterprises and they really do care a great deal about their patients, they want to help them. They want their data to be right. They put a lot of energy into that, but they have millions and millions of patients. You are yourself. So at the end of the day, you're going to worry about yourself. You're going to worry about your family. And you're going to probably want to give that data, your individual attention. Whereas a healthcare organization has millions of patients and it would be very difficult for them to look at each patient record under a microscope to see if it could be wrong. Now there are technologies and clinical architecture has some of those that are designed to help maximize the effectiveness of technology at scale, but not everybody puts technology like that in place. And even with technology like that in place, it's no substitute for you eyeballing your own medical record and saying, wait a minute, I don't recall this ever happening, or I don't recall this being the case. As we share our data, as healthcare tries to do a good job in share and aggregate data and deduplicate data and make sense of the data, that's all great. And I applaud what's in the cures act and I applaud what's happening with fire in the U S CDI. But at the end of the day, you have to remember that your best defense, when it comes to engaging with healthcare is taking responsibility for your data and knowing what's there and keeping everybody honest. All right. So with that, I'm going to close out this episode of the infer monster podcast. I hope you take care and I really appreciate you tuning in.
Speaker 1:Thanks a lot.[inaudible].