FHIR in Primary Care: What I've Learned from 18 Years in the Trenches¶

Date: January 8, 2025
Author: Shawn Vincent
Purpose: Sharing what I've learned about primary care EMRs and why FHIR struggles with ambulatory workflows

Executive Summary¶

After 18 years wrangling EMRs, building interoperability solutions, and watching countless "revolutionary" standards come and go, I've learned that primary care is fundamentally different from hospital care. FHIR—designed primarily in and for hospitals—consistently misunderstands what makes primary care tick. This document captures what I've learned about why primary care EMRs are the way they are, and why forcing hospital-centric models onto ambulatory care creates so much friction.

What Makes Primary Care Unique¶

Let me tell you what I've learned after years of watching primary care physicians work and building systems for them.

1. Longitudinal Care Relationships¶

Primary care is fundamentally about continuity over time. I've seen doctors who:

Follow families for generations: "I delivered you, and now I'm delivering your baby"
Know the whole story: "Your depression started when your dad died—that context matters"
Build trust over decades: Patients tell their family doc things they'd never tell a specialist
Make decisions in context: "I know you hate pills, so let's try lifestyle changes first"

2. Comprehensive Scope¶

I've watched primary care physicians handle everything in a single day:

Undifferentiated symptoms: "I don't feel well"—no roadmap, just detective work
Multiple chronic conditions: Managing diabetes, hypertension, and depression in the same 15-minute visit
Preventive care: Squeezing in vaccine discussions while treating acute bronchitis
Mental health: Being the only mental health provider most patients will ever see
Social determinants: "Doc, I can't afford the medication" or "I got evicted and my sugars are crazy"

2a. How Primary Care Differs from Specialist Care¶

Here's what I've observed about the fundamental difference:

Referral Pattern¶

Primary Care → Specialist: I've built referral systems, and the flow is always one way:

Primary care SENDS the questions: "Is this cancer?"
Specialists ANSWER the questions: "No, it's a lipoma"
Primary care manages everything else
Specialists send patients back when done

Scope of Practice¶

Primary Care: In one visit, I've seen doctors handle:

"My knee hurts and I'm depressed and can you check this mole?"
They're jacks of all trades, masters of common things
90% of problems never leave their office

Specialists: Meanwhile, the orthopedist down the hall:

"I only do knees" or even "I only do ACL repairs"
Won't touch the depression or mole
Refers back for anything outside their domain

Patient Relationships¶

Primary Care:

Sees whole families for decades
Knows the patient's context, job, family dynamics
"How's your mother doing after her hip surgery?"
Continuous relationship regardless of health status

Specialists:

Episode-focused relationships
May never see patient again after issue resolved
Limited to their domain of expertise
Discharge back to primary care when done

Documentation Patterns¶

Primary Care:

Narrative, contextual notes
"Patient worried about job loss affecting diabetes control"
Multiple issues per note
Longitudinal story over time

Specialists:

Focused, technical documentation
Detailed findings specific to specialty
Single issue focus
Consultation letters back to primary care

IT Modeling Implications¶

Primary Care EMRs need:

Comprehensive patient context
Multiple problem tracking
Family linkages
Lifetime longitudinal view
Flexible documentation for anything

Specialist EMRs need:

Deep specialty-specific templates
Procedure documentation
Surgical planning tools
Referral management
Episode tracking

2b. How Primary Care Differs from Hospital Care¶

This is the distinction that FHIR completely misses:

Temporal Dynamics¶

Primary Care (Ambulatory): The word "ambulatory" literally means "to walk"—and that's the pace:

We think in weeks to months: "Try this medication and see me in 3 months"
Patient goes HOME after 15 minutes—the room is immediately available
Nothing is urgent unless there are red flags. If a patient has a heart attack in the waiting room, the clinic dials 911.
We can wait for test results—patient isn't deteriorating in a bed

Hospital (Inpatient): I've worked with hospital systems too. Everything is different:

They think in hours to days: "We need to stabilize this NOW"
Patient occupies a $2000/day bed—every hour costs money
Everything is urgent or emergent
Need results STAT—decisions can't wait

Economic Drivers¶

Primary Care:

Fee-for-service or capitation
Low overhead per patient
Volume-based (see 25-40 patients/day)
Appointment no-shows are annoying but not costly
Empty room = lost opportunity, not ongoing cost

Hospital:

DRG/Case-based funding
MASSIVE overhead per patient
Bed occupancy drives everything
Length of stay = profit killer
Empty bed = still costs money (staff, equipment, overhead)

IT Optimization Incentives¶

Primary Care EMR optimizes for:

Quick documentation
Billing capture
Preventive care reminders
Prescription management
Managing thousands of patients

Hospital EMR optimizes for:

Bed management
Discharge planning
Real-time coordination
Intensive monitoring
Managing dozens of patients intensively

Care Coordination¶

Primary Care:

Asynchronous coordination
"I'll send a referral letter"
Phone/fax/secure messaging
Can wait days for specialist response
Patient self-schedules follow-ups

Hospital:

Synchronous, real-time coordination
"Get cardiology here NOW"
Face-to-face huddles
Need immediate consultant input
Discharge planning starts on admission

Data Patterns¶

Primary Care:

Sparse data points over long time
Quarterly A1C values
Annual screening results
Medication list stability
Years of history matters

Hospital:

Dense data over short time
Q4H vital signs
Daily labs
Hourly I&O
Last 48 hours matters most

Patient Agency¶

Primary Care:

Patient is autonomous decision-maker
"I'll think about starting that medication"
Can refuse, delay, negotiate
Shared decision making
Patient manages own care between visits

Hospital:

Patient is dependent on system
"You need this surgery today"
Limited ability to leave AMA
Provider-driven decisions
24/7 professional management

Failure Modes¶

Primary Care:

Missed diagnosis (caught later)
Lost to follow-up
Medication non-adherence
Preventive care gaps
Slow, insidious problems

Hospital:

Rapid decompensation
Medical errors
Hospital-acquired infections
Falls
Immediate life-threatening events

IT Modeling Consequences¶

