You don't have to change anything, but you now have to do tons of documentation. Other consultants typically have a very different opinion on this and will tell you that you have to change everything and focus on "quality management" blablabla, but those people typically have never written a line of code.
Long Answer
So, if you want to get into medical device software development and you already have experience developing software, that's awesome! Because that means you have way more software experience than the average regulatory consultant and even auditor. It's a weird industry, haha.. anyway!
Now the big question how large the difference is between what you're currently doing and what you need to do if want to bring a medical device to market successfully.
That difference mostly lies in documentation. Some examples of documentation activities which you have to do for medical device software development are:
Now the big question how large the difference is between what you're currently doing and what you need to do if want to bring a medical device to market successfully.
That difference mostly lies in documentation. Some examples of documentation activities which you have to do for medical device software development are:
Documentation Requirements For Medical Device Software Development
- Documenting User Needs (similar to user stories)
- Writing a "Design Input" specification
- Documenting your tests, and mapping them to Design Inputs
- Setting up a "Quality Management System" (QMS).
If you think all of this sounds easy and you can easily automate all of this, this is unfortunately not true. The problem, in simplified terms, is that a list of design inputs is not equal to a list of all your user stores which you're already documenting.
Your user stories typically look like this:
Your user stories typically look like this:
- Build login with Google
- Change login with Google so that user is automatically logged out after 20 minutes
- Fix login with Google
- etc.
You get the idea. Most user stories at most companies describe changes, and they assume that the reader already has a rough idea of how the software currently looks like. The problem is that, from a regulatory perspective, design inputs for medical device software development should look different, e.g. like this:
Design Inputs For Medical Device Documentation
- A user can log in with Facebook or Google.
- After 20 minutes, they are logged out.
So it's an absolute specification of what your software does at a certain point in time.
This will mostly mean you'll have to retrospectively document your software, because you almost certainly don't know the exact features and behaviour your software is going to have once it's done.
And that, in a nutshell, is why medical device software development adds a ton of overhead to your process.
For what it's worth, there are tons of free articles on our website to help you get started, and we even published all our templates for free! If you want to automate things even further, check out our eQMS software, Formwork.
This will mostly mean you'll have to retrospectively document your software, because you almost certainly don't know the exact features and behaviour your software is going to have once it's done.
And that, in a nutshell, is why medical device software development adds a ton of overhead to your process.
For what it's worth, there are tons of free articles on our website to help you get started, and we even published all our templates for free! If you want to automate things even further, check out our eQMS software, Formwork.
