Adding FHIR format for the API response

Growth Charts
1

Hello Drs. Baw, Chapman, and the RCPCH Digital Growth Charts project!

I am a fellow pediatrician and would like to help add a FHIR API endpoint as discussed here. I’ve begun to learn the FHIR spec, and have a local copy of the RCPCH API running in Docker.

As I become more familiar with your project and FHIR, I thought I’d introduce myself and inquire about any thoughts you have about implementation.

My goals are to:

  • Produce useful code that is worth merging into production
  • Support both the UK Core and USCDI.

I hope that adopting a standard like FHIR will facilitate global adoption of this code, for the benefit of children everywhere.

When I have something more specific to share, I’ll do so via a pull request.

Looking forward to talking more. All the best from the U.S.

Matt

2

The backend api and exchanging of observation data (from PHR to EHR) may be a topic on

https://digitalhealthrewired.com/rewired-hack-day/

The suggested methods of querying data would likely be the Observation option from here https://wiki.ihe.net/index.php/Query_for_Existing_Data_for_Mobile_(QEDm) [HL7 UK may call this UKCore FHIR Access API]

The PHR/Device to EHR suggestion would be https://wiki.ihe.net/index.php/Personal_Health_Device_Observation_Upload

Examples and notes on Observation data https://simplifier.net/guide/clinicalobservations/introduction?version=current

3

I would see this as splitting out the source data away from the growth chart app.

If community suppliers expose the growth chart data via QEDM api then thats how this app accesses the data.
The alternative is for this app to have a duplicate copy of the observations and data is fed into this copy via something like the PHR Observation upload

Technical community is likely to prefer the former option (we shouldn’t be creating copies of data but sharing it instead). Most systems in the UK which are using FHIR are believed to have gone for the sharing option. The moving data from A->B is still (and likely to remain) HL7 v2 ORU_R01 Unsolicited Observation message

4

We probably need to clarify the terms being used here because we are not making or selling a growth charts App.

  • We have a REST API which is the service we sell, it is a REST wrapper around some complex calculations that are exceedingly hard to implement correctly. Suppliers of clinical systems can then use this API to get accurate growth calculations without any additional work other than a REST call. Documentation is at dGC API Server - RCPCH Digital Growth Charts

  • We have a demo client which is not for clinical use here https://growth.rcpch.ac.uk/

  • We have a React.js component which reduces the work involved in displaying a graph of the growth parameters returned from the API. React Chart Component - RCPCH Digital Growth Charts

Splitting out the source data from the end user’s (Supplier) application is therefore already done - the API is decoupled entirely from the display element but we have provided a reference web UI display element for people to either use or base their own solution on.

The low-level data source which the API uses is called an LMS table, it is owned by RCPCH and it is very hard to grasp without clinical and statistical understanding. Prof Tim Cole, who originally developed these tables, was in the development team and did all the testing for us. (us being @pacharanero and @eatyourpeas)

However the data tables are here if you want to look growth-references/uk-who at main · rcpch/growth-references · GitHub

5

Thanks for your interest in contributing! Really happy have other clinicians and coders (and those special people who are both!) involved. There is also another offer of help in the related Issue, and I know @mayfield.g.kev personally, he’s very experienced and knowledgeable in FHIR.

In terms of adding FHIR, we are all in agreement that it is a nice additional feature and certainly does help with wider adoption. Internationalising the API will be a significant piece of work as it was designed and built quite rapidly by a very small team, with the target market being the UK only.

I was thinking we would probably continue to serve the existing ‘simple’ response, without the FHIR wrapper, at

https://api.rcpch.ac.uk/growth/v1/uk-who/... and add an additional path to the FHIR-wrapped version at something like:

https://api.rcpch.ac.uk/growth/fhir-v1/uk-who/ which has the advantage of clearly separating the endpoints.

Alternatively we could use the Accept: request header value of application/fhir+json which is possibly the FHIR industry accepted way to negotiate the response content type? Http - FHIR v4.3.0

The presence of the Accept: application/fhir+json header would cause the API to return the calculations wrapped in a FHIR Observation object

Views?

6

To be a legit FHIR interface the url has to end in the name of one of the FHIR resources, unless it is a whole server oriented operation.

So that means something like {anything}/Patient or {anything}/Observation. However you can add on ids, query parameters, and operation names on the end of those resource names e.g. {anything}/Patient/1234/$growth-chart

