T1.1: Installs EMPI Software and Configures Production

Overview

Before installing InterSystems EMPI (formerly HealthShare Patient Index), you must select a deployment model that determines the architectural relationship between EMPI and the HealthShare Registry. The deployment model choice affects performance, resource allocation, production configuration steps, and operational procedures. InterSystems recommends consulting with the Sizing and Performance group to select the optimal model for your environment.

The deployment model determines whether EMPI runs in its own namespace (requiring a separate production) or shares a namespace with the Registry (requiring integrated configuration). It also determines whether EMPI processing can impact Registry and UCR performance.

Deployment Model 1: Dual-Instance with Separate EMPI

• EMPI: Deployed on its own dedicated instance
• Registry: In HealthShare Unified Care Record on a different instance
• Benefits: Complete isolation prevents EMPI processing from impacting UCR/Registry performance; optimal for high-volume environments
• Container Support: Only model supported for container-based deployments
• Production Required: Yes - EMPI has its own production created via Installer Wizard

Deployment Model 2: Single-Instance with Separate Namespace

• EMPI: On a UCR instance in its own namespace
• Registry: In a separate namespace from EMPI on the same instance
• Benefits: Single-instance simplicity reduces infrastructure costs
• Drawbacks: EMPI processing may cause other HealthShare areas to run more slowly due to shared resources
• Production Required: Yes - EMPI has its own production created via Installer Wizard

Deployment Model 3: Shared Namespace

• EMPI: On a UCR instance in the Registry namespace
• Registry: In the same namespace as EMPI
• Production Required: No - no separate EMPI production needed
• Use Case: Not recommended for production systems; primarily for demo/test environments

Deployment Model 4: Standalone EMPI

• EMPI: On its own standalone instance with no UCR
• Registry: Not present
• Use Case: Independent patient matching without UCR integration
• Production Required: Yes - standalone production template includes additional components for API operations

---

Overview

InterSystems EMPI software is installed using either a kit-based deployment (traditional installer) or a container-based deployment (Docker/Kubernetes). The installation process deploys the EMPI classes, database structures, and production templates onto an InterSystems IRIS instance. The installation method depends on your deployment model and infrastructure strategy.

Kit-based deployments offer interactive installation with the Installer Wizard or automated silent installation using scripts. Container-based deployments use pre-built container images with environment-specific configuration.

Kit-Based Installation Steps

1. Obtain the InterSystems EMPI installation kit from the InterSystems distribution site 2. Verify system requirements: supported OS version, available disk space, memory, CPU 3. Ensure InterSystems IRIS is installed and licensed for HealthShare components 4. Run the EMPI installer with administrative privileges 5. Follow the installation wizard prompts to specify installation directory and configuration 6. Select feature configuration options based on deployment model 7. Complete installation and verify success in installation logs 8. Confirm EMPI classes are available in the %SYS namespace

Container-Based Installation (Model 1 Only)

1. Obtain the InterSystems EMPI container image from the InterSystems Container Registry 2. Configure environment variables for namespace, database paths, and registry connection 3. Deploy the container using Docker or Kubernetes with appropriate resource limits 4. Mount persistent volumes for database storage 5. Configure network policies for inter-container communication with Registry 6. Verify container health and readiness probes 7. Review container logs for successful startup

Post-Installation Verification

• Navigate to Management Portal and verify HealthShare menu availability
• Check that HSPI.* packages are listed in the namespace class list
• Verify database directories exist and have correct permissions
• Review installation logs for errors or warnings
• Confirm license includes EMPI features
• Test Management Portal access with administrative credentials

---

Overview

For deployment models 1, 2, and 4, you must create an EMPI production using the Installer Wizard. This wizard-driven process creates the namespace, configures the production database, and instantiates the production template with all required business services, processes, and operations. The Installer Wizard provides a guided experience that ensures all necessary components are correctly configured.

The production serves as the interoperability container for EMPI processing, including inbound services for data reception, business processes for linkage computation, and operations for Registry communication.

Using the Installer Wizard (Models 1 and 2)

