kputnam / stupidedi

Ruby API for parsing and generating ASC X12 EDI transactions
BSD 3-Clause "New" or "Revised" License
265 stars 138 forks source link

Semantics behind versioning of EDI transactions for Institutional Claims #174

Closed RomanKapitonov closed 5 years ago

RomanKapitonov commented 5 years ago

I'm currently into institutional claims which is basically an 837I. The question I have is related to the consolidated documents listed in the implementation guide for Health Care Claim: Institutional (837). The document I'm using is dated June 2014, which also lists the following consolidated documents:

Consolidated Documents: May 2006 005010X223 October 2007 005010X223A1 June 2010 005010X223A2 June 2014 005010X223A3

It's not very clear from the code which one is being used to implement the transaction schema. Going through each single segment/element definition is very time consuming, so I'm wondering whether there exists a faster way to figure out which exact version the current implementation stands for. Hipaa config contains the following versions:

https://github.com/irobayna/stupidedi/blob/f3ca1a27b6cc5e25038086c18374076a40a4fbdd/lib/stupidedi/config.rb#L97-L127

Even though it does contain an institutional claim (005010X223), it's not clear which exact one. The transaction set for 837I was registered by @pepito2k Gonzalo Robaina dated 2016-11-21, so I assume that commit may already be utilizing the most recent 005010X223A3 version, but not sure. Perhaps someone has more details on the versioning.

Apart from that It may be a good idea to refine the versioning semantics, since it seems those guides are being updated time to time. Or simply add a precise version of the implementation guide. But that would imply going through every single schema in order to figure that out.

irobayna commented 5 years ago

@RomanKapitonov I'm not 100% sure but It seems only 005010X223 x.register("005010X223", "HC", "837") { Stupidedi::Guides::FiftyTen::X223::HC837I }

If other versions had been defined I would expect would follow a similar pattern to the professional one (837P) where you will see two different ones have been defined (regular one and A1):

x.register("005010X222",   "HC", "837") { Stupidedi::Guides::FiftyTen::X222::HC837P }
x.register("005010X222A1", "HC", "837") { Stupidedi::Guides::FiftyTen::X222A1::HC837P }
pepito2k commented 5 years ago

Hi,

The implementation on the gem responds to the implementation guide dated MAY 2006, so it is 005010X223.

Bests, Gonzalo.

On Mon, Jan 21, 2019 at 9:08 AM Isi Robayna notifications@github.com wrote:

@RomanKapitonov https://github.com/RomanKapitonov I'm not 100% sure but It seems only 005010X223 x.register("005010X223", "HC", "837") { Stupidedi::Guides::FiftyTen::X223::HC837I }

If other versions had been defined I would expect would follow a similar pattern to the professional one (837P) where you will see two different ones have been defined (regular one and A1):

x.register("005010X222", "HC", "837") { Stupidedi::Guides::FiftyTen::X222::HC837P } x.register("005010X222A1", "HC", "837") { Stupidedi::Guides::FiftyTen::X222A1::HC837P }

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/irobayna/stupidedi/issues/174#issuecomment-456052606, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlb3_K7vddWroo-dCnMw3h_F6feaogfks5vFa2xgaJpZM4aKn9f .

kputnam commented 5 years ago

Thanks Gonzalo. Do you send/receive 005010X223, or do you send/receive 005010X223A2, but that was the documentation you had available? I had the impression that HIPAA mandated the use of X223A2, but maybe people are still using X223 or X223A1.

@pepito2k and @RomanKapitonov, in a separate branch that hasn't been merged, I planned to deprecate X223 and X223A1 but have them link to X223A2 with a deprecation notice. However, I don't have the changes document for A1 and A2.

If either of you have that available, could you please review this file? I'm not sure if you can submit a PR to a branch other than master, but if so, that would be appreciated; otherwise, maybe you can send a gist or just comment on the existing PR #164, if the changes are small.

RomanKapitonov commented 5 years ago

@kputnam I do have A3 version, i've spent an entire day today comparing it to what is present for X223, yet I'm only half way though. I've found several differences and will come up with a PR in a couple of days.

Unfortunately I do not possess the version for X223A1 and X223A2. At least i've never seen any "change log" inside those docs for the EDI transactions. If you know any source for the change log, please let me know. In any case I anticipate submitting what I have soon.

If you'd rather prefer applying those changes as a single PR (#164 in that case) I may simply push my changes to a separate branch so that you are able to pick those.

kputnam commented 5 years ago

