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
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 chil
'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 se
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 b
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 archety
gt;
>
> 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 strengt
t 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
> *
-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'.
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
9 matches
Mail list logo