HIPAA EDI: Enabling the RTE for Health Plans/Providers

Transcription

1 Technology, W. Rishel Research Note 28 February 2003 HIPAA EDI: Enabling the RTE for s/providers Health plans that supplement batch HIPAA transactions with real-time electronic data interchange make a major contribution to the real-time enterprise of the healthcare system. This is not harder than doing direct data entry. Topic Healthcare: Healthcare Technologies, Infrastructure and Standards Key Issues How will developments in underlying Information technologies, architecture, standards and regulations affect healthcare organizations' technology strategies? Which Information technologies and standards have been proven effective and are ready for adoption by healthcare organizations? Note 1 Cyclones for HIPAA The 10 cyclones are ranked in three levels of activity: leadership, management and operation. HIPAA transactions, which are mandated by legislation and inherently interenterprise, apply to operational cyclones. Adapting the cross-industry model to healthcare, Gartner regards the eligibility and referral transactions as belonging to the operational category of cyclones, specifically to the "demand to service" cyclone. Note 2 Real-Time EDI In the language of EDI, a transaction is handled in "real time" if the input transaction and its response occur during the same communications session. The time permitted for the response is dictated by business conditions and may range from a few seconds to a minute or more. Note 3 Is "Screen Scraping" DDE an Alternative? Many provider systems now use DDE as a computer-to-computer communications medium. Reasonable people disagree on the interpretation of the HIPAA regulation on this point; however, at best, screenscraping from one enterprise to another is a fragile approach that requires the provider to do custom work to match the screens or pages of each payer. This is very much contrary to the spirit of HIPAA, which is to create a uniform interface between providers and payers. The U.S. Health Insurance Portability and Accountability Act (HIPAA) and the Real-Time Enterprise (RTE) The RTE is predicated on an event-driven viewpoint how long does it take to respond to, and ultimately resolve, a significant occurrence? In "The RTE 'Cyclones' Model Changes the View," Gartner provides a framework for analyzing RTE initiatives. The framework consists of 10 major categories of end-to-end eventto-response cycles cyclones. We chose the metaphor "cyclone" to emphasize that achieving the RTE requires largescale initiatives that are repeated on a cyclical basis to drive ever more waste, inefficiency and poor customer service from enterprises (see Note 1). The revenue cycle of care delivery organizations (s) represents fertile ground for a "cyclone" round of improvements. Health plans, which are an integral part of this revenue cycle, will share the benefit of these improvements through a reduction of support costs and increased good will with the s and with their members. Here, we address one technology that health plans can and should implement to better support process improvements in s. They should go beyond the minimum requirement of HIPAA, which is batch electronic data interchange (EDI), to provide real-time responses to EDI transactions for eligibility and referrals (see Note 2). Some health plans have indicated that they will support these transactions only in batch and rely on direct data entry (DDE) to meet a 's real-time requirements. DDE requires personnel to expend time directly using a health plan terminal or site and requires the users to be trained for the different screens and procedures of each health plan (see Note 3). It further requires personnel time to redundantly transcribe data from scheduling or registration Gartner Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.

2 systems into the DDE screens and perhaps to copy response data back to the system. It also introduces inaccuracies in copying the data that can lead to suspended or denied claims downstream. Many s only perform eligibility checks on a fraction of all walk-in and same-day patients because of the personnel requirement to key in the data to check all such cases. By spot-checking, they are losing opportunities to collect payment at the time of service and increasing the number of claims that are suspended or rejected because of inaccurate member identification data. Some s that have access to interactive EDI-based eligibility systems coupled to their own have told Gartner that their payback times for implementing this feature were less than 12 months. A recent Gartner survey asked 11 vendors of 24 administrative and practice management systems if their users would be able to initiate X12N interactive eligibility request (270) transactions automatically during the scheduling of same-day appointments and on demand when processing walk-in patients. Preliminary results show that 70 percent of the products offer one or both of these features now or will by year-end The features are only useful, however, for health plans that provide the X12N interactive eligibility response (271) transaction response in real time. The Challenge of Implementing Real-Time EDI In "Direct Data Entry vs. EDI for HIPAA: Sorting Out the Issues" Gartner states that health plans with high-performance DDE can easily offer fast-turnaround EDI for the transactions mandated by HIPAA that correspond to their DDE services. Some health plans have asked us to elaborate on this statement. Of course, "easy" is in the eye of the beholder. We say it is easy for health plans that have found a way to provide responsive, high-volume DDE to provide the same functions in real time or fast batch EDI because they can do so without revamping their batch EDI environment or making major enhancements to their core applications. How is this possible? The answer depends on the model that the health plan uses to provide DDE. There are three common models: Terminals directly to the core application A server connected directly to the core application A server using a replicated database 28 February

