This “Read This First” test helps to prepare you to test RFD-based profiles at an IHE Connectathon.

A Pre-Connectathon Task for Form Managers & Form Processors

Documenting RFD_Form_Identifiers: This is a documentation task. We request all Form Managers and Form Processors to help their Form Filler test partners by documenting the Form Identifiers (formID) that the Form Fillers will use during Connectathon testing. Follow the instructions in preparatory test RFD_formIDs

Overview of RFD Connectathon Testing

RFD and its 'sister' profiles:

The number of IHE profiles based on RFD has grown over the years.  These 'sister' profiles re-use actors (Form Filler, Receiver, Manager, Processor, Archiver) and transactions (ITI-34, -35, -36) from the base RFD profile.

Starting at 2016 Connectathons, to reduce redundant testing, we have removed peer-to-peer tests for RFD only.  If you successfully complete testing for an actor in a 'sister' profile, you will automatically get a 'Pass' for the same actor in the baseline RFD profile.  For example, if you "Pass" as a Form Filler in CRD, you will get a "Pass" for a Form Filler in RFD for 'free' (no additional tests).

Similar test across profiles:

Baseline Triangle and Integrated tests: These RFD tests exercise the basic RFD functions Retrieve Form and Submit Form.

"Triangle" and "Integrated" refer to the combinations of actors in the tests. A Triangle test uses a Form Filler, Form Manager and Form Receiver (triangle). An Integrated test refers to the Form Processor that is an integrated system (supports both ITI-34 and ITI-35); the Integrated test uses a Form Filler and a Form Processor.

CDA Document Tests: We have tried to be more thorough in our definitions of tests for CDA documents; we still have some work to do. There are “Create_Document” tests that ask actors that create CDA documents to produce a document and submit that document for scrutiny/validation by a monitor. There are test sequences that need those documents for pre-population or as an end product; you cannot run those tests until you have successfully completed the “Create_Document” test. We have modified the test instructions for the sequence tests that use CDA documents to require the creator to document which “Create_Document” test was used. We do not want to run the sequence tests before we know we have good CDA documents.

Archiving Forms:  We have a single test -- "RFD-based_Profiles_Archive_Form" to test Form Archivers and Form Fillers that support the 'archive' option.  There are separate tests for archiving source documents.

Testing of options: IHE does not report Connectathon test results for Options in IHE profiles. We readily admit that the tests that cover options will vary by domain and integration profile. If you read the tests in domains other than QRPH (or even in QRPH), you may find profiles that have no tests for named options. We continue to try to enhance tests for named options and other combinations of parameters found in the QRPH profiles.

1. This has created an explosion of tests. You can look in the BFDRe, FP, SDC and VRDR tests and see this. BFDR-E and VRDR are interesting because they specify two different classes of pre-pop documents. SDC has three named options that control the Retrieve Form transaction. Finally, we still have to consider the Form Processor vs. Form Manager + Form Receiver issue.
2. This is mainly directed at Form Fillers, but is relevant for other actors: If you have registered as a Form Filler with multiple options (say in SDC for HTML Package, URI Form and XML Form), you only have to complete testing for one of the paths to receive Connectathon credit. We are happy to work with you to test the other options; we do not have the systems in place for our public reporting to make this distinction.
3. An option that you support might be something we need to test in order to validate a different actor from a different organization. If you decide to not test an option, we may still request your help with that option to help test another system for whom that behavior is required.

ATNA Logging: If you implement the ATNA profile, one of the requirements is that you send audit messages for certain transactions, primarily those that carry PHI. The ITI-35 can be a PHI export transaction, implying that Form Filler who also supports ATNA should send an audit message. This is an issue for a Form Filler when the form was retrieved as an unencoded form (just retrieved the Form URI); the Form Filler does not actually have control over the form.

If your Form Filler has requested an encoded form and has an XML form to process, it does have control over the ITI-35 transaction and should be able to send the appropriate audit message. The same issue exists for the ITI-36 Archive Form transaction.

Form Instance Identifiers: The RFD profile discusses the concept of partial or interim storage of a form. In order to make this work, the Form Filler needs to have a Form Instance ID to retrieve the correct instance of the form that was stored. There are two different mechanisms for a Form Filler to obtain a Form Instance ID:

1. The Form Instance ID is an optional field in the response to ITI-34.
2. The Form Instance ID is an optional field in the response to ITI-35.

That is, the Form Processor or Form Manager is going to control when the Form Instance ID is returned to the Form Filler. We need to get clarification from the ITI Technical Committee if the intended sequence included the Form Filler obtaining that Form Instance ID from the ITI-34 or from the ITI-35 transaction. Until we have that clarification, we will have to work with test participants and their interpretation of this mechanism.

Use of the Gazelle Proxy

Because RFD transactions are generally not sent over TLS connections (unless required by a specific profile), RFD tests are good candidates to use the Gazelle proxy. It will record HTTP transactions and allow you and the monitors to review those logs in a centralized manner.  We highly encourage you to use the proxy when performing this test.   It will allow you to easily see the messages exchanged between test partners and to document them for the monitor.

Evaluation

There is no result to upload into Gazelle Test Management for this informational test.