lessons from Intermountain Health, and starting work on openEHR 2.x

Erik Sundvall erik.sundvall at liu.se
Sun Oct 7 15:41:25 EDT 2012


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-clinical_lists.openehr.org/attachments/20121007/3fb7a612/attachment.html>


More information about the openEHR-clinical mailing list