Cardinality Behaviors Discussion

1. Cardinality BehaviorsDiscussion Version 4.0 November 13, 2013

2. Cardinality and Behaviors • Problem is focused on the situation where the receiver cannot consume the total transmission from the sender and the error is considered a hard error (HE) by definition in the Cardinality proposal • This is primarily an issue with not all of the following can be consumed by the EHR • All orders in a transaction • All results in an order • All notes in a “comment” or “textual report”

3. Research • Input was received from individuals representing the following organizations (Note: official statements were not requested) : • CMS/CLIA • CDC (CLIAC) • CAP • API • The inability to consume the entire transaction is inconstant with the CLIA regulations in 42 CFR 493.1290/1291 (per CMS/CLIA) • Presents a significant patient safety and liability issue

4. Three possible options presented • Based on input regarding CLIA and patient safety, the entire failed transaction must be rejected, the provider must be notified and an acknowledgement transaction must be sent to the laboratory indicating a hard failure (recommended solution) • Continue with any orders (OBRs) that can be consumed in their entirety, inform the provider that the report is incomplete and an acknowledgement transaction must be sent to the laboratory indicating a hard failure -- assumption is that it is better to give the provider some data (orders that can be consumed) even if it is incomplete • Continue with whatever can be consumed (including partial orders), inform the provider that the reports are incomplete and an acknowledgement transaction must be sent to the laboratory indicating a hard failure -- assumption is that it is better to give the provider some data even if it is incomplete, including in complete orders

5. Definition of Transaction For the purpose of this analysis and recommendation, the following is the definition of a “transaction” • Limited to a single MSH and associated segments • Does not have an impact on previous or future transactions, e.g., failure to consume a corrected report or a report that completes preliminary or partials does not require removal of an earlier preliminary, partial or final report. • May include one or more orders (ORC/OBR) up to the total number of orders reported under the same MSH • Limited to a single patient • Limited to orders that were placed together on the “requisition” or single order transaction – On reporting, may include any reflex and add-on orders • Note: After reporting a final order (ORC/OBR) (all components are complete), the recommended method is to not report the order again unless there is a change (e.g. corrected result).

6. Issues for consideration • Situation should only occur infrequently ( best guess << 1:1,000,000) due to testing during certification • Will occur only on most complex requisitions/ reports / patients (if it occurs on routine orders, then systems will not be compliant with certification) • Immediate retransmission will not fix the problem (this is a technical failure) – very unlikely the missing data will become part of the record via an interface transaction in a timely manner (unless consumable portions of the transaction can be sent by the laboratory) • Can occur for any of the following • Too many Orders – orders will be missing • Too many results – results on an order will be missing • Too many note lines/segments – part of text will be missing

7. Other comments Comparison to an incomplete fax • No fax has missing items in the middle of the fax • All incomplete faxes have a clear indicator that the fax is incomplete • The fax is not viewed in part (different displays) • Any partial fax will be recognized and the lab will be called to resend • Do we really want to implement a solution that mimics a fax failure? • Comparison to preliminary and partial reporting • Preliminary and partial reporting is controlled by the lab and there is a clear indication on the report and expectation on the part of the provider that the information is incomplete and will be updated when complete

8. Additional Comments • All methods of transport used in healthcare (MLLP, SOAP, Direct) allow for detection and rejection of incomplete transmissions – this is the standard – it is either received intact or the entire transmission is rejected. • While we can make up scenarios were partial receipt of orders (never results or notes/text) may be ok, we have no guarantee that the orders are not related and required for interpretation • The technology to validate a complete transaction may need to be created by an EHR vendor to implement the recommended solution. • If partial consumption is allowed, how can an EHR ensure that all views of laboratory data from an incomplete transaction will indicate that the transaction was incomplete, may impact interpretation, and express the need to call the lab • Providers frequently ignore warning messages and proceed with the information at hand as if it is complete

