From the November 2004 Issue

Drivers and Outcomes of PACS

Beyond Clinical Documentation: Using the EMR as a Quality Tool

Works as Advertised: Case History

Strategic Planning Supports ED Automation: What Works

Public Trust

HSAs Will Catalyze Adoption of EHRs

 

Works as Advertised

Blue Cross Blue Shield of Montana adds transaction validator technology that streamlines claims error testing and prevents batches of claim submissions from being rejected because of a single error.

Even the best laid plans—and the best executed, too—can encounter challenges when it comes to meeting standards emanating from a government mandate. Payers and providers alike know that compliance with transaction and code set (TCS) regulations required by HIPAA didn’t end in October 2003—far from it. But one Midwest health plan organization managed to face the challenges and overcome them, with the help of information technology.

Health-e-Web (HeW), a subsidiary of Blue Cross Blue Shield of Montana (BCBSMT), handles 80 percent of all electronic claims processed in the state with direct connectivity with major payers, and through THIN (The Health Information Network) and WebMD/Envoy with commercial payers. The organization manages more than 6 million claims per year.

Preproduction Testing
Acting as an all-payer clearinghouse for the state of Montana presents myriad challenges, especially when it comes to dealing with payer-specific transaction edits. One of the biggest is the need to validate individual claims that come bundled together and must be separated and routed to multiple payers. HeW/BCBSMT was forced to test each claim for every possible error condition before it could move to the production environment. This testing intensified labor costs by requiring the full-time equivalent of three technical and two business professionals.

SOURCE
Joseph P. Fleming
Director, Infrastructure Support
Health-e-Web
Blue Cross Blue Shield of Montana
www.bcbsmt.com

PRODUCT/COMPANY
InStream
Foresight Corp.
Dublin, Ohio
www.foresightcorp.com

Without such testing, an organization might batch and submit 2,000 claims, but if only one or two claims contained errors, the entire batch could be rejected and, hence, payment delayed. While testing and validating was necessary, HeW needed less reliance on human intervention and manual support, and more reliance on automated error identification and validation.

HeW/BCBSMT had begun work on transaction and code set conversion a full two years before the October 2003 deadline, but with a product that the organization eventually decided to deinstall. When e-Business Executive Joseph P. Fleming was made responsible for the organization, about a year prior to the October deadline, HIPAA requirements were indeed looming large for HeW.

Plays Well With Others
In addition, the organization anticipated a demand from their provider partners for consulting and transaction debugging services. Certain that Medicare’s facilities for identifying problems were inadequate for their needs, Fleming and his team set out to find a way to streamline the transaction process and reduce human intervention, thereby improving adjudication and processing efficiency.

Their existing system required extensive manual testing and error corrections, resulting in additional mistakes due to human error by programmers. “At that point, we went back to square one and were forced to re-evaluate how to quickly and permanently get compliant with HIPAA mandates and how to automate validation,” says Fleming.

The organization had changed to a different claims processing system, so Fleming directed the search for a product that would play well with it and with Microsoft BizTalk, and would bring strength in editing and error messaging, with information generated in English as an outcome. A critical requirement was the software’s ability to look at incoming claims and call the right standards and edits based on information in individual claims. The software had to enable HeW/BCBSMT to make corrections to edits and to reduce or eliminate the need for extensive testing. It also had to validate WEDI types 1 through 7 (see box).

Why Fight Success?
Fleming had previous experience with Dublin, Ohio-based Foresight Corp. products and decided to explore the company’s InStream transaction validator product. “We brought it in, tried it and had it fully operational within a week,” he says. “The product worked as advertised.” HeW/BCBSMT chose not to look further.

Setup and integration were completed in less than two weeks. Developers from HeW/BCBSMT spent approximately 40 hours on installing the new system, with a single call to the technical support team at Foresight. A business analyst and a systems analyst spent an additional 24 hours testing and analyzing the new system to ensure compatibility and function. Total cost for installation and testing was approximately $2,500.

