More on ISO 21090 complexity

Technical (archive)
1

It might be just me thinking that some of the 21090 types are not that simple, so am interested in reactions of others. Here is the documentation of the term-code representation type CD, which explains how the ‘no exceptions’ (CNE) and ‘exceptions’ (CWE) variants should be realised:

A CD is a reference to a concept defined in an external code system, terminology, or ontology. A CD may contain a simple code - that is, a reference to a concept defined directly by the referenced code system, or it may contain an expression in some syntax defined by the referenced code system that can be meaningfully evaluated. e.g., the concept of a “left foot” as a post-coordinated term built from the primary code “FOOT” and the qualifier “LEFT”.

A CD may also contain an original text or phrase that served as the basis of the coding. This is preserved to allow for validation of the representation of the concept in various fashions.

A CD can contain one or more translations into multiple coding systems. The translations are all representations of the same concept in various code systems. There is only one concept, and only the first CD may contain an original text. It is possible to represent the translation chain - which CD was translated from which - if desired. Each CD may also carry a rationale to indicate why it is represented.

A CD with no nullFlavor attribute SHALL have a code attribute or nonNull originalText attribute. A CD that has a code, codeSystem or originalText attribute but does not meet external constraints of the applicable value set SHALL have a nullFlavor attribute with a value of OTH.

Attributes with type CD are generally bound by externally specified constraints which constrain the coded concepts to which a CD may refer. These constraints may be qualified as “extensible” (CWE) or “not extensible” (CNE). If the constraint is not extensible (CNE), then a the CD that does not have a nullFlavor SHALL contain a code that conforms to the constraint. If the constraint is extensible (CWE) then a CD that does not have a nullFlavor SHALL contain either a code that exists in the domain with which the attribute is associated, a code from a locally defined code system, or just some originalText that describes the concept. If the code is taken from a locally defined code system, then the codeSystem property SHALL specify the local code system.
For both CNE and CWE constraint types, the translations may contain nonNull codes from any source unless otherwise specified by the constraining model.

For code systems that define expression syntaxes, CNE constraints may be used, providing that the code system definitions define the appropriate support to enable value sets to make useful statements about how to control the expression syntax, and that the value set machinery used also has the appropriate support.

This is the data structure of a CD, with the HL7v3 message attributes in red:

 type CD = class (

*   validTimeLow : characterstring,*

*   validTimeHigh : characterstring,*

*   controlInformationRoot : characterstring,*

*   controlInformationExtension : characterstring,*

*   nullFlavor : NullFlavor,*

*   updateMode : UpdateMode,*

*   flavorId : Set(characterstring),*

   code : characterstring,

   codeSystem : characterstring,

   codeSystemName : characterstring,

   codeSystemVersion : characterstring,

   valueSet : characterstring,

   valueSetVersion : characterstring,

   displayName : ST,

   originalText : ED,

   codingRationale : CodingRationale,

   translation : Set(CD),

   source : CD

)

Am I alone in thinking that this is not the simplest way to implement exceptions or not, to coding? The rules for setting NullFlavor are also not so simple. I would have thought a more obvious method would be to define a type with a text field in it, and then a subtype with coding, e.g. (with message attributes removed):

 type TEXT = class (

   text : ST

   mappings: Set(CD)

 )

 type CD: TEXT = class (

   code : characterstring,

   codeSystem : characterstring,

   codeSystemName : characterstring,

   codeSystemVersion : characterstring,

   valueSet : characterstring,

   valueSetVersion : characterstring,

   codingRationale : CodingRationale,

   translation : Set(CD),

   source : CD

)

This would enable specifiers to simply put TEXT for ‘coded with exceptions’ or CD for ‘coded no exceptions’ within a model, with the GUI making the relevant coding widgets available in the correct way (there are some slight benefits to making a more theoretically correct model, using 3 classes rather than just 2, but the differences are not significant). Note that I merged displayName and originalText, as this seems to be a modelling confusion; if originalText represents some other text, not the text of the code, then the whole data structure is essentially a mapping, not a coding of the text. One way to do this is shown with a ‘mappings’ attribute in the TEXT class (some people will object that this could be used infinitely, but in practice it is never a problem, since applications don’t create such structures). In the original model, ‘originalText’ and ‘displayName’ would be the same much of the time. The rules to do with setting nullFlavor would make more sense elsewhere, not in the core model.

There are also some interesting comments relating to the valueSet attribute:

In many cases, a CD is created from a value set – either a code/code system pair is chosen from a valueSet, or one is not chosen and the CD has the exceptional value of NullFlavor.OTH. If no code is chosen, it is generally inappropriate to reference the code system from which the code was chosen as the value set may not match the code system (may include a subset of the codeSystem, or additional terms from other code systems); instead, the value set should be provided. In addition, there are some known use cases where the value set that a user or system was offered when choosing a code affects the interpretation of the code.

The last sentence above indicates that the meaning of a code stored in data might depend on how it was chosen. This would break the basic immutability of meaning of codes in a code system. I wonder how we would compute with such data?

The ‘translations’ attribute is also strange: according to the documentation it is not about translations but about code synonyms and/or mappings (in reality two different things).

  • thomas beale
2

hi Tom

It might be just me thinking that some of the 21090 types are not that
simple

no, they're not simple. That's not the relevant question. Instead, it's
how well designed they are. I could design a set of "simple" types
that met the requirements, but the profusion of resulting types would
not be simple to implement. So the long term question is not how
simple the types are, but how you can work with them. I do recognise
that the simplicity of the types is related to that, but there is more to
it than just that.

