Sequence Diagrams for UC-01: HCP Creates a PS-CA

A Health Care Provider in any care setting creates/produces a PS-CA for use at point of care, including for unscheduled/scheduled local care, which is made available to PS-Consumers.

UC-01:Implementation Option 1: MHD

Scenario / Assumption(s): Patient Summary-CA is stored in Central or Local (Decentralized) Document Repository

Release 1: Clinical data (e.g. medication, lab results, immunization) is retrieved from local sources only

Implementation Option 1: This sequence diagram provides the option of using the MHD IHE profile, including a Document Repository actor and supporting HL7 FHIR standards.

Sequence Diagram Overview:
Below provides guidance on how to read the sequence diagram:

• This sequence diagram illustrates how the different standardized actors of systems should interact with each other to carry out specific standardized transactions, and the order in which the transactions and interactions occur when Use Case 1 of the Patient Summary-CA is executed.
• The legend on the bottom right corner describes the different system components, actors and transactions that are necessary to carry out this particular use case.
• The green swim lane is a simplified view of the actors and transactions required by the Foundational Profiles, defined here, in addition to the other ones that are not explicitly illustrated on the diagram (e.g. ATNA, CT) but included as a white note. These are pre-requisite conditions for this particular use case and it is assumed that these will be satisfied.
• The blue swim lanes groups sequence of processes (along with their required actors and transactions) that are needed to occur to satisfy this particular use case. These are to be read from left to right and top to bottom.
• The red note boxes describe important call outs, information and notes that provide more context for the sequence diagram.
• For more information on core IHE Profiles and specific Canadian implementation guidance, refer to Reference Architecture.

UC-01: Implementation Option 2: CA:FeX

Scenario: Clinical Solution A Retrieves Patient Summary-CA from Central Document Repository

Assumption: Patient Summary-CA is stored in Central Document Repository

Implementation Option 2: This sequence diagram provides the option of using the CA:FeX Interoperability Specifications that provide support for saving and retrieving a Patient Summary-CA to and from a central Document Repository. This profile includes a Data Source and a Data Recipient actor. Additionally, this sequence diagram uses the 'Submit Data' FHIR operation.

Note: Additionally, this sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.). Additional details will be included in the PS-CA Interoperability Specifications.

Sequence Diagram

Sequence Diagrams for UC-02: HCP Views/Consumes a PS-CA

A Health Care Provider in any care setting requests and uses a PS-CA at the point of care, including for unscheduled/scheduled local care.

UC-02:Implementation Option 1: MHD

Scenario: Clinical Solution A Retrieves Patient Summary-CA from MHD Document Registry – (MHD* IHE Profile).

Assumption: Patient Summary-CA is stored in Central or Local (Decentralized) Document Repository.

Implementation Option 1: This sequence diagram provides the option of using the MHD IHE profile, including a Document Repository actor and supporting HL7 FHIR standards.

Note: Additionally, this sequence diagram include the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc). Additional details will be included in the PS-CA Interoperability Specifications.

Sequence Diagram Overview:
Below provides guidance on how to read the sequence diagram:

• This sequence diagram illustrates how the different standardized actors of system should interact with each other to carry out specific standardized transactions, and the order in which the transactions and interactions occur when Use Case 2 of the Patient Summary-CA is executed.
• The legend on the bottom right corner describes the different system components, actors and transactions that are necessary to carry out this particular use case.
• The green swim lane is a simplified view of the actors and transactions required by the Foundational Profiles, defined here, in addition to the other ones that are not explicitly illustrated on the diagram (e.g. ATNA, CT) but included as a white note. These are pre-requisite conditions for this particular use case and it is assumed that these will be satisfied.
• The blue swim lanes groups sequence of processes (along with their required actors and transactions) that are needed to occur to satisfy this particular use case. These are to be read from left to right and top to bottom.
• The red note boxes describe important call outs, information and notes that provide more context for the sequence diagram.
• This sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.). Additional details will be included in the PS-CA Interoperability Specifications.
• For more information on core IHE Profiles and specific Canadian implementation guidance, refer to Reference Architecture.

UC-02: Implementation Option 2: CA:FeX

Scenario: Clinical Solution A Retrieves Patient Summary-CA from Central Document Repository

Assumption: Patient Summary-CA is stored in Central Document Repository

Implementation Option 2: This sequence diagram provides the option of using the CA:FeX Interoperability Specifications that provide support for saving and retrieving a Patient Summary-CA to and from a Document Repository (Local to PS-Producer or Central). This profile includes a Data Consumer and a Data Responder actor. Additionally, this sequence diagram uses the 'Search Data' and 'Retrieve Data' FHIR operations.

Note: Additionally, this sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.). Additional details will be included in the PS-CA Interoperability Specifications.

Sequence Diagram

Sequence Diagrams for UC-03: Patient Views/Obtains Personal PS-CA

A Patient or Subject of Care accesses/views and can retrieve a copy of their own PS-CA to support unscheduled/scheduled local care, or for any other purpose.

UC-03:Implementation Option 1: MHD

Scenario: Patient Portal Retrieves PS from MHD Document Registry – (MHD* IHE Profile).

Assumption: Patient Summary-CA is stored in Central or Local (Decentralized) Document Repository.

Implementation Option 1: This sequence diagram provides the option of using the MHD IHE profile, including a Document Repository actor and supporting HL7 FHIR standards.

Note: Additionally, this sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.). The Document Repository in this scenario can be either (1) central or (2) at PS-CA Producer (the source where the document was produced). The Document Consumer actor would query the appropriate repository.

Sequence Diagram Overview:
Below provides guidance on how to read the sequence diagram:

• This sequence diagram illustrates how the different standardized actors of system should interact with each other to carry out specific standardized transactions, and the order in which the transactions and interactions occur when Use Case 2 of the Patient Summary-CA is executed.
• The legend on the bottom right corner describes the different system components, actors and transactions that are necessary to carry out this particular use case.
• The green swim lane is a simplified view of the actors and transactions required by the Foundational Profiles, defined here, in addition to the other ones that are not explicitly illustrated on the diagram (e.g. ATNA, CT) but included as a white note. These are pre-requisite conditions for this particular use case and it is assumed that these will be satisfied.
• The blue swim lanes groups sequence of processes (along with their required actors and transactions) that are needed to occur to satisfy this particular use case. These are to be read from left to right and top to bottom.
• The red note boxes describe important call outs, information and notes that provide more context for the sequence diagram.
• This sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.). Additional details will be included in the PS-CA Interoperability Specifications.
• For more information on core IHE Profiles and specific Canadian implementation guidance, refer to Reference Architecture.

UC-02: Implementation Option 2: CA:FeX

Scenario: Clinical Solution A Retrieves Patient Summary-CA from Central Document Repository

Assumption: Patient Summary-CA is stored in Central Document Repository

Implementation Option 2: This sequence diagram provides the option of using the CA:FeX Interoperability Specifications that provide support for saving and retrieving a Patient Summary-CA to and from a Document Repository (Local to PS-Producer or Central). This profile includes a Data Consumer and a Data Responder actor. Additionally, this sequence diagram uses the 'Search Data' and 'Retrieve Data' FHIR operations.

Note: Additionally, this sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.). Additional details will be included in the PS-CA Interoperability Specifications.

Sequence Diagram

Sequence Diagrams for UC-04: HCP Requests PS-CA On-Demand

A Health Care Provider in any care setting requests and uses a PS-CA on-demand at the point of care, including for unscheduled/scheduled local care.

Implementation Option 1: CA:FeX $summary operation

This option is recommended for systems where the clinical data needed to generate the Patient Summary is internal to the Clinical Data Repository.

Note that generally with $summary operation, servers may choose not to produce “fresh” patient summaries on every request. Due to performance impacts, servers may choose to generate Patient Summaries on a nightly or cached basis, and return those.

Implementation Option 2: CA:FeX $docref operation

This option is recommended for systems where the clinical data needed to generate the Patient Summary is either external to the Clinical Data Repository generating the summary, or distributed across various internal and external data sources.

UC-04:Implementation Option 1: CA:FeX $summary

Scenario: Clinical Solution A Requests Patient Summary-CA On Demand from Clinical Data Repository

Assumption: Clinical data used to generate the Patient Summary is retrieved from sources internal to the Clinical Data Repository

Implementation Option : This sequence diagram provides the option of using the CA:FeX Interoperability Specifications that provide support for requesting a Patient Summary-CA on demand from a Clinical Data Repository (Local to PS-Producer or Central). This profile includes a Data Consumer and a Data Responder actor. Additionally, this sequence diagram uses the 'Retrieve Patient Summary' CA:FeX-3D transaction which is based on IPS Summary ($summary).

This implementation option is suitable for systems where the discrete FHIR resources needed to generate the Patient Summary are internal to the Clinical Data Repository where the Patient Summary is generated.

Note that generally with $summary operation, servers may choose not to produce “fresh” patient summaries on every request. Due to performance impacts, servers may choose to generate Patient Summaries on a nightly or cached basis, and return those.

Note: Additionally, this sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.).

Sequence Diagram Overview:
Below provides guidance on how to read the sequence diagram:

• This sequence diagram illustrates how the different standardized actors of system should interact with each other to carry out specific standardized transactions, and the order in which the transactions and interactions occur when Use Case 4 of the Patient Summary-CA is executed.
• The legend on the bottom right corner describes the different system components, actors and transactions that are necessary to carry out this particular use case.
• The green swim lane is a simplified view of the actors and transactions required by the Foundational Profiles, defined here, in addition to the other ones that are not explicitly illustrated on the diagram (e.g. ATNA, CT) but included as a white note. These are pre-requisite conditions for this particular use case and it is assumed that these will be satisfied.
• The blue swim lanes groups sequence of processes (along with their required actors and transactions) that are needed to occur to satisfy this particular use case. These are to be read from left to right and top to bottom.
• The red note boxes describe important call outs, information and notes that provide more context for the sequence diagram.
• This sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.). Additional details will be included in the PS-CA Interoperability Specifications.
• For more information on core IHE Profiles and specific Canadian implementation guidance, refer to Reference Architecture.

UC-04: Implementation Option 2: CA:FeX $docref

Scenario: Clinical Solution A Requests Patient Summary-CA On Demand from Clinical Data Repository

Assumption: Clinical data used to generate the Patient Summary is retrieved from sources that are internal and/or external to the Clinical Data Repository

Implementation Option 2 : This sequence diagram provides the option of using the CA:FeX Interoperability Specifications that provide support for requesting a Patient Summary-CA on demand from a Clinical Data Repository (Local to PS-Producer or Central). This profile includes a Data Consumer and a Data Responder actor. Additionally, this sequence diagram uses the 'Fetch DocumentReference' CA:FeX-2B transaction which is based on $docRef

This implementation option is suitable for systems where the discrete FHIR resources needed to generate the Patient Summary are either external to the Clinical Data Repository generating the summary, or distributed across various internal and external data sources.

The on-demand Patient Summary generation occurs in two steps and involves asynchronous processing when data retrieval has longer response times, which is typically the case for external data sources. In the first step, a DocumentReference resource is created, that contains the location where the Patient Summary document is or will be available. The retrieval of the discrete FHIR resources needed to assemble the Patient Summary document is an asynchronous operation. In the second step, the on-demand Patient Summary document is retrieved once the assembly of the discrete FHIR resources is complete.

Note: Additionally, this sequence diagram includes the CA:FMT Interoperability Specifications that handle transformations to and from various formats (e.g. FHIR to PDF, CDA, etc.). Additional details will be included in the PS-CA Interoperability Specifications.

Sequence Diagram

