I assume that mappings could also contain constraint bindings right? 2017-03-15 23:20 GMT+01:00 Ian McNicoll <i...@freshehr.com>:
> 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. The > defining_code should be the one that is selected by the user. > > I would strongly suggest that you use mappings for this purpose. I would > also not bother with trying to place constraints via archetypes or > templates. You are really not achieving much that cannot be otherwise > simply documented or applied in software. > > Perhaps I'm still not understanding the requirement here? > > Ian > > > > > > Dr Ian McNicoll > mobile +44 (0)775 209 7859 <+44%207752%20097859> > office +44 (0)1536 414994 <+44%201536%20414994> > 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 15 March 2017 at 21:31, Bert Verhees <bert.verh...@rosa.nl> wrote: > >> 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>: >> >>> 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>: >>> >>> 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> 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 >>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_ >>> lists.openehr.org >>> >>> -- >>> Ian McNicoll >>> >>> _______________________________________________ >>> openEHR-clinical mailing list >>> openEHR-clinical@lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_ >>> lists.openehr.org >>> >>> >>> >>> >>> -- >>> >>> [image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ> >>> >>> [image: Twitter] <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn] >>> <https://htmlsig.com/t/000001C4DPJG> [image: Maps] >>> <https://htmlsig.com/t/000001BZTWS7> >>> >>> Diego Boscá Tomás / Senior developer >>> diebo...@veratech.es >>> yamp...@gmail.com >>> >>> VeraTech for Health SL >>> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023 >>> <+34%20627%2001%2050%2023> >>> 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. >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > clinical_lists.openehr.org > -- [image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ> [image: Twitter] <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn] <https://htmlsig.com/t/000001C4DPJG> [image: Maps] <https://htmlsig.com/t/000001BZTWS7> Diego Boscá Tomás / Senior developer diebo...@veratech.es yamp...@gmail.com VeraTech for Health SL +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023 <+34%20627%2001%2050%2023> 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.
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
