Overview: What is Being Generated?

The synthetic data mimics real-world immunization records from provincial registries while ensuring FHIR-compliant JSON format for interoperability. Differences between BC and ON data models are accounted for, including variations in fields such as allergy tracking.

Provincial Differences in Data Generation

Immunization Data Generation (FHIR Standard)

Field	FHIR Path	Example Value	Logic
Vaccine Type	Immunization.vaccineCode	"MMR", "Influenza"	Random selection.
Manufacturer	Immunization.manufacturer	"Pfizer", "Moderna"	Random manufacturer assignment.

Summary of Key Features

• FHIR-Compliant: Structured to align with HL7 FHIR.
• Synthetic but Realistic: Uses Faker for realistic patient data.
• Handles Provincial Variations: BC and ON have different data models.
• Includes Adverse Reactions & Exemptions: Adds realism for testing.

Overview: What is PT-to-PT Transfer?

When a patient moves or seeks healthcare in another province, their immunization record needs to be securely transferred. This Proof of Concept (PoC) focuses on the technical feasibility of such transfers while leaving governance, consent, and policy discussions out of scope.

How the Transfer Works

The transfer follows a structured push-based approach:

• The originating province (data owner) initiates the transfer.
• A secure API transmits immunization records between provinces.
• The transfer occurs only after external consent and authorization.
• The receiving province acknowledges and integrates the record.

Data Transferred Between Provinces

1. Patient Information

• Unique patient identifier within the provincial system.
• Full name, birth date, and gender.
• Address, including city, province, and postal code.
• Health card number (if applicable) for identity matching.

2. Immunization History

• Vaccine type (CVX codes).
• Date of administration and dose number.
• Manufacturer and lot number.
• Site of administration (e.g., left arm, right arm).
• Adverse reactions and exemptions (if applicable).

3. Metadata for PT-to-PT Transfers

• Transfer origin marker indicating the source jurisdiction.
• Receiving province acknowledgment confirming integration.

Technical Flow of the Transfer

1. Patient relocates or seeks healthcare in another province.
2. Originating province completes consent and authorization.
3. A secure API request is triggered by the originating province.
4. Receiving province ingests and processes the immunization record.
5. The record is now available in the receiving province’s registry.

Key Assumptions and Considerations

• This PoC does not handle consent management; it must be externally managed.
• The push-based model ensures data is only transferred when authorized.
• Manual transfer requests (fax, email, policy-driven) remain possible but are out of scope.
• The PoC leverages FHIR repositories to validate secure data exchange.

Testing and Simulation Approach

• FHIR-based simulation using synthetic data.
• Initial scope focused on MMR vaccine records, expandable in future phases.
• Optional UI demonstration to visualize transferred records.

Overview: Why is Aggregation Needed?

PHAC does not require full patient-level data but instead needs structured, summarized reports for national immunization monitoring. Aggregation transforms raw immunization records into anonymized datasets, ensuring accuracy while protecting privacy. This process maintains consistency across provinces, even when different immunization tracking systems are used.

PHAC does not access or process identifiable Personal Health Information (PHI) at any stage. All de-identification is performed at the Provincial/Territorial (PT) level before any data is shared with PHAC. The information shared with PHAC is structured, anonymized, and formatted for public health reporting in compliance with privacy regulations. Aggregation ensures uniform national immunization reporting while aligning with PT-specific privacy frameworks.

How Data Aggregation Works

1. Extract immunization records from FHIR repositories at the PT level.
2. De-identify data by removing personally identifiable details (e.g., names, health card numbers) entirely at the PT level before aggregation.
3. Categorize data by jurisdiction, age group, gender, and vaccine type.
4. Summarize dose counts and calculate total vaccinated individuals.
5. Format the final dataset into a structured, anonymized report in compliance with PHAC's reporting framework.

Overview

The technical architecture enables secure, real-time immunization data exchange between jurisdictions while ensuring that each province maintains full control over its data. It follows a federated model, using a combination of API gateways, security layers, and standardized data exchange mechanisms.

Key Components

• Provincial Immunization Systems: Each province maintains its own immunization data repository.
• FHIR-Based Data Exchange: Standardized API interactions ensure compatibility between different systems.
• Access Control Gateway: Manages authentication, authorization, and data access policies.
• Interoperability Layer: Enables data transformation and validation to align different provincial data formats.
• Audit & Compliance Framework: Ensures all data access is logged and follows regulatory requirements.

Federated Immunization Data Architecture (UJ-1)

The federated model ensures that each province maintains local control over its immunization records while supporting national-level aggregation for public health surveillance. The architecture consists of:

