ServiceRequest, Lab Reports and Diagnosis resources

So Bob comes to Dr. Alice complaining of fatigue. She’s recorded his symptoms as Observations and we’ve talked about the tricky boundary between Observations and Conditions. But now what?

Dr. Alice looks at Bob and thinks, “Let’s make sure all his blood work is normal.” She needs to order some tests. This is where two crucial FHIR resources come into play: ServiceRequest and DiagnosticReport.

Think of it this way: ServiceRequest is the “please do this” and DiagnosticReport is the “here’s what we found.”

What Is a ServiceRequest?

The ServiceRequest resource represents an instruction to someone to do something. It’s like a digital order slip.

In Bob’s case, Dr. Alice wants to order a Complete Blood Count (CBC) panel. A CBC is when you give blood and they measure several parameters - hemoglobin, white blood cells, red blood cells, all that good stuff in your blood.

Here’s what that order looks like in FHIR:

{
  "resourceType": "ServiceRequest",
  "id": "sreq-cbc-1",
  "status": "active",
  "intent": "order",
  "code": {
    "coding": [
      { "system": "http://loinc.org", "code": "57021-8", "display": "CBC W Auto Differential panel - Blood" }
    ],
    "text": "CBC panel"
  },
  "subject": { "reference": "Patient/bob-patient" },
  "encounter": { "reference": "Encounter/enc-1" },
  "requester": { "reference": "Practitioner/prac-1" },
  "performer": [ { "reference": "Organization/org-1" } ],
  "reasonCode": [
    {
      "coding": [ { "system": "http://snomed.info/sct", "code": "84229001", "display": "Fatigue" } ],
      "text": "Fatigue"
    }
  ]
}

Breaking Down the ServiceRequest

Let’s look at what makes this order tick:

status: “active” means this order is current and needs to be fulfilled
intent: “order” means this is an actual request (not just a plan or proposal)
code: What exactly are we ordering? Here it’s a CBC panel, coded using LOINC (a standard for lab tests)
subject: Who is this for? Bob, of course
encounter: Which visit is this connected to? Bob’s current appointment
requester: Who’s asking for this? Dr. Alice
performer: Who should do this? The lab at Springfield Family Practice
reasonCode: Why are we doing this? Because of Bob’s fatigue

Notice we’re also asking for an “automatic differential” - that’s just fancy talk for using modern machines that automatically count different types of blood cells.

ServiceRequest: The Swiss Army Knife of FHIR

Here’s the cool thing about ServiceRequest - it’s incredibly versatile. You can use it to request:

Diagnostic tests (like Bob’s CBC)
Procedures (like an endoscopy)
Counseling (like nutrition advice)
Therapy (like physical therapy)
Pretty much anything you can think of in healthcare

It’s like the universal “please do this” resource in FHIR.

What Happens After the ServiceRequest?

So Dr. Alice places the order. Bob goes to the lab. They draw his blood and send it off for testing. Then what?

The lab runs the tests and creates a DiagnosticReport. This is where things get interesting.

What Is a DiagnosticReport?

The DiagnosticReport resource is like the lab’s answer to the doctor’s question. It’s the complete package of findings from diagnostic tests.

Here’s Bob’s CBC results as a DiagnosticReport:

{
  "resourceType": "DiagnosticReport",
  "id": "drpt-cbc-1",
  "status": "final",
  "category": [
    {
      "coding": [
        { "system": "http://terminology.hl7.org/CodeSystem/v2-0074", "code": "LAB", "display": "Laboratory" }
      ]
    }
  ],
  "code": {
    "coding": [
      { "system": "http://loinc.org", "code": "57021-8", "display": "CBC W Auto Differential panel - Blood" }
    ],
    "text": "CBC panel report"
  },
  "subject": { "reference": "Patient/bob-patient" },
  "encounter": { "reference": "Encounter/enc-1" },
  "effectiveDateTime": "2025-08-08T10:05:00-05:00",
  "issued": "2025-08-08T10:10:00-05:00",
  "performer": [ { "reference": "Organization/org-1" } ],
  "result": [ { "reference": "Observation/obs-hb-1" } ],
  "conclusion": "Hemoglobin is low. Findings consistent with anemia."
}

