T3.5: Explains Worklist Actions

Worklist actions are the mechanisms by which users resolve record pairs that appear on the worklist. Each action changes the linking relationship between two records and/or their MPIID assignments. Understanding which actions are available in different situations and what each action accomplishes is fundamental to effective worklist management.

The worklist interface displays action buttons in the rightmost column of each row. The specific buttons visible vary depending on the current link status, category, and MPIID configuration of the record pair. Users can apply actions to individual pairs by clicking the action button for that row, or apply the same action to multiple pairs simultaneously by checking the checkboxes at the beginning or end of each row and then clicking an action button.

Action Execution Process: When a user clicks an action button, the action is selected but not immediately executed. This allows users to: 1. Select actions for multiple record pairs 2. Review the pending actions 3. Cancel actions if desired (click the button again or select a different action) 4. Execute all selected actions together by clicking a confirmation button

This design prevents accidental actions and allows batch processing of similar worklist items.

Audit Trail Integration: All worklist actions are automatically recorded in the EMPI audit log (unless skipAudit is enabled). The audit log captures:

• What action was taken (Link, Unlink, etc.)
• Which records were affected
• Who performed the action
• When the action was performed
• Any comment associated with the action

This audit trail provides accountability, supports compliance requirements, and enables troubleshooting when linkage issues are discovered later.

Comment Documentation: The Comment text box at the top of the worklist allows users to enter a comment that will be associated with the action. Comments should explain the rationale for the decision, especially for non-obvious cases. For example:

• "Same patient - confirmed via phone call with facility"
• "Different patients - SSN mismatch"
• "Duplicate sent to Memorial Hospital for MRN merge on 2024-03-15"

Once a comment is entered and applied to an action, it remains in the comment field until manually cleared using the "Clear Comment" button. Users can also select the "Previous Comment" checkbox to reuse the last comment for repetitive actions.

---

The primary worklist actions modify the linking relationship between record pairs. The specific action buttons available depend on the current status of the pair.

Same / Link Action (button icon: chain link symbol):

• Purpose: Links two records together, indicating they represent the same person
• Effect: Creates a link between the records; if they have different MPIIDs, assigns one record the MPIID of the other
• When Available: Appears for non-linked pairs (potential links, overlays, some duplicates)
• Cascading Impact: By linking record A to record B, you are also linking record A to all records already linked to record B
• Common Use Cases: Confirming that two records in the Review category represent the same person; resolving an overlay by linking records that already share an MPIID

Different / Unlink Action (button icon: broken chain symbol):

• Purpose: Unlinks two records, indicating they represent different people
• Effect: Removes the link between the records; if they have the same MPIID and the "Synchronize MPIID and Linkage Status" option is enabled, assigns a new MPIID to one of the records
• When Available: Appears for linked pairs (validated links, overlaps)
• Warning: Unlinking without MPIID reassignment can create overlays (two unlinked records with the same MPIID)
• Common Use Cases: Correcting an incorrect automatic link; resolving an overlap by unlinking records with different MPIIDs

A is Different Action (button icon: broken chain with "A" indicator):

• Purpose: Unlinks two records AND assigns a new MPIID to record A
• Effect:

1. Unlinks records A and B 2. Assigns a new MPIID to record A 3. Propagates the new MPIID to any records that had the same MPIID as A, except for record B and any records linked to B 4. Removes all links between record A (and its linked group) and record B (and its linked group)

• When Available: Appears for overlays and some duplicate scenarios where MPIID reassignment is needed
• Common Use Cases: Resolving overlays where you want to separate record A into its own linked group; resolving duplicates where you've determined the records represent different people

B is Different Action (button icon: broken chain with "B" indicator):

• Purpose: Unlinks two records AND assigns a new MPIID to record B
• Effect: Same as "A is Different" but assigns new MPIID to record B instead of record A
• When Available: Appears for overlays and some duplicate scenarios where MPIID reassignment is needed
• Strategic Consideration: Choose "A is Different" vs "B is Different" based on which record appears to be the "intruder" in the linked group—assign the new MPIID to the record that doesn't belong

