Questionnaire eEKP-FHIR UseCase 2026

Acknowledgement

The given structure of this track is mainly based on HL7 International's Connectathon Patient Track definition.

Short Description

Within the scope of the track, participants are enabled to implement and test both the authorization process and the Questionnaire-based interactions with a test environment. This includes, in particular, the structured capture and exchange of examination data related to birth using the defined FHIR-based artifacts from the eEKP-FHIR project. Furthermore, the end-to-end process and the required technical interactions for obtaining the necessary access prerequisites, i.e. obtaining and exchanging SAML-based Assertions for access tokens, and related authorization artifacts, can be tested and validated as part of the track.

Long Description

The track provides a comprehensive testing scenario that mirrors the core integration principles of the eEKP-FHIR architecture. Participants are not only able to connect to a dedicated test environment, but can also walk through the complete security and access workflow required to access FHIR-based interaction endpoints for eEKP-FHIR. This includes simulating the identity and authorization chain starting with the acquisition of a valid Assertion (SAML), performing the necessary token exchange procedures, and obtaining OAuth2-based access tokens required to invoke the protected FHIR endpoints.

Beyond the security layer, the track focuses on the functional interoperability aspects defined in the eEKP-FHIR specifications. Participants can retrieve and process the officially defined FHIR Questionnaire resources that model the structured documentation of examinations related to pregnancy and birth. These Questionnaires serve as canonical definitions for standardized data capture and are intended to be completed and submitted as FHIR QuestionnaireResponse resources. The scenario enables implementers to test both read and write use cases, ensuring correct implementation of resource structures as defined in eEKP-FHIR.

Type

Experimental use of FHIR interactions, including authorization logic, for eEKP FHIR.

Submitting Work Group/
Project/
Accelerator/
Affiliate/
Implementer Group  

ELGA GmbH

Track Lead(s)

Schuler, Andreas & Anna Lin

Track Lead Email(s)

tc-fhir@hl7.at

Related Tracks

https://hl7at.atlassian.net/wiki/x/AYCKOw (in case the basics are required)

FHIR Version

All related Questionnaires and IHE-Profiles:

  • FHIR R4

Specification(s) this track uses

In course of the eEKP-FHIR Track, we focus on 4 distinct Questionnaire definitions that are intendet to record the examinations related to pregnancy and birth. For reference, you can find the Questionnaire-definitions and a prebuild form rendering via

Artifacts of focus
Date / Time

Monday March 2nd, 09:00am-17:00pm CET

Test Servers

A dedicated test server will be provided as part of the event. Access details and further information will be shared separately.

Expected participants

In general this track is open for all participants. However, the track focusses on the following participants in particular:

  • Software developers and system integrators who develop FHIR-compatible applications or modules for the eEKP FHIR integration,

  • Healthcare service providers who wish to capture or retrieve birth-related data via HL7® FHIR Questionnaires, and

  • Manufacturers of medical software who intend to integrate eEKP-FHIR into existing systems.

Track Details

System Roles

FHIR Client

eEKP FHIR Test System

  • In the course of the event a test instance for eEKP FHIR will be provided composed of

Pre-Requisites (depending on use case)

Example Instances

Access to eEKP FHIR Test System will be provided in the course of the event.

Level 1

Browser-based Questionnaire Interaction

For this level, participants are provided with a preconfigured browser client that already includes all required setup:

  • access tokens and configuration and are handled automatically in the background

  • FHIR Questionnaires are automatically loaded and rendered in the UI

  • completed QuestionnaireResponses can be submitted and edited directly through the interface

The test client is available at the following link: http://eekp.projekte.fh-hagenberg.at/

Participants interact solely through the UI and do not need to perform REST calls or manually work with JSON resources.

Participants will learn:

  • how a FHIR Questionnaire is structured conceptually

  • how Questionnaires are retrieved and rendered by a FHIR client

  • how user input is transformed into a QuestionnaireResponse

  • how structured healthcare data can be collected without manual JSON handling

  • how a typical FHIR workflow works from a client perspective

This level intentionally hides technical complexity in order to focus on concepts:

  • no manual JSON editing

  • no token handling or authentication setup required

  • emphasis on understanding workflow and data structure

This allows participants to concentrate on the functional aspects of questionnaires and their role in healthcare documentation.

Success Criteria

Participants successfully complete Level 1 when they can:

  • open and interact with a provided Questionnaire in the browser

  • complete and submit a QuestionnaireResponse

  • understand the relationship between Questionnaire and QuestionnaireResponse

  • load and view an embedded PDF from a DocumentReference

  • display and edit related Questionnaires associated with a DocumentReference

Step 1: Load a Questionnaire

A Questionnaire definition (the template / empty form) is automatically retrieved from ELGA and rendered by the client. At this stage, the Questionnaire is still empty and no answers have been entered yet.

