T4.1: Troubleshoots EMPI Issues

Overview

The Composite View in InterSystems EMPI presents a unified patient record by aggregating data from multiple linked source records. When users report missing data in the Composite View, the issue typically relates to trust tier configuration, missing or disconnected data sources, aging factor settings, or linkage problems. Resolving these issues requires systematic investigation of the data pipeline, linkage status, and composite view configuration.

The Composite View is consumed by downstream clinical applications such as Clinical Viewer, and incomplete data can impact clinical decision-making. Understanding the mechanisms that control which data appears in the Composite View is essential for effective troubleshooting.

Trust Tier Configuration

The trust tier determines which data source's values are selected for display in the Composite View when multiple linked records provide conflicting information. Each facility is assigned a trust tier value, with lower numbers indicating higher trust.

• Trust Tier Assignment: Navigate to Composite Record Definition in the Management Portal to review and modify trust tier assignments for each facility
• Missing Trust Tier: If a facility has no trust tier assigned, its data may be excluded from the Composite View
• Trust Tier Conflicts: When multiple sources have the same trust tier, the most recent data (based on timestamps) is typically selected
• Verify Settings: Check that expected data sources have appropriate trust tier values and that the trust tier ordering aligns with business requirements

Data Source Registration

Missing data may indicate that a facility is not properly registered or is not actively sending data:

• Facility Registry: Verify that the facility appears in the Facility Registry with correct settings
• Production Status: Check that the Edge Gateway or source system production is running and actively sending messages
• Message Flow: Use the Production Message Viewer to confirm that messages from the facility are being received and processed
• Error Messages: Review the Event Log for errors related to the facility's data feed

Aging Factor and Data Freshness

The Composite View may prioritize recent data over older data based on aging factor configuration:

• Aging Factor Setting: Controls how the timestamp of data affects its selection for the Composite View
• Expired Data: Old records may be de-prioritized or excluded if newer data is available from higher-trust sources
• Review Timestamps: Use the Whole Record Viewer to examine the timestamps of source records and determine why certain data is not appearing

Linkage Status

Records that should be linked but are not will result in incomplete Composite Views:

• Worklist Review: Check the Worklist for record pairs that require manual linking
• Link Conflicts: Resolve overlay, overlap, and open-chaining issues that prevent proper linkage
• Record History: Use the Record History page to trace linkage changes and identify when unlinking occurred

---

Overview

Medical record number (MRN) re-use is the most critical patient safety issue in EMPI operations. It occurs when a facility assigns the same MRN to two different patients, either sequentially over time or due to registration errors. When MRN re-use occurs, patients may see another patient's clinical data, creating severe patient safety and privacy violations. According to sample exam question Q15, MRN re-use at a facility is the most likely scenario in which a patient would see another patient's data.

Identifying MRN re-use quickly is essential to minimize patient safety risk. The Worklist, Record History page, and comparison tools provide the evidence needed to detect and confirm MRN re-use incidents.

Worklist Pattern Recognition

MRN re-use typically manifests in the Worklist as record pairs with the following characteristics:

• Identical MRNs: Both records have the same MRN from the same facility
• Conflicting Demographics: Different patient names, dates of birth, or Social Security numbers despite same MRN
• Deterministic Category: Worklist entries appear in the Deterministic category due to conflicting identifiers (per sample Q11, conflicting SSNs or other deterministic IDs create Deterministic Worklist entries)
• Domain Conflict: Link Reason shows "Domain Conflict" when MRNs match but other demographics conflict

Record History Investigation

The Record History page provides a timeline of changes to individual records and record pairs:

• Access Record History: From the Comparison Detail page, select the Record History link to view all changes for a specific record or pair
• MRN Changes: Look for entries showing MRN updates or corrections from the source facility
• Link/Unlink Events: Trace when records were linked or unlinked, which may indicate recognition of MRN re-use
• User Actions: Identify manual interventions by EMPI operators addressing MRN conflicts

Comparison Detail Analysis

