Ref: http://www.mirthcorp.com/community/wiki/display/mirth/Example+Channel
_______________________________________________________________________________________
FHIR (Fast Healthcare Interoperability Resources) is a new set of HL7 healthcare standards. Its main focus is on the ease of implementation, based on RESTful HTTP using XML or JSON. Components called “Resources” are used to store and exchange data between systems.
Since Mirth Connect has HTTP connectors and supports XML/JSON data, you might have already guessed that creating a fully-compliant FHIR implementation has already been completely possible. What this extension provides is an even easier way for you to kick-start your new interface.
The FHIR Listener connector acts much like an HTTP Listener but also includes an assortment of FHIR-specific settings as well as some helper/utility classes for working with responses. There is also an FHIR Sender destination connector and a new FHIR Resource Builder available as both a transformer step type and code template type.
Note: Before implementing FHIR connector, you need to download the FHIR listener according to the version of Mirth connect you are using.
Firstly, we need to open Mirth Connect Administrator, navigate to the Channels view, and click on Import Channel to the left. Select the channel XML file, and then click Open.
Then you’ll be taken to the edit channel view:
Click on Save Changes to save the channel.
Creating the Database
This example channel depends on a database to store resource information. It is set up to support PostgreSQL or SQL Server, though you can modify the code templates to support others. Once you create a schema (e.g. “fhirdb”), here are the other create statements you need:
PostgreSQL:
SEQUENCE
resource_sequence INCREMENT 1 START 1;
CREATE
TABLE
resource( sequence_id bigint
NOT
NULL
DEFAULT
nextval(‘resource_sequence’::regclass), name
character
varying(255) NOT
NULL, id character
varying(255) NOT
NULL, version integer
NOT
NULL, data xml, mimetype character
varying(255), last_modified timestamp
with
time
zone DEFAULT
now(), deleted boolean, request_method character
varying, request_url character
varying, CONSTRAINT
resource_pkey PRIMARY
KEY
(sequence_id), CONSTRAINT
resource_unq UNIQUE
(name, id, version));
CREATE
TABLE
resource_sequence( id BIGINT
NOT
NULL);
INSERT
INTO
resource_sequence VALUES
(1);
CREATE
TABLE
resource( sequence_id BIGINT
NOT
NULL, name
NVARCHAR(255) NOT
NULL, id NVARCHAR(255) NOT
NULL, version INTEGER
NOT
NULL, data XML, mimetype NVARCHAR(255), last_modified DATETIMEOFFSET DEFAULT
CURRENT_TIMESTAMP, deleted BIT, request_method NVARCHAR(MAX), request_url NVARCHAR(MAX), CONSTRAINT
resource_pkey PRIMARY
KEY
(sequence_id), CONSTRAINT
resource_unq UNIQUE
(name, id, version));
Adding the Configuration Map Properties
The example channel also relies on some configuration map properties to store database connection information. If you don’t already have configuration map properties set, you can just import this file:
PostgreSQL:
# The type of database server (postgres, sqlserver).fhirDBDatabaseType = postgres# The JDBC Driver class to use when connecting to the FHIR database.fhirDBDriver = org.postgresql.Driver# The JDBC connection URL to use when connecting to the FHIR database.fhirDBUrl = jdbc:postgresql://localhost:5432/fhirdb# The username to use when connecting to the FHIR database.fhirDBUsername = postgres# The password to use when connecting to the FHIR database.fhirDBPassword = postgres# The maximum amount of retry attempts when a database connection fails.fhirDBMaxRetries = 3
SQL Server:
# The type of database server (postgres, sqlserver).fhirDBDatabaseType = sqlserver# The JDBC Driver class to use when connecting to the FHIR database.fhirDBDriver = net.sourceforge.jtds.jdbc.Driver# The JDBC connection URL to use when connecting to the FHIR database.fhirDBUrl = jdbc:jtds:sqlserver://localhost:1433/fhirdb# The username to use when connecting to the FHIR database.fhirDBUsername = sa# The password to use when connecting to the FHIR database.fhirDBPassword = admin# The maximum amount of retry attempts when a database connection fails.fhirDBMaxRetries = 3
Otherwise, you can just add them to the configuration map table:
Make sure to change the connection information (URL, username, and password) as needed.
Notes on Implementation
First, note that certain interactions have been selectively enabled for certain resource types. For this example, we’ll only actually be implementing some interactions, so this is largely for illustration. You can enable or disable interactions as you see fit so that the generated conformance statement will reflect that support to clients.
On the source connector settings, we also have a custom “response” variable selected. This indicates that the FhirResponse object the FHIR Listener uses will be retrieved from the response map.
Source Transformer
Here, we just have a single step. We use destination set filtering to decide in advance which destination to send a message to. Each destination is named according to one of the possible FHIR interactions, like “create” or “update.” Because the interaction of the request will be in the “fhirInteraction” source map variable, we can use that to directly filter on destinations:
var
interaction = sourceMap.get(‘fhirInteraction’);
if
(interaction == ‘operation’) {// Operation destinations will have a name of “$name”.destinationSet.removeAllExcept([sourceMap.get(‘fhirOperationName’)]);} else
if
(interaction.startsWith(‘history’)) {// This will match history-system, history-type, and history-instancedestinationSet.removeAllExcept([‘history’]);} else
if
(interaction.startsWith(‘search’)) {// This will match search-system and search-typedestinationSet.removeAllExcept([‘search’]);} else
{// All other destinations should have a name equal to the interactiondestinationSet.removeAllExcept([interaction]);}
Destinations
We’ll just look at one: the “create” destination. As the name implies, this destination will handle all create interactions that flow through the channel. It’s a JavaScript Writer that will take a resource posted to the channel and store it in a database (the one you created above). The JavaScript code in the destination simply inserts the resource into the database and uses FhirResponseFactory to create a FhirResponse object. Then it places that response into the response map, with the key “response.”
The other destinations in the channel are much the same. For example, the “read” destination will use similar code to select resource data from the same database table and return the data in an appropriate FhirResponse object. The “history” and “search” destinations are a little more complex because it involves selecting multiple resources and compiling them into a Bundle resource.
Sending Sample Requests
Once you’ve made any necessary tweaks to the channel or configuration map (like pointing it to your local database), save and deploy it. The FHIR Listener channel will be up and running and you should be able to request the home page at the URL http://localhost:9001/r3/, or the conformance statement at the URL http://localhost:9001/r3/metadata. Note that the IP, port, or base context path may be different depending on your source connector settings. If you request a resource (like the conformance statement) in a web browser, it will return the HTML template with the resource narrative (if available):
Creating a Patient Resource
After verifying the /metadata endpoint works correctly, try creating a new Patient resource. Doing so is simple, just POST a request to http://localhost:9001/r3/Patient. You can go here to get some example patient resources: Resource Patient — Examples.
If you choose an XML-formatted resource, use “application/fhir+xml” for the Content-Type. If you choose JSON, use “application/fhir+json”.
After sending the request, the channel should receive the message, and you can view it in the message browser:
Notice how the fhirType variable contains “Patient” and the fhirInteraction variable contains “create,” which is correct. Back in whatever HTTP client you’re using, you should have received a 201 (Created) status code and also a Location header. The Location header contains a URL telling the client where to issue a “vread” interaction to retrieve the same resource you just created.
Reading a Patient Resource at a Specific Version
If you copy that URL and issue a new GET request to it, it should return the same resource XML that you POSTed earlier. Again in the message browser, you can view the read request that came in, and verify the response data that was sent back to the client:
Binary Resources
You can also create and read Binary resources. Issue another POST request, but this time to the address http://localhost:9001/r3/Binary (again, the URL may change depending on source connector settings). Use the Content-Type “application/pdf”, and select a testing PDF for the actual HTTP payload. You should see the same “create” request in the message browser, but the PDF will be stored as an attachment instead, and the content of the Binary resource will be a replacement token, like “${ATTACH:efe4cd42-de30-4e80-b1d4-1e15dbd646f9}”.
Finally, in the HTTP response, you should get the same Location header. If you copy that URL and issue a new GET request to it, it should return the same PDF that you created previously. Know more about Mirth IT solutions, https://www.tactionsoftware.com/healthcare-software-solutions/mirth-hl7-consulting/read more as a mirth developer http://www.mirthcorp.com/community/wiki/display/mirth/Example+Channel
Nilkamal's Blog for Health Standards 