Breaking Down the DiagnosticReport

Let’s understand what’s happening here:

status: “final” means the results are complete and ready for clinical use
category: “LAB” tells us this is a laboratory report
code: Same as the ServiceRequest - this report answers that specific order
effectiveDateTime: When the test was actually performed (10:05 AM)
issued: When the report was released (10:10 AM - just 5 minutes later!)
performer: Who did the test? The same organization
result: Points to the actual test results (like Bob’s hemoglobin observation)
conclusion: The lab’s interpretation - “Hemoglobin is low. Findings consistent with anemia.”

The Beautiful Connection

Notice something cool? The DiagnosticReport’s code is exactly the same as the ServiceRequest’s code. This creates a perfect link between “what was ordered” and “what was delivered.”

It’s like ordering a pizza and getting exactly the pizza you ordered - with a receipt that matches your order slip.

DiagnosticReport: More Than Just Lab Results

While we’re using a lab example, DiagnosticReport can handle much more:

Laboratory reports (like Bob’s CBC)
Pathology reports (like biopsy results)
Imaging reports (like X-ray interpretations)
Cardiology reports (like EKG results)
Any diagnostic investigation you can think of

According to the FHIR specification, DiagnosticReport is suitable for “the findings and interpretation of diagnostic tests performed on patients, groups of patients, devices, and locations.”

The Nested Structure: Reports Reference Observations

Here’s where it gets interesting. The DiagnosticReport doesn’t contain the actual test values - it references them.

In Bob’s case, the DiagnosticReport points to Observation/obs-hb-1 - that’s where the actual hemoglobin value (10.0 g/dL) lives.

Why this separation? Because:

Individual results can be used elsewhere
Complex panels can reference multiple observations
Different systems can handle data differently
Flexibility is maintained for various use cases

Think of the DiagnosticReport as a cover letter that says “Here are your results” and points to the actual detailed findings.

The Workflow That Keeps Repeating

This ServiceRequest → DiagnosticReport pattern is everywhere in healthcare:

Doctor orders something (ServiceRequest)
Someone performs the test/procedure
Results come back (DiagnosticReport)
Doctor interprets and acts on results

You’ll see this pattern again and again. It’s like the heartbeat of diagnostic medicine.

Real-World Complexity Made Simple

In the real world, a CBC panel might include dozens of individual measurements. In FHIR, you might see:

One ServiceRequest for “CBC panel”
One DiagnosticReport summarizing the findings
Multiple Observations for each individual measurement (hemoglobin, white blood cell count, platelet count, etc.)

The DiagnosticReport ties them all together with a nice bow.

What Happens Next?

Bob’s DiagnosticReport shows low hemoglobin. Dr. Alice looks at this and thinks, “Bob has anemia.” That diagnosis becomes a Condition resource.

Here’s how Bob’s anemia diagnosis looks in FHIR:

{
  "resourceType": "Condition",
  "id": "cond-1",
  "clinicalStatus": {
    "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/condition-clinical", "code": "active" } ]
  },
  "verificationStatus": {
    "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/condition-ver-status", "code": "confirmed" } ]
  },
  "code": {
    "coding": [ { "system": "http://snomed.info/sct", "code": "271737000", "display": "Anemia" } ],
    "text": "Anemia"
  },
  "subject": { "reference": "Patient/bob-patient" },
  "encounter": { "reference": "Encounter/enc-1" },
  "onsetDateTime": "2025-08-08",
  "evidence": [ { "detail": [ { "reference": "DiagnosticReport/drpt-cbc-1" }, { "reference": "Observation/obs-hb-1" } ] } ]
}

The Condition can reference back to both:

The DiagnosticReport (the overall findings)
The specific Observation (the low hemoglobin value)

This creates a complete evidence trail from symptom to diagnosis.

From Diagnosis to Action: The Procedure Resource

