T3.6: Explains EMPI Person Search

Overview

InterSystems EMPI includes a dedicated Patient Search page specifically designed for searching patients, viewing demographic data, and accessing alternate and historical views of patient information. This is distinct from the search functionality in the Worklist.

Key Distinction: EMPI Person Search vs. Worklist Search

The fundamental difference between these two search interfaces lies in their purpose and scope:

Worklist Search:

• Filters and displays pairs of database records requiring human intervention
• Focuses on potential duplicates, overlaps, and linkage conflicts
• Results are limited to records with matching scores near decision thresholds
• Used for managing the review queue of problematic matches

EMPI Person Search:

• Returns all records satisfying specified demographic criteria
• Not limited to problematic pairs - retrieves any matching patient records
• Provides comprehensive view of all data associated with a person
• Used for general patient lookup and linkage investigation

Primary Use Cases for EMPI Person Search

1. Investigating Linkage Issues When users need to understand why records were linked or not linked, EMPI Person Search provides the starting point. Users can locate all records for a patient and then navigate to alternate views (Comparison Detail, Record History, Whole Record Viewer) to investigate the linkage relationships.

2. Finding Records by Demographic Criteria Unlike deterministic searches by MPIID or MRN, EMPI Person Search allows users to find patients using fuzzy demographic matching - useful when exact identifiers are unknown or when searching for patients with similar but not identical demographic information.

3. Verifying MPIID Assignments Healthcare organizations need to verify that the correct records have been assigned to each Master Patient Index ID. EMPI Person Search allows users to search by MPIID and view all database records associated with that enterprise identifier.

4. Researching Patient Identity Questions When clinicians or registration staff have questions about patient identity - for example, when a patient presents with similar but not matching demographic information - EMPI administrators use Person Search to investigate whether existing records represent the same individual.

5. Auditing and Quality Assurance Quality assurance staff use EMPI Person Search to audit the accuracy of patient matching and linking, selecting random samples of patients to review their linked records and verify correctness.

Navigation

To access EMPI Person Search: 1. Navigate to the InterSystems EMPI menu in the Management Portal 2. Select Patient Search 3. The search pane appears on the left with various demographic and organizational criteria 4. Enter search criteria and click the Search button at the top

EMPI Person Search vs. UCR Person Search

While both systems provide person search capabilities, they serve different purposes:

EMPI Person Search:

• Shows matching and linkage details
• Displays MPIIDs, link weights, and linkage status
• Provides access to linkage-focused alternate views
• Used by EMPI administrators and data stewards
• Focus: identity resolution and data quality

UCR Person Search:

• Shows clinical data and patient information
• Displays patient demographics and clinical summaries
• Provides access to clinical documents and care records
• Used by clinicians and care coordinators
• Focus: clinical care delivery

---

Probabilistic Search Criteria

The Patient Search feature combines both probabilistic and deterministic searches to yield the most accurate results. Probabilistic criteria use fuzzy matching algorithms to return both exact and inexact matches.

Probabilistic Criteria Include:

• Family Name
• Given Name
• Middle Name
• Gender
• Date of Birth
• Street
• City
• State
• Postal Code
• Phone

Probabilistic Matching Behavior: Probabilistic criteria return both exact and inexact matches, with results ranked according to how well they match the criteria. For example:

• Searching for "John Smith" may also return "Jason Smith" or "Jon Smyth"
• Searching for "123 Main Street" may also return "123 Main St" or "123 Maine Street"

Boolean Logic for Probabilistic Criteria: All probabilistic criteria function as "OR" conditions: results may exactly or approximately match any of the probabilistic criteria entered. This means entering multiple probabilistic criteria broadens the search rather than narrowing it.

Deterministic Search Criteria

Deterministic criteria require exact matches and are used for precise lookups when specific identifiers are known.

Deterministic Criteria Include:

