SBS - The best value in QMS software

Iterative development and FDA change requests

#1
Hello,
this is my first message and, first of all, I would like to congratulate with the users and administrators who spend their time answering questions. I find this forum very useful especially for the ones, like me, who are entering the field of medical devices.

I am trying to map FDA 21 CFR 820.30 requirements with an incremental and iterative life cycle (before doing the same with IEC 62304). I found some food for thought in several threads but there is a couple of simple questions that I cannot answer yet.

1) Do Design Inputs need to be approved before Design Output are produced? If yes, is there any place where such a constraint is clearly stated?
2) If the answer is yes, and we adopt an iterative and incremental software development life cycle, then does it imply that, from the second iteration onward, every single activity must be carried out in terms of design change?
For example, let's consider two iterations for a generic project. During the first iteration we specify a requirement R1, the overall architecture, a component C1 and its corresponding code. Assuming that the answer is yes, then before working on the architecture we need to approve R1, which becomes the Design Input, and the other elements are collected as Design Outputs (please, correct me if I am wrong).
Now, during the second iteration we want to add a new requirement R2 and develop the corresponding software unit C2 (with its code). Does it mean that such an improvement, as well as any further improvement of subsequent iterations, must be carried out within a change request as we need to update the Design Inputs and Outputs generated in the first iteration?

Thanks a lot.
 
Elsmar Forum Sponsor

Gisly

Starting to get Involved
#2
Hi!

I would recommend you to have a look at this recent panel discussion on the topic:
and that you invest in the TIR:45 which I find explaining this nicely. My experience, from a non-perfect development procedure though, has been that baselining the documentation periodically has been an intuitive way to work with the team to approach this question. By this Change Requests are embedded into the development process. If developing a new product, the documentation can be levelled up incrementally with each baseline/increment.

Taken from the TIR:

-It would be prudent to baseline the software configuration at each major milestone or at the end of each major phase, certainly at each INCREMENT. Include the configuration of SOUP items as part of the software configuration baselines.
-Treat change requests and new BACKLOG items similarly, using the same development processes for both.
 
#4
Hello Gisly,
thanks again, I have read the TIR45 and watched the video you shared.
I have still a couple of questions, that I hope you (or somebody else) may answer:
  1. In TIR45, given that Design Input and Design Output activities constitute the "frame" of stories, and provided that during one sprint usually one or more stories are implemented, can I conclude that at the end of every sprint there is an approval for some Design Inputs and Design Outputs?
  2. It seems it is not explicitly declared in the document, but given that change requests are managed through the traditional backlog, does it mean that certain sprints are in fact "designed" to approve, implement and review changes to existing Design Input and Design Outputs?
Again, thanks a lot.
 

Gisly

Starting to get Involved
#5
Disclaimer: we are just to start aligning the TIR:45 with our processes, and I'm only acting as the Project Manger on the team so there are others with better control of agile practices as well as the regulatory. But some thought I have on your questions:

1: I would exchange "approval" with "review", although practically same meaning. And yes, however in respect to part 11 requirements I would chose my wording carefully in your Design and Development Plan and lay out the formal approvals when you do your Increments. In other words, you continuously apply design control activities such as requirements specification, risk evaluation, unit testing, code review, verification which are finally approved downstream at your increments. We aim at baselining our documentation (formally updating the design records) at each increment. This is though for a new product development.

2: we have no practical experience with this yet, but to my understanding the TIR:45 recommends to deal with Design Changes with the same process as new features. What I foresee we need to ensure is that traceability to the origin of the change request (complaint, customer request, post market surveillance...), and that the criteria's for change evaluation as per QSR/ISO13485 are evaluated (risk, impact on products on market/in production... etc.) within the process.
 
#6
Hello Gisly,
thanks again for your answer.
Before reading your message I was assuming that Design Inputs were to be approved before approving Design Output.
This was due to my interpretation of FDA 21 CFR 820.30 and TIR 45. In particular, I misinterpreted the images of TIR 45 having stories framed by Design Input and Design Output Activities, where approval and control for Design Inputs seem to start before the homologous activities for Design Outputs (even though the same document states that the reverse may be reasonable).
Then, after reading the message, I started realising that my assumption was wrong. So I went through both the FDA and TIR45 documents again and I have realised that:
  1. FDA 21 CFR 820.30 does not explicitly state that Design Outputs must be approved after Design Inputs.
    Also, many paragraphs seem to insinuate such a dependency whereas a few ones may be interpreted as arguments to claim the reverse.
  2. TIR 45 is clearer on this, explicitly stating that such a dependency is not declared neither in FDA 21 CFR 820.30 nor in IEC 62304. But again, in many paragraphs and images, such dependency seem to emerge.
