Overview

The following are some general requirements for the EMPI Profile provided by Misys to Mirth Corp as part of the collaboration on the IXS.  These requirements need to be reconciled with the general capabilities contained within Mirth Match

Patient Registration

1. The eMPI must be able to receive ADT(Admission, Discharge and Transfer) messages from all participating systems
   1. An IXS implementation surfaces web services and does not explicitly use HL7
   2. Mirth will be bundled with any given install of the Mirth Match and provide a set of stock channels.  Some of these channels will handle this use case
   3. The Mirth Channel taking an incoming HL7 ADT would transform that message into the appropriaite WebService call
2. The following types of ADT messages should be supported: A01, A04, A05, A08, A31
   1. No problem.  The appropriate information is pulled out of the necessary segments in the ADT to form the appropriate IXS calls
3. Merge and unmerge messages should be supported.
4. The eMPI should support the addition of other protocols for patient registration (e.g. a web services message containing patient information).
5. The eMPI should also support a polling mechanism for getting ADT feeds.
6. Patient update messages from a particular participating system should update patient records (and matching where required).

Matching Logic

1. The matching logic must include the following parameters:
   1. Source System
   2. MRN
   3. First Name
   4. Last Name
   5. Middle Name
   6. SSN
   7. DOB
   8. Sex
   9. Address
      1. Line 1
      2. Line 2
      3. City
      4. State
      5. Zip
   10. Home phone number
   11. Work phone number
2. The eMPI must allow adjustable weights on each of these fields
3. The eMPI should allow different matching logic; at the minimum, the following types should be supported:
   1. Exact Match
   2. Fuzz Match
4. The matching engine should allow different matching logic to be assigned to each field.  For example, exact match on SSN, fuzzy match on address, etc
5. The matching engine should allow exclusion on certain values in certain fields in the matching process.  For example: exclude 111-11-1111 in SSn or 999-999-9999 in phone number fields
6. The eMPI shoud allow a configurable "threshold" to be set for automatic matching or linking
7. The eMPI should allow an administrator to manually match or un-match patients.
8. Patients manually matched or un-matched should not be automatically linked (or un-linked) based on update messages. The behavior in such cases should be configurable.

Patient Search

1. The eMPI should provide a API mechanism to lookup patients. The minimum lookup fields would be:
   1. Name (last, first)
   2. MRN
   3. DOB
   4. Sex
   5. Phone Number
   6. SSN
2. In addition to the API, the eMPI should provide a service to lookup patients. This could be a web services or HL7 based service.
3. The search API should allow for multiple types of search (e.g. exact vs. fuzzy)
4. The API should also allow partial searches i.e. last name starts with "smit..".
5. The search API should be able to return exact matches as well as matches within a certain "confidence" level.

Notifications

1. The eMPI should be able to notify other systems about new patients.
2. Notify when a patient demographics is updated from one participating system.

Patient Privacy

1. The eMPI should be able to capture patient consent data. The basic minimum is to capture an opt-in or opt-out.
   #The consent could be captured through the ADT messages.
2. 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.

Administration

1. Provide a way for an administrator to do forced linking or un-linking of patients.
2. 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.
3. Provide a way to add new participating systems. The eMPI should not accept messages from systems that are not registered.
4. Provide a way to remove a participating system. This might involve cleanup of the database of entities from that system.
5. Provide a way to configure the various parameter for the eMPI.

Reporting

1. Provide Auditing for all functions within the eMPI - patient registration, match, un-match, forced match/un-match etc.
2. Provide standard or custom reports on the following minimal set:
   1. Number of patients in the eMPI (by date range, by participating system)
   2. Number of matches/un-matches done by the system.
   3. Items pending manual intervention.
3. In addition, the system should provide mechanisms to create custom reports.