New post
Question
· Jul 17, 2017

Discarding Received non HL7 data

#Ensemble #Business Service #HL7

Hi ,

     I'm using standard business service not(Customized business service). I'm not able to process the Hl7 data file which contains CRLF characters.It shows warning "Discarding  Received non HL7 data". Actually it discards some segment after CRLF character. Is there any settings to overcome this problem?

 

Also i tried UTF-8, Ascii,Unicode.. characterset . But it won't work. Please help me .

 

Urgent!!!

Discussion (11)2
Log in or sign up to continue
Jeffrey Drumm · Jul 17, 2017

It's not a character set problem, it's a malformed HL7 problem. If the vendor sending the message needs to include a carriage return character in the middle of a segment, they should be escaping it. 

If the vendor won't fix it, you're probably looking at overriding the inbound service's OnProcessInput() method to strip out \0x0D\0x0A sequences and replace them with something else. If they're in there for textual formatting purposes, you'll need to know what the target system expects for a line-break character sequence.

1 0
Scott Roth · Feb 5, 2018

I have found that the text of "Discarding Received non HL7 data" lives in the EnsLib.HL7.Parser.cls. Has anyone tired to copy and make their own HL7.Parser that would not throw this warning message? It seems pretty simple but I am having issues trying to call my updated Parser.cls. All I want to do it comment this error out so it is not thrown and taking up database space.

 

Thanks

Scott

0 0
Scott Roth · Feb 6, 2018

This was a custom interface written some time ago, and only maintained by hiring someone outside to update the contents of the software.

We are getting the following warning message "Discarding received non-HL7 data(1) 'r'" . We have tried different framing values to no avail, and it still wants to log this warning. We were just looking for a way to shut this warning off for just this one Operation.

0 0
Jeffrey Drumm · Feb 6, 2018

Looks like changing the framing would require a modified Parser anyway. So ...

I think you'll have to create a copy of EnsLib.HL7.Service.Standard (something like OSU.HL7.Service.CrappyFraming) that changes the  %Parser property to be your custom parser:

Property %Parser As OSU.Custom.HL7.CrappyFramingParser [ Internal ];

Then modify the custom service that was developed long, long ago to subclass it:

Class OSU.HL7.Service.TCPService Extends OSU.HL7.Service.CrappyFraming[ ClassType = "", ProcedureBlock, System = 4 ]
1 0
Scott Roth · Feb 7, 2018

The application is sending us the following back... Of course it does not match up to any structure but like you said they probably have omitted the backslash from the ACK causing the error.

MSH|^~\&|GCRC|RDM|INTENG||20180207084732||SIU^S12|70577207|P|2.3|
MSA|AA|Successful|

I went ahead and made copies of 4 different EnsLib.HL7 classes, and modified the Parser to not throw the warning message. So for it is working like it should.

0 0