SBS - The Best Value in QMS software

Software as medical device (SaMD) replicated for multiple clients through APIs

#1
Hello Elsmar friends,

I have been working with a start-up who is a SaMD developer. This start-up has developed AI/ML based software application, cloud based, for detecting few physiological parameters. While, this company has their own software mobile application delivering services to users, they are also providing their technology as Software as a Service (SaaS) for other companies by integrating their technology with other company's products. Technically, the core product remains same but there could only be a slight modification, as required for each API integration.

Example, if my company's SaMD is detecting a parameter X and other company's product is detecting parameters like Y, Z, they are using my company's application integrated with theirs (through APIs) for detecting Parameter X along with Y & Z.

In this scenario, my query is "how should we control this software replications through API integrations for multiple companies under a single QMS?"

1. Shall we consider each integration as a separate product with separate technical file, prepared for each product? or
2. Shall we create a single technical documentation covering the core product and control different instances under configuration management? and
3. How to strategize regulatory approach for such a product?

Appreciate your time & valuable responses.
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
Interesting topic. I think that the startup will have a product for which they need a complete technical file. I presume that since you're selling the back-end as a service, your client will not be involved in the regulatory filings for the companies using the back-end. The back-end AI will be effectively SOUP (more like COTS, really) for the clients using it. You may not need (or want!) to expose the complete design history to them; only the API and use guidelines. You'll also want to support them by providing known bugs lists, etc.
 
#3
Hello Yodon,

Thanks for your prompt and insightful response.

While it is understood from your view that services provided through API will be considered as OTS by the manufacturer who uses our APIs, and the regulatory scope for our start-up will be confined to obtaining regulatory approval for our own delivery of services to end user through software mobile application, furthermore, I would like to understand:

1. How do we manage our core product and the API services under one QMS?
2. How do we keep a track of bugs/complaints which arise from our API services? Shall we keep it independent to our core product or combine them with our core product's bugs/complaints?
3. While a full technical file is necessary for our core product, what kind of documentation shall be captured as part of QMS for API services (under Section 7 - Product Realization of ISO 13485)?
4. Shall I document my start-up's role as both, a manufacturer and a service provider, as required under 4.1.1 of ISO 13485:2016?
The organization shall document the role(s) undertaken by the organization under the applicable regulatory requirements.
Appreciate your thoughts and time.

Thank You.
 

yodon

Staff member
Super Moderator
#4
It is an interesting situation.

1. How do we manage our core product and the API services under one QMS?
Where do you see any conflicts? You have, effectively 2 products: one is a medical device in and of itself and the other is a service. (I realize this ties in closely with your question 4.)

2. How do we keep a track of bugs/complaints which arise from our API services? Shall we keep it independent to our core product or combine them with our core product's bugs/complaints?
Do you foresee the API services diverging from or staying in sync with the core product? If diverging then absolutely keep separate (but recognize that those may well be inputs to your core product and vice versa).

3. While a full technical file is necessary for our core product, what kind of documentation shall be captured as part of QMS for API services (under Section 7 - Product Realization of ISO 13485)?
That's mostly going to rely on what your customers' requirements are. I would think they would mostly need something of an interface specification and release documentation (see IEC 62304 for good content). You can also look at 62304 to see what is expected by your customers for managing SOUP. That might help you frame out some documentation. You'll want to make available the list of known issues and keep it up to date. Of course, cybersecurity and data protection is a big concern so you'll probably want some documentation available on that (FDA has some guidance on that and other countries are starting to add their own guidance docs).

4. Shall I document my start-up's role as both, a manufacturer and a service provider, as required under 4.1.1 of ISO 13485:2016?
That's probably best taken up with your AO. I would think that would be the best approach, though.
 
#6
Hello Elsmar friends,

I have been working with a start-up who is a SaMD developer. This start-up has developed AI/ML based software application, cloud based, for detecting few physiological parameters. While, this company has their own software mobile application delivering services to users, they are also providing their technology as Software as a Service (SaaS) for other companies by integrating their technology with other company's products. Technically, the core product remains same but there could only be a slight modification, as required for each API integration.

Example, if my company's SaMD is detecting a parameter X and other company's product is detecting parameters like Y, Z, they are using my company's application integrated with theirs (through APIs) for detecting Parameter X along with Y & Z.

In this scenario, my query is "how should we control this software replications through API integrations for multiple companies under a single QMS?"

1. Shall we consider each integration as a separate product with separate technical file, prepared for each product? or
2. Shall we create a single technical documentation covering the core product and control different instances under configuration management? and
3. How to strategize regulatory approach for such a product?

Appreciate your time & valuable responses.
Well this is pretty common use case for most of the cloud services. You would have your Product Validated against your company Intended User cases. So lot depends on your customers whether using AS IS or customer specific configuration. Also the risk management procedure and risk associated to your company will differ from customer to customer. So in a Nutshell, every customer will have to risk assess and validate against their own company process and provide evidence that product is meeting the Intended use.
 
