The first is the FhirResponse class. This is an extension of the standard Response class that also allows certain FHIR-specific data to be stored so that the FHIR Listener can automatically return the correct information. Here is a list of the additional methods that can be used:
- getId / setId: The logical ID of the resource associated with the response.
- getVid / setVid: The version ID of the resource associated with the response.
- getStatusCode / setStatusCode: The HTTP status code that will be sent back to the client.
- getLastModified / setLastModified: The date that will be sent back to the client in the Last-Modified header.
- getMimeType / setMimeType: The MIME type that will be sent back to the client in the Content-Type header.
- isIncludeLocationHeader / setIncludeLocationHeader: Determines whether the Location header will be included in the HTTP response.
- isIncludeETagHeader / setIncludeETagHeader: Determines whether the ETag header will be included in the HTTP response.
- getHeaders / addHeader / removeHeader: Allows the user to add additional custom HTTP headers to include in the response.
In the example above, say you've successfully stored a resource in response to a "create" interaction. Now according to
the FHIR specifications, your response should include the Location header, the status code 201 (Created), and the Last-Modified / ETag headers for versioning information. So you can create a FhirResponse object like so:
Then you can return that response to the source connector however you wish (response map, postprocessor script, etc.).