When I first began browsing openEHR information a few weeks ago, I read something on the web that left me with the impression that at least some openEHR people are in strong disagreement with HL7 people and/or parts of the HL7 standard (version 3, I presume). Would anyone be willing to educate me about this? Exactly where is the thinking within openEHR incompatible with the current trends of HL7?
Best regards
Ole Jørgen Anfindsen
Ole Jørgen Anfindsen wrote:
When I first began browsing openEHR information a few weeks ago, I read something on the web that left me with the impression that at least some openEHR people are in strong disagreement with HL7 people and/or parts of the HL7 standard (version 3, I presume). Would anyone be willing to educate me about this? Exactly where is the thinking within openEHR incompatible with the current trends of HL7?
People in this community may have widely varying views on this subject. My view of things is:
openEHR is predicated on a few key design principles not particularly compatible with the HL7v3 view of the world:
ISO RM/ODP - separation of information, services, enterprise viewpoints; in other words - a service architecture approach (although this is recently starting to emerge in HL7)
two-level modelling - stable reference model + archetypes & templates
orthodox object-oriented ‘extension’ (i.e. additive) semantics in object models
we haven’t used the HL7v3 specifications in general for a number of reasons:
they don’t generally address EHR requirements (they are essentially a new approach to doing messaging). An exception is the CDA specification, which has a lot of commonality with the Composition part of openEHR and CEN. However, we wanted an object model of these concepts; CDA release 1 was an XML-schema, and CDA release 2 is an RMIM.
they are problematic technically - e.g. the data types are difficult to implement, and have some design problems. The final chapter of the openEHR data types document gives some details - see http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/data_types_im.pdf
we haven’t found the RIM particularly useful or easy to implement.
Ontologically it presents problems (i.e. taken as a model of reality); it also doesn’t include all the semantics we wanted for the EHR, see http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/html/architecture/overview/Output/design_of_ehr.html#1161244 and following sections. I am not saying that openEHR’s model is ‘right’ (I guess there are no ‘right’ models only more or less ‘useful’ ones), but for us it represents a closer implementation of our analysis of the problem domain (or the ‘clinical information’ part of it anyway)
technically, its design is some kind of hybrid of an object-oriented model and (according to the authors) a model of relational projection, where you include all the possible attributes in top-level classes, and ‘remove’ them logically in lower level classes that are actually projections (i.e. particular selections of the total possible attributes) of the top classes. The semantics of inheritance are thus ‘subtractive’ not additive between the RIM and derived models. This has been called ‘upside-down’ inheritance by a lot of people, and isn’t a common approach in software engineering in health or elsewhere to our knowledge.
The refinement methodology for creating new schemas (RMIMs) from the RIM uses this projection/deletion idea, which causes problems for object-oriented system design (although it can be implemented - I believe it has been done in the HL7 Java SIG - but the designers of openEHR decided to use more orthodox modelling methods where abstract classes have few, common attributes and lower classes add to that).
In any case, each RMIM (i.e. each new message definition) is a new information schema, which is not consistent with the openEHR approach, which uses a single stable reference model, and archetypes and templates to create domain models. All information in an openEHR system is instances of the openEHR RM; in an HL7v3 message bank, it is instances of multiple message schemas.
RMIMs and CMETs have historically only provided 1 level of re-use in domain models. I have been told this could be changing now, but we wanted multi-level componentisation in archetypes, which has been there since the beginning.
in HL7v3, the RIM has to be the basis of all other models. In openEHR we have an extensible Reference Model (i.e. if we wanted to model workflow, we would add some new classes); we also wanted service interface specifications as separate models.
openEHR isn’t based on messaging as a paradigm, although of course it interoperates with messages.
however, some particular HL7 specifications are used, e.g. units (UCUM spec), a few of the data types (GTS, EIVL, PIVL); some terminology- HL7 didn’t have an equivalent to archetypes. It has some kind of ‘template’ notion being specified currently, but HL7 templates apply only to HL7 artifacts (i.e. RMIMs, CMETs etc) which we don’t use internally. Our need was for a kind of model that could easily be used to:
define clinical concepts
control data validation
generate GUI display elements
be the formal basis for queries (using paths)
the specifications coming from the HL7/OMG HSSP (services) project are more inline with openEHR system thinking, and the intention is to participate in this process
we are following the ISO data types activity that will hopefully provide a standard that all communities can use.
In summary a lot of good work and thinking has been done in the HL7v3 effort, but much of it is in the form of technical artefacts and a methodology that many people find difficult to use.
BTW, you can see a relatively up-to-date description of use of standards in openEHR here - http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/html/architecture/overview/Output/standards.html#1141279
hope this clarifies somewhat.