Software is increasingly becoming a part of or the entirety of medical devices these days. Each company is evaluating the need for an app to keep track of data flows, provide feedback to the doctors, patients, or hospitals, or to better connect devices to actionable answers. In this world, software such as AI/ML, UI based interfaces fall in a regulatory gray area, whether you recognize it or not. Where do we draw a line where a medical device ends and an app or UI starts? Do you even know the distinction?
Well you’re in luck - let's get right into it. A medical device is still defined by being intended to diagnose or treat patients, even when it’s intangible like with software. Software as a medical device (SaMD) is often used as a tool that overtakes some of the decision making and generates risks that can directly affect end user or patient’s well being or diagnosis. We typically write a hazard analysis document to determine risks associated with these features, and the final goal is to create indications for use that the FDA can approve so the company can sell products and generate revenue.
As we mentioned before, most if not all companies that create software as a medical device want to display the data they generated in a user interface (UI), or app, or both. However, a core requirement of a medical device quality system is the need to verify and validate functionalities to ensure that the system works correctly every time, and mitigates risks as reasonably as possible. Therefore, we need an architecture map to determine what software functions are responsible for making medical decisions, and what is for aesthetic or visual needs. This would be important for any hardware or software medical device, as resources such as CAD modeling tools would also be in this category. Software outside of the device can be anything from database software to a modeling program, or UI software that does not contribute to the medical decision making directly. These can be validated with a stringency lower in risk than the main calculating systems that require the 21 CFR 820 or similar compliance levels.
In summary, drawing out what makes the system run is always a good idea, the links you create between individual pieces will also help you determine risk; of failure, hacking, patient data issues, etc. that you can more easily identify and resolve.