Giter Site home page Giter Site logo

rcpch / digital-growth-charts-documentation Goto Github PK

View Code? Open in Web Editor NEW
5.0 6.0 9.0 10.65 MB

Documentation site for all parts of the RCPCH Digital Growth Charts Project

Home Page: https://growth.rcpch.ac.uk/

HTML 90.96% Dockerfile 9.04%
documentation growth rcpch-growth-charts

digital-growth-charts-documentation's People

Contributors

a-wei-william avatar aciduk avatar anchit-chandran avatar chvanlennep avatar dc2007git avatar eatyourpeas avatar magdaumerska avatar mbarton avatar pacharanero avatar statist7 avatar

Stargazers

avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar

Forkers

chvanlennep statist7 aciduk pacharanero magdaumerska chakshuverma a-wei-william anchit-chandran dc2007git

digital-growth-charts-documentation's Issues

Design feedback on Graphs

From @kirsten-olson @Jo-Ball

  • The use of tint for shading on some graphs is fine

  • Per Simon’s’ question, we think the black and grey grid colours are fine. (We weren’t
    totally sure what was meant by data points – is it the centiles and other instructions
    that display on hover? But think fine!)

  • We see (we think?) the standard Arial font is used for the graphs’ titles, axes titles,
    etc. The popups that display on hover are in Montserrat. We assume you’ve used
    the standard font where needed, ie for legibility, so that’s fine. Our general
    preference is for Montserrat, with Arial as a backup; we thought you could use Arial
    for all chart elements.

  • Explanation – There’s some draft text below the graphs and input form. We wonder
    whether should rather display immediately below heading, so serves as an
    introduction?

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

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

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.

image

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

Documentation for how to set up a Material for MkDocs development environment is outdated

  • We probably want to switch to using a Dockerised development environment to simplify things - this will of course change the documentation significantly.
  • We no longer use the Insiders Edition of Material for MkDocs, so we need to change the instructions accordingly.
  • Windows instructions are a little unclear as to whether to use WSL, bash (eg git-bash), or CMD/PowerShell. We need a very clear, worked example of one of these, whichever is the best.

Add Tags to the documentation site

Material for MkDocs has support for Tags which are applied in the YAML front matter of each page and are indexed into a [TAGS] section which we can render in a tags.md page.

This allows us to superimpose another layer of discoverability on the documentation site, which is now quite large. Users may find what they need via navigating the 'tree' of headings and content, they may find content via search, but they may also find from the tags menu all the parts of the documentation that is tagged of relevance to that subject.

https://squidfunk.github.io/mkdocs-material/setup/setting-up-tags/#adding-tags

Academic publication

As part of a review of the concept of age correction, we should present the RCPCH API in the academic press to discuss how the process of developing an API influences the science of growth and charting.

Contact us tab

Might make contact info easier to find if we put it on the main navigation bar

Fix the Dark Mode so that the header bar and RCPCH logo invert on Dark toggle

At present, although Dark Mode works for the page content, the header bar doesn't switch.
This is probably because we have hard-coded CSS for some of this in docs/_stylesheets/extra.css
image

MkDocs info on this is here https://squidfunk.github.io/mkdocs-material/setup/changing-the-colors/#custom-colors

Ideally we'd want the top header bar to invert to a dark colour, probably a shade lighter than the dark content background?
Text would need to change colour for contrast and readability.
RCPCH logo may need to be re-coloured (maybe switching where used, but keeping the same colours?)

Specify fair use for free tier in the docs

We need to have a section stating the terms of the API - some of this can come from the T&C/contract template we have.

  • Multiple Free Tier account creation will result in deletion of all accounts and a ban/block
  • Use of any endpoints other than the api.rcpch.ac.uk endpoint is prohibited
  • 'reselling' the API through your own service is banned and could result in legal action ('rebadging' a Medical Device presumably has consequences)

iframe on front page of demo site needs to be resized so that there is no scrollbar

See https://growth.rcpch.ac.uk/

The demo site is embedded as an iframe, from a static React site which is CI'd in GitHub Pages and is live at https://rcpch.github.io/digital-growth-charts-react-client/

However the content of the demo client must have changed slightly and now it is displaying with a scroll bar, which is undesirable from an appearance point of view

  • resize the iframe constraints to fit without needing a scroll bar
  • (optional) see if there is a way to make it auto-adapt to future changes in demo client size

Digital Technologies Assessment Criteria (DTAC) documentation

As per discussions at today's Sprint Planning Meeting, we agreed to prioritise completion of the DTAC assessment form for the Digital Growth Charts project.

The details of DTAC on NHSE's website are here https://transform.england.nhs.uk/key-tools-and-info/digital-technology-assessment-criteria-dtac/

