EDI Test Automation In Healthcare

By Daniel Schwartz, content strategist

I have experienced many complicated problems needing to be solved throughout my career as a software testing engineer. There are always more bugs to find, more software to break, and more tools to learn. However, one of my greatest accomplishments has been in developing, building, and executing a KDT framework to enable test automation in healthcare.

Basically, the company functions as a go-between for healthcare providers and payers, processing transactions and claims for each at a lower price. Because they provide this service for many different providers and payers, there are many different file formats and types needing to be configured and tested.

EDI Testing Challenges: The Ugly, And The Uglier
Prior to my involvement with the project, the company was already using automation to test their Electronic Data Interchange (EDI) database and product. However, they were using legacy automation that was built using an industry-scheduling tool that only could work with VB-scripting capabilities and SQL/PL SQL Queries. This provided them with a host of problems, including:

• Automation did not lend itself to repeatability/modularity.

• For batch processing in EDI claims, there was a commonality across six or seven different scripts. To update certain functionality, the automated regression code had to be accessed in order to be changed, which was exceedingly inefficient.

• Updates could only be handled by testers with coding experience.

• Any updates to automation relied on having testers with coding experience. All testers do not know how to write code, so changing the code was limited by the number of resources who could update changes to automation.

• Simple updates required code changes (such as db structure errors).

• Difference Reports were difficult to read, not sortable, repetitive, etc.

• Automation execution depended on variable/parameter updates to a config file, as well as being error prone. The goal of automation is to be in a position of only clicking a button, with no need for subparameters or variables.

With EDI, there are a number of different, complex, and reactive workflows that are reliant on data input and environmental variables, as well as the processes themselves for claims to go through many stages in order to be validated. This entailed the following list of problems:

• Large Volumes Of Data To Process And Validate — The traditional way to do this would be through a data driven approach, but we found that the conventional way of DDT did not scale well to large data sets, so we had to determine a way to overcome challenges and process large volumes of data.

• Numerous File Formats To Validate — There are many file formats to validate for EDI, including NSF, X12, ASCII and more. These can each sometimes be distributed across multiple files, and a test can validate multiple file formats together. Also, formats like X12 can vary depending on client/vendor.

• Complex Relational Data To Validate — In a typical test environment for database validation, testers don’t require in-depth database knowledge, but with complex relations, we had to know SQL, manage data, optimize queries, and therefore had to know how to validate the data.

• Configuring The Test Environment — The company had many environments to deploy data, so we wanted to make the solution configurable in order to run the tests across various environments and input data.

• Achieving Comprehensive Test Coverage (Volume Of Tests) — We wanted to go with a holistic approach instead of automating every single test case. Our goal was to have a large input data that would cover a large scope of test cases.

• Minimizing Human Intervention And Man Hours — Due to the complex nature of the workflows, we needed the workflow to be completed without human intervention to allow testers more time for test analysis rather than configuration and execution.

EDI Automation Requirements
When building our EDI testing framework, we considered each of the following bullets to be of the utmost importance:

• non-technical users must be able to interact with automation

  • automation must provide coverage for web applications, database applications, and web services (both REST and Soap)

• automation must be able to verify against previously run results (regression purposes)

• maintenance cost of automation should be low and code-free when possible

• automation steps should be reusable and configurable across multiple workflows — to spin up test cases and workflows quickly

Implementation Of EDI Testing Framework
For the EDI Testing framework, we decided to utilize a keyword-driven testing (KDT) approach. So, what is KDT? It is a system in which business logic is encapsulated in keywords. One Keyword represents one unit of business logic, and a test case in KDT is a sequence of keywords executed.

• Keyword Driven Testing (KDT) Framework

  • Data Driven — We used a non-traditional data driven approach, where instead of each step being executed multiple times per data row, we executed variable sized batches of data per step.

  • Configurable — We had to make this framework highly configurable, with a variety of different inputs, where keywords could act differently depending on input.

  • Modular — We needed to plug in keywords with different test cases without having to worry about whether they have dependencies on each.

• Modules for large relational data comparison/validation — We needed modular systems that were adaptable to different input sets of data, within tables, as well as different file formats, for validating various claim files.

• Scalable framework for parsing and validating various file formats

• Seamless support for database and web service functionality — The framework allows a class hierarchy for keywords that allows us to establish a framework for EDI/DB and WS functionality, like a framework within a framework. The framework focuses on EDI, as well as web services.

• Baseline data comparison functionality — Automatic management and configuration for baseline and generation of new baseline data, where each execution would generate a test result. We provided a solution to migrate that test result from historical to baseline data.

• Easy to read and archive HTML reports for results — The overall report provides details on each keyword, including results, warnings, errors, and links to additional in depth reports (such as comparison).

Benefits Of EDI Automation
So where did all of this work in test automation and building a framework get us? The framework allowed us to:

• Reduce turnaround time on regression suite. Because the keywords can be spun up, whereas many workflows require manual intervention at many different points, the automation aspect could run through all these steps and allow the tester to focus more on test outcome analysis.

• Reduced human intervention (creation and analysis).

• Reduced cost of maintenance.

• Increased test coverage — A holistic approach allowed all test cases to be encapsulated within large amount of input data. We could throw a lot of data at automation, and then the tester just needs to analyze outcomes and test results.

• Increased test accuracy (fewer false positives/negatives) — We achieved efficiency in analyzing differences in XML report or from database standpoint. EDI transactions are batch processing, and the way we do our transactions is from database values.

Building the test automation framework for EDI testing has been one of the largest accomplishments of my life! We have completely simplified the testing of tons of amounts of data, and reduced test cases that would take days to only taking minutes.

About The Author
Daniel Schwartz is a content strategist who sheds light on various engaging and informative topics related to the health IT industry. His belief in technology, compliance, and cost reduction has opened new horizons for people in the healthcare industry. He is passionate about topics such as Affordable Care Act, EHR, revenue cycle management, and privacy and security of patient health data. He can be contacted at https://twitter.com/dschwartz20.