Are there ways to query FHIR servers for aggregated data?
I know we can search for all blood pressure results between two dates for a patient. But what if we wanted the average blood pressure by month?
Thatâs not really what FHIR itself is for. Itâs a way to access data, not so much a way to do calculations on it.
It canât do averages, as it stands, but it is possible to extend FHIR with custom operations and search parameters. That would allow FHIR to directly do this (though someone has to code it, of course).
But this is more the job of the next layer of application. There are general purpose analysis tools like âR on FHIRâ. Or a user interface built on top of FHIR may do averages and graphing etc etc.
Most (non-technical) users wonât ever see âraw FHIRâ or the raw query interface.
Rik
1 Like
Hi Rik
That was my understanding too.
I am currently working on a layer that PHR apps can connect to access FHIR data that has a simpler interface and that can provide aggregated data and other useful stuff like cloud function triggers.
I think there are some who think the individual PHR apps will connect directly to FHIR Servers which makes no sense IMO. Rather they will connect to their own API Backends that will query FHIR Servers.
I was just making sure there wasnât some magic spec I was missing for these kind of aggregated data scenarios.
Many thanks
Matt
Echo Riks comments, it is upto the client to calculate that average.
If the system has calculated/recorded it (using relevant code e.g. Average blood pressure) it could be queried.
Hi Kev
Thanks for the link. I think this raises an interesting question about what the expectations about this should be and where they should be documented.
I can imagine only wanting PHRs to provide Average scores rather than flood care records with individual data points. But that can lose context.
I wonder if these are conversations that are really happening yet?
Some conversations are occurring and they seemed to be centred on a NHS view of the problem ⊠and that seems to be centred around putting all the data into a big shared database.
(Not clear on the use cases but often it sounds like putting all the data in a local NHS+social care into a database to share with the patient)
That probably does make sense.
I think all the rich data should be persisted somewhere - even if patients are live streaming from their strava or glucose monitor. Then snapshots can be created that might appear as a PHR Summary doc before an appointment.
Thatâs the approach adopted by NHS Scotland via the National digital platform, albeit using a openEHR CDR (or I suspect federated CDRs over time) with FHIR facades where that makes sense but likely to be a multi-api approach, openEHR, FHIR or custom, depending on utility, speed of deployment, market adoption of CC profiles etc. Mixed economy. And this is intended as a primary source-of-truth not a data lake or HIE.
And yes an openEHR CDR does allow you to do that kind of population querying out of the box, via AQL ,or indeed federated querying as they are doing in the NTGMC !00k Genomes project.
@Matt_Bourne - there is a tricky challenge re the potential flood of patient-recorded datapoints. My view is though, at some point, if it is going to be clinically actionable, it has to come inside a properly managed EHR or a coPHR - with adit trail, version control etc. Outside that , yes interesting work needs to be done on collapsing âboringâ data so that only potentially interesting signals get commited. Average, average, Wow!!
1 Like
I feel weâve got two things going on here:
- Personnel Health Record (PHR)
- Patient Held/Health Record
Yes, the PHR wonât be fully trusted by clinicians (or looked at) but itâs not for clinicians, itâs for the person.
Progress on the former is always going to be more rapid and widespread that the PatientHR. In agile terms PHR is greenfield development and PatientHR is at most brown field. The PHR already is REST, JSON and OAuth2 (controlled by the person, like other sectors) and integrates with wearables. [I know more people sharing PHR data with insurance providers than NHS - this may be a developer, middle aged and/or cyclist thing 
]
Hi Matt
The FHIR standard does include provision for a number of statistical functions on Observations - take a look at Observation - FHIR v3.0.1
It does of course require that the FHIR server that you use to have implemented these operations.
1 Like
What happens with aggregation operations when the observation value is not numeric?
Itâs not explicit but I would suspect that returning an OperationOutcome with a suitable error message would be sensible.
Hi Richard
Many thanks for this.
Anyone know if this is likely to become normative?
I am trying to use operators such as $stats and $everything and none seem to be supported below:
https://data.developer.nhs.uk/ccri-fhir/STU3/
Is there a way to see what operators are supported?
It does not seem to show here:
Itâs not supported.
The idea was that frequently requested operations and queries would be added to the Care Connect Api and also this sandbox.
I donât know the current status of care connect api within NHS D or X
but yes /metadata is the way to see those. If they are not there they are not supported by that server.
You can see âeverythingâ here:
http://hapi.fhir.org/baseR4/metadata
Even if ânormativeâ they would still be optional.
Do people want a minimum standard?
Or groups of resources as conformance standards. So if you had a PAS system you would be able to say to support the PAS pack (Patient, practitioner, encounter, episodeofcare, referralrequest, appointment)?
You could have packs for EPR, EDMS,LIS,RIS,etc.
Yes absolutely.
They want a platform specification, that defines how all the data structures (resources) and interfaces work.
Most of that is optional for any given context, so there is minimum burden on any implementer.
Then a next layer of profiles of those resources and building up to implementation guides that describe in detail how the platform handles those domains you list.