In 005010X214 HN-277, there are two tables, "Table 2 Billing Provider of Service Detail" and "Table 2 Patient Detail" which each contain an HL loop that can be repeated (disregard the other tables, since they do not have a repeatable HL loop).
If a file contains some number of HL*..*..*19 loops, these could be grouped into a single "Table 2 - Billing Provider of Service Detail". If these are then followed by some number of HL*..*..*PT loops, these could be grouped into a single "Table 2 - Patient Detail".
However, if following that, there is another HL*..*..*19 loop, then it would conceivably belong to a different "Table 2 - Billing Provider of Service Detail" from the first. Does this mean that there may exist multiple occurrences of a table? Surely this is not the case for most header and summary tables, though. Or must all the HL*..*..*19 loops precede any HL*..*..*PT loops? Since the tables themselves are not marked repeatable, required, optional, etc, do they have any syntactical meaning?
There is only one table 2 in the 277 transaction set. There are multiple hierarchical loops within this table 2. These hierarchical loops are defined in BHT01 of the 005010X214E2 Technical Report Type 3 (TR3) to be Information Source, Information Receiver, Provider of Service, Patient. Appendix B of the 005010X214E2 TR3 specifies that these hierarchical loops shall appear in the hierarchical order specified in BHT01. That is, an HL parent loop must be followed by the subordinate child loops, if any, prior to commencing a new HL parent loop at the same hierarchical level.
This means that the first HL*..*..*19 Billing Provider of Service loop is immediately followed by the subordinate HL*..*..*PT Patient Detail loops for that provider. If there is another Billing Provider of Service, another HL*..*..*19 loop then follows with its subordinate HL*..*..*PT loops. If there are third and subsequent Billing Provider of Service loops, they each follow with their subordinate HL*..*..*PT loops.
Additional references:
Section 5.4 (Heading/Summary Areas of a Transaction Set) of X12.59 (Implementation of EDI Structures – Semantic Impact:
Most EDI transaction sets are designed so as to be divided into discrete "areas," which are typically identified in the transaction set definition by distinct tables of segments.
The split of transaction sets into heading, detail, and summary areas is very common among EDI transaction set definitions. Unless otherwise defined in the publication of a transaction set definition, the heading, detail, and summary areas of a transaction set will be referred to as Tables 1, 2 and 3, respectively, excluding the transaction set header (ST) and trailer (SE). Note that Table 2 would encompass multiple detail areas, if applicable.
Section B.1.1.4.3 (HL Structures) of TR3 005010X214E2 Appendix B:
The HL segment is used in several X12 transaction sets to identify levels of detail information using a hierarchical structure, such as relating dependents to a subscriber. Hierarchical levels may differ from guide to guide.
For example, each provider can bill for one or more subscribers, each subscriber can have one or more dependents and the subscriber and the dependents can make one or more claims.
Each guide states what levels are available, the level's usage, number of repeats, and whether that level has subordinate levels within a transaction set.
For implementations compliant with this guide, the repeats of the loops identified by the HL structure shall appear in the hierarchical order specified in BHT01, when those particular hierarchical levels exist. That is, an HL parent loop must be followed by the subordinate child loops, if any, prior to commencing a new HL parent loop at the same hierarchical level.
RFI #1719 provides additional clarification on HL segment order.