Discarding Received non HL7 data

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

  • 0
  • 0
  • 511
  • 10
  • 0

Comments

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.

Thanks Jeffery,

   Is there any way to handle this via any settings?

Because we are using standard business service. We are not using any customized one like (OnProcessInput()).

 

There aren't any "userland" settings in the HL7 service configuration that will allow a carriage return to be treated as both a segment delimiter and, well, not a segment delimiter. They're mutually exclusive.

This situation is one of the reasons why InterSystems supports custom services ...

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

This error is usually indicative of a framing issue. Have you looked at what, specifically, this non-HL7 data consists of?

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.

 

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 ]

 

 

Looking at the error you're getting, I'm suspecting that the vendor of the external application that feeds your service intended to include a \r (carriage return) as the EOD character and somehow managed to omit the backslash. That would explain the 'r' character ... it's always an 'r' in the error that's generated, right?

 

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.