Snomed CT AU Vocabulary inquiry

I’m wondering if there has been consideration by OHDSI Athena of adding SNOMED Clinical Terminology from Australia (SNOMED CT-AU) as a Athena Vocabulary download?
I’m not sure what that entails, so if this isn’t the venue for that type of question then let me know.

Context:
During the side quest I went on, to update my NIH login.gov access.
With that learning curve/adventure it showed me the starter guide for Snomed CT.
SNOMED CT Starter Guide - SNOMED CT Starter Guide - SNOMED Confluence
At high level I know our group collaboration of sites is looking to come up with a Vocabulary with concept ids greater than 2 billion to represent concepts in Domains that aren’t currently in Athena’s downloadable default list of vocabularies.

For me, this is more of a gain understanding question to the OHDSI Vocabulary forum - based on the premise:
If SNOMED CT AU has more concepts and extends what is currently there in SNOMED CT - then maybe there maybe some overlap by its extended values and thus eliminate some of the need(s) to define a unique vocabulary.

Citing the AU gov slide 14 in https://www.healthterminologies.gov.au/library/DH_3288_2020__TerminologyAndClassificationPresentation_v2.1.pdf as reference to my question

Aside: The AU Ontology lookup tool is pretty interesting ECL Builder as it gives me insight into the “is a” “was a” “replaced by” logic which was quite helpful paired with how they logically lay how it builds/relates here at Expression Constraint Language (ECL) Reference

Hope this explains where my question is coming from for Snomed CT and Snomed CT AU extension.

Thanks and best regards,
Heidi

Hello, @Heidi_Schmidt1

Do you have concepts that are present in SNOMED AU, but not available in other versions of SNOMED, already implemented in the standardized vocabularies (International, US, UK)?

Currently, the SNOMED you see in Athena is a combination of the abovementioned modules, and adding one more is a considerable lift to the vocabulary team. The planned work is specified in the roadmap, and the current implementation of Australian SNOMED is not included there.

Thanks for the links for OHDSI SNOMED and the Vocab Roadmap. I’m still working to get my head around this, so bear with me.
In their SNOMED documentation SNOMED CT pamphlets. It look more extensible with SNOMED CT AU and so I wondered if it was extensible for more than the AU population.

All our group sites currently are in the USA, so it wouldn’t be that we’d use it for mapping data coming from an Australian data source.

My question was more to understand if SNOMED CT AU might cover some additional Measurement value_as_concept_id(s) for things that current Athena concepts “Has Answer” does not cover, Visit Detail visit_detail_concept_id(s) for specific sites of care, Procedure Occurrence procedure(s) that only have a relative observation or measurement concept codes for, Device Exposure device(s) and Drugs as device(s).

It might help extend what we can’t currently find for an analog for an OMOP table in their domain for mapping. I’ve found matches to name values in adjacent domains, but that invalidates the DQD.

I found this web site - Shrimp/🔥 which helps me visually see relationships.
I had gotten to SNOMED’s ECL app through their documentation ; which looks like it is only related for FHIR. It’s not clear to me, yet the difference between the two apps.

I’ll take a few names for string values under value_as_concept_id and procedure names to run through their web application, shrimp.

My thought process is that if SNOMED AU covered it with a code and we proactively used a SNOMED CT AU code (without it colliding with an existing Athena concept code) then it might be a better alternative to coming up with a completely new 2 billion id code in a new vocabulary submission. Thus potentially meeting the future in the middle.

In this case, It makes sense to use SNOMED CT AU as long as these concepts are 2bil+ and do not collide with existing concepts from the standardized vocabularies, you are right. I am afraid adding SNOMED CT is not a priority in the moment, therefore, I cannot guarantee that you will meet the future in the middle.

I am curious, if your group sites are in the US, what clinical concepts can’t be covered with existing SNOMEDs? Maybe mapping uphill (with a minor loss of information) is a way?

@zhuk

I am curious, if your group sites are in the US, what clinical concepts can’t be covered with existing SNOMEDs?

I am wondering the same.
Maybe the simplest solution might be to have SNOMED promote these concepts to the international edition? If they’re being used in the US, sounds like they meet the criteria of use by 2 or more countries?

Piper

Thanks Piper for the info to know the criteria to ask for a concept id to be folded into SNOMED CT. That’s great to know.

An example: One specific visit domain type we’d like to have a concept id to use is for “Neurological Intensive Care Unit”

Which I can find the following in Shrimp:

Property Value
System http://snomed.info/sct
Code 309909006
Preferred Neurological intensive care unit
Displayen Neurological intensive care unit
Effective Time 20020131
Primitive true
Fully specified nameen Neurological intensive care unit (environment)
Inactive false
Module ID 900000000000207008
Synonym (acceptable)en Neurological ITU

