Stream: implementers
Topic: Cardinality of Endpoints
Adrian (Feb 09 2018 at 02:27):
Hi Everyone!
My team is working on the Endpoints logic for Organizations, Locations and HealthcareServices. And we need to clarify some questions. According to the Australian FHIR spec, HealthcareService can have multiple Endpoints. if for example there is the same HealthcareService provided by one Organization on its 3 different Locations, If i request a specific HealthcareService object, and that one has 3 endpoints, then how would I know which one will send the information to which Location, been that Endpoint doesn't have a reference to Location?. For me the fact that a HealthcareService has more than 1 endpoint is kind of confusing, can anyone help me please? thank you :D
Lloyd McKenzie (Feb 09 2018 at 02:47):
@Brian Postlethwaite
Brett Esler (Feb 12 2018 at 00:07):
Hi @Adrian the current scope of the AU PD IG is that the addressable destinations are ProviderRole (person in role; for AU restricted to 1 location) or HealthcareService (service operating over one or more locations). This is really a scope decision and we have remained silent on addressing Location.endpoint which is possible in the FHIR core specification.
Brett Esler (Feb 12 2018 at 00:10):
Addressing an endpoint for HealthcareService with more than one location implies there is one messaging receiver for that service (all locations). If you want to differentiate the service by location then would need to have multiple HealthcareService entries for each location(s) that has a specific receiver.
Adrian (Feb 12 2018 at 00:33):
Addressing an endpoint for HealthcareService with more than one location implies there is one messaging receiver for that service (all locations). If you want to differentiate the service by location then would need to have multiple HealthcareService entries for each location(s) that has a specific receiver.
Hi @Brett Esler thank you very much for your reply, this information will help a lot :D
Brett Esler (Feb 12 2018 at 00:41):
@Brian Postlethwaite might like to comment but seems safer and easier that the HealthcareService.endpoint is in the context of the service (which implies one or more locations with AU constraints) and Location.endpoint would be delivery address related to the physical/logical destination alone (AU PD has not looked at specific location only delivery concepts yet)
Brian Postlethwaite (Feb 12 2018 at 00:43):
I agree with what has been stated, that if the details are the same for all locations, then you may have a single healthcareservice instance, however if there are differences (as you've noted) then you should have a healthcare service for each location.
Brett Esler (Feb 12 2018 at 00:46):
thanks @Brian Postlethwaite think it has to be this way as per all the attributes of HealthcareService otherwise would need to differentiate the usage (location or otherwise) of repeating elements like specialty, type, telecom, availableTime, notAvailable etc...
Brett Esler (Feb 12 2018 at 00:48):
might be nice if the HealthcareService.endpoint description had minor addition at the end:
Technical endpoints providing access to services operated for the location(s)
Brian Postlethwaite (Feb 12 2018 at 23:03):
That's a sensible update, can you log a tracker for it?
Brett Esler (Feb 12 2018 at 23:43):
GF#15520: HealthcareService.endpoint description wording
Last updated: Apr 12 2022 at 19:14 UTC
