Ontario Provenance HL7® FHIR® Implementation Guide -v1.0.0-trial-use

For a full list of available versions, see the Directory of published versions

2.4. Use Cases

This section outlines typical scenarios where the use of Provenance improves the traceability of healthcare data exchange. Each use case is grounded in a real-world example and highlights the roles of key actors involved: the Provenance creator, the system responsible for storing Provenance, and the Provenance consumer or subscriber.

2.4.1. Actors

This section defines the key actors involved in the implementation and exchange of Provenance information across various Use Cases.

Participant	Description
Provenance Requestor	Systems that generate clinical or administrative FHIR resources (e.g., EMRs, lab systems, referral apps). Its action (for example,initiating transaction from EMR to SmartApp) triggers Provenance creation.
Provenance Creator	The system responsible for creating a Provenance Resource based on the specific requirements.
Provenance Store	The system responsible for persisting the Provenance Resource
Provenance Consumer	The system that consumes the Resource Response to enables the system to evaluate the source and context of the data it receives.

2.4.2. UC01 - Use of Provenance to capture participant in the transaction from EMR to Smart Apps via HALO / SoFA layer

Actors

Actor	Description
EMR	Provenance Requestor
SoFA	Provenance Creator
FHIR Server (SoFA)	Provenance Store
SmartApp	Provenance Consumer

Summary

The use case supports creation of Provenance Resource in the context of SmartApp launch request by the EMR via SoFA layer.

Pre-Conditions

The SmartApp launch request is authenticated through SoFA.
All necessary identifiers for Provenance creation are available within SoFA.

Primary Flow

EMR launches SmartApp to process the patient related data.
SoFA layer authenticates the request, sets the launch context and creates Provenance resource with required attributes (see business rules section)
FHIR Server persists Provenence resource (with other FHIR resources in the launch context) as created by SoFA layer.
Before sending notification back to requesting EMR, SoFA retrieves Provenance resource and embeds it in the Notification Bundle.

Following sequence diagram illustreates the sequence of interactions assocaited with use case.

Post-Conditions

The Provenance resource is created with all required attributes

2.4.3. UC02 - HL7 v2 Data Submission Flow via HL7 v2 Adapter

Actors

System	Actor	Description
Source System	Provenance Requestor	The system responsible for sending original HL7 v2 message
CDF	Provenance Creator	Clinical Data Foundation layer responsible for processing HL7 v2 message and transforming it to FHIR for the target system. Also responsible for creation and management of Provenence Resource
HL7 v2 to FHIR Adapter	Provenence Creator	The system that converts HL7 v2 to FHIR.
OH CDR	Provenance Consumer	Target system that consumes the FHIR resources from source system and eventually persists the Provenence resource.

Summary

The use case supports creation of Provenance Resource in the context of conversion of HL7 v2 to FHIR message via CDF layer

Pre-Conditions

The Source system generates HL7 v2 message .

Primary Flow

Source system submits a valid HL7 v2 message to CDF.
CDF accepts the message and sends it to HL7 v2 adapter for conversion
Converted FHIR resource is returned to CDF.
CDF submits FHIR resource to OH CDR. Upon successful creation CDF generates a Provenance resource and submits to OH CDR.

Following sequence diagram illustrates the sequence of interactions associated with use case.

2.4.4. UC03 - FHIR Data Submission Flow

Actors

System	Actor	Description
Source System	Provenance Requestor	The system responsible for sending original HL7 v2 message
CDF	Provenance Creator	Clinical Data Foundation layer reesponsible for processing HL7 FHIR message. Also responsible for creation and management of Provenence Resource
OH CDR	Provenance Consumer	Target system that consumes the FHIR resources from source system and eventually persists the Provenence resource.

Summary

The use case supports creation of Provenance Resource in the context of conversion of HL7 v2 to FHIR message via CDF layer

Pre-Conditions

The Source system generates HL7 FHIR message (resource) .

Primary Flow

Source system submits a valid HL7 FHIR message to CDF.
CDF submits FHIR resource to OH CDR. Upon successful creation CDF generates a Provenance resource and submits to OH CDF.

Following sequence diagram illustrates the sequence of interactions associated with use case.

2.4.5. UC04 - FHIR Data Migration Flow

Actors

System	Actor	Description
Source System	Provenance Requestor	The system responsible for sending original HL7 v2 message
CDF	Provenance Creator	Clinical Data Foundation layer reesponsible for processing HL7 v2 message and transforming it to FHIR for the target system. Also responsible for creation and management of Provenence Resource
CDFMigrationDataAdapter	Provenance Creator	The system that converts HL7 v2 to FHIR.
OH CDR	Provenance Consumer	Target system that consumes the FHIR resources from source system and eventually persists the Provenence resource.

Summary

The use case supports creation of Provenance Resource in the context of migration of FHIR data via CDF layer

Pre-Conditions

The Source system creates migration load of HL7 FHIR data (resource) .

Primary Flow

Source system initiates migration of HL7 FHIR data to CDF.
CDF moves FHIR resource to OH CDR. Upon successful creation CDF generates a Provenance resource and submits to OH CDF.

Following sequence diagram illustrates the sequence of interactions associated with use case.