Frequently Asked Questions

Q: The dGC API Server is open source, so should I be self-hosting it?

A: No. In general, people should not be self hosting the API server. Only the version deployed and managed by the RCPCH team is warranted to be correct. If you are running the code on your own server then you must be prepared to have the appropriate clinical and technical assurance performed. You would require MHRA registration for your medical device. By using the RCPCH-provided API you avoid all that requirement and use our commodity server.

Q: Where is all your dGC code?

A: All the code for all our Digital Growth Chart work is publicly available on GitHub.

Integrators who have a web-based stack may wish to use the React component, or to study it in order to make their own implementation process easier. We may also be able to assist in developing components for other JavaScript frameworks or other non-web-based languages - please contact @pacharanero to discuss or email for further information.

Q: Why did you build the API in Python?

A: It’s a well-used, stable language, which has a good scientific and research user-base. It’s also accessible to relatively new coders (eg clinicians) who might want to help contribute to the project.

Q: Is entering a gestation age mandatory? from a DPCHR implementer perspective, if a birth notification has not flowed into the DPCHR, suppliers will need to require parents to enter it.

A: Gestational age is not mandatory. If it is not supplied then the child will be assumed to be born at term (ie between 37 and 42 weeks) and for the UK-WHO charts, the standard term references will be used for calculations and charts.

Q: Is corrected gestational age passed back by the API, or do implementers have to calculate it?

A: Yes, corrected age is passed back by the API, if a gestational age is included in the request.

The API can only correct for gestational age if a gestational age has been supplied.

This correction is applied up to the corrected age of 1 year for preterm children born above 32 weeks, and to the corrected age of 2 years for preterm children born below 32 weeks, which is accepted standard practice among paediatricians.

Q: Does my application need to validate inputs?

A: The API has validation and error handling for out-of-range requests, but it is good practice for the front-end software to also reject input values that are out of range since this feedback can be shown to the user, by the application.

Q: Is there a source from where we can get a list of extreme input values to use for our validation?

A: Yes, we have included one in our source code: Validation Constants . This is what is used internally to validate API inputs and also used by the internal rcpchgrowth Python module to validate inputs to the Measurement class.

Q: If we have a calculated centile or SDS from the API then why do we need the traditional ‘curved-lines’ growth charts at all?

A: Good question. Maybe, in time, this style of chart will no longer be needed.

The traditional growth charts were actually a form of paper calculator for the centile values. You plotted the age and the height/weight data and you then looked for which centile lines it was between, and this was the read-off data.

The Growth Charts API obviates the need for this step since we calculate the centiles for you. However, another important function of the chart was to visualise trends in the growth. Our API does not do this, so there will be a need for some form of chart to visualise the trend.

Initially we expect that clinical users will want to see the traditional growth chart, out of simple familiarity. But in time we think that researchers may develop better visualisations of the trend in centiles/SDS that don’t have to come on such confusing curvy charts. The future of displaying growth trends is entirely open to new ideas and innovation.

Q: Would it be good enough to plot the returned centile values on a pre-prepared image of a growth chart?

A: Maybe. It would depend on the implementation.

Images of charts are definitely not good enough for calculating a centile from, although many GP software packages do it this way, it’s poor practice and it’s why the API needed to exist in the first place. BUT, since we are calculating the centiles for you, then the chart is only for displaying the trend. An image could be used, but we would advise against it generally.

The problem with images is that it is very easy to accidentally have an offset or scaling error that means that some plotted points are in the right place, and some are not. Best practice is always to use the same vector graphic tooling to both construct the lines and plot the points, to avoid offsets/scaling inaccuracy. If you are using an image (please don’t) then you must ensure you’re selecting the correct one for the data you’re presenting, and that the scaling and offset is not just programmed to be correct, but clinically tested to be correct!

What development effort is required to integrate this API into an app or Electronic Patient Record?

1 Like

Minimal development is required. The tricky stuff (calculating centiles from complex statistical tables, selecting the correct UK90 or WHO references for age, and gestational age correction) is all done for you. The data returned will be the correct centiles, which can be displayed to the user.

Producing a visual ‘growth chart’ with this data on is a little more involved, however we have tried to make the process as easy as possible by building API endpoints which return the coordinate data from which to build the chart lines, and also we’ve made an open source library which takes that source data and makes a chart for you. It’s built in React and is MIT licensed, but if you are using another technology then you can inspect the source and use that to build your own client.

We are keen to build a ‘catalogue’ of chart clients so other open source clients are very welcome and we will help you build and test them!

1 Like