V10 Upgrade Information
- 1 Description
- 2 Findings
- 2.1 Upgrade Logging
- 2.2 SQL 2005 Considerations
- 2.3 .Net TimeZone Issue
- 2.4 SQL 2005 FW Install Considerations
- 2.5 Scan Upgrade
- 2.6 Web Server Upgrade
- 2.7 Database Upgrade
- 2.8 Medcin Version
- 2.9 Client Apps
- 2.10 Scan SP41
- 2.11 PDA Upgrade 10.2.7
- 2.12 RxDisable Preference for 10.2.4 upgrades and higher
This page is dedicated to information for the V10 upgrade process. As we hear or find issues with the upgrade process, we should note them here for others to benefit from. Most of this information applies to 10.2.7 upgrades.
I have forwarded this to the configuration management team. They have requested in the past that when we report issues with the installer that we also include the log files -- so going forward (for v10 upgrades), we should use the "Detailed Log" option in the installer where available. When you have issues where there appear to be problems with the installer or with the scripts, please either send them to me with a copy of the log, or enter an RTI incident and attach the log and let me know the incident number.
SQL 2005 Considerations
I am doing an install of 10.2.7 for a re-build of a test environment. A few more caveats about this release have come to my attention. Note that the DB server in this test environment is 64 bit SQL2005. Not a typical situation, but may become more frequent with 10.2.7 and later, 10.2.8, as more clients think about what hardware they are going to want to put in play for a v11.x environment.
Running the DB install (not upgrade, install), after making the connection to the database, the pull down where you would select the respective database names for the install (i.e. Works, IDXwf, Impact) does not provide any database names. The names can be manually typed in, which is fine, but is not how the installation is documented.
Oh, and then the databases are created in name only...NO TABLES! This is a result of where the database backups are unzipped before they are restored. Basically, I think because this is a 64 bit system, there are two Program Files folders: 'C:\Program Files' and 'C:\Program Files (x86)'. So what happens is the installer unzips the database backup to the temp folder in one of these folders and then tries to restore from temp folder in the other one.
.Net TimeZone Issue
The documented location for the script to register the .Net Time Zone code is incorrect. The script that needs to be run is in the following folder:
..\Allscripts Software\TouchWorks\Databases\TW9x_TW10.2.3DBUpgrade\SQL\TouchWorks\Clinical\099 DEC06 Assemby and CLR Procedures for TimeZone.sql
SQL 2005 FW Install Considerations
The setup.hta for IDX Web FrameWork GR 4.09.00.079 is pre-set to SQL2005 = True...this may be an issue if you are not using SQL 2005. The other setup.hta's appear to have this set to False.
For upgrading the Scan database I copied over from live, the dbupgrader was not at all pleased with the patients.viw. I had to drop this view. It was re-created later in the upgrade.
When I attmepted to run the DBUpgrade after upgrading the Impact Server I received this error:
430 Class does not support Automation or does not support expected interface
To fix this, you must launch the scan client first. Once the scan client has been upgraded the DBUpgrader should work fine.
Web Server Upgrade
- requires both upgrade links
- upgraded version of Sun Java included. There is an uninstall for 188.8.131.52 and an install for 184.108.40.206 as part of the upgrade
- still potential VOE problems to be worked through. I found on 2 out of 3 installs that after the first web upgrade link was processed the VOE service did not restart, despite Installation Manager's assertion that it did. After processing the second link it was started. However, when right-clicking to see the properties, I got a configuration manager error "The specified device instance handle does not correspond to a present device". I tried running a Repair on the TouchWorks Web install via Add/Remove Programs, which took longer than both upgrade links put together and had no effect. Reinstalling VOE a few times usually makes it go away (sometimes it has to be uninstalled completely and reinstalled and reconfigured, for those who haven't been through this before).
- I got an error during the scan integration scripts saying that the Patients view couldn't be dropped (dbo.Patients in Impact). However when I investigated I found that there were now 2 views ... one IDXAdmin.Patients and one dbo.Patients. So my guess is that this is due to a malformed existing install on my test platform. Which is good news because it means that the upgrade is now delivering the proper Patients view with dbo as the owner.
- The 10.2.3 scan integration is delivering the wrong version of rsGetWarehouses. I will attach the corrected version from the old workbook in the new tech steps.
- Still have to grant impactuser execute permissions on the idxwf..GetPreferenceSetting stored procedure
- Still have to grant impact user select permissions on the following idxwf tables: UserPreference, SystemApplication, SystemProduct, and SystemSecurity (the Preference and SystemPreference tables have select permission already)
Make sure you upgrade the Medcin version to December 2007 (which is actually November 2007 Medcin, but anyway it's included on the CD). We need to be on the lookout for incorrect versions of the medcin.xxx files resulting from this upgrade -- I will get the correct timestamps for comparison and let you know whether the version that comes with the CD is the right one.
Patient Merge is the only client app that appears to be changed from 10.2.6 to 10.2.7 (the 'hotfixed' version of SA from 10.2.6 is included with 10.2.7)
10.2.7 Patient Merge Issue
So far we have had two 10.2.7 upgrade clients report an issue with the version of Patient Merge that is delivered with 10.2.7 -- similar to what happened prior to the SA/PM hotfix, it just won't launch. If you encounter this problem:
1. Verify that SA is working. 2. Try reinstalling Patient Merge. 3. Check to see if there are merge requests pending and note how many, using the following script (all these should be run in WORKS database):
select count(*) from patientmergerequest where pendingflag = 'Y'
4. If there are, make a backup of the table and then reset the pending requests so that there will be none -- here's a script:
select * into patientmergerequest_bkp from patientmergerequest update patientmergerequest set pendingFLAG = 'N' where PendingFLAG = 'Y'
5. Try running Patient Merge again. 6. When it still doesn't launch, go ahead and link your incident to Problem 279364. Development is already aware of the issue and looking into the matter. 7. Here is a script that will put the original requests back to a pending status (the number of rows affected should equal the original count from step 3):
update patientmergerequest set pendingflag='Y' where oldpatientid in (select oldpatientid from patientmergerequest_bkp where pendingflag='Y') and newpatientid in (select newpatientid from patientmergerequest_bkp where pendingflag='Y')
Beginning with SP 39, there is a new version of the Citrix Remote Scan Workstation which is REQUIRED to be upgraded prior to attempting to use Citrix Remote Scanning. Failure to do so results in painful scan issues the resolution of which involves manually removing and readding scan records in the database. In addition, there is a new requirement that the client must have a Citrix Remote Scan license installed on the scan server in order to use it. The license is free and can be acquired by contacting Level 1 Scan support. The remote scan workstation upgrade is not on the CD, but I will put it up on flanders. I also have some documentation on the upgrade process.
I only ran the first link on the Print Server Upgrade for now. I will do some testing and see if that second one is required similar to the web upgrade. That is all for now. I have bunches of notes and am taking the tech steps home with me tonight to try to finish them. Obviously not done today as planned, but I still hope to get them out tomorrow and meet my self-imposed end of the week deadline.
PDA Upgrade 10.2.7
We found that the upgrade was not delivering a new version of the download.htm file for PDAs ( Program Files\AHS\TouchWorks PDA\download.htm ). This caused errors when trying to update the PDAs. There should be an updated version delivered with each upgrade. Upgrade Techs -- as a workaround, after the Web Upgrade open the source code for this file and edit references to the previous version to update the text and the filenames to point to the new version PDA install files for TestConnect and TWUpdate. For example:
In C:\Program Files\Allscripts Healthcare Solutions\TouchWorks PDA\download.htm
<a href="UPD_10_2_4_45.cab">TouchWorks Update Utility (10.2.4.45) </a>
<a href="TC_10_2_4_45.cab">TestConnect (10.2.4.45) </a>
<a href="UPD_10_2_7_62.cab">TouchWorks Update Utility (10.2.7.62) </a>
<a href="TC_10_2_7_62.cab">TestConnect (10.2.7.62) </a>
RxDisable Preference for 10.2.4 upgrades and higher
Please be on the lookout for the the following issue in v10 upgrades from 10.2.4 and up to 10.2.7. I have seen a couple of incidents come through which suggest that the RxDisable preferences for putting signatures on printed/faxed prescriptions are being cleared or overwritten by the upgrade.
I have reviewed the upgrade scripts that affect this preference and don't see anything that should change an existing preference. In order to eliminate the upgrade as a suspect in the future I suggest that the values of these preferences be noted prior to the upgrade. Then compare them post upgrade to verify whether or not they have changed. Please let me know immediately if at any time you find that the upgrade has changed this preference.
This is just a temporary step until we can confirm that the upgrades are not actually changing the preference (or that they are). By the end of July we should have enough data to make a determination, and I will send out an update at that time.