I have another use case. Archetypes like Spirometry result are modelled using an internal cluster containing a “Test name” and a “Result” element due to the large number of possible tests which would make the archetype huge if every single one was modelled as a separate static element. The possible test names are included in the archetype as a value set of the “Test name” element:
This looks forgivable in the picture, but when we want to start adding SNOMED CT bindings to the value set it breaks down a bit. The correct SNOMED CT code for these test names would be “observable entity” ones, like 50834005 |Forced vital capacity (observable entity)|. At least to me, it’s weird to put “observable entity” terms as the value set of a text element. It should really be the name of the “Result” element, which leads us back to the question:
How do we utilise the DV_TEXT of the element names, and archetype them as DV_CODED_TEXT? Is this a tooling issue? Could we ask @borut.fabjan and @sebastian.garde to implement this in AD and CKM, and it’d work in implementations? Or are there larger issues?
If I understood it properly it would be solved in ADL1.4 with an acxxxx code that points to a snomed expression in URI form such as this http://snomed.info/ecl/<71388002 (which is any snomed procedure). I agree that observable entity seems to be the incorrect snomed hierarchy
Can I do this in AD? And what if I want to specify a set of SNOMED codes in the archetype, without a single value set URI to point to?
I think it’s the correct hierarchy, but it should be naming the actual data element of the result value (the “Result” DV_QUANTITY in the image above), and not be sitting in a DV_TEXT value set in another data element.
I would say that for sets of codes we should use the termset mechanism (available in CKM) to define valuesets that live outside the archetypes themselves. When having a defined valueset that way you could point them from the archetypes as URI. Currently there is only one termset defined in CKM (Clinical Knowledge Manager) but you could use that URI as is to point to the defined valueset, and evolve it at it’s own pace.
Do you want to define something like this? I’m not sure that AD will let you do that
PS: just checked in athena vocabulary browser and observation entities would end up as measurements in OMOP, so I think they are the right codes for this (procedures would end up in other tables)
In most cases we want the archetype to be self-contained, so that it can be used both with and without a terminology server or a licence to for example SNOMED. So just linking to a value set in a terminology server isn’t enough, we need to be able to do this internally in the archetype.
In the case where we have multiple ‘names’ for an observation, should we use name constraints in the same element, or should we carry the name of the observation in a separate element.
Name constraints does feel like a more natural approach, and is a more ‘openEHR’ way of doing things but is quite confusing to integrators coming from other disciplines- that was why in the Lab analyte discussions, we moved (after a lot of discussion) from using name constraints on the Analyte result element, to adding a Analyte value element, which lines up with HL72 and FHIR. And I guess the same pattern has been adopted here.
I understand what you mean when you say that it seems odd to have an observable as a value but that is exactly how it is used almost everywhere else outside openEHR.
Whether we use one approach or the other, we have an identical problem in how we represent the bindings and (in templates) the actual deployed mappings, especially as we will find situations whee the actual text recorded via the UI may differ from either our internal codes or the terminology rubrics, and we need to be able to constrain what might be quite complex structures.
I agree but I think we should look at being able to use a FHIR Valueset inside the archetype, as an option. Controversy alert!! And that does not solve the problem of how we would express the constraints on that Valueset but I think it might be a good place to start.
This whole area is definitely a tricky area and I think we should take a good look at what works and what does not, both in openEHR and FHIR.
The ‘use name constraint or not’ issue is more one of style I suspect, though it might be easier to argue for name constraints if we go the mapping constraint challenge sorted and enabled in tools.
I think the key is, when coding result if the binding should point to the test code or to a code telling something like " 423100009 | results section (registry element) |"
when doing “test name” as an element the codes go explicitly as data, while when putting in the result you will end up saying that a “result” (with semantics of registry) is mapped to a measurement code which could also cause their own set of problems
Just saying that if we make external references to archetypes, nowadays it should likely be by referencing FHIR value sets rather than the original CKM (OTS) termsets. (Do I need to duck and cover?)
Re support for TERM_MAPPING Diego also mentions above (and I agree with):
I don’t think these mappings would currently be displayed in CKM…but if someone can write them to the ADL, we should be able to extract and display these mappings as well. (Although the exact display may be a challenge and may need some discussion).
That’s interesting. What does the terminology policy in Norway look like? My observation is that in most countries (especially in ones with access to SNOMED), there’re initiatives that parallel openEHR and FHIR modelling, but using terminologies, like this one. Would not it be a challenge to keep archetypes synchronised to this type of work if you embed (if I may call it that) the subset of terminologies into Archetypes instead of referencing them? I won’t speculate further in case I’m completely clueless, you and/or @ian.mcnicoll can educate me on this one.
Typically these national terminology efforts create large thematic lists based on SNOMED hierarchies that are often othogonal to the detailed requirements inside archetypes (or indeed FHIR resources). In other words the exact codes you need are often very contextual to the specific archetype e.g. body position codes for pulse vs. body site codes for blood pressure measurement. Added to that , if you look at e,g the Dutxh ZIBS standards they often have mixes of SNOMED and other terminolgies very specific to the ‘archetypes’. Traditional refsets have not been an option
However the advent of FHIR Vsaluesets has made things a bit more blurry and I can imagine use-cases for managing some highly contextual codelists internally vs others referencing out to nationally managed Valuesets.
Both approaches have validity depending on circumstances.
Talking with @bna about this today made me realise that using DV_CODED_TEXT as an element name is essentially what we do when we apply a run-time name constraint to an element in an archetype, whether we use internal (at) codes or an external terminology. If we could apply (external terminology) run-time name constraints to elements at the template level, this issue would be solved.
Incidentally, this could also solve the issue of paths prone to change whenever a typo is discovered, by using paths like
[openEHR-EHR-OBSERVATION.problem_screening.v1]/data[at0001]/events[at0002]/data[at0003]/items[at0022, and name/defining_code/code_string='5' and name/defining_code/terminology_id/value='my_local_terminology']/items[at0005]
instead of
[openEHR-EHR-OBSERVATION.problem_screening.v1]/data[at0001]/events[at0002]/data[at0003]/items[at0022, and name/value='Have you ever had any had a lung or heart disese or any other thing we shuld know about?']/items[at0005]
( ^ this is a made up example, but unfortunately this kind of question (typos and all) is all too common in questionnaires)
too.