If you're looking for a truly disruptive startup, you should tackle insurance billing. This is a $1 Trillion+ industry powered by people making phone calls and sending paper mail.
Just look at this list of insurance payers: https://drchrono.com/public_payer_search/. See how they all have different enrollment forms? Every clinic that wants to do electronic billing with insurance has to fill out an enrollment form for every insurer on that list (though most only do a subset). Filling out those forms is powered by people.
For those of you that haven't dealt with insurance, a real-time eligibility checker is actually a huge deal. The best of class eligibility providers define "real-time" as "we'll respond within five minutes to your request, and only between the hours of 8am and 6pm Eastern, and often the service will be down for many of those hours, and requests will fail randomly, and we can handle a full 10 requests per minute." When clinics get eligibility information wrong they end up eating the cost of service or sending out a huge unexpected bill to the patient.
(Actually, it looks like DrChrono is using Emdeon, which has many of the problems described above.)
The (stealthy) biotech startup at which I work has to deal with a huge number of insurance companies. I've been working on insurance claim integration and had to build out a parser for the absurd file format standard the healthcare industry uses (https://github.com/sbuss/TigerShark). We're parsing and handling claim acceptance/denials pretty well (resulting in, literally, a 300x boost in productivity of our billing & support team).
This is absolutely true. The opportunity to disrupt insurance is massive, and at this point, almost a certainty.
Through Leaky, one of the things that we've always liked is that there's room for disruption in all parts of the spectrum. Customer acquisition, retention, quoting, pricing, binding, billing, etc ad nauseum. You can even decide if you want it to be B2C or B2B.
For us, we've focused on 1) simplifying the comparing and ultimately the purchasing of personal lines insurance (auto, home, life) and 2) creating a real-time (truly real-time; not the "we'll call you back in 5 minutes" model) commercial insurance comparison and purchasing platform.
There are a lot of headaches to disrupting insurance as an industry, namely there are a lot of regulations and a lot of litigious parties. However, our view is that mounting public frustration (for all forms of insurance) and the current lack of software-based solutions make insurance a ripe industry for disruption.
I've been working on our billing features and have worked with our X12 parser quite a bit. I died a little inside when I realized that I could scan X12 files almost as quickly as reading English. :P
I just finished building out a 271 interface for medicare and emdeon - the error rate is higher than I'd like, but isn't terrible. Response rates are typically under 20 seconds for us...
For claims, we're using http://x12parser.codeplex.com/. It's still pretty cumbersome, but I think that's more a symptom of the format itself.
Comments
If you're looking for a truly disruptive startup, you should tackle insurance billing. This is a $1 Trillion+ industry powered by people making phone calls and sending paper mail.
Just look at this list of insurance payers: https://drchrono.com/public_payer_search/. See how they all have different enrollment forms? Every clinic that wants to do electronic billing with insurance has to fill out an enrollment form for every insurer on that list (though most only do a subset). Filling out those forms is powered by people.
For those of you that haven't dealt with insurance, a real-time eligibility checker is actually a huge deal. The best of class eligibility providers define "real-time" as "we'll respond within five minutes to your request, and only between the hours of 8am and 6pm Eastern, and often the service will be down for many of those hours, and requests will fail randomly, and we can handle a full 10 requests per minute." When clinics get eligibility information wrong they end up eating the cost of service or sending out a huge unexpected bill to the patient.
(Actually, it looks like DrChrono is using Emdeon, which has many of the problems described above.)
The (stealthy) biotech startup at which I work has to deal with a huge number of insurance companies. I've been working on insurance claim integration and had to build out a parser for the absurd file format standard the healthcare industry uses (https://github.com/sbuss/TigerShark). We're parsing and handling claim acceptance/denials pretty well (resulting in, literally, a 300x boost in productivity of our billing & support team).
This is absolutely true. The opportunity to disrupt insurance is massive, and at this point, almost a certainty.
Through Leaky, one of the things that we've always liked is that there's room for disruption in all parts of the spectrum. Customer acquisition, retention, quoting, pricing, binding, billing, etc ad nauseum. You can even decide if you want it to be B2C or B2B.
For us, we've focused on 1) simplifying the comparing and ultimately the purchasing of personal lines insurance (auto, home, life) and 2) creating a real-time (truly real-time; not the "we'll call you back in 5 minutes" model) commercial insurance comparison and purchasing platform.
There are a lot of headaches to disrupting insurance as an industry, namely there are a lot of regulations and a lot of litigious parties. However, our view is that mounting public frustration (for all forms of insurance) and the current lack of software-based solutions make insurance a ripe industry for disruption.
I've been working on our billing features and have worked with our X12 parser quite a bit. I died a little inside when I realized that I could scan X12 files almost as quickly as reading English. :P
I just finished building out a 271 interface for medicare and emdeon - the error rate is higher than I'd like, but isn't terrible. Response rates are typically under 20 seconds for us...
For claims, we're using http://x12parser.codeplex.com/. It's still pretty cumbersome, but I think that's more a symptom of the format itself.