1. 1 HIPAA TRANSACTIONS AND CODE SETS: HOW THE JOHN MUIR / MT. DIABLO HEALTH SYSTEM IS IMPLEMENTING THE HIPAA TRANSACTIONS AND CODE SETS Session 2.05 Ross Hallberg, Chief Compliance Officer and Chief Privacy Official John Muir / Mt. Diablo Health System

2. 2 John Muir / Mt Diablo Health System Located in the San Francisco Bay Area - (corporate offices in Walnut Creek, CA) A not-for-profit, multi-entity, integrated health system 12 entities including two acute care hospitals, a behavioral medicine and psychiatric hospital, a home health agency, ambulatory surgery centers, outreach Laboratory services, several outpatient service entities, and a foundation model entity that owns 80 physician practices in 19 locations, serving approximately 64,000 covered lives We also operate our county’s only Trauma Center - 733 square miles and a population of 972,000

3. 3 Applications Inventory & Audit Here’s what we found: –15 Applications that generate claims, one that can receive an 835, and no other transactions are supported. No central management of these applications. –Of the 15, 13 bill Medicare in some form (UB, 1500, NCPDP) –Of the 15, 10 are performing some level of electronic transmission of claims to Medicare, other payers and/or clearinghouses (and 5 are only printing paper claims) –1 additional application that receives and adjudicates claims from other providers -- accepts both manual and electronic NSF format claims. Creates paper Remittance Advices. –That is, we are both a payer and a provider.

4. 4 Print Current (2001-2002) Claims Environment

5. 5 Achieving the HIPAA TCS Vision To achieve the vision of fully electronic communications, 5 components are necessary: 1. Standard data content. The regulations specify what elements of patient information are to be communicated, and what the meaning of each data element is. 2. Standard data formats. The sequence of the data elements must always be the same, or each organization will not know which data element is which. The regulations specify the formats for the transactions. 3. Communication of the transactions. It won’t help to be able to gather all the required data elements and put them in the proper electronic sequence, if there isn’t some way to send the transactions back and forth between providers, payers, and others involved. Appropriate communications technologies are required. The regulations don’t specify the communications protocols. It’s up to each pair of senders and receivers (trading partners) to agree on these protocols.

6. 6 Achieving the TCS Vision, cont’d. 5 Components are Required (Cont’d): 4. New software applications. Even if the standard transactions can be communicated properly, the goal of replacing expensive, manual processes with automated processes cannot happen unless vendors add new application programs and functions. Today’s software will not do the job. We are using it to support all the current manual processes! New applications must be developed to properly utilize the electronic transactions and provide the basis and means for us to replace the current manual processes. 5. New Work Processes. Even if the vendors create the necessary applications to fully utilize the electronic transactions, the cost reductions and other benefits will not be achieved unless we redesign all the work processes associated with the transactions and eliminate the labor and manual functions currently in place.

7. 7 Applications Current Status (May, 2003) Revised HIPAA-compliant software installation under way for 6 applications by year-end, 2002. Of those, only 1 was successfully tested with Medicare & other payers by year-end. Installation for 5 other applications started by 4/2003. Still waiting for the vendors of 2 applications to provide an install date. We will not remediate 2 of the applications at this time since they bill on paper and focus primarily on Worker’s Comp. One application successfully implemented for NCPDP transactions to Medicare & other payers. HIPAA testing underway with 6 applications using our in-house HIPAA editor, Claredi, UGS (Medicare), and one CH. 9 of the 13 applications are/will produce compliant transactions.

8. 8 Need for an In-house Approach Since many vendors could not articulate their strategy, the Health System had to formulate its own strategy to protect its revenue stream and achieve compliance. Central to that strategy was development of in-house, “clearing house” capabilities including: –transaction creation –data translation –compliance editing / validation –communications –logging –reporting –error avoidance / error recovery –and much more...

9. 9 The JMMDHS Central EDI Services (CEDI)

