The Fossible Stack — The Inherently AI-Native Digital Health Foundation

A complete, open-source stack where every layer is agent-addressable by design

---

Healthcare IT had a layering problem. With agents, it has a foundation problem.

Every health system CIO is now under pressure to do AI. But the agents being deployed today — for prior auth, claims processing, clinical documentation, patient triage, scheduling, RCM — are running on top of healthcare IT stacks that were never designed for them. Epic and Cerner expose narrow, gated APIs through expensive partner programs. Best-of-breed point solutions each speak their own dialect. Patient data sits in proprietary formats behind login walls. Operational data lives in a different universe from clinical data.

The result is the agent failure mode everyone is quietly running into: agents that hallucinate because they can't see the source of truth, can't take action because there's no authenticated tool surface, can't be audited because they leave no trail, and can't be trusted with anything that matters.

Agents don't need a chatbot. They need a foundation.

The Fossible Stack is that foundation. Every layer — engagement, operations, platform, clinical data, analytics — is open-source, FHIR-native, and exposes both a full REST API surface for developers and integrations and first-class MCP (Model Context Protocol) servers for agents. Through Hydra MCP for operations and ERP, and Medplum MCP for clinical data and FHIR, AI agents become first-class citizens of the stack. Not bolted-on observers. Native operators with structured, permissioned, auditable access to every layer.

One stack. No vendor lock-in. Full ownership of your data, your code, and your roadmap. And — because the stack was built API-first from day one — a single, unified surface that any agent, internal or third-party, can reason and act over without custom plumbing.

Why This Stack Is Inherently AI-Native

There's a difference between a stack that has had AI added to it and a stack that is inherently AI-native. The Fossible Stack is the second kind, and that's because of two architectural choices made long before the agent era arrived:

1. Every doctype, every resource, every workflow is exposed as a REST API by default. Frappe automatically generates a full RESTful API for every entity in the system. Medplum exposes the entire FHIR R4 resource tree as a standards-compliant API. There is no "API roadmap" — APIs are how the stack is built. Every operation a human can perform through a UI is already programmatically addressable.

2. Every API surface now has a corresponding MCP server. REST is the right protocol for developers writing integrations. MCP is the right protocol for agents calling tools. Both are needed. The Fossible Stack ships both — Hydra MCP for the operational stack, Medplum MCP for the clinical stack — so agents get discoverable, self-describing, scoped, auditable tools without anyone needing to write custom wrappers.

The combination is what makes the stack inherently AI-native. REST without MCP means every team building an agent has to write their own tool layer over your APIs, with their own auth, their own scoping, their own validation. MCP without solid REST APIs underneath is a thin facade that breaks the moment an agent does something the wrapper didn't anticipate. REST + MCP together means agents and humans operate on the same system of record, through the same RBAC, the same workflows, and the same audit trail — they just enter through different doors.

This is what people mean when they say agent-native infrastructure. Not "we have a chatbot." A stack where the data model, the permission model, the workflow engine, and the API surface were all designed with the assumption that any operator — human or agent — should be able to do everything.

Hydra MCP — The Operational Brain for Agents

Hydra MCP is the agent surface for everything operational in the Fossible Stack. It exposes the entire CareOps and ERP layer — every doctype in Frappe, every workflow, every report — as a structured, permissioned, auditable tool surface for agents.

What Hydra MCP exposes:

• Patient operations — registration, demographics, appointment scheduling, check-in, encounter creation
• Clinical orders — lab orders, radiology orders, prescription orders, with the full LIS/RIS/PMS workflow behind them
• Billing & RCM — invoice generation, claims submission, payment posting, denial management
• Inventory & supply chain — stock queries, procurement, transfers, expiry management
• ERP transactions — accounting entries, payroll runs, vendor management, asset tracking
• Workflow execution — submitting documents through approval chains, advancing state machines, triggering notifications
• Reporting — every Frappe report, dashboard, and KPI exposed as a queryable tool
• Custom doctypes — anything your team builds in Frappe's low-code layer is automatically MCP-addressable

Why this is different from "an API on top of ERPNext": every action an agent takes through Hydra MCP flows through the same RBAC, workflow engine, and audit log as a human action. An agent registering a patient triggers the same validations and notifications as a front-desk clerk. An agent submitting a claim goes through the same multi-level approval chain. There is no parallel "agent backdoor" — there is one system of record, and agents are participants in it like any other operator. This is what makes Hydra MCP safe enough to put in front of real clinical operations.