• MPIID (Master Patient Index ID)
• MRN (Medical Record Number)
• Assigned By (Assigning Authority/Facility)
• SSN (Social Security Number)
• Other Identifier (allows selection of other previously defined deterministic identifiers, such as driver's license number)

Deterministic Matching Behavior: Deterministic criteria return only exact matches. For example:

• Searching for SSN "123-45-6789" returns only records matching that exact value
• No fuzzy matching or approximations are applied

Boolean Logic for Deterministic Criteria: Deterministic criteria function as "AND" conditions: only results matching all deterministic criteria exactly are returned. This creates a highly specific search.

Mixing Probabilistic and Deterministic Criteria

When users combine probabilistic and deterministic criteria in a single search, the search effectively becomes deterministic. The system requires exact matches on all deterministic criteria while allowing fuzzy matches on probabilistic criteria.

Example: Searching for:

• Family Name: "Smith" (probabilistic)
• SSN: "123-45-6789" (deterministic)

This returns only patients whose SSN exactly matches "123-45-6789" AND whose last name is similar to "Smith". The probabilistic fuzzy matching is applied only after the deterministic filter has been satisfied.

Result Ranking

Results include a Rank column showing how well each result matched the search criteria. Higher-ranking results more closely match the entered criteria. This ranking is particularly useful when using probabilistic criteria, as it helps users identify the most likely matches among many approximate matches.

---

Search Interface Layout

The EMPI Person Search interface consists of two main sections: 1. Search Pane (Left): Contains all search criteria fields 2. Results Pane (Right): Displays matching patients and their associated records

Executing a Search

Step 1: Enter Search Criteria In the search pane on the left, users can enter any combination of:

• Deterministic identifiers (MPIID, MRN, SSN)
• Demographic information (names, date of birth, gender)
• Address information (street, city, state, postal code)
• Contact information (phone numbers)
• Organizational identifiers (Assigned By facility)

Step 2: Execute the Search Click the Search button at the top of the search pane to perform the search. The system executes both probabilistic and deterministic matching algorithms to identify matching records.

Step 3: Review Search Results Results appear in the right pane, grouped by MPIID. Each group represents a distinct patient identity as determined by EMPI matching and linking processes.

Understanding Search Results Display

Result Grouping by MPIID: Results are grouped by Master Patient Index ID (MPIID), with each MPIID representing a unique patient identity. This grouping reflects the current linkage state - all database records linked together share the same MPIID.

Top-Level Result Rows: Each top-level row displays:

• Alternate view icons for accessing different views of the data
• MPIID of the individual matching the search criteria
• Demographic data: name, gender, date of birth, and address
• Rank: how well the result matched the search criteria

Expanding Record Details: By default, results show only the MPIID-level summary. To view all individual database records associated with an MPIID:

• Click the Show Detail button at the top to expand all results, OR
• Click the arrow in an individual result row to expand just that patient's records

Collapsed Record Details: Each database record within an MPIID group displays:

• Assigning Authority: the facility that created the record
• Facility: where the record originated
• MRN: the Medical Record Number from that facility
• Demographic data: may differ slightly from the MPIID-level summary if records contain conflicting information
• These records are displayed with indentation to show they belong to the MPIID above them

To Collapse Expanded Details:

• Click the Hide Detail button at the top to collapse all results, OR
• Click the arrow again in an individual result row to collapse just that patient's records

Managing Result Set Size

Result Limit: Enter an integer in the Result Limit box to control the maximum number of MPIID-level results displayed. This is useful when searches return very large result sets. The default limit prevents overwhelming the interface with too many results.

Pagination: If more results exist than the specified limit, users can navigate through additional pages of results using pagination controls.

Search Management Buttons

Clear Button: Clicking Clear performs two actions: 1. Clears the current result set 2. Clears all populated search fields

This resets the interface to perform a completely new search.

Previous Button: Clicking Previous repopulates the search fields with the criteria from the previous search. This is useful when users want to modify a recent search slightly without re-entering all criteria.

---

Results Table Structure

The EMPI Person Search results table presents a hierarchical view of patient data, with MPIID-level summaries expandable to show underlying database records.

Top-Level Results (MPIID Level)

Column: Alternate View Icons Each MPIID row includes icons for accessing alternate views:

• Whole Record Viewer icon: Opens a comprehensive view showing all linked records and their relationships
• Audit Log icon: Displays the audit trail of changes to records associated with this MPIID
• Composite View icon: Shows the composite record built from multiple data sources for this patient
• History icon: Opens the Record History view showing changes over time

These icons provide quick navigation from search results to detailed investigation tools.

Column: Identifiers For top-level results, this column displays the MPIID (Master Patient Index ID) - the enterprise-wide identifier assigned by EMPI to represent this unique patient across all facilities and systems.

Column: Name Displays the patient's name. At the MPIID level, this typically shows the "best" or most recently updated name from linked records. The format varies based on system configuration but typically shows:

• Family (Last) Name
• Given (First) Name
• Middle Name (if available)

Column: Gender Shows the patient's gender (M, F, or other values as configured in the system).

Column: Date of Birth Displays the patient's date of birth in the format configured for the system (e.g., YYYY-MM-DD).

Column: Address Shows the patient's address, typically including:

• Street address
• City
• State
• Postal/ZIP code

Column: Rank A numerical value indicating how well this result matched the search criteria. Higher rank values indicate closer matches. This is particularly useful when using probabilistic search criteria, as it helps users identify the most likely correct matches among fuzzy results.

Database Record Level (Expanded View)

When users click Show Detail or expand individual results, each database record associated with the MPIID is displayed with indentation below the MPIID row.

Identifiers for Database Records: Instead of showing the MPIID, database record rows display:

• Assigning Authority Name: The organization or system that created this identifier
• Facility: The specific facility where this record was created
• MRN: The Medical Record Number assigned by that facility

This three-part identifier uniquely identifies the database record: Facility + MRN identifies the patient within that facility's system.

Demographic Data for Database Records: Each database record displays its own demographic information, which may differ from other records associated with the same MPIID. These differences are common and represent the data as recorded at different facilities or different times. Variations might include:

• Different name spellings or formats
• Different addresses (patient moved between facilities)
• Different phone numbers
• Slightly different birth dates (data entry errors)

These variations are exactly why EMPI exists - to recognize that these different records represent the same patient despite demographic discrepancies.

Visual Hierarchy

The indentation of database records under their MPIID creates a clear visual hierarchy:

• Unindented rows: MPIID-level summaries representing unique patient identities
• Indented rows: Individual database records from various facilities, all linked to the MPIID above

This visual structure helps users quickly understand which records EMPI has determined represent the same patient.

---

Alternate View Icons in Search Results

Each MPIID-level result row includes four icons that provide single-click access to alternate views. These views offer different perspectives on the patient's data, supporting various investigation and analysis workflows.

Whole Record Viewer Icon

Purpose: The Whole Record Viewer displays all database records associated with a patient in a comprehensive, side-by-side comparison format. It shows not only the records linked to the MPIID, but also records in related linked groups.

When to Use:

• Investigating complex linkage scenarios involving multiple facilities
• Understanding the full scope of a patient's records across the enterprise
• Identifying disagreements between records (fields highlighted when data differs)
• Making informed linking/unlinking decisions
• Visualizing the complete network of records associated with a patient

What It Shows:

• Anchor record (selected record for comparison)
• All records linked to the same MPIID
• Linkage relationships and link weights
• Field-level comparisons with disagreements highlighted
• Link status indicators (manual link, automatic link, non-link)

Available Actions: From the Whole Record Viewer, users can:

• Link or unlink records
• View Record History for any record
• Access Comparison Detail for record pairs
• Review link weights and matching details

Audit Log Icon

Purpose: The Audit Log provides a chronological record of all actions taken on records associated with the MPIID, including system-generated actions and user interventions.

When to Use:

• Investigating who made linking/unlinking decisions and when
• Auditing compliance with organizational policies
• Understanding the sequence of events that led to the current linkage state
• Troubleshooting unexpected linkage outcomes
• Quality assurance reviews

What It Shows:

• Timestamp of each action
• Username of person who took the action (or "SYSTEM" for automated actions)
• Action type (link, unlink, status change, etc.)
• Records involved
• Comments or reasons entered by users

Importance for Compliance: The Audit Log is critical for healthcare compliance, providing the documentation trail required to demonstrate that patient identity management follows established policies and procedures.

Composite View Icon

Purpose: The Composite View displays a virtual "composite record" that represents the most trustworthy or current information compiled from multiple database records. This provides a "single best view" of the patient by intelligently selecting the most reliable data from all linked records.

When to Use:

• Determining the "current truth" about a patient's demographics
• Understanding which source systems provide the most accurate data
• Verifying that composite record definitions are producing expected results
• Identifying data quality issues across facilities
• Supporting data governance initiatives

What It Shows:

• The composite record with property values selected from various source records
• Color-coded indication of which source record contributed each property value:
• Blue: composite winner (this record contributed the value)
• Orange: disagrees with composite
• White: same as winner
• Dark blue: manual override
• The underlying database records used to build the composite
• Rationale for why each property was selected from its source record

Configuration Dependency: The Composite View requires that a composite record definition has been configured. Different composite definitions can be created for different use cases or organizational policies.

History Icon (Record History)

Purpose: The Record History view traces the evolution of patient records over time, showing how demographic information has changed and when those changes occurred.

When to Use:

• Investigating discrepancies between current and historical data
• Understanding how patient information has evolved
• Identifying when specific changes were made
• Researching data quality issues that developed over time
• Comparing how records have changed relative to each other

What It Shows:

• Current versions of records alongside historical versions
• Temporal sequence of changes with timestamps
• Field-level change highlighting (changed values appear in color, typically orange)
• Both single-record history and paired-record comparative history

Accessing Record History:

• From Patient Search: Click the History icon for an MPIID
• Can show history of a single record or compare history of multiple records
• Historical snapshots stored as part of EMPI's demographic audit trail

Navigation Workflow

A typical investigation workflow might be:

1. Start: Use EMPI Person Search to find the patient by demographic criteria 2. Identify: Review search results to confirm the correct MPIID 3. Investigate: Click Whole Record Viewer to see all linked records 4. Compare: Select two records in Whole Record Viewer and navigate to Comparison Detail 5. Audit: Click Audit Log to understand the history of linking decisions 6. Verify: Check Composite View to confirm the "best" data is being used 7. Research: Use Record History to understand how data has changed over time

This workflow demonstrates how EMPI Person Search serves as the entry point for comprehensive patient identity investigation.

---

Comparison Detail Overview

While the Comparison Detail view itself is not directly accessible via an icon in the Patient Search results table, it is frequently accessed as a next step after using Patient Search. Understanding this navigation path is important for complete EMPI workflows.

Navigation Path to Comparison Detail from Patient Search

Path 1: Via Whole Record Viewer 1. Execute EMPI Person Search to find the patient 2. Click the Whole Record Viewer icon for the MPIID of interest 3. In the Whole Record Viewer, click the Comparison Detail icon for any pair of records 4. The Comparison Detail view opens showing the two selected records side by side

Path 2: Via Worklist (Indirect) 1. Execute EMPI Person Search to identify the patient's MPIID 2. Navigate to the Worklist separately 3. Filter the Worklist for record pairs involving the identified MPIID 4. Select a record pair to view in Comparison Detail

Purpose of Comparison Detail

The Comparison Detail page allows users to view the details of two records side by side to help determine if they represent the same patient. This side-by-side comparison is the primary tool for making linking and unlinking decisions.

What Comparison Detail Displays

Original Properties Section: Shows the core demographic fields for both records:

• MPIID
• Data Source
• Facility
• MRN
• Name (Given, Family)
• SSN
• Gender
• Birth Date/Time
• Identifiers (alternate identifiers with assigning authority)
• Addresses (with expansion for multiple addresses)
• Telecoms (phone numbers, email)

Normalized Properties Section: Shows the normalized versions of demographic data after preprocessing:

• Demonstrates how names, addresses, and other fields are standardized
• Allows users to understand how matching algorithms see the data
• Helpful for troubleshooting why records did or did not match

Linkage Information Section: Displays detailed information about the relationship between the two records:

• Review Threshold
• Autolink Threshold
• Validate Threshold
• Link Weight (the calculated matching score)
• Agreement Pattern (which fields agreed/disagreed)
• Link Status (Link, Non-Link, etc.)
• Internal Link Status
• Link Reason (Manual, Automatic, Rule-based)
• Secondary Reason
• Link Comment (user-entered notes)
• Username (who created manual links)
• Assigned To (current assignee for review)
• Assignment Comment
• Custom Status
• Custom Status Comment

Additional Sections (Expandable):

• Link Weight by Parameters: Shows how individual parameters contributed to the overall link weight
• Other Link: Information about other records linked to these records
• Other Link to Validate: Related records requiring validation
• Other Non-Link to Review: Non-links that should be reviewed
• Warnings: Any system-generated warnings about the linkage
• Link-Key Index entries: Technical details about matching index entries

Color Coding in Comparison Detail

Fields are typically highlighted when they differ between the two records, making it easy to spot disagreements:

• Matching values: no highlighting
• Differing values: highlighted (typically in color)
• Missing values: may be indicated with empty cells or special markers

Actions Available in Comparison Detail

From the Comparison Detail view, users can take actions on the record pair:

• Same: Link the two records (mark as representing the same patient)
• A is Different: Mark as non-link (different patients)
• B is Different: Mark as non-link (different patients)
• Reset: Clear any custom status or assignment
• Assign to User: Assign to a specific user for review
• Change Status: Set a custom status for workflow tracking
• Colors: Configure color preferences for the display
• Clear: Reset the form
• Previous: Return to the previous view

Use Case Example

A typical use case demonstrating the path from Person Search to Comparison Detail:

Scenario: A patient calls to report they are seeing duplicate records in the patient portal.

Investigation Steps: 1. Use EMPI Person Search to search for the patient by name and DOB 2. Search returns two different MPIIDs for what should be the same patient 3. Click Whole Record Viewer icon for the first MPIID 4. Observe that records under this MPIID look legitimate 5. Click Whole Record Viewer icon for the second MPIID 6. Observe records under the second MPIID also look legitimate 7. From Whole Record Viewer, select records from both MPIIDs and open Comparison Detail 8. Review side-by-side comparison of the two records 9. Identify slight spelling variation in last name (Smith vs. Smyth) 10. Determine records represent the same patient 11. Click "Same" to manually link the records 12. Enter comment explaining the manual link decision 13. Save the change

This workflow demonstrates how EMPI Person Search serves as the starting point for investigating and resolving patient identity issues.

---