{"id":379,"date":"2016-04-14T18:09:42","date_gmt":"2016-04-14T08:39:42","guid":{"rendered":"http:\/\/blog.healthbase.info\/?p=379"},"modified":"2016-04-14T18:18:23","modified_gmt":"2016-04-14T08:48:23","slug":"hl7-and-the-ringholm-effect","status":"publish","type":"post","link":"http:\/\/healthbase.info\/blog\/?p=379","title":{"rendered":"HL7 and the Ringholm Effect"},"content":{"rendered":"<p>HL7 messages are the lifeblood of electronic health communication in many settings in many countries. In the healthcare sector in Australia, for example, they are ubiquitous in hospital settings for notification of patient Admissions, Discharges and Transfers and they are ubiquitous in both hospital and primary care settings for reporting pathology results to the ordering clinician&#8217;s or her organisation\u2019s clinical system. Millions of HL7 messages flow between systems \u00a0every day in Australia. The vast majority are based on HL7 version 2.3, 2.3.1 or 2.4. These standards are the <em>lingua franca<\/em> for healthcare messaging.<\/p>\n<p>However, their quality is often less than desirable. There is diversity in the way they are structured and represented from one system to another. The system interfaces that construct, route or process these messages are difficult and expensive to build and maintain. They are intended for point to point communication within a relatively confined and stable eco-system, rather than as components of a national infrastructure to support patient-centred care. Many of their well-known idiosyncrasies embody and epitomise the profound difficulty faced in trying to share information amongst heterogenious systems in healthcare &#8211; often dubbed \u201clack of interoperability\u201d. Some of this \u201clack of interoperability\u201d is due to shortcomings of, or ambiguity in the HL7 v2 standards. Some is due to ambiguity in implementation guides, or more often, conflict between various implementation guides and between implementation guides and their referenced standards. Some is due to developers&#8217; and implementers&#8217; ignorance or misapplication of the \u201cstandards\u201d. Some is due to the lack of standardisation of infrastructure upon which the messages depend &#8211; e.g. lack of standardised patient and provider identification infrastructure, or the lack of adequate value set infrastructure to describe clinical concepts.<\/p>\n<p>Such was the dismay at this lack of interoperability within the HL7 community that at the turn of the century a completely new version &#8211; version 3 was developed, based loosely ( and poorly ) on object-oriented methodologies. HL7 version 3 messaging, although adopted in some countries, emphatically failed to displace HL7 v2 as a preferred standard for healthcare messaging. I am not aware of any successful attempts to use it in Australia. Later, but still early this century, some HL7 members developed yet another health information communication standard &#8211; based on a document paradigm &#8211; CDA. HL7 CDA has had some take up in many countries, often lubricated by vast amounts of government money, such as via the Meaningful Use program in the USA or the national PCEHR in Australia. One of the major reasons for its adoption in those examples was \u00a0the hype created or swallowed by semi-literate, but influential technocrats who seriously believe(d) that the \u201cindustry-standard\u201d XML was an essential prerequisite for every piece of national health information infrastructure.<\/p>\n<p>In the intervening decade or more, millions of HL7 v2 messages continued to flow each day, through the arteries and veins of the Australian health system. Yes there are toxins in the blood, but very little government money has gone into analysing those toxins or into improving the quality in any way whatsoever.<\/p>\n<p>And now we have FHIR thrown into the ring &#8211; HL7\u2019s 3rd attempt at \u201cimproving\u201d upon the v2 messaging standard. But with FHIR, the hype has reached super-hype, possibly even ultra-hype levels. It has infected not only the semi-literate technocrats, but the technology-illiterate bureaucrats and money will pour in to support it\u2019s further development and adoption. Perhaps, eventually the investment might be worth it. But it will be at the expense of improving the existing messaging infrastructure and improving the quality of data so needed for clinical decision support and interoperability.<\/p>\n<p>Meanwhile, HL7 v2 messages probably still constitute today\u00a0close to 100% of electronic messages in those areas cited in the opening paragraph of this article. They will do so for many years to come. So it was with much interest and some trepidation that I headed up to Brisbane earlier this week to attend the first \u201creboot\u201d of HL7 Australia standards activities with an all day workshop that established 3 working groups to cover to-be-determined topics related to Medications, Patient Administration, and Orders and Observations. Despite the inevitable cohort of FHIR evangelists there were still a few agnostics in the room and a very welcome commitment from the organisers and Board for open, collaborative and technically supported processes. I came away cautiously optimistic. But not before declaring my concerns about a prior and current lack of a commitment to quality amongst many health informatics professionals both in Australia and overseas as embodied in the \u201cRingholm Effect\u201d. I should explain.<\/p>\n<h1>The Ringholm Effect<\/h1>\n<p>For much of HL7 v2\u2019s life, copies of standards have been difficult to obtain. Membership of HL7 International or a country Affiliate organisation was necessary. Documentation was scant. Some vendors produced interface specifications with perhaps an occasional sample message cited within a PDF or word document. To fill a void in understanding of HL7, some individuals and organisations have provided free explanatory material. For over a decade, the Netherlands-based HL7 consulting company Ringholm has contributed a substantial corpus of material to help a variety of people understand and adopt various HL7 standards. Much of this material has been made freely available on the internet with no strings attached, including a remarkable collection of recent videos of interviews and conference\/workshop sessions. Ringholm is to be applauded for this service to the health informatics community. But&#8230;<\/p>\n<p>Some published material contains errors. e.g.\u00a0<a href=\"http:\/\/www.ringholm.com\/docs\/04300_en.htm\">http:\/\/www.ringholm.com\/docs\/04300_en.htm<\/a> contains the following description and sample HL7 v2.4 laboratory report message fragment.<\/p>\n<pre style=\"font-size: 11px;\"><span style=\"font-size: 11px;\">The V2.4 representation of the use-case is a ORU^R01 message.\u00a0<\/span><\/pre>\n<pre style=\"font-size: 11px;\">The syntax encoding is based on the classic HL7 v2 syntax,<\/pre>\n<pre style=\"font-size: 11px;\">commonly referred to as the vertical-bar syntax.<\/pre>\n<pre style=\"font-size: 11px;\">The MSH (Message Header) segment contains the message type,<\/pre>\n<pre style=\"font-size: 11px;\">in this case, ORU^R01, which identifies the message type and the trigger event.<\/pre>\n<pre style=\"font-size: 11px;\">The sender is the GHH Lab in ELAB-3. The receiving application is the GHH OE system located in BLDG4.<\/pre>\n<pre style=\"font-size: 11px;\">The message was sent on 2002-02-15 at 09:30. The MSH segment is the initial segment of the message structure.<\/pre>\n<pre style=\"font-size: 11px;\"><span style=\"color: #815e4e;\"><strong>MSH|^~\\&amp;|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4&lt;cr&gt;\u00a0<\/strong><\/span><\/pre>\n<pre style=\"font-size: 11px;\"><span style=\"color: #815e4e;\"><strong>PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||153 FERNWOOD DR.^<\/strong><\/span><\/pre>\n<pre style=\"font-size: 11px;\"><span style=\"color: #815e4e;\"><strong> ^STATESVILLE^OH^35292||(206)3345232|(206)752-121||||AC555444444||67-A4335^OH^20030520&lt;cr&gt;\u00a0<\/strong><\/span><\/pre>\n<pre style=\"font-size: 11px;\"><strong><span style=\"color: #815e4e;\">OBR|1|845439^GHH OE|1045813^GHH LAB|<\/span><span style=\"color: #007d03;\">15545^GLUCOSE<\/span><span style=\"color: #815e4e;\">|||200202150730|||||||||<\/span><\/strong><\/pre>\n<pre style=\"font-size: 11px;\"><strong><span style=\"color: #815e4e;\">\u00a0555-55-5555^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||||||<\/span><span style=\"color: #381880;\">444-44-4444^HIPPOCRATES^HOWARD H^^^^MD<\/span><span style=\"color: #815e4e;\">&lt;cr&gt;\u00a0<\/span><\/strong><\/pre>\n<pre style=\"font-size: 11px;\"><strong><span style=\"color: #815e4e;\">OBX|1|SN|<\/span><span style=\"color: #821127;\">1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER\/PLAS:QN<\/span><span style=\"color: #815e4e;\">||^182|mg\/dl|70_105|H|||F&lt;cr&gt;<\/span><\/strong><\/pre>\n<pre style=\"font-size: 11px;\">The PID (Patient Identification) segment contains the demographic information of the patient.<\/pre>\n<pre style=\"font-size: 11px;\">Eve E. Everywoman was born on 1962-03-20 and lives in Statesville OH.<\/pre>\n<pre style=\"font-size: 11px;\">Her patient ID number (presumably assigned to her by the Good Health Hospital)<\/pre>\n<pre style=\"font-size: 11px;\">is 555-44-4444.The OBR (Observation Request) segment identifies the observation<\/pre>\n<pre style=\"font-size: 11px;\">as it was orignally ordered: 15545^GLUCOSE. The observation was ordered by<\/pre>\n<pre style=\"font-size: 11px;\">Particia Primary MD and performed by Howard Hippocrates MD.\r\nThe OBX (Observation) segment contains the results of the observation: 182 mg\/dl.<\/pre>\n<p>&nbsp;<\/p>\n<p>There are, in fact, significant errors in the above message. Quite possibly, this was copied from a real system. I would not be surprised. Either way, a quick check by an HL7 v2 <em>expert<\/em> should have uncovered some of the errors and led the author to either correct or comment on them. Not only has it not been corrected after 9 or more years, but the author has repasted this faulty message into another paper \u00a0describing how HL7 v2 messages could be mapped to FHIR. I\u2019ve seem similar suggestions by other bloggers such as David Hay, who originally cited the same faulty message.<\/p>\n<p>Readers at this stage probably think I am over-reacting to what, in many circles would be considered just an authoring oversight. No-one would complain if a blogger posted some faulty code C# or Javascript code on a web-site.\u00a0But this is much different. Firstly, there aren\u2019t many alternative sites where sample messages are available.\u00a0Secondly, in this case \u00a0it is symptomatic of a culture that has long pervaded the cottage industry of health informatics. One where most of the focus is on technology development rather than clinical meaning or implementation concerns. One where standards development stops and implementation is someone else\u2019s concern. One where nowadays XML or JSON or Java or C# or the meaning of &#8220;Health Concern&#8221; dominate rather than a concern for better patient care. One where greenfields take precedence over brownfields. One where the abstract is more palatable than the real world.<\/p>\n<p>This one example of HL7 v2 has been repeated <em>ad nauseum<\/em> in books on health informatics; in university lecture notes; on the HL7 Intl wiki; and many other places. The faulty message itself has \u00a0been used for testing various HL7 code libraries and floats around on blogs and github with ne\u2019er a comment about it\u2019s faults. Nobody seems to notice or care. This one v2 message, and probably its CDA counterpart and its FHIR counterpart would make an excellent subject for discussing the obstacles \u00a0to interoperability. It is not just this message that is faulty. Faults exist in many of the examples I look at. Those same faults translate to faults in real messages. Some of these faults last for years. Often the more severe ones are detected in implementations and slowly \u00a0resolved, often by expensive or fragile work-arounds and hacks. There is not the money nor the proper understanding nor proper leadership\/governance to do otherwise. The pain is often born by vendors or system support personnel for the receiving systems or by the burgeoning integration teams needed to monitor and map defective fields or values for each and every participating system. Interoperability by manual intervention.<\/p>\n<p>When I look at sample CDA messages I often see symptoms of the same culture. Because you can\u2019t meaningfully view the computable entries of CDA documents we end up with faulty samples scattered around the web. Even the ONC, who professes to care about interoperability posts faulty CDA samples. I looked at the first one in over 6 months and saw a number of faults at\u00a0<a href=\"https:\/\/github.com\/jddamore\/HL7-Task-Force-Examples\/blob\/master\/RESULT_BMP_with_Tropinin.xml\">https:\/\/github.com\/jddamore\/HL7-Task-Force-Examples\/blob\/master\/RESULT_BMP_with_Tropinin.xml<\/a>\u00a0referenced as the approved CDA Example Task Force sample.<\/p>\n<p>In the past the official FHIR site had the same problem. Whilst Grahame Grieve has tried very hard to detect errors in the examples cited on the standards site, the snippets of sample resources scattered around the web often contain errors. This problem is likely to balloon as more and more budding innovators incubate their own local resources.<\/p>\n<p>Yet as much as the proponents of CDA or FHIR may wish otherwise, the bulk of health information in the real world is carried in HL7 messages. Those people who suggest that these messages could be readily mapped to CDA or FHIR in many cases simply do not understand the nature of the problem. If you can\u2019t see the issues in the above message you cannot understand the nature, nor scale of the interoperability problem.<\/p>\n<p>We cannot clean the toxins out of the blood by giving everyone a blood transfusion. We have to understand the physiology of the health information ecosystem. We have to have appropriate tools and standards to analyse and diagnose. We cannot do that just with faulty text book samples or by hand knitted cadavers.<\/p>\n<h3>Appendix<\/h3>\n<p>Here is the list I have garnered of the Health Informatics books citing the Ringholm sample message, some with attributions thereto. I\u2019m happy to add to this if readers know of others.<\/p>\n<ul>\n<li>Braunstein: Practioner\u2019s Guide to Health Informatics Pg 58<\/li>\n<li>Hutton: Pediatric Biomeidical Informatics: Computer Applications in Pediatric Research P 29<\/li>\n<li>Hovenga: Health Informatics: An Overview Pg 139<\/li>\n<li>Duplaga et al Transformation of Healthcare with Information Technologies Pg 327<\/li>\n<li>Trotter &amp; Uhlman Meaningful Use and Beyond: A Guide for IT Staff in Health Care Pg 174<\/li>\n<li>Trotter &amp; Uhlman Hacking Healthcare: A Guide to Standards, Workflows, and Pg 174<\/li>\n<li>Borko Furht, \u200eAnkur Agarwal Handbook of Medical and Healthcare Technologies Pg 511<\/li>\n<li>Borko Furht, \u200eArmando Escalante Handbook of Cloud Computing &#8211; Pg 559<\/li>\n<li>Taktak et al &#8211; 2013 &#8211; Clinical Engineering: A Handbook for Clinical and ..<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>HL7 messages are the lifeblood of electronic health communication in many settings in many countries. In the healthcare sector in Australia, for example, they are ubiquitous in hospital settings for notification of patient Admissions, Discharges and Transfers and they are ubiquitous in both hospital and primary care settings for reporting pathology results to the ordering [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[55],"tags":[20,51,18,41],"class_list":["post-379","post","type-post","status-publish","format-standard","hentry","category-safety-quality","tag-hl7","tag-safety","tag-semantic-interoperability","tag-standards"],"_links":{"self":[{"href":"http:\/\/healthbase.info\/blog\/index.php?rest_route=\/wp\/v2\/posts\/379","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/healthbase.info\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/healthbase.info\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/healthbase.info\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/healthbase.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=379"}],"version-history":[{"count":2,"href":"http:\/\/healthbase.info\/blog\/index.php?rest_route=\/wp\/v2\/posts\/379\/revisions"}],"predecessor-version":[{"id":381,"href":"http:\/\/healthbase.info\/blog\/index.php?rest_route=\/wp\/v2\/posts\/379\/revisions\/381"}],"wp:attachment":[{"href":"http:\/\/healthbase.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=379"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/healthbase.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=379"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/healthbase.info\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=379"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}