SYSTEM AND METHOD OF MANAGING TESTING FOR A HEALTHCARE SYSTEMS TRANSITION

FIELD OF INVENTION

The invention relates generally to testing of transactions in healthcare systems. In particular, the invention relates to the management of transaction testing in the context of one or more Health Insurance Portability and Accountability Act (hereinafter 'HIPAA') electronic data interchange standards ('EDI') compliant transaction scenarios.

BACKGROUND

Ensuring HIPAA EDI standards compliance is a large and complicated task for any healthcare or health service provider. Migration from the HIPAA EDI 4010 standards set to the HIPAA EDI 5010 standards set, for example, is a huge, and expensive, task that involves an analysis of standards compliance requirements, a corresponding analysis of the magnitude of change from the provider's extant practice that is required for such compliance, and a willingness to confront and deal with any of a multitude of challenges involved in an implementation that bridges the gap. Rough industry estimates have, for example, placed the cost of a 5010 implementation at as much as 20% of implementing the last HIPAA EDI iteration.

Transitions of this nature are generally done in a phased manner, and include, invariably, planning, execution, and, importantly, testing. While determining the impact of these changes is a challenge in itself, possible ramifications may include a significant, organization wide, impact that affects people, processes and systems, thereby making the need for an orderly and effective transition paramount.

A crucial part of ensuring a successful outcome, then, is a holistic and efficient test tool that simulates a real world transaction environment, and simulates an accurate output. Such a tool must be able to perform its function when input with any existing or prospective test scenario, and the associated data, that the organization might reasonably expect to encounter in a HIPAA related transition, thereby ensuring accuracy in the transition process.

However, current approaches to transaction testing in the HIPAA compliance environment have no provision for managing scenarios through the definition of virtual templates, file analysis, comparison and generation, and managing associated data and entities, through for example, data mining that allows data to be correlated. A further problem associated with the transition process is the complexity of the ANSI X-12 EDI (electronic data interchange) terminology - it is hard for medical professionals without training or orientation related to EDI terminology to prepare or transfer test-case scenarios as the EDI standard is often obscure and hard to grasp. An effective test tool, then, must be able to circumvent such a problem, and reduce dependency on the EDI subject matter expertise ordinarily required for testing. What is needed, then, is to allow users to define structures and constraints in their own language. Such structures and constraints defined may then be leveraged to generate test data, which, in combination with test case scenarios, are used to produce both request and response EDI files for automated testing.

Accordingly, there is a need for a holistic HIPAA transaction testing tool, comprehensible to both business and technical users that is able to manage both scenarios and data to produce request and response EDI files for automated testing.

SUMMARY

A computer implemented method for managing testing for a healthcare systems transition is described. Some aspects of the method may comprise selecting a first test-case scenario, wherein a scenario is a set of business specific rules that control a test-case, identifying a second scenario to be linked to the first scenario linking the first and second scenarios, identifying test data that is to be associated with the test-case scenarios, and generating one or more EDI files from the linked scenarios and the test data.

In an additional embodiment, a system for managing transaction testing is disclosed, the system comprising a processor readable storage medium in communication with a processor, wherein the processor readable storage medium contains one or more programming instructions whereby the processor is operably configured to implement a scenario management module adapted to manage one or more test-case scenarios, and the management of one or more scenarios may comprise selection of a first test-case scenario, wherein a scenario is a set of business specific rules that control a test-case, identification of a second scenario to be linked to the first scenario, linking the first and second scenarios. The system may additionally comprise a data management module adapted to identify data to be used in combination with the one or more test-case scenarios and a file generation module adapted to generate one or more electronic data interchange files.

DRAWINGS

These and other features, aspects, and advantages of the present invention will be better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

FIG. 1 is a computer architecture diagram illustrating a computing system capable of implementing the embodiments presented herein.

FIG. 2 is an illustration of a computing environment in which a system for managing a healthcare systems transition is represented.

FIG. 3 is a flow diagram illustrating a method of managing a healthcare systems transition.

FIG. 4 is a flow diagram illustrating an aspect of an embodiment provided herein for inferring a scenario for a healthcare systems transition.

FIG. 5 is a flow diagram of an aspect of an embodiment provided herein, detailing the identification of data to be used for generating an output.

FIG. 6 is a flow diagram illustrating an aspect of an embodiment provided herein that details the correlation of one or more data entities.

