Stream: implementers
Topic: Search Encounters by Practitioner
Markku Nikkanen (Jul 13 2020 at 15:46):
Hello,
how one can search Encounters that has any individual Practitioner as reference? I use Java (and REST).
{
"resourceType": "Encounter",
...
"participant": [
{
"individual": {
"reference": "Practitioner/4",
"type": "role-xxx"
}
}
]
}
Bundle bundle = ourClient
.search()
.forResource(Encounter.class)
.where(Encounter.PARTICIPANT.???
.returnBundle(Bundle.class)
.execute();
BR, Markku
Lloyd McKenzie (Jul 13 2020 at 15:57):
Are you wanting to filter on those with a specific participant, or just that have 'some' Practitioner as a participant?
Hue Nguyen (Jul 13 2020 at 15:58):
@Markku Nikkanen did you try with _include query like _include:Encounter:practitioner
Markku Nikkanen (Jul 14 2020 at 05:26):
Lloyd McKenzie I want to filter encounters with some Practitioner as a participant.
Markku Nikkanen (Jul 14 2020 at 05:55):
Hue Nguyen It seems that query does not have effect.
http://localhost:8080/fhir/Encounter?_include:Encounter:practitioner
gives same result as
http://localhost:8080/fhir/Encounter?_include:Encounter:kjfdsljfds
René Spronk (Jul 14 2020 at 06:12):
You'd better talk to your server provider, to see whether they support _include. That's a pretty basic search functionality used by quite a lot of projects.
Markku Nikkanen (Jul 14 2020 at 06:13):
René Spronk Following seems to work in REST but I am still missing one thing:
http://localhost:8080/fhir/Encounter?_include:Encounter:participant&participant:missing=false
Type must be for example role-xxx. I want to return only e.g. physicians and refractionists.
participant": [
{
"individual": {
"reference": "Practitioner/4",
"type": "role-xxx"
}
}
]
René Spronk (Jul 14 2020 at 06:21):
Encounter?_include:Encounter:participant:participant-type=role-xxx&participant:missing=false ? Or Encounter?participant-type=role-xxx&_include:Encounter:participant&participant:missing=false
Markku Nikkanen (Jul 14 2020 at 07:20):
René Spronk said:
Encounter?_include:Encounter:participant:participant-type=role-xxx&participant:missing=false ? Or Encounter?participant-type=role-xxx&_include:Encounter:participant&participant:missing=false
Actually above does now work. It seems that the role-xxx rule does not have any effect. Following queries returns same result:
// Should return only Encounter having role-refractionist as participant type, not Encounter having role-physician
http://localhost:8080/fhir/Encounter?_include:Encounter:participant:participant-type=role-refractionist&participant:missing=false
http://localhost:8080/fhir/Encounter?_include:Encounter:participant&participant:missing=false
{
"resourceType": "Bundle",
"type": "searchset",
"total": 2,
"entry": [
{
"resource": {
"resourceType": "Encounter",
"participant": [
{
"individual": {
"reference": "Practitioner/4",
"type": "role-refractionist"
}
}
]
}
},
{
"resource": {
"resourceType": "Encounter",
"participant": [
{
"individual": {
"reference": "Practitioner/8",
"type": "role-physician"
}
}
]
}
}
]
}
Following query does not return any matches:
Is this correct: "participant-type"?
René Spronk (Jul 14 2020 at 10:09):
See http://build.fhir.org/encounter.html#search for parameters. Are you using a code from http://build.fhir.org/valueset-encounter-participant-type.html or are you using an extended value set? What does the 'self' link in the response bundle contain (i.e. any parameters that are ignored by the server because they're not supported)?
Markku Nikkanen (Jul 14 2020 at 10:30):
René Spronk said:
See http://build.fhir.org/encounter.html#search for parameters. Are you using a code from http://build.fhir.org/valueset-encounter-participant-type.html or are you using an extended value set? What does the 'self' link in the response bundle contain (i.e. any parameters that are ignored by the server because they're not supported)?
See self:
{
"resourceType": "Bundle",
"id": "bca650b7-508a-4059-bc6e-72de6f85da99",
"meta": {
"lastUpdated": "2020-07-14T10:25:36.004+00:00"
},
"type": "searchset",
"total": 2,
"link": [
{
"relation": "self",
"url": "http://localhost:8080/fhir/Encounter?_include%3AEncounter%3Aparticipant%3Aparticipant-type=role-refractionist&participant%3Amissing=false"
}
We have extensions in Encounter. Individual type should be standard. See how JSON object is constructed that is posted to HAPI FHIR:
participant.push({
individual: {
reference: `Practitioner/${this.practitionerFhirId}`,
type: Roles.PHYSICIAN
},
Markku Nikkanen (Jul 15 2020 at 06:24):
René Spronk I think participant-type points to incorrect location:
participant-type token Encounter.participant.type
It should point to Encounter.participant.individual.type.
participant": [
{
"individual": {
"reference": "Practitioner/4",
"type": "role-xxx"
}
}
]
I do not find such search option:
http://build.fhir.org/encounter.html#search
Following is most closest:
practitioner reference Encounter.participant.individual.where(resolve() is Practitioner)
(Practitioner)
Is it possible to enrich Encounter query options to match Encounter.participant.individual.type?
René Spronk (Jul 15 2020 at 07:48):
Why would you need that information? It contains the name of the resource type being referenced, i.e. Practitioner or PractionerRole or RelatedPerson. http://build.fhir.org/references.html#Reference , sure it's an extensible binding, but extending the value set would only be appropriate if your server supports new resource types not documented in FHIR itself.
René Spronk (Jul 15 2020 at 07:48):
how one can search Encounters that has any individual Practitioner as reference?
Encounter?participant:Practitioner:missing=false
Markku Nikkanen (Jul 15 2020 at 07:53):
René Spronk I am building reporting tool with filtering options in UI. I need to list all Encounters that has individual type role-physician or role-refractionist for instance. Individual type is the only location where role information for the Practitioner is stored.
René Spronk (Jul 15 2020 at 07:56):
OK, but that's a non appropriate use of that data element. As such you'll need some server side tweaking, as FHIR won't offer you a solution out of the box.
Markku Nikkanen (Jul 15 2020 at 08:45):
René Spronk what would be proper element to store practitioner role for the Encounter? Following?
Encounter.participant.type - Role of participant in encounter
René Spronk (Jul 15 2020 at 11:37):
Practitioner.qualification.code , but probably better would be PractitionerRole.code . If the Practitioner could have different roles depending on the encounter, then Encounter.participant.type may be more appropriate.
Markku Nikkanen (Jul 16 2020 at 06:00):
René Spronk
In our case Practitioner Role is Encounter specific. Is it possible to add custom roles as code e.g. PHYSCIAN? Predefined list does not have roles we are using. Can you add link to custom system definition where our domain roles are defined?
https://www.hl7.org/fhir/valueset-encounter-participant-type.html#expansion
"participant": [
{
"type": [
{
"coding": [
{
"system": "http://hl7.org/fhir/ValueSet/encounter-participant-type",
"code": "PHYSICIAN",
"display": "something"
}
]
}
],
"individual": {
"reference": "Practitioner/4"
}
Markku Nikkanen (Jul 16 2020 at 07:52):
It seems that you can define custom terminologies:
{
"system": "http://something.com/fhir/ValueSet/encounter-participant-type",
"code": "PHYSICIAN"
}
http://localhost:8080/fhir/Encounter?participant-type=http://something.com/fhir/ValueSet/encounter-participant-type|PHYSICIAN
Following operates, also:
{
"code": "PHYSICIAN"
}
http://localhost:8080/fhir/Encounter?participant-type=PHYSICIAN
Lloyd McKenzie (Jul 16 2020 at 13:18):
Encounter.participant.type has a binding of "extensible", meaning you MUST use the codes HL7 defines unless you're conveying a concept that is in no way covered by one of the standard codes (even if it's conveying a different granularity). The notion of "physician" seems like an odd choice of code for this element because the element isn't about "what kind of clinician is this individual?", it's "how are they involved in the encounter?". What kind of clinician would be conveyed in PractitionerRole.code.
René Spronk (Aug 01 2020 at 14:30):
Indeed. The intent of the attribute is a different one than the envisioned use, as such it seems Marku was looking at the wrong data element. If the intent of an attribute is to identify a color, then even the fact that the predefined value set is extensible doesn't mean one can/should create a new concept for "high fever". That's clearly a different thing.
Last updated: Apr 12 2022 at 19:14 UTC