10. 10 The Dual Switch Dilemma The Claims Clinical Editor System Existing application vendor system used to edit claims from our largest billing systems and manage batch claims communications to payers and Clearing Houses. Financial managers not interested in giving up this excellent claims editing capability, but also not interested in including all the billing systems in it. Not clear early on that vendor would fully comply with all TCS needs The family members couldn’t agree on a single solution - And decided to compromise by implementing a dual switch approach for claims processing (837s and 835s) Some billing systems to go through the existing claims edit system And other billing systems to go through the new Central EDI system

11. 11 The Dual Switch Approach Claims In-House Business Apps. In-House EDI Apps. Outside Trading Partners & Payments & Inquiries / Eligibility Claims Clinical Editor CEDI Health Network HN Payers Clearing Houses Outside Providers Home Hlth Adapter Other Hospital Apps. Other Hospital Apps. Other Hospital Apps. Adapter Other Associated Apps Other Associated Apps Other Associated Apps Adapter MDMC EDI adapt. Adapter JMMC EDI adapt. Adapter LAB EDI adapt. Adapter Pavilion Adapter HN-CBO EDI adapt. Adapter EDI adapt.

12. 12 The Dual Switch Approach Pros Back-up technology through CEDI to address vendor “gaps” Reduces operational impact on current work processes Lowers risk of complete interruption to revenue stream Lays the foundation for a Central Switch migration Better than Silo strategy Cons Adds cost and complexity through a dual implementation Introduction of two sets of new technology Duplicity of common functions such as editing and tracking will result in a lack of consistency Not as smooth as a Central Switch approach CEDI and the existing claims edit application will independently be used to perform functions such as editing, communication, and trading partner management.

13. 13 CEDI Services Required Translator Software –Takes in ASC-X12N, NSF, NCPDP, “flat file”, and even “print image” transactions from internal applications and trading partners. –Produces HIPAA-compliant transactions. –Edits both in-bound and out-bound transactions for compliance under the HIPAA rules (presently, version 4010a1). Communication Services –Sends and receives transactions in a variety of ways using a variety of protocols including HTTPS, SFTP (FTP over SSL), COM, SOAP. Operates in both real-time and batch modes. –Uses a variety of encryption and authentication protocols and provides non-repudiation of messages. –Uses any communication medium including internet, VPN, dedicated lines, dial, and VAN.

14. 14 CEDI Services Required cont’d Transaction Tracking & Error Recovery –Tracks transactions from the point they enter the CEDI system through acknowledgement or hand-off to the user applications. –Provides alerts and initiates automated recovery processes when certain common failures occur (such as unavailable communication services at trading partners). –Provides logging of transaction stages including timed recovery of failed processes. Enterprise Electronic Transaction Management –Provides an intranet web-based viewer for the various patient accounting departments to assess the processing state of their transactions. –Provides the ability to create & accept eligibility transactions (270/271). –Provides manual or semi-automated claims follow-up (276/277).

15. 15 CEDI Services Required cont’d Translator, Communications, and Transaction Tracking / Error Recovery services are provided by 3 separate vendors: –Sybase’s EDI Translator, Mapping, and Editing –Cyclone Commerce’s Cyclone Interchange - communications –Quovadx’s Platform V - transaction tracking and error recovery Transaction Management is being developed in- house: –Specifications developed internally and validated through use of a prototype and Joint Application Development sessions with users. –1 FTE of development resource dedicated to the project for 4 months. –Hardware added to the Health System’s Intranet to host the service.

16. 16 CEDI Phase One Strategy Architecture provides the framework to support all electronic formats. Initial TCS Project, however, will focus first on those formats that will enable continuation of the electronic revenue stream, and will keep the Health System in HIPAA compliance. –Provide the means to generate 837s or NCPDPs if the billing applications cannot do so –Automate editing & transmission of valid 837s to payers and CHs –Provide means to track transmission & receipt (inventory of claims outstanding) –Provide a means to receive and automatically update payment (835). –Provide compliant enrollment transactions to our employee health plan benefits administrators (834). –Automate Medicare claims / payments for all applications, & others as required by the payer.