It probably cannot just work solely via the mime type, without a FHIR specific part of the url.

But I am not clear if the data is patient oriented or if it is non-patient specific reference data (tables).

If the latter then it could be whole server oriented operation perhaps, and you can then use any url as the base - though that would imply you wanted to fetch all the FHIR data on the entire server (and maybe you do).

Or is it a service that provides graphing/analysis on top of existing data? In which case it needs to consume FHIR rather than write it maybe.

7

@pacharanero: Thanks, happy and inspired to have the opportunity to try to contribute to an open-source project with such evident clinical utility – and to meet a fellow physician coder who has shipped code that’s out in the world for people like me to use, learn from, and contribute to.

It’s clear to me that this project’s mission places children’s well-being front and center. Would be happy to share more about my interest in the project down the road. Suffice to say, the accuracy of proprietary growth chart implementations varies, which is a completely predictable consequence of the extraordinary difficulty of getting the core logic right.

I share your vision of getting the fundamentals right, and allowing others to leverage this project’s accurate and reliable calculations in their own growth chart product, and stop trying to re-invent the wheel.

Thank you also @mayfield.g.kev and @riksmithies for your commentary and insights. As a someone who is new to FHIR and APIs, I welcome insights and the opportunity to collaborate with people with technical expertise.

FHIR Also Supports Extended Operations

I think it would be helpful to clarify how I think FHIR would integrate with the RCPCH API, which differs from the typical FHIR use case. Most discussions around FHIR focus on facilitating the exchange of patient-specific information via Create, Read, Update, Delete (CRUD) operations.

However, as you know, the RCPCH API doesn’t exchange patient information. Rather, it puts a child’s growth measures in context by comparing them with those of their peers. By design, it does not receive or store identifiable patient data.

This makes the Extended Operations resource, (“operations”), rather than CRUD interactions on patient and observation resources, a better foundation for a FHIR endpoint.

The purpose of the RCPCH API’s “calculation” endpoints is aptly described by FHIR’s Extended Operation: a remote procedure-style call (RPC) in which the server formulates the response’s content.

The Evaluate Measure

Specifically, I think the Evaluate Measure operation, which takes parameters and returns a MeasureReport, is well-suited to our use case, which does not entail the exchange of information per se, but rather putting it in context.

The Observation resource is another good option, which would have the benefit of being a simpler and more mature FHIR resource than MeasureReport. One potential downside I see of using Observation is that it may require more work to define other custom FHIR resources, like the FHIR operation that would define the transformation from the input parameters to the output Observation. There is also the risk that the more custom FHIR resources we define, the more friction for interoperability we create.

API Endpoint Style

@pacharenero, I agree it would be best to introduce the FHIR endpoint as an option alongside the existing ‘simple’ response. The FHIR style guide calls for following a [base URI]/[resource type]/[type interactions] template, which differs from the {reference growth chart}/calculation} the ‘simple’ API uses.

I think this new endpoint could look something like:

http://api.rcpch.ac.uk/growth/v1/fhir/R4B/Measure/{standardized_measure}/$evaluate-measure

where {standardized_measure} is the centile/standard deviation score for weight, height, occipitofrontal circumference, and BMI, respectively.

Although I included R4B following the lead of FHIR test servers like hapi.fhir.org and server.fire.ly which support running different versions on different endpoints, this forward-compatibility may be excessive for an alpha version of the API.

@pacharenero, as you have mentioned, the {standardized measures} could be encoded as a codeable concept which references multiple codings like SNOMED CT, Read Version 2, and perhaps LOINC (although I’m not sure this system has all the measures we need).

I generally favor following expected FHIR convention as much as possible, although I also want to be sensitive to the multiple other considerations about how this extension would fit into the larger project which likely exist, and of which I am unaware.

What do you think? I think the main points of discussion at this point include:

  1. The format of the URI which hosts the FHIR API endpoint
  2. The FHIR resources which should form the basis of the API
  3. In particular, should the API return a MeasureReport or an Observation?
8

I assume this would operate on an individual patient, and compare their measurements with the standard set and return an evaluation (e.g. a single centile). Is that it?

For it to work as $evaluate-measure I believe it can only be called on a Measure resource. So the data and rules would need to be expressed as a Measure resource. I am not sure if Measure can be used for this - it’s possible that it could.

If you just want some data that is not exposed directly but is only used in the calculation, then an operation on patient would be needed I think.

So I would expect a custom operation on Patient, that returns an Observation with a simple value.