Medplum MCP — The Clinical Brain for Agents

Medplum MCP is the agent surface for everything clinical in the Fossible Stack. Where Hydra MCP handles the operations of running a healthcare business, Medplum MCP handles the structured clinical record — patients, encounters, observations, conditions, medications, documents, and the full FHIR R4 resource tree.

What Medplum MCP exposes:

• FHIR resource CRUD — Patient, Encounter, Observation, Condition, MedicationRequest, DiagnosticReport, AllergyIntolerance, and the full R4 resource set
• FHIR search — agents run structured queries across the clinical record using FHIR's native query language
• Composition & document generation — agents assemble FHIR Composition resources for clinical summaries, discharge documents, and ABDM-compliant exports
• Terminology services — agents resolve and validate codes against ICD-10, SNOMED-CT, LOINC, and custom code systems
• SMART on FHIR scopes — every agent call is scope-checked against the patient's consent and the agent's authorization context
• Bundles & batch operations — atomic multi-resource operations with transactional integrity preserved
• Subscriptions & event hooks — agents listen for clinical events (new lab result, new diagnosis, discharge) and act on them in real time

Why this is different from "calling FHIR endpoints": Medplum MCP isn't a thin wrapper over a FHIR server. It's an agent-aware clinical layer. Tools are described semantically — find_patient_by_demographics rather than GET /Patient?name=…&birthdate=…. Outputs are validated FHIR R4. Compliance scopes (HIPAA, ABDM, NABH) are enforced at the tool boundary, not left to the calling code. Every read and write is logged in a way that maps to regulatory audit requirements out of the box.

For agent builders, this collapses weeks of FHIR plumbing into a single MCP connection. For health systems, it means agents can be trusted with clinical reads and writes — because the compliance perimeter is enforced by the tool layer, not by the model.

The Combined Picture: What Agents Can Do With Both

The most interesting agent workflows in healthcare aren't purely operational or purely clinical — they're both. And this is where most existing AI deployments fail, because in a typical hospital, operations live in one system and clinical data in another, and the agent has to choose which half of the picture to operate on.

With Hydra MCP and Medplum MCP both exposed by a unified Fossible Stack deployment, an agent can reason and act across both halves at once.

Concrete example — patient calls about a billing dispute:

1. Identify the patient — Medplum MCP, find_patient_by_demographics
2. Pull the related encounter — Medplum MCP, get_encounter
3. Find the corresponding invoice — Hydra MCP, get_sales_invoice_by_encounter
4. Check insurance authorization status — Hydra MCP, get_workflow_state
5. Spot a missing diagnosis code that caused the claim denial — Medplum MCP, search_conditions
6. File a corrected claim — Hydra MCP, submit_corrected_claim (running through the same approval workflow a billing clerk would)
7. Document the patient interaction — Medplum MCP, create_composition (clinical-grade audit record, not a Slack note)
8. Audit trail — visible to compliance through both Frappe's audit log and Medplum's FHIR AuditEvent resources

This is the kind of workflow that requires an agent to hold both the operational and clinical contexts at once. It is structurally hard to build on Epic or Cerner, where operations and clinical data live in separate stacks with different ownership and different APIs. It is the default mode on the Fossible Stack, because both halves were designed to be a single fabric.

The architectural unity below the MCP surface is what makes the agents above it actually work.

The Stack at a Glance

The Fossible Stack is organized into five layers, each open-source, each connected to the layers above and below through standard APIs and event-driven integrations. Each layer is REST-addressable for developers and MCP-addressable for agents.

Layer	Function	Developer Surface	Agent Surface
1. Omni-Channel Engagement	Frappe CRM — leads, support, communication	REST + Webhooks	Hydra MCP
2. Practice Management & CareOps	PMS, LIS, RIS, ERP, Inventory, Billing	REST (every doctype)	Hydra MCP
3. Frappe Platform	Auth, workflow, APIs, reports, low-code	REST + Webhooks	Hydra MCP
4. Health Data Platform	Medplum FHIR R4, patient portals, interoperability	FHIR REST	Medplum MCP
5. Clinical Data Warehouse	Tuva Project on Redshift, analytics, AI/ML	SQL + REST	Analytics MCP (roadmap)

100% Open Source · API-First · MCP-Native · No Vendor Lock-In

Humans & Integrations

Meta / WhatsAppWebsite / ChatbotCalendly / TypeformDeveloper APIs

AI Agents

