T3.7: Teaches Use of Alternate Views

What Are Alternate Views?

Alternate views in InterSystems EMPI are specialized interfaces that present patient data in different formats and contexts to support various operational needs. Rather than providing a single monolithic view of patient data, EMPI offers multiple focused views, each optimized for specific tasks and user roles.

Why Multiple Views Are Needed

Patient identity management is complex and involves multiple stakeholder groups with different needs:

Data Stewards and EMPI Administrators:

• Need detailed linkage information
• Require audit trails for compliance
• Must understand matching logic and decisions
• Focus on data quality and identity resolution

Quality Assurance Staff:

• Need to review and validate linking decisions
• Require side-by-side comparisons of records
• Must identify data quality issues
• Focus on accuracy and compliance

Clinical and Registration Staff:

• Need to understand patient identity issues
• May need to escalate complex cases
• Require clear, actionable information
• Focus on patient safety and care continuity

Integration and Technical Staff:

• Need to understand how data flows through the system
• Require visibility into data transformations
• Must troubleshoot matching and linking issues
• Focus on system configuration and data quality

Each alternate view addresses the specific needs of one or more of these groups.

The Four Primary Alternate Views

1. Whole Record Viewer

• Displays all database records linked to a patient in a comprehensive side-by-side format
• Shows linkage relationships and disagreements between records
• Primary tool for investigating complex linkage scenarios
• Supports linking and unlinking decisions
• Target users: EMPI administrators, data stewards

2. Composite View

• Generates a virtual "composite record" assembled from multiple source records
• Shows which source contributed each property value
• Demonstrates the "single best view" of patient demographics
• Validates composite record definitions
• Target users: Data governance staff, integration specialists

3. Record History

• Displays temporal changes to patient records over time
• Shows both single-record evolution and paired-record comparisons
• Tracks who made changes and when
• Critical for audit and compliance
• Target users: Quality assurance, compliance auditors, EMPI administrators

4. Comparison Detail

• Presents two records side by side for detailed comparison
• Shows original and normalized data
• Displays linkage information and matching scores
• Primary interface for making linking/unlinking decisions
• Target users: EMPI administrators, quality assurance staff

Relationship Between Views

These views are interconnected, allowing users to navigate seamlessly between different perspectives:

• From EMPI Person Search → Access any view via icons in search results
• From Whole Record Viewer → Navigate to Comparison Detail, Record History, or Composite View
• From Comparison Detail → Link/unlink records, then return to Whole Record Viewer
• From Record History → Navigate to current record views
• From Composite View → Access Record History for component records

This interconnected architecture supports flexible investigation workflows where users can move between views as needed to understand and resolve patient identity issues.

Common Characteristics Across Views

Despite their different purposes, all alternate views share certain characteristics:

Accessibility:

• Accessible from the InterSystems EMPI menu in the Management Portal
• Also accessible via icons from search results and other views
• Consistent navigation paradigms

Data Fidelity:

• All views display the same underlying EMPI data
• Changes made in one view are reflected in all views
• Real-time data (not cached snapshots except for Record History)

Security:

• Subject to the same security and access controls
• User permissions determine which views are available
• Audit trail captures all access and actions

User Interface Consistency:

• Similar visual design and layout principles
• Consistent button placement and terminology
• Common actions (Search, Clear, Previous, etc.)

Selecting the Right View for the Task

Use Whole Record Viewer when:

• Investigating linkage conflicts involving multiple records
• Needing to see all records associated with a patient
• Making decisions about complex linkage scenarios
• Identifying data quality issues across facilities

Use Composite View when:

• Determining the "current truth" about patient demographics
• Validating that composite record definitions work as intended
• Understanding which source systems provide the most reliable data
• Supporting data governance initiatives

Use Record History when:

• Investigating how patient information has changed over time
• Researching when specific changes occurred
• Auditing who made changes and why
• Understanding the evolution of linkage relationships

Use Comparison Detail when:

• Making linking or unlinking decisions for a specific pair of records
• Comparing demographic details field by field
• Understanding matching scores and agreement patterns
• Entering comments and justifications for manual decisions

