Stream: implementers
Topic: Should HealthcareService reference Practitioner?
Tim Berezny (Nov 12 2017 at 22:35):
I'm doing some work with a HealthcareService directory, and i notice that the HealthcareService does not have a reference to a Practitioner (or practitionerRole?) resource. Instead, it looks like the PractitionerRole has a reference to the HealthcareService.
This feels like the wrong direction for the relationship to me, i.e., I believe that the HealthcareService should reference practitioner (or practitioner Role)? This would be more consistent with fact that it's the healthcareService that references organization and location, it seems odd that it doesn't also reference practitioners.
What is the rationale for the direction of this reference, and is it under consideration for change?
Lloyd McKenzie (Nov 13 2017 at 11:16):
In general, references point from the record created second to the one created first and from the many to the 1. The relationship between Practitioner and HealthCareService is consistent with that guideline. The relationship between HealthCareService and Location and Organization is also consistent with that guideline. Is there a pressing need for a change?
Tim Berezny (Nov 14 2017 at 14:42):
Thanks @Lloyd McKenzie for the insight, that is helpful. Yes, practitioner would often be created after healthcare service. However, a healthcare service would have many practitioners (often). Healthcareservice <> practitioners is many-to-many conceptually, so that one could go either way.
The main thing I’m trying to figure out is how to build a search API to a HealthcareService directory. I would like the root URL that my integrations use to stay with [base]/HealthcareService, (not search on [base]/practitionerRole) so that the integrator can easily chain a number of search parameters together (organization, near to a location, type, specialty, etc…).
The search example scenario I’m running into challenges with is “Search for a healthcareService near an address, by a practitioner’s name”, which, ideally would look something like this.
GET [base]/HealthcareService?PRACTITIONER-NAME:contains=Jones&location.near=-83.694810:42.256500
&near-distance=10||km
I’ve written PRACTITIONER-NAME in as the main item I’m not sure how to include in the search string, since practitioner is NOT referenced from the healthcareService Resource (hence the original question).
There might be something simple in SEARCH that I’m missing here, I’m fairly early in my exploration of search in FHIR.
As a bit of additional context: an underlying philosophy we’re using for searching for services for the purpose of sending an eReferral is that I’m ALWAYS looking for a healhtcareService resource. This is our key resource used to route the eReferral to the correct destination.
Lloyd McKenzie (Nov 14 2017 at 14:58):
It's true that Practitioner<->HealthCareService is many-to-may. However typically a practitioner will have fewer healthcare services than the reverse.
Lloyd McKenzie (Nov 14 2017 at 14:59):
Technically there's nothing to stop you from writing a custom search parameter on HealthCareService that involves a reverse search of Practitioner - so long as the HealthCareService repository has access to all relevant Practitioner repositories.
Lloyd McKenzie (Nov 14 2017 at 15:00):
The problem with search as a criteria for what properties live where is there's typically use-cases for both
Lloyd McKenzie (Nov 14 2017 at 15:01):
Have you looked at _has?
Lloyd McKenzie (Nov 14 2017 at 15:07):
I think you can do what you need with GET[base]/HealthcareService?location.near=-83.694810:42.256500&near-distance=10|km&_has:PractitionerRole:service:practitioner.name:contains=Jones
Lloyd McKenzie (Nov 14 2017 at 15:07):
@Ewout Kramer @Grahame Grieve @Josh Mandel Can reverse chaining and regular chaining be mixed as above?
Grahame Grieve (Nov 14 2017 at 15:23):
I think so
Lloyd McKenzie (Nov 14 2017 at 16:35):
Do we need to add anything to the spec to make that support explicit?
Brian Postlethwaite (Nov 14 2017 at 23:00):
only complexity there is the chaining to the location for near and near-distance.
Not sure that would work (as its a kind of composite on location)
Lloyd McKenzie (Nov 15 2017 at 09:17):
Yeah, that's true. Should that actually be defined as a composite parameter? "near-distance" isn't actually useful without the .near
Brian Postlethwaite (Nov 16 2017 at 09:40):
Probably.
Lloyd McKenzie (Nov 16 2017 at 09:55):
Do you want to write the change request or should I? :)
Tim Berezny (Nov 20 2017 at 15:31):
Thanks @Lloyd McKenzie , @Grahame Grieve , @Brian Postlethwaite , this is hugely helpful. We weren't familiar with the _has parameter, we're going to pursue that path.
Christiaan Knaap (Nov 22 2017 at 19:01):
Chain & _has can be combined in Vonk as well.
Lloyd McKenzie (Nov 23 2017 at 01:05):
Brian Postlethwaite (Nov 23 2017 at 01:09):
Thanks Lloyd.
Last updated: Apr 12 2022 at 19:14 UTC
