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 <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
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
