From Regulation to Reality: The Foundations of a Modern DHF/DDF

Thomas Cronin

— 4 min read

In my initial post, Introducing the Project, I noted a pattern I’ve seen across teams building digital health products, regulations themselves are rarely the real barrier, the challenge is translating those expectations into clear, repeatable ways of working that fit the realities of modern product development

Most teams know what they need to comply with. Far fewer have a shared understanding of how to operationalize it in real SDLC execution.

This post begins that exploration by surveying the regulatory and industry guidance that defines what a modern Design History File (DHF), soon to become the Design and Development File (DDF) under FDA’s QMSR, actually needs to demonstrate in the context of agile engineering and product delivery. In later posts I’ll break these topics down through Plan-Do-Check-Act (PDCA) and map where automation, traceability, and toolchain integration can reduce friction and risk.

1. FDA guidance defines the regulatory backbone

FDA’s core documents set the expectations for how a modern DHF/DDF should look and behave:

These materials define what must be evidenced: clear design inputs/outputs, risk-based validation, secure architectures, transparent logic, and evidence that non-device functions (e.g., MDDS-type features) do not compromise safety.

2. Industry engineering teams show how this works in practice

Industry voices add the operational “how” that FDA doesn’t spell out:

Recurring themes include:

  • Traceability in agile environments
  • Integrating design controls into Jira, GitHub, CI/CD
  • Avoiding DHF/DDF catch up at release

All reinforce a key point: the DHF/DDF has to be built into the workflow, not bolted on afterward.

3. Cybersecurity experts push the DHF/DDF toward security by design

FDA sets the regulatory expectation; industry provides concrete patterns and failure modes:

Common implications include:

  • Threat modeling must be continuous, not a onetime artifact
  • SBOMs require real dependency and vulnerability management
  • Secure SDLC evidence must reflect actual engineering practice
  • Vulnerability management and patching must integrate into releases
  • Post market cybersecurity monitoring becomes a core safety function

Cybersecurity is now a top DHF/DDF input, not an appendix.

4. Privacy by design is emerging through both security and product practice

While FDA doesn’t regulate privacy directly, privacy expectations now shape how teams design and document digital health products.

Highlighted practices include:

  • Data classification and mapping
  • Consent flows and transparency
  • Access control and audit logging
  • Data minimization and retention
  • Privacy relevant risk assessments

Combined with FDA cybersecurity guidance, these practices push privacy by design into DHF/DDF adjacent documentation, especially in risk, architecture, and post market surveillance.

5. MDDS, multiple function, and CDS guidance reflect real product complexity, and industry confirms it

FDA’s guidance reflects the reality that many digital health products blends:

  • Regulated and unregulated functions
  • Data storage/transport and clinical decision support
  • Workflow features and diagnostic/therapeutic features

Industry sources (Orthogonal, Emergo, etc.) echo similar operational challenges:

  • Documenting boundaries between device and non-device functions
  • Ensuring unregulated features don’t introduce safety risks
  • Maintaining architectural clarity as products evolve
  • Documenting CDS logic and transparency to FDA expectations

This is where regulatory theory meets product reality, and where the DHF/DDF becomes the place to show that the system has been thought through end to end.

What this means for the modern DHF/DDF

Across FDA guidance and industry practice, the DHF/DDF is evolving into a holistic, lifecycle-oriented evidence system that integrates:

  • Design controls and software lifecycle documentation
  • Risk management and clinical/performance evidence
  • Cybersecurity by design and privacy by design
  • MDDS and multi-function boundaries
  • CDS transparency and logic traceability
  • Post market surveillance and continuous learning
  • Real world engineering workflows and agile practices

Conclusion

Taken together, the FDA guidance landscape and the parallel body of industry practice paint a clear picture, a modern DHF/DDF isn’t just a regulatory artifact. It’s the connective tissue between design intent, engineering execution, safety and performance evidence, cybersecurity posture, privacy safeguards, and the realities of how digital health products evolve in production. It’s the system that shows not only what was built, but why, how, and with what level of control.

This post sets the foundation. From here, I’m moving into two concrete next steps.

First, I’ll assemble a comprehensive, end to end list of DHF/DDF deliverables, not just the traditional design control elements, but the full set of artifacts implied across FDA guidance, software lifecycle standards, cybersecurity expectations, privacy by design practices, and industry proven workflows. The goal is to create a single, unified view of what “good” looks like for modern digital health teams.

Second, I’ll begin breaking these elements down through Plan–Do–Check–Act (PDCA) to show how they map onto real software development. That’s where automation, traceability, and toolchain integration start to matter, how teams can reduce friction, eliminate DHF/DDF catch‑up work, and build compliance into the flow of engineering rather than bolting it on at the end.

Those pieces are coming next, and they’ll form the bridge between this landscape survey and the practical frameworks that follow.

Read more