1. 1 Cardinality Specification and Testing Recommendations LOI and LRI MU Certification October 21, 2013 Draft 2.4 1

2. 2 Wiki Comments 2 CategoryCountIndividuals Confirm As Is51 Question re “Vital”15 Specific suggestions147 Not applicable11 Specific comments: 1.C1:1: For limits verify with clinical experts 2.C2:17: Unlimited list OBR, OBX, NTE, NTE-3 3.C3:36: Notify both sending and receiving parties if supported occurrences exceeded 4.C4:41: Issue regarding partial or complete rejection 5.C5:52: Imperative? 6.C6:58: Process to grow (e.g. 10%) 7.C7:72: Ability to have local agreement that meets base standard but violates IG on cardinality 8.C8:74: Requested examples of Patient Safety 9.C9:75: Multiple levels of ACK 10.C10:77: Option to stop processing on CE 11.C11:78: Is there a “flavor” between “Partial” and “Hard Stop”? 12.C12:79: Partial consumption of results – no this is a CLIA issue 13.C13:80: Error response behavior of client site message replication 14.C14:81: New codes to avoid confusion with usage; suggestion on specific limits and usage Note: definition of vital includes/implies specific segments/elements as unlimited (0/1,*) and others as bounded (0/1,n)

3. 3 Responses to Comments 3 1.C1:1: For limits verify with clinical experts R1:1:Include as part of redefining * to n for limited occurrence items and testing for unlimited items 2.C2:17: Unlimited list OBR, OBX, NTE, NTE-3 R2:17: yes, this is the recommended minimum list for unlimited occurrences – update tables 3.C3:36: Notify both sending and receiving parties if supported occurrences exceeded R3:36: Yes, new “Notification” slide with recommendations 4.C4:41: Issue regarding partial or complete rejection R4:41: Reviewed with CLIA – required to reject all under 493.1291 report all results and associated information in a secure, reliable, accurate manner 5.C5:52: Imperative? R5:52: No response required 6.C6:58: Process to grow (e.g. 10%) R6:58: Include with R1:1 as part of testing limit evaluation 7.C7:72: L ocal agreement that meets base standard; increase upper limit for IG on cardinality R7:72: Yes, new slide with approach: appropriate adjustments in behavior at upper limit

4. 4 4 8.C8:74: Requested examples of Patient Safety R8:74: Requested from LRW and CDC/FDA 9.C9:75: Multiple levels of ACK R9:75: See discussion on new slide 10.C10:77: Option to stop processing on CE R10:77: Option will be added to table 11.C11:78: Is there a “flavor” between “Partial” and “Hard Stop”? R11:78: No see R4:41 12.C12:79: Partial consumption of results – no this is a CLIA issue R12:79: See answer R4:41 13.C13:80: Error response behavior of client site message replication R13:80: Recommendations on new slide 14.C14:81: New codes to avoid confusion with usage; suggestion on specific limits and usage R14:81: Agreed – will update tables

5. 5 Issues related to upper limits If standard says 0,10 –If guide says 0,5 then Test can send 0-5 Test that we can receive and consume 0-5 Sending –Error if unable to send 0 –Error if unable to send up to 5 –Error if send more than 5 Receiving –Error if unable to receive 0 –Error if unable to receive and consume less than 5 –Error if receive more then 5 –Can create new derived profile –May not decrease upper limit below IG –May increase upper limit up to base standard –Then may increase the error on upper limit for sending or receiving to be equivalent to the new upper limit 5

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

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

8. 8 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. Receiver behavior defined in 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. 8

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

10. 10 Cardinality Conformance Assessment Rob TODO 10

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

12. 12 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.Hard Error -- 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 to both sender and recipient 2.Soft Error -- Process message and ACK with Warning/Alert Error  Proceed with warning—alert sender and receiver of exceeding limits (as well as missing/incorrect information), but proceed with processing the lab order/result  May also treat as Hard Error –For both LOI and LRI, the appropriate behavioral option is determined based on an element by element basis 12

