Medical Device Software
- # Medical Device Software Planning...
(I'm familiar ish with the hardware / classic design controls process but software is new. So we're mapping 62304 / FDA requirement deliverables onto the design controls buckets)
- Standards/Guidances Inputs
- Cybersecurity Gang
- See written notes at https://github.com/CameronCarroll/medical_device_software?hidden=true
- InputsPlanning
- ## SDP
Software Development Plan
(Lifecycle, roles, tools, system integration)
- Software Gang
- ## Coding Standards
- ## Software Safety Classification Documentation ??
(Just put this in the SDP?)
- ## Development Environment Documentation
(Tools, compiler/interpreter, development standards)
--> Build reproducibility
- ## Software Config Mgmt Plan
Version control, traceability, change mgmt
- ## Cybersecurity Management Plan
(Proactive controls for devices, cloud & data)
[FDA Premarket Cybersecurity 2023]
- ## SRS
Software Requirements Specification
(Detailed functional/performance/safety requirements for each software component)
- ## Software Hazard Analyses
Initial risk analyses for each software component (firmware, SaMD, backend server)
- ## Software Architecture Design
High-level structure of software components and physical / logical interfaces
(Arch is input because it defines/locks the interfaces)
- ## Cybersecurity Hazard Analysis
(Initial)
- ## FDA-specific architecture views
FDA may be expecting certain views such as detailed connectivity diagrams, update paths, and segregration controls.
- ## Threat Modeling Report
(Identifies attack vectors such as cloud APIs and bluetooth in handheld devices)
[FDA Cybersecurity Guidance]
- ## SBOM
(Software Bill of Materials - inventory of all open-source and commercial software components, used for downstream vulnerability monitoring)
SBOM might be used as a risk input? Depending on what type of third party components we have I guess? Not sure about this but that's why it's way over here in inputs.
[§360n–2. Ensuring cybersecurity of devices]
- OutputsDMR
- V&V
- ## Software Integration / Integration Testing
Test interactions between components.
[Integration testing - Test transfer of data & control across internal / external interfaces (eg OS call or interface to hardware)
Tests boundary conditions and beyond (invalid, unexpected, special inputs)
Expect both white-box and black-box approaches will be needed for our risk class
- ## Software Validation Master Report
Trace software requirements to test cases
EMC/EMI aspects of software?
- ## WI for version control / administration
- ## WI's for deployment (App Store, Knox, Cloud)
- WI for sending new versions of firmware to the CM? or ... is that just a design change?
- Transfer
- Postsubmission / Postmarket
Medical Device Software
- # Medical Device Software Planning...
(I'm familiar ish with the hardware / classic design controls process but software is new. So we're mapping 62304 / FDA requirement deliverables onto the design controls buckets)
- Standards/Guidances Inputs
- Cybersecurity Gang
- See written notes at https://github.com/CameronCarroll/medical_device_software?hidden=true
- InputsPlanning
- ## SDP
Software Development Plan
(Lifecycle, roles, tools, system integration)
- Software Gang
- ## Coding Standards
- ## Software Safety Classification Documentation ??
(Just put this in the SDP?)
- ## Development Environment Documentation
(Tools, compiler/interpreter, development standards)
--> Build reproducibility
- ## Software Config Mgmt Plan
Version control, traceability, change mgmt
- ## Cybersecurity Management Plan
(Proactive controls for devices, cloud & data)
[FDA Premarket Cybersecurity 2023]
- ## SRS
Software Requirements Specification
(Detailed functional/performance/safety requirements for each software component)
- ## Software Hazard Analyses
Initial risk analyses for each software component (firmware, SaMD, backend server)
- ## Software Architecture Design
High-level structure of software components and physical / logical interfaces
(Arch is input because it defines/locks the interfaces)
- ## Cybersecurity Hazard Analysis
(Initial)
- ## FDA-specific architecture views
FDA may be expecting certain views such as detailed connectivity diagrams, update paths, and segregration controls.
- ## Threat Modeling Report
(Identifies attack vectors such as cloud APIs and bluetooth in handheld devices)
[FDA Cybersecurity Guidance]
- ## SBOM
(Software Bill of Materials - inventory of all open-source and commercial software components, used for downstream vulnerability monitoring)
SBOM might be used as a risk input? Depending on what type of third party components we have I guess? Not sure about this but that's why it's way over here in inputs.
[§360n–2. Ensuring cybersecurity of devices]
- OutputsDMR
- V&V
- ## Software Integration / Integration Testing
Test interactions between components.
[Integration testing - Test transfer of data & control across internal / external interfaces (eg OS call or interface to hardware)
Tests boundary conditions and beyond (invalid, unexpected, special inputs)
Expect both white-box and black-box approaches will be needed for our risk class
- ## Software Validation Master Report
Trace software requirements to test cases
EMC/EMI aspects of software?
- ## WI for version control / administration
- ## WI's for deployment (App Store, Knox, Cloud)
- WI for sending new versions of firmware to the CM? or ... is that just a design change?
- Transfer
- Postsubmission / Postmarket