Joint reference architecture lets healthcare builders compose two specialized infrastructure layers - continuous biosignal pipeline and episodic clinical workflow - instead of retrofitting either layer into the other.

AnyBio, the biosignal infrastructure platform for builders, and Medplum, the open-source FHIR-native developer platform, today announced a joint reference architecture for biosignal-driven care programs. The architecture is backed by a working integration over the FHIR Observation resource and a technical blog outlining how the two layers compose. The combination gives healthcare builders an end-to-end deployable stack - from wearable device to clinician workspace - over a standards-based seam, instead of forcing them to retrofit a streaming pipeline into a clinical workflow product, or vice versa.

The integration addresses a structural problem in healthcare engineering. Continuous biosignal data - the streaming output of wrist-worn and chest-worn wearables - and episodic clinical workflow - the FHIR-resource-shaped data model that EHRs, care plans, and patient portals run on - require fundamentally different infrastructure underneath. Streaming pipelines need different runtime, storage, and consistency guarantees than transactional clinical workflow systems. Platforms that try to absorb both end up doing one well and the other badly, and builders pay for the worse half.

Two layers, one seam. AnyBio handles the continuous side: Bluetooth Low Energy (BLE) ingestion from consumer and medical wearables, real-time signal processing and feature extraction, episode detection, governed AI agents, and FHIR Observation emission with pre-mapped LOINC codes. Medplum handles the episodic side: FHIR-native resource storage, CarePlan and Questionnaire scaffolding, patient portal and clinician workspace primitives, and the consent, audit, and auth stack required for clinical deployment. The boundary between the two is the FHIR Observation resource - emitted natively by AnyBio, consumed natively by Medplum, with no proprietary translation layer between them.

Anchored to a reference build. The joint architecture is anchored to a detailed reference build: an integrated framework that helps developers quickly close the gap between collecting a wearable’s raw BLE data and transforming such signals into clinical grade EHR-actionable records. The reference models demonstrate how to build remote patient monitoring programs from five patients to 100s of patients, with the ability to enable patient-facing nudges two to three times a day via the Medplum web portal or the AnyBio iOS app. The reference build demonstrates how to set up real-time biosignal handling on the AnyBio side and clinical workflow presentation on the Medplum side without either platform stepping out of its lane - a build that would conventionally take 12 to 18 months and a full engineering team to produce from scratch.

"Continuous biosignals and episodic clinical workflow are two different engineering problems. Every platform that tries to absorb both ends up doing one well and the other poorly, and the builder pays for the worse half. We built AnyBio to be the biosignal plumbing and stay below the app layer. Medplum does the same thing for clinical workflow. Compose us over a FHIR boundary and a builder ships a real care program in weeks instead of spending 12 to 18 months building both halves themselves."

- Stephen Saine, founder & CEO | Any Biosignal

"FHIR was designed for exactly this kind of composition. AnyBio emits FHIR Observation resources that can be consumed directly by Medplum, allowing shared customers to integrate biosignal data into clinical workflows without building custom translation layers. An Observation written by AnyBio lands in a Medplum FHIR server cleanly, and from there standard FHIR-based workflows can take over. Together, the two platforms demonstrate how specialized healthcare systems can compose through open standards."

- Cody Ebberson, co-founder & CTO, MedPlum

Availability.

The integration is available today. Builders can configure FHIR Observation forwarding from AnyBio to any Medplum project through the AnyBio dashboard's Integrations panel. Both platforms operate under HIPAA-compliant infrastructure with Business Associate Agreements available on their respective production tiers.

A technical write-up of the joint reference architecture - "From BLE to FHIR: Streaming Clinical-Grade Biosignals with AnyBio + Medplum" - is available today. A step-by-step build guide for a HIPAA-compliant technical integration guide showing how to get any clinical-grade biosignal from a BLE wearable into a FHIR-native EHR (Medplum) using AnyBio for the upstream signal pipeline. Signals such as HR, HRV, ECG, SpO₂, EDA, PPG, blood pressure and more available.

About AnyBio

AnyBio is the biosignal infrastructure layer for clinical teams - the compliant runway between wearable biosignals and clinical care. Purpose-built rails extract, normalize, and route wearable health data through a FHIR-native, auditable pipeline directly into the clinical workflow, without device-by-device integrations. Builders deploy on Day 1; health systems use the same shared foundation so physician-led clinical programs survive IT review and actually deploy. GDPR-aligned, SOC 2 Type I certified (Type II in observation), and BAA-ready. The clinician stays the decision-maker. One foundation. Many programs. Learn more at anybio.io.

About Medplum

Medplum is the open-source, FHIR-native developer platform for healthcare. Medplum provides FHIR-compliant data storage, clinical workflow scaffolding, patient portal and clinician workspace primitives, and the consent, audit, and authentication stack required for HIPAA-grade deployments. Healthcare builders use Medplum to ship FHIR-native applications without rebuilding the clinical workflow layer from scratch. Learn more at medplum.com.

View source version on businesswire.com: https://www.businesswire.com/news/home/20260630984228/en/

Continuous biosignals and episodic clinical workflow are two different engineering problems. Every platform that tries to absorb both ends up doing one well and the other poorly, and the builder pays for the worse half.