Private response, so OpenEHR list is not for further discussion?

Clinical (archive)
1

Dear all,

I did not get a respons on my viewpoints about the irrelevance of the HL7 v3 versus OpenEHR debate which is in my opinion, from a clinical and modelling point of view, irrelevant.

I need tools that help clinicians to express clinical needs, data, instruments, vocabulary and that supports their workflow and communication. Neither Open EHR nor HL7 currently can do this all. Both approaches need years of work ahead.

Joint work, especially on archetypes / templates, would both increase the number of standardised clinical items that can easily exchanged and documted in and between systems, irrespectively of their technical solution. Technology is not the issue with current XML based, distributed technology where storage and communication are integrated to almost indistinghuisable components. Of course each tecnology needs further work to make it work in clinical practice.

Of course there are differences in the technologies, and where OpenEHR is lacking obviously in the dynamic behaviour of data and workflow support (nicely modeled in HL7 moodcode), HL7 v3 will be lacking on simplicity for storing information as documents and the exact entry points for archetypes in the message (where the award earning OpenEHR division of systems and clinical models is strong), I see no solution in a blame and shame approach expressed in private messages.

I am very sorry that for some commercial? or power play? reasons this debate has moved into an area where I do not want to play. Is there a problem with the system of democratic votes on issues in one of these organisations? I really wonder what is behind all this energy flow to uselessness.

For me both the HL7 v3 messages and modeling and the OpenEHR archetype work are important. Especially since the major effort is in the appropriate definition and expression of the clinical materials, and the proper description of complex dynamics and communication in healthcare.

Can we please focus on finding solutions instead of blaming one system being dead, which is just a false accusation.

I challenge the OpenEHR community to work on improvement of the standardisation of archetypes and to work in cooperation with the HL7 community doing exactly the same.

These are my last words on this issue of either - or. I need my time to develop archetypes and tools that allow easy conversion from HL7 R-MIM format to OpenEHR format, so that I do not have to worry. I don’t care at all if some OpenEHR developers do not like HL7, I do not care if some HL7 developers do not like OpenEHR.
I wont both the things work and do not take “no” or “cannot do” as an answer. There is only imperfection, well lets make it the perfect imperfection then.

dr. William Goossen
archetype builder
see www.zorginformatiemodel.nl

2

Dear William

Thanks for that.

It is very important that the clinical requirements are met in the information space that is to provide the technology behind an EHR. I have been working in this space for 25 years and feel that it is time - in the openEHR space - to commit to developing the repository of knowledge within this space.

I have found you to be one of the few people on the planet who have a very strong grip on this - and I hope you will review the openEHR archetypes, as I am prepared to look at the HL7 RMIMs for guidance. I think you and we want a single source concept representation - we do not want a blood pressure or a diagnosis represented differently in a different communication - this is plainly unsustainable.

I hope you will let us see some more RMIMs and get some archetypes which are based on these. The set on the Ocean website represent a more formal process of agreement involving a lot of clinicians and feedback - and our knowledge repository is growing. We are attempting to keep links with HL7 artefacts in this knowledge repository.

I am some of the people on this list who are working in the openEHR space will underestimate the HL7 process - and visa-versa. This is not important. What is important is that we get systems out there communicating - and in the near future - as the political pressure to be successful in this space is growing.

We are committed to implementing openEHR and are doing so now - this does mean that some of the problems that are embodied in our current expression will be here for a long time to come. But the technology will go a long way into the future - and if enough countries embrace it - it will be a good solution for EHR systems and EHR to EHR communication.

HL7 is already implemented in the UK - but I think in a way that is not compatible with your approach - and also in Canada for a few messages. I am sure this international effort will continue to flourish and get around its own problems.

I am now more interested in implementation than design - I will leave that to the next generation. I am also interested in level 4 interoperability - not just facsimile communication. Both approaches can achieve this and we will see which is best for which purpose - this is healthy. The alignment of the clinical concepts into a single approach is laudible and I am sure everyone in openEHR will be keen for this to be the case. The reality is that the base models may be orthoganol - and it may require such a compromise to get a super-model on which to base the archetypes that there is no real benefit.

We have to accept a little diversity in the world if it is necessary.

I look forward to ongoing cooperation,

Cheers, Sam Heard

3

Dear William,

