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.

Submitting Test Results into Gazelle

The RFD Testing System does not produce a result file that can be loaded into Gazelle. The web based user interface does provide evaluation and reporting of your transactions. 

Make a screen capture of the web user interface that shows the result of your test and upload that into Gazelle as evidence that you have completed the specific test successfully.

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 version in RFD-version.war contains the release date (e.g. RFD-20151023.war).

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

This section is intended for people testing the following actors:

• Form Filler

• Form Manager

• Form Processor

The test cases make use of form data defined by IHE supplements. The supplements define both the elements and the mapping of pre-population data to forms. The RFD Testing System will test the CDA pre-population documents provided by Form Fillers and will map those data to defined forms as a by-product of testing. The RFD Testing System also has sample CDA documents that the Form Manager and Form Processor actors under test need to accept and map to form data.

Specification data for pre-population documents supported by the RFD Testing Software is available in spreadsheets (see links below). Each spreadsheet contains two sheets, “Mapped Attributes” and “Derivation & XPath”.

 The "Mapped Attributes" Sheet

The “Mapped Attributes” sheet varies in format from profile to profile. In all cases, the first column contains the name or code given to the element in the Integration Profile, and the second column indicates if the element is currently being tested. There may be additional columns in the case where we have multiple sample CDA pre-population documents. Those additional columns are used to indicate the coverage of pre-population data in the different sample CDA documents.

The "Derivation & XPath" Sheet

The “Derivation & XPath” sheet contains derivation rules and XPaths for all data element included in testing. For simple items, only an XPath is needed, as in these from the LDS pre-population:

For elements using derivation rules, the XPaths of Logical Variables as well as the derivation rule is included, as in this description of the “HEPB” element in the LDS pre-population document:

Here are the links to the spreadsheets for Profiles currently supported in RFD testing:

Display of Data Elements by RFD Testing Software

The forms generated by the RFD Testing System are simple html documents, which should display in any browser. While different forms are generated depending on the Integration Profile being tested and the particular CDA pre-population document sent, they all have the same basic format, the elements derived from the pre-population data are listed in a table with (at least) two columns, “Element Name” and “Element Value”, as can be seen in this screen capture:

Notice that, for simplicity, the component fields in some elements, such as names and addresses, are combined. For the “Baby Facility State ID” element, which is an id type, the extension is shown in a third column, under the header “Coding system”. Coded Data Elements have both the display name and the coding system OID in this column, as can be seen in the “Decedent Race” element in this shot from a VRDR form:

The VRDR screen shot also includes a “Prepopulation Document Type”, which is included on the form in Profiles where more than one pre-population CDA document type is possible.

For Elements which are derived using a derivation rule and one or more items from the pre-population document, the result of the derivation is shown in the “Element Value” column, and a command button labelled “Show Derivation Details” appears in the “Coding System” column. When this button is clicked, a box opens which shows the derivation rule, and the XPath expression(s) for the logic variable(s) used in the derivation. Underneath these is a table showing any Logic Variables which were found in the pre-population document. Here is a screenshot of the derivation details for a positive Chlamydia finding in an LDS pre-population document:

Here you can see that a Problem Code value of 105629000 (Chlamydial infection) was found, resulting in a derived value of “Y” for the CHAM element. Clicking the “Hide Derivation Details” button at the bottom of the box will close it:

Support

Support Page