Migrating Data to Centricity Practice Solution

GE Healthcare Migrating Data to Centricity Practice Solution 2032026-001 Rev B March 2007 Centricity Practice Solution 2032026-001 Rev B 2006 General Electric Company

All information is subject to change without notice. This information is the confidential and proprietary information of General Electric Company. Unauthorized duplication is strictly prohibited. Centricity and Logician are registered trademarks of General Electric Company. 2006 General Electric Company. All Rights Reserved. GE Healthcare, 540 W. Northwest Highway, Barrington, IL 60010, USA

CONTENTS 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 Complex data mappings...30 Data cleanup operations...30 2006 General Electric Company

Migrating Data to Centricity Practice Solution 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 Orders...98 Patients...99 Pharmacy...100 Relationships...100 Service Providers...101 Practice management views...102 Crystal Reports v10.0 required for custom reports...103 Converting EMR custom reports to Crystal Reports v10.0...103 Converting PM custom reports to Crystal Reports v10.0...104 iv 2006 General Electric Company March 2007

About this guide Getting the latest information v Documentation conventions vi Other resources vi If you encounter a problem vii 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. 2006 General Electric Company

Migrating Data to Centricity Practice Solution Documentation conventions Centricity Practice Solution documentation uses the following conventions to represent different types of information: This convention... monospaced type Chart > Clinical Lists Ctrl + U italic type!!! Means this... Type this text exactly as it appears. Open the Chart folder and select the Clinical Lists item. Hold down the Ctrl key while you press U, then release both keys A term that is being defined Information that is important and should not be overlooked Information about a shortcut or other convenient or optional information Information with a critical impact on software implementation or performance Warning: the information presented can prevent patient harm Other resources Online help (F1) GE offers a variety of other resources to help you get up and running with the application on a daily basis. 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. Find conceptual information in the help Glossary Follow task procedures Use process maps to locate key tasks in a workflow vi 2006 General Electric Company March 2007

If you encounter a problem Documentation on the Centricity Practice Services Web site Training database 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. 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: 2032026-001 Rev B 2006 General Electric Company vii

Migrating Data to Centricity Practice Solution Report a defect or an enhancement idea 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 centricitypmservices@ge.com. For issues related to EDI plugins, send e-mail to centricityediservices@ge.com. If you have an urgent question and need immediate help, don t send email. Instead, call appropriate phone number. To report a defect or drop us a line about an enhancement idea, use the Product Feedback Form on the Centricity Practice Services Web site. viii 2006 General Electric Company March 2007

CHAPTER 1 Overview of data migration 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 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. 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. 2006 General Electric Company

Migrating Data to Centricity Practice Solution Data migration phases The data in your current Oracle database is migrated in four phases: For information about this migration phase... 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. Phase II - Set up the data migration (10 minutes) Includes setup tasks in the Data Migration Wizard, before running the migration program. Phase III - Migrate Oracle data (2-10 hours) This is an automated process that first transforms and then migrates all your data. 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. Go to... Page 2 Page 5 Page 6 Page 8 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 Centricity PM customers: If you are already running a joint PM/EMR implementation with a version of Centricity Practice Management, upgrade that PM database to Centricity Practice Solution. Centricity EMR customers: If you are upgrading from the Centricity Electronic Medical Record application only, install a new instance of Centricity Practice 2 2006 General Electric Company March 2007

Phase I: Prepare data and environments Solution on a separate server that meets the hardware and software configuration requirements for the product. 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. 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 2032026-001 Rev B 2006 General Electric Company 3

Migrating Data to Centricity Practice Solution 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 Data Transfer Station.. Remove or merge duplicate charts. All apparent duplicates are migrated. If you do not resolve duplicates prior to migration, you can remove them in Centricity Practice Solution. Tasks in Centricity Practice Solution/Centricity PM applications Create/confirm all Centricity Practice Solution users in Active Directory on the domain where the destination database is located. Create/confirm Active Directory Security Groups to represent EMR user Role assignments. This ensures that all clinic users have immediate 4 2006 General Electric Company March 2007

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 Destination database: Centricity Practice Solution database 2032026-001 Rev B 2006 General Electric Company 5

Migrating Data to Centricity Practice Solution 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 Data conversion Phase III is in two parts: data conversion and data migration. Data migration 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. DO NOT add or modify data in the Oracle source database after the staging database is created. This data will not be migrated. 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. Much of your data moves directly from the Oracle database to the same table in the new Microsoft SQL Server database. These migrations require little or no input from you. For a list of tables that are replicated in the Centricity Practice Solution schema, see Direct data migrations on page 25. 6 2006 General Electric Company March 2007

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 Data that is not migrated 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. 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. 2032026-001 Rev B 2006 General Electric Company 7

Migrating Data to Centricity Practice Solution 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 partially matching record is migrated as a new record. 8 2006 General Electric Company March 2007

CHAPTER 2 Migrate your EMR Oracle data 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 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 For best results GE recommends that you install and run the Data Migration Wizard on the Oracle database server to properly transfer data. The migration process is accomplished in three phases; you must complete each phase before proceeding to the next. 2006 General Electric Company

Migrating Data to Centricity Practice Solution Set up the Data Migration Wizard [ 5 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 Centricity Physician 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. 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 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 and PM products. You are migrating EMR data to a Centricity Practice Solution database that already contains patient and user information from Centricity PM. As the migration wizard moves your Oracle data, it will try to match EMR and PM shared values.. EMR 2005 (Oracle). Select this option if you only have Centricity EMR 2005 and either a non-ge practice management application or a billing service. You are migrating EMR data into an empty Centricity Practice Solution database. 10 2006 General Electric Company March 2007

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 b 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. 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. 2032026-001 Rev B 2006 General Electric Company 11

Migrating Data to Centricity Practice Solution c d Phase 2: Migrate your data For Database Name, enter a name for this staging database. The default name is EMRStagingDb. Unless you require multiple staging databases, GE recommends you accept the default. 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. 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] 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. 3 Under Staging Database confirm the name and authentication for the staging database. If the information you entered in the previous screen does not automatically appear in these fields, re-enter the database name, login and password. 12 2006 General Electric Company March 2007

Phase 2: Migrate your data 4 Under Practice Solution Database, do the following: a b c For SQL Server enter the name of the destination database the Centricity Practice Solution database your EMR data is migrating to. For Authentication, select Windows or SQL Server and then enter the SQL Server user Login name and Password for the destination database. 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. 2032026-001 Rev B 2006 General Electric Company 13

Migrating Data to Centricity Practice Solution 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. This phase of the migration may last up to several hours depending on the size of your database. The Data Migration Wizard first converts your data from Oracle to the SQL Server platform and copies it into the staging database. From there it copies the data into the new SQL database, matching EMR and PM data (joint implementations) and resolving any data type conflicts. 14 2006 General Electric Company March 2007

Phase 3: Post-migration cleanup 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. 10 When 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. 11 To continue to the next phase, click Finished. The initial Welcome screen displays. 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. In this phase you ll review data presented by the wizard and, where necessary, confirm matches so data migration can be completed. 2032026-001 Rev B 2006 General Electric Company 15

Migrating Data to Centricity Practice Solution About post-migration cleanup tasks Items requiring immediate action Optional items requiring action Items for review Post-migration data cleanup includes three categories of data and tasks: 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. 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. 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. 2 In the navigation panel, expand EMR Data Problems. For each data integrity category, problem records display on the left. A problem description and instructions for resolution appear above. If any data is hidden, maximize the window to expand the table columns. Individual columns and window sections can also be resized. 16 2006 General Electric Company March 2007

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. 2032026-001 Rev B 2006 General Electric Company 17

Migrating Data to Centricity Practice Solution 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 b c Select a logon conflict in the list and click View Logons Affected to view the matched users. Click OK to accept the match. 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. c Click Merge Resource/Provider to merge the user with the selected Resource/Provider. 18 2006 General Electric Company March 2007

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. 2032026-001 Rev B 2006 General Electric Company 19

Migrating Data to Centricity Practice Solution 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 migration opens at the point where you exited from the process. 20 2006 General Electric Company March 2007

CHAPTER 3 Data migration processes 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 Moving data from source to destination 92 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. 2006 General Electric Company

Migrating Data to Centricity Practice Solution 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. For information about how table changes in the integrated schema impact your custom reports, see Migrating and upgrading custom reports on page 93. 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. Example: The ALLERGY table in EMR becomes the Centricity Practice Solution ALLERGY table. Simple migrations - operations that copy data into a new table and column. Example: The USR.PVID in EMR becomes the DoctoryFacility.PVId in Centricity Practice Solution. Complex migrations - operations that must relink relationships or transform the source data in some way in addition to moving it into a new table. Example: The primary physician string value PP (in RELPERS.RELATIONSHIP) is replaced with the numerical value 3 (in DoctorFacility.Type). 22 2006 General Electric Company March 2007

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: EMR tables affected APPT BUSINESS PERSON PERSON_PICT RELBUSS RELPERS RELPROV USR INSURANC INSURECO PM tables affected DoctorFacility Employer Guarantor Medlists PatientProfile PatientContacts PatientRelationship Pharmacy 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: 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 To determine whether all actions are completed, confirm that the L3TASKONCE table does not contain any currently running tasks. 2032026-001 Rev B 2006 General Electric Company 23

Migrating Data to Centricity Practice Solution 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. 24 2006 General Electric Company March 2007

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 2032026-001 Rev B 2006 General Electric Company 25

Migrating Data to Centricity Practice Solution 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 ICDDEPT ICDDEPT Copied from source IGNOREOBJECTS IGNOREOBJECTS Copied from source INETSERVICES INETSERVICES All records copied where SVCID does not already exist in destination INQFLTRS INQFLTRS Not migrated* INQPHRAS INQPHRAS Not migrated* 26 2006 General Electric Company March 2007

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 2032026-001 Rev B 2006 General Electric Company 27

Migrating Data to Centricity Practice Solution 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 PERIOD PERIOD Copied from source PRBLOOK PRBLOOK Copied from source PRBXREF PRBXREF Copied from source PREF PREF Copied from source PREFDEF PREFDEF All records copied where PREFNAME does not already exist in destination 28 2006 General Electric Company March 2007

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. 2032026-001 Rev B 2006 General Electric Company 29

Migrating Data to Centricity Practice Solution Complex table migrations Simple data mappings 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. Complex 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. Data cleanup operations 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. 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. Invalid data: This data is mapped to an invalid relationship a patient or user that does not exist in the destination database. These might be duplicates of data already matched in your system or symptoms of a data integrity problem. The details of these data are displayed after the migration. You may need to contact Centricity Practice Services for help manually restoring the data. These data might include documents, flags, and data related to allergies, observations, orders, directives, medications, or problems. 30 2006 General Electric Company March 2007

Complex table migrations Order of data transfer 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. 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 Appointments 2032026-001 Rev B 2006 General Electric Company 31

Migrating Data to Centricity Practice Solution Doctors, Physicians and Resources User Resource data 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. 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. --all existing users select distinct * from USR left outer join LOCREG on USR.HOMELOCATION = LOCREG.LOCID 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 32 2006 General Electric Company March 2007

Doctors, Physicians and Resources Simple User Resource table mappings EMR only: Simple mappings when migrating EMR data to an empty destination database. 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 Joint EMR/PM: Simple mappings when migrating EMR data to a Centricity Practice Solution database containing upgraded PM data. 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 2032026-001 Rev B 2006 General Electric Company 33

Migrating Data to Centricity Practice Solution Complex User Resource table mappings EMR only: Complex mappings when migrating EMR data to an empty destination database. 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 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, 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 USR.DB_CREATE_DATE DoctorFacility.Created Replace if older than DoctorFacility.Created USR.DB_UPDATED_DATE DoctorFacility.LastModified Populate with current date - DoctorFacility.Phone3Type Populate with value: Fax; If Phone3!= NULL - DoctorFacility.LastModifiedBy Populate with MigrationUsr - DoctorFacility.DoctorFacilityID Auto-generated ID if new record 34 2006 General Electric Company March 2007

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 USR.LICNUMBER DoctorFacility.StateLicenseNo Select data to save 2032026-001 Rev B 2006 General Electric Company 35

Migrating Data to Centricity Practice Solution Referring Physician data EMR application Doctors who are not Centricity Practice Solution users but related patient providers (PERSON, RELPERS, and PERSON_PICT tables) are moved to the DoctorFacility table. They are classified as a Doctor related to a Patient and either a Referring Physician or a Primary Physician. When there is no data match in the destination database (EMR-only migration), the record is inserted. Relevant SQL A trigger fires when inserting into the DoctorFacility table that updates the USR record with the DoctorFacilityId for the given PVID. select distinct PERSON.*, PERSON_PICT.* from PERSON left outer join PERSON_PICT on PERSON_PICT.PID = PERSON.PID inner join RELPERS on RELPERS.PERID = PERSON.PID where ISPHYSICIAN = 'Y' and RELATIONSHIP in ('RP', 'PP') SQL matching rules (joint implementations) PERSON.UPIN = DoctorFacility.UPIN PERSON.DEANumber = DoctorFacility.DEA PERSON.LICNUMBER = DoctorFacility.StateLicenseNo PERSON.LASTNAME like DoctorFacility.Last + DoctorFacility.Suffix PERSON.FIRSTNAME like DoctorFacility.First 36 2006 General Electric Company March 2007

Doctors, Physicians and Resources Simple Referring Physician table mappings EMR only: Simple mappings when migrating EMR data to an empty destination database. Source Table: PERSON Dest Table: DoctorFacility Migration Action(s) PERSON.TITLE DoctorFacility.Prefix Data copied from source PERSON.FIRSTNAME DoctorFacility.First Data copied from source PERSON.MIDDLENAME DoctorFacility.Middle Data copied from source PERSON.LASTNAME DoctorFacility.Last Data copied from source PERSON.ENTITLEMENTS DoctorFacility.Suffix Data copied from source PERSON.SEARCHNAME DoctorFacility.ListName Data copied from source PERSON.ADDRESS1 DoctorFacility.Address1 Data copied from source PERSON.ADDRESS2 DoctorFacility.Address2 Data copied from source PERSON.CITY DoctorFacility.City Data copied from source PERSON.STATE DoctorFacility.State Data copied from source PERSON.ZIP DoctorFacility.Zip Data copied from source PERSON.COUNTRY DoctorFacility.Country Data copied from source PERSON.WORKPHONE DoctorFacility.Phone1 Data copied from source, removing non-numeric characters PERSON.HOMEPHONE DoctorFacility.Phone2 Data copied from source, removing non-numeric characters PERSON.FAXPHONE DoctorFacility.Phone3 Data copied from source, removing non-numeric characters PERSON.UPIN DoctorFacility.UPIN Data copied from source PERSON.LICNUMBER DoctorFacility.StateLicenseNo Data copied from source PERSON.REGNOTE DoctorFacility.Notes Data copied from source PERSON.HOMELOCATION DoctorFacility.LocationId Data copied from source PERSON.DB_CREATE_DATE DoctorFacility.Created Data copied from source PERSON.DB_UPDATED_DATE DoctorFacility.LastModified Data copied from source PERSON.DEANUMBER DoctorFacility.DEA Data copied from source 2032026-001 Rev B 2006 General Electric Company 37

