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:
o 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;
o 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;
o 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:
o 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)
o class-names containing the '.' character are not legal in
most type systems;
o it is not generally known or understood by IT practitioners;
o it is not clear how such 'constrained types' should be
implemented in normal object-oriented development technologies;
o 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:
o 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).
o 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
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101106/db2056a9/attachment.html>
