[criley2]

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]

> 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?

[sergers]

My company software is considered a Class 2 medical device.

We have to go through so many crippling hurdles with FDA it's almost not worth it.

You are spot on.

To add though, In atleast the diagnostic imaging space, radiologist reading groups/practices are selecting their own systems more and more nowadays.

Individual doctors? Likely not.

[616c]

So why do you need FDA regulation in your situation? I know people handling security regulation in the defense industry and I'm curious how you know the FDA has to approve you as opposes to CMS and what it entails.

[sergers]

For diagnostic imaging (x-rays, CTs etc) which we make software for, alot of equipment is FDA regulated.

We chose to go for class 2 designation in FDA terms as it shows you comply with uptmost regulations, which is a selling point. Some hospitals depending on state gets rebates for meeting compliance.

It depends on what space you are going into. If it touches a patient, more than likely FDA regulated in the USA.

Other countries have similar orgs ( Canada has... Health Canada).

We also work with DoD/VA... Don't get me started on compliance with them.(the security stuff is a plus though, while initially challenging to meet, it has us pushing the code into commercial space products, everyone benefits from the extra security hardening. )

[Thriptic]

What it entails depends on the product. FDA has 2 regulatory classes which require a premarket notification, class 2 and class 3. Class 2 submissions generally require you to comply with a set of software development standards governing testing and validation, requirements generation at multiple levels, interface design, risk management, traceability, design, and actual development. You are required to handle customer complaints, safety problems, and maintenance in specific ways. You are required to produce customer facing documentation in specific ways, have installation plans, etc. Finally, you need to register yearly with the FDA and have all sorts of training and infrastructure planning. Proof of all of this is to be constantly generated (think every test report) and it all gets put into a massive file for FDA review. There are also some writeups you need to do explaining why you are class 2 as opposed to class 3. This generally involves finding a class 2 piece of software which resembles yours and saying your software is basically doing the same thing. This is typically referred to as a 510(k) submission.

There is also a pathway you can apply for if there is no existing device with a class 2 designation which resembles yours, but you believe your device is still fairly low risk. That is called a de Novo submission.

A class 3 submission generally involves even stricter requirements for development plus a clinical trial to prove efficacy and safety. The most common one if these is called a PMA which stands for premarket approval.

Also, if you are FDA regulated you still have to comply with CMS regs. It is an extra layer of regulatory scrutiny.