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?
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.