1. Open the Management Portal and navigate to Home > HealthShare 2. Click the Installer Wizard link in the banner 3. Select Configure Patient Index from the wizard options 4. Local Name: Enter a namespace name for EMPI (e.g., HSPIDATA) - record this value for later steps 5. Press Tab to auto-populate the Network Name and Production fields 6. Description: Optionally enter a descriptive name for the production 7. Mirror Database: Select checkbox if deploying in a mirrored environment (recommended for production) 8. Template: Select HSPI.Server.Production from the dropdown 9. Alternate Database Location: Specify custom database location or accept default (/mgr/) 10. Review configuration summary and click Finish 11. Wait for production creation to complete and verify success message

Standalone Production Template (Model 4)

• For standalone EMPI deployments (no UCR Registry), select Configure Standalone Patient Index from Installer Wizard
• Use template HSPI.Standalone.Production instead of HSPI.Server.Production
• Standalone production includes additional components:
• HSPI.Server.APIOperation: Handles API queries for patient search/retrieval
• Inbound Services: Accept HL7 ADT messages for patient create/update/merge operations
• Web Services: Expose SOAP endpoints for external system integration

Production Components Created

• HSPI.Server.Process: Core business process for patient matching and linkage
• HSPI.Server.RemoteOperations: Communicates with Registry (Models 1/2 only)
• HSPI.Server.Operations: Handles local EMPI database operations
• HSPI.Server.LinkageService: Background service for linkage computation
• HSPI.Server.BuildService: Manages linkage build processes

---

Overview

While EMPI provides comprehensive out-of-the-box matching capabilities, most production deployments require custom classes to address site-specific data quality issues, integration requirements, or matching rules. Custom classes extend the base EMPI functionality without modifying core InterSystems code, ensuring upgrade compatibility.

Common customizations include normalization rules for cleaning facility-specific data patterns, custom matching rules for deterministic identifiers, and integration components for connecting to external systems.

Custom Normalization Classes

• Subclass HSPI.Data.Normalization to create custom normalization logic
• Override methods like NormalizeSSN(), NormalizeName(), NormalizeAddress() to apply site-specific transformations
• Example: Strip veterinary patient prefixes, standardize facility-specific abbreviations, clean OCR errors
• Register custom normalization class in Definition Designer Parameters tab
• Custom normalization executes before matching algorithm evaluates parameters

Custom Rule Classes

• Extend HSPI.Match.Rule to create deterministic or probabilistic matching rules
• Implement Evaluate() method to return TRUE/FALSE based on custom criteria
• Example: Match on composite key (facility + MRN + DOB), apply domain-specific identifier logic
• Register custom rule in Definition Designer Rules tab
• Rules can force links (autolink) or non-links (exclusion) based on data patterns

Custom Integration Components

• Create custom business processes for pre-processing or post-processing workflows
• Implement custom business operations for external system integration (notifications, data exports)
• Add custom business services for additional inbound data formats
• Configure custom components in production Configuration settings
• Use TargetConfigNames to route messages through custom components

Installing Custom Classes

1. Develop custom classes in a development namespace using Studio or VS Code 2. Export classes to XML or UDL format 3. Import classes into EMPI namespace using Management Portal > System Explorer > Classes > Import 4. Compile classes using Compile > Compile All to ensure dependencies resolve 5. Verify custom classes appear in class list (e.g., Custom.HSPI.Normalization.MyRule) 6. Configure production components or Definition Designer to reference custom classes 7. Test custom functionality in development environment before deploying to production

---

Overview

After creating the EMPI production, several post-activation configuration tasks must be completed before the system is ready to receive data. These tasks establish the connection between EMPI and the Registry, define the structure of patient records, configure matching parameters, and register data sources.

Post-activation setup transforms the newly-installed production from a template into a production-ready system tailored to your organization's data and requirements.

Registry Configuration (Models 1 and 2)

1. Navigate to Registry Management > Configuration Registry in the UCR namespace 2. Create a new key for the EMPI namespace (use the Local Name from Installer Wizard) 3. Set MPI value to the EMPI namespace name (e.g., HSPIDATA) 4. Verify Configuration Registry entry is saved 5. Restart Registry production to activate changes

Composite Record Definition

• The Composite Record is the aggregated view of a patient's data from all linked source records
• Navigate to Patient Index Settings > Definition Designer > Composite Record tab
• Review default composite record fields (Name, DOB, SSN, Gender, Addresses, Telecoms)
• Customize field trust tiers to prioritize data from preferred sources (hospitals over clinics)
• Define aging factors to depreciate older data in favor of recent updates
• Save composite record definition changes

