Long Description | The Austrian Patient Summary (APS) is based on the specifications of the International Patient Summary (IPS) as well as the HL7AT FHIR Core IG. Definitions of the (I)PS: “The International Patient Summary is a minimal and non-exhaustive set of basic clinical data of a patient, specialty-agnostic, condition-independent, but readily usable by all clinicians for the unscheduled (cross-border) patient care.”
“Although this dataset is intended to aid health professionals in providing unscheduled care, it can also be used to provide planned medical care (e.g. in the case of citizens movements or cross-organizational care paths).”
(eHealth Network Guideline on Patient Summary (Nov 2024))
The APS aligns with the needs of the Austrian healthcare environment by making use of the Austrian FHIR core profiles (e.g. patient, practitioner, etc.) and by the use of value sets already established in the Austrian e-health community where possible. Furthermore, by taking into consideration the definition of the eHealth Network the APS shall also be used as part of disease management programs. For this reason, two additional IGs have been created - one covering diabetes and one covering heart insufficiency. The aim of these IGs is to further refine the value sets to be used in a specific context. In addition they contain examples which are in line with the clinical care paths and as such present how APS instances may reflect different stages within a disease management program. The aim of this track is to discuss and review the specification of the APS to create, exchange, and edit (new) examples of APS instances to visualize APS instances to validate APS instances to track down problems which might arise in any of the points above and find solutions for them which may improve the specification of the APS or the tools which have been used.
|
Track Details | System Roles FHIR Client create, update patient summary instances validate against specification display patient summaries using VIDi
FHIR Server Pre-Requisites (depending on use case) IG generation (and validation) Stand-alone Validation Visualisation REST-Client (Postman, Insomnia, and/or Bruno)
For all levels of testing the fundamental requirement is 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. Check the documentation of each FHIR server beforehand to verify its compatibility. Preparations This Track provides a  containing a set of REST requests which may help you to fulfill the tasks at hand and which shall also enable you to take a deep dive into the realm of patient summaries. Depending of the FHIR server being used (see Test Servers) for interactions it might be necessary to provide required terminologies and profiles upfront  Furthermore, the Postman collection of the HL7 AT FHIR Core IG Track may provide you with basic REST-requests regarding the creation of e.g. patient resources.
Example Instances The provided Postman collection contains several APS instances. Additional sample instances can be found within the related FHIR IGs. Note, that all the instances may still contain errors. Level 1 (a) Get to know the specification of the IPS and the APS (b) Create a first example Action: FHIR client creates a new APS instance and saves it to FHIR server. The client can assign the Id. Precondition: APS instance does not exist in FHIR server prior to action Success Criteria: APS instance created correctly on FHIR server (use browser or Postman to inspect Patient)
>>Note: the resource Id can either be created by the client or the server (depending on the capability of the server). However, if the server assigns the Id, then the client will need to be able to retrieve the Id from the server response or by a patient query. Bonus points: Try to add an Immunization or a Condition to one of the examples and upload it to the server. REST requests: 01 Level/CREATE APS Bundle (no problems, medication, etc.)
01 Level/CREATE APS Bundle (problems)
(b) Visualize APS using VIDi Action: Take VIDi and fire up a local web server within that directory (e.g. python -m http.server 8000). Browse to localhost:8000. Precondition: Have a local copy of VIDi and a locally running webserver available (e.g. Python). Success Criteria: Display APS in a browser. Bonus points:
Level 2 (a) When the APS is of type “transaction” Action: FHIR client creates a new APS instance of type “transaction” (see FHIR transactions) and saves it to FHIR server. Precondition: None Success Criteria: The resources within the provided Bundle have been successfully created. Bonus Points: Take one of the APS instances from 01 Level and transform them into Bundles of type “transaction” REST requests:
(b) Use the $summary operation to regain an patient summary Action: Create a patient summary by invoking the $summary operation. Precondition: The required information (see 02 Level/CREATE APS Bundle (transaction)) has been successfully loaded onto the server. The server has to support the $summary operation. Success Criteria: The server creates a patient summary. Bonus Points: REST requests:
(c) Walk through the patient journey of a DMP Action: Based on the IV Diabetes | Patient Journey incrementally update the clinical information regarding the related patient. Precondition: No information about the patient is present on the FHIR server. Create a reference between the CarePlan and the Adipositas-Condition (CarePlan.addresses). After each step create a patient summary instance using the $summary operation. Create another bundle representing another doctor’s visit. Validate the created patient summary.
REST requests: 02 Level/Patient Journey - initial state = APS instance
02 Level/Patient Journey - first visit = Bundle containing additional information
Necessary adaptions: set the correct ID of the Patient created in 02 Level/Patient Journey - initial state, e.g. Patient/123 set the correct ID of the Pratitioner created in 02 Level/Patient Journey - initial state, e.g. Practitioner/123
02 Level/Patient Journey - review of findings = Bundle containing additional information
Necessary adaptions: set the correct ID of the Patient created in 02 Level/Patient Journey - initial state, e.g. Patient/123 entry[1].resource.subject.reference - MedicationStatement
entry[2].resource.subject.reference - Condition
entry[3].resource.subject.reference - Observation
entry[4].resource.subject.reference - Observation
entry[5].resource.subject.reference - CarePlan
entry[5].resource.activity[0].detail.performer.reference - CarePlan
set the correct ID of the Practitioner created in 02 Level/Patient Journey - initial state, e.g. Practitioner/123 set the correct ID of the Condition created in 02 Level/Patient Journey - first visit, e.g. Condition/123
Patient Journey - follow-up = Bundle containing additional information
Necessary adaptions: set the correct ID of the Patient created in 02 Level/Patient Journey - initial state, e.g. Patient/123 set the correct ID of the Practitioner created in 02 Level/Patient Journey - initial state, e.g. Practitioner/123 set the correct ID of the MedicationStatement created in 02 Level/Patient Journey - review of findings, e.g. MedicationStatement/123
Level 3 (a) Validate APS instances using different tools Action: Validate APS instances against the specification of the APS using different tools. Precondition: Depending on the validation tool you want to use make sure that you have set up your system. Success Criteria: Validation of APS instance succeeds. Bonus Points: REST requests:
(b) Modify mapping used for VIDi Action: Modify/enhance the mapping used to transform an APS instance to VIDi conformant json files. Precondition: Checkout MaLaC-HD | VIDi-maps. The maps for VIDi are located in tests\fml\r5\vidi-map\IpsToVidi.5.map. After setting up MaLaC-HD to convert the maps into Python the resulting Python code can be used to transform APS instances. Success Criteria: Create VIDi conformant json files and display APS instances. Bonus Points: Find a way to deal with different data types of Observation.value. Find a way to deal with extensions (e.g. dataAbsentReason → _timingDateTime in JSON, etc).
Level 4 We are happy to follow any topic requiring a deep dive into technical/semantic/organisational/etc. discussion regarding the patient summary. |
Helpful Links | Converting between FSH/FHIR https://fhirpath-lab.com/FhirPath (Testing of FHIR-Path expression) Postman (Import & Execute Postman-collection) Insomnia (Import & Execute Postman-collection) Bruno (Importieren & Ausführen der Collection, Open Source & ohne Anmeldung) Postman collection
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. |
