25 posts tagged with "fhir-datastore"

Healthcare APIs need flexibility. While FHIR's standard CRUD operations (create, read, update, delete) handle most use cases, real-world healthcare workflows often require custom logic that goes beyond basic data manipulation. That's why we're excited to introduce custom FHIR operations in Medplum.

What Are FHIR Operations?​

FHIR operations are the "dollar sign things" – endpoints like $validate, $expand, or $match that perform specialized functions beyond standard CRUD operations. These are technically called "operations" in FHIR terminology, distinct from the basic "interactions" used for everyday data management.

Medplum is the platform of choice for technical leaders in healthcare, and that has given us a unique perspective into the transformative power of AI in healthcare - we get asked about it every single day.

We know that technical leaders feel the pressure to define and execute on an AI strategy, and to demonstrate tangible progress to teams and stakeholders, that's expected in times of rapid technical advances.

That's why we're thrilled to announce our beta support for Anthropic's Model Context Protocol (MCP), marking a significant leap forward in how large language models (LLMs) can securely and intelligently interact with healthcare infrastructure and systems of record.

Healthcare technology relies on established systems like Electronic Health Records (EHRs) and is now incorporating concepts like Unified Digital Health Platforms (UDHPs). Understanding this evolution is key to navigating the industry's direction.

Forking can look like the fastest path to control, but it often becomes a long‑term maintenance tax. Here’s a pragmatic checklist to decide—and alternatives that usually win.

As the open source healthcare developer platform of choice for innovators worldwide, Medplum continues to evolve with the rapidly changing technology landscape. We're excited to announce our upcoming major version release, Medplum v5, scheduled for October 2025. This post outlines the significant changes coming in this release to help our users prepare accordingly.

We've heard many success stories from enthusiastic early adopters who have smoothly upgraded to v4. Thank you all for your support and your feedback in this process!

However, we've identified an issue affecting some Medplum deployments that are configured to automatically pull the :latest Docker tag. With our recent release of Medplum 4.0.0, these deployments may be caught in a failing deployment loop. This post explains why this is happening and how to resolve it.

Medplum v4.0.0 is coming soon! Many of the new features in this release have already been rolled out incrementally, making the v4.0.0 designation more symbolic of the semantic versioning. We prioritize stability and backwards compatibility and work hard to minimize unnecessary changes. However, sometimes changes are necessary to keep the platform up-to-date and secure. This document outlines the key updates in v4.0.0, including important information for self-hosting deployments and TypeScript SDK users.

As we close out 2024, the Medplum team would love to thank our community and customers for joining us on this journey.

If you've worked with FHIR before, you've probably noticed there are a lot of resources. And I mean a lot! At first glance, it might seem overwhelming to figure out how they all fit together. But here's the thing: once you understand a few core patterns, the whole system starts to make much more sense.

Today, let's talk about one of FHIR's clever organizational tricks: the Workflow module. It's an pattern overlaid onto resource types that helps unlock how different healthcare activities relate to each other. Whether you're building a scheduling system, managing prescriptions, or handling lab orders, these patterns will come in handy.

Medplum is built on Postgres. Until recently, our hosted Medplum service was using an Amazon Web Services (AWS) RDS Aurora Postgres cluster running version 12.16. Since v12 is rather outdated and nearing the end of its standard support window on RDS, it was time to plan our upgrade to the newest version available on RDS, v16.4. Various methods to upgrade to a new major version on various places across the downtime vs level-of-effort continuum; we decided to upgrade our database with no downtime. This is how we did it.