[
https://issues.apache.org/jira/browse/CAMEL-18709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jensen Garde updated CAMEL-18709:
-----------------------------------------
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.
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]
was:
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
> 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
> Priority: Minor
>
> 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)
