Engineers write the software requirements specification, the architecture diagram with its software items, and the interfaces to systems outside the device. Risk workshops bring engineering, clinical and regulatory staff through each hazard and turn each design control into a requirement that can be verified. The algorithm is packaged in a container so the runtime used in verification is the runtime that ships.
On the map: Software requirements and architecture. Risk workshops. Containerize the algorithm.
Rows are disciplines, columns are stages 1 to 8. Select a square to open that task.
Back to the full map
Write requirements alongside cybersecurity's threat model and clinical's hazard input, so every risk control lands as a testable requirement. Quality checks the trace before the Phase 1 review.
Only what will certainly ship goes inside the boundary. Routers, PACS, host computers and viewers are named as external items, each with an interface requirement and installation instructions. A tight boundary keeps the requirements, threat model and later change assessments small.
Each requirement states one verifiable property without prescribing a design and carries a unique ID. Software items are cut where they can be developed and tested separately and where a failure in one can be isolated from the rest.
For each hazardous situation the group estimates severity and likelihood before controls. Controls are chosen in the order of inherent design, protective measure and information for safety. Every design control becomes a requirement traced to its risk and to a verification protocol.
The image holds the algorithm, its libraries and the model weights, pinned so the verified environment can be reproduced at every site. Inputs and outputs pass through mounted folders or a documented port, so hospital IT can connect them without changing the device.
See the open positions and apply.