ISO 21090

Technical (archive)
21

IYou apparently misread my comment. The mountains of money I assume you
mean UK was spent on many things, including archetypes. Great. I don't

that is one place mountains of money were spent (a few £100k on
archetypes), but not the only one.

understand the comment "I know for a fact that the outcomes (using v3) are
not seen as good value. I have heard the opposite from those people who
spendt a lot of money. In any case, it is a value proposition. We use v2
at Duke because it works for us, and we control the environment.

none of this conversation (at least on my side) is about v2; v2 is
proven technology, even if old, and it does more or less what it says on
the tin, if you control it well enough (e.g. like via the specific v2
message standards in Australia).

  CDA is a
v23 product - based on the HL7 RIM. Thanks for the compliment that CDA is
findoing great use. I declare that success.

well it is finding use that's for sure, how widespread it is I can't
say. You can move data with it. You can't built a realistic EHR with it;
distributed versioning is not defined, querying is not defined (other
than: figure it out some Xpaths yourself). Representing properly
structured data with it has not been done much, and is widely recognised
and claimed by HL7 experts to not be its main use case.

I don;'t care if the throw the red ball, roll the red nball, or toss the
red ball as long as I know it is a red ball.

To all: I recognize that Thanksgiving is uniquely a US Holiday, but permit
me to wish you all a Happy Thanksgiving. I think we all have a lot to be
thankful for - including the friendship and the opportunity to voice
different experiences. Now, my turkey is calling. It is a family time -
for us all.

oops - apologies! The above is a far better pursuit that this debate!
Bon apetit :wink:

- thomas

22

Speaking informally as someone who has used the products, and also experienced (to varying degrees) the development approaches of both openEHR and HL7 (as well as ISO and CEN), all I'd like to say is that they both have strengths and they both have weaknesses - in different areas, in terms of organisation / governance, technical approach, stakeholder involvement, and deployment. Neither general approach is perfect and I can't think of any international organisation working on shared or standard health informatics specifications and tools that can't be improved. There is lots to learn from one another (as well as others and I realise that much of the general discussion has reflected willingness to do this). Personally, however, I'm more interested in seeing (or at least talking about plans for) product progress than I am in debating which development community's process is 'right' or 'wrong' - I just can't see the point of trying to win that debate, even if a 'winner' could be declared.

Cheers,
Laura

23

Just an example of downstream modeling designs in HL7 to counterbalance Thomas erreonous comments on HL7 modeling.

  1. The path to get to implementable HL7 v3 XML is quite clear:
    we have the RIM as building blocks offering structure, attributes, and behaviour. Pure UML modeling.

  2. From the LEGO bricks using constraining, we create LEGO guidelines (similar to the booklets that help in a step by step picture to put the right bricks together). This is the Domain message inf. model.

Each of these D-MIM is taking into account a multitude of use cases identified and defined by clinicians, or from projects with clinicians.

  1. Following the guideline booklet, actual messages are built, the R-MIMs

  2. The object oriented models in R-MIM are serialised into XML.

OK, that is the basic pattern. I have used this to create the about 100 R-MIM examples covering a lot of clinical content on the level that in the 13606 world would be an entry. I am still of the opinion that the semantic content of this R-MIM is 100% the same as the same content in an archetype.

Well, I came to HL7 int with this and got 2 very important comments from experts in different committees:

  1. That is an excellent example of representing clinical content in HL7 v3 specification, it does follow the steps and rules 1-4 above. So the modeling did fit.
  2. If we continue to work this way and downstream have to make R-MIMs and serialize them we face the combinatorial explosion. If you have 3000 entry level or data element / data element clusters and 1000 assessment scales and want to vary that in the messages: well we face 3000 x 1000 x 5? variations. That is not sustainable.

Hence we abandonned to create fully specified R-MIMs for each clinical artifact and changed the route to what now is DCM. DCM allow still at conceptual level to express what clinicians want and need, but downstream only deliver XML output with structure and coding etc in such a format that it can be inserted in one and the same base message. Hence the combinatorial explosion is 1 for instance for the care record which holds the clinical statement pattern allowing such serialised DCM content to be included.

Hence, the downstream implementation in HL7 guided in this example the modeling approach.

William

24

In a message dated 25-11-2010 18:00:44 W. Europe Standard Time, thomas.beale@oceaninformatics.com writes:

I believe that the openEHR methodology provides a pretty good framework for a) safe data, b) interoperable data, c) data reuse, d) implementable software, and e) being domain driven (via archetypes). I just can’t use any HL7 models to do anything useful in the EHR space.

Hi Tom,

This can easily be read as:

