We need the ability to create value sets in archetypes (and templates) that are hierarchical. This should be done using "contains" and not "is a" semantics, since the items on a higher hierarchical level are not necessarily strict subtypes of the lower level items.
Example of hierarchical value set in FHIR: https://www.hl7.org/fhir/valueset-diagnostic-report-status.html
"Pulse irregular" contains "Pulse regularly irregular"
"Pulse irregular" contains "Pulse irregularly irregular"
Surely ‘contains’ here really means subsumes? Regularly irregular and irregularly irregular are both subsumed by irregular - those are the semantics of those terms. The visual display will follow the subsumption hierarchy.
The only problem that we have is that we can’t currently introduced subsumption (i.e. IS-A) children in the same archetype as the parent terms are defined, only in some child archetype.
It does mean subsumes in this case but it may not in other cases. We know this from SNOMED subsets - there is not always a direct relationship between the ‘natural’ order from a clinical perspective. If we had subsumption in the same archetype, that would be helpful but we would probably still need some kind of visual ordering/hierarchy. And getting same-level subsumption, realistically is going to take a while to get into production. It is definitely a nice to have but I’m not sure the effort is really worth it. There are probably only a small number of places where it is required for internal value sets, and by and large, more complex examples will end up being in external valuesets, especially as FHIR valueset support becomes fully supported.
I’ll take this back to clinical colleagues to discuss. I’d be happy to trade the inconvenience of having to query 2 terms vs. 1 , against the delay in getting it working. But I agree we should ask that question more widely, get more examples.
Could you explain what you mean with ‘visual’? Archetypes are data in models, with a representation in a language, ADL. There are many ways to visualise those models. Do you mean having enough data to be able to visualise the hierarchy in a tool, or visual as in layout in ADL?
If what is required now is some visual surrogate that gives the impression of subsumption (or other) relationships, then those relationships are going to have to be asserted somewhere other than archetypes, until such time as we add the capability to assert relationships more freely inside archetypes or else do it in some controlled archetype-related terminology (which I personally think is the more appropriate approach).
I think that sums up my emerging view pretty well . Whilst the need to be able to assert these relationships is undeniable, I’m just not sure that the effort required to add this right now is worth it (unless you or have some brilliant, quickly agree/adoptable/implementable ideas!!). I agree that the known, and potentially complex future requirements, make external ref terminologies a better option, especially as SNOMED seem to be loosening their licensing.
I have started a wee private discussion on the clinical side, which we will open up if we get consensus.