Finding a Patient in Cerner
Look up a patient in Cerner by ID, or search by name, birthdate, or identifier — with built-in checks for missing patients, bad requests, and expired logins.
The workflow
The complete flow, exactly as it runs in the Workflow Builder. Scroll to explore, or use the zoom controls.
Requirements
Set up these connections in the Workflow Builder before importing or running this workflow.
Provides the backend access token used to read and search Patient resources in Cerner's FHIR API.
About this workflow
Before you build anything real on top of FHIR, you need to know that reading and searching for a patient actually works — including the times it's supposed to fail. This workflow is a small test suite against Cerner's FHIR Patient API: it reads a patient by ID, searches by name, birthdate, and identifier, and deliberately checks the failure cases too — a missing patient, a malformed ID, a bad search parameter, a missing login.
The problem
Every EHR implements FHIR a little differently, and the only way to trust an integration is to test it against the real thing — not just the happy path, but the cases where it should fail. An endpoint that returns success for a bad request, or goes quiet on a missing patient, causes confusing bugs much later. Checking that by hand, one request at a time, is slow and easy to skip.
How it works
Each test case is a single trigger: get a backend access token, build the matching FHIR request — a direct read by patient ID, or a search by family name, birthdate, or identifier — and send it to Cerner. The read tests cover a valid patient, a non-existent ID, a malformed ID, and a request with no login at all. The search tests cover the same pattern across each search parameter, plus an invalid one.
Every response, success or failure, is logged so you can see exactly what Cerner returned.
Why it matters
It turns "does our Cerner connection actually work" from a guess into something you can check in a couple of clicks — the happy path and the edge cases both — instead of writing a manual test script.
Who it's for
Integration engineers validating a new Cerner connection, and teams who want a ready-made regression check before shipping changes to a patient lookup feature.
How to build this workflow
Recreate it in the Workflow Builder by wiring these steps in order — or download it above and import it directly.
Step 1: Lookup Request Comes In
A request to find a patient — either a direct read by ID, or a search by name, birthdate, or identifier.
Step 2: Authenticate with the EHR
Get a backend access token so the request is allowed to read patient data.
Step 3: Build & Send the Request
Turn the input into a proper FHIR request — a direct read or a search query — and send it to the EHR.
Step 4: Check the Response
Confirm what came back: a matching patient, an empty result, or the right error for something that should fail.
Step 5: Log the Result
Every outcome — success or expected failure — is logged, so you can see exactly what the EHR returned.