DETAILED DESCRIPTION

The following description is the full and informative description of the best method and system presently contemplated for carrying out the present invention which is known to the inventors at the time of filing the patent application. Of course, many modifications and adaptations will be apparent to those skilled in the relevant arts in view of the following description in view of the accompanying drawings and the appended claims. While the system and method described herein are provided with a certain degree of specificity, the present technique may be implemented with either greater or lesser specificity, depending on the needs of the user. Further, some of the features of the present technique may be used to get an advantage without the corresponding use of other features described in the following paragraphs. As such, the present description should be considered as merely illustrative of the principles of the present technique and not in limitation thereof, since the present technique is defined solely by the claims.

The transition of healthcare systems to mandated HIPAA 5010 standards present opportunities and challenges that impact people, processes and systems in healthcare organizations. Implementing such a transition, however, requires a great deal of cost, in time and effort. Industry estimates, for example, put the cost of 5010 implementation at around 20% of the cost of the previous 4010 standards transition. At the same time, implementing HIPAA 5010 as a mere regulation set dilutes the potential inherent in leveraging this process to improve the efficiency of healthcare delivery and administration. Opportunities exist, for example, to implement greater automation in referral, eligibility and claim inquiry, improve efficiency in claim payments through the use of more accurate and granular codes, as well as to improve interoperability in healthcare. A significant way to achieve each of these is to implement a clean systems transition - a task that is only possible when the systems transition is backed up by a robust systems testing approach.

A typical HIPAA transaction involves the exchange of data between two or more trading partners - this data is, as evident, in a standards compliant EDI (electronic data interchange) format. A variety of transaction types are defined accordingly, such as an eligibility inquiry, which is assigned the number 270, and the corresponding eligibility response, which is assigned the number 271. While a standardized framework of request/response transactions persists, customizations to the particular data format of EDI messages involved are not uncommon across different business cases. An EDI file involved, therefore, may be said to consist of a combination of data and rules that are required for HIPAA standards conformance.

Referring first to Fig. 1, a computing environment 100 comprising a processing unit 110, a communication connection 120, an input device 130, an output device 140, and a processor readable storage medium 150, in operable communication with the processing unit 110, is depicted. The computing environment runs a software 160, the software 160 stored on the computer readable storage medium, and consisting of one or more programming instructions stored in the processor readable storage medium, the programming instructions suitable for managing a healthcare systems transition.

As additionally illustrated in Fig. 2, in the computing environment 200, the storage medium 202 in operable communication with the processor 204 contains at least the programming instructions operable for implementing a scenario management module, as in a block 206, a data management module, as in a block 208, and a file generation module, 210. The operation of each of these modules is described in further detail below.

More specifically, an implementation of a systems testing tool that facilitates a healthcare systems transition is described with reference to Fig. 3. Firstly, the selection of one or more test case scenarios is detailed. Specifically, such scenarios may include various customer specific or business model specific rules which specify the organization of data. In a block 302, then, at least two scenarios for inclusion identified, and, as in a block 304, the scenarios are linked. Further, as in a block 306, test data is identified, and, finally, as in a block 308, one or more EDI files are generated from the combination of test-case scenarios and the data they organize. The overall function of the test tool, then, may be considered in terms of scenario management and, equally importantly, data management.

Test case scenarios, in this context, may be defined as a collection of rules that define, or identify, a unique business case. Given that the testing tool deals in the manipulation of one or more electronic data interchange files, it is evident that these scenarios are either pre-loaded into the tool or extracted from an EDI file that is compliant with HIPAA 4010 or HIPAA 5010 standards.

In either of these instances, the selection of a scenario may be dependent on, as in a preferred embodiment, an analysis of test-case requirements in an attempt to establish the nature of a scenario suitable for a model systems transition. Following such an analysis, one or more scenarios may be reviewed and selected on the basis of said review. Such a review would generally include a comparative analysis between one or more scenarios and the associated test-cases' requirements that were obtained in the analysis step. Scenarios involved in the review may, in some embodiments, have been pre-loaded, provided 'out-of-the-box', or be otherwise available to the customer as a default scenario set. Predefined test-case scenarios of this sort may be stored on a computer readable storage medium and accessible thereby, or they may be stored on a remote machine accessible through a communications network.