Migrating Data to Centricity Practice Solution Joint EMR/PM: Simple mappings when migrating EMR data to a Centricity Practice Solution database containing upgraded PM data. Source Table: PERSON Dest Table: DoctorFacility Migration Action(s) PERSON.DEANUMBER DoctorFacility.DEA Data copied from source Complex Referring Physician table mappings EMR only: Complex mappings when migrating EMR data to an empty destination database. Source Table: PERSON Dest Table: DoctorFacility Migration action(s) PERSON.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 tablename = Specialty - DoctorFacility.Type Assign to value of 3: 1 - Doctor 2 - Facility 3 - 'PP' Physician 5 - 'RP' Referring Physician 6 - Resource 7 - Other Provider - DoctorFacility.Phone3Type Populate with value: Fax; If Phone3!= NULL - DoctorFacility.CreatedBy Populate with MigrationUsr - DoctorFacility.LastModifiedBy Populate with MigrationUsr - DoctorFacility.DoctorFacilityId Populate with current date 38 2006 General Electric Company March 2007

Doctors, Physicians and Resources Joint EMR/PM: Complex mappings when migrating EMR data to a Centricity Practice Solution database containing upgraded PM data. See also next section, Referring Physician data requiring user input (joint EMR/PM) on page 40. Source Table: RELPERS, PERSON Dest Table: DoctorFacility Migration action(s) RELPERS.RELATIONSHIP DoctoryFacility.Type 1 Determine value of 3 since the RELPERS.RELATIONSHIP should be 'RP' or PP : 1 - Doctor 2 - Facility 3 - 'PP' Physician 5 - 'RP' Referring Physician 6 - Resource 7 - Other Provider Both EMR and PM source data should match after conversion of the RELPERS.RELATIONSHIP since these are both referring physicians. PERSON.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 tablename = Specialty PERSON.DB_CREATE_DATE DoctorFacility.Created Replace if older than DoctorFacility.Created PERSON.DB_UPDATED_DATE DoctorFacility.LastModified Populate with current date - DoctorFacility.Phone3Type Populate with value: Fax; If Phone3!= NULL - DoctorFacility.LastModifiedBy Populate with MigrationUsr - DoctorFacility.DoctorFacilityID Auto-generated ID if new record 2032026-001 Rev B 2006 General Electric Company 39

Migrating Data to Centricity Practice Solution Referring Physician data 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 Migration action(s) PERSON.TITLE DoctorFacility.Prefix Select data to save PERSON.FIRSTNAME DoctorFacility.First Select data to save PERSON.MIDDLENAME DoctorFacility.Middle Select data to save PERSON.LASTNAME DoctorFacility.Last Select data to save PERSON.LASTNAME/ PERSON.ENTITLEMENTS DoctorFacility.Suffix Select data to save; suffixes are removed in transfer PERSON.SEARCHNAME DoctorFacility.ListName Select data to save PERSON.ADDRESS1 DoctorFacility.Address1 Select data to save PERSON.ADDRESS2 DoctorFacility.Address2 Select data to save PERSON.CITY DoctorFacility.City Select data to save PERSON.STATE DoctorFacility.State Select data to save PERSON.ZIP DoctorFacility.Zip Select data to save PERSON.COUNTRY DoctorFacility.Country Select data to save PERSON.WORKPHONE DoctorFacility.Phone1 Select data to save Non-numeric characters removed in transfer PERSON.ALTPHONE DoctorFacility.Phone2 Select data to save Non-numeric characters removed in transfer PERSON.FAXPHONE DoctorFacility.Phone3 Select data to save Non-numeric characters removed in transfer PERSON.UPIN DoctorFacility.UPIN Select data to save PERSON.LICNUMBER DoctorFacility.StateLicenseNo Select data to save PERSON.REGNOTE DoctorFacility.Notes Select data to save 40 2006 General Electric Company March 2007

Doctors, Physicians and Resources Appointment Resource data When migrating EMR data to a new Centricity Practice Solution database (EMR-only) all non-persons in the source database BOOK (and LOCREG) tables are moved to the destination database DoctorFacility table. Any persons associated with a book will be added as a resource later when migrating EMR users. Relevant SQL A trigger fires when inserting into the DoctorFacility table that updates the USR record with the DoctorFacilityId for the given PVID. --all appointment resources select * from BOOK inner join LOCREG on BOOK.LOCID = LOCREG.LOCID where BOOKTYPE <> 'P' Simple Appointment Resource table mappings Source Table: BOOK Dest Table: DoctorFacility Migration Action(s) BOOK.Name DoctorFacility.First Data copied from source BOOK.Name DoctorFacility.ListName Data copied from source BOOK.DB_CREATE_DATE DoctorFacility.Created Data copied from source BOOK.DB_UPDATED_DATE DoctorFacility.LastUpdated Data copied from source Complex Appointment Resource table mappings Source Table: BOOK Dest Table: DoctorFacility Migration Action(s) - DoctorFacility.Type Assign to value of 1: 1 - Doctor 2 - Facility 3 - 'PP' Physician 5 - 'RP' Referring Physician 6 - Resource 7 - Other Provider 2032026-001 Rev B 2006 General Electric Company 41

Migrating Data to Centricity Practice Solution Data related to security permissions For users assigned one or more roles in the EMR application, all their security permissions (in SECGATE, SECPROF, USR tables) are migrated to the SecuritySettings table. Relevant SQL -- Declare Variables DECLARE @sqlquery as varchar(4000) DECLARE @loginname as varchar(32) DECLARE @gatedesc as varchar(80) -- Temp table to store user permissions create table #USRPermissions ( LOGINNAME varchar(32) GATEDESC varchar(80) ) -- Get sql queries to return individual permissions for -- each user and store into temporary table for processing select 'set @loginname = '''+LOGINNAME+ ''' select @gatedesc = SECGATE.GATEDESC from SECGATE where SECGATE.gateid in (select GATEID from SECPROF where ROLEID in ('+GROUPLIST+') or secprof.gateid in ('+grouplist+'))' as PermissionsQuery into #migratepermissions from [cpo_emr_train].[dbo].[usr] where GROUPLIST is not null -- Execute each query for user permissions DECLARE @sqlquery varchar(2000) DECLARE Row CURSOR FOR SELECT PermissionsQuery FROM #migratepermissions OPEN Row FETCH Row INTO @sqlquery WHILE @@Fetch_Status = 0 BEGIN insert #USRPermissions EXEC (@sqlquery) FETCH Row INTO @sqlquery END CLOSE Row DEALLOCATE Row - Select all the distinct users and their permissions select distinct * from #USRPermissions -- Drop temp tables drop table #migratepermissions drop table #USRPermissions 42 2006 General Electric Company March 2007

Business information Complex Security table mappings Source Table: temp migration table Dest Table: SecuritySettings Migration action(s) #USRPermissions.LOGINGNAME SecuritySettings.UserGroup Copy column data from source #USRPermissions.GATEDESC SecuritySettings.SecurityNodesId 1 Query SecurityNodes table for match where Description = #USRPermissions.GATEDESC 2 Populate with SecurityNodes.SecurityNodesId - SecuritySettings.Allowed. Populate with CurrentTime - SecuritySettings.SecurityType Populate with NULL - SecuritySettings.Created Populate with CurrentTime - SecuritySettings.CreatedBy Populate with MigrationUsr - SecuritySettings.LastModified Populate with CurrentTime - SecuritySettings.LastModifiedBy Populate with MigrationUsr - SecuritySettings.SecuritySettingsId Auto-generated new id Business information The following sections describe how EMR business information is migrated, including information about employers, insurance companies, pharmacies, and service provider organizations. Employer data Businesses (BUSINESS table) that are not insurance companies, pharmacies, or order providers are moved to the Employers table. When there is no data match in the destination database (EMR-only migration), the record is inserted. Relevant SQL select distinct * from BUSINESS where ISINSCO is NULL and ISPHARMACY is NULL and ISORDERPROV is NULL 2032026-001 Rev B 2006 General Electric Company 43

Migrating Data to Centricity Practice Solution SQL matching rules BUSINESS.Name like Employer.Name BUSINESS.ADDRESS1 like Employer.Address1 Simple Employer table mappings (EMR only) Source Table: BUSINESS Dest Table: Employers Migration Action(s) BUSINESS.NAME Employer.Name Data copied from source BUSINESS.NAME Employer.ListName Data copied from source BUSINESS.ADDRESS1 Employer.Address1 Data copied from source BUSINESS.ADDRESS2 Employer.Address2 Data copied from source BUSINESS.CITY Employer.City Data copied from source BUSINESS.STATE Employer.State Data copied from source BUSINESS.ZIP Employer.Zip Data copied from source BUSINESS.COUNTRY Employer.Country Data copied from source BUSINESS.PRIMPHONE Employer.Phone1 Data copied from source, removing non-numerical characters BUSINESS.SECPHONE Employer.Phone2 Data copied from source, removing non-numerical characters BUSINESS.DB_CREATE_DATE Employer.Created Data copied from source BUSINESS.DB_UPDATED_DATE Employer.LastModified Data copied from source Complex Employer table mappings EMR only: Complex mappings when migrating EMR data to an empty destination database. Source Table: BUSINESS Dest Table: BusinessID.Mapping Source Table - Employer.CreatedBy Populate with MigrationUsr - Employer.LastModifiedBy Populate with MigrationUsr Employer.EmployerId Auto-generate new ID 44 2006 General Electric Company March 2007

Business information Joint EMR/PM: Complex mappings when migrating EMR data to a Centricity Practice Solution database containing upgraded PM data. See also next section. Source Table: BUSINESS Dest Table: BusinessID.Mapping Source Table BUSINESS.DB_CREATE_DATE Employer.Created If USR.DB_CREATE_DATE older than DoctorFacility.Created, replace it. BUSINESS.DB_UPDATED_DATE Employer.LastModified Populate with CurrentTime - Employer.LastModifiedBy Populate with MigrationUsr - Employer.Phone3Type Populate with value fax if BUSINESS.FAXPHONE is not NULL - Employer.EmployerId Auto-generated new ID Employer data 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 Migration Action(s) BUSINESS.NAME Employer.Name User selects data to save BUSINESS.NAME Employer.ListName User selects data to save BUSINESS.ADDRESS1 Employer.Address1 User selects data to save BUSINESS.ADDRESS2 Employer.Address2 User selects data to save BUSINESS.CITY Employer.City User selects data to save BUSINESS.STATE Employer.State User selects data to save BUSINESS.ZIP Employer.Zip User selects data to save BUSINESS.COUNTRY Employer.Country User selects data to save BUSINESS.PRIMPHONE Employer.Phone1 Data copied from source, removing non-numerical characters User selects data to save BUSINESS.SECPHONE Employer.Phone2 Data copied from source, removing non-numerical characters User selects data to save BUSINESS.FAXPHONE Employer.Phone3 Data copied from source, removing non-numerical characters User selects data to save 2032026-001 Rev B 2006 General Electric Company 45

Migrating Data to Centricity Practice Solution Insurance data Businesses flagged as insurance companies (BUSINESS, INSURECO tables) are moved to the InsuranceCarriers and InsuranceCarriersFormulary tables. When there is no data match in the destination database (EMR-only migration), the record is inserted. Relevant SQL select distinct BUSINESS.*, INSURECO.ORDCOMMENTS, INSURECO.AUTHFORMTYPE, INSURECO.AUTHFORMPATH, INSURECO.FID, INSURECO.INSPLANID from BUSINESS inner join INSURECO on BUSINESS.BUSID = INSURECO.BUSID where ISINSCO = Y and ISPHARMACY is NULL and ISORDERPROV is NULL SQL matching rules BUSINESS.NAME like InsuranceCarriers.Name BUSINESS.ADDRESS1 like InsuranceCarriers.Address1 (esp. PO Box) Simple Insurance table mappings EMR only: Simple mappings when migrating EMR data to an empty destination database. Source Table: BUSINESS, INSURECO Dest. Table: InsuranceCarriers Migration Action(s) BUSINESS.NAME INSURECO.PLANCODE BUSINESS.NAME INSURECO.PLANCODE InsuranceCarriers.Name InsuranceCarriers.ListName BUSINESS.NAME and INSURECO.PLANCODE concatenated BUSINESS.NAME and INSURECO.PLANCODE concatenated BUSINESS.ADDRESS1 InsuranceCarriers.Address1 Data copied from source BUSINESS.ADDRESS2 InsuranceCarriers.Address2 Data copied from source BUSINESS.CITY InsuranceCarriers.City Data copied from source BUSINESS.STATE InsuranceCarriers.State Data copied from source BUSINESS.ZIP InsuranceCarriers.Zip Data copied from source BUSINESS.COUNTRY InsuranceCarriers.Country Data copied from source BUSINESS.CONTACT InsuranceCarriers.Contact Data copied from source INSURECO.ORDCOMMENTS InsuranceCarriers.OrderNotes Data copied from source 46 2006 General Electric Company March 2007