The ISO 21090 types are designed using a different philosophy and
design pattern to what you use - they are *dense*. This is not to
everybody's liking, but does have more benefits the further you get into
implementation. It certainly has the problem that the initial engagement
with the data types requires more investment before favourable
outcomes start to occur

We could discuss who this benefits if you want, but the saying that
they just aren't "simple" is... too simple

This is the data structure of a CD, with the HL7v3 message attributes in

I guess you'll continue to dismiss them as "hl7 v3 message
attributes", but you miss the point by doing so - they are a response
to a set of use cases that are not v3 - or even messaging - specific.
They are in a different place to where you would like to have them,
but that's about the above discussion

I would have thought a more obvious method would be to define a
type with a text field in it

I don't think it's more obvious. It's certainly possible, but then I have
terminology policy differences represented as different types in
my engineering layer - rather a drawback from at least my point
of view. I'd say more, but I think that's enough to demonstrate that it's
not obvious. To determine which was better would be a long discussion,
and we'd need to start by determining the scope of "better for what?"

with the GUI making the relevant coding widgets available in the correct way

uh? What's the GUI got to do with it? For the ISO 21090 data types,
this is not in scope. I understand that this is in scope for openEHR,
because you automatically build UI from model's choice of data
type, and that's why you'll continue to use openEHR data types for that.
fine, makes sense.

Note that I merged displayName and originalText, as this seems
to be a modelling confusion

or you could actually read the documentation that makes the differences
very clear. In particular, note the restrictions on the use and implications
of displayName. I will say that originalText is semantic in nature - inherent
to the actual meaning, whereas displayName is distinctly interoperability
related - and pretty much irrelevant in an openEHR context.

In addition, there are some known use cases where the value set
that a user or system was offered when choosing a code affects
the interpretation of the code.

The last sentence above indicates that the meaning of a code stored in data
might depend on how it was chosen. This would break the basic immutability
of meaning of codes in a code system. I wonder how we would compute with
such data?

yes, I wonder about that too. And the answer appears to be, pretty much, that
you can't. Which is the point of recording the value set - so that some other
person, later, can decide for themselves whether the limited value set undercuts
the immutability of the meaning of the code. The problem is that this *does*
happen in practice all the time, and merely banning it's occurrence in our
mental model of the standard contributes to the standard being a fantasy.
Needless to say, I argued against the inclusion of that particular text
strenuously, but I end up recognising that it is merely a reflection of
the real world

The 'translations' attribute is also strange: according to the documentation
it is not about translations but about code synonyms and/or mappings (in
reality two different things).

really? how would you define so? Do you mean, translations to other languages?
otherwise, the terms mappings vs translation are used about as consistently
as any other terminological terms. (See, it's the proven blind leading the
blind when the terminologists tell us that they can lead us to consistent use
of terms)

Grahame

3

Grahame, Tom

Given the enormous respect I have for both of you and your deep technical
knowledge in this domain
I hesitate to offer an opinion.

However, I have followed with great interest the evolution of the ISO
dataypes from a small Standards Australia
Technical working Committee, all the way through HL7 and ISO.

From the point of view of a clinical datatype implementer who has to write

actual code, the ISO dataypes provide a level of detail
that is both required and sufficient. They are definitely not "simple" in
their definition but are mostly "simple"
in terms of concept representation.
The atom at one time looked "simple" and remains so in concept, though in
fact having considerable underlying complexity.
The level of detail required depends on your use case which seems to be a
major contributor to your divergence of opnion.

In addition, there are some known use cases where the value set
that a user or system was offered when choosing a code affects
the interpretation of the code.

The last sentence above indicates that the meaning of a code stored in
data
might depend on how it was chosen. This would break the basic
immutability
of meaning of codes in a code system. I wonder how we would compute with
such data?

As you correctly observe Tom, this makes these particular codes
"non-computable"
and hence possibly not worth coding. However, as Grahame notes, it does
reflect some real world instances
where Grahame conceded (somewhat reluctantly) to the clinicians. Usage (or
lack of it) will determine
whether this has any actual value, but this issue probably needs to be
highlighted in BIGGER LETTERS.

Regards
Vince

Dr Vincent McCauley MB BS, Ph.D
CEO, McCauley Software Pty Ltd www.mccauleysoftware.com
Chair, IHE Australia www.ihe.net.au
Treasurer, Medical Software Industry Association www.msia.com.au
p: +61298186493
f: +61298181435

Jan. 2011 HL7 International Meeting: Sydney www.HL7.org.au/Sydney2011

4

Thanks Vince

and hence possibly not worth coding. However, as Grahame notes, it does
reflect some real world instances
where Grahame conceded (somewhat reluctantly) to the clinicians.

this kind of makes it sounds as though I needed to concede!
Even if I hadn't conceded, I was going to be outvoted on this
issue, like some others :wink:

I'm just the editor!

Grahame

5 
This is the data structure of a CD, with the HL7v3 message attributes in


I guess you'll continue to dismiss them as "hl7 v3 message
attributes", but you miss the point by doing so - they are a response
to a set of use cases that are not v3 - or even messaging - specific.
They are in a different place to where you would like to have them,
but that's about the above discussion

