Technical Proposal: OpenEMR as a Controlled Path Forward for CNP

Audience: Peter, third-party technical reviewer
Purpose: Present the technical case for OpenEMR while making the risks, obligations, and validation gates explicit.
Status: Draft for review
Date: 2026-06-09

Position

OpenEMR should be evaluated as CNP’s preferred baseline, not because it is easy and not because it eliminates engineering work. It should be evaluated because the hard engineering work exists under every option, and OpenEMR gives CNP the most direct control over data, workflow, auditability, and medical interoperability.

This is not a leap-of-faith infrastructure proposal and not a claim that OpenEMR is a panacea. It is a controlled path forward if CNP accepts the operating responsibilities that come with owning a self-hosted or contractor-managed platform.

The core technical judgment is:

A case-management SaaS reduces some infrastructure burden, but it does not remove the need for stateful integration, privacy segmentation, reconciliation, observability, recovery, and controlled data movement. OpenEMR puts those unavoidable responsibilities around a platform CNP can inspect, configure, extend, back up, and export.

System Boundary

CNP’s future operating system must support at least these domains:

• Participant intake and identity matching.
• FindHelp referral ingestion and reconciliation.
• Food-as-Medicine intervention records.
• Delivery partner coordination.
• Red/Green/White data segmentation.
• Consent and opt-in management.
• Behavior-change messaging and participant responses.
• Outcomes tracking.
• Reporting for operations, grants, and funders.
• Audit logs and error handling.
• AI-assisted staff workflows, only where privacy controls permit.

The important point is that these requirements are not eliminated by choosing CaseWorthy, ALLCO, or any other SaaS product. The same integration and control plane still exists. The difference is whether the control plane is built against an open, medically oriented platform or against vendor-owned abstractions and API limits.

Competitive Technical View

Why OpenEMR Is Technically Reasonable

OpenEMR provides primitives that align with CNP’s likely long-term architecture:

• Structured participant records.
• Appointments for scheduling/delivery.
• Encounters or forms for check-ins and intervention touchpoints.
• Orders/procedure-like structures for food-box fulfillment.
• Prescription-like structures for meal-plan instructions.
• Documents for intake, consents, and uploaded records.
• Billing/fee-sheet concepts for grant or reimbursement mapping.
• Role-based access controls and sensitivity concepts.
• FHIR/health-data interoperability surfaces.
• Direct data access for exports, reconciliation, reporting, and backup.

The strongest technical reason to prefer OpenEMR is that CNP’s Food-as-Medicine work is closer to care delivery than generic social-service case notes. If the program needs to become more interoperable with medical services, referrals, health plans, and CMS-adjacent reporting, it is better to start from a medical-record baseline than to retrofit medical semantics into a case-management SaaS.

What OpenEMR Does Not Solve

OpenEMR does not remove the following work:

• Production hosting design.
• Security hardening.
• Patch and upgrade procedures.
• Backup and restore testing.
• Monitoring and alerting.
• Access reviews.
• Audit-log review.
• FindHelp ingestion.
• Delivery partner synchronization.
• Red/Green/White export rules.
• Behavior-change messaging.
• AI workflow guardrails.
• Staff training and support.

These are required work items, not optional enhancements. The proposal is viable only if they are explicitly planned.

Operating Model

The OpenEMR path should be treated as a small production platform, not as a collection of scripts.

Minimum operating expectations:

• Version baseline: Evaluate and deploy against OpenEMR 8, not the older 7.x local evaluation baseline, because OpenEMR 8 is the current certification-relevant version and OpenEMR 7.x certification retired on February 27, 2026.
• Hosting: Run in a supported environment with documented ownership, access controls, TLS, backups, and monitoring.
• Backups: Automated database and file backups with defined retention.
• Restore tests: Scheduled restore tests, not just backup job success.
• Patching: Documented patch cadence for OS/container/runtime/OpenEMR updates.
• Secrets: No credentials in code or shared documents; use a managed secret store or equivalent operational control.
• Auditability: Retain logs for user access, record changes, integration jobs, errors, retries, exports, and administrative actions.
• Runbooks: Document common failures and recovery steps.
• Change control: Track configuration changes, custom forms, custom modules, and integration behavior.

Red/Green/White Segmentation

The privacy model remains central under any platform.

• Red: PHI and clinical context. Examples: diagnoses, medical eligibility basis, medications, lab values, clinical notes, treatment rationale.
• Green: Operational PII without clinical rationale. Examples: participant name, address, phone, delivery schedule, program status, opt-in state.
• White: De-identified or aggregate data. Examples: counts, trends, test datasets, funder dashboards without participant identity.

With OpenEMR, the first validation task is to prove that access controls and exports can enforce this boundary. That means testing:

• Clinical user sees Red data.
• Operations user sees only Green data needed for delivery and coordination.
• Reporting user sees only aggregate or de-identified outputs.
• API access follows the same permissions.
• Reports do not leak clinical context.
• Appointment notes, delivery notes, and custom fields do not become accidental PHI leakage paths.