Linkage Definition Review

• Navigate to Patient Index Settings > Definition Designer
• Review General Settings: Locale, Enable Domain Conflict, MPIID format
• Review Parameters: Names, SSN, Gender, Birth Date, Addresses, Telecoms, Identifiers
• Review Thresholds: Default Auto-Link (80), Review (70), Non-Link (60) thresholds
• Review Rules: Default rules for SSN conflict, DOB conflict, gender conflict
• Do not modify settings yet - baseline configuration should be established first

Facility Registry Setup

1. Navigate to Registry Management > Facility Registry (or EMPI Settings for standalone) 2. Add each data source facility with unique Facility Code and Name 3. Assign appropriate Edge Gateway for each facility (Model 1/2) or leave blank (Model 4) 4. Configure assigning authority OIDs for each facility 5. Verify facility codes match those in incoming HL7 messages (PID-3 or PID-4) 6. Save facility definitions

System Settings Configuration

• System settings are configured as globals in the EMPI namespace
• Common initial settings to configure:
• ^MPRL.Config("buildData","blockSize"): Set to 1000 for progress reporting during builds
• ^MPRL.Config("buildData","showProgress"): Set to 1 to display build progress
• ^MPRL.Config("enterpriseId"): Set initial MPIID value if not using default
• ^MPRL.Config("skipDemographicAudit"): Set to 0 to enable demographic audit trail
• Edit globals using Terminal: `set ^MPRL.Config("setting","key") = value`
• Caution: Global changes have no undo - document changes before modifying

---

Overview

EMPI deployments require multiple environments to support development, testing, and production operations. A development environment provides a safe space for tuning the linkage definition, developing custom classes, and testing configuration changes. A production environment runs live patient matching. A tuning environment (sometimes called staging) allows testing of data from new sites before integrating into production.

Proper environment separation prevents experimental changes from disrupting production matching and provides a controlled pathway for promoting tested configurations to production.

Development Environment Setup

• Install EMPI on a separate instance or namespace from production
• Use a copy of production data (or synthetic test data) for realistic testing
• Configure production components to match production architecture
• Enable verbose logging and debugging settings for troubleshooting
• Allow direct access to Definition Designer for iterative tuning
• Use for: Testing normalization rules, adjusting thresholds, developing custom classes, testing data quality rules

Production Environment Setup

• Install EMPI on dedicated production instance with sizing appropriate for data volume
• Configure mirroring for high availability and disaster recovery
• Enable production-grade security: SSL/TLS, role-based access, audit logging
• Restrict direct Definition Designer access - changes should be promoted from development
• Configure monitoring and alerting for production health metrics
• Use for: Live patient matching, production data feeds, clinical application queries

Tuning Environment Setup

• Create dedicated namespace or instance for testing new data sources
• Load sample data from new site to analyze data quality and matching behavior
• Tune linkage definition specifically for new site's data patterns
• Test normalization rules against new site's data anomalies
• Validate matching accuracy before integrating new site into production
• Export tested configuration to production after validation

Promoting Configurations Between Environments

1. Export linkage definition from development: Definition Designer > Export Definition 2. Export custom classes from development: System Explorer > Classes > Export 3. Import linkage definition into production: Definition Designer > Import Definition 4. Import custom classes into production: System Explorer > Classes > Import 5. Execute linkage build in production to apply new definition 6. Validate production matching results after promotion

---

Overview

The Data Quality Tool is an analytics-based monitoring system that tracks the quality of demographic data entering EMPI. It evaluates each incoming patient record against validation rules, categorizing field values as valid, invalid, or blank. Data Quality dashboards and trending pivots provide visibility into data quality patterns, helping identify facilities with data issues and track improvement over time.

Enabling the Data Quality Tool is essential for ongoing data governance, enabling proactive identification of data quality degradation and supporting conversations with facilities about improving data at the source.

Enabling the Data Quality Tool

1. Navigate to Patient Index Settings > Data Quality Manager 2. Click Enable Data Quality Tool button 3. System creates three analytics cubes: DQSummary, DQSummaryNormalized, DQTrend 4. Initial cube build populates with existing patient data 5. Verify cube build completion in Build Log 6. Access dashboards via View Data Quality Dashboards button

