FHIR-Based Hemodialysis Workflows

The Identity Bootstrap: Why PCR Comes First

In any automated clinical system, especially those involving high-frequency data like Hemodialysis, the first failure point is Identity. You cannot predict a fluid-overload trend if you cannot definitively link the sensor data to a verified human being.

In Ontario, this foundation is the Provincial Client Registry (PCR). Managed by Ontario Health (formerly eHealth Ontario) and supported by Canada Health Infoway, the PCR serves as the authoritative source for patient demographics across the province.

The Logic of the Query

To integrate a dialysis system with Ontario’s infrastructure, we follow the CA-ON-PCR R4 Query Implementation Guide. This isn't just a "search box"; it is a set of standardized FHIR operations:

• EMPI Match: Using deterministic and probabilistic logic to resolve identity.

• PIXm (Patient Identifier Cross-reference): Mapping local Hospital MRNs to the Provincial ECID.

• Patient Read: Retrieving the verified demographic “Golden Record.”

If your local database doesn’t reference the ECID, your data is siloed and useless for provincial-level analytics.

graph TD
    %% Identity Phase
    subgraph Identity [Step 1: Identity Verification - Ontario PCR]
        Query[Client System: HCN/MRN Query] -->|FHIR Patient Search/Match| PCR{Provincial Registry}
        PCR -->|Probabilistic| Verify[Manual Data Clerk Verification]
        PCR -->|Deterministic| ActiveID[Verified ECID / Corporate ID]
    end

    %% Clinical Phase
    subgraph Clinical [Step 2: Hemodialysis Encounter]
        ActiveID --> ENC[Encounter: In-Center Dialysis]
        ENC --> PROC[Procedure: Hemodialysis Treatment]
        ENC --> MED[MedicationAdministration: Heparin/Dialysate]
    end

    %% Observation Phase
    subgraph Metrics [Step 3: Clinical Observations]
        PROC --> OBS1[Observation: Ultrafiltration Rate]
        PROC --> OBS2[Observation: Dry Weight Trend]
        PROC --> OBS3[Observation: Access Site Assessment]
    end

    %% Mapping
    Verify --> ActiveID
    style ActiveID fill:#b45309,stroke:#fff,stroke-width:2px,color:#fff
    style PCR fill:#1a1a1a,stroke:#facc15,stroke-width:2px,color:#fff

Mapping the Dialysis Workflow to FHIR R4

Once identity is confirmed via the PCR, we can map the complex telemetry of a dialysis session into structured resources.

1. Longitudinal Trends (Observations)

Instead of a “flat file,” we use the Observation resource to track the 90-day window.

• Session Count: Observation.code = HD-Session-Count | valueInteger = 36.
• Vascular Assessment: Tracking “Access Site Swelling” as an interpreted value (Requires follow-up).

2. The Treatment Event (Procedure & Medication)

A dialysis session is a high-risk event requiring precise logging:

• The Session: Captured via the Procedure resource with specific performedPeriod start/end times.
• Dose Adjustments: If clotting occurs, the MedicationAdministration resource logs the Heparin increase, specifically linking it to the reasonCode from the previous session.

3. Complication Monitoring (Condition)

Intradialytic Hypotension isn’t just a data point; it’s a clinical Condition. By mapping it as active, we ensure it triggers alerts in the next session’s “Look-back Window.”

1. Identity Verification

   PCR Lookup

   Confirmed via **Patient** resource (ECID).
2. Dialysis Session

   Procedure

   Logged as `completed` status.
3. Medication

   MedicationAdministration

   Heparin dose administered.

---

Conclusion: Foundations for Automation

Every dialysis order and treatment record depends on the integrity of the identifiers retrieved from the PCR. By grounding our clinical data in a verified, authoritative identity, we lay the foundation for high-quality, interoperable care across the Canadian continuum.