3 Here are some case examples: Case 1: Terminal-Based DDE to the Note 4 Programmatic Integration s The industry uses the metaphor "screen scraping" to refer to the facility of programmatic integration servers to emulate the actions that a person would normally perform on a terminal or browser. Programmatic integration servers can perform data entry (for example, entering claims) or data retrieval (for example, looking up patient eligibility). The application accessed is unmodified and none the wiser. It "thinks" it is interacting directly with a user. Figure 1 illustrates a straightforward use of an integration broker that accepts EDI transactions using secure HTTP (the same protocol that is used when a browser accesses a server in secure mode). The integration broker decodes the EDI and uses a programmatic integration server to "screen scrape" (see Note 4) the health plan's core application to retrieve the response data. The integration broker then encodes the response as a HIPAA EDI transaction and returns it to the 's system as the response to the incoming transaction. Figure 1 Fast EDI With -Terminal DDE Terminal Dedicated Line Scheduling or Registration System EDI Mapper Programmatic Integration Integration Broker All of the integration broker products that offer HIPAA-specific products also offer the ability to accept transactions over the using secure HTTP. This is a new technology, but it is by no means "bleeding edge." It has been used for more than five years in federally regulated EDI transactions standardized by the Gas Industry Standards Board (see "Questions About XML and HIPAA"). is used by many health plans precisely for real-time HIPAA transactions. A few examples include the participants in New England Healthcare EDI Network, the Minnesota HIPAA Collaborative and MedUnite (recently acquired by ProxyMed). is also the basis for secure access with the Simple Object Access Protocol (SOAP) and the burgeoning developments of services. 28 February

4 In an enterprise that otherwise only does batch EDI, the integration broker pictured in Figure 1 should be a physically separate system, optimized for real-time transactions. Some programmatic integration servers that would be appropriate for the screen scraping are Jacada, Clientsoft, Seagull and IBM. Case 2: -Based DDE Linked to the Figure 2 illustrates the general architecture of a -based DDE application that links directly to the core application. Health plans will use different servers and different middleware technologies, including integration brokers or application servers. The adapter that connects the middleware to the core application may employ any of a number of approaches, from directly accessing the core application database to sending transactions to the application transaction processor in XML or proprietary formats, and might even be accomplished using screen scraping (see "Wrapping : New Architectures From Old Systems" for more information on connecting to a legacy application). Figure 2 Typical Architecture for -Based DDE Secure HTTP Integration Broker Adapter Assuming that this combination of server, middleware and core application has adequate response times, the modifications to handle real-time or fast-batch EDI queries are shown in Figure 3. The front end is the same as in Case 1. The EDI transaction is mapped to an internal format. From that point forward, essentially the same programs that support normal queries will be used to retrieve data from the core application. 28 February

5 Figure 3 -Based DDE With Real-Time EDI Adapter Scheduling or Registration EDI System Mapper Case 3: -Based DDE Linked to a Parallel Figure 4 illustrates the approach generally used for DDE when the health plan wants to provide richer functionality than is available directly in the core application, or the core application is not sufficiently scalable to support the transaction volume. The self-contained DDE application periodically replicates data from the core application. Figure 4 -Based DDE With Replicated Database Program Logic Replica Database 28 February

6 s use browsers to view pages encoded in and enter inquiries that are transmitted to the server using HTTP. Software in the application server retrieves the appropriate information from the DDE database andformats it in, and the server then returns it in response to the inquiry. Figure 5 shows that the architecture for real-time EDI HIPAA transactions is scarcely different. The only change from Figure 4 is that the inquiry comes in formatted as an EDI transaction and must be mapped to the discrete data elements that would be posted from a browser-based inquiry. Figure 5 -Based DDE, Real-Time EDI With Replicated Database Program Logic Replica Database Scheduling or Registration System EDI Mapper Because the EDI transactions will generally be less rich than what are offered to browser-based users, there will be the need to create a special version of the program logic in the application server to service EDI requests. The special version will not offer some features available through the -based DDE. Not as Easy: Increased Transaction Volumes If s automate sending referral and eligibility transactions, they will do so more often. Indeed, being able to do so consistently, without tying up personnel resources, is precisely the facility that will allow s to achieve the savings associated with timely and more-accurate data. In each of the cases we have identified, the easy technical changes must be 28 February

7 Acronym Key 270 Eligibility request 271 Eligibility response Care delivery organization DDE Direct data entry EDI Electronic Data Interchange HIPAA U.S. Health Insurance Portability and Accountability Act RTE Real-time enterprise SOAP Simple Object Access Protocol X12N Accredited Standards Committee X12, Subcommittee N, Insurance accompanied by an assessment of the effect of increased transaction volumes on the underlying system. If investment is required to boost the capacity of a health plan's systems, this must be justified by a reduction in personnel time associated with suspended or denied claims and expected reductions in the overhead that appears to the health plan as medical costs. Bottom Line: Many health plans are justifiably proud of their -based direct data entry (DDE) and see electronic data interchange (EDI) as a step backward in functional richness. This is true, but it does not take into account the needs of large care delivery organizations (s) to remove manual steps and duplicate data entry from their business processes. Health plans should support this drive toward the real-time enterprise (RTE). Those with good DDE will spend less going to real-time EDI because they will be able to leverage their investment in DDE. 28 February