OSCAR 19 Upgrade Guide

Scope

This guide covers the upgrade process of OSCAR 15 to OSCAR 19. OSCAR 15 is not easily defined due to the fact that many users have done updates since the original release (build 361, Feb 12, 2016). Although some users may be starting the upgrade from different points in time, the process remains the same.

Database Updates

Database updates must be performed in order to upgrade the schema and perform essential data migrations to support the updated codebase. The update files are available from the OSCAR source code tree under the database/mysql/updates subfolder and each file's release date is encoded within it's name. The files can also be seen and downloaded using the following link

https://bitbucket.org/oscaremr/oscar/src/stable/database/mysql/updates/

The user should choose the starting file which is most appropriate, for example, if one is updating from OSCAR 15~build-361, the first file to load into the database engine would be update-2016-02-16.sql. All files should be run in order up until the the date of the build you are running.

If you are not sure the corresponding date of your build, you can find it from one of the following links. 

https://demo.oscarmcmaster.org:11042/job/oscar15BetaMaster/ (for builds up to and including 533)

http://jenkins.oscar-emr.com:8080/job/oscar-stable/ (for builds 534 and up)

For more details on what is contained in each file, see DB Patch files. 

Properties File

The OSCAR properties file has also had some updates. Each entry has a default, but the upgrader should check each new property and see whether or not it should be set to a different value than the default for the clinic they are upgrading.

The list of changes are available here OSCAR Properties.

Updating the Dependencies

Upgrade to  Ubuntu 18.04

Upgrade to JAVA 8 or 11

Upgrade to Apache Tomcat 8.5.x (latest) or Tomcat 9 

Upgrade to MariaDB 10.3.x (latest packages on Ubuntu 18.04)

Update DrugRef

Updating the Code

Update the WAR file and deploy

Data Fixes

Under admin → migrations, there is the ability to fix Enrolment Data (sets enrolled to based on MRP at the time), and to migrate to Contacts from relationships