Internal Agents3rd-Party AgentsSMART on FHIR Apps

REST · FHIR · WebhooksMCP (Model Context Protocol)

Layer 1

REST + WebhooksHydra MCP

Omni-Channel Customer Engagement

Frappe CRMLead CaptureSupport & CommsPatient Funneling

Webhooks & APIs ↓

Layer 2

REST (every doctype)Hydra MCP

Practice Management & CareOps

PMSLIS (LOINC)RIS / DICOM / PACSERPNextInventoryBilling & RCMSuperset / InsightsAI Decision Support

Runs on ↓

Layer 3

REST + WebhooksHydra MCP

Frappe Platform Features

Auth / SSO / RBACWorkflow EngineREST APIsWebhooksLow-Code / DoctypesReports & DashboardsCron / Batch

Real-Time ETL (Kinesis + Redis) ↓

Layer 4

FHIR RESTMedplum MCP

Health Data Platform

Medplum FHIR R4 ServerPatient Portal AppsSMART on FHIRHL7v2 / CDATerminology ServerHIPAA / ABDM / NABH

Standardized FHIR Data ↓

Layer 5

SQL + RESTAnalytics MCP · roadmap

Clinical Data Warehouse & Analytics

Tuva ProjectRedshiftAI / ML ModelsDashboards & ReportingNotebooks (Jupyter)Population Health

100% Open Source · API-First · MCP-Native · No Vendor Lock-In

Layer 1: Omni-Channel Customer Engagement

Where every patient relationship begins.

Frappe CRM sits at the top of the stack as an omni-channel engagement platform. It captures inbound interest from Meta (WhatsApp Business and Messenger), website and chatbot widgets, and APIs/Calendly/Typeform for forms and scheduling. When a lead converts to a patient, the record hands off to the Practice Management layer below via webhooks and APIs — no manual data entry, no copy-paste, no dropped context.

REST surface: every CRM doctype (Lead, Opportunity, Contact, Communication) is queryable, writable, and webhookable. Agent surface (Hydra MCP): lead capture, contact lookup, communication history, automated follow-up, conversion to patient.

Layer 2: Practice Management & CareOps

One platform for clinical workflows, operations, and business.

This is the operational core — a Frappe-based single platform delivering everything most healthcare organizations buy as five separate products from five separate vendors:

• PMS — patient registration, scheduling, encounter documentation, clinical workflows, billing, and revenue cycle management
• LIS — LOINC-coded lab workflows, sample tracking, device integration, diagnostic reporting, multi-location capable
• RIS — DICOM and PACS integration, imaging order management, radiology reporting
• Inventory & ERP — full ERPNext-powered inventory, procurement, accounting, HR, payroll, asset management
• CareOps Analytics — Superset and Frappe Insights for real-time visibility into clinical volumes, revenue, inventory, and KPIs

External integrations: DICOM imaging systems, LIS/RIS device integrations, logistics providers, the Medplum Agent for HL7 device data, and AI-powered decision support.

REST surface: every doctype in every module is automatically a full REST resource. Agent surface (Hydra MCP): the complete operational toolset — patient ops, orders, billing, inventory, ERP transactions, workflow execution. This is the layer where agents do work.

Layer 3: Frappe Platform Features

The low-code engine that powers everything above — and the agent layer.

Every module in the CareOps layer runs on the Frappe Framework — a mature, battle-tested low-code platform that provides foundational capabilities most healthcare IT vendors charge extra for or don't offer at all:

• Auth / Authz / SSO — RBAC, document-level permissions, MFA, single sign-on
• Workflow Engine — visual designer for clinical and business processes; state transitions, conditions, approvals, alerts
• REST API / Integrations — every doctype exposes a full RESTful API automatically
• Notifications / Webhooks — email, push, SMS, Slack; outbound webhooks for real-time integration
• Reports / Excel / Print / PDFs — script reports, query reports, report builder, print designer
• Low-Code / Rapid Dev — custom doctypes, forms, dashboards in days, not months
• Cron / Batch Processing — scheduled tasks, background jobs, ETL, automated billing
• Module-Wise Dashboards — operational dashboards on every module, configurable, real-time

The platform layer is what makes the Fossible Stack extensible. You're not locked into a rigid product — you're building on a framework your own team can customize, extend, and maintain.

Agent surface (Hydra MCP): the platform primitives themselves are MCP tools. Agents can query workflows, run reports, trigger background jobs, and operate on custom doctypes the same way they operate on built-in ones. Anything your team builds in Frappe's low-code layer becomes MCP-addressable automatically.