The proof of concept was to integrate InStream validation without impacting the existing technical flow. Fleming says the software was easy to integrate within HeW/BCBSMT’s production flow, particularly with the organization’s data translator.

HeW/BCBSMT’s due diligence, which included product testing, determined that the proposed solution met all the organization’s requirements, which were:

  • validating WEDI types 1 through 7 edits from the transaction’s structure and through business edits;

  • sustaining accurate and up-to-date code set tables, as well as providing effective beginning and end dates for the individual codes;

  • adding specific edits requested by each payer;

  • adding error messages, with the ability to add custom messages;

  • the ability to provide application document splitting on all HIPAA transactions to prevent batch rejections due to a single error;

  • rebalancing data for claims and payments.

The real-time transaction filtering system validates 500 claims at once against all seven WEDI types. Instead of rejecting an entire batch based on even a single error on one claim, the HeW/BCBSMT system now uses InStream’s document splitter to separate bad claims and allow compliant claims to continue to move along in the submission and adjudication process.

Harvest of Results
Before the validator was installed, three programmers were assigned to test for errors, as well as continually update tables and code sets. With the new system, human intervention has been reduced by 50 percent in less than one year after implementation. All transactions are screened for errors, with edits entered quickly. Error messages are now reported in English rather than technical jargon, allowing billing specialists to make their own corrections. This further reduces human intervention by eliminating the need for IT professionals to interpret error messages and reducing the need for calls back to HeW/BCBSMT customer service for explanations of EDI-based error messages. Updates to tables and code sets are provided monthly by Foresight.

Edits that had taken hours now are completed in a matter of minutes. The new system has reduced staff expenses by half while improving service levels and moving toward full production more quickly than originally anticipated.

Fleming and his organization are pleased with the results. “What was most impressive to me was that within one week of installing InStream, it was up and running and doing everything it was supposed to do. We needed a little help with interfaces, but found good support with the supplier. We were the first in the nation to be 100 percent ANSI-compliant for submitting claims to Medicare parts A and B. I saw the first Medicare report, indicating compliance rates between 20 percent and 50 percent. We busted and achieved 100 percent compliance.”

It’s hard to argue with that kind of success.

For more information about InStream and other products from Foresight Corp.,
www.rsleads.com/411ht-209
 

WEDI Edit Types

The Workgroup for Electronic Data Interchange (WEDI) established seven edit types to help healthcare organizations better understand the complex HIPAA implementation guides. Using the edit types, organizations may focus on testing EDI syntax (types 1 and 2) and the different application types such as situation testing (type 4), external code set testing (type 5), specialty services (type 6) and payer-specific edits that are specified in the implementation guides (type 7). These types may be tested in any order, determined by the organization or partner.

Type 1 Integrity Testing (X12 syntax, file integrity)
   ▼Type of data element
   ▼Maximum size of element
Type 2 Requirement Testing (healthcare limits to X12 syntax)
   ▼Optional element not recommended
   ▼Segment repeats X times (less than X12 standard)
Type 3 Balancing (ensures amounts and totals balance)
   ▼Detail claim items should add up to summary claim amount
Type 4 Situational (healthcare situation conditions)
   ▼ “This element should be used when patient is less than 29-days-old”
Type 5 Code Set Type
Type Description examples/further description (verification of healthcare data codes)
   ▼Verify procedure codes against HCPCS
   ▼ Verify claim adjustment reason codes
Type 6 Product Type or Line of Service (specialties, type of bill specifics)
   ▼Verify ambulance, home oxygen treatment, nursing home conditions, etc.
Type 7 Partner- (payer-) Specific Edits (payer edits in implementation guides)
   ▼ Medicare, Indian Health edits
   ▼“SSN should not be used for Medicare” Partner (Payer) Edits (not in implementation
       guides)
   ▼Edits (types 2-6) that are suggested by a payer to give guidance to pass their
      adjudication system


© 2004 Nelson Publishing, Inc