Do tables repeat? #172
Comments
|
This item will make the library even better, a step in the right direction. Nothing wrong with having clear guidelines hence |
child loops to be repeatable (per X12 specifications); added TableDef.repeatable_detail for other cases (#172) - Improve error messages in BuilderDsl by adding position and better descriptor (AbstractVal#descriptor) - Create pass/, fail/, skip/, and case/ directories for fixtures for each transaction set; pass/, fail/, and skip/ automatically create rspec examples and case/ are ignored (to be used for hand-written rspec examples) - Deprecate 005010X223 and 005010XX223A1 HC837, since HIPAA mandated 005010X223A2 HC837; in case it's accidentally still used, old (X223, X223A1) are aliased to the new (X223A2) - Define 005010X223A2 HC837 - Fix incorrect set of allowed values in 005010X214 HN277's 2220D STC10-03 and STC11-03; fix wrong requirement designation for 2220D DTP Service Line Date. - Fix wrong requirement designation for 005010X279A1 HB271's 2000D HL segment - Fix countless non-fatal errors in 005010 fixture files, such as element values that aren't allowed; loops, segments and elements that shouldn't be present; missing loops, segments and elements that should be present; incorrect separator characters; wrong element value lengths; ...
repeatable loop, then the table is also considered repeatable; however, the parser will prefer to reuse the current table, if possible, when instantiating new instances of that loop. Otherwise, when the table starts with a segment (optional or mandatory), or a non-repeatable loop, then the table cannot be repeated. Fix an issue (previously irrelevant) so tables can begin with not only the first required SegmentUse or LoopDef declared, but all segments or loops that start at the same position. Now tables that begin with a qualified loop (eg, 2000A, 2000B, 2000C) work with the above changes. Make a change so the parser, when inserting a segment, will always figure out a single Instruction to execute, but when looking for an existing segment it will execute an Instruction for each possibility (eg, when a loop's start segment could've been placed in either a new table or the current one). Restore 005010X212 HR276 and 005010X214 HN277 to their ideal state, now that TableDef.detail infers whether the table is repeatable or not, and now that the parser accomodates both cases correctly. Write specs for Navigation#find that enumerate most possible cases with a minimal grammar defined for each case
|
Finally X12 replied to my question but it didn't help my understanding of this issue. Given that it took 9 months to receive an answer, I don't think I'm going to ask a clarifying question. I asked about 005010X214 HN-277 page 26, where two "Table 2"s with repeatable loops are shown. One is for patient details and the second is for billing provider details. Their response is that there is only one table, and the order of I'm not completely sure how to interpret that response. Maybe they mean that the transaction set shows two tables only for explanatory purposes, but logically it's the same table. I'll come back to this later, but that's what seems most likely to me. To implement that, I don't think it would require changing the parser, just the definition classes and helpers would change. For example |
|
There is only one Table 2 in 277, though it defines multiple loops.
"Detail areas" -- i.e. non-nested loops described in Table 2 -- simply repeat according to their loop repetition specification, with no requirements for adjacent loops. (Caveat: The HIPAA implementation guides require that HL-loops are arranged in depth-first hierarchical order.) |
|
Thanks Paul, that clears things up very well. My file server is down so I can't look for those quotes. What is that document's name/title? Hopefully it's not something that was sitting under my nose the whole time! |
|
That's in the X12 standard (X12.59, section 5). I have that in .chm form. |
Most X12 transaction set definitions have three tables: a header table, a detail table, and a summary table. The header and summary tables usually begin with a non-repeatable segment (eg,
STandSE); it seems clear that the tables must only occur once. In HP835, the summary table begins with an optional, repeatablePLBsegment; however, it still doesn't make sense for the table to be repeated, because that would allow more than oneSEsegment.Unlike header and summary tables, it's less clear if entire detail tables can be repeated, or if only the loop directly inside the tables can repeat. In most cases there is only a single detail table, and it begins with a repeatable loop; it's not clear if occurrences of that loop should each be placed in the same table or each in their own table. For most purposes, it doesn't matter. Currently (v1.2.0), each loop will be parsed into a separate table.
In other cases, there are detail tables which begin with either a non-repeatable segment or loop (005010X214 HN277). It's not clear if the table should be allowed to repeat, but most likely it should not. Finally, there are cases where a transaction set has multiple detail tables (005010X214 HN277). When these begin with repeatable segments or loops, then the ambiguity about repeating tables becomes significant.
If tables cannot repeat, then interleaving multiple detail tables would not be allowed. For example, in 005010 HN277,
Table 2 - Billing Provider Detailbegins with a repeatbleHL**19loop, andTable 2 - Patient Detailbegins with a repeatableHL**PTloop. Suppose the input contains the sequenceHL**19,HL**19,HL**PT. This could be organized into a singleBilling Provider Detailtable (with two occurrences of theHL**19loop), followed by a singlePatient Detailtable. Now suppose the order is changed toHL**19,HL**PT,HL**19. This must construct at least twoBilling Provider Detailtables. If tables cannot be repeated, this would be a syntax error.I have sent a request to X12 for clarification, but I expect it will take a few months for a response. In the meantime, I will be changing
TableDef.detailto define a non-repeatable table, and I will addTableDef.repeatable_detailas its counterpart. One advantage of this change is thatTransactionSetDefswill more closely match the documentation they're derived from, both superficially and meaningfully.The text was updated successfully, but these errors were encountered: