Visit the HL7 website
Visit the FHIR website

Primary Care

0.1.0-dft-preBallot   Canada flag
  • Index
  • Home
  • Business Context
    • Architectural Considerations
    • Use Cases
    • Future Enhancements
    • Consolidation Methodology
  • Technical Context
    • Conformance Guidance
    • Mappings
  • FHIR Artifacts
    • FHIR Artifacts
    • Actors
    • Profiles
    • Extensions
    • Search
    • Data Types
    • Capability Statement
    • Terminology
    • Examples
    • Packages
  • Change Log
    1. Index
    2. Home

dft-preBallot - This is the first draft of the P-Care IG. For a full list of available versions, see the Directory of published versions

Description and Scope

The Primary Care specification (P-Care) is being developed as a pan-Canadian candidate specification, not yet a pan-Canadian specification. It is intended to support a common set of primary care interoperability use cases across Canada; however, broader jurisdictional review, support, and endorsement will be needed before it can be considered pan-Canadian. Its focus is to make it easier for EMRs and external applications, including HALO-conformant applications, to exchange and use primary care information in a consistent way across jurisdictions. This includes use cases such as access to patient information, referral and consult workflows, forms, immunization, and other primary care information-sharing needs.

The initial P-Care release consolidates requirements from a subset of Canadian FHIR implementation guides into a comprehensive specification that EMR vendors can build and test against. Its applicability is therefore validated for the use cases and jurisdictions represented by those source guides; however, it should not be viewed as limited exclusively to those scenarios. Because many primary care interoperability needs are based on common data access, exchange, and integration capabilities, P-Care can support a broader range of related use cases while providing a strong foundation for future national and jurisdictional requirements. As additional implementation guides and requirements are incorporated over time, P-Care is intended to evolve into a broader, shared foundation for primary care interoperability across Canada.

This guide provides a consolidated, conformance-testable specification that EMR vendors can implement to support HALO and other SMART on FHIR applications across the functionality covered by the in-scope guides and other relevant use cases.

Scope note: This guide is intended for EMRs that must support multiple implementation guides across several jurisdictions. EMRs with a narrower interoperability scope may find that its requirements exceed their needs.

Relationship with CA Core+

P-Care builds on the foundation established by CA Core+, deriving its profiles from CA Core+ where applicable, to provide an implementation-ready specification for vendor conformance.

PCare-Core-Relationship

Sources for the Initial Requirements

The initial requirements were derived from the following implementation guides:

  • CA Core+ 1.2.1-dft-ballot
  • Pan-Canadian Patient Summary (PS-CA) 2.2.0 ti-ballot
  • Pan-Canadian eReferral / eConsult (CA:eReC) 1.3.0-dft-preBallot
  • Alberta eReferral / Consult (AB:eReC) 1 1.1.2
  • Alberta Patient Summary (PS-AB) 1.2.0-pre6
  • Ontario Context Management System 1.0.1
  • Ontario eReferral / eConsult (ON:eReC) 0.12.6-2-TU
  • Ontario eForms 1.0.0-ballot6
  • Ontario Immunization (ON:IR) 1.0.0-draft1

Additional content was introduced in response to requirements from:

  • Canadian FHIR Exchange (CA:FeX) 2.2.0-dft-Ballot
  • US Core 9.0.0
  • Ontario Subscription 1.0.0
  • Requirements identified by Ontario Health

Problem Statement

EMRs must interact with a growing number of jurisdictional systems through FHIR interfaces defined by separate implementation guides. As these guides proliferate, vendors face increasing complexity when supporting products across multiple jurisdictions - or even multiple systems within one jurisdiction. Differences among jurisdictional implementations compound this burden.

Vendors must also address the user-interface and workflow requirements introduced by these guides and adapt to changes in subsequent versions. This creates ongoing development and maintenance demands beyond implementing the underlying FHIR interfaces.

Supporting Technologies

Several FHIR technologies can offload use case-specific customization from EMRs:

  • SMART App Launch enables plug-in applications to provide specialized user-interface functions, reducing the need to redesign the EMR interface for each jurisdictional requirement.
  • CDS Hooks enables EMRs to integrate external clinical decision support through a standardized mechanism.
  • Publish/Subscribe enables EMRs to send data of interest to external systems in a standardized way, reducing reliance on custom messages and operations.

Each of these technologies depends on the EMR exposing a FHIR server interface.

Navigation

This guide organized into three main areas:

Business Context

This section provides background information that establishes the foundation for the implementation guide; it does not contain requirements needed for implementation. The subsections are:

  • Architectural Considerations - describes key architectural changes introduced by this guide
  • Use Cases - provides examples of how the capabilities defined by this guide could be used
  • Future Enhancements - indicates known gaps and potential candidates for additional functionality to be added in new versions of this specification
  • Consolidation Methodology - describes the process that was used to derive the conformance artifacts used in this specification

Technical Context

This area is critical for implementation. Its pages contain conformance rules and other information required for successful compliance with the guide.

  • Conformance Guidance - defines conformance rules for compliant systems that cannot be expressed via computable artifacts
  • Mappings - describes how the extensions, value sets, and code systems defined by this guide correspond to artifacts in jurisdiction-defined specifications

