On-Premise Deployment

Change Log

1.006/20/2017DWJInitial Version
1.109/05/2017DWJChanged RHEL/CentOS 6 to 7
1.209/05/2017DWJRemove Render Server - this is now done by the application
1.309/06/2017DWJChanged MariaDB 5.5 to MariaDB 10.2.8


This document outlines the minimum recommended hardware configuration for deployment of Enterprise Health  either on dedicated hardware or within a virtualized environment.


All information supplied in this document by Enterprise Health  is to be considered company confidential. This document (whether in electronic or print format) should only be distributed to the minimum number of individuals possible, and is subject to the restrictions imposed by the executed Non-Disclosure Agreement (NDA) and or contract agreement.


The following critical infrastructure items are assumed to be reliable, redundant and well managed by the hosting organization when considering self-hosting.

  • Power
  • Cooling
  • Networking
  • Security, physical and cyber

This document also assumes the hosting organization has the technical resources to maintain and support the services that will be deployed within the self-hosting environment.


During the installation and configuration period, all instances must have access to the internet for package management and installation. If this install is not an OVA install, then EH engineers must have root level access to the instance during installation and configuration. This elevated security is only during the installation and configuration period.


Enterprise Health  deploys its applications using Enterprise-level open source software. Minimally required services in the hosting environment are as follows:

State Diagram of Services


Typical standalone deployments include three environments to support a Deployment Life Cycle (DLC) for application patches, upgrades and configuration changes:

  1. Development
  2. QA
  3. Production


Enterprise Health  has the ability to run multiple, logically isolated instances of the Enterprise Health  System on a single server or cluster. A URL  for each instance (aka handle) uniquely identifies each instance and provides direct and secure access. This type of deployment is useful for Development and QA environments.


The Enterprise Health  application requires an x86_64 architecture and can be deployed on bare metal hardware or within a virtualized shared or dedicated environment. The balance of this document will focus on deployment within a virtualized environment and includes minimal hardware requirements.

Deployment Methodologies

There are three typical deployment footprints:

  • All-in-one
  • Dedicated DB
  • High Availability / Horizontal Scalability


All the required services run within a single server. This approach is best utilized in small (~50 concurrent users) deployments or for sandbox development use-cases. The “all-in-one” strategy for production is best when a virtualized environment is available for scaling and redundancy underneath the Enterprise Health  System. A VM image that contains all necessary services for the Enterprise Health  System to operate can be provided. This approach can also be used for Development and QA lifecycles. The All-in-one footprint enables quick and easy deployment and can serve as a stepping stone to larger deployments with dedicated services.

Dedicated DB

The Dedicated DB is the first useful step to scaling up to handle more load. The database I/O patterns tend to compete with other I/O so it is useful to split the database to another server with dedicated resources.

High Availability / Horizontal Scalability

The High Availability (HA) and Horizontal Scalability (HS) environment distributes low-level services across multiple systems to provide redundancy and high availability. The Enterprise Health  System is optimized to distribute the components across multiple servers and automatically failover to balanced redundant hardware. Managing a cluster requires expert skills in load balancing, routing, networking and monitoring.

Minimum Hardware Requirement

Hardware requirements vary greatly based on a variety of factors including the number of concurrent users, user activities and data storage requirements. For example, disk requirements will be greater when converting volumes of paper charts to digital images. We typically work with our clients to review current usage requirements and forecast anticipated growth in order to ensure Development, QA and Production environments are provisioned correctly. Minimum requirements are as follows:

Service NameServicesHardware
  • Web Services
  • Database
  • Data Storage
  • Interface
  • Apache
  • memcached
  • MariaDB
  • File System
  • 4 CPU cores
  • 32G Memory
  • 500G Storage
Service NameServicesHardware
Web Services
  • Apache
  • Nginx
  • node.js
  • memcached
  • 4 CPU cores
  • 8G Memory
  • 100G Storage
  • MariaDB
Data Storage
  • File System
  • 4 CPU cores
  • 8G Memory
  • 500G Storage
High Availability/Horizontal Scalability requirements are far more variable, and as such are not depicted here. Please contact your Account Manager for more discussion on this option.

File Servers

  • 3 x (1 as primary, 2 as replication partners)
    • 1 x Quad-core Intel E5 series or better CPUs
    • 64G RAM
    • 5T of storage (RAID6 based array)
  • OS: RHEL / CentOS 7.x

Web Servers

  • 2 x Quad-core Intel E5 series or better CPUs:
    • 12G RAM minimum
    • 500G RAID1
  • OS: RHEL / CentOS 7.x

