Re: FHIR-like terminology 'binding strengths'?

[Thomas Beale]

On 16/04/2019 23:37, Grahame Grieve wrote:

hi Tom


well we need to be precise about what 'extended' means. If you add
first level siblings to the previous version of your value set, it
means your value set was incomplete when published.

yes. and that's the point. The world gets by on incomplete agreements


well specifying and publishing an incomplete value set in a model 
intended as some sort of standard means the authors don't understand 
terminology. Consider: if new top-level codes are later found, they 
really should be children of an 'other' top-level category in the 
original value set.


Nevertheless, I take your point that much of the e-health world doesn't 
really know what it is talking about...




If you want to add children (by far the most common case in
hierarchical terminologies like SNOMED and ICDx) there's no
problem, you are just adding more specific choices of a more
general category you already had.

actually, that *is* the problem. You're taking an agreement and 
varying from it for no good reason. In a world where everyone has a 
terminology server and time to consult it, that may be harmless. But 
only may (there's deep subtleties there). And that's not a world we 
live in.


there are usually very good reasons: non-A-non-B-hepatitis became half 
an alphabet in the last 20y.






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.


probably true; any 'required' or other setting should probably
only be applied at template level.

I think that's a silly rule. Sometimes, the code is inherent to the 
meaning of the structure. Let people say what they need to where they 
need to.


well I wasn't thinking it should be a rule. What Heath meant (I think) 
was that in reality, the 'required' assertion would be most likely at 
local / template level, not at central level. But we should not prevent 
it being used at any level.





yep. it's a mess. Only human review can establish if there was a code 
that should have been used. I completely understand why you dislike 
this as a systems engineer. But reality doesn't go away.


btw, in all my code, I don't treat preferred and example differently 
in code. the only meaningful difference is in the message you give to 
people making templates up, and it's subtle. It was me who invented 
example, and it's proven a very useful way to get designers to be 
concrete about their meaning when they are making designs that are 
about capabilities rather than actual solutions.


It still seems to me that the right model for this concept is more like:

 * /conformance/: required | extensible | optional
 * /usage/: recommended | example

With only the /conformance /attribute being machine processable.

- t



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: FHIR-like terminology 'binding strengths'?

[Grahame Grieve]

hi Tom


> well we need to be precise about what 'extended' means. If you add first
> level siblings to the previous version of your value set, it means your
> value set was incomplete when published.
>
yes. and that's the point. The world gets by on incomplete agreements

> If you want to add children (by far the most common case in hierarchical
> terminologies like SNOMED and ICDx) there's no problem, you are just adding
> more specific choices of a more general category you already had.
>
actually, that *is* the problem. You're taking an agreement and varying
from it for no good reason. In a world where everyone has a terminology
server and time to consult it, that may be harmless. But only may (there's
deep subtleties there). And that's not a world we live in.


>
> 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.
>
> probably true; any 'required' or other setting should probably only be
> applied at template level.
>
I think that's a silly rule. Sometimes, the code is inherent to the meaning
of the structure. Let people say what they need to where they need to.

> well I am looking for computability. If we go the FHIR way, people are
> going to be writing code like:
>
> if (x.required) {
> // make sure value is from code set
> }
> elseif (x.preferred) {
> // hm... anything goes
> }
> elseif (x.extensible) {
> if (x.value == some code not in the value set) {
> // hm... how to determine if there was a code
> // in the vs that should have been used?
> }
> }
> elseif (x.example) {
> // ?ignore / don't care ?
> }
>
> And probably all doing it differently.
>
yep. it's a mess. Only human review can establish if there was a code that
should have been used. I completely understand why you dislike this as a
systems engineer. But reality doesn't go away.

btw, in all my code, I don't treat preferred and example differently in
code. the only meaningful difference is in the message you give to people
making templates up, and it's subtle. It was me who invented example, and
it's proven a very useful way to get designers to be concrete about their
meaning when they are making designs that are about capabilities rather
than actual solutions.
.
Grahame
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: FHIR-like terminology 'binding strengths'?

[Thomas Beale]

'Example' is surely a documentation level concept, not a computational 
one, and I would think often local. So if you are locally saying 'here's 
an example', it's pretty close to saying 'we recommend you use this (in 
this locality)'. So I would think at best it would appear in the 
annotations section of an archetype if in the archetype at all; probably 
more like template documentation?


- thomas



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: FHIR-like terminology 'binding strengths'?

[Thomas Beale]

On 16/04/2019 00:16, Heath Frankel 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.


well we need to be precise about what 'extended' means. If you add first 
level siblings to the previous version of your value set, it means your 
value set was incomplete when published. If you want to add children (by 
far the most common case in hierarchical terminologies like SNOMED and 
ICDx) there's no problem, you are just adding more specific choices of a 
more general category you already had.


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.


probably true; any 'required' or other setting should probably only be 
applied at 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.


well I am looking for computability. If we go the FHIR way, people are 
going to be writing code like:


if (x.required) {
    // make sure value is from code set
}
elseif (x.preferred) {
    // hm... anything goes
}
elseif (x.extensible) {
    if (x.value == some code not in the value set) {
        // hm... how to determine if there was a code
    // in the vs that should have been used?
    }
}
elseif (x.example) {
    // ?ignore / don't care ?
}

And probably all doing it differently.

- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: FHIR-like terminology 'binding strengths'?

[Thomas Beale]

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-5 concepts, but most 
of that is a very lng 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.




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: FHIR-like terminology 'binding strengths'?

[Ian McNicoll]

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  *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-5 concepts, but most of that is a very
> lng 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 
> 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 i

Re: FHIR-like terminology 'binding strengths'?

[Grahame Grieve]

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.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  *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-5 concepts, but most of that is a very
> lng 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 
> 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 

RE: FHIR-like terminology 'binding strengths'?

[Heath Frankel]

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  On Behalf 
Of Grahame Grieve
Sent: Tuesday, 16 April 2019 7:03 AM
To: For openEHR technical discussions 
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-5 concepts, but most of that is a very lng 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 
mailto: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 val

Re: FHIR-like terminology 'binding strengths'?

[Grahame Grieve]

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-5 concepts, but most of that is a very lng
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 
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
> 
> .
>
> 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
> ).
> Some here will recognise this question as roughly the one that FHIR's
> 'binding strengths' 
> 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 
> Consultant, ABD Project, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
>  | The Objective Stance
> 
> ___
> 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

FHIR-like terminology 'binding strengths'?

[Thomas Beale]

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 
.


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 
). 
Some here will recognise this question as roughly the one that FHIR's 
'binding strengths'  
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 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org