HAZARD: Wrong units of measurement are used for the data sent to the API

[pacharanero]

This Issue Template is based on the practices described in NHS Digital DCB0129/DCB0160 Clinical Safety Officer training.

Thanks to John Meredith of Digital Health and Care Wales for requesting clarification which resulted in this Hazard being created.

Description

If the API receives data in the wrong units, the result of the calculation could be wrong or misleading.

For example if the child is weighed in grams and this gram weight value is sent to the API then the weight centile will be potentially very high. Similarly if the height is measured in metres and supplied to the API as metres then the height centile will potentially be very low. However the API does have error rejection to handle this within certain bounds.

Cause

• This hazard would have to occur as part of a mis-implementation by the supplier or Trust adopting the charts, or a significant user error.

• If the units of measurement of the data sent to the API are incorrect, then an incorrect result will be returned.

• This result would not necessarily be distinguishable from a correct result as it would be displayed in the user interface alongside correct values.

Effect

• The clinician using the chart would potentially interpret the erroneous value as a correct one.

• This could result in incorrect decisions being made about the care being provided.

Hazard

• In a worst case scenario this could result in unnecessary monitoring or treatment being provided to the patient because of concern about a massively outlying single measurement.

Existing Mitigations

• TECHNICAL: The API rejects significantly outlying data in the request. The ranges for this validation are described in the rcpchgrowth Python library codebase here https://github.com/rcpch/rcpchgrowth-python/blob/live/rcpchgrowth/constants/validation_constants.py

In the below example, the height has been passed in metres instead of the correct centimetres.

"child_observation_value": {
        "measurement_method": "height",
        "observation_value": 1.15,
        "observation_value_error": "Height/length must be passed in cm, not metres"
    },

• IMPLEMENTATION GUIDANCE: In our demonstration user interface the UI validates outlying values, raising errors for obviously incorrect values. We encourage implementers to use our demo as a 'live code documentation' example which they can use for implementing their own UI, and they can actually use this open source code as a framework to start from.

• INTERFACE: An extremely outlying growth result would be markedly divergent from the existing growth trajectory on the growth chart, which should raise concerns. The UI is clearly labelled with the units required.

• TRAINING: Clinicians are trained when using Growth Charts that they must not take action on the basis of a single outlying growth result. They are also trained as to the correct units to use (cm for length/height/OFC and kg for weight).

---

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 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

[pacharanero]

I think that this risk is well mitigated already, at a number of levels. The actual real risk of a patient receiving incorrect treatment or additional surveillance or parental concern as a result of this error is very low.

However I can see that our API documentation could make it clearer exactly which units are expected. I will raise this as an issue to improve the API documentation so that implementers are fully aware of the expected units.