...
There will be a set of test cases focused on ensuring that the Patient Summary document is structured in the expected format and that it contains the required information using the correct data types and valuesets, where specific valuesets are defined as required in the PS-CA.
Participants will also have ability to validate the national (In addition to testing the PS-CA) and , test cases will validate the harmonized provincial Patient Summary specifications from from Ontario (PS-ON) , British Columbia (and Alberta (PS-AB) which are very closely aligned to the PS-CA:BC), and from New Brunswick (PS-CA:NB) and Alberta British Columbia (PS-AB).
...
CA:BC) which have adopted the PS-CA FHIR profiles. All should be supported by minimal configuration of capability in the vendor systems.
...
The test cases will
...
ensure that the Patient Summary is formatted and contains the required content according to the respective Jurisdiction Implementation Guide (IG), where applicable. Vendors will need to prepare to validate PT data against both PS-CA and the applicable PT Implementation Guide. Refer to the Test Cases for Document Format and Content table below for details about each PT implementation guide.
The test cases will highlight where configuration is needed and test that the configuration is applied properly, based on claimed vendor conformance.
Testing the Document Format and Content
Testing supports for the Patient Summary document format and content validation will be provided using a combination of test cases, test data sets, and tools (see table Test Cases for Document Format and Content below for more information). While test cases reside in Gazelle, they may refer todata sets which will be available on the Test Data Sets page. The data sets will be available in an Excel spreadsheet format and include the following:
- Clinical Data Set for PS-CA: a clinical data set that represents minimum data requirements for PS-CA.
- Clinical Data Set for PS-CA:BC : a clinical data set that represents minimum data requirements for PS-CA:BC.
- Clinical Data Set for PS-CA:NB : a clinical data set that represents minimum data requirements for PS-CA:NB.
- Clinical Data Set for PS-ON : a clinical data set that represents minimum data requirements for PS-ON.
- Clinical Data Set for PS-AB : a clinical data set that represents minimum data requirements for PS-AB.
2. PS-CA Secure, Exchange Transactions
This area of testing will focus on validating the recommended secure exchange methods of the FHIR summary document as presented in the Reference Architecture (RA v0.2.0 DFT-Ballot), referenced by the PS-CA and CA:FeX specifications. Under ideal conditions, depending on the number of participating vendors and their system capabilities, tests will offer a high degree of coverage for all profiles.
There are two categories of integration profiles (see table Test Cases for Secure, Exchange Transactions for more information):
- Core integration profiles: CA:FeX and MHD
- Supporting integration profiles: CA:Sec, CA:Aud (Canadian implementation guidance for ATNA), CT, and IUA
Implementation patterns of these integration profiles may differ from jurisdiction to jurisdiction and information exchange channels may vary in terms of their security footprint. Therefore, the Projectathon test cases have been organized into two categories:
.
2. PS-CA Secure, Exchange Transactions
This area of testing will focus on validating the recommended secure exchange methods of the FHIR summary document as presented in the Reference Architecture (RA v0.2.0 DFT-Ballot), referenced by the PS-CA and CA:FeX specifications. Under ideal conditions, depending on the number of participating vendors and their system capabilities, tests will offer a high degree of coverage for all profiles.
There are two categories of integration profiles (see table Test Cases for Secure, Exchange Transactions for more information):
- Core integration profiles: CA:FeX , MHD and CA:SHL
- Supporting integration profiles: CA:Sec, CA:Aud (Canadian implementation guidance for ATNA), CT, and IUA
Implementation patterns of these integration profiles may differ from jurisdiction to jurisdiction and information exchange channels may vary in terms of their security footprint. Therefore, the Projectathon test cases have been organized into two categories:
- Category 1: Test cases that test individual actor capabilities in isolation. E.g., how a system can handle encrypted transactions, how a system can handle a CA:FeX transaction, how a system can handle an OAuth 2 token exchange, etc.
- Category 2: Complex test cases that group individual actor capabilities with other relevant actor capabilities to simulate real world scenariosCategory 1: Test cases that test individual actor capabilities in isolation. E.g., how a patient summary creator system can handle encrypted transactions, how a system can handle a CA:FeX transaction, how a system can handle submit the document to a repository by using an OAuth 2 token exchangeintegration, etc.
- Category 2: Complex test cases that group individual actor capabilities with other relevant actor capabilities to simulate real world scenarios. E.g., how a patient summary creator system can submit the document to a repository by using an OAuth 2 integration, etc.
Testing the SecureTesting the Secure, Exchange Transactions
Testing supports for the Patient Summary secure, exchange transactions will be provided using a combination of test cases and tools (see Table Test Cases for Secure, Exchange Transactions below for more information).
...
Test Cases for Document Format and Content | |||
By IG | IG Description and Purpose of Test Cases | IHE Profiles Involved | Test Case Peer Type & Supporting Tools* |
PS-CA | The Projectathon 2025 will focus on interoperability demonstrations based on the pan-Canadian Patient Summary (PS-CA v2.0.0 DFT-Ballot) and the associated pan-Canadian FHIR Exchange (CA:FeX v2.1.0 DFT-Ballot) specifications. The PS-CA specification defines the building blocks to create and share patient summaries. The purpose of the test cases for the PS-CA will ensure that the Patient Summary is formatted and contains the required content according to the PS-CA Implementation Guide. A PS-CA clinical data set will be provided to support these test cases. Refer to the Test Data Sets for more details. To read more about the PS-CA, go here. |
| No-Peer (PS-CA Renderer, FHIR Validator, CA:FeX Simulators, and MHD Simulators) Peer-to-Peer (Gazelle platform) |
PS-CA:BC | The PS-CA: BC Patient Summary Project has been endorsed by Canada Health Infoway and BC Provincial Digital Health as a key strategy to support patient information sharing across care settings. PS-CA: BC Implementation Guide leverages foundational artifacts from PS-CA, including BC-specific guidance tailored to provincial healthcare needs. For Release 1, national artifacts are utilized, with the potential to build on PS-CA profiles for BC-specific needs in future releases. Since the PS-CA is based on the IPS, provinces and territories can configure their building blocks to address variances and ensure alignment with the IPS specification. British Columbia has committed to aligning as close as possible with the Patient Summary sharing work with the PS-CA. The BC Patient Summary Project has focused on an initial Release that meets the minimum requirements as outlined by clinicians. BC Providers in community/clinic settings have not historically shared information digitally outside of their settings. As a result, the BC requirements are expected to evolve as clinicians become more comfortable with sharing of information and of the clinician requirements of a Patient Summary. The purpose of the test cases for PS-CA:BC will ensure that the Patient Summary is formatted and contains the required content according to the PS-CA:BC implementation guide. In support of these test cases, the following documents will be provided:
To read more about the PS-CA:BC, go here. |
| No-Peer (PS-CA Renderer, FHIR Validator, CA:FeX Simulators, and MHD Simulators) Peer-to-Peer (Gazelle platform) |
PS-ON | The Ontario Patient Summary is based on the International Patient Summary standard and was developed in collaboration with Canada Health Infoway and other jurisdictions and with preliminary input from primary care clinicians and solution vendors. The Ontario Patient Summary (PS-ON) Standard aligns, where applicable, to the International Patient Summary (IPS) HL7 FHIR standard, the Pan-Canadian Patient Summary (PS-CA) Standard (under concurrent development), and the Canadian Baseline (CA-Baseline). The purpose of the test cases for PS-ON will ensure that the Patient Summary is formatted and contains the required content according to the PS-ON implementation guide. In support of these test cases, the following documents will be provided:
To read more about the PS-ON, go here. |
| No-Peer (PS-CA Renderer, FHIR Validator, CA:FeX Simulators, and MHD Simulators) Peer-to-Peer (Gazelle platform) | PS-CA:NB |
| No-Peer (PS-CA Renderer, FHIR Validator, CA:FeX Simulators, and MHD Simulators) Peer-to-Peer (Gazelle platform) |
PS-AB | Alberta is in the process of developing implementation details to provide to their implementers. Update: The PS-AB will not be tested at the Projectathon 2023. Vendors are being requested to focus on the PS-CA. At such time that the PS-AB is ready, it is expected that minimal configuration of capability in the vendor systems will be needed. To read more about the PS-AB, go here. | Coming soon | Coming soon |
*To learn more about the Supporting Tools, go here.
The following table describes the integration profiles being tested, purpose of each, actors involved and types of tests and supporting tools.
information and of the clinician requirements of a Patient Summary. To read more about the PS-CA:BC, go here. |
| No-Peer (PS-CA Renderer, FHIR Validator, CA:FeX Simulators, and MHD Simulators) Peer-to-Peer (Gazelle platform) | |
PS-ON | The Ontario Patient Summary is based on the International Patient Summary standard and was developed in collaboration with Canada Health Infoway and other jurisdictions and with preliminary input from primary care clinicians and solution vendors. The Ontario Patient Summary (PS-ON) Standard aligns, where applicable, to the International Patient Summary (IPS) HL7 FHIR standard, the Pan-Canadian Patient Summary (PS-CA) Standard (under concurrent development), and the Canadian Baseline (CA-Baseline). To read more about the PS-ON, go here. |
| No-Peer (PS-CA Renderer, FHIR Validator, CA:FeX Simulators, and MHD Simulators) Peer-to-Peer (Gazelle platform) |
PS-CA:NB | The PS-CA:NB implementation has adopted the PS-CA FHIR profiles without creating a separate implementation guide. The initial NB Patient Summary release focuses on requirements outlined by NB clinicians, a subset of data from MyHealth Records, and the Patient Mediated Access use case using the CA:SHL profile. To read more about the PS-CA:NB implementation, go here |
| TBD |
PS-AB | The Alberta Patient Summary (PS-AB) is based on the the Pan-Canadian Patient Summary (PS-CA) Standard, and the Canadian Baseline (CA-Baseline). It was developed in collaboration with Canada Health Infoway and with input from Alberta clinicians and solution vendors. The PS-AB attempts to profile in a way that allows the patient summary instances to be conformant to PS-CA, and CA-Baseline without having to formally derive from the profiles in these specifications. To read more about the PS-AB, go here. |
| No-Peer (PS-CA Renderer, FHIR Validator, CA:FeX Simulators, and MHD Simulators) Peer-to-Peer (Gazelle platform) |
*To learn more about the Supporting Tools, go here.
The 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, involved actors, step-by-step instructions, and any supporting tools required for testing. To explore and execute these test cases, please 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 | ||
Test Cases for Secure, Exchange Transactions
By IHE 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)
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: CA: |
read more technical information about |
CA:FeX, 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
| No-Peer (CA:FeX Client & Server Simulator) Peer-to-Peer (Gazelle platform) | |
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 Presentation Deck (PDF) To read more technical information about |
MHD, go here. |
- Secure Application
| No-Peer (MHD Client & Server Simulator) Peer-to-Peer (Gazelle |
platform) |
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 operationsIUA | 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: |
learn more |
about |
IUA, go here. |
|
No-Peer ( |
CT
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: |
CA:Sec Profile Information Presentation Deck (PDF) To read more technical information about |
CA:Sec, go here. |
- Time Client
- Time Server
No-Peer (Scripts provided within the test cases)
CA:SHL
*To learn more about the Supporting Tools, go here.
Where to Find the Test Cases
All Projectathon 2023 test cases will reside in the Gazelle platform, the primary testing tool where vendors will test and prove that their products align with the published specifications. It is within the Gazelle platform where you will find the details for each test case, including the following information:
- name of the profile(s) and transactions being tested (e.g., CA:FeX, CT, IUA)
- actors involved in the test case
- type of test:
- Peer-to-Peer: tests between systems
- No-Peer: tests between a system and one of the supporting tools (e.g., CA:FeX Client Simulator)
- indicator to identify if the test case is mandatory or optional.
- description of the test case with step-by-step instructions detailing how to run the test case
In addition to the Gazelle platform, a suite of testing tools, including validators and simulators, will be available for the No-Peer tests during the pre-Projectathon testing and Projectathon event testing. For more information about the testing tools, please refer to the Tools and Training page.
When to Run the Test Cases
...
| 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. |
| 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. |
| 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 |
| TBD |
*To learn more about the Supporting Tools, go here.
...