What is HL7 programming? (Part 1 of 3)

What is HL7 programming? (Part 1 of 3)

Hi,

I know what the HIT gurus are thinking about this topic's title. But really, I do have to listen to this question quite frequently.

Not only do I receive this inquiry from the folks that are trying to get involved in healthcare IT for the first time, but for many years I have also heard of it from recruiters and head hunters, "Are you an HL7 programmer too?", is typical in their screenings. Of course, hesitantly I answer "yes!", or risk losing the opportunity to further discuss what might end up being a lucrative contract or a nice career job.

"HL7 programming" is a misnomer. HL7 is not a programming languange, like C# or Java are. HL7 in itself is not a standard either. HL7 is a standard developing organization (SDO).

HL7, the organization, has published several standards, among them:

• HL7 Version 2.x series (currently they list only versions 2.3 through 2.6),
• HL7 Version 3.0,
• Clinical Context Management (CCOW),
• Arden Syntax,
• Clinical Document Architecture (CDA),

HL7 Version 2.x series are the most popular of their standards. They have been adopted by an overwhelming number of healthcare delivery organizations in such a way that some reputable studies estimate the adoption rate in the US is over 90%. HL7 Version 2.x series are often referred to collectively as an interface messaging standard since they do consist of a specification formed by a myriad of well-structured and well-organized field delimited messages. The messages are defined by abstract templates which aid in their implementation. This messaging standard which was first released in 1987 under version 1.0 has evolved significantly but it initiated much before other popular industry formats such as, XML, ever existed, or were widely known as they are today. The latest release from the version 2.x series was HL7 Version 2.6 which was approved as an ANSI standard October, 2007.

HL7 Version 3.0 is based on the HL7 Reference Information Model (HL7 RIM) which is much more complex and it is also based on XML. It uses the RIM and an object-oriented methodology to create messages.

This version has had a difficult time being adopted in the United States. Europe, having a smaller Healthcare IT infrastructure than the US, has been able to adapt to it with much more ease. In my opinion it was a smart decision not to move forward with Version 3.0 since it was defined much before the XML standard evolved and there are many "lessons learned". We also have mature "use cases" and "best practices" acquired from other industries and that we weren't quite aware of years before. Version 3.0 should undergoe scrutiny and reinvented, maybe by creating Version 4.0, which should be simpler so that it can be easily adopted and implemented. Until this happens I doubt that it will gain significant momentum.

I have architected, developed, and encountered many implementations of HL7 Version 3.0. Somehow they remind me of the early days of DICOM implementations in which each vendor had a very different interpretation of the DICOM standard. Some of these DICOM implementations continue to be a cause of difficulties when integrating equipment from different vendors. Many healthcare delivery organizations decided to go in the direction of "Single Vendor" solutions due to the complexity involved in integrating heterogeneous environments.

To be continued (Part 1 of 3) ...

The EHR Guy

HIMSS09 ...

HIMSS09 ...

Hi,

HIMSS09 is a little over a week away. Held at the same ol' location where RSNA has been held for many years, the McCormick Place in Chicago, Illinois starting Sunday, April 4th and ending Wednesday, April 8th.

I hope it isn't as cold in Chicago as it was when I travelled there to attend the RSNA event last year. Anyways, Chicago is a nice city and I enjoyed the whole event. I stayed at the Chicago Marriott Downtown Magnificent Mile which is nearby everything. I even had dinner at President Obama's favorite italian restaurant and I won't say which it is since I'll leave that to your own discovery.

This year will be slightly different than others since two major vendors: MEDITECH and Cerner, have both cancelled their attendance. This is unfortunate because MEDITECH is a cornerstone of healthcare IS and albeit they are a very conservative company they do tend to continuosly bring innovations and improve their product line. Cerner having been a major industry player for many years will also be missed. I am unaware of other cancellations but from what I have gathered from other colleagues, most companies, at least the ones they work for, are sending the minimum amount of people as they can.

