Re: [HAPI-devel] Z segments in Hapi, latest source code and version for download

[Ian V. <ian...@gm...>]

The short answer to your question is yes, through the use of terser.
Terser is very useful, and works well. Parse the message with a pipeparser,
create a terser on the message, use the get method. Your messages may
introduce challenges, that terser can overcome, but it can still end up
being a complex implementation which is potentially fragile if a change
occurs in format of the message.
If you are going to use terser, remember that printstructure is your
friend. If you have message structures which insert Z segments within
groups, and/or standard segments in non standard locations you may find, as
I have, that building custom message structures using hapi is worth the
effort. See the lengthy example below.

Hope this helps
Ian

Example Message (yes, this is based upon reality)
MSH|^~\&|CM^DIETARY|SITE|EIP|SITE|20230118115154||ORM^O01|UniqueID|P|2.3||||||8859/1
PID|1|Lots of fields
PV1|1|Lots of fields
AL1|1|FA|734881000^Tomato^Allergy|MO
ZAL|SNAPSHOT|20230118114955|19937481|19937481|ALLERGY|ACTIVE|||||20230118114953|More
fields
NTE|1||Comments added
AL1|2|FA|255620007^Other - Food Allergy^Allergy
ZAL|SNAPSHOT|20230118115043|19937487|19937487|ALLERGY|ACTIVE|||||20230118115042|More
fields
NTE|1||added allergy
ORC|NW|Lots of fields
OBR|1|Lots of fields
OBX|1|IS|MODTEX^SSH Type of Diet||STD

This test case:

    @Test
    void showZsegmentUsageWithoutCustomMessage() throws HL7Exception {
        ModelClassFactory MCF = new DefaultModelClassFactory();
        PipeParser parser = new PipeParser();
        parser.getParserConfiguration().setValidating(false);
        Message message = parser.parse(REAL_FORMAT_OF_NON_STANDARD_MESSAGE);
        LOGGER.info(message.printStructure());
        Terser terser = new Terser(message);
        LOGGER.info("Terse for ZAL-4 will find the first ZAL and show field
4? " + terser.get("ZAL-4"));
        LOGGER.info("No, it shows the value from the second ZAL, because
the first is in a group.");
        LOGGER.info("Terse for /PATIENT/ZAL-4 will find the first ZAL and
show field 4? " + terser.get("/PATIENT/ZAL-4"));
        LOGGER.info("Yes, it shows the value from the first ZAL, because we
specified the group");
        LOGGER.info("Terse for /NTE2 will find the segment shown as NTE2 in
the printstructure " + terser.get("/NTE2-3"));
        LOGGER.info("Terse for /NTE3 will find the segment shown as NTE3 in
the printstructure " + terser.get("/NTE3-3"));
    }

Produces this output:
ORM_O01 (start)
   MSH -
MSH|^~\&|CM^DIETARY|SITE|EIP|SITE|20230118115154||ORM^O01|UniqueID|P|2.3||||||8859/1
   [ { NTE } ] - Not populated
   PATIENT (start)
   [
      PID - PID|1|Lots of fields
      [ PD1 ] - Not populated
      [ { NTE } ] - Not populated
      PATIENT_VISIT (start)
      [
         PV1 - PV1|1|Lots of fields
         [ PV2 ] - Not populated
      ]
      PATIENT_VISIT (end)
      INSURANCE (start)
      [{
         IN1 - Not populated
         [ IN2 ] - Not populated
         [ IN3 ] - Not populated
      }]
      INSURANCE (end)
      [ GT1 ] - Not populated
      [ { AL1 } ] - AL1|1|FA|734881000^Tomato^Allergy|MO
      [ { ZAL } ] (non-standard) -
ZAL|SNAPSHOT|20230118114955|19937481|19937481|ALLERGY|ACTIVE|||||20230118114953|More
fields
   ]
   PATIENT (end)
   ORDER (start)
   {
      ORC - Not populated
      ORDER_DETAIL (start)
      [
         <
            OBR - Not populated
         |
            RQD - Not populated
         |
            RQ1 - Not populated
         |
            RXO - Not populated
         |
            ODS - Not populated
         |
            ODT - Not populated
         >
         [ { NTE } ] - Not populated
         [ { DG1 } ] - Not populated
         OBSERVATION (start)
         [{
            OBX - Not populated
            [ { NTE } ] - Not populated
         }]
         OBSERVATION (end)
      ]
      ORDER_DETAIL (end)
      [ CTI ] - Not populated
      [ BLG ] - Not populated
   }
   ORDER (end)
   [ { NTE2 } ] (non-standard) - NTE|1||Comments added
   [ { AL1 } ] (non-standard) - AL1|2|FA|255620007^Other - Food
Allergy^Allergy
   [ { ZAL } ] (non-standard) -
ZAL|SNAPSHOT|20230118115043|19937487|19937487|ALLERGY|ACTIVE|||||20230118115042|More
fields
   [ { NTE3 } ] (non-standard) - NTE|1||added allergy
   [ { ORC } ] (non-standard) - ORC|NW|Lots of fields
   [ { OBR } ] (non-standard) - OBR|1|Lots of fields
   [ { OBX } ] (non-standard) - OBX|1|IS|MODTEX^SSH Type of Diet||STD
ORM_O01 (end)

Terse for ZAL-4 will find the first ZAL and show field 4? = 19937487
No, it shows the value from the second ZAL, because the first is in a group.
Terse for /PATIENT/ZAL-4 will find the first ZAL and show field 4 =
?19937481
Yes, it shows the value from the first ZAL, because we specified the group
Terse for /NTE2 will find the segment shown as NTE2 in the printstructure =
Comments added
Terse for /NTE3 will find the segment shown as NTE3 in the printstructure =
added allergy

Note how the non-standard segments (extra NTE segment and ZAL) push the
ORC, OBR and OBX segments out of the normal structure. As a result, it will
be almost impossible to deal with these messages without creating a custom
structure to accommodate the non standard segments in a repeating group.


On Wed, 31 May 2023 at 04:26, Michael Godinez via Hl7api-devel <
hl7...@li...> wrote:

> Hi,
>
>
>
> I am trying to determine if Hapi supports any Z segment type without
> needing to code anything new within Hapi?
>
> Also I am trying to find the latest source code and version for download.
>
>
>
> Thanks so much,
>
> Mike
>
>
>
> *Mike Godinez*
> Sr. Software Engineer
>
> Email: mic...@he...
>
>
> _______________________________________________
> Hl7api-devel mailing list
> Hl7...@li...
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>