Solving the Test Automation Challenge for EDI Data Feeds
Digital transactions between organizations and institutions require data interface standards to communicate effectively – whether they are commercial, medical, financial, educational, or governmental in nature. Electronic Data Interchange (EDI) is the principle standard that ensures all connected systems speak the same language to keep information flowing instantly, accurately and in a secure manner.
Since the introduction of EDI more than 50 years ago, it has grown in size and scope to encompass multiple industries including retail, banking, healthcare, manufacturing, high-technology, and transportation services. In the healthcare industry alone, the EDI market is projected to be worth $5.9 billion by 2025 with an annual growth rate of 9.4%.
The reason for this dramatic growth and cross-industry proliferation are the many benefits EDI can bring to software applications and systems that enable organizations to:
- Reduce their costs
- Improve data quality
- Accelerate business cycles
- Improve business efficiency
- Ensure data security
Because of EDI, trading partners can automate transactions and exchange information in a standard electronic format. Retailers can exchange purchase orders and invoices, suppliers can manage inventory levels, banks can manage payments and transmit financial records, insurance companies can process claims and healthcare providers can share critical patient care information.
For example, information exchange in the healthcare industry is based on the Health Level 7 (HL7) standard for short messages that continuously update patient care data such as electronic medical records, patient visit details, diagnosis details, patient insurance details, and make updates to revenue management systems. Other participants in the healthcare arena, such as finance and insurance organizations, use the Accredited Standards Committee X12 standard (also known as X12) for processing billing and claims transactions. Two examples are the 835 (Claim Payment) and the 837 (Healthcare Claim). .
Banking and financial institutions use Financial EDI (FEDI) to manage the transfer of funds and exchange financial documents, particularly in support of their commercial clients. The X12 standard is used to specify multiple document types for the transfer of payments and payment-related information in the course of everyday business. In addition to X12, there are many other standards used by financial service firms for treasury, cash management and securities including ISO 20022 XML, NACHA, BAI2, SAP IDOC, Microsoft Excel, SWIFT MT/FIN, FIX XML, FpML, and ISO 15022.
The Challenge of Testing EDI Data Feeds
While EDI data feeds are the lifeblood of software applications that rely on the exchange of information between diverse systems, they present a major testing challenge for QA organizations charged with ensuring compliance, interoperability and quality testing for applications that rely on EDI data feeds.
Test data must adhere to strict industry specifications, support the testing of complex workflows and provide data with high variation at high data volume to maximize coverage. And for most EDI environments, Personally Identifiable Information (PII) must be eliminated from the test data set to ensure privacy and security.
Here are the principle EDI testing challenges:
- Provisioning large volumes of quality test data
- Compliance with multiple file formats
- Validation of complex relational data tables
- Configuring the test environment for testing complex workflows
- Achieving comprehensive test coverage (volume of tests)
- Maximizing the use of automation to streamline the process
Testing EDI Data Feeds with GenRocket’s Test Data Generation Platform
GenRocket can meet all of the challenges associated with testing EDI data feeds with by leveraging the architecture of its Test Data Generation (TDG) platform. Because the GenRocket platform is component-based, the ability to separate the type of test data needed by the test case from the format and data structure required for EDI compliance is both easy and straight forward.
Here’s an example. Generating HL7 test data for healthcare applications is a simple process that allows any member of the QA team to generate large volumes of controlled and conditioned test data on-demand.
GenRocket uses its a Domain component to represents an HL7 Segment and its Attribute Component to represent an HL7 Composite. The GenRocket Receiver component, in this case the SegmentDataCreatorReceiver, morphs a Domain’s generated data into name/value pair XML segments. By creating XML segments which represent each HL7 segment, we can ensure full referential integrity between various components. The HL7SegmentMergeReceiver can then read these XML segments and merge the segmented data into the required HL7 format.
The healthcare industry mandates strict patient privacy and data security protocols restricting the use of Personally Identifiable Information (PII). Our support for the HL7 data format combined with the ability to generate 100% secure, synthetic test data makes GenRocket a perfect match for healthcare software testing environments.
Here is a summary of the GenRocket HL7 solution for healthcare:
- Generate HL7 files rapidly without the need to access and mask production data
- Generate HL7 files with any level of complexity and complete referential integrity
- Avoid any use of PII with HL7 files that are synthetically generated and 100% secure
- Implement a budget-friendly, cost-effective solution for any testing requirement
We have prepared a case study describing this GenRocket solution for healthcare.
GenRocket can provide solutions for testing virtually any EDI data feed. Regardless of whether the required EDI format is the more prevalent X12 standard or one of the more specific standards used by retail, banking, insurance or financial services applications, GenRocket has (or can create) Generator and Receiver components to support it.
If you find this information to be relevant to your EDI testing environment, please contact us at any time to discuss your data feed testing requirements.