Were such pre-loaded scenarios to prove inadequate in comparison with test-case requirements, new scenarios may be defined and added, or existing scenarios may be modified. Specifically, scenarios may be customized by the tool by means of one or more of the following operations:

Firstly, making a situational loop/segment/element in the EDI file mandatory. Secondly, setting minimum and maximum bounds for repeats of a loop or segment or element in the EDI file. Thirdly, restricting the values allowed for an element in the EDI file, and, finally, allowing the user to define the varying nodes, such as the loop /segment/element, in the EDI file. The final option reflects change that is effected when user customization is desired.

Any new or modified scenario may have its rules validated, and any conflicts, if present, pointed out. For example, if a data rule is specified on an element, an ordinal rule cannot be, or, if a parent element is excluded, then a rule operating on the element may become unavailable. Conflicts of this nature may be handled by means of rule validation.

Test-case scenarios may, additionally, be modified, deleted, copied or otherwise added or made accessible or inaccessible. A scenario may also be tagged with a name, and referred to by said name thereafter. For example, a scenario may be tagged in accordance with a desired nomenclature for a set of rules it models.

In an additional embodiment, scenarios may be added to the test tool by means of a scenario inference operation. In order to construct an inferred scenario, an input set of EDI files are analyzed to infer one or more scenarios for import. The input set of EDI files are one or more EDI files that constitute a standard, HIPAA 4010 or 5010 compliant, transaction type. They may be EDI files involved in an eligibility request/response transaction, for example. Referring now to Fig. 4, this input set, then, is analyzed by selecting the transaction type to which the input set of files belongs. Then, as in a block 402, one or more criteria are selected from which a scenario may be inferred. These criteria are derived from data in the EDI files, and may include loops, segments, or elements present therein. Then, as in a block 404, the one or more putative scenarios are grouped and named, and may be saved as a file and used as input for scenario inference, as indicated in a block 406. Then this file is analyzed, as in a block 408. The purpose of such a step is to check whether any new rules inferred from the criteria may be mapped to extant rules. Then one or more scenarios are then derived from the input file, as in a block 410. These scenarios may be stored, and a report detailing them generated if so desired by a user. The comparison report may contain information that highlights one or more missing rules which, if added to the one or more scenarios being compared, may render them equivalent. Such an operation has the benefit of increasing reusability of existing test files, particularly when they are compared with predefined scenarios.

Referring again to Fig. 3, identification of the test data, as disclosed in a block 306, is integral to the generation of an output EDI file. Identification, however, is a multi-step process that may involve data entity definition, data instance creation, correlation of data instances and association of these instances with the previously defined entities.

More substantially, entities are logical data blocks that correspond to a logical block in the HIPAA transaction tree, i.e. they are data blocks consisting of one or more EDI loops, segments or elements. They are, in effect, user friendly data blocks which hide the complexity of a transaction structure, and are generally mapped to HIPAA transaction data elements. Creating entities is complex, and usually requires input from EDI experts. In an example embodiment, they may be added, edited, or otherwise modified to create a logical structure for HIPAA transactions. In sum, entities are self-contained and consistent and may include real time data that are to be populated into an output EDI file.

Referring now to Fig. 5, as in a block 502, one or more entities are first selected. These entities are generally extracted from the EDI transaction tree, and may be identified at any of the field, segment, or element levels of the EDI transaction tree. In an embodiment, one or more data entities may be predefined, or provided 'out-of-the-box' in the testing tool. Such a measure may save a tester the effort of defining data entities from scratch.

In a preferred embodiment, additionally, any existing data entities are checked to see if they are carrying the same concept across transactions, e.g. multiple 'patient' entities across transactions, and they are matched if so. For example, a subscriber entity in a 270 transaction may be matched with a subscriber entity across an 837 transaction. Matched data entities may then be used to populate the tool.

Then, as in a block 504, one or more constraints on each of the entities selected may be specified. When constraints are specified against the aforementioned 'Patient' entity, for example, the 'Patient' entity may be restricted to a set of specified values, or made non-editable, etc. Additionally, when these data are provided from an external source, they are subject to any previously specified rules, or constraints, as well.

Then, as in a block 506, data entities may be named, or defined, under a user defined name. Names for entities provided by the EDI standard may be mapped to a user defined nomenclature, for example.

