Physicians Health Plan
Who is PHP?
Physicians Health Plan of Northern Indiana (PHP) is a successful, not-for-profit health maintenance organization that has provided quality, affordable health insurance services since its inception in 1983. With a strong financial history and an ever expanding range of services, PHP offers first-class benefits to its members by relying on the knowledge and experience of its staff and the use of technology.
With this purpose in mind, PHP constantly analyzes its own business practices in order to streamline processes and remove inefficiencies. By regularly updating and upgrading its strategies, PHP is able to stay ahead of the competition, increase productivity, and maintain the exceptional customer satisfaction for which it is known.
Situation
Through ongoing self-analysis, PHP discovered that more than 85% of its incoming claims were delivered via EDI. This information led to a re-evaluation of the existing EDI processing system.
The EDI system was responsible for validating and cleaning incoming EDI data before loading it into PHP’s claims processing system. In addition, paper copies of the incoming claims were generated and images were created for routing to other systems within PHP.
As PHP began to closely evaluate the EDI system, it realized that the EDI method of processing claims no longer met the needs of a growing business. Below are several issues that led to this awareness:
- The previous system consisted of several disparate sub-systems that did not directly communicate with each other.
- Incoming EDI files required manual movement from one sub-system to the next.
- If any sub-system failed, the entire EDI process halted.
- After the process halted, fragments of data remained in various stages of processing and needed to be manually removed.
- Several sub-systems showed an unacceptably high failure rate.
- The previous system relied on multiple disparate systems that were external to the actual EDI process.
- If any of these unrelated systems failed or encountered an issue, the process would halt and potentially generate corrupt data.
- Updating or upgrading any of the external systems could cause the process to fail, making the entire system extremely difficult to maintain.
- The previous system required 6 – 8 hours daily for end-to-end processing to occur. Over 50 percent of this time required a systems analyst to perform manual (human) intervention and data cleansing activities.
- Malformed EDI interchanges caused the previous system to fail and corrupt data. Systems analysts commonly spent up to 30 hours per week correcting data integrity issues.
- The previous system’s scalability was extremely limited.
- Adding a single clearinghouse to the previous system required up to 150 hours of programming time.
- Changes in processing functionality required updates and redeployments for most of the disparate sub-systems that comprised the overall EDI processing system.
- The previous system lacked any significant auditing or logging capabilities.
- The previous system made HIPAA compliance verification extremely difficult and time consuming.
- The previous system’s file transfer mechanisms were inefficient.
Solution
PHP asked Aptera, a Microsoft Gold Certified Partner, to research practical solutions to its EDI processing issues. The guidelines stipulated that the final solution be robust, scalable, and reliable while ensuring simplicity in maintenance and administration. PHP also asked Aptera to implement a system for logging, auditing, and reporting as part of the overall solution.
Aptera immediately started identifying requirements, interviewing stakeholders, identifying risks and ranking the feasibility and practicality of possible solutions. After presenting several options to PHP, a decision was made and development started.
The solution recommended by Aptera and accepted by PHP was based on the following Microsoft technologies:
- SQL Server 2005 Relational Database Management System
- SQL Server Integration Services (SSIS)
- SQL Server Reporting Services (SSRS)
- BizTalk Server 2006r2
- Microsoft Visual Studio & .NET 3.5
In order to facilitate the transfer of EDI interchanges and alleviate dependencies on third party encryption software, an in-house SFTP server was brought online at PHP. This server gave all external EDI trading partners the ability to use a single point of entry to drop off and retrieve incoming and outgoing interchanges without manually encrypting and decrypting the data. Each trading partner was given unique access to ensure all interchanges were kept secure.
BizTalk 2006r2 (BTS) and SQL Server 2005 (SQL) were utilized to consume the incoming x12 EDI interchanges. Aptera decided to use an existing server already running SQL Server 2005 as the database server while a new server was purchased and dedicated to running BizTalk. Aptera’s plan allowed PHP to maintain high efficiency while keeping overall costs at a minimum.
Another major goal of the project was to create logging and editing capabilities for each activity in the EDI process. Making extensive use of the .NET 3.5 Framework, Aptera created a system that could track each claim through every step of the processing cycle. The data provided by this process allows PHP to track the start and end time of each individual processing step and assess changes made to claims created during data cleansing. The process was designed to be easily extensible, giving PHP the ability to add auditing or logging to other portions of the process when necessary.
Visual Studio 2008, SQL Server and the .NET 3.5 Framework were all used to create two applications responsible for cleansing all of the incoming data. The first application does a “pre-scrub” of all incoming claims based on an extensive set of business rules. It also identifies claims that need manual (human) intervention before being processed. The second application provides PHP’s claims processors with the ability to correct any non-conforming claims received through EDI. Both of these applications ensure that HIPAA compliant claims entering PHP’s claims processing system have the highest level of conformity and integrity possible.
PHP also needed the new EDI process to generate electronic and paper claims from the incoming data. To satisfy this need, Aptera employed SQL Server Reporting Services (SSRS), Visual Studio 2008 and the .NET 3.5 Framework. An adaptable, multi-threaded application was developed to make use of SSRS’s innate ability to generate TIF images. This application automatically generates multiple image versions of all incoming EDI claims in a single pass.
To round out the EDI processing solution, Aptera used Visual Studio 2008, SQL Server and the .NET 3.5 Framework to create a front-end dashboard for PHP’s claims processing team. This dashboard contains various reports and tools that allow users to access information concerning every part of the EDI process. This information includes historical EDI loads, statistics and overall process health. The dashboard also houses the log and audit data that was collected during EDI processing and can be viewed via reports. Finally, the dashboard includes tools used to research EDI discrepancies and search raw EDI data in order to maintain a centralized “point of access” for all EDI related tasks.
Benefit: Reliability
The EDI processing solution that Aptera created for PHP made significant advancements in efficiency and reliability. Claims received via EDI now require minimal user interaction. This automation reduces the likelihood of errors and allows PHP resources to work on other activities.
- PHP no longer relies on the availability of systems or vendors outside the EDI processing system.
- The new EDI process is decoupled from a specific adjudication system. This separation ensures that changes and upgrades to the claims processing system do not affect the EDI processing system.
- The new system saves significant time and money by dealing with issues concerning corrupt incoming interchanges at the beginning of the processing cycle.
- The transactional nature of the new EDI system ensures that fragments of data will not be left behind should a failure ever occur.
- The Dashboard allows the claims processing team within PHP to view real-time information regarding the “health” of the EDI system.
Benefit: Scalability
The EDI processing system developed by Aptera is extremely flexible and scalable. As PHP continues to expand its business and services, the new system will quickly and easily adapt to the changing environment with minimal effort.
- Adding a new EDI trading partner requires less than two hours of configuration time. This is down from 150+ hours under the old system.
- By utilizing BizTalk, future updates to the healthcare industry’s X12 EDI standard are much easier to integrate.
- Business analysts can map changes to the EDI interface without the assistance of a developer.
- All user interfaces are web-based applications and no longer require desktop installation.
- BizTalk’s processing power allows a significantly greater amount of interchanges to be processed daily.
- All configuration settings for the EDI claims processing system are now centrally managed.
- User logins and email notifications are centrally managed using Active Directory Groups.
- The tools used to develop the EDI claims processing system allow for highly customizable file and HIPAA validation procedures.
Benefit: Logging and Auditing
The healthcare industry is extremely complex, and PHP benefit tremendously from the ability to log and audit all facets of claims received via EDI. The new system allows any stage of the claims processing lifecycle to be monitored and analyzed either in real-time as it is being processed or from a historical standpoint.
- Each step in the processing lifecycle is logged for every claim. The dashboard makes this log data available to the user in real-time.
- Any changes made to incoming claims due to data cleansing are logged and made available in the dashboard.
- Configurable user privileges regulate the availability of sensitive information (e.g. employee claims, etc.)
Benefit: Compliancy
BizTalk 2006r2 natively handles validation of incoming files.
- All incoming interchanges are validated for ANSI X12 EDI conformity before being loaded into the system.
- All incoming interchanges are validated for HIPAA compliancy before being loaded into the system.
Benefit: Error Reporting
The ability to monitor every aspect of the EDI processing system is vital to PHP. Basing decisions on real-time and historical data strongly benefits several departments within PHP.
- Information on all aspects of the overall EDI process is made available either on-demand or via a “subscription” service.
- The EDI processing system provides extensive automated error messages if a failure occurs.
- Reports are clear, concise, and easy to understand
- Performance statistics are readily available for:
- Overall process health
- Processing times
- Trading partner performance
Benefit: Efficiency
The EDI process developed by Aptera helped PHP become considerably more efficient and significantly increase productivity within the claims processing department. Resources that were previously utilized are now free for other activities.
- The time required for overall end-to-end processing was reduced by over 90%. The legacy system required 6-8 hours per day to process EDI claims. The new system requires less than 45 minutes.
- The time required for manual intervention in claims processing was reduced by over 90%. The legacy system required 4 or more hours of manual intervention each day. The new system requires less than 20 minutes daily.
- The number of claims that need to be manually scrubbed was reduced by over 80%. The legacy system required 300+ claims to be manually scrubbed each day. The new system reduced this number to roughly 60 per day.
- The time required to create images of the processed claims was reduced by over 95%. The legacy system required 3-4 hours daily while the new system requires approximately 10 minutes.
- The time required to search for raw EDI interchanges has been decreased by over 90%. New toolsets make raw EDI interchanges accessible for research purposes in less than a minute where the old system took 10-15 minutes.