Vanuit gemeenten en leveranciers komt de vraag om ook voor andere processen specifieke vraag-antwoordberichten, services waarmee gegevens kunnen worden gezocht of opgevraagd, te definiëren. Er is nu een werkgroep (uitbreiding van de werkgroep prefill). Op deze plaats willen we de stukken en discussie van deze werkgroep plaatsen.
Naar aanleiding van de uitnodiging tot deelname kwamen drie vragen naar boven:
- Wat is de business case? Waarom zou je hier geld en energie in willen steken?
- Hoe verhoudt dit zich tot het koppelvlak prefill?
- Wat is de scope? Wat maakt dat je een service/bericht wel of niet opneemt in dit koppelvlak?
Laten we beginnen om die vast te beantwoorden. Ik zet die in aparte discussies. Graag jullie reactie.
Veel gemeentes vragen me wanneer onze taakspecifieke applicatie met GBA-v, BAG of NHR koppelt. Op dit moment zijn wij niet van plan een directe koppeling tussen deze applicatie en GBA-v, BAG of NHR te leggen. We hebben behoefte aan een eenduidig koppelvlak voor het bevragen van subjecten en objecten uit de gemeentelijke gegevensdistributie - volgens een standaard met duidelijkheid over welke berichttypes en velden wel/niet ondersteund worden - zonder onderscheid tussen binnengemeentelijke en buitengemeentelijke subjecten/objecten - met een testmogelijk buiten de leveranciers van gegevensmagazijnen om
Aansluitend op Johannes : De landelijke voorzieningen kennen allen bevragingsmogelijkheden (al dan niet op basis van de StUF standaard). Het koppelvlak Gegevensmagazijn zou in beginsel al deze bevragingsmogelijkheden moeten omvatten, maar dan wel op basis van StUF standaard. Hierdoor hoeft Johannes niet meer bij de landelijke voorzieningen aan de kloppen:) Dus alle specificaties hiervoor liggen al op straat en zijn de te vinden op de desbetreffende archieven van de lv's. Het uitgangspunt van Johannes stelt wel hoge eisen aan het gemeentelijk gegevensmagazijn (GGM). Als je bevraagt op persoonsgegevens dan zal het GGM moet borgen dat altijd hetzelfde antwoord wordt gegeven als de GBA-V dat zou geven. Idem voor een perceel, bag-object of bedrijf, etc. Johannes in de rol van burger of in de rol als bedrijf wil namelijk maar 1 overheid ervaren in de e-dienstverlening en geen last hebben van "achterlopende" gegevensmagazijnen.
Op basis van diverse reacties moeten we denk ik de naam herzien. Mogelijk is 'Koppelvlak voor routinematige bevraging van basisgegevens' wel een betere term. Gaan we het in de werkgroep over hebben.