Core EHR Definition — Module Bundling & Licensing
Scope: Defines which modules are always-on (Core EHR) vs optional licensed add-ons.
Authority: Normative for module activation and licensing behavior.
1. Principle
- The product is modular, but a deployable EHR ships with a Core EHR baseline that is always enabled.
- Optional modules are additive — enabled/disabled per license assigned to HierarchyNodes.
- Even Core modules support RBAC/ABAC, auditing, and tenant/facility configuration.
2. Core EHR Baseline (Always-On)
2.1 Core Clinical Workflow
| Module | Service | Spec |
|---|---|---|
| Patient Registration | registration | specs/modules/registration/SPEC.md |
| Scheduling | scheduling | specs/modules/scheduling/SPEC.md |
| Provider Directory | provider-directory | specs/modules/provider-directory/SPEC.md |
| Facility Management | facility | specs/modules/facility-management/SPEC.md |
| Patient Chart | patient-chart-service | specs/modules/patient-chart/SPEC.md |
| Clinical Notes | clinical-notes | specs/modules/clinical-notes/SPEC.md |
| Orders / CPOE | orders | specs/modules/orders-cpoe/SPEC.md |
| Results | results | specs/modules/results/SPEC.md |
| Medication Management | medication | specs/modules/medication-management/SPEC.md |
| Allergies | allergies | specs/modules/allergies/SPEC.md |
| Vitals | vitals | specs/modules/vitals/SPEC.md |
| Problem List | problem-list | specs/modules/problem-list/SPEC.md |
2.2 Core Platform Foundation
| Module | Service | Spec |
|---|---|---|
| IAM | iam | specs/modules/iam/SPEC.md |
| Access Policy | access-policy | specs/modules/access-policy/SPEC.md |
| Tenant Management | tenant | specs/modules/tenant/SPEC.md |
| Hierarchy | hierarchy | specs/modules/hierarchy/SPEC.md |
| Licensing | licensing | specs/modules/licensing/SPEC.md |
| Audit | audit | specs/modules/audit/SPEC.md |
| Terminology | terminology | specs/modules/terminology/SPEC.md |
| Platform Admin | platform-admin | specs/modules/platform-admin/SPEC.md |
3. Optional Licensed Add-Ons
| Category | Module | Service | Module Code |
|---|---|---|---|
| Diagnostic | Laboratory / LIS | laboratory-lis | diag.laboratory |
| Diagnostic | Radiology / PACS | radiology-pacs | diag.radiology |
| Engagement | Patient Portal | patient-portal-api | engage.patient-portal |
| Engagement | Messaging | messaging | engage.messaging |
| Financial | Billing | billing | billing.rcm |
| Financial | Insurance | insurance | billing.insurance |
| Financial | Claims | claims | billing.claims |
| Clinical | Immunizations | immunizations | clinical.immunizations |
| Clinical | Care Plans | care-plans-service | clinical.care-plans |
4. Module Dependencies
- Patient Portal ← Scheduling (appointment requests), Messaging (patient communications)
- Messaging can operate standalone for provider-to-provider; patient messaging requires Patient Portal
- Laboratory/LIS ← Orders/CPOE (work items); → Results (lab observations/reports)
- Radiology/PACS ← Orders/CPOE (imaging orders); → Results + Patient Chart (reports/links)
- Billing/Insurance/Claims ← Registration (encounters), Orders (charges)
5. Licensing Behavior
- Managed by Licensing Service — licenses assigned to HierarchyNodes (not flat tenants).
- Core modules seeded as
always-onon root node at tenant activation. - Add-ons require explicit
inherit-downorexactlicense assignment. - Runtime:
GET /internal/licensing/effective?nodeId=X— services returnMODULE_NOT_ACTIVE(422) for unlicensed access. - UI hides nav entries for unlicensed modules.
- Deactivation rules: preserve data per retention policy; block deactivation that would break safety workflows.
6. Product baseline
The shipped repository (default branch) defines the current product. Capability gaps versus module specs are tracked in SERVICE_BASELINE_AUDIT_TRACKER.md and per-module TRACEABILITY_MATRIX.md — not in a separate phased roadmap document.