Personal tools
You are here: Home / OSCAR EMR 15 / 4.0 Developers / 4.1 Installation / 4.1.1 Migration 12_1_2 to OSCAR 15

4.1.1 Migration 12_1_2 to OSCAR 15

Migrating from 12_1_2 to OSCAR 15 requires a rebuilt server

Preface

This migration instructions allows people on OSCAR 12_1 migrate to OSCAR 15.

Document Version History

  • v1.0 – initial OSCAR 15 version published to oscarmanual.org – May 10, 2016
  • v1.1 – added instructions to increase tread stack if gets indexing error – July 6, 2016
  • v1.2 – corrected path for new document directory – Oct 24, 2016
  • v1.3 – added instructions for upgrades from non deb installed OSCAR 12_1 – May 5, 2017
  • v1.4 – added instructions for patch1.sql for DEBs newer than v64 – Sept 7, 2017
  • v1.5 – clarified that you must start with the last OSCAR 12_1 – Sept 19, 2017

Migrating from older OSCAR installations

Note that BC region upgrades have not been tested.

OSCAR 15 is not an incremental upgrade to OSCAR 12_1.  Most systems and many conventions have been changed, and an in place upgrade is neither recommended nor supported.  These instructions start with a new server which will improve performance and reliability and leaves the old server intact as business continuity security.  

There is nothing like production data to humble programmers.  Test your conversion on a backup first prior to committing to convert live data over.

1. Update your OSCAR 12 to 12_1_2

2. A NEW OSCAR_12_1_2 Backup

Save a new backup of your 12_1_2 build 585 installation.
mysqldump --opt -uroot -p******* oscar_12_1 > OscarBackup.sql

3. Install OSCAR 15

  • You need a new server for OSCAR 15 that is separate from your OSCAR 12 machine
  • Install a new installation of OSCAR 15 with demo data on a fresh VM or machine with standard property files that is separate from your existing OSCAR instance.
  • Confirm that the installation is working with the standard login of oscardoc mac2002 1117

4. Create Blank Database

After having tested the new OSCAR 15 installation to confirm that it works, take the opportunity to retrieve the Rourke 2014 eform code with the following (supply your MySQL password for the ******)

mysqldump -no-create-info -uroot -p******* oscar_15 eform > RourkeEform.sql
Now you can now safely drop the schema. 
mysql -uroot -p****** -e "drop database oscar_15;"

Now create a blank oscar_15 schema that defaults to new best practices database engines and encoding.

mysql -uroot -p****** -e "CREATE DATABASE IF NOT EXISTS oscar_15 DEFAULT CHARACTER SET utf8  DEFAULT COLLATE utf8_general_ci;"

5. Clean The Backup

The standard backup historically has been using latin1 encoding on MyISAM database engine.  For best results for using Integrator, support for foreign characters, and keeping up to date this needs to be changed to InnoDB and UTF8.  Its much safer and quicker to convert the data when it is in the form of a backup than in the server, so we will do it now.

Change to your home directory on your new server.

cd ~
You need to de-compress and de-encrypt your existing oscar_12_1 schema backup in preparation of loading it to the new server.   If you were using a non standard backup and are unable to de-encrypt, use mysqldump using the password and the database name found in the OSCAR 12_1 properties file to make a fresh OscarBackup.sql for your OSCAR 12_1 instance.
 
The standard backup specifies the engine and encoding but it is usually to large to edit using GUI editors.

Instead you can change all the encoding and engines with the following sed command.  These changes will also prevent your backup from deleting the legacy table structures you just added.

sed 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=UTF8/g; s/ENGINE=MyISAM/ENGINE=InnoDB/g; s/DROP TABLE IF EXISTS `formRourke2009`;//; s/CREATE TABLE `formRourke2009`/CREATE TABLE IF NOT EXISTS`formRourke2009`/;s/DROP TABLE IF EXISTS `formONAREnhanced`;//; s/CREATE TABLE `formONAREnhanced`/CREATE TABLE IF NOT EXISTS`formONAREnhanced`/; ' <OscarBackup.sql > CleanBackup.sql

6. Load Legacy Structures

Now populate the blank OSCAR 15 database with the structures of two legacy MyISAM tables (`formRourke2009` and `formONAREnhanced` cannot be converted and will be retained in their current state for backwards compatibility). 

mysql -uroot -p****** oscar_15 < /usr/share/oscar-emr/legacyMyISAM.sql

7. Restore the Backup

Then load the cleaned backup into the empty oscar_15 schema.  A 10GB (1.8GB gziped) backup may easily take a half hour so... get a coffee! 
mysql -uroot -p****** oscar_15 < CleanBackup.sql

8. Update the Schema to oscar_15

a) Case 1: Known Starting Point

If you have updated your DEB successfully to the final version of oscar_emr12.1.2-76final585.deb as mentioned in step 1
Then you can safely run the migration script that brings the OSCAR schema from the last version of 12.1.1 to 15.  
mysql -uroot -p****** oscar_15 < /usr/share/oscar-emr/oscar_12_1_1_to_oscar_15.sql