The form is an ODT document which we will edit online using Google Docs, then download again as ODT for adding to the documentation website

@magdaumerska and I will work on this ASAP

Swagger demo API calls don't work

The Swagger demo which is integrated into our documentation site is not working fully. It displays the API spec but it doesn't successfully call the API because it is using the wrong baseUrl.

Because there is authorization required on the api.rcpch.ac.uk endpoint, even just to request the / (root) endpoint, which describes the API in openapi/Swagger format, we can't call that api.rcpch.ac.uk endpoint without having to include an API key in the documentation site.

So instead we call the raw page in GitHub to get the API spec: https://raw.githubusercontent.com/rcpch/digital-growth-charts-server/live/openapi.json

But the Swagger UI component seems to think this is the BaseUrl we want to call with API requests.

FIX:

  • Set up the / root endpoint on api.rcpch.ac.uk so that some domains can call it without needing authorization (this will probably require a different API Management platform, which we are currently looking at)

  • Change the configuration of the Swagger UI component to call api.rcpch.ac.uk/growth/v1 to get the AI spec document form there.

Needs STRONG WARNING on demo site banner to advise people not to use demo site for clinical work

We have had reports that some community trusts are advising their staff to use the RCPCH digital growth charts demo site at https://growth.rcpch.ac.uk/ for clinical use, against the warnings in the documentation.

At the dGC Project Board meeting on 16th February 2022 the board suggested adding a more obvious banner or warning to prevent this kind of use.

We also discussed the idea of a more 'lightweight' solution for trusts lacking sufficient IT infrastructure to be able to integrate the dGC properly - for example a simple webapp with login, and a usage quota on a per-organisation basis

These images look terrible - need better ones

digital-growth-charts-documentation/docs/clinician/chart-information-health-staff.md

Lines 31 to 32 in 9e0aa8d

## When to measure length or height

view the documentation site here https://rcpch.github.io/digital-growth-charts-documentation/clinician/chart-information-health-staff

These images are quite small. I think they were originally embedded in some source documents which the Project board asked to add to the main documentation. Could we get hold of some nicer versions of them?

Consider non-pink/blue

I will embed them once we have nicer images

HAZARD: Unavailability of the dGC API calculation and charting functions

Description

If the API does not respond then centile measurements will be unavailable

Effect

No response from the API would mean no growth chart calculation values and no graphical growth charts

Hazard

In the absence of a measurement from the API, users may have to fall back on manual methods of centile calculation such as printed Growth Charts.

Harm

It is hard to envisage the unavailability of the API causing any form of harm to a patient because there are immediately available fallback methods such as manual calculation on printed paper charts.

Possible Causes

  1. Failure of internet connectivity at Site
  2. Failure of Internet connectivity at Supplier/Integrator
  3. Failure of Internet connectivity at Microsoft Azure UK Data Centre
  4. Failure of internal networking in Azure cloud platform
  5. Failure of proxying through Azure API Management Platform
  6. Failure of the API server WebApp platform
  7. Failure of the API server application code

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'

User Journeys documentation

NHS Wales have developed User Journeys for their implementation, which we may be able to obtain and modify for our needs.

dGC "Subscriber Guide" section in dGC docs needs developing

Some notes for when doing next review of the docs site:

  • Following conversations with some of our customers it may help to have an architecture diagram showing how the dGC API fits in with their current system - needs to be clearer that the base EPR is the one calling our API.
  • Possibly need a clearer walkthrough of how to creat an App in the Dev Portal
  • Need to add a section showing how to view reporting/usage in the Dev Portal
  • FAQs section - full review and add in questions asked by the NHS cBMI team.

High level description of the API endpoints

  • What is offered by the API?
  • What do each of the endpoints do?
  • One-pager in the MkDocs site which details the main offerings, by API endpoint, with links to the relevant section in the openAPI docs.

HAZARD: Misuse of the API code by external organisations

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.

Merge the documentation site into one of the other dGC repos

As we have found with the E12 project, having documentation within the project makes it more likely it will be updated at the time other codebase changes are made.

We should merge this repo into one of the other repos.

The most appropriate one would probably be the dGC server repo itself since this is the 'central product' of the dGC platform and service.

At the point of merging the repos, the other codebase should also be Dockerised, so that both can easily be set up to run in one dev env, simply.

  • Follow the instructions here https://gist.github.com/msrose/2feacb303035d11d2d05 to merge the repos without losing the Git history. Put the documentation site inside a documentation/ folder.
  • Delete the old repo from GitHub
  • Ensure all links which refer to the location of the old repo are updated, everywhere across the other repos
  • Dockerise the destination repo
  • Add the Mkdocs service to the docker-compose.yml of the destination repo
  • create scripts folder and s/up, s/down scripts as needed
  • update deployment GitHub Actions, which currently push the docs site to Azure - this will need to continue but will build from documentation folder. This needs to be done with care because THIS IS A LIVE DOCS/DEMO SITE FOR DGC
  • Test local dev is working, from scratch
  • Test the deployment works

