ISO 21090: Underlying design propositions #1

Jul 16, 2011

In a previous post (see here), I promised to talk about the underlying design issues that are implicit in ISO 21090. ISO 21090 has attracted some strenuous criticism because of it’s underlying design characteristics. The primary critic is Tom Beale, though he’s not the only one. Complexity

The first design characteristic of ISO 21090 is that there is a huge requirements gathering network that leads to ISO 21090. It’s very comprehensive. A lot of people struggle with this - “But it’s sooo complex”. And it is. This is a value proposition, that if you invest in a solid implementation of the data types library, you’ll be able to reuse it again and again. This is a very evident aspect of ISO 21090: it was designed to be something you had to invest in to use - a heavy weight standard. If you run into ISO 21090 on the fly from some wider perspective, and have to implement a little bit of it, then it’s not going to make you happy; the density of the standard (particularly the ‘design by condensation’ discussed in the next post) is mostly going to be painful, and it’s comprehensiveness, along with the value that can be leveraged from a solid implementation - that’s going to be irrelevant to you.

So a lot of criticism of ISO 21090 is driven by this. It’s not usually well expressed, but does that make it invalid? Well, it comes back to the value proposition: which is better? For invested healthcare developers, particularly healthcare enterprise information system developers, who work slowly and thoroughly, the ISO 21090 value proposition is a winner.

Worst-Case Interoperability

ISO 21090 starts with the following words:

This International Standard provides a set of datatype definitions for representing and exchanging basic concepts that are commonly encountered  in  healthcare  environments  in  support  of  information  exchange  in  the  healthcare environment.

Also, it says:

This  International  Standard  can  offer  a  practical  and  useful  contribution  to  the  internal  design  of  health information systems but  it is primarily  intended to be  used  when defining external interfaces or messages to support communication between them

It’s become evident to me that we didn’t say enough about this, about how the for-exchange aspects of the design are not the same as how you design things for a system. One of the underlying presumptions of ISO 21090 is Worst Case Interoperability. The premise is that the systems exchanging data don’t share anything other than the data being exchanged right here and now. ISO 21090 is designed for that, and that’s what I meant when I said “for exchange”. In committee discussions, Dipak Kalra picked up that there was an issue and extended the language, but we didn’t go far enough.

The problem is that “for exchange” can mean for use between best mates Peter and George who share nearly everything, as between Alice and Bob, who can barely be civil to each other (see Worst Case Interoperability). ISO 21090 is built to allow Alice and Bob to work together, but at the cost of making things well designed for Peter and George. They can still make it work, but they pay a tax for that by the presence of things that are in the wrong place because they’d rather normalise them out of every exchange and put them where they belong.

A good example of this is the notion of the audit trail attributes built into the HXIT type. In a properly designed system, you don’t exchange references to past history of things in well designed systems; in a well designed system you’d have an audit trail (probably a 3rd party one, maybe based on IHE ATNA). But we didn’t make ISO 21090 for properly designed systems like that. We made it for systems that don’t need to share audit trails.

I think that this is the heart of Tom Beale’s criticisms of ISO 21090. He pretty much claims that worst case interoperability doesn’t work. And though I know it “works” (for a given value of work), it sure ain’t pretty. It may be that it won’t scale, and it certainly won’t scale as well as it might’ve if we designed it for a cleaner architecture (a la openEHR). But we designed it to work in the worst case. I wish now that we had extended the wording in the introduction to make this clear, because some enterprises are pushing system designers to use ISO 21090 directly inside their systems. It should be clear that I don’t think this is a good idea - ISO 21090 lives on the perimeter; I’d never have my internal application objects be actual ISO 21090 types - though they’d be based on it, and indirectly conformant.

This is part #1 of a series. - I’ve run out of time for now. Part #2 will cover Normalisation of Mix-Ins, and Design by Condensation, and describe a System Implementation Guide for ISO 21090 that Tom and I propose to write.