Core Interoperability Specification Requirements

Actor Mapping to Interoperability Specification

The Use Case Actors, Services and Optionality are conveyed in the first three columns of Tables 1 to 3 in the section below. The second part of the table (columns 4-6) provides the mapping of the Use Case Actor to the detailed specifications (such as IHE Profiles, Technical Actors, Optionality) that systems shall implement to exchange healthcare information in the context of these Use Cases. The purpose of the tables below is to map the use case actors to the technical actors and the services they are supporting. These tables are aligned with the flow captured in the sequence diagrams.

For a selected Use Case Actor (columns 1-3), the system shall implement all the requirements (some optionality when allowed) listed in the second part of the table (columns 4-6). This includes the referenced healthcare profiles, the standards specified and terminology standards. For Technical Actors, which map to IHE Profiles or pan-Canadian Interoperability Specifications (MHD, PDQm, PMIR, CA:FeX, etc.), refer to the Reference Architecture, here. Additionally, there are two implementation options defined in this specification (MHD and CA:FeX), which may be used to solve for the use cases outlined in the tables below.

The following interoperability requirement tables are categorized by options for implementation patterns that jurisdictions may choose based on their maturity, capabilities and current state:

  • Document Repository/Registry Pattern using MHD
  • FHIR Health Information Exchange (HIE) Pattern using CA:FeX

Legend

R = Required

O = Optional

Conformance Requirements for UC-01: HCP Creates a PS-CA

Note: For details about Profiles/Standards listed in the tables below, please refer to Reference Architecture (RA) standards.

Table 1.1 Interoperability Conformance Requirements for Use Case 1: HCP Creates PS-CA : Mapping Use Case Actors to Technical Actor and its related Profile or Standard

Option 1: Document Repository/Registry Pattern

USE CASE ACTOR SERVICE SUPPORTED OPT TECHNICAL ACTOR OPT PROFILE / STANDARD
PS-CA Producer Authenticate User O Client (e.g., EMR) O Internet User Authorization (IUA)
PS-CA Producer Identify Patient O Client (e.g., EMR) O Use Existing Standards Employed by the Clinical System
PS-CA Producer Identify Patient O Patient Demographic Consumer O PDQM
PS-CA Producer Retrieve clinical data from local data sources (Patient Identifier) R Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System
PS-CA Producer Assemble and review Patient Summary R Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System
PS-CA Producer Update Current Valuesets and ConceptMaps O Client (e.g., EMR) O SVCM
PS-CA Producer Omit or Mask Data based on Jurisdictional Policy O Client (e.g., EMR) O Jurisdictional Requirement
PS-CA Producer Save PS-CA to Document Repository R Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System
PS-CA Producer Save PS-CA to Document Repository R Document Source R MHD
Document Repository (Local to PS-CA Producer or Central) Save PS-CA to Document Repository R Document Recipient R MHD
Central Infrastructure Identify Patient O Patient Identity Registry O PMIR

Table 1.2 Interoperability Conformance Requirements for Use Case 1: HCP Creates PS-CA: Mapping Use Case Actors to Technical Actor and its related Profile or Standard

Option 2: FHIR Health Information Exchange (HIE) Pattern

USE CASE ACTOR SERVICE SUPPORTED OPT TECHNICAL ACTOR OPT PROFILE / STANDARD
PS-CA Producer Authenticate User O Client (e.g., EMR) O Internet User Authorization (IUA)
PS-CA Producer Identify Patient O Client (e.g., EMR) O Use Existing Standards Employed by the Clinical System
PS-CA Producer Identify Patient O Patient Demographic Consumer O PDQM
PS-CA Producer Retrieve clinical data from local data sources (Patient Identifier) R Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System
PS-CA Producer Assemble and review Patient Summary R Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System
PS-CA Producer Update Current Valuesets and ConceptMaps O Client (e.g., EMR) O SVCM
PS-CA Producer Omit or Mask Data based on Jurisdictional Policy O Client (e.g., EMR) O Jurisdictional Requirement
PS-CA Producer Save PS-CA to Document Repository R Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System
PS-CA Producer Save PS-CA to Document Repository R Document Source R CA:FeX
Document Repository (Local to PS-CA Producer or Central) Save PS-CA to Document Repository R Document Recipient R CA:FeX
Central Infrastructure Identify Patient O Patient Identity Registry O PMIR

*For Option 2, Document Repository use case actor is a logical role enacted by the Data Recipient which is described in detail in the 'Companion Guide: Reference Architecture'.

Conformance Requirements for UC-02: HCP Views/Consumes a PS-CA

Note: For details about Profiles/Standards listed in the tables below, please refer to Reference Architecture (RA) standards.

Table 2.1 Interoperability Conformance Requirements for Use Case 2: HCP Views/ Consumes PS-CA: Mapping Use Case Actors to Technical Actor and its related Profile or Standard

Option 1: Document Repository/Registry Pattern

USE CASE ACTOR SERVICE SUPPORTED OPT TECHNICAL ACTOR OPT PROFILE / STANDARD
PS-CA Consumer Authenticate User O Client (e.g., EMR) O Internet User Authorization (IUA) - see RA specifications
PS-CA Consumer Identify Patient O Client (e.g., EMR) O Use Existing Standards Employed by the Clinical System
PS-CA Consumer Identify Patient O Patient Demographic Consumer O PDQM -see RA specifications
PS-CA Consumer Request Patient Summary References (Patient Identifier) R Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System
PS-CA Consumer Request Patient Summary References (Patient Identifier) R Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System
PS-CA Consumer Return Patient Summary References R Document Consumer R MHD
PS-CA Consumer Return Patient Summary R Document Consumer R MHD
PS-CA Consumer Perform transformation between different formats O Client (e.g., EMR) O Use Existing Standards Employed by the Clinical System (Render to Specific Format (PDF))
PS-CA Consumer Perform transformation between different formats O Client (e.g., EMR) O CA:FMT (e.g., FHIR to CDA, Export to PDF, etc.)
PS-CA Consumer Download/Print PS-CA O Client (e.g., EMR) O Use Existing Standards Employed by the Clinical System
PS-CA Consumer Update Current ValueSets and ConceptMaps O Client (e.g., EMR) O SVCM
Document Repository (Local to PS-CA Producer or Central) Retrieve PS-CA References from Document Repository R Document Responder R MHD
Document Repository (Local to PS-CA Producer or Central) Retrieve PS-CA from Document Repository R Document Responder R MHD
Central Infrastructure Identify Patient O Patient Identity Registry O PMIR

Table 2.2 Interoperability Conformance Requirements for Use Case 2: HCP Views/ Consumes PS-CA: Mapping Use Case Actors to Technical Actor and its related Profile or Standard

Option 2: FHIR Health Information Exchange (HIE) Pattern

USE CASE ACTOR SERVICE SUPPORTED OPT TECHNICAL ACTOR OPT PROFILE / STANDARD
PS-CA Consumer Authenticate User O Client (e.g., EMR) O Internet User Authorization (IUA) - see RA specifications
PS-CA Consumer Identify Patient O Client (e.g., EMR) O Use Existing Standards Employed by the Clinical System
PS-CA Consumer Identify Patient O Patient Demographic Consumer O PDQM -see RA specifications
PS-CA Consumer Request Patient Summary References (Patient Identifier) R Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System
PS-CA Consumer Request Patient Summary (Bundle ID) R Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System
PS-CA Consumer Return Patient Summary Compositions R Document Consumer R CA:FeX
PS-CA Consumer Return Patient Summary R Document Consumer R CA:FeX
PS-CA Consumer Perform transformation between different formats O Client (e.g., EMR) O Use Existing Standards Employed by the Clinical System (Render to Specific Format (PDF))
PS-CA Consumer Perform transformation between different formats O Client (e.g., EMR) O CA:FMT (e.g., FHIR to CDA, Export to PDF, etc.)
PS-CA Consumer Download/Print PS-CA O Client (e.g., EMR) O Use Existing Standards Employed by the Clinical System
PS-CA Consumer Update Current ValueSets and ConceptMaps O Client (e.g., EMR) O SVCM
Document Repository (Local to PS-CA Producer or Central) Retrieve Patient Summary Compositions From Document Repository R Document Responder R MHD
Document Repository (Local to PS-CA Producer or Central) Retrieve Patient Summary Bundle Document Repository R Data Responder R CA:FeX
Central Infrastructure Identify Patient O Patient Identity Registry O PMIR

*For Option 2, Document Repository use case actor is a logical role enacted by the Data Recipient which is described in detail in the 'Companion Guide: Reference Architecture'.

Conformance Requirements for UC-03: Patient Views/Consumes a PS-CA

Note: For details about Profiles/Standards listed in the tables below, please refer to Reference Architecture (RA) standards.

Table 3.1 Interoperability Conformance Requirements for Use Case 3: Patient Views/Consumes PS-CA : Mapping Use Case Actors to Technical Actor and its related Profile or Standard

Option 1: Document Repository/Registry Pattern

USE CASE ACTOR SERVICE SUPPORTED OPT TECHNICAL ACTOR OPT PROFILE / STANDARD
Patient Portal Authenticate User O Client App O Internet User Authorization (IUA)
Patient Portal Identify Patient O Client App O Use Existing Standards Employed by the Clinical System
Patient Portal Identify Patient O Patient Demographic Consumer O PDQM -see RA specifications
Patient Portal Request Patient Summary References (Patient Identifier) R Client App R Use Existing Standards Employed by the Clinical System
Patient Portal Request Patient Summary (Patient Summary References) R Client App R Use Existing Standards Employed by the Clinical System
Patient Portal Return Patient Summary References R Document Consumer R MHD
Patient Portal Return Patient Summary R Document Consumer R MHD
Patient Portal Perform transformation between different formats O Client App O Use Existing Standards Employed by the Clinical System (Render to Specific Format (PDF))
Patient Portal Perform transformation between different formats O Client App O CA:FMT (e.g., FHIR to CDA, Export to PDF, etc.)
Patient Portal Download/Print PS-CA O Client App O Use Existing Standards Employed by the Clinical System
Patient Portal Save to Portable Media O Client App O Use Existing Standards Employed by the Clinical System
Patient Portal Save to Portable Media O Portable Media Creator O XDM
Document Repository (Local to PS-CA Producer or Central) Retrieve PS-CA References from Document Repository R Document Responder R MHD
Document Repository (Local to PS-CA Producer or Central) Retrieve PS-CA from Document Repository R Document Responder R MHD
Central Infrastructure Identify Patient O Patient Identity Registry O PMIR

Table 3.2 Interoperability Conformance Requirements for Use Case 2: HCP Views/ Consumes PS-CA: Mapping Use Case Actors to Technical Actor and its related Profile or Standard

Option 2: FHIR Health Information Exchange (HIE) Pattern

USE CASE ACTOR SERVICE SUPPORTED OPT TECHNICAL ACTOR OPT PROFILE / STANDARD
Patient Portal Authenticate User O Client App O Internet User Authorization (IUA)
Patient Portal Identify Patient O Client App O Use Existing Standards Employed by the Clinical System
Patient Portal Identify Patient O Patient Demographic Consumer O PDQM
Patient Portal Request Search Patient Summary (Patient Identifier) R Client App R Use Existing Standards Employed by the Clinical System
Patient Portal Request Patient Summary (Bundle ID) R Client App R Use Existing Standards Employed by the Clinical System
Patient Portal Return Patient Summary Compositions R Document Consumer R CA:FeX
Patient Portal Return Patient Summary R Document Consumer R CA:FeX
Patient Portal Perform transformation between different formats O Client App O Use Existing Standards Employed by the Clinical System (Render to Specific Format (PDF))
Patient Portal Perform transformation between different formats O Client App O CA:FMT (e.g., FHIR to CDA, Export to PDF, etc.)
Patient Portal Download/Print PS-CA O Client App O Use Existing Standards Employed by the Clinical System
Patient Portal Save to Portable Media O Client App O Use Existing Standards Employed by the Clinical System
Patient Portal Save to Portable Media O Portable Media Creator O XDM
Document Repository (Local to PS-CA Producer or Central) Retrieve Patient Summary Compositions from Document Repository R Data Responder R CA:FeX
Document Repository (Local to PS-CA Producer or Central) Retrieve Patient Summary Bundle from Document Repository R Data Responder R CA:FeX
Central Infrastructure Identify Patient O Patient Identity Registry O PMIR

*For Option 2, Document Repository use case actor is a logical role enacted by the Data Recipient which is described in detail in the 'Companion Guide: Reference Architecture.'

Conformance Requirements for UC-04: HCP Requests PS-CA On Demand

Note: For details about Profiles/Standards listed in the tables below, please refer to Reference Architecture (RA) standards.

** Table 4.1 Interoperability Conformance Requirements for Use Case 4: HCP Requests PS-CA On Demand : Mapping Use Case Actors to Technical Actor and its related Profile or Standard**

Option 1: Clinical FHIR Data Sources are internal to the Clinical Data Repository

USE CASE ACTOR SERVICE SUPPORTED OPT TECHNICAL ACTOR OPT PROFILE / STANDARD
PS-CA Consumer Authenticate User O Client (e.g., EMR) O Internet User Authorization (IUA)
PS-CA Consumer Identify Patient O Client (e.g., EMR) O Use Existing Standards Employed by the Clinical System
PS-CA Consumer Identify Patient O Patient Demographic Consumer O PDQM
PS-CA Consumer Request Patient Summary on-demand (Patient Identifier) R Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System
PS-CA Consumer Request Patient Summary on-demand (Patient Identifier) R Data Consumer R CA:FeX (CA:FeX-3D with $summary)
PS-CA Consumer Return Patient Summary Document Bundle R Document Consumer R Use Existing Standards Employed by the Clinical System
PS-CA Consumer Perform transformation between different formats O Client (e.g., EMR) O Use Existing Standards Employed by the Clinical System (Render to Specific Format (PDF)
PS-CA Consumer Perform transformation between different formats O Client (e.g., EMR) O CA:FMT (e.g., FHIR to CDA, Export to PDF, etc.)
Clinical Data Repository (Local to PS-CA Producer or Central) Retrieve patient FHIR data resources from internal data sources R Data Responder R Use Existing Standards Employed by the Clinical System
Clinical Data Repository (Local to PS-CA Producer or Central) Assemble Patient Summary from discrete FHIR resources R Data Responder R Use Existing Standards Employed by the Clinical System
Clinical Data Repository (Local to PS-CA Producer or Central) Return Patient Summary Document Bundle R Data Responder R CA:FeX(CA:FeX-3D with $summary)
Central Infrastructure Identify Patient O Patient Identity Registry O PMIR

Table 4.2 Interoperability Conformance Requirements for Use Case 4: HCP Requests PS-CA On Demand: Mapping Use Case Actors to Technical Actor and its related Profile or Standard

Option 2: Clinical FHIR Data Sources are internal and/or external to the Clinical Data Repository

USE CASE ACTOR SERVICE SUPPORTED OPT TECHNICAL ACTOR OPT PROFILE / STANDARD
PS-CA Consumer Authenticate User O Client (e.g., EMR) O Internet User Authorization (IUA)
PS-CA Consumer Identify Patient O Client (e.g., EMR) O Use Existing Standards Employed by the Clinical System
PS-CA Consumer Identify Patient O Patient Demographic Consumer O PDQM
PS-CA Consumer Request Patient Summary on-demand Document Reference (Patient Identifier) R Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System
PS-CA Consumer Request Patient Summary on-demand Document Reference (Patient Identifier) R Data Consumer R CA:FeX (CA:FeX-2B with $docref)
PS-CA Consumer Return Patient Summary Document Reference (include URL to Document Bundle) R Document Consumer R CA:FeX (CA:FeX-3B)
PS-CA Consumer Return Patient Summary Document Bundle R Data Consumer) R Use Existing Standards Use Existing Standards Employed by the Clinical System
PS-CA Consumer Perform transformation between different formats O Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System (Render to Specific Format (PDF)
PS-CA Consumer Download/Print PS-CA O Client (e.g., EMR) O Use Existing Standards Employed by the Clinical System
Clinical Data Repository (Local to PS-CA Producer or Central) Retrieve patient FHIR data resources from internal and/or external data sources [Sync or Async] R Data Responder R Use Existing Standards Employed by the Clinical System
Clinical Data Repository (Local to PS-CA Producer or Central) Generate Patient Summary Document Reference (include URL where Document Bundle is or will be available R Data Responder R Use Existing Standards Employed by the Clinical System
Clinical Data Repository (Local to PS-CA Producer or Central) Return Patient Summary on-demand Document Reference (include URL to Document Bundle) R Data Responder R CA:FeX (CA:FeX-2B with $docref)
Clinical Data Repository (Local to PS-CA Producer or Central) Return Patient Summary Document Bundle R Data Responder R CA:FeX (CA:FeX-3B)
Central Infrastructure Identify Patient O Patient Identity Registry O PMIR

Conformance Requirements for UC-05: Patient Mediated Access and Exchange of their Patient Summary

Note: For details about Profiles/Standards listed in the tables below, please refer to Reference Architecture (RA) standards.

Table 5.1 Interoperability Conformance Requirements for Use Case 5: Patient Mediated Access and Exchange of their Patient Summary: Mapping Use Case Actors to Technical Actor and its related Profile or Standard

Part A: Patient Requests Access to Their Shareable Patient Summary

USE CASE ACTOR SERVICE SUPPORTED OPT TECHNICAL ACTOR OPT PROFILE / STANDARD
Patient-facing Application (e.g. Patient Portal or Mobile App) Authenticate User O Client App O Internet User Authorization (IUA)
Patient-facing Application (e.g. Patient Portal or Mobile App) Identify Patient O Client App O Use Existing Standards Employed by the Clinical System
Patient-facing Application (e.g. Patient Portal or Mobile App) Identify Patient O Patient Demographic Consumer O PDQM -see RA specifications
Patient-facing Application (e.g. Patient Portal or Mobile App) Request Generate SHLink (Patient Identifier, passcode) R Client App R Use Existing Standards Employed by the Clinical System
Patient-facing Application (e.g. Patient Portal or Mobile App) Request Generate SHLink (Patient Identifier, passcode) R SHLink Requester R CA:SHL Generate SHLink [CA:SHL-1]
Patient-facing Application (e.g. Patient Portal or Mobile App) Return Patient Summary SHLink O SHLink Requester 0 Use Existing Standards Employed by the Clinical System
Patient-facing Application (e.g. Patient Portal or Mobile App) Generate QR Code R SHLink Requester R Use Existing Standards Employed by the Clinical System
Patient-facing Application (e.g. Patient Portal or Mobile App) Return QR Code O SHLink Requester O Use Existing Standards Employed by the Clinical System (Render to Specific Format (PDF))
Patient-facing Application (e.g. Patient Portal or Mobile App) Download/Save QR Code to Phone/Media O Client App O Use Existing Standards Employed by the Clinical System
Patient Portal Download/Save QR Code to Phone/Media R Client App R Use Existing Standards Employed by the Clinical System
Clinical Data Repository (Local to PS-CA Producer or Central) Generate SHLink artifacts (manifest URL, encrypt/decrypt key, etc.) R SHLink Creator R CA:SHL
Clinical Data Repository (Local to PS-CA Producer or Central) Generate SHLink (with optional viewer URL) R SHLink Creator R CA:SHL
Clinical Data Repository (Local to PS-CA Producer or Central) Return Patient Summary SHLink R SHLink Creator R CA:SHL Generate SHLink [CA:SHL-1]
Central Infrastructure Identify Patient O Patient Identity Registry O PMIR

Table 5.2 Interoperability Conformance Requirements for Use Case 5: Patient Mediated Access and Exchange of their Patient Summary: Mapping Use Case Actors to Technical Actor and its related Profile or Standard

Part B: Patient presents their QR code or SHL to HCP for access to their Patient Summary

USE CASE ACTOR SERVICE SUPPORTED OPT TECHNICAL ACTOR OPT PROFILE / STANDARD
PS-CA Consumer Authenticate User O Client App O Internet User Authorization (IUA)
PS-CA Consumer Identify Patient O Client App O Use Existing Standards Employed by the Clinical System
PS-CA Consumer Identify Patient O Patient Demographic Consumer O PDQM
PS-CA Consumer Scan QR Code O Client (e.g., EMR) O Use Existing Standards Employed by the Clinical System
PS-CA Consumer Request retrieve SHLink data [recipient, passcode] R Client (e.g., EMR) R Use Existing Standards Employed by the Clinical System
PS-CA Consumer Decode SHLink R SHLink Consumer R Use Existing Standards Employed by the Clinical System
PS-CA Consumer Request retrieve SHLink manifest [recipient, passcode] R SHLink Consumer O CA:SHL Retrieve SHLink Manifest [CA:SHL-2]
PS-CA Consumer Request retrieve PS-CA O O O CA:SHL Retrieve SHLink Clinical Data [CA:SHL-3]
PS-CA Consumer Decrypt PS-CA data R SHLink Consumer R Use Existing Standards Employed by the Clinical System
PS-CA Consumer Return PS-CA data R SHLink Consumer R Use Existing Standards Employed by the Clinical System
PS-CA Consumer Access SHLink viewer URL O Client App R Use Existing Standards Employed by the Clinical System
PS-CA Consumer Display PS-CA and/or related data O Client App R Use Existing Standards Employed by the Clinical System
Clinical Data Repository (Local to PS-CA Producer or Central) Generate SHLink Manifest with updated PS-CA location R SHLink Responder R Use Existing Standards Employed by the Clinical System
Clinical Data Repository (Local to PS-CA Producer or Central) Return SHLink manifest R SHLink Responder R CA:SHL Retrieve SHLink Manifest [CA:SHL-2]
Clinical Data Repository (Local to PS-CA Producer or Central) Retrieve PS-CA referenced in Manifest R SHLink Responder R Use Existing Standards Employed by the Clinical System
Clinical Data Repository (Local to PS-CA Producer or Central) Return PS-CA Document Bundle R SHLink Responder R CA:SHL Retrieve SHLink Clinical Data [CA:SHL-3]
Clinical Data Repository (Local to PS-CA Producer or Central) Return PS-CA and/or related data O Clinical Solution O Use Existing Standards Employed by the Clinical System
Central Infrastructure Identify Patient O Patient Identity Registry O PMIR

PS-CA Actor Conformance

A system conforming to this Core Interoperability Specification shall claim conformance at the level of a Use Case Actor (first columns of Tables 1.1, 1.2, 2.1, 2.2, 3.1 and 3.2). A system may claim conformance to one or more Use Case Actors among:

  • PS-CA Producer
  • PS-CA Consumer
  • Document Repository (Local or Central)
  • Central Infrastructure
  • Patient Portal

PS-CA Producer and PS-CA Consumer use case actor roles will primarily be taken up by EMR clinical solution vendors. Document Repository and Central Infrastructure use case actor roles can be taken up either by EMR clinical solution vendors or jurisdictions depending on the implementation approach that the jurisdiction decides to adopt. Similarly, the Patient Portal use case actor can be taken up either by a vendor or jurisdiction depending on the approach and policies defined regarding patient/subject-of-care access to their patient summary.

In order to implement a system that fully supports the pan-Canadian Patient Summary Interoperability Specifications, the system shall be able to claim conformance to 'Required' services and it's associated requirements as defined in Core Interoperability Specification Requirements.

OpenAPI Specification

It is recommended to use the OpenAPI UI to access the interactive API documentation. The API allows developers to test API calls directly in the browser. There are two APIs:

  • Open API for MHD: available here

  • Open API for CA:FeX: available here

Constraints on PS-CA Use Case Actors: Option 1 - Document Repository/Registry Pattern Using MHD Profile

There are some design constraints on use case actors when developing functionality to support the services mapped to those Use Case Actors.

Note: The scope of this section is limited to the constraints that are applicable to IHE MHD profile actors and transactions. The two key services supported by the IHE MHD Profile are:

  • Save PS-CA to Document Repository
  • Retrieve PS-CA from Document Repository

This section provides key design constraints for implementation of these two required services using IHE methodology and FHIR standards.

Save PS-CA to Document Repository

The Save PS-CA to Document Repository service shall be implemented using PS-CA Producer and Document Repository Use Case Actors.

These actors shall use the IHE Transaction Provide Document Bundle [ITI-65] of the MHD profile that passes a Provide Document Bundle Request from a Document Source to a Document Recipient.

Provide Document Bundle [ITI-65] This message uses the HTTP POST method on the target Provide Document Bundle endpoint to convey the metadata and the document(s) as a FHIR transaction.

Trigger Events This method is invoked when the Document Source needs to submit one or more documents to a Document Recipient.

Message Semantics The Document Source shall initiate a FHIR “transaction” using a “create” action by sending an HTTP POST request method composed of a FHIR Bundle Resource. The media type of the HTTP body shall be either application/fhir+json or application/fhir+xml.

Expected Actions The Document Recipient shall accept both media types application/fhir+json and application/fhir+xml. On receipt of the submission, the Document Recipient shall validate the resources and respond with one of the HTTP codes defined in the response Message Semantics.

Refer to the Provide Document Bundle [ITI-65] transaction details page for additional information.

Retrieve PS-CA from Document Repository

The Retrieve PS-CA from Document Repository service shall be implemented using the PS-CA Consumer and Document Repository Use Case Actors.

These actors shall use the following IHE Transactions of the MHD profile to find document references, document lists and retrieval of an identified Patient Summary document:

  • Find Document Lists [ITI-66]
  • Find Document References [ITI-67]
  • Retrieve Document [ITI-68]

Find Document List [ITI-66]

This message uses the search method parameterized query to obtain List Resources from the Document Responder.

Trigger Events

When the Document Consumer needs to discover List Resources matching various metadata parameters it issues a Find Document Lists message.

Message Semantics The Document Consumer executes an HTTP search against the Document Responder List endpoint. The search target follows the FHIR HTTP specification, addressing the List Resource http://hl7.org/fhir/R4/http.html

[base]/List?<query>

This URL is configurable by the Document Responder and is subject to the following constraints:

  • The <query> represents a series of encoded name-value pairs representing the filter for the query as well as control parameters to modify the behavior of the Document Responder such as response format, or pagination.
  • The Document Consumer may use GET or POST based searches. The Document Responder shall support both GET and POST based searches http://hl7.org/fhir/R4/http.html#search.

Query Search Parameters The Document Consumer may supply, and the Document Responder shall be capable of processing all query parameters listed below. All query parameter values shall be appropriately encoded per RFC3986 “percent” encoding rules. Note that percent encoding does restrict the character set to a subset of ASCII characters which is used for encoding all other characters used in the URL.

  • The Document Consumer shall include search parameters patient or patient.identifier, code, and status. The other parameters described below are optional.
  • The Document Responder shall implement the parameters described below. The Document Responder may choose to support additional query parameters beyond the subset listed below. Any additional query parameters supported shall be supported according to the core FHIR specification. Such additional parameters are considered out of scope for this transaction. Any additional parameters not supported should be ignored and shall not cause a failure.
Parameter Type Description
author.given string Specifies the given name of the author associated with the DocumentReference Resource, following FHIR Chaining Parameters search methodology.
author.family string Specifies the family name of the author associated with the DocumentReference Resource, following FHIR Chaining Parameters search methodology.
category token Specifies the general classification of the DocumentReference Resource, corresponding to the classCode in Document Sharing nomenclature.
creation dateTime Specifies a search against DocumentReference.content.attachment.creation. See FHIR date search for details.
date date Specifies the creation time of the DocumentReference. See FHIR date search for details.
event token Specifies the main clinical acts documented by the DocumentReference Resource, corresponding to the eventCodeList in Document Sharing nomenclature.
facility token Specifies the kind of facility (DocumentReference.context.facilityType), corresponding to healthcareFacilityTypeCode in Document Sharing nomenclature.
format token Specifies the format of the DocumentReference Resource, corresponding to the formatCode in Document Sharing nomenclature.
identifier token Specifies an identifier for the DocumentReference and/or its contained document (DocumentReference.masterIdentifier and DocumentReference.identifier).
patient Reference(Patient) Specifies the patient associated with the DocumentReference. Patient references may be retrieved using PDQm or PIXm Profiles.
patient.identifier token Specifies an identifier associated with the patient, following FHIR Chaining Parameters search methodology.
period date Represents the time of service documented by the DocumentReference. This corresponds to the serviceStartTime and serviceStopTime in Document Sharing nomenclature. See FHIR date search for details.
related reference Represents other identifiers associated with the DocumentReference Resource, corresponding to referenceIdList in Document Sharing nomenclature.
security-label token Specifies the security labels of the document, corresponding to confidentialityCode in Document Sharing nomenclature.
setting token Specifies the specific practice setting of the DocumentReference Resource, corresponding to practiceSettingCode in Document Sharing nomenclature.
status token Specifies the status of the DocumentReference Resource, corresponding to availabilityStatus in Document Sharing nomenclature. The token system is not populated.
FHIR Code: Current → ebRIM Code: urn:oasis:names:tc:ebxml-regrep:StatusType:Approved
FHIR Code: Superseded → ebRIM Code: urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated
type token Specifies the specific type of the DocumentReference Resource, corresponding to typeCode in Document Sharing nomenclature. See ITI TF-2x: Appendix Z.2 for constraints on the token search parameter type.

Expected Action

The Document Responder shall process the query to discover the List entries that match the search parameters given. Refer to the Find Document Lists [ITI-66] transaction details page for additional information.

Find Document References [ITI-67] This message uses the search method parameterized query to obtain DocumentReference Resources from the Document Responder.

Trigger Events When the Document Consumer needs to discover DocumentReference Resources matching various metadata parameters, it issues a Find Document References message.

Message Semantics The Document Consumer executes an HTTP search against the Document Responder's DocumentReference URL. The search target follows the FHIR HTTP specification, addressing the DocumentReference Resource http://hl7.org/fhir/R4/http.html:

[base]/DocumentReference?<query>

This URL is configurable by the Document Responder and is subject to the following constraints:

  • The <query> represents a series of encoded name-value pairs representing the filter for the query, as specified in Section Query Search Parameters, as well as control parameters to modify the behavior of the Document Responder such as response format, or pagination.
  • The Document Consumer may use GET or POST based searches. The Document Responder shall support both GET and POST based searches http://hl7.org/fhir/R4/http.html#search.

Query Search Parameters

The Document Consumer may supply, and the Document Responder shall be capable of processing, all query parameters listed below. All query parameter values shall be appropriately encoded per RFC3986 “percent” encoding rules. Note that percent encoding does restrict the character set to a subset of ASCII characters which is used for encoding all other characters used in the URL.

  • The Document Consumer shall include search parameters patient or patient.identifier, and status. The other parameters described below are optional.
  • The Document Responder must implement the parameters described below. The Document Responder may choose to support additional query parameters beyond the subset listed below. Any additional query parameters supported shall be supported according to the core FHIR specification. Such additional parameters are considered out of scope for this transaction. Any additional parameters not supported should be ignored and shall not cause a failure.
Query Search Parameter Description
author.given and author.family Parameters of type string specifying the name parts of the author person associated with the DocumentReference Resource. This follows the FHIR Chaining Parameters search methodology.
category Parameter of type token specifying the general classification of the DocumentReference Resource, corresponding to the classCode in Document Sharing nomenclature.
creation IHE-defined parameter (DocumentReference-Creation) of type dateTime, specifying a search against DocumentReference.content.attachment.creation. See FHIR date search.
date Parameter of type date, specifying the time when the DocumentReference was created. See FHIR date search.
event Parameter of type token, specifying the main clinical acts documented by the DocumentReference Resource, corresponding to the eventCodeList in Document Sharing nomenclature.
facility Parameter of type token, specifying the kind of facility found in DocumentReference.context.facilityType, corresponding to healthcareFacilityTypeCode in Document Sharing nomenclature.
format Parameter of type token, specifying the format of the DocumentReference Resource, corresponding to the formatCode in Document Sharing nomenclature.
identifier Parameter of type token, specifying an identifier for the DocumentReference or contained document. Represents searches on DocumentReference.masterIdentifier and DocumentReference.identifier.
patient Parameter of type Reference(Patient). The Document Consumer may retrieve this reference using the PDQm or PIXm Profile.
patient.identifier Parameter of type token, specifying an identifier associated with the patient assigned to the DocumentReference Resource. Follows FHIR Chaining Parameters search methodology.
period Parameter of type date, representing the time of service documented by the DocumentReference. Corresponds to the serviceStartTime and serviceStopTime in Document Sharing nomenclature. See FHIR date search.
related Parameter of type reference, representing other identifiers associated with the DocumentReference Resource, corresponding to referenceIdList in Document Sharing nomenclature.
security-label Parameter of type token, specifying the security labels of the document, corresponding to confidentialityCode in Document Sharing nomenclature.
setting Parameter of type token, specifying the specific practice setting of the DocumentReference Resource, corresponding to practiceSettingCode in Document Sharing nomenclature.
status Parameter of type token, specifying the status of the DocumentReference Resource, corresponding to availabilityStatus in Document Sharing nomenclature.
FHIR Code: Current → ebRIM Code: urn:oasis:names:tc:ebxml-regrep:StatusType:Approved
FHIR Code: Superseded → ebRIM Code: urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated
type Parameter of type token, specifying the specific type of the DocumentReference Resource, corresponding to typeCode in Document Sharing nomenclature. See ITI TF-2x: Appendix Z.2 for constraints on the use of the token search parameter type.

Expected Actions The Document Responder shall process the query to discover the DocumentReference entries that match the search parameters given.

Refer to the Find Document References [ITI-67] transaction details page for additional information including the Find Document References Response Message.

Retrieve Document [ITI-68] This transaction is used by the Document Consumer to retrieve a document from the Document Responder.

Trigger Events The Document Consumer wants to obtain a document.

Message Semantics

The Document Consumer sends an HTTP GET request to the server. The Document Consumer request may be to retrieve the document content referenced by a DocumentReference.content.attachment.url.

The Document Consumer may provide an HTTP Accept header, according to the semantics of the HTTP protocols. This enables the Document Consumer to indicate preferred mime-types such that the Document Responder could provide the document requested in an encoding other than the encoding indicated in the DocumentReference. For example, indicating application/fhir+json could result in the response from the Document Responder being a JSON FHIR Bundle of type document with all the content encoded as FHIR resources.

The only MIME type assured to be returned is the MIME type indicated in the DocumentReference.content.attachment.contentType.

The HTTP If-Unmodified-Since header shall not be included in the GET request.

Expected Actions

The Document Responder shall provide the document in the requested MIME type or reply with an HTTP status code indicating the error condition. The Document Responder is not required to transform the document.

Refer to the Retrieve Document [ITI-68] transaction details page for additional information including the Retrieve Document Response Message.

Constraints on PS-CA Use Case Actors: Option 2 - FHIR Health Information Exchange (HIE) Pattern Using CA:FeX

The section below captures some of the design constraints on use case actors when developing functionality to support the services mapped to those Use Case Actors.

Note: The scope of this section is limited to the constraints that are applicable to actors and transactions defined in the CA:FeX Interoperability Specifications.

While global implementations are actively testing various ways to exchange patient summaries and other documents (See Pan-Canadian FHIR Exchange (CA:FeX) Interoperability Specifications: Preface), more sophisticated exchange patterns may not be as accessible for implementers in the current state. As such, PS-CA has identified the patterns in CA:FeX that early implementers are most likely to start with.

This implementation is currently constrained to only support FHIR-assembled documents in the form of a Bundle of resources of type "document" that has a Composition resource as the first resource in the bundle, followed by a series of other resources, referenced from the Composition resource, that provide supporting evidence for the document.

The two key services supported by CA:FeX are:

  • Submit PS-CA to Document Repository

    • Submit FHIR Document [CA:FeX-1A]

  • Retrieve PS-CA from Document Repository

    • Search FHIR Document [CA:FeX-2A]
    • Retrieve FHIR Document [CA:FeX-3A]

The following section provides key design constraints for implementation of these two required services using the CA:FeX Interoperability Specifications and FHIR standards.

Save PS-CA to Document Repository

PS-CA Producer attempts to save a PS-CA in the Document Repository. The PS-CA Producer implements the Data Source actor from the CA:FeX Interoperability Specifications by using the Save PS-CA to Document Repository service. Similarly, the Document Repository implements the Data Recipient actor from the CA:FeX Interoperability Specifications.

These actors shall use the transaction Submit FHIR Document [CA:FeX-1A] of CA:FeX that executes a Submit Data Request from a Data Source to a Data Recipient.

Note: Global, pan-Canadian, and jurisdictional practices for document lifecycle management of patient summaries are still in development. For this reason, the management, verification, replacement and deprecation of documents, are out of scope of the guidance included in this release but have been included in the roadmap for future releases. This does not preclude or prevent early implementers from defining their document management practices and beginning to exercise them in their own specifications.

Submit FHIR Document [CA:FeX-1A]

This message involves a request by a Data Source to transfer a PS-CA FHIR Document Bundle to a Data Recipient. The request is received by a Data Recipient which stores the received PS-CA document bundle and returns an HTTP response code.

Trigger Events

This method is invoked when the Data Source needs to submit a FHIR Document Bundle to a Data Recipient (Document Repository).

Message Semantics

This message uses the HTTP POST method on the target Submit Data endpoint to convey the metadata and the document(s) as a FHIR transaction. The Data Source shall initiate a FHIR “transaction” using a “create” action by sending an HTTP POST request method composed of a FHIR Bundle Resource (with type of document). The content type of the HTTP body shall be either application/fhir+json or application/fhir+xml.

Expected Action

The Data Recipient shall accept both content types application/fhir+json and application/fhir+xml. On receipt of the submission, the Data Recipient shall validate the resources and respond with one of the HTTP response codes and an OperationOutcome, if applicable. For additional information on HTTP response codes, refer to Exchanging Documents in FHIR in the CA:FeX Specifications.

Retrieve PS-CA from Document Repository

The PS-CA Consumer and Document Repository (Central) Use Case Actors are required to implement the Retrieve PS-CA from Document Repository service. These actors shall use the following transactions to find document metadata and retrieval of identified Patient Summary document:

  • Search FHIR Document [CA:FeX-2A]
  • Retrieve FHIR Document [CA:FeX-3A]

Search FHIR Document [CA:FeX-2A]

This message involves a query request by Data Consumer for PS-CA FHIR Document Bundle matching the search criteria included in the request. The request is received by Data Responder which returns a searchset Bundle containing the document(s) matching search parameters.

The Data Consumer may use HTTP GET or HTTP POST based searches. The Data Responder shall support both GET and POST based searches.

Trigger Events

When the Data Consumer needs to discover PS-CA FHIR Document Bundles in the Document Repository matching various parameters.

Message Semantics

The Data Consumer executes a FHIR search request against the Data Responder endpoint (FHIR Repository).

The Data Consumer may use HTTP GET or HTTP POST based searches. The Data Responder shall support both GET and POST based searches.

GET [base]/Bundle?composition

POST [base]/Bundle/_search{?&_format=[mime-type]}

Query Search Parameters Search Document Bundle operation shall include the following search parameters:

Query Search Parameter Description Usage Note
timestamp (bundle.timestamp) Parameter of type date, specifying the timestamp when the FHIR bundle was created. See FHIR date search for details. Applied directly on Bundle, does not require chaining. Usage of prefix modifiers encouraged for targeted retrieval by date.
type (bundle.composition.type) Parameter of type token, specifying the kind of composition (LOINC if possible). Follows the FHIR Chaining Parameters search methodology. Will be fixed to 60591-5 for patient summary.
status (bundle.composition.status) Parameter of type token, specifying the status of the composition. Follows the FHIR Chaining Parameters search methodology. Helpful in differentiating compositions that are final vs other statuses. See IPS Note on Composition.status.
patient.identifier (bundle.composition.patient.identifier) Parameter of type token, specifying an identifier associated with the patient to which the FHIR bundle is assigned. Follows the FHIR Chaining Parameters search methodology. Should include system and value to prevent improper retrieval of patient summaries.

Query Result Parameters

Search Document Bundle operation may include the following result parameters to help organize and manage the returned results. They are not required by the specification but are considered conditionally useful in environments where multiple patient summaries are expected to be returned for the subject of care.

Result Parameter Description
_sort This parameter is used to indicate the sort rules (both priority elements and sort direction). Can be applied using comma-separated lists of rules. See Sorting for more details on its use.
_count This parameter is used to minimize the number of results that are returned in a single page of the response bundle. See Page Count for more details on its use.

Note: The combination of _sort and _count can be used to return only the latest resource that meets a particular criteria - set the criteria,and then sort by date in descending order, with _count=1. This way, the last matching resource will be returned.

Example Search Queries

Search by Type of Patient Summary

Note: This is the base that is recommended for all searches for patient summaries to build on. This type is shared by IPS and national implementations of the Patient Summary and therefore will return any patient summaries for the subject of care.

GET [base]/Bundle?composition.type=60591-5

Search by Type + Patient Identifier

GET [base]/Bundle?composition.type=60595-1&composition.patient.identifier=[system]|[value]

Search by Type + Date with qualifier

GET [base]/Bundle?composition.type=60591-5&date=gt2021-01-01

Search by Type + Status

GET [base]/Bundle?composition.type=60591-5&status=final

Expected Actions

The Data Responder shall process the query and return a search result Bundle matching the search criteria included in the request. The FHIR standard provides encodings for responses as either JSON (application/fhir+json) or XML (application/fhir+xml). For additional information on HTTP response codes, refer to Exchanging Documents in FHIR in the CA:FeX Specifications.

Security Considerations

This transaction should not return information that the Data Consumer is not authorized to access. Authorization is inclusive of system, app, user, and purpose, according to local policy, patient consents, and security layering. It is essential to understand that if a jurisdiction doesn't explicitly prohibit the sharing of elements, that would not be considered "not authorized to access". It would merely be a floor describing minimal access requirements. If a jurisdiction explicitly prohibits the sharing of certain elements, that would mean access was not authorized. However, the transaction may return search result bundles that have Reference elements that the Data Consumer may not have access to. This is to say that the authorization need only be to the content returned in the Bundle. There may be references (URLs) for which the content is not authorized. This is considered proper as the Data Consumer would need to retrieve the content pointed to by those references, and at that time the proper authorization decision would be made on that context and content. In this way it is possible for a Data Consumer to get Resources that are pointing at data that the Data Consumer is not authorized to retrieve. Thus, the URLs used must be carefully crafted so as to not expose sensitive data in the URL value. Also most of the significant resources should be included in the document, so it wouldn't be possible to strip out sensitive content, and thus the whole document should be treated as sensitive.

Note to Implementers : It is the responsibility of organizations supporting APIs compliant with the specifications to ensure that the access control policies they have in place are technically realizable by the underlying software.

Retrieve FHIR Document [CA:FeX-3A]

This transaction involves a request by the Data Consumer for retrieving the identified PS-CA FHIR Document Bundle from a FHIR Repository.  The desired Document Bundle is identified by the target server's record ID for that PS-CA FHIR Document Bundle. The request is received by the Data Responder which returns the requested PS-CA FHIR Document Bundle and returns an HTTP response code.

This message uses the HTTP GET request to retrieve the identified PS-CA FHIR Bundle from the central FHIR repository.

Trigger Events

This method is invoked when the Data Consumer needs to retrieve a FHIR Document Bundle.

Message Semantics

The Data Consumer sends an HTTP GET request to the server based on a known resource ID from the Data Responder. The Read operation will return a document Bundle resource containing the Patient Summary Composition and linked resources.

GET [base]/Bundle/[id]

Expected Actions

The Data Responder shall process the query and respond with PS-CA FHIR Bundle matching the specified ID included in the request. When the requested document is returned, the Data Responder shall respond with an HTTP Status Code 200. The HTTP message-body shall be the content of the requested document. For additional information on HTTP response codes, refer to Exchanging Documents in FHIR in the CA:FeX Specifications.

Security Considerations

This transaction should not return information that the Data Consumer is not authorized to access.

Information Models, Application, and Infrastructure

This table provides key implementation guidance for Information Models, Applications and Infrastructure for the PS-CA specifications.

Information Models : Information models are widely used to express structure and process resulting in data interchange formats and behaviours.

Application : Functional specifications are laid down at the Information level. These form the basis for the technical specifications, which are described at the Application level. At this level, agreements have to be made within both the PS-CA Producer and PS-CA Consumer regarding the integration of various applications between which information is exchanged.

Infrastructure : Infrastructure refers to the communication between systems in the different healthcare organizations. Agreements are defined between PS-CA Solutions and jurisdictions on the design of the infrastructures, databases, networks, exchange protocols, tokens and other technologies.

Categories

Category Concept Implementation Guidance
Information Models PS-CA: Data Domains of Interest by Canadian Jurisdiction and Release The relationship to other specifications includes a table representing the:
- Alignment of the PS-CA to the IPS-UV
- Data domains of interest by the participating Canadian jurisdictions (including Manitoba (MB), according to their Home Clinic Client Summary Service). Note that although a PT may have identified interest in a particular data domain, they may choose to prioritize which data domains to include according to their individual Patient Summary roadmaps.
- Data domains included in each PS-CA version
Information Models Valuesets Data residing in a clinical system will need to be mapped to appropriate FHIR profiles and Valuesets from the Content Data Model of the PS-CA specification in Release 1.
- Valuesets define the possible choices of coded concepts for a data element within a PS-CA.
- The concept domains often serve the function of a predicate to be tested.
- In any clinical setting, implemented systems usually host many Valuesets.
- Valuesets are often localized, which makes semantic interoperability between systems difficult without extensive cross-mapping.
Infoway is working with Canadian jurisdictions to identify suitable pan-Canadian valuesets that promote the use of standard terminologies (e.g., SNOMED CT) for exchange of patient summaries in Canada.
The PS-CA specification also encourages global interoperability where possible for international exchange. Valuesets defined by the HL7® FHIR® Base Standard or by the IPS Specification for the purposes of interoperable international exchange can also be found.
For more information on the Valueset implementation patterns, refer to the Terminology Approach page.
Application Patient Summary References (e.g., Patient Identity) The PS-CA Solution (e.g., EMR, EHR) will leverage existing product standards and policies for identifying the patient/subject of care.
- If a central service is available for patient identity, the PS-CA Solution can leverage those services for uniquely identifying the patient/subject of care.
For more information on the patient identity implementation patterns, refer to the IHE Profile PDQm and PMIR in the Appendices.
Application Render to Specific Format (e.g., PDF, CDA) It is recommended that the PS-CA Solution leverages the CA:FMT Interoperability Specifications that provides formatting support service.
- It provides support for transformation of documents between different formats (e.g., from FHIR to PDF, CDA, etc.).
Content is in development and will be added in future roadmaps.
Application Data Interchange Format JSON is the recommended data interchange format for the implementation of the PS-CA interoperability use cases.
- Server actors (PS-CA Recipient and PS-CA Responder) are required to support JSON and XML.
- Client actors (PS-CA Producer and PS-CA Consumer) can use either JSON or XML.
Application Data Conversion / Structured Data The PS-CA should be a FHIR Document (authored and assembled using FHIR).
- For scenarios requiring delivery in a different form (e.g., PDFs), jurisdictions should use conversion and translation services that can convert FHIR Documents.
Application On-Demand Refers to the capability to generate a patient summary at the time it is requested, retrieving the most current health data from available sources (e.g., CDR, EHR) when needed, ensuring timely access for clinical decision-making and patient care.
Infrastructure Jurisdictional Infrastructures Integration of the recommended actors and transactions of the PS-CA standard into existing jurisdictional healthcare infrastructures may differ. It is recommended to review local implementation guidance prior to PS-CA implementation.
Example: Alberta uses certificate-based security for authentication, while Ontario uses token-based security.
Infrastructure Document Management Implementation must refer to jurisdictional specific requirements and policies for document management, including archiving, replacement, etc.