CNP OpenEMR Infrastructure Plan

Overview

This document describes the target infrastructure architecture for CNP’s OpenEMR-based platform, including the Food RX NFP initiative.

The primary goals are:

Design Principles

Keep Everything in a Box

The architecture intentionally favors simplicity over horizontal scalability.

Rather than adopting a traditional enterprise AWS architecture with multiple managed services, the platform is deployed as a self-contained appliance consisting of:

This approach minimizes:

Infrastructure as Code

All infrastructure must be reproducible.

Infrastructure definitions should be maintained using:

No manual server configuration should be required after provisioning.

Cloud Portability

The deployment architecture should be portable across:

The application stack should not depend on AWS-specific runtime services.

Production Architecture

                Internet
                    |
                HTTPS 443
                    |
            Reverse Proxy
             (Caddy/Nginx)
                    |
              OpenEMR 8
                    |
                MariaDB
                    |
           Encrypted EBS Volume
                    |
       Encrypted Restic Backups
                    |
                    S3

AWS Deployment

Compute

Option vCPU Memory
t4g.medium 2 4 GB
t4g.large 2 8 GB

Recommendation

Production should start with:

t4g.large

Reasons:

Storage

Primary Storage

Encrypted EBS volume:

Stores:

Backup Storage

Encrypted S3 bucket:

Container Architecture

Docker Compose

Production consists of:

services:
  proxy:
    caddy
  openemr:
    openemr
  mariadb:
    mariadb

No orchestration platform is required.

Specifically avoided:

Why Separate MariaDB

Although OpenEMR and MariaDB could technically run inside a single container, a dedicated database container provides:

The architecture remains simple while improving maintainability.

Backup Strategy

Daily Backups

Nightly backup process:

  1. Database dump
  2. OpenEMR file backup
  3. Encryption
  4. Upload to S3

Tools:

Backup Retention

Backup Type Retention
Daily 30 days
Weekly 12 weeks
Monthly 12 months

Disaster Recovery

Recovery requires:

A complete environment can be rebuilt from source control and backups.

HIPAA Considerations

Administrative Requirements

Before production use:

Technical Controls

Encryption

Access Control

Auditing

Network Security

Environment Strategy

Local Development

Development environments run locally.

Requirements:

Docker
Docker Compose
OpenEMR
MariaDB

No cloud resources required.

Testing

Testing environments should mirror production.

Differences:

Production

Production uses the same Docker image and Compose definitions as development.

This ensures:

ARM Architecture

Target Platform

Preferred architecture:

linux/arm64

Reasons:

Validation Requirement

Before production deployment, verify all images support:

linux/arm64

Including:

If any critical component lacks ARM support, production should temporarily use x86_64.

OpenEMR Customization Strategy

Guiding Principle

Avoid a deep fork of OpenEMR whenever possible.

Repository Structure

cnp-openemr/
├── docker/
├── modules/
│   └── foodrx/
├── config/
├── patches/
├── infra/
│   └── opentofu/
├── scripts/
└── docs/

Upstream Strategy

Maintain:

Preferred workflow:

OpenEMR Upstream
        |
        v
     CNP Fork
        |
        v
   Food RX Modules

Why Not a Deep Fork

A large fork increases:

The goal is to remain close enough to upstream that security and platform updates can be adopted with minimal effort.

Estimated AWS Cost

Always-On Deployment

Resource Monthly Cost
t4g.medium ~$25
EBS 100 GB ~$8
S3 Backups ~$2-3
Public IPv4 ~$4
Total ~$39/month
Resource Monthly Cost
t4g.large ~$49
EBS 100 GB ~$8
S3 Backups ~$2-3
Public IPv4 ~$4
Total ~$63/month

Night Shutdown Strategy

If the server is stopped approximately 12 hours each day:

Configuration Monthly Cost
t4g.medium ~$26
t4g.large ~$39

Storage costs remain unchanged.

Future Evolution

The architecture is intentionally optimized for simplicity.

Future scaling options include:

These enhancements should only be adopted when justified by user growth or operational requirements.

Until then, a single-server architecture remains the preferred deployment model.

Conclusion

The recommended CNP OpenEMR deployment is:

This architecture provides a HIPAA-capable, low-cost, highly portable platform suitable for small healthcare and nonprofit deployments while preserving long-term flexibility and minimizing vendor lock-in.

← Back to portal