ICH Q9(R1) tests whether digital risk records support decisions

A risk record must preserve a decision

ICH Q9(R1) frames quality risk management as a systematic process for assessing, controlling, communicating, and reviewing risks to medicinal-product quality across the lifecycle. That sequence is more demanding than storing a probability score and a colored status. A useful digital record must preserve the question being assessed, the evidence considered, the reasoning behind the evaluation, the controls selected, the residual uncertainty, and the conditions that cause the decision to be reviewed.

The guideline also says the level of effort, formality, and documentation should be commensurate with the level of risk. That principle does not mean high-risk records should simply contain more fields. It means the method, expertise, evidence, review, and documentation should fit the consequence and uncertainty of the decision. A system that applies one rigid workflow to every issue can create administrative volume without improving the quality of judgment.

Subjectivity needs visible controls

The revision gives added attention to subjectivity in quality risk management. Teams can reach different conclusions because of assumptions, incomplete knowledge, facilitation choices, or the way a risk question is framed. Software may standardize scales and calculations, but a standardized interface does not remove those sources of variation. It can even conceal them if the result appears authoritative while the underlying rationale remains unavailable.

Buyers should test whether reviewers can see the evidence behind each rating, identify who supplied it, record alternative interpretations, and challenge a conclusion without erasing the original history. The platform should distinguish a fact from an assumption, a proposed control from an implemented one, and an unresolved uncertainty from an accepted risk. Those distinctions support review and learning; they do not replace the accountable quality decision.

Digitalization expands the assessment boundary

ICH Q9(R1) notes that digitalization and emerging technologies can reduce risks in some circumstances and introduce new ones in others. Its examples include the design, validation, technology transfer, and lifecycle management of advanced manufacturing processes, data-analysis methods, and computerized systems. This makes the technology itself part of the risk question: data lineage, model changes, configuration, access, integration failure, and human oversight can affect the reliability of the resulting quality process.

A provider demonstration should therefore include a change to the computerized workflow, not only the steady-state form. Teams can ask what happens when a calculation rule changes, an input arrives late, an integration supplies conflicting data, or an automated recommendation is rejected. The system should preserve version, validation status, exception handling, approval authority, and the evidence used at the time. Later reconstruction should not depend on the current configuration.

Review triggers are more useful than dashboards

Risk review is part of the ICH process, and the frequency of review should relate to the level of risk. That creates a practical buyer test: can the organization define both scheduled and event-driven review triggers? A deviation trend, supplier change, process modification, new knowledge, control failure, or product-availability concern may all change the evidence supporting an earlier conclusion. An overdue badge is not enough if the platform cannot show why review was triggered and what changed.

The final harmonised guideline provides principles and illustrative applications; it does not validate a software product or prescribe one implementation. RegQuality Review therefore treats vendor documentation as evidence of documented capability, not proof of validated use or compliant outcomes. Buyers should connect the guideline's decision logic to their procedures, risk taxonomy, validation approach, and accountable roles, then test whether the digital record remains intelligible throughout the lifecycle.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

RegQuality Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.