### Medical Imaging and DICOM Support Medical imaging has been the part of the patient record that lives somewhere else. A digital health company builds its charting, ordering, and results workflows on FHIR, and then imaging arrives and the answer is a separate PACS, a separate login, a separate access control model, and a link out to a viewer that knows nothing about the rest of the chart. Today we are releasing [DICOM and DICOMweb support](/content/docs/dicom/index.html) in [Beta](/content/docs/compliance/alpha-beta/index.html). A modality on a hospital network can send a study to Medplum over the DICOM network protocol, the study is stored as ordinary Medplum resources under the project's existing access policies, and a DICOMweb viewer can read it back out — with no image server in the middle. ### Genetic Intelligence for Longevity [Profile Health](https://profilehealth.com/) is building **genetic intelligence for longevity and functional medicine** — the concierge, naturopathic, and longevity practices that treat chronic, whole-person conditions rather than single episodes of care. Their thesis is simple: the most valuable signal in medicine — a patient's whole **genome**, enriched with a lifetime of their clinical records — sits scattered, unread, and never makes it into the exam room. Profile fuses the two and hands the result to the physician, so care can get ahead of disease instead of reacting to it. ### Medplum's Accomplishments The headline this month: **Medplum earned the [2026 FHIRplace Participant emblem](/content/blog/fhirplace-participant-2026/index.html) from Drummond Group** for electronic prior authorization testing, ahead of the January 2027 enforcement date. July was another heavy shipping month — 206 commits from 28 contributors and five patch releases, v5.1.23 through v5.1.27. On the revenue cycle side, real-time [insurance eligibility checks](/content/docs/billing/insurance-eligibility-checks/index.html) arrived as a FHIR operation of their own, and `Claim/$submit` learned to route preauthorization requests to their own processor. Elsewhere, [server-scoped subscriptions](/content/docs/subscriptions/server-scoped-subscriptions/index.html) give project-per-tenant deployments one central data-processing flow, a concentrated round of authentication hardening tightened JWT validation, outbound fetch, and MFA, and the [Decision Guides](/content/docs/decision-guides/index.html) are now published natively in the docs. A first DICOMweb implementation also landed in [Alpha](/content/docs/compliance/alpha-beta/index.html) for teams beginning to work with imaging. All of this continues to drive forward our [2026 roadmap priorities](/content/blog/2026-roadmap/index.html). ### Upcoming Events Today is the day: Medplum is hosting the **Agentic Healthcare Hackathon** with Y Combinator at the YC office in San Francisco on **Saturday, August 1, 2026**. ### Prior Authorization Changes Prior authorization is one of the biggest sources of administrative burden in healthcare, and it is now the subject of a regulatory deadline. [CMS-0057-F and HTI-4](/content/docs/compliance/hti-4/index.html) require payers and providers to support electronic prior authorization workflows built on FHIR, with enforcement beginning January 2027. Medplum supports ePA transactions for payers AND providers and has earned the 2026 FHIRplace Participant emblem from Drummond Group for our engagement in **electronic prior authorization (ePA) testing**. ### Everself's Innovative Approach [Everself](https://everself.com/) is building the **second line of defense for obesity care**. Every month, more than a million patients drop off GLP-1 medications, and most regain the weight within three to six months. Until now, the only durable alternative has been invasive bariatric surgery, which can require weeks away from work. Everself fills the gap with an **outpatient endoscopic weight loss procedure** that delivers bariatric-level results without surgery, wrapped in a longitudinal care program delivered by a full care team. ### The Role of Forward Deployed Engineers 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. 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. ### Security and Compliance Updates The headline this month: **Medplum achieved [HITRUST certification](/content/blog/hitrust-e1-certification/index.html)**, 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](/content/docs/scheduling/index.html) saw a lot of activity. The [Provider App](https://provider.medplum.com/) 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](/content/docs/auth/mfa/index.html), enforceable per project. All of this continues to drive forward our [2026 roadmap priorities](/content/blog/2026-roadmap/index.html). ### Medplum's Scheduling API Development After several months of preview as an [Alpha](/content/docs/compliance/alpha-beta/index.html) product, we are pleased to announce that [Medplum's Scheduling API](/content/docs/scheduling/index.html) has graduated to [Beta](/content/docs/compliance/alpha-beta/index.html). Medplum's Scheduling API provides an interface for applications to atomically interact with [Schedule](/content/docs/api/fhir/resources/schedule/index.html), [Slot](/content/docs/api/fhir/resources/slot/index.html), and [Appointment](/content/docs/api/fhir/resources/appointment/index.html) 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. ### Bridging the Gap in Digital Health 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](https://anybio.io/) handles the upstream half of that pipeline. [Medplum](/content/site-root.html) 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](https://build.fhir.org/ig/HL7/US-Core/index.html) 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.