You don't need to constrain the TERM_MAPPINGS to use it.
Regards
Heath
On Tue, Mar 21, 2017 at 11:50 PM +1030, "Bert Verhees"
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>> wrote:
I was checking again with the multiple simultaneous terminology mapping on one
text item.
TERM_MAPPINGS could do, but the archetype-editor, nor the ocean, nor the
linkehr support it. The template-editor does not support it well. This makes it
unmaintainable for the company I work. I could hack it in the datasets, but I
am only on temporary base here, that is why this
It seems that other have similar problems, and I think a revise of the RM is
necessary. Multiple defining_codes on one DV_CODED_TEXT does not break existing
datasets or archetypes.
And to support the non-code-hackers, a new check on the tooling (regarding to
term-mapping) will be necessary, even to support the existing RM features.
Bert
Op zo 19 mrt. 2017 om 23:35 schreef Heath Frankel
<heath.fran...@oceanhealthsystems.com<mailto:heath.fran...@oceanhealthsystems.com>>:
See SPECPR-132 and proposed solution in SPECPR-165 which is designed to not
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
<openehr-clinical@lists.openehr.org<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 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 find the Jira
card) to add a value to the mappings code phrase. Is this a 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
<openehr-clinical@lists.openehr.org<mailto:openehr-clinical@lists.openehr.org>>
Subject: Re: Problem with constraint_binding
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 problem with to Dv_coded_text's is however that it offers two value -
fields and that is not what we want.
It is a pity that a Dv_coded_text only can carry one code. I don't understand
that restriction but we cannot solve that now, I hope this can be considered in
a RM change.
So I think, we will have two Dv_coded_text's and from one having the value put
of in a template if that is possible. I look into that tomorrow.
Best regards
Bert
Op wo 15 mrt. 2017 12:20 schreef Diego Boscá
<yamp...@gmail.com<mailto:yamp...@gmail.com>>:
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
<i...@freshehr.com<mailto:i...@freshehr.com>>:
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_code is allowed in the instance data.
Ian
On Wed, 15 Mar 2017 at 10:29, Bert Verhees
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>> wrote:
Dear readers,
I have a problem and I want to ask your advise.
The problem is that I want to use openEHR-EHR-EVALUATION.problem_diagnosis.v1
which is in CKM.
In that archetype is the item "Problem/Diagnosis name", which is of type
DV_TEXT. We want to use it as DV_CODED_TEXT, because we want to add code to the
entered name.
In this situation where I work, the customer wants to use 2 different codes,
one company crerated internal codelist, and ICD10.
It seems easy to arrange in the archetype, I think I need to specialize it,
because I want to add the constraint-bindings to give room for the codes. The
archetype-editor from Ocean allows two constraint-bindings on the same node,
like displayed below. But this seems wrong to me.
In the reference model in the DV_CODED_TEXT is one CODE_PHRASE (1..1). And
CODE_PHRASE has terminology_id and code_string also 1..1
So how will the construct below be interpreted following the specs?
constraint_bindings = <
["ETDA"] = <
items = <
["ac0001"] = <terminology:ETDA>
>
>
["ICD10"] = <
items = <
["ac0001"] = <terminology:ICD10>
>
>
>
My second question, if you say this is impossible to add two terminology
constraints to one data-item, which construct do you advise to make two
terminology constraints_bindings available to one DV_CODED_TEXT (or maybe
another datavalue-type)?
Thanks for any help.
Best regards
Bert Verhees
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org<mailto:openEHR-clinical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
--
Ian McNicoll
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org<mailto:openEHR-clinical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
--
[VeraTech for Health SL]<https://htmlsig.com/t/000001C268PZ>
[Twitter] <https://htmlsig.com/t/000001C47QQH> [LinkedIn]
<https://htmlsig.com/t/000001C4DPJG> [Maps]
<https://htmlsig.com/t/000001BZTWS7>
[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]
Diego Boscá Tomás / Senior developer
diebo...@veratech.es<mailto:diebo...@veratech.es>
yamp...@gmail.com<mailto:yamp...@gmail.com>
VeraTech for Health SL
+34 961071863<tel:+34%20961%2007%2018%2063> / +34
627015023<tel:+34%20627%2001%2050%2023>
www.veratech.es<http://www.veratech.es/>
Su dirección de correo electrónico junto a sus datos personales forman parte de
un fichero titularidad de VeraTech for Health SL (CIF B98309511) cuya finalidad
es la de mantener el contacto con usted. Conforme a La Ley Orgánica 15/1999,
usted puede ejercitar sus derechos de acceso, rectificación, cancelación y, en
su caso oposición, enviando una solicitud por escrito a
verat...@veratech.es<mailto:verat...@veratech.es>.
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org<mailto:openEHR-clinical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org<mailto:openEHR-clinical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
