Stream: implementers
Topic: Implementation of "totals" or "counts" in FHIR
Katie Wheatley (Mar 02 2021 at 10:40):
We have a requirement to implement two count of record totals. Currently the only way which we have considered doing this is by adding two extensions to our models (although we are still in the process of considering which resource we should extend). I attach two possible design options. I would really appreciate advice on
- Which of the designs attached appears the best of the two.
- Are there any generic ways in FHIR which can be used to model a total or count which I may not be aware of ?
Many thanks in advance for assistance with this.
CP-IS-DesignOptions1.jpg
CP-IS-DesignOptions2.jpg
René Spronk (Mar 02 2021 at 14:07):
To me count is relevant 'upon disclosure' / 'upon communication', so Bundle (which already has a total data element), or perhaps AuditEvent (if you're not using a bundle) would be the best candidates for an extension.
Lloyd McKenzie (Mar 02 2021 at 14:50):
Can you explain more about what the total covers?
Katie Wheatley (Mar 03 2021 at 13:14):
Lloyd McKenzie said:
Can you explain more about what the total covers?
The totals cover the total returned records (data aggregated from the AuditEvent(s)) and the total returned CarePlans (data aggregated from the CarePlans returned) for a given patient NHS number parameter.
The background is that a Care professional is querying a relevant database by Patient NHS number to determine a) who has previously queried the database for this NHS number b) how many CarePlans exist (with or without end dates) for the specified NHS number.
Michele Mottini (Mar 03 2021 at 14:00):
If those can be expressed as searches (as they seem) you can simply use _summary=count
Michele Mottini (Mar 03 2021 at 14:02):
(https://www.hl7.org/fhir/search.html#summary-count)
Lloyd McKenzie (Mar 03 2021 at 14:45):
Agree. The first sounds like a search against AuditEvent - returning a count. This wouldn't generally be a persisted value because it would be continuously changing. The latter would be a search against CarePlan. Those wouldn't change as often, but they'd still be dynamic.
Kevin Mayfield (Mar 03 2021 at 15:27):
The focus of the search should be CarePlan, so total would be number of CarePlan's returned. We have a requirement to also return number of AuditEvents (counting them or a seperate API would be our preferred approach BUT.........)
Last updated: Apr 12 2022 at 19:14 UTC