Sequence Diagrams for UC-05: Patient Mediated Access and Exchange of their Patient Summary

This use case describes the process of accessing and sharing a Patient Summary using a Shareable Health Link (SHL) and QR code. It is split into two distinct parts (Part A: Patient Requests Access to Their Shareable Patient Summary and Part B: Patient presents their QR code or SHL to HCP for access to their Patient Summary), offering a complete overview of the workflow from the creation of the shareable Patient Summary to its use by Health Care Providers (HCP).

UC-05A: Generate SHLink for Patient Summary

Scenario: Patient-facing application (Mobile App, Patient Portal, or proprietary Patient Viewer Application) requests access to a shareable copy of their Patient Summary in SHLink format.

Assumption: The Patient Summary either exists or is generated on demand. This step occurs prior and is transparent to the SHLink generation.

Implementation Option : This sequence diagram provides the option of using the CA:SHL Interoperability Specifications that provide support for requesting generation of a Shareable Health Link to their Patient Summary from a Clinical Data Repository. This profile includes an SHLink Requester and an SHLink Creator actor. Additionally, this sequence diagram uses the 'Generate SHLink' CA:SHL-1 transaction.

The server-side generates the SHLink and upon receival, the SHLink is typically converted in a QR code format, that can be downloaded by the patient and saved onto their phone or other media. The SHLink optionally contains a viewer URL that is recognizable by a browser and can display information related to the SHLink.

Sequence Diagram Overview:
Below provides guidance on how to read the sequence diagram:

• This sequence diagram illustrates how the different standardized actors of system should interact with each other to carry out specific standardized transactions, and the order in which the transactions and interactions occur when Use Case 5 of the Patient Summary-CA is executed.
• The legend on the bottom right corner describes the different system components, actors and transactions that are necessary to carry out this particular use case.
• The green swim lane is a simplified view of the actors and transactions required by the Foundational Profiles, defined here, in addition to the other ones that are not explicitly illustrated on the diagram (e.g. ATNA, CT) but included as a white note. These are pre-requisite conditions for this particular use case and it is assumed that these will be satisfied.
• The blue swim lanes groups sequence of processes (along with their required actors and transactions) that are needed to occur to satisfy this particular use case. These are to be read from left to right and top to bottom.
• The red note boxes describe important call outs, information and notes that provide more context for the sequence diagram.
• This sequence diagram includes the CA:SHL Interoperability Specifications. Additional details will be included in the PS-CA Interoperability Specifications.
• For more information on core IHE Profiles and specific Canadian implementation guidance, refer to Reference Architecture.

UC-05B: Consume SHLink and Access Patient Summary

Scenario: Clinical Solution A decodes SHLink and Retrieves Patient Summary from Document Repository.

Assumption: The Patient Summary is encrypted and either pre-prepared and stored in a secure location, or made available when the SHLink is accessed and the data is requested. As a prerequisite, the patient shares the passcode with the HCP to allow accessing the Patient Summary associated with the SHLink. Typically the HCP is authenticated in their clinical system such as an EMR or HIS.

Implementation Option : This sequence diagram provides the option of using the CA:SHL Interoperability Specifications that provide support for consuming a Shareable Health Link associated with a Patient Summary. This profile includes an SHLink Consumer and an SHLink Responder actor. Additionally, this sequence diagram uses the 'CA:SHL Retrieve SHLink Manifest' CA:SHL-2 transaction to retrieve the manifest file and 'CA:SHL Retrieve SHLink Clinical Data' CA:SHL-3 transaction to retrieve the Patient Summary document. The client-side consumer application has the capability of scanning QR codes, interpreting SHLinks and access encrypted data. The SHLink optionally contains a viewer URL that is recognizable by a browser and can display relevant information. A viewer might have the capability to consume the SHLink and display the Patient Summary, if the client application does not have the necessary capabilities. The location where the Patient Summary is available for access must be short-lived and and potentially limited to one-time use.

Sequence Diagram