web stats
Mirth is sending AE ACKs instead of AR when a filter returns false - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Reply
 
Thread Tools Display Modes
  #1  
Old 07-29-2016, 12:06 AM
ppazos ppazos is offline
OBX.2 Kenobi
 
Join Date: May 2008
Posts: 76
ppazos
Default Mirth is sending AE ACKs instead of AR when a filter returns false

Hi, doing some filtering tests I detected Mirth 3.4.1.8057 is generating AE instead of AR when a message is filtered in a source filter. My channel: all datatypes HL7 v2.x, Source TCP Listener, Destination File Writer.

My filter is really simple, just a javascript step that returns false.

Why is filtering a message considered an error instead of just a reject?

IMO the ACK code that should be returned when a message is filtered is AR not AE.

Thanks!
Reply With Quote
  #2  
Old 07-29-2016, 02:32 AM
siddharth siddharth is offline
Mirth Guru
 
Join Date: Feb 2013
Posts: 832
siddharth is on a distinguished road
Default

That is expected. The purpose of AR is different than AE. I quite don't have much grasp on that topic, but I think AR is when your application fails to consume the message, where is AE is when it is a processing error. The actual explanation might differ.

If a message is not able to pass the filter, that qualifies for AE as an indication that "sorry we can't process your message as you are unauthorized" . We also send our customers AE when they can't pass the filter.
Reply With Quote
  #3  
Old 07-29-2016, 08:05 PM
ppazos ppazos is offline
OBX.2 Kenobi
 
Join Date: May 2008
Posts: 76
ppazos
Default

Application Error is when the application can't consume the message because problems related with: bad formatting or missing or wrong data in the header (MSH): HL7 version not supported, control ID not present, missing mandatory segments, etc.

Application Reject is when the application can't consume the message because problems related with the data in the message: mandatory data is not present, patient doesn't exists, requested service code doesn't exists, etc.

What I'm seeing is that all filtered messages on the source are returning AE without letting me say what kind of rule was violated (error related o reject related).

With that being said, if you don't know the difference between when to use AR/AE, how can you be sure that returning AE is the expected behavior?

Quote:
Originally Posted by siddharth View Post
That is expected. The purpose of AR is different than AE. I quite don't have much grasp on that topic, but I think AR is when your application fails to consume the message, where is AE is when it is a processing error. The actual explanation might differ.

If a message is not able to pass the filter, that qualifies for AE as an indication that "sorry we can't process your message as you are unauthorized" . We also send our customers AE when they can't pass the filter.
Reply With Quote
  #4  
Old 07-31-2016, 07:47 AM
siddharth siddharth is offline
Mirth Guru
 
Join Date: Feb 2013
Posts: 832
siddharth is on a distinguished road
Default

For that you need to go back to the time when HL7 began. Integration Engine came very late...Earlier there used to application to application or product to product interfaces. So a PM communicating directly with the EMR or another PM etc. That was the time when ACKs were designed to be elborative and AE and AR has their meaning.

Eg. If I have an allscripts PM sending data to a Cerner emr directly, and my version mismatches with what cerner expects I will get an AE. and if there is a data mismatch I will get an AR.

Now, Mirth is an integration engine and not the end product which eventually consumes the data. So the AR will never arise. I am basing this on the definition you posted, I don't know where you get it from. I did tell you that actual explanation might differ.

If a rule in the filter breaks or is not passed, it will just send an AE. You would need to build custom ACKs to achieve what you want.

Again, this is all my understanding.
Reply With Quote
  #5  
Old 07-31-2016, 07:59 PM
ppazos ppazos is offline
OBX.2 Kenobi
 
Join Date: May 2008
Posts: 76
ppazos
Default

Hi,

I checked HL7 v2.5 CH02. From there: Application Error (AE) should be generated when there is an application error or when a constraint set by the specs is not satisfied, for example populating a field that is marked as not supported.

IMO, rejecting a message because of a different condition than that the message is not well formed, should return Application Reject by default.

I understand the difference between the integration engine and the final app, but (depending on the implementation) Mirth can do all the checks an app might do, I think that is sort of a grey area, and what caused my initial question.

Considering that, maybe would be useful to allow changing the ACK code depending on what we are actually implementing in Mirth. In some cases might be AE in others AR. With this we can reduce the need of creating custom ACKs, but I understand that currently this is not supported.

Thanks a lot for the discussion.
Reply With Quote
  #6  
Old 08-02-2016, 08:35 AM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,123
narupley is on a distinguished road
Default

I just tested and an AR NACK is generated when the message is filtered in the source connector. Perhaps there's an issue with your channel code / configuration?

Also, you can go to the Response Generation section in your inbound HL7 v2.x properties and change the ACK codes if you need to.
__________________
Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

Nicholas Rupley
Work: 949-237-6069
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


- How do I foo?
- You just bar.
Reply With Quote
Reply

Tags
ack code, filter

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 10:15 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Mirth Corporation