HAZARD: Misuse of the API code by external organisations

[pacharanero]

Description

The dGC code is open source. This could mean that an external organisation could decide to self-host the API and they may make an error in its implementation or deployment, leading to erroneous results.

Cause

We do not necessarily know the motivation of an external body for wanting to self-host the API. They may wish to avoid paying the API fees, for example. The RCPCH provides a commercial support tier which offers on-premise deployment, for organisations which wish to have their own API server running on their own infrastructure.

Implementing digital growth charts is technically difficult and we warn extensively against independent self-hosting in the documentation for the dGC project. Even an organisation who are quite technically competent could make elementary errors in clinical interpretation or accidentally skew the statistical model which generates the Growth Chart response data.

Effect

An aberrant implementation could return erroneous data to clinicians.

Hazard

The erroneous data returned could mislead clinicians in their management of a patient, leading to suboptimal care.

Harm

A patient could get the wrong treatment resulting in excessive treatment for a condition which does not exist, or undertreatment of an unrecognised condition.

Based on discussions in our other Hazard Log entries, the Project Board did not think it plausible that death of a single patient was possible because of this kind of error. In their extensive paediatrics careers they had not experienced harm of a high Severity occurring solely from aberrant growth chart data.

Mitigation

• As mentioned above, the RCPCH offers a commercial support tier which provides a warranted on-premise deployment for organisation who wish to have a safe, dedicated API server running on their own infrastructure.
• The dGC project's documentation warns strongly against self hosting of the API, in a number of places, and offers detailed explanation as to the reasoning behind this.
• Beyond this, we do not believe there is anything further we need to do to mitigate this issue, as it is occurring completely outside the control of the RCPCH. Closing the source of the application would remove the ability for others to host it, but it would also have very serious side-effects curtailing the open transparency, auditability, and safety profile of the project. Closing the source code is not an appropriate mitigation and will not be considered.

---

Assignment: Assign this Hazard to its Owner. Default owner is the Clinical Safety Officer @pacharanero
Labelling: Add labels according to Severity. Likelihood and Risk Level
Project: Add to the Project 'Clinical Risk Management'

• Subsequent discussion can be used to mitigate the Hazard, reducing the likelihood (or less commonly reducing the severity) of the Harm.
• If Harm is reduced then you can change the labels to reflect this and reclassify the Risk Score.
• Issues can be linked to: Issues describing specific software changes, Pull Requests or Commits fixing Issues, external links, and much more supporting documentation. Aim for a comprehensive, well-evidenced, public and open discussion on risk and safety.

[github-actions]

Thank you for opening or editing a Hazard in the RCPCH dGC Hazard Log.

Next steps

• Please use the Labels feature in the right sidebar area to stratify this Hazard in terms of Likelihood and Severity

[github-actions]

Thank you for opening or editing a Hazard in the Hazard Log.

Next steps:

• Please use the Labels feature in the right sidebar area to stratify this Hazard in terms of Likelihood and Severity
• Assign the Issue to the Clinical Safety Officer for triage