Layer 4: Health Data Platform

Standardized, compliant, interoperable clinical data.

Above the operational layer, the Fossible Stack includes a standards-compliant health data platform for organizations that need FHIR interoperability, patient-facing applications, and regulatory compliance.

Medplum FHIR R4 Server is the core — an open-source FHIR server that serves as the canonical Standardized Clinical Data Repository. Clinical data from the CareOps layer flows into Medplum via real-time ETL (Amazon Kinesis + Redis), giving you a standards-compliant representation of every patient, encounter, observation, and procedure as events happen, not in nightly batches.

The platform also supports patient portal applications, SMART on FHIR EHR apps, clinical data standards migration, healthcare compliance (HIPAA, ABDM, NABH), HL7v2 / CDA exchange, and a terminology server for ICD-10, SNOMED-CT, LOINC, and custom code systems.

REST surface: the full FHIR R4 RESTful API. Agent surface (Medplum MCP): the entire clinical resource tree as semantic tools, with SMART scopes, terminology validation, and FHIR AuditEvent generation enforced at the tool boundary.

Layer 5: Clinical Data Warehouse & Analytics

AI-ready analytics on standardized clinical data.

The bottom layer is where clinical data becomes actionable intelligence. Tuva Project is an open-source clinical data warehouse purpose-built for healthcare analytics and AI. It takes standardized FHIR data from Medplum and transforms it into analytics-ready datasets — pre-built data models for claims, clinical events, quality measures, and population health.

Analytics infrastructure includes Redshift (or any columnar analytics database), operational and clinical dashboards, AI-powered decision support that feeds recommendations back into the practice management layer, and Jupyter notebooks for data science teams to build custom models, run cohort analyses, and develop predictive analytics.

This is where AI becomes practical, not theoretical. With standardized, longitudinal patient data in a queryable warehouse, you can build risk stratification, readmission prediction, clinical outcome analytics, operational forecasting, and population health dashboards.

REST surface: SQL and REST query interfaces. Agent surface (roadmap): an analytics MCP for natural-language queries against the warehouse, with the same auditability and scoping as the operational and clinical layers.

The Open-Source Advantage

Every layer is built on open-source foundations. Not for ideological reasons — for practical ones.

You own everything. Code, data, deployment. No vendor can revoke your access, raise your subscription, or sunset a feature you depend on.

No per-user licensing. Frappe, ERPNext, Medplum, Tuva, Superset — all GPL or Apache. Scale to 10,000 users without a license negotiation.

Full API surface — and full MCP surface. Integration isn't a premium feature. Agent-readiness isn't a premium feature. Both are how the stack is built.

Host anywhere. Cloud, on-premise, hybrid, air-gapped. Your infrastructure, your rules.

Community-backed, enterprise-ready. Frappe has 50,000+ community members. ERPNext runs in 10,000+ organizations across 140+ countries. Medplum is backed by a growing FHIR ecosystem. You're not betting on a single vendor's roadmap.

Low-code extensibility, agent-extensible by default. Anything your team builds in Frappe's low-code layer is automatically REST-addressable and MCP-addressable. Custom doctypes become custom agent tools without writing a wrapper.

Who the Fossible Stack Is For

• Multi-site hospital groups that need a unified, agent-ready platform across locations
• Diagnostic lab chains running high-volume LIS workflows with device integration and cross-location analytics
• Specialty and multi-specialty clinics that need configurable clinical workflows per department, with AI assistance built in
• Health-tech startups building care delivery platforms that need clinical + operational backbone and an agent foundation on day one
• Government and public health programs that require open-source, standards-compliant, locally hostable, AI-ready infrastructure
• AI-native healthcare service companies building agent-driven offerings — claims, prior auth, RCM, care coordination — that need a real system of record underneath
• Organizations pursuing ABDM, HIPAA, or NABH compliance that need FHIR-native architecture, not retrofitted compliance

Ready to Deploy the Stack?

The Fossible Stack is deployed and managed through Espresso Cloud — our enterprise CI/CD and managed infrastructure platform. We handle the DevOps, monitoring, scaling, and SLAs so your team focuses on clinical outcomes, agent development, and product.

Book a Demo →Try Live Demo →View on GitHub →

---

The Fossible Stack is built and maintained by Fossible Works Inc. For technical documentation, deployment guides, and architecture deep-dives, visit our solutions page.