Business Context > Business Model
Context
In the complex and critical landscape of healthcare, the integrity, reliability, and trustworthiness of data are paramount. The Ontario Health Provenance Implementation Guide addresses a fundamental business need: to establish a comprehensive and verifiable record of how health information is created, transformed, and managed across various systems. This is not merely a technical requirement but a strategic imperative to ensure accountability, facilitate auditing, and support informed decision-making for clinicians, administrators, and ultimately, patients. By documenting the "Who, What, When" of every data transaction, this guide enables Ontario Health to build a robust foundation for data governance and quality assurance.
The implementation of Provenance resources directly supports key operational objectives. During data ingestion into the Clinical Data Repository (CDR), Provenance records will be systematically injected alongside contributed content. This process ensures that every piece of versioned data is intrinsically linked to its origin, including the contributing systems, organizations, and individuals. This capability is crucial for troubleshooting data discrepancies, validating the source of information, and fulfilling regulatory compliance requirements. Without robust provenance, the ability to trace data lineage becomes challenging, leading to potential delays, inaccuracies, and a lack of confidence in the data used for patient care and population health management.
Conceptual Architecture
The following diagram depicts key componenets 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 evaluate trust, 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 componenets 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 | FHIR API Gateway | Submits the Provenance resource via POST /Provenance. |
| 4 | FHIR API Gateway | Provenance Repository (FHIR Store) | Persists Provenance resource alongside or independently of the target resource. |
| 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. |
Conceptual Data Model
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 thingActivity 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