Details
-
Improvement
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
3.14.2
-
None
-
Unknown
Description
Hi
I have noticed some discrepancies between the HL7 component and the MLLP component in how the HL7 Sending Application message header (MSH-3) is extracted from an HL7 message and saved in their respective Camel exchange headers.
In short
The MSH-3 header may contain 3 components separated by "hats" (^)
namespace id^universal id^universal id type
Here is a couple of examples of how the two Camel components interpret these headers:
(1)
HL7 message MSH-3:
UNIVERSAL_ID
Camel exchange headers:
CamelHL7SendingApplication -> UNIVERSAL_ID CamelMllpSendingApplication -> UNIVERSAL_ID
(2)
HL7 message MSH-3:
^UNIVERSAL_ID
Camel exchange headers:
CamelHL7SendingApplication -> null
CamelMllpSendingApplication -> ^UNIVERSAL_ID
(3)
HL7 message MSH-3:
^UNIVERSAL_ID^TYPE
Camel exchange headers:
CamelHL7SendingApplication -> null
CamelMllpSendingApplication -> ^UNIVERSAL_ID^TYPE
So...
I'm not entirely sure what expected behaviour should be. We expected to use the CamelHL7SendingApplication exchange header for validating the sending application Universal Id but as of now we can't really trust it. Similarly CamelMllpSendingApplication isn't useful for validating the Universal Id, otherwise we need to do a manual split of the exchange header and the we would rather just have a Terser do it for us instead. So right now, we just do this instead:
private static String getSendingSystemUniversalId(Message hl7Message) throws HL7Exception { Terser terser = new Terser(hl7Message); return terser.get("MSH-3-2"); }
Link to the MSH-3 standard: