Om de implementatie van nieuwe versies van het koppelvlak (StUF-kv Jeugdzorg bij gemeenten, EBV bij de andere ketenpartijen) beheerst te kunnen laten verlopen, is het noodzakelijk dat er in de keten telkens twee versies van het koppelvlak in gebruik zijn. Overeenkomstig StUF: de laatst uitgebrachte en de daaraan voorafgaande.(sub)versie. De vraag is hoe we hiermee omgaan, welke afspraken we maken, wat dat betekent voor de applicaties van zenders en ontvangers en de CORV zelf. Hiervan is een eerste verkenning gemaakt in bijgaand document.
Graag reacties, voors en tegens en eventuele alternatieven.
Ik heb over het document de volgende opmerkingen:
1. Het feit en de reden dat optie 3 wordt verworpen is naar onze mening volledig onterecht. Ik begrijp dat voorkomen moet worden dat CORV interpretaties van berichten moet uitvoeren, maar dat is niet aan de orde. De vertaal (transformatie) tussen de oude en nieuwe versie van het koppelvlak (cq de berichten) moet onderdeel uitmaken van de nieuwe versie van het koppelvlak. Vanuit effectiviteit (doe het éénmaal goed en voorkom interpretatie verschillen bij diverse partijen) maar zeker ook efficiëntie (éénmaal is goedkoper dan N maal) is het essentieel dat de implementatie van deze vertaling enkelvoudig en centraal binnen CORV plaatsvindt.
2. In de titel van deze discussie wordt gesproken over twee versies van het "koppelvlak" terwijl in het document gesproken wordt over twee versies van "berichten". Dit vergroot het aantal combinaties omdat het blijkbaar mogelijk is dat op enig moment een partij voor het ene bericht de oude versie en voor het andere bericht de nieuwe versie moet gebruiken. Los daarvan is niet duidelijk wat met "een bericht" bedoeld wordt. Het zorgmeldingDi01 bericht wordt bijvoorbeeld gebruikt als basis voor zowel de "notificatie" berichten van Justitie als voor de "zorgmelding" berichten van Politie.
3. Er wordt gesproken over een situatie dat de software van een partij zowel de oude als de nieuwe versie van berichten kan ondersteunen. Wordt hierbij gebruik gemaakt van dezelfde service die aangesproken moet worden en wat betekent dit voor de validatie van de berichten tegen het (welk?) xsd? Is dit praktisch gesproken wel mogelijk?
4. Los van bovenstaande opmerkingen is het mij nog onvoldoende duidelijk welke partij bepaalt wanneer welke versie van een bericht gebruikt wordt en hoe dit gecommuniceerd en geïmplementeerd wordt. Ook wordt niet gesproken over hoe gehandeld moet worden in de situatie dat een partij de verkeerde versie van een bericht verstuurt.
Onze conclusie is dat gekozen moet worden voor het formeel vaststellen van de transformatieregels tussen de oude en nieuwe versie van berichten als onderdeel van de nieuwe versie van het koppelvlak en het centraal en enkelvoudig implementeren van deze transformatieregels binnen CORV. Indien CORV daarnaast per aangesloten leverancier (hoeft veelal niet per gemeente) bijhoudt of deze de nieuwe versie van het koppelvlak ondersteunt, kan de overgang geïmplementeerd worden zodat dat aangesloten partijen twee versies van het koppelvlak ondersteunen.