Support Considerations

Mirth® Connect by NextGen Healthcare Deployment in Azure®

Containerized versus Virtualization

Mirth® Connect by NextGen Healthcare can be run using Azure Kubernetes Service (AKS). The Azure Kubernetes Service is a managed service which takes care of the availability of your underlying clusters, auto scaling, or patching your underlying VM. The benefit of using containers can be quickly deployed as it does not require loading of the underlying OS. The disk space used is smaller as it only requires the space to run the application (Mirth® Connect by NextGen Healthcare and does not require space for the underlying OS. The benefit of running a VM is that it is able to be scalable vertically. With AKS, scaling is done only horizontally using the Cluster autoscaler. Mirth® Connect by NextGen Healthcare upgrades are more complex with containerization. The container image will need to be updated with the upgrade of the Mirth® Connect by NextGen Healthcare application. The NextGen support team will not be able to update container images with the updated Mirth® Connect by NextGen Healthc

Mirth® Connect by NextGen Healthcare Deployment in Azure®

Mirth® Connect by NextGen Healthcare Setup Considerations

It is highly recommended that both the Advance Clustering and Advance Alerting plugins be installed on the Mirth® Connect instances. The Advance Clustering plugin will allow the user to view message statistics between the nodes and also view the health of the nodes. Together with the Advance Alerting plugin, an alert can be configured so that if any of the nodes becomes unavailable, the proper resources can be alerted. It is also recommended that Mirth® Connect version 3.6+ be installed. This is because the proper JDBC driver required to communicate with the managed Azure SQL database is not natively contained with the older versions. A work-around can be done by installing the latest Microsoft SQL driver with the older version of Mirth® Connect, but this is not recommended. Benchmark testing of both Mirth® Connect 3.5 and 3.11 was performed to identify if there are any performance issues when comparing the two versions. Messages were sent via TCP in a channel running on a local machin

Mirth® Connect by NextGen Healthcare Deployment in Azure®

Options and Recommendations

A way to manage the overall cost of deployment of the Mirth® Connect by NextGen Healthcare on Azure is to decrease the compute and storage resources allocated to the virtual machines and database instances. The compute and storage size for the VMs can be decreased if the traffic and workload does not warrant the higher CPU and memory allocation. The CPU and memory should correspond to the number for channels deployed and the overall volume and size of the messages. If you plan to have channels perform transformations of large (CDA messages, large flat files, and so on), increasing the memory is suggested. If you plan to use multi-threading in many of your channels, then increasing CPU is suggested. The resource allocation for the VM setup mentioned above is only a recommendation. It can be adjusted based on the amount of traffic and the size of the message being processed. Vertical scaling using the Azure Virtual Machine scale sets, as described above, is another option can also decrea

Mirth® Connect by NextGen Healthcare User Guide

Before You Upgrade

Before upgrading, NextGen Healthcare highly recommends that you backup both your Mirth® Connect Server Configuration and your Mirth® Connect database using the following steps. Note: mirth_home directory. Backup server configuration: Before proceeding, it is important that you backup your existing server configuration. This can be done through the Mirth Connect Administrator (Settings>Server Tab>Server Tasks – Backup Config). The server configuration includes channels, code templates, alerts, and global scripts. User accounts and stored messages will not be backed up. Backup database: If you use the embedded Derby database, create a backup of the "mirth_home/appdata/mirthdb" folder. Note that appdata is the database folder as defined in the "mirth_home/conf/mirth.properties" file. For additional information, see mirth.properties File. If you use an external database (for example, PostgreSQL, MySQL), create a backup of your database using your preferred database administration tool (for

Mirth® Connect by NextGen Healthcare Deployment in Azure®

Architecture - Design

The recommended architecture described in this document has high availability as the central requirement of running Mirth® Connect by NextGen Healthcare using the Azure cloud services. This requires the use of two Centos virtual machines (VM) located in two different availability zones. Each virtual machine will run Mirth® Connect with the advance clustering plugin installed. The cluster will have an active/active configuration where the Azure load balancer will route traffic to either VM nodes. The backend database for both Mirth® Connect instances will share a managed Azure SQL database instance, where high availability is achieved by using three different availability zones. The traffic between the Azure services is managed by the Azure Virtual Network (VNet), which allows secure communication between the service needed for the implementation. All the Azure services used in this design is in-scope as part of the HIPAA Business Associate Agreement. Mirth Connect Architecture with Vir

Cures Certification Support User Guide

About Cures Certification Support

With Cures Certification Support, you can determine whether the event log has been tampered with by directly changing the database. Cures Certification Support provides additional features to support Mirth® Connect by NextGen Healthcare's Cures certification. This support includes automatic detection of audit log changes. The Cures Certification Support extension is designed to determine if the events log has been tampered with by directly changing the database. Using the SHA-256 algorithm, a running message digest is created that includes all events in the database as they occur. The digest is saved separately from the audit log to avoid tampering. Every 24 hours the extension compares the correct message digest (that is created throughout the day) against a digest that it creates with the events currently in the events table. The 24 hours count begins at the time the extension is installed (and the server restarted). If a server goes down prior to a 24-hour period, then the validatio