General questions and convoluted responses about Mirth Match

Installation

• How do I set the timezone?
  There is a java system property, user.timezone, you can try to set in your domain.xml (refer to Installation Notes on how to edit this file). Make sure it doesn't already exist. It should be with your other jvm-options and would look something like this:

Monitoring and Maintenance

• I have asked the IT team to constantly monitor the service URL http://hostname:port/MirthMatch/EIS?wsdl for heartbeats on a regular basis to make sure MM is running.
  That's a good idea. Also, monitor the login page with a GET and parse the response.

• We would be removing the rotated server.log files under GF which are more than a month old.
  Sounds like a plan. We rotate here more frequently than that actually. Rotating and archiving is an excellent idea.

• We would setup notifications for calls that might fail due to unforeseen conditions.
  Monitoring GF logs in realtime and looking for any stacktraces would seem prudent. Also an ability to pause any code that feeds into MM would be a good idea. For instance, a Mirth channel that posts the EntityFeeds could be paused and messages would queue and then processed when the server was back in a ready state. A java module could queue as well via some mechanism. In short, every feed should have some form of queuing pattern in the event the server is down for any reason.

• Anything else that we should keep in mind? Any tips from your other customers that have gone live with MM would be very valuable.
  1. Keep the database statistics up to date. Update them weekly at least should be fine.
  2. Create a daily maintenance window, even if you don't use it. Automate it so that you have an operational window where you can do things on the MPI when you need to. You can do backups during this window.
  3. Try and establish some form of archive of system activity during a given window (daily?). The goal would be to be able to restore to a prior known point from backups and then reprocess up to a known point and then go live again. Mainly disaster recovery plan, but also in less drastic events.

Notifications

• Is Mirth Match able to notify other systems about new patients or generation notifications when a patient demographics is updated from one participating system?
  You'll use the Event Notification capability here located under the Main Menu. Creating an Event Notification for the events you want to monitor, perhaps by the particular Identifier Domains a particular external subscribee wants to listen on, should focus the notification to relevant changes.
  Mirth Match can monitor general system events as well as changes to individual entities traits (e.g., patient demographics).

Patient Privacy

• The eMPI should be able to capture patient consent data. The basic minimum is to capture a opt-in or opt-out. The consent could be captured through the ADT messages.
  Mirth Match has no 'inate' capability dealing with consent across entities. Typically consent related information is stored/located within some other application's data stores that are integrated/orchestrated with Mirth Match.
  That said, you could definitely create a trait for the Patient entity called "CURRENT_OPTIN_STATUS" let's say. This could then be referenced or fetched whenever a querying application queries for a given Entity. It would be up to that querying application to execute the appropriate logic to constrain queries or other business logic depending on the value of the trait.
  For Mirth Match as it has been integrated within the NHIN CONNECT system (which relies heavily on the Consumer Consent Profile (CCP)), Mirth Match stores on consent information at all. That job is given over to the orchestrating code that handles the Subject Discovery request let's say. That orchestrating code, as needed, makes a corresponding call to Mirth Results to fetch the necessary CCP for the patient and behaves accordingly. Same for the DocQuery and DocRetrieve requests.
  My current thinking has me feeling that it is not the job of the EMPI generally (or a more generic service like the XIS specifically) to be the repository of reference for Consent information. This is based on all the use cases I've experienced to date. I lean towards layering this functionality into the inevitable proxy layer sitting on top of the EMPI that has knowledge of the context of the usage of the consent as well as more flexible means to deal with edge cases.
  That said, I'm open to brainstorming a bit about this general ability, provided we could layer it in within the XIS – meaning it's a general aspect related to any arbitrary entity (Provider, Patient, etc). So it'd need to be something abstract than Patient Consent. My big concern here is moving something into Mirth Match that is certainly going to be handled buy some new/existing service... It's just too big and complicated a service, properly done, to cram into a generic service like Mirth Match, I think.

• If ADT messages are not enough, the eMPI should provide an alternate way for participating systems to indicate consent. Patient search should be able to return patients (linked or un-linked) based on a configurable "consent" setting. For e.g., return all patients irrespective of consent vs. return all patients who have "opted-in".
  It is desirable that patient search be allowed to configure the level of consent from each participating system. For e.g., User 1 of System 1 does a search on "John Smith"; Based on some configuration, it is determined that User 1 can access non-consented patients from System 2 and System 3, but not System 4 and 5; In this case, the search should return all patients matching the criteria from System 2 and 3, but only the consented patients from System 4 and 5.*
  Based on what I wrote above, when it comes to patient consent, I think this general capability to preclude individual callers (clients to the XIS service) from seeing patients data should belong in a proxy that actually makes the call and filters results.
  For general entity query capability that doesn't involve a Consent aspect, I think it's reasonable to think that Mirth Match would remove candidate matches depending on the rights for a particular client making a query call. We currently don't have this capability in Mirth Match but I agree it should be there and we'll get it on the near term road map. It will rely on certain meta-data being defined in Mirth Match as well as keys to this information provided on each call from the client (userid, systemid, etc).

Administration capabilities

• Is there also a way to add additional traits to the import that are not currently available?
  Yes. Follow these steps:
  1. Enter into an entity domain
  2. Go to Administrator (top right) -> Setup (menu) -> Traits. Then add the traits you want.
  3. Then you can associate the new traits to your domain on the dashboard for that domain. Make sure to include a sort order.

• I had a question about the Status Alias trait that is required. I noticed in your example that you used ENTITY_STATUS.ACTIVE for the value. Is this what I should include in my import file?
  Regarding status, you can leave that field out if you'd like. The importer will default to Active.

• Provide a way for an administrator to do forced linking or un-linking of patients.
  Exists at the API, but not made available in the UI properly yet.
  API call is eis.linkEntities() and eis.unlinkEntities()

• For patients matches (or un-matches) which fall within a delta of the "threshold", provide a mechanism for the administrator to see the details and make an informed decision. This is similar to a "Work Queue" type of feature.
  This would be the Work Queue facility within Mirth Match. Linkage assertions meeting/not meeting certain thresholds are added to this queue for review. An operator has the ability to Approve or Reject these assertions.

• Provide a way to add new participating systems. The eMPI should not accept messages from systems that are not registered.
  New participating systems can be added dynamically via the Webservice API or the web UI. Configured appropriately (as is the default), callers attempting to register an entity for a system (identifier domain) not already existing, error out with a IDENTIFIER_DOMAIN_NOT_FOUND error.

• Provide a way to remove a participating system. This might involve cleanup of the database of entities from that system.
  Available via the UI or the WS API.

• Provide a way to configure the various parameter for the eMPI.
  Not sure what this means.

Reporting capabilities

• Provide Auditing for all functions within the eMPI - patient registration, match, un-match, forced match/un-match etc.
  Currently available under EventLog.

• Provide standard or custom reports on the following minimal set: Number of patients in the eMPI (by date range, by participating system).
  Current aggregates available for entire Domain and individual systems, but not point in time currently.

• Number of matches/un-matches done by the system.
  Available for ad-hoc reporting from Event Log data

• Items pending manual intervention.
  Available for ad-hoc reporting and from UI via Event Log data.

• The system should provide mechanisms to create custom reports.
  Custom reports in short term will probably be done through direct database access to the underlying repository database.