Centile Part 3 - Work That's Been Done


(Marcus Baw) #1

It’s about a year since my last article about Child Health and centile calculations/persistence.

Let’s solve this problem

In some ways the NHS’ IT infrastructure is so fundamentally broken that banging on about centiles all the time has seemed almost pointless, given that perspective. I’ve been busy with various other things, but my attention has been brought back around to centiles because of a chance conversation with Rachel Pryke, another GP who has been working hard on exactly the same problem, who has put me in contact with a number of other clinicians trying to solve this problem. Knowing that there are others trying to fix this serious issue has given me the motivation to pick up where I left off.

Sharing information

Fundamental to us solving the problem of delivering fit-for-purpose child health monitoring tools to all frontline clinicians involved in child health, is open sharing of information about the current status of our work. There’s so much good work going on in health technology, that is hidden from others because of the default use of direct emails for all communication between, when this is not confidential we have a #publicduty to share the state of progress. It enables interested others to join in solving the problem, ensures openness, and enables scrutiny of statutory bodies who are not doing their public a good enough service.

Centile software I’m aware of - a curated, and as yet non-exhaustive list

  • eRedBook - this is being developed by SiteKit Ltd and is reportedly funded by the NHS.

  • It is not being developed as open source, which means there is a risk of SiteKit using public funds to develop the solution, and then charging astronomically for the NHS to use it. From what I have heard of the proposed pricing policy (£5 per child per year, from 0-5 years, for 700,000 children) this is the stated intention.

  • Since it’s a closed platform, we can’t inspect the source code, and since I don’t have access to the web platform, I have only verbal anecdotal reports that it can calculate a Height/Weight/BMI Centile. If anyone can confirm/refute whether it can indeed calculate and persist/track trends in centiles, that would be helpful.

  • I have no evidence that there is any capability for the eRedbook to integrate with any existing clinical systems. If the eRedbook cannot interface with EMIS Web and TPP SystmOne, the two most common GP clinical systems, then this renders it useless as a professional clinical tool for managing child growth.

  • King’s College Hospital eGrowth Charts - Developed by Dr Jack Barker and Dr Simon Chapman of KCL, this is a series of T-SQL database tables and methods, and is integrated with the clinical EPR at KCL. I’m not aware of any other implementations in the NHS, although the software is open source so there is potential for this to be done.

  • Growth Charts UK - a free app developed for iOS and Android by Paediatrics.co.uk - it calculates centiles and uses the correct UK90 tables. It was developed by Chris Kelly of http://incubate.co.uk/, although I can’t find any source code or any links to further information about the app apart from what’s on http://paediatrics.co.uk. The app was announced in this long-running thread about centiles, on the NHS Hack Day google group

  • ruby gem - this is a library of code for the Ruby programming language (in Ruby, libraries are somewhat cutely called ‘gems’). I have been developing it in various forms for a few years, having extracted it from previous versions of centile calculation code I’ve worked on. I’ve made it into a gem, which is published on rubygems.org, in order to make it easier to deploy as a centile web service (coming soon)

  • node.js module - written and maintained by @eatyourpeas (Dr Simon Chapman), this is an open source implementation of code which calculates Z-scores and centiles for height, weight, BMI and blood pressure.

  • python centile code - written by Paul Rubenstein and myself, this was a no-frills proof-of-concept implementation of centile calculation code, now a little old, but probably still working. Untested with recent Python versions though.

  • clinical calculator & Obesity Data Prize 2015 - the clinical calculator API was a 5-day hack project created during Young Rewired State 2015, and was an attempt to generalise the problem of wrapping complex clinical parameter calculation in a service API, to make it easier for developers. We won the Obesity Data Prize 2015 for this work, but unfortunately there was no further interest from Public Health England or NHS England, and we were unable to pursue the idea further. [further info]

  • SMART-on-FHIR centile calculation UIs - these are a collection of re-usable clinical User Interfaces (UIs) which have been designed to ‘slot in’ to a standard connector in an Electronic Patient Record (EPR) - the connector is called SMART and the interface technology is called FHIR (Fast Healthcare Interoperability Resource), hence SMART-on-FHIR. The quality and polish of the graphics is amazing, however in the UK there are no vendors of EPRs who are including a SMART interface, so it’s not presently possible to utilise this great work.

There’s also a huge amount of work that’s been done, not in the ‘coding’ area of this problem, but in the political, clinical, and organisational areas - and I’ll come to that in Centile Part 4 - hopefully it won’t take me another year to write it!

Marcus


Centile Part 2 - What's the Problem?
(Kev Mayfield) #2

Surely you need demand before vendors supply SMART (SMART deals with the authorisation and permissions to access data it doesn’t provide an interface to the data)

eRed Book should be able to use GP Connect when it is available and I believe Cerner is intends to provide acute equivalent as part of CareConnect/InterOpen (I’d assume Cerner would also include SMART). I’m assuming a bit here, do these apps have a common set of data requirements? Common set of data requirement leads to a common interface requirement and eventually common consent/auth model (e.g. SMART)


(Ben McAlister) #3

Hi Marcus/Kevin,