17. 17 Key CEDI Functionality - Phase 1 Key Provider Functionality: –Full Featured Bi-directional EDI Communications –Claim Submission (837) –Claim Payment Receipts (835) –Claims Inventory Management –Employee Health Plan Enrollment Transactions (834) –Claim Follow-up (276 / 277) (If Payers are ready) Key Payer Functionality for our Payer Entity: –Full Featured Bi-directional EDI Communications One batch method, and one real time using EDI INT AS2 –Claim Receipt (837 & NCPDP) –Claim Payment (R/A & EOB) Distribution (835) –Support automated transactions for eligibility (270/271), claim status (276/277), enrollment (834), and Review / Referral (278) as needed based on trading partner request.

18. 18 CEDI Requirements - Claims Processing Claims acquisition from our various billing systems: –batch load (FTP) –transmission via TCP/IP to CEDI –Drop-off to a CEDI directory Additional data acquisition when vendor system cannot Claims batch transformation from whatever format to 837 Compliance edit run (NOTE: Editing not permitted within CEDI due to audit considerations) Claims rejection and notification Aggregation of claims by payer (destination) for transmission Transmission of claim batches to payers Receipt of 997 application acknowledgement Inventory & auto-tracking of sent claims

19. 19 CEDI Phase 1 - Current Status CEDI application requirements have been generated, reviewed, and approved. CEDI core software acquired or in development (3 applications purchased, and one being written in-house). Support & development staff recruited (1 in-house FTE plus contract labor as needed). CEDI acquired products implementation and training has been completed. Planning for each interfacing application is nearly completed. Trading Partner Agreements have been completed with key payers and CHs including Medicare (UGS & NHIC), Blue Cross, Blue Shield, Delta Health, UHC, and McKesson’s TSH) and testing is underway.

20. 20 CEDI Phase 1 - Challenges Data Requirements Beyond UB –28 additional required or situational fields for 837- Institutional Claim (more for some services) –42 additional required or situational fields for 837- Professional Claim –Several changed and expanded codes and code sets –Additional identifiers either included now or will be required soon that need to be planned for now –Many fields needed for Trading Partner setup; many trading partners use unique identifiers for the same provider –While the 837 Implementation Guides standardize the segment and field definitions, many situational fields are left to development of individual TPAs.

21. 21 CEDI Phase 1 - Challenges cont’d Claims and Billing Application Vendor Readiness -- Only 4 of our vendors have fully provided the capability to: capture all the new data elements; ensured the elements have been added to their databases; -- Some of our vendors have not (and will not) deliver software that can produce valid 837’s, recommending instead that we use a clearing house partner to format & transmit the claims -- Some of our vendors, while they produce a format-compliant claim, and appear to have most or all required data elements, do not include data in the output stream for all of the situational segments.

22. 22 CEDI Phase 1 - Challenges cont’d Development of New Departmental Procedures Regardless of how HIPAA is implemented by any “Provider”, new policies and procedures are required to gather the additional data elements and to gather and encode new identifiers: –Many of the additional required and situational data fields are in the medical chart, but not presently part of the “billing” data gathering process –Providers (those who document) and admissions / registration personnel must change procedures to gather new fields –Many identifiers need to be encoded in the source billing applications such as provider taxonomies (application setup) –Alternate payer & provider identifiers need to be encoded in the applications and published in the output billing data stream (many of our application vendors seem to be unaware of these identifiers) And we have not committed to doing all of this (yet)

23. 23 CEDI Phase 1 - Challenges cont’d Varying Payer implementations of X12N transactions & specific segments: –997 (functional acknowledgement) generally used, but not mandated; causes additional non-standard setup effort and Payer-specific coding –997 not forwarded when using multiple hops (e.g. sending transactions through CHs or Repricers) –TA1 (transmission acknowledgement) infrequently used –Certain claim status (e.g. denials) can be communicated by 277, 835, or payer-specific (proprietary) format –Inconsistent usage of destination segments (Loop 2000) when third parties are involved (repricers, reviewers, administrators, etc.)