I don’t think I am missing the point at all. They are
a) a response to some (undoubtedly real) needs by the hL7v3 design group, and are modelled according to the hL7v3 architecture, not some other architecture. I don’t dispute the need to address the requirement that these attributes try to address, I am just pointing out that this is HL7’s specific way of doing it (other people would have designed completely different solutions).

b) there is no escaping the fact that these attributes are inherited into every other data type, a design that instantly renders these types not directly usable for situations other than messaging. Since the first thing any system will need to do with received data in messages is process and store it in some way, that’s an extremely unfortunate thing to have done. I realise you had no choice, and this is the way beloved of HL7, but it does happen to break some basic OO rules of reuse and maintainability.

I would have thought a more obvious method would be to define a
type with a text field in it


I don't think it's more obvious. It's certainly possible, but then I have
terminology policy differences represented as different types in
my engineering layer - rather a drawback from at least my point
of view. I'd say more, but I think that's enough to demonstrate that it's
not obvious. To determine which was better would be a long discussion,
and we'd need to start by determining the scope of "better for what?"

better for everything. I am just talking about a simpler, more comprehensible model, in the interests of less bugs and anomalies by implementers.

with the GUI making the relevant coding widgets available in the correct way


uh? What's the GUI got to do with it? For the ISO 21090 data types,
this is not in scope. I understand that this is in scope for openEHR,
because you automatically build UI from model's choice of data
type, and that's why you'll continue to use openEHR data types for that.
fine, makes sense.

The openEHR data types have nothing specific to to with the GUI; I only made this comment because I have seen specious arguments about how certain model structures (like the one I proposed) would lead to infinite strings of data, which of course is nonsense. Thinking about how a real system works (e.g. at the GUI layer) may help some people to understand this.



Note that I merged displayName and originalText, as this seems
to be a modelling confusion


or you could actually read the documentation that makes the differences
very clear. In particular, note the restrictions on the use and implications
of displayName. I will say that originalText is semantic in nature - inherent
to the actual meaning, whereas displayName is distinctly interoperability
related - and pretty much irrelevant in an openEHR context.

I have read the documentation, don’t worry! I still think it is conceptually mixed up. In fact, I am not even sure the spec is clear itself on what originalText really is:

Original text can be used in a structured user interface to capture what the user saw as a representation of the code on the data input screen, or in a situation where the user dictates or directly enters text, it is the text entered or uttered by the user

So is it a representation of the code on the data input screen (i.e. the term for the code) ? Or is it some other freely entered text to which a code (and term) is being attached? Why is originalText ‘semantic’ and ‘displayName’ not - when it is in fact the proper linguistic rendering of the code, and therefore surely ‘semantic’?

The last sentence above indicates that the meaning of a code stored in data
might depend on how it was chosen. This would break the basic immutability
of meaning of codes in a code system. I wonder how we would compute with
such data?


yes, I wonder about that too. And the answer appears to be, pretty much, that
you can't. Which is the point of recording the value set - so that some other
person, later, can decide for themselves whether the limited value set undercuts
the immutability of the meaning of the code. The problem is that this *does*
happen in practice all the time, and merely banning it's occurrence in our
mental model of the standard contributes to the standard being a fantasy.
Needless to say, I argued against the inclusion of that particular text
strenuously, but I end up recognising that it is merely a reflection of
the real world

more realistically, a reflection of committee-based standard building.

The 'translations' attribute is also strange: according to the documentation
it is not about translations but about code synonyms and/or mappings (in
reality two different things).


really? how would you define so? Do you mean, translations to other languages?
otherwise, the terms mappings vs translation are used about as consistently
as any other terminological terms. (See, it's the proven blind leading the
blind when the terminologists tell us that they can lead us to consistent use
of terms)

you are right in that there is probably more complexity to this bit that we have time for here, but we can at least distinguish between:

  • a true synonym (different linguistic rendering of the same concept), AND

  • a mapping - usually done for classification purposes, e.g. association of a broad ICD or DRG code to some specific disease or condition text.
    To me, the fact that there are so many things worth debating in the standard really tells me that the committee-based approach hasn’t worked; a proper engineering review process would have changed the standard significantly and for the better in my view.

  • thomas

6

I see this as one of the major problems of HL7 actually. It seems to think that everything should be driven by use cases. This is not the case. The general drive in all engineering and software development is to have layers of highly reusable elements that work in all situations. Thus the design concept of ‘Integer’ and ‘String’ in a programming language is not specific to any particular used. Neither should the concept of ‘codedtext’, ‘ordinal’ or ‘physical quantity’. The idea that a set of such data types should be built not just for messaging, but apparently with features for other more specific use cases is plain wrong. It is not good modelling. Contextual (i.e. use-case specific) features should always be added in specific classes / locations in models dealing with those specific use cases.

The openEHR data types are designed like that - it is just basic god practice. They can be (and are) used in messaging, storage, GUI, business logic. Context specific features are modelled and coded where they are relevant, not integrated into what would otherwise be completely generic data types.

Not understanding this basic modelling practice has lead HL7 to produce models that are very far from being easily implementable or reusable - which is a real pity.

  • thomas
7

[2nd attempt]

This is the data structure of a CD, with the HL7v3 message attributes in


I guess you'll continue to dismiss them as "hl7 v3 message
attributes", but you miss the point by doing so - they are a response
to a set of use cases that are not v3 - or even messaging - specific.
They are in a different place to where you would like to have them,
but that's about the above discussion

