# 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?