Skip to content

FHIR Resource Relationships in Primary Care EMRs

Overview

Understanding the relationships between FHIR resources in the context of primary care EMRs is crucial for proper implementation of the Nexus EMR specification. This guide explains how these resources form a hierarchical structure that reflects the reality of EMR system boundaries and organizational relationships.

Resource Hierarchy Diagram

graph TD
    %% Styling
    classDef deviceClass fill:#e1f5e1,stroke:#4caf50,stroke-width:3px,color:#000
    classDef orgClass fill:#e3f2fd,stroke:#2196f3,stroke-width:2px,color:#000
    classDef locClass fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,color:#000
    classDef roleClass fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px,color:#000
    classDef practClass fill:#ffe0e0,stroke:#e91e63,stroke-width:2px,color:#000

    %% Main hierarchy
    Device["🖥️ Device<br/>(EMR Instance)<br/>Root of Tree"]:::deviceClass
    Org["🏢 Organization<br/>(Runs EMR Instance)"]:::orgClass
    Loc1["📍 Location 1<br/>(Site/Department)"]:::locClass
    Loc2["📍 Location 2<br/>(Site/Department)"]:::locClass
    LocN["📍 Location N<br/>(...)"]:::locClass

    PracRole1["👤 PractitionerRole<br/>(EMR User Account)"]:::roleClass
    PracRole2["👤 PractitionerRole<br/>(EMR User Account)"]:::roleClass
    Prac1["👨‍⚕️ Practitioner<br/>(Demographics)"]:::practClass
    Prac2["👩‍⚕️ Practitioner<br/>(Demographics)"]:::practClass

    %% Relationships
    Device -->|"owns/contains"| Org
    Org -->|"has"| Loc1
    Org -->|"has"| Loc2
    Org -->|"has"| LocN

    Org -->|"referenced by"| PracRole1
    Org -->|"referenced by"| PracRole2

    PracRole1 -->|"references"| Prac1
    PracRole2 -->|"references"| Prac2

Core Resources

Device as the Root

The EMR Device resource represents the EMR instance itself and serves as the root of the entire resource hierarchy. This design reflects a fundamental principle:

  • EMR instances are isolated - Information is not shared between EMR instances
  • Complete containment - Each EMR instance contains all related resources
  • Separate user records - When a user works at multiple EMR instances, they have entirely separate records at each

Related Profiles

Organization

The Organization represents the healthcare organization operating a specific EMR instance. Key points:

  • One-to-one with EMR instance - Each EMR instance has exactly one Organization record
  • Multiple instances, multiple records - If an organization runs multiple EMR instances, each gets its own Organization record
  • Unique identifiers - Organization identifiers are globally unique across all instances

For more details on organization identifiers, see Organization References.

Location

Location resources represent physical sites or logical divisions within an organization:

  • Multi-site support - Commonly used for clinics with multiple physical locations
  • Department segregation - Can represent departments or sections within a single facility
  • Variable EMR support - Implementation varies significantly between EMR vendors

See Primary Care EMR Locations for detailed information about location modeling.

Practitioner and PractitionerRole

The relationship between these resources is critical for understanding user management.

Corrected 2026-08-04. An earlier version of this page said PractitionerRole was primary and that Practitioner was "always accessed through a PractitionerRole." That was wrong, and it was load-bearing: it is where the PractitionerRole-primary reading in this IG originated, and it kept getting re-derived from here long after the model changed. Practitioner is the primary provider identity. PractitionerRole is the tenant-scoped role binding, used when the clinic/role relationship is the thing being asserted.

Practitioner (Primary)

Practitioner is the stable provider identity:

  • The identity a login resolves to - carries the EMR user-account identifier (identifier[userId]), following the SMART fhirUser precedent, where the canonical example is Practitioner/123
  • The default reference target - clinical resources reference the Practitioner unless the clinic/role binding is specifically what matters
  • Identity, demographics, qualifications - name, contact information, licences
  • Durable - survives role changes, so historical clinical references keep resolving
  • Potential duplication - the same person may have multiple Practitioner records across different EMR instances

PractitionerRole (Secondary -- the role binding)

PractitionerRole represents a practitioner's role at an organization/location:

  • Not the user - the login's stable identity is the Practitioner; PractitionerRole is the binding, not the account
  • Organization relationship - Practitioner has no organization element, so the clinic/instance binding can only live here. This remains the one thing PractitionerRole is structurally required for.
  • Role differentiation - use PractitionerRole.code to list only doctors, route a task to a nurse, and similar workflow filtering. Access permissions are managed in Auth0, not here.
  • Use it when the role is the assertion - multi-org providers, role-scoped booking, or where the medicolegal context is role-specific

Practical guidance: primary-care writers should emit Practitioner references. Both spellings are permitted on the reference elements that accept a provider, and consumers must handle either -- plus identifier-only references, per the logical reference model.

Identifier namespacing

No Nexus EMR profile mandates a canonical identifier system. Every profile declares identifier as 0..*, recommends a business identifier, and leaves the choice of system to the sender.

Carry the identifier the source system assigns, under a system URI that genuinely identifies it, preferring a governed external system where one exists. Organization identifiers are the one case with a global uniqueness requirement: the value must distinguish one installation from every other, because it is what separates one clinic's data from another's.

See Nexus EMR Identifiers and References for the full rules, and Organization, Patient, and Device identifiers for the three anchor resources.

Key Relationships Summary

Relationship Type Description
Device → Organization 1:1 Each EMR instance has exactly one Organization
Organization → Location 1:N An Organization can have multiple Locations
Organization ← PractitionerRole N:1 Multiple user accounts reference the same Organization
PractitionerRole → Practitioner 1:1 Each user account links to demographic information

Implementation Considerations

Data Isolation

  • EMR instances operate as completely isolated systems
  • No cross-instance references should be created
  • Users with access to multiple instances must be treated as separate entities in each

Resource Creation Order

When implementing these resources, follow this sequence:

  1. Device (EMR instance)
  2. Organization
  3. Locations (if applicable)
  4. Practitioners
  5. PractitionerRoles

Validation Requirements

  • Ensure Organization identifiers are globally unique
  • Verify all other identifiers include the EMR instance segment
  • Validate references follow the hierarchy (e.g., PractitionerRole must reference valid Organization)

See Also