Template: Document Roadmap for Technical Documentation

Sören Hornof
September 7, 2022
0 comments

Template Download

This is a free template, provided by OpenRegulatory.

If you are a user of Formwork, our eQMS software, choose “QMS” on the top menu and “OpenRegulatory Templates” on the left menu, and then open the relevant folder to find this template ready to load into Formwork.

If, for some mysterious reason, you’re using a different QMS Software, you can also simply download this template – specifically, as Word (.docx), PDF, Google Docs or Markdown file. Scroll down for a preview!

The template license applies (don’t remove the copyright at the bottom).

Tired of copy-pasting? If you want to save time and edit these templates directly, you can use Formwork, our eQMS software. And if you’re looking for step-by-step instructions for filling them out, check out our Wizard 🙂

Don't Miss Updates to This Template
Subscribe to our newsletter and we'll keep you posted on which templates we've changed.

Questions? Still Lost in Regulation?

Good news! Our goal is to provide lots of stuff for free, but we also offer consulting if you need a more hands-on approach. We get stuff done really fast. Have a look!

Template preview

This is a proposed roadmap to creating the TechDoc file. The documents are grouped by “Design Phase”. To each document, a responsible person is assigned as the author. Go through the list phase by phase. You can mix up the order of documents within a phase, but I recommend to finalize documents from one phase before moving on to the next.

PHASE 1: Planning & Feasability

DocumentAuthorComment
Intended UseCEOThis is the most important document of your TechDoc. Business and Regulatory Strategy depend on it.
Medical Device ClassificationQA/RA MangerDefining the product’s medical device classification acc. to MDR.
Product RoadmapProduct ManagerNot an essential document. This is for feasibility assessments and resource planning. Helps to keep track of what’s to come.
Software Development and Maintenance PlanSoftware DeveloperGiving product-specific information on the tools, resources and methods to be used for software development. Helpful for developer teams to align regarding the development setup.
Change Evaluation ListQA/RA MangerListing and assessing gaps between the last and the upcoming software version. Follows criteria from MDCG 2020-3. Not needed for the very first release.
Risk Management Plan and Risk Acceptance MatrixRisk ManagerSpecifies the methods for assessing risks to be used for the product at hand. Defines probability and severity categories and acceptable ranges.
Clinical Evaluation PlanClinician / Scientific PersonSpecifying the methodology that shall be used to assess the clinical benefits and risks of the product.

PHASE 2: Specification

DocumentAuthorComment
User Needs ListProduct ManagerThis is a list of high-level requirements. Most of them will be implemented through Software Requirements.
User Needs ChecklistQA/RA ManagerChecking if the User Needs List makes sense.
Software Requirements ListDeveloper-adjacent personSpecifying how User Needs will be incorporated in the software. Describing the details of a feature.
List of Hazard-Related Use ScenariosRisk ManagerIdentifying scenarios in which users could be prone to hazards.
Risk TableRisk ManagerAnticipating and assessing risks. Gathering input from various channels.
Software Requirements ChecklistQA/RA ManagerChecking if the Software Requirements List makes sense.
Software Test PlanSoftware DeveloperDefining tests for every Software Requirement and mapping them to each other.
Usability Test PlanProduct Manager / Usability EngineerSpecifying the methodologies to be used to conduct the Usability Test.

PHASE 3: Development

DocumentAuthorComment
SOUP ListSoftware DeveloperList of external libraries, frameworks and packages used in the product, incl. their assessment of criticality.
Software ArchitectureSoftware DeveloperDescription/Graphic outlining the software components and their interaction.

The actual programming work takes place in this phase. It makes sense to create the SOUP list and the software architecture immediately before programming begins and to adjust them if anything changes during code creation. These documents should actually be created in advance, but due to the iterative nature of software development, it will not be possible to plan everything before the actual work begins. Therefore, it makes sense to create them in parallel with the programming.

PHASE 4: Verification and Validation

DocumentAuthorComment
Software Test ResultsQA TesterResults of the Software Tests: passed or failed?
List of Known AnomaliesSoftware Developer / Product ManagerList of known bugs and failed software tests. Justification why the software can still be released without impacting benefit/safety and a timeline when those bugs will be fixed.
Instructions For UsePerson with the best overviewThe name says it all.
Usability Test ProtocolProduct Manager / Usability EngineerSpecifying the actual usability test cases: Testing User Needs, Hazard-Related Use Scenarios and Instructions for Use.
Usability Test ReportProduct ManagerSummary of the results of the Usability Test.
Clinical Evaluation ReportClinician / Scientific PersonAnalysing scientific data to prove the products safety and efficacy.
Risk Management ReportRisk ManagerSummary of the Risk Management Activities

PHASE 5: Product Release

DocumentAuthorComment
GSPR ListQA/RA ManagerChecking if the “General Safety and Performance Requirements” are fulfilled.
PMS (/PMCF) PlanQA/RA ManagerPlanning the product-specific activities for Post-Market Surveillance. If the clinical data is not sufficient, also plan Post-Market Clinical Follow-Up activities.
Software Release ChecklistQA/RA ManagerChecking if all the requirements are fulfilled, if the documents are complete and if the product is safe to be used.
Release NotesProduct Manager OR Software DeveloperDescription of new features in the current release.
Declaration of ConformityQA/RA and CEODeclaring the product’s conformity with the regulations and standards.

Template Copyright openregulatory.com. See template license.

Please don’t remove this notice even if you’ve modified contents of this template.

Template preview

Comments

Leave the first comment