Hi All The idea was that the code_phrase was directly entered as part of choosing the text from the terminology. Anywhere where coding is done as a secondary process, the code mappings allow multiple codes.
I think this meets all the needs you have specified. Mappings allow each terminology to be specified. It is likely in the future that EHRs will have multiple mappings for different purposes and different eras of computing, allowing upgrading of historical data. Cheers, Sam Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Beatriz de Faria 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 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 <bert.verh...@rosa.nl<mailto: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<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
