Patient Matching Criteria

Patient Matching Criteria

Description

The TouchWorks interface uses specific criteria in order to complete a patient match. This article explains the necessary requirements and is valid as of TouchWorks v11.1. The standard criteria is available in all versions of TouchWorks. In v11.1 there are new, "extended" matching criteria, which are optional and must be setup in each of your interface(s) that should use the extended matching criteria. Please see the "Extended Matching Criteria" below for more information.

In order to match properly, TouchWorks relies on the Last name, First name and two of the following three items: MRN, DOB, SSN. A more detailed description is shown below.

Regardless of matching used (Standard or Extended v11.1+ Matching), a single match is required. Let's say you are using the Extended Matching available in v11.1+ and there are two patients with the same Full Name and DOB, a match will not occur.

Fields

Last Name

This element is required and TouchWorks uses the first 5 letters of the last name for matching purposes.

First Name

This element is required and TouchWorks uses the first 3 letters of the first name for matching purposes.

Medical Record Number

Also known as the MRN, this field is optional, but two of the three optional fields must be present to match. If MRN is used, the Organization must match as well (applicable for multi-org only). See Matching Logic below.

Date of Birth

Also known as DOB, this field is optional, but two of the three optional fields must be present to match. See Matching Logic below.

Social Security Number

Also known as SSN, this field is optional, but two of the three optional fields must be present to match. See Matching Logic below.

Insurance / PBM

This is part of Test #4, used only for patient registrations (FilePatient_CMS). The fields used are the Card Holder Number (for the PBM) and Relationship to Card Holder. These are FilePatient_CMS fields MemberNumber (126) and PatientRelToCardholderCode (127).

Standard Matching Logic

• Test #0.1
  • XID Matching: XID is used by some clients, primarily IDX FlowCast / GE Centricity Business Solutions. It's a completely unique identifier, that never changes (unlike MRN can). XID matching trumps all other matching.
• Test #0.2: MRN and Org - File Patient Only
  • If a patient is being updated, it only needs to find the record (in the same org) based on MRN.
• Test #1: Name, MRN, DOB and Org
• Test #2: Name, MRN, SSN and Org
• Test #3: Name, DOB, SSN
• Test #4: Name, DOB, Insurance / PBM Match

Extended Matching Logic

This extended matching was added in TouchWorks v11.1. There are six new optional Tests/Scenarios for matching. These require additional setup in each interface that plans to utilize the new matching.

If not specified – Option 1 is assumed and standard patient matching logic occurs.

If specified – At least one entry from option 1, 2, 3, 4, 13, 14 or 16 MUST be specified as the primary matching logic. If not, a -163 error will be returned to ConnectR.

Options:

• Option #1: Perform Standard Matching
• Option #2: Perform Standard Matching, replacing MRN matching with Other Number matching
• Option #3: Perform Standard Matching, replacing MRN matching with Other Number 2 matching
• Option #4: Only perform XID matching - all other matching is ignored.

• Option #5: Name, DOB, Driver License
• Option #6: Name, DOB, Phone Number

• Option #7: Name, DOB, Address Line 1
• Option #8: Name, DOB, Mothers Maiden Name
• Option #9: Full Name (all characters of first and last names), DOB, Sex
• Option #10: Full Name (all characters of first and last names), DOB
• Option #11: Name, Other / Other 2, and SSN / DOB (11.1.7)
  • Off-cycle addition to the EHR.
  • Used with EMPI solutions. Used for demographics (ADT) matching only, across shared organizations. For example, patient Jane Smith (Other/EMPI = 1234) in Org A could have a new registration in Org B with Other/EMPI as 1234 and match to create a single chart (assuming either DOB or SSN match as well as Name and Other/2).
• Option #12: Full Last Name, Date of Birth, Sex, and MRN or Other Number (11.1.7)
• Option #13: MRN, Organization, Name, and Date of Birth or SSN (11.2.2)
• Option #14: MasterChartID, OrgSharingDE, Name, and Date of Birth or MasterChartID, OrgSharingDE, Name, and SSN or Name, Date of Birth and SSN (11.4.0)
• Option #15: MasterChartID, OrgSharingDE, Full Last Name, Date of Birth, and Sex (11.4.0)
• Option #16: MasterChartID only (11.4.0)
  • MasterChartID is a new identifier that is unique to the Organization sharing pool.

Implementation:

• There is a new parameter to most inbound interfaces, called @MatchLogic
  • This is a pipe-delimited list of the options. For example, '1|5|7|' if you were aiming to perform standard matching, Name/DOB/Driver's License and Name/DOB/Address Line 1 matching.
  • You must also provide the appropriate fields that you need (Phone Number, Driver's License, etc) - these are found immediately below the @MatchLogic parameter in stored procedures other than FilePatient_CMS. In FilePatient_CMS these fields already existed higher up in the parameter list.
• Phone Number matching
  • This is Home Phone in File Patient, and the specified Phone in other File routines
  • In file patient, Home Phone, must be entered in through fields 34-46, @o3x4HomePhoneArea, @o3x4HomePhoneExchange, @o3x4HomePhoneLast4 (@PatientFullHomePhone not an option as of v11.1.4).

Other Considerations

• In shared multi-org environments where there can be multiple practice management systems, the MRN may not be available as matching criteria because the patient could exist in mulitple orgs with different MRN's. This becomes a problem if SSN is not available. Some patients refuse to give out their SSN at registration, and some PM systems only store the last 4 digits.

The use of an Empi can solve this problem by linking a patient that exists in multiple systems to a single MRN which becomes the primary identifier in the EHR.

• In V11 GetPatientMatch will not match on Demographics unless you have an Org Sharing Pool linked to your organization.

Merged and Deactivated Patients

Merged: Matching will not occur on patients who have been merged "from". If the Patient Merge Tool (aka CMS Patient Merge Tool) has been used to merge two patients, the patient that was Deactivated will not be considered for matching. These are patients that cannot be seen in the Patient Lookup screen, even when the Inactive check box has been checked.

Deactivated: Patients that haven't been merged from, but have been deactivated in the Practice Management System, will be considered during matching; however, if they are found as the match, they will not be allowed to match. You will see a "-103 Patient is inactive" error.

Patient Matching Logic Spreadsheet

Here is another representation of the information in this Wiki article. Patient Matching in TouchWorks is often times confusing and the hope is a different view into the logic may help make it more clear.