1 / 14

Cardinality Behaviors and MSH 15 -16 Overview

Cardinality Behaviors and MSH 15 -16 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

bradford-jerry
Download Presentation

Cardinality Behaviors and MSH 15 -16 Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cardinality BehaviorsandMSH 15 -16 Overview November 7, 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 • The inability to consume the entire transaction is inconstant with the CLIA regulations in 42 CFR 493.1290/1291. • Presents a significant patient safety and liability issue

  4. Two 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 indicating a hard failure must be send to the laboratory (recommended solution) • 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

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

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

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

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

  9. Acknowledgements Architecture • EHR direct to LIS (no intervening technologies that do anything other than forward messages) • EHR connected to Gateway then to LIS • EHR connected to Gateway then to second Gateway then to LIS • EHR connected to unknown number of intermediate Gateways then to LIS Gateway (or middleware) is technology that: • receives messages, • optionally validates a message syntax, but usually not the content • acknowledges messages (NACK only if validation is done) • optionally transforms the message • Forwards the message to the next Gateway or LIS • Receives the acknowledgement from the next Gateway or LIS

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

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

  12. HL7 Tables HL7 0008 Acknowledgment code AA Original mode: Application Accept Enhanced mode: Application acknowledgment: Accept AE Original mode: Application Error Enhanced mode: Application acknowledgment: Error AR Original mode: Application Reject Enhanced mode: Application acknowledgment: Reject CA Enhanced mode: Accept acknowledgment: Commit Accept CE Enhanced mode: Accept acknowledgment: Commit Error CR Enhanced mode: Accept acknowledgment: Commit Reject HL7 0155 Accept/application acknowledgment AL Always ER Error/reject conditions only NE Never SU Successful completion only AE NEW to accommodate End-to-End

  13. Tables HL7 0357 Message error condition codes 0 Message accepted 100 Segment sequence error 101 Required field missing 102 Data type error 103 Table value not found 200 Unsupported message type 201 Unsupported event code 202 Unsupported processing id 203 Unsupported version id 204 Unknown key identifier 205 Duplicate key identifier 206 Application record locked 207 Application internal error HL7 0119 Order Control Codes UA Unable to accept order/service UC Unable to cancel HL7 0516 Error severity E Error F Fatal Error I Information W Warning

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

More Related