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 decrease the monthly cost. The Virtual Machine scale sets for auto-scaling is provided as an option to consider, but is not part of the overall architecture as it has not been fully implemented and tested.
The disk size and type used by the VM can also vary the overall price. It is recommended to use the Standard SSD option as it is a good middle ground between the other options. The lowest option Standard HDD can also be used, but based on the Azure website, this is recommended for "Backup, non-critical, infrequent access" use cases. The size of the disk allocation can also be decreased. If the backend database to Mirth® Connect by NextGen Healthcare is not sharing the disk allocation to the VM, then the disk size can be reduced to use the bare minimum. The bare minimum would be sufficient disk space to run the OS and Mirth® Connect by NextGen Healthcare. The majority of the disk usage will be on the storage of the messages and thus the disk allocation should be higher on the database resource.
The SQL Managed Instance's disk allocation should be based on the volume and size of the messages along with consideration of how long you want to keep the messages (message pruning). If you have a more aggressive pruning schedule (7 days or less) for all channels, then a smaller disk allocation of the database can be considered. If you are processing smaller messages with a smaller volume, then a smaller disk allocation can be considered. The general rule is to consider a 5 times message storage for the original message size. For example, if your original message is 1KB in size, consider having 5KB to process that message through the channel, with basic transformations and minimal mapped variables.
An alternative to using the managed Azure SQL database is to implement a Postgres database on the same virtual machines running Mirth® Connect by NextGen Healthcare. Each VM will have its own Postgres instance that each Mirth® Connect by NextGen Healthcare will use independently of each other. The positive would be that it will reduce the overall cost by removing the Azure SQL database, as Postgres is freeware. Since the VMs are located in two different availability zones, it will still meet the 99.99% SLA. The negative is that the PaaS capabilities for a managed service (automatic patching and version updates, automated backups) will be lost. Since the two Mirth® Connect by NextGen Healthcare instances are not sharing a single database instance, maintenance of channels will require making changes to both instances rather than only one, which is another downside. Disk allocation to both VMs will also need to be increased to accommodate the need for the Postgres back-end database.