The point is
a) that they are HL7’s idea, from HL7’s architecture, of how to solve some problems. Had other engineers & developers been involved, other, better and certainly different solutions could have been found.
b) it is an unavoidable fact (an inconvenient truth) that HL7’s approach of putting context/use case specific attributes in general models, and then expecting them to be ‘profiled out’ is contrary to maintainability and reusability of these models. Where I would like to see them is not my personal choice, it is just a conclusion of basic good modelling practices.



I would have thought a more obvious method would be to define a
type with a text field in it


I don't think it's more obvious. It's certainly possible, but then I have
terminology policy differences represented as different types in
my engineering layer - rather a drawback from at least my point
of view. I'd say more, but I think that's enough to demonstrate that it's
not obvious. To determine which was better would be a long discussion,
and we'd need to start by determining the scope of "better for what?"

better for everything. We should be interested in generic, reusable data types here, not HL7 message specific ones, nor ones that try to incorporate every possible contextual use case into the same model. That just creates complexity and increases the likelihood of non-interoperable implementations, due to different implementers having interpreted the rules differently, and profiled the model differently.



with the GUI making the relevant coding widgets available in the correct way


uh? What's the GUI got to do with it? For the ISO 21090 data types,
this is not in scope. I understand that this is in scope for openEHR,
because you automatically build UI from model's choice of data
type, and that's why you'll continue to use openEHR data types for that.
fine, makes sense.

I just used the example of the GUI to help people understand that there is no realistic danger of endless strings of terms, even if the model technically permits it. With respect to the openEHR data types, they have no specific relationship to GUI, messages or anything else. On the other hand, they can (and are today) used effectively in GUIs, messages, persistence, business logic and document processing. Contextually specific features needed in any of those places are included in the relevant models and software, not jammed into the data types. This is the way any good modelling works; the openEHR models just try to follow generally accepted good modelling principles.



Note that I merged displayName and originalText, as this seems
to be a modelling confusion


or you could actually read the documentation that makes the differences
very clear. In particular, note the restrictions on the use and implications
of displayName. I will say that originalText is semantic in nature - inherent
to the actual meaning, whereas displayName is distinctly interoperability
related - and pretty much irrelevant in an openEHR context.

I have read the spec, and I don’t think it is even clear itself (here we come up again against trying to satisfy competing use cases within a single data types specification).

Original text can be used in a structured user interface to capture what the user saw as a representation of the code on the data input screen, or in a situation where the user dictates or directly enters text, it is the text entered or uttered by the user

So is originalText the freely entered text of the user, or the term for the code which is being attached to some text? How is the original text the user entered more ‘semantic’ than the term from the terminology? The problem here is not specific to this type in this model, but in fact systemic in the whole specification: the actual formal semantics of any model are only what is expressed in the formal specification. Any further meaning of values in any field of any object defined by the data types specification is not the business of the latter, but of the client code & models using it. However, this 21090 specification is full at every turn with natural language statements about how the various fields might be interpreted in various circumstances, according to use cases known by its authors. I am not saying this is not useful information, but what I am saying is that it is in completely the wrong place.

Some posts ago, I suggested that a useful standard for data types could consist of:

  • a set of clean, clear core data types - no context information like ‘updateMode’ or null flavour etc.
  • a set of wrapper types designed to use the core types, optimised for messaging
  • other sets of wrapper types as needed, optimised for other specific purposes, e.g. storage or whatever
    The contextual / use case specific stuff would then go in the ‘wrapper specifications’.
The last sentence above indicates that the meaning of a code stored in data
might depend on how it was chosen. This would break the basic immutability
of meaning of codes in a code system. I wonder how we would compute with
such data?


yes, I wonder about that too. And the answer appears to be, pretty much, that
you can't. Which is the point of recording the value set - so that some other
person, later, can decide for themselves whether the limited value set undercuts
the immutability of the meaning of the code. The problem is that this *does*
happen in practice all the time, and merely banning it's occurrence in our
mental model of the standard contributes to the standard being a fantasy.
Needless to say, I argued against the inclusion of that particular text
strenuously, but I end up recognising that it is merely a reflection of
the real world

I would say it is a reflection of the committee-driven standards building process. There is no realistic prospect of physicians or anyone else going back through gigabytes of medical data and trying to decide what might have been in the mind of the person originally recording the data, and how that might have been somehow different from the terminology’s definition of the meaning, due to some knowledge about how they chose it. There may be reasons to record the value set / ref set id, and it may be true that the author of the data could only choose some higher level code e.g. ‘parasite infection’ rather than ‘giardia infection’. But whatever term is chosen, it must be by definition the correct thing to record in the data, otherwise the software and clinical process is a nonsense.

The 'translations' attribute is also strange: according to the documentation
it is not about translations but about code synonyms and/or mappings (in
reality two different things).


really? how would you define so? Do you mean, translations to other languages?
otherwise, the terms mappings vs translation are used about as consistently
as any other terminological terms. (See, it's the proven blind leading the
blind when the terminologists tell us that they can lead us to consistent use
of terms)

well we can make the basic distinction:

  • synonym: a different linguistic rendering of the same concept
  • mapping: an association of a term, typically a classification, with some text, for a particular purpose, e.g. an ICD code or DRG code.

The terminology’s business is to maintain the first kind; the second kind is the business of EHR system and applications. Neither of these is what people mean when they use the word ‘translation’ in the normal sense.

  • thomas
8

Apparently there are others including the CDISC people very unhappy about the ISO21090 data types. This comment from Barry Smith’s blog (emphasis added by me):

