In the case where we want to receive a practitioner id in the request and we will return either a single url reference (not to a resource but to a deep linked application) what type of resource would be efficient and effective for the response? The Reference resource seems ideal but seems to impose the need to return a FHIR resource url. The list resource might be effective but seems rather bloated and inefficient in the event that many elements would be returned in the list.
Can you explain your use-case in a bit more detail? Are you performing a search against Practitioner or ServiceRequest or something else?
Hello, thanks. Yes. I may be trying to hijack FHIR for general purpose api work but the concept is to have FHIR be all external facing data exchange between us and our customers.
The idea is a customer would pass us a GET request containing a unique identifier. This identifier would reference the primary practitioner of a patient’s care team.
We want to return (in some FHIR resource like Reference perhaps) an external url or a set of urls which link to that primary practitioners patient’s profile in a custom application - i.e. not in a FHIR server.
example GET:
https://api.domain.com/fhir/v1/ds5g34hfe54/$deepLink
the RESPONSE would (essentially contain)
{
id: 1234,
url: https://customapplication.com/patient/1234
}
But we want to use FHIR formatted data so as to normalize all external communications with customers
Thus, I was thinking:
-Bundle
-MessageHeader
-Reference
might do the trick but the FHIR Reference resource seems to only allow for pointing to another FHIR resource as opposed to some external URL. Would prefer not to definite a custom Basic resource to represent this but maybe that is the only way.
So you’re passing in a ‘business’ identifier (license number, employee id, etc.) for a Practitioner that does not have a RESTful resource instance. The response is a pointer to a non-FHIR instance that represents the Practitioner?
Sounds like a custom operation to me. The ‘response’ isn’t something that has its own independent identity or status, it’s just a dynamic resolution.
Out of curiosity, why return a pointer rather than the proprietary business object directly? With a FHIR operation, there’s nothing to stop you from returning the custom business structure as a Binary instance. If it’s the sole thing returned, you wouldn’t even need to base64 encode it…
1 Like
the return has to contain a sso deep link to a dashboard where member profile and other data is displayed and acted upon
It sounds like a custom operation would make the most sense.
righto thanks, the idea then, presumably, would be an extended operation returning a Basic resource tailored to the need. Does that seem a logical path?
You don’t need a Basic resource. Operations can return a Parameters instance that just contains the relevant output(s). There’s no persistent record created.