T1.5: Prepares EMPI System for Go-Live

The transition from development and testing to production operation is a critical milestone in any InterSystems EMPI deployment. Go-live preparation involves systematic validation that the system is configured correctly, secured appropriately, and ready to handle real patient data at production scale.

Understanding Go-Live Readiness

Go-live readiness encompasses multiple dimensions:

Configuration Validation: Ensuring all system components are configured according to best practices and production requirements. This includes production settings, registry configuration, facility and assigning authority registries, and linkage definition parameters.

Security Hardening: Implementing appropriate security controls, including user roles and permissions, authentication mechanisms, audit logging, and encryption for data in transit and at rest.

Performance Verification: Confirming the system can handle expected transaction volumes, data loading rates, and concurrent user access without performance degradation.

Operational Readiness: Ensuring operational procedures are documented, staff are trained, monitoring is configured, and backup/recovery processes are tested.

Data Quality Baseline: Establishing baseline data quality metrics and ensuring initial data loads meet quality standards before ongoing operations begin.

The Role of Configuration Check Utility

InterSystems provides the Configuration Check utility specifically to assist with go-live preparation. This utility performs automated validation of numerous configuration settings that are critical for production operation. The Configuration Check examines system configuration in both InterSystems EMPI and Registry (Hub) namespaces to ensure settings are appropriate for a live, production-quality deployment.

Key Principle: InterSystems strongly recommends running the Configuration Check utility before loading large numbers of patient records and again before go-live. Configuration issues are far easier to correct before the system contains production data.

Pre-Go-Live Timeline

A typical pre-go-live timeline includes:

T-30 days: Final configuration freeze, full Configuration Check, security review initiated

T-14 days: Security settings implementation, user access provisioning, final testing

T-7 days: Final data load, linkage build, data quality validation

T-3 days: Configuration Check rerun, monitoring verification, backup testing

T-1 day: Final readiness review, go-live decision

Go-Live: Transition to production operations, activate real-time data feeds

T+1 day: Post-go-live monitoring, issue triage

This timeline allows adequate time to identify and resolve issues before committing to production operations.

---

The Configuration Check utility is a method that checks system configuration to ensure various settings are appropriate for a live, production-quality InterSystems EMPI deployment. Understanding how to run this utility and interpret its results is essential for go-live preparation.

Accessing the Configuration Check Utility

Based on sample question Q5 from the EMPI exam, the Configuration Check utility is run from the Patient Index Settings menu in the Management Portal. The exact navigation path:

1. Open the Management Portal 2. Navigate to the Person Index menu (location varies by deployment model) 3. Select Settings from the Person Index menu 4. Locate and click the Run Configuration Check option or button

Important for Exam: Sample question Q5 specifically asks where the Configuration Check utility can be run, with the correct answer being "From the Patient Index Settings menu in the Management Portal." This is a direct factual question that tests knowledge of the Management Portal navigation.

Incorrect Options (from Q5):