Participants proceed as follows:

  1. Open the client and navigate to QuestionnaireResponses

  2. A list of the most recently created QuestionnaireResponses is displayed. These existing entries are ignored in Step 1.

  3. Click “Neuer Eintrag” and select one of the four provided Questionnaires.

  4. At this point, the selected Questionnaire is dynamically loaded from ELGA (see https://developer.elga.gv.at/apis/eekp-fhir-anbindung/v0.1.0/reference/questionnaires/#zustand-des-kindes-bei-entlassung-transfer ) and rendered in the UI as an empty form.

  5. Participants can immediately begin filling it out (see Step 2).

Step 2: Fill out answers and explore the dynamic form (enableWhen fields) in the UI and submit the QuestionnaireResponse

Before filling out the form, an identifier for the new QuestionnaireResponse must be entered. This identifier represents the “Untersuchungs ID” and is essential to ensure that the QuestionnaireResponse can later be found and correctly assigned.

Participants should pay attention to how the answer types defined in the Questionnaire are rendered automatically in the UI:

  • free-text input fields

  • predefined selection fields

Additionally, some questions are displayed only when specific answers are selected in preceding questions. These dynamic dependencies are defined in the Questionnaire and rendered automatically by the client.

Participants should then continue by filling out the form.

Validation rules defined in the Questionnaire template must be considered:

  • certain fields enforce specific constraints

  • for example, the Apgar score may only contain values between 0 and 2

  • entering an invalid value causes client-side validation to fail

Some fields are marked as read-only. These fields will later be automatically calculated by the svc application. At the moment, they remain greyed out. For testing purposes, a checkbox allows manual overriding of these fields.

After entering some answers, participants should click the “Expert Mode” button to inspect how the rendered QuestionnaireResponse appears in JSON format.

When clicking “Eintrag speichern”, the client performs validation:

  • if required fields are missing or validation rules fail, the corresponding fields are highlighted

  • saving is prevented until all issues are resolved

The goal of step 2 is to successfully save a new QuestionnaireResponse entry and to remember it’s entered Untersuchungs ID.

Step 3: Load a previously submitted QuestionnaireResponse and edit it

Participants use the previously noted Untersuchungs ID (identifier) from Step 2.

In the QuestionnaireResponses tab, a list of the most recently created QuestionnaireResponses is displayed, independent of their identifier.

To locate the previously created entry:

  1. Open the overview page:
    http://eekp.projekte.fh-hagenberg.at/QuestionnaireResponses

  2. In the search field “Nach Identifier suchen”, enter the previously created Untersuchungs ID.

  3. All QuestionnaireResponses associated with this identifier are displayed in the list, including their metadata.

  4. In the corresponding row, click “Details”.

The selected QuestionnaireResponse is loaded and displayed with all previously entered answers prefilled. Editing the QuestionnaireResponse is now possible and represents the main objective of this step.

After modifying the answers, click “Eintrag speichern” to save the updated QuestionnaireResponse. The client returns to the table overview.

The updated entry should now appear in the list with the same identifier but with an updated timestamp in the “Erstellt am” column.

Step 4: Load a DocumentReference and explore related Questionnaires

In this step, participants switch to the DocumentReference overview:

http://eekp.projekte.fh-hagenberg.at/DocumentReferences

A DocumentReference represents a document summary that is embedded as a PDF and enriched with corresponding metadata. DocumentReferences may also contain links to related QuestionnaireResponses.

Participants proceed as follows:

  1. Open the DocumentReferences overview.

  2. Select an entry that contains an embedded PDF.

  3. Open the entry to display the PDF directly in the browser.

The goal of this step is to understand how document-based information is represented and displayed within the client.

Additionally, participants should identify and open a related QuestionnaireResponse linked to the DocumentReference:

  • related QuestionnaireResponses are displayed as links

  • clicking the link loads the corresponding QuestionnaireResponse

The loaded QuestionnaireResponse can be viewed and edited. However, for testing purposes, changes made to the QuestionnaireResponse are not synchronized back to the PDF.

In the test application, the embedded PDF remains static and does not change based on the QuestionnaireResponse data.

Level 2

API-Level Interactions (OAuth2 + FHIR)

  • Participants shall be able to test the following interactions against a provided test instance of the ELGA Access Control System:

    • Request an Access Token using provided Authentication Statements

    • Renewing the Access Token token using provided Authentication Statements

  • Participants shall be able to test the following interactions and scenarios via the FHIR-SF:

    • Search for eEKP using provided access token

    • Retrieve the complete eEKP using provided access token

    • Store eEKP examinations using provided access token

    • Search for examinations using provided access token

    • Update examinations using provided access token

Security and Privacy considerations

Do not submit personal data (in particular, social insurance numbers and the like). Development and Test clusters require authentication, but are not encrypted and hardened like a production instance would be - use only the provided pseudo certificates.