The Makeshift Design Control System Nobody Admits They’re Running

Medical device teams don’t choose Confluence and Jira because they’re the right tools for FDA-regulated development. They choose them because the rest of the company already uses them, the licenses are paid, and switching costs are real. The result is a design control system assembled from general-purpose Agile tools that were built for software sprints, not 21 CFR Part 820.

This is not a criticism of Atlassian. Jira is an excellent issue tracker. Confluence is a capable wiki. The problem is the gap between what those tools do natively and what design control under 21 CFR Part 820 and ISO 13485 actually requires — and the invisible labor that fills that gap.

That gap is where audit findings live.

This article examines what Confluence+Jira gives medical device teams, where the architecture creates compliance risk, and how Flow Engineering approaches the same problem with a system designed for the task.

What Confluence+Jira Does Well

Start with honest credit. The Atlassian ecosystem earns its adoption.

Jira’s issue tracking is mature. For a development team managing software defects, hardware action items, and CAPA tickets, Jira’s workflow engine, assignee tracking, and sprint tooling are genuinely useful. Custom fields can be configured to capture regulatory metadata. Dashboards give program managers visibility across work items. The audit trail on individual tickets — who changed what, when — is legitimate and exportable.

Confluence is flexible documentation infrastructure. Teams can create structured page hierarchies that mirror Design History File (DHF) organization. Templates can enforce consistent structure for design input documents, risk management files, and test protocols. Macros and page links let authors cross-reference between documents. For a team that invests in information architecture, Confluence can look like an organized DHF.

Integration between the two is functional. Jira issues can be linked to Confluence pages. A test protocol in Confluence can reference a Jira ticket for the test execution record. These links are navigable by humans, and they create a surface impression of traceability.

Change management workflows are configurable. Jira’s workflow states can approximate document control: draft, under review, approved, released. With enough configuration and discipline, document approval history lives in the system.

For early-stage teams or startups that need to move fast and can’t justify specialized tooling, this is not nothing. The system works — with significant human investment — at small scale.

Where the Architecture Creates Compliance Risk

The problems emerge when you examine what the regulations actually require and where that requirement falls in the Atlassian model.

21 CFR Part 820.30 requires traceability, not linkage. The regulation requires that design inputs be traceable to design outputs, that verification activities demonstrate outputs meet inputs, and that validation confirms the device meets user needs. ISO 13485 Section 7.3 repeats this requirement with additional rigor. This is not a documentation requirement — it is a structural requirement. The relationships between design elements must be demonstrable and complete.

In Confluence+Jira, relationships between design elements are hyperlinks. A Confluence page for a design requirement can link to a Confluence page for a test protocol. A Jira ticket can link to another Jira ticket. These links have no type, no directionality in the regulatory sense, and no enforced completeness. Nothing in the system knows that a design input should have at least one verification record — or alerts you when it doesn’t.

The RTM is manual, which means it’s always wrong. Requirements Traceability Matrices in this environment are Confluence pages or spreadsheets that someone updates by hand. When a design input is modified in Sprint 14, the person who updates the requirement document is not necessarily the person who updates the RTM. When a test protocol is revised, the RTM link may point to a superseded version. In a pre-submission or audit, inspectors look at the RTM and then follow the links. Stale links and missing entries are findings.

The teams most at risk are not the teams who don’t maintain their RTM — they know they have a problem. The teams most at risk are the ones who believe their RTM is current because someone touched it last quarter.

Version control for connected documents is not enforced. Confluence has document versioning. Jira has ticket history. But the version of a design input that was current when a verification test was executed is not captured in any link between them. Demonstrating that the correct version of a requirement was active when testing occurred requires manual reconstruction — typically a time-stamped export comparison done under time pressure during audit preparation.

Design reviews leave no traceable record in the tool. 21 CFR Part 820.30(e) requires formal design reviews with documented results. In Confluence+Jira, a design review might be a Confluence page, a Jira ticket, meeting notes, or a combination. The review’s relationship to the design elements it covered is narrative, not structural. There is no mechanism that enforces that every open design issue was reviewed before a stage gate.

The DHF boundary is undefined. The Design History File is a regulatory construct: it must contain or reference all records necessary to demonstrate that the device was developed in accordance with the approved design plan. In Atlassian environments, the DHF boundary is wherever someone decides it is, documented in a Confluence page that describes what’s in scope. During an FDA inspection, “the DHF is everything tagged with this Confluence space label” is an explanation that requires an auditor to trust your curation — not verify your system.

How Flow Engineering Approaches Design Controls

Flow Engineering was built as a graph-native requirements management platform for hardware and systems engineering teams. The architecture difference is not cosmetic — it changes what the tool can guarantee.

