Interesting comments. It is interesting that the ISO standard was approved
by HL7, CEN and ISO.
As to why we fix the problems of ISO 21090 on HL7, someone else will have
to address. As far as I know, HL7 actually does not even vote on ISO
standards. I must admit that I hoped at times the differences could be
resolved. I guess the differences are so fundamental that we can't find a
path to harmonization. Maybe some other group with the biases that we have
can help resolve the situatiuon. I am interested in seeing things brought
together. I think if we don't, neither of us will enjoy success at a level
we would like to see. More importantly, I think we won't meet the
requirements of the global HIT community without trying to find a solution
to the differences. I think, and I know you don't agree, that some of the
differences are matters of opi ion - a different way of doing things., I
am using data types for ISO 21090 without any problems. I may be to dumb
to appreciate the difficulties. I do admit that I am not using every data
type.
In any case, the best to you. I thnk openEHR has made major progress and
is becoming an influential organization. I do enjoy some of the
discussions on this list server. I am, believe it or not, learning some
new things. Thanks to these discussions.
Best. Looking forward to seeing you all in January.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
<thomas.beale at oce
aninformatics.com To
> openehr-technical at openehr.org
Sent by: cc
openehr-technical
-bounces at openehr. Subject
org Re: ISO 21090 data types too
complex?
11/06/2010 05:36
PM
Please respond to
For openEHR
technical
discussions
<openehr-technica
l at openehr.org>
Hi Ed,
well since you asked ... my list of problems, from a cursory examination:
The model is defined such that all data types inherit from HXIT and
then ANY, which contain 7 attributes specific to HL7v3 messages. This
means that any other types, such as BL (Boolean) inherits these
attributes. This is a basic modelling error, since the normal
approach is to separate context-specific attributes (e.g. specific to
the use of data values in messages, but not other uses) into
?wrapper? classes. The practical effects of this modelling are
twofold:
There is not a close correspondence between the 21090 idea of
?ANY? and the typical Any/Object or other root class of most
object-oriented type systems ? this name clash would have to be
resolved in some way;
an implementation of the 21090 data types is forced to have
HL7v3 specific attributes in its base classes, and it also
complicates the use of more orthodox modelling for such
purposes;
alternatively to produce a version of 21090 for use outside of
HL7v3, a ?profile? of some kind has to be developed by ISO
and/or CEN.
It includes ?types? for name and address that are really
compositional structures, and would normally be considered to be
archetypable or otherwise configurable structures consisting of
lists, trees etc of primitive types (String, Integer etc); (this
problem has been around forever in HL7. I was in CEN meetings in 2002
or 2003 when people were complaining about this. It might make sense
for HL7, but it doesn't in more generic modelling frameworks)
It uses a modelling notion called ?flavours? defined via ?common
constraint patterns on existing datatypes?, whereby e.g. the
timestamp type TS can be constrained to TS.CA.BIRTH, i.e. a variant
used in Canada for recording birth dates. The problems with this
approach include:
is that it is not supported in any standard industry UML or
related tools (e.g. Eclipse Modelling Framework); (It is sort
of doable in OO languages, but it breaks the normal spirit of
OO modelling, and is not conducive to maintainability)
class-names containing the ?.? character are not legal in most
type systems;
it is not generally known or understood by IT practitioners;
it is not clear how such ?constrained types? should be
implemented in normal object-oriented development technologies;
it mixes the concept of localised constraint that would
normally be defined outside of the software, with ?hard? data
types that would normally be implemented in the software (e.g.
TS would normally be implemented in software, but implementing
?Canadian birthdate? is likely to make software brittle).
Due to the above problem, date/time types typically needed in
clinical data, and archetypes, are defined using types: TS.DATE,
TS.DATETIME, although there is no match for the logical type
?Duration? or ?Time?.
The error of including context-specific attributes within base types
occurs elsewhere in the specification. To give two examples:
The type TEL (telecommunications address) includes the
attribute ?useablePeriod?, intended to indicate when the
address is useable. Normally such a context attribute would be
found within a context specific information structure
representing ?Contact? or some other typical demographic
concept in which not only the date range, but also type /
purpose (e.g. ?business?, ?home?) might be recorded. 21090
forces it to be in every instance, although it presumably can
be empty (as is likely in most instances).
The type II (instance identifier) includes the coded attribute
?reliability? which indicates whether the identifier was
?issued by the system?, ?verified by system? or ?unverified by
system?.
The modelling style seems to follow the strange HL7 obsession with
non-object orientation, popularised in the RIM. In summary, I don't see
21090 as being at all appropriate for the title of the standard, which is
"Health Informatics ? Harmonized data types for information interchange".
Instead, it should just have been called "Data types for HL7-based
messaging". It doesn't make sense as an ISO standard; it is really an HL7
standard.
- thomas
On 06/11/2010 18:39, William E Hammond wrote:
I agree with Dqavid's points.
The world, unfortunately, is not perfect. Understanding how the ISO
data
types standard came into being might be useful in understanding why
it is
as it is. After more than 5 years in trying to get a g;obal standard
for
data type, a group, lead by Graham Grieve, was able to put together a
combination of documents from ISO, CEN, and HL7. The result was an
overwhelming and certainly more than we need or will probably ever
use data
types.
I would be interested in knowing why this standard is considered to
be
complex. Is it a result on the large number of data types? Is is a
result
of the complexety of some of the data types?
I would be interested in knowing how anyone would change the simplier
data
types. It seems to me that most of these "primitive" data types are
exactly wahat we have been using for a long time.
I would suggest that NCI - and others - simply identify what subset
of the
datatypes they propose to use and move ahead. On the o0ther hand,
that
migtht happen naturally out of the full set. If its\'s too complex
or not
useful, it will not be used.
I agree that everyone haveing their own set does not solve the
problem. If
any set meets my needs, I don't care what else is in the package.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
