Stream: implementers
Topic: eligibilityresquest and eligibilityresponse
jassy (Aug 05 2016 at 19:34):
How to implement eligibilityresquest and eligibilityresponse resource access for a FHIR server? Should an FHIR resource request "eligibilityresquest" get "eligibilityresponse" resources back?
Grahame Grieve (Aug 05 2016 at 21:13):
@Paul Knapp should comment - but in a messaging solution, yes.
Grahame Grieve (Aug 05 2016 at 21:13):
in REST, you would post the request and poll looking for a response unless the response will be posted elsewhere (e.g. to you)
jassy (Aug 05 2016 at 22:37):
So assume it makes sense for doing it in REST, the flow could be:
client POST an eligibilityrequest to server and later client GET an eligibilityresponse (related to the eligibilityrequest POSTed earlier) from server. Can we confirm this is one expected work flow in respect to FHIR standard?!
Grahame Grieve (Aug 05 2016 at 22:38):
I think it is. Though I think most of the participants in the connnectathons have focused on req/resp by messaging or an operation
jassy (Aug 05 2016 at 22:42):
Thanks @Grahame Grieve. We will look into operation and messaging as well.
Lloyd McKenzie (Aug 06 2016 at 02:23):
@jassy Take a look at the http://hl7-fhir.github.io/workflow.html page in the spec. It identifies a number of different mechanisms for handling request/response situations and identifies some of the trade-offs in the different approaches.
Paul Knapp (Aug 07 2016 at 05:12):
@jassy You are correct, in FHIR REST you would POST an EligibilityRequest and then Get (Poll) for an EligibilityResponse, from the target server (normmaly) or your local server (if there is an arrangeent whereby the target server is allowed to Post the EligibiliyResponse) at a later time.
In a Request/Response paradigm you would sent the Eligibility as a Request and receive the EligibilityResponse as the Response.
We have demonstrated both approaches in Connectathons, including multiple Request/Response transports (TCP, http (rest), WSI web services), but the connectathon activity tends to focus on the Request/Response style given the immediate response nature and effeciency of the exchange.
Lloyd McKenzie (Aug 07 2016 at 05:42):
There's several other possibilities too - using publish subscribe, using Task or even dropping outside HTTP and using something like SMTP for a non-immediate response.
Paul Knapp (Aug 07 2016 at 06:22):
There are lots of possiblities, especially important can be consideration of using existing transports so that you don't have to re-engineer your transport layer(s) just because you want to upgrade your content models.
Pub/Sub is excess machinery, not the way the business flows and inefficient if the answer can come in the response. However, if this was the coutry-wide decision as to how content models would be exchanged then it would be more efficient to support that model than oppose.
Task is a content model rearraingement, not a transport level change.
Existing model are often Request/Response based and not necessarily TCP or HTMP based. SMTP would work too - just not effcient - unless that's all you have or is better than what you have.
jassy (Aug 10 2016 at 20:50):
Thanks for those info. I am thinking on using Messaging with $process-message over our FHIR REST service for eligibilityresquest and eligibilityresponse.
Paul Knapp (Aug 11 2016 at 06:45):
@jassy: are you a provider or a payor?
Last updated: Apr 12 2022 at 19:14 UTC
