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 Polaris 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 Polaris EMR Device Core 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 Polaris Organization Core 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

Polaris Location Core 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.

PractitionerRole and Practitioner

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

PractitionerRole (Primary)

Polaris PractitionerRole Core represents an EMR user account:

  • User boundary - EMR user accounts define system access boundaries
  • Organization relationship - Links a practitioner to an organization
  • Account-centric - Represents the user's relationship with the software/organization

Practitioner (Secondary)

Polaris Practitioner Core contains demographic information:

  • Demographics only - Name, contact information, qualifications
  • Referenced by role - Always accessed through a PractitionerRole
  • Potential duplication - Same person may have multiple Practitioner records across different EMR instances

Identifier Namespacing

The Polaris specification uses a sophisticated identifier system to ensure global uniqueness while maintaining EMR instance boundaries:

Standard Pattern

Most resources follow this pattern: - Include an EMR instance segment in the identifier system - Format: https://fhir.apps.health/NamingSystem/{instance-id}-{resource-type}-identifier - Example: https://fhir.apps.health/NamingSystem/Juno-1234-patient-identifier

Organization Exception

Organizations use a global namespace: - No EMR instance segment in identifiers - Must be unique across ALL instances - Format: https://fhir.apps.health/NamingSystem/organization-identifier

For complete identifier guidelines, see Identifiers and Identifier Migration.

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