Stream: implementers
Topic: Group: Get With Filtered Members
Erik Greif (Oct 24 2018 at 17:10):
My team and I are exposing the FHIR Group as a REST service, where we have been able to satisfy most of our needs in a fully FHIR-compliant manner. We have found some difficulty satisfying our requirement to GET a Group and filter the member list based on criteria about the relationships, which are BackboneElement type. We need to page results as well, given that one group could have tens or hundreds of thousands of member entries, and a UI may need to expose these.
Examples of filter criteria:
- if period will expire within some unit of time
- if the given time is within the period
- if currently active or not
- truncate to a given offset (front truncation, page start)
- truncate to a given maximum count (rear truncation, page size)
We were also looking at the Operation-group-everything, but this is not an official type, and doesn't offer all of the filters we require above.
http://hl7.org/fhir/2018May/operation-group-everything.html
However, it does mention something indirectly: "The key differences between this operation and simply searching the group's patients compartment are..." which implies there is a way to "[search] the group's patients compartment," which may refer to the member list. We have been unable to identify how this is done from a fully-FHIR-compliant REST API.
We welcome all input on this topic, as our ability to solve this problem will ultimately decide whether we implement a custom or FHIR-compliant service, and I am very much advocating for the latter.
Lloyd McKenzie (Oct 25 2018 at 03:56):
To do something like that, you'd need to define an Operation - essentially generating an anonymous or non-identified Group instance that represents the filtered view. The 'read' and 'search' operations have to return the resource as it is. They can filter to only show certain data elements or constrain data based on permissions, but they can't transform the content of the resource.
Erik Greif (Oct 26 2018 at 16:29):
That is a great suggestion... I have posed it to my team, and we will see if that works. In my eyes, I see one custom operation as a "more compliant" solution than adding a custom resource with all custom operations. Thank you!
Last updated: Apr 12 2022 at 19:14 UTC
