Recommended
Practice Guidelines for Test Profiles
The name of the organization
completing the Test Profile.
e.g.
Fairview Health Services
Everything assumed to be true regarding the transaction being profiled.
e.g. Test file is indicated by “T” in field ISA 15.
Connectivity is established.
The name, phone number and/or email of the contact for this specific transaction testing.
e.g. John Doe
(612)555-1234
A list of conditions that may be required of a Trading Partner prior to or during testing. A checked box indicates that that condition is required.
Member Number List – A list
of member’s names and #’s included in the test being submitted.
Non-Compliance List –
Although a Trading Partner may not be totally compliant, there may still be
value in starting testing. In these
cases, a list of known non-compliant issues may be required.
Validation Requirement – Prior
to point-to-point testing, validation utilizing a validation product may be
required. This validation may be either
conducted internally (e.g. self-validation) or externally (e.g. third party
vendor).
Volume Requirement – Volume
requirements may be required during point-to-point testing. If volumes are required, the specifics of
this requirement need to be detailed in the Notes section.
Scenarios Required –
Specific test scenarios may be required in order to complete successful
testing. If they are required, the
completed Test Scenarios document needs to accompany the Test Profile.
EDI Trading Partner Agreement – A Trading Partner Agreement needs to be
signed prior to point-to-point testing.
None –
Selected when there are no pre-test
conditions required for point-to-point
testing.
Other – Any
requirements for point-to-point testing not specified above.
Any specific notes regarding point-to-point testing.
e.g. See Connectivity/File Security Guidelines.
A description of the Source System and the EDI System consisting of the following: translator being used, method for loading data into the test environment, and parameter sets.
e.g. EDI System: Dedicated test environment replicating production. Test tables replicate production. Automated process flow not utilized for
test.
The time an automated process
begins to run available test files. If
none, specify “on-demand”
e.g. Daily – 2:00 am & 6:00 am
The estimated time it takes to complete a test cycle.
e.g. Two days from request to submission of the test file. Remits can be posted immediately.
Method for notifying the Trading Partner of the test results during and after testing. This may include the use of the 997 transaction.
e.g. Email and/or voice mail of test results to trading partner contact.
997s will be generated by recipient and sent back to the clearinghouse, but not forwarded to the submitter.
Method for communicating changes in the Test and/or Production system to Trading Partners.
e.g. Daily changes within our test environment. Notification of EC EDI Team of potential impact. No communication to trading partner unless necessary.
Departments within an organization
responsible for the testing process.
e.g. Shared responsibility between submitter’s business and IT resources.
A list of guides and documents identifying release specifications and Trading Partner specific requirements.
e.g.
Professional – 004010X098A1
A description of each step in the
testing methodology.
e.g. Translation of Test File
Send 997 if agreed upon for testing with trading
partner.
Compliance Errors – See Step #6
No compliance Errors – See Step #7
The amount of time it takes a
specific test process to complete.
e.g. 2 Hours
The step(s) that need to be
completed before beginning this process step.
e.g. #4
The department(s) or group(s)
responsible for each test process.
e.g.
Electronic Commerce EDI/ Trading Partner
Any additional comments specific
to a particular test process.
e.g. This
is done via the batch cycle for posting cash in test.