Deze pagina beschrijft de operatie POST /audit/v1/registraties.
Header
Data | Type | Toelichting |
|---|---|---|
x-correlation-id | UUID | Referte (uuid) om meerdere request transacties te groeperen. Identificeert alle operaties die onder één business context plaats vinden. Als er bijvoorbeeld persoonsgegevens uit het rijksregister moeten opgehaald worden en er daarvoor ook een registratie in het repertorium moet gebeuren, dan is het de bedoeling dat de logs van beide operaties met dezelfde x-correlation-id worden geregistreerd. |
x-tracing-id | UUID | Referte (uuid) om de request transactie end-to-end uniek te identificeren. Om terug te komen op voorgaand voorbeeld: het loggen van het ophalen van de persoonsgegevens uit het rijksregister heeft een andere tracing id dan het loggen van de registratie in het repertorium. Indien er echter een ketting van transacties geregistreerd wordt, dan hebben al deze log records dezelfde x-tracing-id. Zie diagram hieronder voor meer toelichting. |
x-request-id | UUID | De unieke identificatie van het verstuurde HTTP request. Elke nieuwe call genereert een nieuwe requestId. |
Het is belangrijk om een onderscheid te maken tussen de refertes van de operatie die in het audit register geplaatst wordt (zie hieronder) en de refertes van de call naar het auditregister zelf (hierboven). Aangezien dit alles in dezelfde business context gebeurt, kan de correlatieId (en misschien ook de tracingId) hetzelfde zijn.
Body
Data | Type | Card. | Toelichting | ||
|---|---|---|---|---|---|
meta | 0-1 | ||||
onderwerpInOnderzoek | boolean | 1 | Indicatie dat verwerking gegevens kadert binnen een (gerechtelijk) onderzoek | ||
registratie | 1 | Omvat 3 refertes: correlatie id, tracing id en request id. Onderstaand schema licht het gebruik hiervan toe: | |||
correlatieId | UUID | 1 | Referte (uuid) om meerdere request transacties te groeperen. Identificeert alle operaties die onder één business context plaats vinden. Als er bijvoorbeeld persoonsgegevens uit het rijksregister moeten opgehaald worden en er daarvoor ook een registratie in het repertorium moet gebeuren, dan is het de bedoeling dat deze beide operaties met dezelfde correlatieId worden geregistreerd. | ||
tracingId | UUID | 1 | Referte (uuid) om de request transactie end-to-end uniek te identificeren. Om terug te komen op voorgaand voorbeeld: het ophalen van de persoonsgegevens uit het rijksregister heeft een andere tracing id dan de registratie in het repertorium. Indien er echter een ketting van transacties geregistreerd wordt, dan hebben al deze transacties dezelfde tracingId. | ||
requestId | UUID | 1 | De unieke identificatie van het verstuurde HTTP request. Elke nieuwe call genereert een nieuwe requestId. | ||
clientId | string(256) | 1 | De unieke identificatie van de applicatie van de leverancier die de inschrijving in het register uitvoert. Dit zal gebruikt worden om het audit record in de juiste databank terecht te laten komen. Het auditregister is weliswaar één gemeenschappelijk systeem, maar is opgesplitst in verschillende tenants elk met hun eigen databank. De clientId moet worden afgesproken met team aansluitingen. | ||
operatie | 1 | ||||
operatie | string(256) | 1 | De uitgevoerde operatie op het onderwerp. Dit is een vrij string attribuut, maar we streven toch een conventie na omwille van de uniformiteit en het opzoeken achteraf. In de overgrote meerderheid van de gevallen is de transactie het oproepen van een webservice.
| ||
finaliteit | |||||
finaliteitId | string(64) | 1 | Het doel van de operatie. Het is sterk aangeraden om hiervoor een IPDC code te gebruiken: https://www.vlaanderen.be/digitaal-vlaanderen/onze-oplossingen/ipdc-interbestuurlijke-producten-en-dienstencatalogus Hoewel afgeraden, kan er ook een eigen identificatie gebruikt worden. | ||
finaliteitType | string(32) | 1 | Gebruikt type voor finaliteit. Is een enumeratie:
| ||
tijdstipUitvoering | date/time | 1 | Datum/tijdstip wanneer de operatie uitgevoerd werd. Dit volgens RFC3339: https://www.rfc-editor.org/rfc/rfc3339 | ||
uitvoerder | 1 | Wie een bepaalde transactie heeft uitgevoerd wordt bepaald door het uitvoerder object. Dit bevat 3 onderdelen: organisatie, dataverwerker en gebruiker. | |||
gebruiker | 0-1 | Welke gebruiker heeft vanuit de toepassing de bevraging uitgevoerd. Indien de transactie in de applicatie geïnitieerd werd door een persoon, dan kan de sleutel voor de identificatie van deze persoon ook meegegeven worden. Als sleutel is hiervoor het INSZ-nummer zeer sterk aangeraden. Dit vergemakkelijkt en uniformiseert immers opzoekingen achteraf door de DPO. Indien dit niet beschikbaar is kan er ook een andere sleutel opgegeven worden. Het type is dan GEBRUIKERSIDENTIFICATIE. Het is dan de verantwoordelijkheid van de gebruiker van het auditregister systeem om dan in het geval van een onderzoek de sleutel te linken aan de juiste persoon. Het gebruiker object is optioneel. Bij een transactie geïnitieerd door een automatisch proces (bijvoorbeeld bij machine2machine communicatie) is er immers geen persoon betrokken. Het is ook mogelijk dat o.w.v. privacy redenen de gebruikersinformatie niet mag meegeven worden aan een extern systeem. In dit geval is het dan wel de verantwoordelijkheid van de afnemer van de auditregister service om in het geval van een onderzoek de identiteit van de gebruiker aan de transactie te kunnen linken. | |||
gebruikerId | string(64) | 1 | Identificatienummer van de natuurlijke persoon of een andere persoonsidentificatie zoals bv. personeelsnummer of account. | ||
gebruikerSleutelType | string(32) | 1 | Gebruikt sleuteltype voor de gebruikerId. Dit is een enumeratie:
| ||
organisatie | 1 | Voor welke organisatie de bevraging uitgevoerd. Dit is de organisatie eigenaar van het systeem dat de geregistreerde transactie heeft uitgevoerd. Deze organisatie is dan de dataverantwoordelijke. Deze organisatie wordt geregistreerd via haar sleutel. Voor Vlaamse entiteiten wordt meestal de OVO code als sleutel gebruikt. Het KBO nummer is echter beschikbaar voor elke Belgische organisatie. Als geen van deze opties mogelijk is (bijvoorbeeld voor buitenlandse organisaties) dan is er de mogelijkheid om een andere sleutel te gebruiken, aangeduid door het type ENTITEIT. | |||
organisatieId | string(256) | 1 | Nationaal identificatienummer van de organisatie | ||
organisatieSleutelType | string(32) | 1 | Gebruikt sleutelType voor de organisatieId. Dit is een enumeratie:
| ||
dataverwerker | 1 | Als er gebruik gemaakt wordt van een tussenliggende dataverwerker, dan kan dit via dit object gespecifieerd worden. Dataverwerkers worden via dezelfde soort sleutels aangeduid als organisaties. Het dataverwerker object is verplicht. Als er geen dataverwerker is, dan is de dataverwerker gelijk aan de organisatie. | |||
dataverwerkerId | string(256) | 1 | Nationaal identificatienummer van de dataverwerker | ||
dataverwerkerSleutelType | string(32) | 1 | Gebruikt sleuteltype voor het DataverwerkerId. Dit is een enumeratie:
| ||
dataverwerkerSysteem | string(256) | 1 | Systeem dat gebruikt werd om de bevraging uit te voeren | ||
onderwerpen | lijst | 1-n | Over wie/wat werd de bevraging uitgevoerd. Het belangrijkste en meest gebruikte sleuteltype is het INSZ nummer. Personen kunnen ook via een ander sleuteltype geïdentificeerd worden (type PERSOONSIDENTIFICATIE), maar we verkiezen steeds het INSZ. Indien de transactie in eerste instantie een ander object betreft (bijvoorbeeld vastgoed via CAPAKEY of een voertuig via een NRPLAAT) maar dan toch in de transactie gelinkt wordt aan een persoon, dan kunnen zowel de sleutel van het object als de INSZ van de persoon in het onderwerpen veld meegegeven worden. Dit maakt het makkelijker voor de DPO om achteraf opzoekingen te doen. | ||
onderwerpSleutelType | string(32) | 1 | SleutelType van onderwerpId. Dit is een enumeratie:
| ||
onderwerpId | string(256) | 1 | Identificatienummer van de natuurlijke persoon of een andere persoonsidentificatie zoals bv. personeelsnummer of account.
| ||
informatie | 0-n | De hoofdbedoeling van het auditregister syteem is om de sleutels van de onderwerpen van een transactie te loggen. Indien er toch ook andere informatie in het audit record moet opgeslagen, dan kan hiervoor het optioneel informatie veld gebruikt worden. De informatie wordt opgegeven via key/value paren. Belangrijk om te weten dat de opzoekfunctionaliteiten (zoekfilters) achteraf toegepast worden op het onderwerpen veld en NIET op het informatie veld. De inhoud van het informatie veld wordt uiteraard wel weergegeven in de zoekresultaten. Het informatie veld kan bijvoorbeeld gebruikt worden om de transactie te linken aan een eigen dossiernummer of een andere interne referte. Indien het een vereiste is om ook de opzoekparameter van de transactie op te slaan (bijvoorbeeld adres, geboortedatum, geslacht, …) dat kan hiervoor ook het informatie veld gebruikt worden. | |||
informatieType | string(32) | 1 | De ‘key’ | ||
informatieWaarde | string(256) | 1 | De ‘value’ | ||
probleem | 0-1 | ||||
titel | string(128) | 1 | Korte omschrijving van het probleem. Bv: FOUT | ||
detail | string(256) | 1 | Uitgebreide omschrijving van het probleem. Bv: Fout formaat in de vraag (XSD-validatie) | ||
status | string(64) | 1 | code voor het probleem. Bv: 10501 | ||
