Cardinality Behaviors and MSH Overview November 7, 2013

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

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

Two possible options presented 1.Based on input regarding CLIA and patient safety, the entire failed transaction must be rejected, the provider must be notified and an acknowledgement transaction indicating a hard failure must be send to the laboratory (recommended solution) 2.Continue with whatever can be consumed, inform the provider that the reports are incomplete and an acknowledgement transaction indicating a hard failure must be send to the laboratory -- assumption is that it is better to give the provider some data even if it is incomplete 4

Issues for consideration Situation should only occur infrequently ( best guess -- < 1:1000 to < 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 not become part of the record via an interface transaction in a timely manner 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 5

Other comments This issue has been compared to an incomplete fax, however –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 – not used as is –Do we really want to implement a solution that mimics a fax out of paper? Comparison to preliminary and partial reporting –That is controlled by the lab and there is a clear indication and expectation on the part of the provider that the information is incomplete and will be updated when complete 6

Additional Comments No method of transmission (MLLP, SOAP, Direct) allows for incomplete receipt of a transaction – this is the standard – it is either received intact or the entire transaction 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. 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 Finally, providers frequently ignore warning messages and proceed with the information at hand as if it is complete 7

MOTION 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 8

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

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) 10

Transactions OML^O21_OML_O21New and append –All levels of acknowledgement OML^O21^OML_O21Cancel (provider) –Control Code in ORC –All levels of acknowledgement ACK^O21^ACKAcknowledge –Next in line ACK – MSH-15/16 NE on response –End to end ACK with MSH-16 NE on response ORL^O22^ORL_O22Application Level Ack –End to end only MSH-16 must be NE on response 11

HL7 Tables 12 HL Accept/application acknowledgment ALAlways ERError/reject conditions only NENever SUSuccessful completion only AENEW to accommodate End-to-End HL7 0008Acknowledgment code AAOriginal mode: Application Accept Enhanced mode: Application acknowledgment: Accept AEOriginal mode: Application Error Enhanced mode: Application acknowledgment: Error AROriginal mode: Application Reject Enhanced mode: Application acknowledgment: Reject CAEnhanced mode: Accept acknowledgment: Commit Accept CEEnhanced mode: Accept acknowledgment: Commit Error CREnhanced mode: Accept acknowledgment: Commit Reject

Tables 13 HL Order Control Codes UAUnable to accept order/service UCUnable to cancel HL Message error condition codes 0Message accepted 100Segment sequence error 101Required field missing 102Data type error 103Table value not found 200Unsupported message type 201Unsupported event code 202Unsupported processing id 203Unsupported version id 204Unknown key identifier 205Duplicate key identifier 206Application record locked 207Application internal error HL7 0516Error severity EError FFatal Error IInformation WWarning

Transaction Process 14 LIS Gateway 2 Gateway 1 EHR OML AL/ER ACK NE/NE Original Message (Order/Append/Cancel) LIS Gateway 2 Gateway 1 EHR ACK AE/NE End-to-End Acknowledgement ACK NE/NE LIS Gateway 2 Gateway 1 EHR ORL AL/NE Application Level Acknowledgement (on Error) ACK NE/NE 1a/b 2a/b3a/b 4a/b 6a/b5a/b 7a/b 8a/b9a/b a MSH-3EHR LIS a MSH-5LIS EHR b MSH-3GT1GT2LISGT2GT1EHRGT2GT1EHR b MSH-5EHR LIS