Cerner does support SMART and FHIR and the Boston Children’s Hospital Growth Chart App https://code.cerner.com/app/pediatric-growth-chart and has made a number of contributions to the App that have been merged https://github.com/cerner/growth-chart-app. We are just now looking to start deployment of SMART and FHIR in the UK. Cerner’s FHIR API, http://fhir.cerner.com/millennium/dstu2/ is currently based on the Argonaut Implementation Guide http://www.fhir.org/guides/argonaut/r2/ We are engaged with development of the proposed INTEROPen CareConnect API Implementation Guide through INTEROPen https://nhsconnect.github.io/CareConnectAPI/index.html http://www.interopen.org/candidate-profiles/care-connect/ and are targeting support for. In the meantime our as is FHIR API can be used. Once CareConnect is introduced, depending on alignment with the Argonaut Profiles some tweaks to existing Apps may be required.


(Marcus Baw) #4

But surely you need vendors to supply SMART on FHIR before there can BE demand?

‘There’s just no demand for it, sorry’ is something they say in small shops, not a supposedly innovative industry. There was no actual ‘demand’ for the iPod, the motor car, Amazon Web Services, and lots of other new ideas - until they existed. Then there was lots of demand.


(Marcus Baw) #5

I agree with you @mayfield.g.kev, but, the above sentence contains two conditional clauses, and it’s those that make me uncomfortable.

  • eRed Book should be able to use GP Connect - yes, but WILL it? There is a considerable business incentive to hang on to the data, and no clear contractual mechanism to enforce sharing of the data. I’m not sure if SiteKit are part of InterOPEN…

  • GP Connect when it is available - GP Connect has already hit something of a brick wall in trying to convince a certain supplier that a HTML view is not a proper API. And even with the other vendors, there is considerable work to do to get true bidirectional and standard interfaces.

I’m not disagreeing with you - I have hope that both conditionals will work out the way we want them to, and all will be well. But historically this has not usually been the case…

Marcus


(Kev Mayfield) #6

I’ll take the fifth on that, I’ve heard it several times. :cold_sweat:

Great to hear about Cerner CareConnect though. The CareConnect profiles should be appearing on this FHIR Reference server soon https://fhir.nhs.uk/


(Kev Mayfield) #7

As Ben mentioned take a look at CareConnect. It is a structured API - https://nhsconnect.github.io/CareConnectAPI/restfulapis_clinical_observation.html

Would weight/height/BMI examples be useful?


(Kev Mayfield) #8

I’m about to work on a developer HOWTO guide for clinical data (CareConnect) and I’m looking to base it around a scenario. I’ve worked on NHS Scotland Child Health Systems Programme CHSP (and related work in England with community) in the past so initial thoughts are to base it on data collected in this form: http://www.isdscotland.org/Health-Topics/Child-Health/Child-Health-Programme/Primary1_Assessment.pdf

So how to obtain height, weight, BMI’s and visual acuity from a system and also diagnosis/problems - nothing complicated. Getting patient demographics or looking patients is a work in progress but early view is here https://care-connect-api.netlify.com/design_patient_search.html
An example for getting immunizations is listed here https://care-connect-api.netlify.com/restfulapis_clinical_immunization.html (this example is based on work I did 20 years ago with a GP supplier :slight_smile: )

Understand this isn’t getting data from a GP system but hopefully would show how an app would get child health data from a community, mental health and acute system. (Don’t know timescales but the API is based on work that’s already been or being implemented)

Thoughts?


(Marcus Baw) #9

@mayfield.g.kev what you’re suggesting sounds really helpful and useful - thanks - look forward to reading it.

On a related, but separate note, I’m closely involved in the NHS Digital Healthy Child Events Programme work, which is building a pub/sub model for the various Child Health Events - the system works thus: a care-giver who, for example, measures a child’s height/weight/BMI & centiles will ‘publish’ that Event. Other organisations with a care-giving relationship to that child will ‘subscribe’ to receive those events, which can then be displayed natively in the receiving system.

How does the implementation of Healthy Child Events fit in with CareConnect?


(Kev Mayfield) #10

It’s a good point, it is related and the difference is with the use cases.

Child Health events is using pub/sub that could be used to send child health data from maternity/national screening programmes to child health or gp systems https://nhsconnect.github.io/Digital-Child-Health/Generated/Chapter.3.Architecture/Events.png

CareConnectAPI allows access to the same data (using Request/Response pattern instead of pub/sub), which would be useful if you’ve not subscribed to the events or you have an (web/mobile) app that wants to use child health data held in the original or subscribed systems. Looking at Measurement.Events to get the weight you would do a CareConnectAPI query like (for birth weight)

GET [baseUrl]/Observation?patient.identifier=https://fhir.nhs.uk/Id/nhs-number|(jonny NHS Number)&code=http://snomed.info/sct|27113001

or possibly (for weight)

GET [baseUrl]/Observation?patient.identifier=https://fhir.nhs.uk/Id/nhs-number|(jonny NHS Number)&code=http://snomed.info/sct|363808001
(code is a

The response would contain the same Observation in this example:

https://nhsconnect.github.io/Digital-Child-Health/Generated/Examples/Profile.MeasurementsEvent/MeasurementsEvent-1YearReview-Scenario1.xml


(Kev Mayfield) #11

Just noticed the last link is wrong for weight. A working demonstration:

https://purple.testlab.nhs.uk/careconnect-ri/STU3/Observation?code=27113001,364589006

to restrict to a specific patient add in patient={id} e.g.

https://purple.testlab.nhs.uk/careconnect-ri/STU3/Observation?code=27113001,364589006&patient=1176

(This is simulating a system that has received a DCH message)