Would a SNOMED CT AU “environment” be translate-able to the Athena OHDSI Visit Domain?
The other options list “procedure” for code 183448005 which is labelled “Admission to a Neurological Intensive Care Unit”.

A couple of points,

Neurological intensive care unit is present in core SNOMED, there is no need to add any new concepts.

After extensive discussions on the topic, the concepts of locations have been destandardized in OHDSI. Locations in SNOMED are physical locations, basically walls, and not something we expect from the neurological ICU (eg. a highly-equipped unit with a team ready to treat any neurological condition).

And finally - what is your analytical use case? If you want to see if patients treated by Neurologists recover faster than other patients, use providers.

We were told not to use the Non standard concepts so I wasn’t looking at that.
What makes that entry non standard if it is in the Snomed Core?

We are tracking our providers in our OMOP data but not in the central OMOP data we are collecting.
Providers are independent in our OMOP than the location/care site aka the hospital department.
In terms of data coming from Clarity, the code gets mapped to a visit detail concept, which is within the hospital.
What folks want to do is specify more along the departments specialty to differentiate within the visit detail concept id itself and leave the visit detail admitting and discharge concept ids as they are.

As @zhuk explained: Care sites, visits, visit details or locations have no specialty. I know that hospital departments are often called that way. But there is no defined difference between a neurological intensive care unit and an ordinary ICU. Actually, there even is no formal difference between a normal hospital word and an ICU that you can pinpoint. During Covid, we tried a lot. There is no specialty provider, treatment (drug or procedure) or anything else that is a telltale sign that something is an ICU.

Which makes it unusable for a central data reference like the OHDSI Standardized Vocabularies. Essentially, you cannot say "Give me all patients where visit_concept_id=“Neurological intensive care unit” and you will get those patients reliably.

So, your problem may have nothing to do with the Australian SNOMED.

Any other use case?

1 Like

Yes, Agreed. The concept was listed as non standard and so I missed it.
The bummer is that the collective “we” do want to specify what type of ICU as the visit_detail_concept_id and use standard concepts for them in the Visit Domain.

For other use cases, I have procedure and measurement value_as_concept_id concepts that I will have to come back to here after I assemble their list and do my homework.

What my take away from the forum discussion (and thanks for that btw!) is that our team is making a set of 2 billion concept ids for speciality departments that are meant to represent visit locations in the Visit Domain so that there can be delineation along department specialties.

Some of them could be handled by non standard concepts (and I’d have to verify that list of 30 or so entries)

Thanks.
Heidi

@Christian_Reich @Heidi_Schmidt1 @zhuk

This discussion goes beyond the vocabulary. We need to disambiguate the speciality from the location from the actual type of visit. These are three distinct domains.

  • Specialties are things like rehabilitation agency, well babies, intensive care
  • Locations include taxi, ambulatory prison health clinic / center
  • Types of visit contain the original standard concept_ids for the visit domain: inpatient, outpatient, ER

We need to do a surgery on the standard concepts in the visit domain. But first, we need to gather the use cases.

The original use of the handful of standard visit concepts was to help distinguish severity of illness. A person with penuemonia needing inpatient care is much more ill than a person with pneumonia receiving outpatient care. The distinction also helps in building cohorts. Most epidemiologists only want their myocardial infarction cohort to include persons with a diagnosis of myocardial infarction if it occurs during an IP or ER visit.

Locations should be removed from the visit domain and placed in the Location table. And specialties are best placed with Care Sites, though @Christian_Reich will argue against this. But they are better suited in Care Sites than with the visit. Though I might be convinced they could be represented with the visit_detail_concept_id. However, that would be a change in the definition of the field. Lots to think about here. That’s why it is so important to have the use cases. Then we will be able to properly model the data based on the questions it needs to answer.

At the University of Colorado, I mapped all our ICUs to concept_id = 32037 for a non-OHDSI network study. However, when we need to distinguish NICU from CICU or identify any department, we utilize the Care Site table since all our Visit Detail records are linked to a Care Site.

1 Like

@MPhilofsky:

Yes, this is important. We’ve had lengthy debates a few years ago about it. The gist of it came down to:

  1. Specialties are attributes of providers (doctors, nurses, but also optometrists and the like). Specialties are highly regulated with certificates, and therefore well defined. Internationally, they are very compatible.
  2. Visits are configurations of healthcare, defined by who actively comes to whom (e.g. outpatient = patient to provider), length of interaction (e.g. Outpatient = >1 day), and intensity of service (e.g. skilled nursing facility = nurse there 24/7). The specialty is irrelevant, except for special situations like closed mental institutions, where the configuration is that the patient is housed there by the authorities.
  3. Care sites are often called by their specialty (“MGH Department of Obstetrics & Gynecology”), but there is no definition. They also often blend specialties, depending on the local situation. Therefore, care sites should be just anonymous organizational structures with no meaning to the outside beyond their ID.
  4. Locations are just geographical. They have no other attributes.

