How to Stop Managing Documents and Start Managing the Work

For decades, regulated teams have treated documentation as the work. But what if documentation simply reflected the work that’s already been done? 

That’s the shift behind item-centric, or data-centric, development. Instead of writing, formatting, and manually maintaining documents, teams generate compliant documentation as a byproduct of their development process.

This is how modern, agile teams deliver high-quality, safety-critical products faster—without compromising safety or compliance (and actually even improving them). 

Actual Quotes from Document-Centric and Item-Centric Teams

More traditional, document-centric teams tell us that they are hesitant to move to a more item-centric or data-centric approach because they fear the quality of their products would suffer. On the other hand, agile, item-centric teams recognize that generating documentation directly from the work done actually decreases the risk of errors making their way into final documents.

From Blank Docs to Artifacts 

Traditional documentation begins with a blank page (usually a Word document). Teams have to manually write a Software Requirements Specification (SRS), Software Design Specification (SDS), Software Detailed Design (SDD), a Risk Management File, a Testing Report—then update each document as changes occur. 

In an item-centric approach, the starting point isn’t a document—it’s a unit of work. Each requirement, specification, test, or risk is treated as a traceable object (or “configuration item,” in the words of IEC 62304), with its own traceability relationships.

So when a requirement changes, the system knows which downstream items are impacted. When a test is added or updated, it’s automatically linked to the item it’s testing. When a patch is deployed, approvals, risks, and mitigations get captured automatically. 

Documentation isn’t built separately. It’s assembled automatically. 

“If we just document the work that engineers already do, it creates no more work for them. It lets engineers be engineers.” - Head of Quality, global medical device company

Companies embracing this shift are seeing results: 

• A radiology company released a critical patch in 48 hours instead of two weeks 
• A SaMD startup structured their development around items in Jira from day one, so they never had to build a spreadsheet
• A cardiology AI company decomposed a Markdown file into 150 traceable design control items in under 5 minutes using an AI agent 

“We don’t want to do this in the old fashioned way with a lot of Excel spreadsheets and so on. If we automate this process, it will also help us moving forward because it will be faster if we need to fix something.” - engineering lead, first-time device company

Here’s what the shift from document-centric to item-centric looks like in practice: 

Why This Works

Item-centric development works because it flips the process. Instead of asking, “How do we write a compliant document?” teams ask, “How do we build a compliant product?”

When every item is traceable and audit-ready, the documents practically write themselves. 

“We’re looking to become a repeat FDA application company. So we want to set up our system in such a way that we can just continue working in our day-to-day, handling complaints and feature requests, our normal way of working inside our natural SDLC setup, and generating all these outputs that can be FDA-compliant.” - Engineering leader, early-stage radiology company

This isn’t just about speed. It’s about safety and scalability. Agile, quality-driven teams can’t afford to reinvent documentation from scratch with every change. With an item-centric approach, they don’t have to. 

Start with Items

If your current process starts with writing documents, you’re already behind.

Start managing the work, not the paperwork. Let documentation become an outcome—not a barrier—to speed, quality, and safety. 

In our next post in this series, we’ll dive deeper on how to use AI to assist in managing the work and generating the documents needed for regulatory compliance.