• From the System Administration menu (incorrect)
• From the Terminal (incorrect - it's a GUI utility)
• From the operating system command line (incorrect)
• From the System Operation menu (incorrect)

Running the Check

Once you access the Configuration Check utility:

1. Click the button or link to run the check 2. The utility executes automatically (no parameters required) 3. Processing typically takes seconds to minutes depending on system size 4. Results are displayed on screen

The Configuration Check can be run as often as needed without any negative impact on the system. It is a read-only operation that examines configuration but does not modify anything.

What the Configuration Check Validates

The Configuration Check utility examines numerous settings across different system components:

Registry Production Settings:

• Hub MPI Manager component configuration
• MPITarget property in Hub web service
• LogEnsSystemError production setting (should be disabled)
• HSPI Operations component settings
• Pool Size appropriateness

Facility Registry:

• All facility codes are unique
• No duplicate facilities differing only by case (e.g., "CGH" vs. "cgh")
• No facilities associated with Edge Gateways have "Home Facility" setting enabled

Assigning Authority Registry:

• All assigning authority codes are unique
• No duplicate authorities differing only by case

Production Components:

• Component names and class names are correct
• Required settings are populated
• Optional settings use recommended values
• No inappropriate subclasses are in use

The complete list of settings checked is documented in the Configuration Check Settings table in the InterSystems EMPI Configuration Guide.

Deployment Model Awareness

The Configuration Check utility is aware of different deployment models and validates only applicable settings:

Deployment Model 1: InterSystems EMPI on its own instance, Registry on different instance

• Checks both EMPI and Registry configurations
• Validates communication settings between instances

Deployment Model 2: InterSystems EMPI on Unified Care Record instance, separate namespace from Registry

• Checks both EMPI and Registry configurations
• Validates namespace-to-namespace communication

Deployment Model 3: InterSystems EMPI in Registry namespace

• Checks Registry configuration
• Skips EMPI production checks (no separate production)

Deployment Model 4: Standalone InterSystems EMPI (no Registry)

• Checks only EMPI configuration
• Skips Registry-related validations

The utility automatically detects the deployment model and adjusts its validation accordingly.

---

The Configuration Check utility produces a comprehensive report identifying configuration issues and providing guidance for resolution. Learning to interpret these results is crucial for go-live preparation.

Result Categories

Configuration Check results are organized by the aspect of configuration being validated:

Production Components: Validation of business operations, business services, and production settings in both EMPI and Registry productions.

Registry Settings: Validation of Registry-specific configuration including facility registry, assigning authority registry, and Hub settings.

Communication Settings: Validation of settings that enable communication between EMPI and Registry components (for applicable deployment models).

Security Settings: Validation of security-related configuration (in some versions of the utility).

Status Indicators

Each checked setting receives a status:

Pass (Green): The setting is configured correctly according to best practices. No action is required.

Fail (Red): The setting is incorrect or misconfigured. This issue must be addressed before go-live. Failure status indicates a configuration that could cause system malfunction, data corruption, or performance problems.

Warning (Yellow): The setting may not be optimal or requires review. Warnings should be investigated to determine if they apply to your deployment scenario. Some warnings are environment-specific and may not require action in all deployments.

Common Configuration Issues

The Configuration Check commonly identifies these issues in pre-go-live systems:

Hub MPI Manager Not Configured Correctly:

• Component name is not exactly "HS.Hub.MPI.Manager"
• Classname is not HS.Hub.MPI.Manager (a subclass is being used)
• MPIOperations is not set to HS.MPI.HSPI.Operations
• DynamicAssignAuthorityRegistration or DynamicFacilityRegistration are enabled (should be cleared)

Incorrect MPITarget:

• The Hub web service MPITarget property does not point to HS.Hub.MPI.Manager
• This prevents proper routing of MPI requests to the linkage engine

LogEnsSystemError Enabled:

• The LogEnsSystemError setting is checked (enabled) in the Registry production
• This causes excessive logging and can degrade performance in production
• Should be unchecked (disabled) for production deployments

HSPI Operations Pool Size Incorrect:

• Pool Size is not set to appropriate value
• Recommended value: Number of Edge Gateways + Expected simultaneous patient searches
• Too small: Performance degradation and timeout errors
• Too large: Excessive resource consumption

Duplicate Facilities or Assigning Authorities:

• Two or more entries differ only by case (e.g., "CGH" and "cgh")
• System treats these as different but this usually indicates a data entry error
• Can cause records to be assigned to wrong facility or authority

Home Facility Setting on Edge Gateway Facility:

• A facility associated with an Edge Gateway has "Home Facility" checked
• This is an invalid configuration that can cause routing errors

Resolving Configuration Issues

When the Configuration Check identifies issues:

1. Document Issues: Record all failures and warnings for tracking 2. Prioritize Corrections: Address all failures first, then warnings 3. Make Corrections: Update configuration settings to resolve issues 4. Rerun Check: After making corrections, rerun Configuration Check to verify 5. Repeat Until Clean: Continue correction cycle until all critical issues are resolved

Best Practice: Achieve a clean Configuration Check (all passes, no failures) before go-live. Some warnings may be acceptable depending on your deployment, but zero failures is the goal.

---

Security is a critical aspect of go-live preparation. InterSystems EMPI contains sensitive patient demographic data and must be secured according to healthcare industry standards (HIPAA in the US, GDPR in Europe, etc.).

User Roles and Permissions

InterSystems EMPI includes predefined roles that should be assigned to users based on their job functions:

%HSPI_Operator Role:

This role is for everyday operational users who work with patient data and resolve linkage conflicts. Users with this role can:

• View the Definition Designer page (read-only)
• Use the Worklist page to review and resolve linkage conflicts
• Use the Whole Record Viewer to examine patient demographics
• Use the Linkage Graph to visualize record relationships
• Use the Record History page to track changes
• Use the Detail Comparison page to compare record pairs
• Use the Composite View page to see aggregated patient data
• Use the Audit Log page to review system activity
• Use the Build Log page to review linkage builds
• Use the Settings page to set color conventions only

What %HSPI_Operator CANNOT Do:

• Modify the linkage definition
• Start or stop linkage builds
• Change system-level settings
• Start or stop productions

%HSPI_Master Role:

This role is for system administrators and data governance specialists who maintain the system. Users with this role have all %HSPI_Operator capabilities plus:

• Full access to Definition Designer to create and modify linkage definitions
• Ability to build linkage data
• Ability to configure system-level items on the Settings page
• Administrative control over EMPI configuration

%Ens_ProductionRun Resource:

Users who need to start and stop productions (required when compiling linkage definitions) must have "USE" permissions on the %Ens_ProductionRun resource. This should only be granted to users with the %HSPI_Master role.

To grant this resource: 1. Navigate to System Administration > Security > Roles 2. Click the role (%HSPI_Master recommended) 3. On the Edit Role page, General tab, click Add in the privileges table 4. Select %Ens_ProductionRun from available resources, click OK 5. Click Edit link in the %Ens_ProductionRun row 6. Under Permissions, select the Use checkbox and click OK

Pre-Go-Live Security Checklist

Before go-live, complete these security tasks:

Review Default Accounts:

• Disable or rename default administrative accounts
• Ensure no accounts have default passwords
• Remove or disable unnecessary service accounts

Implement Password Policy:

• Minimum length (12+ characters recommended)
• Complexity requirements (uppercase, lowercase, numbers, special characters)
• Password expiration (90 days maximum)
• Password history (prevent reuse of recent passwords)
• Account lockout after failed login attempts

User Access Provisioning:

• Create user accounts for all authorized personnel
• Assign appropriate roles based on job functions
• Document role assignments and approvals
• Implement least-privilege principle (minimum necessary access)

Service Account Security:

• Create dedicated service accounts for integrations
• Use strong, unique passwords for service accounts
• Document service account purposes and owners
• Restrict service account permissions to minimum required

---

Encrypting communication between system components and to end users is a critical security requirement for production healthcare systems. InterSystems EMPI supports SSL/TLS encryption for all network communication.

SSL Configuration for Registry Communication

In deployments with separate Registry and EMPI instances (deployment models 1 and 2), communication between components must be encrypted:

Registry SSL Configuration:

The EMPI production configuration includes an sslConfig setting that specifies the SSL configuration to use for Registry communication:

```json "sslConfig": "RegistrySSLconfig" ```

This references an SSL/TLS configuration defined in the InterSystems IRIS Management Portal.

Hub Endpoint HTTPS:

The hubEndpoint setting must use HTTPS (not HTTP) for encrypted communication:

```json "hubEndpoint": "https://MyHost:8443/csp/healthshare/HSREGISTRY/services/HS.Hub.HSWS.WebServices.cls" ```

Note the "https://" protocol and typically port 8443 (though any port can be used).

Creating SSL/TLS Configuration:

To create an SSL/TLS configuration:

1. Navigate to System Administration > Security > SSL/TLS Configurations 2. Click Create New SSL/TLS Configuration 3. Specify configuration name (e.g., "RegistrySSLconfig") 4. Select or import certificate and private key 5. Configure certificate authority (CA) certificates for validation 6. Set other SSL parameters (protocols, cipher suites) 7. Save the configuration

Certificate Requirements:

• Valid X.509 certificate from trusted CA (for production)
• Certificate subject name matches server hostname
• Certificate not expired and within validity period
• Private key securely stored and properly protected
• CA certificate chain included for validation

SSL for Web Portal Access

The Management Portal and Person Index user interface should also be accessed via HTTPS:

Web Server SSL Configuration:

Configure the web server (typically Apache or IIS) to:

• Enable HTTPS on port 443 (or other secure port)
• Install valid SSL certificate
• Redirect HTTP requests to HTTPS
• Disable weak SSL protocols (SSLv2, SSLv3, TLS 1.0)
• Use strong cipher suites

Force HTTPS:

Configure the web server or application to force HTTPS:

• Reject plain HTTP connections
• Automatically redirect HTTP to HTTPS
• Set HSTS (HTTP Strict Transport Security) headers

Certificate Management

Establish processes for certificate management:

Certificate Expiration Monitoring:

• Track expiration dates of all certificates
• Set alerts for certificates expiring within 30-60 days
• Plan certificate renewal well in advance

Certificate Renewal:

• Renew certificates before expiration
• Test renewed certificates in development environment
• Schedule production update during maintenance window
• Verify all components after certificate update

Certificate Revocation:

• Implement certificate revocation checking (CRL or OCSP)
• Revoke certificates for decommissioned systems
• Replace certificates if private keys are compromised

---

Audit logging is essential for healthcare compliance, security monitoring, and forensic investigation. InterSystems EMPI provides comprehensive audit logging capabilities that must be properly configured before go-live.

Audit Events in InterSystems EMPI

InterSystems EMPI can audit numerous event types:

User Access Events:

• User login and logout
• Failed login attempts
• Session timeout
• Role and permission changes

Patient Record Access:

• Patient record searches
• Record views
• Record updates
• Record merges and splits

Linkage Events:

• Manual link creation
• Manual unlink
• Link review and validation
• Linkage definition changes

Administrative Events:

• Production start and stop
• Configuration changes
• User account creation and modification
• Role assignment changes

Data Events:

• Patient record creation
• Patient record updates
• Patient record deletion (if permitted)
• Batch data loads

Configuring Audit Logging

Audit logging is configured through the Management Portal:

1. Navigate to the audit configuration page 2. Enable audit logging 3. Select which event types to audit 4. Configure audit log destination and rotation 5. Set retention period for audit logs

Audit Log Destination:

Audit logs can be stored in:

• InterSystems IRIS database
• External files
• Syslog server
• Security information and event management (SIEM) system

For production systems, sending audit logs to an external SIEM or syslog server provides better security (logs cannot be tampered with by someone who compromises the EMPI system).

Audit Log Security

Audit logs must be secured to prevent tampering:

Access Control:

• Restrict access to audit logs to security administrators only
• Do not grant audit log access to users with %HSPI_Operator or %HSPI_Master roles
• Implement separate audit administrator role

Integrity Protection:

• Use write-once storage for audit logs if possible
• Implement cryptographic signatures on audit log entries
• Send logs to external system immediately (prevents local tampering)

Retention:

• Retain audit logs per regulatory requirements (typically 6-7 years for HIPAA)
• Implement automated archival to long-term storage
• Test audit log restoration procedures

Audit Log Review

Establish procedures for regular audit log review:

Regular Review Schedule:

• Daily: Review security-relevant events (failed logins, unauthorized access attempts)
• Weekly: Review patient record access patterns for anomalies
• Monthly: Comprehensive review of administrative events and configuration changes

Automated Alerting:

• Configure alerts for suspicious patterns (multiple failed logins, after-hours access)
• Alert on administrative changes (role assignments, configuration modifications)
• Alert on unusual patient record access (accessing records of VIPs, employees, etc.)

Audit Reports:

• Generate regular reports on system usage
• Track metrics like user activity, search volumes, linkage operations
• Provide reports to security and compliance teams

---

A comprehensive go-live checklist ensures all aspects of readiness are validated before transitioning to production operations.

Configuration and Technical Readiness

Configuration Check:

• [ ] Configuration Check utility run and passes with no failures
• [ ] All warnings reviewed and addressed or documented as acceptable
• [ ] Linkage definition tested and validated
• [ ] Facility Registry complete and accurate
• [ ] Assigning Authority Registry complete and accurate

Production Settings:

• [ ] LogEnsSystemError disabled in Registry production
• [ ] Pool Size settings appropriate for expected load
• [ ] ServiceName settings point to correct Registry endpoints
• [ ] SSL/TLS configurations validated and tested

Data Quality:

• [ ] Initial data load completed successfully
• [ ] Linkage build completed without errors
• [ ] Data quality metrics meet acceptance criteria
• [ ] Known duplicate pairs resolved or documented

Integration Testing:

• [ ] HL7 data feeds tested and validated
• [ ] Edge Gateway communication verified
• [ ] Registry synchronization confirmed
• [ ] Error handling tested

Security Readiness

User Access:

• [ ] All user accounts created and roles assigned
• [ ] Default accounts disabled or secured
• [ ] Password policy implemented and enforced
• [ ] Service accounts created with minimum necessary permissions

Encryption:

• [ ] SSL/TLS configured for all network communication
• [ ] Certificates valid and from trusted CA
• [ ] HTTPS enforced for web portal access
• [ ] Certificate expiration monitoring implemented

Audit Logging:

• [ ] Audit logging enabled for all required events
• [ ] Audit logs sent to secure external storage
• [ ] Audit log review procedures documented
• [ ] Audit log retention policy implemented

Access Control:

• [ ] Role-based access control (RBAC) implemented
• [ ] Least-privilege principle applied
• [ ] Segregation of duties enforced
• [ ] Access review procedures documented

Operational Readiness

Documentation:

• [ ] System architecture documented
• [ ] Configuration settings documented
• [ ] Integration points documented
• [ ] Operational procedures documented (startup, shutdown, monitoring, troubleshooting)

Training:

• [ ] System administrators trained on EMPI operations
• [ ] Data stewards trained on Worklist processing
• [ ] Help desk trained on basic troubleshooting
• [ ] End users trained on search and access procedures

Monitoring:

• [ ] Production monitoring configured
• [ ] Performance metrics baseline established
• [ ] Alerting configured for critical issues
• [ ] Monitoring dashboard accessible to operations team

Backup and Recovery:

• [ ] Backup procedures tested
• [ ] Recovery procedures tested
• [ ] Recovery time objective (RTO) validated
• [ ] Recovery point objective (RPO) validated

Runbook:

• [ ] Go-live runbook prepared with detailed steps
• [ ] Rollback procedures documented and tested
• [ ] Emergency contacts list prepared
• [ ] Communication plan established

Post-Go-Live Preparation

Hypercare Period:

• [ ] Enhanced monitoring planned for first 48-72 hours
• [ ] 24/7 support coverage arranged
• [ ] Issue triage process defined
• [ ] Escalation procedures documented

Performance Validation:

• [ ] Performance metrics collection configured
• [ ] Baseline performance metrics documented
• [ ] Acceptance criteria for production performance defined
• [ ] Performance degradation response procedures documented

Issue Management:

• [ ] Issue tracking system configured
• [ ] Issue categorization and prioritization defined
• [ ] Response time commitments documented
• [ ] Post-implementation review scheduled

---

Review documentation for detailed information.