This page describes how to use Mirth to connect OpenMRS to other systems.
(at Joachim's request, some I-TECH Mirth links added below)
Before the REST web services module, OpenMRS had a Mirth Messaging Module which probably shouldn't be used anymore.
Our specific case is connecting OpenMRS for importing and exporting data to another database in the same MySQL instance. Below is a diagram. 
Questions
- How to connect Mirth using the REST web services module
- Should the REST web services work for both incoming and outgoing messages? The comment at the end of the page describes that it would only work for outgoing messages.
- How to trigger a channel for outgoing messages?
- In our case we are going to export data from OpenMRS to a MySQL database table. So my guess is that we should be able to either schedule this every so many minutes or hours. Can we also trigger than on an update of a patient it sends the data via OpenMRS REST to Mirth?
- How to trigger a channel for incoming messages?
- We are going to import the data from a table in a separate MySQL database. Again, our idea is based on a schedule, but could we trigger Mirth on an update of that table?
Below is an initial explanation (translated via google from spanish to english)
one hand, a Mirth channel where you configure a Web Service Listener displays a wsdl that works like a normal web service, for all purposes.
REST Web Services OpenMRS, if a server is running OpenMRS, other programs can connect to obtain and update data in the database OpenMRS (get / add patient encounters, orders ...)
If you want to keep the two databases synchronized (OpenMRS + Financial System), so that the financial system sends data to the database of OpenMRS guess you only need to use the REST Web Services module Module. You can also use a Mirth channel that detects when the data in a table (Database Reader source connector) and when this happens, the connector using the REST target Web Services Module for OpenMRS update the DB.
If what you want is to export data to another DB OpenMRS, you can easily use a Mirth channel receive data through a Web Service Listener making use of Mirth Messaging Module as a client, but 'tuneándolo' to be able to understand customized web service (as we have done in our client module of Mirth). We do not know enough about the REST Web Service Module to ensure that it is able to perform this part (connect to an external web service to modify an external DB), but if comentaís that is the best solution if you understand that.
Therefore, to summarize:
- If a table changes in database connection, you can make a channel that detects Mirth (Database Reader) and synchronize the data in the database Digital Health (OpenMRS) using REST Web Services Module connector on your destination.
- If something changes in OpenMRS require updates in Database Connection, you can connect with Mirth OpenMRS our way (with Mirth Messaging Module) and then use the Database Writer in the destination connector. We do not know in this case if you could use REST Web Services Module, I think it is not for this, but we do not know enough to secure outright.
============
Some comments re I-TECH experience with Mirth for OpenEMRConnect
Attribution – OEC owes most of it’s design and existence to staff in I-TECH’s Kenya and Seattle offices, to Jim Grace of UCSF/FACES in Kisumu, and to CDC staff in Kisumu and Kisian, Nyanza.
GSOC project using Mirth to import/export CDA as part of OpenEMRConnect (OEC). click here...
The OEC documentation site is not especially active (or pretty), but a lot of stuff is linked off here: https://sites.google.com/site/oeckenya/ This page has references to much of the Mirth work, which was done in late 2011, early 2012.
We’ll try and update at some point w/ a description of the currently deployed OEC system – things got hectic for a while and then our focus switched to the development and implementation of the OpenMRS distribution for the KenyaEMR. https://sites.google.com/site/kenyahealthinformatics/ (This is the primary site for all of our KE work).
============
Comments from PIH when using Mirth to connect to a McKesson PACS system:
We went with the option of Mirth connecting to OpenMRS via the database, because it is a simple way of setting up a message queue on the OpenMRS side, and because Mirth and OpenMRS will reside on the same server in our implementation. Basically, when OpenMRS wants to send a message, it writes out a row in an "outbound_message_queue" table (in the OpenMRS database). Mirth polls this table every several seconds for new entries (connecting via a user that only has rights to access that table)
Here's a screenshot of our channel configuration: 
OpenMRS drops HL7 messages into this table, and then this channel reads the messages from the database. This channel passes on the HL7 message to another channel that sends the HL7 message off to the PACS system via LLP. We use the following preprocessing script on the second channel to convert the xml format that the Mirth database reader returns into a format Mirth recognizes at HL7:
// Strip off the leading and trailing <result> and <message> tags
message = message.replace(/&/g,"&");
message = message.replace(/ /g,"\x0D");
message = message.replace("<result><message>","");
message = message.replace("</message></result>","");
return message;