How to make really expensive medical device software

The path to designing and developing ludicrously expensive medical device software is easier than you might think.

In fact, it’s so easy that many startups end up making super expensive medical devices.

Even established companies thinking they’ll shift a product into the medical space often make the same mistake as companies less than half their age.

In this post, we will share what we’ve learned about how to make a medical device that’ll make your VCs or board members’ eyes water.

And we’ll tell you how to stop making absurdly expensive medical device software.

Here are three ways to make expensive medical devices and how to stop doing that.

Not thinking about compliance from the start

The costliest way to create your device software is to not consider compliance early on. Different regulatory bodies and standards call for a variety of things for compliance. But without thinking about compliance from the start and seeing what’s needed, you’ll miss something that you’ll need to get approval later.

If you write a piece of software and want to use that in a medical context and you’re missing:

• Design reviews
• Code reviews
• Risk assessments

You’re looking at a total software rewrite because your software won’t get through approval. And these steps are extremely hard to reverse engineer—not to mention, that’s just not good practice.

How to fix this

If the damage has already been done, you’ll need to start over and follow the expectations set out in standards like IEC 62304 and IEC 62366.

But if no code has been written, all is not lost! Assess where your knowledge gaps are and either build the compliance-ready team you need in-house or outsource for the skills gaps you have. (For verification and validation (V&V), the FDA encourages you to have V&V assessed independently.)

Get your software development plan in order and clearly codify how you will do what you’re going to do. (Our IEC 62304 checklist has some great advice on doing this.)

Put in regular points for design and code reviews. In fact, planning for a software development cycle that allows for small iterations and frequent feedback loops is an excellent way to do this.

Not thinking clearly about the use case with a helping of feature creep

Constantly innovating is something that businesses are encouraged to do, especially startups.

But this can start to get expensive when working on medical devices. How? It happens when you’re adding in features without tracking back to actual user needs and relying on emerging requirements without properly recording them.

Again, if you do not effectively record those emerging requirements, you’re in trouble. You’re hitting rewrite territory without clear lines of traceability between them, design, features, code, and tests.

And even if you’re fully recording all this innovation, what if you’re adding features no one needs or solving issues that don’t need to be solved?

Then you’re just burdening yourself with even more documentation, time wasted on development and testing and the joy of features becoming potential security holes in the future. Oh, and building a product nobody wants to buy.

If you’re also adding hardware that isn’t compatible with a user’s surrounding systems—say it needs a serial port and users only have access to USB? That’s going to cost you in sales.

How to fix this?

Getting to grips with IEC 62366 and your human factors and user needs is a start.

From a software perspective, investing in good user experience (UX) research and testing from the outset. UX practices can help teams gain early insights into user needs and then help you refine features and prioritise them during software development.

If you’re following an evolutionary lifecycle for medical device software development, then UX fits in well.

An evolutionary lifecycle sees software developed iteratively, with short feedback loops between software versions to enable continuous improvement. The FDA put the notion forward in TIR45, which considers how to bring Agile to medical device software development.

UX practices that can help in discovery include:

• Research to understand the needs of stakeholders, subject matter experts, and users;
• The creation of personas;
• The creation of user journey maps.

UX practices which will bring value to the iterative design, develop, and test cycle include:

• Sketching;
• Prototyping;
• Usability testing.

And to meet the needs of IEC 62304, the above activity would still need to be documented. Plus, your software development plan would need to explain how UX activity will affect software development.

Leaving documentation to last

If regulatory bodies could insist on recording through an fMRI scan the instant that a device idea takes root in someone’s thoughts as part of the evidence to document traceability—they would. Luckily for you, they don’t.

But they do expect a clear traceable path from inception through to the finished software. A documented path of artefacts.

While leaving documentation to last isn’t the costliest mistake your team could make, it does introduce an element of risk to the project’s success. With memories not so fresh and time obscuring the links between choices made, the process will take longer and be more prone to error.

And if something ends up under scrutiny by an auditor and it’s incorrect? Well, that could put your device’s approval in jeopardy.

How to fix this

Medical device software documentation should start at project kick-off. The benefits are manifold:

• It creates less room for error;
• It makes it easier to onboard new team members;
• It gives you a head start on what can be a massive process for complex device projects.

Doing documentation from the start means doing little and often. Here are three top things that can make this a lot easier:

Have a software analyst on your team. They’ll help you keep track of requirements and ensure there are references to them in user stories and acceptance tests. Software analysts can be a final check for document version control and sign off. There is a lot they can help with.

Use living documentation. What is it? It’s documentation that evolves alongside your codebase. It helps reduce the time everyone spends on documentation, drawing on artefacts that teams create as part of their work. It works exceptionally well with teams using practices like Test-Driven Development (TDD) and Behaviour-Driven Development (BDD). And for the most part, living documentation is automated.

Keep your documentation easy to understand and navigate. Writing things succinctly and using plain language can ensure accessibility from a reading perspective. Meanwhile, linking documents so that references between them can be easily navigated saves everyone time.

There are more ways you can make an expensive medical device, but working with Bluefruit isn’t one of them

The list here isn’t exhaustive. There’s plenty more anyone could do to make it costly to develop medical device software or SaMD.

But as we are fond of pointing out, using Lean-Agile software development principles and practices can also help keep your long-term costs down. It does this while improving software quality, cutting waste, and giving you project management and technical practices that make it easier to iterate software and document everything.

You can read more about Lean-Agile for medical device software in the links below.

And if you want to work with a team that’s ready to help you get your project right from the start, let’s set up a call.