This script can only be run once and must run to completion without error.  On any error the conversion will stop at that point and the system will be broken.  Note the line number of the error.  You will need to fix the error(s) in your data at that line number in the conversion script and rerun the conversion script FROM THAT LINE NUMBER.

NOTE:  If the script fails with something like

"ERROR 1062 (23000) at line 1443: Duplicate entry '1838-rxInteractionWarningLevel' for key 'uk_demo_ext'"

it is likely that you need to edit  /etc/mysql/my.cnf to set the tread_stack=256K or greater

b) Case 2: Unknown starting point

The state of your existing OSCAR 12_1 database will be unknown if it was not created by the final version of oscar_emr12.1.2-76final585.deb.  Unless that is the case you should update the database from your clean backup to the latest 12.1.1 schema.

There are utility scripts that OSCAR_15 puts in /usr/share/oscar-emr that will convert between schema.  These are NOT safe to be re-run and will error and stop converting at the noted line number.  If you experience an error, correct it and then run the script for the line numbers AFTER the error.

These scripts include scripts allow for conversion from OSCAR 10_12 to OSCAR_11 and from OSCAR_11 to OSCAR 12.  The final update script, oscar_12_to_oscar_12_1.sql takes you through update-2012-03-29.sql to update-2012-11-03.sql. 

Then you need to apply a patch to get to 12.1.1.  The patches in OSCAR are written to be safe to be re-run usually without errors, although they will often offer warning messages which indicates that a change is being skipped as its not necessary. You can ignore those.  If there is a true error, the console will provide the line number where it stops executing the script.  That requires you to fix your data before re-running the patch.
 

Get your FINAL12_1patch.sql patch here  

wget http://sourceforge.net/projects/oscarmcmaster/files/FINAL12_1patch.sql
Run the patch script that corrects and updates your OSCAR schema from version 12.1? to the last 12.1.1.   
mysql -uroot -p****** oscar_15 < FINAL12_1patch.sql
Now at the final form of the database for 12.1.1 you can safely run the migration script that brings the OSCAR schema from version 12.1.2 to 15.  
mysql -uroot -p****** oscar_15 < /usr/share/oscar-emr/oscar_12_1_1_to_oscar_15.sql

9. Patch From OSCAR_15 to the Latest OSCAR_15 Schema

Last minute tweaks that came out after the conversion script was made are in a special patch file(s) that the OSCAR 15 deb has placed on your hard drive.  If you have both patch files (DEBs labelled version 64 or newer eg oscar_emr15-64~671.deb) you need to load them in the following sequence.  For older DEBs you won't have a patch1.sql so just execute the patch.sql line. 
mysql -uroot -p****** oscar_15 < /usr/share/oscar-emr/patch1.sql
mysql -uroot -p****** oscar_15 < /usr/share/oscar-emr/patch.sql

You can ignore any  messages such as DropIndexMessage that you might see, they are warnings and not errors.

10. Copy over OscarDocuments

You will also want to copy over the OscarDocuments from your backup.  You can copy them using rsynch over the network from your previous server with something like the following:.

rsync -avz --progress --chown=tomcat7:tomcat7 --rsh='ssh -p22' {USER}@{OSCAR 12 SERVE IP}:/var/lib/tomcat6/webapps/OscarDocument/oscar_mcmaster/ /usr/share/oscar-emr/OscarDocument/oscar/

11. Migrate ONAREnhanced (optional)

Navigate to Admin> Updates and Migrations > Migrate ONAREnhanced and run the report/utility

12. Install Non-Free components (optional)

In the province of Ontario, regulatory requirement mandates OSCAR to use a commercial drug interaction database.  To configure this Lexicomp/Medi‐span database, add the following line into /usr/share/tomcat7/drugref2.properties replacing ????? with the licence key. Please contact your OSP for instructions to purchase a licence key. If you do not have an OSP, contact OSCAR EMR directly for the license key. 

licence_key=??????????

For oscar.properties add the following to the properties file

RX_INTERACTION_LOCAL_DRUGREF_REGIONAL_IDENTIFIER=yes

OSCAR-EMR has obtained a license for Canadian OSCAR users for the 2014 Rourke.  This is at no cost to the eligible end user and is installed automatically by the DEB.  For OSCAR 15 upgrades the main eform code you retrieved in part 1 of this Appendix while the other files will be already loaded.  Edit the sql by hand (the fid of your desired eforms need to be adjusted for your system prior to running the insert) and then run it.

mysql -uroot -p****** oscar_15 < RourkeEform.sql

13. Activate K2A (its easy and free!)

You will want to activate Know2Act as it is a repository of pre made eforms, report templates, drug information, clinical tools and other contributions by your peers in the OSCAR community.  Go to https://www.know2act.org and register.  Then go to Administration > Integration > Know2Act Configuration.  Insert your clinic name into the text box and click Initialize Know2Act.

15 K2A Configuration

A K2A tab will appear on your schedule screen.  Click on it and enter your registration credentials and that's it!.

 

 

Note that this describes a quick way to get up and running.  You will still want to hand adjust the property files to meet your needs.

Document Actions