XML4Pharma said:

As an XML-guy, my major problem with all these ‘standards’ (as well HL7, ISO21090, OpenEHR) is that they all start from UML modeling and auto-generate the XML-schemas from that, ignoring any of the advanced features (such as native XML datatypes) of XML.

I have no problem with UML modeling, but I have major problems with the naïve believe that one can generate high quality XML-Schemas automatically from UML diagrams.
Essentially, these ‘standards’ are abusing the XML standard itself. They even manage to reinvent basic datatypes such as integer, date, time, duration which are already defined by XML and XML-schema itself. For example, HL7- and ISO21090 ‘date’ is expressed as YYYYMMDD, where there is already a base XML-schema datatype ‘date’ expressed as YYYY-MM-DD. So when validating an HL7-v3-message against the schema (and even against the schematron), the date 20070231 (February 31, 2007) is accepted as a correct date. If they had respected the XML standard instead of abusing it, then the same data in correct XML (2007-02-31) would have immediately been rejected by XML-Schema as being an invalid date. The same applies for many other HL7- and ISO21090 datatypes (e.g. date, time, datetime, duration). Each time HL7 as well as ISO21090 ‘reinvents’ these datatypes making life much more complicated than is necessary.
I am one of the developers of the CDISC ODM standard used in clinical research. We also use UML for modeling, but our schemas are not automatically generated from them, but created manually. We use native XML datatypes as much as possible, not trying to reinvent the wheel. We try to make our standard so that instance files are even understandable by non-specialist when looking at the XML itself (so without stylesheet). They are also ‘human-readable’. The latter cannot be said of any HL7- or ISO21090 instance file.

Some time ago, our team was asked to enable ISO21090 in ODM. The request came from one of the largest nonprofit research organizations in the US. We had a teleconf with them and it soon became clear that they wanted us to replace our own (XML-Schema based) datatypes by the ISO21090 datatypes. We refused.

Instead, we will develop an ODM-extension that allows to attach ISO21090 data points (in their own namespace) to ODM ‘ItemData’ elements. Doing so, the ODM standard will support ISO21090 AND remain ODM.
Somewhat more than a year ago, I developed a stylesheet to extract information from HL7-CCD (health records) to prepopulate clinical forms in ODM format. This stylesheet was soon regarded as a key-enabler for integration between health records and clinical research. However, I cannot guarantee that it will work for ANY health record in CCD format. The reason is that CCD is so complex that I fear that one can put the same information (for example a systolic blood pressure) in very many ways in a CCD. So how can I guarantee that the systolic blood pressure can be extracted in all cases?

The ISO21090 ‘standard’ is clearly a political compromise, not a technical compromise. As such, from the technical point of view it is probably not an improvement.
In my personal opinion, the best that can be done for a data standard for healthcare is to restart from nearly scratch. Yes, UML modeling can and should be used, but based on solid and agreed principles, and taking into account that XML will later be the transport format. So, no ‘reinvention’ of datatypes, but using the XML native datatypes right from the start. No fully-automated generation of XML-Schemas, but development of the schemas by schemawriters (though part of the work can be automated).

And most of all, involve all eligible players (HL7, ISO, OpenEHR, etc.) right from the start.

I am not involved with these people, but their response sounds entirely rational. In my view this just shows that the 21090 data types in their current form are not at all what we should be standardising on.

  • thomas
9

I see this as one of the major problems of HL7 actually. It seems to think that everything should be driven by use cases.

shorter Tom Beale: Only by ignoring use cases can one design usable data types?

Original text can be used in a structured user interface to capture
what the user saw as a representation of the code on the data
input screen, or in a situation where the user dictates or directly
enters text, it is the text entered or uttered by the user

So is originalText the freely entered text of the user, or the
term for the code which is being attached to some text?

The second only if it's the basis for the choice of the code.
So the two fields may contain the same information.

