Architecture

The shape of the system

JamEMR is deployed as a set of cooperating services inside the practice’s deployment environment. This page describes the architecture at the level a practice administrator or technical evaluator needs; deeper detail is covered during pilot scoping.

+--------------------------------------------------------------+
|                Practice deployment environment                |
|                                                                |
|  +----------------+      +----------------+                   |
|  | Web application| <--> |  API backend   |                   |
|  | (clinician UI) |      | (auth, RBAC,   |                   |
|  +----------------+      |  audit logging)|                   |
|                          +-------+--------+                   |
|                                  |                             |
|              +-------------------+------------------+          |
|              |                                      |          |
|      +-------v--------+                   +---------v-------+  |
|      | Clinical       |                   | Local AI        |  |
|      | database       |                   | inference tier  |  |
|      | (versioned     |                   | (dedicated GPU  |  |
|      |  migrations)   |                   |  hardware)      |  |
|      +----------------+                   +-----------------+  |
|                                                                |
|          PHI is processed and stored inside this boundary      |
+--------------------------------------------------------------+

The four tiers

• Web application. The clinician- and staff-facing interface for charting, encounters, and scheduling. It talks only to the API backend.
• API backend. The single gateway to clinical data. It enforces authentication, role-based access control, and API token validation, and writes the audit log. Nothing reads or writes the clinical database except through it.
• Clinical database. The system of record for charts, encounters, and documents. Schema changes are applied only through versioned database migrations, so every deployment’s schema state is known, repeatable, and reviewable.
• Local AI inference tier. Ambient documentation, document intelligence, and the clinical assistant run on dedicated GPU hardware inside the deployment environment. Protected health information stays within the practice’s environment for AI processing — it is not sent to third-party consumer AI services.

Design principles

1. One boundary for PHI. Clinical data lives and is processed inside the deployment environment. That boundary is the architecture’s first commitment.
2. One path to data. All access flows through the API backend, where RBAC and audit logging apply uniformly.
3. Known state, always. Versioned migrations and role-based configuration mean a deployment can be reasoned about, audited, and upgraded predictably.

For access control, tokens, and audit specifics, see the Security Model and the Trust Center.