Investor brief · MuleSoft integration
Pause-Health.ai's integration with JupyterHealth, DBDP wearable features, Agentforce, and consumer wearables runs through MuleSoft Anypoint — the connectivity platform most US health systems and large payers already license.
API-Led Connectivity, applied to menopause
Wrap each upstream once
Per-vendor adapters that own OAuth, rate limits, retry, and circuit-breaker behavior. One System API per wearable (Oura, Apple Health, Whoop, Empatica) plus one each for JupyterHealth Exchange and the DBDP feature worker.
Orchestrate cross-system flows
Stateless orchestration between System APIs. pause-ingest-process-api validates an Open mHealth payload, transforms to FHIR R5 via DataWeave, posts to JHE, and fires a feature compute request to DBDP.
Pause-facing read endpoints
Read-optimized FHIR Bundles that combine raw Observations with DBDP-computed feature Observations. The Pause clinician web app calls these — never JHE or DBDP directly.
Why MuleSoft
Most US health systems and large payers already license MuleSoft Anypoint Platform. Adding Pause becomes 'another Mule app on the existing fabric' — the lowest-friction posture a procurement team can encounter.
Adding a new wearable (Garmin, Withings, etc.) is one new System API plus one row in the Process API's routing config. The Pause backend is untouched. Customers extend the integration without coordinating with our engineering team.
The customer's integration team owns the System and Process APIs. Pause owns the Experience APIs and the menopause-specific logic. Each side operates the layer they understand best.
MuleSoft in the middle, JupyterHealth + FHIR on the back, DBDP for wearable features, Agentforce on the front. Every piece is the best-in-class substrate for its job, and they fit together cleanly.
Touch the architecture
The Next.js frontend exposes a mocked Experience-tier endpoint at /api/mulesoft/health. It returns a realistic FHIR R5 Bundle with a Patient, three raw wearable Observations (heart rate, sleep duration, HRV RR intervals), and one DBDP-computed feature Observation — the sliding-window RMSSD — with a derivedFrom reference back to the raw HRV input. That is the production read-path shape. The data lineage is intact: every computed feature points to the raw window it was derived from.
Prototype vs production
| Aspect | Prototype today | Customer deployment |
|---|---|---|
| Where the integration runs | Mocked Experience API served by Next.js at /api/mulesoft/health. | Three-tier Mule application on the customer's Anypoint Runtime Fabric or CloudHub 2.0. |
| Reference flow code | mulesoft/flows/pause-process-api.example.xml — labeled Mule 4 XML with comments; not deployable. | Real Mule project with property files, secret references, API spec in Anypoint Exchange, CI/CD. |
| OMH → FHIR transform | mulesoft/transforms/omh-to-fhir.example.dwl — DataWeave 2.0 reference; same file ships into the real project. | Promoted to a shared Anypoint Exchange asset reused across customers. |
| Wearable vendor adapters | Direct vendor calls from pause_ingest (Python). | Per-vendor System APIs in Mule with token vaults, rate-limit controls, circuit breakers. |
| Pause backend integration surface | Direct calls to JupyterHealth Exchange. | Calls go only to Experience APIs. The customer's IT team owns the policy on those endpoints. |
Phased plan
Today
Reference Mule flow + DataWeave transform committed under mulesoft/. Mocked Experience API at /api/mulesoft/health. Design doc at docs/mulesoft-integration.md. Investor page (this one).
2–3 weeks
Pause-managed Anypoint trial org. Six System APIs as real Mule projects. JHE and DBDP System APIs wired to local instances. One Process API end-to-end.
4–6 weeks with customer
Deploy Mule apps into the customer's Runtime Fabric. Wire their identity provider (PingFederate / Azure AD) to the Experience APIs. Cut over the Pause backend's reads.
Ongoing
Promote shared System APIs (Oura, Apple Health, JHE) to versioned Anypoint Exchange assets. Customer-specific Process and Experience APIs remain in customer orgs.
Why investors should care
Read deeper
