Dear all,
The archetypes Gugging Swallowing Screen (GUSS) and Gugging Swallowing Screen for Intensive Care Units (GUSS - ICU) have been through one review round each, and the editors recommend them for publication.
If you have any comments or objections, please make a Change Request or start a discussion in the relevant archetype in the CKM in due time for planned publication on September 15th, 2025.
Kind regards on behalf of the editors,
Hanne Marte Bårholm & John Tore Valand
Great! was looking at Athena to get an OMOP mapping and seems like we have a good candidate for the first on Athena where we can put the total score.
I can see the results and severity element being interesting for omop. There is not an exact match for the valueset (as usual), but I can see creating OMOP observations and measurments about the difficulty . I’m thinking each item of the openEHR valueset generates a set of different objects on OMOP
e.g. “Swallowing semisolids, liquids and solid textures successful. Slight / No dysphagia with no or minimal risk of aspiration” could generate
Does swallow soft foods [snomed-ct::306776007] + Does shallow fluid [snomed-ct::288949005] + Screening for dysphagia [snomed-ct::431765005] → low risk [snomed-ct::723505004]
There is no explicit code for the GUSS - ICU
Thanks for all this work.
I have made a change request related to aligning the two archetypes and the Editorial style guide - Observation Archetype: Gugging Swallowing Screen (GUSS) [openEHR Clinical Knowledge Manager]
Can you explain a little more please. The archetype is a direct representation of the clinical assessment and the options for result/severity is in the final data element - ‘Results and severity code’ or ‘Severity code’ (-currently labelled slightly differently)
“Low risk” is not a feature of the assessment as it stands.
Yes, as I’ve said before, archetype internal valuesets are far more richer (i.e. more codes), detailed (more specific codes) and far more updated than any other known terminology (specially OMOP terminology as releases don’t have to align with other terminology release timings).
While we have a code for dysphagia screening, there is no code such as Aspiration screening or aspiration observable. I would propose putting both, but as far as I’ve seen that kind of code does not exist in terminologies
Instead of “low risk”, it could be just better to use “Screening for dysphagia” → “slight” , as the risk was referring to the aspiration that has no code. Loinc code “no risk” could be used instead as it is reused in multiple panels, and maybe it’s more fitting as value for the (non-existing) aspiration observation.
In general, it is also worth exploring the “known absent” hierarchy , but no specific code was found that fitted this case (using “Known absent” as the value could be fine too)
It is also worth noticing that defining multiple OMOP mappings from the same Element is not something we have done with the OMOCL mappings, but I can see it as being a powerful way of generating info from very specific openEHR valueset codes. I’m pretty sure tooling would allow it if we were to go that route.
OK - the archetype is simply copying the GUSS assessment tool. If OMOP was representing the GUSS as well, I’d expect the same values - this is why I’m confused. See - A bedside swallowing screen for the identification of post-extubation dysphagia on the intensive care unit – validation of the Gugging Swallowing Screen (GUSS)—ICU | BMC Anesthesiology | Full Text
But it sounds like the OMOP model is more abstracted and generic, maybe?
OMOP always* reuses other terminologies (in this case SNOMED), which only has of the GUSS score as a measurement. There is no GUSS related severity or codes for each individual question. Scales defined in papers take a lot of time to end up in any standard terminology, and most of the time you get the score and that’s it, no codes for individual questions. Ideally national bodies should report all these elements to be included in their snomed national extension first, and then contribute them to the international edition (again, it takes time for that formal process to happen). Only after that OMOP would end up having those codes when imports the latest international edition. In the end OMOP vocabulary is as good as the terminologies it imports.
*always relies in external “clinical” terminologies, OMOP has defined their own codes for context-like fields and also when they are working closer to the knowledge frontier such as oncology or when COVID happened and everyone needed a standard code for analytics.
I think you might get into a tangle by trying to allocate ‘sort-of matching’ SNOMED codes to the GUSS risk categories, until those codes are actually formally delivered. I’d certainly push back on that in a direct care context. These are very specific ‘derived’ categories based in a very strict protocol, and IMO should have their own codes.
They are, in any case, derived categories, based on the quantitative total score, so exporting the categories is really only a matter of convenience…
In total 4 levels of severity can be determined:
0-9 Points: severe dysphagia and high aspiration risk.
10-14 Points: moderate dysphagia and moderate risk of aspiration
15-19 Points: mild dysphagia with mild aspiration
20 Points: normal swallowing ability
I’d request the codes - maybe LOINC is an easier route, and just use the exported score for OMOP.
OTOH, I’d love to find a way to make archetype-based codesets like this be available as independent codesets - i.e you can ‘see’ them as FHIR codesystems/valuesets. Also somewhere that we could perhaps work more closely with LOINC .. and indirectly through to SNOMED as part of their alignment.
I’m explicitly talking about research reuse (while we don’t have official codes)