Quality Management System¶

This page is the quality manual for the RCPCH's medical-device software activities. It describes the Quality Management System (QMS) maintained for the design, development, release and post-market surveillance of the RCPCH Digital Growth Charts (dGC) Platform, and maps the requirements of ISO 13485:2016 to the place in this documentation, or the GitHub process, where each is satisfied.

Purpose and scope¶

The QMS exists to ensure that the dGC Platform is clinically safe, effective and fit for purpose. It is implemented primarily through Git-based version control on GitHub, supplemented by the structured clinical-safety and regulatory processes documented in this section.

• In scope: all Software as a Medical Device (SaMD) registered with the MHRA under the RCPCH as manufacturer — currently the dGC API Platform and its associated client components.
• Out of scope: third parties deploying RCPCH open-source code under licence, who assume manufacturer/deployer responsibilities independently under their own DCB0160 assessment.

The dGC Platform is the RCPCH's only SaMD product today. As further products follow, generalisable patterns from this QMS are intended to be extracted into a shared template.

Normative references¶

Organisational roles¶

Person Responsible for Regulatory Compliance (PRRC)¶

The RCPCH designates a Person Responsible for Regulatory Compliance (PRRC) — a role adopted from medical-device regulatory good practice — who ensures that the technical documentation is kept up to date, that post-market surveillance and reporting obligations are met, and that the Declaration of Conformity is accurate. The PRRC for the dGC Platform is Dr Marcus Baw.

Competence and training¶

Clinical-safety activities are undertaken by competent staff (see the Clinical Risk Management Plan). It is a matter of public record that:

• Dr Marcus Baw is an NHS Digital-trained Clinical Safety Officer and a registered medical practitioner (GMC 4712729);
• Dr Simon Chapman is a consultant paediatrician (paediatric diabetes and endocrinology) and a trained Clinical Safety Officer.

Quality policy and objectives¶

Quality policy. The RCPCH is committed to developing and maintaining SaMD that is clinically safe, effective and fit for purpose, achieved through transparent open-source development, rigorous clinical-safety management, and continuous improvement informed by real-world performance and user feedback.

Standing quality objectives:

• No unmitigated high or unacceptable risks in the Hazard Log at any release.
• All serious incidents assessed for MHRA reportability and reported within required timelines.
• Management review and internal audit each conducted at least annually.
• Calculation accuracy continuously evidenced by the static test harness, with zero unresolved calculation regressions at release.

Document and record control¶

All controlled documents — this manual, the clinical safety file, and the technical documentation — live in Git and are published on this site. The control mechanism is GitHub, not a manual document-control log:

• Changes are proposed by Pull Request and require at least one approving review before merge to the protected live branch.
• The Git commit history is the complete, immutable change record for every controlled document; history is not rewritten on live.
• Records (hazards, incidents, complaints, CAPAs, audits and management reviews) are created from the QMS Issue templates, identified by QMS process labels, kept as GitHub Issues and commits, and retained indefinitely. Records are public by default; where a record would contain sensitive or patient-identifiable information (for example within a serious-incident investigation), that specific content is restricted and handled case by case.

This replaces traditional manual document controls, as described in the Clinical Risk Management Plan.

Design and development¶

Design and development follow the IEC 62304 software lifecycle (software safety Class B). In practice this is the project's open, CI-gated, branch-promotion workflow: requirements and design inputs are captured as GitHub Issues and published specifications; changes are implemented with accompanying automated tests; every change is peer-reviewed via Pull Request; and releases are tagged commits promoted to live only after verification. Verification and validation — including the ~4000-child static test harness — are summarised in the Software Lifecycle page.

Risk management¶

Risk management follows ISO 14971, implemented through the DCB0129 process and 5×5 risk matrix, with a mapping between the two. The risk management file comprises the Clinical Risk Management System, the Clinical Risk Management Plan, the Hazard Log and the Clinical Safety Case Report. No release may proceed with an unmitigated risk rated high or unacceptable.

Purchasing and supplier management¶

Suppliers whose products could affect device quality, safety or availability are assessed and monitored in the Third Party Tools Safety criticality register, which records each supplier's purpose, criticality and the controls applied. Critical suppliers are reviewed at management review.

Complaints and post-market surveillance¶

Feedback and complaints arrive through open GitHub Issues, the RCPCH forum, and direct implementer communication, and are handled under the Post-Market Surveillance plan. Serious incidents are assessed for MHRA reportability by the PRRC under the incident process. Clinical performance is appraised in the Clinical Evaluation Report.

Scheduled QMS activities¶

The QMS runs to a defined rhythm. Each recurring activity has an owner and a record; the records are GitHub Issues raised from the corresponding Issue template.

Management review¶

A formal management review is conducted at least annually, and following any significant quality event. It reviews the quality policy and objectives, audit findings, complaints and PMS data, supplier status, regulatory changes, open CAPAs, and actions from the previous review. Each review is planned and recorded using the Management Review Issue template, whose agenda enumerates the ISO 13485 §5.6 inputs; the completed, closed Issue is the record of the review, and follow-up actions are raised as CAPA or design-input Issues.

Internal audit¶

Internal audit verifies that the QMS conforms to ISO 13485 and is effectively implemented. The RCPCH already audits its software and quality process on an ongoing, informal basis (for example through continuous open code review and the static test harness); this manual formalises that practice into a documented annual audit cycle. Each audit is planned with the Internal Audit Issue template and conducted by someone independent of the area audited; each finding is recorded with the Audit Finding template, and non-conformities drive a CAPA to resolution.

ISO 13485:2016 clause mapping¶

Review of this manual¶

This manual is a controlled document under the QMS it describes. It is reviewed at each management review, following any significant regulatory change, following any internal-audit finding affecting the QMS itself, and when a new product is brought into scope. Changes are made by Pull Request; the Git commit history is the version record.