Hi! On Thu, Sep 13, 2012 at 11:15 AM, David Moner <damoca at gmail.com> wrote:
> 2012/9/13 Erik Sundvall <erik.sundvall at liu.se> > >> It would be great if e.g most of the future ISO 13606 version could be a >> true subset of openEHR instead of the current confusing situation. > > > This is something I discussed with Thomas some time ago, it would be one > of the best harmonisation solutions, but probably with a slightly different > interpretation. Since 13606 has more generic classes (eg. the generic ENTRY > can represent all of OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead > of 13606 being a subset of openEHR I think that openEHR should be a > specialized model of 13606. I don't care if one is called a specialisation of the other, or a subset the other way around :-) as long as it all works properly in software. Would thoughts along the lines of http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+-+CIMI+version+1 work for the ISO 13606 use cases you are thinking of? Or do you need something like the yellow boxes in "Candidate C" at.. http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model?focusedCommentId=37978115#openEHR2.xRMproposals-lowerinformationmodel-CandidateCsimplificationandclassrenamingforeasierexplanationandimplementation The main issue is probably on which class the "data" attribute fits if we want the openEHR entry types to specialize the 13606 entry class - in e.g. OBSERVATIONS you may not want to use the same attribute name for another datatype. In "Candidate C" the CARE_ENTRY could share the same "interface" as ENTRY but it is not a direct specialization of ENTRY in implementation languages without multiple inheritance (like Java). Another option would of course be to call the current data-field of OBSERVATION something else than data and make a call for the data field on an observation return some kind of summary/conversion adhering to 13606 structures (in a way inspired by the as_hierarchy in the DATA_STRUCTURE class, see 3.2.1 in http://www.openehr.org/releases/1.0.2/architecture/rm/data_structures_im.pdf ) > Obviously this would require a deep analysis and changes of the models, > but that could be the idea. Yep, deeper analysis of the thoughts above would also be neccesary. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121007/3fb7a612/attachment.html>