Then, data from an external data source are loaded, and one or more data instances created thereby. These data instances are associated with each entity, and, as such, each data entity may be reviewed to check whether there are extant data instances with which it is associated. In some aspects, data entities that are predefined may carry similarly predefined data instances. If no data instances are associated with an existing entity, or it is desired to define a new instance for an entity, a data instance may be created by means of loading data from the external source, as in a block 508 of Fig. 5. In some embodiments, these data sources may include user input, a database or a structured file, such as a spreadsheet. These datasets, then, may consist of data that are required to create an EDI file. The data management module described herein gathers and organizes these data, which may then be used to generate an EDI file output, or stored. Data once extracted can be used across all transaction types and scenarios, and may be used in the creation or modification of data entities.

Specifically, data are mapped against an entity to be used during EDI file generation. For example, an entity may be defined as a 'Patient', and a transaction file associated with the 'Patient' may contain such records as name, age etc. These records are mapped against the dataset provided, and used, subsequently, in EDI file generation.

A final step in the identification of data may include, as in a block 510, validation of the externally loaded data. Validation generally involves checking the application of the constraints defined in the data entity. For example, one or more fields in the data entity may be disabled in validation, and no external data may, consequently, be accepted for those fields. Other examples of the effect the application of a validation step may include instances where, if a data entity defines a field as non- editable, and a default value is provided, then the default value will not be tampered with. If the 'Patient' entity is marked as non-editable, for instance, it will maintain its default data, regardless of external input. A further effect of a validation step may include the automatic insertion of a default value for a field where the presence of such a value is necessary, but missing.

Referring now to Fig. 6, a preferred embodiment incorporating the above may include the creation of a correlation database, as in a block 602, the correlation database comprising one or more correlation parameters indicating a correlation between the one or more data instances, and, further, the analysis of a set of any existing test EDI files, as in a block 604, as well as the creation of an association table in the correlation database, as in a block 606, wherein the association table comprises one or more entities and one or more correlation parameters detailing a frequency of occurrence of each of the one or more entities in the one or more test case scenarios and, finally, the derivation of a correlation factor between each of the one or more entities from the association table, as in a block 608.

Like a scenario matching and inference function, the use of correlation parameters may salvage significant utility from existing test files, and simplify a standards transition as a result. For example, some organizations may have extant test files in the HIPAA 4010 format - files that that they use for testing their existing systems. Some of these files may be negative test cases, and some positive test cases. When a correlation analysis is to be performed, these test files are analyzed and an association table consequently created. For example, given three entities - 'hospital', 'doctor' and 'subscriber; an entry is made for each of these in the association table, noting how many times they occur in the test files, and, equally, how many times they occur in conjunction with each other. To illustrate, if, following analysis, a count of the total number of occurrences by a 'Subscriber X' entity = 10, and, similarly, a 'Hospital A' count = 7, a 'Hospital B' count = 3, 'Doctor A' count = 6, 'Doctor B' count = 2, and a 'Doctor C count = 2, then it follows that subscriber X is strongly positively correlated with Hospital A, and strongly negatively correlated with Hospital B.

When 'Subscriber X' is used as a data entity in a positive test case then, 'Hospital A' may be recommended, or automatically chosen, as a data entity for the scenario, i.e. a first entity may be recommended for inclusion in any test case scenario where a second entity that it is strongly correlated with is included. The same process may be applied across all entities, or other logical data blocks, that are included in the test files, as well as scenarios therein. For the generation of a negative test case scenario the same concept applies in reverse. Strongly correlated entities may thus be combined to form a positive test case, or weakly correlated entities combined similarly to form a negative test case. Reuse is also encouraged through the translation of one or more entities, across transactions, which are strongly correlated to a similar entity set.

EDI file generation involves generating different combinations of EDI files for a given transaction scenario. The generated EDI file, or files, has many data blocks and each block has fixed values. The EDI file is structured based on the scenario rule applied on the data. Constraints include the HIPAA specification, including the HIPAA ruleset, and additionally, rules associated with the specific business scenario, as well as that of real-time data gathered etc. The number of files generated depends on the data present for each combination for a given transaction.

In a disclosed embodiment, for example, the generation of EDI files involves, generally, looping through scenario rules, associating data with the data entities accordingly and generating an EDI portion that might be split over multiple files or contain repetitive data based on the elements therein.

