4 ms·

The two massive barriers to entry are regulatory uncertainty and sales difficulties Regulations: Up until recently, the regulatory landscape for medical softwa

The two massive barriers to entry are regulatory uncertainty and sales difficulties Regulations: Up until recently, the regulatory landscape for medical software was extremely confusing. People were sitting on the sidelines waiting for FDA to figure out how to deal with machine learning, agile development, app stores, blah blah. Startups that wanted to jump in were staring at yearly 100K+ regulatory consultant bills. FDA is now actively de-regulating the bulk of medical software, and will create a regulatory kit which should better explain the regulations in an actionable way (instead of "create a design history file" without much explanation of wtf that means in practice). This should ease pains on that front Sales: This is where the big pain is. Getting paid for shit in healthcare is just too damn hard unless your product is on the hospital operations side of things. Getting an FDA approval (assuming it's required) DOES NOT mean one of the thousands of insurers will decide to reimburse you for your product; many require multiple clinical trials for reimbursement purposes; and many will decide to stop covering your product for stupid reasons (ie some editorial in the "No One Reads This Journal of Nonsense" said it was unclear the product was effective). Good luck getting patients to pay for anything, as they expect all products to be covered by insurance. Good luck convincing doctors they should use your product, as they are already overwhelmed with data entry / shitty UIs and don't want to perform any additional clicks or workflow changes.

phren0logy 8y ago
Glad to hear things are improving on the regulations front. Sales is going to be hard for a while, but I think that there are some markets where this is less of an issue, as it's more cash-based anyway. It makes me sad, though, that a lot of the population-based preventative stuff for which AI would be a great fit is unlikely to be a financially appealing investment.
killjoywashere 8y ago
Sales: skip it. Cardinal, Leica, Stryker, and others already have sales workforces. Cut your deal with one of them instead.
criley2 8y ago
The FDA is not the primary source of regulation in medical software, it's CMS. And while CMS regulations do not apply theoretically to private insurance and private practice, Medicare and Medicaid represent such a large segment of the healthcare economy that private insurers tend to use similar expectations as CMS regs. Also, software which cannot meet CMS reg and cannot be used for Medicare/Medicaid patients is a non-starter for the majority of the healthcare industry. The idea that our medical software space would be mostly deregulated is a rather horrifying thing in and of itself. I don't want my father being cared for using beta, buggy, software. I have high expectations for quality and risk management from healthcare software that I do not have for some agile beta video game or social network. I think your "bulk deregulation" comment is rather wrong. If you are coding in this space and are not INTIMATELY familiar with the concept of PHI and HIPAA, then you will be writing software which violates core regulations in this space. Your concerns on the sales side also do not mention "RISK" even once. You don't speak even a little bit of our healthcare space. Those doctors want risk management. What happens if/when the software screws up? Whose fault is it that the software is literally response for killing patients? You also don't mention what doctors care about: does it meet CMS regs? Does it meet state regs? Will I be able to submit my obscure XYZ state form? Will I be able to submit to BCBS, Aetna, Medicare? Will they accept? Etc etc. You will be writing custom software for customers all over, because the regulations that states and even cities like NYC might impose could be imposed on a single customer of yours only. I think people who want to disrupt healthcare forget that healthcare IT is literally life or death. Your bug isn't just an annoyance, it could be the thing that ends someones life. Regulations aren't just a barrier to agile development, they're also a life saving tool to ensure that risk management and data privacy are established in all products that get used on patients in our country.
- Thriptic 8y ago
  > The FDA is not the primary source of regulation in medical software, it's CMS It's totally dependent on what you are doing. Sure, HIPAA / PHI concerns are the primary issues for people who generally make software for the medical space, but by "medical software" I mean software that FDA might classify as "software as a medical device" AKA FDA regulated software. If your software falls under this designation, as most diagnostic medical AI systems like Watson would, then your primary regulatory concern is the FDA and you are held to much more stringent software development requirements than someone that has to deal with some PHI concerns. In this context, my bulk de-regulation comment is 100% correct, as the FDA has basically dictated almost everything in the space to be unregulated (all back office products, general wellness products, enforcement discretion products, MDDS, even CDS which almost certainly should be regulated). They have literally gutted Class 1. You basically have to be writing something that is going to provide a diagnosis or treatment plan, control an existing medical device remotely, or mimic an existing regulated medical device in functionality in order to be regulated now. Reasonable people weren't scared to enter the space because they might have to deal with PHI for HIPAA concerns, as it is well known how to do that at this stage; they were scared to enter because there was (and continues to be) some uncertainty as to how novel product classes will be regulated by FDA. > Your concerns on the sales side also do not mention "RISK" even once. You don't speak even a little bit of our healthcare space. Those doctors want risk management. What happens if/when the software screws up? Whose fault is it that the software is literally response for killing patients? All FDA regulated software is mandated to have robust risk management planning prior to approval (ie ISO 14971 compliance). Other than that, the vast majority of products that a patient will be interfacing with can't do them real harm if they are buggy. That is precisely why the FDA has chosen not to regulate them. > You also don't mention what doctors care about: does it meet CMS regs? Does it meet state regs? Will I be able to submit my obscure XYZ state form? Will I be able to submit to BCBS, Aetna, Medicare? Will they accept? Etc etc. You will be writing custom software for customers all over, because the regulations that states and even cities like NYC might impose could be imposed on a single customer of yours only. I don't mention doctor wants because doctors aren't the buyers most of the time. Payers are the buyers, hospitals are the buyers, or patients are the buyers. How many pieces of software that you know of are sold directly to the doctor?

phren0logy 8y ago

Glad to hear things are improving on the regulations front. Sales is going to be hard for a while, but I think that there are some markets where this is less of an issue, as it's more cash-based anyway. It makes me sad, though, that a lot of the population-based preventative stuff for which AI would be a great fit is unlikely to be a financially appealing investment.

killjoywashere 8y ago

Sales: skip it. Cardinal, Leica, Stryker, and others already have sales workforces. Cut your deal with one of them instead.

criley2 8y ago

The FDA is not the primary source of regulation in medical software, it's CMS. And while CMS regulations do not apply theoretically to private insurance and private practice, Medicare and Medicaid represent such a large segment of the healthcare economy that private insurers tend to use similar expectations as CMS regs. Also, software which cannot meet CMS reg and cannot be used for Medicare/Medicaid patients is a non-starter for the majority of the healthcare industry. The idea that our medical software space would be mostly deregulated is a rather horrifying thing in and of itself. I don't want my father being cared for using beta, buggy, software. I have high expectations for quality and risk management from healthcare software that I do not have for some agile beta video game or social network. I think your "bulk deregulation" comment is rather wrong. If you are coding in this space and are not INTIMATELY familiar with the concept of PHI and HIPAA, then you will be writing software which violates core regulations in this space. Your concerns on the sales side also do not mention "RISK" even once. You don't speak even a little bit of our healthcare space. Those doctors want risk management. What happens if/when the software screws up? Whose fault is it that the software is literally response for killing patients? You also don't mention what doctors care about: does it meet CMS regs? Does it meet state regs? Will I be able to submit my obscure XYZ state form? Will I be able to submit to BCBS, Aetna, Medicare? Will they accept? Etc etc. You will be writing custom software for customers all over, because the regulations that states and even cities like NYC might impose could be imposed on a single customer of yours only. I think people who want to disrupt healthcare forget that healthcare IT is literally life or death. Your bug isn't just an annoyance, it could be the thing that ends someones life. Regulations aren't just a barrier to agile development, they're also a life saving tool to ensure that risk management and data privacy are established in all products that get used on patients in our country.

Thriptic 8y ago
> The FDA is not the primary source of regulation in medical software, it's CMS It's totally dependent on what you are doing. Sure, HIPAA / PHI concerns are the primary issues for people who generally make software for the medical space, but by "medical software" I mean software that FDA might classify as "software as a medical device" AKA FDA regulated software. If your software falls under this designation, as most diagnostic medical AI systems like Watson would, then your primary regulatory concern is the FDA and you are held to much more stringent software development requirements than someone that has to deal with some PHI concerns. In this context, my bulk de-regulation comment is 100% correct, as the FDA has basically dictated almost everything in the space to be unregulated (all back office products, general wellness products, enforcement discretion products, MDDS, even CDS which almost certainly should be regulated). They have literally gutted Class 1. You basically have to be writing something that is going to provide a diagnosis or treatment plan, control an existing medical device remotely, or mimic an existing regulated medical device in functionality in order to be regulated now. Reasonable people weren't scared to enter the space because they might have to deal with PHI for HIPAA concerns, as it is well known how to do that at this stage; they were scared to enter because there was (and continues to be) some uncertainty as to how novel product classes will be regulated by FDA. > Your concerns on the sales side also do not mention "RISK" even once. You don't speak even a little bit of our healthcare space. Those doctors want risk management. What happens if/when the software screws up? Whose fault is it that the software is literally response for killing patients? All FDA regulated software is mandated to have robust risk management planning prior to approval (ie ISO 14971 compliance). Other than that, the vast majority of products that a patient will be interfacing with can't do them real harm if they are buggy. That is precisely why the FDA has chosen not to regulate them. > You also don't mention what doctors care about: does it meet CMS regs? Does it meet state regs? Will I be able to submit my obscure XYZ state form? Will I be able to submit to BCBS, Aetna, Medicare? Will they accept? Etc etc. You will be writing custom software for customers all over, because the regulations that states and even cities like NYC might impose could be imposed on a single customer of yours only. I don't mention doctor wants because doctors aren't the buyers most of the time. Payers are the buyers, hospitals are the buyers, or patients are the buyers. How many pieces of software that you know of are sold directly to the doctor?