hi Tom We did not define extensible bindings because we like it. Using it creates many issues and it's problematic. We defined it because it's a very real world requirement, in spite of it's apparent 'unreliability'.
The use cases arises naturally when - the approval cycle of changes to the value set is slower than operational requirements - the value set is large, and a community can only get partial agreement in the space. This is actually pretty common - typically, clinical code sets may need to contain 5000-50000 concepts, but most of that is a very loooong tail, and 95%+ of the use comes from 200-400 common codes. There's plenty of clinical communities investing time in requiring common agreed codes with fixed granularity for the head of the distribution. Neither of these things are an issue if openEHR is just targeting single application functionality. But as soon as the community that maintains the value set is wider than the users of a single system, then extensible bindings are inevitable. You can consider it bad... but that doesn't make it go away. Nor does it reduce the value of the agreements that do exist. Grahame On Tue, Apr 16, 2019 at 1:27 AM Thomas Beale <thomas.be...@openehr.org> wrote: > 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 > -- ----- http://www.healthintersections.com.au / grah...@healthintersections.com.au / +61 411 867 065
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