Use the Comparison Detail page to examine record pairs flagged for potential MRN re-use:

• Original Properties: Compare all demographic fields between the two records
• Normalized Properties: Review normalized values to confirm that the differences are substantive, not just formatting variations
• Warnings Section: Check for warnings related to overlay or overlap problems
• Link-Key Index: Examine link-key index values to determine if other matching logic detected similarities

Facility Communication

Once MRN re-use is suspected:

• Contact Facility: Report the issue to the facility's health information management (HIM) department
• Request Investigation: Ask the facility to review their MRN assignment process and patient registration records
• Document Findings: Record all evidence of MRN re-use in the Audit Log with detailed comments

---

Overview

When MRN re-use is confirmed, immediate corrective action is required to protect patient safety. The primary goal is to separate the incorrectly linked records and ensure that each patient's data is associated only with the correct patient identity. This requires coordination between EMPI operators and the source facility's registration staff.

The corrective process has two phases: immediate remediation in EMPI to prevent incorrect data display, and root cause correction at the source facility to prevent recurrence.

Immediate EMPI Remediation

1. Unlink Records: Use the Whole Record Viewer or Comparison Detail page to manually unlink the two records that were incorrectly linked due to MRN re-use

• Select the "Unlink" action button on one of the records
• Click "Update" to execute the unlink action
• Confirm the action and add a detailed comment explaining the MRN re-use issue

2. Verify Composite View: After unlinking, verify that each patient's Composite View now displays only the correct patient's data

3. Check Other Linkages: Use the "Other" sections in the Comparison Detail page to identify any additional records that may have been incorrectly linked due to the MRN re-use, and unlink them as well

4. Document in Audit Log: All unlink actions should include comprehensive comments documenting the MRN re-use issue, the records involved, and the corrective action taken

Source Facility Correction

The facility must correct the root cause:

• MRN Correction: The facility should assign a new, unique MRN to the patient who received the duplicate MRN
• Data Retransmission: The facility must retransmit all records for the affected patient(s) with the corrected MRN
• Process Review: The facility should review their MRN assignment process to prevent future re-use incidents

EMPI Re-processing

After the facility sends corrected data:

• Monitor Incoming Messages: Watch for the corrected records in the Production Message Viewer
• Verify New Links: Confirm that the corrected records link appropriately to the correct patient identity
• Worklist Cleanup: Verify that MRN re-use pairs are resolved and removed from the Worklist

Prevention

• Facility Training: Work with facilities to implement MRN assignment policies that prevent re-use
• Monitoring: Implement regular Worklist reviews to detect MRN re-use patterns early
• Agreement Functions: Consider implementing MRN agreement functions that flag potential re-use based on demographic mismatches

---

Overview

Linkage builds re-evaluate all patient records against the current linkage definition to identify new links, update link weights, and resolve conflicts. Builds are necessary after making changes to the linkage definition parameters, thresholds, or algorithms. Managing linkage builds in a production environment requires careful planning to minimize system impact while ensuring data accuracy.

According to sample exam question Q4, linkage builds are initiated from the Definition Designer menu option in the Management Portal.

When to Perform Linkage Builds

Linkage builds are required after:

• Threshold Changes: Adjusting review, autolink, or validate thresholds
• Parameter Modifications: Adding, removing, or modifying weighted parameters
• Agreement Function Changes: Updating normalization, agreement, or blocking functions
• Link-Key Index Changes: Adding or modifying link-key indexes
• Algorithm Updates: Changing linkage type or algorithm settings

Build Types

• Full Build: Re-evaluates all records in the system against the current linkage definition. Required after major definition changes. Can take hours or days depending on system size.
• Incremental Build: Re-evaluates only records that have changed since the last build. Faster, suitable for minor definition adjustments.
• Test Build: Run a build on a subset of records to validate definition changes before running a full production build

Initiating a Linkage Build

