Developer Guide - APIs
- Tjerk Drouen
Supported APIs
For the Medication Proces, AORTA-LSP offers a mix of APIs.
The support for the Medication Process is a hybride mix of Medication Information Standaards.
The AORTA-LSP is a hybride mix of Infrastructure-Routes with a legacy as well as a replacing AoF system composition.
The AORTA-LSP APIs offer multiple-exchange-formats.
The Healthcare Application Medicatieoverdracht spans a hybrid situation in which messages can be exchanged in both HL7 v3 and HL7 FHIR. The AORTA infrastructure uses a Transformation Service to transform one type into another so systems only supporting a specific format can still exchange information.
To make this transformation possible without losing valuable information some restrictions to the FHIR implementation are required:
ALWAYS make sure the resource instance has a valid business identifier
do NOT use absolute FHIR references, they cannot be converted to an HL7 v3 reference
ALWAYS add the necessary resources in a bundle, the LSP gateway cannot fetch the additional resources and incomplete bundles (i.e. with referenced resources that are not present in the bundle) can not be transformed.
API support HL7v3/CDA exchange format
API support for FHIR R4
TODO onderstaande tekst moet gecontroleerd worden (klopt alles en hoe is dit uitgewerkt in de PvE’s e.d.) en zo nodig hierboven herschreven/aangevuld worden.
Omschrijving: Hoe kunnen we tussen medicatiebouwstenen refereren in FHIR in een ecosysteem waarin ook geconverteerd moet worden van en naar HL7v3?
In HL7v3 kunnen absolute FHIR referenties niet overgebracht worden en bestaat een referentie uit een business identifier.
Bij het converteren van FHIR naar HL7v3 moet de business identifier dus achterhaald kunnen worden, anders verlies je de relatie.
Het verliezen van de relatie is niet acceptabel in verband met de afleidingsregels.
Op het LSP worden géén REST-calls gedaan om (FHIR-)referenties te kunnen resolven en dus een business identifier te achterhalen bij een absolute of relatieve FHIR URL.
Referenties kunnen ook gaan naar een bouwsteen die ‘van’ iemand anders is (een andere zorgaanbieder).
Bij een LSP-query mogen andermans bouwstenen niet opgeleverd worden. Hoe kan je dan (bij het antwoord op een query) een referentie resolven die in een FHIR bouwsteen een relatieve URL heeft naar je eigen server zonder een extra REST-call te doen naar die FHIR server?
Is het eventueel gewenst om URL’s naar ándere FHIR servers (bij andere zorgaanbieders) in jouw FHIR-bericht op te nemen?
Hoe weet je of een andere zorgaanbieder een échte FHIR-server heeft waar deze URL’s resolvable zijn, of wellicht alleen een façade?
In gesprek met Lauri R en Jelmer vd M kwamen we tot de voorzichtige conclusie dat - zo lang we te maken hebben met conversies van/naar HL7v3 - referenties tussen medicatiebouwstenen ook in FHIR altijd via business identifier zouden moeten gaan. Klopt die conclusie?
src: https://nictiz.atlassian.net/browse/MP-1596
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 XML for HL7 v3 SOAP interactions
See FHIR Implementation Guide Medication Process 9 version 3.0.0-beta.4 - informatiestandaarden for FHIR integration.
V3 messages and packages
Backwards compatibility for MP 6.12 transactions on AORTA 8.4
The 6.12 messages can and will be exchanged via AORTA 8.4. This no longer goes through the AORTA 6 version of the infrastructure.
The PvEs for the AORTA 6 version of the infrastructure are no longer used and have been replaced by the PvEs based on the 8.4 version of the infrastructure.
The old version of MO is also 6.x. That is why these messages are called 6.12 messages. The 6.12 messages can and will be exchanged via AORTA 8.4.
Two parallel paths
Within AORTA-LSP, there are two parallel paths for processing messages: a legacy path and a replacement path.
The legacy path is also known as the ZIM route.
The replacement path is also known as the AoF route.
With the introduction of AoF, a new architecture has started with a new replacement path that will eventually replace the legacy path.
FHIR profiles and packages
Lijst met links naar de relevante FHIR profielen op Simplifier. Zowel de Nictiz profielen als de VZVZ profielen.
Benoem de FHIR packages die nodig zijn voor deze profielen. Indien het belangrijk is dat een specifieke versie van een bepaald package gebruikt wordt, vermeld dat dan.
Het wordt afgeraden om naar een specifieke versie te verwijzen. Doe dat dus alleen als het echt niet anders kan.
The FHIR profiles used in this Healthcare Application can be found on Simplifier.
Project/package | Description |
|---|---|
The profiles and examples related to MO | |
AoF | link naar de scrollhelp pagina met alle AORTA-profielen |
Conform to FHIR R4B - Index - FHIR v4.3.0
Examples
Neem hier een lijst op van embedded links naar voorbeeldberichten, bijv. op Simplifier en/of code voorbeelden in GitHub.
NB. de voorbeeldberichten voor AORTA staan per profiel genoemd op de pagina met AORTA-profielen en die van MO staan in Simplifier, volgens mij zonder overzicht
API specification
API specificaties van de toepassing
beschrijving/visualisatie van de API, volgens industry standard methode → referentie d.m.v. OpenAPI (voorheen Swagger)
Swagger werkt met Viewport
Swagger is compatible met API’s en SOAP’s
AORTA specifications: see all the links combined in the AoF Releases as ‘AoF Release’ with label “AoF.2024.1” (Functionaliteit die nodig is voor de kickstart MO).
The various calls on the various API’s adhere to naming conventions by Nictiz and VZVZ.
These are the naming conventions in Dutch:
Naamgeving Nictiz
Sturend
Ontvangend
Beschikbaarstellend
Raadplegend
Voorstel
AntwoordVoorstel
Naamgeving AoF
ZA Verzendend Systeem
ZA Ontvangend Systeem
Naamgeving AORTA v3
Webservice
Versturen
Opvragen
Transactierollen
xxZ - verzendendsysteem
xxD - ontvangendsysteem
Vxx - voorstel…
Axx - antwoord…
xxO - … opvragend systeem
xxV - …bronsysteem | …opleverend systeem