HAZARD: Wrong data is entered into the Digital Growth Chart API (as opposed to the user interface)

Description

Incorrect data could be sent to the API. This incorrect input data would cause the API to return the incorrect results.
Importantly, this Hazard is

Cause

A number of causes for this hazard are possible, and these all originate outside of the API.

It is important to note that RCPCH do not control the client software which will use the API. However, all dGC client software systems are themselves subject to NHS Clinical Safety standards, and there should be consideration of this risk within their own Hazard Log and Clinical Safety Case.

Examples of some causes that dGC integrators should watch out for:

  • User interface error which allows the user to enter the wrong data into the UI, or a poor UI design which makes it difficult to spot common errors.
  • An internal client data transfer error which sends incorrect data to the API despite correct data entered in the UI.

Effect

Incorrect data sent to the API could result in incorrect results being returned from the API and an aberrant clinical decision being made on the basis of those incorrect results.

Hazard

As with most of the Growth Chart Hazards, the potential problem is that a child either:

  • doesn't receive intervention when it should, or
  • receives inappropriate intervention when it should not.

Harm

In both the above scenarios, our Project Board of clinical paediatrics and growth experts agreed that the absolute risk of directly attributable harm to a child is rather low, because of the multiple clinical practice safeguards that exist whether the growth chart is paper, PDF or digital.

Because growth is slow, such clinical decisions regarding growth monitoring and interventions are often taken on the basis of multiple measurements, over a period of time, and there is always 'clinical correlation' between the Growth Chart findings and the presentation and appearance of the patient.

This means that a single erroneous reading is unlikely to result in an incorrect clinical decision. Furthermore, the actual visual plot points on chart itself are part of the mitigation because a single outlying result that seems at odds with the preceding trend will alert clinical suspicions. The charting is actually part of the clinical error-rejection mechanism, which established in practice and predates digital charting and APIs.

Examples of harm that 'could' happen:

  • A child's failing growth is not noticed because of incorrect data, and intervention fails to happen. The child comes to harm because intervention is not taken.
  • A child is wrongly referred to Social Services by a clinical practitioner because, based on an erroneous trend in the growth measurement suggesting neglect, and this results in a complaint from the child's parents.

Related Hazards

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.

Weight Chart 67.7 value look higher that 68.1

67_7_KG
68_1_KG
fullchart

Hi,
This was noticed by one of the clinicians.

In the Down weight chart we have 5 weight observations.

Two of those observations are for a weight of 67.7 and 68.1.

Now in the chart the 67.7 look slightly higher that the 68.1 (see attached images).

Not a major issue/but is noticeable in the chart.

Thanks
Stephen

Print Chart

Have you any experience printing the chart?

I've tried and it doesn't come out very well.

It something the clinician are asking for as there a requirement to send printed charts to external 3rd parties.

Thank
Stephen

Page for list of 'Who is using the dGC API?'

@joknight25 could we collate a list of organisations who are using the dGC API?

I am not sure whether we should ask them first or not. I can't see any reason why using the dGC API would be seen as anything other than an accolade and a positive thing. Perhaps we could make the list and publish it and 'ask forgiveness' if anyone objects?

Once we have a list I will incorporate it into a new page in the documentation.

Homepage banner - text is hard to read

The text, especially the ‘Working with clinicians…’ is hard to read. While we’d originally recommended the ‘wallpaper’ design, we suggest using a bright blue (#11a7f2) background so easier to read. Or, if there’s another option to add a white background to the
text, that would also work.

Screenshot of current state

image

Review documentation on Gestational Age Correction

  • Ensure the GAC pages of documentation cover the topic properly
  • Add discussion on post-term GAC, for example the 'reversed' correction which applies to 43- or 44-weekers
  • Point to the discussion on this subject in the Archives

HAZARD: Incorrect centile data is returned by the API

Affects

Code: https://github.com/rcpch/digital-growth-charts-server

Description

The API could return incorrect centile data.

Effect

The user would be presented with an incorrect set of centile data.

Hazard

The hazard is that an inappropriate clinical decision could be made on the basis of this incorrect centile data.

Harm

Harm could result from the incorrect data not being recognised as such, and

Possible Causes

An analysis of the Causes of the Hazard

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'

google sheets extension - details

@eatyourpeas could you share the links for the Google Sheets extension?
Is it in version control somewhere or in the weird Google Apps Script walled garden?
Can we publish it somehow?
Can we mirror the source in GH?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.