Decision Analysis

← CNP Portal · June 9, 2026

Decision Analysis

OpenEMR Decision Memo for CNP

Audience: Kristie, Executive Director; Peter, third-party technical auditor Purpose: Provide a clear decision frame for selecting CNP’s next operating platform after the CaseWorthy implementation failed to produce usable output.
Status: Draft for discussion
Date: 2026-06-09

Executive Summary

CNP is not deciding between “custom build” and “buy software.” The unavoidable work is broader than case management. CNP needs a system that can support Food-as-Medicine operations, FindHelp intake and referral data, delivery partner coordination, Red/Green/White privacy segmentation, stateful integration workflows, behavior-change programs, auditability, reporting, and future AI-assisted operations.

Those requirements exist under every platform option. A third-party case management system may provide a hosted user interface and some social-care workflows, but it does not eliminate the integration layer. It can also introduce new risks: vendor backlog, licensing costs, opaque APIs, limited customization, and dependence on the vendor’s product roadmap.

The working recommendation is:

CNP should favor OpenEMR as the primary platform baseline if CNP is willing to own a lightweight but real technical operating layer, supported by qualified contractors or technical staff. OpenEMR better matches the long-term shape of a medically legible Food-as-Medicine program. A third-party case-management SaaS should remain under consideration only if a vendor can quickly prove working intake, FindHelp integration, open APIs, privacy segmentation, data export rights, behavior-program extensibility, and realistic total cost.

This recommendation is not based on novelty or a preference for open source. It is based on where the unavoidable complexity should live. With OpenEMR, CNP drives features into a system it controls. With a SaaS case-management provider, CNP waits behind the provider’s backlog and must still build the integration, data, and behavior-change layer around the vendor’s constraints.

1. Decision Premise

The central question is not: “Which case-management product has the most features?”

The central question is:

What baseline gives CNP the most durable operating system for a Food-as-Medicine program that must interact with care organizations, delivery partners, funders, participants, and future behavior-change workflows?

CNP’s program is medically adjacent by design. Food boxes, medically tailored groceries, food preparation devices, adherence tracking, diet quality, social needs, and outcomes measurement are not generic client-service notes. They are interventions. If CNP wants to grow into stronger clinical partnerships, referrals, CMS-adjacent reporting, health-plan relationships, or medical interoperability, the system should treat these interventions as first-class records.

That is the main reason OpenEMR is compelling. It already has medical concepts that can be adapted to CNP:

This mapping is not perfect, and it should not be hidden. OpenEMR is not a social-services case-management product. It will require configuration, workflow discipline, and some customization. But the conceptual direction is aligned: CNP is operating a treatment-like program, not merely logging services.

2. The Unavoidable Work

Several parts of the system are unavoidable regardless of whether CNP chooses OpenEMR, ALLCO, CaseWorthy, or another case-management SaaS.

First, FindHelp remains the likely conduit from and between care organizations. The CNP platform should consume FindHelp data, reduce double data entry, and maintain a clear record of what was received, accepted, rejected, merged, or acted on. FindHelp is not necessarily CNP’s operational system of record; it is a network and referral conduit.

Second, delivery partner coordination will require structured data movement. The delivery partner does not need all clinical context, but it does need correct participant, address, schedule, route, eligibility, fulfillment, and exception data. That requires privacy-aware extraction and synchronization.

Third, the Red/Green/White privacy model remains necessary under any platform:

If CNP chooses a case-management SaaS, the integration layer still has to enforce these boundaries. If CNP chooses OpenEMR, the boundary may be enforced more directly inside the system through roles, ACLs, sensitivity settings, and controlled exports. Either way, the work exists.

Fourth, the glue layer will be stateful. It will not be a simple one-time script. It will need to remember referral IDs, participant matches, delivery statuses, outbound messages, consent state, retry attempts, error states, and reconciliation results. Stateful systems require backups, reliability work, recovery procedures, monitoring, and audit logs. A SaaS case-management system does not remove this requirement if the glue is still needed around it.

Fifth, behavior-change programming will be a feature of whatever system CNP selects. Opt-in SMS, MMS, calls, app messages, surveys, positive reinforcement, nutrition education, food-choice nudges, self-efficacy tracking, and adherence measurement all need participant consent, message history, outcome tracking, and staff oversight. This is a core program capability, not an optional add-on.

Finally, AI-assisted operations are likely to matter. AI could help draft follow-up messages, summarize participant history, flag outreach risk, recommend next best actions, detect missing data, or assist operators during intake. These workflows are still novel. Many SaaS vendors are struggling to package AI features into mature service offerings, and when they do, those features may become additional monthly licensing costs on top of the base platform.

The practical conclusion: CNP should not assume a third-party case-management system makes the hard parts disappear. It may only move them behind a vendor API and vendor backlog.

3. Vendor Risk

The CaseWorthy experience is important evidence. Ten weeks of work, including substantial professional services involvement, produced no positive operational output, including failure to complete even one section of the intake form. That does not prove CaseWorthy is a bad product in general, but it is strong evidence that the vendor path can fail CNP in practice.

The specific failure mode matters:

That failure mode is directly relevant to future SaaS decisions. Third-party providers prioritize their platform roadmap, implementation queue, and customer base. CNP’s requested features may sit behind an 18-month backlog. Even when a platform advertises customization, the question is whether CNP can actually drive the work or whether it must wait for vendor professional services, vendor configuration, vendor APIs, and vendor release cycles.

