Developer Guide - Transactions

Context

Transactions as required within the context of AORTA-LSP.

Purpose

This section covers all available transactions as defined by Nictiz.

It details the mapping of those transactions to exchang format specific application layer transactions.

Those application layer transactions are exposed as AORTA-LSP using HL7v3 and/or FHIR interfaces.

This section also refines the application layer requirements by this Healthcare Application.

Scope

Which transactions should I support?

Scope of Kickstart

De scope is conform Verzamelbestand met functionele, technische en infrastructurele documentatie Medicatieproces 9 t.b.v. Kickstart - informatiestandaarden.

Het functioneel ontwerp bevat al meer functionaliteiten dan nu door de Kickstart-leveranciers wordt geïmplementeerd.

Oa. de transactie ‘medicatieoverzicht’ hoeft initieel niet te worden ondersteund; en Patiënten hoeven initieel geen MGB’s beschikbaar te stellen.

Scope for Follower group

Mar 20, 2025 Nictiz

Voor de volgende leveranciers geldt dat zij de implementatie van de Kickstart-leveranciers kunnen volgen. Het verzamelbestand (de kruisjestabellen) is daarbij voor nu leidend en borgt dat dezelfde functionaliteiten worden ingebouwd.

Volgende XIS-leveranciers hebben zicht contractueel gecommitteerd aan de implementatie van MP9 waarbij ze de scope van implementatie door de kickstart aanhouden.
De standaard groter is, en ook de standaarden LAB en CiO horen daar nog bij, maar dat valt buiten de eerste scope/deadline waar ze zich initieel op focussen.

End goals

Echter, het is belangrijk te beseffen dat de uiteindelijke scope van MP9 aanzienlijk groter is.
Het verzamelbestand is dus geen definitieve weergave van wat uiteindelijk geïmplementeerd moet worden. Voor een aantal functionaliteiten zullen aanvullende beproevingen plaatsvinden. Daarnaast is de standaard nog in ontwikkeling en onderhevig aan wijzigingen die doorgevoerd moeten worden.

Houd hier rekening mee in de verdere implementatie.

The Healthcare Application Medicatieoverdracht is very large and covers all use cases for every type of EHR system that participates. The list below indicates which use cases should be supported by each type of system. This allows vendors to drill down to only support the relevant use cases.

The roles and use-cases are summarized by Nictiz and the Program in Verzamelbestand met functionele, technische en infrastructurele documentatie Medicatieproces 9 t.b.v. Kickstart - informatiestandaarden.

Medicatieprocessen contains additional business analysis by VZVZ.

Transactions per system role

Voorschrijver

Stap 3 - Voorschrijven

Stap 4- Verificatie en gebruiken

Stap 5- Verstrekken

Stap 6- Toedienen

Verstrekker

Stap 3 - Voorschrijven

Stap 4- Verificatie en gebruiken

Stap 5- Verstrekken

Stap 6- Toedienen

Toediener

Stap 3 - Voorschrijven

Stap 4- Verificatie en gebruiken

Stap 5- Verstrekken

Stap 6- Toedienen

Patient

Stap 3 - Voorschrijven

Stap 4- Verificatie en gebruiken

Stap 5- Verstrekken

Stap 6- Toedienen

Verzamelbestand VZVZ applicatie interfaces richting AORTA

Hier volgt een uitgebreide toelichting op het Verzamelbestand informatiestandaarden.

Dit uitgebreide verzamelbestand bevat informatie over:

• VZVZ AoF BGx-Systeemrol (platformgeneriek voor FHIR)

• VZVZ AORTA FHIR Systeemrol (specifiek voor zorgtoepassingen binnen FHIR)

• VZVZ AORTA v3 Applicatiesysteemrol (specifiek voor zorgtoepassingen binnen v3)

Deze uitleg biedt ondersteuning bij de implementatie van de vereisten voor elke benodigde rol.

Open

Individual use cases

MP-MGR MP-MGB proxy-facade

AORTA acts as proxy-facade towards the source systems. The calls from a MP-MGR are distributed towards MP-MGB servers and the responses are aggregated as bundled response.

We hanteren een generieke query (in FHIR in de vorm van een $get-aorta-data operation) voor vragende systemen, die door AORTA wordt omgezet naar FHIR searches (minus BSN) naar bronsystemen.

MP-MGR MP-MGB FHIR includes

