🆔Loket Integration (ERE + OP)
| STATUS | OWNER | ACTION | DATE |
|---|---|---|---|
In proposal | Yassin | 6/7/2022 | |
In refinement - Design/ Research | Yassin, Sofie | List up attributes in OP, LLB and OSLO in tableform | SP2, GS 21 |
In refinement - Technical Research/Feedback | Team (Claire, Boris, Nordine) | Review list of attributes | SP2 or SP3, GS 21 |
Review by LLB | Team + Felix | Discuss mapping differences and how to overcome them (who changes what). | GS 22 |
In development | |||
In QA/ Testing | |||
In Final state |
Analysis
Vision
The goal is to have an OrganisatiePortaal where data in control of Bestuurseenheden can be managed by them (directly by using the LLB or indirectly by publishing to LLB from a third party app) and be accessible in the OrganisatiePortaal voor ABB users.
Current state
There is currently no integration between Loket and OP. For public data, Centrale Vindplaats is used by both application stacks to make non-GDPR related information accessible.
🤩 Expectations
In this feature passport, we will tackle these future expectations:
Background
For the worship services there is a legal basis that they have to provide this data (will be clarified in later sections) to the Flemish Government. They can manage this with a third-party vendor or the Loket. If it is managed by a third-party vendor, it will be published in Loket.
For the central worship services there are no ministers, hence it is not applicable to them. The central worship services have mandates, but given that there is no legal basis to gather personal data (regarding gender, birth date, nationality and national registery number), this will be managed by OP.
Nicole/Peggy LOW wanted to fill it in once every 3 years in OP. We objected because that entails little commitment to maintain the data quality.
| Position | Bestuur vd Eredienst | Centraal bestuur vd eredienst |
|---|---|---|
Mandates/Board members | Captured from Loket | Managed from OP |
Ministers | Captured from Loket | NA |
Sites (non-MVP) | Captured from Loket (non-MVP) | Captured from Loket (non-MVP) |
Data to be provided by Loket
The following data will be provided by Loket:
Minister
Personal data
Unique identificator (ABB URI id, Rijksregisternummer), gender , nationality, first name, last name, adress, province, E-mailadress, Primary phone number, Secundary phone number
In the OP these are (inherited) attributes from the classes OSLO::Persoon, OSLO PersoonsGebeurtenis:: Geboorte and OSLO:: Nationaliteit
Position data
Bedienaarsfunctie, Startdatum, Einddatum, Gerelateerde besturen van de eredienst (ABB URI ID)
In the OP these are (inherited) attributes from the classes Rol Bedienaar, Positie Bedienaar and relationship with Bestuur van de eredienst
FOD Financiering ("is this person being financed by the federal government to carry out this function?") will be gathered from FOD Justitie and imported into OP. This data will thus not be gathered from Loket end-users. How this data will be obtained from FOD Justitie and be used by ISD (in OP) is to be determined. Out of scope for MVP.
Mandatenbeheer
Personal data
Unique identificator (ABB URI id, Rijksregisternummer), gender, nationality, first name, last name, adress, province, E-mailadress, Primary phone number, Secundary phone number
In the OP these are (inherited) attributes from the classes OSLO::Persoon, OSLO PersoonsGebeurtenis:: Geboorte and OSLO:: Nationaliteit
Position data
Bestuursfunctie, Startdatum, Geplande einddatum, (Effectieve) einddatum, Type helft, Effectieve einddatum, Gerelateerde bestuursorganen van de eredienst (ABB URI ID)
In the OP these are (inherited) attributes from the classes EredienstMandataris, OSLO Mandatendatabank:: Mandaat, Bestuursorgaan (in bestuursperiode)
Startdatum and verkiezingsdatum are two seperate attributes in the datamodel. By the business it is said that it is important to gather the "verkiezingsdatum" so that we can run scripts on it to deduce whether elections were held.
For the MVP we consider election date (verkiezingsdatum) and start date (startdatum) to be equal.
"Reden voor stopzetting" might need to be retired - to be discussed with Peggy if she returns. This field exists in OP and is editable by end users of OP but does not appear in the mandatendatabank.
Functional Mapping Table
Link: https://docs.google.com/spreadsheets/d/1AuOv1nBGYvgvYnfO1nOqo3hT1UEIXct-YveePaStOTU/edit#gid=0
Data Mapping LLB - OP
Differences between LLB and OP - 1 August 2022
The following differences were discovered by Claire during a first assessment.
person:Person
Attributes:
foaf:givenName: used as first name in OP, not used in Loket
persoon:gebruikteVoornaam: used as first name in Loket but as alternative name in OP
foaf:name: used as alternative name in Loket, not used in OP
Yassin 5/8: this requires investigation from OP team + consultation with Niels
mandaat:Mandataris
Attributes:
mandaat: start and mandaat:einde are datetimes in Loket and dates in OP
Yassin 5/8 : OSLO mentions datetime as well ... https://data.vlaanderen.be/doc/applicatieprofiel/mandatendatabank/#Mandataris%3Astart
code:MandatarisStatusCode / ext:MandatarisStatusCode
They don't have the same prefix in their types, the data will not match during the import (!)
code:BestuursfunctieCode / ext:BestuursfunctieCode
They don't have the same prefix in their types, the data will not match during the import (!)
besluit:Bestuurseenheid
Attributes:
classfication in OP has prefix org:classification but has prefix besluit:classificatie in Loket
code:BestuurseenheidClassificatieCode / ext:BestuurseenheidClassificatieCode
They don't have the same prefix in their types, the data will not match during the import (!)
besluit:Bestuursorgaan
Attributes:
classfication in OP has prefix org:classification but has prefix besluit:classificatie in Loke
code:BestuursorgaanClassificatieCode / ext:BestuursorgaanClassificatieCode
They don't have the same prefix in their types, the data will not match during the import (!)
Sync Directions
From OP to Loket : One time
Gather all related data of active bestuursorganen from worship services to Loket.
FP Loket: https://binnenland.atlassian.net/browse/DL-3940
From Loket to OP: Frequently - Hard deadline is 1/4/2023
Gather all related data of all (active + inactive) bestuursorganen
Frequency
The expectation from the business is that a daily sync of this data is sufficient.
Solution
Design
User research
User Research Conclusions:
Mock-ups
Technical
[Information about the technical solutions for expectations that need it e.g. using mu-search for showing all types of positions in one table.]
Technical Research Conclusions
Last updated