Data Quality Dashboards

• EMPI Data Quality Summary: Displays valid/invalid/blank counts for each parameter before normalization
• EMPI Data Quality Summary - Normalized: Displays quality metrics after normalization rules applied
• Trend Dashboard: Displays long-term trends for user-defined trending pivots
• Dashboards filterable by Facility and Assigning Authority
• Export data to Excel or PDF for reporting to stakeholders

Creating Custom Validation Rules

1. Navigate to Data Quality Manager > Custom Rules 2. Click New Rule to define validation logic 3. Specify property (e.g., SSN, Name, Address) 4. Define validation expression using ObjectScript syntax 5. Example: SSN must be 9 digits and not all zeros: `(##class(%Regex).Match(value,"^\d{9}$")) && (value '= "000000000")` 6. Save custom rule 7. Click Rebuild Cube Data to apply new rule to existing records 8. Review dashboard to see custom rule results

Trending Pivots

• Trending pivots track specific data quality metrics over time
• Default pivots include: City Validity Reason, SSN Validity Reason, Name Validity Reason
• Create custom pivots: Navigate to User Portal > Analyzer, create pivot with DQTrend cube
• Format: `HSPI Data Quality Trending/, ;`
• Add custom pivot to Data Quality Trending Pivots list in Data Quality Manager
• Next cube synchronization collects data for new pivot

Cube Synchronization Schedule

• Data Quality cubes synchronize automatically on a schedule (default: nightly)
• Manual synchronization: Click Rebuild Cube Data in Data Quality Manager
• Synchronization processes new patient records since last build
• Large data volumes may require scheduled synchronization during off-peak hours
• Monitor cube build logs for errors or performance issues

---

Overview

When adding a new facility or data source to an existing EMPI production system, best practice is to first test that facility's data in a dedicated tuning environment. This approach allows EMPI specialists to analyze the new site's data quality, identify anomalies, adjust normalization rules, and validate matching accuracy without affecting production operations or contaminating production linkages with test data.

A tuning system is a separate EMPI instance or namespace that mirrors the production configuration but operates on isolated test data from the new site.

Tuning System Architecture

• Separate IRIS instance or namespace dedicated to tuning activities
• Mirror production linkage definition as baseline
• Import sample data from new site (2,000-10,000 records recommended)
• Enable verbose logging and debugging for detailed analysis
• Provide unrestricted Definition Designer access for rapid iteration
• No integration with production Registry or clinical applications

Setting Up a Tuning System

1. Install EMPI using same deployment model as production 2. Create production using Installer Wizard with tuning-specific namespace (e.g., HSPITUNING) 3. Import production linkage definition: Definition Designer > Import Definition 4. Configure Facility Registry entry for new site 5. Set up Batch Import utility or HL7 feed for test data ingestion 6. Load sample data from new site 7. Execute initial linkage build

Analyzing New Site Data

1. Run Data Quality Tool to identify validation failures 2. Review common data anomalies: missing SSNs, malformed addresses, name abbreviations 3. Examine sample records in Patient Search to understand data patterns 4. Identify facility-specific conventions: MRN format, name entry practices, coding systems 5. Document data quality issues for feedback to facility

Tuning for New Site Data

1. Create custom normalization rules to clean facility-specific anomalies 2. Adjust parameter weights if new site uses different data elements (e.g., lacks SSN) 3. Add exclusion rules to prevent matching on facility-specific invalid patterns 4. Test normalization: Review normalized values in Definition Designer > Parameters > Normalization Test 5. Execute linkage rebuild after each change 6. Validate matching results against known patient identities (gold standard dataset)

Validating and Promoting Configuration

1. Achieve acceptable matching accuracy: >95% true positive links, <1% false positive links 2. Review Worklist for conflicts requiring manual resolution 3. Export tuned linkage definition: Definition Designer > Export Definition 4. Export custom classes: System Explorer > Classes > Export 5. Import into production environment during scheduled maintenance window 6. Execute production linkage rebuild to apply new configuration 7. Monitor production matching results after new site integration

---

Overview

InterSystems EMPI contains highly sensitive patient demographic data and must be protected with comprehensive security controls. Security implementation includes role-based access control, encrypted communications, audit logging, database encryption, and integration with enterprise authentication systems. Proper security configuration is essential for HIPAA compliance and protecting patient privacy.

