FHIR-like terminology 'binding strengths'?

Thomas Beale thomas.beale at openehr.org
Tue Apr 16 05:42:36 EDT 2019

I meant to say, in the previous post:

For large domain value sets (anything beyond ?200), I assume the value 
set sits in a terminology service, and the archetype just has a binding 
straight to that. /So there is no problem with the changing contents of 
this kind of value set/, from the archetype point of view, i.e. it's 
always the same value set, even if specific codes change in its usage. 
/We are only talking about literally inline-included value sets/.

- thomas

On 15/04/2019 22:32, Grahame Grieve wrote:
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20190416/aeb78bf3/attachment.html>

More information about the openEHR-technical mailing list