Dit is een sjabloon voor de Developer Guide. Alle instructies staan in een Note panel (paars). Voorbeelden worden cursief weergegeven.
De instructies worden in het Nederlands gegeven, maar de uiteindelijke tekst van de Developer Guide is in het Engels. Engels is Amerikaans Engels.
Table of Contents
style
none
Numberedheadings
number-format
decimal
skip-headings
start-numbering-with
1
h1
h2
h3
h4
h5
h6
enabled
true
start-numbering-at
H1
add-anchors
false
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
Version
note
Deze sectie bevat informatie over het document zelf. Zoals versie informatie en een change log
Deze sectie bevat informatie over het document zelf. Zoals versie informatie en een change log
Date
Status
Version
Remarks
Author(s)
1
Draft
0.0.1
First draft
VZVZ
2
Draft
0.0.1
Added essential information on VZVZ deviations from Nictiz specs
Added TODOs
Added reference links
3
v1
4
Changelog
note
Beschrijf globaal in het Engels wat er in deze versie is veranderd t.o.v. de vorige versie.
1.0
Aanpassingen nictiz URLs
Added paragraph 'Dataset constraints are transaction specific'
Added ‘Backwards compatibility for MP 6.12 transactions on AORTA 8.4’
Added 'Two parallel paths'
Changelog
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
Beschrijf globaal in het Engels wat er in deze versie is veranderd t.o.v. de vorige versie.
Hanteer de volgende indeling:
H3 kopje ‘Version’ gevolgd door het versienummer
H4 kopje ‘Fixed’ met daaronder als bullet list voor elke fix het Jira issue nummer dat geleid heeft tot deze fix en daar achter een korte omschrijving van de fix
H4 kopje ‘New’ met daaronder als bullet list voor elke nieuwe toevoeging het Jira issue nummer dat geleid heeft tot deze toevoeging en daar achter een korte omschrijving van de toevoeging
Beschrijf globaal in het Engels wat er in deze versie is veranderd t.o.v. de vorige versie.
Hanteer de volgende indeling:
H3 kopje ‘Version’ gevolgd door het versienummer
H4 kopje ‘Fixed’ met daaronder als bullet list voor elke fix het Jira issue nummer dat geleid heeft tot deze fix en daar achter een korte omschrijving van de fix
H4 kopje ‘New’ met daaronder als bullet list voor elke nieuwe toevoeging het Jira issue nummer dat geleid heeft tot deze toevoeging en daar achter een korte omschrijving van de toevoeging
Version 0.0.1
First draft
Product Overview
Introduction
...
Purpose
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
Korte beschrijving van de scope van dit document.
Korte beschrijving van de scope van dit document.
This
Excerpt
Belangrijke documenten en achtergrond informatie
Document
Document Version
vb: AoF specificaties
2024.1
AORTA
Nictiz FO
Architecture
Context
note
repo = Confluence space nodig waarvandaan wordt gerefereerd.
Voor de diagrammen wordt er gerefereerd vanuit een eerdere uitwerkingen vanuit een repository. Aan de hand van de uitwerkingen in de PvE dienen afspraken gemaakt te worden over de uitwerkingen conform de uitwerkingen in de repo.
Bij de diagrammen ook toelichting bij de platen
repo = Confluence space nodig waarvandaan wordt gerefereerd.
Voor de diagrammen wordt er gerefereerd vanuit een eerdere uitwerkingen vanuit een repository. Aan de hand van de uitwerkingen in de PvE dienen afspraken gemaakt te worden over de uitwerkingen conform de uitwerkingen in de repo.
Bij de diagrammen ook toelichting bij de platen
note
Korte uitleg
Korte uitleg
It should be possible to exchange information regarding medication between healthcare providers and between healthcare providers and consumers.
The Healthcare Application Medicatieoverdracht consists of three parts:
content-related specifications as defined by the Nictiz project team
updates to these specifications as defined by the VZVZ project team to allow the exchange to happen on the AORTA infrastructure
infrastructural specifications as defined by the VZVZ AORTA team to allow conformance to the AORTA infrastructure
This application layer architecture is related to the higher business layer architecture as formulated in Architectuur.
Context diagram
note
Verplicht Plaat met daaronder de beschrijving.
Context diagram (UML/businesslaag van Archimate) → relatie met de buitenwereld moet helder zijn. Relatie met de andere actoren.
Verplicht Plaat met daaronder de beschrijving.
Context diagram (UML/businesslaag van Archimate) → relatie met de buitenwereld moet helder zijn. Relatie met de andere actoren.
162162incomplete Aanvullen met informatie van Architectuur Bedrijfsprocessen MO
Terminologie overgang in AORTA 8
Abonneren Notificeren is de nieuwe naamgeving.
In AORTA v3 architectuur is soms de oude naamgeving nog van kracht. Registreren Abonnement en Signaal bij Gebeurtenis.
Flow chart
note
Verplicht
business niveau
Verplicht
business niveau
163163incompleteAanvullen met informatie van transacties en interfaces en verzamelbestand links
Use cases
This section covers all available use cases as defined by Nictiz and the changes to the specfications as required by this Healthcare Application.
note
Verplicht
korte omschrijving, referentie naar de technische use cases
bij voorkeur embedden, indien niet mogelijk dan extern linken of bijlagen toevoegen (zip). Dit laatste alleen in uiterste nood.
Verplicht
korte omschrijving, referentie naar de technische use cases
bij voorkeur embedden, indien niet mogelijk dan extern linken of bijlagen toevoegen (zip). Dit laatste alleen in uiterste nood.
Which use cases should I support
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.
note
Neem hier de kruisjestabel van Tjerk op of geef een link naar de locatie waar die staat
Neem hier de kruisjestabel van Tjerk op of geef een link naar de locatie waar die staat
164164incompleteAanvullen met informatie van transacties per systeem rol en interfaces en verzamelbestand
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.
Individual use cases
note
Voeg hier algemene afwijkingen toe t.o.v. de Nictiz use cases
Zet hieronder een overzicht van de beschikbare use cases, een link naar de Nictiz versie en eventueel een aanvulling van de afwijkingen die specifiek zijn voor die use case. Verwijs zo nodig naar andere lokaties. Voorkom dubbel opschrijven.
Voeg hier algemene afwijkingen toe t.o.v. de Nictiz use cases
Zet hieronder een overzicht van de beschikbare use cases, een link naar de Nictiz versie en eventueel een aanvulling van de afwijkingen die specifiek zijn voor die use case. Verwijs zo nodig naar andere lokaties. Voorkom dubbel opschrijven.
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.
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.
HTTP argument patient.identifier is NOT supported like
GET [base]/MedicationRequest? patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn%7C111222333
MP-VOS + LAB-LRS
Sturen verzoek tot medicatieverstrekking van medicatie of verwerking van wijziging in medicatieafspraak.
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
Search on the MedicationAgreement, VariableDosingRegimen, AdministrationAgreement and MedicationUse2 building blocks that are related to medication that was used, is used or will be used during the indicated period.
Whenever a search is done on the MedicationAgreement, VariableDosingRegimen or AdministrationAgreement building blocks it is required to also include the latest stopped building blocks of that kind within each pharmaceutical treatment, even if these have a period of use outside the PeriodOfUse that is being searched on.
The client may request that the server returns resources related to the search results, in order to reduce the overall network delay of repeated retrievals of related resources.
Supporting the include of the Patient and Medication resources referenced by building blocks is required. Others (Organization, Location, PractitionerRole, Practitioner, RelatedPerson, Observation) are optional. However: all resources referenced per literal reference SHALL be resolvable per the Nictiz IG.
_include=[type]:patient
_include=[type]:medication
Not Supported via arguments!
Includes arec implicit and automatically added by VZVZ based on agreements with Nictiz.
Sequence diagrams
note
Verplicht
technische niveau
Niet alleen de happy flows, maar ook de unhappy alternatieve flows.
Eventueel links naar de diagrammen → m.n. die van Ron van Holland m.b.t. de diverse workflows
Verplicht
technische niveau
Niet alleen de happy flows, maar ook de unhappy alternatieve flows.
Eventueel links naar de diagrammen → m.n. die van Ron van Holland m.b.t. de diverse workflows
165165incompleteToevoegen scrollhelp links voor Sequence Diagrammen richting AoF en instructies welke flows te implementeren per rol MedMij, FHIR bron/ont.166166incomplete Zie ook abo/not swimlanes in Uitwerking usecases VGU en abonneren en notificeren
Class diagrams
167167incompleteToevoegen databoom-structuren voor BTD verwerking middels includes.168168incompleteToevoegen link naar contextcode definities Zie ook Architectuurnote
UML
embedded vanuit de repository
Opnemen indien relevant
UML
embedded vanuit de repository
Opnemen indien relevant
Voorbeeld:
21009571861499581036231Diagram zonder titel-1726576793084.drawio11https://vzvz.atlassian.net/wikiDiagram zonder titel-1726576793084.drawio0911952
Available APIs
V3 messages and packages
FHIR profiles and packages
note
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.
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.
link naar de scrollhelp pagina met alle AORTA-profielen
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.
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
Examples
The purpose of this document is intended for developers who want to implement the MedicatieOverdracht Healthcare application to support the implementation of the Healthcare Application Medicatieoverdracht on the AORTA-LSP infrastructure
References
Glossary
note
Hier komt een tabel met Nederlandse en Engelse termen met uitleg. Onderstaande tabel kan gebruikt en aangevuld worden met specifieke termen die in deze Developer Guide gebruikt worden.
159159incompleteTODO de termen en de omschrijvingen moeten nog gecontroleerd worden op correctheid.160160incompleteTODO termen en omschrijvingen aanvullen met MO-specifieke termen cq verwijzen naar beschrijvingen van die termen
Hier komt een tabel met Nederlandse en Engelse termen met uitleg. Onderstaande tabel kan gebruikt en aangevuld worden met specifieke termen die in deze Developer Guide gebruikt worden.
TODO de termen en de omschrijvingen moeten nog gecontroleerd worden op correctheid.
TODO termen en omschrijvingen aanvullen met MO-specifieke termen cq verwijzen naar beschrijvingen van die termen
Term (English)
(Dutch)
Definition
Consumer
Burger
Subject of an action regarding the health or wellbeing of the subject. This might be a patient or client but can be broader that that.
(src ChatGPT) Consumer – This term is used in healthcare to refer to someone who engages with healthcare services, products, or information in a more general sense.
Personal Health Record (PHR)
PGO
An application where a person/consumer can request access to his or her own medical information stored in the EHR systems of the healthcare providers.
Vaccination
Vaccinatie
Healthcare Provider
Zorgaanbieder
The organization that provides healthcare to patients or consumers.
Healthcare Provider
Zorgverlener
The person that provides healthcare to patients or consumers. The context should provide the indication whether the English term refers to the organization or the person.
Mitz
Mitz
Dutch centralized patient consent registry.
Transfer record
Overdrachtsdossier
The patient record to be transferred from one healthcare provider to another. This transfer implies transfer of responsibility for the record.
Expiration date
Houdbaarheidsdatum
Healthcare Application
Zorgtoepassing
The implementation, both application and process, that supports healthcare providers in their treatment of patients. TODOControleer de definitie zoals die in de architectuurboard is afgesproken.
Referral
Verwijzing
The act of referring a patient to a different healthcare provider for further treatment.
Requirements (Programma van eisen)
The list of requirements for the healthcare application addressed in this Developer Guide can be found here:
note
verwijzing naar de betreffende PvE → inline link
verwijzing naar de betreffende PvE → inline link
Programma van Eisen Medicatieoverdracht
Use cases (functional use cases)
note
Als de use cases intern binnen VZVZ beschreven zijn (dus Confluence), dan een include, dus embedded binnen de pagina
Bronnen hiervoor kunnen zijn: PSA, Functioneel Ontwerp
Als de use cases extern aangeboden zijn, dan een inline link naar de documentatie
Bron hiervoor kan bijvoorbeeld zijn Nictiz
Boven de link ook een begeleidende tekst waarin duidelijk gemaakt is wat de link betreft, zodat bij een dode link alsnog een aanknopingspunt is.
Vermijd om de use cases hier uit te schrijven, want dat is foutgevoelig. Hanteer een single point of truth.
Als de use cases intern binnen VZVZ beschreven zijn (dus Confluence), dan een include, dus embedded binnen de pagina
Bronnen hiervoor kunnen zijn: PSA, Functioneel Ontwerp
Als de use cases extern aangeboden zijn, dan een inline link naar de documentatie
Bron hiervoor kan bijvoorbeeld zijn Nictiz
Boven de link ook een begeleidende tekst waarin duidelijk gemaakt is wat de link betreft, zodat bij een dode link alsnog een aanknopingspunt is.
Vermijd om de use cases hier uit te schrijven, want dat is foutgevoelig. Hanteer een single point of truth.
The use cases were assembled in cooperation with Nictiz. For the Healthcare Application Medicatieoverdracht the following use cases are relevant and can be found on the Nictiz website or in the PSA which is developed internally.
The purpose of this document is to support developers, product owners and architects in the implementation to of the Healthcare Application Medicatieoverdracht. This document gives a technical overview of the Healthcare Application with references to other documents with further information. It is intended as a landing page that refers to other locations with further information.
This document contains
the system architecture to indicate how this Healthcare Application relates to other products
information on the available APIs
relevant policies and governance that must be adhered to to be able to use this Healthcare Application
information regarding the configuration of the Healthcare Application, such as connection details for the test and acceptance environments
an overview of common and known issues
contact information
Intended audience
The intended audience of this document are developers, product owners and architects of the vendors of EHR and related systems that want to implement connection to the Healthcare Application described in this Developer Guide.
note
Platte tekst, dus geen verwijzing.
Formuleer hier in de template een standaard tekst, omdat de doelgroep voor een dev guide bijna altijd hetzelfde is. Zie voorstel hierboven.
Platte tekst, dus geen verwijzing.
Formuleer hier in de template een standaard tekst, omdat de doelgroep voor een dev guide bijna altijd hetzelfde is. Zie voorstel hierboven.
Related documents
note
Hier een opsomming van relevante documenten, met onderstaande voorkeuren in prio:
Inline externe link
Toevoegen van bijlagen (ZIP, i.v.m. compatibiliteit).
Lijst met links moet een beschrijving bevatten zodat duidelijk is waar de link over gaat.
NB. Afspraak is dat alle links zoals in dit document hier bij elkaar gezet worden en aangevuld worden met andere relevante documenten.
Hier een opsomming van relevante documenten, met onderstaande voorkeuren in prio:
Inline externe link
Toevoegen van bijlagen (ZIP, i.v.m. compatibiliteit).
Lijst met links moet een beschrijving bevatten zodat duidelijk is waar de link over gaat.
NB. Afspraak is dat alle links zoals in dit document hier bij elkaar gezet worden en aangevuld worden met andere relevante documenten.
This section contains a list of all the links from other sections of this document as well as links to other relevant documents.
links to requirements from government or relevant national and European standards
NEN
WEGIZ
Product Documentation Versioning
note
Dit is een verwijzing naar de versie van de documentatie waarnaar verwezen wordt.
Geef alleen de Major-Minor versie van het gerefereerde document
UPDATE 2024-11-12: mogelijk is deze sectie niet van belang.
Dit is een verwijzing naar de versie van de documentatie waarnaar verwezen wordt.
Geef alleen de Major-Minor versie van het gerefereerde document
UPDATE 2024-11-12: mogelijk is deze sectie niet van belang.
161161incomplete Aanvullen met informatie uit Doel
.
Scope
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
Platte tekst, dus geen verwijzing.
Platte tekst, dus geen verwijzing.
This document gives a technical overview of the Healthcare Application with references to other documents with further information. It is intended as a landing page that refers to other locations with further information.
This document contains
the system architecture to indicate how this Healthcare Application relates to other products
information on the available APIs
relevant policies and governance that must be adhered to to be able to use this Healthcare Application
information regarding the configuration of the Healthcare Application, such as connection details for the test and acceptance environments
an overview of common and known issues
contact information
Intended audience
This document is intended for developers, product owners and architects of XIS-system development and integration.
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
Platte tekst, dus geen verwijzing.
Formuleer hier in de template een standaard tekst, omdat de doelgroep voor een dev guide bijna altijd hetzelfde is. Zie voorstel hierboven.
Platte tekst, dus geen verwijzing.
Formuleer hier in de template een standaard tekst, omdat de doelgroep voor een dev guide bijna altijd hetzelfde is. Zie voorstel hierboven.
References
Glossary
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
Hier komt een tabel met Nederlandse en Engelse termen met uitleg. Onderstaande tabel kan gebruikt en aangevuld worden met specifieke termen die in deze Developer Guide gebruikt worden.
371371incompleteTODO de termen en de omschrijvingen moeten nog gecontroleerd worden op correctheid.372372incompleteTODO termen en omschrijvingen aanvullen met MO-specifieke termen cq verwijzen naar beschrijvingen van die termen
Hier komt een tabel met Nederlandse en Engelse termen met uitleg. Onderstaande tabel kan gebruikt en aangevuld worden met specifieke termen die in deze Developer Guide gebruikt worden.
TODO de termen en de omschrijvingen moeten nog gecontroleerd worden op correctheid.
TODO termen en omschrijvingen aanvullen met MO-specifieke termen cq verwijzen naar beschrijvingen van die termen
Glossary
Term (English)
(Dutch)
Definition
Medication agreement
Medicatieafspraak
'Medicatieafspraak / Medication agreement/ is the prescriber’s proposal for medication use with which the patient agrees. An agreement to discontinue medication is also an MA.
Variable dosing regimen
Wisselend doseerschema
'Wisselend doseerschema / Variable dosing regimen' contains the dosing instruction as composed by an (external) prescriber. In the WDS the element 'instructions for use' from the MA is further specified. The WDS can be modified without changing the MA.
Dispense request
Verstrekkingsverzoek
'Verstrekkingsverzoek / Dispense request' is the request from a prescriber to a pharmacist to supply the patient with one or more medicinal products in support of the current MA(s)
Administration agreement
Toedieningsafspraak
'Toedieningsafspraak / Administration agreement' contains the instructions for medication use (or administration) from the pharmacist to the patient (or his representative or administrator), adding to the MA.
Medication dispense
Medicatieverstrekking
'Medicatieverstrekking / Medication dispense' is the provision of a supply of medicinal product to the patient or his administrator or representative.
Medication administration
Medicatietoediening
'Medicatietoediening / Medication administration' is the registration of individual administrations of the medicinal product to the patient by the person who administers them (such as a nurse or the patient himself) in relation to the agreements made.
Medication use
Medicatiegebruik
'Medicatiegebruik / Medication use' is a statement about historical, current or intended use of a medicinal product.
Proposal medication agreement
Voorstel medicatieafspraak
'Voorstel medicatieafspraak / Proposal medication agreement' is a recommendation or request from the pharmacist, prescriber or the administrator to the prescriber of the MA about the medication agreed upon. The recommendation request may include evaluating, discontinuing, starting or modifying medication.
Reply proposal medication agreement
Antwoord voorstel medicatieafspraak
'Antwoord voorstel medicatieafspraak / Reply proposal medication agreement' is a reply from the prescriber to the VMA.
Proposal dispense request
Voorstel verstrekkingsverzoek
'Voorstel verstrekkingsverzoek / Proposal dispense request' is a proposal from the pharmacist to the prescriber to approve one or more MVE(s) in support of the current MA(s). This is comparable with the current situation of submitting the authorisation form or combined prescription or submitting a repeat prescription for signing. The patient may also submit a VVV to the prescriber.
Reply proposal dispense request
Antwoord voorstel verstrekkingsverzoek
'Antwoord voorstel verstrekkingsverzoek / Reply proposal dispense request' is a reply from the prescriber to the VVV.
Clinical Information Model (CIM)
zorginformatiebouwsteen (ZIB)
See Clinical Building Block (CBB)
Clinical Building Block (CBB)
zorginformatiebouwsteen (ZIB)
Related data elements are grouped together in a Clinical Information Model (CIM)
Therapeutic and logistical building blocks
Therapeutische en logistieke bouwstenen
The model is designed in such a way that therapeutic building blocks and logistical building blocks are separated from each other.
Pharmaceutical treatment
Medicamenteuze behandeling
'Pharmaceutical treatment' is a technical concept in the information standard. Its purpose is:
To unambiguously identify the set of interdependent medication building blocks, and
To apply rules to it to unambiguously determine the present situation.
Product Overview
Requirements (Programma van eisen)
The list of requirements for the healthcare application addressed in this Developer Guide can be found here:
Als de use cases intern binnen VZVZ beschreven zijn (dus Confluence), dan een include, dus embedded binnen de pagina
Bronnen hiervoor kunnen zijn: PSA, Functioneel Ontwerp
Als de use cases extern aangeboden zijn, dan een inline link naar de documentatie
Bron hiervoor kan bijvoorbeeld zijn Nictiz
Boven de link ook een begeleidende tekst waarin duidelijk gemaakt is wat de link betreft, zodat bij een dode link alsnog een aanknopingspunt is.
Vermijd om de use cases hier uit te schrijven, want dat is foutgevoelig. Hanteer een single point of truth.
Als de use cases intern binnen VZVZ beschreven zijn (dus Confluence), dan een include, dus embedded binnen de pagina
Bronnen hiervoor kunnen zijn: PSA, Functioneel Ontwerp
Als de use cases extern aangeboden zijn, dan een inline link naar de documentatie
Bron hiervoor kan bijvoorbeeld zijn Nictiz
Boven de link ook een begeleidende tekst waarin duidelijk gemaakt is wat de link betreft, zodat bij een dode link alsnog een aanknopingspunt is.
Vermijd om de use cases hier uit te schrijven, want dat is foutgevoelig. Hanteer een single point of truth.
The use cases were refined in cooperation with Nictiz. For the Healthcare Application Medicatieoverdracht the following use cases are relevant and can be found on the Nictiz website or in the PSA which is developed internally.
repo = Confluence space nodig waarvandaan wordt gerefereerd.
Voor de diagrammen wordt er gerefereerd vanuit een eerdere uitwerkingen vanuit een repository. Aan de hand van de uitwerkingen in de PvE dienen afspraken gemaakt te worden over de uitwerkingen conform de uitwerkingen in de repo.
Bij de diagrammen ook toelichting bij de platen
repo = Confluence space nodig waarvandaan wordt gerefereerd.
Voor de diagrammen wordt er gerefereerd vanuit een eerdere uitwerkingen vanuit een repository. Aan de hand van de uitwerkingen in de PvE dienen afspraken gemaakt te worden over de uitwerkingen conform de uitwerkingen in de repo.
Bij de diagrammen ook toelichting bij de platen
note
Korte uitleg
Korte uitleg
Vision:
The Medication Transfer program works on good, complete electronic transfer of medication data. For an up-to-date and complete medication overview for every healthcare provider and every patient. A basic set of medication data has been agreed in the Guideline for Transfer of Medication Data in the Chain. These basic data must be available to every healthcare provider who prescribes, provides or administers. Three information standards enable the registration and exchange of this basic set. These are the information standards Medication Process, Lab values for medication and CiO (Contraindications and hypersensitivities). The healthcare-wide implementation of the guideline and the associated information standards takes place within the Medication Transfer program. New agreements and procedures make network and chain care possible; the information standards included in software packages make digital data exchange possible.
Objectives:
The Medication process program aims first to take away existing obstacles in the medication process, while taking into account current legislation and the possibility of obtaining tangible results in the foreseeable future.
Architecture:
The Healthcare Application Medicatieoverdracht consists of various parts:
business layer architecture by Nictiz
Information standards
functional requirements
information models
application layer architecture by VZVZ
application requirements
information models for data exchange on AORTA-LSP infrastructure
infrastructure integration specifications with centralized application services
This application layer architecture is related to the higher business layer architecture as formulated in Architectuur.
Terminology:
Note
AORTA 8 - Subscribe and notify
The terms; subscribe and notify need to be used instead of the legacy terms; signal, event and register.
In the AORTA v3 architecture the legacy terms are still present.
Context diagram
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
Verplicht Plaat met daaronder de beschrijving.
Context diagram (UML/businesslaag van Archimate) → relatie met de buitenwereld moet helder zijn. Relatie met de andere actoren.
Verplicht Plaat met daaronder de beschrijving.
Context diagram (UML/businesslaag van Archimate) → relatie met de buitenwereld moet helder zijn. Relatie met de andere actoren.
This architecture is performed within a larger framework. See Nictiz page on Interoperabiliteit. This application mainly addresses Application and IT-infrastructure.
Flow chart
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
Verplicht
business niveau
Verplicht
business niveau
Algemene workflow uitwisseling
Onderstaande stappen zullen altijd uitgevoerd worden, ongeacht de inhoudelijke berichten. Voor het overzicht wordt de algemene workflow hier beschreven en wordt bij de inhoudelijke workflows alleen de stappen en berichten genoemd die aanvullend zijn op deze algemene workflow.
Opvragen medicatiegegevens
Workflow
vrager stelt generieke query / $get-aorta-data
LSP splitst in losse bouwsteen queries
zo nodig transformatie
antwoorden zo nodig getransformeerd
(getransformeerde) antwoorden worden gebundeld aangeleverd aan vrager
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
373373incompletelink naar of excerpt include waar dit beter beschreven staat
Interacties
lijst met interacties die bevraagd kunnen worden/ ontvangen kunnen worden
Berichten
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
374374incompletelinks naar simplifier375375incompleteberichten376376incompletevoorbeelden (search query in simplifier)377377incompletelinks naar info bij MO
Sturen en afhandelen medicatievoorschrift
Workflow
bron stuurt voorschrift-bericht naar ontvanger
ontvanger stuurt ontvangstbevestiging terug
ontvanger stuurt afhandeling-voorschrift-bericht naar bron
bron stuurt ontvangstbevestiging terug
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
378378incompletelink naar of excerpt include waar dit beter beschreven staat
bron stuurt medicatiegegevens-bericht naar ontvanger
ontvanger stuurt ontvangstbevestiging terug
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
380380incompletelink naar of excerpt include waar dit beter beschreven staat
Berichten
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
381381incompletelinks naar simplifier382382incompleteberichten383383incompletevoorbeelden (search query in simplifier)384384incompletelinks naar info bij MO
Use cases
This section covers all available use cases as defined by Nictiz and the changes to the specfications as required by this Healthcare Application.
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
Verplicht
korte omschrijving, referentie naar de technische use cases
bij voorkeur embedden, indien niet mogelijk dan extern linken of bijlagen toevoegen (zip). Dit laatste alleen in uiterste nood.
Verplicht
korte omschrijving, referentie naar de technische use cases
bij voorkeur embedden, indien niet mogelijk dan extern linken of bijlagen toevoegen (zip). Dit laatste alleen in uiterste nood.
Which use cases should I support
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 dataset needs to adhere to the constraints set by the transaction
Per transaction in the data model in ART DECOR, in the Condition column, refinements are found on attributes. The implementation needs to adhere to these. These refinements are often the same for all transactions, but sometimes they differ per transaction. For example, when sending a prescription, there are some fields that are not needed in the prescription and therefore we do not expect them in the prescription. However, when you request and provide medication data, those fields would be included. There are small discrepancies between what is transmitted in one transaction and another.
The advice is to build the building blocks in such a way that you can hide or include attributes in that building block depending on the interaction. This is also future-proof if you need to move to a newer version of FHIR or other transport protocols.
As implementor, the differences will become apparent, when you Compare transactions side by side. On big difference is between prescription and medication agreement.
The phone number is mandatory when sending a prescription, but it must not be included when making a medication agreement available (important - we also qualify on this).
The VV relationship to MA (1-) on (0-) depends on the migration.
Voeg hier algemene afwijkingen toe t.o.v. de Nictiz use cases
Zet hieronder een overzicht van de beschikbare use cases, een link naar de Nictiz versie en eventueel een aanvulling van de afwijkingen die specifiek zijn voor die use case. Verwijs zo nodig naar andere lokaties. Voorkom dubbel opschrijven.
Voeg hier algemene afwijkingen toe t.o.v. de Nictiz use cases
Zet hieronder een overzicht van de beschikbare use cases, een link naar de Nictiz versie en eventueel een aanvulling van de afwijkingen die specifiek zijn voor die use case. Verwijs zo nodig naar andere lokaties. Voorkom dubbel opschrijven.
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.
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.
Info
HTTP argument patient.identifier is NOT supported like
GET [base]/MedicationRequest? patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn%7C111222333
MP-VOS + LAB-LRS
Sturen verzoek tot medicatieverstrekking van medicatie of verwerking van wijziging in medicatieafspraak.
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
MP9 search parameter
Description
FHIR search parameter
Nictiz
VZVA (AoF)
PatientIdentificationNumber
Search on patient.
patient.identifier
subject:Patient.identifier
NOT supported on argument line
is part of context
Identification
Search on identifier.
identifier
Code Block
GET [base]/MedicationRequest?identifier=http://example.nl/fhir/NamingSystem/MedicationRequest|999922448
Supported via
GET [base] $get-aorta-data ?[context] {&[destination]} {&[effective-time]} {&[therapy-identifier]} {&[classifier]} {&[instance-identifier]
Retrieves all MedicationRequest resources that represent the building block MedicationAgreement.
Code Block
GET [base]/MedicationRequest?category=http://snomed.info/sct|33633005
Retrieves all MedicationRequest resources that represent the building block DispenseRequest.
Code Block
GET [base]/MedicationRequest?category=http://snomed.info/sct|52711000146108
Retrieves all MedicationRequest resources that represent the building block VariableDosingRegimen.
Code Block
GET [base]/MedicationRequest?category=http://snomed.info/sct|395067002
Supported via
GET [base] $get-aorta-data ?[context] {&[destination]} {&[effective-time]} {&[therapy-identifier]} {&[classifier]} {&[instance-identifier]
as
&category=http://snomed.info/sct|<category>
Retrieves all MedicationDispense resources that represent the building block MedicationDispense.
Code Block
GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005
Retrieves all MedicationDispense resources that represent the building block AdministrationAgreement.
Code Block
GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009
Supported
Retrieves all MedicationStatement resources that represent the building block MedicationUse2.
Code Block
GET [base]/MedicationStatement?category=http://snomed.info/sct|422979000
Supported
Retrieves all MedicationAdministration resources that represent the building block MedicationAdministration2.
Code Block
GET [base]/MedicationAdministration?category=http://snomed.info/sct|18629005
Supported
MedicationCode
Search on medication code.
medication.code
NOT SUPPORTED?
PeriodOfUse
Search on the MedicationAgreement, VariableDosingRegimen, AdministrationAgreement and MedicationUse2 building blocks that are related to medication that was used, is used or will be used during the indicated period.
Whenever a search is done on the MedicationAgreement, VariableDosingRegimen or AdministrationAgreement building blocks it is required to also include the latest stopped building blocks of that kind within each pharmaceutical treatment, even if these have a period of use outside the PeriodOfUse that is being searched on.
period-of-use
Supported via effective-time as GebruiksPeriode
GET [base] $get-aorta-data ?[context] {&[destination]} {&[effective-time]} {&[therapy-identifier]} {&[classifier]} {&[instance-identifier]
The client may request that the server returns resources related to the search results, in order to reduce the overall network delay of repeated retrievals of related resources.
Supporting the include of the Patient and Medication resources referenced by building blocks is required. Others (Organization, Location, PractitionerRole, Practitioner, RelatedPerson, Observation) are optional. However: all resources referenced per literal reference SHALL be resolvable per the Nictiz IG.
_include=[type]:patient
_include=[type]:medication
Not Supported via arguments!
Includes are implicit and automatically added by VZVZ based on agreements with Nictiz.
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)
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.
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
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
Verplicht
technische niveau
Niet alleen de happy flows, maar ook de unhappy alternatieve flows.
Eventueel links naar de diagrammen → m.n. die van Ron van Holland m.b.t. de diverse workflows
Verplicht
technische niveau
Niet alleen de happy flows, maar ook de unhappy alternatieve flows.
Eventueel links naar de diagrammen → m.n. die van Ron van Holland m.b.t. de diverse workflows
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.
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
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
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
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.
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.
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
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 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
de pagina met AORTA-profielen en die van MO staan in Simplifier, volgens mij zonder overzicht
API specification
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
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
API specificaties van de toepassing
beschrijving/visualisatie van de API, volgens industry standard methode → referentie d.m.v. OpenAPI (voorheen Swagger)
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:
Info
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
Security
xxD - ontvangendsysteem
Vxx - voorstel…
Axx - antwoord…
xxO - … opvragend systeem
xxV - …bronsysteem | …opleverend systeem
Security
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
voor de onderstaande onderdelen een acceptable means of compliance beschrijven.
Verwijs naar de tokens, VGU, etc.
voor de onderstaande onderdelen een acceptable means of compliance beschrijven.
Verwijs naar de tokens, VGU, etc.
Identification and Authorization Management
acceptable means of compliance beschrijven.
Verwijs naar de tokens, VGU, etc.
Identification and Authorization Management
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
ref naar IAM eisen in PvE, embedded
verklaring op de eisen en een howto--> uitvragen: op welke manier wil een developer dit
ref naar IAM eisen in PvE, embedded
verklaring op de eisen en een howto--> uitvragen: op welke manier wil een developer dit
Voeg hier ook informatie m.b.t. de validatietools toe. Zie ook https://vzvz.atlassian.net/browse/MEDVEILIG-177af1aa7de-fede-31f8-ae91-0deac6bac210System Jiravoor links
Benodigde configurations, waarbij elke bullet point bij voorkeur embedded wordt opgenomen:
Aansluiten op testomgevingen (referentie aansluitformulier)
MEDVEILIG-177 - Issue details worden opgehaald...STATUS voor links
Common Issues/Known Issues
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
Known issues is een overzicht waarin de issues zijn opgenomen van veel voorkomende problemen in de praktijk, met daarbij een advies hoe hier mee om te gaan.
Externe inline link naar common- / known issues (bijvoorbeeld in supportal)
Known issues is een overzicht waarin de issues zijn opgenomen van veel voorkomende problemen in de praktijk, met daarbij een advies hoe hier mee om te gaan.
Externe inline link naar common- / known issues (bijvoorbeeld in supportal)
Contact information
.
Externe inline link naar common- / known issues (bijvoorbeeld in supportal)
Contact information
Scroll ignore
scroll-viewport
true
scroll-pdf
true
scroll-office
true
scroll-chm
true
scroll-html
true
scroll-docbook
true
scroll-eclipsehelp
true
scroll-epub
true
note
Contactgegevens
Single point of contact (bijvoorbeeld: Product Manager), die verwijst bijvoorbeeld door naar:
Vul hier een link in naar bijv. een service desk of een andere manier om in contact te komen met iemand die geraadpleegd kan worden.
Vermijd namen, email adressen en telefoonnummers omdat een Developer Guide publiekelijk beschikbaar komt op het internet. Voeg alleen links toe naar een omgeving waarop eerst ingelogd moet worden voordat de vragen gesteld kunnen worden. Anders kun je wachten op spam-registraties.
Update 2024-11-12: er is nog geen generieke servicedesk applicatie beschikbaar, dus we ontkomen niet aan email adressen. Misschien moet er dan besloten worden dat alle vragen via het testteam gaan en dat zij ze intern routeren naar de juiste persoon.
Vul hier een link in naar bijv. een service desk of een andere manier om in contact te komen met iemand die geraadpleegd kan worden.
Vermijd namen, email adressen en telefoonnummers omdat een Developer Guide publiekelijk beschikbaar komt op het internet. Voeg alleen links toe naar een omgeving waarop eerst ingelogd moet worden voordat de vragen gesteld kunnen worden. Anders kun je wachten op spam-registraties.
Update 2024-11-12: er is nog geen generieke servicedesk applicatie beschikbaar, dus we ontkomen niet aan email adressen. Misschien moet er dan besloten worden dat alle vragen via het testteam gaan en dat zij ze intern routeren naar de juiste persoon.
