rcpch / digital-growth-charts-documentation Goto Github PK
View Code? Open in Web Editor NEWDocumentation site for all parts of the RCPCH Digital Growth Charts Project
Home Page: https://growth.rcpch.ac.uk/
Documentation site for all parts of the RCPCH Digital Growth Charts Project
Home Page: https://growth.rcpch.ac.uk/
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?
This section may need review
Couple of issues with it:
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.
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.
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.
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.
rcpchgrowth
Python library codebase here https://github.com/rcpch/rcpchgrowth-python/blob/live/rcpchgrowth/constants/validation_constants.pyIn 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"
},
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'
There is currently no content on this page https://github.com/rcpch/digital-growth-charts-documentation/blob/79ea3593f28606b628dbb249203e79cca6f9bddc/docs/developer/adding-a-new-api-endpoint.md
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
We have this guidance for Down Syndrome charts from Dr Liz Marder, which is of clinical importance to add to the documentation portal.
Do we need a sub-section under Clinician > Chart information for Health staff > Down Syndrome charts?
Many thanks,
It sounds like the UKCA mark is going to be phased out in favour of keeping the recognition of the Conformité Europeénne (CE) mark. At present we have a MHRA-registered medical device which is UKCA marked but we should look to add CE marking to this ASAP and document as such.
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.
Might make contact info easier to find if we put it on the main navigation bar
ositowfm
bpac/rc3.0
direct links to whypython etc
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
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?)
As per all our repos we are gradually moving to a live
staging
dev
setup.
In this case we are building the live docs site off live
to GH pages
If we need a build for viewing and testing staging
or dev
then we can do this with Netlify quite easily
This shortcoming of the documentation identified in the chart component repo issues.
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.
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
iframe
constraints to fit without needing a scroll barAs 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
digital-growth-charts-documentation/docs/about/team.md
Lines 16 to 17 in 6881d61
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.
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
Are these definitions meant to be completed?
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
If the API does not respond then centile measurements will be unavailable
No response from the API would mean no growth chart calculation values and no graphical growth charts
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.
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.
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'
NHS Wales have developed User Journeys for their implementation, which we may be able to obtain and modify for our needs.
please fix asap
Some notes for when doing next review of the docs site:
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.
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.
An aberrant implementation could return erroneous data to clinicians.
The erroneous data returned could mislead clinicians in their management of a patient, leading to suboptimal care.
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.
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'
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.
documentation/
folder.scripts
folder and s/up
, s/down
scripts as neededdocumentation
folder. This needs to be done with care because THIS IS A LIVE DOCS/DEMO SITE FOR DGC# TODO: Update NHS.UK cBMI Calculator link
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
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.
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.
As with most of the Growth Chart Hazards, the potential problem is that a child either:
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.
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'
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
@magdaumerska please attache the updated one here and I will add it to the site
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
@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.
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.
"To provide high quality, usable, clinically safe digital growth charts for all clinician users in the UK"
Code: https://github.com/rcpch/digital-growth-charts-server
The API could return incorrect centile data.
The user would be presented with an incorrect set of centile data.
The hazard is that an inappropriate clinical decision could be made on the basis of this incorrect centile data.
Harm could result from the incorrect data not being recognised as such, and
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'
@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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.