1. Navigate to Person Index > Definition Designer in the Management Portal 2. Make necessary changes to the linkage definition 3. Save the definition changes 4. Click the Build button to initiate the linkage build 5. Choose build type (full or incremental) 6. Confirm the build initiation

Monitoring Build Progress

• Build Log: Navigate to Person Index > Build Log to view build status, progress percentage, and estimated completion time
• Event Log: Check the production Event Log for build-related messages, warnings, and errors
• System Performance: Monitor CPU, memory, and disk I/O during the build to ensure system stability

Production Considerations

• Schedule Builds: Run linkage builds during off-peak hours (evenings, weekends) to minimize impact on production operations
• Resource Allocation: Ensure sufficient system resources (CPU, memory, disk space) are available before initiating a build
• Communication: Notify users and stakeholders of planned builds and expected system slowdowns
• Build Failure: If a build fails, review the Build Log and Event Log for error messages, address the root cause, and restart the build

Post-Build Validation

After a linkage build completes:

• Worklist Review: Check the Worklist for new entries that require manual review
• Link Statistics: Review link counts and distributions to verify expected results
• Spot Checks: Examine sample records to confirm that linkage behavior matches expectations

---

Overview

System slowdowns in EMPI can result from database growth, inefficient queries, production processing bottlenecks, or resource exhaustion. Diagnosing slowdowns requires systematic investigation of database performance, production throughput, and system resource utilization. Effective troubleshooting identifies the root cause and guides appropriate remediation strategies.

Database Growth and Performance

As EMPI accumulates patient records, linkage data, and audit logs, database size increases, which can impact query performance:

• Database Size Monitoring: Use database tools to track database size over time (covered in T4.4)
• Index Maintenance: Ensure that database indexes are properly maintained and tuned
• Table Growth: Identify tables experiencing rapid growth (audit log, linkage pairs)
• Archival Strategy: Implement data archival or purge strategies for historical audit data

Query Performance Analysis

Slow queries can degrade user experience:

• Query Performance Tools: Use InterSystems IRIS SQL query performance tools to identify slow-running queries
• Execution Plans: Analyze SQL execution plans to identify missing indexes or inefficient joins
• Parameter Tuning: Adjust query parameters or rewrite queries for better performance
• Caching: Leverage caching mechanisms to reduce redundant query execution

Production Queue Analysis

Production message queues can indicate processing bottlenecks:

• Message Viewer: Use the Production Message Viewer to check for queued messages awaiting processing
• Queue Depth: Monitor queue depth for all production components (services, processes, operations)
• Pool Size Settings: Verify that Pool Size settings in production components are adequate for message volume
• Bottleneck Identification: Identify which production component has the longest queues, indicating a processing bottleneck

Resource Utilization

System resource exhaustion can cause slowdowns:

• CPU Utilization: Monitor CPU usage to identify periods of high utilization correlated with slowdowns
• Memory Usage: Check memory usage and swap activity; insufficient memory causes paging and degrades performance
• Disk I/O: Monitor disk read/write rates; slow disk I/O impacts database and production performance
• Network Latency: For distributed deployments, check network latency between EMPI, Registry, and Edge Gateways

Common Causes and Remediation

| Symptom | Likely Cause | Remediation | |---------|--------------|-------------| | Slow Worklist queries | Database size, missing indexes | Add indexes, archive old data | | Production message backlogs | Insufficient Pool Size | Increase Pool Size settings | | High CPU during builds | Linkage build in progress | Schedule builds during off-peak hours | | Slow Composite View display | Complex linkage graphs | Optimize linkage definition, reduce open-chaining | | General slowness | Audit log growth | Implement automated audit log purge (T4.4) |

Escalation

If troubleshooting does not identify a clear cause:

• InterSystems WRC: Contact the InterSystems Worldwide Response Center with system diagnostics, pButtons output, and detailed symptom descriptions
• Performance Tuning: Request a performance tuning engagement to optimize system configuration
• Capacity Planning: Evaluate whether system capacity is sufficient for current and projected data volumes

---