Investor Brief · Part 2

JupyterHealth Integration: open substrate, menopause-specific layer

Pause-Health.ai is the menopause intelligence layer. JupyterHealth is the open, FHIR-native substrate underneath it. The architectural punchline: JHE stores the data and runs consent; Pause does the reasoning.

What we adopt

JupyterHealth Exchange

jupyterhealth/jupyterhealth-exchange

What it doesFHIR R5 + Open mHealth data plane. OAuth2/OIDC, scope-based consent, multi-tenant orgs and studies. Django app deployable into a customer VPC.
Why it mattersWe adopt this instead of building it. Customers see open standards, not a black box.

jupyterhealth-client

jupyterhealth/jupyterhealth-client

What it doesPython client (pip install jupyterhealth-client). Used by the Pause backend to read patient observations from the Exchange.
Why it mattersLibrary, not service. Adds zero ops surface.

omh-shim

jupyterhealth/omh-shim

What it doesConverters from vendor wearable JSON (Oura, Open Wearables) to Open mHealth / IEEE 1752.1.
Why it mattersLets us normalize wearable data before ingest. Pause contributes new converters back (Apple Health, skin temperature).

jupyter-smart-on-fhir

jupyterhealth/jupyter-smart-on-fhir

What it doesReference SMART-on-FHIR launch flow from an EHR into a Jupyter / web environment.
Why it mattersPattern for our Epic / Cerner-embedded launch. Same auth model as the rest of the platform.

helm-charts

jupyterhealth/helm-charts

What it doesKubernetes deployment for JHE — public cloud, private cloud, or on-prem behind a firewall.
Why it mattersHow customer health systems run the substrate inside their own VPC. Pause's inference layer runs alongside.

Wearable data types we surface

Data type	Menopause relevance
Heart rate	Vasomotor signal; sympathetic drive
Heart rate variability	Autonomic dysregulation, sleep quality
Sleep duration / sleep episode	Night sweats, sleep fragmentation
Oxygen saturation	Sleep-disordered breathing. Wired for Open Wearables today; Oura converter is a near-term upstream PR.
Step count / physical activity	Fatigue, activity drop
Skin temperature (gap)	Hot-flash signal not yet in omh-shim v1.0.1. Natural Pause contribution back upstream — converter plus Open mHealth schema proposal.

Phased integration plan

Phase 1 · Local dev loop

1–2 weeks

Stand up JHE locally. Add jupyterhealth-client and omh-shim to the backend. Convert a sample wearable JSON to OMH and upload it as a FHIR Observation. Read it back from FastAPI. End-to-end proof.

Phase 2 · Real wearable ingest

2–3 weeks

Vendor OAuth for Oura, then HealthKit bridge for Apple Health. Background worker polls samples and runs the convert → upload pipeline at scale.

Phase 3 · Provider read path

2–3 weeks

FastAPI assembles a patient timeline via jupyterhealth-client. Wire the menopause classifier and RAG over the guideline corpus. Clinician view in the Pause web app.

Phase 4 · Provider write path

3–4 weeks

Write Observation, CarePlan, and DocumentReference back to JHE. Capture clinician accept / edit / reject as outcomes-registry events.

Phase 5 · Customer-VPC deployment

4+ weeks per customer

Deploy JHE into the customer VPC via Helm. Wire SAML SSO. Deploy Pause inference alongside in federated mode — model weights leave the VPC; PHI does not.

Strategic value

Sales accelerationOpen standards reduce procurement and security review. CIO-friendly story.
Customer-controlled dataJHE runs in customer VPC. PHI never leaves their boundary; Pause inference runs federated alongside.
Compounding ecosystemEvery device converter added to omh-shim — by us or the community — becomes a new Pause data source.
Audit and explainabilityEvery recommendation is a FHIR resource with a reproducible input set. Compliance teams can read it.

Open contributions back

Part of the strategy, not an afterthought. Earning standing in the JupyterHealth and Open mHealth communities lowers procurement friction for every subsequent customer.

omh-shim converter for Apple HealthKit (today only Oura and Open Wearables).
omh-shim converter and OMH schema proposal for skin_temperature.
Helm chart values tuned for HIPAA-friendly defaults (TLS everywhere, audit logging, restricted egress).
Open mHealth schema for a structured menopause symptom cluster (Pause-led, community-reviewed).

Read the full design doc

The complete engineering design — data flow detail, risks, and references — lives in the repository at docs/jupyterhealth-integration.md. The architecture is reviewable, not aspirational.

For the integration plane that fronts JupyterHealth in customer deployments, see MuleSoft integration — the three-tier API-Led Connectivity layer that hosts the actual ingest, transform, and read-bundle flows. The Pause backend never talks to JupyterHealth directly in a customer environment; it goes through the MuleSoft Experience APIs.