(v3) Wijzigingshistorie
Versie | Datum | Omschrijving |
8.3.0.0 | 01-09-2022 | AORTA-infrastructuurdocumentatie v8.3.0.0 |
Achtergrond
VZVZ richt zich op de totstandkoming van een betere informatievoorziening rondom en voor de patiënt/cliënt met behulp van ICT. Het uiteindelijke doel is het bereiken van een hogere doelmatigheid en kwaliteit van ICT in de zorg.Ter ondersteuning van dit doel is een samenhangende set van documentatie ontwikkeld, de zogenoemde AORTA-documentatierelease. De wijzigingshistorie ondersteunt de lezers met een beknopt overzicht van alle wijzigingen in de 'nieuwe' AORTA-documentatierelease ten opzichte van de vorige totaalrelease inclusief patches en errata.
Reikwijdte
De wijzigingshistorie is een handreiking naar de softwareontwikkelaars van XIS-applicaties, bedoeld als informatief hulpmiddel en niet als een uitgebreid en volledig overzicht van issues. De eigenlijke AORTA-documentatierelease 8.3.0.0 bevat de normatieve teksten en blijft leidend.
Samenhang met andere documenten
In de wijzigingshistorie wordt aan diverse documenten van AORTA gerefereerd. De nadruk ligt echter op de volgende documenten die het 'koppelvlak' met de programmeurs vormen:
- De PvE's;
- De implementatiehandleidingen;
- Het XML-materiaal.
Uitgangspunten
Referenties
Zie hiervoor het [Documentatieoverzicht AORTA].
Begrippen
Zie hiervoor de [Verklarende woordenlijst].
Afkortingen
Zie hiervoor de [Verklarende woordenlijst].
Wijzigingsoverzicht t.o.v. de vorige release
Vorm
Categorieën versiecompatibiliteit
Om te bepalen welke wijziging potentieel compatibiliteitsproblemen oplevert tussen systemen met verschillende operationele AORTA-versies, classificeert VZVZ elke voorgenomen wijzing. VZVZ hanteert daarbij de volgende categorieën:
- Categorie 0: geen wijziging voor systemenWijzigingen in de architectuurdocumentatie zonder impact op programma van eisen. Geïnstalleerde onderdelen van de infrastructuur hoeven niet aangepast en niet opnieuw gekwalificeerd te worden. Een voorbeeld van deze wijzigingen zijn verduidelijkingen in de documentatie.
- Categorie 1: wijzigingen die lokaal doorgevoerd kunnen wordenWijzigingen met impact op 1 partij of op meerdere partijen maar zonder onderlinge afhankelijkheden. Deze wijzigingen zijn binnen de verschillende onderdelen van de infrastructuur afzonderlijk door te voeren zonder dat daarbij verlies aan functionaliteit optreedt. Een voorbeeld van dit soort wijzigingen is een wijziging aan de eis aan GBZ'en inzake de bewaartermijn voor bepaalde gegevens. Dit heeft impact op elke GBZ, maar de wijziging hiervan binnen een GBZ heeft geen gevolgen voor overige onderdelen van de infrastructuur.
- Categorie 2: wijzigingen die compatibel zijn met de vorige versieWijzigingen die impact hebben op meerdere partijen met onderlinge afhankelijkheden maar die compatibel zijn. Deze wijzigingen worden zodanig ontworpen dat het doorvoeren van de wijzigingen geen afhankelijkheden met zich meebrengt voor overige onderdelen van de infrastructuur. Dat wil zeggen, zowel de uitwisseling tussen een oude zender en een nieuwe ontvanger blijft goed gaan, als de uitwisseling tussen een nieuwe zender en een oude ontvanger blijft goed gaan. Ook deze wijzigingen kunnen dus lokaal doorgevoerd worden (zonder dat men van elkaar weet welke versie geïnstalleerd is). Een voorbeeld van zo'n wijziging is wanneer op landelijk niveau wordt afgesproken dat een optioneel veld in een bepaald bericht voortaan gebruikt gaat worden. Een ander iets complexer voorbeeld is wanneer een optioneel veld verplicht wordt. Een dergelijke wijziging is niet 100% compatibel, maar kan wel als zodanig ontworpen worden door te specificeren dat de nieuwe ontvanger ook een leeg of ontbrekend veld aankan. Een GBZ hoeft dan niet twee versies van één bericht te onderhouden, maar kan lokaal de nieuwe versie doorvoeren.
- Categorie 3: wijzigingen die centraal worden opgevangenWijzigingen met impact op meerdere partijen met onderlinge afhankelijkheden, die niet compatibel zijn, maar waarbij de ZIM verschillende versies ondersteunt zodat GBZ'en geen maatregelen hoeven te nemen. Deze categorie betreft wijzigingen die niet compatibel ontworpen kunnen worden, maar wel door het LSP afgevangen kunnen worden. Dat wil zeggen dat, indien er geen verdere maatregelen getroffen worden, de invoering van de wijziging leidt tot een verlies aan communicatiemogelijkheden en/of functionaliteit. In deze categorie wijzigingen zal de ZIM echter een faciliterende rol vervullen zodat het voor de verschillende decentrale onderdelen van de architectuur lijkt alsof er geen sprake is van verschillende versies. Een voorbeeld van deze categorie zijn wijzigingen in de buitenste wrappers van een bericht. Het LSP kan hierbij zowel een oude als een nieuwe versie ondersteunen zodat er geen compatibiliteitsproblemen ontstaan. Hierbij is de centrale registratie van de conformance tabel per GBZ uiteraard wel van belang.
- Categorie 4: wijzigingen die versiebeheer vergen bij een GBZWijzigingen met impact op meerdere partijen met onderlinge afhankelijkheden, niet compatibel, niet te ondersteunen door de ZIM. Deze laatste categorie bestaat uit wijzigingen die niet compatibel te ontwerpen zijn en waarbij de ZIM ook niet kan faciliteren. Voor deze categorie zal VZVZ per wijziging, in overleg met de belanghebbenden, een aanpak opstellen voor het doorvoeren van de wijziging. Een voorbeeld van deze categorie is de inperking van de mogelijke doseerinstructies om de ontvangende applicatie te ontlasten (die hoeft dan niet alle theoretische combinaties aan te kunnen). Het probleem hierbij is dat een nieuwe ontvanger van een oude zender nog een oude doseerinstructie kan krijgen. Het eisen dat de nieuwe ontvanger deze nog even moet ondersteunen is juist niet de bedoeling van de wijziging.
Overzicht wijzigingen gepubliceerd in errata.
RfC | Beschrijving | Docs |
Infrastructuurwijzigingen versie 8.3.0.0 t.o.v. 8.2.0.0
RfC | Beschrijving | Docs |
n.v.t. | Herschriijving van documentatie in confluence. Hierbij zijn verschillende teksten herzien, aangevuld etc. Met name wetgeving en principes zijn meer up to-date gebracht. Naast bovenstaande is een koppeling met Mitz opgenomen in de documentatie. | Alles |
INI-7464 | Duplicaatdetectie op vertrouwensniveau laag | PvE ZIM |
INI-9450 | Mandateren zorgverlener zonder UZI-middel | PvE <Zorgtoepassing> |
INI-9490 | Ciphersuites naar minimaal goed | PvE <Zorgtoepassing> |
INI-9491 | JWT opgenomen in protocolstack | PvE <Zorgtoepassing> |
INI-9567 | Rol XIS-servicedesk | PvE <Zorgtoepassing> |
INI-9569 | Eisen toegevoegd t.b.v. CQ | PvE <Zorgtoepassing> |
INI-9577 | Niet tonen zorgverlener aan patiënt. | AORTA Architectuur |
INI-9599 | Eis herschreven. | PvE <Zorgtoepassing> |
INI-9600 | Eis verduidelijken. | PvE <Zorgtoepassing> |
INI-9601 | Eis verduidelijken. | PvE <Zorgtoepassing> |
INI-9602 | Invulling gegeven aan configuratieparameters en verduidelijken eis. | PvE <Zorgtoepassing> |
INI-9603 | Eis onder bullit 4 herschreven en invulling gegeven aan configuratieparameters. | PvE <Zorgtoepassing> |
INI-9604 | Eis generieker beschreven. | PvE <Zorgtoepassing> |
INI-9605 | Eis generieker beschreven. | PvE <Zorgtoepassing> |
INI-9607 | Ondersteuning aangemelde bouwsteentypes naast gegevenssoorten in SDS | Ontwerp SDS |
INI-9608 | Meerdere interacties per bouwsteentype | Ontwerp SDS |
INI-9611 | Abonnement functie op basis van contextcode | Ontwerp Abonnementenregister, Ontwerp Gebeurtenisverwerking, |
INI-9597 | Aanpassen APR-documentatie als gevolg aanpassingen XDR | Ontwerp Applicatieregister |
Beschrijving infrastructuurwijzigingen
INI | INI-7464 |
Systeemrol | n.v.t. |
Samenvatting | Duplicaatdetectie dient plaats te vinden op infra- en verstuurberichten. Dit is ongeacht het vertrouwensniveau. |
Compatibiliteit | Categorie 1 |
In document | PvE ZIM |
eis(en) | LSP.ZIM.e4040 |
(XML-)bestand | n.v.t. |
INI | INI-9450 |
Systeemrol | Mandaterend systeem |
Samenvatting | Het moet mogelijk zijn om een zorgverlener/medewerker te mandateren die geen UZI-middel heeft. De zorgverlener/medewerker wordt dan op basis van zijn lokale unieke identificerende kenmerken gemandatereerd. Met dit mandaat kan een zorgverlener/medewerker de conditionele query triggeren. |
Compatibiliteit | Categorie 0 |
In document | PvE <Zorgtoepassing> in geval van toepassing mandaterend systeem |
eis(en) | GBX.AUT.e4513.1 |
(XML-)bestand | n.v.t. |
INI | INI-9490 |
Systeemrol | n.v.t. |
Samenvatting | Ciphersuites moeten minimaal voldoen aan de NCSC richtlijn met beveiligingsniveau goed. |
Compatibiliteit | Categorie 0 |
In document | PvE <Zorgtoepassing> |
eis(en) | GBX.CON.e4080.5, GBX.CON.e4090.2 |
(XML-)bestand | n.v.t. |
INI | INI-9491 |
Systeemrol | Gegevens opleverend systeem, Gegevens ontvangend systeem |
Samenvatting | Een GBx die op basis van FHIR gegevens uitwisselt moet een JWT-token kunnen verwerken. |
Compatibiliteit | Categorie 4 |
In document | PvE <Zorgtoepassing> indien FHIR van toepassing |
eis(en) | GBX.CON.e4130 |
(XML-)bestand | n.v.t. |
INI | INI-9567 |
Systeemrol | n.v.t. |
Samenvatting | De rol van de XIS-servicedesk is binnen de architectuur geformaliseerd. Deze rol blijkt onmisbaar voor het inrichten van het proces 'opvolgen ketentestbevindingen'. |
Compatibiliteit | Categorie 4 |
In document | PvE <Zorgtoepassing> |
eis(en) | XIS.SVD.e4010, XIS.SVD.e4020, XIS.SVD.e4030 |
(XML-)bestand | n.v.t. |
INI | INI-9569 |
Systeemrol | Gegevens opvragend systeem |
Samenvatting | Expliciete eisen toegevoegd voor het gebruik van HSM, gebruik dubbele certificaten en uitvoeren penetratietesten. |
Compatibiliteit | Categorie 4 |
In document | PvE <Zorgtoepassing> indien gebruik wordt gemaakt van de CQ |
eis(en) | GBX.SBH.e4090, GBX.SBH.e4080 en GBX.BVL.e4100.1 |
(XML-)bestand | n.v.t. |
INI | INI-9577 |
Systeemrol | n.v.t. |
Samenvatting | De zorgverlener wordt niet getoond in het Volgjezorgportaal. Verschillende zorgaanbieders verwachten ook dat dit niet getoond gaat worden, zonder dat hier goed over gecommuniceerd gaat worden. Het niet tonen van een zorgverlener is expliciet opgenomen in de architectuur. |
Compatibiliteit | Categorie 0 |
In document | AORTA Architectuur |
eis(en) | n.v.t. |
(XML-)bestand | n.v.t. |
INI | INI-9599 |
Systeemrol | Gegevens versturend systeem |
Samenvatting | Eis is herschreven en verduidelijkt. |
Compatibiliteit | Categorie 0 |
In document | PvE <Zorgtoepassing> in geval van toepassing gegevens versturend systeem |
eis(en) | GBX.BTW.e4080.1 |
(XML-)bestand | n.v.t. |
INI | INI-9600 |
Systeemrol | n.v.t. |
Samenvatting | Een GBx mag niet meer dan 0.5 seconde afwijken van de ZIM. Daarvoor dient er tegen de ZIM of tegen een andere bron gesynchroniseerd te worden. Expliciet gemaakt dat het niet perse een synchronisatie tegen het LSP betreft. |
Compatibiliteit | Categorie 0 |
In document | PvE <Zorgtoepassing> |
eis(en) | GBX.CON.e4030 |
(XML-)bestand | n.v.t. |
INI | INI-9601 |
Systeemrol | n.v.t. |
Samenvatting | Eis iets verduidelijkt. |
Compatibiliteit | Categorie 0 |
In document | PvE <Zorgtoepassing> |
eis(en) | GBX.FBH.e4050.3 |
(XML-)bestand | n.v.t. |
INI | INI-9602 |
Systeemrol | n.v.t. |
Samenvatting | Invulling gegeven aan configuratieparameters. Daarnaast eis op punten herschreven. |
Compatibiliteit | Categorie 0 |
In document | PvE <Zorgtoepassing> |
eis(en) | GBX.CON.e4080.5 |
(XML-)bestand | n.v.t. |
INI | INI-9603 |
Systeemrol | n.v.t. |
Samenvatting | Tekst onder bullit 4 herschreven. Daarnaast invulling gegeven aan de configuratieparameters. |
Compatibiliteit | Categorie 0 |
In document | PvE <Zorgtoepassing> |
eis(en) | GBX.IDA.e4090 |
(XML-)bestand | n.v.t. |
INI | INI-9604 |
Systeemrol | n.v.t. |
Samenvatting | Eis generieker beschreven. |
Compatibiliteit | Categorie 0 |
In document | PvE <Zorgtoepassing> |
eis(en) | GBX.BES.e4020.3 |
(XML-)bestand | n.v.t. |
INI | INI-9605 |
Systeemrol | n.v.t. |
Samenvatting | Eis generieker beschreven. |
Compatibiliteit | Categorie 0 |
In document | PvE <Zorgtoepassing> |
eis(en) | SYS.BVL.e4010.1 |
(XML-)bestand | n.v.t. |
INI | INI-9607 |
Systeemrol | n.v.t. |
Samenvatting | Toegevoegd dat niet alleen de aangemelde gegevenssoorten, maar ook de aangemelde bouwsteentypes gebruikt moeten worden door de SDS |
Compatibiliteit | Categorie 3 |
In document | Ontwerp SDS |
eis(en) | n.v.t. |
(XML-)bestand | n.v.t. |
INI | INI-9608 |
Systeemrol | - |
Samenvatting | Gecorrigeerd dat er meerdere interacties per bouwsteentype zijn ipv meerdere bouwsteentypeversies en dat iedere versie een interactie heeft. |
Compatibiliteit | Categorie 1 |
In document | Ontwerp SDS |
eis(en) | n.v.t. |
(XML-)bestand | n.v.t. |
INI | INI-9611 |
Systeemrol | - |
Samenvatting | Abonnement functie gewijzigd, zodat deze ook op basis van contextcode werkt ipv alleen een gegevenssoort |
Compatibiliteit | Categorie 3 |
In document | Ontwerp Abonnementenregister, Ontwerp Gebeurtenisverwerking, Ontwerp SDS |
eis(en) | n.v.t. |
(XML-)bestand | De volgende berichten in het XML materiaal |
INI | INI-9597 |
Systeemrol | - |
Samenvatting | Aanpassen APR-documentatie als gevolg aanpassingen XDR |
Compatibiliteit | Categorie 1 |
In document | Ontwerp Applicatieregister |
eis(en) | n.v.t |
(XML-)bestand | n.v.t |