If those tests fail and cannot be remediated cleanly, OpenEMR should not proceed to production.

Integration Architecture

The integration layer should be treated as stateful and observable from the start.

Expected state includes:

• External referral IDs.
• Participant match decisions.
• Merge/reject/needs-review decisions.
• Delivery partner export batches.
• Delivery status imports.
• Message consent and opt-out state.
• Outbound message IDs.
• Retry attempts.
• Failed job reasons.
• Reconciliation results.

Each integration should have:

• Idempotency keys or equivalent duplicate protection.
• Structured logs.
• Job status records.
• Error queues or review queues.
• Retry and backoff policy.
• Manual reconciliation process.
• Export history.
• PHI classification for each field.

This same statefulness is required even with a SaaS case-management platform. Choosing SaaS does not eliminate it; it only changes where the source data comes from and which API constraints apply.

Behavior-Change and AI Workflows

Behavior-change programs should be modeled as opt-in workflows with explicit consent, staff oversight, message history, participant responses, and outcome tracking.

AI assistance should be treated as an operator-assist feature, not an autonomous clinical decision-maker. Initial safe use cases may include:

• Drafting outreach messages for staff approval.
• Summarizing recent operational history.
• Flagging missing intake fields.
• Suggesting follow-up categories.
• Preparing call notes from structured templates.

The system should prevent PHI from flowing into any AI service unless the service, contract, configuration, and workflow are approved for that data class. This needs to be enforced at the workflow and integration layer, not left to staff memory.

Primary Risks

Proof-of-Fit Gates

OpenEMR should only move forward if it passes practical gates.

Gate 1: Workflow Fit

• Build CNP intake fields.
• Create a participant.
• Record program enrollment.
• Create a food-box or meal-plan order.
• Schedule a delivery.
• Record a delivery outcome.
• Record a behavior-change opt-in.
• Record at least one outcome measure.

Gate 2: Privacy Boundary

• Configure Red, Green, and White roles.
• Verify role behavior in UI.
• Verify role behavior through API access.
• Test reports and exports for leakage.
• Confirm audit logs capture meaningful activity.

Gate 3: Integration State

• Import one FindHelp-style referral payload.
• Match or create a participant.
• Export a delivery batch.
• Import a delivery result.
• Produce a reconciliation report.
• Show failure handling for duplicate, missing, or invalid data.

Gate 4: Operations

• Create backup procedure.
• Restore to a test environment.
• Demonstrate log access.
• Demonstrate patch plan.
• Demonstrate user disable/access review process.
• Document incident response owner.

Gate 5: Executive Usability

• Demo the workflow to Kristie and operations staff.
• Confirm the model is understandable.
• Confirm staff do not need technical staff for normal daily work.
• Identify confusing language before production.

SaaS Reconsideration Criteria

CNP should reconsider a SaaS provider if the provider can prove:

• Working CNP-specific intake in the product.
• FindHelp integration with clear data flow and duplicate handling.
• Delivery partner integration or practical export/import workflow.
• API documentation and test credentials.
• Data export rights and sample exports.
• Red/Green/White-compatible role and export behavior.
• Behavior-change workflow extensibility.
• Total cost including implementation, messaging, forms, reporting, support, AI features, and data access.
• Security and compliance roadmap, including current stack support.
• A timeline measured in weeks, not an 18-month backlog.

Technical Recommendation

Proceed with an OpenEMR 8 proof-of-fit under explicit gates.

The recommendation is conditional, not blind:

• If OpenEMR passes workflow, privacy, integration, operations, and usability gates, it is the reasonable path forward.
• If OpenEMR cannot enforce Red/Green/White boundaries or cannot support CNP’s core workflows without brittle customization, stop and revisit SaaS options.
• If a SaaS provider can prove the same workflows faster, with clearer operating risk and acceptable data rights, it should remain eligible.

The current evidence favors OpenEMR because CNP’s hard requirements are medically adjacent, integration-heavy, and likely to evolve faster than a SaaS vendor roadmap. OpenEMR does not remove responsibility. It makes the responsibility inspectable and controllable.

Sources and Current Project Context

• CNP OpenEMR evaluation: docs/OpenEMR-Evaluation-Plan.md
• ALLCO vs OpenEMR decision matrix: docs/vendor-analysis/allco-vs-openemr-decision-matrix.md
• CNP Red/Green/White architecture: docs/DataArchitecture-Plans.md
• Food-as-Medicine outcome measures: docs/FIM-Outcome-Measurement-Best-Practices.md
• CaseWorthy and FindHelp integration notes: docs/caseworthy/README.md
• OpenEMR 8.0.0 certification and download page: https://www.open-emr.org/wiki/index.php/OpenEMR_Downloads
• OpenEMR 8.0.0 ONC certification requirements: https://www.open-emr.org/wiki/index.php/OpenEMR_8.0.0_ONC_Ambulatory_EHR_Certification_Requirements
• OpenEMR 7.0 certification retirement note: https://www.open-emr.org/wiki/index.php/OpenEMR_7.0.0_ONC_Ambulatory_EHR_Certification_Requirements