· Apr 2, 2019

Upgrade Vs Parallel install

Hello All,


Our Group currently has the following version of Healthshare, and Ensemble installed:


Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2015.2.1 (Build 705U) Mon Aug 31 2015 16:53:38 EDT [HealthShare Modules:Core:14.01.7913 + Linkage Engine:14.0.7913 + Patient Index:14.0.7913 + Clinical Viewer:14.0.7913 + Active Analytics:14.01.7913]


We are planning on upgrading all of our instances from 2015.2.1 to the latest version (currently 2018) starting in May. 


These instances are responsible for receiving data (i.e., Dicoms, CDAs, ADTs, and a custom JSON format) from site source systems, checking them for consent, extracting whitelisted elements, de-identifying the data, and passing that data downstream to a client database. We store bare minimum patient information on the MPI to check consent.  We mostly use custom code for the data normalization and processing. For communication between servers, we use SOAP classes generated in studio.  For consent, we use the consent API in HSPI.  


The main reason we are upgrading is to get Atelier, the latest vulnerability fixes for HSPI as well as the latest MPIID Data Integrity and configuration Check utilities. There are a few issues involved with the upgrade that we are having trouble reconciling.


Our first issue is that we can only do one upgrade at a time. We could spend several days upgrading all the sites. If we were to perform our updates one at a time, Could the Edge Gateways on the older versions of Ensemble still interact with the newer versions of Healthshare on the shared Registry and MPI instances? The InterSystems documentation seems to suggest that communication over SOAP should not be affected (see Web Services and SOAP section at  We are worried about communication between the old and new Healthshare out of the box components.


Another potential approach was to do a parallel fresh install of 2018 and to import all custom code to that version. That way we could migrate everything without having to bring the previous instances down until the new ones are ready to go. The issue with this approach is that we are unsure if we would be able to use the database files containing the Audit logs as well as the patient information in the MPI. Will those same databases work across different versions? 


There are a few more issues, but those are our primary concerns. Has anyone done a parallel install vs. an upgrade?  What are the advantages/ disadvantages to a parallel install? Are there any other considerations?


We believe that...


The advantages of a parallel upgrade seem to be:

  1. Less downtime since production systems can run until their replacements are ready.
  2. Easier rollback (if the new instance doesn’t work just turn it off and switch back to the old instances)


The disadvantages

  1. We would need to copy the databases the old instances were using and remap them.
  2. We would need to reschedule the tasks we had running in the new instances.


Knowledge Gaps

  1. Not sure if the New versions of Ensemble/ Healthshare can use the older database files.
  2. Not sure if using the old database files will get us the Audit logs
  3. Not sure if any additional configurations are necessary for a parallel install

Any feedback on this matter would be greatly appreciated. 

Discussion (3)1
Log in or sign up to continue

Hello Miguel,

My name is Sebastian Musielak and I'm one of the Product Owners of HealthShare.  I've also spent some time in HealthShare Support helping customers just like you go through the upgrade process.  

First off, I'd like to say that I'm happy to hear that you are upgrading to latest release of HealthShare Information Exchange, HS 2018.1.  That's great news.  That being said, I have a few questions and comments about your upgrade:

1) Have you been in touch with your Account Team at InterSystems to get their thoughts on the upgrade process?  Your Account Manager and Sales Engineer are a great resource in getting started in this process.  

2) What is your timeline for this upgrade?  In my personal experience, HealthShare customers typically take a few months of testing their customizations on the upgrade version before performing the actual upgrade in their LIVE environment.   Please make sure to adjust your "Go Live" date accordingly.   Don't forget that you also have the option of moving to the next release of HealthShare (2019.1) when that comes out as well. 

3) In my experience with customers, the biggest hurdles they face in upgrading a HealthShare environment has been dealing with customizations.  If you haven't already, I strongly recommend you take a thorough inventory of all of the customizations that you have made in your version and document why that customization is there (whether you're fixing a bug in your version or adding functionality that wasn't there in your version).  Unfortunately, the HealthShare Version you're running (HS Core:14.01 running on Ensemble 2015.2.1) is quite a bit older than the latest release version (HS 2018.1), so for each customization that you have made, you need to confirm whether it should still be included in HS 2018.1.  

4) Regarding the notion of performing an "In-Place" upgrade vs. a "Migration" to a parallel set of servers, I can tell you that the InterSystems HealthShare Quality Development team has not tested the migration of code and data from HS Core 14.01 to HS 2018.1, so we can not recommend that approach for upgrading your LIVE environment.  What we will recommend though is creating a TEST environment which mimics your LIVE environment as closely as possible.  With your parallel TEST environment running on the same version as your LIVE environment,  you can perform upgrade tests which will allow you to see how well your customizations work in HS 2018.1.  That will give you a good estimate for how long an in-place upgrade might take. 

5) Finally, to address some of your Knowledge Gaps:

  • Question: Not sure if the New versions of Ensemble/ HealthShare can use the older database files
  • Answer: Although the underlying Ensemble Instance in HealthShare 2018.1 is able to mount and read globals from the CACHE.DAT file that came from a HealthShare instance of HS Core 14.01, the data and SQL table structures have changed between versions, which means that HealthShare running 2018.1 will not run correctly on data from an HS Core 14.01 instance.  It must first go through a conversion process which is done during upgrade and Namespace Activation. 
  • Question: Not sure if using the old database files will get us the Audit logs
  • Answer: A similar answer to the above applies here.  Although the 2018.1 instance can mount the CACHE.DAT file and read globals, HS Core 14.01 data needs to be converted during upgrade and Namespace Activation to run properly in 2018.1. 
  • Question: Not sure if any additional configurations are necessary for a parallel install
  • Answer: As mentioned, the parallel installation is not recommended.  

I hope this give you a good place to start.

Good luck on the upgrade!

Best Regards,

Sebastian Musielak

Product Specialist – HealthShare

InterSystems Corporation