13. 13 Processing Requirements – Segments (In Process) 13 IDSegment DescriptionLOI Cardinality/UsageLRI Cardinality/Usage BehaviroBehavior UsageCardinalityUsageCardinalityLOILRI Order Begin [1..*]R SEHE NTE Notes and Comments SegmentRE[0..*]RE[0..*]SEHE PRT Participation Information SegmentVaries (1) [0..5][0..*]n/a SEn/a DG1 Diagnosis SegmentC(R/RE) (2) [0..*]O SEn/a OBX Observation/Result SegmentRE[0..*]R SEHE SPM Specimen InformationC(R/O) (3) [0..*]RE[0..*]SE May not be limited in IG 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 SESoft Error -- Consume as much as possible, notify sender with non-fatal error code, alt ernative is F HEHard Error -- Reject Message and notify sender with fatal error code n/aNot Applicable

14. 14 Processing Requirements – Elements (In Process) 14 LOILRI Behavior SegmentElementElement NameData TypeUsageCardinalityData TypeUsageCardinalityLOILRI MSH ERR C(R/O)[0..*] C(R/O)[0..*] SE MSH 21Message Profile IdentifierEIR[1..*]EI_GUR[1..*] HE PID 3Patient Identifier ListCXR[1..*]VariesR[1..*]SE PID 5Patient NameXPNR[1..1]XPNR[1..*]SE PID 10RaceCWE_CR1RE[0..*]CERE[0..*]SE PID 11Patient AddressXADC(R/RE)[0..*] O SEn/a PID 13Phone Number – HomeXTNVaries[0..*] O SEn/a PID 14Phone Number – BusinessXTNVaries[0..*] O SEn/a ORC 23Ordering Facility Phone NumberXTNVaries[1..*] O SEn/a OBR 13Relevant Clinical Information O CWE_CRERE[0..*]n/aSE OBR 28Result Copies ToXCNRE[0..5][0..*]VariesC(R/X)[0..*]SE OBR 49Result Handling (Table 507)ISVaries CWE_CRERE[0..*]n/aSE OBX 8Abnormal Flags (Table 78) O ISRE[0..*]n/aHE NTE 3CommentFTR[1..*]FTR[1..*]SEHE 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/aSE SPM 24Specimen Condition (Table 493) O CWEVaries[0..*]n/aSE

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

16. 16 Minimum Upper-Limit Test Guidance – Segments (In Process) 16 IDSegment DescriptionLOI Cardinality/UsageLRI Cardinality/Usage Upper Limit UsageCardinalityUsageCardinalityLOILRI Order Begin [1..*]R 30 50 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 – final determination in Functional Behavior Guide

17. 17 Minimum Upper-Limit Test Guidance – Elements (In Process) 17 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 – final determination in Functional Behavior Guide

18. 18 Notification on Error Receiver (Technical Response) –Must notify sender (Application Level Acknowledgement) Receiver (Functional Behavior) –Must notify recipient of error –To the extent possible Associate with Patient/Order Associate with Intended Recipient Must be visible to clinical staff, not just technical support Receiver (Technical Response) –Must be able to receive and consume error response (Application Level Acknowledgement) Sender (Functional Response) –Must notify appropriate personnel to Resolve technical problem with receiver Ensure report / order is handled by exception methods 18

19. 19 Local Agreement Constraints Local agreements – conformant with the IG and certificaiton –Must be implemented as published profiles –Cardinality May increase the requirements on both the lower and upper bounds, e.g. –[0,5] to [1,5] –[1,5] to [1,10] May not exceed the upper limit on the base standard –Conformant behaviors Any associated conformance or Functional Behaviors will also increase along with the increase in limits (e.g. error notification) 19

20. 20 Multiple Acknowledgements Acknowledgements –System As described in base standard and IG –Application Multiple levels based on MSH-9 and MSA –Sending application must be able to receive multiple acknowledgements: System is synchronous Application level messages are asynchronous Requested Application Level – may be all messages Error for additional checks is error only 20

21. 21 Client Side Message Replication Assumes –Message is split by client using interface engine, middleware, et. –Lab is unaware of, or not responsible for, of additional recipients Replication engine behavior –Replicate copies must have MSH-3 updated to correspond to the replication engine and not the laboratory –If error is received from the replicated recipient and echoed copy of MSH- 3 (where should this be placed in the ACK?) is that of the replication engine, it should be intercepted and not reported to the LIS –Message to LIS intended recipient shall not be modified and on application error, the entire message will be passed to the LIS EHR behavior –Consume message –Report errors same for all messages (replicated and original) See notification on error –Must include MHS-3 in ACK (where) 21

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

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