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

2 Overview Issue – handling of cardinality requirements How is cardinality tested; limited and unlimited? What requirements does unlimited “*” cardinality place on the implementers? What should vendors do when dealing with non-conformant messages? What should vendors do when they are non-conformant? Four Areas of Clarification and Recommendations LOI/LRI Implementation Guide Lab (set of IGs) Behavioral Guide Testing Guidance Document HL7 V2 Chapter 2B Conformance - Clarification 2

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 3

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. 4

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 unlimited occurrences—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. 5

6 Cardinality Conformance Assessment Rob TODO 6

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. 7

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 1.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 2.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 8

9 Processing Requirements – Segments (In Process) 9 IDSegment DescriptionLOI Cardinality/UsageLRI Cardinality/Usage BehaviroBehavior UsageCardinalityUsageCardinalityLOILRI Order Begin [1..*]R CER NTE Notes and Comments SegmentRE[0..*]RE[0..*]CER PRT Participation Information SegmentVaries (1) [0..5][0..*]n/a CEn/a DG1 Diagnosis SegmentC(R/RE) (2) [0..*]O CEn/a OBX Observation/Result SegmentRE[0..*]R CER SPM Specimen InformationC(R/O) (3) [0..*]RE[0..*]CE Note: If there is only one non-optional segment in the repeat, then the repeat is not listed and the segment is used (1) sender one for each OBR-28 (Results Copies to), Receiver O (2) if PV1-20 is valued "T" (third party) (3) if OBR-7 (Observation Date/Time) is not valued '0000' Behavior on unable to consume CEConsume as much as possible, notify sender with non-fatal error code RReject Message and notify sender with fatal error code n/aNot Applicable

10 Processing Requirements – Elements (In Process) 10 LOILRI Behavior SegmentElementElement NameData TypeUsageCardinalityData TypeUsageCardinalityLOILRI MSH ERR C(R/O)[0..*] C(R/O)[0..*] CE MSH 21Message Profile IdentifierEIR[1..*]EI_GUR[1..*] R R PID 3Patient Identifier ListCXR[1..*]VariesR[1..*]CE PID 5Patient NameXPNR[1..1]XPNR[1..*]CE PID 10RaceCWE_CR1RE[0..*]CERE[0..*]CE PID 11Patient AddressXADC(R/RE)[0..*] O CEn/a PID 13Phone Number – HomeXTNVaries[0..*] O CEn/a PID 14Phone Number – BusinessXTNVaries[0..*] O CEn/a ORC 23Ordering Facility Phone NumberXTNVaries[1..*] O CEn/a OBR 13Relevant Clinical Information O CWE_CRERE[0..*]n/aCE OBR 28Result Copies ToXCNRE[0..5][0..*]VariesC(R/X)[0..*]CE OBR 49Result Handling (Table 507)ISVaries CWE_CRERE[0..*]n/aCE OBX 8Abnormal Flags (Table 78) O ISRE[0..*]n/aR NTE 3CommentFTR[1..*]FTR[1..*]CER SPM 5Specimen Type Modifier (Table 541)CWE_CRE1Varies[0..*] O ?n/a SPM 6Specimen Additives (Table 371)CWE_CRE1Varies[0..*] O ?n/a SPM 9Specimen Source Site Modifier (Table 542)CWE_CRE1Varies[0..*] O ?n/a SPM 21Specimen Reject Reason (Table 490) O CWEVaries[0..*]n/aCE SPM 24Specimen Condition (Table 493) O CWEVaries[0..*]n/aCE

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 11

