Let’s assume your software has various different components – and you have no clue how to separate medical device software components from other, non-medical components? The larger topic of this is the medical device scope, and I’m not exaggerating: not a week goes by in which I’m not asked how to define a medical device scope. From different angles, this can sometimes take a different form and tone:
- How to differentiate medical device from non-medical device components?
- Is it an advantage to exclude less “risky” components from the medical device scope?
- How should I set up the documentation for my API-only device (= without a user frontend)?
- My medical device is a platform-as-a-service product. How to set up my documentation so that it can “scale” and include many more devices?
As you can see, all of those questions sound different and they address different devices, but they all have one thing in common: our customers want to define the scope of their medical device documentation in the right way from day one, so that it accurately captures the specific situation of their product. Likely, I won’t be able to address all the many implications involved in each question. But I will try to address the basic pros and cons of scoping your product.
Let’s start, as always, with a short round of definitions. What I mean by software components is what the FDA refers to as modules (“a discrete unit or architectural item within the system or software”, see FDA Guidance on Premarket Submission for Device Software Functions, part E). The IEC 62304 also refers to this as software components or software systems (“Integrated collection of software items organized to accomplish a specific function or a set of functions”, see section 3.27). Some simple examples: what I mean is your frontend vs. backend, your client order administration system vs. your image processing system or your algorithm model – all being part of the same medical device software.
Medical Device vs. Non-Medical Device Software Components
First things first: how to differentiate medical device from non-medical device components? Well, by their medical purpose. One system might be responsible for managing customer orders for shoe inlays, based on another system’s output regarding a walking analysis. The first system is not a medical device. But the second is, because it analyzes walking patterns for the purpose of diagnosis and treatment.
Don’t make things more complicated than needed: of course, you can integrate both systems (medical and non-medical) into one software package. Just keep in mind that users should be able to recognize once the interact with a medical device software component. Picture archiving and communication systems (PACS) are typically not certified medical device software. Nowadays, they might provide seemless integrations with fancy new AI algorithms to analyze their image data. But the shiny CE mark should jump into the eyes of anyone interacting with those algorithms. And their output, such as medical reports, should contain medical device labelling information.
Benefits (or: Pitfalls) of Excluding Components
Of course, the general rule is: the smaller the scope of your medical device, the less energy you need to spend on documentation efforts. Every aspect within the scope of your medical device software should be mentioned in your software specifications, tested in your software and usability tests, any changes should be kept under version control, and so on.
But: there’s no need to go above and beyond to exclude certain parts. Don’t get creative arguing that your frontend doesn’t serve a medical purpose – and that only the image processing algorithm does -, if a frontend is clearly needed to fulfil the intended use of your product. In my experience, all this creativity will lead to more complexity and more headache: are you really able to fully describe every software feature without this component? Is your bug analysis, your risk management, your deployment process complete without involving the naughty component in question – or will you have to get creative again?
Instead, follow common sense and include every component in your medical device scope which is needed to meet your device’s intended use. And should you ever decide to exclude something for the purpose of “lean” documentation: make sure to really keep it out of all your documentation then, or otherwise risk triggering suspicious auditor questions.
Also, unfortunate medical device scoping might slow your startup down, but it’s no catastrophe. Keep in mind that your documentation is never set in stone – you can still change things again. For example, it’s totally ok to first start with a combination of product plus (self-developed) frontend, and later switch to an integration with other third-party user interfaces. Of course, that’s likely a major update to your MDSW and you will have to update about every aspect of your documentation (like conducting new software and user tests, ough!). But it’s not the end of the world. I’ve talked to startups that didn’t know precisely what other systems they wanted to integrate into, and neither would their product support such integration yet. Still, they wanted to bend over backwards to formulate a broad intended use statement and to keep all their options open. Maybe spend that energy on product development first!
No User Interface – No Usability Requirements?
In the recent past, I’ve worked with a growing number of “API-only” products, meaning software which does not provide its own frontend, but instead plugs into third-party systems, using their user interfaces. While the concept of such products is far from rocket science for software people, it seems like the regulatory world and guidances haven’t really caught up with such developments.
Those manufacturers read the applicable requirements and scratch their heads: what about those “information to be supplied by the manufacturer”? Think of contact information for customer support, labelling information such as the Unique Device Identifier or residual risks that need to be communicated to users. Check EU Regulation 2021/2226 and requirements for a user manual or so-called “instructions for use”. And finally: how to conduct usability testing (so-called “summative usability evaluation“) according to IEC 62366-1 if you have no control over how data is displayed to users?
Me too, I was at first incredibly confused over how to tackle those requirements. When talking to usability experts, I asked if the IEC 62366-1 standard for usability was applicable at all for such medical devices. Spoiler: I would say, it usually is. Ask yourself the question: does your product influence in any way how information is displayed to the user? Even the calculated device output “only” entails measurements, image segmentations or DICOM labels, you still need to make sure that it is intuitive for users to understand what it means.
Let’s correct a common misunderstanding next: you do have (certain) control over the display of data, even if you don’t provide a user interface. As the manufacturer of your API-only device, you need to specify what kind of environment it should be used in. You can specify the frontend(s), or the specific manufacturer(s) thereof, which your device is compatible with. That kind of information should be part of the user manual or the software specifications – which also need to be verified and validated. Meaning: you should document software tests which verify the compatibility, and user tests which validate that users understand the way in which your device output is presented in the third-party user interface.
Platform as Medical Device Software
Let’s say you intend to provide a software platform with many different devices. What’s the best way to set up your documentation: should you write one technical documentation, with a very broad intended use, encapsulating all the different medical device software components – or rather compile a set of separate technical documentations for each of the devices on the platform? The answer to this last one may not be satisfying at all: I don’t really know.
I guess you could make good arguments for both approaches: one technical file for the entire platform might be easier to do than writing and maintaining five different files (each containing at minimum 30-40 individual records!). But then, writing this one technical documentation might become brutally complex, accounting for all these different but similar devices on the platform. Also, consider that you will kind of “put all your eggs in one basket” with this one platform-as-a-medical-device: any incident or pending regulatory approval could simultaneously affect all the different use cases on your platform.
I might be missing out on a lot of relevant details here. Large corporate companies manage hundreds of medical devices – maybe there are smart solutions to this problem which I’m not aware of. (But then, these corporates hire armies of regulatory employees, so maybe there aren’t any smart solutions.) For startups, I believe this is a mostly hypothetical problem. So I would circle back to my earlier point: your documentation is never set in stone, and you can always change things again, even if it costs you time. My gut feeling: prioritize market entry and profitability of your first few medical devices before the platform setup becomes an urgent regulatory problem to solve.
