FHIR Chat · FT1-29 and FT1-43

Stream: V2

Topic: FT1-29 and FT1-43

Vassil Peytchev (Oct 27 2020 at 20:10):

The Chapter 6 description of these fields states:

Definition: This field has been defined for NDC codes that are required by HIPAA for electronic claims for Pharmacy charges. Refer to Externally-defined Table 0549- NDC Codes in Chapter 2C, Code Tables, for suggested values.

If a system supports multiple NDC codes for a charge, this information will be sent in OBX segments. FT1-29 and FT1-43 can be used for single NDC codes and quantities instead of using OBX.

The problem with this description is that (at least in the DFT messages) there are no OBX segments directly associated with the FT1 segment. Can we allow these fields to repeat for multiple NDC codes?

Craig Newman (Oct 30 2020 at 13:00):

Response from Beat Heggli:
In all message structures of Chapter 6 the OBR, ORC, and OBX segments are not mandatory and the usage of the preceding OBR, ORC is not absolutely necessary. In message structures like BAR_P01, BAR_P05 there are single OBX segments We can also find single OBX segments in other chapters, eg. Chapter 9. All these message structures have in common, that the OBX-Segment appears only once in the whole message ( repeatable or not).

If there are several OBX-Segments possible, like in the DFT_P03, we have to take care that the usage of a single OBX segment without OBR, ORC doesn’t lead to unparsable messages. In this message structure the OBX segment is part of a segment group COMMON_ORDER and FINANCIAL_COMMON_ORDER and for groups there are some requirements defined in chapter 2_Controls 2.5.2.:

As of v 2.5, the first segment in a newly defined segment group will be required to help ensure that unparsable messages will not be inadvertently defined. This required first segment is known as the anchor segment.

If we follow this rule there is a least a preceding OBR segment necessary before the OBX. Nevertheless in all Financial messages the OBX are either contained in a single order group or the order group is part of another group (like FINANCIAL with the FT1 segment) and appears only once in this group .

In my opinion the usage of a OBX segment without OBR, OCR should be possible in financial messages and does not create unparsable messages.

Vassil Peytchev (Oct 30 2020 at 23:29):

In my opinion the usage of a OBX segment without OBR, OCR should be possible in financial messages and does not create unparsable messages.

This contradicts both the rule in chapter 2, and what is in version 2.9 (I was wrong about OBR, but ORC is still required):

{             --- FINANCIAL begin
  FT1
  <other segments and groups skipped>
  [{             --- FINANCIAL_COMMON_ORDER begin
    ORC            Common Order (specific to above FT1)
    [{ PRT }]      Participation
    [{             --- FINANCIAL_TIMING_QUANTITY begin
      TQ1            Timing/Quantity
      [{ TQ2 }]      Timing/Quantity Order Sequence
    }]             --- FINANCIAL_TIMING_QUANTITY end
    [              --- FINANCIAL_ORDER begin
      OBR            Order Detail Segment
      [{ PRT }]      Participation
      [{ NTE }]      Notes and Comments (on Order Detail)
    ]              --- FINANCIAL_ORDER end
    [{             --- FINANCIAL_OBSERVATION begin
      OBX            Observations / Result
      [{ PRT }]      Participation
      [{ NTE }]      Notes and Comments (on Result)
    }]             --- FINANCIAL_OBSERVATION end
  }]             --- FINANCIAL_COMMON_ORDER end
}              --- FINANCIAL end

Frank Oemig (Nov 02 2020 at 10:02):

It sounds like we have to create a new message structure to fix it.

Vassil Peytchev (Nov 18 2020 at 21:58):

After a few e-mails. I think the current status of the issue is that:

The intent was to have independent OBR, and independent OBX segments follow the FT1 segment
The message structure before version 2.9 was not deterministically parsable, and that was "fixed" in 2.9, resulting in the above structure - which is not compatible with version 2.8 and earlier.

Given the above, I believe that it is appropriate to get a technical correction on the message structure that will allow for deterministically parsable messages and will allow independent OBR and OBX segments to follow FT1 as follows:

{             --- FINANCIAL begin
  FT1
  <other segments and groups skipped>
  [{             --- FINANCIAL_OBSERVATION_STANDALONE Begin
    OBX            Observations (directly related to FT1)
    [{ PRT }]      Participation
    [{ NTE }]      Notes and Comments (on Result)
  }]             --- FINANCIAL_OBSERVATION_STANDALONE End
  [{             --- FINANCIAL_ORDER_STANDALONE Begin
    OBR            Order Detail Segment
    [{ PRT }]      Participation
    [{ NTE }]      Notes and Comments (on Order Detail)
    [{             --- FINANCIAL_OBSERVATION begin
      OBX            Observations / Result
      [{ PRT }]      Participation
      [{ NTE }]      Notes and Comments (on Result)
    }]             --- FINANCIAL_OBSERVATION end
  }]             --- FINANCIAL_ORDER_STANDALONE End
  [{             --- FINANCIAL_COMMON_ORDER begin
    ORC            Common Order (specific to above FT1)
    [{ PRT }]      Participation
    [{             --- FINANCIAL_TIMING_QUANTITY begin
      TQ1            Timing/Quantity
      [{ TQ2 }]      Timing/Quantity Order Sequence
    }]             --- FINANCIAL_TIMING_QUANTITY end
    [              --- FINANCIAL_ORDER begin
      OBR            Order Detail Segment
      [{ PRT }]      Participation
      [{ NTE }]      Notes and Comments (on Order Detail)
    ]              --- FINANCIAL_ORDER end
    [{             --- FINANCIAL_OBSERVATION begin
      OBX            Observations / Result
      [{ PRT }]      Participation
      [{ NTE }]      Notes and Comments (on Result)
    }]             --- FINANCIAL_OBSERVATION end
  }]             --- FINANCIAL_COMMON_ORDER end
}              --- FINANCIAL end

Comments?
@Frank Oemig @Craig Newman @Anthony(Tony) Julian @k connor

k connor (Nov 18 2020 at 23:55):

I support Vassil's proposal but FM doesn't have a v2 editor at this time so not sure how to proceed. If Vassil would kindly submit the CR, I will move it through FM for approval, of course with agreement from other v2 editors. Then, guess that FM has to find a v2 editor. Vassil, are you available to draft this change using v2 publishing processes?

Vassil Peytchev (Nov 19 2020 at 04:27):

Should I use a Jira ticket, or GForge?

k connor (Nov 19 2020 at 04:46):

Good question Vassil - seems like the v2 tickets on next FM agenda https://confluence.hl7.org/display/FM/2020-11-24+FM+Interim+Meeting+-+DRAFT are in gforge. But I thought we're supposed to migrate to JIRA. I put that question in the agenda. So let's wait and see what the answer is. I've got the issue documented in the agenda, so likely ok for now. But maybe Tony or Frank have better guidance?