You have probably noticed that "Forward Deployed Engineer" is having a moment. Over the last couple of years the role has spread from a Palantir-specific curiosity to the role every enterprise software company suddenly wants to hire for. OpenAI, Anthropic, Ramp, and dozens of others have stood up FDE teams, and the VC blog and tech newsletters alike have declared it the hottest new role in tech.

We are excited about it too. However, healthtech has been doing this for more than 40 years.

At Medplum, forward deployed engineering is not a trend we picked up. Healthtech companies have always built software in a "forward-deployed" manner, embedding engineers directly in the clinic to learn directly from interactions between healthcare providers and patients. This post is about what an FDE is, why healthcare got here early, how we think about the role at Medplum, and the values our team lives by. And, if any of this resonates, we would love to hear from you.

The headline this month: Medplum achieved HITRUST certification, a validation of our security and compliance program. June was also another busy month of shipping, with 200+ commits from 25+ contributors and nine patch releases — v5.1.14 through v5.1.22.

Scheduling saw a lot of activity. The Provider App gained a reusable inbox shell, and operation-based claim submission. SMART Health Cards and Links arrived with a QR code scanner, the Enterprise data warehouse export was released, and the AI workspace added configurable model routing. The platform also gained email-based multi-factor authentication, enforceable per project.

All of this continues to drive forward our 2026 roadmap priorities.

After several months of preview as an Alpha product, we are pleased to announce that Medplum's Scheduling API has graduated to Beta.

Medplum's Scheduling API provides an interface for applications to atomically interact with Schedule, Slot, and Appointment resources to safely create and manage bookings without creating scheduling conflicts. Developing a feature like this required the ability to iterate as we learned, and our Alpha period provided exactly that.

If you're building a digital health product, you've probably hit the same wall everyone hits: the gap between a wearable's raw signal and a clinical-grade artifact in the EHR that is actionable by a clinician.

There's a lot of plumbing in that gap: device integration, real-time ingest, signal processing, derived metrics, provenance, governance, FHIR projection, US Core conformance, and most of it is undifferentiated infrastructure that takes a year or more to build properly.

AnyBio handles the upstream half of that pipeline. Medplum handles the downstream half.

Together they give you a standards-based path from a BLE sensor on a patient's wrist to a US-Core-conformant Observation in a queryable FHIR record - and on the AnyBio side, wiring up that path is a configuration step, not an engineering project.

This post walks through what each side does and how the data is shaped, then gives you two ways in: a two-minute path that exports a synthetic demo run to your own Medplum instance with zero setup, and the full production wire-up. And - because "it works in the demo" is not the same as "I'd run this in production" - how the pipeline behaves when things go wrong.

There's a piece of conventional wisdom in health tech that won't die: FHIR is fine for interoperability, but too slow and bloated for real-time clinical apps.

The skepticism isn't unreasonable. FHIR resources can be verbose, real charts are messy, and clinical workflows don't forgive much. A physician who opens a chart and watches a spinner for five seconds has already been let down by the architecture.

More and more Medplum users are building with AI coding assistants — Cursor, Claude, Copilot, and others. We have been talking to users about what works and wrote up what we have learned in a new guide: Building on Medplum with AI Coding Assistants. This post is the short version of what is in there.

Demonstrating commitment to cybersecurity and information protection: HITRUST Certification validates the Medplum Platform is meeting rigorous cybersecurity and data protection standards through independent assessment and assurance.

San Francisco, Calif., June 1, 2026 – Medplum, a leading provider of open-source healthcare developer infrastructure, today announced its Medplum Platform residing at Amazon Web Services (AWS) has earned certified status from HITRUST for cybersecurity and information protection.

May was a heavy month for Medplum, with 100+ commits from 20+ contributors and four patch releases — v5.1.10 through v5.1.13. Scheduling was the headline: the full appointment operation suite — $find, $hold, $book, $confirm, and $cancel — landed in Alpha. The Provider App also gained medication ordering components, order set import, and operation-based claim submission. On the enterprise side, a new data warehouse export features were enabled, and the platform team shipped passwordless magic-link login, AWS GuardDuty malware protection, and a round of OAuth2 spec-compliance fixes. All of this continues to drive forward our 2026 roadmap priorities.

• Register here for PlumCon 2026, September 3, 2026 in San Francisco
• Join the PlumCon Discord channel

Medplum stayed active this April, with 130+ commits from 20+ contributors amounting to three patch releases — v5.1.7, v5.1.8, and v5.1.9. The Provider app's billing and coverage workflows took a major step forward with integrated claim submission and live eligibility visibility. Scheduling added support for service line configurations on HealthcareService, aligning with R5/R6 FHIR conventions. Spaces, an AI-powered chat workspace inside the Provider App, now surfaces tool calls and responses directly in the chat so you can see exactly what the AI is doing. Clinical documentation expanded across intake, care plans, diagnostics, authentication, and integrations. All of this continues to drive forward our 2026 roadmap priorities.