Adding the additional accepted values for a segement about stupidedi HOT 1 CLOSED

Hi, it depends on the circumstances. I assume you are talking about changing this for a particular TransactionSetDef -- either a transaction set standard or an implementation. The difference between the two is a bit of X12 trivia, but implementations are basically a "narrowed down" standard. The standard defines some grammar that is either required or optional, repeat counts, and some other coarse details. Any implementations of the standard can skip the optional things, but they must keep required things.

So if you want to change an transaction set implementation, you would make a copy of the definition in a new file. Then you'd edit a line like this one. Suppose I wanted to change that allowed list for the the NM1 segment defined. NM1 is defined here, which tells us the element within the segment I'm changing is the 8th one, the E66 element. That element is defined here, where you can see the full list of allowed values.

If you want to allow a value that's within that full set, you're fine and just need to add it in your transaction set definition. Put the copied/edited transaction set somewhere in your application, then wire it up in your parser configuration using #customize like this.

But you cannot specify values in the transaction set that aren't in the "full set" of values for the element definition, because that would violate X12 standards. One of the main design goals of this library is to prevent the creation of invalid documents that would be rejected by a trading partner -- with medical billing, this could result in negative financial consequences for a physician's office.

I only have access to a limited set of documentation on X12, namely the 5010 HIPAA transaction set definitions. That means there are things which aren't included in the library's definitions which are indeed valid with respect to X12's specs. You can submit a PR to add them if you can provide reasonable evidence that the standard permits it -- this means something besides a single trading partner, but something like a clearing house or a validation service, or even X12 documentation. I'm happy to accept PRs like this.

If you can't provide this evidence, I recommend skipping the PR and forking a copy of the library for your own use. You might be able to edit the list at runtime, which means you don't need to fork, but it is a crude approach. Maybe a feature like the ability to edit schemas at runtime would come in handy, but it's mostly against the design goals so I'm not likely to build it.

Because this particular change might require editing an ElementDef, it potentially affects every other grammar shipped with the library within the same X12 version. Other changes to grammars are not as invasive, so if you want to add a missing segment to a transaction set, or remove one, etc, this can be done by simply copying the transaction set definition, moving it some place in your application, making your edits, and then wiring it into a Config.

from stupidedi.