Cardinality Specification and Testing Recommendations

1. Cardinality Specification and Testing Recommendations LOI and LRI MU Certification September 9th, 2013 Draft 1.2

2. Overview

3. Cardinality Definition • Cardinality identifies the minimum and maximum number of occurrences that a message element must have in a conformant message • Some elements shall always be present (e.g., cardinality [1..1], [1..n]) • Other elements shall never be present (e.g., cardinality [0..0]) • Other elements may or may not be present—zero or more occurrences (e.g., cardinality [0..n]) • A conformant message must always contain at least the minimum number of occurrences, and shall not contain more than the maximum number of occurrences

4. How is Cardinality Tested? • Limited case - if cardinality specification is [1..5], per the standard a conformant message must • always contain at least one occurrence • and shall not contain more than five occurrences • Senders must be capable of • sending up to 5 instances of the element and • Receivers must be capable of • “processing” 5 elements. • How the receiver processes those elements should be indicated with associated functional requirements for the element. • Testing the sender • we have a test case where we provide data for 1 instance of the element and validate based on that. • In another test case, we provide data for 5 instances and we would validate to check that 5 instances were in the message. • Another test case we could provide data for 6 instances. Now the application interface may very well allow for this and this is OK (because it could support other use cases), what we would test for here is that only 5 are sent (present in the message). If 6 instances are sent then the application is not conformant. • If we don’t provide any data, the application should recognize that data is needed. • Testing the receiver • we would inspect that the number of elements we sent are correctly processed/associated/stored depending on the element.

5. How is Cardinality Tested? • Unlimited case • a cardinality of [1..*] indicates that implementations must be capable of supporting an unlimited number of instances for that element • Currently, an arbitrary number is selected for testing when the maximum upper limit is indicated with “*” • Testing proceeds exactly as indicated on the previous slide since an arbitrary upper limit is selected, i.e., [1..*]  [1..x] • In the case of “*”, implementers are not excused from supporting unlimitedoccurrences—there is just a practical limit that can be tested • In current MU testing, under-testing is typical because creation of relevant test cases usually is difficult and resource-consuming • NIST welcomes guidance for testing a “minimum upper limit” for unlimited cardinality elements.

6. Cardinality Conformance Assessment To Be Done

7. Recommendations for LOI/LRI Implementation Guides • The specification of “*” for unlimited occurrences of an element should remain as is • That is, systems are required to support unlimited “*” occurrences of elements • This applies for both the Sender and Receiver • There is no need for the proposed [0..x, *] conformance construct; the “x” is described in the Testing Guidance document and is only guidance not a requirement (i.e., unlimited, when specified, remains the requirement)—nothing has effectively changed for implementers • What is new is that guidance for testing is being specified in a separate document and does not affect implementation requirements.

8. Lab IGs Behavioral Guide • Indicate in this guide the behaviors of a receiving system in error circumstances • Example 1: no element is sent where at least 1 is required • Example 2: Cardinality is [1..5] and the sender (non-conformant) sends more than 5 instances. Receiver is conformant and can only accept 5 instances • Example 3: Sender sends more than receiver can handle (receiver is non-conformance but may implement “practical upper –limit”, but in case of failure it is better to indicate this to the sender then process with missing information—that is, handle in another workflow, potentially manually. • Behavioral options for the receiver • Reject message and ACK with Fatal Error • Hard stop, i.e., for an LOI message, the lab / result would not be processed • Fatal error is returned • Process message and ACK with Warning/Alert Error • Proceed with warning—alert sender of exceeding limits (as well as missing/incorrect information), but proceed with processing the lab order/result • For both LOI and LRI, the appropriate behavioral option is determined based on an element by element basis

9. Processing Requirements – Segments(In Process)

10. Processing Requirements – Elements(In Process)

11. Testing Guidance Document • Will contain guidance for testing elements designated with unlimited “*” cardinality • For each element, a minimum upper limit of instances will be specified to indicate NIST testing for MU certification • The determination of the minimum upper limits is based on a review of the upper limit of practical clinical scenarios • It is important to note that the limits are recommendations and do not replace implementation requirements; vendors are still required to support an unlimited number of occurrences • NIST will follow the recommendations provided; however, at NIST’s discretion an arbitrary higher minimum upper limit could be tested for a few selective elements • Vendor’s EHR technology will be expected to demonstrate that the system supports up to this number of instances • NIST testing can exceed the suggested minimum upper limit of instances, requiring vendor’s EHR technology to demonstrate their system supports a higher number of instances (for example, for [1..*] where 5 is the suggested upper limit, NIST could test for 7) • Test Guide + Behavior Guide ≠ Compliance

12. Minimum Upper-Limit Test Guidance – Segments(In Process) Note: Upper Limits are intended as starting points for discussion only

13. Minimum Upper-Limit Test Guidance – Elements(In Process) Note: Upper Limits are intended as starting points for discussion only

14. HL7 V2 Conformance Chapter • Update Chapter 2B to better define cardinality and the requirements it places on implementers • Update as part of V2.8.1 or V2.8.2? • Describe in a table the implementation and operational requirements for cardinality for both sender and receiver (similar to the table created for usage in V2.8)—see next slide • Provide a conformance assessment table for cardinality and appropriate (options) behavior of the receiver in error circumstances

15. Cardinality Requirements 1m must be greater than 1 and n must be greater than or equal to m; the case where m equals 1 is addressed separately.