# ISO 21090
**URL:** https://discourse.openehr.org/t/iso-21090/15037
**Category:** Technical (archive)
**Created:** [23 November 2010 13:24 UTC](https://discourse.openehr.org/t/iso-21090/15037 "2010-11-23T13:24:21Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@grahamegrieve](https://discourse.openehr.org/u/grahamegrieve)
#### Post date: [23 November 2010 13:24 UTC](https://discourse.openehr.org/t/iso-21090/15037/1 "2010-11-23T13:24:21Z")
Hi All
I have been having a long discussion with Tom off the
list about ISO 21090, and we've come to agreement
about the general picture.
When I teach ISO 21090 tutorials, and I get to the
implementation part, the first thing I say is that the
data types are completely denormalised, and that
I would never implement them as is inside my system
(as anything but an object model for exchange.)
And Tom says that they are all designed wrong
to be used as data types inside a system
We're both saying pretty much the same thing. The
21090 data types are designed, as Stef pointed out,
for \*exchange\*. Specifically, for exchange between
systems that are otherwise unconnected in any
effective way.
When you use the data types inside a system, then
they aren't so appropriate. Now we have to be careful
about using the term "inside a system" because even
within systems, we have multiple connection/exchange
points. So by "inside a system" I mean, for exchange
between different entities that are connected by a
common architecture that establishes, to a greater
or lesser degree, common infrastructure that is used
to normalise the content.
That normalisation might be
- the 5 normal forms of classical relational databases
- moving audit information away from the content to a
specialised audit/logging functionality
- moving constraint information out of the data into the
system metadata
- re-organising content that has been conflated by
semantic intent to more clearly draw apart
management concerns.
- moving concerns out of the data into the code
There's more, but that list will suffice for now. (so it should be
clear that I am using "normalise" in a somewhat loose
sense).
Tom sees these gaps, and responds negatively, whereas
I just accept them, knowing that they exist, and that I have
plans to deal with them, plans that vary across my different
systems as their architectures change.
But we do both share the concern that the degree to which
the 21090 data types are designed and optimised for
exchange is not understood by casual adopters. It's not that
it's impossible to adapt non-normalised models built for
exchange to serve as system architectures (there's an
active group in HL7 - RIMBAA - doing just that), but that
you need to know that what you are doing is going to
present certain challenges you will need to prepare for.
Users could easily start to implement them in systems and
find themselves later with a series of bad choices that they
could have avoided earlier, and then they'd blame 21090..
It appears that Tom and I may jointly develop a variant
of ISO 21090, that features the same basic semantic
content, but in a format that is suitable for use in systems
rather than for exchange. It will describe clearly how to
interoperate using 21090, but will be suited for system/case
design.
I am a little uncertain, because I am concerned that the
particular normalisations you anticipate will affect the way
that you design such a variant, and I don't see how to
pick a particular set - a logical obvious candidate around
which an implementation community would coalesce. Tom
and I are still talking about that.
Tom and I hope that this explanation will bring some clarity
to any observers who have been left confused by our somewhat
passionate debate to this point đ
Grahame
---
### Author:  [@Heath\_Frankel3](https://discourse.openehr.org/u/Heath_Frankel3)
#### Post date: [23 November 2010 22:24 UTC](https://discourse.openehr.org/t/iso-21090/15037/2 "2010-11-23T22:24:28Z")
I too are concerned, as you know Isolated 21090 is being balloted now, how
should we recommend our member countries vote given this new viewpoint?
Should we at least be requesting a name change?
What form would the new spec take, another standard or a profile?
Heath
---
### Author:  [@grahamegrieve](https://discourse.openehr.org/u/grahamegrieve)
#### Post date: [23 November 2010 22:40 UTC](https://discourse.openehr.org/t/iso-21090/15037/3 "2010-11-23T22:40:06Z")
hi Heath
> I too are concerned, as you know Isolated 21090 is being balloted now, how
> should we recommend our member countries vote given this new viewpoint?
> Should we at least be requesting a name change?
I don't think it needs a name change. The full name is:
Health Informatics â Harmonizied datatypes for information interchange
(nor do I think you can change the name in FDIS)
And the scope covers it too, I think. We had a discussion in the ISO
committee over this same ground (though probably not expressed quite
so clearly as I did below), which lead to Dipak drafting the words that
I used for this purpose.
And I think the problem is that people don't understand the underlying issues.
Fiddling with the name or scope further isn't going to solve that.
> What form would the new spec take, another standard or a profile?
I don't know what it is yet, nor where it could/should be done, nor
what it's final form would be. I'd rather let the technical side mature
before thinking about that. Let's see what we come up with
What I'd really like discussed is whether Tom and I should try and
target a particular system architecture, or whether we should try and
target a range. (and I'm still concerned by the question that if the
particular system architecture is openEHR, why not just use the
openEHR data types, and publish a mapping? It's not what we're talking
about, but we would need to be clear - why is what we propose better?)
Grahame
---
### Author:  [@Stef\_Verlinden1](https://discourse.openehr.org/u/Stef_Verlinden1)
#### Post date: [24 November 2010 23:02 UTC](https://discourse.openehr.org/t/iso-21090/15037/4 "2010-11-24T23:02:17Z")
Dear Grahame,
---
### Author:  [@grahamegrieve](https://discourse.openehr.org/u/grahamegrieve)
#### Post date: [25 November 2010 00:43 UTC](https://discourse.openehr.org/t/iso-21090/15037/5 "2010-11-25T00:43:50Z")
> This is really great news.
I'm glad you think so. Cause the more I think about it, the
more pessimistic I get.
> important technical agreed standards should still become
> formal standards because, at least here in Europe, they
> can be incorporated in laws.
y. but is that what we have here? How can we have more than
a systems implementation guide for ISO 21090?
I'll illustrate by talking about our favourite bugbear, CD
For me, CD conflates 3 different notions in it's properties
(and that's ignoring the things it gets from ANY and HXIT):
\* a definitional concept
\* a context of use of the concept
\* descriptional stuff to help foreigners work with the thing
when they don't know the definitional concept
In my systems, I split the first 2 up and struggle with the last.
I'll explain.
The definitional concept itself is code + codeSystem. This
pairing provides the actual meaning. So the first thing I do
is normalise this out of CD into a separate table (note, then,
that my focus here is relational databases, and working with
them). I keep a table of every discrete concept encountered
in the system. And I also maintain tables that keep track of
implies relationships between these concepts. This means
that I can write fast SQL joins that can use subsumption.
Again, note the implementation focus I have here. And actually,
I maintain a separate table for code systems to help with
system maintenance, so I break code+code system up too,
and there's a slew of infrastructural things hanging off them.
My CD datatype therefore devolves into originalText + primary
key for the concept. I ignore the valueset set stuff at the moment,
on the basis that it's not in my product's requirements space.
The descriptional stuff, I populate from my infrastructure -
codeSystemVersion and CodeSystemName. DisplayName, that's
a problem. Because in theory I can (and should) generate that
it. (well, I don't actually maintain a table for snomed - I have
a cache structure instead). But there's no algorithmic way to
turn a snomed expression into a display name. For me, this is
ok right now, we're not in the snomed expressions space.
Yet. But soon. I'm kind of hoping that the nascent work in that
space will start offering something solid about when I need it.
And what are translations? I don't think they are any of those
other things. I keep track of them as a series of postulates
that the underlying concepts may be related. (and who
postulated it, cause I'm never sure who's going to believe who)
So CD is a cascade of tables for me. Cecil Lynch from Ontoreason
does a different cascade, reflecting his different tooling, architecture,
and requirements.
OpenEHR doesn't split that stuff out - just compresses what it has
into a single de-normalised type. I'd never do that. But Gunther, on
the other hand, would never normalise it - he just uses the fully
denormalised RIM + data types and wouldn't bother understanding
why we'd have this discussion at all.
(I do use the fully denormalised type in my object models at my
exchange points (CDA, HL7 v2, etc), where it makes prefect
sense, btw)
Anyway, the problem I have is that my tooling, architecture and
requirements all change the way that I \*implement\* the notional
ISO 21090 types inside my system. Out of that, we are supposed
to be able to write a single specification which is the one correct
model for implementing these types in a system?
So I don't feel as though we can produce a standard, just an
implementation guide.
Grahame
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [25 November 2010 08:33 UTC](https://discourse.openehr.org/t/iso-21090/15037/6 "2010-11-25T08:33:26Z")
It seems reasonable for the two of us to at least come up with something that other people might look at. If we start with 20 people, nothing can happen - it is like starting with a standards meeting. And software engineering shows that teams of more than 5 donât work. I like the WWTA concept - I wonder how to make that into an alternative to committee-based standards?! I also agree that standards need to be formalised - I have never been against it, only _bad_ standards being formalised.
- thomas
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [25 November 2010 09:18 UTC](https://discourse.openehr.org/t/iso-21090/15037/7 "2010-11-25T09:18:11Z")
We donât use relational databases in the orthodox way as Grahame does, but his explanation really shows that CD (and most other 21090 DTs) are conflations of multiple concepts. The âcoreâ that I want to dig out is essentially the semantics we put into openEHR. The modelling methodology is as follows:
- you have a **core data type** definition, e.g. CD, or DV\_CODED\_TEXT or whatever, that provides a computational model of the data type concept, in this case âcoded textâ, in its simplest form that supports expressing an instance of that type. The essential in this case is the code + code system, and in openEHR, we include the code term, i.e. the text for that code in the language of the locale in which the data were created (this allows the data to be human-readable even when a terminology service is not available). So far, no context- or environment-related inclusions in the model.
- further **contextless semantics** could be included, especially if they are very common, e.g. in openEHR we have âmappingsâ on DV\_TEXT, inherited into DV\_CODED\_TEXT. This defines a standard data structure for connecting 1 or more mapped terms, e.g. ICD codes, LOINC codes or whatever to the original text or coded text.
- another very common addition in openEHR is that of reference ranges to the Quantity types; these support the representation of lab data. It could be argued that this addition is context-related, and should be dealt with in the next category below.
- then, any **real world (i.e. clinical) context-related** items, such as the following list should only be added to the model in âclientâ classes, i.e. wrapper classesâŚ
- **nullflavour** : this only relates to situations in which the data were captured from the outside world in some way. But a lot of values are not captured at all, they may have been extracted from a terminology service, generated by a decision support algorithm, or used in some related application that has no interest in any data whose null flavour was non-Void
- **clinical statement structure** : what we call an Entry in openEHR and CEN, and also in CDA, is a larger structure within which multiple atomic data points might occur. Within this structure in openEHR and CEN, you have ELEMENTs holding the data values, then CLUSTERs, EVENT, HISTORY, ACTIVITY, INSTRUCTION, etc etc. Each of these may add some contextual items germane to its semantics, e.g. HISTORY & EVENT contain observation timing info, ENTRY has protocol and other\_participants, as well as subject (who is the data about) and information\_provider (who wrote it).
- **health event context** : at higher levels, data relating to the visit, or lab test etc, such as date, time, location, and participants are typically attached to the top level structure, e.g. COMPOSITION, or Document in CDA.- now any **system-related context** is added, also in outer classes:
- version control information
- message control information (HL7 HXIT stuff)
- anything specific to storage or GUI rendering.
If this kind of approach, based on **additive inheritance and encapsulation** , is not followed, we end up with leaf level data type definitions that are a soup of items from these other contexts and levels. This prevents us writing a clear model of what a CD or a Quantity actually is, and then deploying it in all the different contexts where it may be used. It also **prevents anyone knowing** , when such data are passed around **which items represent the data value** , and which are context-related items from some other context, now of no interest to the present computing context (e.g. HXIT attributes turning up inside the EHR). It is not always possible to follow modelling principles 100% and sometimes compromises seem to make sense. For example, the Quantity reference range one noted above. However, if the model does not by and large follow good practices, it wonât do what is needed.
This is the problem of ISO 21090, and as well, the HL7 RIM, and is why in their current form they are so hard to use, and why they in fact worsen interoperability: each implementer is forced to **subtract** some subset of items from the basic classes to suit their purposes, and each implementer does this differently, resulting in a custom variant of the model (in HL7v3 this is called an RMIM). Not only that, but no-one can write a definitive set of classes in the common programming languages that can be widely used, because each of these implementation sites has a different variant of the same classes in the model.
Let me make one thing clear: the above is not a matter of taste or subjectivity. If we agree that we are in fact using object modelling to express these standards, then we need to stick to good object-oriented methodology. Not doing so has bad downstream consequences.
Now, doing 21090 properly means doing the above. It is probably too late to do that. So the official standard will be like the HL7v3 messages - capturing a huge amount of useful learning and semantics yet modelled in just such a way as to prevent reusability or interoperability.
However, this is not the situation we are in. I donât know if the relevant ISO people (including relevant national representatives) can be alerted and made to understand in time that what they are doing is going to have more or less the opposite effect to what they think. If it is possible we should do it. If not, as Grahame says, a few of us could try to create a 21090-stripped-down. Assuming a technical agreement could be reached, then we still have the problem as Stef mentioned, of making it official.
I donât know how to solve this situation. Hence my near total loss of faith in the international standards process, in e-health for some years now.
- thomas
> **(attachments)**
>
> 
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [25 November 2010 10:02 UTC](https://discourse.openehr.org/t/iso-21090/15037/8 "2010-11-25T10:02:06Z")
Some of the things I mentioned in the last post on good modelling
practice, and the problems in HL7 due to not using them are mentioned
here in by Bill Hogan MD, who is Director of Medical Vocabulary/Ontology
Services, Pittsburgh Medical Centre. See
[http://hl7-watch.blogspot.com/2010/11/demographics-hl7-vs-reality-part-1.html](http://hl7-watch.blogspot.com/2010/11/demographics-hl7-vs-reality-part-1.html)
- thomas beale
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [25 November 2010 10:35 UTC](https://discourse.openehr.org/t/iso-21090/15037/9 "2010-11-25T10:35:44Z")
Hi Thomas,
I am not sure that the particular difficulties highlighted in this
piece are really the sole province of HL7. As I read the original
discussions and Barry Smith's analysis, there are 2 separate issues
1) The overall difficulties of harmonising value sets for particular
use cases (HITSP in this example). Whilst I think we can argue that
the archetype and maximal dataset approach make this task much easier,
nevertheless the organisational and legacy representation issues
mentioned are identical for our modelling work.
2) Barry Smith takes issue with the ontological definition of 'marital
status'. Whilst his logic may be impeccable, I think this is an
unfortunate example to pick apart. I am not sure if his preferred
higher-level marital status 'married/not married' is of any real
practical clinical or administrative value. Does he mean legally
married or effectively married or religiously married? By whose rules?
I think this is taking ontological purity into an unsustainable and
fruitless level of detail.
Ian
Dr Ian McNicoll
office / fax +44(0)1536 414994
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical analyst, Ocean Informatics
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care SG Group www.phcsg.org
---
### Author:  [@William\_E\_Hammond](https://discourse.openehr.org/u/William_E_Hammond)
#### Post date: [25 November 2010 14:22 UTC](https://discourse.openehr.org/t/iso-21090/15037/10 "2010-11-25T14:22:30Z")
I have to admit that I am tired of the HL7 bashing, most specifically by
Thomas. In my opinion, it serves no purpose. I would hope Thomas would
spend his energy in a positive direction, not by bashing HL&. Further,
quoting a blog from someone who has problems with HL7 does not make his
case nor help the situation. Regardless of what Thomas says, HL7 is used
by thousands of people. About 90% of the hospitals in the US use v2.
Further, the UK, Canada and Australia use v2. One reason that v3 is not
adopted in the US is the success of v2.
I think archetypes and/or DCM are important. Rather than working toward a
common pathway to mutually promote both HL& and openEHR, we have spent a
lot of energy of the negatives of HL7. n
If I became the one source of standards, I think I could make the perfect
standard. Of course, no one else would think so. As openEHR expands it
use, it will get (and has gotten) pusgback from persons who think it does
do what they want it to do. Then openEHR can say tough luck or they can
change to accommodate. Now you are in the world of HL7.
What I have argued for a long time is that we, all of use in the standards
arena, are an invisible minority. When it is convenient and in the best
interest of governments or large companies, they will make their own
standards. I would like to see us follow some of the good advice in this
discussion and move forward - quickly and competently.
So I'd love to see an e-mail that simply does not serve to bash HL7. We
need to undersatnd the differences and why, but we also need to understand
what we have in common.
I believe that Graham Grieve is the most organizally unbiased person I
know. He is biased by what he thinks is correct. I think he make an
honest attempt to deal with some of the issues relating to data elements
and reach a compromise between openEHr and HL7 data elements.
Unfortunately, it seems that even this approach has not led to success.
I have kept the e-mail thread, and would like to make some sense of it.
That trail also is important because it exposes the various philosophies
and differences. I may ask for permission from the participants of the
discussion to share their comments with a broader audience. The purpose of
the article would be to understand where we are and wht we differ and
perhaps enable a solution.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
\ For openEHR technical discussions
Sent by: \
openehr-technical cc
-bounces@openehr.
org Subject
HL7 modelling approach
11/25/2010 05:07
AM
Please respond to
For openEHR
technical
discussions
\
Some of the things I mentioned in the last post on good modelling
practice, and the problems in HL7 due to not using them are mentioned
here in by Bill Hogan MD, who is Director of Medical Vocabulary/Ontology
Services, Pittsburgh Medical Centre. See
[http://hl7-watch.blogspot.com/2010/11/demographics-hl7-vs-reality-part-1.html](http://hl7-watch.blogspot.com/2010/11/demographics-hl7-vs-reality-part-1.html)
- thomas beale
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [25 November 2010 15:58 UTC](https://discourse.openehr.org/t/iso-21090/15037/11 "2010-11-25T15:58:49Z")
Ian,
I agree with your comments. The thing I noted that is to do with the previous discussion on HL7âs âsubtractive modellingâ approach:
> With respect to how the RIM represents marital status, first we note that HL7 places most demographic information as âattributesâ (in HL7 lingo) of two classes: LivingSubject and Person. Note that the latter specializes the former.
>
> LivingSubject âattributesâ
> administrativeGenderCode
> birthTime
> deceasedInd
> deceasedTime
> Person âattributesâ
> raceCode
> ethnicGroupCode
> maritalStatusCode
>
> So, marital status is an âattributeâ of the Person class. Note that the Person class, per the RIM, may be used to represent a group of people as well as a single person. What the marital status of a group of people might represent is not clear.
Specifically the last sentence above: the Person class is wrongly named (presumably it should be âSubjectâ), and it contains 3 attributes that donât apply to some/many of its instances (none apply in general to family as a subject for example, and maritalStatus does not usefully apply to children or infants and would never be recorded for them). It is a case of too much stuff being put in, trying to cope with all possible forseeable use cases. The latter can never be achieved, so by definition this approach to modelling wonât work in the long run.
- thomas
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [25 November 2010 16:12 UTC](https://discourse.openehr.org/t/iso-21090/15037/12 "2010-11-25T16:12:31Z")
Ed,
I am not engaging in HL7-bashing. I am critiquing specific aspects of HL7v3 that donât work well and cause widespread problems. Anyone should presumably be allowed to do that, otherwise how do we make progress? I would argue that critiques of this sort do help - we received lots of objections about openEHR from all kinds of places over the years and it helps.
The negatives of HL7v3 need to be exposed and explained, because they are getting in the way of interoperability and progress. HL7v2 is used extremely widely. HL7v3 is not, and there are reasons for that. I am trying to explain them, because ISO 21090 suffers from the same problems, and is about to create the same problems as the RIM: a very complex standard that is hard to use, has to be âprofiledâ for use, and will be profiled in numerous different ways, largely preventing the interoperability (and in many cases, even implementability) it should have enabled.
I think this is important. It is not about any perfect standard; any standard that at least followed basic modelling good practice is worth contemplating and working together on. But standards that donât follow basic, accepted modelling principles will just cause problems. There can be no common pathway when one of the modelling approaches is this subtractive modelling approach of HL7, it is only possible when all the candidates are at least doing proper modelling. Then we can talk about which one to agree on.
My only interests are in doing the engineering we need to do in this sector. If I sound biased, it is because I do not see HL7 helping, and worse, it is not listening, not even about basic modelling practices. So the sector continues to suffer and make limited progress. I wish HL7 would adopt recognised modelling practices, because then we could make very fast progress.
- thomas
> **(attachments)**
>
> 
---
### Author:  [@William\_E\_Hammond](https://discourse.openehr.org/u/William_E_Hammond)
#### Post date: [25 November 2010 16:26 UTC](https://discourse.openehr.org/t/iso-21090/15037/13 "2010-11-25T16:26:29Z")
OK. I accept the comment. However, the problem I have is that many of the
comments are a matter of opinion - that's ok, but it is not a right or
wrong. If the issues were balloted, by shere numbers HL7 would come out
ahead. The comment of attributes in quotes and the comment incorrectly
named does not make your point.
If you want HL7 to respond to your critiques, sedn them to the TSC or HL7
leadership.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
\ openehr-technical@openehr.org
Sent by: cc
openehr-technical
-bounces@openehr. Subject
org Re: HL7 modelling approach
11/25/2010 11:13
AM
Please respond to
For openEHR
technical
discussions
\
Ed,
I am not engaging in HL7-bashing. I am critiquing specific aspects of HL7v3
that don't work well and cause widespread problems. Anyone should
presumably be allowed to do that, otherwise how do we make progress? I
would argue that critiques of this sort do help - we received lots of
objections about openEHR from all kinds of places over the years and it
helps.
The negatives of HL7v3 need to be exposed and explained, because they are
getting in the way of interoperability and progress. HL7v2 is used
extremely widely. HL7v3 is not, and there are reasons for that. I am trying
to explain them, because ISO 21090 suffers from the same problems, and is
about to create the same problems as the RIM: a very complex standard that
is hard to use, has to be 'profiled' for use, and will be profiled in
numerous different ways, largely preventing the interoperability (and in
many cases, even implementability) it should have enabled.
I think this is important. It is not about any perfect standard; any
standard that at least followed basic modelling good practice is worth
contemplating and working together on. But standards that don't follow
basic, accepted modelling principles will just cause problems. There can be
no common pathway when one of the modelling approaches is this subtractive
modelling approach of HL7, it is only possible when all the candidates are
at least doing proper modelling. Then we can talk about which one to agree
on.
My only interests are in doing the engineering we need to do in this
sector. If I sound biased, it is because I do not see HL7 helping, and
worse, it is not listening, not even about basic modelling practices. So
the sector continues to suffer and make limited progress. I wish HL7 would
adopt recognised modelling practices, because then we could make very fast
progress.
- thomas
I have to admit that I am tired of the HL7 bashing, most specifically
by
Thomas. In my opinion, it serves no purpose. I would hope Thomas
would
spend his energy in a positive direction, not by bashing HL&.
Further,
quoting a blog from someone who has problems with HL7 does not make
his
case nor help the situation. Regardless of what Thomas says, HL7 is
used
by thousands of people. About 90% of the hospitals in the US use v2.
Further, the UK, Canada and Australia use v2. One reason that v3 is
not
adopted in the US is the success of v2.
I think archetypes and/or DCM are important. Rather than working
toward a
common pathway to mutually promote both HL& and openEHR, we have
spent a
lot of energy of the negatives of HL7. n
If I became the one source of standards, I think I could make the
perfect
standard. Of course, no one else would think so. As openEHR expands
it
use, it will get (and has gotten) pusgback from persons who think it
does
do what they want it to do. Then openEHR can say tough luck or they
can
change to accommodate. Now you are in the world of HL7.
What I have argued for a long time is that we, all of use in the
standards
arena, are an invisible minority. When it is convenient and in the
best
interest of governments or large companies, they will make their own
standards. I would like to see us follow some of the good advice in
this
discussion and move forward - quickly and competently.
So I'd love to see an e-mail that simply does not serve to bash HL7.
We
need to undersatnd the differences and why, but we also need to
understand
what we have in common.
I believe that Graham Grieve is the most organizally unbiased person
I
know. He is biased by what he thinks is correct. I think he make an
honest attempt to deal with some of the issues relating to data
elements
and reach a compromise between openEHr and HL7 data elements.
Unfortunately, it seems that even this approach has not led to
success.
I have kept the e-mail thread, and would like to make some sense of
it.
That trail also is important because it exposes the various
philosophies
and differences. I may ask for permission from the participants of
the
discussion to share their comments with a broader audience. The
purpose of
the article would be to understand where we are and wht we differ and
perhaps enable a solution.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
\ For openEHR technical
discussions
Sent by:
\
openehr-technical
cc
-bounces@openehr.
org
Subject
HL7 modelling approach
11/25/2010 05:07
AM
Please respond to
For openEHR
technical
discussions
\
Some of the things I mentioned in the last post on good modelling
practice, and the problems in HL7 due to not using them are mentioned
here in by Bill Hogan MD, who is Director of Medical
Vocabulary/Ontology
Services, Pittsburgh Medical Centre. See
[http://hl7-watch.blogspot.com/2010/11/demographics-hl7-vs-reality-part-1.html](http://hl7-watch.blogspot.com/2010/11/demographics-hl7-vs-reality-part-1.html)
- thomas beale
> **(attachments)**
>
> 
---
### Author:  [@William\_E\_Hammond](https://discourse.openehr.org/u/William_E_Hammond)
#### Post date: [25 November 2010 16:31 UTC](https://discourse.openehr.org/t/iso-21090/15037/14 "2010-11-25T16:31:33Z")
HL7 is following basic modeling procedures in the minds of a lot of people.
HL7 and CDISC, for example, have worked together to produce BRIDG. A large
number of international technologists have and are contributing to HL7. I
agree that RIM has problems. RIM evolved early on from data models.
Decisions were made by a number of people who at that time believed that
was the approach. Stan Huff is leading a TF to look at some of these
issues (Graham is part of that TF). WHat changes will be made? I don't
know. The problem is further complicated in that the current model has
been used in a lot of applications. Thise applications work, even though
many of us believe there is a better way. Those changes have to be made
against an implemented set. I do urge you to submit your criticisms to the
HL7 Technical Steering Committee and to John Quinn, the HL7 CTO. Or to
Stan HUff.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
\ openehr-technical@openehr.org
Sent by: cc
openehr-technical
-bounces@openehr. Subject
org Re: HL7 modelling approach
11/25/2010 11:13
AM
Please respond to
For openEHR
technical
discussions
\
Ed,
I am not engaging in HL7-bashing. I am critiquing specific aspects of HL7v3
that don't work well and cause widespread problems. Anyone should
presumably be allowed to do that, otherwise how do we make progress? I
would argue that critiques of this sort do help - we received lots of
objections about openEHR from all kinds of places over the years and it
helps.
The negatives of HL7v3 need to be exposed and explained, because they are
getting in the way of interoperability and progress. HL7v2 is used
extremely widely. HL7v3 is not, and there are reasons for that. I am trying
to explain them, because ISO 21090 suffers from the same problems, and is
about to create the same problems as the RIM: a very complex standard that
is hard to use, has to be 'profiled' for use, and will be profiled in
numerous different ways, largely preventing the interoperability (and in
many cases, even implementability) it should have enabled.
I think this is important. It is not about any perfect standard; any
standard that at least followed basic modelling good practice is worth
contemplating and working together on. But standards that don't follow
basic, accepted modelling principles will just cause problems. There can be
no common pathway when one of the modelling approaches is this subtractive
modelling approach of HL7, it is only possible when all the candidates are
at least doing proper modelling. Then we can talk about which one to agree
on.
My only interests are in doing the engineering we need to do in this
sector. If I sound biased, it is because I do not see HL7 helping, and
worse, it is not listening, not even about basic modelling practices. So
the sector continues to suffer and make limited progress. I wish HL7 would
adopt recognised modelling practices, because then we could make very fast
progress.
- thomas
I have to admit that I am tired of the HL7 bashing, most specifically
by
Thomas. In my opinion, it serves no purpose. I would hope Thomas
would
spend his energy in a positive direction, not by bashing HL&.
Further,
quoting a blog from someone who has problems with HL7 does not make
his
case nor help the situation. Regardless of what Thomas says, HL7 is
used
by thousands of people. About 90% of the hospitals in the US use v2.
Further, the UK, Canada and Australia use v2. One reason that v3 is
not
adopted in the US is the success of v2.
I think archetypes and/or DCM are important. Rather than working
toward a
common pathway to mutually promote both HL& and openEHR, we have
spent a
lot of energy of the negatives of HL7. n
If I became the one source of standards, I think I could make the
perfect
standard. Of course, no one else would think so. As openEHR expands
it
use, it will get (and has gotten) pusgback from persons who think it
does
do what they want it to do. Then openEHR can say tough luck or they
can
change to accommodate. Now you are in the world of HL7.
What I have argued for a long time is that we, all of use in the
standards
arena, are an invisible minority. When it is convenient and in the
best
interest of governments or large companies, they will make their own
standards. I would like to see us follow some of the good advice in
this
discussion and move forward - quickly and competently.
So I'd love to see an e-mail that simply does not serve to bash HL7.
We
need to undersatnd the differences and why, but we also need to
understand
what we have in common.
I believe that Graham Grieve is the most organizally unbiased person
I
know. He is biased by what he thinks is correct. I think he make an
honest attempt to deal with some of the issues relating to data
elements
and reach a compromise between openEHr and HL7 data elements.
Unfortunately, it seems that even this approach has not led to
success.
I have kept the e-mail thread, and would like to make some sense of
it.
That trail also is important because it exposes the various
philosophies
and differences. I may ask for permission from the participants of
the
discussion to share their comments with a broader audience. The
purpose of
the article would be to understand where we are and wht we differ and
perhaps enable a solution.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
\ For openEHR technical
discussions
Sent by:
\
openehr-technical
cc
-bounces@openehr.
org
Subject
HL7 modelling approach
11/25/2010 05:07
AM
Please respond to
For openEHR
technical
discussions
\
Some of the things I mentioned in the last post on good modelling
practice, and the problems in HL7 due to not using them are mentioned
here in by Bill Hogan MD, who is Director of Medical
Vocabulary/Ontology
Services, Pittsburgh Medical Centre. See
[http://hl7-watch.blogspot.com/2010/11/demographics-hl7-vs-reality-part-1.html](http://hl7-watch.blogspot.com/2010/11/demographics-hl7-vs-reality-part-1.html)
- thomas beale
> **(attachments)**
>
> 
---
### Author:  [@William\_E\_Hammond](https://discourse.openehr.org/u/William_E_Hammond)
#### Post date: [25 November 2010 16:33 UTC](https://discourse.openehr.org/t/iso-21090/15037/15 "2010-11-25T16:33:06Z")
Since I have argued that HL7 is using recognized modeling proactices -
perhaps that may be the start. Critical is what are the recognized
modeling practices and recognized by whom. Why do you think HL7 has not
listened?
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
\ openehr-technical@openehr.org
Sent by: cc
openehr-technical
-bounces@openehr. Subject
org Re: HL7 modelling approach
11/25/2010 11:13
AM
Please respond to
For openEHR
technical
discussions
\
Ed,
I am not engaging in HL7-bashing. I am critiquing specific aspects of HL7v3
that don't work well and cause widespread problems. Anyone should
presumably be allowed to do that, otherwise how do we make progress? I
would argue that critiques of this sort do help - we received lots of
objections about openEHR from all kinds of places over the years and it
helps.
The negatives of HL7v3 need to be exposed and explained, because they are
getting in the way of interoperability and progress. HL7v2 is used
extremely widely. HL7v3 is not, and there are reasons for that. I am trying
to explain them, because ISO 21090 suffers from the same problems, and is
about to create the same problems as the RIM: a very complex standard that
is hard to use, has to be 'profiled' for use, and will be profiled in
numerous different ways, largely preventing the interoperability (and in
many cases, even implementability) it should have enabled.
I think this is important. It is not about any perfect standard; any
standard that at least followed basic modelling good practice is worth
contemplating and working together on. But standards that don't follow
basic, accepted modelling principles will just cause problems. There can be
no common pathway when one of the modelling approaches is this subtractive
modelling approach of HL7, it is only possible when all the candidates are
at least doing proper modelling. Then we can talk about which one to agree
on.
My only interests are in doing the engineering we need to do in this
sector. If I sound biased, it is because I do not see HL7 helping, and
worse, it is not listening, not even about basic modelling practices. So
the sector continues to suffer and make limited progress. I wish HL7 would
adopt recognised modelling practices, because then we could make very fast
progress.
- thomas
I have to admit that I am tired of the HL7 bashing, most specifically
by
Thomas. In my opinion, it serves no purpose. I would hope Thomas
would
spend his energy in a positive direction, not by bashing HL&.
Further,
quoting a blog from someone who has problems with HL7 does not make
his
case nor help the situation. Regardless of what Thomas says, HL7 is
used
by thousands of people. About 90% of the hospitals in the US use v2.
Further, the UK, Canada and Australia use v2. One reason that v3 is
not
adopted in the US is the success of v2.
I think archetypes and/or DCM are important. Rather than working
toward a
common pathway to mutually promote both HL& and openEHR, we have
spent a
lot of energy of the negatives of HL7. n
If I became the one source of standards, I think I could make the
perfect
standard. Of course, no one else would think so. As openEHR expands
it
use, it will get (and has gotten) pusgback from persons who think it
does
do what they want it to do. Then openEHR can say tough luck or they
can
change to accommodate. Now you are in the world of HL7.
What I have argued for a long time is that we, all of use in the
standards
arena, are an invisible minority. When it is convenient and in the
best
interest of governments or large companies, they will make their own
standards. I would like to see us follow some of the good advice in
this
discussion and move forward - quickly and competently.
So I'd love to see an e-mail that simply does not serve to bash HL7.
We
need to undersatnd the differences and why, but we also need to
understand
what we have in common.
I believe that Graham Grieve is the most organizally unbiased person
I
know. He is biased by what he thinks is correct. I think he make an
honest attempt to deal with some of the issues relating to data
elements
and reach a compromise between openEHr and HL7 data elements.
Unfortunately, it seems that even this approach has not led to
success.
I have kept the e-mail thread, and would like to make some sense of
it.
That trail also is important because it exposes the various
philosophies
and differences. I may ask for permission from the participants of
the
discussion to share their comments with a broader audience. The
purpose of
the article would be to understand where we are and wht we differ and
perhaps enable a solution.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
\ For openEHR technical
discussions
Sent by:
\
openehr-technical
cc
-bounces@openehr.
org
Subject
HL7 modelling approach
11/25/2010 05:07
AM
Please respond to
For openEHR
technical
discussions
\
Some of the things I mentioned in the last post on good modelling
practice, and the problems in HL7 due to not using them are mentioned
here in by Bill Hogan MD, who is Director of Medical
Vocabulary/Ontology
Services, Pittsburgh Medical Centre. See
[http://hl7-watch.blogspot.com/2010/11/demographics-hl7-vs-reality-part-1.html](http://hl7-watch.blogspot.com/2010/11/demographics-hl7-vs-reality-part-1.html)
- thomas beale
> **(attachments)**
>
> 
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [25 November 2010 16:39 UTC](https://discourse.openehr.org/t/iso-21090/15037/16 "2010-11-25T16:39:03Z")
Ed,
thatâs the whole problem with these standards committees: they are full of people whose competence is not modelling or engineering, and who donât see the downstream consequences of their choices, and in any case, the âdemocraticâ committee process largely prevents proper design occurring. People just object to whatever, country X demands that a certain attribute be renamed⌠it just comes down to who came on the day and who shouts loudest.
I came to HL7 meetings for 5 or 6 years, and followed all the required process (well, except the shouting down in meetings, sorry I am not into that), and it had no effect. I know many many people who have said the same thing, including people in key positions in e-health programmes around the world.
- thomas
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [25 November 2010 16:59 UTC](https://discourse.openehr.org/t/iso-21090/15037/17 "2010-11-25T16:59:52Z")
I have not seen much evidence of widespread uptake of HL7v3, indeed Stan and others have said in various places that it has been significantly lower than expected. CDA is the one thing that is getting use. The few large implementations have spent a MOUNTAIN of money to do what they did, and I know for a fact that the outcomes are not seen as good value.
See here for what appears to be a reasonable outline of the status quo - [http://www.hl7standards.com/blog/2007/10/10/preparing-for-hl7-v3/](http://www.hl7standards.com/blog/2007/10/10/preparing-for-hl7-v3/)
I donât believe changing the RIM, 21090 and other models (apart from CDA) would have that much negative impact on the industry as a whole, but if the changes were radical enough, they could help a lot.
I currently donât have time to submit endless feedback to HL7 processes, especially when I know they will not be listened to. I canât imagine that HL7 is going fix its basic modelling methodology, which is what it needs to do. I have actually provided very detailed critiques in the past, and nothing has happened (other than blocking). Today I just have to be concerned with things that are going to be economically implementable by normal programmers, correct and safe. I realise that openEHR still has to solve some things to make that true (mainly to do with better and more openly available Operational Template downstream generators), but at least we donât (for the most part) have models that just cannot achieve interoperability. In openEHR, every single installation of any major version of openEHR, anywhere in the world, is 100% safe for data creation, readability, and interoperability. It is the same schema forever, for all clinical and demographic data, within any given major release.
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.
- thomas
p.s. if v3 was so good and easy, I am pretty sure Stan would have introduced it at IHC.
---
### Author:  [@William\_E\_Hammond](https://discourse.openehr.org/u/William_E_Hammond)
#### Post date: [25 November 2010 17:22 UTC](https://discourse.openehr.org/t/iso-21090/15037/18 "2010-11-25T17:22:49Z")
Your experiences are different than mine. I must confess that I have not
been in any HL7 meeting which included shouting down. Disagreements - yes;
but not shouting down. In any case, The problem with kicking out the
non-modelers is that I am not sure who defines the experts - we ourselves?
I am not smart enough to think I know all the answers - or perhaps I should
say I am smart enough to know that I do not know all the answers. I
strongly believe in the democratic process. My knowledge of other
approaches have always lead to disaster. mI also have no problem with
disagreements. In fact, I think we find better solutions when we disagree.
But disagreements demand respectful discussions. I would think much of the
world would not accept your comment about proper design.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
\ openehr-technical@openehr.org
Sent by: cc
openehr-technical
-bounces@openehr. Subject
org Re: HL7 modelling approach
11/25/2010 11:40
AM
Please respond to
For openEHR
technical
discussions
\
Ed,
that's the whole problem with these standards committees: they are full of
people whose competence is not modelling or engineering, and who don't see
the downstream consequences of their choices, and in any case, the
'democratic' committee process largely prevents proper design occurring.
People just object to whatever, country X demands that a certain attribute
be renamed... it just comes down to who came on the day and who shouts
loudest.
I came to HL7 meetings for 5 or 6 years, and followed all the required
process (well, except the shouting down in meetings, sorry I am not into
that), and it had no effect. I know many many people who have said the same
thing, including people in key positions in e-health programmes around the
world.
- thomas
---
### Author:  [@William\_E\_Hammond](https://discourse.openehr.org/u/William_E_Hammond)
#### Post date: [25 November 2010 17:28 UTC](https://discourse.openehr.org/t/iso-21090/15037/19 "2010-11-25T17:28:32Z")
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
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. CDA is a
v23 product - based on the HL7 RIM. Thanks for the compliment that CDA is
findoing great use. I declare that success.
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.
Best
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
\ openehr-technical@openehr.org
Sent by: cc
openehr-technical
-bounces@openehr. Subject
org Re: HL7 modelling approach
11/25/2010 12:01
PM
Please respond to
For openEHR
technical
discussions
\
I have not seen much evidence of widespread uptake of HL7v3, indeed Stan
and others have said in various places that it has been significantly lower
than expected. CDA is the one thing that is getting use. The few large
implementations have spent a MOUNTAIN of money to do what they did, and I
know for a fact that the outcomes are not seen as good value.
See here for what appears to be a reasonable outline of the status quo -
[http://www.hl7standards.com/blog/2007/10/10/preparing-for-hl7-v3/](http://www.hl7standards.com/blog/2007/10/10/preparing-for-hl7-v3/)
I don't believe changing the RIM, 21090 and other models (apart from CDA)
would have that much negative impact on the industry as a whole, but if the
changes were radical enough, they could help a lot.
I currently don't have time to submit endless feedback to HL7 processes,
especially when I know they will not be listened to. I can't imagine that
HL7 is going fix its basic modelling methodology, which is what it needs to
do. I have actually provided very detailed critiques in the past, and
nothing has happened (other than blocking). Today I just have to be
concerned with things that are going to be economically implementable by
normal programmers, correct and safe. I realise that openEHR still has to
solve some things to make that true (mainly to do with better and more
openly available Operational Template downstream generators), but at least
we don't (for the most part) have models that just cannot achieve
interoperability. In openEHR, every single installation of any major
version of openEHR, anywhere in the world, is 100% safe for data creation,
readability, and interoperability. It is the same schema forever, for all
clinical and demographic data, within any given major release.
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.
- thomas
p.s. if v3 was so good and easy, I am pretty sure Stan would have
introduced it at IHC.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [25 November 2010 18:08 UTC](https://discourse.openehr.org/t/iso-21090/15037/20 "2010-11-25T18:08:35Z")
Ed,
I am sure you do not suffer the bad behaviour that I and many others have. As befits being a founding father of HL7, and many time chair, I am sure you are accorded proper respect. Unfortunately this doesnât happen for everyone. But that isnât my main complaint. My main complaints are about a) trying to do design by committee process and b) using wrong modelling approaches.
I have yet to meet the person who thinks that design by committee is proper design. Why do we have architecture and engineering schools all over the world in that case? Design of anything that matters just isnât done by holding meetings with randomly selected people. There are well recognised processes for software engineering, and well-understood competencies required to perform it. I guarantee you that the process that goes on at standards meetings do not come close. Proper design processes have a small number of people who work together to produce a coherent solution based on analysed requirements. Meetings of other competent people, following recognised processes specific to their activities may be used to discuss requirements, review, etc. But they donât create anything.
Better solutions are often found by disagreement, but it has to be between people with the basic competencies needed for the job at hand.
- thomas
[Next page](https://discourse.openehr.org/t/iso-21090/15037.md?page=2)