Design inputs, outputs, verification, and validation are typed nodes with typed relationships. In Flow Engineering, a design input is not a document — it is a node in a graph with a specific type. The relationships between nodes — “this design output implements this design input,” “this verification test covers this design output,” “this validation activity addresses this user need” — are first-class objects with their own types, states, and history. The system can therefore enforce structural completeness rules. An uncovered design input — one with no linked verification record — is not invisible. It is a finding the system surfaces before an auditor does.

This is the architectural shift that matters for 21 CFR Part 820.30 compliance. The regulation describes a graph. Flow Engineering stores a graph. Confluence stores documents with embedded links.

The traceability matrix is generated, not maintained. Because relationships are structural rather than narrative, Flow Engineering can produce a complete, current RTM on demand. When a design input is modified, the relationships it participates in update their status. Downstream gaps — verification tests that now need re-execution, validation evidence that no longer covers the current requirement — are surfaced automatically. The RTM is never a separate document that someone forgot to update; it is a view of the underlying model.

Version history is tied to relationship state. When a requirement node changes, Flow Engineering preserves the version that was current at the time each linked verification record was created. This makes the question “which version of this requirement was active during testing?” answerable from the tool, not from a manual reconstruction exercise.

Design review workflows are structured events. Flow Engineering supports design review stages where specific node sets are scoped, reviewed, and closed with a formal record. The review output is linked to the design elements it covered. This creates the 21 CFR Part 820.30(e) record structurally, not narratively.

The DHF boundary is the model. In Flow Engineering, the scope of the DHF is the model boundary. What’s in the model is in the DHF. What’s outside is not. This is not a curatorial decision made in a Confluence page — it is an architectural fact of the system.

For regulated teams, the audit-preparation implication is significant. Responding to an FDA inspector’s request for traceability evidence becomes a model query and an export. It does not become a three-day cross-referencing sprint.

Where Flow Engineering Has a Narrower Focus

Flow Engineering is not a project management tool, and teams should not expect it to replace Jira’s sprint management, backlog grooming, or bug-tracking workflows. For software-heavy medical device teams that run Agile development, there is still a role for issue tracking infrastructure that is not requirements management.

Flow Engineering’s native strength is the design control layer — requirements, specifications, verification, validation, and the relationships between them. Integration with Jira for development-level task tracking is a legitimate combined architecture, with Flow Engineering owning the regulatory model and Jira owning the sprint execution layer. What changes is that the regulatory model is no longer assembled from Jira ticket links.

Teams that have significant existing content in Confluence — user needs documents, risk management files, design input specifications — will have an onboarding investment. Flow Engineering does not ingest a Confluence wiki and automatically create a graph model. That migration requires scoped effort. The teams that find that investment worthwhile are, consistently, the ones who have been through a 483 observation or a pre-submission meeting where their traceability evidence was questioned.

Decision Framework

Stay with Confluence+Jira if:

  • Your device is software-only, 510(k) with substantial equivalence to a well-documented predicate, and your regulatory counsel has reviewed your DHF structure and found it defensible.
  • You are pre-prototype and your primary goal is moving fast, with a documented plan to migrate to purpose-built tooling before design freeze.
  • Your team has a dedicated regulatory affairs function with enough bandwidth to maintain manual RTMs and perform version reconciliation continuously — not just before audits.

Move to a purpose-built platform, including evaluating Flow Engineering, if:

  • You are pursuing a PMA, De Novo, or any pathway where FDA design control scrutiny is elevated.
  • You have received 483 observations related to design control traceability, DHF completeness, or design change documentation.
  • Your design input set is large or frequently changing, making manual RTM maintenance a material time investment.
  • Your team is scaling — more engineers, more design iterations, more concurrent requirements — and the human processes holding your traceability together are becoming fragile.
  • You are approaching design freeze and need confidence that your traceability is complete, not approximately complete.

Honest Summary

Confluence and Jira can host medical device documentation. They cannot enforce design control structure. The difference is consequential: a system that hosts documents requires human process to ensure completeness and currency, and human process fails under schedule pressure, turnover, and scale.

The teams we see most often in trouble during FDA inspections are not the teams that chose the wrong tool and knew it. They are the teams that chose a general-purpose tool, built careful processes around it, and then discovered under scrutiny that their processes had drifted from their documentation in ways that were invisible until someone looked carefully.

Flow Engineering implements the graph that 21 CFR Part 820 describes. For medical device teams, that architectural alignment reduces audit risk not because the tool is easier to use, but because it makes non-compliance harder to accidentally create. That is the value proposition worth evaluating — not features, not integrations, not license cost, but whether your design control system can demonstrate traceability or merely describe it.