FHIR-like terminology 'binding strengths'?

Grahame Grieve grahame at healthintersections.com.au
Mon Apr 15 19:19:14 EDT 2019


HL7 allows you to do that - and we would like you to do that

Grahame


On Tue, Apr 16, 2019 at 9:16 AM Heath Frankel <
heath.frankel at 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-bounces at lists.openehr.org> *On
> Behalf Of *Grahame Grieve
> *Sent:* Tuesday, 16 April 2019 7:03 AM
> *To:* For openEHR technical discussions <
> openehr-technical at 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.beale at 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 at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
>
> --
>
> -----
> http://www.healthintersections.com.au / grahame at healthintersections.com.au
> / +61 411 867 065
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 
-----
http://www.healthintersections.com.au / grahame at healthintersections.com.au
/ +61 411 867 065
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20190416/fae8a453/attachment.html>


More information about the openEHR-technical mailing list