Bottom line: If you want to know what specialty was practiced at a visit, care site or location - find the providers involved and look up their specialties.

Whether a taxi is a visit or a location has nothing to do with specialties, does it? Do you want to open that box?

@Heidi_Schmidt1 or @Heidi_Schmidt:

(Why do you have two identifiers? Bad data modelling! :slight_smile:)

Yes, you can do that. But make sure you create CONCEPT_RELATIONSHIP “Is a” records to the standard Visit concepts. That way, you can run network scripts from people who have no visibility to your 2-Billionaires and it will still work.

@Christian_Reich - sometimes (not always) the caresite carries a lot of important information beyond just specialty (i.e., subject matter domain). Examples are staffing models (e.g., nursing:patient ratios in ICUs, mix of/minimal expertise of staff on site at any given time, etc.); minimum levels of equipment and supplies, types of equipment/supplies on hand, etc. (e.g., cardiac cath lab, OR); other features of the environment (e.g., special mental health units designed to be calming/soothing, or without access to objects that could be used to harm self or others, etc.).

@MPhilofsky I’d be interested in exploring this more if there is a group doing a deep dive on representing visits (and de-conflating information related to subject matter domain, environment, services offered, custodial status, staffing, etc.). We’ve been working to sort this in our org over the last year.

Totally. But it was deemed next to impossible to create a model that would reflect all that in a way that is queryable this from the outside. Remember, the OMOP CDM is not for you, but for your OHDSI colleagues who have no knowledge of or access to the data. Internally you can expand the database in any way you want.

Also, we didn’t see any use case. Do you have one? With the detour through the providers (in a pediatric department you’d expect mostly pediatrician or hierarchical descendants thereof) why do we need the specialty of a care site?

yep - 100%

So when we have concepts for specialty, healthcare services, environments, and they have to have shared meaning across all countries. That’s the challenge.

The use case is enabling analysis to understand how structure of care impacts outcomes (the structural part of healthcare quality).

Like the rest of the community, we’re learning the hard way that its waaaay more complicated than it seems on the surface. I DO think we can make it work, and I do think making it work will reward us with some actionable knowledge.

Structure of care is a huge in mental health (my pet interest).

Piper

1 Like

Sorry Christian, It’s probably a Google identity issue for me.
I use both my personal Gmail in Chrome and my professional Gmail in Chrome.

I also answer to hey you!, Mom, Moooooooom!, Mrs. Page, Mrs. Schmidt and sometimes goofball. <3

Thanks Christian.
CHoRUS/Bridge2AI is the group through Andrew Williams and Eric Rosenthal, and other PI’s that are working on these 2 billion concept ids.

Pollina, as part of that group, had done the DDL relationship work as of Jan 30th 2025 for the 30 visit_detail_concept_id(s) or so in our list.
I hadn’t looked into detail how she created those relationships, yet.
I’ll circle back to that to reference and see if the patterns make sense to me.
And I need to catch up and re-read through these threads as well.

I attended the Themis WG Mtg this morning, 2/6/2025
To track ideas for possible projects (though its called issues),
Melanie would like us to create a Themis Github Issue with the Template and track it there with reference back to the OHDSI forum post.

I gave Piper my work email to follow up for a Github Themis Issue for this thread.
Once that Github Issue is there, it will be posted here so other folks who are interested in it can help collaborate, shape, and inform.

To put in a plug here along what Melanie was asking in mtg this morning -
There are initiatives that folks are working on that could get more visibility if there is a Themis Github Issue tracking that project work.

There is an opportunity to cleanup and prioritize from a project management perspective for any current Themis Github Issues.
If folks could review the list and see what’s relevant to the now and has folks who want to work on them, that would help.

No, I want to throw it in the recycle bin! Let’s destandardize concepts or change their domain, if applicable. We don’t allow “home” to be a standard concept in the Visit domain, why is taxi a standard concept? And if we have use cases for other codes/non-standard concepts, let’s identify them and change their status.

It’s time for a cleanup, this topic continues to come up and causes lots of consternation and debate. @Heidi_Schmidt1 and @Piper-Ranallo have graciously offered to gather the forum posts, reach out to the participants, identify & define the use cases, and take sponsorship of this issue. Then we will get all relevant parties together and sort it out. Themis will host the party and you’re on the invite list :partying_face:

1 Like