ADL2 valuesets - extend beyond 'local' terms

Specifications ADL
,
1

Currently, the last main blockers in getting ADL2 over the line, are various issues around DV_CODED_TEXT constraints that are required and variably supported in .oet.

One of the options in .oet is to be able to define an inline external terminology valueset e.g.
https://ckm.apperta.org/ckm/templates/1051.57.253

SNOMED-CT::49727002::Cough SNOMED-CT::386661006::Fever SNOMED-CT::267036007::Difficulty breathing

Looking at AOM2, it feels as if we might usefully open up the valueset to include non-local terms, and indeed consider some other features in FHIR such as a simple way of nesting terms with in the valueset. Not having nesting has led to us (IMO) havesome rather mangled models - e.g. there is wel established pattern oin documenting pulse rythm of

Regular
Irregular
   regularly irregular
   Irregularly irregular

with some people wanting to stick at the top-level only, others preferring second-level detail for irregualr.

Flattening out the list was felt the wrong thing to do so we currently have 2 datapoints one for Regular/Irregular, the other for Type of Irregularity.

Controversy alert!!!

Is there even an argument for aligning our valueset with the helpful features in the FHIR valueset, so that becomes pretty well identical whether constrained locally or as an external rtef

2

What you would do for your example in ADL 2, is to define a local value set:

value set ac1:
    at1: cough
    at2: fever
    at3: difficulty breathing

Then define snomed term bindings:

at1: SNOMED-CT::49727002
at2: SNOMED-CT::386661006
at3: SNOMED-CT::267036007

Actually a bit different in your COVID-19 example, since they are used in separate template overlays you would get one value per template overlay, with the binding inside of the template overlay, but that does not matter much here I think.
This is how you define an external terminology value set in ADL 2, and which is also how the ADL 1.4 to ADL 2 converters handle this. This has the benefit that you always have the terms in the local terminology, so that the archetype works and is readable even without an external terminology server, plus you have the bindings to the external terminology available. Perhaps not inline, but I think not doing this inline is much easier - you only have to support one mechanism in many tools, instead of several.

The only thing you cannot do with term bindings is to store that a certain binding is the preferred way of storing this in the data, or if a certain binding should be included as a mapping, and I think we are missing a bit of text in the specification saying exactly which code should go in which field in the RM - that now offers several options.

I would actually prefer to always store at least the local code somewhere, which makes tool and form development much simpler.

For nesting, perhaps we can describe specialised value codes? As in for the parent archetype:

at1: regular
at2: irregular

child:

at1: regular
at2.1: regularly irregular
at2.2: irregularly irregular

You can then choose in the child archetype if you leave at2 or remove it from the value set, keeping only the children, plus any tool that can interpret the parent archetype can still interpret this data. I think that is already possible right now in ADL2, but I’m not entirely sure - I would have to check the conformance rules.
I would still say you would want to keep the local codes in the RM data here as well.

1 Like
3

That does not sound right, since it’s really only one datapoint, so that’s creating a complication for software and display and so on.

To achieve what you want, i.e. subsumption (I assume that’s what you mean by ‘nesting’) you can just create child at codes as @pieterbos showed lower down in this thread, in a child archetype, because a code of the form atN.M is understood in ADL as a subsumption (i.e. specialised) child code of atN. The fact that you have to define the children in a specialised child archetype is a bit unfortunate, and is a consequence of our self-defining code system.

One way around that might be to consider codes that represent subsumption children of another code, but can be introduced on the same level. Now, since ‘at-codes’ are intended to represent only values (unlike ‘id-codes’, which essentially represent names/types of things), we might be able to simply relax the rule that relates the number of ‘.’ in a code to the specialisation level of the archetype. I have never thought about this, so don’t know what would break, but I suspect, not too much (This is a good example BTW of a semantic difference between id-codes and at-codes.)

Getting away from the limitation completely means a really big change:

  • changing ADL at-codes to be meaningless ids, e.g. 10-digit numbers or whatever
  • maintaining a terminology repository next to all archetypes, containing all such codes, and their relationships in it (since now you can no longer tell that at1.0.5 is a child of at1)
  • providing a superfast way of creating new codes on the fly, that never clash with anyone else’s codes (probably doable if codes are prefixed by fully namespace-qualified archetype ids.

I think we should think about the former option :wink:

4

I don’t think the ‘big change’ is really justified. If we ainto that territory a proper TS is really required.

The idea of atCode inheritance without requiring a child archetype look like a possibility that is worth exploring.

I’ll play around with Pieter’s suggestion re using bindings as this also crosses into the bindings/mappings question.

5

Me neither. I was just trying to fill everyone with appropriate horror and dread…

I’m starting to like it myself…

6

While same archetype code inheritance is probably a good solution (and respects the ontological part of the codes, which I like) it can probably have an impact in current systems that assume the level of specialization by counting dots in the identifier.

But as I say, I think it’s probably right

7

Oh I didn’t think about in the same archetype - of course, you need that too. If done with dots, that might break some things indeed, although it could be possible for just the at codes.

Alternatively, we could do things like a separate code relationship section, where you can define things like nesting, and/or other code relationships. But that could also be done in a separate terminology server?

8

There are actually use-cases for a similar approach on the ‘id’ side re run-time name constraints. Again from the pulse archetype. We may have changed it now but at one point we had a need to do something like this

pulse/heart rate
pulse rate
heart rate

as in most cases the distinction is neither important or specifically recorded but there are some situations where it is important to document whether this was pulse rate or heart rate explicitly.

9

We have indeed thought about this for a very long time (here’s a CR on it from 2008!). Everytime I look at that approach, I shy away from the danger of recreating terminology inside archetypes.

Having said that, it could make sense to think about how the at-codes (in ADL2, so not the id-codes) could be one taken outside archetypes and added to an archetype vocabulary. Then we have to solve all the classic problems of terminology, like issuing new codes etc etc. But probably solvable if done without trying to re-invent SNOMED.

10

I’m following some but not all this thread. Totally agree that this critical area needs improving. As CKA, I’m also a little uncomfortable that you are potentially making changes that may have a significant impact on our modelling patterns/processes, and may have governance consequences for existing archetypes. I know that Ian is intimately involved in your discussions, but it seems appropriate to have all CKAs across the proposed changes.
At an appropriate time I would appreciate if we can schedule a call to brief both Silje and I so that we are all in agreement before it is locked down as a technical solution?
Thanks

2 Likes
11

No rush on this one - I would be as concerned as you, because this change would be radical, since it breaks the long-established rules of archetype codes. We would do a lot of analysis and public discussions before going anywhere near actually doing it. Right now, I have not even worked out a basic analysis of it.

There are other changes coming which are much less drastic and I think contain no surprises - the coding ‘strength’ being one, which I think everyone more or less understands, and won’t break anything in CKM (@sebastian.garde is probably the most knowledgable on it in fact).

The other one is more meta-data on bindings, which I think everyone agrees is needed, and the tech side just has to make sure existing archetypes upgrade cleanly (would be done as an ADL1.4 → ADL2 upgrade I think).

3 Likes
12

Hi Heather,

Totally agree, indeed I 've been meaning to start a ‘clinical’ conversation (prob best in Slack for now?) on the implications. The COVID work has been quite instructive as, for me at least, it is the first time I have been trying to maximise use of SNOMED-CT, in an international context. Agree - time to broaden the conversation about what we think we need from a ‘valueset’, based in a few years of experience and a big push in recent weeks.

Ian

3 Likes
13

Conversation started.