24. 24 CEDI Phase 1 - Challenges cont’d Unique Payer Communication Methodologies While the HIPAA Implementation Guides provided very specific instructions for the allowed data values, virtually no time was spent on how the transactions were to be communicated, and there are no regulations. –Medicare 837I uses archaic dial-up batch transfer with Zmodem protocol –Many payers use FTP, some over SSL, and some with DES or PGP encryption. Some have not yet addressed encryption. –Some payers are experimenting with SOAP and HTTP using both symmetric and asymmetric keys and PKI –Some payers use a “push” methodology, while others host mailboxes for transactions to be left and picked up –At least 2 payers we have contacted want to use VPNs

25. 25 On-going Work / Next Steps - Beyond Nominal Compliance Use of Data Gap Analysis for Application Profiling –Identification of how additional data is encoded in the applications –Determination of application deficiencies & feedback to vendors –Working with Vendors to accommodate all potential added data elements Examination of Data Gathering Processes –Current expectation is that Medicare will be the first to adopt added data elements, other major payers will follow in time –Each entity must evaluate their current data gathering processes and the added fields - and determine which elements may be needed New Procedures & Change Management –Determine strategy for supplying the new fields –New processes must be established to gather the added elements and input them to the applications –Employees must be informed of the new elements and training provided for the data gathering –Monitoring must be established and remediation implemented as needed And We Have Not Committed to Doing All of This (Yet)

26. 26 CEDI Phase 2 - Strategy Development of Trading Partner relationships with “top 20” payers (those payers that represent 90% of the overall claims transactions) and further expansion of provider transaction capabilities into claims status and eligibility. –Several of the smaller Health System Entities have unique primary payers, as a result, the “top 20” will end up being 40 to 50 payers. –Expansion of the basic Enterprise Electronic Transaction Management (EETM) transaction tracking capabilities into the ability to generate eligibility transactions (including, in some cases, links into the applications to select specific key data fields) –Expansion of EETM to additionally include both timed and on- demand claim status request generation, and response notification –Development of TPAs with one to two additional clearing houses to handle EDI for those payers with whom we have not established direct transaction relationships –Expansion of provider CEDI capabilities to include 278 messages

27. 27 CEDI Phase 2 - Challenges Modification of departmental procedures around use of the new transactions (eligibility, status, referral): –Procedures required to integrate new web-based eligibility lookup into registration processing –Procedures required for “back office” creation of review / referral requests and accepting responses –Procedures and claim follow-up defaults required (by payer) for collections Training –All departments using the new transactions will need training and will have to be registered on Intranet

28. 28 CEDI Phase 2 - Challenges, cont’d Payer Readiness –Began process of querying payers in June, 2001 on their HIPAA readiness, and to establish a TPA –Of the 23 payers and 2 CHs contacted, only 3 payers and 1 CH was ready to negotiate a TPA by year-end 2002 –5 payers have indicated that they will not be communicating directly, and have designated certain CHs as their “HIPAA portal” (including giants such as Aetna) –Several payers have only recently (post- 4/16/03) indicated a willingness to set up a TPA and begin testing –Transaction testing with most payers we have contacted is still limited to claims and payments

29. 29 Oh - Oh, I Wonder If This Will Actually Work? WEDI “Train Wreck” Letter to DHHS, April 15, 2003 - “WEDI believes that a substantial number of covered entities are not sufficiently far along to achieve compliance with the HIPAA TCS standards by the October 16, 2003 deadline…” - WEDI warns that given the substantial degree of noncompliance, if the regulations are strictly enforced, a so-called train wreck will result from reversion to paper claims or stoppage of cash (payment) flows. - WEDI recommends that DHHS allow, for some time period: * Use of HIPAA “standard” transactions that may not contain all required content elements * Use of current electronic transactions (UB-92) in lieu of reversion to paper transactions. On the other hand, an extension by DHHS will further complicate implementation by causing all of us to have to maintain multiple claims formats and communication methods

30. 30 Or Comments