Primary Care EMRs must handle:

40-year histories
Flexible, narrative documentation
Population health across thousands
Appointment scheduling complexity
Prescription management over years
Family/social context

Hospital EMRs must handle:

Minute-by-minute documentation
Real-time order management
Bed/resource optimization
Intensive device integration
Rapid care transitions
Multi-disciplinary rounding

This is why I keep saying hospital-designed standards like FHIR struggle in primary care:

Encounters make sense when a patient is IN a bed for days
Episodes make sense for surgical admissions with clear start/end
Real-time coordination is assumed because everyone's in the same building
Dense data collection expected because nurses document every hour
Clear boundaries assumed (admission/discharge) that don't exist in primary care

3. Population Health Management¶

Primary care clinics manage panels of 1,000-2,500 patients per physician:

Panel management: Tracking who needs what care when
Quality metrics: Meeting targets for screening, chronic disease management
Risk stratification: Identifying high-risk patients for proactive intervention
Registry functions: Diabetes registries, cancer screening lists
Recall systems: Bringing patients back for overdue care

4. Care Coordination Hub¶

Primary care serves as the medical home:

Referral management: Coordinating specialist consultations
Care transitions: Hospital discharge follow-up, post-ED visits
Multi-disciplinary teams: Nurses, pharmacists, social workers, dietitians
Community resources: Connecting to social services, home care

5. Time-Constrained Encounters¶

The 15-minute visit creates unique pressures:

Multiple concerns per visit: "While I'm here, can you also look at..."
Documentation burden: Charting takes as long as the visit
Cognitive load: Switching between pediatric vaccines and geriatric polypharmacy
Interruption-driven workflow: Phone calls, urgent walk-ins, lab results

Primary Care Clinical Workflows¶

Daily Workflow Patterns¶

Morning Huddle (7:30-8:00 AM)¶

Review day's schedule for complex patients
Identify care gaps and preventive needs
Coordinate team responsibilities
Review overnight hospital admissions/discharges

Clinical Sessions (8:00 AM - 5:00 PM)¶

Scheduled Visits (70%)

Chronic disease management (20-30 min)
Annual physicals (30-45 min)
Well-child checks (15-20 min)
Follow-ups (10-15 min)

Same-Day Access (30%)

Acute illness slots
Urgent concerns
Medication refills
Form completions

Between-Visit Work¶

Inbox management: Lab results, specialist reports, patient messages
Prescription refills: 20-50 per day
Prior authorizations: Insurance approvals
Care planning: Complex case management

End-of-Day Tasks¶

Documentation completion: Finishing notes
Results review: Acting on critical values
Tomorrow prep: Pre-visit planning

Weekly/Monthly Cycles¶

Weekly

Team meetings for complex patients
Quality improvement reviews
Student/resident teaching

Monthly

Panel reports review
Chronic disease registries
Performance metrics
Billing reconciliation

Annual Cycles¶

Flu season (Sept-March): Vaccination campaigns
Wellness visits: Birthday month physicals
School/camp physicals (May-August)
Medicare wellness visits (Year-round)

FHIR Resources for Primary Care¶

Core Patient Management¶

Patient Resource¶

Central to everything in primary care:

{
  "resourceType": "Patient",
  "identifier": [
    {
      "system": "Provincial Health Number",
      "value": "123456789"
    },
    {
      "system": "EMR Patient ID",
      "value": "EMR-PAT-001"
    }
  ],
  "name": [{
    "family": "Smith",
    "given": ["John", "Michael"]
  }],
  "telecom": [
    {"system": "phone", "value": "555-0123"},
    {"system": "email", "value": "patient@email.com"}
  ],
  "generalPractitioner": [{
    "reference": "Practitioner/dr-jones"
  }]
}

Encounter Resource (THEORETICAL - NOT REALITY)¶

Let me be clear: In my 18 years working with primary care EMRs, I've NEVER seen one that actually models encounters the way FHIR expects.

What FHIR thinks we have:

Office visits as discrete encounters
Clear start and end times
One problem per encounter
Clean boundaries

What I actually see in every primary care EMR:

SOAP notes: Often multiple per day, loosely timestamped
Appointment slots: Which may or may not match when the patient was actually seen
Daily sheets: Everything that happened today, somehow
Billing codes: The only thing that HAS to be structured (money talks)
A mess of documents: Referrals, prescriptions, forms, all loosely associated with "today"

How we fake "Encounters" for FHIR:

Appointment (if it exists) + 
Any notes from that day +
Prescriptions from that day +
Orders from that day +
Billing codes (the only reliable timestamp)
= Synthetic Encounter resource we pretend is real

I've seen this problem at every EMR vendor: A single day might have:

Multiple SOAP notes (different issues)
Phone call documentation
Prescription refills done between patients
Lab reviews during lunch
Insurance forms completed after hours

Is that one encounter or five? The EMR doesn't know. The doctor doesn't care. But FHIR demands an answer.

EpisodeOfCare Resource (NOT USED IN PRIMARY CARE)¶

This is a FHIR fiction for primary care.

Why it doesn't work:

Primary care is continuous, not episodic
Chronic conditions don't have clear start/end
Problems overlap and interact
Pregnancy might be the only "episode" that makes sense
Mental health is ongoing, not discrete episodes

What primary care actually tracks:

Problem lists: Active/inactive/resolved
Chronic disease registries: Diabetes cohort, HTN cohort
Care plans: But not linked to "episodes"

Clinical Documentation (What Actually Works)¶

DocumentReference Resource (The Real MVP)¶

This is what primary care EMRs actually have:

Clinical notes (SOAP, progress notes)
Scanned documents
Faxed reports
Consultation letters
Forms and assessments

{
  "resourceType": "DocumentReference",
  "type": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "34117-2",
      "display": "History and physical note"
    }]
  },
  "content": [{
    "attachment": {
      "contentType": "text/plain",
      "data": "U09BUCBOb3RlOiBQYXRpZW50IHByZXNlbnRzIHdpdGgg..."
    }
  }],
  "context": {
    "period": {
      "start": "2025-01-08T09:00:00Z",
      "end": "2025-01-08T09:15:00Z"
    }
  }
}