That implies the patient data is on the server though. If not, then it may want a custom operation on the server in general (not a Patient specific endpoint), that takes a series of parameters, and returns an Observation.

The FHIR server purely acts as a calculator, not a data store (however it would still be seeing patient data, but without identifiers).

Presumably not news, but there is also an existing open source FHIR Growth Chart application that may be of interest to see how it works.
https://apps.smarthealthit.org/app/growth-chart
http://docs.smarthealthit.org/tutorials/server-quick-start/

It’s UI oriented rather than a calculation service.

9

I’m hoping to have a demo/test EHR server available in the next few weeks (hopefully its official NHS UK).

It’s likely to be populated with paediatric observations for a Rewired Hackathon in March https://digitalhealthrewired.com/

So this could be extended to include other child obs (I would need test data to load into the server).

It will provide a FHIR API for you to call and retrieve the data for your measurements in FHIR R4 UKCore format
This will be very similar to the API the smarthealthit uses (Rik mentions this above)

10

I’m hoping use cases around retrieving observations and uploading them (from device or PHR to EHR/NHS) will feature in the hack.

I think you also have these use cases (before the actual calculation)

11

Yeah this app is excellent UX and it’s been around a while, I’m sure Ian McNicoll first pointed it out to me and that has to be about 7-8 years ago. But that app uses the CDC data references to calculate centiles and SDS and therefore is only applicable to the US. To some extent the reference data in the backend can be switched for UK data, but the data formats internationally are not all identical, some are completely different and would require a complete backend API rewrite.

@riksmithies and @mayfield.g.kev thanks for the advice on how best to represent the API correctly and ‘idiomatically’ in the FHIR world. We will definitely take all this into account when we do put the API behind a FHIR façade. However at the moment none of our customers have asked for FHIR because I suspect they don’t as yet have a requirement to consume FHIR.

I’ll be at Rewired Kev, I will see if I can attend the hackathon. (I’m not running the Rewired Hackathons these days)

12

Recommend being careful around is/isn’t FHIR part of this conversation.
It can become cart before the horse.

We’re really talking about getting data to you calculation and what data needs to be output.

For me to store calculations in an EHR I’d need extra information on your measures, e.g. SNOMED/LOINC codes, units for the measurements. (<- this is the most important bit for me, I’d rather this was supplied rather than me having to add it in or work it out)

Once we have that, then I would say HL7 FHIR Observation or HL7 v2 ORU_R01 Unsolicited Observation is a suitable format.

13

I wanted to take a moment to thank everyone for their responses on this topic.

If I understand correctly, while a FHIR facade may be useful in the future, it’s not something customers presently expect. A FHIR Observation resource or an HL7 v2 ORU_R01 Unsolicited Observation are both suitable choices for conveying standardized measures and the relevant context, which includes the appropriate SNOMED or LOINC code.

Are there other ways in which I could become involved? Perhaps documentation communicating with a clinical audience, or helping with this issue (raising an error if observation date precedes birthdate).

I may also create a demo FHIR endpoint along the lines of what I’ve described above as a means for me to become more familiar with FHIR, and will keep you updated via this thread if I publish something interactive.

Please also let me know if creating a FHIR endpoint is something that customers begin to express an interest in the future.

Thank you for the invitation to the Rewired Hackathon. Although it’s too far away for me to make the journey this time around, I hope I can make it in the future at some point. If this topic comes up at the Hackathon, please keep me in the loop.

I think this community is fantastic, and am glad that there is a community of people who are creating open tools and standards for medical use. This is meaningful work, and I remain interested in contributing.

14

Thanks Matthew that is really helpful. I don’t think the observation preceding birthdate is an issue anymore. I think our error handling now picks this up.
I think the FHIR issues is still relevant. Whilst no one has asked for this I think it is only a matter of time and an implementation of this I think would be helpful. If you are interested in having a look at this what other help would you need from me and Marcus?

15

Hi Simon, I am interested, and am endeavoring to carve out some time to work on this.

For now, all I’d ask from you and Marcus is to be available as a sounding board for questions, and to review and give feedback on the code I write.

I’ll work on creating a FHIR endpoint for, say, weight observations, and check back in via this forum once I’ve created something functional, or have gotten stuck and need help.

How does that sound?

16

Hi just checking in to make sure you are still happy doing this? Very happy to help/answer any questions you have. Let me know if you have any code on GitHub you want to review- thanks again for doing this.