the core technical approach taken by openEHR to modelling is quite different from that taken by HL7. You do need to accept that we did this not for some emotional reason, but for absolutely objective clinical and technical reasons. openEHR is a requirements-driven EHR interoperability architecture. Our analysis of requirements (involving many people over many years) led us to certain kinds of models and thinking (see GEHR etc). More recent advances (archetypes, templates) produced a new modelling paradigm. Over this time, ongoing improvements to the reference model have been made, incorporating the thinking of many people, including people from this list. The result is an architecture which is:

  • completely object-oriented

  • based on accepted type systems (ISO 11404, programming language and XML type systems)

  • componentised rather than monolithic specifications

  • respects the RM/ODP separation of viewpoints (service models and information models)

  • clean separation of ontology/terminology, information models, and domain-level models of information

  • allows for relatively future-proof software systems and databases to be built

  • powerful information concepts like generic versioning and workflow-oriented Instructions

  • allows clinical and other domain people to model their concepts in a natural and flexible way

  • offers “single-source semantic modelling” in the sense that you only need to define an archetype once, and you can generate the appropriate schemas for databases, GUI software, messages, etc

  • developed in an open, engineering (requirements & design) environment, rather than a standards (meetings-based) development environment

  • implementable (there are implementations in 3 languages, some already deployed in production).
    Of course it is not perfect. But it is a very considered response to requirements, and also other available standards and technologies. And of course, it is still evolving.

During this time, we have made a very careful analysis of HL7v3 (as well as CEN EN13606, ASTM CCR, HL7 CDA and others). I myself went to HL7 working group meetings for about 4 years; so did many of my colleagues. So our engagement was not fleeting (nor was it inexpensive…).

HL7 is based on very different design notions, some of which are unfortunately incompatible with key items the above list. So, at an engineering level, the approaches cannot be merged (although we made significant efforts in this direction). We have certainly included useful thinking from HL7v3. To take one example, the openEHR datatypes specification is clearly influenced by the HL7 datatypes (and acknowledged in the relevant document). Nevertheless, at an engineering level the HL7 approach could not be used in openEHR. The main reason is that in the HL7 approach, all the primitive data types (integer, real, string etc) are redefined, incompatibly with existing primitive data types. This is a well-known problem within the HL7 organisation (and in CEN), and some steps have been taken to improve the situation. It is not yet resolved. There is now a work item in ISO TC 215 to try and solve it. In the meantime we need something that works (despite all this: have a look at the openEHR ‘encapsulated data’ or ‘timing specification’ types; they are nearly unchanged from HL7).

Clearly it would be nice to bridge the gap between RMIMs and other message models, and archetypes and templates. As far as I know, there is no solid specification of HL7 “templates” (their word for archetypes). Even if there were, there is still the problem of competing notions of any given clinical concept within HL7, expressed firstly as an RMIM, and secondly as a template. At least the former is heavily tied to the HL7 RIM and message development specifics, whereas from our point of view, domain concept models (archetypes) have to be cleanly separated from the underlying information model. This is how we can build systems based on only one set of stable schemas, which never change when archetypes change or are added. In HL7, the domain level specification is in each case a new information schema. So there is an important design principle at stake, which has profound consequences on system architecture. We have spent significant time in looking at harmonisation in this area. One problem has been HL7’s attitude is that it is up to the other party to re-express their ideas in the RIM or other related things, and to change their approach. The HL7 modelling approach is not up for modification in my experience.

I will mention one further area, where we have had significantly more success in harmonisation with HL7, which is the CDA specification. Dipak Kalra and others have spent a lot of time with the CDA group on cross-reviewing CDA / EN13606 / openEHR, and changes to the openEHR models have certainly come out of that.

I won’t go into other problematic areas, that would take all day. But I don’t think people who work on and develop openEHR can be accused of not engaging with HL7, or any other standards organisation for that matter. I would say we have bent over backwards, with minimal funding, to be involved.

The openEHR community is absolutely focussed on solutions (there are dozens of implementation projects going on around the world), and is also focussed on standardising archetypes and templates. We have published a completely generic (and industry-independent) language and model of archetypes, and work is going on to standardise actual archetypes. There is even an early archetype ontology server at http://www.dualitysystems.com.au/archetypefinder/archetypefinder. There are also some very interesting openEHR/HL7v2.x design approachs and solutions emerging.

I think you will find that people working on openEHR are very happy to cooperate with others. But cooperation is a two-way process.

  • thomas beale
4

Dear Sam,

Yes, let us continue with what we have been doing, try to model the reusable bits in such a way that technology becomes important, but not important which technology exactly. If the clinical stuff is expressed properly, we will find workarounds to fit in OpenEHR and in HL7 v3.