Security planning should begin during installation and be finalized before go-live.

EMPI Security Roles

InterSystems EMPI provides predefined roles with specific permission sets:

• %HSPI_Manager: Full access to Definition Designer, Worklist, Patient Search, Data Quality, system settings
• %HSPI_Operator: Access to Worklist for resolving conflicts, Patient Search for queries, restricted Definition Designer
• %HSPI_Viewer: Read-only access to Patient Search and reports, no Worklist or Definition Designer access
• %HS_Administrator: Full administrative access including production configuration, user management
• %HS_RoleAssigner: Assign roles to users, manage user accounts

User Account Creation

1. Navigate to System Administration > Security > Users 2. Click Create New User 3. Enter username (typically corporate ID or email) 4. Set authentication method: Password, LDAP, Kerberos, or SAML 5. Assign appropriate EMPI roles based on job responsibilities 6. Set account expiration and password policies 7. Enable account and verify user can log in 8. Document user account creation for compliance audit trail

SSL/TLS Configuration

• Enable SSL/TLS for all communications between EMPI and Registry
• Generate SSL certificates or obtain from enterprise PKI
• Configure SSL in production component settings:
• HSPI.Server.RemoteOperations: Set SSL Config setting to appropriate SSL configuration name
• Registry Web Services: Configure SSL for SOAP endpoint
• Test SSL connectivity: Verify production components connect successfully
• Force HTTPS for Management Portal access: Configure Web Gateway SSL settings

Audit Logging

• EMPI maintains audit logs for user actions: manual links/non-links, worklist actions, patient searches
• Enable demographic audit logging: Set global `^MPRL.Config("skipDemographicAudit") = 0`
• Audit log stored in HSPI.Audit.Log table
• Access audit log: Patient Index Settings > Audit Log
• Purge old audit log entries: Requires %HSPI_Manager role, use Audit Log > Purge function
• Export audit logs for compliance reporting: Use SQL queries or export to CSV

Database Encryption

• Enable IRIS database encryption for EMPI namespace databases
• Navigate to System Administration > Configuration > Local Databases
• Select EMPI database (e.g., HSPIDATA)
• Enable encryption and specify encryption key
• Store encryption keys securely in enterprise key management system
• Test database access after enabling encryption

LDAP/SAML Authentication

• Integrate EMPI authentication with enterprise directory (Active Directory, LDAP)
• Configure LDAP authentication: System Administration > Security > System Security > LDAP Configurations
• Create LDAP configuration: Specify server, base DN, search filters
• Configure user accounts to use LDAP authentication method
• For SAML/SSO: Configure SAML service provider settings, integrate with identity provider (Okta, Azure AD)
• Test authentication: Verify users can log in with enterprise credentials

---

Overview

After configuring EMPI, the next step is loading demographic data from each participating facility. Initial data loads typically use the Batch Import utility to process large volumes of historical patient records from CSV exports. Ongoing data updates use HL7 ADT feeds for real-time synchronization as patients are registered or updated at facilities.

Proper data loading requires pre-configuration of facilities in the Facility Registry to ensure incoming records are correctly attributed to their source.

Setting Up Batch Import Utility

1. Ensure facilities are defined in Facility Registry with correct Facility Codes 2. Navigate to Edge Gateway namespace (or standalone EMPI namespace) 3. Open Interoperability > Configure > Production 4. Add new service: Click + next to Services 5. Select service class: HS.MPI.Dataload.Delimited.FileService 6. Configure service settings:

• Enabled: Check to activate service
• File Path: Directory where CSV files will be dropped (e.g., /data/import/)
• Target Config Names: Set to "HUB" (UCR) or "HS.Hub.MPI.Manager" (standalone)
• LogFileSpec: Log file path for import results (e.g., /logs/batchimport.log)

7. Apply settings and start service

Batch Import File Format

• CSV or pipe-delimited format with header row
• Required fields: FacilityCode, MRN, LastName, FirstName, DOB, Gender
• Optional fields: SSN, MiddleName, Street, City, State, Zip, Phone, Email
• Field specifications detailed in Batch Load File Specification appendix
• Facility codes must match those defined in Facility Registry
• Date format: YYYYMMDD or YYYY-MM-DD