9. Issues raised with transaction rejection • What about the CBC ordered with a rejected transaction (this was the most commonly cited case) • Still << 1:1,000,000 (very rare occurrence) • If due to AP or genetic testing (most likely), chemistry and hematology will have been reported long before these tests are complete • Can always call the lab for the results (and they can send as image to Fax or via Direct) This is the current solution today (Fax) in any number of situations. • What about the ability to consume whatever may be consumed -- providers want any information that is available • Assumption: Providers want partial reporting by the normal laboratory definition – e.g., report results when they are available • Assumption: Providers do not want partial information due to errors in transmission or consumption – too much liability and possibility for inappropriate decisions compromising patient safety – however, providers still need clear indicator that information is available and that they should call the laboratory

10. Additional Considerations • AP report may be split across multiple Orders (OBRs) • Consuming one part of the report and not another may lead to serious patient safety issues • Reflex testing may create additional Order(s), especially for reflex tests that will be billed • Failure to consume the reflex order may have an impact on interpretation of the other components of the test results – especially if there is no indication that the reflex order has occurred

11. Pathologists’ Recommendations • Because of the lack of enforceable standards for how certain types of results are encoded into HL7, then the group feels that rejection of the entire HL7 message is more important for patient safety than the time delays associated with not immediately reporting an OBR with its associated OBXs/NTEs that can be consumed in an HL7 message provided that the laboratory and the providers are both immediately notified of such a technical failure. • We recommend that enforceable standards be created for all text type results such that a single result cannot be split amongst multiple OBRs. • All elements of a orderable (OBR) (e.g. OBXs, NTEs) must be treated as a single item and consumed or rejected together.

12. Conclusion • Failure due to exceeding cardinality limits for segments/elements defined as subject to Hard Error in a certified EHR expected to be a very rare occurrence (<<1:1,000,000) for a certified EHR • This will not affect patient care for routine/stat orders • Potential impact on patient safety outweighs any possible benefit from receiving incomplete report (due to EHR inability to consume) • Provider must be notified to call laboratory for results and the laboratory must be informed electronically of error. This will allow other methods of reporting to be pursued in a timely manner.

13. MOTION (from Thursday) • Motion to adjust proposal that rejection of any portion of the OBR on a result message requires rejection of the entire OBR; that the Lab needs to be notified electronically; that a message must be placed on the associated order when known (i.e., mark the order that asked for it); with message with too many OBRs to be consume, the message must be rejected in total, or a message must be placed in the patient record where it is available to the clinician (e.g., in the current encounter, with the order if known); track through DSTU to further improve. Bob Dieterle, Les Keepper • 12-Nov-2013 Withdrawn by Bob Dieterle

14. Motion for Consideration • 12-Nov-2013 Accept original proposal for cardinality as written (LOI and LRI MU Certification, November 11, 2013 Draft 2.7)and collect information on failures and document any additional needs or adjustments during the DSTU period and propose changes for Normative. Bob Dieterle, Alexis Carter • 12-Nov-2013 Postpone vote on above motion until Thursday 11/14 to allow for verification. Ken McCaslin, Mark Jones Against: 0 Abstain: 0 For: 20 • 12-Nov-2013 Motion to table effort until Pilot phase. David Burgess, Ken McCaslin Against: 7 Abstain: 7 For: 6 – failed to pass (21 in pool, co-chair not vote), resume vote on motion to Postpone on Thursday 11/14

15. Motions continue… • Bob Dieterle to provide a single document that contains only the topics to be voted on, clarify exemplary items.

16. November 14, 2013 Motions • 14-Nov-2013 Accept original proposal for cardinality as written (LOI and LRI MU Certification, November 14, 2013 3.0)and collect information on failures and document any additional needs or adjustments during the DSTU period and propose changes for Normative. Bob Dieterle, Alexis Carter • Against: 8 Abstain: 7 For: 11 • 14-Nov-2013 Motion to postpone motion before group to allow for discussion to revise documentation to clearly delineate between rules for Orders and rules for Results. Ken McCaslin, David Burgess • Against: 11 Abstain: 8, For: 7