Monthly Archives: March 2011

HL7 standards V2 vs V3: a letter to “S”

So, though a long process I don’t care to think too much about, I got dragged into a discussion with an anonymous HL7 member (“S”) over on Barry Smith’s HL7 Watch blog. It’s hard to engage with someone you know anonymously, and then the discussion suddenly (and unexpectedly) broke out into useful content. But it was getting unwieldy responding through Barry’s blog, so I chose to make a longer response here.

So, “S” asks me a series of questions. I’m going to quote them here and respond:

I can understand, and see, that Grahame is a true V3 loyalist (I respect that), but unfortunately to the degree that he is perhaps unable (or unwilling?) to look at its fundamental flaws.

Well, I might be co-chair of MnM, but I’m not really a true believer. In almost everything people do (with the possible exception of banking 😉 there’s some merit. But since everything is done by people, everything also has at least some flaws, and I’m not unwilling to look at it’s flaws. And you ask a series of good questions below, ones that I wish we spent more time looking at.

Thank you Grahame for agreeing to listen to my critique:Here are a few issues that I have with the fundamentals of V3 messaging (CDA not included) vis-a-vis the V2.6 standard.

Uh? CDA not included? It’s not fair to exclude the single most useful part of v3 from the discussion of whether v3 is useful or not. But ok, we’ll confine the discussion to V3 Messaging only, as long as everyone is aware that this is less than all of v3. (And you don’t even grapple with the biggest issue with v3 messaging, the reason why I don’t think it will get any more adoption as it is, which is that the behavioral aspects are deeply broken)

(1) One of the strong points of V3 is conformance. Why does V3 bring about ‘Conformance’ in an extremely opaque, convoluted and complex process (using multiple tools which are proprietary (some open source, some commercial)), when V2.6 can do the same with just use of the standards document and an ASCII editor?

Everything about V3 is complex, layered, and opaque. Let’s agree to that straight away. It’s a direct and inevitable outcome of “Design by Constraint”. Design by constraint is a wonderful process for ensuring semantic design consistency and engineering implementation confusion. I have a powerpoint presentation on that subject that I have given to many HL7, ISO, and OMG standards designers. I should probably turn it into a blog post here too.

And let’s also straight away deal with the complexity argument. So many people simply say, “V2 is less complex that v3, so it’s better”. It’s not so simple. If it were that simple, then we should expect to just use text – it’s even simpler, and we can do everything with an ASCII editor (or, perhaps, a Unicode editor ;-)).

The question we should be asking about where something lies on a simplicity/complexity gradient is whether the outcome meets the purpose. In v2.6, you can develop conformance specifications with an ASCII editor, sure, but turning those into test tools capable of assessing whether a message meets it’s conformance statement is the business of expensive testing services such as AHML, where as in V3, you can get an open source tool to do it for you (I wrote it myself, with support from UK NHS and Canada Health Infoway).

So it’s not true that v2.6v has the same conformance outcome. In fact, to start getting the same outcome, you need to start with messaging workbench, and a much more structured approach, which comes with greater complexity. And then the approaches start to converge – but v2.6 will never offer semantic consistency because of it’s history and shallow design structure.

(2) As a clinician I require my clinical message to be transferred accurately to the recipient. How does V3 do a better job as compared to V2.6? (Please do not bring in points like conformance, security, permissions, confidentiality and encryption, since all of this can easily be configured in V2.6)

Err, easy? I suppose but there’s no standard way to do it. But agree, that’s not the core subject.And now I have a problem. I’ve never implemented a clinical message using v2.6. Nor have I implemented one using v3. I’ve used v2.4 and I’ve used CDA – so I could compare them with confidence, but that’s not the same question.

I think that in principle, v2 suffers terribly from it’s own history. There’s no layering of design, just a single level (in spite of my comments above about layering, absence of layered design is also a terrible way to do design). And v2 has been permanently backwards compatible, which means it’s a hostage to past mistakes. The two message types I have the most practical experience in are ADT messages and observation messages. The core segments (PID, PV1, ORC, OBR, and OBX) are filled with a profusion of fields that are only sometimes well defined. Many are ignored in most implementations, and most are misused in most messages. In fact, I suspect that the simplicity of presentation of v2 makes it worse, because implementors dive in and just do stuff, without having to learn what community consensus about how to use them is. (You might say that it’s greatest strength is also it’s greatest weakness).

This was graphically illustrated to me in a recent round of work undertaken by the Australian MSIA to resolve why we have such troubles with clinical messaging here in Australia. Here in Australia, we have a very solid ecosystem that delivers diagnostic service reports to clinicians, and to a lesser degree, disacharge summaries (& referrals) from clinician to clinician. There are several vendors who spend inordinate amounts of time fiddling with the message content to make a random sender communicate with a random receiver. I hope to make a post later on the MSIA conformance profile that arises out of this work, since there is much to learn from it – but it’s not complete yet.

So asking whether V3 is better than v2 is actually setting the bar rather low. Does v3 clear the bar? I don’t know. CDA certainly clears it easily – but it does have a narrower scope. v3 generally – it has an ocean of semantic consistency features built in, but carries this heavy load when it comes to engineering.

(3) V3 XML vis-a-vis V2.6 XML is massive and convoluted. How is this better?

XML is good because it is self describing. So More tags =more self description. Better!

