yarondassonneville
commented
3 weeks ago Dag Josse, bedankt voor de feedback. Hierbij kan je een antwoord vinden op alle opmerkingen en vragen die gesteld zijn.
1. Duiding
Hier en daar begreep ik niet waarom iets op een bepaalde manier in elkaar zat. Zou het mogelijk zijn om meer toelichting toe te voegen op plekken ter verduidelijking voor lezers die geen context hebben?
- Voorbeelden:
- Begrenzing van de standaard: voor welke doeleinden zien we de standaard gebruikt worden en voor welke niet?
- Aangezien het om een applicatieprofiel gaat, en geen implementatiemodel is de scope hiervan zeer ruim. De opzet van dit traject is om de informatie te standaardiseren in de context van het kind, gericht op het ontwikkelen van een gemeenschappelijk begrip van essentiële kindinformatie. Meer info kan gevonden worden in de verslagen van de werkgroepen op (https://data.vlaanderen.be/standaarden/applicatieprofiel-kindfiche/).
- Uitgangsregeling
- Wat betekent dit concreet?
- Uitgangsregelingen per kind kunnen verschillen aangezien er meerdere ophaalregelingen van toepassing kunnen zijn per kind. Bijvoorbeeld, de ophaalregeling in een vakantieperiode kan verschillen van een ophaalregeling tijdens de schoolperiode. Met uitgangsregeling wordt dus bedoeld wat de regeling is voor het kind om de opvang bv. te verlaten.
- Dienstconsumptie
- Waar dient deze entiteit voor? Die lijkt in het overzicht geen eigen velden te hebben, maar linkt alleen participatie onrechtstreeks met dienstaanbod. Zullen hier in de praktijk nog zaken onder hangen die niet zichtbaar zijn in het schema?
- We bepaalden hier geen attributen voor, maar deze kunnen toegevoegd worden tijdens implementatie. Deze klasse zorgt ervoor dat een aangeboden dienst geconsumeerd kan worden door een specifieke Agent / Persoon.
- Wat betekent dit concreet?
- Begrenzing van de standaard: voor welke doeleinden zien we de standaard gebruikt worden en voor welke niet?
- Is het eventueel opportuun om wat meer duiding gegeven te geven voor wanneer iemand praktisch aan de slag wil gaan met de standaard? Hoe zou iemand dan te werk gaan?
- Deze informatie kan hier teruggevonden worden.
2. Klassen vocabularium / types applicatieprofiel
- Wat is het verschil tussen een klasse (vocabularium) en een datatype (applicatieprofiel)?
- Binnen OSLO van Digitaal Vlaanderen is er een duidelijk verschil tussen een klasse (vocabularium) en een datatype (applicatieprofiel). Een klasse in een vocabularium is een concept dat een groep objecten met gemeenschappelijke eigenschappen en gedrag beschrijft. Het fungeert als een blauwdruk voor het definiëren van de structuur en relaties van gegevens binnen een bepaald domein. Bijvoorbeeld, een klasse "Persoon" kan eigenschappen zoals naam, geboortedatum en adres bevatten. Aan de andere kant is een datatype in een applicatieprofiel een specifieke definitie van de vorm en het type van gegevens die aan een eigenschap van een klasse kunnen worden toegekend. Het bepaalt hoe de gegevens moeten worden geïnterpreteerd en verwerkt. Bijvoorbeeld, het datatype "string" kan worden gebruikt om tekstuele gegevens zoals namen of adressen te definiëren.
- Waarom zijn niet alle datatypes in het applicatieprofiel als klassen gedefinieerd in het vocabularium? zijn die als klassen in een andere standaard gedefinieerd? of zijn er types die geen klasse hebben?
- Dit is een specifieke keuze binnen het OSLO team om te modelleren. De modelleringsregels kunnen hier teruggevonden worden.
3. Organisatie, Dienstaanbod etc
- Kunnen organisatie en dienstaanbod afgesplitst worden van de “kern” kindfiche, m.a.w. de entiteit persoon en de entiteiten die daar rechtstreeks mee verbonden zijn? Met die tweede hebben lijkt het dat een breder inzetbare standaard mogelijk wordt, voorbij de context van kinderopvang en -activiteiten.
- Deze klassen komen uit andere standaarden, waardoor we in het model simpelweg de link gemaakt hebben zodat hier verder gegaan kan worden. In het uiteindelijke implementatiemodel kan dit uiteraard weggelaten worden.
4. Modellering vestiging
- Uit onze eigen analyse voor het BOA platform bleek dat het interessant zou zijn om vestiging en organisatie een gedeeld basistype te laten hebben. Dit om bijvoorbeeld toegangsbeheer uniform te kunnen maken voor organisaties en hun vestigingen. Vestigingen zouden zo zelf als organisatie in parent-relatie onder een grotere organisatie hangen. In het applicatieprofiel is ons idee al gedeeltelijk voorzien via de relatie suborganisatieVan. We zouden dan wel nog een subtype-aanduiding voorzien voor elke organisatie-entiteit waaraan af te leiden is of het om een vestiging gaat of niet. Of de naamgeving “organisatie” dan nog de lading dekt voor het overkoepelende concept is te bekijken, eventueel kan dan een algemenere term gebruikt worden.
- Lijkt ons een goed idee.
5. Evolutie richting API?
- Kunnen er stappen gezet worden richting uitbreiding van de standaard naar een API zodat al enigszins vastgelegd kan worden hoe de interacties tussen verschillende systemen die de standaard toepassen eruit zullen zien? Dit lijkt zou ons een meerwaarde om de standaard makkelijker toepasbaar te maken.
- API opzet is geen onderdeel van de scope van een OSLO standaard (cfr. Implementatie fase)
- Wat is de visie voor beheren en delen van deze data? Een centrale hub die de volledige dataset bevat waarop verschillende systemen kunnen inpluggen voor de stukjes data die ze nodig hebben? Of is het doel meer om gedecentraliseerd te werken - ieder systeem heeft z’n eigen primaire opslag en waar nodig helpt deze standaard met het uitwisselen tussen systemen?
- Een visie voor het delen van de data is geen onderdeel van de scope van een OSLO standaard (cfr. Implementatie fase).
6. Data-privacy
- Zou het nuttig zijn om privacy-overwegingen mee op te nemen in de standaard? Bijv. aanbevelingen/verplichtingen voor omgaan met data, beveiliging API’s, data-opslag
- Privacy is geen onderdeel van de scope van een OSLO standaard (cfr. Implementatie fase)
- Moeten kinderen/ouders het recht krijgen om zaken te laten schrappen uit het dossier indien ze dit wensen? Hoe moet dit gepropageerd worden naar de verschillende systemen die (indien toegestaan) delen van de centrale informatie.
- Dit is geen onderdeel van de scope van een OSLO standaard (cfr. Implementatie fase).
7. Medische aspecten
- Hoe zijn de aspecten van de standaard die de gezondheidstoestand van het kind beschrijven tot stand gekomen? Hebben medische professionals hieraan bijgedragen? En/of zijn gerenommeerde bronnen zijn gebruikt voor classificatie van zaken zoals type beperking, type aandoening, type medicatie?
- Voor het opstellen van de termen zijn gerenommeerde bronnen gebruikt voor de classificatie van dergelijke zaken. Enumeraties zijn echter een open voorstel. Bij de implementatie van het model kunnen deze naargelang de applicatie aangepast worden. Via Agentschap Opgroeien is er daarnaast door een medisch professional feedback gecapteerd en deze is reeds verwerkt in het model.
- Is het mogelijk dat medische professionals hier nog commentaar op zouden hebben? Hoe zouden aanpassingen aan de standaard gemaakt kunnen worden op basis van feedback?
- De publieke reviewperiode dient om alle feedback omtrent het model te capteren via github issues.
Hallo, ik ben Josse van Cubitec. Ik heb in overleg met Michiel Steegmans het voorstel van de standaard doorgelezen en wat feedback en vragen opgesteld.