---

Accessing Whole Record Viewer

Navigate to the InterSystems EMPI menu and select Whole Record. The page initially appears empty. To search for a record to display:

• Click the Search button in the top-left corner
• Search by demographic criteria, MPIID, MRN, or other identifiers
• Select a record from search results

Alternatively, access Whole Record Viewer directly from:

• EMPI Person Search results (click the Whole Record icon)
• Comparison Detail view
• Other alternate views

Screen Layout

Horizontal Layout: Records are displayed in columns from left to right across the screen. Each record occupies a vertical column showing all demographic properties for that record.

Anchor Record: The shaded record at the far left is the anchor record - the reference point for all comparisons. Key characteristics:

• All other records are compared against the anchor
• Fields marked as "disagreement" differ from the anchor
• Linking and unlinking operations are performed with respect to the anchor
• To change the anchor: click the uppercase letter in the top-left corner of any record's tab

Record Identification: Records are identified by uppercase alphabetical letters (A, B, C, D, etc.) displayed in circles at the top of each column. This makes it easy to reference specific records when discussing linkage issues.

Record Organization and Grouping

Records that are not the anchor are organized into three groups from left to right:

Group 1: Undecided (No Manual Link/Unlink)

• Records with no manual linking decision
• Includes automatic links based on matching scores
• Represents records where human review may be pending
• These are candidates for manual review

Group 2: Decided with a Category (Manual Link/Unlink with Work Category)

• Records with manual linking or unlinking decisions
• Assigned to a work category (Duplicate, Overlap, etc.)
• Represents completed reviews with categorization
• Helps organize similar cases

Group 3: Decided without a Category (Manual Link/Unlink, Empty Work Category)

• Records with manual linking or unlinking decisions
• No work category assigned
• May represent straightforward decisions not requiring categorization

Within each group, columns are sorted alphabetically by internal identifier.

Display Limit Configuration

You can specify the maximum number of records displayed on each page:

• Enter a positive integer in the Display Limit field near the top-right
• Default is 20 records
• Useful when patients have many records across multiple facilities
• Pagination controls allow navigation to additional pages

Icons and Navigation Links

All records in the Whole Record Viewer have three icons providing access to related views:

History Icon:

• For the anchor record: displays the history of the anchor record alone
• For other records: displays the History page of that record and the anchor, side by side
• Allows temporal investigation of how records have changed

Composite Icon:

• Opens the Composite View of the record
• Shows how this record contributes to the composite record
• Useful for understanding data source prioritization

Comparison Detail Icon:

• Opens the Comparison Detail page for that record and the anchor record
• Not available for the anchor record itself (can't compare to itself)
• Primary method for making linking/unlinking decisions

Moving and Sorting Records

Arrow Buttons: Left and right arrow buttons appear on either side of the icon set for each record. These allow you to:

• Move records closer to the anchor (left arrow) for easier comparison
• Move records further from the anchor (right arrow) to reduce clutter
• Customize the layout based on your investigation needs

Sort Button: Clicking the Sort button near the top of the page returns all records to the default sort order (organized by group and alphabetical within group). Use this to restore the standard layout after manual rearrangement.

Summary Row

Each record column includes a Summary row that displays key information about the relationship between that record and the anchor. Clicking the link in the Summary row opens a pop-up window showing:

• Work Category assignment
• Link Comment
• Secondary Reason for the link or unlink
• Link Weight (matching score)
• Recommended Action for complex relationships

This summary provides quick access to linkage metadata without opening a full Comparison Detail view.

Field-Level Comparison

The Whole Record Viewer displays all demographic fields in rows, allowing horizontal comparison across all displayed records:

• Matching fields: No special highlighting
• Disagreeing fields: Highlighted or marked to indicate disagreement with the anchor
• Missing fields: Empty cells or special indicators

This field-level comparison makes it easy to spot discrepancies that may indicate:

• Data entry errors
• Patient information changes (address, name)
• Different individuals incorrectly linked
• Data quality issues at source systems

---

Purpose of Record History

Over time, patient demographic information naturally changes - patients move, change phone numbers, get married and change names, etc. Additionally, data entry errors may be corrected, and records may be updated with more accurate information. The Record History feature provides visibility into these changes over time.

The Record History page serves two primary purposes: 1. Trace the history of a single record: Understanding how a specific record has evolved 2. Compare the histories of a pair of records: Understanding how two records have changed relative to each other

How Record History Works

As patient records are updated and saved, EMPI performs a demographic audit, storing a copy of each version of each record. The Record History feature retrieves these historical snapshots on demand, displaying them alongside current versions for comparison.

Accessing Record History

From the Worklist:

• Select a record pair in the Worklist
• Click the History icon
• Opens Record History comparing the two records in the pair

From the Composite View:

• Check the checkbox for one or two records
• Click the History button
• Opens Record History for the selected record(s)

From Patient Search:

• Click the History icon for an MPIID
• Opens Record History for that patient's records

From Whole Record Viewer:

• Click the History icon for any record
• Opens Record History comparing that record to the anchor (or just the anchor alone if viewing the anchor's history)

Record History Display Format

Table Structure: The Record History page displays a table with:

• Columns: Represent different versions of records at different points in time
• Rows: Represent different demographic properties (name, address, DOB, etc.)
• Cells: Show the value of that property at that point in time

Header Information: Each column header shows:

• Patient name (from that version of the record)
• Time Updated: Timestamp showing when this version was saved
• Assigning Authority: The source system or facility
• MRN: Medical Record Number
• MPIID: Master Patient Index ID

Single Record History vs. Paired Record History

Single Record History: When viewing the history of a single record, columns show:

• Current version (rightmost column)
• Previous versions in reverse chronological order (moving left)
• Each column represents the record at a specific point in time

Paired Record History: When comparing two records, columns alternate between the two records:

• Record 1 (current version)
• Record 2 (current version)
• Record 1 (previous version)
• Record 2 (previous version)
• And so on

This alternating pattern makes it easy to compare how both records evolved over the same time periods.

Change Highlighting

When information changes between two versions of a record, the changed value is displayed in color (the default color is orange). This highlighting allows users to quickly identify what has changed without reading every field.

What Gets Highlighted:

• Values that differ from the previous version (for single record history)
• Values that differ from the corresponding version in the other record (for paired record history)
• Both new values and removed values

Benefits of Change Highlighting:

• Quickly spot recent changes
• Identify data quality issues (frequent changes may indicate data problems)
• Understand the impact of data corrections
• Track patient life events (name changes, moves, etc.)

Common Investigation Scenarios

Scenario 1: Resolving Conflicting Information A clinician reports that a patient's address differs between two systems. Investigation steps: 1. Use EMPI Person Search to find the patient's MPIID 2. Open Whole Record Viewer to see all linked records 3. Click History icon for records with different addresses 4. Review Record History to determine:

• Which address is more recent
• When each address was entered
• Whether the patient moved or if this is a data entry error

5. Take appropriate corrective action

Scenario 2: Auditing Manual Linking Decisions Quality assurance needs to verify that two records were correctly linked. Investigation steps: 1. Locate the linked records in Whole Record Viewer 2. Open Record History comparing the two records 3. Review history to determine:

• Whether records have been consistent over time
• If changes to one record correlate with changes to the other
• Whether demographic patterns support the linking decision

4. Document findings in audit report

Scenario 3: Investigating Data Quality Issues An administrator notices frequent changes to a specific patient's record. Investigation steps: 1. Open Record History for that patient 2. Review the timeline of changes 3. Identify patterns:

• Same fields changing repeatedly (data quality issue)
• Regular updates (normal patient lifecycle)
• Sudden bulk changes (data migration or correction event)

4. Work with source system administrators to address root causes

Sample Question Relevance

Question 14 from the sample questions asks: "The Record History view can be used to research which of the following?"

Correct Answer: Changes to an individual record or pair of records

This question directly tests understanding of the Record History view's purpose. Incorrect answers might suggest uses better suited to other views:

• Linkage conflicts across multiple records → Whole Record Viewer
• Composite record generation → Composite View
• Current linkage status → Comparison Detail

Understanding what each view is designed for is critical for exam success.

---

Purpose of Comparison Detail

The Comparison Detail page is the primary workspace for analyzing record pairs and making linking or unlinking decisions. It provides comprehensive information about two records and their relationship, enabling informed decision-making.

When to Use Comparison Detail

Comparison Detail is most appropriate when:

• Reviewing a specific record pair from the Worklist
• Making a manual linking or unlinking decision
• Understanding why records matched or didn't match
• Investigating matching scores and agreement patterns
• Entering justifications for manual decisions
• Understanding the impact of linking/unlinking on other records

Accessing Comparison Detail

From the Worklist:

• Select a record pair
• The Comparison Detail view displays automatically (or click to open)

From Whole Record Viewer:

• Click the Comparison Detail icon for any non-anchor record
• Opens Comparison Detail comparing that record to the anchor

From Other Sources:

• EMPI Person Search → Whole Record Viewer → Comparison Detail
• Direct navigation from some administrative interfaces

Comparison Detail Screen Sections

Section 1: Original Properties This section displays the demographic data as originally recorded in each source system:

Data Source and Identifiers:

• MPIID: Master Patient Index ID for each record
• Data Source: The source system or facility
• Facility: Specific facility where the record was created
• MRN: Medical Record Number

Demographic Fields:

• Name: Given Name, Family Name (displayed in expandable format)
• SSN: Social Security Number
• Gender: M, F, or other configured values
• Birth Date/Time: Complete birth date and time if available

Identifiers (Expandable): Multiple identifiers with:

• Extension: The identifier value
• AssigningAuthorityName: Which organization assigned this identifier
• Use: The purpose or context of this identifier

Addresses (Expandable): Multiple addresses with:

• StreetLine: Street address
• City: City
• State: State or province
• PostalCode: ZIP or postal code

Telecoms (Expandable): Multiple contact methods with:

• Type: Home, Work, Mobile, etc.
• Telephone: Phone number
• Use: Primary, secondary, etc.

Section 2: Normalized Properties This section shows how EMPI normalized the data before performing matching:

• Names converted to uppercase
• Punctuation removed
• Abbreviations expanded
• Phonetic representations
• Standardized address formats

Viewing normalized properties helps users understand:

• How matching algorithms "see" the data
• Why records matched despite appearing different
• Why records didn't match despite appearing similar
• Impact of normalization configuration

Section 3: Linkage Information This critical section provides detailed information about the relationship between the two records:

Thresholds:

• Review Threshold: Score below which record pairs appear on Worklist for review
• Autolink Threshold: Score above which records are automatically linked
• Validate Threshold: Score range requiring validation

Matching Scores:

• Link Weight: The calculated matching score (e.g., 38.387)
• Agreement Pattern: Visual representation showing which fields agreed/disagreed

Link Status:

• Link Status: Link, Non-Link, or other configured statuses
• Internal Link Status: Technical status information
• Link Reason: Manual, Automatic, Rule-based, etc.
• Secondary Reason: Additional detail about why the link was created

Workflow Information:

• Username: Who created manual links
• Assigned To: Current assignee for review
• Assignment Comment: Notes about the assignment
• Custom Status: Organization-specific status values
• Custom Status Comment: Notes about the status
• Link Comment: User-entered justification or explanation

Section 4: Link Weight by Parameters (Expandable) Shows the detailed breakdown of how individual matching parameters contributed to the overall link weight:

• Each matching field listed with its contribution
• Positive weights indicate agreement
• Negative weights indicate disagreement
• Sum equals the total Link Weight

This section is valuable for:

• Understanding why a specific score was calculated
• Troubleshooting unexpected matching results
• Validating matching configuration
• Training users on how matching works

Section 5: Other Link (Expandable) Shows information about other records linked to either of the two records being compared. This is critical for understanding:

• Complex linkage scenarios
• Potential chaining issues
• Impact of linking decisions on other records

Section 6: Other Link to Validate (Expandable) Lists other linkages involving these records that require validation. Helps identify:

• Related review tasks
• Interconnected linkage issues
• Broader patient identity problems

Section 7: Other Non-Link to Review (Expandable) Shows non-link relationships that should be reviewed, helping identify:

• Potential false negatives (records that should be linked but aren't)
• Records that have been manually marked as non-links
• Cases requiring additional investigation

Section 8: Warnings (Expandable) Displays any system-generated warnings about the linkage, such as:

• Conflicting linking patterns
• Data quality issues
• Configuration problems

Actions Available in Comparison Detail

Primary Actions:

• Same: Mark the two records as representing the same patient (create or confirm link)
• A is Different: Mark Record A as representing a different patient (create non-link)
• B is Different: Mark Record B as representing a different patient (create non-link)
• Reset: Clear custom status and assignment

Workflow Actions:

• Assign to User: Assign this record pair to a specific user for review
• Change Status: Set a custom status for tracking purposes

Configuration Actions:

• Colors: Customize the color scheme for highlighting differences

Navigation Actions:

• Clear: Clear the form and prepare for a new comparison
• Previous: Return to the previous view

Entering Comments

When making manual linking or unlinking decisions, users should enter comments in the Comment field explaining the rationale. This creates an audit trail and helps future reviewers understand the decision.

Best Practices for Comments:

• Be specific about the reason for the decision
• Reference specific data points that supported the decision
• Note any unusual circumstances
• Include contact information if the decision is complex

Example Comments:

• "Same patient - SSN matches, name variation is married name"
• "Different patients - DOB differs by 20 years, name similarity is coincidental"
• "Linked per hospital policy - twins with similar demographics"

---

Composite Records Concept

A composite record is a virtual record representing the "single best view" of a patient, created by intelligently selecting the most accurate or current information from multiple source records. This addresses a common problem in healthcare: different systems may have different (and sometimes conflicting) information about the same patient.

Why Composite Records Are Needed

The Multi-Source Data Problem: In a typical healthcare enterprise:

• Registration system may have the most current address
• Laboratory system may have the most accurate phone number
• Billing system may have the best SSN data
• EHR may have the most recent name (after marriage, etc.)

Rather than selecting one system as the "source of truth," composite records allow organizations to define intelligent rules for selecting the best value for each property from the most reliable source.

Generating a Composite Record

Step 1: Access Composite View Navigate to the InterSystems EMPI menu and select Composite View. Alternatively, click the Composite View icon from Patient Search results or Whole Record Viewer.

Step 2: Select Composite Record Definition Click the Open button and choose the class containing the composite record definition you wish to use. Organizations may have multiple composite record definitions for different purposes or different workflows.

Step 3: Specify Enterprise ID Enter a value in the Enterprise ID text box (for example, MPIID: 100000004) and click Go. The system generates the composite record for that patient.

Alternatively, click Search to search by:

• Facility
• MRN
• MPIID
• SSN
• Date of birth
• Family name
• Given name

Step 4: Review Composite Record The Composite View displays:

• Left column: Property group names (Name, Addresses, Identifiers, etc.)
• Second column: Composite record values
• Subsequent columns: Source records that contributed to the composite

Composite View Display Elements

Property Groups: The left side lists property groups such as:

• Summary
• Name
• Gender
• SSN
• Date of Birth
• Identifiers
• Addresses
• Telecoms

Composite Record Column: The column immediately to the right of the property names shows the composite record - the "winner" for each property. This represents the organizational "single truth" about this patient.

Source Record Columns: Columns to the right show the source records that were compared to create the composite. Each column can be:

• Contracted: Showing just key identifiers
• Expanded: Showing all demographic details
• Exchanged: Moved left or right for easier comparison

Column Manipulation Buttons: Near the top of each source record column are buttons to:

• Contract the column to save space
• Expand the column to see all details
• Move the column left or right

Column Ruler: Arrows along the ruler at the top allow stretching or compressing columns to fit more information on screen.

Color Coding in Composite View

The Composite View uses color to indicate whether each source record contributed to the composite:

Default Colors:

• Blue: Composite winner (this record contributed this value)
• Orange: Disagrees with composite (this record has a different value)
• White: Same as winner (this record has the same value as the winner)
• Dark blue: Manual override (user manually overrode the composite definition)

These colors make it easy to see at a glance which sources are contributing which data and where conflicts exist.

Customizing Colors: Click the Settings button to configure color preferences for the display.

Understanding Why a Record Contributed a Value

To understand why a particular record contributed a particular property value to the composite: 1. Locate the property row of interest 2. Click the gray triangle in that row of the composite record 3. A detailed window opens showing how each source record contributed to the composite for that property group

This detailed view shows:

• The composite record definition rules
• How each source record scored against those rules
• Why the winning record was selected

This is valuable for:

• Validating composite record definitions
• Troubleshooting unexpected composite results
• Training staff on how composite records work
• Documenting data governance decisions

Accessing Record History from Composite View

The Composite View integrates with Record History to support temporal investigation:

To Access Record History: 1. Check the checkbox at the top of one or two source record columns 2. Click the History button 3. The Record History window opens showing the historical evolution of the selected record(s)

This allows users to understand not just the current state of the composite, but how it has evolved over time as source records have changed.

Composite Override

In some cases, the composite record definition may select the wrong value, or users may need to manually override the selection for specific patients. The dark blue color indicates manual overrides.

Organizations typically establish policies governing when manual overrides are appropriate and who has authority to create them. Overrides should be used sparingly, as they represent exceptions to the data governance rules.

Use Cases for Composite View

Use Case 1: Data Governance Validation Data governance teams use Composite View to validate that composite record definitions are working as intended:

• Review sample patients across different scenarios
• Verify that appropriate sources are winning
• Identify edge cases requiring rule adjustments
• Document decisions and rationale

Use Case 2: Integration Design When designing integrations that consume EMPI data, integration teams use Composite View to understand:

• Which properties will be available in composite records
• Which source systems contribute which data
• How to handle cases where composite values differ from source values
• Whether additional composite definitions are needed

Use Case 3: Data Quality Investigation When data quality issues are suspected, analysts use Composite View to:

• Identify which source systems have the best data quality
• Find patterns of disagreement between sources
• Prioritize data quality improvement initiatives
• Measure improvement over time

Use Case 4: Regulatory Compliance For compliance with regulations requiring accurate patient demographics, compliance staff use Composite View to:

• Verify that the "best known" patient information is being used
• Document the rationale for data selection decisions
• Demonstrate that systematic processes are in place for data quality
• Audit the accuracy of enterprise-wide patient records

---

Overview of Navigation Paradigms

EMPI alternate views are designed as an interconnected system rather than isolated interfaces. Users can navigate fluidly between views as their investigation evolves, without losing context or having to re-enter search criteria.

Common Navigation Patterns

Pattern 1: General Investigation Workflow 1. Start: EMPI Person Search (search for patient by demographics) 2. Identify: Review search results, confirm correct MPIID 3. Explore: Click Whole Record Viewer icon to see all linked records 4. Compare: Click Comparison Detail icon for specific record pairs 5. Decide: Make linking/unlinking decisions in Comparison Detail 6. Verify: Return to Whole Record Viewer to confirm changes 7. Audit: Access Record History to document the investigation

Pattern 2: Data Quality Audit Workflow 1. Start: EMPI Person Search (find patient by MPIID) 2. Composite: Click Composite View icon to see "best" data 3. Sources: Expand source record columns to see contributing records 4. History: Click History button for selected records 5. Trends: Analyze temporal patterns in Record History 6. Document: Return to Composite View and take screenshots for documentation

Pattern 3: Worklist Review Workflow 1. Start: Worklist (filter for specific category or assignment) 2. Detail: Select record pair to open Comparison Detail 3. Context: Click Whole Record Viewer to see other linked records 4. Decision: Return to Comparison Detail to link/unlink 5. Next: Proceed to next Worklist item

Pattern 4: Complex Linkage Investigation 1. Start: EMPI Person Search (search by patient name) 2. Problem: Find two MPIIDs that should be the same patient 3. First Group: Click Whole Record Viewer for first MPIID 4. Second Group: Open new tab/window, click Whole Record Viewer for second MPIID 5. Compare: Select representative records from each group 6. Detail: Open Comparison Detail for the selected pair 7. Link: Make decision to link the records 8. Verify: Return to Person Search, confirm single MPIID now exists

Navigation Controls in Each View

EMPI Person Search:

• Icons in results table provide direct access to:
• Whole Record Viewer
• Audit Log
• Composite View
• Record History

Whole Record Viewer:

• Icons for each record provide access to:
• Record History (paired with anchor or single record)
• Composite View
• Comparison Detail (paired with anchor)
• Search button returns to search interface
• Sort button restores default record ordering

Comparison Detail:

• Clear and Previous buttons for navigation
• No direct icons to other views (typically accessed from Whole Record Viewer)
• After making decisions, users typically use browser back button or close tab

Composite View:

• Search button to find different patients
• History button to access Record History for selected records
• Open button to select different composite definitions
• Icons may be available depending on configuration

Record History:

• Typically accessed from other views rather than providing onward navigation
• Users return to calling view using browser back button or by closing the history window

Browser Tab/Window Management

Many EMPI workflows involve having multiple views open simultaneously:

Common Multi-View Scenarios:

• Two Whole Record Viewers: Comparing records from two different MPIIDs
• Whole Record Viewer + Comparison Detail: Reviewing record pairs while maintaining context of all linked records
• Composite View + Record History: Understanding current state and historical evolution
• Person Search + Multiple Detail Views: Investigating multiple patients in parallel

Best Practices:

• Use browser tabs rather than windows for easier management
• Keep Person Search open in one tab as a "home base"
• Close detail views when finished to avoid confusion
• Use browser's "Duplicate Tab" feature to maintain current search results while exploring

Maintaining Context During Navigation

When navigating between views, EMPI maintains context in several ways:

URL Parameters: Many views include the relevant MPIID, MRN, or other identifiers in the URL, allowing:

• Bookmarking specific patients or record pairs
• Sharing URLs with colleagues
• Browser back/forward navigation
• Reloading pages without losing the patient being viewed

Session State: The Management Portal maintains session state for:

• Current user's search criteria
• Previously viewed records
• Worklist filters and selections

Previous Button: Many views include a Previous button that restores the prior search or view state.

Error Recovery and Dead Ends

Sometimes navigation leads to error states or empty views:

Common Issues:

• Composite View with no composite definition selected
• Whole Record Viewer with no records matching the search
• Record History with no historical versions available
• Comparison Detail for records that have been deleted

Recovery Strategies:

• Use browser back button to return to previous view
• Click Search button to start a new search
• Navigate to EMPI Person Search as a "reset" point
• Check that required configurations (composite definitions) exist

---

Overview of Actions in Alternate Views

While alternate views primarily serve investigative purposes, several views also provide action capabilities that allow users to modify data, make linking decisions, and manage workflows. Understanding which actions are available in each view is critical for efficient EMPI operations.

Whole Record Viewer Actions

Primary Actions (Available in Summary Row): When viewing the relationship summary for a record pair, users can access:

Link Actions:

• Same: Mark the record as representing the same patient as the anchor (create or confirm link)
• A is Different: Mark Record A as representing a different patient (create non-link)
• B is Different: Mark Record B as representing a different patient (create non-link)

Workflow Actions:

• Assign to User: Assign this record pair to a specific user for review
• Change Status: Set a custom status to track review progress

Comment Entry:

• Enter comments explaining the decision rationale
• Required or recommended by organizational policy

Navigation Actions:

• Clear: Clear current selections and prepare for new comparison
• Previous: Return to previous view or state

Display Actions:

• Show All Changes: Display all modifications made in this session
• Undo All Changes: Reverse all modifications made in this session (before saving)
• Save All Changes: Commit all modifications to the database
• Arrange Windows: Customize pane layout
• Restore Default Settings: Reset display to default configuration

Selection and Comparison Actions:

• Select Next Open-Chaining: Navigate to next open-chaining link in sequence
• Select Link-by-Threshold with Next Lowest Link Weight: Navigate to next threshold link
• Previous Record / Next Record: Navigate through records alphabetically
• Previous Linkage / Next Linkage: Navigate through linkages

These navigation actions support systematic review workflows where users process multiple record pairs in sequence.

Record Manipulation Actions:

• Move records left or right using arrow buttons
• Click letter to change anchor record
• Sort button to restore default ordering

Comparison Detail Actions

Decision Actions:

• Same: Link the two records (mark as same patient)
• A is Different: Create non-link (mark Record A as different patient)
• B is Different: Create non-link (mark Record B as different patient)
• Reset: Clear custom status and assignment

Workflow Management:

• Assign to User: Assign to specific user for review (opens dialog to select user)
• Change Status: Set custom workflow status (opens dialog to select status)

Comment Entry:

• Comment field: Enter justification for manual decisions
• Appears in audit trail and Linkage information section
• Best practice: Always enter meaningful comments for manual decisions

Display Customization:

• Colors: Configure color scheme for highlighting differences
• Allows users to customize for visual preferences or accessibility needs

Navigation:

• Clear: Reset the form and clear both records
• Previous: Return to previous view

Expandable Sections: While not technically "actions," users can expand and collapse sections:

• Link Weight by Parameters: Show detailed score breakdown
• Other Link: Show other linkages involving these records
• Other Link to Validate: Show related validation tasks
• Other Non-Link to Review: Show related non-links
• Warnings: Show system warnings

Composite View Actions

Configuration Actions:

• Open: Select a different composite record definition class
• Settings: Configure color preferences and display options

Search Actions:

• Search: Search for patient by various criteria (Facility, MRN, MPIID, SSN, DOB, Name)
• Go: Generate composite for specified Enterprise ID

Investigation Actions:

• History: Open Record History for selected records (requires checking checkboxes for 1-2 records)
• Click gray triangle in composite row: Show detailed contribution explanation for that property

Display Manipulation:

• Contract/Expand buttons: Control column width
• Left/Right arrows: Move columns
• Column ruler arrows: Stretch/compress columns

No Modification Actions: Importantly, Composite View does NOT allow direct modification of:

• Composite record values
• Source record values
• Composite record definitions (must be done in configuration interface)

The exception is Composite Override functionality (if enabled), which allows manual override of specific property selections.

Record History Actions

Record History is primarily a read-only view designed for audit and investigation:

Available Actions:

• Navigation: Use browser back button to return to calling view
• Scrolling: Scroll horizontally to view historical versions
• Column Selection: Some implementations allow selecting columns for comparison

No Modification Actions: Record History does NOT allow:

• Editing historical records (they are audit snapshots)
• Deleting historical versions
• Creating new links or non-links
• Modifying current records

The read-only nature of Record History is intentional - it serves as an audit trail that cannot be tampered with.

Action Permissions and Security

Not all users have access to all actions in all views. Permissions are typically configured based on roles:

EMPI Administrator Role:

• Full access to all actions in all views
• Link, unlink, assign, change status
• Access to all alternate views
• Administrative configuration actions

Quality Assurance Role:

• Read access to all views
• May have restricted action permissions
• Typically cannot link/unlink, but can review and comment

Clinical User Role:

• Limited access to alternate views
• May have read-only access
• Typically cannot perform linking actions

Integration/Technical Role:

• May have access to technical views
• Typically read-only access for troubleshooting

Organizations should implement least-privilege access, granting only the permissions necessary for each role's responsibilities.

Audit Trail for Actions

All actions taken in alternate views create entries in the EMPI Audit Log:

Captured Information:

• Action type (link, unlink, status change, assignment)
• Username of person who took the action
• Timestamp
• Records involved (MPIIDs, MRNs, facilities)
• Comments entered by user
• Previous state and new state

This audit trail supports:

• Compliance with regulatory requirements
• Quality assurance reviews
• Investigation of problematic linkage decisions
• Training and performance evaluation

---