@RomanKapitonov Oh, thanks! The documentation that I have for X222 (not X223) did have separate files, one for X222 and another "changes only" for X222A1. But those were several years ago, when 5010 was being rolled out, so it might be that X12 have consolidated the amendments of each transaction set into a single document. There also is a section "D. Change Summary" at the very end, but I think they are changes since 4050 or completely different version, at least in my case.

RomanKapitonov commented 5 years ago

@kputnam thank you, the doc indeed contains a summary section. As per what it says:

This Implementation Guide defines X12N implementation 005010X223A2 of the Health Care Claim: Institutional. It is based on version/release/subrelease 005010 of the ASC X12 standards. The previous X12N implementation of the Health Care Claim: Institutional was 004050X141, based on version/re- lease/subrelease 004050 of the ASC X12 standards. Implementation of 005010X223A2 contains significant changes and clarifications. It can only be used with other trading partners who have also implemented 005010X223A2. Below is a high-level description of the substantive changes from the previous version.

This reveals the necessity to carefully go through the log in changes summary. A couple of days might not be enough, but I should definitely finish by the end of the week. From what i've done so far current implementation doesn't seem to have lots of changes comparing 005010X223A3 to 005010X223

kputnam commented 5 years ago

Take your time, it is very tedious and painstaking work! The changes between X222 and X222A1 were very small, and I think changed the requirement designator for a few segments and elements, and added one segment.

i-s-o commented 5 years ago

I also did some work on 005010X223A3 yesterday (some corrections to the descriptions etc.). My main motivation was to create 005010X225A2 based on X223. Not sure what the best way is to share the results (I'm new to git, and I'm not a developer).

One thing I noticed is the loop 2300 required v. situational change that was done recently, and I didn't touch it: there is a discussion in the guides about 2300 being a "floating" loop (i.e. it comes after 2010CA if it exist, and after 2010BB if 2010CA didn't exist); and I saw an issue discussion on floating loops, and I didn't know if this is related to that issue.

kputnam commented 5 years ago

@i-s-o, Yes it was made situational because that loop isn't required to occur under both 2000B and 2000C. There's no way in the grammar to encode the requirement that it should occur in at least once, which is what I think X12 intended, so the best option is to make it situational.

Later down the road, those extra constraints (along with the various semantic constraints from the documentation) could be added to the Editor interface, but that's possibly in a crusty state now.

i-s-o commented 5 years ago

@RomanKapitonov If it is helpful in any way, I pushed my changes to x223a3-hc837.rb.

FYI, it looks like the modifications from X223A2 to X223A3 were done to accommodate dual-use of the original payer identification and CMS's then recently finalized rule requiring (but not enforced) HPIDs/OEIDs (see slides by ASC X12N Chair).

Coincidentally, CMS now proposes to eliminate HPIN/OEID requirement.

RomanKapitonov commented 5 years ago

@i-s-o Thank you for the link, that was very helpful, I've noticed some differences between the two versions and come shortly with a summary.

RomanKapitonov commented 5 years ago

@i-s-o please refer to the https://github.com/irobayna/stupidedi/pull/177 PR. If you take a look at https://github.com/irobayna/stupidedi/blob/1d216f755657660a12d761a70dad8c9e1e4cbff7/lib/stupidedi/guides/005010/X223A3-HC837I.rb you'll find what is different compared to your implementation on lines: 192, 194, 195, 196, 1475, 1688, 1711, 1734, 1757, 1925, 2014, 2057, 2058, 2059, 2060, 2536, 2582

I've also noticed some changes missing in my implementation, which I was able to track based on yours.

i-s-o commented 5 years ago

@RomanKapitonov Thanks for the corrections (I didn't catch many of those errors as they are not used in X225).

I think there are still a few discrepancies: could you please double-check the following?

kputnam commented 5 years ago

For future reference, here's a handy way to review the nesting/parentheses of your TransactionSetDef:

ruby -Ilib -rstupidedi -rpp -e 'pp Stupidedi::TransactionSets::FiftyTen::Implementations::X223A2::HC837' | grep -E '(Segment|Table|Loop)Def'
RomanKapitonov commented 5 years ago

@i-s-o You are right, i've missed all those things. I've created a PR https://github.com/irobayna/stupidedi/pull/178 to address those.

Also @kputnam before merging https://github.com/irobayna/stupidedi/pull/164 it should be

ruby -Ilib -rstupidedi -rpp -e 'pp Stupidedi::Guides::FiftyTen::X223A3::HC837I' | grep -E '(Segment|Table|Loop)Def'

for a fancy output of "nestetness"

Thank you!

irobayna commented 5 years ago

@kputnam I wish I would have known about that awesome command years ago. Very useful.