My personal conclusion is that both are slightly ambiguous. In any case, thanks to your message, I can better understand some TIR 45 paragraphs and I have realised that, at specific points in time (e.g. increments), Design Inputs and Design Outputs can be approved simultaneously, by considering the totality of inputs and outputs produced so far.
 

Tidge

Trusted Information Resource
#7
Then, after reading the message, I started realising that my assumption was wrong. So I went through both the FDA and TIR45 documents again and I have realised that:
  1. FDA 21 CFR 820.30 does not explicitly state that Design Outputs must be approved after Design Inputs.
    Also, many paragraphs seem to insinuate such a dependency whereas a few ones may be interpreted as arguments to claim the reverse.
(eyes pop out of my head)

Regarding the US Code: 21 CFR 820.30(d) does require that design outputs be evaluated against design inputs. If you haven't approved your design inputs then the evaluation of the outputs is meaningless in this context. Furthermore, 21 CFR 820.30 requires design and development planning (b) and design review(s) (c).

None of these requirements get in the way of an agile development approach, but they do constrain possible approaches.
 
#8
Hi Tidge,
thanks for highlighting that paragraph.
TIR 45 is about interpreting Design Controls Regulation from an Agile perspective. Clearly Design Outputs must be verified against Design Inputs, but according to the technical report, this happens in a continuous way, possibly through several iterations where Design Input and Design Output activities influence each others.
I think the authors had enough room to interpret the regulation in this way because the regulation itself does not state that Design Input must be approved and signed off before Design Output activities can start. I think that is also the reason why they can say that the formalisation of Design Outputs prior to the formalisation of Design Inputs may be reasonable in some contexts.
 

Tidge

Trusted Information Resource
#9
Nothing I've seen from TIR 45 or the linked presentation implies that Design Inputs can be unapproved prior to Design Outputs. The presentation explains that that it is possible to have discrete elements of the design inputs locked down to allow development in the area specifically allocated to satisfying those requirements, but those still would be approved design inputs. Outside of medical devices: No one should trust a mechanic to simply start work on an automobile without having approved some area of work.

Immediately after this is discussed in the presentation, the host makes a point about being able to perform regression analysis... which is only possible if there is an approved foundation of requirements and architecture. It is possible to aggregate the piece work and the associated requirements into a larger system of design inputs and design outputs, but one of the promises of agile development is to avoid wasting time by re-doing effort... including testing against (approved) requirements.
 
#10
Hello Tidge,
I see your points and, to continue this discussion, could you point me to the sections/paragraph in TIR 45 / 21 CFR 820.30 that in your opinion back up your thesis, so that I could gain a different view on this problem?

Thanks again.
 
