Hi Heath, I agree with you, other than that use of required may be helpful for some local archetypes, or for some safety-critical valuesets, so I would keep it in. 'Example' has been useful for us in the UK, in that looking at the FHIR resource examples, even though rejected, has given us a clearer idea of the intended purpose of the node. I think I also prefer the flat-list instead of introducing boolean but will think about that a little more.
Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: i...@freshehr.com twitter: @ianmcnicoll Co-Chair, openEHR Foundation ian.mcnic...@openehr.org Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On Tue, 16 Apr 2019 at 00:16, Heath Frankel < heath.fran...@oceanhealthsystems.com> wrote: > Hi Tom, > > I agree with Grahame, in over 20 years of implementing real systems, I > don’t think I recall having seen one value-set that hasn’t been extended at > some point when locally implemented. Even HL7 defined tables in V2 that > were supposed to not be extended have been extended. > > > > There is a big difference between best-practice and reality and we don’t > want to be putting any more barriers to adoption. > > > > To be honest, I am not sure that using required at an archetype level > would be wise, it may be something that can be used at a template level. > > > > You could argue that preferred covers extensible and I agree that example > may not be useful in models, but has proven to be useful as a guide for > FHIR readers. > > > > Therefore, I think we still have Boolean option, either required or > preferred/extensible/example. > > > > Having said that, using a Boolean doesn’t allow for us to support a valid > use case in the future and I see some value in aligning with the FHIR > options (if HL7 allow us to do that) even if we only support a subset. > > > > Regards > > > > Heath > > > > *From:* openEHR-technical <openehr-technical-boun...@lists.openehr.org> *On > Behalf Of *Grahame Grieve > *Sent:* Tuesday, 16 April 2019 7:03 AM > *To:* For openEHR technical discussions < > openehr-technical@lists.openehr.org> > *Subject:* Re: FHIR-like terminology 'binding strengths'? > > > > 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 >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
