Blocking messages with blank MRG segment
Dear All,
I would like to block ADT_A18 and ADT_A47 HL7 2.3 messages with an empty MRG:1 field.
This is to prevent my current HL7 ADT router (Business process) sending blank Merges downstream.
I've attempted to create a business rule where this would return out the business role process. However the messages still loop though the other rules.
Any advice would be great.
Kind Regards
Stuart
Comments
Have you attempted to use LENGTH?
SayLENGTH(HL7.{MRG. PriorPatientIdentifierList }) > 0
We have never been successful in using the field numbers within our routing rules. Normally we just use the name of the field, or that's at least how we were taught.
I would also think you want to check the message type before you check the MRG.1. So it would be if Message Type is A18 and LENGTH(HL7.{MRG. PriorPatientIdentifierList }) > 0 then return
Thank you Scott.
I managed to get my method to work, but yours works really well and is another way I wouldn't of thought of doing.
Hmm. Interesting. I created the exact same rule as your original in my local testing environment and it worked as expected. I was not using the testing service, however. I'm running HS 2017.1 if it matters.
Stuart, have you verified that the merge message parses correctly? Check the contents of the message in the message viewer and verify that the MRG segment isn't displayed in black text. If the segment doesn't parse against the schema and doctype specified in the inbound service, the HL7.{} field selectors referencing it won't work.
Thanks Jeffery
Were on Ensemble 2012.2.5 . We're in the process of testing our upgrade HealthShare 2017.1 on a seperate instance.
After some investigation I found that the method would work with the following:
I found a quirk in the testing service, where the rule would not work using the testing service.
I created a business Operation that feeds our ADT Business service and the same messages now all work.
I'm currently testing with our eMR (Epic's) DEV platform ADT messages and this is also working.
It looks like the testing service might works a bit funny when running from the router.
Thank you all for your reads and contributions.