Thread starter Similar threads Forum Replies Date
V Medical Device Literature Translation Software ISO 13485:2016 - Medical Device Quality Management Systems 1
Q Software as a medical device vs software not sold as medical device: local regulations for sale? EU Medical Device Regulations 4
T IVDR Medical device software CE Marking (Conformité Européene) / CB Scheme 8
N ISO 13485 7.3.9 Change control in medical device software ISO 13485:2016 - Medical Device Quality Management Systems 6
R Medical Device Software Certification IEC 62304 - Medical Device Software Life Cycle Processes 1
Q Storing and developing SAMD (Software as a Medical Device) in the Cloud IEC 62304 - Medical Device Software Life Cycle Processes 3
MDD_QNA Medical Device Software - Is a Help Button required? IEC 62304 - Medical Device Software Life Cycle Processes 1
F Software as a Medical Device (SaMD) Technical File Requirements Manufacturing and Related Processes 3
A Software as Medical Device (SaMD) definition and its applicability Other Medical Device and Orthopedic Related Topics 4
T First 510(k) submission - Class II software as medical device US Food and Drug Administration (FDA) 4
Z Software Library - could it be a medical device? ISO 13485:2016 - Medical Device Quality Management Systems 5
M Informational TGA – Submissions received: Regulation of software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 1
D Requirements for the dimensions / color of medical device labels - Software as a Medical Device IEC 62304 - Medical Device Software Life Cycle Processes 2
D Software as an accessory to a Class I medical device EU Medical Device Regulations 4
R Medical device software without user interface Other Medical Device and Orthopedic Related Topics 3
R Validation of Medical Device Hardware containing Software - How many to Validate ISO 13485:2016 - Medical Device Quality Management Systems 1
Ed Panek Rule 11 Question - CE approvals for software as well as the medical device EU Medical Device Regulations 7
D IEC 60601 for a Software only Medical Device? IEC 60601 - Medical Electrical Equipment Safety Standards Series 5
S Software Release Note - Class A stand alone software medical device IEC 62304 - Medical Device Software Life Cycle Processes 2
M Professional Use Medical Software French Labeling for Canada -- Not Considered Medical Device Canada Medical Device Regulations 2
S Medical Device Software Distribution for a CE-marked medical device via a USB memory stick EU Medical Device Regulations 8
M Informational TGA – Webinar: An update on the consultation for the Regulation of Software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 0
J Qualification of a Software as a Medical Device (SaMD) guidance under MDR EU Medical Device Regulations 9
P Software requirement and design specifications - Medical device contains both hardware and software IEC 62304 - Medical Device Software Life Cycle Processes 2
M Informational TGA Consultation: Regulation of software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 0
N Medical Device Accessory Classification - Software as a Medical Device Other Medical Device Regulations World-Wide 5
R SaMD - Software as a Medical Device - Software change control form ISO 13485:2016 - Medical Device Quality Management Systems 3
G EU MDR 2017/745 Rule 11 interpretation - Re-classification of a Software as Medical Device Other Medical Device Related Standards 0
M Medical Device News TGA – Regulation of Software as a Medical Device Medical Device and FDA Regulations and Standards News 0
S Two Questions about Medical Device Software 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
K Medical Device Software Update in Field of AIMD IEC 62304 - Medical Device Software Life Cycle Processes 1
M Medical Device News Health Canada - Scientific Advisory Panel on Software as a Medical Device (SAP-SaMD) - Record of Proceedings – January 26, 2018 Canada Medical Device Regulations 0
R Online / Cloud Based Software as Medical Device EU Medical Device Regulations 8
S DMR (Device Master Record) for Medical Device Software IEC 62304 - Medical Device Software Life Cycle Processes 3
S Labelling in Medical Device Software IEC 62304 - Medical Device Software Life Cycle Processes 8
S What is considered the complete software medical device? Medical Information Technology, Medical Software and Health Informatics 6
JoCam Medical Device Software - Apps which can control medical devices EU Medical Device Regulations 13
L Software Medical Device - 7.3.8 - Design and Development Transfer ISO 13485:2016 - Medical Device Quality Management Systems 4
A SOP for software validation of software in medical device IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 5
K Registering a Software medical device (SaMD) in China China Medical Device Regulations 5
N Medical Device Software - Switch from Waterfall to Agile methodology Medical Information Technology, Medical Software and Health Informatics 4
V Software medical device labelling EU Medical Device Regulations 8
I Medical Device Software Risk Analysis ISO 14971 - Medical Device Risk Management 4
S If a piece of software receives approval as part of a medical device system Canada Medical Device Regulations 5
C Controlling Software Versions that are part of a medical device IEC 62304 - Medical Device Software Life Cycle Processes 2
S Cloud-Based Stand Alone Software - Software Medical Device (Class II) US Food and Drug Administration (FDA) 2
Q QMS Software for Startup Medical Device Company Other Medical Device and Orthopedic Related Topics 7
B CQC oversight of Medical device software? EU Medical Device Regulations 3
H Identifying Guidance on Medical Device Software Level of Concern for the EU EU Medical Device Regulations 2
B Is IEC TR 80002-1:2009 applicable to stand-alone medical device software? ISO 14971 - Medical Device Risk Management 1

Similar threads

Top Bottom