Wijzigingshistorie

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 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 voor softwareontwikkelaars van XIS-applicaties, bedoeld als informatief hulpmiddel en niet als een uitgebreid en volledig overzicht van issues.

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: Referenties

Begrippen

Zie hiervoor: AORTA Verklarende woordenlijst

Afkortingen

Zie hiervoor: Afkortingen

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 wijziging. VZVZ hanteert daarbij de volgende categorieën:

• Categorie 0: geen wijziging voor systemen. Wijzigingen in de architectuurdocumentatie zonder impact op het 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 worden. Wijzigingen 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 in de eis voor GBZ’s 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 versie. Wijzigingen 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 kan verwerken. 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 opgevangen. Wijzigingen 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 conformancetabel per GBZ uiteraard wel van belang.

• Categorie 4: wijzigingen die versiebeheer vergen bij een GBZ. Wijzigingen 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 om de wijziging door te voeren. 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 erratum

Wijzigingen versie 8.5.1 t.o.v. 8.5.0

Wijzigingen versie 8.5.0 t.o.v. 8.4.0.0