In this episode of the Informonster Podcast, Charlie sits down with Clinical Architecture thought leaders Shaun Shakib, MPH PhD, Andrew Frangleton, and Victor Lee, MD, to discuss SNOMED. They will talk about what SNOMED is, how it used by healthcare applications, the benefits of using SNOMED, potential obstacles and how to avoid them.
Contact Clinical Architecture
• Tweet us at @ClinicalArch
• Follow us on LinkedIn and Facebook
• Email us at informonster@clinicalarchitecture.com
Thanks for listening!
In this episode of the Informonster Podcast, Charlie sits down with Clinical Architecture thought leaders Shaun Shakib, MPH PhD, Andrew Frangleton, and Victor Lee, MD, to discuss SNOMED. They will talk about what SNOMED is, how it used by healthcare applications, the benefits of using SNOMED, potential obstacles and how to avoid them.
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:Hi, I'm Charlie Harper, CEO of clinical architecture. Hi, I'm Victor
Speaker 3:Li VP clinical informatics.
Speaker 1:Um,[inaudible] the managing director of the UK clinical architecture, uncharged key, the chief informatics officer,
Speaker 2:And today on the infant monster podcast, we're going to talk a little bit about the snowman CT ontology, how you can use it, some of the pitfalls and benefits and things you have to keep an eye on when you do use it. Oh, we have some folks here that have a lot of both practical and academic and direct experience working with snowman and working on snowman. So we thought it'd be a good opportunity to just share some insights for people that are trying to figure out how they can make the best use of what is really a fantastic resource. Let's start with talking about what's in snowman, in a nutshell, what kind of concepts live in snowman?
Speaker 1:It is officially a clinical terminology, whereas other code systems out there ICD that are officially classification systems and the difference between a terminology and a classification system is that role, the classification system is to create these large buckets to aggregate data categorize data. Whereas terminology's role is to try to capture and encode data at the same level of granularity, as you would expect clinician to care about that.
Speaker 2:And the other thing about snowman that I've always kind of noted is, you know, you have the semantic types that live in snowman and then the different domains that live in snowman, but you also have a category of things that are not really meant to be terminology they're meant to qualify terminology.
Speaker 1:There's a lot of terms that are installment, which had to do with the structure of the ontology rather than being useful clinical terms. And the other thing about snomad is of course it's covering drug and lab and disease and disorder and procedure and other areas. Whereas a lot of the other terminologies and consultations are really focused on one domain of knowledge, like groggy or Lowel procedure.
Speaker 3:And I'll just make a comment just to kind of keep things really simple case. We have listeners who need the context. We're really talking about structured data. There are some advantages to having data that's in a structured format that can be machine computable. And obviously there are things you can do with that kind of information, as opposed to unstructured texts, just narrative free texts that makes it easier for us to understand the clinical information that we're trying to capture.
Speaker 2:Sure. So Victor makes a great point. Any terminology that you see, whether it's healthcare or somewhere else, instead of just having a note that a human can read, you're really trying to enable a piece of software to be able to do something useful. And clinical terminology is like snow med do exactly what Victor described as it allows software to do things like analytics and decision support, and other useful things that wouldn't be much more difficult if we were trying to parse apart unstructured, textual information and deal with it. One of the things that I think about when I think about snowman is obviously it's a terminology for those of you that don't do a lot of things with terminology that ontologies to Sean's point about how it terminology is designed to describe things at a granular level. The other thing about about snowmen is it's also an ontology. So it has codes that represent these things that allow you to represent things at a granular level. It has a set of codes that are really descriptive and supporting things, but it also has a very rich set of relationships that show how these things relate to one another, including does big overarching relationship tree or graph in snowman. That is kind of, this is a hierarchy. I don't know if you want to talk about is a hierarchy.
Speaker 1:Sure. And Victor's point sort of triggers something else, which is snow med is S N O N E D not S N O w, which is one sure. Way to tell that you haven't had experience with the terminology before. And so the way content is related, organized within snowman is the relationships and associations that are substantive. And by that, I mean, there are these parent-child relationships can think of those as being like the vertical relationships, starting at the top of a tree taxonomy, and then just going down, you know, uh, from parent to child, those types of associations. And then there are other semantic associations. Those are the vertical types of relationships and associations. So those would be things that are inbound relationships or associations or outbound relationships and associations. You can think of those as being the vertical bar versus the horizontal apart. Examples of semantic relationships and associations would be things like medication, the ingredient, the strength, the forum.
Speaker 2:Wow. So it lets you kind of determine what something is and its position in the ontology who its parent is, whose children are the thing that is less or is broader than it. And the things that are more specified versions of it, as well as things that it breaks down into or decomposes into. And in some cases, things that for some reason are related to it,
Speaker 1:There are sort of practical ways and they're sort of navigational ways that you can use the ontology. So for example, if I was trying to find a particular group, what I might do is pick one of its members and then navigate the ontology, meaning go up and find its parent, and then find the thing that had organized or created the group. So if I wanted to find viruses, I might pick a virus like CMV search for it, and then start walking up within snomad to its parent and then to its parent, until I found the larger classification of group that had all the things that I cared about, searching things that snowman is interesting to think about because salmon exists for kind of two reasons. It exists to allow us to find terms as humans. It's also trying to organize terms that are structured for computation and data analytics, decision support and things like that. So as a human, when you start looking at snomad understand the organizational structure of the parent-child relationships, the other ontological relationships, but sometimes things aren't quite what they seem and Victor, you and I were talking earlier on stable hypertension. And the fact that if you looked at hypertension, you looked at the children, you don't always get what you see.
Speaker 2:Yeah. That's a great classic example. So if we're trying to, for example, define this concept of hypertension and enumerate the snowman codes that roll up
Speaker 3:To this concept of hypertension. We might be tempted to say, let's pick the hypertensive disorders term and include all of its descendants and to your point. And really this is because nomad is a poly hierarchy where certain concepts may live multiple times within snowman. We might find common things like primary and secondary hypertension, but also things like pregnancy related, hypertensive disorders like eclampsia and preeclampsia and HELLP syndrome and other obstetric related hypertensive disorders that we might not classically consider to be what is hypertension in the vernacular. And so we need to be mindful of how we leverage the richness of snow med. And sometimes it's a little bit too rich and inclusive for a particular use case. So you kind of have to pay attention to these hierarchies.
Speaker 4:That's one of the things is as an engineer and healthcare, we go to these data sources and we really want to think there are a magic bullet they're going to fix the problem. And one of the things you have to be careful about with snowman, that this is true. A lot of these assets that are available, they were built based upon a policy and approach. And that doesn't mean it's universally applicable. When you're trying to do things you, you still might need to go in and curate the things that you want. There are certain things where you can use snowmen out of the box. It'll work great depending upon what your objective is, but you can also kind of think of snowman is like going to the grocery store. I want to build a value set that has terms that are relevant for my clinical use case. And I may not be able to just grab a note and pull all of his children. I might have to go. And like with your hypertension example, go in and pull some things out because for what I'm trying to do, even though they're in that part of the whole hierarchy, it's not appropriate. And that's not necessarily saying that the people that maintain the stomach content made a mistake, but their approach, their policy included those things. And that's just the way they wanted it organized again, when you look at that snowman content, you can get, there's a lot of overlapping content we mentioned before that snowman is maintained in different domains like drug and lab procedure. There's some sort of find a grain domains as well, like the observable entities and findings and scales and assessments. And what the interesting thing about those three areas is if you were building your value set and you're looking for maybe a depression store, as an example, there were three places you might find that depression school, you might find it under assessment and scales, which is really the definition of that. This is a depression school. And it's just saying, this is the type of score it is. You'll also find it mentioned under the findings where if that depression score had a value outcome of one to nine, you'll find the depression score with the value of one depression score with the value of two through to nine. But you'll also find it under the observable entity hierarchy where it'll just say it's depression school and your expected to supply an answer to that question and not a value of one, two, three, four, five, six, seven, eight, nine into your storage when you store that data. So when you're building these value sets and you're trying to choose which things go in your value set, you have to be very capital, which domain in snomad it comes from. And to do that, there's a construct called a fully name. And if you look at the fully specified name, you can always see the semantic tags so that you can understand whether a term is a procedure or a lab result or an assessment scale, or any of the other domains that they have.
Speaker 2:And this is a good time to point out, and I'm not going to get into the weeds of this. I'm not that guy, but when you look at the waste, nomad is structured from a data architecture perspective. You have a concept table and the concept table does not have a description. It has a relationship to a series of descriptions that have purposes. Like one is the preferred term for a given language. And then you have a fully specified name. And then you have alternate terms and snowmen is designed to be international. The concept is kind of the semantical unique identifier. The descriptions are representations that have been assigned to that unique concept in that given set of language. There are modules and other things that I don't really get involved in as an engineer, because I'm just concerned the U S extension. So if you're a developer, for example, when you crack open the snowmen file, you can go to the concept's table. You're going to see a big file full of numbers. You have to join that on the descriptions table to be able to start seeing what those concepts actually are. And that was changed from a few years ago if I remember correctly.
Speaker 1:So that whole area of just sort of dealing with consuming dumb, it generally is an interesting topic area. And, but you were talking about earlier today was how, for example, we do the snowbank us edition versus the UK edition. Now it might be interesting to hear about it.
Speaker 2:Well, can we just talk about how the additions work relative to the core? It does
Speaker 4:Different country by country, but if we just take the U S and the UK as two examples, snowman international publish a clinical core, which has its Mehmet international concepts that are altered by stomate international. Each country can publish their own extension to snowman. And actually as an organization, you can also publish your own snowman extensions as well. When you get snow made in the, in the us, unfortunately for you folk over here, there's been a U S edition created, which gives you one place to go. And you'll find one concept table, one description table. If you go to the UK and you want to use snowman in the UK structurally, it's the same, but actually there are three components that you need to do to build the equivalent of a UK edition. And that is the international call, the UK clinical edition and the UK drug edition of the other major fall we have mentioned is the fall of maintains and contains the relationships between concepts. So when you're building the UK edition, you have to take those three sets of data and you have to process them to create a single UK edition. There are then several complications because you end up with similar term descriptions coming from multiple places in American English, British English. So you have to then look at the ref set contents in snowman, which contain a appropriate point as to which languages, which spellings, which words we want to use. So choice between displaying a term as paracetamol or acetaminophen is controlled by these realm, rough sets. So when you're building snowman and consuming it out of the box, you need to be very cognizant of the region you're in and how you build the addition for that particular region. It's funny. Cause snowman
Speaker 2:Is one of the things that drove us to create the subscription portal. When we built that it was people just struggling with the process of creating the right set of data so they could consume it and make use of it. Because one of the things that I find with standards in general is they create these fantastic resources. And this is less true now than it was say, five years ago, you have to talk to the invisible swordsman and you have to talk through these convoluted steps to be able to get something that you can actually put your hands on and work with. For a lot of people, it can be very daunting and it can be a big barrier to adoption. You've got one that is less true. Well, I think for some things like, we're not going to talk about the homeless men at the source, but you must, Mesosaurus, it's an adventure to get a copy that you can work with snowman. If you're getting the raw file, some assembly is required to be able to make use of the content. And then of course you have to also do similar work when the content updates come out.
Speaker 4:It is kind of funny that if you look at different browsers that are available out there, you can look at what claims to be the same version of snowman, but you'll find different preferred terms and different representations. It just shows the complexity of doing the building, but there's also another set of supporting files. I think I mentioned the rep set files, but there's also several different versions. So whether you want a snapshot version, which is just snowmen as it is today, or whether you want a version, which includes all the history information for all those terms, because terms in STEM, but a dynamic, they have a status on them, which is active or inactive. And that's another thing you'd have to manage when you're applying updates to snowman. Do you have to be very aware or how do you use those status flags as well as just building liberal woods and relationships
Speaker 2:When it comes to utilizing snowman? One of the things that we do a lot is we built subsets snowman has probably close to her over half a million terms. And when people are trying to leverage nomad, one of the best things to do, and you're doing that is essentially carve out a section of relevant terms. And you do that also because there are things that can be conflated. There are qualifiers that have very similar names or similar words to things that are disorders or conditions. If you're trying to create something safe for exchange and meaningful use, and they require a snowman code and you pass a qualifier code in, when you really should be passing a condition, you might be adhering to the spirit of the law because it's technically a snowman code, but it's really, probably not in the value set that they're thinking about when they wanted you to deliver a piece of information. Everybody here has built a snowman subset at some point or another, any pointers or tips on that picture.
Speaker 3:Well, I wonder if it might be helpful for starters to maybe define what we mean when we say subset, as well as you and Andrew both mentioned value set and Sean, we were talking the other day and I kind of liked your definitions as you were describing similarities and differences between subsets and value sets. So I don't know if you wanted to share,
Speaker 4:I would say because you know, the crop has the challenges that it's our garden.
Speaker 1:One thing that's absolutely true. The terminology space in terminology geeks generally is we don't all have the same terminology. So at least when it comes to the way we think about it, a value set can include one to many terminologies as members in that value set. And they're actually kind of rolling up to these, or we refer to these things as elements, but it's like a variable to be used for other purposes in decision support, logic, or some other place that we create that roll up. We source multiple external terminology. So summit would be one of those, but ICD CPT, RXR, it could be other terminologies that would be searched for that purpose for us. Subset is the grocery store the way Charlie was talking about it. So I want to go to the snowman and I want to actually reduce the noise when I'm trying to map to a target, the way I can do it is I can raise these bars up to say, yeah, this is the area of snowman I'm focused on, on a map to concepts within this. Or I want to use concepts within this area. So I create a subset and we create a subset definition that lets me do that. That subset can be, I just want to grab anatomic locations from snowman and work with those. So I'll create a definition, grab that subset of terms, but typically it's not across multiple source terminologies and it's not really rolling up to something that we would call an element. No, our jargon, if you're reading through the snowman documentation, you'll, you'll find that they call wrap sense. Talk about, I think that that was done deliberately so that people using snowman could understand this is what we mean by rep set. And there are different kinds of rep set, but one of the kinds of reps that does match onto a subset handle when I first joined clinical architecture, Charlie had a different name for everything, right? He didn't use any Ms. Standard informatics and it was deliberately to avoid confusion, right? The fact that everybody sort of has their way of interpreting these mapping is another great voice overused term in terminal.
Speaker 2:I think of the patterns from an engineering perspective, I think about patterns. And there's a pattern where you have a collection of concepts that all come from the same place. And I tend to think of that as a subset. When I have a collection of things that come from multiple places, I tend to think of that as a super set, but I think we tend to call those value sets. And we use those in places like quality measures and Hetus and things where we're saying, I know that in patient files, they might have documented using one of these code systems. I want to be able to recognize that a patient has diabetes mellitus through this editorial policy. And so these are the concepts and those different code systems that I want to be able to recognize the diabetes mellitus to your point earlier. I think when we build those things, we build them for rule processing, whether it's an inference or a quality measure, or you're rolling things up to recognize and perform an action. But we also have built these things to create a narrower target. When I'm trying to either map or ship something and land on a particular subset of concepts, we could also do to create pick lists of things. I mean, when you talk about the grocery store of snow med demo, I've done a probably a hundred times is regular frequency where you want to create a pick list of frequencies. You could recreate everything from scratch, or you could go on a snowman and say, what do they have? You have the benefit of a not having to do the research and the work and B having any base on a standard terminology. Now this is probably a good time to talk about some of the things you have to keep in mind. If you're using a standard terminology. I always tell people standard terminologies are great, but you have to recognize that you don't have control. At some point, your standard provider will make a change or do something. Your only recourse is to react to that change and find some way to absorb it. And snowman actually does a good job of providing guidance on replacements. Not all terminologies do that. Sometimes they give you very good guidance. Say this thing was retired, but it's been replaced with this thing. And as long as you can follow that process, you're in good shape. The other thing about using an external terminology is they may not have something. And one of the things that you guys know much better than I do is there's a process. If there's a concept that is not in snowman or in my, my extension of snowman, and I want somebody to add it, there's a process for that, right?
Speaker 4:Yeah. There is a process and it is, it's normally controlled by your regional release centers. So there's a slightly different process in the U S and the UK and other countries, but normally you can request a term. And if the term is genuinely felt to be useful, that can be put into a local country extension, and it'll be published. And in the future that might get promoted into the call and shared between countries, but typically the collation of that is done at a regional level country level. Yeah. Those regional
Speaker 2:Extensions ever get promoted to the international Corp. Does that happen on a regular basis? Are pigeons released? What happens there?
Speaker 4:If the term is added into a regional coal, it will get sent up to the folks at snowman international. And they'll look at that and decide whether it's appropriate to put it into the international code. So I can and does happen on a regular basis.
Speaker 2:It sounds like an opportunity for one of those schoolhouse rock videos, you know, um, just to turn
Speaker 1:Well. I mean, the other option is to just create an extension, right area that's not well addressed and snowman, and you need concepts there. You can create a formal snowman extension.
Speaker 2:Do you have any obligation to share that with snowmen or are you just protecting a numeric range for yourself?
Speaker 1:It's really just giving you a strategy to use snowman as your backbone terminology, but yeah, there's no,
Speaker 2:Typically if you're going to do something like create an extension, you almost have to have some kind of a protocol for recognizing when the thing you created in your extension, hasn't been added to either your regional edition or the core, and then have your own replacement logic. If you want know that's going to be your strategy. Exactly. So if you're thinking about creating a snowmen extension, you have to realize that to be compatible with snowman. You have to be aware that if they add it and you probably should do your due diligence and retire your extended term and create a map to the term that was replaced by snowman.
Speaker 4:So the techie bit is that the identifies in swim at a 64 bit integers. And part of that interject that you get has a namespace sequence in it. If you want to build your own extension, get in contact with snowmen international, and they'll be able to give you a name set. They sequence that means that identifies that you create one clash, but then the other person creating snowman codes. And that's how they can remain unique. But you're right. Once you've created your own code, you really do need to keep an eye on what's coming downstream. And if that concept is hid in the national snowman, you're better off retiring and Halloween the mechanism to adopt the standard code rather than your own local code. I'll probably close this down by saying, if you're thinking about it using snowman in an application, or do you just want to learn more about snowman? One of the best things you can do is just Google to nomad CT starter guide and the[inaudible] stomach international folks have really nice set of documentation to help primer you and get you through the process of how to use it. It's definitely worth learning more about it before you try to use it. It'll keep you from going down a lot of blind alleys and getting a lot of weirdness out of it. I think that the starter guide is a great resource. There's also some online tutorials and some accreditation schemes and the education around school management and as always with the infant monster podcast, if you ever need assistance folks in clinical architecture roles,
Speaker 5:I want to say, thank you. Thank you. Thanks for listening. And we'll see you on the next edition of the informants podcast.[inaudible].