Loading Data via Batch Import

1. Prepare CSV file with patient data conforming to batch import specification 2. Validate file format: Check header row, required fields, date formats 3. Copy file to configured File Path directory 4. Service automatically detects and processes file 5. Monitor import progress in production message viewer 6. Review LogFileSpec file for import results and errors 7. Check Data Quality dashboards for validation issues 8. Repeat for each facility data file

Configuring HL7 ADT Feeds

1. Define facility in Facility Registry with Edge Gateway assignment 2. Configure HL7 TCP service in Edge Gateway production:

• Add Business Service: EnsLib.HL7.Service.TCPService
• Set IP address and port for HL7 connection
• Configure ACK mode (immediate or application)
• Set TargetConfigNames to routing process

3. Configure DTL transformation from HL7 ADT to SDA format 4. Test HL7 feed: Send sample ADT messages and verify processing 5. Monitor HL7 message flow in production message viewer

Post-Load Validation

• Review Data Quality dashboards for data validation results
• Check Patient Search for sample records to verify data loaded correctly
• Verify facility attribution: Confirm records are tagged with correct facility codes
• Review invalid data: Address validation failures with facility or normalization rules
• Execute linkage build to compute matches among loaded records

---

Overview

Before deploying EMPI to users, administrator must create user accounts and assign appropriate roles based on job responsibilities. EMPI uses InterSystems IRIS security framework with predefined roles that grant specific permissions for EMPI functions. Proper user account management follows the principle of least privilege, granting users only the permissions necessary for their role.

User accounts should be created for EMPI managers (configure and tune), operators (resolve conflicts), viewers (query patients), and administrators (system management).

EMPI User Roles and Permissions

• %HSPI_Manager:
• Access: Definition Designer (full), Worklist (full), Patient Search, Data Quality Manager, Settings
• Use Case: EMPI specialists responsible for tuning linkage definition and managing system configuration
• Permissions: Modify linkage definition, create custom rules, configure settings, resolve worklist conflicts
• %HSPI_Operator:
• Access: Worklist (resolve conflicts), Patient Search, limited Definition Designer (read-only)
• Use Case: Data stewards who resolve duplicate/overlay conflicts but do not change configuration
• Permissions: Link/non-link actions on worklist, search patients, view definition (no changes)
• %HSPI_Viewer:
• Access: Patient Search (read-only), Reports (read-only)
• Use Case: Analysts or auditors who need to query patient data without making changes
• Permissions: Search patients, view audit logs, export reports
• %HS_Administrator:
• Access: All HealthShare administrative functions including production configuration
• Use Case: System administrators responsible for infrastructure and production management
• Permissions: Full system access including user management, production updates, namespace configuration

Creating User Accounts

1. Navigate to Management Portal > System Administration > Security > Users 2. Click Create New User 3. User Name: Enter unique identifier (corporate ID, email, or username) 4. Full Name: Enter user's full name for display and audit purposes 5. Authentication Method: Select Password, LDAP, Kerberos, or Delegated based on enterprise policy 6. Roles: Assign appropriate EMPI roles:

• Add %HSPI_Manager for EMPI specialists
• Add %HSPI_Operator for data stewards
• Add %HSPI_Viewer for read-only users
• Add %HS_Administrator for system admins

7. Password: Set initial password (if using password authentication) meeting complexity requirements 8. Account Expiration: Set expiration date or leave blank for indefinite 9. Enabled: Check to activate account immediately 10. Click Save to create account

LDAP Authentication Configuration

• For enterprise authentication via Active Directory/LDAP:

1. Navigate to System Administration > Security > System Security > LDAP Configurations 2. Create LDAP configuration: Specify server, port (389 or 636 for LDAPS), base DN 3. Configure search filter: (sAMAccountName=%username) for Active Directory 4. Test LDAP connection with test user credentials 5. When creating user accounts, select LDAP authentication method 6. Users authenticate with enterprise credentials; password stored in LDAP, not IRIS

Password Policies

• Configure password requirements: System Administration > Security > System Security > System-wide Security Parameters
• Minimum Length: Recommend 12 characters
• Complexity: Require uppercase, lowercase, numbers, special characters
• Expiration: 90 days recommended for compliance
• History: Prevent reuse of last 5 passwords
• Lockout: Lock account after 5 failed login attempts
• Session Timeout: 30 minutes of inactivity for EMPI workstations

