1 / 24

Cardinality Behaviors and MSH 15 -16 Overview

Cardinality Behaviors and MSH 15 -16 Overview. November 11, 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

vanna-clayton
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 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 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” (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 • 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

  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 Always ER Error/reject conditions only NE Never SU Successful completion only AE NEW to accommodate End-to-End 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

  21. Tables (MSA / ERR) 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

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

  23. Transaction Process (LIS only AE) 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

  24. Transaction Process (no Gateways) Original Message (Order/Append/Cancel) OML AE/ER EHR LIS 1a/b ACK NE/NE End-to-End Acknowledgement ACK AE/NE EHR LIS 2a/b ACK NE/NE Application Level Acknowledgement (on Error) ORL AL/NE EHR LIS 3a/b ACK NE/NE

More Related