Now that Dr. Alice has diagnosed Bob with anemia, she wants to investigate further. “Let’s make sure there’s no internal bleeding,” she thinks. She decides to perform an upper endoscopy (EGD) to examine Bob’s upper gastrointestinal tract.

Here’s the Procedure resource that represents this endoscopy:

{
  "resourceType": "Procedure",
  "id": "proc-endoscopy-1",
  "status": "completed",
  "code": {
    "coding": [
      { "system": "http://snomed.info/sct", "code": "1259004", "display": "Upper gastrointestinal endoscopy" }
    ],
    "text": "Upper endoscopy (EGD)"
  },
  "subject": { "reference": "Patient/bob-patient" },
  "encounter": { "reference": "Encounter/enc-1" },
  "performedDateTime": "2025-08-08T14:30:00-05:00",
  "performer": [
    {
      "actor": { "reference": "Practitioner/prac-1" }
    }
  ],
  "reasonReference": [
    { "reference": "Condition/cond-1" }
  ]
}

Breaking Down the Procedure

Let’s understand what happened here:

status: “completed” means the procedure has been finished
code: SNOMED CT code for “Upper gastrointestinal endoscopy”
subject: Bob, our patient
encounter: Same encounter where everything else happened
performedDateTime: When the procedure was actually done (2:30 PM)
performer: Dr. Alice performed the procedure herself
reasonReference: References the anemia condition - this is why the procedure was done

The Beautiful Chain of Evidence

Look at how everything connects:

Observation: Bob’s low hemoglobin (10.0 g/dL)
DiagnosticReport: CBC results showing anemia
Condition: Anemia diagnosis with evidence pointing to the report and observation
Procedure: Endoscopy performed because of the anemia condition

Each resource references the previous ones, creating an unbroken chain of clinical reasoning.

ServiceRequest Can Lead to More Than Reports

While we focused on diagnostic testing, ServiceRequest can also lead to:

Procedures (if it’s a request for a procedure)
MedicationRequests (if it’s a request for treatment)
Other ServiceRequests (if one test leads to ordering another)

It’s the universal “please do something” that can branch into any healthcare action.

The Status Lifecycle

Both resources have important status fields:

ServiceRequest Status:

draft: Still being written
active: Ready to be acted upon
completed: The requested action has been performed
cancelled: No longer needed

DiagnosticReport Status:

registered: Exists but no results yet
preliminary: Early results, might change
final: Complete and verified
corrected: Final report has been modified

These statuses help track where things are in the workflow.

Common Gotchas for Beginners

Don’t confuse ServiceRequest with Procedure: ServiceRequest is the order, Procedure is the actual doing
DiagnosticReport isn’t the raw data: It’s the interpretation and summary
Multiple observations per report: One report can reference many individual results
Timing matters: effectiveDateTime vs issued can be different
Status tracking: Always check if results are final before making clinical decisions

Key Takeaways

ServiceRequest = “Please do this thing”
DiagnosticReport = “Here’s what we found when we did that thing”
They connect through matching codes
Reports reference individual Observations for detailed data
This pattern repeats throughout healthcare
Status fields track the workflow progress

The Bigger Picture

ServiceRequest and DiagnosticReport are crucial building blocks in FHIR. They represent the essential healthcare workflow of:

Question → Investigation → Answer → Action

Bob’s fatigue led to a CBC order, which led to results showing anemia, which will lead to treatment. These resources capture that flow in a structured, interoperable way.

Want to Learn More?

Check out the official FHIR specifications:

These resources have extensive examples showing different types of orders, reports, diagnoses, and procedures. The ServiceRequest page shows everything from lab orders to procedure requests, while DiagnosticReport covers laboratory, pathology, and imaging scenarios. The Condition resource details how to represent clinical problems and diagnoses, and the Procedure resource shows how to document completed medical procedures.

Remember: healthcare is about asking the right questions, interpreting the answers, making diagnoses, and taking action. ServiceRequest, DiagnosticReport, Condition, and Procedure resources capture this complete clinical workflow in FHIR’s structured format.