41–50 of 95 posts
I wish the raw data was available (is it, somewhere?). I'd love to do some statistical analysis on this and get some real insight about how different insurance companies treat claims.
absolutely. I'll send you over as much raw X12, with removed patient info of course, as you want! Please email support@eligibleapi.com
I wish the raw data was available (is it, somewhere?). I'd love to do some statistical analysis on this and get some real insight about how different insurance companies treat claims.
absolutely. I'll send you over as much raw X12, with removed patient info of course, as you want! Please email support@eligibleapi.com
If the former, I wonder if some statistical analysis could be done in order to detect possible fraud, waste, and abuse. (I'm not a data geek or anything, but have I always wanted to learn.)
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)?
Also, it's simulating JSON [] lists as objects with fields named "Item #1", "Item #2", ... Seems an odd choice. e.g.
"Deductible": {
"Item #1": {
"Calendar Year": "1500"
},
"Item #2": {
"Remaining": "500"
}
},
"Deductible": [
{
"Calendar Year": "1500"
},
{
"Remaining": "500"
}
],Earlier quoted context omitted.
Thanks for your comment. We handle the connections to the insurance companies and the EDI to JSON transformation. I respect your point about 5 cents being high. We, of course, will evaluate that as time goes on. To start, you as a developer can make an app for the medical industry that checks patient's health insurance eligibility. Details you can call include: health spending accounts, deductibles remaining, coinsur…
> Thanks for your comment. Perhaps I am having a bad day, but is it really necessary to thank someone for their question? Seriously, this makes me feel like I am dumb for asking a question. I understand you trying to be extra polite, but I am sure you won't start a conversation with "thank you" every time your wife, son, daughter, lover or employee ask you a question. So while many will appreciate your "politeness th…
* Use REST.
* Use HTTP Basic auth instead of cluttering the URL query string with the API key.
* Use ISO 8601 for dates, no exceptions.
* Use lower_case or lowerCamelCased keys.
* Don't use spaces or other non-alphanumeric/underscore characters in keys, otherwise you can't easily index child objects with dot notation in many languages.
* Instead of liberally using dictionaries, use arrays with a type field. For example (I couldn't finish the example because the example JSON on your site is indented too poorly to comprehend):
active_coverage: [
{
title: "Item #1",
description: "Choice Fund HRA Open Access Plus",
free_text: "Member is in network based on NPI ID provided in request",
...
}
]
* Same goes for balance, make it a number (use cents to avoid floating points), and provide units like "USD".
The JSON example at https://eligibleapi.com/overview/how-it-works is incomplete and invalid. I'd be interested in seeing the entire JSON envelope to see how to actually get at the data and what other metadata is exposed.
This looks like a straight up EDI translation into JSON, and thus not natural at all. I'd try to abstract it out a bit more into what people might use it for, and build a truly consumable REST API.
Earlier quoted context omitted.
While I think this is awesome (I work in the healthcare space - on the infrastructure side (design, build and implement systems for new hospitals)) though I would LOVE to see the following, if this API allows: I as a user would like to tell you my insurance info and tell you what procedure I want and you tell me the best/cheapest location to get that done. Then - here is where the groupon model farking failed: (I hav…
Insurance covers teeth whitening? I thought elective/cosmetic procedures were not covered.
As it stands, the insurance market is inverted that it makes the insured compete for coverage.
I applaud the initiative, but I think the JSON needs to be friendlier. * Use REST. * Use HTTP Basic auth instead of cluttering the URL query string with the API key. * Use ISO 8601 for dates, no exceptions. * Use lower_case or lowerCamelCased keys. * Don't use spaces or other non-alphanumeric/underscore characters in keys, otherwise you can't easily index child objects with dot notation in many languages. * Instead o…
I love your feedback, we know this is still raw (early beta) but its great hearing constructive suggestions. Please email when you have a chance k@eligibleapi.com so that I can provide you with a full data set of JSON response.
Earlier quoted context omitted.
API's and services like this are Key in making it so that more people will be able to afford medical care. Solving the current cluster F * of paperwork and time involved in establishing eligibility is one of the lowest hanging fruits in cutting medical costs (....NOTE: As opposed to more complicated cost cutting concepts such as preventative care) A typical Doctors office of 2 or 3 practitioners may have 2 or 3 or mo…
So if I'm understanding correctly, the lowest hanging fruit to providing medical care to those in need is...paperwork? Sounds like we're working on a band-aide, not a solution. Again, progress is progress. I guess I wonder whether or not these efforts could be focused on the root. I'm probably sounding like a pretentious douche with all the answers...it's not intentional. On a very base level, I cant help but wonder…