2

Can I use mirth connect to store millions of HL7v2 messages (pipe delimited) and query them programmatically by our third party software application at a later point of time?

What's the best way to do that? Is mirth's REST API capable to query its message store efficently?

Unfortunatly I need a running mirth connect instance to browse the REST API documentation according to the manual at page 368. (If it wouldn't require to have a running instance of mirth to browse the documentation of the REST API I wouldn't have asked that question. Is there a mirth connect instance available on the internet to play with? Or would somebody be so kind to post the relevant REST API documentation for that question?)

So far, those are the scenarios I came up yet:

enter image description here

OneWorld
  • 17,512
  • 21
  • 86
  • 136
  • 1
    MC is open source and runs on any platform and runs with an embedded database by default. That should make it easy to launch a copy and access the dynamic REST API documentation. – Freiheit Jan 17 '19 at 15:22

2 Answers2

4

Mirth is integration engine, and its strength is processing messages. Browsing historical messages can be at times difficult or slow, depending on the storage settings for the channel and whether or not you take care to pull additional information out during processing to store in "custom metadata" fields. The custom metadata fields are not indexed by default, but you can add your own (mirth supports several back-end databases, including postgres, mysql, oracle, and mssql.) Searching the message content basically involves doing a full-text search and scanning. Filter options to reduce scan time, apart from the custom metadata you create, are mostly related to the message properties (datetime received, status, etc..) and not the content.

So, I would not recommend it for the use-case you are suggesting.

However, Mirth could definitely be used to convert your messages (batched from files or live) to xml which could be put in a database designed to handle and query large volumes of xml documents. I assume when you say HL7 you mean the ER7 (pipe delimited) format of HL7v2. Mirth automatically does the conversion to xml for those types of messages as they are handled as xml during processing. You could easily create a new parent node that holds both the converted xml and the original message string as children.

If the database you choose has a JDBC driver, Java SDK, or HTTP/REST API, mirth can likely directly insert the converted messages for you as it processes them.

agermano
  • 1,679
  • 6
  • 16
  • Can I configure mirth the way, that it stores millions of messages and will later answer my `QRY A19` messages? Will mirth answer that message in a fast manner using its internal message store? As reading that article I am almost sure that setup is possible, but will it be performant? https://mirthconnect.wordpress.com/anwendungszenarien/patientendatenabfrage/ [english](https://translate.google.de/translate?sl=de&tl=en&u=https%3A%2F%2Fmirthconnect.wordpress.com%2Fanwendungszenarien%2Fpatientendatenabfrage%2F) – OneWorld Jan 17 '19 at 07:53
  • You wrote "could be put in a database designed to handle and query large volumes of xml documents". Do you have any experience doing so? What DB and software libraries have you used to do so? Could you be so kind and share your experiences at this question: [Best way to store received HL7 message from customer in database](https://stackoverflow.com/questions/14356431/best-way-to-store-recieved-hl7-message-from-customer-in-database) – OneWorld Jan 17 '19 at 08:05
  • 1
    The internal message store keeps the exact messages as they were received. It has no concept of patient records that would be kept and updated. Mirth can receive QRY A19 messages. It's possible to have mirth query the HIS database directly and construct a response based on those results. – agermano Jan 18 '19 at 03:32
  • Otherwise, it sounds like what you really need is a lightweight EMR to store patient records for you that mirth can query. Mirth can still sit between the HIS and EMR and filter/transform the broadcast HL7. – agermano Jan 18 '19 at 03:39
1

There are two misconceptions here:

  • HL7v2 message is triggered by the real-world event, called the trigger event, on the placer (sender) side. It expects some activity to happen on the filler (receiver) side by either confirming the message, replying with the query response, etc. I.e., HL7v2 supports data flow among systems.

  • Mirth Connect is HL7 interface engine aimed at transforming incoming feeds in one format (e.g., HL7v2 in ER7 format) into outgoing feeds in another format (which could be another HL7v2, or XML, or database, etc.). It does not store anything except a configured portion of messages for audit purposes.

Now, to implement a solution you outlined, Mirth Connect or any other transformation mechanism has to implement two flows: receive, convert if needed and store incoming messages; provide an interface to query those messages.

This is obviously can be done with Mirth Connect but your initial question if Mirth is capable in storing millions of records is incorrect. In fact it's recommended to keep as less messages as possible to speed up Mirth processing (each processed message is stored in the Mirth internal database several times depending on configuration). Thus, all transformed messages are going into the external public or private message storage exactly as shown on your diagrams.

Shamil
  • 910
  • 4
  • 17