Op 22-3-2017 om 12:31 schreef Thomas Beale:
Just catching up on this conversation - I am unclear on why the
original solution Bert proposed here isn't correct. What this says is:
* for the ac0001 term constraint in the model, allow the term to be
from one of ETDA or ICD10
I think, t
Just catching up on this conversation - I am unclear on why the original
solution Bert proposed here isn't correct. What this says is:
* for the ac0001 term constraint in the model, allow the term to be
from one of ETDA or ICD10
Since this is set at the archetype level, it is stated as tr
Op 21-3-2017 om 22:34 schreef Heath Frankel:
You don't need to constrain the TERM_MAPPINGS to use it.
Regards
Heath
What if I want a specific number of Term-mappings? (I want two
term-mappings)
What if I want a specific terminologies to be used? (that was also part
of my question)
How do
From: Heath Frankel
Sent: Thursday, 16 March 2017 10:52 PM
To: For openEHR clinical discussions
mailto:openehr-clinical@lists.openehr.org>>
Subject: RE: Problem with constraint_binding
Perhaps I have come in at the wrong point of the conversation and missed the
original question but I
ot break the current schema. They appear to be assigned to R1.1 but not
> progressed to a CR.
>
>
>
> Heath
>
>
>
> *From:* Heath Frankel
> *Sent:* Thursday, 16 March 2017 10:52 PM
>
>
> *To:* For openEHR clinical discussions >
>
> *Subject:* RE: Pr
@lists.openehr.org>>
Subject: RE: Problem with constraint_binding
Perhaps I have come in at the wrong point of the conversation and missed the
original question but I believe that the SEC has already approved a change (or
at least got a change proposal from me, I’ll need to follow up to fi
solution to your
issue?
Heath
From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On
Behalf Of Bert Verhees
Sent: Thursday, 16 March 2017 8:31 AM
To: For openEHR clinical discussions
mailto:openehr-clinical@lists.openehr.org>>
Subject: Re: Problem with constraint_b
Thanks Peter, I must have missed it.
blush blush (missing my regular workstation/email client)
It is indeed the solution.
Sorry for that
Best regards
Bert
On 17-03-17 14:42, Peter Gummer wrote:
On 17 Mar 2017, at 22:39, Bert Verhees wrote:
The several countries have independent organizat
On 17 Mar 2017, at 22:39, Bert Verhees wrote:
>
> The several countries have independent organizations, and the overall
> organization cannot enforce a common terminology. There are two terminologies
> in this case, and those two terminologies cannot be mapped easily, because
> the granularity
It is a customer requirement. It is a real life problem.
It is not very helpful to me to have discussions about the good, bad or
ugly of solutions. But, of course, go ahead for your own interests.
It is about an international organization which processes data from
several countries.
The sev
On Fri, Mar 17, 2017 at 11:43:33AM +0100, GF wrote:
> Any item in an archetype potentially has:
> - an ad-hoc, locally defined, display name
> - an official canonical name in a specific language domain
> - and, in order to disambiguate it, an unique code in
> - a specific terminology/classificatio
Yes.
Any item in an archetype potentially has:
- an ad-hoc, locally defined, display name
- an official canonical name in a specific language domain
- and, in order to disambiguate it, an unique code in
- a specific terminology/classification domain
Gerard Freriks
+31 620347088
gf...@luna.nl
I'm not sure Diego. I guess so. We definitely need to be able to specify at
template level how/if any code bindings should be handled at runtime. I
suspect this might need some sort of rules that are a bit more complex than
just a simple constraint.
This conversation might be a chance to tease out
On Wed, Mar 15, 2017 at 09:31:27PM +, Bert Verhees wrote:
> The problem with to Dv_coded_text's is however that it offers two value -
> fields and that is not what we want.
But isn't the "name" field in any coded terminology "just
another code" for a concept ? Or, in other words, the
"canoni
I assume that mappings could also contain constraint bindings right?
2017-03-15 23:20 GMT+01:00 Ian McNicoll :
> Hi Bert,
>
> A dv_coded text can carry a single defining_code but as many code mappings
> as you wish. This makes sense to me as I would always expect one code to be
> regarded as the
Hi,
Multiple codes create the problem of deciding which one is ‘the truth’.
One code needs be declared to be ‘the truth’.
But…
‘The truth’ depends on the context the code is used in.
So how can one declare what the clinical/administrative/research context is?
And…
‘subject’ has ‘associated dat
Hi, I need to defer this discussion to next Monday. I will come back to
this. Thanks all for your input.
Best regards
Bert
Op wo 15 mrt. 2017 om 23:22 schreef Ian McNicoll :
> Hi Bert,
>
> A dv_coded text can carry a single defining_code but as many code mappings
> as you wish. This makes sense
Hi Bert,
A dv_coded text can carry a single defining_code but as many code mappings
as you wish. This makes sense to me as I would always expect one code to be
regarded as the original clinical source of truth, and other mappings to be
regarded as secondary. All of these can be queried via AQL. Th
a Leao<mailto:bfl...@terra.com.br>
Sent: Thursday, 16 March 2017 7:10 AM
To: For openEHR clinical discussions<mailto:openehr-clinical@lists.openehr.org>
Subject: Re: Problem with constraint_binding
Perhaps the best solution for the time being is to add an additional diagnosis
component
Perhaps the best solution for the time being is to add an additional diagnosis
component with the secondary terminology binding that might be used. This is
not so common and would need a BR specialization.
Beatriz
> On Mar 15, 2017, at 6:31 PM, Bert Verhees wrote:
>
> We are considering th
We are considering that Diego, the fact is that the customer wishes to code
the name -item two times. Both coding - systems are not easy to map and the
mapping cannot be calculated easily by software.
So we need two Dv_coded_text's to carry the codes, and only one value to
carry the name.
The pro
Thanks Ian, that explains.
Best regard
Bert
Op wo 15 mrt. 2017 om 12:14 schreef Ian McNicoll :
> Hi Bert
>
> This is correct. If you were to add those constraints in a specialised
> archetype, at run-time the submitted term in the defining_code attribute
> would have to come from one of the two
What about having two sibling DV_CODED_TEXT nodes as alternatives on the
parent? (or specialize two different ones from the single parent one). That
would allow to arbitrarily define constraint binding as needed, and in data
only one would be correct one
2017-03-15 12:13 GMT+01:00 Ian McNicoll :
Hi Bert
This is correct. If you were to add those constraints in a specialised
archetype, at run-time the submitted term in the defining_code attribute
would have to come from one of the two terminologies specified.
The constraint can define multiple potential terminologies but only one
defining_
24 matches
Mail list logo
