FHIR Workflow Patterns to Simplify Your Life | Medplum

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 a 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.

The Three Resource Patterns: A Simple Framework

Think of healthcare workflows like a play: you have the script (what should happen), the actual performance (what did happen), and the stage directions (how things should happen). FHIR organizes its workflow resources in a similar way, with three main patterns:

1. Request Resources: "Please Do This"

These are resources that ask and authorize someone to do something. When a doctor orders a blood test, prescribes a medication, or assigns a task to a nurse, they're creating a Request resource. It's FHIR's way of saying "hey, this needs to happen."

2. Event Resources: "This Happened"

These record what actually happened. When the nurse draws blood, when the patient takes their medication, or when two healthcare providers have a conversation about a case - these all become Event resources. They're the historical record of what actually happened.

3. Definition Resources: "Here's How Things Should Work"

These are like the rulebook or playbook. They define standard procedures, protocols, and guidelines that aren't tied to any specific patient. Think of them as templates that can be used over and over again.

The Complete Resource Grouping

Let's look at how FHIR organizes all its workflow resources. This might seem like a lot at first, but remember - they all follow those three patterns we just discussed:

Definitions (aka "Templates and Protocols")

Requests (aka "Please Do This")

Events (aka "This Happened")

How These Patterns Connect: The Standard Relationships

Before we dive into a specific example, let's talk about how FHIR connects these different patterns. The specification defines several standard relationships that you'll see over and over:

• basedOn is the canonical way to connect an Event to the Request that triggered it. When something happens because someone asked for it, this is your go-to field.
• instantiates is how Events and Requests point to their Definition (like saying "I'm following this protocol")
• partOf shows parent-child relationships between Events or between Definitions
• replaces is used when a newer version supersedes an older Request or Definition

Understanding these standard relationships is key to using FHIR effectively. They're not just random fields - they're carefully chosen to represent common healthcare workflows.

A Real Example: Handling Insurance Rejections

Let's make this concrete with a real-world example. Imagine you're building a system to handle insurance claim rejections. You need to track communications between customer service agents and pharmacy staff about resolving these rejections. How would you model this in FHIR?

Your first instinct might be to just create a bunch of Communication resources and call it a day. But understanding the workflow patterns helps us make better choices:

1. First, we need a Task (a Request resource) that represents the work of resolving the rejection
2. Then, we'll have multiple Communication resources (Event resources) that document the discussions about resolving it

But here's the tricky part: how should we link these together? FHIR gives us several options:

• Communication.about
• Communication.basedOn
• Communication.partOf

This is where understanding the patterns and their standard relationships really helps! Since we're linking an Event ( Communication ) to the Request (Task) that triggered it, basedOn is the canonical choice - it's specifically designed for connecting Events to their triggering Requests.

{
  resourceType: "Communication",
  basedOn: [{
    reference: "Task/insurance-rejection-123"
  }],
  status: "completed",
  payload: [{
    contentString: "Patient's new insurance card received. Resubmitting claim."
  }]
}

Why This Matters for You

Understanding these patterns isn't just about knowing FHIR better (though that's nice too!). It's about making your life easier as a developer. When you understand these patterns, you can:

• Figure out which resource you need more quickly
• Predict what fields a resource probably has
• Make better decisions about how to connect resources
• Write more maintainable code

The Big Picture

Healthcare workflows are complex - there's no way around that. But FHIR's patterns give us a structured way to handle this complexity. Next time you're working with FHIR resources, try asking yourself:

• Is this something being requested, something that happened, or a definition of how things should work?
• How does this resource relate to others in the workflow?
• What real-world process am I trying to model?

Understanding these patterns transforms FHIR from a seemingly random collection of resources into a coherent system for modeling healthcare workflows. And that makes building healthcare applications a whole lot more manageable!