I'm not going to argue about the more general point you
are making. I don't think it's obviously true that your proposed
alternative is better (though it's certainly not obviously worse).
But I agree that there's no question that the data types
are HL7's data types.

There is no realistic prospect of physicians or anyone else
going back through gigabytes of medical data and trying to
decide what might have been in the mind of the person
originally recording the data

well, I thought so too. But it already happens in some places.

But whatever term is chosen, it must be by definition the
correct thing to record in the data, otherwise the software
and clinical process is a nonsense.

please inform the end users that you say that they must behave
this way.

well we can make the basic distinction:

   * synonym: a different linguistic rendering of the same concept
   * mapping: an association of a term, typically a classification, with some text, for a particular purpose, e.g. an ICD code or DRG code.

where do you get that distinction? I'm not familiar with these
terms from any terminology standard, though I haven't yet
read the latest version of Heather's glossary

Essentially, these 'standards' are abusing the XML standard itself.

heh. XML forever, it will solve every problem in the world. Just if
everyone else does it 'my' way, we'll be right.

For example, HL7- and ISO21090 'date' is expressed as YYYYMMDD,
where there is already a base XML-schema datatype 'date' expressed
as YYYY-MM-DD. So when validating an HL7-v3-message against the
schema (and even against the schematron), the date 20070231
(February 31, 2007) is accepted as a correct date.

OpenEHR too. We are all beyond redemption. Actually, I don't know
why he thinks that 20070231 is valid, I wrote and tested the regex
to make it illegal, though the regex doesn't do the leap year thing.
[edit: ahh no, that regex didn't make it in for some reason. I don't
recall why, but it was -super- long.].

And we chose not to use the silly XML schema type with care. I
don't know if it was the right decision, but, unlike he says, there was
a reason, to do with incomplete dates. It's actually more compelling
in times than dates but we do both the same way, as does openEHR

So, no 'reinvention' of datatypes, but using the XML native
datatypes right from the start. No fully-automated generation of
XML-Schemas, but development of the schemas by
schemawriters (though part of the work can be automated).

When I teach the data types or CDA, I point out that there's two
irreconcilable camps in how to use XML. The first camp says that
XML is just a transport, and you keep away from being clever, so
that it just works. I call this is "the object mapping crowd" (and
it solidly includes both you and me). The second camp says
that XML is your concrete form, and you leverage it as hard
as you can, including tricks in schemas and screwy one
off things to make transforms easier. I call this the "XML
hacker" crowd. And the two groups want different frequently
incompatible things. XML4Pharma who you are quoting is certainly
in the second crowd. The interplay between the two camps
virtually guarantees that any XML standard is a political compromise.
Give that guy a beer or two, and ask him about schema...
(and, btw, if one was to follow his recommended method,
you'd end up at the same place, unless either camp was to
somehow figure out how to exclude the other. The details
might be different, but the basic picture would be the same,
I reckon)

Grahame

10

shorter Tom Beale: Only by ignoring use cases can one design usable data types?

I think is more like "you don't have to look only the use cases to
design usable data types"

heh. XML forever, it will solve every problem in the world. Just if
everyone else does it 'my' way, we'll be right.

there is a quote that says "XML is like violence. If it doesn't solve
your problem, you're not using enough of it." :wink:

anyway, I prefer ISO dates whenever possible

11

shorter Tom Beale: Only by ignoring use cases can one design usable data types?

I think is more like “you don’t have to look only the use cases to
design usable data types”

I agree with this vision. Because we can’t think of all use cases, so we can never create datatypes that consider all posible cases. So, we need to think more general solutions, seeing not only the use cases.

  • Pablo.
12

Hi all,

Given this discussion on ISO 21090 I would like to bring forward the following:

  1. Every international standard is and has to be based on political decisions: all member countries have to be accepting it and hence will want to get something specific out of it, or block too difficult parts.
    That is the way of standards making, in contrary to what a group of friends like in OpenEHR foundation can do. This has nothing to do with committees working in the implementation space or sitting at a table. It is how formal democratic voting goes. Not a perfect system we know, but apparently chosen above totalitarian approaches.
    This democratic development (inclusive of all parties concerned, and voting by members) has been and is still the case for ISO 21090.
    The same democratic and transparant voting procedure by members is used in HL7 international (of course the membership is organised different from ISO).

  2. The use cases for ISO 21090 do come from different sources: an older basic data type standard from ISO, clinical use cases, CEN standards, in particular the one on archetypes (13606-2), AND HL7 among others. The resulting set is accepted by the ISO membership, and indeed the HL7 membership, referring to it as datatypes R2 (and facing an enourmous piece of effort and work to redo a lot of the models and messages due to the harmonisation). And under the JIC, also the CDISC organisation deals with this since ISO 21090 is part of the joint harmonisation work. I think the willingness of the different JIC partners to step beyond their traditional route and harmonise this formidable and fundamental work is the most important achievement in the last 25 years of international standards work. I would like to compliment Grahame in particular that he managed to get a useful, albeit say 96% “perfect” standard out of this.

  3. No standard or specification can be perfect. In particular, Tom’s work might be closer to perfection than the ISO 21090, but that is hypothetically a matter of a percentage between 96% and 97.5% on a VAS of 0 - 100%. I personally are pragmatic, I need in Detailed Clinical Models and in HL7 v3 Care Provision message implementations about 20 - 30% of the ISO 21090, so do not bother about the rare use cases addressed.

  4. Core principle behind the standard is that you create a profile around it that allows you to implement it in your system, or your message, or your datawarehouse or whatever. There is usually no way to have it 100% ready for use. The example from the blog that Tom talks about, where ISO 21090 is mapped into their own CDISC models is almost perfect. That is the way to go. Yes it will include mappings from ISO time format to XML time format. But if that works well on implementation, at the exchange level you are compliant.

  5. If you adhere to ISO 21090 / conform to it / there is always the option to limit your implementation set. E.g. refer to particular chapters or codes in ISO 21090.

  6. It looks from Tom’s objections that OpenEHR cannot adhere to data type standard ISO 21090. Is that a problem in the OpenEHR specifications, or is that a problem on political level: we do want to invent our own because it is closer to perfection? What I mean here is: if I create archetypes in OpenEHR spaces (there are about 25 in Dutch available pending other issues to be solved before releasing). And from this system I need to exchange HL7 v3 messages in the Dutch national switshboard space, will I be in trouble because the OpenEHR archetypes cannot handle even the basic ISO 21090 datatypes?

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

13

Just one more thought about this.

When someone design a custom software system, the information model is not only based on use cases. We all know about “general software quality characteristics” that we have to think about, like Usability, Maintainability (modifiability, adaptability, etc), Completeness, Conciseness etc, etc (http://en.wikipedia.org/wiki/Software_quality#Maintainability) (this are the basics of software engineering, nothing new to us). So, we have to think of something that:

  • reach something that meets the use cases (complete, adds complexity),
  • but it is also cocise (only needed things, must be simple),
  • and maintainable (generic, good organization, simple extend and change (adapt to other realities that may be not covered by the use cases))
  • etc …

So, the use cases are a part of the puzzle, of course are the base of the design, but not the olny piece of the final puzzle (if we want quality).

Kind regards,
Pablo.

shorter Tom Beale: Only by ignoring use cases can one design usable data types?

I think is more like “you don’t have to look only the use cases to
design usable data types”

I agree with this vision. Because we can’t think of all use cases, so we can never create datatypes that consider all posible cases. So, we need to think more general solutions, seeing not only the use cases.

  • Pablo.

heh. XML forever, it will solve every problem in the world. Just if
everyone else does it ‘my’ way, we’ll be right.

there is a quote that says “XML is like violence. If it doesn’t solve
your problem, you’re not using enough of it.” :wink:

anyway, I prefer ISO dates whenever possible

openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

_______________________________________________ openEHR-technical mailing list openEHR-technical@openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

14

Hi William

Thanks for the kind words. It seems to me that we could define a mapping from openehr to iso 21090. I certainly designed it that way. The mapping is not perfect, but it’s good enough to be useful except for corner cases. I just have to find the time to write it up properly, but that seems an increasingly distant prospect at the moment.

Grahame

15

Hi all,

Given this discussion on ISO 21090 I would like to bring forward the following:

  1. Every international standard is and has to be based on political decisions: all member countries have to be accepting it and hence will want to get something specific out of it, or block too difficult parts.
    That is the way of standards making, in contrary to what a group of friends like in OpenEHR foundation can do. This has nothing to do with committees working in the implementation space or sitting at a table. It is how formal democratic voting goes. Not a perfect system we know, but apparently chosen above totalitarian approaches.

I do hate to bring this up, but in the entire rest of existence, all engineering (i.e. all creation of technical artefacts) is done by ‘totalitarian’ approaches. If you know the person who would travel on a plane built by ‘democracy’ rather than engineering, please introduce us…

This democratic development (inclusive of all parties concerned, and voting by members) has been and is still the case for ISO 21090.
The same democratic and transparant voting procedure by members is used in HL7 international (of course the membership is organised different from ISO).

  1. The use cases for ISO 21090 do come from different sources: an older basic data type standard from ISO, clinical use cases, CEN standards, in particular the one on archetypes (13606-2), AND HL7 among others. The resulting set is accepted by the ISO membership, and indeed the HL7 membership, referring to it as datatypes R2 (and facing an enourmous piece of effort and work to redo a lot of the models and messages due to the harmonisation). And under the JIC, also the CDISC organisation deals with this since ISO 21090 is part of the joint harmonisation work. I think the willingness of the different JIC partners to step beyond their traditional route and harmonise this formidable and fundamental work is the most important achievement in the last 25 years of international standards work. I would like to compliment Grahame in particular that he managed to get a useful, albeit say 96% “perfect” standard out of this.

I don’t have a problem with the fact that use cases have been researched, indeed that is an excellent achievement. I have a problem with the way the standard has been created on that basis; it tries to do way to much, incorporating all kinds of special cases that should not be included in the core generic data types standard. Such use cases can be accommodated in one or more separate ‘packages’ that show how to use the core classes for the specific purpose, and what extra classes are needed to formalise other data specific to the use case.

  1. No standard or specification can be perfect. In particular, Tom’s work might be closer to perfection than the ISO 21090, but that is hypothetically a matter of a percentage between 96% and 97.5% on a VAS of 0 - 100%. I personally are pragmatic, I need in Detailed Clinical Models and in HL7 v3 Care Provision message implementations about 20 - 30% of the ISO 21090, so do not bother about the rare use cases addressed.

no, no, no… wrong argument William! It is not about being on a sliding scale of good / better / perfect! This standard is in a different place altogether, ‘designed’ according to different permises, specifically that it should try and cover all known use cases in one standard. It is trying to do way too much, has numerous formal attributes and natural language guidelines not applicable to most use cases. It is built according to the wrong-headed HL7 notion of modelling which is: put everything in at the top/centre and profile it out later. Firstly this breaks basic rules of maintainability, encapsulation, etc, secondly, it is going to really damage the uptake and usefulness of this standard! Just like software and models based on the HL7v3 RIM, where NO TWO IMPLEMENTATIONS CAN COMMUNICATE, this will be the same.

  1. Core principle behind the standard is that you create a profile around it that allows you to implement it in your system, or your message, or your datawarehouse or whatever. There is usually no way to have it 100% ready for use. The example from the blog that Tom talks about, where ISO 21090 is mapped into their own CDISC models is almost perfect. That is the way to go. Yes it will include mappings from ISO time format to XML time format. But if that works well on implementation, at the exchange level you are compliant.

mappings are unavoidable with standards. But having to do this ‘profiling’ with every HL7 standard is nonsense - having to decide which attributes I don’t need, which ones I can set to 0 or Nil, or False, or some other special value… just think about the combinatorial complexity of all those decisions over an object with 10 data fields! ANd then multiply that by the number of organisations having to make those decisions.

  1. If you adhere to ISO 21090 / conform to it / there is always the option to limit your implementation set. E.g. refer to particular chapters or codes in ISO 21090.

particular chapters, particular classes, particular attributes, but only in specific circumstances… the ‘profiling’ work has to be done all over the place, so even when the standard is fully accepted, noone except HL7v3 message people can directly use it! It doesn’t even make sense in its current form for CDA! (And I forgot to mention it is full of CDA specific stuff which also makes no sense being in a supposedly generic standard).

  1. It looks from Tom’s objections that OpenEHR cannot adhere to data type standard ISO 21090. Is that a problem in the OpenEHR specifications, or is that a problem on political level: we do want to invent our own because it is closer to perfection? What I mean here is: if I create archetypes in OpenEHR spaces (there are about 25 in Dutch available pending other issues to be solved before releasing). And from this system I need to exchange HL7 v3 messages in the Dutch national switshboard space, will I be in trouble because the OpenEHR archetypes cannot handle even the basic ISO 21090 datatypes?

openEHR can handle all of the data types conceptually, that isn’t the problem. The mapping, just like for everyone else with a normal kind of object model, will be painful because of the irrelevant stuff in ISO 21090, and annoyances like TS.DATE, and numerous other details. But, much more importantly, which profile should openEHR map to? Some core profile? A 13606 profile? A CDA profile? A v2 profile? an NHS profile? The Sweden profile? How many mappings will we need? Remember, archetype designers don’t care about which specific way the archetypes might be deployed - in messages, on a screen etc, so any attributes specific to those uses won’t make sense. Do we need an ‘archetype’ profile of 21090?

Please have a look at this specification: openEHR Support Information Model - the section on ‘Assumed types’ shows how little openEHR assumes about underlying basic types. On top of that, it builds a core set of data types that have no attributes relating to messaging, null flavours, or obscure use cases. All of that latter is handled in contextually sensible places. Normal object models created according to normal design principles always end up like this. ISO 21090 doesn’t, because it follows the HL7 include-everything-then-profile approach.

  • thomas
16

Following this debate is for me more interesting than a tennis match, and, in my opinion, it is advantage-Beale.

Randy Neall

17

Tom, Now I know why HL7 has so much trouble. -- "just basic god practice.
" Shouldn't god be capitalized? I think HL7 needs to pay Tom a consulting
fee - for all the advice.

W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics

             Thomas Beale
             <thomas.beale@oce
             aninformatics.com To
             > openehr-technical@openehr.org
             Sent by: cc
             openehr-technical
             -bounces@openehr. Subject
             org Re: More on ISO 21090 complexity
                                                                           
             11/18/2010 06:38
             AM
                                                                           
             Please respond to
                For openEHR
                 technical
                discussions
             <openehr-technica
              l@openehr.org>
                                                                           
      >From the point of view of a clinical datatype implementer who has to
      write
      actual code, the ISO dataypes provide a level of detail
      that is both required and sufficient. They are definitely not
      "simple" in
      their definition but are mostly "simple"
      in terms of concept representation.
      The atom at one time looked "simple" and remains so in concept,
      though in
      fact having considerable underlying complexity.
      The level of detail required depends on your use case which seems to
      be a
      major contributor to your divergence of opnion.

I see this as one of the major problems of HL7 actually. It seems to think
that everything should be driven by use cases. This is not the case. The
general drive in all engineering and software development is to have layers
of highly reusable elements that work in all situations. Thus the design
concept of 'Integer' and 'String' in a programming language is not specific
to any particular used. Neither should the concept of 'codedtext',
'ordinal' or 'physical quantity'. The idea that a set of such data types
should be built not just for messaging, but apparently with features for
other more specific use cases is plain wrong. It is not good modelling.
Contextual (i.e. use-case specific) features should always be added in
specific classes / locations in models dealing with those specific use
cases.

The openEHR data types are designed like that - it is just basic god
practice. They can be (and are) used in messaging, storage, GUI, business
logic. Context specific features are modelled and coded where they are
relevant, not integrated into what would otherwise be completely generic
data types.

Not understanding this basic modelling practice has lead HL7 to produce
models that are very far from being easily implementable or reusable -
which is a real pity.

- thomas

18

So what does he win?

W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics

             Randolph Neall
             <randy.neall@veri
             quant.com> To
             Sent by: For openEHR technical discussions
             openehr-technical <openehr-technical@openehr.org>
             -bounces@openehr. cc
             org
                                                                   Subject
                                       Re: More on ISO 21090 complexity
             11/19/2010 01:08
             PM
                                                                           
             Please respond to
                For openEHR
                 technical
                discussions
             <openehr-technica
              l@openehr.org>
                                                                           
Following this debate is for me more interesting than a tennis match, and,
in my opinion, it is advantage-Beale.

Randy Neall

19

I knew that one wouldn’t get past… still, I could not in all conscience accept payment for so much unused advice over the years :wink:

20

Tom, As you have often pointed out, we do disagree but we are friends. In
aqny case, I enjoy the banter. At a minimum, it teaches me reserve.
Unfortunately, the issues go beyond technical and even philosophy. The
problem is when you put 500 people to writing standards, most of whom are
technical, the result demands compromise and that results in complexity.
The other choice is each will have its own standard. Not bad as long as it
is my standard.

W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics

             Thomas Beale
             <thomas.beale@oce
             aninformatics.com To
             > openehr-technical@openehr.org
             Sent by: cc
             openehr-technical
             -bounces@openehr. Subject
             org Re: More on ISO 21090 complexity
                                                                           
             11/19/2010 04:17
             PM
                                                                           
             Please respond to
                For openEHR
                 technical
                discussions
             <openehr-technica
              l@openehr.org>
                                                                           
I knew that one wouldn't get past.... still, I could not in all conscience
accept payment for so much unused advice over the years :wink: