Medical device product checklist – The place where OCD rules!

Preface

I’ve sampled the healthcare industry both from the administrative services point of view, developing actuarial Risk Adjustment for US health providers, from the production side, designing face recognition application to reduce the errors in medical treatments as well as being involved in the implementation and planning of biometric solution to reduce the tracking effort of shop-floor workers in the pharma industry. Also adopting a medical device that used a sensor to track vitals for bedridden patients, and via AI calculate the patient various health parameters and risks.

In all those activities for various companies, with different SOPs (Standard Operating Procedures), the common denominator was traceability, not quality but traceability!

Edward Deming who was one of the fathers of scientific management said that “Quality comes from not from inspections but from improvement”. If you don’t have measurement and traceability of your processes, you can’t improve them, nor can you inspect or control them.

Traceability is the ability to verify the history, location, or application of an item by means of documented recorded identification. So, it’s a log of the process that is used to develop the item, as well as it’s outcomes.

Waterfall and agile, software and hardware – Like water and oil

When dealing with interdisciplinary products we have a clashing of cultures and different development speeds. In software you can and probably do Agile or Scrum, as it has proven to be the most effective way to develop code. You can automate stuff by CI/CD and practically not be limited by the laws of physics. In Hardware things are a bit different in terms of development rate as well as building a BOM that is using external resources with hard supply chain, and physical packaging constraints.

The usual way to deal with those differences is to incapsulate the faster processes in the slower ones – I.e. build a Gant that has relevant cyclic activities like sprints shown within a container task. Since sprints are managed quite well within tools like Jira and MS Devops, there is no need to track them in detail, unless there are dependencies with the slower process, for example. Developing a driver for a hardware component. In this case it’s worthwhile to manage it with the Hardware development.

Building traceability into the process.

Traceability is defined as: “The ability to discover information about how the product was made”. This means that there should be an audit trail that documents the decision process and the activities that took place during the product’s lifecycle.

There are several levels of decision making that can, and should be dealt with differently:

Strategic – Those are document driven processes that broadly define product direction, like MRD (Market requirement definition) and PRD.
Tactical – Documents that describe what is planned in terms of technical design documents and processes like SDD (Software Design Document) and Electrical schemas.
Operational – How the actual implementation is done, usually linking actual code, objects, and other product outputs like git commit hashes pointing to the user story that created them, or naming convention that is linked to the parent document.

Tracking through the ages

As the product is moving through its lifecycle, we may have multiple changes from MVP to maturity. Most of those changes are aggregated through time so we need a way to trace them. Imagine a product that you review after a development process that took 18 years (this is not uncommon in internally developed applications in large organizations). How can you trace what you see and have to the original requirements? Those were changed several times due to internal or external constraints and demands.

One way to do it is through meticulous usage of elements of the CMMI (Capability Maturity Model Integration). To cut a long story short, you add a structured layer of process management to your development process, this is not just CI/CD automation but rather workflow of change requests and approval by stakeholders, so that you can oversee if the change in the size of a component didn’t hinder its placement. And on top of that you measure the process activities with KPIs like the accuracy of time estimation tasks, and on top of that you build a mechanism to optimize change the process to be fore efficient, by maybe explore changes that reduce time to market not by scope changes of the product but by changes material resources, production methods or libraries.

The process – An example

I am by now way a regulation expert, but I’ll try to give an example of standardized development process of a multidisciplinary product that is targeting a regulated market like the medical devices market.

Remember that medical devices are broadly specified according to their risk to the patient and the auditing procedures as well as standards are different between the USA FDA, the EU and Japan.

In the table below we have a check list that can be used to build a document driven traceable development process. The main takeaway from this is that one has to keep the waterfall structure between the stages, however within the stages there can be parallelization as well as agility.

