Add Your Heading Text Here
Add Your Heading Text Here
From design input to FDA submission.
Inside Azure DevOps.
Modern Requirements gives Class II and Class III device programs their design record inside Azure DevOps — design controls, ISO 14971 hazard traceability, IEC 62304 lifecycle enforcement, and Part 11 electronic signatures, in the environment your engineers already work in. AI-native by default.
Modern Requirements4DevOps · Copilot4DevOps · Agents4DevOps — including AI/ML SaMD programs under the FDA's PCCP framework.
The challenge
The clinical work is on track. The compliance posture rarely is.
Device programs don't fail audits because the engineering is weak. They fail because the evidence of that engineering lives in fragments. These are the four symptoms we see walking into device companies — each one a finding waiting to happen on inspection day.
Disconnected sources of truth
Requirements scattered across Excel, Confluence, and Word. Engineering writes, regulatory rewrites, nothing reconciles into one design record.
Bidirectional traceability
No way to trace a single hazard from ISO 14971 analysis through to its verified test result. The V-model exists in theory only.
Of AI lifecycle undocumented
Model versions, training data lineage, retraining triggers — none of it captured in a way the FDA's AI/ML SaMD guidance recognizes.
To assemble a Design History File
A full DHF pull consumes weeks of regulatory team time. An FDA inspection or notified body audit gives you days.
A composite picture drawn from device programs we've worked with. Your numbers will differ — the pattern rarely does.
Risk that drifts from the requirements it controls
Hazard items fall out of sync with the mitigations and requirements that govern them. Severity gets rescored in one spreadsheet, the derived requirement changes in another, and the V&V protocol never hears about either. The gap stays invisible until someone rebuilds the trace matrix by hand — or an auditor does it for you.
Approvals scattered across email and PDFs
Design reviews run over email threads. Signatures live in exported PDFs on a shared drive. When quality needs to prove which requirement version the release actually shipped against — with signer identity, timestamp, and meaning of signature — the answer is an archaeology project, not a record.
An AI lifecycle the FDA can't recognize
For AI/ML SaMD programs, the Predetermined Change Control Plan framework has quietly become the hardest part of the submission. A retrained model is a design change. If model versions, data provenance, and change boundaries aren't captured as controlled records, the AI work is fully built — and undocumented.
A DHF assembled under audit pressure
The Design History File is meant to accumulate as the design evolves. In practice it gets reconstructed before every inspection — linked artifacts hunted down, matrices rebuilt, gaps papered over. Reconstruction under deadline is exactly where errors propagate, and exactly what data integrity principles (ALCOA+) are meant to prevent.
Everything on this page runs on three Modern Requirements products
All native to Azure DevOps. Start with the foundation; add the layers as your program needs them.
Modern Requirements4DevOps
The requirements platform: Smart Docs, live traceability, baselines, Part 11 review management, and reporting — as work items inside Azure DevOps.
See the foundation ↓ The AI layerCopilot4DevOps
Governed AI for requirements work: elicit, analyze, check gaps, and assess impact — every output a reviewable, signable, traceable work item.
See the AI layer ↓ The agents layerAgents4DevOps
Agents that run the routine compliance work — DHF assembly, PCCP envelope monitoring, trace patrol — under policy controls you define.
See the agents layer ↓Next: how design controls and risk management run as one living lifecycle.
Next: The lifecycle →The lifecycle
Design controls as a living lifecycle — not a binder
21 CFR 820.30 and ISO 13485 describe a lifecycle: user needs flow down into design, and verification and validation flow back up. Modern Requirements runs that lifecycle as live, linked work items in Azure DevOps — so the diagram below isn't a poster on the QA wall. It's how the data actually moves.
User needs
Intended use & clinical need, captured as items
Design inputs
Requirements — quality-scored before approval
Design process
Architecture, 62304 lifecycle, reviews at each gate
Design outputs
Specs & code, traced to the inputs they satisfy
Medical device
DHF assembled from the live thread
ISO 14971
Risk management
Hazard identification
Risk analysis
Risk evaluation
Risk control
Residual risk & benefit
Post-production monitoring
The risk loop never closes. Neither does the record.
ISO 14971 isn't a phase — it's a loop that runs from first hazard analysis through post-market surveillance. In Modern Requirements, every hazard is a work item traced to the risk control that mitigates it, the requirement that implements the control, and the verification evidence that proves it works.
When post-production data reopens a risk, the loop re-enters with its history intact — the original analysis, every control decision, and every signature, on one thread. That's the difference between a risk file and a risk record.
Next: the five governed workflows that run the lifecycle day to day.
Next: Workflows →Governed workflows
Five workflows that run a device program
Each workflow is enforced inside Azure DevOps. Every state has an owner, every transition has a rule, and every approval is logged with a 21 CFR Part 11 compliant audit trail. These aren't templates you might build — they ship as the MedTech configuration of Modern Requirements4DevOps, the operating structure a deployment starts from.
Hazard & risk management
From hazard identification through verified mitigation and residual-risk sign-off. Used for every hazard in the program — vessel, embolic, electrical, AI behavioral, cybersecurity — with each control measure linked to the system requirement that implements it and the test evidence that proves it.
Identified
Hazard logged with category and exposure scenario
Risk estimated
Severity × probability scored, risk matrix applied
Risk evaluated
Acceptable, ALARP, or unacceptable
Mitigation designed
Control measure linked to system requirement
Mitigation verified
Test evidence linked, residual risk recalculated
Residual reviewed
Sign-off recorded with electronic signature
Closed & baselined
Immutable in current baseline, audit trail locked
Software item lifecycle
Every software requirement, from initial draft to baseline. Class C means the highest rigor: independent verification, formal review at every gate, no skipped states — enforced by the workflow, not by heroics.
Drafted
SWR authored, linked to parent system requirement
Peer reviewed
Technical correctness and testability confirmed
Approved for impl.
Compliance review against IEC 62304
Implemented
Code committed with SWR ID in branch name
Unit tested
Coverage threshold met, results auto-linked
System verified
Integration + system test evidence captured
Baselined
Immutable, evidence pack ready for export
Design control
Maps every design activity to the seven design controls the FDA expects — planning, inputs, outputs, review, verification and validation, transfer, and changes. This workflow drives the structure of the Design History File: each completed state contributes its section automatically.
Design plan
§820.30(b) · plan approved
Inputs documented
§820.30(c) · intended use, user needs
Outputs created
§820.30(d) · drawings, specs, code
Design review
§820.30(e) · review board sign-off
V&V complete
§820.30(f)(g) · verification + validation
Transfer approved
§820.30(h) · production-ready
DHF updated
§820.30(j) · DHF section auto-assembled
AI/ML change control
The critical one for AI-enabled devices. Every model change — retraining, architecture, thresholds — is checked against the Predetermined Change Control Plan filed with the FDA. Inside the envelope: document and deploy. Outside: halt, and prepare the pre-submission. The boundary check is automated; the decision record is permanent either way.
Change proposed
Model retrained or architecture changed
PCCP envelope check
Auto-compare change vs. filed PCCP boundaries
Documented & deployed
Change logged, model versioned, monitoring resumed
Halted · FDA pre-sub
Deployment frozen, supplement filing prepared
Lifecycle logged
Versioned model card updated with full provenance
Review & approval
The universal review workflow used for any artifact requiring formal approval — requirements, hazard analyses, protocols, baselines. Item-by-item navigation, threaded comments, and a dedicated admin account so system-driven actions are never attributed to the last human in the room.
Submitted
Review initiated with target reviewers and SLA
In review
Item-by-item navigation, threaded comments
Comments resolved
All threads addressed before approval lock
Electronically signed
Part 11 compliant signature with timestamp
Auto-closed
System action via governed admin, not last user
Audit trail locked
Immutable record, evidence ready for export
Next: every standard mapped, obligation by obligation.
Next: Compliance →Compliance
Every framework in a device program, mapped to capability
Modern Requirements maps every artifact in your Azure DevOps environment to the regulatory frameworks below — obligation by obligation, not as a marketing checkbox.
| Standard | What it governs | How it's covered inside Azure DevOps |
|---|---|---|
| FDA 21 CFR Part 820 | Quality System Regulation, design controls §820.30(a–j) | Native design control workflow mapped to all seven controls, feeding the DHF auto-builder |
| FDA 21 CFR Part 11 | Electronic records and electronic signatures | E-signatures applied to work-item versions — signer identity, timestamp, and meaning on the record itself; dedicated admin account separates user and system actions |
| FDA AI/ML SaMD + PCCP | AI lifecycle and predetermined change control | PCCP envelope workflow with agent-monitored boundary checks on every model change |
| ISO 13485:2016 | Quality management systems for medical devices | Document control via Smart Docs, live traceability, and review automation |
| IEC 62304 + A1 | Medical device software lifecycle (up to Class C) | Seven-gate software item workflow with evidence captured at every gate, no skipped states |
| ISO 14971:2019 | Risk management for medical devices | Hazard management workflow (§5–7) with configurable risk matrices and residual-risk sign-off |
| IEC 62366-1 | Usability engineering | Use specification, use-error analysis, and formative + summative evaluation records as traceable items |
| EU MDR 2017/745 | European medical device regulation | Technical file structure generated from live work-item data, supporting post-market surveillance |
Every mapping is bidirectional. Pick a clause, see which artifacts satisfy it. Pick an artifact, see which clauses it covers. When a notified body asks "show me your IEC 62304 §5.5 evidence," the answer is a filtered view of live data — not a folder someone maintains.
Next: the foundation, the AI layer, and the agents layer.
Next: The platform →The foundation · Modern Requirements4DevOps
One connected design record, from intended use to signed evidence
Modern Requirements4DevOps makes every artifact below a real Azure DevOps work item or a Modern Requirements virtual work item. The links are live. Nothing is exported, synced, or reconstructed.
Smart Docs for the documents a device program actually runs on
Structured, versioned requirement documents built from work items — not Word files pretending to be a system of record. Templates enforce your document structure, and every clause is a traceable item: system requirements, software requirements, hazard analysis, V&V protocols, the DHF skeleton, and AI/ML model cards.
Immutable baselines at every design milestone
Snapshot any work-item set at a design review, freeze, or submission gate. Locked baselines can never be edited. Compare any two and generate a difference report — your change history, in the form an auditor expects design change control to take.
Traceability into test execution, not just test plans
Horizontal traceability and intersection matrices generated in seconds from live link data. Virtual work items extend the trace into execution depth: Test Point, Test Run, Test Result, Test Step Run. Coverage gaps surface as missing links, not missing spreadsheets.
Part 11 reviews where the work lives
Structured review workflows with item-by-item navigation, threaded comments, and 21 CFR Part 11-supporting electronic signatures. Every approval carries user identity, timestamp, and version — an approval history the system builds, not a folder someone maintains.
Built inside Azure DevOps. Not integrated with it.
Many requirements tools connect to Azure DevOps. Connection means synchronization — and synchronization is where threads break, records fork, and validation findings are born.
External RM tool, synced to Azure DevOps
- Two systems of record; sync jobs decide which one is true today
- Traceability crosses a tool boundary — matrices exported, screenshotted, rebuilt
- Separate user store, separate permissions, separate validation scope
- Evidence assembled per audit: days of reassembly, every time
- AI experiments live in a third place, outside the design record entirely
Modern Requirements, native in Azure DevOps
- One system of record — requirements are work items, links are link data
- Traceability spans requirement → design → code → test execution in one graph
- Inherits Azure DevOps identity, permissions, and your existing qualified platform
- Evidence is continuous: reports generate from live state in minutes
- AI works inside the same environment — every artifact governed from birth
The AI layer · Copilot4DevOps
Govern the AI. Don't ban it — and don't ignore it.
Your organization is already an AI organization. The question a quality system asks isn't "did AI help?" — it's "can you prove what it did?" Copilot4DevOps puts AI-assisted requirements work inside Azure DevOps, so every generated artifact lands in the managed lifecycle with authorship, review, approval, and trace links intact.
Elicit & generate
Turn stakeholder inputs, source documents, and existing work items into structured requirements, derived software requirements, hazard analyses, and full V&V protocols — mapped to Azure DevOps items with traceability intact, edge cases included.
Analyze quality before it costs you
Requirements scored against the six C's — clarity, conciseness, completeness, consistency, correctness, concreteness — catching ambiguity before it becomes rework or a deviation. In a device program, an ambiguous requirement isn't a style issue; it's a nonconformance in waiting.
Gap & compliance checks
Automated analysis flags missing coverage and compliance risks across a document or backlog — the review your team means to do and never has time for. Hazards without mitigations, requirements without verification, clauses without evidence.
Impact assessment on live data
Real-time impact analysis over your actual link graph when scope changes — so a requirement change in sprint 40 doesn't surface as a validation finding in sprint 52. See every hazard, design output, and test a change touches before committing it.
The agents layer · Agents4DevOps
The routine work of compliance, executed by agents. Humans approve.
Agents4DevOps runs the repetitive, high-volume work a device program generates — trace patrol, suspect analysis, evidence assembly — under policy controls you define, with a human decision at every consequential step.
Design History File assembly
One prompt. The agent pulls every linked requirement, hazard, mitigation, design output, V&V record, and review approval from the project, validates traceability, and exports a submission-ready DHF. Work that consumes weeks of regulatory team time becomes a task you run — and re-run before every internal review.
PCCP envelope monitoring
The agent watches every AI/ML model change against the boundaries filed in your Predetermined Change Control Plan. Inside the envelope, it documents and lets the change proceed. Outside, it blocks deployment and routes to regulatory — before an out-of-envelope change ships.
Trace integrity patrol
Agents patrol the link graph as work happens: hazards missing verified mitigations, requirements missing test coverage, suspect links after every change. Gaps are flagged and repair packets drafted — before the gap becomes a finding.
Review preparation
Baseline snapshots, evidence bundles, and sign-off packages assembled automatically ahead of every design review — so the review board reviews, instead of hunting for artifacts.
A capacity multiplier for your best people, not a replacement for them. Agents execute under policy controls you define; humans review, decide, and sign. Every agent action runs through the same governed admin account and Part 11 audit trail as everything else in the system.
Next: what each role does inside the same record.
Next: Who it's for →Who it's for
One design record. Six roles working inside it.
Every workflow on this page has named owners because that's how a device program actually runs — regulatory owns residual risk, QA owns verification, engineering owns implementation. Here's what each role does inside the same system, instead of in six disconnected tools.
Owns the evidence, without the archaeology
RA owns hazard acceptability decisions, residual-risk sign-off, baseline management, and the DHF. Instead of reconstructing evidence from other teams' spreadsheets before every inspection, RA works in live compliance views — filter by clause, see the artifacts that satisfy it, export the pack.
Inspection-ready without the fire drill
Quality verifies mitigations, runs Part 11 reviews, and answers for data integrity. Because evidence accumulates as the team ships — original by construction, per ALCOA+ — inspection readiness is a state the system maintains, not a project quality runs every audit season.
Authors the record, not documents about it
Systems engineers and analysts write intended use, user needs, and system requirements in Smart Docs — where every clause is a versioned, traceable work item from the moment it's written. Copilot4DevOps drafts derived requirements and flags ambiguity before review, with the author accountable for every accepted output.
Class C rigor inside the daily workflow
Developers stay in Azure DevOps — the IEC 62304 workflow runs through the same boards, repos, and pipelines they already use. Code commits carry the SWR ID, unit test results auto-link, and compliance gates are workflow states rather than meetings. No second tool, no export discipline to maintain.
Coverage that survives requirement change
V&V protocols are traceable items linked to the requirements and hazards they verify, with the trace extending into execution — Test Point, Run, Result, Step Run. When a requirement changes, suspect links flag every affected test the moment the change lands, not when the failure ships.
Ship model changes without shipping findings
For AI/ML SaMD programs, ML engineers propose model changes into the PCCP workflow: the envelope check runs automatically, in-envelope changes document themselves into the versioned model card, and out-of-envelope changes are blocked before deployment — with the full provenance record the FDA's guidance expects.
Next: guides, blogs and whitepapers to go deeper.
Next: Resources →Resources
Go deeper on MedTech compliance.
Guides, blogs and whitepapers on building and governing medical-device software in Azure DevOps — from IEC 62304 and ISO 14971 to EU MDR, 21 CFR Part 11 and ISO 13485.
Your Guide to Medical Device Software Development
Read the guide →BlogWhy IEC 62304 and ISO 14971 Must Work Together
Read the blog →WhitepaperISO 13485 Whitepaper
Get the whitepaper →BlogEU MDR Compliance Automation for Technical Documentation
Read the blog →Blog21 CFR Part 11 Compliance
Read the blog →BlogFDA QMSR and ISO 13485 Requirements Governance
Read the blog →Next: the 90-day rollout and the questions strong buyers ask.
Next: Getting started →Implementation
A use-case-driven rollout, not a platform project
We don't turn on the full platform on day one. The rollout starts with one hazard, traced end to end, so the team experiences a real win in the first sprint — and by day 90, holds an evidence pack it can show an auditor.
One hazard, end to end
- Deployed into your existing Azure DevOps tenant
- One hazard traced from identification to verified V&V evidence
- Smart Doc structure mirrored from your current documents
- First evidence sample in regulatory's hands
Hazard analysis moved in
- Full hazard register migrated as traceable items
- ISO 14971 risk matrix configured to your scheme
- Review workflow live with governed admin account
- First Copilot4DevOps drafts on derived requirements
Role-based training, four tracks
- R&D — Smart Docs, traceability, Copilot
- QA — V&V protocols, evidence capture
- Regulatory — compliance views, baseline management
- Dev — code linking, Azure DevOps integration
First evidence pack
- DHF assembled by Agents4DevOps from live data
- PCCP envelope monitoring live for AI/ML programs
- Internal pre-audit run with mock review
- Pack exported for your next audit milestone
What "audit-ready" means, measurably
Full bidirectional trace coverage on at least one critical hazard family · the complete hazard register migrated with the ISO 14971 workflow active · and a DHF section auto-generated from live data that passes an internal mock audit.
The questions strong buyers ask
What a decision maker will want answered before talking to anyone
The questions quality directors, regulatory leads, and engineering VPs actually ask when they evaluate a system that will hold their design record. Straight answers, including where the honest answer is "that stays in your eQMS."
If this tool holds our design record, don't we have to validate the tool itself?
Yes — and any vendor that dodges this question should worry you. Under ISO 13485 and FDA expectations for computerized systems, software used in your quality processes needs validation for intended use. Because Modern Requirements runs inside your existing Azure DevOps environment, it inherits a platform your organization has typically already qualified, which narrows the validation scope to the Modern Requirements capabilities you deploy. The FDA's Computer Software Assurance approach also rewards risk-based validation over exhaustive scripts — meaning teams with continuous, system-generated evidence validate faster. [CONFIRM with product: validation pack / IQ-OQ documentation offered to customers, and current state of the CSA-aligned validation guide]
Where does our data live — and what does the AI actually see?
Your requirements, hazards, and evidence are Azure DevOps work items — they live in your tenant, under your identity model and your permissions. There is no separate Modern Requirements data store holding a copy of your design record. For the AI layer: Copilot4DevOps operates within your existing Azure DevOps permissions, is SOC 2 compliant, and your data is never used to train models or retained by third-party AI providers. [CONFIRM with product: AI subprocessor / model host, data residency options, and on-prem Azure DevOps Server support statement]
Does this replace our eQMS?
No — and it's worth being precise about the boundary. Modern Requirements is the engineering design record: requirements, hazards, design outputs, V&V, traceability, and the review evidence around them, living where the engineering happens. Your eQMS remains the system of record for controlled QMS documents, CAPA, complaints, supplier quality, and training records. The two meet at the evidence: audit-ready exports (DHF sections, trace matrices, baseline difference reports) are generated from live engineering data and filed into your QMS document structure. Teams that try to run design-level traceability inside a document-centric eQMS are usually the ones rebuilding matrices by hand.
We already have DOORS / Jama / Polarion. What does moving look like?
Migration is a program decision, not a weekend export — so the honest answer is staged. Word and document imports bring structured requirement sets into Smart Docs with their hierarchy intact; existing IDs can be preserved as attributes so historical references in submissions stay resolvable. Most teams migrate by program or product line rather than big-bang: the active program moves first (usually starting with the hazard register, as in the 90-day rollout above), and legacy programs stay read-only in the old tool until retirement. [CONFIRM with product: ReqIF import support and current migration tooling for DOORS/Jama/Polarion exports]
What are the Azure DevOps prerequisites?
You need an Azure DevOps environment — the platform your software teams are likely already living in. Modern Requirements installs as an extension into your existing organization and projects; requirements become work item types alongside the ones your teams already use, so there's no new user store, login, or permission model to administer. [CONFIRM with product: supported Azure DevOps Services plans, Azure DevOps Server versions for on-prem/regulated-cloud deployments, and extension licensing model]
What does an auditor actually receive?
Documents — because inspections still run on documents. Smart Report and document generation produce Word- and PDF-format outputs from live work-item data: traceability matrices, baseline difference reports, hazard analyses with residual-risk sign-offs, DHF sections mapped to 21 CFR 820.30, and review histories with Part 11 signature records (signer identity, timestamp, meaning of signature). The difference from the status quo isn't the format an auditor sees — it's that the document is a report of the system's state, not a reconstruction of it.
What happens after submission — post-market changes, EU MDR surveillance?
The design record doesn't retire at submission. Post-market design changes run through the same change control: impact assessment before the change commits, suspect links flagging affected verification, and baseline comparisons documenting exactly what moved between the as-submitted and as-modified states. For AI/ML devices, the PCCP workflow is inherently a post-market mechanism — it governs the model changes you'll make for years after clearance. Field data, complaints, and CAPA remain eQMS-side; where a complaint drives a design change, the change enters here as a traced requirement. [CONFIRM with product: any packaged EU MDR post-market surveillance reporting views]
Ready? Scope a MedTech working session with our team.
Book a working session →Talk to us
See it on a device program shaped like yours
A working session with our MedTech team — in a demo environment preloaded with hazard analysis, DHF structure, V&V protocols, and Part 11 review workflows. Your standards, your vocabulary, your artifact types.
- Walk one hazard end to end: identification → mitigation → verification → locked evidence
- See the PCCP change-control workflow if AI or ML is part of your device
- Watch a Design History File assemble from live work-item data
Prefer to look before you talk? Watch the five-minute technical demo — Smart Docs authoring, live traceability into test execution, and Part 11 e-signature workflows, screen-recorded in the live product. Watch the demo — no form →
Book a MedTech working session
Tell us about your program. We'll come prepared with your standards, not a generic tour.
