1. Mirth Connect
2. Home
3. FHIR Connector Extension (3.6)
4. User Guide
5. FHIR Listener

Created by Nick Rupley on May 08, 2018

Let's say you've set up a destination that specifically handles the "create" interaction. Once you've created the resource and stored it (for example, in a database somewhere), the next step is to return a proper response back to the client. Each interaction is different and may require different response headers and status codes. You can view the summary table for responses here, but for ease of use, this technology preview also includes a couple of utility classes.

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:

var fhirResponse = new FhirResponse();
fhirResponse.setId('The ID you created here');
fhirResponse.setVid('The version ID you created here');
fhirResponse.setStatusCode(201);
fhirResponse.setIncludeLocationHeader(true);
fhirResponse.setIncludeETagHeader(true);
fhirResponse.setLastModified(lastModifiedDate);

Then you can return that response to the source connector however you wish (response map, postprocessor script, etc.).

This utility class makes the above even easier, with the following methods:

• getReadResponse(message, vid, lastModified, statusCode, mimeType)
• getVreadResponse(message, vid, lastModified, statusCode, mimeType)
• getUpdateResponse(message, vid, lastModified, statusCode, mimeType)
• getCreateResponse(message, id, vid, lastModified, statusCode, mimeType)
• getResponse(message, id, vid, lastModified, statusCode, mimeType)

All of these are convenience methods for creating FhirResponse objects. Some methods have multiple versions depending on whether you're sending a payload back. So for example instead of the code above, all that would be needed is this:

var fhirResponse = FhirResponseFactory.getCreateResponse(id, vid, lastModified, 201);

Note that documentation for these classes is included in the Reference list in transformers, and also in the auto-completion dialog. You can also view the Javadoc by going to the extensions/fhir/docs/javadocs/ folder in your installation directory.

Once you send back an appropriate FhirResponse object, the FHIR Listener will take care of everything else (status code, custom headers) automatically.

Document generated by Confluence on Nov 11, 2019 08:40

Atlassian