De onderstaande vragen hebben betrekking op versie 1.0.2 van het CORV koppelvlak (dd 19-12-2018):
1. Paragraaf 5.2, pagina 19, tabel, heeftBetrekkingOp (komt ook voor op andere plaatsen):
Het woord “alleen” is vervangen door “hooguit”, maar dit moet “optioneel” zijn.
Regel CORV-A3.3 verbiedt namelijk niet dat van een ongeboren kind ook andere gegevens worden opgenomen.
2. Paragraaf 5.2, pagina 23, regel CORV-A3.6 (telefoonnummer of emailadres verplicht):
Geldt deze regel alleen ook voor ongeboren kinderen? Dit lijkt niet logisch. Overigens, ook voor kinderen van jonge leeftijd is deze regel niet logisch.
Waarom wordt deze regel toegevoegd en welke waarde wordt verwacht als het (geboren of ongeboren) kind geen telefoonnummer en emailadres heeft?
3. Paragraaf 5.2, pagina 23, regel CORV-A3.7 (lengte emailadres) (komt ook voor op andere plaatsen):
Waarom wordt hier afgeweken van de internationale standaarden (254 tekens) en worden de applicaties die hiervan afwijken niet aangepast?
4. Paragraaf 5.2, pagina 26, regel CORV-A9.2 (grootte van de bijlagen):
Mag deze wijziging al worden geïmplementeerd voordat versie 1.0.2 ingaat (op de beoogde datum van 4 februari 2019)?
5. Paragraaf 5.2, pagina 27, regel CORV-A9.6 (karakters in bestandsnaam):
Waarom wordt hier afgeweken van de internationale standaarden en worden de applicaties die hiervan afwijken niet aangepast?
Aanvullende opmerkingen:
5.1 Bij “liggend streepje” wordt “-“ vermeld, terwijl veelal “_”(underscore) wordt bedoeld. Is “-“ het bedoelde teken?
5.2 Waarom wordt een underscore (“_”) niet toegestaan? Dit teken wordt in veel bestandsnamen gebruikt.
5.3 Volgens de regel mag een bestandsnaam beginnen met een spatie. Is dit een bewuste keuze?
6. In onze specificaties van koppelvlak versie 1.0.1 staat dat bij een VTO maximaal 10 bijlagen opgenomen mogen worden.
Deze regel zie ik niet (meer) terug in koppelvlak versie 1.0.2. Is deze regel (nog) van toepassing en waar kan ik die vinden?
7. Paragraaf 5.2, pagina 28:
De volgende zin is doorgehaald: “Het referentienummer en het crossRefNummer in de stuurgegevens van de Fo03 worden daarbij gevuld.”
Mogen wij aannemen dat het Fo03 bericht blijft voldoen aan de StUF 3.01 specificaties en het betreffende (xsd) schema?
8. Diverse wijzigingen die opgenomen zijn bij het VTO bericht, verwachten wij dan ook bij de overige berichten.
Waarom wordt er verschil gemaakt tussen de wijzigingen bij het VTO bericht en bij de andere berichten?
9. Bij CORV koppelvlak versie 1.0.1 zijn referentielijsten opgenomen (StUF-Kv Jeugdzorg - Referentielijsten v1.0.0 20150831.xlsx). Zijn deze referentielijsten niet gewijzigd? Voor de volledigheid is het aan te bevelen om deze lijsten ook bij versie 1.0.2 op te nemen.
Met vriendelijke groet,
John Rooijakkers
John,
Als het goed is krijg je deze week een antwoord op je vragen.
Er is me trouwens gevraagd op welke internationale standaarden je precies doelt in de opmerkingen 3 en 5. Kan je daar nog wat specifieker in zijn?
Hi Robert,
Ik had geen concrete standaarden op het oog behalve het RSGB en de aanname dat de daarin gehanteerde definities op andere standaarden zijn gebaseerd. Voor het e-mail adres wordt op de meeste plaatsen die ik ken een lengte van 254 tekens gehanteerd en dus niet slechts 150. Ook de inperking van de toegestande tekens in de bestandsnaam kom ik verder nergens tegen. Het lijkt erop dat gemeenten en GI's nu hun systemen moeten aanpassen omdat één systeem (dat van de RvdK) beperkingen kent en dat vind ik de omgekeerde wereld.
Gr. John.
V.w.b. lengte mailadres, ik weet ook niet beter dat deze in de regel niet langer dan 254 karakters mogen zijn. Mede afgestemd op http://www.rfc-editor.org/errata_search.php?rfc=3696&eid=1690.
De inperking van toegestane tekens is volgens mij al opgenomen in het de Bijlage 2: Specificatie Informatiemodel van het document StUF-Koppelvlak Jeugdzorg. Daarin staat "alle in fysieke bestandsnamen toegestane tekens". Geen verdere inperking nodig of mogelijk wat mij betreft.
Bij deze per punt een antwoord op de vragen van John. Voor het gemak herhaal ik de vragen hier even. Mijn antwoorden staan in vet:
1. Paragraaf 5.2, pagina 19, tabel, heeftBetrekkingOp (komt ook voor op andere plaatsen):
Het woord “alleen” is vervangen door “hooguit”, maar dit moet “optioneel” zijn.
Regel CORV-A3.3 verbiedt namelijk niet dat van een ongeboren kind ook andere gegevens worden opgenomen.
In de tabel wordt vermeldt welke informatie er per onderdeel van het bericht wordt verstrekt. Voor een ongeboren kind kan dat niet meer zijn dan een geboortedatum, het heeft immers geen identificerende kenmerken, naam of wat dan ook. Dit wordt in de vermelde regels overigens niet hard afgedwongen. Er mogen dus meer gegevens verstrekt worden, de afnemer mag er niet van uitgaan dat die aanwezig zijn.
2. Paragraaf 5.2, pagina 23, regel CORV-A3.6 (telefoonnummer of emailadres verplicht):
Geldt deze regel alleen ook voor ongeboren kinderen? Dit lijkt niet logisch. Overigens, ook voor kinderen van jonge leeftijd is deze regel niet logisch.
Waarom wordt deze regel toegevoegd en welke waarde wordt verwacht als het (geboren of ongeboren) kind geen telefoonnummer en emailadres heeft?
Hier is inderdaad een foutje in de specificatie geslopen. Excuses daarvoor. Regel CORV-A3.6 moet komen te vervallen.
3. Paragraaf 5.2, pagina 23, regel CORV-A3.7 (lengte emailadres) (komt ook voor op andere plaatsen):
Waarom wordt hier afgeweken van de internationale standaarden (254 tekens) en worden de applicaties die hiervan afwijken niet aangepast?
Voor de RvdK levert een lengte van 254 tekens grote problemen op vandaar de afwijking.
4. Paragraaf 5.2, pagina 26, regel CORV-A9.2 (grootte van de bijlagen):
Mag deze wijziging al worden geïmplementeerd voordat versie 1.0.2 ingaat (op de beoogde datum van 4 februari 2019)?
Ja, ook nu worden bijlagen met deze totale grootte al geaccepteerd.
Justid heeft bij monde van Patrick Klaasen aangegeven dat een bruto grootte van 30Mb resulteert in een netto grootte van 21 Mb.
5. Paragraaf 5.2, pagina 27, regel CORV-A9.6 (karakters in bestandsnaam):
Waarom wordt hier afgeweken van de internationale standaarden en worden de applicaties die hiervan afwijken niet aangepast?
Hier kom ik nog op terug.
Aanvullende opmerkingen:
5.1 Bij “liggend streepje” wordt “-“ vermeld, terwijl veelal “_”(underscore) wordt bedoeld. Is “-“ het bedoelde teken?
Met liggend streepje wordt inderdaad “-“ bedoeld. Underscore is abusievelijk niet vermeld in regel CORV-A9.6. Die regel moet dus aangepast worden.
5.2 Waarom wordt een underscore (“_”) niet toegestaan? Dit teken wordt in veel bestandsnamen gebruikt.
Idem
5.3 Volgens de regel mag een bestandsnaam beginnen met een spatie. Is dit een bewuste keuze?
De restricties komen van de RvdK. Voor hen is een naam beginnend met een spatie blijkbaar geen probleem. Al lijkt mij dat geen logische keuze. Te overwegen is in het StUF-koppelvlak deze eis wel te stellen, om misverstanden te voorkomen, al is dat voor de ketencommunicatie blijkbaar niet nodig.
6. In onze specificaties van koppelvlak versie 1.0.1 staat dat bij een VTO maximaal 10 bijlagen opgenomen mogen worden.
Deze regel zie ik niet (meer) terug in koppelvlak versie 1.0.2. Is deze regel (nog) van toepassing en waar kan ik die vinden?
Deze regel is al vanaf versie 1.0.0 niet meer van toepassing en staat abusievelijk nog wel in het diagram in par. 4.2 en in bijlage 2 bij het objecttype DOCUMENT bij de relatie ZAAK kent DOCUMENT. Dit moet dus aangepast worden.
7. Paragraaf 5.2, pagina 28:
De volgende zin is doorgehaald: “Het referentienummer en het crossRefNummer in de stuurgegevens van de Fo03 worden daarbij gevuld.”
Mogen wij aannemen dat het Fo03 bericht blijft voldoen aan de StUF 3.01 specificaties en het betreffende (xsd) schema?
Dit is standaard functionaliteit van StUF en is derhalve overbodig om hier te vermelden.
8. Diverse wijzigingen die opgenomen zijn bij het VTO bericht, verwachten wij dan ook bij de overige berichten.
Waarom wordt er verschil gemaakt tussen de wijzigingen bij het VTO bericht en bij de andere berichten?
De wijzigingen zijn doorgevoerd vanwege het correct kunnen verwerken van het VTO-bericht door de RvdK. Dit is niet in andere berichtsoorten doorgevoerd om de impact te beperken tot alleen het VTO-bericht. Veel van de wijzigingen hebben overigens geen effect op andere berichtsoorten.
9. Bij CORV koppelvlak versie 1.0.1 zijn referentielijsten opgenomen (StUF-Kv Jeugdzorg - Referentielijsten v1.0.0 20150831.xlsx). Zijn deze referentielijsten niet gewijzigd? Voor de volledigheid is het aan te bevelen om deze lijsten ook bij versie 1.0.2 op te nemen.
Aan de referentielijsten is niets gewijzigd. Voor alle duidelijkheid: alleen de meest recente versie van de referentielijsten is van toepassing. De laatste versie van de referentielijsten is 'StUF-Kv Jeugdzorg - Referentielijsten v1.0 20181221'.
Tot slot: we zijn nog in beraad over de feitelijke datum van intreding van het GVS. Daar komen we dus nog op terug.
Bovenstaand wordt deze reactie gegeven:
6. In onze specificaties van koppelvlak versie 1.0.1 staat dat bij een VTO maximaal 10 bijlagen opgenomen mogen worden.
Deze regel zie ik niet (meer) terug in koppelvlak versie 1.0.2. Is deze regel (nog) van toepassing en waar kan ik die vinden?
Deze regel is al vanaf versie 1.0.0 niet meer van toepassing en staat abusievelijk nog wel in het diagram in par. 4.2 en in bijlage 2 bij het objecttype DOCUMENT bij de relatie ZAAK kent DOCUMENT. Dit moet dus aangepast worden.
Opmerking 1: het diagram in par. 5.2 moet dan ook aangepast worden.
Opmerking 2: het is volkomen aan mij voorbij gegaan dat er geen limiet meer op het aantal bijlagen zit. Ook teruglezend in https://www.gemmaonline.nl/images/gemmaonline/3/3e/Documentatie_behorend... en dan het wijzigingsdocument, zie ik niets terug van het laten vervallen van de limiet van 10 bijlagen bij een VTO (of ik kijk er volledig overheen?).
Graag bevestiging dat er géén limiet meer zit op het aantal bijlagen bij VTO, idealiter met verwijzing naar documentatie waarin dit gecommuniceerd is, zodat ik kan nagaan waar ik dit gemist heb.
Ruud,
Om met het antwoord op opmerking 2 te beginnen, ik heb Arjan Kloosterboer even geraadpleegd en hj heeft bevestigd dat er inderdaad geen limiet meer zit op het aantal bijlagen van een VTO. Om grote omvangen te voorkomen is blijkbaar indertijd tegelijk met het invoeren van de MaxMb beperking ook de beperking tot max 10 documenten ingevoerd. Later heeft men zich gerealiseerd dat dit dubbelop is en dat alleen een Mb-beperking voldoende is. Blijkbaar is dit toentertijd wel aan de EBV-kant doorgevoerd maar zijn we dit aan de StUF-kant vergeten.
Het antwoord op opmerking 1 is dus dat inderdaad dit ook in het diagram in par. 5.2 moet worden aangepast wat betekent dat dus het XML-Schema moet worden aangepast. Dit is gelukkig een wijziging die backwards compatible is. Desondanks hoor ik graag of er leveranciers zijn voor wie deze wijziging tot onoverkomelijke problemen zal leiden en die deze wijziging dus liever niet doorgevoerd zien worden.
Duidelijk Robert, bedankt voor het navragen. Ik verwacht aan onze zijde geen problemen bij aanpassing XL schema.
Verwijderen van de beperking maximaal 10 bijlagen toe te voegen is voor ons (PinkRoccade) akkoord.
Ik stel voor om dit mee te nemen bij de geplande aanpassingen in versie 1.0.3.
Om de implementatie van alle aanpassingen te plannen horen we graag wanneer deze versie opgeleverd wordt.
Heeft iemand al eens een VTO met meer dan 10 bijlagen succesvol getest op het KTP? Als ik in scenario 1 een VTO indien met 11 bijlagen krijg ik een Fo01 retour met details:
Code:901
Plek:server
Omschrijving:Het StUF VTO bericht voldoet niet
Details:se XSD validation details:
<string>:198:0:ERROR:SCHEMASV:SCHEMAV_ELEMENT_CONTENT: Element {http://www.egem.nl/StUF/sector/zkn/0310}heeftRelevant: This element is not expected.
No SCH validation done
Vraag is nu of ons bericht niet juist is of dat het KTP (nog) niet voorziet in de juiste validatie.
Door een fout aan de kant van de CORV acceptatie omgeving wordt jouw bericht ten onrechte afgewezen doordat je meer dan 10 bijlagen bij hebt gevoegd.
Blijkbaar hebben wij nog niet alle Stuf versie 1.01 schema's vervangen.
Aha, dank voor de reactie Patrick, dan hoef ik niet verder te zoeken aan onze kant.
Patrick,
De fout ligt geheel aan onze kant. Zie deze discussie.
Krijgen we bericht wanneer dit op het KTP is aangepast, zodat ik ook daar kan testen met > 10 bijlagen?