Hi David, thanks for the response here. I did end up coming to a solution,
which looks like:
/**
* Parse an hl7 message and extract the header (MSH) segment.
*
* @param hl7Message The hl7 message to parse.
* @return The parsed MSH segment, or null on error.
*/
public static MSH getHeader(final String hl7Message) {
if (Objects.isNull(hl7Message)) return null;
try {
final HapiContext context = new DefaultHapiContext();
// Parse the message in whatever hl7 version it is declared to
be
// This will validate the message structure, throwing an
exception if invalid
context.getPipeParser().parse(hl7Message);
// Convert message into most recent version format, since
they're backwards compatible
final CanonicalModelClassFactory modelClassFactory = new
CanonicalModelClassFactory(CANONICAL_VERSION);
context.setModelClassFactory(modelClassFactory);
// We disable validation because deprecated fields appear to
cause parsing errors when
// up-converting messages
context.setValidationContext(new NoValidation());
final Message parsedMesssage =
context.getPipeParser().parse(hl7Message);
final MSH msh = (MSH) parsedMesssage.get("MSH");
return msh;
} catch (ClassCastException | HL7Exception ex) {
LOG.warn("Unable to parse header from hl7 message:\n{}",
forPrinting(hl7Message));
return null;
}
}
I don't love this, since it requires turning off the validation when
up-versioning, but it appears to work on all test inputs I've attempted.
~Andrew
On Tue, Jan 28, 2020 at 6:28 PM David Bunzli <david.bun...@health.qld.gov.au>
wrote:
> Hi Andrew,
>
> Is your concern about casting related to performance? Because, in general,
> solutions should be provisioned for the work they have to do. If you need
> more processing grunt, its often better to tackle that before 'optimising'
> your code.
>
> Aside from casting the whole message, you can cast the segment [eg
> (pseudo-code) MSH msh = (MSH) Terser.getSegment("MSH")] to get a proper MSH
> object. But this option is still casting.
>
> Another option is treating the message as a String eg...
> protected static String getMsh10(String input) {
> int startOfMsh10 = StringUtils.ordinalIndexOf(input, "|", 10);
> int lengthOfMsh10 = StringUtils.ordinalIndexOf(input, "|", 11) -
> startOfMsh10;
> return StringUtils.mid(
> input
> , startOfMsh10
> , lengthOfMsh10
> );
> }
>
> But that option brings me back to the first point - 'optimising' by String
> manipulation is convoluted. It'd have been better to wear the costs of
> parsing and casting the message and enjoy the benefits of using HAPI.
>
> Hope this helps,
> David
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 23 Jan 2020 18:13:11 -0800
> From: Andrew Ring <andrew.r...@ninesai.com>
> To: hl7api-devel@lists.sourceforge.net
> Subject: [HAPI-devel] Parse MSH from arbitrary message
> Message-ID:
> <CAEw6ye59CaL9rrOF3+Xi0KkvPBrdhhPp3G5gjCNpT+E=ge3...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I'm receiving HL7 messages of any type, and want to examine the MSH
> segment before having to cast the message to a particular type. I can't
> seem to find a mechanism to do this. I can get individual MSH fields using
> a Terser, but I would prefer to use well typed structures. Even getting the
> MSH segment using Terser.getSegment() does not appear to be able to be
> converted into an MSH object. Can anyone help?
>
> Thanks,
> Andrew Ring
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Hl7api-devel mailing list
> Hl7api-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>
> ------------------------------
>
> End of Hl7api-devel Digest, Vol 144, Issue 5
> ********************************************
>
>
>
>
>
> ********************************************************************************
>
> This email, including any attachments sent with it, is confidential and
> for the sole use of the intended recipient(s). This confidentiality is not
> waived or lost, if you receive it and you are not the intended
> recipient(s), or if it is transmitted/received in error.
>
> Any unauthorised use, alteration, disclosure, distribution or review of
> this email is strictly prohibited. The information contained in this email,
> including any attachment sent with it, may be subject to a statutory duty
> of confidentiality if it relates to health service matters.
>
> If you are not the intended recipient(s), or if you have received this
> email in error, you are asked to immediately notify the sender by telephone
> collect on Australia +61 1800 198 175 or by return email. You should also
> delete this email, and any copies, from your computer system network and
> destroy any hard copies produced.
>
> If not an intended recipient of this email, you must not copy, distribute
> or take any action(s) that relies on it; any form of disclosure,
> modification, distribution and/or publication of this email is also
> prohibited.
>
> Although Queensland Health takes all reasonable steps to ensure this email
> does not contain malicious software, Queensland Health does not accept
> responsibility for the consequences if any person's computer inadvertently
> suffers any disruption to services, loss of information, harm or is
> infected with a virus, other malicious computer programme or code that may
> occur as a consequence of receiving this email.
>
> Unless stated otherwise, this email represents only the views of the
> sender and not the views of the Queensland Government.
>
>
> **********************************************************************************
>
>
> _______________________________________________
> Hl7api-devel mailing list
> Hl7api-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
_______________________________________________
Hl7api-devel mailing list
Hl7api-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
