I have a project that uses the HL7 Encoder with the JMS BC to convert HL7 v2.x delimited messages to HL7 v2.x XML messages. I've received a couple of messages that contain badly formed field repetitions in the PID.3 field. The source application is sending messages in which the first repetition in the field is empty and the second repetition has data. This causes the HL7 Encoder to improperly parse the field and either give an error indicating PID.3 is empty (when PID.3 is set as required) or place the second repetition in PID.4 (when PID.3 is set as optional). Setting the PID.3 field as optional in the XSD for the message doesn't get around this problem. My last option to resolve this issue is to create a utility web service that identifies and corrects this specific problem in any of the HL7 fields. This service would have to get called prior to the message being handle by the HL7 Encoder, hence it will have to be done without first converting the HL7 message to XML (i.e. using Java, instead of BPEL). Has anyone run into this same problem and found a good work-around?
We are using Glassfish v2.1/Java CAPS 6.2. Any help is appreciated.
Edited by: jamies on May 10, 2010 4:09 PM
Edited by: jamies on May 10, 2010 4:27 PM