Cardinality Specification and Testing Recommendations LOI and LRI

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

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 HL 7 V 2 Chapter 2 B Conformance - Clarification 2 2

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 3

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 4

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 5

Cardinality Conformance Assessment Rob TODO o T e B e n o D 6 6

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 7

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

Segment Description LOI Cardinality/Usage Cardinality Order Begin NTE Notes and Comments Segment PRT Participation Information Segment DG 1 Diagnosis Segment OBX Observation/Result Segment SPM Specimen Information LRI Cardinality/Usage Cardinality LOI Behavior ID Behaviro Processing Requirements – Segments (In Process) LRI [1. . *] R [1. . *] CE R RE [0. . *] CE R Varies(1) [0. . 5][0. . *] n/a CE n/a C(R/RE)(2) [0. . *] O CE n/a RE [0. . *] R [0. . *] CE R C(R/O)(3) [0. . *] RE [0. . *] CE 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 PV 1 -20 is valued "T" (third party) (3) if OBR-7 (Observation Date/Time) is not valued '0000' Behavior on unable to consume CE Consume as much as possible, notify sender with non-fatal error code R Reject Message and notify sender with fatal error code n/a Not Applicable 9 9

Element Name ERR Message Profile Identifier Data Type EI Cardinality [0. . *] [1. . *] PID PID PID 3 5 10 11 13 14 Patient Identifier List Patient Name Race Patient Address Phone Number – Home Phone Number – Business ORC 23 Ordering Facility Phone Number XTN Varies [1. . *] OBR OBR 13 28 49 Relevant Clinical Information Result Copies To Result Handling (Table 507) XCN IS O RE Varies [0. . 5][0. . *] OBX 8 Abnormal Flags (Table 78) NTE 3 Comment SPM SPM SPM 5 6 9 21 24 Specimen Type Modifier (Table 541) Specimen Additives (Table 371) Specimen Source Site Modifier (Table 542) Specimen Reject Reason (Table 490) Specimen Condition (Table 493) CX R XPN R CWE_CR 1 RE XAD C(R/RE) XTN Varies [1. . *] [1. . 1] [0. . *] O FT R [1. . *] LRI Data Type Usage Cardinality C(R/O) [0. . *] EI_GU R [1. . *] Varies XPN CE R R RE O O O [1. . *] [0. . *] O CWE_CRE RE Varies C(R/X) CWE_CRE RE Behavior Segment Element MSH 21 LOI Usage C(R/O) R Behavior Processing Requirements – Elements (In Process) CE CE CE n/a n/a LOI LRI CE CE R R CE n/a [0. . *] n/a CE CE CE n/a CE IS RE [0. . *] n/a R FT R [1. . *] CE R CWE_CRE 1 Varies [0. . *] O ? n/a O CWE Varies [0. . *] n/a CE 10 10

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 11

Minimum Upper-Limit Test Guidance – Segments (In Process) Segment Description LOI Cardinality/Usage Order Begin NTE Notes and Comments Segment PRT Participation Information Segment DG 1 Diagnosis Segment OBX Observation/Result Segment LRI Cardinality/Usage Cardinality Specimen Information LOI LRI [1. . *] R [1. . *] 30 50 RE [0. . *] 30 30? Varies(1) [0. . *] n/a 15 n/a C(R/RE)(2) [0. . *] O 12 n/a RE [0. . *] R 30 80 ? 3000(4) 20 20 [0. . *] AP Report SPM Upper Limit ID Upper Limit Note: Upper Limits are intended as starting points for discussion only C(R/O)(3) [0. . *] RE [0. . *] 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 PV 1 -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 12 12

Minimum Upper-Limit Test Guidance – Elements (In Process) Segment Element MSH 21 Element Name ERR Message Profile Identifier Data Type EI LOI Usage C(R/O) R Cardinality [0. . *] [1. . *] Data Type [1. . *] [1. . 1] [0. . *] Varies XPN CE PID PID PID 3 5 10 11 13 14 Patient Identifier List Patient Name Race Patient Address Phone Number – Home Phone Number – Business ORC 23 Ordering Facility Phone Number XTN Varies [1. . *] OBR OBR 13 28 49 Relevant Clinical Information Result Copies To Result Handling (Table 507) XCN IS O RE Varies [0. . *] OBX 8 Abnormal Flags (Table 78) 3 Comment NTE SPM SPM SPM 5 6 9 21 24 Specimen Type Modifier (Table 541) Specimen Additives (Table 371) Specimen Source Site Modifier (Table 542) Specimen Reject Reason (Table 490) Specimen Condition (Table 493) CX R XPN R CWE_CR 1 RE XAD C(R/RE) XTN Varies O FT R [1. . *] EI_GU LRI Usage Cardinality C(R/O) [0. . *] R [1. . *] R R RE O O O [1. . *] [0. . *] O CWE_CRE RE Varies C(R/X) CWE_CRE RE Upper Limit Note: Upper Limits are intended as starting points for discussion only LOI LRI 10 10 5 1 5 3 3 3 5 5 5 n/a n/a 3 n/a [0. . *] n/a 10 15 15 5 5 IS RE [0. . *] n/a 5 FT R [1. . *] 300 0 0 CWE_CRE 1 Varies [0. . *] O 10 n/a CWE_CRE 1 Varies [0. . *] O 5 CWE_CRE 1 Varies [0. . *] O 10 n/a O CWE Varies [0. . *] n/a 5 O 13 CWE Varies [0. . *] n/a 5 13

HL 7 V 2 Conformance Chapter • • Update Chapter 2 B to better define cardinality and the requirements it places on implementers Update as part of V 2. 8. 1 or V 2. 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 V 2. 8)—see next slide Provide a conformance assessment table for cardinality and appropriate (options) behavior of the receiver in error circumstances 14 14

Cardinality Requirements Value [0. . 0] Operational Requirements Valid Usage Codes The application (or as configured) shall not support the element. The application shall support one occurrence of the element. The application shall support “n” occurrences of the element. Element never present X Element may be omitted and it can have at most one occurrence Element must have exactly one occurrence RE, O, C(a/b) Element may be omitted or may have up to n occurrences Element must appear at least once, and may have up to n occurrences RE, O, C(a/b) [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. [m. . *]1 The application shall support unlimited occurrences of the element. Element must have at least "m" occurrences and may R and RE 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 Element must have at least "m" occurrences and may R and RE 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. [0. . 1] [1. . 1] [0. . n] [1. . n] 1 Implementation Requirements R R 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 15