In accordance with an embodiment of the present invention, as will be appreciated by those ordinary skilled in the art, the foregoing example, demonstrations, and method steps may be implemented by suitable code on a processor base system, such as general purpose or special purpose computer. It should also be noted that different implementations of the present technique may perform some or all the steps described herein in different orders or substantially concurrently, that is, in parallel.

Furthermore, the functions may be implemented in a variety of programming languages. Such code, as will be appreciated by those of ordinary skilled in the art, may be stored or adapted for storage in one or more tangible machine readable media, such as on memory chips, local or remote hard disks, optical disks or other media, which may be accessed by a processor based system to execute the stored code. Note that the tangible media may comprise paper or another suitable medium upon which the instructions are printed. For instance, the instructions may be electronically captured via optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.

The following description is presented to enable a person of ordinary skill in the art to make and use the invention and is provided in the context of the requirement for a obtaining a patent. The present description is the best presently-contemplated method for carrying out the present invention. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art and the generic principles of the present invention may be applied to other embodiments, and some features of the present invention may be used without the corresponding use of other features. Accordingly, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.

CLAIMS

What is claimed is:

1. A computer implemented method for managing testing for a healthcare systems transition, the method comprising:

identifying at least two scenarios for inclusion in a test-case modeling a healthcare systems transition, wherein:

a scenario is a set of business specific rules that control the test-case; and

the at least two scenarios are identified on the basis of an analysis of one or more requirements associated with the healthcare systems transition; linking each of the at least two identified scenarios;

identifying test data for inclusion in the test-case, wherein the test data to be included comprises one or more data entities, an entity being a representation of a discrete data set, and one or more data instances associated with each of the one or more data entities; and

generating an EDI file from the included linked scenarios and the included test data.

2. The method as claimed in claim 1, further comprising analyzing an input set of electronic data interchange files to infer one or more scenarios for import.

3. The method as claimed in claim 2, wherein inferring one or more scenarios for import comprises:

selecting one or more criteria from which one or more scenarios may be inferred;

specifying a name for each of the one or more scenarios;

receiving an input file from which the one or more scenarios is to be inferred;

analyzing the input file; and

deriving one or more scenarios thereby, wherein one or more rules are derived on the basis of the one or more criteria selected.

4. The method as claimed in claim 1, wherein one or more test case scenarios are predefined.

5. The method as claimed in claim 1, wherein at least one scenario is blank and at least one scenario is non-blank and generating the output EDI file on the basis of the at least one non-blank scenario and the included test data thereby.

6. The method as claimed in claim 1, further comprising modifying one or more rules in a test-case scenario.

7. The method as claimed in claim 6, further comprising validating a modified rule in a test-case scenario.

8. The method as claimed in claim 1, further comprising tagging a test-case scenario with a desired name.

9. The method as claimed in clam 1, further comprising using the generated EDI files for testing.

10. The method as claimed in claim 1, wherein identifying data associated with the one or more test-case scenarios further comprises:

selecting one or more entities from an EDI transaction tree;

specifying one or more constraints on each of the one or more entities selected;

defining the one or more entities selected in a desired nomenclature;

loading data from an external data source and creating one or more data instances thereby, wherein at least one data instance is associated with each of the one or more entities; and

validating the externally loaded data.

11. The method as claimed in claim 10, wherein one or more entities and their associated data instances are predefined.

12. The method as claimed in claim 10, wherein the external data source from which a data instance is populated comprises manual input of data by a user, a database, a spreadsheet, or any combination thereof.

13. The method as claimed in claim 10, further comprising:

creating a correlation database, the correlation database comprising one or more correlation parameters indicating a correlation between the one or more data instances;

analyzing one or more test files;

creating an association table in the correlation database, wherein the association table comprises one or more data instances and one or more correlation parameters detailing a frequency of occurrence of each of the one or more data instances in the one or more test case files; and

deriving a correlation factor between each of the one or more instances from the association table.

14. The method as claimed in claim 13, further comprising combining one or more instances on the basis of their associated correlation factor, wherein one or more strongly correlated instances are combined to form a positive test case and one or more weakly correlated entities are combined to form a negative test case.

15. The method as claimed in claim 13, further comprising providing a recommendation for the inclusion of at least one instance in a test case, wherein

the instance that is recommended for inclusion is strongly correlated with one or more instance that are present in the test case scenario.

16. The method as claimed in claim 13, further comprising translating one or more instances which serve a similar purpose across one or more transactions.

