Are segment field idx numbers supposed to match HL7 field seq numbers?

[Obversity]

Hi guys,

Question: does the segment field idx match up to the HL7 spec's field seq numbers? E.g. should MSH-9 (Message Type) be accessible via msg[:MSH][9]?

Background: Trying to build a tool to dynamically extract data from HL7 segments by users specifying the Segment name and the field number.

Problem: I immediately ran into problems doing that, discovering that in the MSH segment, the field with IDX = 9 isn't the Message Type field.

All documentation on HL7 MSH segment indicates that the Message Type should be MSH-9.

I figured maybe it was just zero-based indexing and I could offset by one, but that doesn't seem to be the case for other segments, e.g. for this OBR segment, 4 is the correct sequence for the Universal Service Identifier, and that's what's in the file I'm looking at.

Some clarification would be great so I can confidently use the library, thanks in advance!

[LucasMontorio]

Hi @Obversity ,

Sorry for the late reply (I just started contributing to this repo recently), I hope this still helps.
I believe the issue you are facing here is specific to the MSH segment, on which MSH-1 has not been implemented as a proper field, despite being a required field according to the following documentation: https://hl7-definition.caristix.com/v2/HL7v2.8/Fields/MSH.1.
This results in a offset of 1 in all the indexes of the subsequent fields.

I'm not sure of the impact yet but I believe the gem has been formatting MSH segments with this offset from day 1.
Can you confirm that the MSH segments you generated were properly formatted despite the getters behaving this way?

[LucasMontorio]

According to the doc, the MSH-1 field "contains the separator between the segment ID and the first real field, MSH-2 Encoding Characters".
Hence, the gem does not have a setter for this field, which causes the offset to happen because we expect all fields to be explicitly defined via such a setter. I will fix this case ASAP

[LucasMontorio]

Issue fixed in the following PR: #141