Some questions that immediately came to mind after reading through the docs:
1. Does the response contain more than just the 271 EB segments? The demographics segments are important, as are payer contact segments.
2. How do you deal with payers that require provider registration? Do you have a standard registration form that can be used to expedite the process. Do you, can you, register on behalf of the provider?
3. JSON is web service friendly and stuff, but your output sure is verbose. Is there any reason you choose to print entire descriptions of codes instead of just returning the code? (for example "Diagnostic Lab" instead of simply "5"). Personally I think sticking to the standard X12 codes would make the data easier for software to consume. In my honest opinion it's hard to beat X12 for EDI transactions given its well defined structure. Though it's very unfortunate that it's not "open".
4. Do you accept multiple service type codes on a single request?
5. Can you accept a Service Date in the request? Often times it is useful to retroactively check for coverage. A good example is Medicaid: providers often batch eligibility requests for their self-pay patients at the end of the calendar month to see if they now have coverage (new Medicaid coverage can be retroactive in some cases).
6. How reliable are your connections? Have you setup your own direct payer connections, or is mostly hopping through other EDI vendors (Emdeon, ENS, Meddata, etc)?
1. Does the response contain more than just the 271 EB segments? The demographics segments are important, as are payer contact segments.
2. How do you deal with payers that require provider registration? Do you have a standard registration form that can be used to expedite the process. Do you, can you, register on behalf of the provider?
3. JSON is web service friendly and stuff, but your output sure is verbose. Is there any reason you choose to print entire descriptions of codes instead of just returning the code? (for example "Diagnostic Lab" instead of simply "5"). Personally I think sticking to the standard X12 codes would make the data easier for software to consume. In my honest opinion it's hard to beat X12 for EDI transactions given its well defined structure. Though it's very unfortunate that it's not "open".
4. Do you accept multiple service type codes on a single request?
5. Can you accept a Service Date in the request? Often times it is useful to retroactively check for coverage. A good example is Medicaid: providers often batch eligibility requests for their self-pay patients at the end of the calendar month to see if they now have coverage (new Medicaid coverage can be retroactive in some cases).
6. How reliable are your connections? Have you setup your own direct payer connections, or is mostly hopping through other EDI vendors (Emdeon, ENS, Meddata, etc)?