Observation Resource¶

The workhorse of primary care data:

Vital signs: BP, weight, temperature
Lab results: CBC, lipids, A1C
Assessments: PHQ-9, GAD-7, AUDIT
Social history: Smoking, alcohol, exercise
Family history: Cancer, heart disease

Condition Resource¶

Problem list management:

Profile: PrimaryCareProblem
Parent: Condition

* clinicalStatus MS
* verificationStatus MS
* category = $condition-category#problem-list-item
* code from PrimaryCareDiagnosisVS (extensible)
* onset[x] MS
* recordedDate MS
* recorder only Reference(PrimaryCareProvider)

Procedure Resource¶

Documents office procedures:

Immunizations
Joint injections
Skin biopsies
IUD insertions
Wound care

Medication Management (The Physician vs Pharmacy Divide)¶

The Fundamental Disconnect¶

What Physicians Think About:

Clinical intent: "Control blood pressure"
Therapeutic class: "ACE inhibitor"
Dosing strategy: "Start low, titrate up"
Duration: "3 months then reassess"
Patient instructions: "Take with food if stomach upset"
Clinical flexibility: "Take 1-2 tabs as needed for pain"

What Pharmacists Think About:

Specific product: "APO-RAMIPRIL 5mg tablets (DIN 02371235)"
Package size: "Bottle of 100"
Inventory management: "3 boxes in stock"
Insurance codes: "Coverage under Plan G"
Dispensing rules: "Maximum 90-day supply"
Exact count: "Dispense 90 tablets"

How FHIR Models Medications (Pharmacy-Centric)¶

{
  "resourceType": "Medication",
  "code": {
    "coding": [{
      "system": "https://fhir.infoway-inforoute.ca/CodeSystem/canadiandrug",
      "code": "02371235",
      "display": "APO-RAMIPRIL 5MG TABLET"
    }]
  },
  "form": {
    "coding": [{
      "system": "http://snomed.info/sct",
      "code": "385055001",
      "display": "Tablet"
    }]
  },
  "ingredient": [{
    "itemCodeableConcept": {
      "coding": [{
        "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
        "code": "35296",
        "display": "ramipril"
      }]
    },
    "strength": {
      "numerator": {"value": 5, "unit": "mg"},
      "denominator": {"value": 1, "unit": "tablet"}
    }
  }]
}

This level of detail is IRRELEVANT to physicians who just want to write "Ramipril 5mg daily"

The DIN Problem (Canadian Context)¶

Physicians prescribe:

"Metformin 500mg BID"

Pharmacy reality:

APO-METFORMIN 500mg (DIN 02099233)
TEVA-METFORMIN 500mg (DIN 02223687)
GLUCOPHAGE 500mg (DIN 00272809)
JAMP-METFORMIN 500mg (DIN 02380978)

Each DIN is a different:

Manufacturer
Package size
Price point
Insurance coverage
Physical appearance

Physicians DON'T CARE - they want metformin to lower glucose. The pharmacy chooses the DIN based on insurance, availability, and patient preference.

MedicationRequest - The Compromise That Pleases No One¶

What physicians want to write:

Ramipril 5mg daily
#90 days
Refills: 3
"For blood pressure"

What FHIR MedicationRequest requires:

{
  "resourceType": "MedicationRequest",
  "medicationCodeableConcept": {
    "text": "Ramipril 5mg"  // What MD wrote
  },
  "dosageInstruction": [{
    "text": "Take 1 tablet daily",
    "timing": {
      "repeat": {
        "frequency": 1,
        "period": 1,
        "periodUnit": "d"
      }
    },
    "doseAndRate": [{
      "doseQuantity": {
        "value": 1,
        "unit": "tablet"
      }
    }]
  }],
  "dispenseRequest": {
    "quantity": {
      "value": 90,
      "unit": "tablets"
    },
    "numberOfRepeatsAllowed": 3
  }
}

What pharmacy systems need:

{
  "resourceType": "MedicationDispense",
  "medicationCodeableConcept": {
    "coding": [{
      "system": "DIN",
      "code": "02371235",
      "display": "APO-RAMIPRIL 5MG (100 TABLETS)"
    }]
  },
  "quantity": {
    "value": 90,
    "unit": "tablets"
  },
  "daysSupply": {
    "value": 90,
    "unit": "days"
  },
  "substitution": {
    "wasSubstituted": true,
    "type": {
      "coding": [{
        "code": "G",
        "display": "Generic substitution"
      }]
    }
  }
}

The "Instructions to Patient" Problem¶

Physician writes: "Take as directed"

Means: "We discussed this, you know what to do"
Assumes: Clinical context and verbal instructions
Allows: Patient adjustment based on response

Pharmacy requires: Exact, unambiguous instructions

"Take 1 tablet by mouth once daily"
No room for interpretation
Legal/liability requirements

FHIR tries to handle both:

dosageInstruction.text - What MD wrote
dosageInstruction.timing - Structured for pharmacy
dosageInstruction.patientInstruction - Additional context

But often these conflict or duplicate each other awkwardly.

MedicationStatement - What Patients Actually Do¶

The gap between prescribed and taken:

Prescribed: "Metformin 500mg BID"
Actually taking: "I take it once because twice upsets my stomach"
Also taking: "Generic Tylenol from Costco when needed"
Traditional remedy: "Chinese herbs from my acupuncturist"

Primary care EMRs rarely capture this well. FHIR MedicationStatement exists but is rarely populated accurately.

Laboratory & Diagnostic Ordering (The Physician vs Lab Divide)¶

The Granularity Mismatch¶

What Physicians Order:

"CBC" (Complete Blood Count)
"Lytes" (Electrolytes)
"Thyroid panel"
"Lipids"
"A1C"
"Urine R&M" (Routine & Microscopy)

What Labs Actually Run:

"CBC" explodes into:

- WBC count
- WBC differential (5+ subtypes)
- RBC count
- Hemoglobin
- Hematocrit
- MCV, MCH, MCHC
- RDW
- Platelet count
- MPV
- Maybe reticulocytes
- Maybe nucleated RBCs