Reset Action (button icon: reset/undo symbol):

• Purpose: Undoes any manual changes made to the link status of the record pair
• Effect: Returns the pair to its system-determined link status (based on link weight, deterministic identifiers, rules, etc.)
• When Available: Appears after manual link or unlink actions have been applied
• Important Note: If "Synchronize MPIID and Linkage Status" is enabled, reset may cause records to be given different MPIIDs
• Common Use Cases: Correcting a mistaken manual action; reverting to system-determined status after circumstances change

Action Confirmation Pop-up: Upon clicking the Update button (or equivalent) after selecting actions, a pop-up appears showing:

• What actions will be taken
• Which records are affected
• The comment (if any) that will be entered in the audit log
• Note: The pop-up may not show all cascading effects (e.g., all records that will be linked transitively)

Users can click OK to accept the actions or Cancel to reject them. If accepted, another pop-up displays the results, listing successful and unsuccessful actions (there will likely be more actions listed than in the confirmation pop-up due to cascading effects).

Previously Completed Actions: Previously completed manual link and unlink actions are indicated on the action buttons with a solid black square. For example, if record B has been manually linked to record A, a solid black square appears around the link symbol for record B.

---

In addition to the primary linking actions, some EMPI configurations may provide secondary or conditional actions that support phased workflow:

Possible Match:

• Purpose: Flag a record pair as potentially representing the same person, but not link them yet
• Effect: May change the link status or category of the pair, or assign a custom status
• Use Case: When a user believes two records might be the same person but wants to gather more information before making a final decision (e.g., waiting for facility to confirm demographics)
• Workflow Integration: Pairs marked "Possible Match" might be filtered and batch-processed later after additional research

Not a Match:

• Purpose: Document that two records have been reviewed and determined to represent different people
• Effect: May change the link status to definitive non-match, preventing the pair from appearing on future worklists
• Use Case: When a user has definitively determined that two high-scoring potential links represent different people and wants to prevent the pair from reappearing on the worklist
• Distinction from "Different": "Not a Match" is typically used for pairs that aren't currently linked, while "Different/Unlink" is for pairs that are already linked

Configuration Variability: The availability and behavior of these secondary actions may depend on:

• Specific EMPI version and configuration
• Custom rules or workflow implementations
• Organizational policies about phased decision-making
• User role and permissions

Best Practices: When secondary actions are available:

• Use them consistently according to organizational definitions
• Document decision criteria for when to use "Possible Match" vs "Link" vs "Not a Match"
• Include explanatory comments when using secondary actions
• Establish follow-up procedures for pairs marked "Possible Match"
• Monitor conversion rates (e.g., what percentage of "Possible Match" pairs are eventually linked)

---

Custom Status is a powerful workflow management feature that allows organizations to track worklist items through multiple stages of resolution.

Creating Custom Statuses: Custom status values must be created in the EMPI configuration before they can be assigned. This is typically done through the Configuration menu or Definition Designer. Common custom status values include:

• "Under Review"
• "Sent to Hospital"
• "Awaiting MRN Merge"
• "Escalated to Specialist"
• "Pending Patient Verification"
• "Resolved - Awaiting Confirmation"

Assigning Custom Status: To assign a custom status to a worklist item: 1. Click the "Change" button in the Custom Status column for the desired row 2. The "Assign Custom Status" pop-up window appears, displaying the names and MRNs of the records as a subtitle 3. Select the desired custom status from the drop-down list 4. Enter a comment in the Comment field, or click "Use Default" to use the default comment "Change custom status" 5. Click OK to apply

After assignment, the custom status value appears in the Custom Status column for that worklist item.

Filtering by Custom Status: The search panel provides two custom status filter options:

• Custom Status Includes: Display only worklist items with the selected custom status
• Custom Status Excludes: Hide worklist items with the selected custom status

This supports workflows like:

• "Show me all items with status 'Under Review' assigned to me" (active work queue)
• "Show me all Duplicates except those with status 'Sent to Hospital'" (items needing hospital notification)
• "Show me all items with status 'Escalated to Specialist'" (specialist's queue)

Multi-Stage Workflow Example:

A complex duplicate resolution workflow might use custom statuses to track progress:

1. Initial Identification: Duplicate appears on worklist with no custom status 2. First Review: Staff reviews the duplicate, confirms it's valid, assigns status "Verified Duplicate" 3. Hospital Notification: Coordinator sends duplicate information to hospital, assigns status "Sent to Hospital", adds comment with date and contact person 4. Follow-Up Tracking: If hospital doesn't respond within 30 days, item is reassigned to status "Follow-Up Required" 5. Resolution Pending: Hospital confirms MRN merge is scheduled, status changes to "Pending MRN Merge", comment includes scheduled date 6. Completion: After MRN merge is confirmed, worklist item is resolved and removed from worklist

At each stage, staff can filter by custom status to see items requiring specific action.

Reporting and Metrics: Custom status values enable tracking of operational metrics:

• How many items are in each workflow stage
• Average time items spend in each status
• Conversion rates between statuses
• Bottlenecks (statuses where items accumulate)
• Staff productivity (items moved through workflow per user)

Best Practices for Custom Status:

• Limit the number of status values (5-10) to keep workflows manageable
• Use clear, descriptive names that indicate action needed
• Document what each status means and when it should be assigned
• Establish standard operating procedures for status transitions
• Review status usage regularly and retire unused values
• Train all staff on status definitions and workflow expectations

---

The Assignment feature allows worklist items to be assigned to specific users, supporting team-based workflow management and individual accountability.

Assigning to a User: To assign a worklist item to a user: 1. Click the "Assign" button associated with the worklist item 2. The "Assign User Tasks" pop-up window appears, displaying the names and MRNs of the records as a subtitle 3. Select the desired user from the drop-down list (users must be added to the system before they appear in the list) 4. Enter a comment in the Comment field, or click "Use Default" to use the default comment "Assign user" 5. Click OK to apply

After assignment, the assignee's username appears next to the "Assign" button on the worklist item.

User Management: Users must be created in the EMPI configuration (typically through the Configuration menu) before they can be selected for assignment. User configuration typically includes:

• Username
• Full name
• Role/permissions
• Email address (for notifications, if configured)

Filtering by Assignment: The Assignment filter in the search panel allows users to see specific assignment groups:

• Default: Automatically displays the current user's username, showing items assigned to you
• Specific User: Select a different username to see items assigned to that user (useful for supervisors monitoring team member workloads)
• (unassigned): Shows only worklist items not assigned to any user (available work for distribution)

Workload Distribution Strategies:

Round-Robin Distribution: Supervisor assigns batches of similar items equally across team members

• First 20 Review items to User A
• Next 20 Review items to User B
• Next 20 Review items to User C
• Ensures balanced workload

Expertise-Based Distribution: Assign items based on complexity and staff skill level

• Standard Review items to junior staff
• Overlap/Overlay items to senior staff
• Duplicate items requiring hospital coordination to dedicated liaison

Source-Based Distribution: Assign items based on data source familiarity

• Memorial Hospital items to User A (their liaison)
• City Clinic items to User B
• Regional Network items to User C

Self-Assignment Model: Leave items unassigned; staff members claim items as they work

• Users filter for (unassigned) items
• Select and assign items to themselves
• Prevents duplicate effort (items disappear from unassigned queue when claimed)
• Requires discipline to ensure all items are eventually claimed

Reassignment: Items can be reassigned from one user to another: 1. Filter by Assignment = 2. Select items to reassign 3. Click "Assign" button 4. Select new user from drop-down 5. Comment should explain reason for reassignment

Supervisor Monitoring: Supervisors can monitor team performance by:

• Filtering by each team member's assignment to see their current queue size
• Tracking Time Updated to see which assigned items haven't been touched recently
• Reviewing comments to understand decision quality
• Using assignment in combination with custom status to see workflow progress

Benefits of Assignment:

• Accountability: Clear responsibility for each worklist item
• Workload Visibility: Supervisors can see who has how much work
• Priority Management: Individuals can prioritize within their assigned items
• Performance Tracking: Assignment history enables productivity metrics
• Reduced Duplication: Prevents multiple users from working the same item simultaneously

Assignment Best Practices:

• Assign items soon after they appear on worklist (prevent backlog of unassigned items)
• Balance workload across team members
• Match item complexity to staff skill level
• Reassign if a user is out sick or on vacation
• Review assignment distribution regularly to ensure fairness
• Use in combination with Custom Status for comprehensive workflow tracking

---

The worklist supports batch actions, allowing users to apply the same action to multiple record pairs at once, significantly improving efficiency for repetitive tasks.

Multi-Selection Mechanism: Each worklist row has checkboxes at the far-left and far-right ends. Users can:

• Click individual checkboxes to select specific rows
• Click the checkbox in the header row to select ALL rows currently displayed
• Mix and match selections as needed

Applying Batch Actions: 1. Check the boxes for all rows you want to process with the same action 2. Click the desired action button (e.g., "Link", "Different", "Assign") 3. The system will apply that action to all checked rows 4. A confirmation pop-up shows all actions that will be taken 5. Click OK to execute or Cancel to abort

Batch Action Use Cases:

Scenario 1 - Linking Similar Review Items: After reviewing 15 record pairs that all clearly represent the same people:

• Check all 15 rows
• Click "Link" button
• Enter comment: "Batch link - all confirmed same patient via name/DOB/SSN match"
• Click OK
• All 15 pairs are linked in one operation

Scenario 2 - Assigning Duplicates for Hospital Notification:

• Filter: Category = Duplicate, Data Source = Memorial Hospital, Custom Status Excludes = "Sent to Hospital"
• Check all rows (25 duplicates)
• Click "Change" in Custom Status column
• Select status = "Sent to Hospital"
• Enter comment: "Batch sent to Memorial Hospital for MRN merge on 2024-03-20"
• Click OK
• All 25 duplicates now have the custom status

Scenario 3 - Distributing Workload:

• Filter: Category = Review, Assignment = (unassigned), Order by Descending Link Weight
• Check first 20 rows
• Click "Assign"
• Select User A
• Click OK
• Repeat for next 20 rows, assigning to User B
• Efficiently distributes 40 items to two team members

Limitations and Cautions:

• Batch actions should only be used for genuinely similar items
• Review the action confirmation carefully—batch actions affect many records
• Different action types may not all be available for batch processing
• Some complex actions (A is Different, B is Different) may require individual consideration
• Audit log will show individual entries for each pair processed, not a single batch entry

Performance Considerations:

• Applying actions to many pairs (100+) may take noticeable time
• System may process batch actions asynchronously (display progress indicator)
• Very large batch operations may be better performed during off-peak hours
• If batch operation fails partway through, audit log shows which actions completed

Best Practices for Batch Actions:

• Review a few examples individually before batch-processing many similar items
• Use consistent, descriptive comments for batch actions
• Limit batch size to manageable numbers (20-50 items) unless very confident
• Verify results after batch operation completes
• Document standard scenarios where batch actions are appropriate
• Train staff on when batch actions are safe vs when individual review is needed

---

The Whole Record Viewer is an essential tool for understanding complex linkage relationships and identifying worklist records with more than one link or potential link. It provides a comprehensive view of a record's entire linkage network.

Accessing Whole Record Viewer: Click the Whole Record Viewer icon in the Alternate Views column of any worklist row. This opens a new view displaying:

• Anchor record: The original record selected (typically displayed at the top)
• Linked records: All records currently linked to the anchor record
• Potential links: Records that have high link weights with the anchor but aren't currently linked
• Link details: Link weight, agreement pattern, link status, link reason for each pair

Interface Layout: The Whole Record Viewer typically displays:

• Anchor record section with full demographic details
• List of related records (both linked and potential links)
• For each related record:
• Summary demographic information
• Link weight and agreement pattern
• Link status (Link, Potential Link, Non-Link)
• Action buttons (Link, Unlink, A is Different, B is Different)
• Indicators for conflicts (overlay, overlap, open-chaining)

Identifying Records with Multiple Links: The Whole Record Viewer makes it immediately obvious when a record has multiple links or potential links:

• Simple case: Anchor record with 3 linked records → straightforward linked group
• Complex case: Anchor record with 5 linked records, 3 potential links, and 2 overlap indicators → requires careful analysis

Using Whole Record Viewer for Open-Chaining: Open-chaining scenarios are particularly difficult to resolve without the Whole Record Viewer:

Example:

• Record A is linked to Record B
• Record B is linked to Record C
• Record A is NOT linked to Record C (open chain)

In the Whole Record Viewer with Record B as anchor:

• You see Record A listed as linked
• You see Record C listed as linked
• You can switch anchor to Record A and see that Record C is listed as a potential link or non-link
• This visualization helps you determine whether A and C should be linked (completing the chain) or whether one of the existing links should be broken

Resolution Strategy for Open-Chaining: 1. Examine all three records' demographics carefully 2. Determine which records truly represent the same person 3. Options:

• Link A to C if all three are the same person (completes the chain)
• Unlink A from B if A and B are different people
• Unlink B from C if B and C are different people

4. Use Whole Record Viewer to see immediate effect of any action before confirming

Using Whole Record Viewer for Overlaps: Overlaps (linked records with different MPIIDs) are clearly visible in the Whole Record Viewer:

• Anchor record has MPIID 12345
• Linked Record X has MPIID 67890 (OVERLAP indicator)
• User can see all records sharing each MPIID
• Helps determine which MPIID should be retained and which should be changed

Update Button and Multiple Actions: The Whole Record Viewer allows queuing multiple actions: 1. Click Link button for Record D 2. Click Unlink button for Record E 3. Click A is Different for Record F 4. All actions are selected but not executed 5. Click "Update" button to execute all actions together 6. Confirmation pop-up shows all pending actions 7. Results pop-up shows outcomes of all actions

Undo Capability: Before clicking Update, any selected action can be undone by:

• Clicking the same action button again (deselects it)
• Clicking a different action button (replaces the action)
• Navigating away from the Whole Record Viewer without clicking Update (discards all pending actions)

When to Use Whole Record Viewer:

• Any worklist item in Open-chaining category
• Any worklist item in Overlap category
• Review items where the two displayed records are both linked to many other records
• Investigating suspected data quality issues affecting multiple related records
• Training scenarios to help users understand transitive linking

Whole Record Viewer vs Other Tools:

• vs Comparison Detail: Comparison Detail shows side-by-side demographics for two records; Whole Record Viewer shows entire linkage network for one record
• vs Linkage Graph: Linkage Graph provides visual network diagram; Whole Record Viewer provides actionable interface for making changes
• vs Worklist: Worklist shows individual pairs; Whole Record Viewer shows complete context for all pairs involving an anchor record

---

Certain worklist categories—Overlap, Overlay, Open-chaining, and Deterministic conflicts—represent linkage conflict situations that need careful research by experienced staff members. These categories indicate violations of EMPI integrity rules or logical contradictions that require expert judgment to resolve correctly.

Why Conflicts Require Expert Staff:

Complexity: Conflict categories often involve multiple records, cascading relationships, and non-obvious implications. Resolving them incorrectly can create additional conflicts affecting many records.

Root Cause Analysis: Conflicts often indicate:

• Previous incorrect manual linking/unlinking decisions
• System configuration issues
• Data quality problems in source systems
• Complex family relationships or identity scenarios (twins, parent/child with same name)

Risk of Cascading Errors: Incorrect resolution of conflicts can:

• Create new overlaps or overlays
• Break correct links, creating false negatives
• Propagate MPIID changes to many records inappropriately
• Generate additional worklist items that are harder to resolve

Overlap Category Expertise Requirements:

Understanding: Staff must understand that overlap (linked records with different MPIIDs) violates the fundamental EMPI rule: if records are linked, they must share the same MPIID.

Analysis Required:

• How did the overlap occur? (Often from "A is Different" or "B is Different" actions that didn't account for all linked records)
• Which MPIID is correct for the linked group?
• Are there additional records linked to either MPIID that need consideration?
• Will resolving this overlap create new overlaps or overlays with other records?

Resolution Expertise: Experienced staff know to:

• Use Whole Record Viewer to see complete linkage context
• Verify all records in both MPIID groups before making changes
• Understand the propagation effects of "Same" vs "Different" actions
• Document the decision rationale in comments
• Follow up to verify resolution was successful

Overlay Category Expertise Requirements:

Understanding: Staff must understand that overlay (unlinked records with same MPIID) violates the rule: if records share the same MPIID, they must be linked.

Analysis Required:

• How did the overlay occur? (Often from "Different/Unlink" action without MPIID reassignment)
• Do the records truly represent the same person? (Should they be linked?)
• If they represent different people, which record should keep the MPIID and which should get a new one?
• Are there other records sharing this MPIID that need consideration?

Resolution Expertise: Experienced staff know to:

• Carefully review demographics to determine if records are truly the same person
• If same person: Use "Same/Link" action (straightforward resolution)
• If different people: Use "A is Different" or "B is Different" to unlink and assign new MPIID
• Consider which record is the "intruder" (gets new MPIID) vs the "legitimate" record (keeps MPIID)
• Check for potential duplicates if records are from same facility

Open-Chaining Category Expertise Requirements:

Understanding: Open-chaining creates a logical impossibility—if A=B and B=C, then A must equal C, but the system shows A≠C.

Analysis Required:

• Review all three (or more) records involved in the chain
• Determine which relationships are correct and which are incorrect
• Consider: Are all records the same person? Are some different? Is there a data quality issue?

Common Scenarios:

• True Match: All records are the same person, so A-C link should be created (complete the chain)
• False Link: One of the existing links is incorrect, so it should be broken
• Twins/Family: Records are for related individuals (twins, parent/child) with similar demographics

Resolution Expertise: Experienced staff know to:

• Use Whole Record Viewer to visualize all relationships
• Review original source data if available
• Contact source facilities to verify identity if necessary
• Consider agreement patterns and link weights for all pairs
• Make conservative decisions (prefer unlinking to incorrect linking if uncertain)
• Escalate to technical specialist if pattern suggests system configuration issue

Deterministic Conflict Category Expertise Requirements:

Understanding: Deterministic identifiers are configured to force linking or unlinking. Conflicts occur when deterministic link and deterministic unlink rules are both satisfied by the same pair.

Example:

• Deterministic link rule: Same SSN must link
• Deterministic unlink rule: Different MRNs from same facility must not link
• Conflict: Two records from same facility with different MRNs but same SSN

Resolution Expertise: Experienced staff know to:

• Understand which deterministic identifiers are configured in the system
• Investigate data quality—is the SSN correct in both records? Are the MRNs correct?
• Escalate to technical specialist if rules need reconfiguration
• Contact source facility to verify correct identifiers
• Document which identifier is believed to be incorrect and why

Escalation Criteria: Even experienced staff should escalate conflict category items when:

• Multiple overlaps or overlays involve the same MPIID
• Open-chaining involves more than 3-4 records
• Deterministic conflicts recur frequently (suggests configuration issue)
• Resolution attempts create new conflicts
• Suspected data quality issue affects multiple worklist items
• Unusual pattern suggests family relationship or identity scenario beyond normal experience

Training for Conflict Categories: Organizations should provide specialized training for staff who handle conflict categories:

• Understanding EMPI linking rules and MPIID logic
• Using Whole Record Viewer and Linkage Graph effectively
• Recognizing common patterns (previous incorrect actions, data quality issues, twins)
• Following decision trees for systematic analysis
• Documentation requirements for complex decisions
• When and how to escalate

---

Worklist actions often have cascading effects beyond the immediately visible record pair. Understanding these impacts is critical for preventing unintended consequences.

Transitive Linking Principle: InterSystems EMPI implements transitive linking: if A is linked to B, and B is linked to C, then A is automatically linked to C. This is a fundamental principle that cannot be disabled—it ensures that all records in a linked group are linked to each other.

Link Action Cascading Effects:

When you link Record A to Record B: 1. A and B are directly linked 2. A is automatically linked to all records already linked to B (C, D, E...) 3. B is automatically linked to all records already linked to A (F, G, H...) 4. All of A's linked records (F, G, H) are automatically linked to all of B's linked records (C, D, E)

Example:

• Record A is linked to Records F, G, H (4 records in Group 1)
• Record B is linked to Records C, D, E (4 records in Group 2)
• You link A to B
• Result: All 8 records are now linked to each other (28 total links: 8 records × 7 connections each ÷ 2)

Unlink Action Cascading Effects:

When you unlink Record A from Record B using "Different" action: 1. A and B are directly unlinked 2. If "Synchronize MPIID and Linkage Status" is enabled, one record gets a new MPIID 3. All records previously linked to A remain linked to A 4. All records previously linked to B remain linked to B 5. All links between A's group and B's group are removed

A is Different / B is Different Cascading Effects:

These actions have the most extensive cascading effects:

When you use "A is Different": 1. A and B are unlinked 2. A receives a new MPIID (e.g., changes from 12345 to 67890) 3. All records that had MPIID 12345 AND are linked to A (but not to B) also get MPIID 67890 4. All records that had MPIID 12345 AND are linked to B (but not to A) keep MPIID 12345 5. Any records that were linked to both A and B create overlap conflicts (linked to both groups which now have different MPIIDs)

Action Confirmation Limitations: The confirmation pop-up that appears before executing actions shows:

• The immediate direct action you selected
• The records directly affected
• The comment to be applied

Important: The pop-up does NOT explicitly list all cascading effects. For example:

• Pop-up says: "Link Record A (John Smith, MRN S2345) to Record B (Jon Smith, MRN LAB572048)"
• Actual effect: Link A to B, plus link A to C, D, E (B's linked records), plus link F, G (A's linked records) to B, C, D, E
• Result pop-up (after action) shows all actions taken, which may be much longer than confirmation pop-up

Preventing Unintended Consequences:

Strategy 1 - Use Whole Record Viewer: Before linking or unlinking records that may be part of larger linked groups, view them in the Whole Record Viewer to see all relationships.

Strategy 2 - Check Link Counts: In the worklist, if the Alternate Views column shows a Whole Record Viewer icon, clicking it reveals how many other records are in the linked group. A large number (10+) suggests complex relationships requiring careful analysis.

Strategy 3 - Review Agreement Patterns: Before linking, check the agreement patterns for the pair. If they show many "X" (negative) or "L" (low) values, investigate why they're on the worklist—there may be a data quality issue or incorrect previous action.

Strategy 4 - Start Conservative: When uncertain:

• Use "Possible Match" instead of "Link" if available
• Assign Custom Status for further review instead of taking immediate action
• Assign to more experienced user for decision
• Add detailed comment explaining uncertainty

Strategy 5 - Monitor Audit Log: After complex actions, review the audit log to verify all cascading effects were appropriate. If unintended consequences occurred, use Reset or manual unlinking to correct.

Common Cascading Effect Scenarios:

Scenario 1 - Overlap Creation:

• Link Record A (MPIID 100) to Record B (MPIID 200)
• System asks which MPIID to keep
• Choose MPIID 100
• Record B and all its linked records change to MPIID 100
• If any of B's linked records were linked to records with MPIID 200, those create overlaps

Scenario 2 - Mass Unlink:

• Open-chaining exists: A linked to B, B linked to C, A not linked to C
• You determine A and B are different people and unlink them
• This doesn't automatically unlink B from C or A's linked group from B's linked group
• May need multiple unlink actions to fully separate the groups

Scenario 3 - Deterministic Propagation:

• Link Record A to Record B, both have deterministic identifier "SSN:123-45-6789"
• Record C has same SSN and is automatically linked by deterministic rule
• C is now linked to both A and B by transitivity
• Unlinking A from B requires addressing what happens with C

Understanding cascading effects requires experience, training, and careful use of visualization tools. This is why linkage conflict categories should be handled by experienced staff.

---

Effective worklist action execution requires following established best practices to ensure data quality, consistency, and accountability.

Comment Best Practices:

• Be specific: "Same patient - confirmed via SSN match" is better than "Match"
• Document evidence: "Different patients - birth dates 20 years apart" explains the decision
• Record external verification: "Confirmed with Memorial Hospital registration on 3/20/24"
• Explain unusual decisions: "Linked despite address difference - patient confirmed move in phone call"
• Batch comment discipline: Use "Clear Comment" between different batches; don't apply wrong comment to wrong action

Tool Selection Best Practices:

Use Worklist for:

• Simple Review category items with clear demographic matches or mismatches
• Batch processing similar items
• Quick triage of high-scoring potential links

Use Comparison Detail for:

• Detailed side-by-side review of two records
• Examining specific field agreements and disagreements
• Reviewing link weight calculations and agreement patterns
• Standard Review and Validate category items

Use Whole Record Viewer for:

• Any conflict category (Overlap, Overlay, Open-chaining)
• Records with multiple links or potential links
• Understanding transitive linking relationships
• Complex scenarios requiring context of entire linked group

Use Linkage Graph for:

• Visualizing large linked groups (10+ records)
• Understanding complex open-chaining scenarios
• Seeing relationships between multiple linked groups
• Making multiple related decisions in an enclosed workspace

Verification Best Practices:

• After batch actions, spot-check a few processed items to ensure correct action was applied
• After resolving conflicts, re-run the worklist search to verify items no longer appear
• Review audit log periodically to ensure your actions are being logged correctly
• Check for unintended overlaps or overlays after complex unlinking actions

Escalation Best Practices:

• Know your organization's escalation criteria and follow them consistently
• When escalating, provide thorough documentation: what you analyzed, why you're uncertain, what you recommend
• Use "Assign to User" to route escalated items to appropriate expert
• Add Custom Status like "Escalated" to track escalation workflow
• Follow up on escalated items to learn from expert's resolution (continuous improvement)

Quality Assurance Best Practices:

• Participate in regular case reviews where team discusses difficult decisions
• Request second opinion on borderline cases before finalizing decision
• Track personal error rate (how often your decisions are later reversed)
• Learn from discovered false matches or false non-matches
• Stay current on organizational policy changes affecting linking criteria

Performance Best Practices:

• Process worklist items promptly to prevent backlog accumulation
• Focus on highest-priority categories first (conflicts, then validate, then review)
• Use batch actions appropriately for efficiency without sacrificing quality
• Balance speed with accuracy—rushing leads to errors that take longer to fix
• Communicate with supervisor about workload challenges or training needs

Documentation Best Practices:

• Maintain personal notes on unusual cases or complex decisions
• Contribute to organizational knowledge base (document common scenarios and resolutions)
• Share lessons learned with team members
• Document systemic issues (e.g., "Hospital X always sends duplicate birth dates") for escalation to technical staff

Continuous Improvement:

• Regularly review your worklist action patterns and outcomes
• Seek feedback from supervisors on decision quality
• Attend training sessions on new features or updated procedures
• Propose procedural improvements based on frontline experience
• Monitor industry best practices for master patient index management

---