Published: Aug 6, 2023 by Yu-Wen (Weny)

A common query from entrepreneurs establishing a software as a medical device company is, “When should we start to implement a QMS system, especially design control?” In response, it’s suggested to initiate this process when you’re prepared to construct your Minimum Viable Product (MVP) (p.7).

Several key indicators hint at the readiness for this step:

Completion of the “ideation/research section” and transition to the “design phase.”
Finalization of a “prototype/proof-of-concept” beta version product and readiness to construct your MVP.
Planning to market your device, such as when potential customers appear, or you decide to distribute your product.
Remember, this should occur before the first clinical use, unless you have an IRB-approved clinical trial. If the clinical trial falls under the Investigation Device Exemption (IDE)(21 CFR 812), you should - initiate your Design Control (and QMS, according to your target market(s)).

By the time you embark on design control implementation, you should have:

A clear high-level intended use and instructions for use:
- These provide your Software Safety Classification (IEC 62304) and the regulatory paths. It includes necessary specifications required by regulatory authorities and the type of validation—usability or clinical. This assists in estimating the timeline and resources for setting up your design control and QMS.
A defined vision for your MVP-level requirements, including:
- All software system inputs and outputs.
- All functions performed by the software system.
- Performance requirements to be met, such as data throughput, reliability, and timing.
- Definition of all external, user, and internal software-to-system interfaces.
- The interaction model between users and the system.
- Error identification and handling protocols.
- Required response times.
- The intended operating environment for the software, if it’s a design constraint (e.g., hardware platform, operating system).
- Safety and security-related requirements.
A thorough understanding of what software tools will be used in the design and development process. The design and development process in software is also considered as the “production” process. Therefore, your software tools should be validated before use(sec 6 & guidance).

For those whose target market(s) include the EU, Canada, and similar countries, you’ll need your QMS certificate while applying for your product’s regulatory authorization. Based on your resources and company size, establishing your QMS and technical files for your design-controlled product(s) typically takes between 6 to 18 months. This estimate doesn’t include potential administrative time from the notified body and regulatory authorities.

If your target market(s) is the US, you’re not obligated to have a full QMS before pre-market clearance for the US FDA. However, implementing an entire QMS is still advised so that you can put ISO 13485 and IEC 62304 as your consensus standards in your pre-market submission (which can benefit manufacturers). You’ll have to apply the complete design control regardless.

In conclusion, timely initiation of QMS and design control helps navigate regulatory paths and ensures software safety, thus paving the way for successful market entry.

Design_Control

Share

What is interoperability?

In medical devices, “interoperable medical devices refer to the ability to exchange and use information through an electronic interface with another medical/non-medical product, system, or device. Interoperable medical devices can be involved in simple unidirectional data transmission to another device or product or in more complex interactions, such as exerting command and control over one or more medical devices. Interoperable medical devices can also be part of a complex system containing multiple medical devices.” [The US FDA, Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Device, issued on September 6, 2017]. For example, a blood glucose meter that can send data to a smartphone app, an x-ray that can communicate with a picture archiving and communication system, or a ventilator that can adjust its settings based on the patient’s vital signs are all examples of interoperable medical devices.

When do you start to put your Software as Medical Device under design control?

To Convert An Existing Software Product to a SaMD

It has been more and more often that equipment and software companies providing their products to clinics and hospitals are, actively or passively, due to requests from the regulatory authorities, documenting/filing their products as medical devices. Such changes in the status of a product particularly often occur on software. This is [thankfully] due to the huge progress in the use of software in improving physical and mental health. Common scenarios that a company needs to consider converting an existing software product to a medical device or bringing a legacy software item into part of a Software as Medical Device (SaMD) include: