For a full list of available versions, see the Directory of published versions
Business Context > Business Model
The purpose of the Provenance Implementation Guide (IG) is to support internal Ontario Health (OH) requirements for capturing who took action on data, when the action occurred, and how the action was performed across Electronic Health Record (EHR) assets. This information is essential to ensure transparency, accountability, and traceability of data processing activities within OH-managed and OH-integrated solutions.
The IG leverages the FHIR Provenance profile to capture information related to actions performed on targeted FHIR resources, as well as the systems, applications, or solutions involved in the processing of that data. Provenance information provides the business context needed to understand data lineage and operational responsibility without altering the underlying clinical or administrative content.
The primary focus of this IG is to define standardized profiles that support:
The consistent capture of provenance information, and
The ability to search and retrieve provenance records relevant to specific data assets and business use cases as needed.
It is expected that internal systems will generate Provenance information based on their existing technology capabilities and operational workflows. Systems are not required to directly implement FHIR-based interactions in order to create Provenance resources, as long as the required information is captured and made available in alignment with the profiles defined in this IG.
The following diagram depicts key components of the Provenance conceptual architecture.
| Component | Description |
|---|---|
| FHIR Data Producer | Systems that generate clinical or administrative FHIR resources (e.g., EMRs, lab systems, referral apps). |
| Provenance Service | Service or module that creates, presist and share Provenance resources based on the action initiated by the FHIR Data Producer. May be integrated or standalone. |
| FHIR API Gateway | RESTful interface for POSTing, reading, and querying FHIR resources, including Provenance. Secures and routes requests to back-end systems. |
| Provenance Repository (FHIR Store) | Backend database or cloud-native store (e.g., HAPI FHIR, Azure Health Data Services, AWS HealthLake) used to persist and manage Provenance resources. |
| Provenance Consumer | Systems or services (e.g., analytics platforms, EHRs, registries) that query and use Provenance to understand how data was created, support filtering, or generate reports. |
| Policy Evaluation | Evaluates policies linked to Provenance records to determine if a resource can be shared or used, often in conjunction with access control services. |
The description of interaction between architecture components is given in the table below.
| # | Source Component | Target Component | Interaction Description |
|---|---|---|---|
| 1 | FHIR Data Producer | Provenance Generator | Triggers Provenance creation upon creation/update of a FHIR resource. |
| 2 | Provenance Service | Context Management / Auth System | Retrieves authenticated user/session metadata (e.g., user ID, organization). |
| 3 | Provenance Service | Provenance Repository (FHIR Store) | Persists Provenance resource alongside or independently of the target resource. |
| 4 | FHIR API Gateway | FHIR API Gateway | Submits the Provenance resource via POST /Provenance. |
| 5 | Provenance Consumer | FHIR API Gateway | Queries Provenance via GET /Provenance?target=... to assess origin and trust. |
| 6 | Policy Evaluation | Provenance Repository | Validates policy references in Provenance.policy for data access decisions. |
The following diagram shows the core components and relationships of the Provenance component model. It illustrates how an Activity (e.g., a process or event) uses an Entity (input), is associated with an Agent (e.g., a person or system), and generates a new Entity (output). This model helps track the origin, derivation, and responsibility behind data and processes.
Provenance resource corresponds to a single activity that identifies a set of resources (target) generated by the activity.
Activity also references other entities (entity) that were used and the agents (agent) that were associated with the activity.
To record multiple activities that resulted in one (target), record each (activity) in independent Provenance records all pointing at that (target).
Entity is a physical, digital, conceptual or other kind of thing with some fixed aspects; entities may be real or imaginary.
* One or more entities can be the input (.entity) of an activity, and one or more entities can be the output (.target).
Agent is something that bears the responsibility identified by the type of participation in the activity taking place, for the existence of an entity, or for another agent's activity.
* An Agent may be a person, device, system, organization, group, care-team, or identifiable thing.
Activity is something that occurs over a time period and acts upon or with entities.
* It may include consuming, processing, transforming, modifying, relocating, using, or generating entities.