Skip to content

SOP-008-DesignAndDevelopmentControl.md

Latest commit

 

History

History
129 lines (112 loc) · 7.42 KB

SOP-008-DesignAndDevelopmentControl.md

File metadata and controls

129 lines (112 loc) · 7.42 KB
Raw
sop_id SOP-008
title Design and Development Control
revision R11
revision_date 2026-05-04
status Published
owner_role engineering_lead
approver_role qa_lead
related_issue #4

1. Purpose

Define design and development controls for healthcare software products from planning through release and maintenance.

2. Scope

Applies to new products, major features, and significant lifecycle changes affecting safety, performance, regulatory submissions, or claims.

3. Inputs

  • Product intended use and user needs
  • Regulatory and standards requirements
  • Risk management inputs

4. Outputs

  • Approved design-input baseline and design history evidence
  • Verified/validated software release package
  • Controlled transfer and maintenance artifacts

5. Roles and Responsibilities

Role Responsibilities
Engineering Lead Owns system/software requirements, technical design planning, architecture, and release-readiness accountability.
Engineer Implements design outputs and executes assigned verification activities under approved plans.
QA Lead Ensures process conformance and evidence adequacy, and owns intended use, claims, user needs, and regulatory constraints that become design inputs.
Usability Lead Owns usability-engineering inputs, user profiles, critical tasks, and user-interface evaluation planning for user-facing products.

6. Procedure

6.1 Design and Development Planning

  1. Define lifecycle plan, milestones, and responsibilities.
  2. Identify review/verification/validation gates.
  3. Define required deliverables and entry/exit criteria per phase.
  4. For regulated software products, include software safety classification, configuration baselines, and release decision criteria per SOP-020.
  5. Do not treat implementation planning as approved until the design-input baseline gate is completed.
  6. Integrate risk management activities throughout the design and development lifecycle in accordance with SOP-018.

6.2 Design Inputs

  1. Capture user needs, safety/performance requirements, and regulatory constraints.
  2. Engineering Lead owns system and software requirements; QA Lead owns intended-use, claims, and regulatory input definitions; Usability Lead owns user-profile and critical-task inputs for user-facing products.
  3. Verify input completeness, consistency, and testability.
  4. Resolve conflicting requirements before implementation.

6.3 Design-Input Baseline Approval

  1. Before controlled implementation starts, open a PR in the designated product repository that baselines:
    • design and development plan
    • intended use or equivalent scope statement
    • user needs
    • system requirements baseline
    • initial risk-management plan/reference set
    • planned V&V strategy
  2. The design-input baseline must state key assumptions, open constraints, and any explicitly deferred inputs.
  3. The PR body must state:
    • **Meaning of Signature:** Approved Design Inputs and Development Plan
    • **Signer Roles:** Quality Assurance Lead; Engineering Lead
    • **Required Signatures:** 2
  4. Merge only after required approvals on the current head commit and post-merge signature attestation collection.
  5. Changes to approved design inputs require a new PR revision before they are used as the basis for controlled implementation or release evidence.

6.4 Design Outputs

  1. Produce architecture, detailed design, and implementation artifacts.
  2. Ensure outputs are traceable to approved inputs.
  3. Define acceptance criteria for each output element.

6.5 Design Review

  1. Conduct planned independent reviews at defined milestones.
  2. Record participants, findings, decisions, and action items.
  3. Resolve critical findings before proceeding to next phase.

6.6 Verification and Validation

  1. Verification demonstrates outputs meet design input requirements.
  2. Validation demonstrates product meets user needs/intended use in representative context.
  3. Maintain bidirectional traceability requirements -> risk controls -> tests -> results.
  4. Execute V&V planning, approval, evidence review, and post-merge PIN signature flow using WI-001.

6.7 Design Transfer and Release

  1. Confirm release readiness checklist completion.
  2. Ensure required regulatory and QMS deliverables are approved.
  3. Design transfer shall ensure that approved design outputs are correctly translated into deployment, operational environments, support processes, and release procedures.
  4. Release only controlled versions with immutable record linkage.
  5. Configuration baseline and release publication must follow SOP-020 and WI-002.

6.8 Design Changes

  1. Manage post-baseline changes under SOP-009.
  2. Re-run impacted verification/validation and update traceability.
  3. Design and development records shall be maintained as part of the Medical Device File in accordance with SOP-007.
  4. Integrate risk-management updates throughout design changes in accordance with SOP-018.

7. Required Records

  • Design/development plan and approved design-input baseline
  • Requirements, architecture, and traceability records
  • Verification/validation evidence

8. Traceability

Standard Clause Control in this SOP
ISO 13485:2016 7.1 Planning of product realization and quality controls.
ISO 13485:2016 7.3.1-7.3.10 End-to-end design/development controls from planning to changes.

9. Related Controlled Documents

  • SOP-007 Medical Device File Control
  • SOP-009 Change Management
  • SOP-015 Nonconforming Product Control
  • SOP-020 Software Lifecycle, Configuration, and Release Management (IEC 62304:2006+A1:2015)
  • WI-001 Verification and Validation Execution
  • WI-002 Configuration and Release Management Execution

10. Revision History

Revision Revision Date Change Summary
R00 2026-03-02 Initial full release.
R01 2026-03-06 Added IEC 62304:2006+A1:2015 lifecycle/release linkage and default GitHub-native V&V execution reference.
R02 2026-03-07 Normalized engineering and product/regulatory roles for small teams and added explicit engineer execution responsibilities under approved plans.
R03 2026-03-07 Renamed lead roles to engineering_lead and regulatory_lead to remove owner-style role wording.
R04 2026-03-07 Clarified ownership of system requirements, regulatory design inputs, and usability inputs, and added usability_lead responsibilities.
R05 2026-03-07 Added the explicit design-input baseline gate requiring group approval of the development plan and approved input set before controlled implementation.
R06 2026-03-07 Removed overly specific signature-regulation terminology from the design-input approval wording and used technology-neutral signature language.
R07 2026-03-18 Removed top-table standards clause metadata; normative references remain in the Traceability section.
R08 2026-03-25 Added explicit lifecycle risk-management integration, expanded design transfer expectations, and linked design records to the MDF.
R09 2026-03-27 Consolidated the standalone regulatory-lead responsibilities into the QA-lead role and reduced the design-input baseline signer set accordingly.
R10 2026-04-27 Renamed YAML metadata field effective_date to revision_date to align controlled-document metadata with the tag-based publication model. The effective date is derived from the published QMS release tag rather than from the document front matter.
R11 2026-05-04 Standardize standards citations to specific versions.