Fax Server

  1. If using our Dialogic based FAX server, the fax and interface box can be one in the same:
    • One server provides fax functionality, interfaces, and runs a virtual machine for the print functions:
      • 2 x Quad-core Intel E5 series or better CPUs
        • 64G RAM
        • 4 x 600G 15K SAS drives in a RAID10 volume
        • 1 x Dialogic DIVAServer E1 306-304 PCIe fax card for currently developed MIE faxing solution
      • OS: RHEL / CentOS 7.x
      • VM: Windows 7 32bit, running latest copy of Microsoft Word (for print conversions)
  2. If using a separate FAX server, the following specs are for a separate interface server and separate print server:
    • Print server:
      • 1 x Quad-core Intel E5 series or better CPUs
        • 2G RAM minimum
        • 20G RAID1
      • OS: Windows 7 32bit, running Word 2013

Batch Server

  • 1 x Quad-core Intel E5 series or better CPUs
    • 4G RAM minimum
    • 60G RAID1
    • OS: RHEL / CentOS 7.x

Supportive Servers and Services

The following servers and services are not covered in detail in this document, but are typically included as part of a on-premise environment.

  • Fax Server
    • Dedicated bare metal hardware
    • Dialogic DIVA 306-304 PCIe T1/PRI FAX card
  • Interface
    • EDI
    • sFTP/FTPs
    • Socket based

Deployment Guide

Below are the requirements, technical details and steps on how to install, configure and access the Enterprise Health system as an All-in-one VM.

Getting Started

The All-in-One  EH VM deployment is designed to be quick and easy allow for  Enterprise Health environments to be launch within just a few hours.

Downloading All-in-One **_

EH _** VM
  1. Using the link provided by your deployment specials, download the EH All-in-One VM Box Image. If you do not have a link contact your deployment specialist and one will provided to you.
  2. Deploy the VM within your Virtualized Environment
  3. Assign IPv4 address to VM Network and System
  • Hostname
  • DNS
  • VPN to MIE
  • Firewall rules
    • tcp/443 (HTTPS) to MIE and Application Users
    • tcp/22 (SSH) to MIE
    • tcp/389 and tcp/636 LDAP to MIE
    • tcp/10050 and tcp/10051 - Zabbix
    • tcp/1514 OSSec
    • tcp/514 and udp/514 - syslog
    • tcp/4505 and tcp/4506 - Salt
  • Mail Services
    • Allow mail to be sent from instance
  • Monitoring of systems
  • Audit Logging
  • Backup

Web Services Configuring

  • Purchase SSL certificate for selected domain name
  • Configure Apache 2.2.15  with SSL certificates

On-Premise Golive Checklist

Successful Go-Live of an On-Premise Enterprise Health  System requires planning, coordination and orchestration throughout the many facets of the customer’s organization, including divisions and departments to bring everything pieces together. These include, but are not limited to, data migration, IT operations, staff training, support and notification to stakeholders. This document is to help you prepare and plan for such a monumental task.


This checklist is to help the customer plan and give insight to what is needed for a successful go-live and is by no means is comprehensive.

  • Determine Enterprise Health endpoint example: (https://ehs.mycompany.com )
  • Purchase SSL certificates for domain (ehs.mycompany.com )
  • Server / Application Configuration:
    • install and configuration of services

    • Install and configuration of EH

    • Logging

    • Monitoring

    • Backup configuration

    • Outbound email Configuration to EH support

  • Production functionality testing
    • Access to Application
    • View / uploading data
  • Failover testing (if applicable)

Hosted vs On-Premise

  • SOC2 type II certified Data Center
  • Dedicated Services
  • Highly Available
  • Multi-Region Redundancy
  • Tuned for best performance
  • 99.95% uptime SLA
  • Tuned IDS and IPS
  • Auto applied security patches
  • 24/7 Monitoring of infrastructure
  • Backup and rotations
  • Optional data-at-rest encryption
  • Provisioning of hardware
  • purchase of domain name and SSL certificates
  • Configuration of load balancers
  • Configuration of Linux CentOS 7, Apache, MariaDB, MIEFS, failover, logging, monitoring and other software to support the application.
  • Self configured IDS and IPS
  • Support Contract
  • VPN Connectivity
  • Access to servers
  • Easy deployment - 8 to 24 hours, and your Enterprise Health system is up and running ready for production
  • Long deployment cycle
  • Requires provisioning of hardware
  • Software installation and configuration
IT Operations
  • Dedicated Operations team specializing in SaaS and experts in full stack deployment
  • Continuous capacity planning, we scale as you grow

  • Infrastructure may not support EH requirements
  • May require additional resources to support Enterprise Health system
  • Capacity planning may require the provisioning of additional costly hardware or reconfiguration
Software Deployment
  • We plan and deploy hotfixes and upgrades seamlessly
  • Requires patch files to be sent
  • Depending on deployed infrastructure, software updates may require extended downtime to implement.

Managed Services

EH offers managed services for the following:

Enterprise Health Documentation

Last Updated:

Last Build: Tue, 18 Jun 2024 18:57:48 EDT
WikiGDrive Version: dd69069d725fca5f553df7ded62e130a49d49ca6