I believe that the HL7 v3 methodology provides an excellent framework for
a) safe data,
b) interoperable data,
c) data reuse,
d) implementable software, and
e) being domain driven (via DCM).
f) safely exchange data based on different systems that have a complete different architecture
g) decision support
h) support of the dynamics in care, e.g. with the most powerfull attribute called mood code. The dynamics of care cannot be modeled in the static 13606 / OpenEHR RM, which is only a collection of snapshots
I just can’t use any archetype models to do anything useful in the HL7 space.

To Laura,

I agree, that winning is like a football game, one time you loose, the other you win, the next you loose, the next you win, loose, win, win, loose (oops :-)), with can go on and on.

Point is that I agree on the tools that help doing the job.

To all:

I have experience with some: HL7 tools in VISIO are sometimes a bit clumsy, but work, OpenEHR archetype editor is unreliable, I have in the creation of archetypes lost about a 40 days of work just due to crashing editor. Not a helpful tool.
So yes, please support the creation of a tool (set) that is reliable and not too clumsy and that helps me realize the DCM content, check it with clinicians and next use it in both HL7 v2, CDA, v3, RIMBAA and services space and in 13606 ADL 1.2 / ADL 1.4., ADL 1.5 and in ER diagramming, and in user interface specifications and in queries and in reportings.
Because I still believe that the Apgar score in HL7 v3 MUST be 100% identical to the Apgar score in archetype. If that is not the case, both methods fail to do what they are intented for.

Met vriendelijke groet,

Results 4 Care b.v.

dr. William TF Goossen
directeur

De Stinse 15
3823 VM Amersfoort
email: wgoossen@results4care.nl
telefoon +31 (0)654614458

fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713

25

I would have an interest in linking this subset to real world clinical and research use of data.

Met vriendelijke groet,

Results 4 Care b.v.

dr. William TF Goossen
directeur

De Stinse 15
3823 VM Amersfoort
email: wgoossen@results4care.nl
telefoon +31 (0)654614458

fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713

26

Because I still believe that the Apgar score in HL7 v3 MUST be 100% identical to the Apgar score in archetype. If that is not the case, both methods fail to do what they are intented for.

I have to disagree with that. The apgar DCM is only one, but the
different representations in each one of the standards don't have to
be the same. DCM should go far away the HL7 vs. openEHR issue. You
should be able to transform them to any model

27

Dear William,
I found your note of great interest. IMHO V3 definitely has a higher learning and implementation curve as compared to V2.x and I look forward to ideas that would simplify message creation in V3. I Would be interested in downloading details of DCM (detailed clinical models) to XML conversion (conversion tools, PPTs, PDFs, etc). Would be great if you could share some URLs.

Thanks in advance.

With warm regards,

Dr D Lavanian
MBBS,MD
CEO and MD
HCIT Consultant
www.hcitconsultant.com

Certified HL7 Specialist
Member- American Medical Informatics Association
Member HIMSS
Senior Consultant and Domain Expert - Healthcare Informatics and TeleHealth

Former Vice President - Healthcare Products, Bilcare Ltd
Former Vice President - Software Division, AxSys Healthtech Ltd
Former Co-convener Sub committee on Standards , Governmental Task force for Telemedicine
Former Vice President - Telemedicine (Technical), Apollo Hospitals Group
Former Deputy Director Medical Services, Indian Air Force
Office: +91 20 32345045
Mobile: +91-9970921266

28

William,

Not to continue on the main debate - but with respect to your statement:

"I am still of the opinion that the semantic content of this R-MIM is 100% the same as the same content in an archetype. "

It might be the case. But it is a problem like trying to express the same thoughts in Malay language and in Russian. In the former there are no tenses, and you have to add words indicating time, like ‘yesterday’ to do it. Russian is a richer language, so expressing sophisticated concepts in Russian a) takes less words and b) is likely to more closely express subtle concepts, tone of expression etc.

In our world, we have to be able to machine translate models to say they are the same, or reuse one expression in the other world. If we can’t do that, it is of only academic interest to say they are ‘the same’. And the difficulty of doing machine translation on natural languages shows us how hard this is. Even across European languages, Google translate and other such tools are quite weak.

Model translation as practised in IT does work somewhat in some circumstances - but is fairly unreliable (e.g. UML tool round-tripping). What enables or hinders such translation is the closeness or otherwise of the underlying grammatical structures; in our world, this is the reference models.

  • thomas
29

Thomas / Ed and all

I have been lurking on this thread - and am not sure that it is really constructive to contribute, but I will try.

Changing the world in this space is difficult - indeed any wide-scale change to complex systems is hard to achieve, especially if you have a very clear view as to what the “right” future state is.