We have had a good presentation by Alan Rector this week at Terminfo, and he came up with some ideas to link data / fields / attributes with content = terminology and codes in a consistent matter, leading to a true XML representation based on the HL7 v3 format. I think, given the ease with which you transformed the R-MIM into the archetype, that we can work this way.

Evelyn commented on our R-MIM based approach to continue making these models, but to include perhaps different technical expression formats. This would imply to work up e.g. Barthel, including the value set differences in Eng and NL versions, and to include the R-MIM, the XML and your archetype in the same document. Hence let technicians find the representation that fits them best.

I even could think of including the dynamics of ordering, promising, performing and having an result (event).

You can have a look at www.zorginformatiemodel.nl where we have put the first 90+ examples in pdf. They are in Dutch, but the mapping table, which is most important for you I guess, are in English too. If you need a particular example translated, just mail and I will ask my colleagues to do so. We are keen on getting it really at the international level.

William

5

Williamtfgoossen@cs.com wrote:

Dear Sam,

Yes, let us continue with what we have been doing, try to model the reusable bits in such a way that technology becomes important, but not important which technology exactly. If the clinical stuff is expressed properly, we will find workarounds to fit in OpenEHR and in HL7 v3.

We have had a good presentation by Alan Rector this week at Terminfo, and he came up with some ideas to link data / fields / attributes with content = terminology and codes in a consistent matter, leading to a true XML representation based on the HL7 v3 format. I think, given the ease with which you transformed the R-MIM into the archetype, that we can work this way.

William,
we do need to be careful with statements like this. The 'transformation' you are talking about here is a manual one - a clnical person looking at an RMIM, and manually building a hopefully equivalent archetype in another tool. There is no guarantee that such a process will produce an archetype such that the data of the RMIM and the data of the archetype are in any automatically convertible; indeed, it is almost guaranteed that they won't be, based on what we already know of the features of any RIM-derived RMIM. So: this does not achieve sharing; it just means that there are a) two hopefully similar expressions of some domain concept floating around and b) still two incompatible data representations. This gives us no automatic power at all. Further, note that if there are N RMIMs, then there are N data schemas incompatible, probably mutually incompatible with each other as well as the schema of openEHR; but there is always only one schema of openEHR. So if we posit 150 RMIMs, there are 150 data schemas to worry about; in openEHR there is just 1.

Bringing any of this together requires it to be done in an automatable fashion, otherwise the two worlds of data will remain difficult to bring together.

Interestingly, work we have been doing with v2 messages indicates that we will be able to deal with them relatively easily, and there is a structured framework for this purpose underway already. It will be published on the openEHR website in the coming weeks.

Evelyn commented on our R-MIM based approach to continue making these models, but to include perhaps different technical expression formats. This would imply to work up e.g. Barthel, including the value set differences in Eng and NL versions, and to include the R-MIM, the XML and your archetype in the same document. Hence let technicians find the representation that fits them best.

I cannot imagine how a clinician, presented with "barthel" in an RMIM and an archetypes, and maybe various XML-based or non-XML-based expressions is going to make such a choice. How would they know what the implications of all these things are?

I even could think of including the dynamics of ordering, promising, performing and having an result (event).

You can have a look at www.zorginformatiemodel.nl where we have put the first 90+ examples in pdf. They are in Dutch, but the mapping table, which is most important for you I guess, are in English too. If you need a particular example translated, just mail and I will ask my colleagues to do so. We are keen on getting it really at the international level.

William

The ultimate point is that there absolutely must be a single set of models for clinical concepts. Secondly, that it must be possible to express these concepts clearly, and re-usably. Thirdly, that such expressions can be automatically translated for use in any particular deployment technology or circumstance. Having parallel libraries of such concept definitions (and this will probably be made worse with HL7v3 templates) is not going to be a useful step for healthcare.

- thomas

6

Further, note that if there are N RMIMs, then there are N data schemas incompatible, probably mutually incompatible with each other as well as the schema of openEHR; but there is always only one schema of openEHR. So if we posit 150 RMIMs, there are 150 data schemas to worry about; in openEHR there is just 1.

This is an important statement of fact.

The ultimate point is that there absolutely must be a single set of models for clinical concepts. Secondly, that it must be possible to express these concepts clearly, and re-usably. Thirdly, that such expressions can be automatically translated for use in any particular deployment technology or circumstance. Having parallel libraries of such concept definitions (and this will probably be made worse with HL7v3 templates) is not going to be a useful step for healthcare.

I agree.We all need a neutral and formally correct way to express clinical content.

And that could be EN13606 part2?

Gerard