User Account Lifecycle Management

• Onboarding: Create account when user begins EMPI responsibilities
• Role Changes: Update role assignments when job responsibilities change
• Offboarding: Disable account (do not delete) when user leaves organization to preserve audit trail
• Periodic Review: Audit user accounts quarterly to ensure appropriate access levels
• Documentation: Maintain record of account creations, modifications, and deactivations for compliance

---

Overview

InterSystems EMPI provides configurable system settings that control matching behavior, performance characteristics, user interface limits, and audit logging. These settings are stored as global variables in the EMPI namespace and can be modified using Terminal commands. Custom system settings allow tailoring EMPI behavior to organizational requirements and optimizing performance for specific data volumes and usage patterns.

Settings should be carefully documented and tested in development before applying to production.

Accessing System Settings

• Settings are configured as globals using Terminal in the EMPI namespace
• Access Terminal: Management Portal > System Explorer > Terminal
• Set global syntax: `set ^MPRL.Config("category","setting") = value`
• View current setting: `write ^MPRL.Config("category","setting")`
• Caution: No undo for global changes - document original values before modifications

Build Progress Settings

• showProgress: Display progress messages during linkage builds
• `set ^MPRL.Config("buildData","showProgress") = 1` (enabled)
• Use for monitoring long-running builds; disable in production for performance
• blockSize: Number of records processed before progress message
• `set ^MPRL.Config("buildData","blockSize") = 1000`
• Smaller values provide more frequent updates; larger values reduce logging overhead
• singleProcess: Force single-threaded build processing
• `set ^MPRL.Config("buildData","singleProcess") = 1` (single-threaded)
• Use for debugging; disable (0) for production parallel processing

Search Selectivity Settings

• maxMatches: Maximum number of candidate matches to evaluate per record
• `set ^MPRL.Config("search","maxMatches") = 100`
• Higher values improve match accuracy but reduce performance
• minMatchPercentage: Minimum percentage of link key matches required for candidate
• `set ^MPRL.Config("search","minMatchPercentage") = 50`
• Higher percentages reduce false positives but may miss true matches

Build Limit Settings (Development/Testing)

• linkKeyIndexGroupSizeLimit: Limit link key index group size during testing
• `set ^MPRL.Config("buildData","linkKeyIndexGroupSizeLimit") = 1000`
• Prevents runaway builds during tuning; remove limit (0) for production
• transitiveGroupSizeLimit: Limit transitive closure group size
• `set ^MPRL.Config("buildData","transitiveGroupSizeLimit") = 500`
• Prevents memory issues with large linkage chains during development
• maxToBuild-normalized, maxToBuild-classified, maxToBuild-linkkeyindex: Limit records processed in each build phase
• Use during development to speed up iterative tuning
• Remove limits for production builds

UI Table Size Limits

• auditLogMaxResultRows: Maximum rows returned in audit log queries
• `set ^MPRL.Config("ui","auditLogMaxResultRows") = 1000`
• Prevents browser performance issues with large audit logs
• worklistMaxSortRows: Maximum rows sorted in worklist display
• `set ^MPRL.Config("ui","worklistMaxSortRows") = 5000`
• Limits memory usage for worklist sorting operations

Audit Control Settings

• skipAudit: Disable all audit logging
• `set ^MPRL.Config("audit","skipAudit") = 1` (disabled)
• Not recommended for production; use only for performance testing
• skipDemographicAudit: Disable demographic change audit logging
• `set ^MPRL.Config("audit","skipDemographicAudit") = 0` (enabled)
• Enable for compliance; captures all patient demographic changes

MPIID Settings

• enterpriseId: Set starting value for MPIID assignment
• `set ^MPRL.Config("mpiid","enterpriseId") = 1000000`
• Configure before first data load to establish MPIID numbering scheme
• Once set, do not change in production (would create duplicate MPIIDs)

Loading Settings

• skipLinkage: Load patients without computing linkages
• `set ^MPRL.Config("load","skipLinkage") = 1` (skip linkage during load)
• Use for fast initial bulk load; execute linkage build afterward
• Not recommended for production ongoing feeds

---