Sharing and manipulating healthcare information happens in many evolving ways in different places and contexts - there is not going to be a single well engineered framework for this, any more than there is a single language uniformly engineered and tested for written and oral communication.
As for written communication there will be some widely supported “lingua franca” for some purposes. What makes a good spoken language is use and usefulness, not necessarily tight semantics or clean grammar. What makes good HIT data exchange languages and syntaxes is something that we are all learning about - as we are about the best economic and social way to develop, test, improve and promote the use of such languages.

I have always been somewhat surprised by the degree of similarity between openEHR and HL7v3, with their reference models, datatypes, and constrained, reusable models. Also with the fact that some people who try implementing them find them complex and brittle, and others find them useful. Also the fact that they seem to some to be controlled by a small cohort who do not seem to listen. I know that there is work going on on both organisations to understand and address these perceptions.
My personal focus in HL7 for the last four years has been on improving the visibility of the work being done and the processes being followed, to make it easier to engage in a cost effective way, and to reduce duplication of effort.
There is much more to be done in that regard, but I was still approached at the last HL7 WGM by a number of new and old attendees to be told that it was a remarkably good place to get work done. I know that this is a matter of perspective, and that there are folk who have found it frustrating and unproductive. I am sure that the HL7 TSC will continue to work on improving that.

I personally find HL7 a pragmatic place where skilled engineers and subject matter experts address the problems that they care about and develop the specifications that they need and I see similar behaviours on this openEHR list.

As for changing the world to make sharing healthcare information more effective, getting a good specification is important, but there are other factors. The supply chains and sets of collaborations that gets the right information to the patient and carer/clinician at the right time for effective management of health are very rich and varied - those of us that do think there is a valuable place for international consensus standards need to continue to work on identifying, measuring, improving and promoting that value. I am sure that the openEHR community will continue to do the same with the value of their work..

I look forwards to continuing to learn from both traditions as well as others, and do have a great deal of respect for the energy and insight that exists in the openEHR community, and am hopeful that constructive collaborations and cross-fertilisations will continue

all the best
Charlie

30

Hi Thomas,

I think you are missing the point here with the translation. Of course English Englisch, Scottish English, US English and Australian English differ.

What I talk about is exactly that the concepts and language and terms and symbols used e.g. in English English, need and can be addressed at clinical level, where clinicans contribute content for modeling.

However, I should not read a different message in English English language if I use an iPad, a Nokia phone, a printed newspaper, a pencil written note or a Windows PC, when the source material is the same intended concept and description. ( I ignore mark up influences here).

And that is exactly what is going wrong here: the technical representations create difficulties because they do not sufficiently address clinical precision.

In my experiences HL7 matches up to 98% of ability to represent clinical concepts and behavior and OpenEHR archetypes have several limits, making it maximum of 50% of representing clinical concept characteristics.

In particular in OpenEHR it is too hard to have relationships with coding systems, e.g. Snomed CT (HL7 code attribute and OID systems is almost perfect and widely implemented for this), I have seen no proper archetype allowing to do the same.
It is difficult to express relationships between data elements in archetypes, e.g. which data elements are organized in what structure with each other (such as the HL7 component relationship) and e.g. define the algorithm to create a sum score (such as the HL7 attribute of derivation method).
The option to model workflow or behaviour of concepts (e.g. the HL7 mood code for an observation) has no equivalent in OpenEHR archetypes.

These are all options of proper UML modeling and applied in HL7 v3, perhaps is this explaining why OpenEHR does not like UML, does it reveal the weaknesses of archetyping too much?

Vriendelijke groet,

William Goossen
directeur Results 4 Care

31

Good thoughts Charlie… just a final thought from me (not really needing any reply):

  • I still want to know if the inheritance of the HL7v3 HXIT messaging control class into every data type in 21090 is really what everyone needs/wants, in order to maximise interoperability and implementability…

  • thomas

(attachments)

OceanInformaticsl.JPG

32

In a message dated 25-11-2010 22:42:38 W. Europe Standard Time, yampeku@gmail.com writes:

Because I still believe that the Apgar score in HL7 v3 MUST be 100% identical to the Apgar score in archetype. If that is not the case, both methods fail to do what they are intented for.

I have to disagree with that. The apgar DCM is only one, but the
different representations in each one of the standards don’t have to
be the same. DCM should go far away the HL7 vs. openEHR issue. You
should be able to transform them to any model

That is exactly the point why they are created.

However, if the Apgar is different in an HL7 message from and OpenEHR EHR, then we are all in big problems creating a dangerous environment for patients.

Met vriendelijke groet,

Results 4 Care b.v.

dr. William TF Goossen
directeur

De Stinse 15
3823 VM Amersfoort
email: wgoossen@results4care.nl
telefoon +31 (0)654614458

fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713

33

