|
From the June 2002 Issue Building Reliability Into Your Digital Telemetry System HIPAA Watch: HL7-What You Need to Know
|
HL7 – What You
The Health Insurance Portability and Accountability Act (HIPAA) encompasses a range of operational, training, policy and technical issues. As an HIS professional, you are well aware of the changes and challenges you face in implementing HIPAA. Hidden in the details is another, perhaps unnoticed catch: the expected requirement for using the HL7 (Health Level Seven) standard to structure patient data submitted in support of payment claims. The HL7 requirement, when enacted, can represent an unexpected complication for your HIPAA efforts—and in compliance matters, there aren’t any good surprises. This is not a platform, system or vendor issue: Regardless of your technical approach, you must ensure that HL7 capabilities are included. In short, your expensive HIPAA solution is incomplete—and worse, non-compliant—if your core systems don’t “speak HL7” when required. Providers: If your HIS (or business partner systems) cannot communicate patient data to payers in HL7 format, you may not get paid. Payers: If your claims processing system cannot handle HL7 patient data, you can’t serve your provider base effectively. HL7 is a key component of HIS interoperability efforts and a significant standard in its own right. From a HIPAA perspective, however, HL7 is a small but crucial piece of the puzzle. Here’s a brief synopsis of what you need to know. HL7 Basics HL7 is a syntax standard specifically designed by the healthcare industry to facilitate patient data exchange between computer applications and systems—typically systems within or connected to one healthcare enterprise. HL7 is now in its 14th year of development, and has become the de facto standard for patient data exchange by specifying the format, structure, and sequence of that data. As such, HL7 has a different scope and focus than HIPAA. HL7 is not targeted at the transformation of business or patient care processes. Its mission is to establish a common language among computer applications regardless of platform, architecture or programming language. While less far-reaching than HIPAA, HL7 is complex and intricate enough to have created its own industry. Although the actual syntaxes are different, HL7 is similar in concept to the X12 EDI standard used for HIPAA-compliant data transfer. HL7 is also different from X12 in that it was designed from the ground up as a healthcare exchange standard—rather than adapted from a larger EDI standard. Figure 1 (below) shows a lab request expressed in HL7 as an OBR (observation request) segment.
HIPAA’s HL7 Requirements There are several X12N implementation guides adopted or expected to be adopted under HIPAA (hereafter “HIPAA transactions”) that are potentially at issue. HIPAA 275—Additional Information to Support a Health Care Claim or Encounter. To send or receive detailed claim or encounter information, you must transmit or receive patient “order data”—diagnoses, test results, observations, treatment modalities, and so forth—in HL7 format. Providers: To submit a 275, your systems must:
Payers: To process a 275, your systems must be able to parse the HL7 ORU message. Other HIPAA Transactions. Although the 275 is the only HIPAA transaction expected to actually contain HL7 content, when the regulations are finalized other HIPAA transactions may be “linked” to a 275 transaction:
An ORU Lesson In HL7 terms, an ORU message is an “observation result/unsolicited.” A HIPAA-compliant ORU consists of:
Conceptually, a HIPAA 275 transaction looks like this. Here’s a sample HIPAA 275 message, with the BIN segment highlighted: (click here) (Figure 3. Sample 275 Message. (From "HL7 Implementation Guide for Additional Information to Support a Healthcare Claim or Encounter" © 1999 Health Level Seven, Inc.)) Three Essential Steps First, in anticipation of regulation passage, make sure your HIPAA technology initiatives address HL7 compliance. Quiz your vendors, update your specs, check with your team to ensure this hasn’t been overlooked. Next, have IT staff formally trained in HL7. HL7 takes months to learn on your own—don’t expect a programmer to “browse the spec” over the weekend. Examine HIPAA compliance efforts in the context of your larger interoperability goals. Are your pending upgrades and new systems HL7 compliant? A piecemeal approach to HIPAA implementation will not provide maximum cost savings or other benefits. This goes for HL7 compliance, also. Stopgap measures may temporarily hold the fort on HIPAA, but won’t provide the interoperability gains HL7 is designed for.
HL7 has impacts on healthcare technology beyond HIPAA concerns; to learn more visit the HL7 organization’s website (www.hl7.org). Guidelines for HL7 implementation within HIPAA are available from the Washington Publishing Company website (www.wpc-edi.com/HIPAA). © 2002 Nelson Publishing, Inc |
|
|
|
HIPAA
Watch
for June 2002
By Dave Shaver, founder and CEO at
Other aspects of HIPAA—the privacy, training and business partner requirements—are not directly complicated by HL7 considerations, unless they serve as a source of patient data in support of claims. As
Figure 4 shows (at right), the overlap between HIPAA and HL7 requirements is a small slice of either initiative.