@dkanter Thank you. It makes sense, but only for 271 from Medicare. Indeed HETS returns a 271 2110C EB01 of ‘U’ for
Medicare Advantage plans (as the companion guide states). But unfortunately, commercial payers don't do this in their 271s. So, I was hoping to find an indication of Medicare Advantage in the 271 response from the commercial payer.

Hi @bbrummel - David here from the Stedi team.

Yes, you can absolutely do this with our product Stedi Core, and either a Stedi function (or with our new HTTP Destinations product we are launching).

If you'd like to setup time with our engineers, we can show you how this works and provide sample code/config for you to set this up in just a few minutes. Our calendar is up to date here: https://www.stedi.com/book-demo

Stedi does not support creating an EDI Implementation guide from an uploaded X12 sample file, however it is on our roadmap to do this.

There is a fast way of doing this, though. Some steps I usually take if I am looking to build a Guide from a sample only:

Create a guide with the right version & txn set Go to EDI Inspector tab, drop in the file Look at the first error, and fix it in the guide builder (edit tab) Fix and repeat until the guide parses the file and returns "valid"

For a simple EDI file, this process takes only 15-20 minutes. More complex ones could take up to an hour. Don't forget to add your qualifier codes for the allowed values!

Also, Stedi will build guides for customers - for free - and add them to the catalog. If you want to request a guide to be built for you, feel free to drop us a note: https://www.stedi.com/products/guides/accelerator

@joe-cerulli There is no max repeat on the x298 in the 2000A loop.

https://www.stedi.com/app/guides/view/hipaa/health-care-claim-professional-x222a2/01GRYB6EJ999Y6MZ53ZBAHYBHE#properties.detail.properties.billing_provider_hierarchical_level_HL_loop

@tbieber Yes. TDS-01 can have a value 0. But you cannot have an empty TDS-01 element.

@ross - this was super helpful. One thing I noticed that you need to do as well is mark the first variant to not be repeated, as otherwise the parser will make only pick up the first key and have multiple objects inside of it.

@divyesh-bhagat-prtnr of course, happy to help!

I did notice that the 943 has a similar segment you can use, but the 940 transaction set definition made it seem like a more appropriate document to use.

Separately, if you want to generate EDI documentation and share that with your partner, Stedi Guides might be a good fit. If interested, we can always hop on a call and help you build your 940/943.

https://www.stedi.com/products/guides

thank you for the additional context, @thomasasmith!

@lamarr-henry ... just found the forum.. did you make any progress? LMK if you still need help

@eliot-slevin I see a variety of delimiters used in practice. > is popular, as is :, ^ and <. Many EDI platforms use : as the default.

The important rule to remember is that the delimiters cannot show up in your textual data. If you know that your text data uses mathematical symbols then > and < is probably not a good choice, and : or \ would be better. But, if you know your text data includes time values in the format HH:MM:SS you may want to avoid :.

Communicate with the business groups owning the data being sent. Clearly communicate the character restrictions and get company buy-in, and agree on substitution characters when a delimiter is found in textual data.

Finally, if you are receiving EDI, be very open to the delimiters you allow. The sending party will understand the data being sent and the restrictions, and they have likely done upfront work to ensure there are no conflicts.

Hi @kasia ,

LS/LE segments are used to help parsers (and humans) differentiate between segments which can appear in multiple places in a transaction set. Sometimes it is possible for the last segment of a loop to have the same segment ID as the segment after the loop ends.

For example, in the 846 in the 004010 release, https://www.stedi.com/edi/x12-004010/846, the detail area 450 sequence is an N1 segment. In the loop prior to the 450 there is an N1 segment at the 410 sequence. If you received EDI with an N1 it may not be clear whether it is the N1 at the 410 or the 450 sequence.

But, if the previous loop (380 sequence in this case) is wrapped in LS and LE segments then we can differentiate the two N1 segments, as there will always be an LE segment between the 410 and 450 N1 segments.

@siddharth-sarda personally I tend to trust the usage notes whenever there's a discrepancy between guide PDF and usage notes.

Usage notes are explicitly provided by a trading partner and are (IMO) more likely to be accurate.

We should not sent an acknowledgement for an acknowledgement One of the two options could be picked
a) Create an 824 (text msg with rejection and request for corrected document)
b) If the exceptions get reviewed by someone (like a support team) someone may need to reach the source of bad acks (acks with invalid control numbers)

@lamarr-henry that is correct! I actually wrote a post on this, which you can view here, under "Element Requirements in X12 EDI"

@joost-agerbeek this is very helpful, thank you for the detailed reply!