It is important to provide users with numerous examples of the scenarios covered by the implementation guide. Such guidance gives implementers insight into how the specification is expected to be interpreted and applied. The NIST Test Case Authoring and Management Tool (TCAMT, https://tcamt.nist.gov ) is a productivity tool that can be used to create use case scenarios and example messages. The foundation of TCAMT is the computable specification model created in IGAMT. Targeted test cases are critical for assessing the capabilities of the system being tested. TCAMT allows domain experts to create test cases for specific scenarios and capabilities, including functional requirements. Test cases provide context, which expands the scope of testing. Without context, a validation tool cannot test a message exhaustively for conformance to all requirements specified in the implementation guide. TCAMT has been used to create test cases for ONC EHR certification, test cases for HIMSS IIP EHR certification, and template messages for the American Immunization Registry Association (AIRA) assessment, and this tool can be used by implementers to create customized test cases.
TCAMT is a tool used to create HL7 v2.x test plans that contain one or more (typically many) test cases. Key features in TCAMT include test plan creation (narrative and computable), IGAMT XML profile import, HL7 v2 message creation and import, constraint editing, constraint and messaging templates, and multiple export formats. A test case can consist of one or more test steps. A test step can be an HL7 v2.x interaction or a manual step such as visually inspecting the contents of an application’s display screen. Each test case and test step can consist of a test description, pre- and post-conditions, objectives, evaluation criteria, and additional notes and comments. Test steps for an HL7 v2.x interaction contains an HL7 v2 message (with specific data) that aligns with the XML conformance profile created from IGAMT (Not necessarily conformant data; invalid data may be used in the testing process).
Targeted test cases are critical for assessing the capabilities of a system. TCAMT allows domain experts to create test cases (that include example messages) for certain scenarios and capabilities. Test cases provide context, which expands the scope of testing. Without context, a validation tool cannot test a message exhaustively to all requirements specified in the implementation guide. For example, elements with “required, but may be empty (RE)” usage, elements with “conditional usage (C)”, or elements with cardinality greater than “1” cannot be assessed without targeted tests. A message that is validated against the requirements of a conformance profile without any provided context is called “context-free testing”. A message that is validated against the requirements of a conformance profile and with a provided context is called “context-based testing” . The test cases provide context, and TCAMT is a tool that allows users to create the test cases.
A key design component in TCAMT is its use of the XML profiles created in IGAMT as a foundation. The message definition defined in the profile provides the foundation such that data associated with each message element of interest can be specified. TCAMT also allows the user to enter additional assertion indicators based on what they want to test. For example, for an element with a usage of “RE”, the user can provide data that are expected to be entered into the sending system for the element and can select an assertion indicator. There are several assertion indicators that could be selected, for example, “presence”. In this case, if the user provides test data and selects the indicator of “presence”, a constraint is generated by TCAMT and is provided to the validation. For elements with “RE” usage, the element must be supported by the system-under test (SUT), but in a given message instance the element may not be populated. For this construct, the tester wants to ensure that the implementation has, in fact, included support for the element.
In a context-free environment, the absence of data in a message is not a conformance violation for elements with “RE” usage. However, in the example test case described above, data were provided, and a presence constraint was specified. Now, when a message created for this test case is validated, the additional constraint triggers an assertion for the presence of data for this element. This method is one way to determine support for the element.
Via TCAMT, the user can create an unlimited number of test cases and test a broad spectrum of requirements. Other constraint indicators can be used to test for specific content or for the non-presence of an element. Additionally, test data can be provided to trigger conditional elements. In other instances, support for certain observations may need to be ascertained. In such cases, test data for specific observations (e.g., in an immunization forecast, the vaccine group, earliest date to give, and due date) can be provided, requiring the message instance to contain an OBX segment for each observation. The test case might be set up to expect certain codes to ensure each observation (capability) is implemented by the system. TCAMT provides the mechanisms to conveniently and consistently create test cases. Output from TCAMT provides the additional constraints that are interpreted by the validation engine.