Infrastructure - Business Plan
Business Proposal: OpenEMR as CNP’s Food-as-Medicine Operating Platform
Audience: Kristie, Executive Director
Purpose: Compare OpenEMR, CaseWorthy, and ALLCO at the
business-decision level, focused on feature fit, risks, and
control.
Status: Draft for discussion
Date: 2026-06-09
Executive Summary
CNP is not simply choosing a case-management product. CNP is choosing the operating platform for a Food-as-Medicine program that must coordinate referrals, food interventions, delivery partners, participant engagement, outcomes, reporting, and future AI-assisted workflows.
The recommendation is to treat OpenEMR as the preferred baseline unless a third-party vendor can quickly prove that it can deliver CNP’s actual workflow with lower total risk.
This is not a recommendation to “build everything from scratch.” It is a recommendation to start from a medical-record platform that CNP can control and adapt, rather than waiting behind a vendor roadmap for core program features. CNP will need integration work under any option. The question is whether that work happens around a platform CNP can shape, or around a vendor system that may limit CNP’s pace, data access, and future program design.
The Business Decision
The practical decision is:
Does CNP want to operate Food-as-Medicine as a medically legible intervention program, or as a social-service case file with custom fields and external glue?
If CNP’s long-term direction is medically connected Food-as-Medicine, OpenEMR is the stronger fit. It gives CNP a clinical baseline for participants, orders, prescriptions, appointments, encounters, documents, billing concepts, access control, and interoperability.
If CNP’s dominant need is participation in a social-care referral network, 211 directory workflows, and vendor-managed case-management operations, then a SaaS case-management product such as ALLCO may be stronger.
CaseWorthy is currently difficult to recommend as the baseline because the implementation experience produced no usable intake output after roughly ten weeks of effort and professional services involvement.
Feature and Risk Comparison
| Area | OpenEMR | CaseWorthy | ALLCO |
|---|---|---|---|
| Food-as-Medicine fit | Strong medical baseline; can model food boxes, meal plans, devices, adherence, and outcomes as treatment-like records | Configurable case-management model, but CNP already saw poor implementation progress | Strong social-care platform, but food delivery appears to require custom workflow configuration |
| Referral network fit | Needs integration with FindHelp or other referral sources | Has documented FindHelp integration path, but implementation progress has been poor | Stronger fit for 211-style and closed-loop social-care referrals |
| Delivery scheduling | Appointments/calendar can be adapted to delivery operations | Would require configured workflows | Not clearly native for food-box delivery |
| Behavior-change programs | Can be built into CNP-owned workflows and records | Likely requires vendor configuration plus external messaging glue | May have communications features, but novel AI/behavior workflows may require vendor roadmap or add-ons |
| Medical interoperability | Native EHR interoperability direction: FHIR/API, clinical documents, and HL7-oriented lab/results workflows | Case-management integration would need to bridge into medical systems separately | Claims FHIR capability, but implementation details need proof |
| Data ownership | CNP owns database and export paths | Vendor-hosted; export/API terms must be confirmed | Vendor-hosted; export/API terms must be confirmed |
| Customization control | High; CNP can drive changes with qualified technical help | Low to medium; depends on vendor/pro-services capacity | Medium; configurable but vendor platform constraints remain |
| Vendor backlog risk | Low for CNP-specific changes; CNP owns roadmap | High based on current experience | Unknown; must verify |
| Technical operations burden | CNP must own hosting, backups, upgrades, monitoring, and support | Vendor handles core hosting | Vendor handles core hosting |
| Certification-readiness | Stronger medical baseline if deployed on OpenEMR 8 | Social-services/case-management baseline | Social-services/case-management baseline |
| Known concern | Requires technical ownership and careful workflow design | Ten weeks with no positive intake output | Apparent aging stack risk; needs vendor verification |
Why OpenEMR Is the Recommended Baseline
OpenEMR fits the shape of CNP’s program because it starts with medical concepts rather than generic case-management concepts.
CNP can map its work into durable records:
- Participants become patient records.
- Food boxes and medically tailored groceries become orderable interventions.
- Meal plans become prescription-like instructions.
- Food preparation devices can be tracked with related consumables.
- Deliveries become appointments or fulfillment events.
- Wellness checks become encounters or structured forms.
- Adherence, food security, diet quality, self-efficacy, and satisfaction become outcomes.
That matters because CNP’s future is likely to involve deeper relationships with care organizations, health plans, funders, and possibly CMS-adjacent reporting. The system should help CNP speak that language from the beginning.
OpenEMR also gives CNP more control over program innovation. Behavior-change programs, opt-in participant messaging, positive reinforcement, AI-assisted staff workflows, and delivery partner integration can be added as CNP-owned capabilities rather than waiting for a SaaS vendor to add them to a package.
Medical Interoperability: Opening Doors with Clinical Partners
OpenEMR also gives CNP a stronger basis for conversations with medical partners because it is already an electronic medical record system, not a social-services case-management system trying to bridge into medicine after the fact.
This matters for business development. When CNP talks with health systems, clinics, referral partners, payers, or CMS-adjacent programs, the question will not only be “Can you manage clients?” It will be “Can your system exchange medically meaningful information in recognizable healthcare formats?”
OpenEMR has native healthcare interoperability apparatus, including:
- FHIR/API support for modern healthcare data exchange.
- Clinical document support such as CCDA/CCD-style summary documents.
- HL7-oriented workflows, especially around lab/results-style clinical exchange.
- Existing EHR concepts for patients, encounters, orders, procedures, prescriptions, documents, and billing.
There is still integration work. Each medical partner will have its own requirements, security review, data-sharing agreement, interface expectations, testing process, and workflow constraints. OpenEMR does not make those conversations automatic.
The difference is the starting point. With OpenEMR, CNP is adapting an EHR that already speaks the language of healthcare interoperability. With a case-management SaaS, CNP would likely need to create an ETL or integration bridge between a social-services data model and medical systems. That bridge may work, but it becomes another translation layer to build, secure, audit, and maintain.
For CNP, this is strategically important. Food-as-Medicine is most valuable when it can participate in medical referral, treatment, outcome, and reimbursement conversations. OpenEMR gives CNP a more credible foundation for those conversations than a generic case-management record.
Why This Is Not a Panacea
OpenEMR is not a turnkey case-management solution. It does not remove the need for technical work.
CNP would still need:
- Configuration and workflow design.
- Staff training.
- FindHelp integration.
- Delivery partner data exchange.
- Red/Green/White privacy segmentation.
- Messaging and behavior-change workflows.
- Backups, restore testing, monitoring, and support.
- Clear policies for access control, audit logs, data retention, and incident response.
The business argument is not that OpenEMR avoids all complexity. The business argument is that the complexity is unavoidable, and OpenEMR gives CNP a better baseline for owning it.
Vendor Risks
CaseWorthy
CaseWorthy has relevant social-services features and documented FindHelp integration, but CNP’s actual experience is the key risk. Ten weeks of effort produced no usable intake progress, including failure to complete even one section of the intake form.
That is not just a schedule issue. It shows a control issue. CNP could not move the platform forward at the speed required for the program.
ALLCO
ALLCO appears stronger for New York social-care coordination, closed-loop referrals, and 211-style workflows. It may be a legitimate alternative if referrals and multi-agency coordination are the dominant need.
However, the current analysis identifies technology-age concerns: Vue 2 reached end of life in December 2023, and .NET Core 6 reached end of life in November 2024. If ALLCO is still materially dependent on those versions, CNP should ask for a clear security, modernization, and compliance roadmap before selecting it.
ALLCO also needs to prove pricing, API access, export rights, FindHelp behavior, delivery workflow fit, and total cost including messaging and future AI-related features.
Decision Standard
CNP should proceed with OpenEMR unless a vendor can demonstrate the following quickly and concretely:
- Working CNP intake flow.
- FindHelp integration approach.
- Delivery partner integration approach.
- Role-based privacy segmentation.
- Red/Green/White-aware exports.
- Open API documentation.
- CNP-owned data export rights.
- Behavior-change workflow extensibility.
- Clear total cost including implementation, messaging, forms, reporting, AI features, support, and data access.
- Evidence that CNP will not wait behind a long vendor backlog for core features.
Recommendation
Move forward with an OpenEMR 8 proof-of-fit as the primary path.
The proof should focus on business capability, not abstract infrastructure:
- Intake for CNP’s actual participant fields.
- Food-box or meal-plan ordering.
- Delivery scheduling.
- FindHelp-style referral import.
- Red/Green/White access roles.
- Basic FHIR/API or HL7-oriented interoperability demonstration.
- Behavior-change opt-in and outreach record.
- Basic outcome tracking.
- Export/reporting for operations and funders.
If OpenEMR can demonstrate these core workflows in a controlled proof, it becomes the reasonable path forward. If it cannot, CNP should return to the vendor market with a sharper checklist and demand proof before committing.
Bottom Line
A SaaS case-management system may reduce visible infrastructure burden, but it does not remove the program-design burden. CNP will still need integrations, privacy segmentation, data reconciliation, delivery workflows, behavior-change programs, and reporting.
OpenEMR is the better business bet if CNP wants control over its Food-as-Medicine model and is willing to support a small but real technical operating layer.
CNP Platform Overview
References
- OpenEMR API documentation: https://www.open-emr.org/wiki/index.php/OpenEMR_7.0.2_API
- OpenEMR walkthrough noting HL7 viewer capability: https://www.open-emr.org/wiki/index.php/OpenEMR_v6%2B_Walkthrough
- OpenEMR electronic results workflow using HL7 samples: https://www.open-emr.org/wiki/index.php/Incorporate_lab_tests_and_values_or_esults_%28MU2%29
- OpenEMR reference architecture showing an HL7 engine in the integration layer: https://www.open-emr.org/wiki/images/2/24/OpenEMR_Reference_Architecture.pdf