12 Minimum Upper-Limit Test Guidance – Segments (In Process) 12 IDSegment DescriptionLOI Cardinality/UsageLRI Cardinality/Usage Upper Limit UsageCardinalityUsageCardinalityLOILRI Order Begin [1..*]R NTE Notes and Comments SegmentRE[0..*]RE[0..*] 3030? PRT Participation Information SegmentVaries (1) [0..*]n/a 15n/a DG1 Diagnosis SegmentC(R/RE) (2) [0..*]O 12n/a OBX Observation/Result SegmentRE[0..*]R 3080 AP Report ?3000 (4) SPM Specimen InformationC(R/O) (3) [0..*]RE[0..*]20 Note: If there is only one non-optional segment in the repeat, then the repeat is not listed and the segment is used (1) sender one for each OBR-28 (Results Copies to), Receiver O (2) if PV1-20 is valued "T" (third party) (3) if OBR-7 (Observation Date/Time) is not valued '0000' (4) Needs to accommodate AP reports with one line per OBX Note: Upper Limits are intended as starting points for discussion only

13 Minimum Upper-Limit Test Guidance – Elements (In Process) 13 LOILRI Upper Limit SegmentElementElement NameData TypeUsageCardinalityData TypeUsageCardinalityLOILRI MSH ERR C(R/O)[0..*] C(R/O)[0..*] 10 MSH 21Message Profile IdentifierEIR[1..*]EI_GUR[1..*]10 PID 3Patient Identifier ListCXR[1..*]VariesR[1..*]55 PID 5Patient NameXPNR[1..1]XPNR[1..*]15 PID 10RaceCWE_CR1RE[0..*]CERE[0..*]55 PID 11Patient AddressXADC(R/RE)[0..*] O 3n/a PID 13Phone Number – HomeXTNVaries[0..*] O 3n/a PID 14Phone Number – BusinessXTNVaries[0..*] O 3n/a ORC 23Ordering Facility Phone NumberXTNVaries[1..*] O 3n/a OBR 13Relevant Clinical Information O CWE_CRERE[0..*]n/a10 OBR 28Result Copies ToXCNRE[0..*]VariesC(R/X)[0..*]15 OBR 49Result Handling (Table 507)ISVaries CWE_CRERE[0..*]55 OBX 8Abnormal Flags (Table 78) O ISRE[0..*]n/a5 NTE 3CommentFTR[1..*]FTR[1..*]3000 SPM 5Specimen Type Modifier (Table 541)CWE_CRE1Varies[0..*] O 10n/a SPM 6Specimen Additives (Table 371)CWE_CRE1Varies[0..*] O 5n/a SPM 9Specimen Source Site Modifier (Table 542)CWE_CRE1Varies[0..*] O 10n/a SPM 21Specimen Reject Reason (Table 490) O CWEVaries[0..*]n/a5 SPM 24Specimen Condition (Table 493) O CWEVaries[0..*]n/a5 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 14

15 Cardinality Requirements ValueImplementation RequirementsOperational RequirementsValid Usage Codes [0..0] The application (or as configured) shall not support the element. Element never presentX [0..1] The application shall support one occurrence of the element. Element may be omitted and it can have at most one occurrence RE, O, C(a/b) [1..1] The application shall support one occurrence of the element. Element must have exactly one occurrenceR [0..n] The application shall support “n” occurrences of the element. Element may be omitted or may have up to n occurrences RE, O, C(a/b) [1..n] The application shall support “n” occurrences of the element. Element must appear at least once, and may have up to n occurrences R [0..*] The application shall support unlimited occurrences of the element. Element may be omitted or may have an unlimited number of occurrences RE, O, C(a/b) [1..*] The application shall support unlimited occurrences of the element. Element must appear at least once, and may have an unlimited number of occurrences R [m..n] The application shall support “n” occurrences of the element. Element must have at least "m" occurrences and may have at most "n" occurrences. Except that in the case where the usage code is RE, the element may also be omitted or have zero occurrences R and RE [m..*] 1 The application shall support unlimited occurrences of the element. Element must have at least "m" occurrences and may have an unlimited number of occurrences. Except that in the case where the usage code is RE, the element may also be omitted or have zero occurrences. R and RE 1 m must be greater than 1 and n must be greater than or equal to m; the case where m equals 1 is addressed separately. 15