17. The method as claimed in claim 16, further comprising combining the one or more data instances with the correlation factor, and producing one or more electronic data interchange files thereby.

18. The method as claimed in claim 13, wherein generating an EDI file comprises:

analyzing one or more rules provided by the linked scenarios; associating data with one or more entities on the basis of the rules provided; and

generating one or more EDI files thereby.

19. A system for managing testing for a healthcare systems transition, the system comprising:

a processor readable storage medium in communication with a processor, wherein the processor readable storage medium contains one or more programming instructions whereby the processor is operably configured to implement:

a scenario management module adapted to manage one or more test-case scenarios, wherein a scenario is a set of business specific data against which a set of rules is applied, the management of one or more scenarios comprising:

identifying at least two scenarios for inclusion in a test-case modeling a healthcare systems transition, wherein:

a scenario is a set of business specific rules that control the test-case; and

the at least two scenarios are identified on the basis of an analysis of one or more requirements associated with the healthcare systems transition; and linking each of the at least two identified scenarios;

a data management module adapted to identify and include data in the test-case wherein:

the included test data comprises one or more data entities, an entity being a representation of a discrete data set; and

one or more data instances associated with each of the one or more data entities in combination with the one or more test-case scenarios; and

a file generation module adapted to generate one or more electronic data interchange files from the included scenarios and data.

20. The system as claimed in claim 19, further comprising analyzing an input set of electronic data interchange files to infer one or more scenarios for import.

21. The system as claimed in claim 20, wherein inferring one or more scenarios for import comprises:

selecting one or more criteria from which one or more scenarios may be inferred;

specifying a name for the each of the one or more scenarios;

receiving an input file from which the one or more scenarios are to be inferred;

analyzing the input file; and

deriving one or more scenarios thereby, wherein one or more rules are derived on the basis of the one or more criteria selected.

22. The system as claimed in claim 19, wherein one or more test case scenarios are predefined.

23. The system as claimed in claim 19, further comprising modifying one or more rules in a test-case scenario.

24. The system as claimed in claim 23, further comprising validating a modified rule in a test-case scenario.

25. The system as claimed in claim 24, further comprising tagging a test-case scenario with a desired name.

26. The system as claimed in clam 25, further comprising using the generated EDI files for testing.

27. The system as claimed in claim 19, wherein identifying data associated with the one or more test-case scenarios further comprises:

selecting one or more entities from an EDI transaction tree, wherein an entity is a representation of a discrete data set;

specifying one or more constraints on each of the one or more entities selected;

defining the one or more entities selected in a desired nomenclature;

loading data from an external data source and creating one or more data instances thereby, wherein at least one data instance is associated with each of the one or more entities; and

validating the externally loaded data.

28. The system as claimed in claim 27, wherein the at least one data instance is tagged in accordance with a desired nomenclature.

29. The system as claimed in claim 27, wherein one or more entities and their associated data instances are predefined.

30. The system as claimed in claim 27, wherein the external data source from which a data instance is populated comprises manual input of data by a user, a database, a spreadsheet, or any combination thereof.

31. The system as claimed in claim 27, further comprising:

creating a correlation database, the correlation database comprising one or more correlation parameters indicating a correlation between the one or more data instances;

analyzing one or more test case files;

creating an association table in the correlation database, wherein the association table comprises one or more data instances and one or more correlation parameters detailing a frequency of occurrence of each of the one or more data instances in the one or more test case files; and

deriving a correlation factor between each of the one or more entities from the association table.

32. The system as claimed in claim 31, further comprising combining one or more data instances on the basis of their associated correlation factor, wherein one or more strongly correlated data instances are combined to form a positive test case and one or more weakly correlated data instances are combined to form a negative test case.

33. The system as claimed in claim 32, further comprising providing a recommendation for the inclusion of at least one data instance in a test case, wherein the data instance that is recommended for inclusion is strongly correlated with one or more data instances that are present in the one or more test case files.

34. The system as claimed in claim 33, further comprising translating one or more data instances which serve a similar purpose across one or more transactions.

35. The system as claimed in claim 31, further comprising combining the one or more data instances with the correlation factor, and producing one or more electronic data interchange files thereby.

36. The system as claimed in claim 31, wherein generating an EDI file comprises:

analyzing one or more rules provided by the linked scenarios; associating data with one or more entities on the basis of the rules provided; and

generating one or more EDI files thereby.