AORTA ensures that all relevant data is requested in a minimum number of requests. This avoids unnecessary round-trips, and ensures sufficient data retrieval to allow for the BTD to transform data between exchange formats.

These includes result in explicitely broadend FHIR searches with _include and _include:iterate parameters towards MP-MGB.

Patient identifier not part of argument but part of context

Patient identifier is not intended to be mentioned in the query parameters. This would impose a security risk.

Om security redenen nemen wij het BSN niet op in de URL van FHIR searches. Het is onderdeel van het token dat wordt meegestuurd (dat dus niet alleen autorisatiehulpmiddel is maar ook gegevensdrager).

The patient indentifier needs to be communicated via the access-token.

This design-pattern is used for incoming as well as outgoing traffic on AORTA-LSP.

AORTA-LSP does NOT support patient identification with the use of search parameters.

As mentioned in FHIR Implementation Guide Medication Process 9 version 3.0.0-beta.4 - informatiestandaarden

Within AORTA, each transaction is performed in the context of a specific patient, whose context might has been established using the authentication mechanisms. Patient is part of the token exchange.

Het BSN van de betreffende patient is opgenomen in het access_token.

MP-VOS + LAB-LRS

Sturen verzoek tot medicatieverstrekking van medicatie of verwerking van wijziging in medicatieafspraak.

VZVZ implementeert lab Observations als open-world extension boven op nictiz.fhir.nl.r4.medicationprocess9 | mp MedicationPrescription Bundle - SIMPLIFIER.NET.

Security

Wij hebben een security requirement en daarom is het nodig om een access token te verkrijgen dat meegestuurd wordt naar bronsystemen. Dit verandert niets aan de FHIR-search, maar wel de HTTP call.

HTTP-Headers

Daarnaast zijn er nog een aantal HTTP-headers die we gebruiken, zoals Content-Type (formaat FHIR-content), AORTA-ID (tracing/logging van interacties/ketens) en AORTA-Version (versie infrastructuur).

Zoals request-id, initial-request-id, etc.

AoF FHIR Search parameter support for generic query using get-aorta-data

Provenance Resources in FHIR response bundles

Also see Architectuur for the functional description of Provenance.

During pull and push exchange, the AORTA-LSP as exchange system adds FHIR Provenance Resources into the bundles to indicate the source systems.

Logic in AORTA:

Per bundle only one specific Provenance-object is added per source systeem

Per bundle one specific Provenance-object is shared between all resources of the source

In the Provenance object each resource in the searchset bundle is referenced:

• fullUrl, if the fullUrl is a logical id (urn:uuid)

• http://resource.id , if the fullUrl contains an absolute Url

• Is the source returns a OperationOutcome, and it is not a part of the searchset, than a resource object is created with a logical id, which is referenced from the Provenance-Object

During aggregation of the sources, per source, a Provenance object is maintainted and expanded with the new target.reference(s).

After aggregation the Provenance object(en) are added to the consolidated bundle.

The Provenance objects are also included with regular FHIR search responses, not only during the get-aorta-data operation.

The same logic is being reused.

The Provenance contains the AORTA-app-id and URA to identify the source system.

Note: AORTA-LSP currently does not add user-friendly-name displaynames.

This element is NOT filled:

• Profile Element Provenance.contained.Device.deviceName of profile vzvz.fhir.nl-vzvz-core | NLVZVZDevice - SIMPLIFIER.NET

• Bundle Element /Bundle/entry/resource/Provenance/contained/Device[@id='#nl-vzvz-Device-contained']/deviceName/name as in example vzvz.fhir.aof | aorta-provenance-example-bundle - SIMPLIFIER.NET

The current focus is on reliability and efficiency over additional functionality.
The receiving party may use the Zorg-AB to obtain a user-friendly-name displayname.

Sequence diagrams

See DECOR informatie voor project: Medicatieproces (mp-) for Business Layer scenarios

See DECOR informatie voor project: Medicatieproces op LSP (mp-vzvz-) Medicatieproces op het LSP versie 1.5 en is gebaseerd op MP9 3.0.0-beta.4 HTML for Application Layer scenarios

See https://aorta-on-fhir.scrollhelp.site/aorta-on-fhir-specificaties/latest/sequence-diagrammen for AORTA-on-FHIR platform integrations.

See Uitwerking usecases VGU en abonneren en notificeren