Stream: implementers
Topic: Getting a subset of a resource - how to?
Allan Bro Hansen (Sep 26 2016 at 10:44):
Hi
We have modeled an Appointment with standard CRUD operations.
Now we are faced with the following customer-request: "Please let us read the appointment and its managing organization at a patient with some specific search criteria but let us only get a small subset of the attributes at the appointment and the organization".
I see 2 different FHIR-solutions for this:
1) Use the existing FHIR-resources and define a namedQuery for Appointment which defines 1) the search criteria, 2) to include organization, 3) which attributes to be returned for both appointment and org.
The attributes of the appointment will be minimal (even without mandatory attributes). This removal of attributes for the appointment corresponds to the elements-search (https://www.hl7.org/fhir/search.html#elements), but it goes against the should-recommendation for mandatory attributes. The removal of attributes of the related organization is (as far as I can see) currently not supported via a normal search.
2) Create new resources for the Appointment and Organization - Appointment2 and Organization2 (for this issue we could give them meaningful names). Only GET-operations will be supported for these resources. The resources will basically be new domain resources as we will not include mandatory attributes from Appointment.
A search for Appointment2 at a patient could include the special search criteria (but we could also make a named query for this).
--
I prefer 1) because of its simplicity (and we will probably get similar demands in the future) and its correctness: You are in fact getting a appointment resource returned (just with a limited list of attributes).
I don't like 2) - it doesn't feel right - Appointment2 is not a different kind of appointment - it is just providing a limited view of this attributes.
NB: A 3rd solution would be to choose a non-FHIR solution for this, and “just” make a dedicated REST-service.
Any guidance from you guys?
(The exact issue is that the current Appointment must include new information, and we also have a appointment-template which must be taken into account - but I think this is beside the point for my question)
Jens Villadsen (Sep 26 2016 at 11:08):
Can the question be narrowed down to: When to redefine an already existing resource (facing the issue of maintaining AppointmentEx1 and AppointmentEx2 endpoint and definitions) and when to reuse and extend an existing resource?
Grahame Grieve (Sep 26 2016 at 11:42):
haev you looked at hte _elements parameter? sounds like what you are looking for
Allan Bro Hansen (Sep 26 2016 at 14:47):
@Grahame Grieve: yes, the _elements parameter is mentioned in solution 1), but it means I'll go against the recommendations.
@Jens Villadsen: Yes, that is certainly a part of it - but if I only put it like that then _elements is the answer (apart from the "should"-recommendation). For my case there is more to it.
Grahame Grieve (Sep 26 2016 at 16:21):
why would you go against the recommendations?
Allan Bro Hansen (Sep 27 2016 at 06:01):
because FHIR says "Servers SHOULD always return mandatory elements " (https://www.hl7.org/fhir/search.html#elements), and the customer only wants a very small subset of the apointment
Grahame Grieve (Sep 27 2016 at 08:04):
which mandatory elements do they not want back?
Brian Postlethwaite (Sep 27 2016 at 12:39):
The only mandatory elements are status and participant. Seems strange not to want them.
Chris Grenz (Sep 27 2016 at 12:40):
Hi @Allan Bro Hansen . Sounds like you'd benefit from Profile Governed APIs which is something I'm working on formalizing (GF#10000). This particular use case would be covered by GF#8806. It's not standard yet, but I'm trying to build the use cases.
Allan Bro Hansen (Sep 27 2016 at 13:48):
We have more mandatory elements than the ones defined by FHIR.
For our appointment-resource the unwanted mandatory elements becomes the status, an extra sub-status (extension), an elective flag (extension), a location participant, a practitioner participant, a patient participant and to some extend the startTime (if you consider this as "mandatory" for a booked appointment).
The appointment should only contain the planned arrival date time and the planned arrival place, a reference to the managing organization and a reference to an appointment template. (the patient participants could be included but is not needed since the patient is the main search criteria).
Allan Bro Hansen (Sep 27 2016 at 13:54):
@Chris Grenz : Yes, the "Profile Governed API" addresses it. Although I think I'm pretty close using the namedQuery (with _elements behavior) approach.
Chris Grenz (Sep 27 2016 at 14:09):
"namedQuery"? Do you only need to read a subset of elements, or write them as well?
Allan Bro Hansen (Sep 27 2016 at 14:19):
only read is needed
Grahame Grieve (Sep 27 2016 at 14:59):
how come you don't need status? I would think that wasn't inappropriate, at least. Agree that _elements doesn't deal with repeating participants. That does point you towards a heavier weight solution like Chris's one. But from FHIR pov, it's not aa problem to use a different profile for your read/write operations from that for the outcome of a search
Allan Bro Hansen (Sep 27 2016 at 16:29):
I forgot to mention that status is also one of the search criteria - and I guess it wouldn't be a problem to include it. The _elements part has really gotten the focus which seems to confirm that solution1 is the best way to go with the current toolbox in FHIR (meaning without "Profile Governed API" or similar add-ons).
Grahame Grieve (Sep 27 2016 at 18:57):
so I think the best option for you might be to add a special parameter to indicate a restricted set of data to return for restricting to just the patient participant
Allan Bro Hansen (Sep 28 2016 at 11:02):
yes, if the task was only to return a restricted dataset. Given the "special searchCriteria"-demand I guess the special parameter is just an implicit part of using the namedQuery.
John Moehrke (Sep 28 2016 at 14:08):
How about the use of the _elements query parameter? http://hl7-fhir.github.io/search.html#elements
Allan Bro Hansen (Sep 29 2016 at 08:07):
I do intend to use the _elements way of doing it. I just want it to be an implicit part of the namedQuery.
So I do:
Appointment?_query=MyNamedQuery&patientIdentifier=myPatientIdToken
And only return a subset of appointment and related entities (also only only subsets of related entities)
And I do not do:
Appointment?_query=MyNamedQuery&patientIidentifier=myPatientIdToken&_elements=appointmentElement1,appointmentElement2
In which case I should validate appointmentElement1,appointmentElement2, and still include subsets of appointment related entities.
Grahame Grieve (Sep 29 2016 at 15:54):
I think you don't need to be explicit about _elements if you define your own named query like that. In fact, I wouldn't do it, because saying to use _elements as well creates ambiguity since the named query overlaps with it
Allan Bro Hansen (Sep 29 2016 at 21:31):
Yes, exactly
nicola (RIO/SS) (Oct 12 2016 at 09:50):
We've also implemented non standard _mask parameter:
{
birthDate: true,
name: { given: true },
}
And have some ideas how to introduce functions like showing part of identifiers, specific items in collections etc
Last updated: Apr 12 2022 at 19:14 UTC
