HL7 was originally designed as a standard protocol for exchange of financial and clinical data within an enterprise. The purpose was to allow disparate application vendors within a facility to acquire and send data into/out of their applications with a minimum of "custom programming". As Wes has pointed out, HL7 is very popular in small and large facilities alike, and I know of no healthcare clinical systems vendors that don't support HL7. V3 (the XML version) has been well received so far, and should start making inroads into the older v2.3.1 & V2.4 implementations. Even large organizations like Kaiser have standardized their internal interfaces around HL7.
We have been expecting HL7 messages to be a part of the "additional information" transaction (275), and Wes has confirmed that it is, indeed, featured prominently. The interesting question will be how the MSH will work within the ST. The MSH describes, among other things, the separators that are used in the message, and can allow a much wider range than X12... As to how HL7 will fit into the ebXML-CPP, I don't anticipate any problems as long as we're discussing V3 & beyond; I'm just no sure how we can fit in the older versions. What does concern me is the different perspective of the messaging itself. With X12 we're talking about entity-to-entity EDI messaging where the entities are bound only by external business relationships, and the transactions are intended to be batched. HL7, on the other hand, has always had as its domain inter-entity, and entity-to-entity exchanges where the entities are more closely associated (mostly, under the same umbrella corporation), and the messaging is intended to be asynchronous and near-real-time. While the difference may be subtle, is nevertheless important because of how message management is done. With HL7, there is usually an external interface engine (think "super translator") of some kind that not only translates / transmits / receives messages, but also manages the links & queues the messages travel on. 997s, TA1s and 824s don't exist, per se, in HL7 land, because the interface engine takes care of much of the transaction validation and acknowledgement. The closest HL7 equivalent is the application ACK. HL7 messages, by definition, contain discrete sets of financial or clinical data (within one MSH) from specific applications, and within a single MSH, all of the data goes to a single receiver (or the same message can be cloned to go to many receivers within the interface engine, or can be cloned and sent directly by the originator). There is no facility within HL7 for a single message to have different parts some of which go to one receiver, and some which go to another. The BHS is the closest thing to a GS, and while the FHS is the rough equivalent to an ISA, I'm actually not aware of anyone who uses it. Both the BHS and FHS have only sending application and facility, and receiving application and facility to contain identifiers (same as the MSH), and there are no standards for how those are used. I'll be very interested to see the treatment of HL7 within the 275 - it should help answer a lot of questions. Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240 -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 25, 2002 5:54 PM To: WEDi/SNIP ID & Routing Subject: Re: Provider to Provider Messaging Wes: I agree wholeheartedly that HL7 should be supported in our recommendations in a first-class manner. I assume that HL7 has the rough equivalent of the ISA and GS in the form of file (FHS), batch (BHS) and message header (MSH) segments. They each contain Sending and Receiving facility IDs, but there doesn't seem to be any standard for specifying the IDs. Can you elaborate on the facility ID as used in real life for routing HL7 messages between organizations? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Rishel,Wes" <[EMAIL PROTECTED]> To: "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]> Sent: Saturday, 24 August, 2002 07:11 PM Subject: RE: Provider to Provider Messaging Messaging that runs provider-to-provider and provider-to-public health agency is primarily concerned with clinical data. HL7 (www.hl7.org) has various standard transactions for sending lab data, clinical reports, test and therapy orders, and numerous other clinical functions. It is widely used now within large provider organizations (> 90% penetration rate) and between regional labs and providers and, in at least one case, between regional labs and a payer for care management. The NCVHS, operating under its authority under the HIPAA legislation, has recommended HL7 as the national standard in the US for most kinds of clinical data, while also recognizing the role of NCPDP and DICOM for certain kinds of clinical data. The Centers for Disease Control has an architecture for various surveillance application (NEDSS -- National Electronic Disease Surveillance System) that includes the use of HL7. HL7 has affiliate organizations serving about 30 countries and it is named by the governments of some countries in Europe and the Pacific Rim as the standard for clinical data. HL7 will also be featured prominently in the NPRM for claims attachments (provider to payer), although in that NPRM the transaction is a hybrid using an X12 transaction to convey the administrative data to relate the transaction to a claim and an HL7 transaction to convey the clinical data. HL7 is supported by all major vendors of clinical systems for large practices and hospitals in the US and all major integration broker vendors that target provider-side clients. HL7 offers two formats, one that is segment and delimiter based, similar to X12, has been an ANSI standard since the early 1990s. Its newer standards are based on XML and a clinical Reference Information Model. Some of the XML standards have already been certified by ANSI and others are in ballot now. A major theme of the annual HL7 plenary meeting in Baltimore on Sept 30 will be the use of HL7 to meet national mandates for the exchange of clinical data. It will include speakers from CMS, CDC, Great Britain, Australia and Japan. We in HL7 are following the work being done in WEDI SNIP for routing transactions over the Internet. We strongly believe that whatever is done for EDI (X12) transactions should easily work for HL7 transactions or, at worse, should work with minor modifications. We certainly hope that this group will create the necessary abstractions to support non-X12 payloads, as the ebXML Message Handling Service has done. Wes Rishel Board Chair, Health Level 7 Vice President, Research Area Director Gartner Research, Healthcare Alameda, CA 510 522 8135 [EMAIL PROTECTED] For client Inquiries: 203 316 1288, or [EMAIL PROTECTED] -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 24, 2002 3:31 PM To: WEDi/SNIP ID & Routing Subject: Provider to Provider Messaging What EDI transactions are exchanged between providers? I didn't notice any. Most are exchanged between providers and payers, with the possibility of the 837 and 269 exchanged between payers for COB stuff. Same thing for the NCPDP claims. You might have employer-sponsor to payer exchanges with the 834. And maybe some involving banks as intermediaries for the 835. But other than that? When you talk about provider to provider, are you all thinking of HL7? Even if there were to be any provider to provider EDI, the Healthcare CPP can handle this since it is completely symmetric. But unless there's something I'm missing, it doesn't seem there's going to be any EDI (unless it's HL7 clinical data) exchanged between providers - and thus no point in belaboring the point in the overview. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited. discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
