Migrating Data to Centricity
®
Practice
Solution
2032026-001 Rev B
March 2007
GE Healthcare
Centricity Practice Solution 2032026-001 Rev B
Centricity®and Logician® are registered trademarks of General Electric Company.
C
ONTENTS
About this guide ...v
Getting the latest information... v
Documentation conventions... vi
Other resources ... vi
Online help (F1)... vi
Documentation on the Centricity Practice Services Web site ... vii
Training database ... vii
If you encounter a problem... vii
Overview of data migration... 1
Data migration phases ... 2
Phase I: Prepare data and environments... 2
Confirm/upgrade EMR database to required version ... 2
Separately install/upgrade to Centricity Practice Solution ...2
Clean up your database(s) and prepare for Centricity Practice Solution ... 3
Backup source and destination databases before migration ... 5
Phase II: Set up the data migration ... 5
Phase III: Migrate data to Centricity Practice Solution ... 6
Data conversion ... 6
Data migration ...6
Data that is not migrated ... 7
Phase IV: Data migration cleanup tasks... 8
Data-matching rules (joint EMR/PM implementation) ...8
Migrate your EMR Oracle data... 9
Set up the Data Migration Wizard... 9
Phase 1: Set up the data migration ...10
Phase 2: Migrate your data ...12
Phase 3: Post-migration cleanup ...15
About post-migration cleanup tasks...16
Data migration processes... 21
Data migration actions...22
Tables involved in migration and upgrade of joint implementations ...23
Data that is not migrated ...23
Migrating user accounts for authentication ...24
Direct data migrations ...25
Complex table migrations ...30
Simple data mappings ...30
Order of data transfer ...31
Doctors, Physicians and Resources ...32
User Resource data ...32
Referring Physician data ...36
Appointment Resource data ...41
Data related to security permissions...42
Business information...43
Employer data ...43
Insurance data...46
Insurance Formulary data ...49
Pharmacy data ...50
Service Provider Organization data ...51
Guarantor information ...53
Patient information ...56
Patient demographics data...56
Patient Insurance data ...63
Patient Personal Contacts data ...68
Patient Pharmacy Relationship Data ...71
Patient Referring Provider Relationship Data ...72
Patient Responsible Provider Relationship Data...74
Patient Personal Relationship Data ...76
Appointments information ...78
Appointments Types ...78
Resource/Provider Schedule Data...79
Appointments data ...85
Insurance Code data ...89
Residual tables...91
Moving data from source to destination ...92
Migrating and upgrading custom reports... 93
Impact of schema changes ...93
Changes to patient relationships ...95
Changes that impact reports...95
Appointments...95
Employers ...96
Insurance ...97
About this guide
This guide provides detailed resources for migrating an Oracle® Centricity EMR database to the Microsoft® SQL Server-based Centricity Practice Solution database. This guide contains the following information:
“Overview of data migration” on page 1, describes the data migration
process, from pre-migration steps to prepare and secure your data through configuring and running the Data Migration Wizard.
“Migrate your EMR Oracle data” on page 9, provides detailed instructions
for configuring and running the migration and carrying out post-migration cleanup tasks.
“Data migration processes” on page 21, describes in detail how data in an
existing Centricity Physician Office – EMR 2005 Oracle database is moved and transformed during the migration, including the source and
destination location (in tables and columns).
“Migrating and upgrading custom reports” on page 93, explains how
custom clinical (EMR) and financial (PM) reports may be affected by the data migration.
Getting the latest information
GE documentation is often updated after general release of the product. To get the latest version of this guide and other documentation go to the Centricity Practice Services Web site at http://centricitypractice.gehealthcare.com.
Check the publication date listed on the title page of all documents and in the lower right corner of left facing pages to see if you need to download a more recent version. In updated versions, content revisions are marked with revision bars.
Getting the latest information v Documentation conventions vi Other resources vi
Documentation conventions
Centricity Practice Solution documentation uses the following conventions to represent different types of information:
Other resources
GE offers a variety of other resources to help you get up and running with the application on a daily basis.
Online help (F1)
When you need a quick answer about using a particular feature in the application, online help is your fastest route. Wherever you are in the application, simply press F1 for relevant help about the task at hand.
This convention... Means this...
monospaced type Type this text exactly as it appears. Chart > Clinical Lists Open the Chart folder and select the
Clinical Lists item.
Ctrl + U Hold down the Ctrl key while you press U, then release both keys
italic type A term that is being defined Information that is important and should not be overlooked
3
Information about a shortcut or other convenient or optional information!!!
Information with a critical impact onsoftware implementation or performance
✖
Warning: the information presented can prevent patient harmIf you encounter a problem
Documentation on the Centricity Practice Services Web site
The Centricity Practice Services Web site contains the latest, downloadable versions of all documentation for Centricity Practice Solution, LinkLogic, Formulary Editor, Encounter Form Editor, EDI plug-ins, and other related applications (with the exception of the online help system.)
You need a logon ID and password to access the documentation area. Contact your clinic manager for your organization’s logon credentials. While at the site you also can
Review known issues.
Search for clinical content in the KnowledgeBank—a repository of
encounter forms and other clinical content ready-made by other users.
Join a mailing list and receive email newsletters on topics related to
clinical content and the Encounter Form Editor, service packs, and technical alerts.
Discuss product features with other users on the discussion forum.
Training database
The Centricity Practice Solution Demo Database helps you get up to speed with Centricity Practice Solution. The database contains patient charts and typical users in several locations of care, with scheduling, and billing information you can practice on without affecting your clinic’s patient records.
If you encounter a problem
If you run into a problem while using Centricity Practice Solution, first try the following:
In the application, press F1 and read the online help for your current
location in the program and the task you’re trying to perform.
Consult relevant user guides (Adobe PDF format) available on the
Centricity Practice Services Web site and the documentation CD.
Ask your clinic’s Centricity Practice Solution Manager for help.
If you’re still having trouble, please contact Centricity Practice Services as follows:
Phone: Dial 888.436.8491, select option 2
Call from a phone next to the workstation where the problem is occurring so it’s easier to answer questions from the Services Engineer. Centricity Practice Services hours are 7 a.m. to 8 p.m. Central Time.
Email: For non-urgent issues related to Centricity Practice Solution, send
email to [email protected]. For issues related to EDI plugins, send e-mail to [email protected].
If you have an urgent question and need immediate help, don’t send email. Instead, call appropriate phone number.
Report a defect or an enhancement idea
To report a defect or drop us a line about an enhancement idea, use the
CHAPTER
1
Overview of data migration
If you are upgrading to Centricity Practice Solution from Centricity Physician Office - EMR 2005 or earlier, your Oracle® database must be transformed to the Microsoft® SQL Server platform and its data migrated to the new
Centricity Practice Solution database schema.
The Centricity Practice Solution Data Migration Wizard walks you through the available migration options and steps from start to finish. The end result is a new Centricity Practice Solution database populated with all the data from your previous EMR implementation.
This guide provides instructions for transforming and migrating your EMR data and includes a detailed description of where your EMR data goes in the new schema during the data migration process.
Data migration phases 2
Phase I: Prepare data and environments 2 Phase II: Set up the data migration 5
Phase III: Migrate data to Centricity Practice Solution 6 Phase IV: Data migration cleanup tasks 8
You must upgrade to Centricity Physician Office - EMR 2005 and apply all required service packs before you can upgrade to Centricity Practice Solution and migrate your EMR data.
If you are also upgrading a version of Centricity Practice Management, you must upgrade to Centricity Physician Office - PM 2004 and apply all required service packs, before upgrading to Centricity Practice Solution.
During upgrade, PM data is automatically transferred to the new Centricity Practice Solution database via the Server Setup application. Data migration is only required upgrading Oracle EMR data.
Data migration phases
The data in your current Oracle database is migrated in four phases:
Phase I: Prepare data and environments
Take the following steps in your current Centricity EMR and PM implementations to prepare for migration. Some steps can be facilitated by running the Data Migration Wizard Pre-Migration Checks. See Step 7 on page 13.
Confirm/upgrade EMR database to required version
If necessary, upgrade your EMR database to Centricity Physician Office - EMR 2005 and apply the latest service pack and KnowledgeBase updates.
For installation instructions, see Installing Centricity Physician Office - EMR on Windows servers available on your Centricity EMR documentation CD and on the Centricity Practice Services Web site at http://centricitypractice.gehealthcare.com.
Separately install/upgrade to Centricity Practice Solution
For information about this migration phase... Go to...
Phase I - Prepare data and environments (1+ days)
Includes steps you must complete to prepare your database and patient data for migration before launching the Data Migration Wizard.
Page 2
Phase II - Set up the data migration (10 minutes)
Includes setup tasks in the Data Migration Wizard, before running the migration program.
Page 5
Phase III - Migrate Oracle data (2-10 hours)
This is an automated process that first transforms and then migrates all your data.
Page 6
Phase IV - Complete data cleanup tasks (Varies)
A series of data cleanup tasks you’ll carry out after data migration in the new Centricity Practice Solution database.
Phase I: Prepare data and environments Solution on a separate server that meets the hardware and software
configuration requirements for the product.
Clean up your database(s) and prepare for Centricity Practice Solution
Carry out the following recommended data cleanup and preparation tasks in your current EMR and PM databases. This will make your migration go more smoothly and may reduce transition time to production in the new database. For some types of cleanup tasks, the Data Migration Wizard runs pre-migration checks to help you find data that needs to be addressed.Run pre-migration checks in the Data Migration Wizard (optional)
Once you enter and validate source and destination databases, the Data Migration Wizard runs the several pre-migration checks. You can use the reports details to make needed changes. See “Phase 2: Migrate your data” on page 12.
You need not exit the Data Migration Wizard during cleanup, but if you have a significant amount of work to do, after running the tool you can exit and return to run the migration later.
The Data Migration Wizard checks for the following types of data:
EMR custom reports that may require updating
Some custom reports created in an earlier version of the EMR application, will not work In the integrated data schema. The Data Migration Wizard lists all reports that might be affected. You will want to review and revise these reports to work in the new schema (including standard reports that you have modified). For information about updating reports, see Chapter 4, “Migrating and upgrading custom reports.”
If you have many custom reports or custom reports that you use on a daily basis, consider updating them for the new schema before migrating so that they will be available to you as soon as you begin using Centricity Practice Solution.
User MIK mappings between source and destination databases
The wizard checks both database to confirm that users in the EMR database are mapped to IDs in the destination database. Any unmapped EMR users will be created as Resources in the destination database by
Refer to the Centricity Practice Solution Server Setup help (on your installation CDs) for summary configuration requirements and detailed installation and upgrade instructions.
For detailed hardware and software configuration requirements, see System Requirements for Centricity Practice Solution available on your Documentation Library CD and also available on the Centricity Practice Services Web site at http://centricitypractice.gehealthcare.com.
default and assigned a new user logon name. These users may require additional setup to access Centricity Practice Solution.
To create MIK mappings, you must run the Server Setup application. See “Modify MIK Mappings” in Server Setup online help for detailed
instructions.
User name conflicts
The Data Migration Wizard lists user logons found in the EMR database that have already been assigned in the Centricity Practice Solution database prior to migration. To avoid overwriting these user identities, change the Centricity Practice Solution logon name. You’ll have an opportunity to merge these users in the wizard after migration completes.
Pending LinkLogic tasks
The Data Migration Wizard checks the EMR database and lists the number of pending tasks. Complete all tasks and shut down the Data Transfer Station before migration so no further jobs are queued.
Duplicate patients
The Data Migration Wizard looks for possible duplicate patients in the source Oracle database, by comparing patient last name, SSN, birth date, sex, and home location. Any possible duplicates are migrated to the destination database if they are not resolved prior to migration.
Clinical data integrity in the EMR database
The Data Migration Wizard checks for orphaned clinical data associated with invalid patient and user IDs. If the wizard reports the presence of invalid user or patient data, exit the tool and contact Centricity Practice Services for help identifying any invalid data.
Clean up data and set up users and patients
Tasks in Centricity EMR application
Complete pending updates and sign all documents.
Clear out Superuser Desktop items, including Flags and documents. Complete LinkLogic data transfers, resolve all errors, and shut down the
Phase II: Set up the data migration access to Centricity Practice Solution with the same set of permissions granted in EMR.
Remove duplicate and obsolete records and values.
Tasks in a joint Centricity EMR/PM implementation
Confirm that each EMR user login ID is mapped to a corresponding value in MIK. The Data Migration Wizard can assist you in identifying these users. See “User MIK mappings between source and destination databases” on page 3.
If you have custom interfaces that rely on Race and Language fields, make sure you assign language and race values to all patients. The presence of patients without these values in the Centricity Practice Solution database may cause problems with your custom interfaces.
Backup source and destination databases before migration
When you are ready to migrate your EMR data, do a full backup of the Oracle database. You should also back up the new Centricity Practice Solution database if it contains upgraded Practice Management data.
Phase II: Set up the data migration
Setting up the Data Migration Wizard to perform your data migration involves the following steps. (For detailed instructions, see “Migrate your EMR Oracle data” on page 9).
1 Select a migration type (EMR only or EMR and PM)
2 Check pre-migration steps. Check off required and recommended
pre-migration steps completed prior to launching the Data Migration Wizard.
3 Create a staging database. Set up and name a temporary SQL-based
staging database on a specified server running Microsoft SQL Server. Before migration, the EMR Oracle database must be converted to the SQL platform. Your data is migrated to Centricity Practice Solution from this special staging database, which tracks the accuracy of the migration and stores problem data you'll be asked to review after migration. 4 Confirm source/staging/destination databases. Confirm the location
and login name and passwords for the following:
Source database: Oracle database you are migrating
Staging database: temporary SQL-based database that will hold
your EMR data
5 Validate database connections. The application automatically checks
the connections to all three databases and display detailed error messages if any connection cannot be made.
6 Review results of pre-migration data checks and if necessary quit the wizard and correct problems before continuing with migration. To
ensure the quality of the migration, the Data Migration Wizard runs the following checks on your source and destination databases and lists data items items/issues found. See “Run pre-migration checks in the Data Migration Wizard (optional)” on page 3.
Phase III: Migrate data to Centricity Practice Solution
Phase III is in two parts: data conversion and data migration.Data conversion
Once you launch the migration process, your data will first be converted from the Oracle to SQL Server platform and placed in the staging database. The conversion process generates a snapshot of the Oracle database to be used in the migration process.
The Data Migration Wizard recreates the Oracle source data schema in a SQL Server-based database on the designated server. Then it copies the Oracle data from the source database into the new database with matching schema. It also resolves any data type conflicts that might exist between Oracle and SQL Server platforms.
When that process is complete, the Data Migration Wizard will begin moving the data from the staging database to the Centricity Practice Solution database.
Data migration
Much of your data moves directly from the Oracle database to the same DO NOT add or modify data in the Oracle source database after the staging database is created. This data will not be migrated.
Phase III: Migrate data to Centricity Practice Solution
Complex data migrations
Other data moves to an entirely new table location in the SQL database. The Data Migration Wizard sets up mapping tables for those values to facilitate their migration to new Centricity Practice Solution tables. During this part of the migration, the wizard may require input from you to determine how to proceed. For example, if EMR data matches more than one record in the destination database (where you previously upgraded an existing PM database to Centricity Practice Solution), you’ll be invited to confirm the correct match.
Types of data affected by schema changes include information about:
Patients, including patient demographic information transferred into the
Centricity Practice Solution Registration module
Patient contacts and contact relationships, including Employers
Guarantors
Insurance companies and formularies Pharmacies
Referring physicians and responsible providers (Doctors) Family members and other relatives
Order providers (laboratories and other service providers)
Patient appointments and user schedules moving to the new Centricity
Practice Solution Scheduling module
Application users (providers, staff, administrators–any individual who
logs into the application)
User security roles and permissions transferred to new tables under the
Centricity Practice Solution Active Directory security model
For detailed information about how these data are migrated and the tables involved, see “Complex table migrations” on page 30.
Data that is not migrated
Two types of data are not migrated to the destination database:
Custom inquiries are not migrated from the INQTYPE, INQPHRAS, and
INQFLTRS tables. You’ll need to recreate your custom inquiries after migration is complete in Centricity Practice Solution.
Pending LinkLogic actions must be completed before migrating
LinkLogic data. Information about pending LinkLogic actions will not be migrated. For details and instructions on how to confirm, see “Data that is not migrated” on page 23.
Phase IV: Data migration cleanup tasks
After all data to be migrated is processed, the Data Migration Wizard displays any data records that require your input to complete the migration and offers options to merge or change certain records. In most cases, you’ll be asked to confirm data matches where more than one potential match exists in the destination database. For detailed instructions for accomplishing these tasks, see “Phase 3: Post-migration cleanup” on page 15.
Data-matching rules (joint EMR/PM implementation)
In a joint implementation, data migration will progress more quickly if prior to upgrade and migration you eliminate duplicate or obsolete records within the separate EMR and PM databases. This will speed migration by reducing the number of potential matches the wizard will invite you to confirm during the cleanup phase of migration.
The following assumptions are made in matching EMR data to previously upgraded PM values in the destination Centricity Practice Solution database. For detailed information about data matching during the migration, see
“Complex table migrations” on page 30.
Unique EMR 2005 records (no match in PM 2004). These records are
migrated to Centricity Practice Solution following the rules for a simple migration.
Unique PM 2004 records (no match in EMR 2005). No action during
migration. These records are simply upgraded to Centricity Practice Solution.
Partial match in destination database. Where partial matches occur in
scheduling and patient (registration) information, the PM record is preferred. But in these cases, the match options are displayed so you can choose the correct match. In cases where stopping to verify matches would stop the migration process (for example, insurance), the wizard will make the best match to migrate and insert a record. In such cases, the wizard displays a list of duplicates created by the insertion, which you can correct later in the application if necessary.
NO records are discarded during migration. If the Data Migration
Wizard presents an EMR record for matching against an existing Centricity Practice Solution record and you choose "no match," the
CHAPTER
2
Migrate your EMR Oracle data
This chapter includes step-by-step instructions for running the Data
Migration Wizard to migrate your Centricity EMR (Oracle) data to Centricity Practice Solution. For information about how the data is migrated, see generally “Data migration processes” on page 21.
Before running the Data Migration Wizard, confirm that you have completed all pre-migration checks and tasks. See “Phase I: Prepare data and
environments” on page 2.
Set up the Data Migration Wizard
The migration process is accomplished in three phases; you must complete each phase before proceeding to the next.
Set up the Data Migration Wizard 9 Phase 1: Set up the data migration 10 Phase 2: Migrate your data 12
Phase 3: Post-migration cleanup 15
For best results GE recommends that you install and run the Data Migration Wizard on the Oracle database server to properly transfer data.
Set up the Data Migration Wizard [ 5 minutes ]
Phase 1: Set up the data migration
In this phase you’ll specify the type of migration, confirm required
pre-migration preparation steps, and create a temporary SQL Server staging database from which your EMR data will be migrated to Centricity Practice Solution.
Phase 1: Set up the data migration [ 15 minutes ]
1 Verify access to an instance of your Centricity Physician Office -
EMR 2005 (Oracle Source Database). Confirm that the latest service
pack and quarterly KnowledgeBase update have been applied to the database.
2 Verify access to a Centricity Practice Solution (SQL Server
Destination Database). Confirm that this database meets all current version, service pack, and licensing requirements. See Server Setup Online help for software requirements and detailed instructions. 3 Verify network connectivity between the two database servers. 4 On the CentricityPhysician Office - EMR 2005 server, copy the Data
Migration Wizard (DMWizInstaller.x.x.x.exe) to a temporary folder.
(.x.x.x refers to the tool version number which may vary.)
5 Double-click DMWizInstallerx.x.x.exe to install the application and follow any onscreen instructions.
1 On the Source Database server, navigate to the location of the Data Migration Wizard and double-click DMWizard.exe.
2 On the Welcome window, click Phase 1: Pre-migration Setup Tasks 3 On the Select Migration Type window, for Source Database, select
one of the following and then click Next:
• EMR 2005 (Oracle) and Centricity PM 2004 or Centricity Practice
Solution (SQL). Select this option if you have both Centricity EMR
Phase 1: Set up the data migration 4 For Required Actions, confirm that your source and destination
databases have been been upgraded to required versions, by checking the following:
Upgrade the source Oracle database to Centricity Physician Office - EMR 2005. This version is required for migration.
Complete pending LinkLogic transactions. Information about
pending transactions is not migrated. See “Data that is not migrated” on page 23.
Install a new Centricity Practice Solution 2006 database (EMR
only migration). This will be your destination database for the migration.
OR
Upgrade the Centricity PM 2004 database to Centricity Practice Solution (EMR and PM migration). This upgraded
database will be your destination database for the migration.
You must check all three requirements. The migration cannot be completed if any steps are omitted.
1 Where applicable, check the following Recommended Actions: Do a full backup of the Oracle source database. this ensures
that you have a recent version of your data to revert to there are any problems with your source data.
Do a full backup of the SQL destination database (if migrating
EMR and PM data).
Stop the SQL Server Agent service on the SQL Server machine
(destination database). It must be restarted after the migration. This improves performance by ensuring that no automated backups or jobs are executed during the migration.
2 Click Next.
3 On SQL Information - Staging Database, do the following: a For SQL Server, enter the name of the server where you will
create a temporary staging database for the migration. This database will hold your EMR data when it is converted to the SQL Server platform. It will be migrated to the Centricity Practice Solution from this location.
The current server name prepopulates this field. To create the staging database on a remote server, enter the IP address or machine name of another server on your network.
b For Authentication, select Windows or SQL Server and (for SQL Server authentication), enter the Login name and Password. If you use Windows authentication, you can only access other servers within the same domain. To access a server in a different domain, use SQL Server authentication.
Phase 2: Migrate your data
In this phase you will configure and test your source, staging, and destination databases, and then run the migration. The data is first transformed from Oracle to SQL Server in the staging database, then migrated to Centricity Practice Solution destination database.
Phase 2: Migrate your data [ duration varies based on DB size]
c For Database Name, enter a name for this staging database. Thedefault name is EMRStagingDb. Unless you require multiple staging databases, GE recommends you accept the default. d Click Create Staging Database. When the process is complete a
confirming message displays to the right.
4 Click Next. A summary screen lists the actions completed and the name and location of the staging database. Click Finished to continue to the next phase or Exit to leave the wizard.
If the selected destination database already contains migrated data, the wizard alerts you and asks you to confirm your selection. If you click Yes to continue, the wizard then checks the patient data in the destination database.
If it find potentially duplicate patient records, you’ll be asked to confirm again. Unless you are migrating multiple EMR databases to a single Centricity Practice Solution database, click No, and return to the Select Migration Type window to reconfigure your migration.
1 On the Welcome screen, click Phase 2: Data Migration Tasks. The Select Source, Staging, and Destination Databases screen opens, where you will configure and test the connections for the source, staging, and destination databases.
2 Under EMR 2005 Database, for Host String, enter the name of the Oracle source database for the migration and the Oracle user Login name and Password.
Phase 2: Migrate your data 4 Under Practice Solution Database, do the following:
a For SQL Server enter the name of the destination database–the Centricity Practice Solution database your EMR data is migrating to.
b For Authentication, select Windows or SQL Server and then enter the SQL Server user Login name and Password for the destination database.
c For Database, if there is more than one database on the server, select the name of the Centricity Practice Solution destination database into which your EMR data will migrate.
The Data Migration Wizard attempts to locate and log in to the source, staging, and destination servers. If validation is
successful, all server icons are green and the application displays a Validation Passed alert.
5 Click Validate Connections. The wizard attempts to locate and log in to the source, staging, and destination servers. If validation is
successful, all server icons are green.
If required source or destination database versions are not found, you’ll be instructed to upgrade to the required or latest version. See
“Phase I: Prepare data and environments” on page 2. If the
destination database version is more recent than your version of the Data Migration Wizard, you’ll be instructed to update the wizard. 6 Click OK to close the alert window and then click Next.
To ensure the quality of the migration, the Data Migration Wizard runs pre-migration checks on your source and destination databases and lists data items and issues found.
7 On the Pre-Migration Checks window, click a data category to see details displayed in the field below.
Plan to run these checks prior to migration if you have a lot of data cleanup work to do. However, you need not exit the wizard to resolve errors, except when instructed to call Centricity Practice Services. Some errors must be corrected before you can migration. The wizard checks for the following types of data:
• EMR custom reports that may require updating. In the integrated Centricity Practice Solution schema, old EMR custom reports may not work properly. For information about updating reports, see
Chapter 4, “Migrating and upgrading custom reports.” You may want to revise your custom reports before migrating, so they will be available and ready to use in the new system.
•• User MIK Mappings between source and destination databases. The Data Migration Wizard checks both database to confirm that users in the EMR database are mapped to IDs in the destination database. Any unmapped EMR users will be created as Resources in the destination database by default and assigned a new user logon name. These users may require additional setup to access Centricity Practice Solution.
• User name conflicts. Listed user logons in the EMR database have been assigned in the Centricity Practice Solution database prior to migration. To avoid overwriting these user identities, during migration, change the logon name. You’ll have an opportunity to merge these users in the wizard after migration completes.
• Pending LinkLogic tasks. The wizard checks the EMR database and lists the number of pending tasks. Complete these tasks before migrating.
• Duplicate patients. The wizard looks for possible duplicate patients in the source Oracle database, by comparing patient last name, SSN, birth date, sex, and home location. Any possible duplicates are migrated to the destination database if they are not resolved prior to migration.
• Clinical data integrity in the EMR database. The wizard checks for orphaned clinical data associated with invalid patient and user IDs. If the wizard reports the presence of invalid user or patient data, exit the wizard and contact Centricity Practice Services for help identifying any invalid data.
You will not be able to continue the migration until these problems are corrected.
8 After correcting problems, click Perform Checks in the tool to re-run the data checks. If you pass the clinical data Integrity check, click
Next to continue.
9 On the Pre-Run Summary screen, confirm your configurations for the data migration and do the following:
• To start the data migration, click Go!
• To change your configuration, click Previous twice. This returns you to the database setup screen, where you can change your configuration and revalidate your connections.
Phase 3: Post-migration cleanup
Phase 3: Post-migration cleanup
When you migrate EMR data into a Centricity Practice Solution database with pre-existing PM data, the wizard attempts to match source EMR data with existing PM data.
Some data cannot be successfully matched and needs your input to be
migrated, for example multiple patient matches or providers with invalid IDs.
Other data is not migrated because it is either invalid or an exact match
already exists in the destination database. These data are displayed for information purposes only. For some unmigrated data, however, you’ll be able to add records or update matches.
DO NOT STOP the migration during the first process (Transfer
Oracle Data to Staging Database) unless an error occurs. This may
cause problems later in the migration. Do not attempt to modify the staging or destination databases during migration.
10When all tasks are completed, click Next to continue.
The Wizard display the results of migrating EMR tables related to Users, Resources, Contacts, Businesses, and Patients to new tables in the Centricity Practice Solution schema. This table shows migration results for these tables. For the records in each table, the following information is displayed:
- Total records - Migrated records
- Records with a single exact match - Records with multiple matches - Records with invalid remapping
- Records with possible duplicates (in the source database
- Orphaned records (associated with invalid data, for example, a contact for a nonexistent patient)
- External ID mismatch - Ignored records
Carefully review these results for anomalies or unexpected results. If desired, copy and paste this data into a spreadsheet to review later.
For detailed information about how EMR data is migrated to the Centricity Practice Solution schema, see “Data migration processes” on page 21.
11To continue to the next phase, click Finished. The initial Welcome screen displays.
About post-migration cleanup tasks
Post-migration data cleanup includes three categories of data and tasks:
Items requiring immediate action
Data with multiple partial matches that must be manually matched to
complete the migration
Critical data integrity problems, including orphaned documents, flags,
and data related to allergies, observations, orders, directives,
medications, or problems mapped to an invalid relationship–to a patient or user that does not exist in the destination database. You may need to contact Centricity Practice Services for help in manually restoring or removing these data.
Optional items requiring action
These include data you can optionally change in the Data Migration Wizard or in the application. Some optional items may not appear in the list if that condition does not exist in your data.
Items for review
These records are not migrated because they are invalid or an exact match already exists in the destination database. These items are informational only.
Phase 3: Post-migration cleanup [ 1 - 4 hours
Items requiring immediate action
1 On the Welcome screen, click Phase 3: Post-Migration.
IOn the Immediate Action Required window, you’ll see critical data requiring your input. These items must be addressed before the
migration can be completed.
As you complete items on this window, they are removed from the list. When all items are completed, you can click Next to continue.
Note: If you have no data that require your action to migrate, you’ll see the Optional Items Requiring User Action window.
Phase 3: Post-migration cleanup 3 Select each data item in the list and follow the instructions displayed
to resolve it. You may be required to quit the wizard to resolve problems in the source database and then re-run the migration. 4 For Patients (or Businesses) with multiple matches, select a record
in the list and click Choose Patient (Business) Match, or just double-click the record in the list.
A window opens with the selected record and all potential matches listed below.
5 Review the displayed data matches and do one of the following: • Select a match and click OK. This identifies a matching record in
the destination database and closes the window. The matched record is now italicized in the list.
• If you choose not to match and migrate the data, click Cancel to close the matching window.
6 To confirm the match and migrate the matched data, click Resolve
Patient or Resolve Business. The data will be migrated to the
matching record, and the matched record will appear greyed out in the problem data list.
This does not remove pre-existing duplicates in the destination database. You must remove those manually within the Centricity Practice Solution application.
To save a group of matched items, depress the Shift key and select the items to group. Then click Save Changes to migrate the group. 7 When all data problems are corrected, click Next to continue. This
completes the migration. Your database is ready for use.
Optional items requiring user action
This screen provides additional tools you can use to review data and perform the following common cleanup tasks. Some items may not appear in the list if that condition does not exist in your data.
1 Under Items Requiring User Action, select from the following optional data cleanup tasks. The tasks options displayed are determined by the types of data encountered during the migration. 2 Under Patient/Person Data, select Duplicate EMR Patients Created
as CPS Patients. These duplicate patients were migrated to the
destination database. They must be merged later in the application. Right-click on the list to copy and paste it to a spreadsheet or text document.
3 Under Patient/Person Data, select EMR Patients with PatientIds in
use in CPS. These patients have new PatientIds because their IDs was
already in use in the Centricity Practice Solution database. Change these IDs to more meaningful values in the application in
Registration.
Right-click on the list to copy and paste it to a spreadsheet or text document.
4 Under User/Role Data, select Resolve EMR and CPS users with Same
Logon Names. Centricity Practice Solution user logon names already
in use were renamed to prevent conflicts with migrating EMR users. To merge these users do the following:
a Select a logon conflict in the list and click View Logons Affected to view the matched users.
b Click OK to accept the match.
c Click Merge Logons to confirm the merge.
5 Under User/Role Data, select Change New Resources from EMR to
Providers. These EMR users were migrated and assigned as
Resources. To optionally change them to Responsible Providers, do the following:
a Select one or more users in the list.
b Click Change Resource to Provider to complete the change. 6 Under User/Role Data, select Change New Providers from EMR to
Resources. These EMR users were migrated and assigned as
Providers. To optionally change them to Resources, do the following: a Select one or more users in the list.
b Click Change Provider to Resource to complete the change. 7 Under User/Role Data, select Merge EMR Resource/Provider with an
Existing CPS Resource/Provider. These EMR Resources/Providers had
no match in the destination database. To match and merge EMR Resources and Providers with Centricity Practice Solution Resources and Provider, do the following:
a Select a user in the list and then click View CPS Resources. b Select an unassigned Resource/Provider.
Phase 3: Post-migration cleanup 8 Under User/Role Data, select Security Groups created from EMR
Roles. These groups were created during the migration based on
existing EMR Roles. If they do not exist in the Windows or server domain selected for security authentication, you must create them manually in Active Directory. Right-click on the the list to copy and paste it to a spreadsheet or text document.
Items for review
With the exception of possibly duplicate insurance information, the
view-only records listed in this section were not migrated because an exact match was found in the destination database.
• Where relevant, click View Match to review the matched information. • Click Cancel to close the window.
• Anomalies should be addressed outside the Data Migration Wizard. You can copy and paste these data into a spreadsheet or text document. 1 Under Business Data, review the following items:
• Invalid Provider Relationships - invalid providers associated with a code or category that were not migrated.
• Invalid EMR formularies associated with an Insurance Carrier - invalid formularies not migrated.
• EMR Insurance Matched to CPS Insurance - not migrated because an exact match was found in the destination database.
• EMR Businesses with no relationships - not migrated because they have no relationship with a Patient.
Possibly Duplicate Insurance Information - plan, insurance, and
formulary information created for an insurance carrier that may duplicate existing data. By default these insurance carriers are set to Inactive status.
Because information about insurance carriers is being moved to new locations in different tables in the new database, some information might be duplicated. Copy and paste this information into a spreadsheet or document and remove the duplicates later in the application.
2 Under Orphans, review the following items:
• Contact relationships not migrated (invalid patient). Contact Relationships associated with an invalid patient are not migrated. • Contact relationships not migrated (invalid contact). Contact
Relationships associated with an invalid contact are not migrated. Information about the relationship between a patient and contact can be “orphaned” when the patient record is removed from the database, but the contact information remains. A contact can be “orphaned” when the contact is removed from the database, but not removed from the patient’s demographic information.
3 Under Patient/Person Data, review the following items if displayed. • EMR Patients Matched to CPS Patients. The listed patients were
not migrated because an exact match was found in the destination database.
• EMR Personal Contacts Matched to CPS Contacts. The listed personal contacts were not migrated because an exact match was found in the destination database.
• EMR Referring Contacts Matched to CPS Contacts. The listed referring contacts were not migrated because an exact match was found in the destination database.
• EMR employers matched to CPS employers. The listed employers were not migrated because an exact match was found in the destination database.
• Orphaned Persons with no Relationships. The listed records from the PERSON table were not migrated because they have no relationship with any patient or business in the destination database.
4 Under User/Role Data, select New Logon Names Associated with
CPS Users. This list includes newly created logon names migrated
from EMR and associated with Centricity Practice Solution users. 5 Under User/Role Data, select Assigned CPS logon names
overwritten by matching EMR logon names. These Centricity
Practice Solution logon names were assigned to users who did not have EMR access prior to the migration. They have been overwritten by preexisting matching EMR logon names and granted EMR access. This new logon value is used to access the application.
6 When you have finished your review, click Finish. This completes the migration and displays a summary screen listing data cleanup actions performed in Phase 3.
To quit the Data Migration Wizard before you have completed your review, click Exit. Your migration process is saved.
The next time you launch the wizard, you’ll be asked to continue a current migration or start a new one. You’ll see a file named
dm_*.config. Select the file and click Continue. Your saved
CHAPTER
3
Data migration processes
After your Oracle data is converted to the SQL Server platform, it is migrated to the new Centricity Practice Solution database. During this mostly
automated process, much of your data moves directly from tables in the Oracle database to tables with the same name in the new SQL database. See
“Direct data migrations” on page 25.
However, because Centricity Practice Solution integrates the Electronic Medical Record and Practice Management data schemas, some patient data is moved to entirely new table locations in the SQL database and might also be manipulated in the process. The Data Migration Wizard sets up
temporary mapping tables for those values to facilitate their migration to the new Centricity Practice Solution tables.
If you are migrating EMR data to a new (empty) Centricity Practice Solution database, the migration is complete at this point. However, if you are upgrading from a prior joint implementation of the Centricity EMR and PM applications, the wizard matches your EMR data with upgraded PM data to create integrated records for patients, users, contacts, businesses, and so on. In the final phase of migration, you’ll be asked to make decisions about some of these records, for example, when the wizard finds multiple matches. You’ll also be informed about possibly duplicate data records that were not migrated because an exact match was found or because the data was not valid.
Data migration actions 22 Direct data migrations 25 Complex table migrations 30
Doctors, Physicians and Resources 32 Data related to security permissions 42 Business information 43
Guarantor information 53 Patient information 56 Appointments information 78 Residual tables 91
This chapter describes how your EMR data is migrated from the Oracle database into the Centricity Practice Solution database and how it is matched with practice management records.
Data migration actions
Data migration actions include the following:
Direct migrations - operations that copy EMR data into identical tables
in the Centricity Practice Solution database. See “Direct data migrations” on page 25.
Simple migrations - operations that copy data into a new table and
column.
Complex migrations - operations that must relink relationships or
transform the source data in some way in addition to moving it into a new table.
For information about how table changes in the integrated schema impact your custom reports, see “Migrating and upgrading custom reports” on page 93.
Example: The ALLERGY table in EMR becomes the Centricity Practice Solution ALLERGY table.
Example: The USR.PVID in EMR becomes the DoctoryFacility.PVId
in Centricity Practice Solution.
Example: The primary physician string value “PP” (in
RELPERS.RELATIONSHIP) is replaced with the numerical value “3”
Data migration actions
Tables involved in migration and upgrade of joint implementations
While many EMR tables are duplicated in the Centricity Practice Solution database, more complex migrations impact key tables in EMR and in the upgraded PM database:
Data that is not migrated
Two types of data will not be migrated to the destination database:
Custom Inquiries will not be migrated from the INQTYPE, INQPHRAS,
and INQFLTRS tables. Custom inquiries must be recreated after
migration activities complete. Prior to migration, go to the Inquiries tab and note the elements of any inquiries you want to recreate.
Pending LinkLogic actions must be completed before migrating
LinkLogic data. Information about pending LinkLogic actions from the following tables is not migrated:
To determine whether all actions are completed, confirm that the
L3TASKONCE table does not contain any currently running tasks.
EMR tables affected PM tables affected APPT BUSINESS PERSON PERSON_PICT RELBUSS RELPERS RELPROV USR INSURANC INSURECO DoctorFacility Employer Guarantor Medlists PatientProfile PatientContacts PatientRelationship Pharmacy
Pending actions data in these LinkLogic tables are not migrated... L3CONTACT L3EVENTLOG L3FORMATS L3HEIRARCHY L3INSURANC L3JOBATTRBIND L3LOCKS L3NOTES L3OBRDATA L3PERSON L3RESOURCE L3RESULTS L3SCHEDULE L3TASKONCE L3TASKRESOURCE
Go to LinkLogic > Jobs and LinkLogic > Errors tabs. On each tab, click
Organize and change the view to see ALL types of jobs or errors from all
stations.
!!!Do not save this setting as a preference, because under normal
operations you’ll want a more limited view.Migrating user accounts for authentication
In earlier versions of the Centricity EMR application, user authentication and security is managed within the database. The security model for Centricity Practice Solution is based on Windows authentication. All users in the Oracle database are migrated to the destination database, but must be configured for Windows authentication via Active Directory.
You’ll find the complete list of users that require accounts on the destination server in the USR table in your Oracle database.
When the USR table is migrated, user permissions (privileges) and roles are assigned in Centricity Practice Solution as they were in the EMR application. Once the user is set up in Active Directory, they will be associated with migrated permissions and roles.
For a list of all EMR user login names, run this SQL command: select LOGINNAME from USR
Resolving user login name conflicts
If you are already running Centricity Practice Solution prior to executing a migration, you might have granted some users access to the application under the same login name they used in the EMR application. During migration, those user login names will be renamed to a recognizable temporary login name by adding a number (e.g., hwinston1) and you’ll be presented with these logins to merge with existing logins in the Centricity Practice Solution database.
Direct data migrations
Direct data migrations
The following table lists database tables that exist in both Centricity Physician Office - EMR and Centricity Practice Solution. With few
exceptions, the data in these tables are copied from the source table to the destination table with no additional steps:
Source Table ➔ Destination Table Migration Action(s) ACCESSAUDIT ACCESSAUDIT Copied from source ALLERGY ALLERGY Copied from source AMH_CHART AMH_CHART Copied from source ASSESS ASSESS Copied from source AUDIT_EVENT AUDIT_EVENT Copied from source AUDIT_EVENT_DETAIL AUDIT_EVENT_DETAIL Copied from source AUDIT_PROFILE AUDIT_PROFILE Copied from source CHRTRULE CHRTRULE Copied from source CONFACCESS CONFACCESS Copied from source CONFREASONS CONFREASONS Copied from source CONFTYPES CONFTYPES Copied from source
CONVRATIO CONVRATIO Copied from source
CPTDEPT CPTDEPT Copied from source CUSTOMALLERGIES CUSTOMALLERGIES Copied from source CUSTOMORDERS CUSTOMORDERS Copied from source DESKDOCVIEWS DESKDOCVIEWS Copied from source DIRECTIV DIRECTIV Copied from source DOCCONTB DOCCONTB Copied from source DOCIMAGES DOCIMAGES Copied from source DOCROUTE DOCROUTE Copied from source
Source Table ➔ Destination Table Migration Action(s) DOCTEMPLATE DOCTEMPLATE Copied from source DOCTYPES DOCTYPES Copied from source DOCUMENT DOCUMENT Copied from source DOCVIEW DOCVIEW Copied from source DOCVIEWS DOCVIEWS Copied from source ENCTYPE ENCTYPE Copied from source EXTID EXTID Copied from source EXTIDSPACE EXTIDSPACE Copied from source EXTREFERENCES EXTREFERENCES Copied from source FINDDLGPREFS FINDDLGPREFS Copied from source
FLAG FLAG Copied from source
FLAGTEMP FLAGTEMP Copied from source FLOWSHEETLABELS FLOWSHEETLABELS Copied from source
FORM FORM Copied from source
FORMMEDS FORMMEDS Copied from source FORMSET FORMSET Copied from source FORMULARY FORMULARY Copied from source HANDDEPT HANDDEPT Copied from source
HIERGRPS HIERGRPS All records copied where GROUPID does not exist in destination
HIEROBJS HIEROBJS Copied from source HOUTMAPCRS HOUTMAPCRS Copied from source HOUTMAPMS HOUTMAPMS Copied from source HOUTPICTS HOUTPICTS Copied from source HOUTTEXTCRS HOUTTEXTCRS Copied from source HOUTTEXTMS HOUTTEXTMS Copied from source
Direct data migrations
Source Table ➔ Destination Table Migration Action(s) INQTYPE INQTYPE Not migrated* JOBTITLE JOBTITLE Copied from source
L3ATTRBIND L3ATTRBIND All records copied from source where Location = 1 or Location >= 100
L3ATTRDEFINE L3ATTRDEFINE Copied from source L3COMMPARAMS L3COMMPARAMS Copied from source
L3CONTACT L3CONTACT Not migrated* L3DTS L3DTS Copied from source L3DTSRESOURCE L3DTSRESOURCE Copied from source
L3EVENTLOG L3EVENTLOG Not migrated* L3FORMATS L3FORMATS Not migrated*
L3HIERARCHY L3HIERARCHY All records from source whereItemId >= 100 L3INSURANC L3INSURANC Not migrated* L3JOBATTRBIND L3JOBATTRBIND Not migrated* L3LOCKS L3LOCKS Not migrated* L3NOTES L3NOTES Not migrated* L3OBRDATA L3OBRDATA Not migrated* L3PERSON L3PERSON Not migrated* L3QUALIFIER L3QUALIFIER Copied from source L3RESOURCE L3RESOURCE Not migrated*
L3RESULTS L3RESULTS Not migrated* L3SCHEDULE L3SCHEDULE Not migrated*
L3SUBTASK L3SUBTASK Copied from source L3TASKDTS L3TASKDTS Copied from source L3TASKONCE L3TASKONCE Not migrated*. L3TASKRECUR L3TASKRECUR Copied from source L3TASKRESOURCE L3TASKRESOURCE Not migrated*
L3TASKSTATUS L3TASKSTATUS Copied from source L3TASKSTEP L3TASKSTEP Copied from source L3TASKTYPE L3TASKTYPE Copied from source LIC_HISTORY LIC_HISTORY Copied from source MD_OLDREG OLDREG Copied from source
Source Table ➔ Destination Table Migration Action(s) MD_RESULTS MD_RESULTS Copied from source MEDDEPT MEDDEPT Copied from source MEDICATE MEDICATE Copied from source MEDINFO MEDINFO Copied from source MISCDEPT MISCDEPT Copied from source ML_MASTERMERGE MASTERMERGE Copied from source ML_MERGEAUDIT MERGEAUDIT Copied from source ML_MERGEGLOBALS MERGEGLOBALS Copied from source MRUCUSTOMLISTS MRUCUSTOMLISTS Copied from source MS_D01 MS_D01 Copied from source MS_D02C MS_D02C Copied from source MS_D02I MS_D02I Copied from source MS_M01 MS_M01 Copied from source MS_M02 MS_M02 Copied from source MS_TCRF MS_TCRF Copied from source
OBS OBS Copied from source
OBSHEAD OBSHEAD Copied from source ORDENCDX ORDENCDX Copied from source ORDDX ORDDX Copied from source ORDER_ENTRY_MODIFIERS ORDER_ENTRY_MODIFIERS Copied from source ORDER_MODIFIERS ORDER_MODIFIERS Copied from source ORDERCAT ORDERCAT Copied from source ORDERCODES ORDERCODES Copied from source ORDERLETTERS ORDERLETTERS Copied from source ORDTOCOMPLETE ORDTOCOMPLETE Copied from source PASSHISTORY PASSHISTORY Copied from source PATCHES PATCHES Copied from source
Direct data migrations
Source Table ➔ Destination Table Migration Action(s) PRINTCHARTTMP PRINTCHARTTMP Copied from source PRINTDATATMP PRINTDATATMP Copied from source PRINTDRVTMP PRINTDRVTMP Copied from source PRINTERS PRINTERS Copied from source PRINTNOTETMP PRINTNOTETMP Copied from source PROBLEM PROBLEM Copied from source PROBLEMLISTVIEWNAMES PROBLEMLISTVIEWNAMES Copied from source PROBLEMLISTVIEWS PROBLEMLISTVIEWS Copied from source PROCINFO PROCINFO Copied from source QPICKS QPICKS Copied from source QPRINTDOC QPRINTDOC Copied from source QPRINTPROPS QPRINTPROPS Copied from source ROLETYPE ROLETYPE Copied from source RPTPROP RPTPROP Copied from source SAVINQ SAVINQ Copied from source SAVINQPHRAS SAVINQPHRAS Copied from source SECPROF SECPROF Copied from source SERVPROV SERVPROV Copied from source SERVREG SERVREG Copied from source
SPECIALTYTYPE SPECIALTYTYPE All records copied where SPID does not exist in destination SUPERBILLDEF SUPERBILLDEF Copied from source
SYMBOL SYMBOL All records copied where ID does not exist in destination
SYSTEMTEMP SYSTEMTEMP Copied from source TEMPLATE TEMPLATE Copied from source TEXTMACROS TEXTMACROS Copied from source
UNIQUEID UNIQUEID All records copied where CHECKCOL does not exist in destination
USERDICT USERDICT Copied from source USRFAVCOMPS USRFAVCOMPS Copied from source
*
See “Data that is not migrated” on page 23.Complex table migrations
Complex migrations involve moving existing data from the source database to a location in the destination database where there has been a significant schema change. This section describes how those migrations are handled.
Simple data mappings
In some cases data in EMR tables that are not replicated in the new schema, such as PERSON, USR, or BUSINESS, are simply moved to new locations in the schema.
Complex data mappings
In other cases, other operations are needed to relink relationships or transform the source data in some way in addition to moving it into a new table. In cases where source database tables do not exist in the destination database, mapping tables are created to re-link broken interdependencies for remaining tables that resulted from migrating data to new tables. These re-mapping tables will remain afterwards for historical purposes.
Data cleanup operations
When attempting to match EMR data to preexisting PM data in the destination database, the Data Migration Wizard will classify all data processed during the migration. In some cases, the wizard will display the details if your input is required to determine how non-migrated data should be treated. Data will not be migrated when:
Multiple partial matches in the destination database: You’ll determine
the correct match. You may be presented with multiple matches for patients or businesses.
Possible duplicate records: You’ll decide whether both records should
be stored in the destination database. In some cases possibly duplicate insurance, plan, or formulary information is migrated. When possibly duplicate insurance carriers are created they are set to the Inactive status.
Complex table migrations
Not migrated: A single exact match was found, so partial matches or
duplicate data are not migrated. This information is displayed for your information, but no action is required.
Migrated: No match was found, so the data is inserted in the appropriate
table. No action is required.
Orphans: Usually data related to an invalid person or patient. For
example, contact relationships to patients or contacts that do not exist in the destination database are not migrated.
NULL: This data was not migrated because it is not associated with any
relationship. Typically, these are duplicates of data already matched in yours system. Examples include invalid providers associated with a code or category, invalid formularies associated with an insurance carrier, persons not associated with any valid patient or business, and businesses with no relationship to a patient. You may need to manually restore these data if you want to keep them.
Order of data transfer
Data migrations need to occur in a specified order to ensure all data are properly linked. Generally, your data will be copied to the new database in the following order to avoid “chicken before egg” data issues related to key constraints and to ensure that all the data ends up where it belongs:
Users and roles Doctors Referring Physicians Security Employers Insurance Pharmacy Patients Guarantors Patients
Personal Contacts (into tables) Contact Relationships
Doctors, Physicians and Resources
In Centricity Practice Solution, Resources include medical personnel or medical equipment used during a patient visit. A resource can be a
physician, a nurse, equipment, or lab work. Information about these data in the EMR application is migrated to a variety of new tables in Centricity Practice Solution.
User Resource data
All EMR users (in USR, RELPROV, LOCREG tables) are moved to the
DoctorFacility table. When there is no data match in the destination
database (EMR-only migration), the record is inserted as a Resource Type and can be changed in the Post-Migration Cleanup phase, under Manage
EMR Users/Roles.
Relevant SQL
A trigger fires when inserting into DoctorFacility that updates the USR record with the DoctorFacilityId for the given PVID.
SQL matching rules (joint implementations)
USR.UPIN = DoctorFacility.UPIN USR.DEANumber = DoctorFacility.DEA
USR.LICNUMBER like DoctorFacility.StateLicenseNo
USR.LASTNAME like DoctorFacility.Last + DoctorFacility.Suffix and
USR.FIRSTNAME like DoctorFacility.First --all existing users
select distinct * from USR left outer join
Doctors, Physicians and Resources
Simple User Resource table mappings
EMR only: Simple mappings when migrating EMR data to an empty
destination database.
Joint EMR/PM: Simple mappings when migrating EMR data to a Centricity
Practice Solution database containing upgraded PM data. Source Table: USR, LOCREG, ➔ Dest Table: DoctorFacility Migration Action(s)
USR.FIRSTNAME DoctorFacility.First Data copied from source USR.MIDDLENAME DoctorFacility.Middle Data copied from source USR.LASTNAME DoctorFacility.Last Data copied from source LOCREG.ADDRESS1 DoctorFacility.Address1 Data copied from source LOCREG.ADDRESS2 DoctorFacility.Address2 Data copied from source LOCREG.CITY DoctorFacility.City Data copied from source LOCREG.STATE DoctorFacility.State Data copied from source LOCREG.ZIP DoctorFacility.Zip Data copied from source LOCREG.COUNTRY DoctorFacility.Country Data copied from source USR.LICNUMBER DoctorFacility.StateLicenseNo Data copied from source USR.GLOBALID DoctorFacility.GalacticId Data copied from source USR.CURRENTLOC DoctorFacility.FacilityId Data copied from source USR.PRESCRIBERID DoctorFacility.PrescriberId Data copied from source USR.DB_CREATE_DATE DoctorFacility.Created Data copied from source USR.DB_UPDATED_DATE DoctorFacility.LastModified Data copied from source
Source Table: USR, LOCREG, ➔ Destination Table: DoctorFacility Migration Action(s) USR.PVID DoctorFacility.PVId Data copied from source USR.LOGINNNAME DoctorFacility.LoginUser Data copied from source USR.HOMELOCATION DoctorFacility.LocationId Data copied from source USR.MEMBERID DoctorFacility.MemberId Data copied from source USR.DEANUMBER DoctorFacility.DEA Data copied from source USR.JOBTITLE DoctorFacility.JobTitleGID Data copied from source
Complex User Resource table mappings
EMR only: Complex mappings when migrating EMR data to an empty
destination database.
Joint EMR/PM: Complex mappings when migrating EMR data to a Centricity
Practice Solution database containing upgraded PM data. See also next section, “User Resource date requiring user input (joint EMR/PM)” on page 35.
Source Table: USR, LOCREG, ➔ Dest Table: DoctorFacility Migration Action(s)
USR.PHONE DoctorFacility.Phone1 Copy data from source removing non-numeric characters
- DoctorFacility.Type Assigns to 1 if Rolelist indicates Doctor, otherwise defaults to 3. 1 - Doctor 2 - Facility 3 - 'PP' Physician 5 - 'RP' Referring Physician 6 - Resource 7 - Other Provider - DoctorFacility.ListName Populate with Last, First
- DoctorFacility.Phone2Type Populate with value 'Fax' if LOCREG.FAXPHONE != NULL
- DoctorFacility.CreatedBy Populate with MigrationUsr - DoctorFacility.LastModifiedBy Populate with MigrationUsr - DoctorFacility.DoctorFacilityId Auto-generated new ID
Source Table: USR, RELPROV,
LOCREG, ➔ Dest Table: DoctorFacility Migration Action(s)
USR.SPECIALTY DoctorFacility.SpecialtyMId 1 Query SPECIALTYTYPE table for Description column where USR.SPECIALTY =
SPECIALTYTYPE.SPID
2 User-explicit mapping to (Description) MedlistsId; Query Medlists table for Description match like SPECIALTYTYPE. Description AND table name = Specialty
Doctors, Physicians and Resources
User Resource date requiring user input (joint EMR/PM)
For the following data items, if a single, exact match cannot be made, the Data Migration Wizard presents the source data and possible matches in the destination database and asks you to decide which values to save to the destination database.Source table ➔ Destination table Phase III Migration action(s) RELPERS.RELATIONSHIP DoctoryFacility.Type Type = 3 for ’PP’ or ‘RP’, otherwise 7
USR.TITLE DoctorFacility.Prefix Select data to save USR.FIRSTNAME DoctorFacility.First Select data to save USR.MIDDLENAME DoctorFacility.Middle Select data to save
USR.LASTNAME DoctorFacility.Last Strip entitlements from field; user selects data to save
LOCREG.ADDRESS1 DoctorFacility.Address1 Select data to save LOCREG.ADDRESS2 DoctorFacility.Address2 Select data to save LOCREG.CITY DoctorFacility.City Select data to save LOCREG.STATE DoctorFacility.State Select data to save LOCREG.ZIP DoctorFacility.Zip Select data to save LOCREG.COUNTRY DoctorFacility.Country Select data to save
USR.PHONE DoctorFacility.Phone1 Copy data from source removing non-numeric characters
User selects data to save LOCREG.FAXPHONE DoctorFacility.Phone3 Select data to save