Business information Source Table: BUSINESS, INSURECO Dest. Table: InsuranceCarriers Migration Action(s) INSURECO.AUTHFORMTYPE INSURECO.AUTHFORMPATH InsuranceCarriers.PreAuthorization FormType InsuranceCarriers.PreAuthorization FormFile Data copied from source Data copied from source BUSINESS.KEYWORD InsuranceCarriers.KeyWord Data copied from source BUSINESS.DB_CREATE_DATE InsuranceCarriers.Created Data copied from source BUSINESS.DB_UPDATED_DATE InsuranceCarriers.LastModified Data copied from source Joint EMR/PM: Simple mappings when migrating EMR data to a Centricity Practice Solution database containing upgraded PM data. Source Table: BUSINESS, INSURECO Dest. Table: InsuranceCarriers Migration Action(s) INSURECO.AUTHFORMTYPE INSURECO.AUTHFORMPATH InsuranceCarriers.PreAuthorization FormType InsuranceCarriers.PreAuthorization FormFile Data copied from source Data copied from source BUSINESS.KEYWORD InsuranceCarriers.KeyWord Data copied from source Complex Insurance table mappings EMR only: Complex mappings when migrating EMR data to an empty destination database. Source Table: BUSINESS, INSURECO Dest Table: InsuranceCarriers Migration action(s) BUSINESS.PRIMPHONE InsuranceCarriers.Phone1 Data copied from source, removing non-numerical characters BUSINESS.SECPHONE InsuranceCarriers.Phone2 Data copied from source, removing non-numerical characters BUSINESS.FAXPHONE InsuranceCarriers.Phone3 Data copied from source, removing non-numerical characters INSURECO.INSPLANID InsuranceCarriers.InsuranceCarriers GroupId Re-map to InsuranceCarriersGroupId using INSPLANIDMapping table - InsuranceCarriers.Phone3Type Populate with value Fax if BUSINESS.FAXPHONE is NULL - InsuranceCarriers.Deductible Populate with value 0.0 - InsuranceCarriers.RequiresAuth Populate with value 1 if PreAuthorizationFormFile is not NULL, otherwise with 0 - InsuranceCarriers.CreatedBy Populate with MigrationUsr - InsuranceCarriers.LastModifiedBy Populate with MigrationUsr - InsuranceCarriers.InsuranceCarriersId Auto-generated new ID 2032026-001 Rev B 2006 General Electric Company 47

Migrating Data to Centricity Practice Solution Joint EMR/PM: Complex mappings when migrating EMR data to a Centricity Practice Solution database containing upgraded PM data. See also next section, Insurance data requiring user input (joint EMR/PM) on page 48. Source Table: BUSINESS, INSURECO Dest Table: InsuranceCarriers Migration action(s) BUSINESS.DB_CREATE_DATE InsuranceCarriers.Created If USR.DB_CREATE_DATE older than DoctorFacility.Created, replace it BUSINESS.DB_UPDATED_DATE InsuranceCarriers.LastModified Populate with CurrentTime - InsuranceCarriers.LastModifiedBy Populate with MigrationUsr - InsuranceCarriers.Phone3Type Populate with value fax if BUSINESS.FAXPHONE is not NULL - InsuranceCarriers.Insurance CarriersId Auto-generated new ID Insurance data 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 Migration Action(s) BUSINESS.NAME InsuranceCarriers.Name User selects data to save InsuranceCarriers.ListName User selects data to save BUSINESS.ADDRESS1 InsuranceCarriers.Address1 User selects data to save BUSINESS.ADDRESS2 InsuranceCarriers.Address2 User selects data to save BUSINESS.CITY InsuranceCarriers.City User selects data to save BUSINESS.STATE InsuranceCarriers.State User selects data to save BUSINESS.ZIP InsuranceCarriers.Zip User selects data to save BUSINESS.COUNTRY InsuranceCarriers.Country User selects data to save BUSINESS.CONTACT InsuranceCarriers.Contact User selects data to save BUSINESS.PRIMPHONE InsuranceCarriers.Phone1 Data copied from source, removing non-numerical characters User selects data to save BUSINESS.SECPHONE InsuranceCarriers.Phone2 Data copied from source, removing non-numerical characters User selects data to save BUSINESS.FAXPHONE InsuranceCarriers.Phone3 Data copied from source, removing non-numerical characters User selects data to save INSURECO.ORDCOMMENTS InsuranceCarriers.OrderNotes User selects data to save 48 2006 General Electric Company March 2007

Business information Insurance Formulary data Information about insurance plan formularies (BUSINESS, INSURECO tables) is moved to the InsuranceCarriersFormulary table. Relevant SQL select distinct BUSINESS.BUSID, INSURECO.* from BUSINESS inner join INSURECO on BUSINESS.BUSID = INSURECO.BUSID where ISINSCO = 'Y' and ISPHARMACY is NULL and ISORDERPROV is NULL and FID is not NULL Simple Formulary table mappings Source Table: INSURECO Dest. Table: InsuranceCarriersFormulary Migration Action(s) INSURECO.FID InsuranceCarriersFormulary.FormularyId Data copied from source Complex Formulary table mappings Source Table: BUSINESS Dest. Table: InsuranceCarriersFormulary Migration Action(s) BUSINESS.BUSID InsuranceCarriersFormulary.Insurance CarriersId Re-map BUSINESS.BUSID to InsuranceCarrierId using BUSIDMapping table - InsuranceCarriersFormulary.Created Populate with MigrationUsr - InsuranceCarriersFormulary.CreatedBy Populate with current time - InsuranceCarriersFormulary.LastModified Populate with MigrationUsr - InsuranceCarriersFormulary.LastModified By - InsuranceCarriersFormulary.Insurance CarriersFormularyId Populate with current time Auto-generate ID 2032026-001 Rev B 2006 General Electric Company 49