Phase	Description
Project planning stage	This phase involves defining the project scope, objectives, and deliverables. It includes activities such as creating a project plan, outlining the timeline, identifying resources, and setting milestones.
PRD (Product Requirement document) DRAFT	The PRD is a document that outlines the requirements and specifications for a product. The DRAFT version indicates that it is still under review and subject to changes before finalization.
Project Plan review meeting minutes	Meeting minutes are notes taken during a project plan review meeting. They record discussions, decisions, and action items for future reference and accountability.
Design input stage	Design inputs are the requirements, specifications, and criteria that a product’s design must meet. These inputs are critical for the development process.
PRD (Product Requirements Document)	Final PRD
Risk Analysis	Risk analysis involves identifying potential risks in a project or product and assessing their impact and likelihood. This helps in developing risk mitigation strategies.
Default configuration document	This document specifies the default settings and configurations for a product or system.
List of Applicable Standards and regulatory requirements	It is a compilation of all the relevant standards and regulations that the product must comply with during its development and manufacturing.
SRS review meeting DR (design review)	The SRS (Software Requirements Specification) review meeting focuses on evaluating the software requirements for a project and ensuring they are accurate and complete. DR stands for Design Review.
HRS review meeting (design review)	The HRS (Hardware Requirements Specification) review meeting focuses on evaluating the hardware requirements for a project and ensuring they are accurate and complete.
STP (System testing plan)	The STP outlines the strategy, scope, and approach for testing the entire system to ensure it meets the specified requirements.
User Training – If needed to ensure safety and performance of the device	This involves providing training to users of the product to ensure they can operate it safely and effectively.
RR (requirements review)	Requirements Review is a formal assessment of the project requirements to ensure they are well-defined, complete, and feasible.
Design Output stage	Design outputs are the results and deliverables of the design process, such as technical documents, drawings, and specifications.
SDD (software detailed design)	The SDD describes the detailed design of the software, including algorithms, data structures, and interfaces.
IDD (interface design document)	The IDD outlines the design of interfaces between different components or systems within a product.
OTS (Off-The-Shelf design document)	This document details any off-the-shelf components or products that are used in the design of the main product.
Electrical schemas	Electrical schemas are diagrams that depict the electrical connections and components of a system or device.
Block diagrams	Block diagrams provide a high-level representation of the system or product, showing its main functional blocks and their interconnections.
User manual	The user manual is a document that provides instructions and guidance to users on how to use the product effectively.
BOM (bill of materials)	The BOM is a list of all the materials, components, and parts required to build a product.
Packaging and labeling	This refers to the design and specifications for the packaging and labeling of the product for retail or distribution.
Design output review meeting minutes	Meeting minutes from a review meeting that discusses the design outputs to ensure they meet the required standards and specifications.
TRR – Test readiness review stage	The TRR assesses the readiness of the product for testing, ensuring that all prerequisites for testing are fulfilled.
STP (system testing plan)	The Software Test Plan (STP) describes plans for qualification testing of Computer Software Configuration Items (CSCIs) and software systems. It describes the software test environment to be used for the testing, identifies the tests to be performed, and provides schedules for test activities.
STD (software testing description) including validation protocols	The STD outlines the procedures, protocols, and criteria for testing the software to verify its correctness and compliance with requirements.
Communication bench testing protocol	This protocol outlines the testing procedures for communication systems and protocols used in the product.
HTD (hardware testing description) including sensors if applicable	The HTD describes the procedures and protocols for testing the hardware components of the product, including any sensors used.
HTR (hardware testing report)	The HTR provides a record of the hardware testing results, including any issues found and their resolution.
Test readiness review meeting minutes	Meeting minutes from a review meeting that assesses the readiness of the product for testing.
SVR (System validation review)	The SVR is a review process to ensure that the product meets all the specified requirements and is ready for validation testing.
PRR (product readiness review)	The PRR evaluates whether the product is ready for production and distribution based on various criteria.
Technical support documents	These documents provide information and guidelines for technical support teams to assist users with product-related issues.
DMR (device master record) completion	The DMR is a compilation of all the records required for manufacturing a medical device or product, and its completion indicates readiness for production.
Production and testing equipment	This refers to the machinery, tools, and equipment needed for the production and testing of the product.
Production facility training and readiness	Ensuring that the production facility and its personnel are trained and prepared for manufacturing the product.
Production validation plan	This plan outlines the procedures and criteria for validating the production processes to ensure consistency and quality of the manufactured product.

Delivering Project & Product Management as a Service