No, seriously,the massive and convoluted is a direct consequence of design by constraint. And I don’t know anyone who’s actually using v2.xml, though I’m sure some people are. So why compare to that instead of the vertical bar we now and love?

a) The human readable component is so deeply buried in the code that it requires super human effort to extract it manually (even for a small message) so is it really human readable?

Same for HL7 v2. In spades. CDA forever 😉

b) Coming to the next part, machine readable information – the effort required to human-engineer an application to ergonomically extract information from clinical data (as required by V3) puts a huge load on the end user (clinician).

um? Why is this required by v2 and not v3? I think that this is because particular messages are designed to a different philosophy, and I don’t see why particular v2 message implementations should be different.

There is certainly a desire for more structure and more coding. And where else is this going to come from but the clinician? But this impost on the clinician is not for the sake of the IT Systems, but for the sake of the downstream outcomes humans can derive from leveraging the structure and codes. I’m not sure whether the benefit will truly prove to exist, but let’s not blame v3 for this. v3 has more complexity than v2, but it also has a lot more consistency and this makes a real difference.

End of day there are other methods by which data can be extracted from free flowing text for BI, CDSS and EBM (evidence based medicine). So why complicate?

Yes, I wonder that myself. V3 does not require all this structure and coding – but it was certainly designed to make it possible (unlike v2). There’s a solid community who want that. So v3 is better for their intent. In as much as you disagree with that intent, you’ll dislike that “feature” of v3.

(4) V2.6 can easily transport any kind of media with lower overheads as compared to V3. So why V3?

what lower overheads? I don’t know what they are. Do you mean, transport other media in content? or do you mean transport content across media?

(5) V2.6 can, from the end user point of view, transfer the same clinical content as robustly as V3. So why V3?

My experience shows that this is only true for a particular end user point of view. For the sum of end user points of view, v3 is much better (more rich, more robust, can meet more use cases) than v2. The increased robustness of v3 comes from the tighter specification. For some use cases (see previous section), this increased robustness is neither here nor there.

Which is one problem with this debate – it’s context free. V3 is not meant to solve the same problems as v2. And partially your comments are simply a restatement of that, no? “v2 meets my use cases, why use v3?”

(6) V2.6 messages can be coded by nothing more than Notepad and the standards document.

Y. So can v3 messages. Not fun though!

Why this complex process in V3? Since in the end after all this goes through the grinder (Funnel the RIM to a DMIM (actors, story boards, acts, moods….) to a RMIM, CMETs yada, yada, yada, run it through automated tools) we are finally handed over ready message templates for each domain – as is present in V2x.

Yes, as is present in v2. Except these things are not the same. What v3 produces have many layers of quality built into them that v2 doesn’t.

This message (from the end user point of view) is nothing more than the equivalent of a ready made message from one of the chapters of the V2.6 standard (it is as as simple as simply selecting the appropriate V2.6 message from the standard and going ahead). So why would one waste time, effort and scarce manpower to do the same thing in a more complex way?

Because it’s a better outcome. At this point I should come clean and say, I’m not sure it’s better enough. But it’s certainly better in important ways to do with consistency, and you can’t just ignore that. (Really, at this point, I should spend another hour writing up all this consistency with actual examples, but I’m out of time.)

(7) Has a study been done on the cost overheads of V3 (in $ terms) vis-a-vis V2.6 (including conversion of data, maintaining of 2 standards, training, new apps,etc)? If so what is it and are the costs commensurate?

I don’t know of one. And it would be hard because you’d be comparing apples and some type of bread.

(10) I am sure you agree that the more the parts, the more are the chances of a breakdown (or error or worse still a SILENT error). Complexity, if it improves outcomes to the end user, would be worth the risk. But how does V3, realistically, improve outcomes for the enduser (as compared to V2.6)?

Really, I should’ve answered this point first, cause now I’m out of time. Another post, maybe. Or maybe I can get Lloyd to answer this one.

(11) Do you think it would be a good idea to wrap up all the RIM based complexity into a black box (only to be handled by the WGs) and simply present ready message templates to the end user in the form of a ‘V3Simplified’ Standards Document, something similar to a V2x document? (This is, in any case, gradually happening.)

Yes, I do. And I’m involved in a number of the parts of it gradually happening. Design by constraint has it’s strong points. But we need to internalize it’s weaknesses as well as it’s strong points, instead of externalizing the costs. That would certainly help greatly with the problems of V3 you’ve asked about – which are very real. I’ve argued against them, but that doesn’t mean that your points aren’t real and don’t have at least some merit. Most of all, v3 has real advantages, but it’s too hard to implement.

One last point: “S”, did the V2/V3/CDA taskforce speak to you?

Grahame

p.s. A final note about anonymity: I decry the fact that “S” feels the need to be anonymous. HL7 needs to be an open organization that runs on merit alone, where all the contributors are free to express their beliefs. There’s some jurisdictions around the world, where having chosen a particular HL7 standard, they become intolerant of further criticism and people who speak out suddenly lose their jobs. (and also the reverse: when some jurisdiction reluctantly finally commits to one of the choices, a disaffected party or two start criticizing the decision publicly but anonymously in all this wonderful new free media).  I sure hope that no member of HL7 itself supports either of these processes since they will eat away at HL7’s essential qualities.

When to Profile ISO 21090

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.