ALLCO has a different risk profile. It appears more aligned with New York social-care coordination, 211-style referral workflows, and multi-agency community data sharing. Those are real strengths. But the current analysis flags an aging technical stack: 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, that may indicate disinvestment, deferred modernization, or future compliance and maintenance risk.

This should be verified with the vendor before being treated as a final conclusion. The right question is not “Is ALLCO bad?” The right question is:

Can ALLCO demonstrate a maintained, supported, security-conscious platform with a clear upgrade path, current API documentation, reliable data export, and pricing that includes the workflows CNP actually needs?

For any SaaS provider, CNP should require proof in days or weeks, not months:

4. Why OpenEMR Fits the Program Shape

OpenEMR fits CNP because it starts from a clinical operating model. That matters for a Food-as-Medicine organization that wants to be medically legible.

OpenEMR brings several useful primitives:

These capabilities do not solve the CNP problem by themselves. They create a baseline that CNP can shape.

The key advantage is control. With OpenEMR and qualified technical help, CNP can drive features into the platform:

OpenEMR also aligns better with certification-readiness than a generic case-management baseline. The current certification point must be stated carefully: OpenEMR 8.0.0 has ONC Ambulatory EHR Certification, while OpenEMR 7.x certification retired on February 27, 2026. Any certification-based plan should evaluate and deploy against OpenEMR 8, not the older local evaluation version.

Certification does not automatically make CNP compliant. CNP would still need appropriate policies, hosting controls, BAAs where required, security configuration, access reviews, audit procedures, and operational discipline. But starting from a certified EHR baseline is different from starting from a social-services case-management platform and then trying to glue medical interoperability around it.

The conceptual advantage is simple:

OpenEMR lets CNP treat food, devices, adherence, behavior-change, referrals, and outcomes as parts of a care record. A case-management SaaS may force CNP to treat the same things as custom service fields plus external glue.

5. Where OpenEMR Is Weak

OpenEMR is not a magic answer. The technical auditor should treat the following as real risks.

First, OpenEMR is not purpose-built for social-care case management. It will not naturally provide the same 211 directory workflows, cross-agency closed-loop referrals, or social-services UX that a community information exchange platform may provide.

Second, the user interface may feel clinical. Staff training and careful language changes will matter. If the system feels like a doctor’s office record instead of CNP’s operating platform, adoption will suffer.

Third, OpenEMR requires technical ownership. Someone must handle hosting, upgrades, backups, restore testing, security patches, monitoring, user access, SSL, database maintenance, and incident response. This can be done by a qualified contractor, but it cannot be hand-waved away.

Fourth, integrations still need engineering. FindHelp ingestion, delivery partner sync, messaging, Red/Green/White exports, AI-assisted workflows, and reporting will need design and implementation. OpenEMR gives CNP more control over that work; it does not eliminate the work.

Fifth, CNP must avoid careless semantic mapping. If “prescription” or “procedure order” language creates confusion, legal risk, or clinical governance issues, the implementation should use safer labels and workflow boundaries. The point is to reuse durable medical-management structures, not pretend CNP is practicing medicine beyond its authorized role.

Sixth, certification and compliance are not the same thing. OpenEMR 8 may provide a certified baseline, but CNP’s actual environment must still be configured, operated, and documented correctly. The auditor should specifically review backup/restore procedures, access controls, audit logs, encryption, hosting architecture, disaster recovery, vendor BAAs, and data-retention policy.

These weaknesses do not defeat the OpenEMR path. They define the operating requirements for doing it responsibly.

6. Recommendation

CNP should proceed with OpenEMR as the preferred baseline unless a third-party provider can rapidly prove that it solves CNP’s actual workflow better with lower total risk.

The recommended decision standard is:

Choose OpenEMR if CNP accepts that it must own a small but real technical operating layer. Choose a SaaS case-management provider only if the provider proves, concretely and quickly, that it can deliver CNP’s intake, FindHelp, delivery, privacy segmentation, data export, behavior-change, and reporting requirements without trapping CNP behind a roadmap or professional-services queue.

For Kristie, the executive decision is about control, cost, and program direction:

For the technical auditor, the review should focus on whether the OpenEMR path can be operated safely:

The strongest reason to choose OpenEMR is not that it is free. It is that CNP’s hardest requirements are not generic case-management requirements. They are medically adjacent operating-system requirements. If CNP selects a platform that cannot naturally express those requirements, it will still need to build the hard parts, but with less control.

Suggested Next Steps

  1. Run an OpenEMR 8 proof-of-fit, not OpenEMR 7. The proof should include intake, food-box ordering, delivery scheduling, Red/Green/White roles, and one FindHelp-style referral import.

  2. Create a one-page vendor proof checklist. Any SaaS alternative must show working intake, API access, FindHelp strategy, privacy segmentation, export rights, and total cost before serious consideration.

  3. Ask the auditor to review operations, not just software features. The key risks are backups, recovery, patching, access control, auditability, and failure handling.

  4. Prototype behavior-change as a first-class workflow. Include consent, message history, staff review, participant response, and outcome tracking from the beginning.

  5. Document the semantic mapping. Decide what CNP calls a food intervention, a device, a delivery, an adherence event, and an outcome. Do not rely on informal translation.

  6. Keep FindHelp in its proper role. Treat it as a referral and network conduit. CNP’s internal system should consume and reconcile FindHelp data while remaining the operational source of truth for CNP-specific intervention delivery.

Sources and Current Project Context

← Back to CNP Portal