But there will definitely be other big companies showing off their new products, technologies, ongoing projects, and ideas. Microsoft is one of them. Microsoft is really gaining momentum with their 2 primary healthcare focuses: Microsoft Amalga and Microsoft HealthVault. I am more interested in their UIS (Unified Intelligence System) at this moment since I believe it will revolutionize how healthcare information systems will be developed in the future. The UIS, although I don't know too much about it, I understand that it is a platform. A platform says many things and I'll wait for details that I'll gather when I'm at their booth. I'll flip my tag so that they can't recognize me and I'll carry my stethoscope around my neck (by the way I'm not a physician!) that way they'll spill it all out. Since I used to be a sales engineer I know how to treat that breed. You can find more information about Microsoft's HIMSS 2009 Conference at the following site: http://www.mshimss2009.com/. Microsoft has been exceptionally good to me so I will give them free advertisement. :)

Google, although not being as lavish as its rival, may have some surprises as well. They have only mentioned their free consumer-oriented personal health record (PHR).

I am sure there will be a lot of enthusiasm among attendees since healthcare IT is one of the hottest topics in the current political agenda. We'll see a lot of folks promoting themselves as the solution to the healthcare interoperability challenge.

On Tuesday I will be attending the roundtable discussion tentatively titled, "Meet the Bloggers". I was invited by HIMSS so I guess my blog site is achieving its intended effect. This round table is taking place as part of a new exhibit called "HIMSS Tech Lab", accordingly. Other bloggers are invited as well according to their invitation and I'm just spreading the word.

I hope to see you in Chicago!

The EHR Guy

Are We That Different?

Are We That Different?

Hi,

Lately I've been receiving many inquiries from folks from other IS / IT domains (e.g. financial, insurance, retail, etc.) that want to jump into the healthcare IS/IT bonanza that is about to commence. One thing that amazes me is all the misconceptions many have of our domain.

In some ways this dissapoints me, since I have been loyal to this domain for over 20 years, and despite how "greener the grass" may have appeared to be on other sides of the fence, I along with others have remained firm.

On the other hand, we do need all the help we can get since there is a lot of work that has to be done. So we, the strange healthcare IT breed, will have to welcome this massive influx of newbies.

But first lets get a couple of things straight: First, healthcare IS / IT folks DO KNOW about modern technologies, we are not limited to MUMPS programming and AS/400s. SOA, ESB, Web Services, REST, SOAP, SSO, etc. are part of our repertoire.

We are also starting to use titles such as: solutions architect, enterprise architect, etc. And yes, we also understand what Business Intelligence and XML are all about.

Second, we don't have different standards because of our supposedly capricious nature. In the healthcare domain, due to an imperative necessity we began developing integration standards long before other industries attempted it.

Initially, back in 1983, we created DICOM (Digital Imaging and Communications in Medicine), a standard for the distribution and sharing of images between a myriad of medical devices and IT equipment in hospitals and other healthcare delivery organizations. DICOM for many years was way ahead of its time. Major multinational companies were developing products with this standard, among them: Agfa, GE, HP, Philips, SIEMENS, TOSHIBA, etc.

Then, further down the timeline, in 1987, we founded HL7. One of HL7's missions was to create a messaging standard. This messaging standard would allow a myriad of legacy applications to be able to communicate with each other using a common protocol. It took many years, 21 so far, for this standard to be almost totally adopted by the industry. Currently, HL7 has been adopted by approximately 95% of the hospitals in the United States alone. You can see that HL7 existed long before XML was ever even thought about. Nevertheless, HL7 began working with XML technology since the formation of the SGML/XML Special Interest Group since 1996. Therefore we have 12 years of experience with XML.

In our domain there is a big difference in that we have to deal with many legacy applications that are dissimilar to those of other domains. Similar to the financial industry having to deal with legacy COBOL applications, we have had to maintain, support, and integrate many legacy applications, in COBOL as well as in many other supposedly "dead" languages.

The information we have to manage and integrate is also very different. It is also tenfold * tenfold more complex. While other domains only have to deal with credits and debits and a little demographic data, we have to deal with those as well, and additionally with laboratory test results, medical images, voice transcriptions (both textual and audible), documents as images, pathology data, pharmacological information, etc. Some of my readers will find this list short, so please pardon my omissions. A digital health record comprehends all the aforementioned types.

So before asking us why don't we use XML, solve an integration problem with a web service, or use standard industry business intelligence tools please delve a little further into the "nature of the beast" that we are dealing with. We aren't that different, but the "beast" is.

The EHR Guy

---