• FHIR Immunization Registries: Each province maintains its own secure database.
• Synthetic Data Generator: Creates test data for validation.
• SMART Patient Viewer: Allows healthcare providers to view immunization records.
• Aggregator: Summarizes and anonymizes immunization records before sharing with PHAC.
• Federator (PHAC): Receives de-identified, aggregated data for national reporting.
• R-Shiny Dashboards: Provides real-time analytics and insights.

PT-to-PT Transfer Workflow (UJ-2)

The PT-to-PT transfer mechanism enables secure, structured movement of immunization records when a patient relocates between jurisdictions. This workflow ensures that records are securely exchanged without centralization.

• API Gateway: Facilitates secure and authenticated communication.
• FHIR Data Transfer: Ensures records are formatted correctly.
• Message Queue: Manages retries and queued requests.
• Outbound Transfer Service: Extracts and sends immunization data.
• Inbound Transfer Service: Receives and validates incoming records.

Data Flow

1. A request for immunization data is initiated by an authorized system.
2. The Access Control Gateway verifies authentication and consent requirements.
3. Once approved, data is retrieved from the provincial immunization system.
4. The interoperability layer processes and transforms the data to a standard format.
5. The response is securely delivered back to the requester.

Security & Compliance

• End-to-end encryption is enforced for all data exchanges.
• Mutual TLS authentication ensures secure API communication.
• Audit logs are maintained to track all requests and access events.
• Provincial data sovereignty is preserved by keeping raw data within jurisdictions.

Scalability & Infrastructure

• Containerized microservices enable efficient scaling.
• Event-driven architecture allows real-time data synchronization.
• Cloud-hosted infrastructure supports high availability and fault tolerance.

Overview

The Foundation for Federated Data Architecture outlines a secure and interoperable model for exchanging immunisation data across Canada. It allows real-time synchronisation, role-based access, and privacy-first data sharing — without centralising control or ownership. The model consists of four domains: Data Emitters, Security and Governance, Federated Infrastructure, and General Users. Together, these domains form the foundation of compliant, distributed health data exchange.

Architecture Diagram

Key Concepts

Security, Control, Governance and Enforcement

• Access Control Models: Define who can access what data, under which conditions, and for what purpose. Tailored to each jurisdiction’s legal frameworks, they enforce compliant, transparent, and auditable data usage.
• Data Governance Gateway: Validates all data requests by enforcing jurisdictional agreements, consent requirements, and access policies. It serves as the central gatekeeper for safe and legal data exchange.
• Policy Enforcement: Executes real-time policy checks such as time-bound access, consent verification, and purpose-of-use restrictions. These enforcement systems make governance actionable at runtime.
• Security Protocols: Apply identity validation, encryption, and system hardening across the federation. These controls support compliance with Canadian privacy legislation and prevent unauthorised access.

Infrastructure, Storage, Query, Data Flow and Standards

• Cloud Platforms: Scalable and secure environments for deploying workloads, sharing services, and running jurisdiction-specific applications. These platforms enable a consistent operational foundation across jurisdictions.
• API Management: Provides secure access points for system-to-system communication. Includes request validation, rate limiting, authentication, and observability across federated APIs.
• Data Storage Solutions: Stores both jurisdictional and aggregated datasets using encryption-at-rest and role-based access controls. Designed for durability, auditability, and regional autonomy.
• Data Standards (HL7 FHIR): HL7 FHIR enables structured, consistent, and machine-readable representation of health records. It underpins semantic interoperability across different jurisdictions and systems.
• Real-Time Data Sync: Asynchronous, event-driven pipelines that update immunisation records across systems continuously. These mechanisms ensure up-to-date views while preserving data sovereignty.

Source Data Emitters

• Data Emitter Nodes: The authoritative sources of immunisation data within each province or territory. These nodes maintain full control and apply governance policies before any data is shared externally.

General Data Users

• General Users: Authorised systems or users who access governed outputs — not raw PT data — to generate insights, analytics, or reports. Access is standardised, governed, and fully auditable.

Overview

The Interoperable Immunization Data Initiative (IIDI) is built using a secure, scalable, and federated model. The architecture enables seamless data exchange while ensuring that provincial and territorial jurisdictions maintain control over their immunization records.

GitHub Repository

The source code and related documentation for IIDI can be found in the official GitHub repository:

• IIDI-Tech GitHub Repository

Technical Architecture

The IIDI technical stack is designed for interoperability, security, and compliance with public health data governance frameworks. Key architecture components are documented below:

• GCP Architecture Overview - High-level infrastructure design for deployment.

Architecture Review Board Documentation

The architecture follows a federated data model to support two primary user journeys:

• Interoperable Immunization Data Initiative (IIDI) – User Journey 1: PT-to-PT Transfer
• Interoperable Immunization Data Initiative (IIDI) – User Journey 2: PT-to-PHAC