Doug Strzalko · Sep 17, 2021

Record Map with Repeating Fields

I'm working on a project were we are going to be receiving a non-HL7 formatted flat file that will contain a single result message per line and each result messages may  contain repeating OBX fields that will need to be parsed out so that can be sent as an HL7 ORU messages that contains multiple OBX segments.

The record map I currently have doesn't appear to be able to parse out the repeating OBX fields in the source file, currently my Record Map uses the “|” as the first field separator and the “^” as the second and the “~” as the repeat separator.

Source file format:

|<PID-3>|<PID-5>|<PID-7>|<PID-8>|<PID-19>|<PV1-3>|<PV1-19>|<OBR-3>|<OBR-4>|<OBR-7>|<OBR-16>|<OBR-22>|<OBR-25>|<OBX-2( repetition 1)>^<OBX-3(repetition 1
)>^<OBX-5(repetition 1)>^<OBX-6(repetition 1)>^<OBX-7(repetition 1)>^<OBX-8(repetition 1)>^<OBX-11(repetition 1)>~<OBX-2( repetition 2)>^<OBX-3(repetition 2)>^<OBX-5(repetition 2)>^<OBX-6(repetition 2)>^<OBX-7(repetition 2)>^<OBX-8(repetition 2)>^<OBX-11(repetition 2)>~ETC>|



Target HL7 formatted OBX Segments:




Any assistance help would be greatly appreciated.



Product version: Ensemble 2018.1
0 229
Discussion (10)2
Log in or sign up to continue

No, I was trying to use just a Record Map

I believe with a repeating segment/field, you would need to use a Complex RecordMap - made up of RecordMaps of all the segments - MSH, PID, OBX - with the OBX as repeating.

To use a complex record map I will need to have the source file format to be modified to something like this, correct?



OBR |<OBR-3>|<OBR-4>|<OBR-7>|<OBR-16>|<OBR-22>|<OBR-25>|

OBX |<OBX-2>|<OBX-3>|<OBX-5>|<OBX-6>|<OBX-7>|<OBX-8>|<OBX-11>|

OBX |<OBX-2>|<OBX-3>|<OBX-5>|<OBX-6>|<OBX-7>|<OBX-8>|<OBX-11>|

OBX |<OBX-2>|<OBX-3>|<OBX-5>|<OBX-6>|<OBX-7>|<OBX-8>|<OBX-11>|

Hey Doug,

It's been a very long time :)

So ... no, you don't need a complex record map to do this, but the mechanism takes just a little more work using a "simple" record map. The record map feature doesn't let you set a Composite field as repeating, which is why we need to deal with those "grouped" OBX segments/fields using a different method.

What I've done is define the RecordMap with individual fields for everything before the first OBX field, and then define the rest of the record as a single, repeating field. You can then iterate over that last field and parse out the individual HL7 field values with $PIECE, or turn them into a $LIST and  reference the elements by numeric index. The only delimiters you'll need to set for the record map are a "|" as the field delimiter and a "~" for the repetition delimiter.

Here's a sample record map layout:

Along with setting OBXSegs as repeating, I set the MAXLEN DataType parameter to something large enough to accommodate all of the fields. Also note the Discard field; the sample data in your post included a leading "|," so that needs to be treated as though there's an initial empty field in each record. Including a dummy field to consume it makes things a bit more understandable when addressing the subsequent fields.

Here's one way you might iterate over the repeating record map field:

As you surmised in a follow-up to Nora's earlier posts, the Complex Record Map functionality is really only required when the record structure varies from line to line in the input data.

Hi Jeff,

Good to hear from you :)

I updated my record map and data transformation but when I tried to process a message I received the following errors

I must be missing something because when I created my data transformation and selected my record map as the Source Class it won't allow me to define a Source Document Type.


Hi Doug,

If you're creating a Busness Process to route/translate RecordMap messages, you'll want to use EnsLib.MsgRouter.RoutingEngine as the BP class. It doesn't expect a document type, unlike the VDoc class.

EDIT: I should have also mentioned that there's no need to select a document type for the RecordMap in the DTL editor, since they don't have one laugh

Thanks Jeff,

it looks like it parsing the OBX fields now

Now I need to figure out why it's not hitting the rule with my data transformation

Assuming you have the service pointed in the right direction, there may be something wrong in either the configuration of the router or the rule itself.

The relevant configuration details from the "General" tab of the rule:

And a basic example of how you'd create a rule based on field criteria:

Hi Jeff,

I just to let you know after I updated the rule and corrected a type-o in the transformation :) I was able to get the OBX data to populate the correct OBX fields

Thanks again for all of your help.