Migrating Data to Centricity Practice Solution Pharmacy data Businesses flagged as pharmacies in the (BUSINESS table are moved to the Pharmacy table. When there is no data match in the destination database (EMR-only migration), the record is inserted. Relevant SQL select distinct * from BUSINESS where ISINSCO is NULL and ISPHARMACY = 'Y' and ISORDERPROV is NULL SQL matching rules BUSINESS.NAME like Pharmacy.Name BUSINESS.ADDRESS1 like Pharmacy.Address1 (esp. PO Box) Simple Pharmacy table mappings Source Table: BUSINESS Dest. Table: Pharmacy Migration Action(s) BUSINESS.NAME Pharmacy.Name Data copied from source BUSINESS.NAME Pharmacy.ListName Data copied from source BUSINESS.ABBREVNAME Pharmacy.AbbreviatedName Data copied from source BUSINESS.ADDRESS1 Pharmacy.Address1 Data copied from source BUSINESS.ADDRESS2 Pharmacy.Address2 Data copied from source BUSINESS.CITY Pharmacy.City Data copied from source BUSINESS.STATE Pharmacy.State Data copied from source BUSINESS.ZIP Pharmacy.Zip Data copied from source BUSINESS.COUNTRY Pharmacy.Country Data copied from source BUSINESS.EMAIL Pharmacy.EmailAddress Data copied from source BUSINESS.CONTACT Pharmacy.Contact Data copied from source BUSINESS.NCPDPID Pharmacy.NCPDPId Data copied from source BUSINESS.KEYWORD Pharmacy.KeyWord Data copied from source BUSINESS.DB_CREATE_DATE Pharmacy.Created Copy column data from source BUSINESS.DB_UPDATED_DATE Pharmacy.LastModified Copy column data from source 50 2006 General Electric Company March 2007

Business information Complex Pharmacy table mappings Source Table: BUSINESS Dest. Table: Pharmacy Migration Action(s) BUSINESS.PRIMPHONE Pharmacy.Phone1 Data copied from source removing non-numerical characters BUSINESS.SECPHONE Pharmacy.Phone2 Data copied from source removing non-numerical characters BUSINESS.FAXPHONE Pharmacy.Phone3 Data copied from source removing non-numerical characters - Pharmacy.Phone3Type Populate with value: Fax; If BUSI- NESS.FAXPHONE!= NULL - Pharmacy.CreatedBy Populate with MigrationUsr - Pharmacy.LastModifiedBy Populate with MigrationUsr - Pharmacy.Inactive Populate with value 0 - Pharmacy.PharmacyId Auto-generated new id Service Provider Organization data Businesses flagged as order providers in the (BUSINESS table are moved to the SERVPROVORG table. When there is no data match in the destination database (EMR-only migration), the record is inserted. Relevant SQL select distinct * from BUSINESS where ISINSCO is NULL and ISPHARMACY is NULL and ISORDERPROV = 'Y' 2032026-001 Rev B 2006 General Electric Company 51

Migrating Data to Centricity Practice Solution Simple Service Provider Organization table mappings Source Table: BUSINESS Dest. Table: SERVPROVORG Migration Action(s) BUSINESS.NAME SERVPROVORG.Name Data copied from source BUSINESS.NAME SERVPROVORG.ListName Data copied from source BUSINESS.ADDRESS1 SERVPROVORG.Address1 Data copied from source BUSINESS.ADDRESS2 SERVPROVORG.Address2 Data copied from source BUSINESS.CITY SERVPROVORG.City Data copied from source BUSINESS.STATE SERVPROVORG.State Data copied from source BUSINESS.ZIP SERVPROVORG.Zip Data copied from source BUSINESS.COUNTRY SERVPROVORG.Country Data copied from source BUSINESS.EMAIL SERVPROVORG.EmailAddress Data copied from source BUSINESS.CONTACT SERVPROVORG.Contact Data copied from source BUSINESS.CONTACTBY SERVPROVORG.ContactBy Data copied from source BUSINESS.REFFORMPATH SERVPROVORG.RefFormPath Data copied from source BUSINESS.REFFORMTYPE SERVPROVORG.RefFormType Data copied from source BUSINESS.TESTFORMPATH SERVPROVORG.TestFormPath Data copied from source BUSINESS.TESTFORMTYPE SERVPROVORG.TestFormType Data copied from source BUSINESS.PRINTDEST SERVPROVORG.PrintDest Data copied from source BUSINESS.KEYWORD SERVPROVORG.Keyword Data copied from source BUSINESS.DB_CREATE_DATE SERVPROVORG.Created Data copied from source BUSINESS.DB_UPDATED_DATE SERVPROVORG.LastModified Data copied from source Complex Service Provider Organization table mappings Source Table: BUSINESS Dest Table: SERVPROVORG Migration Action(s) BUSINESS.PRIMPHONE SERVPROVORG.Phone1 Data copied from source removing non-numeric characters BUSINESS.SECPHONE SERVPROVORG.Phone2 Data copied from source removing non-numeric characters BUSINESS.FAXPHONE SERVPROVORG.Phone3 Data copied from source removing non-numeric characters - SERVPROVORG.CreatedBy Populate with MigrationUsr - SERVPROVORG.LastModifiedBy Populate with MigrationUsr - SERVPROVORG.ServProvOrgId Auto-generated new id 52 2006 General Electric Company March 2007

Guarantor information Guarantor information All non-persons flagged in the source database as a guarantor and related to a patient in the PERSON, RELPERS, and RELBUS tables are moved to the destination database Guarantor table. When there is no data match in the destination database (EMR-only migration), the record is inserted. Relevant SQL select distinct PERSON.*, RELBUSS.BUSID from PERSON inner join RELPERS on RELPERS.PERID = PERSON.PID left outer join RELBUSS on PERSON.PID = RELBUSS.PID where RELPERS.RELATIONSHIP = 'GR' SQL matching rules PERSON.LastName like Guarantor.Last PERSON.FirstName like Guarantor.First PERSON.Phone1 Simple Guarantor table mappings Source Table: PERSON Dest Table: Guarantor Migration Action(s) PERSON.TITLE Guarantor.Prefix Data copied from source PERSON.FIRSTNAME Guarantor.First Data copied from source PERSON.MIDDLENAME Guarantor.Middle Data copied from source PERSON.LASTNAME Guarantor.Last Data copied from source PERSON.ENTITLEMENTS Guarantor.Suffix Data copied from source PERSON.ADDRESS1 Guarantor.Address1 Data copied from source PERSON.ADDRESS2 Guarantor.Address2 Data copied from source PERSON.CITY Guarantor.City Data copied from source PERSON.STATE Guarantor.State Data copied from source PERSON.ZIP Guarantor.Zip Data copied from source PERSON.COUNTRY Guarantor.Country Data copied from source PERSON.EMAIL Guarantor.EmailAddress Data copied from source PERSON.DATEOFBIRTH Guarantor.Birthday Data copied from source 2032026-001 Rev B 2006 General Electric Company 53

Migrating Data to Centricity Practice Solution Source Table: PERSON Dest Table: Guarantor Migration Action(s) PERSON.SEX Guarantor.Sex Data copied from source PERSON.DB_CREATE_DATE Guarantor.Created Data copied from source PERSON.DB_UPDATED_DATE Guarantor.LastModified Data copied from source Complex Guarantor table mappings EMR only: Complex mappings when migrating EMR data to an empty destination database. Source Table: PERSON Dest Table: Guarantor Migration Action(s) PERSON.WORKPHONE Guarantor.Phone1 Data copied from source removing non-numeric characters PERSON.ALTPHONE Guarantor.Phone2 Data copied from source removing non-numeric characters PERSON.FAXPHONE Guarantor.Phone3 Data copied from source removing non-numeric characters PERSON.SOCSECNO Guarantor.SSN Data copied from source removing non-numeric characters RELBUSS.BUSID Guarantor.EmployerId Remapped to EmployerId using BUSIDMapping table and populated PERSON.EMPLSTATUS Guarantor.EmpStatudMId User-explicit mapping to (Code) MedlistsId; Use MedlistsMapping table AND tablename = EmploymentStatus - Guarantor.Phone3Type Populated with the value Fax if PERSON.FAXPHONE is not NULL - Guarantor.EmployerID Retrieved from PatientRelationship using PatientProfileId from BUSIDMapping - Guarantor.CreatedBy Populated with MigrationUsr - Guarantor.LastModifiedBy Populated with MigrationUsr - Guarantor.GuarantorId Auto-generated new ID Joint EMR/PM: Complex mappings when migrating EMR data to a Centricity Practice Solution database containing upgraded PM data. See also next section, Guarantor data requiring user input (joint EMR/PM) on page 55. Source Table: PERSON Dest Table: Guarantor, PatientContacts Migration Action(s) PERSON.DB_CREATE_DATE PatientContacts.Created Copies older source data PERSON.DB_UPDATED_DATE PatientContacts.LastModified Populates with current date - Gurantor.Phone3Type Populates with value Fax if PERSON>FAXPHONE is not NULL. - PatientContacts.LastModifiedBy Populates with MigrationUsr 54 2006 General Electric Company March 2007

Guarantor information Guarantor data 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: PERSON Dest Table: Guarantor Migration Action(s) PERSON.TITLE Guarantor.Prefix Data copied from source User selects data to save PERSON.FIRSTNAME Guarantor.First Data copied from source User selects data to save PERSON.MIDDLENAME Guarantor.Middle Data copied from source User selects data to save PERSON.LASTNAME Guarantor.Last Data copied from source User selects data to save PERSON.LASTNAME PERSON.ENTITLEMENTS Guarantor.Suffix Data copied from source User selects data to save PERSON.ADDRESS1 Guarantor.Address1 Data copied from source User selects data to save PERSON.ADDRESS2 Guarantor.Address2 Data copied from source User selects data to save PERSON.CITY Guarantor.City Data copied from source User selects data to save PERSON.STATE Guarantor.State Data copied from source User selects data to save PERSON.ZIP Guarantor.Zip Data copied from source User selects data to save PERSON.COUNTRY Guarantor.Country Data copied from source User selects data to save PERSON.PRIMPHONE Guarantor.Phone1 Data copied from source removing non-numeric characters User selects data to save PERSON.ALTPHONE Guarantor.Phone2 Data copied from source removing non-numeric characters User selects data to save PERSON.FAXPHONE Guarantor.Phone3 Data copied from source removing non-numeric characters User selects data to save PERSON.EMAIL Guarantor.EmailAddress Data copied from source User selects data to save 2032026-001 Rev B 2006 General Electric Company 55

Migrating Data to Centricity Practice Solution Source Table: PERSON Dest Table: Guarantor Migration Action(s) RELBUSS.BUSID Guarantor.EmployerID Remapped to EmployerId using BUSIDMapping table and populated User selects data to save PERSON.EMPLSTATUS Guarantor.EmpStatudMId User-explicit mapping to (Code) MedlistsId; Use MedlistsMapping table AND tablename = EmploymentStatus User selects data to save PERSON.SOCSECNO Guarantor.SSN Data copied from source removing non-numeric characters User selects data to save PERSON.DATEOFBIRTH Guarantor.Birthday Data copied from source User selects data to save PERSON.SEX Guarantor.Sex Data copied from source User selects data to save Patient information Patient demographics data The following sections describe how information about patients is migrated, including patient demographics, insurance, personal contacts, and information about various patient relationships. All persons that are patients are moved from the source tables PERSON, PERSONPICT, RELPERS, and RELBUS to the destination database table PatientProfile table. When there is no data match in the destination database (EMR-only migration), the record is inserted. Relevant SQL A trigger fires when inserting into the PatientProfile table that fills the SearchName column. select distinct PERSON.*, RELBUSS.BUSID, RELPERS.RID from PERSON left outer join PERSON_PICT on PERSON.PID = PERSON_PICT.PID left outer join RELBUSS on PERSON.PID = RELBUSS.PID left outer join RELPERS on (PERSON.PID = RELPERS.PID and RELPERS.RELATIONSHIP = 'GR') where PERSON.ISPATIENT = 'Y' 56 2006 General Electric Company March 2007

Patient information SQL matching rules The Data Migration Wizard searches first for matches on these items: PERSON.DateOfBirth = PatientProfile.Birthdate and PERSON.LastName like PatientProfile.Last and PERSON.FirstName like PatientProfile.First And then attempts to secure a match with one of these items: PERSON.SocSecNo = PatientProfile.SSN or PERSON.Sex = PatientProfile.Sex or PERSON.Primphone = PatientProfile.Phone1 or PERSON.Zip = PatientProfile.Zip Simple Patient Demographics table mappings EMR only: Simple mappings when migrating EMR data to an empty destination database. Source Table: PERSON Dest Table: PatientProfile Migration Action(s) PERSON.PATIENTID PatientProfile.PatientId Data copied from source PERSON.PID PatientProfile.Pid Data copied from source PERSON.TITLE PatientProfile.Prefix Data copied from source PERSON.FIRSTNAME PatientProfile.First Data copied from source PERSON.MIDDLENAME PatientProfile.Middle Data copied from source PERSON.LASTNAME PatientProfile.Last Data copied from source PERSON.ENTITLEMENTS PatientProfile.Suffix Data copied from source PERSON.ADDRESS1 PatientProfile.Address1 Data copied from source PERSON.ADDRESS2 PatientProfile.Address2 Data copied from source PERSON.CITY PatientProfile.City Data copied from source PERSON.STATE PatientProfile.State Data copied from source PERSON.ZIP PatientProfile.Zip Data copied from source PERSON.COUNTRY PatientProfile.Country Data copied from source PERSON.EMAIL PatientProfile.EmailAddress Data copied from source PERSON.SOCSECNO PatientProfile.SSN Data copied from source PERSON.DATEOFBIRTH PatientProfile.Birthdate Data copied from source PERSON.DATEOFDEATH PatientProfile.Deathdate Data copied from source PERSON.SEX PatientProfile.Sex Data copied from source PERSON.RESPDEPTID PatientProfile.FacilityId Data copied from source PERSON.MEDRECNO PatientProfile.MedicalRecordNumber Data copied from source 2032026-001 Rev B 2006 General Electric Company 57

Migrating Data to Centricity Practice Solution Source Table: PERSON Dest Table: PatientProfile Migration Action(s) PERSON.EXTERNALID PatientProfile.ExternalId Data copied from source PERSON.SENSITIVECHART PatientProfile.SensitiveChart Data copied from source PERSON.HOMELOCATION PatientProfile.LocationId Data copied from source PERSON_PICT.PICT PatientProfile.Picture Data copied from source PERSON.LUPD PatientProfile.lupd Data copied from source PERSON.MASTERLOCK PatientProfile.masterlock Data copied from source PERSON.SEARCHNAME PatientProfile.searchname Populated by trigger PERSON.VISDOCNUM PatientProfile.visdocnum Data copied from source PERSON.SSDID PatientProfile.SSDID Data copied from source PERSON.PSTATUS PatientProfile.pstatus Data copied from source PERSON.ISPATIENT PatientProfile.ispatient Data copied from source PERSON.REGNOTE PatientProfile.regnote Data copied from source PERSON.DB_CREATE_DATE PatientProfile.Created Data copied from source PERSON.DB_UPDATED_DATE PatientProfile.LastModified Data copied from source Joint EMR/PM: Simple mappings when migrating EMR data to a Centricity Practice Solution database containing upgraded PM data. Source Table: PERSON Dest Table: PatientProfile Migration Action(s) PERSON.PID PatientProfile.Pid Data copied from source PERSON.EXTERNALID PatientProfile.ExternalId Data copied from source PERSON.SENSITIVECHART PatientProfile.SensitiveChart Data copied from source PERSON.HOMELOCATION PatientProfile.LocationId Data copied from source PERSON_PICT.PICT PatientProfile.Picture Data copied from source PERSON.LUPD PatientProfile.lupd Data copied from source PERSON.MASTERLOCK PatientProfile.masterlock Data copied from source PERSON.VISDOCNUM PatientProfile.visdocnum Data copied from source PERSON.SSDID PatientProfile.SSDID Data copied from source PERSON.PSTATUS PatientProfile.pstatus Data copied from source PERSON.ISPATIENT PatientProfile.ispatient Data copied from source PERSON.REGNOTE PatientProfile.regnote Data copied from source 58 2006 General Electric Company March 2007

Patient information Complex Patient Demographics table mappings EMR only: Complex mappings when migrating EMR data to an empty destination database. Source Table: PERSON, RELPERS, RELBUSS Dest Table: PatientProfile Migration Action(s) PERSON.PSTATUS PatientProfile.PatientStatusMId Explicit mapping to (Code) MedlistsId or NULL; Use MedlistsMapping table AND tablename = PatientStatus PERSON.EMPSTATUS PatientProfile.EmpStatusMId User-explicit mapping to (Code) MedlistsId; Use MedlistsMapping table AND tablename = EmploymentStatus PERSON.RACE PatientProfile.RaceMId User-explicit mapping to (Code) MedlistsId; Use MedlistsMapping table AND tablename = Race PERSON.MARITALSTATUS PatientProfile.MaritalStatusMId User-explicit mapping to (Code) MedlistsId; Use MedlistsMapping table and tablename = MaritalStatus PERSON.RESPPROVID PatientProfile.DoctorId Re-map source to DoctorFacilityId; Use PVIDMapping table PERSON.REFMDID PatientProfile.RefDoctorId Re-map source to DoctorFacilityId; Use PIDMapping table PERSON.PREFLANG PatientProfile.PrefLanguageMId User-explicit mapping to (Code) MedlistsId; Use MedlistsMapping table AND tablename = PreferredLanguage PERSON.CONTACTBY PatientProfile.ContactByMId User-explicit mapping to (Code) MedlistsId; Use MedlistsMapping table AND tablename = ContactMethod PERSON.WORKPHONE PatientProfile.Phone1 Copy column data from source removing non-numeric characters PERSON.ALTPHONE PatientProfile.Phone2 Copy column data from source removing non-numeric characters 2032026-001 Rev B 2006 General Electric Company 59

Migrating Data to Centricity Practice Solution Source Table: PERSON, RELPERS, RELBUSS Dest Table: PatientProfile Migration Action(s) PERSON.FAXPHONE PatientProfile.Phone3 Copy column data from source removing non-numeric characters RELPERS.RID PatientProfile.PatientSameAsGuarantor If RELPERS.PERID is NULL then Y else N RELPERS.RID PatientProfile.GuarantorId 1 If RELPERS.RID is NULL, populate with new PatientProfile.PatientProfileId 2 If RELPERS.RID not NULL, re-map RELPERS.PERID to GuarantorId; use RIDMapping table RELBUSS.BUSID PatientProfile.EmployerId 1. If RELBUSS.BUSID not NULL; Re-map RELBUSS.BUSID to EmployerId; use BUSIDMapping table - PatientProfile.Phone3Type Populate with Fax if PERSON.FAXPHONE!= NULL - PatientProfile.CreatedBy Populate with MigrationUsr - PatientProfile.LastModified Populate with CurrentDate - PatientProfile.LastModifiedBy Populate with MigrationUsr Joint EMR/PM: Complex mappings when migrating EMR data to a Centricity Practice Solution database containing upgraded PM data. See also next section, Patient demographic information requiring user input (joint EMR/PM) on page 61. Source Table: PERSON, RELPERS, RELBUSS Dest Table: PatientProfile Migration Action(s) PERSON.RACE PatientProfile.RaceMId 1 Explicit mapping to (Code) MedlistsId; Use MedlistsMapping table AND tablename = Race 2 Insert to destination database PERSON.MARITALSTATUS PatientProfile.MaritalStatusMId 1 User-explicit mapping to (Code) MedlistsId; Use MedlistsMapping table and tablename = MaritalStatus 2 Insert to destination database PERSON.DB_CREATE_DATE PatientProfile.Created Replace if PERSON.DB_CREATE_DATE older than PatientProfile.Created PERSON.DB_UPDATED_DATE PatientProfile.LastModified Populate with current date - PatientProfile.NewPatient Populate with value N - PatientProfile.LastModifiedBy Populate with MigrationUsr 60 2006 General Electric Company March 2007

Patient information Patient demographic information 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: PERSON, RELPERS, RELBUSS Dest Table: PatientProfile Migration Action(s) PERSON.PSTATUS PatientProfile.PatientStatusMId Explicit mapping to (Code) MedlistsId or NULL; Use MedlistsMapping table AND tablename = PatientStatus PERSON.EMPSTATUS PatientProfile.EmpStatusMId User-explicit mapping to (Code) MedlistsId; Use MedlistsMapping table AND tablename = EmploymentStatus PERSON.TITLE PatientProfile.Prefix Data copied from source PERSON.FIRSTNAME PatientProfile.First Data copied from source PERSON.MIDDLENAME PatientProfile.Middle Data copied from source PERSON.LASTNAME PatientProfile.Last Data copied from source PERSON.ENTITLEMENTS PatientProfile.Suffix Data copied from source PERSON.ADDRESS1 PatientProfile.Address1 Data copied from source PERSON.ADDRESS2 PatientProfile.Address2 Data copied from source PERSON.CITY PatientProfile.City Data copied from source PERSON.STATE PatientProfile.State Data copied from source PERSON.ZIP PatientProfile.Zip Data copied from source PERSON.WORKPHONE PatientProfile.Phone1 Data copied from source removing non-numeric characters PERSON.ALTPHONE PatientProfile.Phone2 Data copied from source removing non-numeric characters 2032026-001 Rev B 2006 General Electric Company 61

Migrating Data to Centricity Practice Solution Source Table: PERSON, RELPERS, RELBUSS Dest Table: PatientProfile Migration Action(s) PERSON.FAXPHONE PatientProfile.Phone3 Data copied from source removing non-numeric characters PERSON.COUNTRY PatientProfile.Country Data copied from source PERSON.EMAIL PatientProfile.EmailAddress Data copied from source PERSON.SOCSECNO PatientProfile.SSN Data copied from source PERSON.DATEOFBIRTH PatientProfile.Birthdate Data copied from source PERSON.DATEOFDEATH PatientProfile.Deathdate Data copied from source PERSON.SEX PatientProfile.Sex Data copied from source RELPERS.RID PatientProfile.PatientSameAs Guarantor If RELPERS.PERID is NULL, then source data value Y otherwise, N Data copied from source PERSON.RESPPROVID PatientProfile.DoctorId Data copied from source Re-map source to DoctorFacilityId; Use PIDMapping table PERSON.REFMDID PatientProfile.RefDoctorId Data copied from source Re-map source to DoctorFacilityId; Use PIDMapping table PERSON.MEDRECNO PatientProfile.MedicalRecordNumber Data copied from source PERSON.PREFLANG PatientProfile.PrefLanguageMId User-explicit mapping to (Code) MedlistsId; Use MedlistsMapping table AND tablename = PreferredLanguage Data copied from source PERSON.CONTACTBY PatientProfile.ContactByMId User-explicit mapping to (Code) MedlistsId; Use MedlistsMapping table AND tablename = ContactMethod Data copied from source RELPERS.PERID PatientProfile.GuarantorId 1 If RELPERS.RID is NULL, populate with the new PatientProfile.PatientProfileId 2 If RELPERS.RID not NULL, re-map RELPERS.PERID to GuarantorId; use RIDMapping table Data copied from source RELBUSS.BUSID PatientProfile.EmployerId If RELBUSS.BUSID not NULL, re-map RELBUSS.BUSID to EmployerId; use BUSIDMapping table Data copied from source 62 2006 General Electric Company March 2007

Patient information Patient Insurance data All records related to a patient are moved from the source tables PERSON, INSURANC, and RELPERS to the destination table PatientInsurance. When there is no data match in the destination database (EMR-only migration), the record is inserted. Relevant SQL EMR - only: select distinct RELBUSS.BUSID,RELPERS.PERID,INSURECO.BUSID,INSURANC.* from [INSURANC] inner join [INSURECO] on INSURANC.INSPLANID = INSURECO.INSPLANID inner join [PERSON] on INSURANC.PID = PERSON.PID left outer join [RELBUSS] on (PERSON.PID = RELBUSS.PID and RELBUSS.Relationship = 'BE') left outer join [RELPERS] on (PERSON.PID = RELPERS.PID and RELPERS.RELATIONSHIP = 'GR') where PERSON.ISPATIENT = 'Y' Joint EMR/PM migration: select distinct INSURANC.*, PERSON.*, RELBUSS.BUSID, RELPERS.PEID from INSURANC inner join PERSON on PERSON.PID = INSURANC.PID left outer join RELBUSS on PERSON.PID = RELBUSS.PID left outer join RELPERS on (PERSON.PID = RELPERS.PID and RELPERS.RELATIONSHIP = 'GR') SQL matching rules PERSON.PID = PatientInsurance.PatientProfileId INSURANC.IDNO = PatientInsurance. InsuredId INSURANC.GROUPNO = PatientInsurance.GroupId 2032026-001 Rev B 2006 General Electric Company 63

Migrating Data to Centricity Practice Solution Simple Patient Insurance data table mappings EMR only: Simple mappings when migrating EMR data to an empty destination database. Source Table: INSURANC, PERSON, Dest Table: PatientInsurance Migration Action(s) INSURANC.GRPNO PatientInsurance.GroupId Data copied from source INSURANC.IDNO PatientInsurance.InsuredId Data copied from source INSURANC.EFFECTIVEDATE PatientInsurance.InsCardEffeectiveDate Data copied from source INSURANC.EXPIREDDATE PatientInsurance.InsCareTerminationDate Data copied from source PERSON.TITLE PatientInsurance.Prefix Data copied from source PERSON.FIRSTNAME PatientInsurance.First Data copied from source PERSON.MIDDLENAME PatientInsurance.Middle Data copied from source PERSON.LASTNAME PatientInsurance.Last Data copied from source PERSON.ENTITLEMENTS PatientInsurance.Suffix Data copied from source PERSON.ADDRESS1 PatientInsurance.Address1 Data copied from source PERSON.ADDRESS2 PatientInsurance.Address2 Data copied from source PERSON.CITY PatientInsurance.City Data copied from source PERSON.STATE PatietInsurance.State Data copied from source PERSON.ZIP PatientInsurance.Zip Data copied from source PERSON.COUNTRY PatientInsurance.Country Data copied from source PERSON.SEX PatientInsurance.Sex Data copied from source PERSON.DATEOFBIRTH PatientInsurance.Birthdate Data copied from source INSURANC.DB_CREATE_DATE PatientInsurance.Created Data copied from source INSURANC.DB_UPDATED_DATE PatientInsurance.LastModified Data copied from source 64 2006 General Electric Company March 2007

Patient information Complex Patient Insurance data table mappings EMR only: Complex mappings when migrating EMR data to an empty destination database. Source Table: INSURANC, PERSON, Dest Table: PatientInsurance Migration Action(s) INSURANC.PID PatientInsurance.PatientProfileId Re-map source to PatientProfileId; use PIDMapping table INSURANC.PSISTATE PatientInsurance.OrderForClaims Convert to numeric values: I - 0 P - 1 S - 2 O - 4 User selects data to save INSURANC.INSID PatientInsurance.InsuranceCarriersId Re-map source to InsuranceCarriersId; use BUSIDMapping table INSURANC.INSPARTYID INSURANC.PID PatientInsurance.InsuredSameAsPatient If INSURANC.INSPARTYID = INSURANC.PID then 1 else NULL RELPERS.PERID INSURANC.PID PatientInsurance.InsuredSameAs Guarantor If RELPERS.PERID is NULL, then 1 else if RELPERS.PERID = INSURANC.PID then 1, else NULL RELBUSS.BUSID PatientInsurance.EmployerId If RELBUSS.BUSID not NULL, re-map RELBUSS.BUSID to EmployerId; use BUSIDMapping table PERSON.EMPLSTATUS PatientInsurance.EmpStatusMId User-explicit mapping to (Code) MedlistsId; Use MedlistsMapping table AND tablename = EmploymentStatus PERSON.WORKPHONE PatientInsurance.Phone1 Data copied from source removing non-numeric characters PERSON.ALTPHONE PatientInsurance.Phone2 Data copied from source removing non-numeric characters PERSON.SOCSECNO PatientInsurance.SSN Data copied from source removing non-numeric characters - PatientInsurance.CreatedBy Populate with MigrationUsr - PatientInsurance.LastModifiedBy Populate with MigrationUsr - PatientInsurance.PatientInsuranceId Auto-generated new id 2032026-001 Rev B 2006 General Electric Company 65

Migrating Data to Centricity Practice Solution Joint EMR/PM: Complex mappings when migrating EMR data to a Centricity Practice Solution database containing upgraded PM data. See also next section, Patient insurance information requiring user input (joint EMR/PM) on page 66. Source Table: INSURANC Dest Table: PatientInsurance Migration Action(s) INSURANC.DB_UPDATED_DATE PatientInsurance.LastModified Replace if INSURANC.DB_CREATE_DATE older than PatientInsurance.Created - PatientInsurance.LastModifiedBy Populate with MigrationUsr Patient insurance information 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: INSURANC, PERSON, Dest Table: PatientInsurance Migration Action(s) INSURANC.PSISTATE PatientInsurance.OrderForClaims Convert to numeric values: I - 0 P - 1 S - 2 O - 4 User selects data to save INSURANC.INSID PatientInsurance.Insurance CarriersId Re-map source to InsuranceCarriersId; Use BUSIDMapping table User selects data to save INSURANC.GROUPNO PatientInsurance.GroupId No information moved if matched to data in destination database. INSURANC.IDNO PatientInsurance.InsuredId No information moved if matched to data in destination database. INSURANC.EFFECTIVEDATE INSURANC.EXPIREDATE PatientInsurance.InsCardEffective Date PatientInsurance.InsCare TerminationDate No information moved if matched to data in destination database. No information moved if matched to data in destination database. PERSON.TITLE PatientInsurance.Prefix No information moved if matched to data in destination database. PERSON.FIRSTNAME PatientInsurance.First No information moved if matched to data in destination database. PERSON.MIDDLENAME PatientInsurance.Middle No information moved if matched to data in destination database. PERSON.LASTNAME PatientInsurance.Last No information moved if matched to data in destination database. 66 2006 General Electric Company March 2007

Patient information Source Table: INSURANC, PERSON, Dest Table: PatientInsurance Migration Action(s) PERSON.LASTNAME/ PERSON.ENTITLEMENTS PatientInsurance.Suffix No information moved if matched to data in destination database. PERSON.ADDRESS1 PatientInsurance.Address1 No information moved if matched to data in destination database. PERSON.ADDRESS2 PatientInsurance.Address2 No information moved if matched to data in destination database. PERSON.CITY PatientInsurance.City No information moved if matched to data in destination database. PERSON.ADDRESS2 PatientInsurance.Address2 No information moved if matched to data in destination database. PERSON.CITY PatientInsurance.City No information moved if matched to data in destination database. PERSON.STATE PatientInsurance.State No information moved if matched to data in destination database. PERSON.ZIP PatientInsurance.Zip No information moved if matched to data in destination database. PERSON.COUNTRY PatientInsurance.Country No information moved if matched to data in destination database. PERSON.WORKPHONE PatientInsurance.Phone1 No information moved if matched to data in destination database. Non-numeric characters removed. PERSON.ALTPHONE PatientInsurance.Phone2 No information moved if matched to data in destination database. PERSON.FAXPHONE PatientInsurance.Phone3 User selects data to save Data copied removing non-numeric characters. If EMR source selected then set PhoneType3 to Fax PERSON.SEX PatientInsurance.Sex User selects data to save Data copied removing non-numeric characters. PERSON.DATEOFBIRTH PatientInsurance.Birthdate User selects data to save Data copied removing non-numeric characters. PERSON.SOCSECNO PatientInsurance.SSN User selects data to save Data copied removing non-numeric characters. PERSON.EMPLSTATUS PatientInsurance.EmpStatusMId User-explicit mapping to (Code) MedlistsId; Use MedlistsMapping table AND tablename = EmploymentStatus User selects data to save RELBUSS.BUSID PatientInsurance.EmployerId Re-map RELBUSS.BUSID to EmployerId; Use BUSIDMapping table User selects data to save 2032026-001 Rev B 2006 General Electric Company 67

Migrating Data to Centricity Practice Solution Source Table: INSURANC, PERSON, Dest Table: PatientInsurance Migration Action(s) INSURANC.INSPARTYID INSURANC.PID RELPERS.PERID INSURANC.PID PatientInsurance.InsuredSameAs Patient PatientInsurance.InsuredSameAs Guarantor If INSURANC.INSPARTYID = INSURANC.PID then Y else N User selects data to save If RELPERS.PERID is NULL then N else if RELPERS.PERID = INSURANC.PID then Y User selects data to save INSURANC.DB_UPDATED_DATE PatientInsurance.LastModified If INSURANC.DB_CREATE_DATE older than PatientInsurance.Created replace it - PatientInsurance.LastModifiedBy Populate with MigrationUsr Patient Personal Contacts data All persons related to a patient and not a guarantor, primary physician, or responsibly physician, are moved from the PERSON, PERSON_PICT, and RELPERS tables n the source database to the PatientContacts table in the destination database. Relevant SQL select distinct PERSON.* from PERSON inner join RELPERS on RELPERS.PERID = PERSON.PID where RELPERS.RELATIONSHIP not in ('GR', 'RP', 'PP') SQL matching rules PERSON.LastName = PatientContacts.Last PERSON.FirstName = PatientContacts.First PERSON.Phone1 68 2006 General Electric Company March 2007

Patient information Simple Personal Contacts table mappings EMR only: Simple mappings when migrating EMR data to an empty destination database. Source Table: PERSON, PERSON_PICT, RELPERS Dest Table: PatientContacts Migration Action(s) PERSON.PID PatientContacts.PId Data copied from source PERSON.TITLE PatientContacts.Prefix Data copied from source PERSON.FIRSTNAME PatientContacts.First Data copied from source PERSON.MIDDLENAME PatientContacts.Middle Data copied from source PERSON.LASTNAME PatientContacts.Last Data copied from source PERSON.ENTITLEMENTS PatientContacts.Suffix Data copied from source PERSON.ADDRESS1 PatientContacts.Address1 Data copied from source PERSON.ADDRESS2 PatientContacts.Address2 Data copied from source PERSON.CITY PatientContacts.City Data copied from source PERSON.STATE PatientContacts.State Data copied from source PERSON.ZIP PatientContacts.Zip Data copied from source PERSON.COUNTRY PatientContacts.Country Data copied from source PERSON.DB_CREATE_DATE PatientContacts.Created Data copied from source PERSON.DB_UPDATED_DATE PatientContacts.LastModified Data copied from source Joint EMR/PM: Simple mappings when migrating EMR data to a Centricity Practice Solution database containing upgraded PM data. Source Table: PERSON, PERSON_PICT, RELPERS Dest Table: PatientContacts Migration Action(s) PERSON.PID PatientContacts.PId Data copied from source 2032026-001 Rev B 2006 General Electric Company 69

Migrating Data to Centricity Practice Solution Complex Personal Contacts table mappings EMR only: Complex mappings when migrating EMR data to an empty destination database. Source Table: PERSON, Dest Table: PatientContacts Migration Action(s) PERSON.PRIMPHONE PatientContacts.Phone1 Data copied removing non-numeric characters. PERSON.ALTPHONE PatientContacts.Phone2 Data copied removing non-numeric characters. PERSON.FAXPHONE PatientContacts.Phone3 Data copied removing non-numeric characters. - PatientContacts.Phone3Type Populate with value of Fax if PERSON.FAXPHONE!= NULL - PatientContacts.LastModifiedBy Populate with MigrationUsr - PatientContacts.PatientContactsId Auto-generated new id Joint EMR/PM: Complex mappings when migrating EMR data to a Centricity Practice Solution database containing upgraded PM data. Source Table: PERSON Dest Table: PatientContacts Migration Action(s) PERSON.TITLE PatientContacts.Prefix User selects data to save PERSON.FIRSTNAME PatientContacts.First User selects data to save PERSON.MIDDLENAME PatientContacts.Middle User selects data to save PERSON.LASTNAME PatientContacts.Last User selects data to save PERSON.LASTNAME/ PERSON.ENTITLEMENTS PatientContacts.Suffix User selects data to save PERSON.ADDRESS1 PatientContacts.Address1 User selects data to save PERSON.ADDRESS2 PatientContacts.Address2 User selects data to save PERSON.CITY PatientContacts.City User selects data to save PERSON.STATE PatientContacts.State User selects data to save PERSON.ZIP PatientContacts.Zip User selects data to save PERSON.COUNTRY PatientContacts.Country User selects data to save PERSON.PRIMPHONE PatientContacts.Phone1 User selects data to save PERSON.ALTPHONE PatientContacts.Phone2 User selects data to save PERSON.FAXPHONE PatientContacts.Phone3 User selects data to save If EMR source selected populate Phone3Type with value Fax PERSON.DB_CREATE_DATE PatientContacts.Created If PERSON.DB_CREATE_DATE older than PatientContacts.Created replace it PERSON.DB_UPDATED_DATE PatientContacts.LastModified Populate with current date - PatientContacts.LastModifiedBy Populate with MigrationUsr 70 2006 General Electric Company March 2007

Patient information Patient Pharmacy Relationship Data All pharmacies related to a patient are moved from PERSON and RELBUSS tables in the source database to the PatientRelationship table in the destination database. If there is no data match in the destination database (EMR-only migration), the record is inserted. Relevant SQL select distinct RELBUSS.* from RELBUSS inner join PERSON on PERSON.PID = RELBUSS.PID where RELATIONSHIP = 'BP' SQL matching rules PatientRelationship.Type = 1 RELBUSS.PID (re-mapped using PIDMapping) = PatientRelationship.PatientProfileId RELBUSS.BUSID = PatientRelationship.RelatedPartyId Simple Pharmacy Relationship table mappings EMR only: Simple mappings when migrating EMR data to an empty destination database. Source Table: RELBUSS Dest Table: PatientRelationship Migration Action(s) RELBUSS.PID PatientRelationship.PId Copy column data from source RELBUSS.COMMENTS PatientRelationship.Notes Copy column data from source 2032026-001 Rev B 2006 General Electric Company 71

Migrating Data to Centricity Practice Solution Complex Pharmacy Relationship table mappings EMR only: Complex mappings when migrating EMR data to an empty destination database. Source Table: RELBUSS Dest Table: PatientRelationship Migration Action(s) RELBUSS.PID PatientRelationship.PatientProfileId Re-map source to PatientProfileId; Use PIDMapping table RELBUSS.RELATIONSHIP PatientRelationship.RelationshipTypeMId Explicit mapping to (Code) MedlistsId; Use MedlistsMapping table AND tablename = ContactRelation RELBUSS.BUSID PatientRelationship.RelatedPartyId Re-map to PharmacyId; Use BUSIDMapping table - PatientRelationship.Type Populate with value 1 0 = None 1 = Pharmacy 2 = Doctor 3 = Referring Doctor 4 = Primary Care Physician 5 = Personal Contact - PatientRelationship.Created Populate with CurrentTime - PatientRelationship.CreatedBy Populate with MigrationUsr - PatientRelationship.LastModified Populate with CurrentTime - PatientRelationship.LastModifiedBy Populate with MigrationUsr - PatientRelationship.PatientRelationshipId Auto-generated new id Patient Referring Provider Relationship Data All referring providers related to a patient are candidates to be moved from the source tables PERSON, and RELPERS to the destination table PatientRelationship. When there is no data match in the destination database (EMR-only migration), the record is inserted. 72 2006 General Electric Company March 2007

Patient information Relevant SQL EMR only: select distinct RELPERS.* from RELPERS inner join PERSON on PERSON.PID = RELPERS.PID where RELATIONSHIP in ('PP', 'RP') Joint EMR/PM migration: -- Get referring physicians select distinct RELPERS.* from RELPERS inner join PERSON on PERSON.PID = RELPERS.PID where RELATIONSHIP = 'RP' -- Get primary care physicians select distinct RELPERS.* from RELPERS inner join PERSON on PERSON.PID = RELPERS.PID where RELATIONSHIP = 'PP' SQL matching rules PatientRelationship.Type = 3 (referring physicians) RELPERS.PID (re-mapped using PIDMapping) = PatientRelationship.PatientProfileId RELPERS.PERID = PatientRelationship.RelatedPartyId PatientRelationship.Type = 4 (primary care physicians) RELPERS.PID (re-mapped using PIDMapping) = PatientRelationship.PatientProfileId RELPERS.PERID = PatientRelationship.RelatedPartyId Simple Referring Provider Relationship table mappings EMR only: Simple mappings when migrating EMR data to an empty destination database. Source Table: RELBUSS Dest Table: PatientRelationship Migration Action(s) RELBUSS.PID PatientRelationship.PId Copy column data from source RELBUSS.COMMENTS PatientRelationship.Notes Copy column data from source 2032026-001 Rev B 2006 General Electric Company 73

Migrating Data to Centricity Practice Solution Complex Referring Provider Relationship table mappings EMR only: Complex mappings when migrating EMR data to an empty destination database. Source Table: RELPERS Dest Table: PatientRelationship Migration Action(s) RELPERS.PID PatientRelationship.PatientProfileId Re-map source to PatientProfileId; Use PIDMapping table RELPERS.RELATIONSHIP PatientRelationship.RelationshipTypeMId Explicit mapping to (Code) MedlistsId; Use MedlistsMapping table; Use MedlistsMapping table AND tablename = ContactRelation RELPERS.PERID PatientRelationship.RelatedPartyId Re-map to PatientProfileId; Use PIDMapping table - PatientRelationship.Type Populate with value 3 or 4 0 = None 1 = Pharmacy 2 = Doctor 3 = RP Referring Doctor 4 = PP Primary Care Physician 5 = Personal Contact - PatientRelationship.Created Populate with CurrentTime - PatientRelationship.CreatedBy Populate with MigrationUsr - PatientRelationship.LastModified Populate with CurrentTime - PatientRelationship.LastModifiedBy Populate with MigrationUsr - PatientRelationship.PatientRelationshipId Auto-generated new id Patient Responsible Provider Relationship Data All responsible providers related to a patient are moved from the source tables PERSON and RELPROV to the destination table PatientRelationship. When there is no data match in the destination database (EMR-only migration), the record is inserted. Relevant SQL select distinct RELPROV.* from RELPROV inner join PERSON on PERSON.PID = RELPROV.PID 74 2006 General Electric Company March 2007

Patient information SQL matching rules PatientRelationship.Type = 4 RELPERS.PID (re-mapped using PIDMapping) = PatientRelationship.PatientProfileId Simple Responsible Provider Relationship table mappings EMR only: Simple mappings when migrating EMR data to an empty destination database. Source Table: RELBUSS Dest Table: PatientRelationship Migration Action(s) RELPROV.PID PatientRelationship.PId Copy column data from source Complex Responsible Provider Relationship table mappings EMR only: Complex mappings when migrating EMR data to an empty destination database. Source Table: RELPROV Dest Table: PatientRelationship Migration Action(s) RELPROV.PID PatientRelationship.PatientProfileId Re-map source to PatientProfileId; Use PIDMapping table RELPROV.PVID PatientRelationship.RelatedPartyId Re-map to DoctorFacilityId; Use PVIDMapping table - PatientRelationship.Type Populate with value: 4 0 = None 1 = Pharmacy 2 = Doctor 3 = Referring Doctor 4 = Primary Care Physician 5 = Personal Contact - PatientRelationship.Created Populate with CurrentTime - PatientRelationship.CreatedBy Populate with MigrationUsr - PatientRelationship.LastModified Populate with CurrentTime - PatientRelationship.LastModifiedBy Populate with MigrationUsr - PatientRelationship.RelationshipTypeMId Query Medlists for MedlistsId where Description = PrimaryCarePhysician and TableName = ContactRelationFixed - PatientRelationship.PatientRelationshipId Auto-generated new id 2032026-001 Rev B 2006 General Electric Company 75

Migrating Data to Centricity Practice Solution Patient Personal Relationship Data All persons related to a patient and not a guarantor, providing physician, or referring physician, are moved from the source tables PERSON and RELPERS to the destination table PatientRelationship. When there is no data match in the destination database (EMR-only migration), the record is inserted. Relevant SQL select distinct RELPERS.* from RELPERS inner join PERSON on PERSON.PID = RELPERS.PID where RELATIONSHIP not in ('RP','PP','GR') SQL matching rules PatientRelationship.Type = 5 RELPERS.PID (re-mapped using PIDMapping) = PatientRelationship.PatientProfileId RELPERS.PERID = PatientRelationship.RelatedPartyId Simple Personal Relationship table mappings EMR only: Simple mappings when migrating EMR data to an empty destination database. Source Table: RELBUSS Dest Table: PatientRelationship Migration Action(s) RELPERS.COMMENTS PatientRelationship.Notes Copy column data from source RELPERS.PID PatientRelationship.PId Copy column data from source 76 2006 General Electric Company March 2007

Patient information Complex Personal Relationship table mappings EMR only: Complex mappings when migrating EMR data to an empty destination database. Source Table: RELPERS Dest Table: PatientRelationship Source Table: RELBUSS RELPERS.PID PatientRelationship.PatientProfileId Re-map source to PatientProfileId; Use PIDMapping table RELPERS.RELATIONSHIP PatientRelationship.RelationshipTypeMId Explicit mapping to (Code) MedlistsId; Use MedlistsMapping table; Use MedlistsMapping table AND tablename = ContactRelation RELPERS.PERID PatientRelationship.RelatedPartyId Re-map to PatientProfileId; Use PIDMapping table - PatientRelationship.Type Populate with value of 5 0 =None 1 = Pharmacy 2 = Doctor 3 = Referring Doctor 4 = Primary Care Physician 5 = Personal Contact - PatientRelationship.Created Populate with CurrentTime - PatientRelationship.CreatedBy Populate with MigrationUsr - PatientRelationship.LastModified Populate with CurrentTime - PatientRelationship.LastModifiedBy Populate with MigrationUsr - PatientRelationship PatientRelationshipId Auto-generated new id 2032026-001 Rev B 2006 General Electric Company 77

Migrating Data to Centricity Practice Solution Appointments information Appointments Types The following sections include information about migrating EMR appointments to the Centricity Practice Solution Scheduling module. This is a complex migration involving many steps. All data related to appointment types are moved from the APPTDEF table in the source database to the the ApptType table in the destination database. Relevant SQL SELECT * from APPTDEF Simple Appointment Types table mappings EMR only: Simple mappings when migrating EMR data to an empty destination database. Source Table: APPTDEF Dest Table: ApptType Migration Action(s) APPTDEF.APPTTYPE ApptType.Name Copy column data from source APPTDEF.DURATION ApptType.Duration Copy column data from source APPTDEF.ETID ApptType.ETID Copy column data from source APPTDEF.DB_CREATE_DATE ApptType.Created Copy column data from source APPTDEF.DB_MODIFIED_DATE ApptType.LastModified Copy column data from source 78 2006 General Electric Company March 2007

Appointments information Complex Appointment Types table mappings EMR only: Complex mappings when migrating EMR data to an empty destination database. Source Table: APPTDEF Dest Table: ApptType Migration Action(s) - ApptType.CreatedBy Populate with MigrationUsr - ApptType.Category Populate with CurrentTime - ApptType.LastModifiedBy Populate with MigrationUsr - ApptType.ApptTypeId Auto-generated new id Resource/Provider Schedule Data All records in the BOOK table are candidates to be moved from the BOOK, TEMPLATE, TEMPLATEID, PERIOD, and APPTRULE tables in the source database to the Schedule, ScheduleTimes, ScheduleTimesAlloc, ApptTypeAssignments, and Medlists tables in the destination database. Recreating EMR schedules in the Centricity Practice Solution application is a complex process, with many steps: 1 Create entries in the Medlists table for each new schedule so they will appear in the lists in the Scheduling module and properly link them to DoctorFacilityIds. 2 Create new schedules for each book (for both resource and doctor books). 3 Associate the newly created schedule with its appointment type. 4 Create new schedule time slots for created books with time frames matching those in EMR. 5 Create new schedule time slots allocations for specific events associated with a book that were allocated. 6 Create permissions for the Doctor or Resource for the appointment type. 7 Create the appointments and assign them to a slot, doctor, and resource. 8 Create new schedules: a b c Generate a new time slot for each division of the time span assuming a default start time of 8 AM and end time of 5 PM. In the default case there would be a total 32 time slots needing to be generated. Each new schedule created in Step 8 is assigned to the doctor or resource. Pre-booked time slots in a schedule are created in their designated time positions. 2032026-001 Rev B 2006 General Electric Company 79

Migrating Data to Centricity Practice Solution Relevant SQL select B1.[Name] as BookName,B1.USERID,B1.LOCID,B1.DB_CREATE_DATE as BookCreated,B1.DB_UPDATED_DATE as BookLastUpdated,T1.[Name] as TemplateName,P1.PERIODTYPE,P1.DateFrom,P1.DateThru,P1.Daylist,P1.Alternate,P1.Sequence,P1.SequenceList,P1.AltOrder,A1.ID as RuleId,A1.RULETYPE,A1.APPTTYPE,A1.TIMEFROM as RuleTimeFrom,A1.TIMETO as RuleTimeTo,A1.REASON as RuleReason from BOOK as B1 inner join TEMPLATE as T1 on T1.ID = B1.TEMPLATEID inner join PERIOD as P1 on P1.TEMPLATEID = B1.TEMPLATEID inner join APPTRULE as A1 on A1.PERIODID = P1.ID Order by B1.USERID, A1.RuleType Step 1 Simple table mappings for new schedules (MedLists) This creates entries in the Medlists table for each new schedule so they will appear in the lists in the Scheduling module and properly link them to DoctorFacilityIds. Source Table: BOOK, TEMPLATE, TEMPLATEID, PERIOD, APPTRULE Dest Table: Medlists Migration Action(s) - Medlists.TableName Populate with value NamedSchedule - Medlists.OtherLong Populate with value 0 - Medlists.Created Populate with currentdate - MedLists.CreatedBy Populate with migrationuser - MedLists.LastModified Populate with currentdate - MedLists.LastModifiedBy Populate with migrationuser 80 2006 General Electric Company March 2007

Appointments information Step 2 Complex table mappings for books (MedLists) This creates new schedules for each book (for both resource and doctor books). Source Table: BOOK, TEMPLATE, TEMPLATEID, PERIOD, APPTRULE BOOK.NAME TEMPLATEID.NAME PERIOD.PERIODTYPE Dest Table: Medlists Medlists.Description Migration Action(s) Create description string based on the book name, templateid name, and period type. - Medlists.MedlistsId Auto-generated new id - Medlists.Created Populate with currentdate - MedLists.CreatedBy Populate with migrationuser - MedLists.LastModified Populate with currentdate - MedLists.LastModifiedBy Populate with migrationuser Step 3 Simple table mappings to associate appointment types (MedLists) This associates the newly created schedule with its appointment type. Source Table: BOOK, TEMPLATE, TEMPLATEID, PERIOD, APPTRULE Dest Table: Medlists Migration Action(s) - Medlists.TableName Populate with value NamedScheduleResource - Medlists.ListOrder Populate with value 1 - Medlists.Created Populate with currentdate - MedLists.CreatedBy Populate with migrationuser - MedLists.LastModified Populate with currentdate - MedLists.LastModifiedBy Populate with migrationuser - MedLists.LastModified Populate with currentdate - MedLists.LastModifiedBy Populate with migrationuser 2032026-001 Rev B 2006 General Electric Company 81

Migrating Data to Centricity Practice Solution Step 4 Complex table mappings for time slots (MedLists) This creates new schedule time slots for created books with time frames matching those in EMR. Source Table: BOOK Dest Table: Medlists Migration Action(s) BOOK.USERID BOOK.ID MedLists.OtherLong Re-map source to a DoctorFacilityId. If the USERID > 0 then re-map the USERID using the PVIDMapping table, otherwise use ID and the BOOKIDMapping table. - MedLists.JoinId Populate with Step 2 s new Medlists.MedlistsId auto-generated value. (sql equivalent: @@identity ) - MedLists.MedlistsId Auto-generated new id Step 5 Simple table mappings for time slot allocations (MedLists) This creates new schedule time slots allocations for specific events associated with a book that were allocated. Source Table: APPT, APPTDEF Dest Table: Medlists Migration Action(s) - Medlists.TableName Populate with value NamedScheduleFacility - Medlists.ListOrder Populate with value 1 - Medlists.Created Populate with currentdate - MedLists.CreatedBy Populate with migrationuser - MedLists.LastModified Populate with currentdate - MedLists.LastModifiedBy Populate with migrationuser Step 6 Complex table mappings for permissions (MedLists) This creates permissions for the Doctor or Resource for the appointment type. Source Table: BOOK Dest Table: Medlists Migration Action(s) BOOK.LOCID MedLists.OtherLong Re-map source value to DoctorFacilityId using the LOCIDFacilityMapping table. - MedLists.JoinId Populate with Step 2 s new Medlists.MedlistsId auto-generated value. (sql equivalent: @@identity ) - MedLists.MedlistsId Auto-generated new id 82 2006 General Electric Company March 2007

Appointments information Step 7 Simple table mappings to create appointments (Schedule) This creates the appointments and assign them to a slot, doctor, and resource. Source Table: APPT, APPTDEF Dest Table: Schedule Migration Action(s) - Schedule.LongTickMark Populate with value 30 - Schedule.ShortTickMark Populate with value 15 - Schedule.Inactive Populate with value 0 - Schedule.Created Copy column data from source - Schedule.LastModified Copy column data from source Step 8 Complex table mappings (Schedule) This creates new schedules. Source Table: BOOK, TEMPLATEID, PERIOD Dest Table: Schedule Migration Action(s) BOOK.USERID BOOK.ID Schedule.DoctorResourceId Re-map to a DoctorFacilityId. If the USERID > 0 then re-map the USERID using the PVIDMapping table, otherwise use ID and the BOOKIDMapping table. BOOK.NAME TEMPLATEID.NAME PERIOD.PERIODTYPE Schedule.Description Create description string based on the book name, templateid name, and period type. - Schedule.ScheduleId Auto-generated new id 2032026-001 Rev B 2006 General Electric Company 83

Migrating Data to Centricity Practice Solution Step 8a Complex table mappings to create time slots (ScheduleTimes) Generate a new time slot for each division of the time span assuming a default start time of 8 AM and end time of 5 PM. In the default case there would be a total 32 time slots needing to be generated. Source Table: APPTRULE Dest Table: ScheduleTimes Migration Action(s) APPTRULE.TIMEFROM ScheduleTimes.TimeStart Calculate next time slot to insert APPTRULE.TIMETO ScheduleTimes.TimeStop Calculate next time slot to insert - ScheduleTimes.ScheduleId Populate with Step 8 s new Schedule.ScheduleId auto-generated value. (sql equivalent: @@identity ) - ScheduleTimes.ListOrder Calculate based on the number of records already existing for the current timestart, schedule, and facility. - ScheduleTimes.Created Populate with currentdate - ScheduleTimes.CreatedBy Populate with migrationuser - ScheduleTimes.LastModified Populate with currentdate - ScheduleTimes.LastModifiedBy Populate with migrationuser Step 8b Complex table mappings to assign doctor/resource (ApptTypeAssignments) Each new schedule created in Step 8 is assigned to the doctor or resource. Source Table: BOOK, APPTRULE Dest Table: AppttypeAssignments, ScheduleTimes Migration Action(s) BOOK.USERID BOOK.ID APPTRULE.REASON APPTRULE.DURATION APPTRULE.TIMEFROM APPTRULE.TIMETO ApptTypeAssignments.DoctorResourceI d ApptTypeAssignments.ApptTypeId Re-map to a DoctorFacilityId. If the USERID > 0 then re-map the USERID using the PVIDMapping table, otherwise use ID and the BOOKIDMapping table. Calculate the Duration using source TIMEFROM and TIMETO (@Duration). Then find the appointment type for the reason and duration: select ApptTypeId from ApptType where [Name] = APPTRULE.Reason and Duration = @Duration - ApptTypeAssignments.Created Populate with currentdate - ApptTypeAssignments.CreatedBy Populate with migrationuser - ApptTypeAssignments.LastModified Populate with currentdate - ApptTypeAssignments.LastModifiedBy Populate with migrationuser - ScheduleTimes.LastModified Populate with currentdate - ScheduleTimes.LastModifiedBy Populate with migrationuser 84 2006 General Electric Company March 2007

Appointments information Step 8c Complex table mappings to create pre-booked time slots Pre-booked time slots in a schedule are created in their designated time positions. Source Table: APPTRULE Dest Table: ApptTypeAssignments, ScheduleTimes Migration Action(s) BOOK.USERID BOOK.ID APPTRULE.REASON APPTRULE.DURATION APPTRULE.TIMEFROM APPTRULE.TIMETO ApptTypeAssignments.DoctorResourceId ApptTypeAssignments.ApptTypeId Re-map to a DoctorFacilityId. If the USERID > 0 then re-map the USERID using the PVIDMapping table, otherwise use ID and the BOOKIDMapping table. Calculate the Duration using source TIMEFROM and TIMETO (@Duration). Then find the appointment type for the reason and duration: select ApptTypeId from ApptType where [Name] = APPTRULE.Reason and Duration = @Duration - ApptTypeAssignments.Created Populate with currentdate - ApptTypeAssignments.CreatedBy Populate with migrationuser - ApptTypeAssignments.LastModified Populate with currentdate - ApptTypeAssignments.LastModifiedBy Populate with migrationuser - ScheduleTimes.LastModified Populate with currentdate - ScheduleTimes.LastModifiedBy Populate with migrationuser Appointments data All records in the APPT table in the source database are candidates to be moved to the Appointments, AppSlots, and ApptTypeAssignments tables in the destination database. Each record in the APPT table has a corresponding slot created in the ApptSlot table. If an appointment type has been assigned, permissions for that Doctor or Resource are given for that appointment type. Since appointments can be numerous, a date can be specified for the earliest appointments to be carried over. 2032026-001 Rev B 2006 General Electric Company 85

Migrating Data to Centricity Practice Solution Relevant SQL declare @StartTime datetime select APPTDEF.APPTTYPE, APPTDEF.LOCID, APPT.* from APPT inner join APPTDEF on APPT.APPTTYPE = APPTDEF.ID where APPTDATE >= @StartTime Step 1 Complex table mappings (ApptTypeAssignments) This assigns Appointment Types to a doctor. Source Table: APPT Dest Table: ApptTypeAssignments Migration Action(s) APPT.APPTDEFID ApptTypeAssignments.ApptTypeId Re-map to ApptTypeId using APPTDEFIDMapping table. APPT.BOOKLIST APPT.BOOKTYPE ApptTypeAssignments.DoctorResourceId Parse each book from the source string. Each ID is separated by colons (:) and should be re-mapped to a DoctorFacilityId. If the BOOKTYPE is P for the ID in the BOOK table, re-map using the PVIDMapping table. Otherwise re-map using the BOOKIDMapping table. - ApptTypeAssignments.Created Populate with currentdate - ApptTypeAssignments.CreatedBy Populate with migrationuser - ApptTypeAssignments.LastModified Populate with currentdate - ApptTypeAssignments.LastModifiedBy Populate with migrationuser Step 2a Simple table mappings (Appointments) This step creates patient appointments through simple and complex mappings. Source Table: APPT Dest Table: Appointments Migration Action(s) APPT.REASON Appointments.Notes Copy data from source APPT.VISITID Appointments.PatientVisitId Copy data from source APPT.ExtApptId Appointments.ExternalApptId Copy data from source APPT.DOCCREATE Appointments.DocCreate Copy data from source APPT.DURATION Appointments.Duration Copy data from source APPT.APPTDATE Appointments.EmrApptStart Copy data from source APPT.DB_CREATE_DATE Appointments.Created Copy data from source APPT.DB_UPDATED_DATE Appointments.LastModified Copy data from source APPT.DOCID Appointments.DocId Copy data from source 86 2006 General Electric Company March 2007

Appointments information Step 2b Complex table mappings (Appointments) Source Table: APPT, APPTDEF Dest Table: Appointments Migration Action(s) APPT.PID Appointments.OwnerId Re-map source to PatientProfileId. Use PIDMapping table APPTDEF.APPTSTATUS Appointments.ApptTypeId Re-map source to ApptTypeId where ApptDef.Description = ApptType.Description APPT.APPTDATE APPT.APPTTIME APPT.APPTDATE APPT.APPTTIME APPT.DURATION Appointments.ApptStart Appointments.ApptStop Calculate date value and populate Calculate date value and populate APPT.APPTSTATUS Appointments.Status Populate with value of Medlists.Description where Medlists.MedlistsId = Appointments.ApptStatusMId APPT.APPTSTATUS Appointments.ApptStatusMId User-explicit mapping to (Code) MedlistsId; use MedlistsMapping table AND tablename = AppointmentStatus APPT.USERID Appointments.CreatedBy Populate with name from USR table; search USR table for APPT.USERID APPT.BOOKLIST Appointments.FacilityId Parse each book from the source string. Each ID is separated by colons (:) and should be re-mapped to a DoctorFacilityId. Find the LOCID for each BOOKID in the BOOK table; re-map using the LOCIDFacilityMapping table. APPT.BOOKLIST Appointments.DoctorId Parse each book from the source string. Each ID is separated by colons (:) and should be re-mapped to a DoctorFacilityId. If the BOOKTYPE is P for the ID in the BOOK table, re-map using the PVIDMapping table. APPT.BOOKLIST Appointments.ResourceId Parse each book from the source string. Each ID is separated by colons (:) and should be re-mapped to a DoctorFacilityId. If the BOOKTYPE is not P for the ID in the BOOK table, re-map using the BOOKIDMapping table. APPT.APPTDEFID Appointments.ApptTypeId Re-map to ApptTypeId using APPTDEFIDMapping table. - Appointments.LastModifiedBy Populate column with Appointments.CreatedBy - Appointments.Type Populate with Name or NULL; query ApptType where new ApptTypeId = Appointments.ApptTypeId - Appointments.AppointmentsId Auto-generated new id 2032026-001 Rev B 2006 General Electric Company 87

Migrating Data to Centricity Practice Solution Step 3a - Simple table mappings (ApptSlot table) This step creates appointment slots for patients through simple and complex mappings. Source Table: APPT Dest Table: ApptSlot Migration Action(s) APPT.DB_CREATE_DATE ApptSlot.Created Copy data from source APPT.DB_UPDATED_DATE ApptSlot.LastModified Copy data from source Step 3b - Complex table mappings (ApptSlot table) Source Table: BOOK, APPT Dest Table: ApptSlot Migration Action(s) BOOK.ID ApptSlot.ScheduleId Re-map source to ScheduleId; Use SCHEDULEMapping table APPT.APPTDATE APPT.APPTTIME APPT.APPTDATE APPT.APPTTIME APPT.DURATION ApptSlot.Start ApptSlot.Stop Calculate date value and populate Calculate date value and populate - ApptSlot.ApptId Use the generated id of Appointments.AppointmentsId - ApptSlot.CreatedBy Populate with name from USR table; Search USR table for APPT.USERID - ApptSlot.LastModifiedBy Populate column with Appointments.CreatedBy - ApptSlot.ApptSlotId Auto-generated new id 88 2006 General Electric Company March 2007

Appointments information Insurance Code data All orders related to an insurance carrier are candidates to be moved from the PLANORDERINFO table in the source database to the InsuranceCarriersOrderCategory and the InsuranceCarriersOrdersApprvProv tables in the destination database. The preferred service provider for an order is added to the InsuranceCarriersOrdersApprvProv table for the code and category it is assigned. Relevant SQL select distinct * from PLANORDERINFO Simple table mappings for insurance code data EMR only: Simple mappings when migrating EMR data to an empty destination databases. Source Table: PLANORDERINFO Dest Table: InsuranceCarriersOrderCategory Migration Action(s) PLANORDERINFO.COVERED InsuranceCarriersOrderCategory.Covered Copy data from source PLANORDERINFO.PREAUTHREQD InsuranceCarriersOrderCategory.PreAuthorization Required Copy data from source PLANORDERINFO.INDREQD InsuranceCarriersOrderCategory.IndicationsRequired Copy data from source PLANORDERINFO.INSCOMMENT InsuranceCarriersOrderCategory.Notes Copy data from source PLANORDERINFO.FORMTYPE InsuranceCarriersOrderCategory.OrderFormType Copy data from source PLANORDERINFO.FORMPATH InsuranceCarriersOrderCategory.OrderFormFile Copy data from source PLANORDERINFO.PREFPROV InsuranceCarriersOrderCategory.PreferedProviderId Copy data from source PLANORDERINFO.PREFPROV InsuranceCarriersOrdersApprvProv.ServProvId Copy data from source PLANORDERINFO. ORDERCODEORCATID InsuranceCarriersOrdersApprvProv.OrderCodeOrCatId Copy data from source 2032026-001 Rev B 2006 General Electric Company 89

Migrating Data to Centricity Practice Solution Complex table mappings for insurance code data EMR only: Complex mappings when migrating EMR data to an empty destination database. Source Table: PLANORDERINFO Dest Table: InsuranceCarriersOrder Category Migration Action(s) PLANORDERINFO.ORDERCODEOR CATID PLANORDERINFO.ORDERCODEOR CATID PLANORDERINFO.PLANORBUSID PLANORDERINFO.PLANORBUSID PLANORDERINFO.DEFDISP InsuranceCarriersOrderCategory.Order CodeId InsuranceCarriersOrderCategory.Order CategoryId InsuranceCarriersOrderCategory.Insuranc ecarriersid InsuranceCarriersOrderCategory. InsuranceGroupId InsuranceCarriersOrderCategory.Default DispositionMId Copy source data if PLANORDERINFO.ISCODE = Y Copy source data if PLANORDERINFO. ISCODE = N If PLANORDERINFO.ISPLAN = N, re-map to an InsuranceCarriersId; use BUSIDMapping table If PLANORDERINFO.ISPLAN = Y, re-map to an InsuranceGroupId, then find corresponding InsuranceCarriersId; use INSPLANIDMapping table User-explicit mapping to (Code) MedlistsId; use MedlistsMapping table AND tablename = InsCarriersOrdersDisposition - InsuranceCarriersOrderCategory.Created Populate with CurrentTime - InsuranceCarriersOrderCategory.Created By - InsuranceCarriersOrderCategory.Last Modified - InsuranceCarriersOrderCategory.Last ModifiedBy - InsuranceCarriersOrderCategory.Insuranc ecarriersordercategoryid Populate with MigrationUsr Populate with CurrentTime Populate with MigrationUsr Auto-generated new id 90 2006 General Electric Company March 2007

Residual tables Residual tables These tables require one or more mapping tables set up after all previous non-trivial table migrations are complete: Source Table: various Dest Table: same Migration Action(s) LOCREG LOCREG 1 Copy all records from source 2 Populate column Created with DB_CREATE_DATE 3 Populate column CreatedBy with MigrationUsr 4 Populate column LastModified with DB_UPDATED_DATE 5 Populate column LastModifiedBy with MigrationUsr ORDENCINFO ORDENCINFO 1 Copy all records from source 2 Re-map PRIMCOV to PatientInsuranceId; Use INSIDMapping table 3 Re-map SECCOV to PatientInsuranceId; Use INSIDMapping table ORDERS ORDERS 1 Copy all records from source 2 Re-map PRIMCOV to PatientInsuranceId; Use INSIDMapping table 3 Re-map SECCOV to PatientInsuranceId; Use INSIDMapping table PRESCRIB PRESCRIB 1 Copy all records from source 2 Re-map PHARMBUSID to PharmacyId; Use BUSIDMapping table USRDEPT USRDEPT 1 Copy all records from source 2 Re-map BUSID to DoctorFacilityId; Use BUSIDMapping table USRGROUP USRGROUP 1 Copy all records from source 2 Populate column Created with DB_CREATED_DATE if NOT NULL 3 Populate column CreatedBy with MigrationUsr 4 Populate column LastModified with DB_UPDATED_DATE if NOT NULL 5 Populate column LastModifiedBy with MigrationUsr 2032026-001 Rev B 2006 General Electric Company 91

Migrating Data to Centricity Practice Solution Moving data from source to destination The last process for data migration involves execution of all previous sections in order. Running the Data Migration Wizard will execute these actions in SQL as stored procedures or as SQL queries. See Data migration phases on page 2. During migration, several steps occur: 1 Create snapshot the Oracle source database. 2 Transform Oracle database to SQL database. 3 Run trivial migration actions to move EMR data to the destination database. 4 Take a snapshot of all working space data to run an integrity check against the data. 5 Resolve discrepancies in the working space data. 6 Migrate non-trivial data After all actions are complete, the records from source database will exist in destination database. For step-by-step instructions for setting up and running the Data Migration Wizard, see Migrate your EMR Oracle data on page 9. 92 2006 General Electric Company March 2007

CHAPTER 4 Migrating and upgrading custom reports Impact of schema changes 93 Changes to patient relationships 95 Changes that impact reports 95 Practice management views 102 Crystal Reports v10.0 required for custom reports 103 Impact of schema changes Centricity Practice Solution integrates patient clinical data from Centricity Physician Office - EMR 2005 with practice management and financial data from Centricity Physician Office - PM 2004. Reports with custom SQL created in either of those applications might need to be revised to work with the new schema. This chapter outlines changes in the new schema that are likely to impact custom reports. For detailed information about how earlier versions of the the EMR and PM data schemas are integrated in Centricity Practice Solution, see Data migration processes on page 21. We assume that you are an experienced custom reports designer and comfortable using Crystal Reports tool. The relational diagrams included in this chapter were created in Crystal Reports v10.0 database designer view. Changes in the new data schema will significantly impact EMR custom reports, because data in many tables related to patient information has moved to new tables in Centricity Practice Solution. To a lesser degree, small changes to existing PM 2004 tables may impact some PM custom reports. See Converting PM custom reports to Crystal Reports v10.0 on page 104. 2006 General Electric Company

Migrating Data to Centricity Practice Solution The following Centricity Physician Office - EMR 2005 tables were removed from the Centricity Practice Solution data schema and their data moved to new tables: APPT APPTDEF APPTRULE BOOK BUSINESS INSURANC INSURECO LASTLABS OBSNUM PERSON PERSON_PICT PLANORDERINFO RELBUSS RELPERS RELPROV RPTAPPT RPTOBS USRINFO In the new data schema, tables equivalent to tables in Centricity Physician Office - EMR 2005 contain the same information, except where noted. For a list of EMR tables that remain unchanged in the Centricity Practice Solution schema, see Direct data migrations on page 25. The following section describe how these changes impact custom clinical reports. The vpatientprofile and vpatientinsurance views referred to in this chapter contain a PID to help you relink Centricity EMR reports that require this value. Any column in a Centricity Practice Solution table that ends with mid, for example patientstatusmid has an equivalent record that can be looked up in the Medlists table to retrieve codes and descriptions. 94 2006 General Electric Company March 2007

Changes to patient relationships Changes to patient relationships In previous versions of the EMR application, information about patient relationships is stored in three tables: RELPERS, RELBUSS, and RELPROV. In Centricity Practice Solution all patient relationships (except insurance) are consolidated in the PatientRelationship table, where the Type column indicates the lookup location to use when mapping the RelatedPartyId. Type value Centricity Practice Solution table Description 1 Pharmacy Pharmacy 2 DoctorFacility Doctor 3 DoctorFacility ReferringDoctor 4 DoctorFacility PrimaryCarePhysician 5 PatientContacts PersonalContact Changes that impact reports Appointments The following sections summarize the changes to key EMR data in the Centricity Practice Solution data schema: Affected tables with old and new locations New keys, where appropriate Sample view of Crystal Reports data linkage The previous EMR Appointments Module has been replaced by Centricity Practice Solution Scheduling: Physician Office EMR table New Centricity Practice Solution table APPT APPTBOOK BOOK RPTAPPT Appointments APPTDEF ApptType PERSON vpatientprofile 2032026-001 Rev B 2006 General Electric Company 95

Migrating Data to Centricity Practice Solution This is an example of a Crystal Reports linkage from PatientProfile: Employers Information about a patient s employer from the previous EMR BUSINESS table is now stored in the Centricity Practice Solution Employer table. The relationship between patient and employer is stored in the PatientRelationship table. Physician Office EMR table New Centricity Practice Solution table BUSINESS Employer Pharmacy PERSON vpatientprofile RELBUS PatientRelationship Key: The EMR BUSID is now the EmployerId. 96 2006 General Electric Company March 2007

Changes that impact reports This Crystal Reports table design shows the common linkage from the PatientProfile view to Employer: Insurance In Centricity Practice Solution, the concept of an insurance plan is no longer used and insurance companies are considered carriers. All information related to insurance companies from the EMR BUSINESS table is now stored in the Centricity Practice Solution InsuranceCarriers table. The relationship between patient and insurance carrier is stored in the PatientInsurance table. Physician Office EMR table New Centricity Practice Solution table BUSINESS INSURECO InsuranceCarriers InsuranceCarriersOrdersApprvProv - lists insurance carriers approved for orders for a given code and category. INSURANC vpatientinsurance - - contains patient-specific insurance details. The insurance carrier type is determined by the OrderForClaims column: 1 Primary 2 Secondary 3 Tertiary) PERSON vpatientprofile Key: The EMR BUSID key is now the InsuranceCarriersId. 2032026-001 Rev B 2006 General Electric Company 97

Migrating Data to Centricity Practice Solution Here s a typical flow in Crystal Reports from vpatientprofile: Orders The EMR ORDERS table and related tables remain unchanged in Centricity Practice Solution. However, the PID should be used as the lookup into vpatientprofile for Patient information (since that table has replaced the EMR PERSON table. Physician Office EMR table New Centricity Practice Solution table PLANORDERINFO InsuranceCarriersOrderCategory MedLists ORDERS ORDERS ORDERCODES ORDERCODES ORDERCAT ORDERCAT Custom reports referencing Orders have a structure like this: 98 2006 General Electric Company March 2007

Changes that impact reports Patients The EMR PERSON table has been replaced by the Centricity Practice Solution PatientProfile table, which does not contain doctors or patient contacts. Doctors associated with a patient are stored in the DoctorFacility table. Other patient contacts are in PatientContacts table. To facilitate data migration, both the PID (EMR) and the corresponding PatientProfileId (PM) columns exist in the vpatientprofile view: Physician Office EMR table New Centricity Practice Solution table PERSON vpatientprofile DoctorFacility PatientContacts PERSONPICT vpatientprofile Here is a typical Crystal reports setup for retrieving patient information: 2032026-001 Rev B 2006 General Electric Company 99

Migrating Data to Centricity Practice Solution Pharmacy Pharmacy-related information stored in the EMR BUSINESS table is now in the Centricity Practice Solution Pharmacy table. Physician Office EMR table New Centricity Practice Solution table BUSINESS Pharmacy Key: EMR BUSID key used is now the PharmacyId. This is an example of how the table relationship can be extracted from vpatientprofile in Crystal Reports: Relationships Patient relationships (except for insurance) have been consolidated in Centricity Practice Solution in a single table: PatientRelationship. See also Changes to patient relationships on page 95. Physician Office EMR table New Centricity Practice Solution table RELBUSS RELPERS RELPROV PatientRelationship PERSON PatientContacts BUSINESS DoctorFacility Pharmacy Employer 100 2006 General Electric Company March 2007

Changes that impact reports New linkages between the PatientRelationship table and contacts are based on the Type column. This diagram describes a personal contact. Other relevant tables could be substituted for the PatientContacts table here: Service Providers Information about service providers in the EMR BUSINESS table is now stored in the Centricity Practice Solution SERVPROVORG table. Old Physician Office EMR table New Centricity Practice Solution table BUSINESS SERVPROVORG SERVPROV SERVPROV Key: The EMR BUSID key is now the ServProvOrgId. The SERVPROV table remains the same and directs to the SERVPROVORG table for business details: 2032026-001 Rev B 2006 General Electric Company 101

Migrating Data to Centricity Practice Solution Practice management views The Reports module in online help includes a set of views and columns (called the Data Dictionary) you can use to easily access data stored in the database without writing complex queries. You also don't have to modify custom queries when changes are made to the underlying database schema. A view is a query written against a table or multiple tables, but its result set is represented in the SQL Server database as if it were a table. Queries can be performed against the view. See the Reports module in online help for detailed descriptions of the columns, their data type, and whether the field can be empty. Practice management views are grouped in the following categories: Category Views Administration uvprocedures uvdiagnosis uvfeeschedule uvsecurity Claims uvclaims Doctor/Facility/ Company uvdoctor uvfacility uvcompany Patients uvpatientdemographics uvpatientinsurance Schedule Schedule uvwaitinglist Transactions uvcheck uvstatements Visits uvvisit uvvisitprocedure uvvisitdiagnosis 102 2006 General Electric Company March 2007

Crystal Reports v10.0 required for custom reports Crystal Reports v10.0 required for custom reports In Centricity Physician Office - EMR 2005 and Centricity Practice Solution, reports included in application and database management reports are written in Crystal Reports v10.0 (Professional Edition or higher). You must use this version to modify them. If you used an earlier version of Crystal Reports to modify or create new reports with custom SQL, you must convert them to v10.0. Converting EMR custom reports to Crystal Reports v10.0 If your reports were created using a version of Crystal Reports earlier than v9, you ll need to convert your custom reports to Crystal Reports v10.0.!!! You may also need modify your reports to work with the Centricity Practice Solution schema. See Impact of schema changes on page 93. Convert EMR Crystal Reports containing custom SQL 1 Open up your custom report in Crystal Reports 8.5 or higher. 2 Select Database Show SQL Query and log in to the database.!!! If an error message indicates an invalid ML... formula, temporarily change the formula in the report. You can change it back once the report is converted. 3 Copy the SQL text to a text editor and reformat it for readability. 4 Close Crystal Reports 8.5. 5 Launch Crystal Reports 10.0 and open your custom report. 6 Select Database Show SQL Query. 7 Log in to the database and click OK. 8 Select Database Database Expert. a Click the plus sign (+) on the current connection to open the sub-menu. b Double-click Add Command and paste the SQL text from step 3. c d Click OK to exit the Database Expert. Ignore the following warning: More than one data source or a stored procedure has been used in this report. 9 In the Refresh Report Data window, click Cancel. 10 Select Report Formula Workshop and then open Formula Fields. 11 Replace the fields in the report one by one with the fields in the command, changing <Table>.Column to Command.Column in all the formulas. 2032026-001 Rev B 2006 General Electric Company 103

Migrating Data to Centricity Practice Solution!!! Be careful with the duplicate names to be sure you get the right ones. 12 Select Report/Record Sort Expert. Review the sorts and change the columns to use the new Command columns. 13 In the Select Expert, change the formulas to use the new Command columns. 14 If any groups use the old columns, change them to use the new Command columns. 15 In the Database/Database Expert, remove the tables one by one. 16 Refresh the report data, then open Database/Show SQL Query and press Reset. This will not change the query. 17 Replace any formulas you changed temporarily back in step 2. 18 Save the report. Converting PM custom reports to Crystal Reports v10.0 Custom reports written in Crystal Reports v9.0 can be opened and modified in Crystal Reports v10.0. However, you will need to create all new reports using Crystal v10.0. If you have reports created in Crystal 8.5, use the Report Converter to convert reports in Crystal 8.5 to Crystal 9.0, then open in Crystal 10.0 without problems. The program MBCReportConverter.exe is located in your...\program Files\Centricity Practice Solution\Client folder. You can convert a single report or all reports in a database. In the integrated data schema, there are many new tables, but few preexisting PM tables and columns have changed. In one instance, columns were removed from the PatientContacts table, including Company, ContactRelToPatient, Notes, and PatientProfileId. As a result, custom reports involving patient relationships might need to be modified. New columns and indexes were added to the following Centricity PM 2004 tables: Appointments ApptSearchCriteria ApptSlot ApptType CasesInsurance CasesPatientVisitFiling DFIds DoctorFacility Guarantor InsuranceCarriers MedLists MIKDestination MIKEventLog MIKPatientVisit MIKPatientVisitDiags MIKPatientVisitProcs PatientContacts PatientInsurance PatientProfile PatientVisit PatientVisitProcs Pharmacy PlugIn ScheduleResource SecurityNodes SecuritySettings SpreadSheetsEditor StatementsCriteria Because there were many changes to tables related to patient information, guarantors, providers, and insurance, you should probably check your custom HCFA and UB92 reports. 104 2006 General Electric Company March 2007