[jira] [Created] (CAMEL-18709) Discrepancies between CamelHL7SendingApplication and CamelMllpSendingApplication exchange headers

["Michael Jensen Garde (Jira)" <ji...@apache.org>]

Michael Jensen Garde created CAMEL-18709:
--------------------------------------------

             Summary: Discrepancies between CamelHL7SendingApplication and CamelMllpSendingApplication exchange headers 
                 Key: CAMEL-18709
                 URL: https://issues.apache.org/jira/browse/CAMEL-18709
             Project: Camel
          Issue Type: Improvement
    Affects Versions: 3.14.2
            Reporter: Michael Jensen Garde


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.
h2. In short

The MSH-3 header may contain 3 components separated by "hats" (^)

 
{code:java}
namespace id^universal id^universal id type
{code}
Here is a couple of examples of how the two Camel components interpret these headers:
h3. (1)

HL7 message MSH-3:
{noformat}
UNIVERSAL_ID{noformat}
 

 

 

Camel exchange headers:

 
{code:java}
CamelHL7SendingApplication -> UNIVERSAL_ID
CamelMllpSendingApplication -> UNIVERSAL_ID{code}
h3. (2)

HL7 message MSH-3:

 

 
{code:java}
^UNIVERSAL_ID{code}
Camel exchange headers:
{code:java}
CamelHL7SendingApplication -> null
CamelMllpSendingApplication -> ^UNIVERSAL_ID{code}
 
h3. (3)

HL7 message MSH-3:
{code:java}
^UNIVERSAL_ID^TYPE{code}
Camel exchange headers:
{code:java}
CamelHL7SendingApplication -> null
CamelMllpSendingApplication -> ^UNIVERSAL_ID^TYPE{code}
h2. 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:
{code:java}
private static String getSendingSystemUniversalId(Message hl7Message) throws HL7Exception {
    Terser terser = new Terser(hl7Message);
    return terser.get("MSH-3-2");
} {code}
 

*Link to the MSH-3 standard:*

https://hl7-definition.caristix.com/v2/HL7v2.8/Fields/MSH.3



--
This message was sent by Atlassian Jira
(v8.20.10#820010)