When to Profile ISO 21090

Mar 9, 2011

This post is a follow up to discussion in an Australian Standards Committee (IT-14) yesterday over whether Australia should profile ISO 21090 for use in Australia Direct vs Indirect Conformance

The first question is, what kind of profile? I have worked with several organisations to profile ISO 21090 now. Each organisation is seeking to achieve a different thing for different reasons. The first and fundamental question is whether to go for “Direct conformance” or “Indirect conformance”, both of which are defined in the standard itself.

In Direct Conformance, the profile uses the semantics of the data types directly - the same classes, the same attributes, the same invariants. (And where relevant, the same wire format in XML for exchange.) All the profile does is add new invariants, primarily of the type “class A is not to be used” or “Attribute A.name is fixed to nullFlavor NI” (i.e. not to be used)

In Indirect Conformance, the profile defines a different set of data types altogether (or references ones that already exist), and defines mappings in and out of the data types defined in ISO 21090. This is obviously a looser process, and it’s hard to assess thequality of the mappings, but it’s also extremely useful.

When deciding whether Australia should have a profile, the first question is, which kind of profile. Because the driver here is the existence and possible adoption of ISO 21090, there’s no benefit in profiling it to a different set of data types. Instead, the point is to make adoption in Australia easier, by removing requirements that do not arise in Australia and some possible committee idiocies. So Direct Conformance it is.

Dangers of Profiles

It’s always tempting to profile a standard like ISO 21090 aggressively. It contains a huge load of complexity in the types and attributes for which the requirements are not immediately obvious. Yet nothing has been added to ISO 21090 for which there is no real requirement. It’s just that many of these requirements are not immediately obvious, especially early on in a given project or context where ISO 21090 is going to be implemented. (There’s a variation of this argument to do with criticisms of how the data types are designed, which will be discussed below)

So almost everybody who sets out to profile ISO 21090 cuts too much out, and then find that they have to re-introduce stuff later. In a project, that’s actually a pretty good approach, as long as you reserved the capacity for changes in this regard later. However the bigger the project, the more likely it is to behave like a waterfall, and the more likely this will be a problem. When you start talking about a national profile as a full standard, on a usual standard turn around time… you’ve got a problem.

The real problem is that if you prohibit attribute X.y, so that it can’t be used, and then it turns out that the prohibition was based on an incomplete understanding of requirements, then some implementer out there is going to have a problem. It’s a sure bet the implementer is not deeply versed in standards, that he’s in a tearing hurry under much pressure, and that technical conformance to the standard is easier to assess than doing something sensible. So they’ll find some other way to do something, and you’ve got a problem, because that sure won’t be interoperable.

This is not to say that profiles are bad - just that you have to be real careful, and only eliminate requirements that are truly out of scope. So what requirements are truly out of scope of an Australian standard? There’s two sets of requirements that I think might be completely out of scope for a full Australian standards: the stupid ones, and the ones that are known to come from other cultures about which we aren’t interested. Stupid Requirements in ISO 21090

Yes, there are some. It’s inevitable in any committee based standard. All you can do is hope that they are kept to a minimum. I’d nominate this list:

  • PQ.translations - these are just a mis-understanding, and I’ve not seen them used anywhere
  • NPPD. If the infomation is that complex-  more structure is needed.
  • HXIT.controInformationRoot+Extension properties. Maybe the requirement is bogus. It’s hard to know.

Again, this is not about stupid design, this is about stupid requirements. Design is discussed below.

Requirements from other Cultures

There’s some very specific things - mainly in names, and a little in address, where some very culture specific things are represented. For instance, Scandinavian middle names. Some of these things could be ruled out of scope here in Australia.

The first question is whether it’s valid to do that - after all, people from these cultures do visit Australia regularly (Australia has about a 1% population turnover weekly according to customs stats). So if they visit, why not handle their names and addresses properly? The answer to this is that some of the name markups are not so important when describing the actual name, but in driving system behaviour, and we don’t have the cultural context in Australia to have systems that work like that.

We could possibly eliminate them, then. It’s a small victory, but it’s something. Here’s my list:

  • AddressPartType.CPA and PRE
  • AddressUse.ABC, IDE, SYL
  • EntityNamePartQualifier.NB.
  • EntityNameUse.ABC, IDE, SYL

That’s it. It’s not a long list. Everything else in the data types is there for some reason or other, and we couldn’t just rule them out on an Australian wide basis.

Other points

  • One vendor wanted to know whether an Australian profile would be good for Australian industry. Well, that cuts both ways. The more impact it has, the more it prevents Australian industry from competing overseas, and the more it protects Australian industry from competition here. Pick your poison (but since the profile couldn’t say much, I don’t think it matters much either way)
  • There’s a prospect that an Australian profile could make some attributes mandatory. For instance, the new II attributes scope and reliability. There’s arguments running in HL7 that they should be - but what do you do if you don’t know. You have to be real careful making things mandatory, and when I scan ISO 21090, I don’t see any candidates
  • There’s all sorts of rationales for profiling ISO 21090 for particular projects. That’s a good idea.

Design

When I set out to write this post, I said I’d address design based issues, as well as requirements ones. Well, I’ve got to 1000 words, and I’ve run out of time. That’ll have to be another post for another day - I’ll discuss the relationship between the ISO 21090 design, system architecture, interoperability, and bad system architecture, along with the Systems Implementation Profile for ISO 21090 that Tom Beale and I are intending to work on.

update: IT-14 decided that an implementation guide for ISO 21090 would probably be more appropriate than a full profile, but final decision awaits further developments - mainly in NEHTA specs.