Physician reaction: "I just wanted to know if they're anemic"

The Lab Process (That Physicians Don't Care About)¶

Lab's Complex Workflow:

Sample collection (which tube? what preservative?)
Sample processing (centrifuge? temperature?)
Sample splitting (chemistry vs hematology vs micro)
Analyzer assignment (which machine?)
Quality control runs
Result generation
Result verification
Delta checks (comparison to previous)
Critical value flagging
Pathologist review (if needed)
Final sign-off

Physician's View:

Ordered test → Got result
Everything else is a black box

FHIR's Lab-Centric Model¶

{
  "resourceType": "ServiceRequest",
  "code": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "58410-2",
      "display": "Complete blood count (hemogram) panel - Blood by Automated count"
    }]
  },
  "specimen": [{
    "reference": "Specimen/edta-tube-1"
  }],
  "bodySite": {
    "coding": [{
      "system": "http://snomed.info/sct",
      "code": "368208006",
      "display": "Left antecubital vein"
    }]
  }
}

Physician: "Why do I need to specify the vein? Just get blood!"

The Specimen Problem¶

FHIR Specimen Resource includes:

Collection time
Collector
Body site
Method
Container type
Preservatives
Processing steps
Storage conditions

Primary care physician knows:

"Patient needs bloodwork"
Maybe "fasting" or "not fasting"
That's it

Lab needs all the specimen details for:

Accreditation requirements
Chain of custody
Troubleshooting bad results
Legal documentation

The Preliminary vs Final Results Nightmare¶

In Hospitals:

Preliminary Result (2 hours): Troponin 0.08
Critical value! Notify physician!
Final Result (4 hours): Troponin 0.08 (confirmed)

This matters - treatment decisions hang on preliminary results.

In Primary Care:

Monday 3 PM: Preliminary TSH: 4.2
Monday 5 PM: Final TSH: 4.3
Tuesday 8 AM: Physician reviews inbox
"Why am I seeing this twice?"
"Did something change?"
"Do I need to act on both?"

The Medical-Legal Problem:

Every result hitting the inbox = physician responsibility to review
Preliminary + final = double the review burden
Missing a critical value = lawsuit
But 99% of preliminary → final changes are clinically irrelevant

How Different Systems Handle Results¶

Hospital Laboratory Information System (LIS):

{
  "resourceType": "DiagnosticReport",
  "status": "preliminary",
  "result": [{
    "reference": "Observation/wbc-prelim"
  }],
  "performer": [{
    "actor": {"display": "Analyzer #3"}
  }],
  "resultsInterpreter": [{
    "actor": {"display": "Auto-verification algorithm v2.3"}
  }]
}

What Primary Care EMR Wants:

{
  "resourceType": "DiagnosticReport",
  "status": "final",  // Only final, please!
  "conclusion": "Normal CBC",
  "result": [{
    "display": "WBC: 7.2 (Normal)"  // Just the basics
  }]
}

The Reference Range Complexity¶

Lab Perspective:

Age-specific ranges
Sex-specific ranges
Ethnicity adjustments
Pregnancy adjustments
Method-specific ranges
Time-of-day variations

Physician Perspective:

Is it normal? (green)
Is it abnormal? (red)
Is it critical? (call me)

Radiology: Even Worse¶

Physician orders: "CXR" (Chest X-ray)

Radiology needs:

Clinical indication (detailed)
Comparison studies available?
Portable or department?
One view or two views?
Inspiration/expiration?
Contrast allergies (even for plain films)
Pregnancy status
Insurance pre-authorization

Radiology workflow generates:

Order acknowledgment
Scheduled notification
Performed notification
Preliminary read (by resident)
Attending addendum
Final report
Maybe critical finding alert
Maybe incidental finding alert

Primary care physician: "Just tell me if there's pneumonia!"

The Microbiology Special Case¶

Physician orders: "Urine C&S" (Culture & Sensitivity)

Lab generates over 3-5 days:

Day 0: Received
Day 1: Preliminary growth detected
Day 2: Organism identification "Probable E. coli"
Day 3: Final ID "E. coli >100,000 CFU/mL"
Day 3.5: Preliminary sensitivities
Day 4: Final sensitivities with MICs
Day 5: Amended report with additional organism

Each update generates a new result hitting the physician's inbox.

Primary care reality:

Started empiric antibiotics on Day 0
Patient feeling better by Day 3
All these updates are noise unless resistant

Why This Matters for FHIR Implementation¶

FHIR assumes everyone wants:

Detailed specimen tracking
Granular test components
All preliminary results
Full workflow visibility
Method and performer details

Primary care physicians want:

Final results only
Clinically grouped (CBC, not 15 components)
Abnormal flagging
Minimal inbox burden
"Just tell me what I need to know"

The implementation challenge:

Can't ignore lab requirements (accreditation, legal)
Can't overwhelm physicians (burnout, errors)
Need different views for different users
Must maintain medical-legal documentation

Primary Care EMR Operational Realities (The Stuff Nobody Talks About)¶

These are the unglamorous realities I've dealt with for years that FHIR completely ignores:

The Manitoba Problem (And Similar Provincial Quirks)¶

I discovered this gem when building a system for Manitoba clinics:

Manitoba Health Cards have TWO numbers:

Personal Health Identifier: 123456789
Family Registration Number: 9876543

Why this breaks FHIR:

Patient.identifier assumes one identifier per system
Which one is "the" Manitoba health number? (Spoiler: you need both)
Family linkages matter for billing—kids share family numbers
Good luck explaining this to a FHIR validator

I've found similar insanity everywhere:

Quebec: Health card has a version code letter that changes
Ontario: Version codes that expire and renew
Military families: CFOne cards with dependent suffixes
First Nations: Some patients have federal AND provincial numbers

The Physician Liability Trap¶

Legal Reality: "Physicians are responsible for EVERY piece of information entering their EMR"

This creates the Review Everything Problem:

Monday morning inbox:

- 47 lab results (including 12 preliminary versions)
- 23 hospital discharge summaries
- 18 specialist consult notes  
- 31 prescription renewal requests
- 14 diagnostic imaging reports
- 8 home care reports

= 141 items requiring physician review and action

The Push Data Problem:

Auto-filing lab results = physician might miss critical value
Auto-importing hospital data = physician liable for missed diagnosis buried on page 47
Every automation = potential liability

Result: Everything flows through manual review, creating massive bottlenecks.

The Coding Compliance Disaster¶

Why Physicians Don't Code Properly:

No immediate feedback loop
- Code diabetes wrong → EMR still works
- No error message
- No patient impact
- Physician never knows

50 Ways to Code Diabetes:

- "DM2"
- "Type 2 diabetes"
- "NIDDM"
- "Diabetes mellitus type 2"
- "T2DM"
- "Adult onset diabetes"
- "250.00" (ICD-9)
- "E11.9" (ICD-10)
- SNOMED: 44054006
- Problem list: "Sugar"

Downstream Consumer Rage:
- Quality metrics can't find diabetics
- Population health reports miss half the patients
- Research data is garbage
- "Why can't doctors just code properly?!"

The LLM Hope:

Auto-suggest codes from clinical notes
Real-time validation
"Did you mean Type 2 Diabetes (E11.9)?"
But requires physician trust and workflow integration

The Paper/Fax Reality¶

Primary Care's Dirty Secret: It's Still 30% Paper

Daily paper influx:

Specialist letters (faxed)
Lab requisitions (paper)
Insurance forms (paper)
School forms (paper)
Hospital records (faxed)
Prescription pads (paper backup)
Consent forms (wet signatures)

What EMRs Need But Don't Have:

Industrial-strength scanning workflows
Fax-to-chart integration
Smart OCR with field extraction
Form fill automation
Signature management

Why It Gets Ignored:

Not sexy for vendors
"We're going paperless!" (No, you're not)
Hospitals went paperless (different workflow)
Young developers don't understand fax machines still exist

FHIR's Response:

{
  "resourceType": "DocumentReference",
  "content": [{
    "attachment": {
      "contentType": "application/pdf",
      "title": "Scanned document"
    }
  }]
}

That's it. No workflow, no extraction, no intelligence.

The Single Screen Problem¶

What Physicians Need in One View:

┌─────────────────────────────────────────┐
│ Patient: John Smith, 67yo, DM2, HTN    │
├─────────────────────────────────────────┤
│ ALERTS: Penicillin allergy, Fall risk  │
├─────────────────────────────────────────┤
│ OPEN TASKS:                            │
│ □ Review cardiology report (NEW)       │
│ □ Refill metoprolol (DUE TODAY)       │
│ □ Call about A1C result (2 days old)  │
├─────────────────────────────────────────┤
│ NEW SINCE LAST VISIT (Nov 15):        │
│ • Cardiology consult - Afib (Dec 1)   │
│ • ER Visit - Chest pain (Nov 28)      │
│ • Labs - A1C 8.2↑ (Nov 22)           │
│ • Imaging - CXR normal (Nov 29)       │
├─────────────────────────────────────────┤
│ TODAY'S VISIT: Follow-up diabetes     │
└─────────────────────────────────────────┘

What EMRs Actually Show:

Tab 1: Demographics
Tab 2: Allergies (click to expand)
Tab 3: Medications (separate screen)
Tab 4: Problems (outdated)
Tab 5: Labs (sort by date? type?)
Tab 6: Documents (500 items, unsorted)
Tab 7: Tasks (somewhere)

Physicians end up:

Opening 15 windows
Missing critical information
Spending 5 minutes just finding things
Suffering

The Task vs Message Problem¶

What Should Happen:

Every EMR item = Task with:

- Single owner (responsible party)
- Status (pending/completed)
- Due date
- Escalation path
- Audit trail

What Actually Happens:

Mixed metaphors:

- "Messages" (like email)
- "Communications" (chat-like)
- "Notifications" (FYI)
- "Tasks" (some things)
- "Reminders" (post-its)
- "Flags" (alerts)

Result: Things slip through cracks because ownership is unclear.

FHIR's Confusion:

Task resource (workflow)
Communication resource (messaging)
CommunicationRequest (orders?)
Flag resource (alerts)

Which one for "Please refill Mr. Smith's metoprolol"?

The Integration Theater¶

What vendors promise: "Seamless interoperability with all systems!"

What actually happens:

Hospital System → HL7v2 → Interface Engine → 
Custom Transform → CSV → FTP → Batch Process → 
Manual Review → Import Queue → Physician Review → 
Maybe Gets Into Chart

Each integration is:

Custom built
Fragile
Undocumented
Breaks with upgrades
Has edge cases

FHIR's promise: Standards will fix this! Reality: Now we have HL7v2 AND FHIR to maintain

The Workflow Interruption Crisis¶

A 15-minute appointment actually involves:

Pre-visit (5 min):

- Review chart
- Check new results
- Note outstanding items

Visit (15 min):

- See patient
- Multiple problems
- Document while talking

Post-visit (10 min):

- Finish documentation
- Order tests
- Send referrals
- Do billing
- Answer nurse question
- Sign prescriptions

Interruptions:

- Phone: "Pharmacy on line 2"
- Nurse: "Can you look at this rash?"
- Lab: "Critical value on patient X"
- Reception: "Patient angry in waiting room"

Total: 30+ minutes per 15-minute slot

EMRs need to support this chaos, not pretend it doesn't exist.

Care Coordination¶

ServiceRequest¶

Referrals and orders are two different shapes, and the IG profiles them separately -- see Referrals. An order carries authorization (intent = order); a referral asks a receiving service to accept the patient and carries none (intent = proposal), which is also why its category is the destination rather than one of the five base FHIR service categories:

Profile: PrimaryCareReferral
Parent: ServiceRequest

* status MS
* intent = #proposal          // not #order -- the referrer does not control acceptance
* priority MS
* category from ReferralServiceTypeVS (extensible)   // the receiving service
* code 0..1                   // optional: the Ontario eReferral contract sends none
* reasonCode MS
* reasonReference MS
* supportingInfo MS  // Prior tests, notes
* note MS  // "Please see this patient for..."

Communication Resource¶

Inter-provider messaging:

Specialist consult responses
Care team coordination
Patient portal messages

CarePlan Resource¶

Comprehensive care planning:

Annual care plans
Chronic disease action plans
Preventive care schedules
Mental health treatment plans

Population Health¶

Group Resource (Patient Panels)¶

Panel/roster management:

{
  "resourceType": "Group",
  "type": "person",
  "actual": true,
  "name": "Dr. Smith's Panel",
  "characteristic": [{
    "code": {
      "coding": [{
        "system": "panel-characteristic",
        "code": "diabetes-registry"
      }]
    },
    "valueBoolean": true
  }],
  "member": [
    {"entity": {"reference": "Patient/123"}},
    {"entity": {"reference": "Patient/456"}}
  ]
}

Task Resource¶

Care gap tracking:

Overdue mammograms
Missing immunizations
Annual lab work needed
Medication reviews due

Flag Resource¶

Patient alerts:

Fall risk
Substance use disorder
Frequent ED user
Complex care needs

Administrative¶

Schedule/Slot/Appointment¶

Complex scheduling needs:

Multiple provider schedules
Different visit types/durations
Same-day access slots
Group visit scheduling

Coverage Resource¶

On-call and coverage arrangements:

After-hours coverage
Vacation coverage
Shared patients in group practice

Organization & Location¶

Multi-site practices:

Main clinic
Satellite offices
Hospital privileges
Nursing home rounds

Canadian Primary Care Context¶

Healthcare System Structure¶

Provincial Health Insurance¶

Each province manages healthcare differently:

Alberta: Alberta Health Care Insurance Plan (AHCIP)
Ontario: Ontario Health Insurance Plan (OHIP)
British Columbia: Medical Services Plan (MSP)
Quebec: Régie de l'assurance maladie (RAMQ)

Primary Care Models¶

Fee-for-Service (FFS)

Traditional model
Paid per service/visit
No formal rostering
~30% of practices

Family Health Teams (FHT)

Interdisciplinary teams
Salary/blended payment
Formal rostering
Ontario-specific

Primary Care Networks (PCN)

Alberta model
Team-based care
Panel management
Quality improvement focus

Family Health Groups/Organizations (FHG/FHO)

Capitation-based
After-hours requirements
Rostering bonuses
Ontario models

Patient Rostering/Paneling¶

What is Rostering?¶

Formal patient-provider attachment where:

Patients commit to seeking care primarily from their rostered provider
Providers commit to providing comprehensive care
Enables population health management
Supports alternative payment models

CPAR (Central Patient Attachment Registry) - Alberta¶

Tracks patient-provider relationships:

Panel size and composition
Continuity metrics
Access measures
Quality indicators

CPAR Data Elements:

Patient demographics
Provider identifiers
Attachment dates
Last visit dates
Panel status

Rostering Challenges¶

Multiple attachments: Patients seeing multiple providers
Ghost patients: Rostered but not seen
Churn: Patients switching providers
Snowbirds: Seasonal residents
Walk-in clinics: Episodic care outside medical home

EMR Landscape in Canada¶

Major EMR Vendors¶

TELUS Health

PS Suite (formerly Healthquest)
Med Access
Wolf EMR
~40% market share

OSCAR

Open-source
Strong in Ontario
WELL Health's Oscar Pro
~15% market share

Accuro (QHR Technologies)

Western Canada focus
Integrated billing
~20% market share

Other Players

Jonoke
PracticeSolutions
MedSys
IntraHealth Profile

EMR Certification Programs¶

OntarioMD

EMR certification program
Funding for certified EMRs
Standards for interoperability
Clinical data standards

Alberta Netcare

Provincial EHR
EMR integration requirements
Pin (Patient information network)

Canadian FHIR Initiatives¶

CA Core (CA-Core+)¶

Canadian base profiles:

Provincial identifier systems
Bilingual requirements
Canadian terminology (pCLOCD)
Privacy/consent models

Infoway Standards¶

Canada Health Infoway initiatives:

PrescribeIT (e-prescribing)
ACCESS Gateway
Terminology services
Clinical document standards

Provincial Projects¶

Alberta

Connect Care (provincial system)
CII (Clinical Information Integration)
CPAR integration

Ontario

HRM (Health Report Manager)
OLIS (lab system)
DHDR (drug repository)

British Columbia

CareConnect
PharmaNet
Clinical Context Viewer

Implementation Challenges¶

The Reality Gap: FHIR vs Primary Care EMRs¶

Let me show you the disconnect I deal with every day:

What FHIR Assumes vs What I Actually See¶

FHIR's Hospital-Centric Model:

Discrete encounters with clear boundaries
Episodes of care with start/end dates
Structured data in every field
Clean referential integrity
One problem = one condition

What I See in Every Primary Care EMR:

Notes are king: Everything—and I mean EVERYTHING—revolves around the clinical note
Appointments are fiction: That 2 PM slot? Patient came at 3:30. The walk-in at 11? No appointment at all
Documents everywhere: Faxes (yes, faxes!), scanned papers, PDFs, letters—half the chart is unstructured
Billing drives structure: The ONLY thing that's reliably coded is what gets paid
Day-based organization: "What happened on Tuesday?" not "What was encounter #12345?"

The Encounter Synthesis Problem¶

Primary care EMRs don't have encounters. They have:

Day Sheet:

- 9:00 AM - SOAP note for diabetes follow-up
- 9:15 AM - Prescription renewal (metformin)
- 10:30 AM - Phone call about lab results
- 11:00 AM - SOAP note for URI
- 11:10 AM - Prescription (amoxicillin)
- 2:00 PM - Insurance form completion
- 3:30 PM - Lab result review & action

FHIR expects this to become structured Encounter resources. But:

Is the whole day one encounter?
Is each SOAP note an encounter?
Are the prescriptions part of the SOAP encounter or separate?
What about the insurance form?

Common "solutions" that don't work well:

Creating one encounter per day (loses granularity)
Creating one encounter per note (misses related activities)
Creating encounters from appointments (misses walk-ins, phone calls)
Creating encounters from billing (non-billable activities disappear)

Technical Challenges¶

Version Fragmentation¶

EMRs on different FHIR versions (DSTU2, STU3, R4, R5)
Incomplete resource support
Varying implementation maturity
Migration complexity

Performance Issues¶

Real-world performance varies widely:

Epic: 1,555-2,500 resources/minute
Custom HIE: 12,000 resources/minute
API rate limiting
Bulk data export delays

Data Quality¶

Primary care data is notoriously messy:

Free-text entries
Inconsistent coding
Missing data elements
Historical data migration issues

Semantic Interoperability¶

Same concept, different representations:

Local codes vs. standard terminologies
Measurement units variations
Temporal granularity differences
Context-dependent meanings

Workflow Challenges¶

Time Pressures¶

15-minute visits leave no time for data entry
Documentation happens after hours
Copy-paste propagates errors
Template fatigue

Cognitive Overload¶

Alert fatigue from decision support
Information scatter across screens
Context switching between patients
Multitasking during visits

Team Coordination¶

Multiple users, one chart
Conflicting documentation
Handoff complexity
Role-based access confusion

Organizational Challenges¶

Change Management¶

Provider resistance to new systems
Training requirements
Workflow disruption
Productivity loss during transition

Resource Constraints¶

Small practice IT budgets
Limited technical expertise
Competing priorities
Vendor lock-in

Regulatory Compliance¶

Provincial privacy laws (PHIPA, HIA, PIPA)
Professional college requirements
Billing rule complexity
Quality reporting mandates

Data Challenges¶

Longitudinal Data Management¶

Decades of historical data
Data migration from paper
Multiple EMR transitions
Archive accessibility

Patient Matching¶

No universal patient identifier
Name changes
Address changes
Duplicate records

Granular consent requirements
Proxy consent for minors
Substitute decision makers
Consent withdrawal tracking

Success Patterns¶

Implementation Best Practices¶

Start Small, Scale Gradually¶

Pilot with willing early adopters
Focus on high-value use cases
Iterate based on feedback
Roll out in phases

Prioritize Workflow Integration¶

Map FHIR to existing workflows
Minimize disruption
Automate where possible
Preserve efficiency gains

Invest in Data Quality¶

Clean historical data
Standardize coding practices
Implement validation rules
Regular data audits

Technical Patterns¶

Resource Composition¶

Aggregate related data efficiently:

Profile: PrimaryCareEncounterBundle
Parent: Bundle

* type = #document
* entry ^slicing.discriminator.type = #type
* entry ^slicing.discriminator.path = "resource"
* entry contains
    composition 1..1 and
    encounter 1..1 and
    observations 0..* and
    conditions 0..* and
    medications 0..*

Longitudinal Data Organization¶

Track changes over time:

{
  "resourceType": "Observation",
  "code": {"coding": [{"code": "55284-4", "system": "LOINC"}]},
  "effectiveDateTime": "2025-01-08",
  "valueQuantity": {"value": 130, "unit": "mmHg"},
  "derivedFrom": [{
    "reference": "Observation/previous-bp"
  }]
}

Panel Management Queries¶

Identify care gaps:

-- Pseudo-query for overdue diabetics
SELECT patient
FROM Patient p
JOIN Observation o ON p.id = o.subject
WHERE o.code = 'A1C'
  AND o.effectiveDateTime < (TODAY - 3 MONTHS)
  AND p.condition.code = 'Diabetes'

Organizational Patterns¶

Governance Structure¶

Clinical leadership engagement
Technical working groups
User advisory committees
Regular feedback cycles

Training Programs¶

Role-based training
Workflow-specific modules
Peer champions
Continuous education

Quality Improvement¶

Measure baseline metrics
Set realistic targets
Regular monitoring
Celebrate successes

Canadian-Specific Patterns¶

Provincial Alignment¶

Follow CA-Core+ profiles
Use provincial identifier systems
Align with provincial EHRs
Respect jurisdictional requirements

Bilingual Support¶

* name.text 0..1 MS
* name.text ^short = "Text representation"
* name.text ^definition = "Full name in official language"
* name.extension contains
    translation named translation 0..* MS

Indigenous Health¶

Cultural safety considerations
Traditional healing integration
Community-based care models
Jurisdictional complexities

Future Directions¶

Emerging Trends¶

AI/ML Integration¶

Clinical decision support
Predictive analytics
Natural language processing
Automated coding

Patient Engagement¶

Portal integration
Wearable data
Patient-reported outcomes
Shared decision making

Value-Based Care¶

Outcome measurement
Cost tracking
Quality metrics
Risk adjustment

FHIR Evolution¶

R5 and Beyond¶

Improved workflow resources
Better terminology services
Enhanced consent management
Subscription improvements

Bulk Data Access¶

Population analytics
Research datasets
Quality reporting
Public health surveillance

SMART on FHIR¶

App ecosystem
Clinical decision support
Patient apps
Provider tools

Canadian Roadmap¶

National Initiatives¶

Pan-Canadian interoperability
National patient identifier discussions
Federal health data strategy
Indigenous health governance

Provincial Convergence¶

Shared standards adoption
Cross-provincial data exchange
Harmonized consent models
Coordinated care across borders

Primary Care Transformation¶

Team-based care models
Virtual care integration
Community health hubs
Social prescribing

Insights from My Published Work (2012-2013)¶

Back when I was writing for Technology for Doctors and Healthcare Information Management, I documented these patterns:

The Banking vs Healthcare Interoperability Paradox¶

From my 2012 article "Interoperability: Banking did it... how hard can it be?"

Why Banking Succeeded: I found it's simple—they had:

Clear financial incentive (everyone makes money on transactions)
Limited data types (just numbers and dates)
Standardized transactions (debit/credit, that's it)
Central authority (central banks mandate standards)
Trust through regulation

Why Healthcare Fails: Meanwhile, in healthcare, I've seen:

No revenue from sharing data (it actually costs money)
Infinitely complex, contextual data
Every patient is unique
No central authority (provincial chaos)
Privacy laws that block sharing

The Data Liberation Principle¶

"Data liberation now, Interoperability standards later" (2013)

The pragmatic approach:

Don't wait for perfect standards
Get data OUT first (even as PDFs)
Let receiving systems figure out import
Perfect is the enemy of good
Patient access drives change

What actually works:

Simple CSV exports
PDF summaries
Patient-downloadable records
Basic API access
"Good enough" data portability

The Translation Problem¶

"It loses something in translation" (2013)

Clinical context doesn't translate:

"Stable" means different things in ICU vs primary care
"Mild" pain to surgeon ≠ "mild" to patient
Lab "normal" varies by population
Medication "as directed" assumes verbal context

Result: Perfectly transmitted data can still be clinically wrong.

Hospital vs Clinic EMRs: Fundamental Differences¶

From my 2013 article "Hospital vs clinic EMRs: What's the difference?"

I learned that Hospital EMRs optimize for:

Bed management (beds are the scarce resource)
Shift handoffs (nurses change every 8 hours)
Department coordination (everyone's in the building)
Acute decision support (seconds matter)
Billing by episode (DRGs)

While Clinic EMRs optimize for:

Volume throughput (see 30+ patients/day)
Longitudinal records (decades of history)
Prescription management (refills for years)
Preventive care reminders (mammograms due)
Billing by service (fee codes)

My key insight: "Hospitals are hotels with medical services. Clinics are medical services without beds." This fundamental difference drives everything.

The Quality vs Cost Trap¶

"Quality of care versus cost of care: The awkward choice" (2012)

The uncomfortable truth:

Better documentation ≠ better care
More data entry = less patient interaction
Perfect coding = physician burnout
Comprehensive records = information overload

The paradox: Systems optimized for quality metrics often degrade actual care quality.

The Asynchronous Bilateral Cutover Problem¶

"What does asynchronous bilateral cutover have to do with improved health care?" (2013)

The migration nightmare:

Can't switch all users simultaneously
Old system must talk to new system
Data exists in two places
Users work in both systems
Errors multiply at boundaries

Healthcare specific challenges:

Can't have downtime (24/7 care)
Can't lose historical data
Can't retrain everyone at once
Can't risk patient safety

Result: Migrations take years and often fail.

The "Don't Just Do Something" Principle¶

"Don't just do something - Stand there!" (2013)

Why healthcare IT should move slowly:

Lives depend on stability
Workflows are complex and interconnected
Unintended consequences are common
Rollback is often impossible
Trust, once broken, doesn't return

The lesson: In healthcare IT, premature action is worse than delayed action.

The Videotex Cautionary Tale¶

"Defunct Videotex reveals pitfalls in creating a healthcare ecosystem" (2012)

Why healthcare ecosystems fail:

Top-down design doesn't match bottom-up reality
Technology-first approaches ignore workflow
Vendor lock-in stifles innovation
Users weren't involved in design
Solutions looking for problems

The pattern: Grand unified platforms always lose to specific, focused tools.

My Key Takeaways After 18 Years¶

Primary Care is Fundamentally Different¶

After building systems for both hospitals and clinics, I can tell you that primary care's comprehensive, longitudinal nature requires completely different thinking. FHIR implementations need to:

Support chaotic, interruption-driven workflows
Handle decades of messy historical data
Work with paper and faxes (yes, still)
Preserve clinical context that can't be coded

The Canadian Context is Unique¶

I've worked across provinces, and the variation is staggering:

Every province has different identifier quirks
Rostering means different things everywhere
Bilingual requirements aren't optional
Indigenous health adds layers of complexity

What Actually Works¶

From my experience, success requires:

Listen to the doctors - They know their workflows better than you
Don't break what works - Even if it's ugly
Data liberation over perfection - Get data out, even as PDFs
Baby steps - Big bang implementations always fail
Embrace the mess - Primary care is messy; your solution should handle that

The Path Forward¶

FHIR will only succeed in primary care when we:

Stop pretending it's a hospital - Ambulatory care is different
Accept that encounters don't exist - They're synthetic constructs
Reduce documentation burden - Not add to it
Handle paper gracefully - It's not going away
Put physicians in control - They're liable for everything

My Final Thought¶

After 18 years in this space, I've learned that primary care EMRs aren't broken—they're evolved. They're messy because primary care is messy. They're complex because they handle everything from birth to death, from psychiatric crises to ingrown toenails, from family dynamics to social determinants.

FHIR, designed in the clean, controlled environment of hospitals, needs to embrace this messiness rather than trying to force primary care into neat, discrete encounters and episodes that simply don't exist in the real world of family medicine.

References¶

Standards Documents¶

HL7 FHIR R4: https://hl7.org/fhir/R4/
CA-Core: https://simplifier.net/ca-core
Nexus EMR Specification: https://fhir.apps.health/
FHIR Shorthand: https://build.fhir.org/ig/HL7/fhir-shorthand/

Canadian Resources¶

Canada Health Infoway: https://www.infoway-inforoute.ca/
OntarioMD: https://www.ontariomd.ca/
Alberta Netcare: https://www.albertanetcare.ca/
CPAR Documentation: Internal Alberta Health Services

Research Papers¶

"The impact of patient rostering on primary care access and continuity" (BMC Primary Care, 2019)
"Canadian Primary Care Sentinel Surveillance Network" (IJPDS, 2019)
"Primary care electronic medical records in Canada" (CMAJ, 2015)
"EMR adoption and data quality in primary care" (BMC Medical Informatics, 2015)

Implementation Guides¶

US Core: https://www.hl7.org/fhir/us/core/
International Patient Summary: http://hl7.org/fhir/uv/ips/
Primary Care Common: https://build.fhir.org/ig/HL7/fhir-pcc/

This document represents the state of FHIR in primary care as of January 2025, with particular emphasis on the Canadian healthcare context and the unique challenges of longitudinal, comprehensive care delivery.