Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Returning Response Headers from FHIR Calls #181

Open
jtilles-xealth opened this issue Oct 24, 2022 · 5 comments
Open

Support Returning Response Headers from FHIR Calls #181

jtilles-xealth opened this issue Oct 24, 2022 · 5 comments

Comments

@jtilles-xealth
Copy link

Expected Behavior

Caller able to access response headers returned by a FHIR Server (e.g. Location Header returned from a Create Call which received a 201 success response). Verified response headers are received from server when making call via Postman, but unable to access via FHIR-Kit-Client

Actual Behavior

Caller unable to access response headers using FHIR-Kit-Client library.

Steps to Reproduce the Problem

  1. Call FHIR Server with valid create call (i.e. Observation.Create)
  2. Verify 201 status code received
  3. Attempt to access response header for Location. Response headers are unexpectedly empty

Specifications

Source of issue appears to be in the following file from ~L172-177

const { status, headers } = response;

@vstrateman
Copy link
Member

vstrateman commented Oct 24, 2022

Hi @jtilles-xealth --

You should be able to access the headers with the method httpFor on the client object:

https://vermonster.github.io/fhir-kit-client/fhir-kit-client/1.9.1/module-fhir-kit-client-Client.html#.httpFor

Let us know if this solves your problem,

Vicki

@jtilles-xealth
Copy link
Author

jtilles-xealth commented Oct 31, 2022

We tried playing around with this and found httpFor() from fhir-kit-client didn’t return headers. The screenshot showed the raw response object after calling httpFor , we renamed it responseFromFhirClient in the attached log. From what we can see, it only consists of {size, timeout} fields. This was after making a Patient.read call, per httpFor() documentation:

fhirClient.read({
  resourceType: 'Patient',
  id: 12345,
}).then((data) => {
  const { response: responseFromFhirClient, request: requestToFhirClient } = Client.httpFor(data)
  console.log(responseFromFhirClient)
})

We traced it back to where the raw response was returned from fetch call in fhir-kit-client:

const { status, headers } = response;
. Basically, no status, nor headers in the response object returned from calling fetch method of cross-fetch module. One thing to note is that we use fhir-kit-client lib with a serverless lambda that makes calls to a fhir resource server. The data field of the above snippet did have patient resource. It’s just the raw response from fetch doesn’t have headers, nor status etc

image

Not sure if there is something we are missing here? We don’t even get the usual headers for a Patient Read call, such as ‘x-request-id’. For our actual use case, the exact header we are trying to get is returned from the EHR after making a Create call, where the EHR returns the FHIR ID of the created resource in the Location response header. Example from Postman call below:
image

@bkaney
Copy link
Member

bkaney commented Nov 1, 2022

@jtilles-xealth - here is a codesandbox that demonstrates it working with cerner's sandbox (see right-hand panel for output) https://bit.ly/3zwiiAK -- there was a problem with the types, so note this is using a new version I just published 1.9.2.

@vstrateman
Copy link
Member

Closing due to lack of responses, reopen if needed

@CHelfgott
Copy link

I'd like to reopen this.
My current code looks like the following:

      const newFhirPractitionerResponse = await this._fhirClient.create({
        resourceType: "Practitioner",
        body: fhirPractitionerBody,
        options: { headers: this._fhirHeaders },
      })
      const { response } = Client.httpFor(newFhirPractitionerResponse)

This works fine to e.g. extract resourceId from the location header when the request is successful, but when I've formatted my fhirPractitionerBody incorrectly (e.g. having an empty string in an address line), the create call, instead of returning the 400 response, throws an exception.
I currently have encapsulated this in a try-catch, but I think it would be better if either the create call always returns the response from the server, or it throws on failure and returns a Resource on success.
Note that the documentation of this function in client.js claims @return {Promise<Object>} FHIR resource

@vstrateman vstrateman reopened this Mar 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants