HL7 message routing improvements

OpenMRS HL7 message routing currently utilizes the HAPI MessageTypeRouter as a property on the HL7Service, configured in applicationContext-service.xml. We have to specify two codes separated by an underscore, corresponding to Type and Event (i.e. ORU_R01).

We need a more flexible HL7 message router that allows for the following features:

• registration from a module
• config.xml is a good candidate for this
• similar to methodology handling module-specific servlets
• wildcards or regular expressions for message attributes
• i.e. Type="", Event="R"
• i.e. SendingApplication=r".[pP][cC][sS]."
• i.e. MessageControlId=r"(^$|^ABC.*$|^0$)"
• more attributes for filtering
• Type
• Event
• Sending Facility
• Message Control Id
• ideally, we could use a mnemonic to define these fields so they are automatically mapped to HL7 fields
• i.e. <bean parent="matchingRule" p:field="MSH-9-1" p:rule="ORU"/> meaning MSH.MessageType.MessageCode = "ORU"

The first round of implementation for this router can be simple:

• use the best match on the most specific rule to route a message to a single consumer
• utilize a canProcess(message) method for every handler (as they already provide) to determine if the message should be moved to the next-best-matching handler instead
• some form of basic conflict resolution without creating a heavily detailed admin interface

Other necessary changes:

• methods for more generic handlers should be made available to and overridable by any class extending it
• i.e. create a handleObsException(obs, e) method that is overridden to ignore the exception or perform some other work on the data
• current methodology should be refactored so that any part of the process can be interrupted and/or reused by an extending class
• i.e. create the encounter in a separate method from the one that saves it, so that another version of this processor can act on the data without forcing it to the database

In this phase, in the interest of getting things done in a timely manner, we should not address the following issues:

• creating a pipeline for queuing and that sort of thing
• allowing for more than just consumers (i.e. filters, transformers or service activators / listeners)
• integrating some third party messaging component (mirth) for this purpose