Cardinality Behaviorsand

MSH 15 -16 Overview

November 11, 2013

2

Cardinality and Behaviors

• Problems 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 presented1. 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)

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

3. 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 TransactionFor the purpose of this analysis and recommendation, the following is the definition of a “transaction” (This definition is focused on result reporting, since this is the only situation under which the error is considered a Hard Error)

• Limited to a single patient• Limited to orders that were placed together on the

“requisition” or single order transaction – may include any potential reflex and add-on orders

• After reporting a final order (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 orders / reports / patients (if it occurs on routine orders, then systems will not be compliant with certification)

• 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 the 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 in a certified EHR will be a very rare occurrence

• 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

14

Motion for Consideration

• Accept original proposal for cardinality as written. Collect information on failures and document any additional needs or adjustments during the DSTU period and propose changes for Normative.

15

Acknowledgements

Not part of Cardinality Behaviors

16

Acknowledgement Background

Architecture

1) EHR direct to LIS (no intervening technologies that do anything other than forward messages)

2) EHR connected to Gateway then to LIS

3) EHR connected to Gateway then to second Gateway then to LIS

4) EHR connected to unknown number of intermediate Gateways then to LIS

Gateway (or middleware) is technology that:1) receives messages,

2) optionally validates a message syntax, but usually not the content

3) acknowledges messages (NACK only if validation is done)

4) optionally transforms the message

5) Forwards the message to the next Gateway or LIS

6) Receives the acknowledgement from the next Gateway or LIS

17

Desired Behaviors

• Gateway acknowledges receipt of message (next in chain response)

• LIS acknowledges message is complete and syntactically correct to EHR (end-to-end)

• LIS sends error if message is unable to be processed (list of reasons)

18

Transactions

• OML^O21_OML_O21 New and append– All levels of acknowledgement

• OML^O21^OML_O21 Cancel (provider)– Control Code in ORC – All levels of acknowledgement

• ACK^O21^ACK Acknowledge– Next in line ACK – MSH-15/16 NE on response– End to end ACK with MSH-16 NE on response

• ORL^O22^ORL_O22 Application Level Ack– End to end only MSH-16 must be NE on response

19

Relevant Segments / Elements

• MSH – Message Header Segment– MSH-3 Sending Application (Varies, RE)– MSH-5 Receiving Application (Varies, RE)– MSH-10 Message Control ID (ST, R)– MSH-15 Accept Acknowledgement (ID, R)

• Request type for System Acknowledgement• See table HL7 0155

– MSH-16 Application Acknowledgement (ID, R)• Request type for Application Acknowledgement• See table HL7 0155

• MSA – Message Acknowledgement Segment (ID, R)– MSA-1 Acknowledgement Code– MSA-2 Message Control ID (ST, R)

• ERR – Error Segment– MSH-3 HL7 Error Code

• From table HL7 0357

– MSH-4 Severity• From table HL7 0516

20

HL7 Tables (MSH / MSA)HL7 0155 Accept/application acknowledgment

AL AlwaysER Error/reject conditions onlyNE NeverSU Successful completion onlyAE NEW to accommodate End-to-End

HL7 0008 Acknowledgment codeAA Original mode: Application Accept

Enhanced mode: Application acknowledgment: AcceptAE Original mode: Application Error

Enhanced mode: Application acknowledgment: ErrorAR Original mode: Application Reject

Enhanced mode: Application acknowledgment: RejectCA Enhanced mode: Accept acknowledgment: Commit AcceptCE Enhanced mode: Accept acknowledgment: Commit ErrorCR Enhanced mode: Accept acknowledgment: Commit Reject

21

Tables (MSA / ERR)

HL7 0119 Order Control CodesUA Unable to accept order/serviceUC Unable to cancel

HL7 0357 Message error condition codes 0 Message accepted100 Segment sequence error101 Required field missing102 Data type error103 Table value not found200 Unsupported message type201 Unsupported event code202 Unsupported processing id203 Unsupported version id204 Unknown key identifier205 Duplicate key identifier206 Application record locked207 Application internal error

HL7 0516 Error severity E Error F Fatal Error I Information W Warning

22

Transaction Process

LISGateway 2Gateway 1EHROML AL/ER OML AL/ER OML AL/ER

ACK NE/NE ACK NE/NE ACK NE/NE

Original Message (Order/Append/Cancel)

LISGateway 2Gateway 1EHRACK AE/NE ACK AE/NE ACK AE/NE

End-to-End Acknowledgement

ACK NE/NE ACK NE/NE ACK NE/NE

LISGateway 2Gateway 1EHRORL AL/NE ORL AL/NE ORL AL/NE

Application Level Acknowledgement (on Error)

ACK NE/NE ACK NE/NE ACK NE/NE

1a/b 2a/b 3a/b

4a/b6a/b 5a/b

7a/b8a/b9a/b

1 2 3 4 5 6 7 8 9

a MSH-3 EHR EHR EHR LIS LIS LIS LIS LIS LIS

a MSH-5 LIS LIS LIS EHR EHR EHR EHR EHR EHR

b MSH-3 GT1 GT2 LIS GT2 GT1 EHR GT2 GT1 EHR

b MSH-5 EHR EHR EHR LIS LIS LIS LIS LIS LIS

23

Transaction Process (LIS only AE)

LISGateway 2Gateway 1EHROML AL/ER OML AL/ER OML AL/ER

ACK NE/NE ACK NE/NE ACK NE/NE

Original Message (Order/Append/Cancel)

LISGateway 2Gateway 1EHRACK AE/NE ACK AE/NE ACK AE/NE

End-to-End Acknowledgement

ACK NE/NE ACK NE/NE ACK NE/NE

LISGateway 2Gateway 1EHRORL AL/NE ORL AL/NE ORL AL/NE

Application Level Acknowledgement (on Error)

ACK NE/NE ACK NE/NE ACK NE/NE

1a/b 2a/b 3a/b

4a/b6a/b 5a/b

7a/b8a/b9a/b

1 2 3 4 5 6 7 8 9

a MSH-3 EHR EHR EHR LIS LIS LIS LIS LIS LIS

a MSH-5 LIS LIS LIS EHR EHR EHR EHR EHR EHR

b MSH-3 GT1 GT2 LIS GT2 GT1 EHR GT2 GT1 EHR

b MSH-5 EHR EHR EHR LIS LIS LIS LIS LIS LIS

Transaction Process (no Gateways)

24

LISEHROML AE/ER

ACK NE/NE

Original Message (Order/Append/Cancel)

LISEHRACK AE/NE

End-to-End Acknowledgement

ACK NE/NE

LISEHRORL AL/NE

Application Level Acknowledgement (on Error)

ACK NE/NE

1a/b

2a/b

3a/b

1 2 7

a MSH-3 EHR LIS LIS

a MSH-5 LIS EHR EHR

b MSH-3 LIS EHR EHR

b MSH-5 EHR LIS LIS