The concept (DCM) is the same, but the implementation in different
standards will differ, as two different standards will never have the
same way of representing the same concept. As DCM should be even
broader than archetypes and templates, generating them from the DCM
should not be dangerous at all: all the information that can be stored
in a standard is included. If something vital is being left out then
it means that the standard can not represent all the domain
constraints and another standard should be chosen. Take epSOS as an
example: HL7 CDA can not define correctly the active ingredients of a
medication in the way decided by the clinicians. The proposed solution
was to modify CDA schema to include the structure needed, creating a
new epSOS-CDA standard incompatible with current normative CDA. Next
epSOS will be supposedly based on a newer CDA version that should
support those things. The dangers for the patient are not on the well
defined concepts but in the standards without the ability to represent
all critical constraints

34

In a message dated 27-11-2010 2:38:22 W. Europe Standard Time, yampeku@gmail.com writes:

The concept (DCM) is the same, but the implementation in different
standards will differ, as two different standards will never have the
same way of representing the same concept. As DCM should be even
broader than archetypes and templates, generating them from the DCM
should not be dangerous at all: all the information that can be stored
in a standard is included. If something vital is being left out then
it means that the standard can not represent all the domain
constraints and another standard should be chosen. Take epSOS as an
example: HL7 CDA can not define correctly the active ingredients of a
medication in the way decided by the clinicians. The proposed solution
was to modify CDA schema to include the structure needed, creating a
new epSOS-CDA standard incompatible with current normative CDA. Next
epSOS will be supposedly based on a newer CDA version that should
support those things. The dangers for the patient are not on the well
defined concepts but in the standards without the ability to represent
all critical constraints

I agree with your first premise, the representation might differ, but it is safe to use the DCM to generate both an archetype and an HL7 clinical statement.
I also agree with your second premise, that if a standard cannot accomodate the clinical concepts, the standard needs to be adjusted. That is the normal way HL7 messages and other artifacts are created, and maintained, based on use cases and clear business needs.

However, epSOS did not choose for the HL7 v3 message that would have been able to accurately represent medication components, i.e. the Care Record R-MIM. The Care Record R-MIM is draft standard for trial use since 2007 and would have been a better choice for representing that particular case.

However, back to 2nd premise, that also has limitations: 1] it is DSTU only (since 2007, so quite stable, but moving to normative will bring changes based on similar use cases as you describe here).
2] it can hold the medication and the breakdown in active ingredients is possible. However, the Care Record does not allow to actively prescribe medication. For that the pharmacy R-MIMs are required as a prerequisite.

Met vriendelijke groet,

Results 4 Care b.v.

dr. William TF Goossen
directeur

De Stinse 15
3823 VM Amersfoort
email: wgoossen@results4care.nl
telefoon +31 (0)654614458

fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713

35

Greetings,
I am interested in the details of some of the statements below. We’ve been working on generic methods of electronic healthcare standards implementation at CHIME. We have different teams focusing on different standards, and developing common tools and methods is an attractive goal for us. So your comments may provide us some interesting cases to work on. Please see comments/questions below

In my experiences HL7 matches up to 98% of ability to represent clinical concepts and behavior and OpenEHR archetypes have several limits, making it maximum of 50% of representing clinical concept characteristics.

Could you please provide an example where openEHR displays some or ideally more of the several limits you mention? I am interested in hearing about clinical concepts which are easily modelled in HL7 and hard to model in openEHR.

In particular in OpenEHR it is too hard to have relationships with coding systems, e.g. Snomed CT (HL7 code attribute and OID systems is almost perfect and widely implemented for this), I have seen no proper archetype allowing to do the same.

Could you please tell why do you find the term/terminology binding mechanics of archetypes too hard? Again, do you have an example of a clinical model which is easily bound to Snomed CT in HL7 and is problematic in openEHR?

It is difficult to express relationships between data elements in archetypes, e.g. which data elements are organized in what structure with each other (such as the HL7 component relationship) and e.g. define the algorithm to create a sum score (such as the HL7 attribute of derivation method).

I must be missing something here, but there are multiple views of Archetypes, from trees in GUI to even mindmaps, (to me) quite clearly displaying the structure. Again, could you provide me a link to an HL7 example which makes use of the relationship you find hard to express in openEHR?

The option to model workflow or behaviour of concepts (e.g. the HL7 mood code for an observation) has no equivalent in OpenEHR archetypes.

Again, do you have an example where INSTRUCTION, ACTION and ACTIVITY fail to deliver what you want to do? Could you kindly provide a clinical use case?

Your mail is interesting for me at a personal level too, since I’ve always seen people having different approaches to the problem, and discussion is mostly around the efficiency or elegance of achieving the goal. You clearly point towards cases where you have observed failure, and I’d really like to hear specifics of these.

Best Regards
Seref

36

Apologies for forgetting to address William Goossen in the mail below. It appears I’ve deleted a little bit too much from the original message.

Best Regards
S