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.

Follow Us

Have a question or topic idea?

Transcript

I’m Charlie Harp, and this is the Informonster Podcast. In this episode of the Informonster Podcast, we’re going to talk about the United States Core Data for Interoperability or USCDI. Now, before we get into the USCDI 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 4: 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” and “interoperability” 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 (A), 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 interoperability establishes a broad 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 a dozen of other powerful initiatives in healthcare; not just improve 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, as 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: Interoperability 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 are mandates on the establishment of a trusted exchange framework (or TEFCA), the availability of software interfaces (or APIs) to access patient data, the use of Fast Health Interoperability Resources (or FHIR) to articulate the data, and the United States Core Data for Interoperability (or USCDI), which describes a baseline set of required data elements – and that’s what we’re talking about today.

现在,一种思考USCDI就像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 am going to be shuffling through papers here (shuffles papers) like that. So enjoy. So this is from the February, 2020 Version One edition of the USCDI, and it all starts with Allergies and Intolerances. So for 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 USCDI under allergies and intolerances are the substance and the reaction. Now, when you look at the USCDI 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 USCDI Version One is they say that the way you communicate intolerance is either for a medication or a drug class. If it’s a medication use RxNorm, or it’s a drug class, use SNOMED. Then there’s the reaction, which they’re also suggesting that you use SNOMED to articulate the reaction. Now, what that means though, is that means things that are environmental allergies or substance allergies that 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 SNOMED 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 SNOMED for the drug class, a lot of people are either using a third-party terminology, like First DataBank,Medi-Span, Multum, to articulate class and what this is basically saying is you have to map that to SNOMED since NDFRT has been deprecated and retired, and MED-RT is still a little fuzzy. So there’s mapping required here, and there’s also mapping to get to medication as well. And they also specify the UCUM, 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.

所以下一个数据类,按字母顺序排列ssessment and Plan of Treatment. They do list a couple of standards here, but it basically represents a health professional’s 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 text 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 FHIR, there are going to be limitations to 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 name (and) 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 FHIR, you’re using their requirements to articulate the care team members as part of that payload.

The next one we’ve got is Clinical Notes. Now with clinical notes, there is a collection of them and basically each have a LOINC 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 of the patient’s admission and course in a hospital or a 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’s interpretation of the laboratory report, pathology report narrative, which contains a consulting specialist’s 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 LTPAC provider or other healthcare encounter. Now some of these have LOINC codes, the lab report and the pathology report narratives do not. And I’m not going to read off LOINC 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 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-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 expressed 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 are LOINC and SNOMED, 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, (such as) 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. I know 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 (of) 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 FHIR, you could have a goal, but I think that’s also probably something that’s evolving.

The next is Health Concerns. (It) says, “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 FHIR 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 they 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.

下一件事就是免疫接种。免疫接种是我nteresting because it’s basically the record of an administration of the vaccine, or a record of a vaccination as reported by a patient, a clinician or another party. And the terminologies, the applicable standards they put out there, are CVX and NDC So CVX is a code system managed by the CDC, and the N.D.C. is a code system that’s really not managed by anybody. NDCs 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 immunization data, you might have an NDC and you might have to normalize it. You might actually have it listed as a third-party terminology, like a Medi-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. You know, what they’re really saying here is that data element is the immunization, but anybody that’s worked with immunization data knows that there are 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 the 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 the applicable standards for the lab test are LOINC, SNOMED, and UCUM 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 LOINC code, it could be a SNOMED code, or something else. It’s the outcome of an examination of a tested specimen. Lab results, pretty straight forward. We’ve been exchanging them forever via HL7 Version Two, FHIR, CCDA, and of course, as text 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 LOINC, or it might have been mapped LOINC, 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 FHIR, 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 that are 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 are to 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 mismap or something doesn’t impact them directly. It 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 RxNorm. And if you’re looking at the dosage amount, they are suggesting the UCUM nomenclature, the Unified Code of Units for Measure. They also tend to put versions out there, and this is a thing that people do when it comes to terminology. So they say, for example, it’s RxNorm January 6, 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 RxNorm and SNOMED is sufficient because if you lock in on a version, you’re basically abandoning any additions or updates or fixes that have 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 RxNorm; that I can use the version that came out last month, which has more current data; and the same thing for UCUM. 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.

好了,病人人口,这些只是fields that are readily available. So the first name, last name, previous name if 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; they 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.

好吧,下一件事就是问题。现在的问题s, it says, is 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, as defined in the USCDI, does include conditions, diagnoses, and situations. And it does use SNOMED as a terminology, and this is the point they say the September, 2019 release. Once again, I’m assuming that they’re really just saying use SNOMED. The other thing to keep in mind when you start looking at things like problems, and other things in SNOMED 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 SNOMED.

All right, the next data class is Procedures, and procedures is 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 HCPCS, the Healthcare 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 SNOMED, 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 FHIR core, for example, it actually suggest which other fields are necessary for a procedure because, 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 USCDI is not just to deliver a boat-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 providence 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, “Well I 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 SNOMED as a standard. There’s a standard set of terms in SNOMED around smoking status for that.

下一件事就是唯一的设备标识符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 are 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. They 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, BMI for patients between two and 20 years old, weight for length percentile for patients that are from birth through 36 months, and head occipital frontal circumference, which is birth to 36 months. Those things are all codified with LOINC codes, and, for things that have units of measure, the UCUM nomenclature. 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. 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 USCDI. And I guess it doesn’t surprise me. A lot of these things, you know, we call it “PAMI.” Problems, allergies, medications, immunizations, or “PAMIL,” 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 USCDI 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 to kind of provide the summary of the USCDI, and I think we have done that. 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, healthcare automates, artificial intelligence egages, 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 members, 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.”

我们分享我们的数据,如医疗试图做一个good job, and 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 FHIR and the USCDI. 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 Informonster podcast. I hope you take care and I really appreciate you tuning in. Thanks a lot.