Configure a Windows system and install HealthShare® Health Connect as an HL7® V2 integration engine in this step-by-step job aid.
There should be a review of all requirements prior to configuring your environment. While InterSystems typically provides best practice configurations, on occasion, we are asked to quote or provide configurations that allow for an apples to apples comparison with systems that are not enterprise grade and do not provide such features as mirroring. In these circumstances you will want to confirm your configuration is not decided by such a request, but rather what is in the best interest of your facility. If you believe this to be the case for your configuration please request a new configuration, that follows InterSystems best practices guidelines, be provided by your assigned sales team.
1. Configure your hardware environment for RAM and CPU as specified in your site’s hardware architecture guide supplied by InterSystems.
2. In a mirroring environment, you will need a total of N+1 IP addresses where N is the number of servers and the extra one is the one for the virtual IP which will likely be controlled by Health Connect mirroring.
3. You will need at least two network cards per machine, per mirroring best practices.
Ask your sales engineer for the amount of space to allocate to each drive.
5. You can translate one LUN to one VMFS (datastore) in a virtual environment such as vSphere (ESXi). When virtualizing, best practice is to have the OS see multiple devices. This is support to segregate journals, databases, and WIJ for performance and resiliency reasons. This is accomplished by presenting multiple VMDKs from that single LUN/VMFS volume to the given virtual machine. Additionally, it is highly recommended to use Paravirtualized SCSI (PVSCSI) controllers and isolate the database VMDKs from the journal VMDKs on separate PVSCSI controllers for optimal performance and provided non-blocking IO / separate queues for databases and journals.
6. To install HealthShare Health Connect, you should run the self- extracting install kit as an administrator (right click on the install kit file and choose Run as Administrator).
The installation will ask you to choose the credentials under which the Windows InterSystems IRIS Service (used by Health Connect) will run. The default is the local default SYSTEM account but you can specify a defined (existing) Windows user account and password.
Refer to your site’s hardware architecture guide supplied by InterSystems for your site-specific routine buffer and database buffer values. After installation succeeds, these values will be configured in the Management Portal. Note that these values are important because they influence other tunings discussed below.
InterSystems recommends granting the Windows “Lock Pages in Memory” privilege to the user account used to run Health Connect. This privilege allows Health Connect to request its memory as Windows large pages, which provides more efficient use of memory and paging space. When you restart Health Connect while using large pages, you typically also need to restart Windows, to guarantee that all the configured memory is allocated. If startup is unable to allocate the full amount of configured memory, it attempts to start up with less memory, and may or may not use large pages. You can check the actual memory allocated by reviewing the most recent Health Connect startup in the cconsole.log.
If you are running 64-bit Health Connect on Windows Server 2003, and the total amount of shared memory configured for Health Connect exceeds 2 GB and is not allocated as Windows large pages, Health Connect can become slow or unresponsive. In these circumstances, key Health Connect processes, such as the write daemon, spend more and more time in the Windows kernel, visible as percentage of Privileged time in Windows Performance Monitor, perfmon.exe.
This problem does not occur when memory is allocated as large pages, and does not occur in Windows Server 2008 even when using small pages. InterSystems recommends granting the “Lock Pages in Memory” privilege to allow Cache to use large pages on all versions of Windows.
To set this, go to Edit Group policy:
Then stop Health Connect, restart Windows, and start Health Connect again.
8. In addition to any TCP interface ports; there are three different default ports the application will use, though you can select others if you wish. Make any necessary firewall configuration changes to allow internal access to ports 1972, 57772, and 2188.
9. There should be easy ways of moving files to and from the servers (such as file shares or SFTP/FTP), and also an easy way to get to the Windows desktop (such as Remote Desktop).
10. Mapped Drives vs. Universal Naming Convention (UNC): Windows allows user to map file share paths to drive letters. Microsoft discourages the use of "mapped" drives for system software because the drive mappings are set up per user account and thus are not generally available for "system" software. Within Health Connect it is possible to map drives using the net use command inside of the %ZSTART routine but the preferred method to access the file shares is by using the Universal Naming Convention (UNC) standard. UNC consists of the \\serverName\ShareName syntax to specify the remote path. If the server that Health Connect is running on has been granted share permission in general this should also work from inside of Health Connect. Note that the file share must allow permission for Health Connect to access utilizing either general permission for open access or specific user permission. Health Connect will normally look like the system default user.
11. Mirroring requires that an agent known as ISCAgent is running on all nodes of the mirrored system including the two HR nodes, the DR node and the Arbiter node. On Windows the ISCAgent will normally start with installation. The ISCAgent should also be configured to start automatically (see item c. in the following list).
Controlling the ISCAgent on Microsoft Windows Systems:12. Security considerations should be established before installation consistent with the needs of your specific site. These decisions dictate security settings on both the OS hosting the Health Connect installation and within the Health Connect installation itself. It is recommended that you familiarize yourself with the following resources from documentation, but further consultation with your site's InterSystems account team or the InterSystems Worldwide Response Center may be helpful as well.
13. With regards to the OS, the installation will be performed by a normal Windows login by running the install kit as Run as Administrator. Users that will be able to log in to the servers desktop will be able to start and stop Health Connect. Additionally, you must know the OS user that will own the instance (normally System in Windows). Any file shares that you wish Health Connect to utilize will need to grant permission to this user.
Be aware that an ACE is added to the entire installation directory for v2012.2+ which allows any user who can log into Windows, by default, to interact with the filesystem. These users can then automatically copy, modify, or replace any file in the entire install directory, essentially having full control of your instance. It is therefore important to consider imposing stricter limits on the access of Windows users to the Health Connect installation directory by removing the ACE granting access to all authenticated users. To learn how to do this, see "Installation Permission Changes" in documentation.
14. After installation, you will want to review certain security matters inside the Health Connect installation. A few users come by default with the system, depending on level of security specified at installation time, such as SuperUser and _SYSTEM. Depending on the usage, these users should be disabled or have their default password changed. For more information, see "Specifying the Appropriate Privilege Level for the Instance’s Users" in documentation.
Be aware that a single username used by multiple individuals complicates proper auditing and isolation of privileges.
Any web applications in use have their own security model; for a closer review, see the "Applications" guide in documentation.
Having an issue with the learning site? Want to provide feedback on a course? Contact us by emailing online.training@intersystems.com.
Please include all relevant information, including the page or course you are having trouble with, and any necessary screenshots.