Software as a Medical Device - SaMD

#1
Hello All,

Sorry if this already exists, but I would like to know what each of the below comprise of when we talk Software as a medical device.

1. Concept of Software development project and its considerations
2. Verification strategy for the implementation
3. How would we measure projects success

In my initial research, I found out that the development process would depend upon the Software safety class and it should contain but not limited to the following
a. Creation of SW development plan
b. Specification of SW requirements
c. Development of SW architecture and a detail design
d. Implementation of the code
e. Verification of code
f. release of SW

However, how to identify what's the best process model (waterfall / V / Agile) to follow?
If the any of the above process model is chosen, how to strategize the verification ?
How to measure the project success?- Does this mean the validation of the end software against the user specification for the intended purpose?

Could someone please clarify the same? Clarification with an example would be highly appreciated.

Thanks in advance.
 
Elsmar Forum Sponsor

Tidge

Trusted Information Resource
#3
The standard for medical device software development (including SaMD) is IEC 62304. I am personally reluctant to approach the topic "generally" for two reasons:
  1. If you are invested in this field, you will invest in the standard.
  2. Providing general and specific advice on this topic is a business of its own.
I am more than willing to discuss subtle points, or areas where I think there is room for collaborative discussion, such as:

However, how to identify what's the best process model (waterfall / V / Agile) to follow?
If the any of the above process model is chosen, how to strategize the verification ?
Back-to-front: All requirements shall be verified for medical software. There is no other priority. The verification of (well-derived) requirements is what makes medical software safe.

In my experience: The most straightforward development SaMD method is a "waterfall" (requirements -> architecture -> implementation -> verification). I believe this to be true independent of consideration of Safety Classification (and/or Level of Concern). I have no allergy to "agile" development methods, but in order to satisfy the requirements of 62304 (for class B or C software) my experience has been that the discipline required to both generate the necessary deliverables (for notified bodies, regulators) in methods (commonly described as 'agile') is seen as more burdensome than simply adhering to the waterfall model.

I use the word 'discipline' in a very holistic sense. The discipline necessary for successful use of agile methods has to come from somewhere, and it has to be adhered to or the project will suffer chaos. The source of the discipline can be a project plan, it could be the architecture, it could be the project manager, it could be a development partner/peer.
 

yodon

Leader
Super Moderator
#4
First off, let me note that you have a sizeable gap: risk management (ISO 14971). That's going to drive / influence many of the things listed.

@Tidge makes some excellent points. Devices (including SaMD) are cleared based on your demonstration that they meed the medical claims that you establish. You can't get clearance for or legally distribute something that's partially implemented. So in that sense, agile concepts make SaMD development challenging. You can still take agile approaches during development (and, IMO, sprints are great in showing integration) but you need to have the target in mind, which includes all the required documentation (and from experience, doing documentation all at the end is extremely painful - build it up as you go).

Agile methods do line up pretty well with compliance to the Usability Engineering standard (IEC 62304), especially for the UI, so if you go that route, leverage those activities for compliance.
 

alex45

Registered
#5
The International Medical Device Regulators Forum (IMDRF) defines software as "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." The use of software as a medical device is growing. A medical device is defined in Article 2 of the new regulation as "any instrument, apparatus, appliance, or software intended by the manufacturer to be used alone or in combination for humans for medical purposes, including: diagnosis, prevention, monitoring for clinical software, prediction, prognosis, or treatment or alleviation of disease."
 

Junn1992

Quite Involved in Discussions
#6
Regulatory should always use waterfall as mentioned for the reasons above. A well documented process saves you time and money. Have fun trying to launch a product when the regulators ask for 'more documentation in X area of testing'.
 

yodon

Leader
Super Moderator
#7
Regulatory should always use waterfall...
Not sure I understand this comment. Regulatory just prepares the submission materials (provided by the software team). The "waterfall" process is a software design approach. "Normal" agile methods promote functionality over documentation but in the end, the documentation has to be there. I *support* agile methods (iterative) but suggest that documentation also has to be built up along the way. I do NOT support a true waterfall approach as it is quite inefficient.

And a waterfall method really doesn't have anything to do with test coverage. You can poorly test using a waterfall approach as you can with an agile approach.
 

Junn1992

Quite Involved in Discussions
#8
I see, thanks for the useful information! Could you elaborate more upon the different roles regulatory and quality play in a big organization? At a small company such as mine everything seems to be jumbled in together X.X
 
Thread starter Similar threads Forum Replies Date
M Software as Medical Device import activities for Chile and Mexico Other Medical Device Regulations World-Wide 0
T Classification Accessory Software medical device EU Medical Device Regulations 4
G Software Medical Device Classification EU Medical Device Regulations 7
B Software as a Medical Device - Language Requirements EU Medical Device Regulations 6
B Software as a NON-medical device Medical Information Technology, Medical Software and Health Informatics 23
A Medical Device Software POC Medical Device and FDA Regulations and Standards News 6
D One Software as Medical Device product or two? EU Medical Device Regulations 4
dgrainger Informational MHRA's Software and AI as a Medical Device Change Programme UK Medical Device Regulations 0
B A.I. diagnostic software is considered as medical device in FDA? US Food and Drug Administration (FDA) 6
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
V Software as medical device (SaMD) replicated for multiple clients through APIs IEC 62304 - Medical Device Software Life Cycle Processes 5
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 6
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) 3
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 5
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 8
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

Similar threads

Top Bottom