HL7 AT FHIR Core IG Track 2023
- Acknowledgement
- Short Description
- Long Description
- Type
- Submitting Work Group/ Project/ Accelerator/ Affiliate/ Implementer Group
- Track Lead(s)
- Track Lead Email(s)
- Related Tracks
- FHIR Version
- Specification(s) this track uses
- Artifacts of focus
- Date / Time
- Test Servers
- Expected participants
- Track Details
- Helpful Links
- TestScript(s)
Acknowledgement
The given structure of this track is mainly based on HL7 International's Connectathon Patient Track definition.
Short Description | This track provides new participants with a friendly introduction to the HL7 AT FHIR Core IG, using a simple scenario that can be met with limited domain knowledge and by those who have not had a lot of exposure to FHIR. |
Long Description | This is the HL7 AT FHIR Core IG Track testing that will be included in all future FHIR Hackathons. This track gives participants the opportunity to learn about how HL7 AT FHIR Core IG Resources are constructed, how you can create a FHIR Resource on a FHIR Server, how you can update that FHIR Resource, how you can review the version history for that FHIR Resource, search for that FHIR Resource and delete the FHIR Resource. This tracks is used by both FHIR Clients and FHIR Servers to learn about the basic foundational concepts used by FHIR. No prior experience is necessary, and it can be accomplished with or without the use of development or programming tools. |
Type | Educate on the use of FHIR technology in Austria |
Submitting Work Group/ | HL7 Austria |
Track Lead(s) | |
Track Lead Email(s) | tc-fhir@hl7.at |
Related Tracks | None |
FHIR Version | FHIR R4 |
Specification(s) this track uses | https://fhir.hl7.at/r4-core-main (HL7 FHIR AT Core IG) |
Artifacts of focus | Patient Extension ValueSet |
Date / Time | Monday March 13, 09:00am-15:30pm CET |
Test Servers | See Test Servers |
Expected participants | Level 1:
Level 2:
Level 3 (optional):
|
Track Details | System Roles FHIR Client This actor initiates the processing requests that enable the creation, deletion, manipulation and retrieval of Patient resource instances. The required, supported interactions are the defined basic CRUD operations: create, read, update and delete. Additional required, supported interactions are the operations: vread, history and search. (check if operations are supported by used FHIR server) FHIR Server This actor receives, processes and responds to the requests for creation, deletion, manipulation and retrieval of Patient resource instances. The implementation of this actor would normally provide for a repository storage mechanism along with corresponding maintenance and retrieval capabilities of the Patient resource instances. The required, supported interactions are the defined basic CRUD operations: create, read, update and delete. Additional required, supported interactions are the operations: vread, history and search. (check if operations are supported by used FHIR server) Pre-Requisites For all levels of testing the required pre-requisite is the fundamental requirement that all FHIR servers SHALL support the capabilities interaction. Please note that not all available FHIR servers support the same interactions, operations and/or resources. It might happen that your chosen FHIR server is incompatible with the action you intend to carry out. This includes the supported data format as well, e.g. XML or JSON. Level 1 - Introduction - New Participants/Systems This has been and will remain the main purpose of this track and provides a 'friendly introduction' for those new to FHIR and/or the HL7 AT FHIR Core IG. Attendees participate in this track using a simple scenario that can be met with limited domain knowledge and by those who have not had a lot of exposure to FHIR. It is quite feasible to complete the client side of the track within a day with only knowledge of a development environment and little to no previous FHIR knowledge. If creating a server, advanced preparation will be required, but this scenario should somewhat limit the effort involved. Testing and test reporting at the Hackathon event will be self-attested and primarily involve peer-to-peer execution between known FHIR clients and/or servers. Level 2 - HL7 FHIR AT Core IG (in more detail) This level gives more FHIR-proficient participants an opportunity to familiarize themselves with the content of the HL7 AT FHIR Core IG, particularly the AT Core Patient Profile which uses multiple FHIR extensions as well as CodeSystems and Value Sets. Finally, participants have the opportunity to intract with the FHIR Terminology Server from the Terminology Track as the HL7 AT FHIR Core Patient is a fairly good demonstration of its usage. Testing and test reporting at the Hackathon event will be self-attested an primarily involve peer-to-peer execution between the participating FHIR servers and clients used by participants. Level 3 - Formal Testing - Participants with FHIR experience (optional) This level introduces a more formalized testing approach for those participants that have been working the FHIR and/or the HL7 AT FHIR Core IG specification and wish to move beyond basic testing and may have systems that are in active development, deployed or soon to be deployed into a production environment. Automated testing is significantly leveraged for both automated testing (testing tool to FHIR server) and surveillance of peer-to-peer testing (external FHIR client to external FHIR server). Pre-hackathon testing is highly encouraged in order to be better prepared for the actual Hackathon event and become familiar with the public testing platforms that will be used for the formal testing. Testing and test reporting will be done using the public testing platforms which will provide test results via the new FHIR TestReport resource type as well as any specific reporting capabilities of those testing platforms. These reports will provide qualitative and quantitative analysis of the system under test and its conformance to the FHIR specification and the HL7 AT FHIR Core IG. Attention: Please make sure the FHIR server you utilize for automated testing supports the FHIR TestScript resource type and its processing. Scenarios Level 1 - Introduction - New Participants/Systems The following scenarios represent the basic scenarios that participants will work to implement during the Hackathon event. Execution of these scenarios is expected to be performed with the other participants of this track as well as the Public Test Servers. 1. Register a new patient Action: FHIR client creates a new HL7 FHIR AT Core Patient and saves it to FHIR server. The client can assign the Id. 2. Update a patient Action: FHIR client updates the HL7 FHIR AT Core Patient created in scenario #1 and updates to FHIR server. The patient is retrieved by Id. 3. Retrieve Patient history Action: FHIR client searches the FHIR server for the history of a HL7 FHIR AT Core Patient 4. Search for a patient on name Action: FHIR client searches the FHIR server for HL7 FHIR AT Core Patients with a given name 5. Delete a patient Action: FHIR client deletes the HL7 FHIR AT Core Patient with a given id Level 2 - HL7 AT FHIR Core IG (in more detail)
Action: FHIR client saves the HL7 FHIR AT Core Address Profile to FHIR server. 2. Register the HL7 AT Core Address-additional-information Extension Profile Action: FHIR client saves the HL7 FHIR AT Core Address-additional-information Extension to FHIR server. 3. Register the HL7 AT Core Patient-religion Extension Profile Action: FHIR client saves the HL7 AT Core Patient-religion Extension Profile to FHIR server. 4. Register the HL7 AT Core ISO 3166-1-alpha-3 CodeSystem Action: FHIR client saves the HL7 AT Core ISO 3166-1-alpha-3 CodeSystem to FHIR server. 5. Register the HL7 AT Core ELGA Country Codes Value Set Action: FHIR client saves the HL7 AT Core ELGA Country Codes Value Set to FHIR server. 6. Register the HL7 AT Core Religion CodeSystem Action: FHIR client saves the HL7 AT Core Religion CodeSystem to FHIR server. 7. Register the HL7 AT Core ELGA Religion ValueSet Action: FHIR client saves the HL7 AT Core Religion ValueSet to FHIR server. 8. Register the HL7 AT Core Patient Profile Action: FHIR client saves the HL7 AT Core Patient Profile to FHIR server. 9. Register the HL7 AT Core Patient Example Action: FHIR client saves one HL7 AT Core Patient Example to FHIR server. 10. Validate the HL7 AT Core Patient Example Action: FHIR client validated the HL7 AT Core Patient Example from Step 8 against its declared Profile, registered in Step 8. Formal Testing Level 3 - Formal Testing - Participants with FHIR experience The following scenarios represent the formal testing scenarios that participants have been working to implement both prior to and during the Hackathon event. Execution of these scenarios will focus on automated testing with the public testing platforms and is expected to be performed with the other participants of this track as well as the Public Test Servers. Each of the scenarios are implemented as FHIR TestScript resources that include extensive assertions to provide a more comprehensive validation/verification of the systems under test conformance to the FHIR specification. NOTE 1: All testing scenarios are performed by choosing FHIR TestScript resources that use: (a) XML or JSON NOTE 2: When testing a FHIR server, all of the test scenarios can be completed with a single TestScript--see 99. test scenario below. NOTE 3: When testing a FHIR client, be sure to remember the following: (a) Use the proxy URL of the FHIR server you are sending the request to, not the proxy URL of the FHIR client. The proxy URL assigned to the FHIR client is only used if the FHIR client is also a FHIR server and can accept requests. 1. Patient Registration/Creation FHIR Server Action: Use testing tool to create a new patient on the FHIR server FHIR Client Action: FHIR client creates a new patient and saves it to FHIR server. A testing tool is used as a proxy in order to validate that the transaction is processed correctly. 2. Patient Modification/Update FHIR Server Action: Use testing tool to update an existing patient on the FHIR server with a new birth date FHIR Client Action: FHIR client updates a patient on the FHIR server. A testing tool is used as a proxy in order to validate that the transaction is processed correctly. 3. Patient Read FHIR Server Action: Use testing tool to retrieve a patient from the FHIR server FHIR Client Action: FHIR client retrieves a patient from the FHIR server. A testing tool is used as a proxy in order to validate that the transaction is processed correctly. 4. Patient History FHIR Server Action: Use testing tool to retrieve patient history from the FHIR server FHIR Client Action: FHIR client retrieves the patient history from the FHIR server. A testing tool is used as a proxy in order to validate that the transaction is processed correctly. 5. Patient Version Read FHIR Server Action: Use testing tool to retrieve specific patient versions from the FHIR server FHIR Client Action: FHIR client retrieves a specific patient version from the FHIR server. A testing tool is used as a proxy in order to validate that the transaction is processed correctly. 6. Patient Searching via Multiple Criteria FHIR Server Action: Use testing tool to search for patient on the FHIR server Precondition: TestScript will first delete the patient if it exists and create a new patient resource to search for by identifier, given and family name Success Criteria: Testing tool passes all assertions and validations which include (a) HTTP status returned is 200 (OK), (b) HTTP Header Content-Type is returned with correct value, (c) returned resource type is Bundle, (d) the returned Bundle conforms to the base FHIR Bundle profile, (e) the Bundle type is searchset, and (f) the Bundle total value matches the number of entries. FHIR Client Action: FHIR client searches for the patient on the FHIR server. A testing tool is used as a proxy in order to validate that the transaction is processed correctly. Precondition: Patient exists on FHIR server prior to action Success Criteria: Testing tool passes all assertions and validations which include (a) HTTP method is GET, (b) URL contains search parameters for identifier, family and given, (c) HTTP Header Accept contains the correct value, (d) HTTP Header Content-Type is absent and (e) the HTTP Response from the FHIR server is valid. 7. Patient Deletion/Removal FHIR Server Action: Use testing tool to delete patient on the FHIR server Precondition: TestScript will first delete the patient if it exists and create a new patient resource to be deleted Success Criteria: Testing tool passes all assertions and validations which include (a) HTTP status returned is 204 (No Content), (b) after attempting to read patient an HTTP status 410 (Gone) is returned, and (c) after attempting to search patient an HTTP status 200 (OK) is returned, the HTTP Content-Type is returned with the correct value, returned resource type is Bundle, and the returned Bundle contains no entries. FHIR Client Action: FHIR client deletes a patient from the FHIR server. A testing tool is used as a proxy in order to validate that the transaction is processed correctly. Precondition: Patient exists on FHIR server prior to action Success Criteria: Testing tool passes all assertions and validations which include (a) HTTP method is DELETE, (b) URL contains full URL to Patient resource, (c) HTTP Header Accept contains the correct value, (d) HTTP Header Content-Type is absent and (e) the HTTP Response from the FHIR server is valid. 98. All Non-Versioning Patient Operations Defined Above FHIR Server (use this TestScript to perform all non-versioning test scenarios listed above with a single TestScript execution) Action: Use testing tool to perform all of the test scenarios listed above on the FHIR server which include (1) create a patient, (2) update the patients birth date, (3) retrieve the current patient, (4) search for the patient by identifier, given and family name and (5) delete the patient. 99. All Patient Operations Defined Above FHIR Server (use this TestScript to perform all test scenarios listed above with a single TestScript execution) Action: Use testing tool to perform all of the test scenarios listed above on the FHIR server which include (1) create a patient, (2) update the patients birth date, (3) retrieve the current patient, (4) retrieve the patient history, (5) retrieve each version of the patient, (6) search for the patient by identifier, given and family name and (7) delete the patient. FHIR Client NOTE: FHIR clients must execute the 7 test scenarios one at a time so, there is no TestScript artifact for this test scenario |
Helpful Links | Here are some links to assist implementers:
HAPI FHIR Client skeleton project - https://github.com/FirelyTeam/fhirstarters/tree/master/java/hapi-fhirstarters-client-skeleton/ Firely .NET SDK - https://fire.ly/products/firely-net-sdk/ FHIR Server documentation IBM FHIR Server - https://ibm.github.io/FHIR/announcement/ Black Tusk Health Storage user manual HAPI-FHIR Server - https://hapifhir.io/hapi-fhir/docs/ Firely Server - https://docs.fire.ly/
Most FHIR terminology terminology service endpoints are open (at present). This may change in the future as adoption and implementation experience increases in order to more directly manage external (non-HL7) licensing considerations. Some servers do allow or require authentication. |
TestScript(s) | The supporting TestScripts and corresponding fixtures have been committed to the FHIR documents Github repository at: FHIR R4 (v4.0.0) TestScripts
The AEGIS Touchstone testing tool has test scripts available for tracks to test their implementations. See www.touchstone.com to sign in our register if you are a new user. Patient Tests can be found here: |