Last week, we had a workshop on ADL2 in Germany, to try to sort out a
few issues on the way to making ADL2 mainstream in openEHR
implementations. See here for the wiki page
<https://openehr.atlassian.net/wiki/spaces/ADL/pages/382599192/ADL2%2BTooling%2BWorkshop%2B2019>.
One of the issues discussed was on what basis terminology code
constraints (value sets, generally) in archetypes (or templates) could
be considered optional, recommended etc (discussion page here
<https://openehr.atlassian.net/wiki/spaces/ADL/pages/386007225/Local+Value-set+Replacement>).
Some here will recognise this question as roughly the one that FHIR's
'binding strengths' <http://hl7.org/fhir/R4/terminologies.html#strength>
tries to solve. I can understand two of the settings:
* /required/: thou shalt use one of these here codes
* /preferred/: we recommend these codes but you can use what you like
I don't know how useful it is to put 'example' value sets in a content
model, since there might be many possible examples, differing across the
world. If there is an obvious example that makes sense for the scope /
geography of application of the archetype, e.g. some SNOMED or LOINC
subset, then this seems to me to be a case of 'preferred'.
But my main issue is with 'extensible'. In FHIR, this means: you should
use one of these codes if it applies to your concept, but otherwise you
can use something else. In my view, in reality, this is the same as
'preferred'. It's worth considering what it would mean to mandate codes
that are supplied in a value-set, but then to say, for other meanings
not covered, use something else. This means that the value-set is
considered not to be complete, i.e. to exhaustively cover the concept
space. Supplying half-built value-sets seems like a very unreliable
thing to be doing in shared clinical models. Is the value set 90%
complete? Or only 10%? The whole idea of specifying partial value sets
in clinical models just seems bad to me.
If we assume that value sets are always well-designed, and exhaustive,
then the only real 'binding strengths' are: required | optional.
I have proposed that this be modelled as:
* required: Boolean
* recommendation: enum ( preferred | example )
If we get rid of the example idea (which I think is just noise) then we
just need 'required'. If required is false, and there is a value set
specified, clearly it is 'preferred' or recommended in some sense. If
there is no value set, it's truly open.
Interested in other thoughts on this, particularly a) users of this FHIR
scheme and b) SNOMED, LOINC, ICD etc specialists.
--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/> | The Objective Stance
<https://theobjectivestance.net/>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