FHIR Artifacts

This includes an index for and detailed pages describing the CapabilityStatement, profiles, and other conformance artifacts that define the expected capabilities of conformant EMRs.

Dependencies

This guide builds on the CA Core+ implementation guide. Wherever possible, P-Care profiles are derived from profiles defined in CA Core+.

The complete dependency set is listed below.

  • ca.infoway.io.pcare 0.1.0-dft-preballot
  • hl7.fhir.r4.core 4.0.1
  • hl7.terminology.r4 7.4.0
  • ca.infoway.io.core 1.2.1-dft
  • hl7.fhir.uv.extensions.r4 5.3.0-ballot-tc1
  • hl7.terminology.r4 6.5.0
  • hl7.fhir.uv.extensions.r4 5.2.0
  • hl7.fhir.ca.baseline 1.1.7
  • hl7.fhir.uv.ips 2.0.0-ballot
  • hl7.terminology.r4 6.0.2
  • hl7.fhir.uv.extensions.r4 5.1.0
  • fhir.dicom 2025.1.20250221
  • ca.infoway.io.ca-ext-reg 0.0.3-beta-1
  • hl7.fhir.xver-extensions 0.1.0
  • hl7.fhir.uv.xver-r5.r4 0.1.0
  • hl7.terminology.r4 7.1.0
  • hl7.fhir.uv.extensions.r4 5.3.0
  • hl7.fhir.uv.ips 2.0.1
  • hl7.terminology.r4 7.2.0
  • hl7.fhir.uv.ipa 1.1.0
  • hl7.terminology.r4 6.2.0
  • hl7.fhir.uv.smart-app-launch 2.0.0
  • hl7.fhir.uv.sdc 4.0.0
  • hl7.fhir.uv.tools.r4 1.1.2
  • hl7.fhir.r4.examples 4.0.1
  • ca.on.erec.r4 0.12.6-2-TU
  • ca.infoway.io.erec.branch 1.0.5-dft
  • ca.infoway.io.psca 1.1.0
  • hl7.fhir.uv.ips 1.1.0
  • hl7.terminology.r4 5.0.0
  • fhir.dicom 2022.4.20221006
  • ca.on.ir.r4 1.0.0-draft1
  • ca.on.ehr.r4 1.0.0-snapshot22
  • hl7.fhir.uv.tools.r4 1.1.0
  • hl7.terminology.r4 7.0.1
  • ca.on.oh-cms-ig 1.0.1-alpha1.0.6
  • ca.on.oh-eforms 1.1.0-snapshot1
  • ca.ab.fhir.aberec1 1.1.2
  • ca.ab.fhir.psab 1.1.0
  • ca.infoway.io.erec 1.2.0-dft
  • ca.infoway.io.core 1.1.0-dft-preballot
  • hl7.fhir.uv.xver-r5.r4 0.0.1-snapshot-2
  • ca.infoway.io.erec 1.3.0-dft-preBallot
  • ca.ab.fhir.psab 1.2.0-pre6
  • hl7.fhir.ca.baseline 1.1.8
  • ca.infoway.io.psca 2.2.0-ti-ballot
  • ca.infoway.io.ca-csd 1.1.1-dft-preBallot
  • ihe.iti.mcsd 4.0.0-comment
  • ihe.iti.balp 1.1.4
  • hl7.fhir.uv.subscriptions-backport.r4 1.2.0-ballot
  • hl7.terminology.r4 5.3.0
  • hl7.fhir.uv.extensions.r4 1.0.0
  • hl7.fhir.uv.tools 0.2.0
  • hl7.terminology.r5 5.5.0
  • hl7.fhir.r5.core 5.0.0
  • hl7.fhir.uv.extensions.r5 1.0.0

Defined terms

The following are some key terms introduced in this specification. For additional defined terms please go to the Infoscribe page here

Term / Acronym Meaning
CA:FeX The Canadian FHIR Exchange guide seeks to promote FHIR RESTful exchange patterns, developed by industry-leading FHIR standards that can be applied on top of an existing infrastructure just as easily as it can be applied on top of FHIR servers.
Consumer The application that is receiving, and in most cases processing, the data generated by the Producer.
IG A FHIR Implementation Guide is a set of rules of how a particular interoperability or standards problem is solved - typically using FHIR resources. It includes both human-readable and computer-processible representations of its content.
Obligation An expectation for a capability a Producer and/or Consumer should have with respect to a data element.
Producer The application that is generating the data to be shared with the Consumer

Specification Feedback

To provide feedback you can email Specifications@infoway-inforoute.ca. Be sure to include "P-Care" in the topic.

IG © based on FHIR R4 | template version 2.5.1 | Package package:ca.infoway.io.pcare@0.1.0-dft-preballot
Copyright © 2026 Canada Health Infoway. All rights reserved. Terms of Use & License Agreements. Privacy Policy.
HL7® and FHIR® are the registered trademarks of Health Level Seven International