Last edited:
Thread starter Similar threads Forum Replies Date
J Iterative design and production for custom made products ISO 13485:2016 - Medical Device Quality Management Systems 3
J Are complaints applicable to development of medical devices? Customer Complaints 2
P Training department ideas and development for automotive supplier Training - Internal, External, Online and Distance Learning 6
N Example for design and development planning,input,output,review,verification,validation and transfer Misc. Quality Assurance and Business Systems Related Topics 4
Felony Melony Project Milestone Plan-Development to Mass Production APQP and PPAP 2
A 8.6 Release of products and services, 8.3 Design and development - evidence required ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
Sidney Vianna What ISO Standard (under the TC 176) supports the UN Sustainable Development Goal #10? ASQ, ANAB, UKAS, IAF, IRCA, Exemplar Global and Related Organizations 11
A Design and development procedure for API Spec Q2 Oil and Gas Industry Standards and Regulations 6
D Using Laboratory Notebooks in R&D and Design and Development ISO 13485:2016 - Medical Device Quality Management Systems 3
D ISO 13485 - 7.3.6 Design and development verification - Do most folks create a separate SOP? ISO 13485:2016 - Medical Device Quality Management Systems 4
M Clinical Development Plan - Advice Requested EU Medical Device Regulations 11
silentmonkey Are risks in supply chain and development activities within scope of MDD? EU Medical Device Regulations 4
M QA/RA Professional Development Suggestions Training - Internal, External, Online and Distance Learning 6
N ISO 19011:2018 - 5.4.2 "...audit program should engage in appropriate continual development..." Training - Internal, External, Online and Distance Learning 4
DuncanGibbons Resources for aiding in procedure, work instruction and manufacturing plan development and management AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 0
L Design & Development of a SERVICE Service Industry Specific Topics 13
T Design Control Procedures later in the Development Process ISO 13485:2016 - Medical Device Quality Management Systems 6
K Old medical devices -> 7.3.7. Design and development validation ISO 13485:2016 - Medical Device Quality Management Systems 1
M Design Development MDR Design and Development of Products and Processes 0
O How can I justify excluding the R&D group and the design and development clause? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
Ajit Basrur ISO 22379 for citywide events now in development General Information Resources 1
D CE Marking Requirements MDD & MDR - new product development covered under same scope EU Medical Device Regulations 1
G Strategy for IEC62304 implementation half way into the software development process IEC 62304 - Medical Device Software Life Cycle Processes 9
M Informational EU – Ongoing Guidance development within MDCG Subgroups Medical Device and FDA Regulations and Standards News 1
F Software development plan for SW update IEC 62304 - Medical Device Software Life Cycle Processes 2
C IATF 16949 8.3 Exclusion - Manufacturing process design and development IATF 16949 - Automotive Quality Systems Standard 5
M Software Development Company - Who would own the whole process and the certification afterwards? ISO 14001:2015 Specific Discussions 1
A Design and development of products and services ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 2
O Software development plan : development methods IEC 62304 - Medical Device Software Life Cycle Processes 2
S ISO 9001 Clause 8.3 - Design & Development for training course center ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
S ISO 9001:2015 & ISO 14001:2015 - I need a format for Design & Development planning ISO 14001:2015 Specific Discussions 2
K Templates for software development quality audit Document Control Systems, Procedures, Forms and Templates 1
DuncanGibbons Are there aerospace standards for the development and manufacture of euipment and tools? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
L AS9100 and Agile development processes AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 8
D Electrical Safety During Medical Device Development IEC 60601 - Medical Electrical Equipment Safety Standards Series 3
S How to consider the relevant standards during development of ISO13482:2016 for IVD manufacturing Blood grouping Other Medical Device Related Standards 6
D Medical device development - Custom test equipment ISO 13485:2016 - Medical Device Quality Management Systems 3
M Informational US FDA – Device Shortages Update: Challenges to encourage the development of new approaches to device sterilization Medical Device and FDA Regulations and Standards News 0
AlienraverX Design and Development Audit ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 11
S Do we need to validate Software used in Drug discovery and development process? Qualification and Validation (including 21 CFR Part 11) 2
I QMS documents required at each stage of Software development IEC 62304 - Medical Device Software Life Cycle Processes 5
V Who should define and own the Design and Development Plan and how to maintain the updates and revisions. ISO 13485:2016 - Medical Device Quality Management Systems 2
S Development of 2xMOPP galvanic isolator for USB-connected device IEC 60601 - Medical Electrical Equipment Safety Standards Series 9
K Design and Development Exclusion Quality Management System (QMS) Manuals 1
V Exclusion of 'Design and Development' from scope of certification ISO 13485:2016 - Medical Device Quality Management Systems 9
H Supplier Development - Distributors only? The new GM Standards IATF 16949 - Automotive Quality Systems Standard 4
cscalise Determination of CPD (Continuing Professional Development) hours for a training course Training - Internal, External, Online and Distance Learning 1
XRAY_3121 Design and Development Requirement - MDSAP Audit Finding Other Medical Device Regulations World-Wide 5
Ed Panek Splitting UI (User Interface) into two development paths 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
K Capturing local government development/planning activities in aspect register ISO 14001:2015 Specific Discussions 2

Similar threads

Top Bottom