Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

*To learn more about the Supporting Tools, go here.


The following table below describes the integration profiles being tested, purpose of each, actors involved and types of tests and supporting tools.

The Test Cases for Secure Exchange Transactions are designed to validate the interoperability capabilities of the system under test in securely exchanging a Patient Summary. Each test case typically defines a specific transaction or action that must be validated between two systems or actors. It includes detailed prerequisites, expected disruptions, involved actors, step-by-step instructions, and any supporting tools required for testing. To explore and execute these test cases, please access access Gazelle, where you can find the full set of test cases categorized by interoperability profile, actor, and transaction. 

Test Cases for Secure, Exchange Transactions

By Interoperability  Profile

Profile Description and Purpose of Test Cases

Actors Involved

Test Case Peer Type & Supporting Tools*

CA:FeX

The pan-Canadian FHIR Exchange (CA:FeX) is an implementable, testable interoperability specification based on HL7 FHIR Implementation Guides, that defines building blocks to enable creating, consuming and sharing clinical data via FHIR RESTful exchange patterns.

The purpose of testing CA:FeX is to ensure systems have the ability to create, search and retrieve FHIR documents (e.g., Patient Summary) over the internet in a secure manner.

Test cases for CA:FeX will include groupings with other profiles to ensure that patient information is shared securely over the internet (CA:Sec), meets audit requirements (CA:Aud), contains a consistent time (CT) with a median error less than 1 second and is accessed only by authorized users (IUA).

To learn more about CA:FeX, you may watch this short video and review the presentation material here: CA:FeX Profile Information Video (mp4), CA:FeX Profile Information Presentation Deck (PDF)

To read more technical information about CA:FeX, go here.

  • Data Source
  • Data Consumer
  • Data Recipient
  • Data Responder

No-Peer (CA:FeX Client & Server Simulator)

Peer-to-Peer (Gazelle platform)Image Removed


MHD

The Mobile Access to Health Documents (MHD) Profile defines one standardized interface to health document sharing. This profile is applicable to systems where needs are simple, such as pulling the latest summary for display.

The purpose of testing MHD is to ensure systems have the ability to publish and access (i.e. query/retrieve) FHIR documents (e.g., Patient Summary) over the internet in a secure manner.

Test cases for MHD will include groupings with other profiles to ensure that patient information is shared securely over the internet (CA:Sec), meets audit requirements (CA:Aud), contains a consistent time (CT) with a median error less than 1 second and is accessed only by authorized users (IUA).

To learn more about MHD, you may watch this short video and review the presentation material here: MHD Profile Information Video (mp4), MHD Profile Information Presentation Deck (PDF)

To read more technical information about MHD, go here.

  • Document Source
  • Document Recipient
  • Document Consumer
  • Document Responder

No-Peer (MHD Client & Server Simulator)

Peer-to-Peer (Gazelle platform)

IUA

The Internet User Authorization (IUA) is an interoperability profile that provides an authorization profile for the HTTP RESTful transactions.

Being authorized means that the user, patient, or provider has legitimate access to this HTTP RESTful service. The authorization includes identifying the user and the application that is making the request to the HTTP RESTful server, so that the server can make further access control decisions.

The purpose of testing IUA in these test cases is to ensure that the person (e.g., patient, provider, etc. ) and application requesting access to the FHIR document (e.g., Patient Summary) are authorized to have access.

To learn more about IUA, you may watch this short video and review the presentation material here: IUA Profile Information Video (mp4), IUA Profile Information Presentation Deck (PDF)

To learn more about IUA, go here.

  • Authorization Client
  • Resource Server
  • Authorization Server

No-Peer (IUA Simulator)


CA:Sec

The CA:Sec (Canadian Network Security) Implementation Guidance specifies the foundational elements needed to securely execute transactions between two systems. It is based on the ATNA profile and aims to bring improvements via loose coupling, and high cohesion, with focus on secure communication.

The purpose of testing CA:Sec in these test cases is to ensure that the systems exchanging FHIR documents are able to meet the requirements of secure exchange between systems.

To learn more about CA:Sec, you may watch this short video and review the presentation material here: CA:Sec Profile Information Video (mp4), CA:Sec Profile Information Presentation Deck (PDF)

To read more technical information about CA:Sec, go here.

  • Secure Application

No-Peer (Gazelle Security Suite, TLS Server and Client Simulators)

CA:Aud

The CA:Aud (Canadian Audit Trail) Implementation Guidance specifies the foundational elements needed to perform event logging for auditing purposes. It is based on the ATNA profile and aims to bring improvements via loose coupling, and high cohesion, with focus on auditing using modern formats and technologies.

CA:Aud defines capabilities to record, store and retrieve audit messages in FHIR format using RESTful operations and other (IHE or non-IHE) methods.

The purpose of testing CA:Aud in these test cases is to ensure that the systems exchanging FHIR documents (e.g., Patient Summary) are able to meet the requirements of recording, storing and retrieving audit messages.  

To learn more about CA:Aud, you may watch this short video and review the presentation material here: CA:Aud Profile Information Video (mp4), CA:Aud Profile Information Presentation Deck (PDF)

To read more technical information about CA:Aud, go here.

  • Audit Creator
  • Audit Record Repository (ARR)
  • Audit Record Forwarder
  • Audit Consumer

No-Peer (Tested as part of CA:FeX and MHD)


CT

The Consistent Time Integration Profile (CT) provides a means to ensure that the system clocks and time stamps of the many computers in a network are well synchronized.

The purpose of testing CT in these use cases is to ensure the systems exchanging FHIR documents (e.g., Patient Summary) are synchronized with a median error less than 1 second. This provides systems with the ability to properly manage the information and provides clarity for users on the timeline of when the information was recorded. 

To learn more about CT, you may watch this short video and review the presentation material here: CT Profile Information Video (mp4), CT Profile Information Presentation Deck (PDF)

To read more technical information about CT, go here.

  • Time Client
  • Time Server

No-Peer (Scripts provided within the test cases)

CA:SHL

The pan-Canadian Shareable Health Links (CA:SHL) based on the HL7 Health Links Specification and part of the PMA initiative, defines building blocks enabling patients to generate shareable links that encode their health data such as patient summaries or immunization records. These shareable links can often be downloaded onto their devices and converted in a QR code format, facilitating patient-mediated data sharing and interoperability within the healthcare ecosystem.

Currently, the CA:SHL includes minimal information, as the profile is in the process of being contributed to IHE (Integrating the Healthcare Enterprise) with the aim of becoming an internationally recognized Integration Profile. Until the international integration profile is available, the initial content for CA:SHL is published within the Reference Architecture release. This approach serves as a temporary measure until the final profile is established.

To read more technical information about CA:SHL, go here

  • SHLink Requester
  • SHLink Creator
  • SHLink Consumer
  • SHLink Responder

TBD

...