HL7: Custom Z Segment

Introduction

This example shows how to use the hl7.zsegment.lua module to parse Z segments without needing grammar definitions in a VMD file.

If you have any questions please contact us at support@interfaceware.com.

Using the Code [top]

  • Import the HL7: Custom Z Segment channel from the Builtin: Iguana Protocols repository
  • Experiment with the code to find out how it works
  • Then add the module to your Translator project
  • Copy the require statement from the channel and add it at the top of your script
    Note: This module uses require to return a single function
  • Adapt the code to your own requirements
  • Use the hl7.zsegment.parse{} function to parse Z segments
  • Choose which parsing mode to use: Compact or Expanded
  • Interactive scripting help is included for this module

This is the github code for the main module:

Which parsing mode to use:

Expanded:

  • Generally recommended
  • Works with optional sub-fields and repeats

Compact:

  • Only works if message format is always identical
  • Does not work with optional sub-fields and repeats

Try out the messages supplied with the channel. The surname field has an optional Title sub-field, which causes problems with the Compact mode parse. The first message contains the Title “Mr”, this is removed from the second message. You will notice that the Expanded mode uses same path to find the surname for both messages. However the  Compact mode needs to use different paths for each message (as the Compact parse returns a different tree structure for each message).

How it works [top]

This module simply iterates through all the segments in a message, looking for Z segments (segments that start with “Z”). When it finds a Z segment it parses it, and appends it to a table. When the end of the message is reached the table (containing zero or more parsed Z segments) is returned .

Compact versus Expanded parsing modes:

Expanded: Generally recommended, works with optional sub-fields and repeats.

Compact: Only works if message format is always identical, does not work with optional sub-fields and repeats.

For example: The sample messages include an optional Title sub-field under the surname field. The first message contains the Title “Mr”, this is removed from the second message. This causes problems with the Compact parsing mode but works fine with the Expanded mode.

With the first message both Compact and Expanded mode use the same path:

With the second message the path for the Compact mode changes:

More information [top]

Tagged: