Anchor
_Toc147120109 _Toc147120109

Anchor
_Toc147125872 _Toc147125872

Anchor
_Toc147125972 _Toc147125972

Anchor
_Toc177287974 _Toc177287974

Anchor
_Toc304799349 _Toc304799349

Anchor
_Toc306262485 _Toc306262485

Anchor
_Toc115421892 _Toc115421892

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.

Anchor
_Toc147120110 _Toc147120110

Anchor
_Toc147125873 _Toc147125873

Anchor
_Toc147125973 _Toc147125973

Anchor
_Toc177287975 _Toc177287975

Anchor
_Toc304799350 _Toc304799350

Anchor
_Toc306262486 _Toc306262486

Anchor
_Toc115421893 _Toc115421893

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.

Anchor
_Toc199836713 _Toc199836713

Anchor
_Toc147125875 _Toc147125875

Anchor
_Toc147125975 _Toc147125975

Anchor
_Toc177287977 _Toc177287977

Anchor
_Toc179964129 _Toc179964129

Anchor
_Toc304799352 _Toc304799352

Anchor
_Toc306262487 _Toc306262487

Anchor
_Toc115421894 _Toc115421894

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.

Anchor
_Toc147120112 _Toc147120112

Anchor
_Toc147125876 _Toc147125876

Anchor
_Toc147125976 _Toc147125976

Anchor
_Toc177287978 _Toc177287978

Anchor
_Toc179964130 _Toc179964130

Anchor
_Toc304799353 _Toc304799353

Anchor
_Toc306262488 _Toc306262488

Anchor
_Toc115421895 _Toc115421895

Uitgangspunten

Anchor
_Toc147120114 _Toc147120114

Anchor
_Toc147125878 _Toc147125878

Anchor
_Toc147125978 _Toc147125978

Anchor
_Toc177287980 _Toc177287980

Anchor
_Toc179964131 _Toc179964131

Anchor
_Toc304799354 _Toc304799354

Anchor
_Toc306262489 _Toc306262489

Anchor
_Toc115421896 _Toc115421896

Referenties

Zie hiervoor het \[Documentatieoverzicht AORTA\].

Anchor
_Toc179964132 _Toc179964132

Anchor
_Toc304799355 _Toc304799355

Anchor
_Toc306262490 _Toc306262490

Anchor
_Toc115421897 _Toc115421897

Begrippen

Zie hiervoor de \[Verklarende woordenlijst\].

Anchor
_Toc179964133 _Toc179964133

Anchor
_Toc304799356 _Toc304799356

Anchor
_Toc306262491 _Toc306262491

Anchor
_Toc115421898 _Toc115421898

Afkortingen

Zie hiervoor de \[Verklarende woordenlijst\].

Anchor
_Toc179964135 _Toc179964135

Anchor
_Toc304799357 _Toc304799357

Anchor
_Toc306262492 _Toc306262492

Anchor
_Toc115421899 _Toc115421899

Wijzigingsoverzicht t.o.v. de vorige release

Anchor
_Ref212548376 _Ref212548376

Anchor
_Toc304799358 _Toc304799358

Anchor
_Toc306262493 _Toc306262493

Anchor
_Toc115421900 _Toc115421900

Vorm

Anchor
_Ref179710818 _Ref179710818

Anchor
_Toc304799359 _Toc304799359

Anchor
_Toc306262494 _Toc306262494

Anchor
_Toc115421901 _Toc115421901

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.

Anchor
_Toc304799360 _Toc304799360

Anchor
_Toc306262495 _Toc306262495

Anchor
_Toc115421902 _Toc115421902

Overzicht wijzigingen gepubliceerd in errata.

Anchor
_Toc115421903 _Toc115421903

Infrastructuurwijzigingen versie 8.3.0.0 t.o.v. 8.2.0.0

Anchor
_Toc115421904 _Toc115421904

Beschrijving infrastructuurwijzigingen