Overview

The RFD Testing System is intended to provide conformance tests for systems that implement actors in the IHE Retrieve Form for Data Capture (RFD) integration profile as well as other profiles that use RFD as a substrate.

The screen capture below shows a subset of the tests defined for this tool and demonstrate a naming convention. You could think of each test in the context of a use case and/or combination of RFD parameters and pre-population documents. We use the same test names for all actors, but we do tailor the test instructions, data and steps by actor.

Each test name has a three part structure that has these components:

• Profile Acronym

• ITI-34 Parameter Map

• Further Test Specification (not always present)

Profile Acronym: The first several letters indicate the Integration Profile that is the subject of this test. The RFD tests are baseline tests for that profile. For example, in the test BFDR_E_1_10000_LDS_A (taken from the screenshot below) the first characters (BFDR_E) indicate the Integration Profile Birth and Fetal Death Recording - Enhanced.

ITI-34 Parameter Map: The ITI-34 Retrieve Form transaction has a number of parameters supplied by the Form Filler.  See the screen capture below from ITI TF 2:3.34.4.1.2

See the table below. We list the same parameters with letter designations (a, b, c, d, e, f). We list those parameters in order below.

The second part of the test name is a Parameter Map which contains “1” when we expect the Form Filler to submit a value for the parameter and “0” when the Form Filler omits a value for the parameter (nil, null string, etc.). The format of the map is:

a_bcdef

where a indicates the parameter prePopData and (b, c, d, e, f) indicate the other parameters.

These are examples:

0_10000 indicates no prePop data, a Form ID is supplied with no further parameters

1_10100 indicates a test with prePop data, a Form ID and an archive URL

Not all combinations are tested. Some combinations indicate error conditions. For example, when “b” (workflowData / formID) = 0, this indicates an error case where the tool would submit a retrieve form request with no value for formID.

Further Test Specification: These are shorthand notations that we use to further specify a test case. The naming convention will evolve as we develop more tests. Consider two of the examples in the screen capture:

• BFDR_E_1_10000_LDS_A

• BFDR_E_1_10000_LDS_A

These are tests of the BFDR-E (Birth and Fetal Death Reporting - Enhanced) profile using prePop documents. LDS_A and LDS_B indicate that the prePop documents are Labor and Delivery Summary for Vital Records (LDS-VR)  documents. The A and B notations indicate that there are content differences between the two LDS documents. In this example, and in many other tests, you will have to read the test description to find those requirements / differences.

Test Instructions

The testing system is a web based system that provide both test instructions and test controls within the web application.

1. Complete the steps outlined in the Installation and Configuration section or use the hosted version of the software.

2. Use a web browser to open the main page of the system.

1. If you install the system, the URL is likely http://localhost:8080/RFD

2. The URL of the hosted system is http://gazelle-gold.wustl.edu/RFD

3. See the screen capture below. Determine which actor you want to test. If you have a Form Filler actor, click on the Form Filler link. You will be taken to a page that lists all possible tests for your actor with links to documentation and test software.

Which Test Cases Do I Run?

The RFD profile defines a baseline set of functions, and we have a small number of tests for actors in the baseline profile. You should run each of the baseline RFD tests. Note that some of the tests require you to create or manage a form that is of no interest to your business. Look ahead to the tests that are specific to your content (e.g., the Birth and Fetal Death Reporting - Enhanced profile) and spend your time on those tests.

Once you have the baseline functions completed, look at the tests for the other content profiles that use RFD as a substrate. These other tests will have data/forms that are specific to the content defined by the various RFD-based profiles. We have tried to display the matrix of tests to make it obvious which ones are appropriate based on the integration profile that your software implements.

If you are given a list of tests to run by some other system (e.g., the IHE Gazelle software for pre-Connectathon or Connectathon testing), then you should execute the tests in that list.

Installation and Configuration

Software Requirements

1. You will need a Java Servlet container. We develop and test using Apache Tomcat 8.0.

2. You will need Java version 8 or higher. You can use a JRE or a JDK. We recommend you use the Oracle version of Java.

3. We develop and test using a Linux system. This should also work under MacOS and Windows. The safest path is to use Linux.

Installation Instructions

1. Download the file RFD-version.war from https://wustl.app.box.com/IHE; look in the RFD folder.. The value for version in the filename uses the standard 3 part naming convention: major.minor.revision.

2. Rename the file to RFD.war.

3. Deploy the RFD.war file in your favorite servlet container. In our Apache Tomcat environment, that means you drop RFD.war in the webapps folder of tomcat.

4. Start the servlet container.

5. You can now point a web browser to the home page of the testing system. Assuming a default installation of tomcat that uses port 8080, the URL would be:

1. http://host:8080/RFD

6. For other containers or non standard tomcat installations, the port number might be different. The RFD part of the URL is fixed by the name of the WAR file (RFD.war).

Hosted Application

We maintain an instance of the RFD testing system on a server at our institution. The test software and test cases on the hosted application are the same as you will find on the version that you download. Considerations for using the hosted application include:

• You may need to alter your firewall settings to be able to send/receive messages

• If there are exceptions that get logged to local log files, you will have to request for support help.

• You have access to the log files on a local copy.

• We hope that the application is robust enough that you can see all of the information that you need through the web user interface. There may be times when we have to revert to log files.

The URL for the hosted application is:

http://gazelle-gold.wustl.edu/RFD

Mapping of Pre-Population Data to Forms

Support