Naar een regionaal integraal leerlingzorgsysteem Parkstad Limburg

Naar een regionaal integraal leerlingzorgsysteem Parkstad Limburg Peter B. Sloep (Fontys Hogescholen) en Eric Sol (Solide BV) met een bijdrage van Roger Dols (Morpheus Software) Sittard, lectoraat educatieve functies van ict, Fontys Hogescholen Januari 2007 In     

opdracht van Onderwijsstichting Movare Stichting Limburg Voortgezet Onderwijs Onderwijsstichting Sint-Bernardinus Onderwijsorganisatie INNOVO Stichting Samenwerkingsbestuur Primair Onderwijs Parkstad Limburg en Omstreken

© Het onderhavige werk valt onder de Creative Commons-licentie: ‘Naamsvermelding-NietCommercieelGeenAfgeleideWerken 2.5 Nederland’. Ga naar de onderstaande URL voor een precieze beschrijving van wat u als lezer of gebruiker op grond van deze licentie is toegestaan. In het kort komt het erop neer dat u het onderhavige werk mag kopiëren, verspreiden, tonen en open uitvoeren mits u: a. de door auteurs aan het werk gegeven naam vermeldt, b. het werk niet voor commerciële doeleinden gebruikt, iii) het werkt niet bewerkt. < http://creativecommons.org/licenses/by-nc-nd/2.5/nl/legalcode>

R IL P a rkstad Limburg

Inhoudsopgave Sa menvatting met aanbevelingen

1

1

Inleiding

5

2

Good practices

8

2.1 2.2 2.3 2.4 2.5

Informatiemodellen Binding van een informatiemodel Normen, standaarden, specificaties Uitwisselingsarchitecturen Analyse van gegevens

3

Enkele relevante afspraken over de systemen: Edex, IMS, IMS LIP, IMS Enterprise Services, IMS ePortfolio, DOD, ELDvo, BRON en Functioneel Ontwerp

18

4

Aanbeveling en en plan van aanpak

27

4.1

Aanbevelingen

4.2

Plan van aanpak

Appendix 1 Opdrachtformulering Regionaal Integraal Leerlingzorgsysteem

38

Appendix 2 Beknopt verslag gevoerde gesprekken

40

Appendix 3 Overzicht van velden en enkele specificaties

45

Appendix 4 Geraadpleegde en aanbevolen websites en documenten

47


Samenvatting Het onderhavige advies betreft het opzetten en invoeren van een regionaal, integraal computersysteem rond leerlingzorg. Meer in het bijzonder gaat het erom allerlei leerlinggegevens die diverse instellingen in de Parkstadregio (scholen, zorginstellingen, gemeentelijke overheid) hebben opgeslagen, te kunnen uitwisselen en aggregeren. Het advies is medebepaald door de uitkomsten van gesprekken met de diverse stakeholders. De gesprekken hebben laten zien dat het om een weerbarstig probleem gaat. Dit wordt mede veroorzaakt door de volgende factoren: - er zijn in de regio veel verschillende partijen bij betrokken, hetgeen de communicatie complex maakt; - er bestaan tussen de partijen grote verschillen in de mate waarin men is voortgeschreden bij de invoering van onderwijsondersteunende ict; - de partijen verschillen in de ambities met betrekking tot het te bereiken einddoel (functionele eisen die men aan het systeem stelt) en tot het tempo waarin men dat wenst te bereiken; - de partijen verschillen van mening over de vraag wat de meest wenselijke architectuur is van de technische infrastructuur (centraal versus decentraal). Deze elementen staan niet los van elkaar. Vooral de laatste drie vloeien voort uit de spanning die er in samenwerkingsverbanden nu eenmaal altijd bestaat tussen lokaal (per partij) en globaal (voor elk van de partijen gezamenlijk) wenselijke ontwikkelingen: wat gemiddeld goed is voor iedereen, kan slecht uitpakken voor enkele individuele deelnemers. Bij het maken van keuzen kan dus ook nooit iedereen volledig worden tevreden gesteld. Bovendien zijn er mondiaal en landelijk allerlei initiatieven om tot beschrijvingen van leerlinggegevens te komen. Daarbij geldt dat de beschrijving van zorggegevens enigszins

1


achterloopt bij de beschrijving van studievolggegevens en naw-gegevens. Het onderzoek stelt daarom een aanpak voor die enerzijds een minimale functionaliteit omschrijft waarmee iedereen uit de voeten kan en anderzijds ruimte biedt aan individuele partijen aanpassingen te doen die hun specifieke functionele eisen recht kunnen doen. In concreto wordt geadviseerd een informatiemodel en binding op basis van de LIP te kiezen. Het informatiemodel en de binding die het ELDvo-project ontwikkelen en die een toepassingsprofiel zijn van de LIP, zijn de veiligste keuze. Weliswaar zijn beide nog niet beschikbaar in definitieve vorm, maar eerste stappen kunnen worden gezet, op dezelfde basis als waarop experimenteerscholen nu ELDvo gebruiken. Door voor ELDvo te kiezen, wordt interoperabele uitwisseling van de belangrijkste leerlinggegevens (een ‘kernverzameling’) gegarandeerd. In eigen beheer, maar bij voorkeur samen met anderen worden dan extra modules ontwikkeld. Dat zal vooral voor de zorgaspecten nodig zijn. Scholen in het samenwerkingsverband kunnen die modules naar behoefte gebruiken voor hun interne bedrijfsvoering. Verder wordt geopteerd voor een decentrale architectuur: iedere partij is zelf verantwoordelijk voor de opslag van de eigen data, evenals voor het onderhoud en de integriteit ervan. Voor deze keuze zijn drie redenen. De eerste is dat zo de verantwoordelijkheid voor de data dicht bij de gebruikers ervan blijft. De tweede is dat zo het eenvoudigst tegemoet kan worden gekomen aan specifieke infrastructurele wensen van afzonderlijke partijen. En ten slotte biedt deze aanpak van een kernverzameling van interoperabele gegevens die uitgewisseld worden tussen autonome gegevensbestanden het voordeel dat implementatie kan plaatsvinden zonder dat daarvoor ingrijpende wijzigingen in bestaande werkprocessen en hard- en software nodig zijn. Wel is nodig dat de leveranciers van (bestaande) softwarepakketten voor het beheer van leerlinggegevens een dergelijke architectuur ondersteunen. Berichtenuitwisseling op basis van webservices verdient dan aanbeveling.

2


Voorwaarde voor de haalbaarheid van de voorgestelde tweesporige aanpak is ook dat de leveranciers van de nu gebruikte software bereid zijn zich aan een informatiemodel en binding op basis van de LIP/ELDvo te conformeren. De fabrikanten van de drie gebruikte pakketten zijn lid van de Vereniging Digitaal OverdrachtsDossier (DOD). De Vereniging, waarvan overigens alle belangrijke Nederlandse fabrikanten van administratieve software voor scholen lid zijn, heeft een eigen informatiemodel en binding ontwikkeld, die niet de LIP als basis heeft. Om aan de wensen tot integratie met bijvoorbeeld een portfoliosysteem te kunnen voldoen en om de nationale en internationale concurrentie het hoofd te kunnen bieden, zullen ons inziens de leden van de Vereniging uiteindelijk niet anders kunnen dan im- en exportfaciliteiten op basis van de ELDvo (en dus de LIP) te bieden. Zolang de ELDvo niet beschikbaar is, zal het DOD overigens vooralsnog naar alle waarschijnlijkheid voldoende uitwisselingsmogelijkheden bieden: het informatiemodel van het DOD is weliswaar nog niet gepubliceerd, maar is ontwikkeld met als doel uitwisseling van gegevens tussen de pakketten van de betrokken fabrikanten mogelijk te maken. In de gesprekken is ook de wens naar voren gekomen analyses op de beschikbare data te kunnen doen, bijvoorbeeld om de effecten van beleidsmaatregelen op bijvoorbeeld de schoolloopbaan van bepaalde groepen van leerlingen in kaart te brengen. Daarin voorziet de voorgestelde aanpak niet zonder meer. Doordat gegevens van leerlingen van computersysteem naar computersysteem overgedragen worden, ontstaat er geen actueel en integraal beeld van de lotgevallen van een leerling over alle betrokken scholen en instellingen heen. Op slechts één plaats – de huidige school van zo’n leerling – beschikt men over een actueel beeld. Doordat verder niet alle gegevens meegenomen worden – dat geldt alleen voor de kernverzameling – is dit beeld bovendien nog incompleet. Er bestaan kennistechnologische methoden, bijvoorbeeld die welke zijn gebaseerd op zogeheten topic maps, om de kennis die in een decentraal systeem als voorgesteld besloten ligt, te ontsluiten en op allerlei manieren te aggregeren terwijl de integriteit van de data noch de privacy in het geding wordt gebracht. De uitwerking van een dergelijke aanpak valt buiten het bestek van het huidige advies, maar lijkt op basis van het voorgestelde informatiemodel en de voorgestelde architectuur zeer goed realiseerbaar.

3


Aanbevelingen

1. Sluit aan aan bij proefimplementaties van ELDvo en werk voor de korte termijn met het DOD. Schakel daarna over op het ELDvo zo gauw dat mogelijk is, dat wil zeggen zo gauw het beschikbaar is en de gebruikte software-pakketten het ondersteunen. 2. Ontwikkel gereedschappen waarmee een eenvoudige berichtenstandaard snel kan worden geïmplementeerd. Zorg er daarna voor dat zo snel mogelijk de leveranciers van de leerlingregistratiesoftware berichtenuitwisseling op basis van webservices (in een decentrale architectuur) ondersteunen. 3. Werk het functioneel ontwerp LeerlingBegeleidingsSysteem om tot in UML geformuleerde use cases, een conceptueel model en, desgewenst, interactie- en activiteitendiagrammen. Als de deskundigheid daarvoor niet intern aanwezig is, huur die dan in. Gebruik de UML-diagrammen om aan de leveranciers van de in de regio gebruikte registratiesoftware gezamenlijk eisen te stellen aan de nog te ontwikkelen versies. 4. Ontwikkel binnen het raamwerk van het ELDvo aanvullende modules om aan schoolen regiospecifieke wensen tegemoet te komen, in elk geval op het gebied van de leerlingenzorg. 5. Doe onderzoek naar de mogelijkheid van analyse van de decentraal opgeslagen gegevens door gebruik te maken van topic maps.

4


1

Inleiding

De opdracht is: tot een advies te komen voor de opzet en invoering van een tot de Parkstadregio beperkt, onderling samenhangend (integraal) computerondersteund systeem voor betrouwbare en efficiënte uitwisseling en aggregatie van allerhande informatie over zorg aan leerlingen in het pretertiaire onderwijs. Deze leerlinginformatie is nu gefragmenteerd beschikbaar bij onderwijsinstellingen (inclusief het peuterspeelzaalwerk), zorginstellingen zoals de gemeentelijke gezondheids-dienst en de bureaus Jeugdzorg, en de gemeentelijke overheden waaronder het bureau Vroegtijdig Schoolverlaten (zie ook appendix 1). Ter onderbouwing van het advies zijn gesprekken met een reeks van belanghebbende partijen gevoerd, die tot doel hadden de functionele eisen die gebruikers aan het systeem stellen, in kaart te brengen. Appendix 2 geeft een compact overzicht van wat er met de verschillende gesprekspartners besproken is. Om gegevens uit te kunnen wisselen, zijn daarom afspraken nodig over de manier waarop we dat gaan doen, dat wil zeggen afspraken over een informatiemodel en een uitwisselingsarchitectuur. Het informatiemodel geeft aan wat precies wordt uitgewisseld of hoe de gegevens gestructureerd zijn. De architectuur geeft aan langs welke wegen ze uitgewisseld worden of hoe het dataverkeer georganiseerd wordt. Wanneer over de manier waarop de uit te wisselen gegevens gestructureerd worden geen afspraken gemaakt zijn, kan een ontvanger verzonden data niet interpreteren, laat staan integreren in zijn eigen administratiesysteem. De adoptie van een voor alle deelnemers gelijk informatiemodel verdient voorts de voorkeur omdat de ontvanger (of de zender) geen dataconversies – het vertalen van data van de ene structuur (format) naar een andere – hoeft uit te voeren. De uitwisselingsarchitectuur geeft aan hoe gegevens uitgewisseld kunnen worden. Het grote aantal betrokken partijen en de veelheid aan te gebruiken systemen sluiten uit

5


dat de informatievoorziening tot stand kan komen door eenvoudige converters te maken. Stel dat iedere partij een eigen softwarepakket met een eigen informatiemodel hanteert. De toevoeging van een nieuw pakket (of veranderingen in het informatiemodel van een bestaand pakket) zal kunnen leiden tot de noodzaak nieuwe converters te schrijven, voor elk van de bestaande pakketten één. Bij 3 pakketten zijn 3 converters nodig, bij 11 al 55! Door voor een gedeeld informatiemodel te kiezen dat als intermediair dient, betekent de toevoeging van een extra pakket de toevoeging van slechts één extra converter, namelijk een die de structuur van het toegevoegde pakket vertaalt naar die van het gedeelde informatiemodel. Omdat er altijd sprake is van bestaande software (legacy-systemen) is een zekere mate van conversie overigens onvermijdelijk, namelijk van het overeengekomen informatiemodel naar het format van de legacy-software. Bij de keuze van een gedeeld informatiemodel verdient het de voorkeur aansluiting te zoeken bij bestaande afspraken op dit gebied (standaarden), nationaal dan wel internationaal. Zo kan geprofiteerd worden van de expertise waarover anderen reeds beschikken, kunnen uitbreidingen van het samenwerkingsverband met nieuwe partners gemakkelijker gerealiseerd worden en zal de noodzaak tot het bouwen van converters bij de aanschaf van nieuwe software al snel vervallen (omdat de nieuwe software van nature – native – de taal van het geadopteerde informatiemodel al spreekt; uit concurrentieoverwegingen zijn fabrikanten daartoe gedwongen). De keuze van een uitwisselingsarchitectuur moet recht doen aan bij betrokkenen in gebruik zijnde systemen en gewenste workflows. Bij de invoering van een systeem als bedoeld, speelt altijd de vraag in hoeverre de gebruikers bereid zijn een dergelijk systeem te adopteren. De innovatiediffusieliteratuur geeft aan dat men zich aan allerlei richtlijnen moet houden, op straffe van mislukking (cf. Rogers, 2003; Sloep, 2006). In het kader van deze opdracht is vooral de richtlijn van belang dat een innovatie moet passen bij bestaande waarden en behoeften. (Andere richtlijnen betreffen de complexiteit van een innovatie, de mogelijkheid ermee te experimenteren en de waarneembaarheid van de voordelen ervan.) Door de heterogeniteit van de groep betrokkenen is het niet eenvoudig

6


daaraan te voldoen. Het vanuit een regionaal beleidsperspectief redelijke standpunt snel over veel en actuele gegevens te willen beschikken, verdraagt zich bijvoorbeeld slecht met de gedachte dat leerlinggegevens van de vertrouwensrelatie tussen kind, ouder/verzorger en docent of zorg- en hulpverlener deel uitmaken. Het begrijpelijke streven van scholen of schoolstichtingen naar autonomie in eigen huis laat zich slecht rijmen met de evenzeer begrijpelijke wens van regionale overheden zo goed mogelijk het overzicht te bewaren. Geprobeerd moet daarom worden tot een architectuurvoorstel te komen dat zo goed mogelijk tegemoet komt aan de waarden en wensen van alle deelnemende partijen zonder tegelijk de winst van gegevensuitwisseling en -aggregatie uit handen te geven. Dat wordt niet bereikt door te mikken op de doorsnee van ieders waarden en wensen. Een optimum kan alleen worden bereikt door te kiezen voor een uitwisselingsarchitectuur die multipele perspectieven biedt op de uitwisseling en aggregatie van data en zo tegemoet komt aan de eigen waarden en wensen van alle betrokkenen. In het volgende hoofdstuk zullen we een aantal good practices bespreken. We zullen bespreken wat informatiemodellen en hun bindings zijn, en hoe (open) standaarden en normen hiermee samenhangen, ook zullen we op enkele mogelijke uitwisselingsarchitecturen voor gegevens ingaan. In het daaropvolgende hoofdstuk zullen enkele relevante standaarden voor de uitwisseling van leerlingegevens onder de loep genomen worden. Dat alles brengt ons tot het formuleren van een plan van aanpak en enkele aanbevelingen, die we ook onderbouwen. Het rapport wordt afgesloten met een overzicht van geraadpleegde bronnen en drie appendices. We gaan er bij onze analyse van uit dat software voor het invoeren en muteren van leerlinggegevens voorhanden is.

7


2

Good practices

2.1

Informatiemodellen

Een informatiemodel is ruwweg een afspraak over de manier waarop gegevens het best gestructureerd kunnen worden. Een informatiemodel geeft voor een reeks van entiteiten (‘objecten’) aan welke eigenschappen ze bezitten, hoe ze onderling gerelateerd zijn en welke bewerkingen er op mogen worden uitgevoerd. Het informatiemodel van de EDEX bijvoorbeeld is een afspraak over de uitwisseling van administratieve gegevens voor het basisonderwijs. Dit model bevat als entiteiten ondermeer [leerling], [onderwijsnummer], [groep], [jaargroep], [schooljaar]. De entiteit [leerling] wordt omschreven als een persoon die onderwijs volgt of gevolgd heeft (voorbeeld van een eigenschap). Een [groep] is een verzameling instanties van [leerling] van één [jaargroep] met een eigen naam binnen een [schooljaar] (relatie). De EDEX bepaalt verder dat een groep één of meer [leerling]en kent (relatie). Iedere [leerling] heeft verder een uniek, dat wil zeggen één en slechts één [onderwijsnummer] (relatie), waarbij het onderwijsnummer het door het ministerie van OCW verstrekte nummer is aan leerlingen die bekostigd onderwijs volgen (eigenschap), dat in de praktijk gelijk is aan het sofinummer (eigenschap). Deze laatste eigenschap houdt in – al staat dat er niet expliciet – dat bewerking van het onderwijsnummer, bijvoorbeeld het toekennen aan een [leerling] van een ander nummer, niet is toegestaan (operatie). Al deze eigenschappen, relaties en operaties worden in het informatiemodel beschreven. Voor de EDEX is dat gedaan in de Nederlands Technische Afspraak (NTA) 2032 van het Nederlands Normalisatie-instituut. De gegevens die worden geproduceerd in het kader van zorg aan leerlingen kunnen omvangrijk en divers zijn. Het is zaak deze gegevens op een betekenisvolle manier te ordenen.

8


-

-

Allereerst zijn er dimensies die te maken hebben met de bron en het eigenaarschap van verstrekte gegevens: - zijn ze van binnen de school afkomstig of van buiten (onderwijsnummer!); - betreffen ze administratieve gegevens over inschrijving, betaling en dergelijke of bewijsmateriaal dat in de loop van een schoolloopbaan is verzameld over de vorderingen (portfolio) of - zorggegevens; gaat het om gegevens die krachtens wettelijke verplichtingen moeten worden aangeleverd (BRON, verzuim)? Schooltypen en -niveaus moeten eenduidig worden gelabeld (niet primair onderwijs en basisschool door elkaar bijvoorbeeld). Hetzelfde geldt voor landenaanduidingen, taalaanduidingen, gebruikte tekensets (denk aan allerlei diakritische tekens).

We kunnen ook vanuit het perspectief van de mate van zorg kijken. - In alle gevallen wordt minimale informatie over de persoonlijke situatie van een leerling vastgelegd: zijn of haar gezinssituatie, etniciteit, het land van herkomst van ouders en dergelijke. - Het vastleggen van persoonskenmerken gaat een stap verder en hebben een meer psychologisch karakter (dyslexie, concentratieproblemen, samenwerkingsproblemen etc.). - In veel gevallen worden indicaties vastgelegd op basis waarvan extra handelingen worden verricht, bijvoorbeeld individueel leesonderwijs of stapsgewijs begeleiden van faalangstige leerlingen. - Weer een stap verder gaat het organiseren van extra zorg waarvoor een beroep wordt gedaan op extra budgetten, waardoor in het algemeen meer en andere verantwoordingsinformatie moeten worden aangeleverd. - Ten slotte zijn in de meer complexe situaties veel partijen, binnen en buiten het onderwijs, betrokken bij het leveren van zorg aan leerlingen: Bureau Jeugdzorg, Politie en andere. Niet alleen wordt informatie-uitwisseling complexer naarmate meer partijen zich

9


intensiever ermee bemoeien, ook de aard van de vastgelegde informatie verschuift van sterk administratief naar meer open gestructureerde dossiers. Zo werken de bureaus Jeugdzorg aan een eigen standaard voor zorgdossiers. Dit gegeven van toenemende complexiteit keert verderop terug in de beschouwing over ambities en plateauplanning.

2.2

Binding van een informatiemodel

Een informatiemodel is een tekstdocument, voor de overzichtelijkheid vaak voorzien van tabellen, dat voor mensen goed leesbaar is. Informatiemodellen kunnen niet door computers gelezen worden, daarvoor zijn de gebruikte woordenlijst en syntaxis (grammatica) te weinig strikt. Informatiemodellen worden daarom afgebeeld in een formele taal, een taal met een nauw vastgelegd vocabulaire en syntaxis, om deze machineleesbaar te maken. Zo’n afbeelding wordt gewoonlijk een binding genoemd. Een heel simpele versie daarvan is het tab-delimited formaat, dat wel wordt gebruikt om data tussen spreadsheets uit te wisselen. Het vocabulaire kent twee ‘woorden’: [data-element] en [scheidingsteken]. Het scheidingsteken heeft als eigenschap [tab], maar had bijvoorbeeld ook [komma] kunnen zijn. Deze binding heeft als grote bezwaar dat de uitdrukkingsmogelijkheden ervan zeer gering zijn – het is onmogelijk de soort relaties als we voor de EDEX beschreven af te dwingen – en dat de twee elementen uitsluitend onderscheidbaar zijn aan de volgorde waarin ze in het databestand voorkomen. De kans op fouten is hierdoor erg groot. Sinds enkele jaren wordt ondermeer hierom veelvuldig gebruikt gemaakt zogeheten XML-bindings. Het voert te ver hier in detail op in te gaan, maar XML - eXtensible Markup Language – is een taal die als het ware zichzelf beschrijft: een computer leest niet alleen wat de inhoud van een dataelement is, maar weet tegelijk om welke type dataelement het gaat. Het element [onderwijsnummer] wordt in XML als volgt weergegeven:

10


522312731 Zo is door gebruikmaking van de gepunte haken helder wat de naam van dit element is en wat het element zelf is. Een XML-binding wordt gegeven in de vorm van een XMLschema, dat precies beschrijft welke elementen zijn toegestaan, hoe ze onderling gerelateerd zijn, welke eigenschappen ze hebben en welke data per element zijn toegestaan (cf. Van der Vlist, 2002). In het schema worden dus de in het informatiemodel vastgelegde afspraken zeer precies en op machineleesbare manier vastgelegd. Doordat er een schema beschikbaar is, kunnen uit te wisselen documenten bij export of import op validiteit worden gecontroleerd: gedragen de data in dit document zich wel zoals we met elkaar hebben afgesproken, is het onderwijsnummer ingevuld wanneer we afgesproken hebben dat dit verplicht was? Hierdoor worden niet alleen handmatige controles bijna overbodig (tegen het formeel correct invullen van het foute onderwijsnummer helpt valideren natuurlijk niet), maar wordt de kwaliteit van de opgeslagen en uit te wisselen data ook veel beter gegarandeerd. XML als binding en XML-schema’s hebben nog allerlei andere voordelen – zoals het feit dat ze platform onafhankelijk zijn, dat het open standaarden zijn die nog volop doorontwikkeld worden, dat het ASCII-bestanden zijn, dat andere specificaties via een proces dat namespacing heet kunnen worden ingevoegd in een specificatie – waarop we hier echter niet verder zullen ingaan.

2.3

Normen, standaarden, specificaties

Afspraken over informatiemodellen en bindings worden nuttiger naarmate zich meer mensen eraan willen houden. Tevens wanneer zij het karakter van standaarden (normen) krijgen, zeker wanneer die standaarden open, dat wil zeggen voor iedereen inzichtelijk en

11


beïnvloedbaar zijn. Daarvoor zijn allerlei redenen, waarvan de belangrijksten zijn dat software- en systeemontwikkelaars zo kunnen profiteren van het beschikbaar komen van een grotere afzetmarkt (iedereen die de standaard gebruikt) en gebruikers van standaarden betere kwaliteit tegen een lagere prijs krijgen (door concurrentie tussen de ontwikkelaars). Zulke open standaarden worden over het algemeen beheerd door speciaal daarvoor in het leven geroepen clubs van experts. IMS (leertechnologiestandaarden) is daar een voorbeeld van, de IETF (Internet Engineering Task Force, voor internetstandaarden) een ander. Soms gaat men nog een stap verder en maakt men afspraken over standaarden onderdeel van overleg tussen - door nationale of internationale overheden in het leven geroepen - instituten. De NEN is hiervan het Nederlandse voorbeeld, DIN het Duitse, CEN het Europese, ISO het mondiale. Standaarden die door dit soort gremia worden vastgelegd leggen meestal extra gewicht in de schaal. De EDEX is een (bijzonder soort) standaard die door de NEN wordt beheerd (cf. Sloep 2002) Pogingen om tot afspraken te komen waar veel mensen zich achter stellen, kunnen ertoe leiden dat zo’n afspraak feitelijk onbruikbaar wordt, doordat alles wat controversieel was eruit gelaten is. Om dat te voorkomen laat men in standaarden de gebruiker waar dat nodig is de ruimte de standaard aan zijn eigen wensen aan te passen. Daarvoor gebruikt men zogeheten toepassingsprofielen. De EDEX stelt bijvoorbeeld dat het gebruik van het onderwijsnummer facultatief is, maar het staat een groep gebruikers natuurlijk vrij onderling af te spreken dat het verplicht is. Dit leidt tot een apart toepassingsprofiel voor die gebruikers op het informatiemodel (en de binding). Toepassingsprofielen worden veel gebruikt. Het bezwaar ervan is natuurlijk wel dat de mogelijkheid tot probleemloos uitwisselen van bestanden met derden erdoor beperkt wordt. In die zin zijn ze een compromis.

2.4

Uitwisselingsarchitecturen

Regionale Integrale Leerlingenzorg vraagt toegang tot en onderhoud van relevante gegevens door verschillende partijen, ieder vanuit de eigen verantwoordelijkheid.

12


Standaardisatie op één systeem waarmee deze verschillende partijen hun eigen verantwoordelijkheid kunnen ondersteunen is geen optie gebleken en ook geen verstandig streven. Er moeten dus andere keuzes moeten worden gemaakt om tot instellingsoverstijgende gegevensuitwisseling te komen. Dit probleem is niet uniek voor leerlingenzorg, men is er bijvoorbeeld ook tegenaan gelopen toen men probeerde afspraken te maken over de uitwisseling van patiëntgegevens. Er zijn uit de praktijk verschillende visies (architecturen) af te leiden op welke wijze deze instellingsoverstijgende gegevensuitwisseling kan plaatsvinden. We bespreken de drie belangrijkste. 1. Centrale opslag van alle gegevens die door meerdere partijen worden gebruikt. In deze architectuur wordt een centrale database ontworpen die alle gegevens bevat, tenzij deze uitsluitend binnen één organisatie worden gebruikt. Alle ontvangende en toeleverende partijen passen hun systemen zodanig aan, c.q. vragen hun leveranciers om aanpassingen te doen zodat deze kunnen synchroniseren met de centrale database. De systemen kunnen technisch en functioneel volledig van elkaar verschillen zolang ze maar een koppeling met de centrale gegevensopslag hebben. Dit model wordt op grote schaal toegepast. Een bekend voorbeeld is BRON, de centrale gegevensopslag van de IB-Groep (zie onder). Deze architectuur laat overigens, net als de hierna te bespreken architecturen, toe dat verschillende softwarepakketten worden gebruikt als client, om de gegevens te beheren. De belangrijkste voordelen van deze architectuur zijn: - de architectuur is bekend; - koppelingen zijn doorgaans eenvoudig te ontwikkelen. De belangrijkste nadelen van deze architectuur zijn: - er moet één partij worden aangewezen die het beheer van de centrale gegevensopslag uitvoert; - het is niet altijd duidelijk wie de eigenaar is van een gegeven, zeker als meer partijen dezelfde gegevens onderhouden.

13


2. Centrale verwijzing naar gegevens die door meerdere partijen worden gebruikt

In deze architectuur worden geen data opgeslagen maar uitsluitend de locatie en autorisatie ervan. Er is dus sprake van een centrale wegwijzer (‘repository’) waarin is opgeslagen op welke plaats zich welke gegevens bevinden. Een geautoriseerde gebruiker kan zich vervolgens tot de individuele eigenaar van de gegevens richten met een verzoek tot inzage of wijziging. Dit model wordt toegepast voor de uitwisseling van patiëntgegevens via het Landelijk Schakelpunt. De belangrijkste voordelen van deze architectuur zijn: - eenvoudige discussie over privacy en eigenaarschap omdat geen gegevens worden verplaatst; - weinig verkeer omdat alleen gegevens worden uitgewisseld als er aanleiding toe is. De belangrijkste nadelen van deze architectuur zijn: - grote complexiteit; - het opvragen van gegevens kost tijd omdat dit altijd in twee stappen moet gebeuren. 3. Uitwisseling volgens een berichtenstandaard

In deze architectuur worden geen gegevens, verwijzingen of andere metadata centraal opgeslagen. Er wordt een standaard afgesproken voor uitwisseling van gegevens tussen systemen in de vorm van een intermediair formaat. Deze intermediair formaat is belangrijk om te voorkomen dat het aantal uitwisselingen explosief groeit als het aantal participerende systemen groter wordt (zie de inleiding). Er zijn vele voorbeelden van berichtenstandaarden, zoals EDIFACT (voor uitwisseling van financiële gegevens tussen marktpartijen) en GIM (voor uitwisseling van gegevens tussen verzekeraars en tussenpersonen). De belangrijkste voordelen van deze architectuur zijn: - technisch eenvoudig; er hoeft geen centraal systeem te worden ontworpen en beheerd;

14


- geen discussie over eigenaarschap van gegevens. De belangrijkste nadelen van deze architectuur zijn: - met het opvragen van gegevens is tijd gemoeid (gebeurt niet in realtime); - er zijn extra voorzieningen nodig om een veilige uitvoering te kunnen realiseren. Om tot een keuze te komen van de meest geschikte uitwisselingsarchitectuur worden de volgende twee vragen in beschouwing genomen: a. Is er een onomstreden partij om gegevens centraal te beheren? b. Welke eisen worden gesteld aan de tijdigheid, actualiteit en volledigheid van de gegevens? De gesprekken leren dat het niet eenvoudig zo niet onmogelijk is één (al dan niet bestaande) partij aan te wijzen die voor alle belanghebbenden acceptabel is om als ‘beherende’ partij op te treden. Daarnaast leert de ervaring dat zo’n partij al snel een eigen dynamiek of juist gebrek daaraan ontwikkelt (denk aan de IB-Groep). Dit zijn belangrijke redenen om niet voor centrale opslag te pleiten. Actualiteit speelt bij de leerlingzorggegevens geen voorname rol; een beperkte vertraging is acceptabel. Een (landelijk) schakelpunt lijkt onnodig complex; de trage invoering van het EPD bevestigt deze reserves. Aanbevolen wordt daarom de informatie-uitwisseling vorm te geven via de ontwikkeling en implementatie van een berichtenstandaard (model 3).

2.5

Analyse van gegevens

Als een geschikt informatiemodel is beschreven en een geschikte binding daarvoor is geformuleerd, kunnen records met leerlinggegevens worden beheerd: aangemaakt, verwijderd, gemuteerd en opgeslagen. Daarvoor zijn uiteraard een of meer softwareapplicaties nodig. We nemen aan dat die er zijn (een vergelijking van functionaliteiten van gebruikte applicaties valt buiten de scope van dit rapport). De winst van volgens een

15


gestandaardiseerd informatiemodel en binding opgeslagen gegevens is dat die gegevens uitgewisseld kunnen worden tussen applicaties van verschillende fabrikanten (mits die zich strikt aan de standaard houden!). Immers, op de diverse scharnierpunten (po/vo, vo/mbo; school A/school B) hoeven nu geen tijdrovende en foutgevoelige handelingen meer verricht te worden ten behoeve van de uitvoer en invoer van gegevens. Als leerlinggegevens eenmaal op deze gestandaardiseerde manier zijn vastgelegd, doen zich allerlei mogelijkheden van analyse door aggregatie voor. Alle leerlingen van een bepaalde lichting kunnen als cohort door de jaren heen worden gevolgd (verticale analyse). Zo kunnen de effecten van ingezet beleid worden gevolgd door elkaar opvolgende cohorten te vergelijken. Scholen van eenzelfde type kunnen onderling vergeleken worden (horizontale analyse). Zo kan bijvoorbeeld worden vastgesteld op welke scholen de leerlingen zitten die het grootste risico lopen te ontsporen. Waar gegevens gedistribueerd op verschillende hardware en zelfs in verschillende software liggen opgeslagen (model 3) is het uitvoeren van dit soort analyses niet zonder meer mogelijk. Om optimaal uitgerust te zijn voor het maken van de gewenste analyses biedt Topic Maps, een internationale ISO-standaard voor kennisintegratie, een uitkomst. De standaard is bovendien gebaseerd op XML, waarmee uitwisseling van informatie wordt vergemakkelijkt. Dat geldt eens te meer voor in XML opgeslagen gegevens. Zo kunnen losstaande systemen die normaal niet of nauwelijks met elkaar in verbinding staan als één geheel worden benaderd, over de grenzen van bestaande systemen heen. Door deze integratie ontstaat als het ware een nieuwe kennislaag, en die maakt het mogelijk om bijvoorbeeld alle gegevens van een individuele leerling of van een cohort in één punt te verzamelen. Hierdoor komt ook informatie naar die welke normaliter niet gevonden wordt. Vanuit deze rijkere, geïntegreerde informatieverzameling kunnen ook verbanden en patronen naar voren komen, die niet op de conventionele manier kunnen worden gevonden. Om de analysecapaciteit verder te versterken kunnen nieuwe verbanden worden toegevoegd aan de bestaande informatie, zonder dat hiervoor

16


systeemaanpassingen noodzakelijk zijn. Zo ontstaat er een flexibele kennis- en informatiestructuur waarmee de ontwikkeling van leerlingen op veelzijdige wijze gemonitord kan worden. Waar meerdere systemen worden ontsloten en gekoppeld, is het belangrijk om de privacy van de betrokkenen in oog te houden. Om de controle hierover te behouden, kan met topic maps de toegang tot de informatie tot en met het niveau van de individuele persoon worden gecontroleerd. Desgewenst kan de informatie ook geanonimiseerd worden getoond. Een laatste belangrijk aspect van topic maps is dat de bestaande organisatie en bestaande systemen niet hoeven te worden aangetast voor de creatie en het onderhoud van deze geïntegreerde kennislaag.

17


3

Enkele relevante afspraken

In de voorgaande paragrafen zijn al enkele afspraken (specificaties) voor de uitwisseling van leerlinggegevens aan de orde geweest. In dit hoofdstuk worden de meest bekende nader geanalyseerd (zie ook Tonneman en Van Hoek, 2005; er staan in dat document overigens enkele misvattingen over wat metadata zouden zijn en over de rol die IMS daarbij zou spelen). Specificaties die zich in het bijzonder richten op leerlingzorggegevens zijn er nauwelijks, in elk geval geen internationale. De reden hiervoor is mogelijk dat er grote verschillen zijn tussen landen vanwege de lokale regelgeving en verder gevoeligheid van de materie. Appendix 3 toont als aanvulling een overzicht van de belangrijkste velden van enkele van deze specificaties. EDEX

Een relatief oude is de EDEX, wat staat voor Educatieve Export, voluit de Nederlandse Technische Afspraak NTA 2032, Administratieve uitwisselingsgegevens voor het basisonderwijs. Deze afspraak is al de negentiger jaren ontstaan en in 2000 nog eens vernieuwd. Die eerste versies maakten niet gebruik van een XML-binding maar van zogeheten fixed formats (zie het verhaal over tab-delimited bestanden in voorgaande tekst), waardoor veel fouten werden gemaakt. In 2004 is daarom een XML-binding gemaakt – EDEXml – en is tevens het beheer van de afspraak in handen van de NEN (normcommissie leertechnologieën) gekomen. De nieuwe EDEX maakt nu ook gebruik van allerlei bestaande afspraken over het gebruik van persoonsgegevens (NEN 1888), het weergeven van landennamen (ISO 316-1), etc. De EDEX bevat elementen om personen (leerlingen en leerkrachten), groepen en scholen te beschrijven. De leerlinggegevens behelzen de bekende NAW-gegevens, evenals het onderwijsnummer, de etniciteit, het groepsnummer, de instroom- en uitstroomdatum en het leerlinggewicht (niet hun massa kg maar hun belang, om eventuele extra financiering te bepalen). De schoolgegevens behelzen onder meer de BRIN-code, dependence-code en gegevens over groepen en

18


leerkrachten. De EDEX biedt een informatiemodel dat voldoet voor de uitwisseling van eenvoudige leerlinggegevens. Wil men additionele gegevens uitwisselen dan zullen daarvoor aanvullingen op het informatiemodel gemaakt moeten worden en additionele xsd’s (bindingen) worden geschreven, die dan via namespacing worden ingevoegd. De EDEX heeft voorzieningen getroffen die dit mogelijk maken. IMS

Het IMS Global Learning Consortium is opgericht in 1997 op initiatief van de EDUCAUSE-organisatie in de Verenigde Staten. IMS ontwikkelt specificaties voor gedistribueerd leren. IMS hanteert een lidmaatschapsmodel, dat wil zeggen alleen organisaties die contributies betalen mogen meewerken aan de ontwikkeling of herziening van specificaties; zij mogen als enigen ook stemmen over het al dan niet accepteren van een specificatie. Eenmaal geaccepteerde specificaties kunnen gratis door iedereen worden gedownload van hun website. Software-ontwikkelaars, uitgevers, universiteiten, overheidsinstellingen en belangengroepen zijn lid van IMS (contributing members). In Nederland zijn de Open Universiteit en de Stichting Surf lid. IMS heeft zo’n 17 specificaties ontwikkeld. Drie daarvan lijken relevant voor het ontwerpen van een leerlingzorgsysteem: Learner Information Package (LIP), Enterprise en ePortfolio. IMS LIP

De LIP is in maart 2001 voor het eerst gepubliceerd, onlangs is er een licht bijgestelde versie (1.0.1) op de markt gekomen. De LIP is in staat informatie over leerlingen op te slaan en tussen verschillende systemen uit te wisselen. Het gaat hier om informatie die nodig is om de activiteiten van leerlingen te kunnen ondersteunen. De LIP is flexibel in twee opzichten: - alle elementen zijn facultatief, dus het is aan de gebruiker vast te stellen wat nodig is en wat niet; - men kan desgewenst elementen toevoegen.

19


De LIP bevat geen functionaliteiten voor het bundelen van LIP-bestanden en voor het uitwisselen van deze LIP-pakketten. De LIP maakt gebruik van de IMS Content Packaging-specificatie uit LIP-bestanden om LIP-pakketten samen te stellen. Omdat Content Packages zip-bestanden zijn, zijn alle gebruikelijke mechanismen voor de uitwisseling van gezipte bestanden geschikt voor de uitwisseling van LIP-pakketten. Bij het ontwikkelen van de LIP heeft men veel aandacht besteed aan privacy-aspecten. De LIP bevat 11 categorieën van gegevens, per categorie worden weer diverse velden (elementen) onderscheiden. We bespreken hier de meest relevante. - De categorie Identification bevat de basale NAW-gegevens en is gebaseerd op de vCard-specificatie (die bijvoorbeeld ook door Outlook gebruikt wordt om NAWgegevens op te slaan). - Goal beschrijft de doelen ambities van een leerling, het specificeren van subdoelen is mogelijk. - QCL staat voor qualifications, certifications en licenses en kan dus gebruikt worden om mijlpalen in iemands schoolcarrière mee vast te leggen, inclusief de herkomst ervan. Denk aan vmbo-certificaten, maar ook een bevordering van groep 4 naar groep 5 op een basisschool of de toelating tot het atheneum. - Accessibility gaat over voorkeuren van leerlingen in de breedste zin van het woord. Dus niet alleen over handicaps, maar ook over geprefereerde taal (moedertaal) en leerstijl. Er is in 2003 overigens een specificatie verschenen, Accessibility for Learner Information Package, die twee subschema’s omschrijft voor dit LIPelement. - In de categorie Activity worden leeractiviteiten vastgelegd. Hoe gedetailleerd men dat wil doen, hangt natuurlijk af van de wensen van de implementatoren. Indien gewenst kunnen ook links naar bewijsstukken van activiteiten (een verlag, een website), mits online beschikbaar, worden opgenomen. - Wanneer het onderwijs competentiegericht is opgezet, kunnen in de categorie Competency verworven competenties worden vastgelegd. - Voor de beschrijving van competenties en leerdoelen is een afzonderlijke specificatie ontwikkeld, de IMS Reusable Definition of Competency and Educational Objective

20


(RDCEO). Verder kunnen relaties tussen bijvoorbeeld QCL- en Activity-elementen worden gelegd. Dat wordt in aparte categorie Relationship gedaan, waarin alle relaties tussen elementen in de verschillende categorieën worden beschreven. IMS Enterprise Services

De Enterprise-Services specificatie is voor het eerst gepubliceerd in 1999, waarna een revisie is gevolgd in 2004 (versie 1.1). De Enterprise-specificatie is bedoeld om het uitwisselen van gegevens tussen verschillende administratieve systemen die bij het onderwijs binnen één organisatie betrokken zijn, zoals een leerlingenadministratie, een bibliotheekadministratie en een leermanagementsysteem (ELO). Er wordt bijvoorbeeld ook geen aandacht besteed aan privacy en data-integriteit. Het accent ligt daarom niet op personen en hun behoeften zoals bij de LIP, maar op groepen (klassen) en de rol die zij in een instelling spelen. De Enterprise-specificatie onderscheidt personen en groepen. Personen maken deel uit van groepen, maar ook groepen kunnen deel uitmaken van groepen, zodat een hiërarchie van groepen gemaakt kan worden (‘Laura zit in groep X van school Y binnen schoolstichting Z’). Anders dan de LIP bevat Enterprise zelf een eenvoudig systeem om boodschappen uit te wisselen tussen een bron- en doelsysteem. Dit vereist overigens dat objecten uniek identificeerbaar zijn. Voor personen kan dat eenvoudig via het onderwijsnummer, voor groepen zullen dit soort IDs speciaal gegenereerd moeten worden. In de manier waarop Enterprise personen beschrijft zit overigens enige overlap met LIP. LIP en Enterprise samen dekken dezelfde behoeften als de EDEX, met dien verstande dat de EDEX een veel minder complexe specificatie is; dat geldt vooral het gedeelte dat overlapt met de LIP. De EDEX kan dus ook veel minder functionaliteiten modelleren. IMS ePortfolio

De IMS ePortfoliospecificatie is, zoals de naam al zegt, een specificatie om portfolio-

21


informatie mee te beschrijven; ze werd voor het eerst gepubliceerd in juni 2005. Een ePortfolio is, aldus de specificatie, een ‘collectie van authentiek en divers bewijsmateriaal, afkomstig uit een meer omvattende archief, dat laat zien wat een persoon of organisatie in een tijdsperiode geleerd heeft [...]’. Het perspectief is dus dat van de individuele gebruiker en wat hij of zij aan anderen wil laten zien van wat hij gepresteerd heeft. De specificatie bevat dan ook als hoofdgroepen [owner] en [view]. ePortfolio leunt zwaar op de LIP voor de beschrijving van allerlei elementen. [competency], [activity] en [accessibility] komen bijvoorbeeld in beide specificaties voor. ePortfolio verschilt vooral van de LIP in het perspectief dat ze biedt: kijkt de LIP vanuit het instellingsperspectief, ePortfolio doet dat van het gebruikers- (leerling-) perspectief. Het [view]-element laat bijvoorbeeld toe verschillende vensters te definiëren op dezelfde informatie, afhankelijk van de vraag of bijvoorbeeld een toekomstige werkgever of een arbeidsbemiddelaar ernaar kijkt. Portfolio’s worden, net als LIPbestanden, verpakt als Content Packages voor ze uitgewisseld worden. De ePortfoliospecificatie van Kennisnet is een toepassingsprofiel van IMS ePortolio. DOD

De leveranciers van leerlinginformatiesystemen hebben in 2004 de Vereniging Digitaal OverdrachtsDossier (VDOD) opgericht om de digitale overdracht van leerlinggegevens tussen de diverse administratieve systemen die in het primair en voortgezet onderwijs gebruikt worden te vereenvoudigen. @vo, Eduscope en Dotcomschool zijn lid van de vereniging. De in de VDOD verenigde leveranciers hebben zich ertoe verplicht dat hun software in staat is volgens de DOD-standaard valide databestanden te genereren, te exporteren en te importeren (volledige interoperabiliteit). De vereniging claimt dat de DOD een open standaard wordt, maar de eigen website hult zich in zwijgen over zowel het informatiemodel als de binding. De standaard is in elk geval niet open in de zin dat de totstandkoming ervan via een openbaar proces van publiceren en kritiseren heeft plaatsgevonden. Mogelijk wordt de standaard wel vrijelijk beschikbaar gesteld.

22


Op grond van wat nu bekend is, blijkt dat de DOD een aantal uit de al eerder genoemde specificaties bekende elementen bevat als [leerling] en [school] maar daarnaast bevat het als enige ook elementen die op de leerlingzorg zijn toegesneden: [zorg], [arts], [handelingsplan], [verzuim], [contact overige organisaties], [instrumenten LWOO-PrO]. Een DOD-bestand is een XML-bestand, uitwisseling ervan vindt plaats door het bestand als e-mail te versturen, aldus de website van de DOD. Serverkoppelingen zijn dus niet voorzien, al kunnen ze natuurlijk altijd door een fabrikant in de software ingebouwd worden. Belangrijk daarbij is in hoeverre het genereren van een DOD-bestand handmatig moet gebeuren. Als dat zo is, heeft automatische uitwisseling ook weinig zin. De specificatie wordt volgens plan in december 2006 opgeleverd. ELDvo

In het ELDvo, voluit ‘Ontwikkeling Standaard Elektronisch Leerdossier voortgezet onderwijs’, werkt een aantal partijen samen: Het departement OCW financiert, de VORaad (voorheen Schoolmanagers-vo) is de inhoudelijk opdrachtgever en CINOP doet het projectmanagement. De bedoeling is dat de standaard eind 2008 operationeel is. Men is van plan in het project ook andere scharnierpunten te betrekken, zoals die tussen het mbo en hbo, tussen mbo en hbo, en tussen hbo en wo. In 2005 is een vergelijking uitgevoerd tussen een aantal standaarden die als uitgangspunt zouden kunnen dienen: BRON, DOD en IMS LIP. De conclusie daaruit is dat men IMS LIP als uitgangspunt zal hanteren. Waarschijnlijk zal men een toepassingsprofiel maken voor de Nederlandse situatie, waaraan op die plekken die in de LIP daarvoor zijn gereserveerd nog te ontwikkelen modulen, zorg wordt expliciet genoemd, kunnen worden ingevoegd. Er wordt hard gewerkt aan het informatiemodel dat volop in ontwikkeling is. Daarom heeft het geen zin nu al in meer detail daarnaar te kijken. BRON

We noemen ook nog het door de Informatiebeheer Groep sinds 2003 gehanteerde

23


BRON-informatiemodel. BRON staat voor Basisregistratie Onderwijsnummer en is in het leven geroepen opdat vo-scholen gegevens aan de Informatie Beheer Groep kunnen aanleveren. Er is sprake van eenrichtingverkeer, van de scholen naar de IB-Groep. BRON is vooral geïnteresseerd in gegevens die de financiering door de overheid van de vo-scholen helpen bepalen. BRON bevat als elementgroepen [persoonsgegevens], [inschrijvingsgegevens], [examengegevens] en [vakgegevens]. Deze gegevens komen uiteraard uit de schooladministratiesystemen, het informatiemodel dat daarvoor gekozen wordt moet derhalve die gegevens kunnen aanleveren. Het informatiemodel zal dus in elk geval de BRON-elementen moeten bevatten. De structurering van de data hoeft overigens niet dezelfde te zijn als in BRON. Als er gekozen wordt voor een XML-binding dan bestaan er technieken (XSLT en X-path bijvoorbeeld) om data te converteren naar het BRON-informatiemodel. Een complicatie is dat de IB-groep voor de aanlevering nog geen xml-bestanden verlangt of zelfs maar toelaat. Dat maakt de conversie ingewikkelder. Functioneel Ontwerp

Ten slotte noemen we nog het zogeheten ‘Functioneel ontwerp LeerlingBegeleidingsSyseem’ (Anoniem, 2006), dat binnen de Onderwijsstichting SintBernardinus en de Stichting Limburgs Voortgezet Onderwijs is ontwikkeld. Het document is wat lastig in een categorie onder te brengen omdat het niet alleen een informatiemodel (bijlage A van het genoemde document) beschrijft maar ook allerlei andere zaken. Zo bevat hoofdstuk 3 een overzicht van actoren en wat zij doen, inclusief verschillen in benamingen tussen de scholen; dit zou een overzicht van UML ‘use cases’ (cf Fowler, 1999) genoemd kunnen worden. Het systeem biedt een aanzet tot het inrichten van workflows rond een operationeel leerlingzorgsysteem. Hoofdstuk 4 beschrijft allerlei procedures, waarvan sommige in een workflow, andere in software geïmplementeerd moeten worden. Dit zou passen in UML activity diagrammen en interactiediagrammen. Een opmerkelijk element in het functioneel ontwerp is ook dat voorwaarden voor de technische implementatie zijn opgenomen (paragraaf 4.3). Bijlage B bevat overigens een

24


vocabulaire voor een specifiek veld, met wat het best omschreven lijkt te kunnen worden als een ‘helpfile’ bij de invulling. De velden van het in bijlage A genoemde informatiemodel lijken ten slotte niet een-op-een af te beelden op een van de bovengenoemde informatiemodellen, al is er wel sprake van substantiële overlap tussen het informatiemodel van appendix A en de hier besproken informatiemodellen. Samenvattend

Vooraf zij opgemerkt dat welk informatiemodel men ook kiest, het in staat zal moeten zijn om de door de IB-Groep vereiste BRON-bestanden te genereren, op straffe van de noodzaak alsnog handmatig dit soort bestanden aan te maken. Het scholenveld zou er overigens goed aan doen gezamenlijk de IB-Groep te stimuleren voor het BRONinformatiemodel een XML-binding te ontwikkelen. Dat maakt de aanlevering aanzienlijk minder foutgevoelig. Het oudste informatiemodel, EDEX, volgt een eigen, historisch gegroeide weg. In zijn functionaliteit is de EDEX een combinatie van een deel van de functionaliteiten van LIP en Enterprise. De LIP-specificatie is een rijke specificatie, die zeker met het ingebouwde extensiemechanisme voldoende rijk is om als informatiemodel onder een leerlingzorgsysteem te fungeren. Hoe die extensies er precies uit moeten zien, welke al bestaande specificaties daarvoor eventueel gebruikt kunnen worden, is nog een open vraag. Vaststaat dat het om redenen van tijdwinst en kwaliteitsborging de voorkeur verdient bestaande specificaties aan te koppelen, eventueel na aanpassing, boven zelf een specificatie te ontwikkelen. De Enterprise- en ePortfoliospecificaties zijn op zich waardevol, maar voegen niets toe waar het gaat om de ontwikkeling van een informatiemodel voor een leerlingzorgsysteem (al zijn het grotere beeld van de ontwikkeling van informatiesystemen voor scholen wel relevant).

25


ELDvo lijkt een toepassingsprofiel van de LIP te worden, de details ervan liggen nog niet vast. De definitieve versie wordt niet eerder verwacht dan eind 2008, al zijn scholen, waaronder het Sint-Bernardinuscollege, inmiddels aan het experimenteren. De DOD valt op doordat in zijn informatiemodel als enige expliciet zorggegevens kunnen worden opgenomen; bij de andere kan dat alleen via extensies (namespacing), wat de kans op verschillen in interpretaties weer groter maakt. De DOD is helaas geen open standaard en wordt in december 2006 gepubliceerd. Het ‘functioneel ontwerp LeerlingvolgBegeleidingsSysteem’ ten slotte volgt een eigen weg omdat men hiermee probeert niet alleen vanuit het perspectief van een informatiemodel te kijken, maar van een softwareapplicatie voor leerlingenzorg en – registratie. Beperken we ons tot alleen het informatiemodel, dan valt op dat het niet zonder meer in te passen valt in een van de genoemde informatiemodellen, al was het maar omdat het aspect zorg veel aandacht krijgt. Dat maakt het overigens een waardevol startpunt voor het uitwerken van toepassingsprofielen voor de LIP. Een ander waardevol element van het document is de aanzet die gegeven is tot het uitwerken van workflows.

26


4

Aanbevelingen en plan van aanpak

In dit hoofdstuk beargumenteren we een aantal aanbevelingen met betrekking tot te adopteren standaarden en uitwisselingarchitecturen. Vervolgens werken we een summier plan van aanpak uit voor een geschikte organisatorische inbedding van de implementatie van deze aanbevelingen.

4.1

Aanbevelingen

Aanbeveling 1: Sluit aan bij proefimpleme ntaties van ELDvo en werk voor de korte termijn m et het DOD. Schakel daarna over op het ELDvo zo gauw dat mogelijk is, dat wil zegg en zo gauw het beschikbaar is en de gebruikte softwarepakketten het ondersteun en. Omdat op termijn op het gebied van administratieve software internationale consolidatie van systemen te verwachten is, is aansluiting bij internationale, lees op IMS LIP gebaseerde, specificaties verstandig. Dat maken de EDEX en waarschijnlijk ook de DOD onaantrekkelijk. Bovendien is de LIP (en daarmee naar verwachting ELDvo) een rijke en uitbreidbare standaard waardoor hij goed aanpasbaar is aan specifieke gebruikerswensen. Omdat te verwachten valt dat ELDvo in Nederland veel gebruikt zal worden, is het evenmin verstandig nu te besluiten zelf een specificatie te ontwikkelen. Een complicatie is dat de ELDvo nu nog niet beschikbaar is, alleen in concept. Een andere complicatie is dat de DOD een concurrerende standaard is, niet waarschijnlijk om reden van de superioriteit van het informatiemodel maar omdat het standaard is die de ontwikkelaars van de drie gebruikte administratieve systemen geïmplementeerd hebben. De DOD zal volgens de Vereniging DOD in december 2006 gepubliceerd worden. Dan zal

27


het nog enige tijd (tot eind 2007?) duren voordat de leveranciers die het DOD ontwikkeld hebben hun software hebben aangepast, maar vanaf dat moment kunnen gegevensbestanden via het DOD worden uitgewisseld. Op de relatief korte termijn biedt dat dus een oplossing voor de uitwisselingsbehoefte. Vanaf eind 2008 is de ELDvo-specificatie beschikbaar. De ontwikkelaars van administratieve software zullen dan niet om het ELDvo heen kunnen. Daarvoor zijn een paar redenen. De eerste is dat hun klanten zullen vragen naar compatibiliteit ermee, eenvoudigweg omdat het ELDvo beschikbaar is. Een tweede reden is dat de concurrentie tussen administratieve pakketten zal verhevigen, nationaal en internationaal, naarmate de markt voor administratieve onderwijssoftware rijper wordt. Klanten zullen om meer functionaliteiten vragen, bijvoorbeeld met betrekking tot de mogelijkheid te koppelen aan andere onderwijssoftware, bijvoorbeeld leermanagementsystemen (elektronische leeromgevingen). Schoolbesturen zullen één administratief pakket voor grote aantallen scholen en leerlingen willen, wat hoge eisen stelt aan de stabiliteit, schaalbaarheid en veiligheid van dergelijke pakketten. Alleen relatief grote spelers zullen zich kunnen handhaven. Nederlandse leveranciers zullen dus moeten concurreren met buitenlandse leveranciers, moeten gaan samenwerken en zelf actief worden op buitenlandse markten om zich te kunnen handhaven. Kader 1: De markt voor administratieve schoolsoftware

De economie van (administratieve) schoolsoftware wordt ernstig beperkt door de relatief geringe omvang van de markt. Er zijn in Nederland ongeveer 7600 basisscholen (inclusief sbo, so en vso) die een 'inkoopkracht voor ICT' vertegenwoordigen van circa € 350 miljoen. (Dit bedrag is 2,5 maal zo hoog als de normatieve ICT-component in de lumpsum vergoeding van OCW; het verschil wordt aangevuld uit fondsen, vrijwillige ouderbijdragen enzovoorts) Door schaalvergroting is het aantal scholen voor VO teruggelopen tot circa 500 nu. Deze scholen vertegenwoordigen een 'inkoopkracht voor ICT' van circa € 550 miljoen. Van deze middelen wordt het overgrote deel besteed aan (beheer

28


van) infrastructuur. Aan administratieve software (roostering, school- & personeelsadministratie, leerlingvolgsysteem) wordt naar schatting € 6,- per leerling uitgegeven. Dit leidt tot een totale omvang van circa € 16 miljoen (zie CBS Statline en de Onderwijsinspectie). Een markt van een dergelijke omvang is niet bijzonder groot, zeker niet als bedacht wordt dat software regelmatig moet worden aangepast aan nieuwe regelgeving. Er is dus sprake van een beperkt aantal leveranciers in een moeilijke markt, temeer omdat wensen van scholen niet altijd synchroon lopen. Investeringen vragen van leveranciers voor uitwisseling van zorginformatie is daarom niet eenvoudig. In plaats van te wachten op een 'shake out' van leveranciers, kiezen sommigen voor Open Source Software als (gedeeltelijke) uitweg uit deze impasse. Open Source is software waarvan de broncode vrij beschikbaar is en waaraan doorgaans door een grote gemeenschap van ontwikkelaars wordt gewerkt. Open Source Software is in veel gevallen een alternatief als de markt imperfect werkt: te lage koopkracht, doorbreken van een monopolie of niet goed gearticuleerde of sterk gedifferentieerde functionaliteit. In deze situaties is het voor leveranciers van closed source software moeilijk om rendabel in de markt aanwezig te zijn (zie OSOSS). Open Source wordt inmiddels op vrij grote schaal ingezet in het leerproces zelf, voor websites en in de infrastructuur (Linux servers); in de administratieve omgeving is Open Source vrijwel afwezig. Door te kiezen voor Open Source wordt de grens tussen de 'leverancier' (de partij die desgewenst onderhoud uitvoert en aanpassingen programmeert) en de afnemer veel flexibeler en kan de noodzakelijke inzet over meer partijen en personen worden verdeeld. Open Source maakt doorgaans ook aanzienlijk beter gebruik van open standaarden. In Nederland is op initiatief van de Gemeente Groningen een leerlingvolgsysteem ontwikkeld; in het buitenland zijn meerdere geslaagde voorbeelden van open source-administratieve software voor scholen te vinden (zie Moyle, 2004; Vuorikari, 2004).

Om op de binnen- en buitenlandse markt te kunnen blijven meedoen, is ondersteuning van internationale standaarden zoals de LIP (en dus in Nederland ELDvo) een noodzaak zijn (zie kader 1 voor een alternatieve strategie). Een derde reden waarom men niet om de ELDvo heen kan, is dat het onderhouden van een specificatie een kostbare aangelegenheid is: wensen van gebruikers ontwikkelen zich en maken voortdurend aanpassingen van het informatiemodel en de binding noodzakelijk. Adoptie van het ELDvo betekent dat die kosten kunnen worden gedeeld met anderen.

29


Dit brengt ons tot de slotsom dat huidige Nederlandse ontwikkelaars van administratieve software de LIP en ELDvo wel zullen moeten gaan ondersteunen. Druk van scholen helpt om het moment waarop dat gebeurt zo vroeg mogelijk na 2008 te laten vallen. Druk kan worden uitgeoefend door aan proefimplementaties van ELDvo mee te doen zoals het Bernardinuscollege al doet - en door, liefst samen met anderen, (zorg)modules voor het ELDvo te ontwikkelen, bijvoorbeeld op basis van ‘het functioneel ontwerp LeerlingBegeleidingsSysteem’. Die druk zal ook nodig zijn om het perspectief dat dat functioneel ontwerp biedt, desnoods via uitbreidingen op ELDvo implementeerbaar te krijgen. Aanbeveling 2: O ntwikkel gereedschappen waarme e e en eenvoudig e berichtenstandaard snel kan worden g eïmplem ente erd. Zorg er daarna voor dat zo snel mogelijk de leveranciers van de le erlingregistratiesoftware berichtenuitwisseling op basis van webservices (in een decentrale architectuur) ondersteun en. Het is belangrijk leveranciers van systemen en instellingen in staat te stellen snel berichten volgens de standaard uit te wisselen, ook al zou dat in eerste instantie semigeautomatiseerd verlopen (bijvoorbeeld via e-mail of een dropbox). Ofschoon scholen voor de implementatie hiervan afhankelijk zijn van de leveranciers van de administratieve softwarepakketten, is het in verband met de toekomstvastheid en flexibiliteit van hun bedrijfsvoering van belang erop aan te dringen dat men moderne technologieën en architecturen gebruikt. Het opzetten van uitwisseling via e-mailboodschappen is alleen voor de korte termijn acceptabel. Er zijn veel handmatige handelingen nodig die niet alleen kostbaar zijn, maar ook een bron van fouten vormen. Het is daarom van belang dat scholen zo snel mogelijk ervaring opdoen met uitwisseling via een eenvoudige berichtenstandaard. Het heeft de voorkeur de uitwisseling in de vorm van webservices te implementeren (zie kader 2).

30


Hiermee kan overigens al worden begonnen in de fase waarin de uit te wisselen gegevens nog gebaseerd zijn op het informatiemodel van de DOD. Wat wordt uitgewisseld staat namelijk los van de manier waarop softwaresystemen met elkaar communiceren over hoe er wordt uitgewisseld. Als bijvoorbeeld wordt gewerkt met IMS Content Packages dan zien uit te wisselen pakketje eruit als zip-files met een gestandaardiseerde ‘pakbrief’ (manifest) die de inhoud beschrijf. Ten slotte is automatische – dat wil zeggen niet handmatige – uitwisseling vereist om horizontale en verticale analyses op de beschikbare gegevens uit te voeren, hetgeen praktisch onuitvoerbaar is. Kader 2: Webservices

Een technologie die voor de uitwisseling van berichten zoals beschreven ontworpen is, is die van de 'webservices'. De W3C definieert een webservice als een 'software system designed to support interoperable machine-to-machine interaction over a network' (W3C; Wikipedia). In het kort houdt dit in dat softwareapplicaties een overeengekomen repertoire aan typen berichten kan ontvangen, waarmee de interne werking van de applicatie beïnvloed wordt, en een overeengekomen repertoire aan typen berichten kan uitsturen, waarmee zij de werking van andere applicaties kan beïnvloeden; en verder dat er een afspraak bestaat over hoe die berichten verpakt en via het netwerk verstuurd worden. Versturing vindt vrijwel altijd plaats via het Internet. Dat heeft als voordeel dat een verbinding in vrijwel alle gevallen beschikbaar is, maar ook vooral dat van alle ontwikkelingen op het gebied van beveiliging van het berichtenverkeer, bijvoorbeeld met behulp van erkende beveiligingscertificaten, gebruik kan worden gemaakt.

Aanbeveling 3: W erk het functione el ontwerp LeerlingBegele idingsSystee m o m tot in UML geformule erde use cases, een conceptue el model en, desg ewenst, interactie- en activiteitendiagramm en. Als de deskundigheid daarvoor niet intern aa nwezig is, huur die dan in. Gebruik de UML-diagramm en om aa n de leveranciers van

31


de in de regio gebruikte registratiesoftware g ezam enlijk eisen te stellen aan de nog te ontwikkel en versies. Historisch gezien had de regio een voorsprong bij het denken over de problematiek van het uitwisselen van leerlinggegevens en bij het formuleren van de wens te komen tot een integraal, regionaal uitwisselingssysteem daarvoor. Die voorsprong is door mondiale (IMS LIP) en landelijke ontwikkelingen (DOD, ELDvo) inmiddels teniet gedaan. Omdat te verwachten valt dat softwareontwikkelaars zich bij de mondiale en landelijke ontwikkelingen zullen aansluiten (zie kader 1) is de enige verstandige actie nu te wachten op het uitkristalliseren van de ELDvo evenals te wachten op de aanpassingen die leveranciers zullen aanbrengen in hun software (zie aanbeveling 1). Kader 3: UML

UML, de Unified Modelling Language, is een gestandaardiseerde taal om grafische modellen te tekenen voor het ontwikkelen van (object-georiënteeerde) softwaresystemen (zie Fowler, 1999). Usecases zijn vaak het startpunt en worden gebruikt om te beschrijven op welke manieren een gebruiker het systeem wil gebruiken. Elke use-case kent een aantal scenario’s, alternatieve manieren waarop een use-case ‘verloopt’. Invoeren van de gegevens van een leerling is een use case, muteren van die gegevens een andere. De use-case ‘muteren’ kent verschillende varianten, afhankelijk van de gegevens die men wil muteren. Zo kunnen rechten verbonden zijn aan het muteren van bepaalde gegevens, die dan in het desbetreffende scenario beschreven moeten worden. Het conceptueel model beschrijft de onderdelen van de software die nodig zijn om de use-cases te implementeren. Dit conceptuele model wordt in een aantal stappen omgezet in programmacode. Als bijvoorbeeld iemands rechten gecontroleerd moeten worden om te weten of hij of zij een bepaalde mutatie mag uitvoeren, is er code nodig die deze controle uitvoert. In het conceptueel model wordt dat bijvoorbeeld omschreven als ‘rechtencontroleur’. Ten slotte zouden ook nog interactiediagrammen en/of activiteitendiagrammen kunnen worden ontwikkeld. De eerste beschrijven voor elk van de use cases de manier waarop een gebruiker met de

32


software interacties aangaat, de tweede de opeenvolging van toestanden die het softwaresysteem doorloopt als gevolg van interacties met gebruikers of in reactie op interne triggers. Er bestaan verschillende processen volgens welke UML diagrammen ontwikkeld worden. Omdat het hier om relatief eenvoudige software gaat, volstaat waarschijnlijk een relatief licht proces. Fowler (1999) beschrijft een variant op het Rational Unified Process, die waarschijnlijk adequaat is.

Door deze ontwikkelingen is nog een tweede probleem ontstaan, namelijk dat het functioneel ontwerp LeerlingBegeleidingsSysteem enigszins in de lucht is komen te hangen. Het functioneel ontwerp is vooral een ontwerp van een systeem voor de opslag van leerlinggegevens. Het beschrijft zowel een structuur voor de opslag van de gegevens in een database (informatiemodel). Maar het beschrijft ook de eisen die gesteld moeten worden aan de (client)software voor het inbrengen en muteren van de gegevens. Enerzijds is die beschrijving in sommige opzichten zo uitgebreid dat het er de ambitie uit lijkt te spreken zelf client-software te willen ontwikkelen - zo worden bijvoorbeeld elementen van het human-computer interface beschreven en wordt aangegeven van welk technisch platform de software gebruik maken. Anderzijds wil men dat het regionaal integraal zorgsysteem zich bedient van de systemen, die de scholen al in gebruik hebben. Het functioneel ontwerp hinkt daardoor op twee gedachten. In lijn met wat de eerder geformuleerde aanbevelingen, adviseren we het functioneel model te gebruiken, en waar het tekort schiet zelfs aan te vullen, om maximale druk uit te oefenen op de leveranciers van de nu gebruikte software hun pakketten zodanig aan te passen dat ze passen binnen de ambities en doelstellingen van het samenwerkingverband. Die doelstelling kan het best bereikt worden door de leveranciers aan te spreken op een manier die misverstanden uitsluit. Dat kan door aan te sluiten bij moderne opvattingen over softwareontwikkeling. Enerzijds wat betreft de manier waarop de eisen geformuleerd worden. Anderzijds wat betreft het proces volgens welke tot de formulering van die eisen gekomen wordt. We bevelen aan de Unified Modelling Language te gebruiken om de eisen te formuleren en als ontwikkelproces de lichtgewicht variant van het Rational Unified Process die Fowler (1999) beschreven heeft (zie kader 3). Bij het hanteren van deze taal

33


en dit ontwikkelproces zal blijken dat het functioneel ontwerp LeerlingBegeleidingsSysteem in een aantal opzichten aanvulling behoeft. De beschrijvingen van de use case (groepen van gebruiksscenario's van de software) zijn nog te onvolledig uitgewerkt en er ontbreken klassediagrammen, zowel op het niveau van het conceptueel model als de meer technische modellen die daarop worden gebouwd). Voor het uitwerken van een ontwerp is het niet nodig in zoveel detail te gaan dat de software daadwerkelijk gebouwd zou kunnen worden, dat is immers de verantwoordelijkheid van de leveranciers. Het gaat er slechts om de gebruikerseisen te vertalen in een taal die voor de softwareontwikkelende leveranciers niet mis te verstaan is. Als UML-deskundigheid niet aanwezig is, verdient het aanbeveling een UMLdeskundige in te huren die samen met gebruikers ten minste een overzicht van use cases en een conceptueel model ontwikkelt. Omdat het functioneel model ook ingaat om de interactie van de gebruiker met het systeem, zouden daaraan nog interactiediagrammen kunnen worden toegevoegd. De volgende werkwijze zou gevolgd kunnen worden: de UML-deskundige maakt een voorzet op basis van het functioneel ontwerp; deze voorzet wordt doorgesproken en bijgesteld in gesprekken met zowel personen met een technische achtergrond, die voor implementatie en onderhoud verantwoordelijk zijn, als personen voor wie het beheer van leerlingzorggegevens de kerntaak is. Aanbeveling 4: O ntwikkel binnen het raamwerk van het ELDvo aanvullende modules om aan schoolen regiospecifiek e wensen teg emo et te ko men, in elk geval op het gebied van de le erlingenzorg. Informatiemodel en binding zullen aanvankelijk gebaseerd zijn op de DOD, op termijn op ELDvo. Zoals boven besproken is ELDvo een raamwerk dat is gebaseerd op de LIP en dat om die reden ruimte biedt tot aanpassing en precisering (ontwikkelen van een toepassingsprofiel, inpassing van extra modules via namespacing). Dat zal niet alleen

34


nodig zijn om zorginformatie te kunnen opslaan en uitwisselen, maar ook om aan andere eisen die specifiek zij voor de regio te voldoen. Die eisen kunnen bestaan uit bijvoorbeeld - het verplicht stellen van de invulling van elementen (velden) waarvoor dat volgens de ELDvo facultatief is; - het ontwikkelen van vocabulaires waaruit verplicht een keuze gemaakt moet worden bij de invulling van een element; - of het ontwikkelen van compleet nieuwe modules, bijvoorbeeld voor zorginformatie. Bij het opstellen van dit regiospecifieke toepassingsprofiel moeten vooral gebruikers betrokken worden, omdat zij als enigen de behoeften kunnen verwoorden over welke gegevens moeten worden opgeslagen en uitgewisseld. Hiervoor voldoet iemand met affiniteit voor techniek. Het functioneel ontwerp LeerlingBegeleidingsSysteem kan dienen als uitgangspunt voor deze exercitie. De technische vertaling van de bevindingen naar een aanvulling en precisering van het informatiemodel en binding moet vervolgens gedaan worden door een technisch onderlegd persoon die instaat is XML-schema’s te lezen en schrijven. Aanbeveling 5: Doe onderzo ek naar de mog elijkheid van analyse van de decentraal opgeslag en gegevens door gebruik te maken van topic maps. Wanneer bovenstaande aanbevelingen zijn uitgevoerd, heeft ieder van de partners in het samenwerkingsverband de beschikking over een systeem dat geschikt is om leerlinggegevens op te slaan en uit te wisselen op een manier die zowel conform internationale en nationale standaarden is als aan de regiospecifieke wensen tegemoet komt. Maar een analyse op aggregaten van leerlinggegevens is nog niet gerealiseerd. Door de decentrale architectuur en het gebruik van diverse pakketten cliënt software, is zo’n analyse zelf lastiger geworden. Daarom bevelen we aan onderzoek te doen naar het aanbrengen van een extra ‘laag’ in de gegevens in de vorm van topic maps, waardoor de gewenste analyses uitvoerbaar zouden moeten zijn zonder dat de privacy ervan in gevaar komt.

35


4.2

Plan van aanpak

Wij bevelen aan bij het realiseren van de aanbevelingen te werken volgens een plateauplanning. Dit biedt een groot aantal voordelen: - partijen krijgen de tijd om te wennen aan de gemaakte afspraken; - de bestaande (internationale) standaarden kunnen rijpen; - de risico’s voor de technische implementatie zijn beter te beheersen. In stappen kan worden gewerkt aan het inlossen van de ultieme ambitie, namelijk dat alle partijen - die geautoriseerd zijn om een inspanning te leveren voor de zorg aan leerlingen - beschikken over de operationele en stuurinformatie om deze taak goed uit te kunnen voeren. We onderscheiden de volgende vier stappen: 1. Korte termijn (direct): organiseer een minimale uitwisseling op basis van het DOD Experimenteer met uitwisseling van gegevens op basis van het DOD. Start de uitwisseling in eerste instantie via e-mail; dit geeft partijen de mogelijkheid hun werkprocessen stapsgewijs aan te passen en schept ruimte om parallel uitwisseling via webservices te ontwikkelen, waardoor de uitwisseling in hoge mate geautomatiseerd, zonder menselijke tussenkomst, kan verlopen. Betrek de leveranciers hierbij, zodat zij kennis kunnen nemen van de ambities die in de regio leven, te weten op webservices gebaseerde uitwisseling op basis van een regionaal toepassingsprofiel op de ELDvo-standaard. 2. Middellange termijn (binnen één jaar): werk zowel aan het regiospecifieke toepassingsprofiel op de ELDvo als aan het gezamenlijke pakket van eisen waaraan de software in de nabije toekomst zal moeten voldoen. Start onderzoek naar het werken met topic maps. Houdt leveranciers van de ontwikkelingen op de hoogte. Zij moeten de gelegenheid krijgen hun software geleidelijk aan te passen, ook al zijn de ambities van de regio hoog gesteld. Ideaal is is als de leveranciers het aanpassen van de software volgens de

36


regionale specificaties zien als een kans de concurrentiekracht van hun software te vergroten. Voor de moderne, op webservices gebouwde systemen zal aanpassing niet zo’n grote stap zijn, voor oudere systemen zal dat anders liggen. Het is niet uitgesloten dat voor sommige leveranciers de stap te groot is. 3. Langere termijn: schroef de ambities verder op. Voortschrijdend inzicht of veranderde wettelijke eisen maken dat het toepassingsprofiel gewijzigd zal worden. Werk verschillende ‘rondes’ aan de aanpassing van het profiel, voer daarbij zorgvuldig versiebeheer. In deze fase zal ook afstemming met het Kader integraal indiceren (commissie Van Eijck) moeten plaatsvinden. Nu ook kan onderzoek naar de implementatie van topic maps ten behoeven van monitoring en analyse plaatsvinden.

37


Appendix 1

Opdrachtformulering Regionaal Integraal Leerlingzorgsysteem Opdracht: het lectoraat ‘Educatieve Functies van ICT’ verbonden aan de Fontys Lerarenopleiding Sittard zal, onder leiding van de aan dit lectoraat verbonden lector dr. Peter B. Sloep: 1. Een aantal gesprekken voeren over de opzet en invoering van een gezamenlijk platform voor transport en aggregatie van leerlinginformatie (integraal leerlingzorgsysteem) met vertegenwoordigers van de betrokken onderwijsinstellingen (INNOVO, LVO, Movare, OSB, SPOPeO) en van betrokken zorginstellingen (peuterspeelzaalwerk, bureaus Jeugdzorg), regionaal begrensd tot de Parkstadgemeenten. Daarbij zal er onderscheid gemaakt worden tussen een lijst van absoluut noodzakelijke gesprekken en wenselijke gesprekken; die laatste worden gehouden voor zover de tijd het toelaat of de opdrachtgever het, ondanks tijdoverschrijding, wenselijk vindt. Gesproken zal worden met vertegenwoordigers van in elk geval INNOVO, MOVARE, OSB, LVO, bureau Voortijdig Schoolverlaten, bureau Jeugd en Gezondheidszorg. 2. In globale termen verslag doen van deze gesprekken, maar alleen voor zover de resultaten ervan van invloed zijn geweest op keuzes die gemaakt zijn onder 3 en 4; het verslag wordt opgenomen in de onder 3 en 4 genoemde rapporten. 3. In de vorm van een rapport een voorstel doen voor een informatiemodel voor de gegevensuitwisseling (beschrijving van relevante velden en categorieën daarvan, van vereist datatype per veld, van een of meer karakteristieke voorbeelden, en of een veld verplicht of facultatief is), gebaseerd voor zover mogelijk op bestaande internationale en nationale specificaties en normen zoals diverse IMS-specificaties en hierop gebaseerde toepassingsprofielen zoals dat van Kennisnet/ICT op school, het digitaal overdrachtsdossier, het ELDvo-profiel. 4. In de vorm van een rapport een voorstel doen voor een softwarearchitectuur volgens welke de gegevens betrouwbaar en efficiënt uitgewisseld kunnen worden, rekening houdend met bij betrokkenen in gebruik zijnde systemen en gewenste workflows.

38


In de rapporten zal geen aandacht worden besteed aan de juridische aspecten (privacy- en database-wetgeving) van het in gebruik nemen van het systeem, aan de organisatorische aspecten rond de implementatie (innovatiediffusie) ervan, aan aspecten van de te gebruiken ontwikkelingsplatformen, en aan een geschikte (XML-) binding voor het informatiemodel. De werkzaamheden zullen in totaal 20 werkdagen beslaan, waarbij met meer- en minderwerk rekening zal worden gehouden. De gesprekken zullen zo veel mogelijk worden gevoerd in de periode tussen 1 juni en 10 juli. Er zal naar aanleiding daarvan een conceptrapport worden opgeleverd dat ter becommentariëring aan de leden van de stuurgroep en aan de gesprekspartner zal worden voorgelegd. Aan de hand van het commentaar zal dan zo spoedig mogelijk maar niet later dan 30 september het definitieve rapport worden opgeleverd. De rapporten zullen zowel als pdf-bestand als op papier in drievoud aan de opdrachtgever worden aangeleverd. De auteursrechten berusten bij het lectoraat, maar de opdrachtgever heeft het niet herroepbare recht de rapporten naar eigen inzicht te vermenigvuldigen en verspreiden. Namens de stuurgroep zal de heer Frank Schins als contactpersoon optreden.

39


Appendix 2

Beknopt verslag van gevoerde gesprekken Hieronder volgt, in chronologische volgorde, een overzicht van beknopte inhouden van gevoerde gesprekken. 

Gesprek met Joep Valk, Martin Relouw, Vera Heijenraths, Cees Rau, Paul Willemsen en Alois Daamen, osb-lvo, 8 juni 2006. Aan het begin van het gesprek presenteerden zij een door hun intern reeds uitgewerkt functioneel ontwerp voor een leerlingbegeleidingsysteem. Uit het gesprek werd duidelijk dat zij niet zo gelukkig zijn met de vertraging die het bouwen van hun functioneel ontwerp dreigt op te lopen, te meer daar ze al 4 jaar aan het werk zijn en behoefte hebben aan een integraal leerlingbegeleidingsysteem. Zij hebben een functioneel ontwerp geschreven dat zo geïmplementeerd kan worden. Voor hun leerlingen is het vooral van belang dat docenten in staat zijn een dossier op te bouwen bij te houden, waarbij verschillende personen intern, binnen de school, toegang hebben. Tweede prioriteit heeft horizontale uitwisseling, bijvoorbeeld voor instromers vanuit de Thermen naar het overig vo (Grotius bijvoorbeeld). Bij uitwisseling gaat het ook om onderwijskundige rapporten. Ze zijn zich bewust van de juridische problematiek, die volgt uit de database-wet en de privacy-wetgeving.  Gesprek met Leo Niessen en John Monsewije, OSB, 27 juni 2006. Men waarschuwde voor een ontwerp dat mikt op de vereniging van alle eisen van alle belanghebbenden. Dat heeft als bezwaar niet alleen dat het omvangrijk wordt, maar ook op gespannen voet kunt komen te staan met de database- en privacy-wetgeving . Een ander punt betreft de asymmetrie in belangen. Het primair onderwijs heeft geen belang bij verticale uitwisseling, enigszins bij horizontale en vooral bij een goed werkend intern, schoolspecifiek systeem (ik laat het peuterspeelzaalwerk even buiten beschouwing). Het voortgezet onderwijs heeft ook belang bij horizontale uitwisseling en

40


een goed werkend schoolspecifiek systeem, maar vooral ook bij goede verticale uitwisseling. De gemeentelijke instellingen zijn niet alleen vragende, maar zelfs bepalende partij (wetgeving) bij veel leerlingzorgaspecten. Zij zijn dus vragend en bepalend. 

Gesprek met Cees Joosen, Jos Gelissen, Peter Satijn en Leander Versleijen, Movare, 28 juni 2006 Belangrijkste conclusie is dat de ambities van Movare vooralsnog relatief beperkt zijn. Men zit midden in het proces van het invoeren van een eigen leerlingvolgsysteem – dotcomschool. Technisch is de zaak op orde, met ingang van het nieuwe schooljaar worden handleidingen gemaakt, docenten getraind, etc. De functionele wensen met betrekkelijk tot een leerlingzorgsysteem zijn vooralsnog relatief beperkt, men verwacht dat er vooral veel behoefte is aan verticale uitwisseling, door de kolom heen. Horizontale uitwisseling is veel minder belangrijk, al was het maar omdat die stroom veel kleiner zal zijn. Men verwacht regelmatig naar het volgsysteem te zullen uploaden, het nut van downloads vanuit het systeem naar dotcomschool zag men vooralsnog als beperkt. Mogelijk kwam dat doordat men verwachte importfilters te moeten schrijven voor elke naar dotcomschool aanleverende applicaties. Dat is veel werk en geeft ook een grote onderhoudsbelasting. Een belangrijke wens die in het gesprek naar voren kwam was dat het systeem een vorm van monitoring zou moeten ondersteunen, ten behoeve van de kwaliteitszorg. Dat moet vergelijkingen tussen scholen mogelijk maken, maar ook longitudinaal onderzoek (volgen van leerlingen tijdens hun hele schoolloopbaan). Zo’n functie is in een interessante omvang alleen te realiseren als leerlinggegevens geanonimiseerd kunnen worden. Ten slotte noemde men ook uitwisseling met jeugdzorg en maatschappelijk werk als wenselijk.  Overleg met Huub Schoen makers, Innovo, 29 juni 2006 Innovo heeft een duidelijke visie op de manier waarop de inzet van informatie-

41


technologie een ondersteunende functie kan hebben voor het primaire leer- en onderwijsproces. INNOVO heeft aanvankelijk gewerkt met een zelfgebouwd systeem (Lezos), inmiddels met Eduscoop. Er worden nauwe contacten onderhouden met de bouwers van Eduscoop, het Sittardse bedrijf Unilogic. Eduscoop wordt inmiddels uitgebreid gebruikt, docenten zijn getraind, het is een operationeel systeem binnen INNOVO. Hun uitgangspunt is het ‘digitaliseren van de gangbare praktijk’ binnen de scholen. Het systeem is een ‘raamwerk database-systeem’, dat op allerlei manieren aanpasbaar is. Eduscoop is leerlinggeoriënteerd en ondersteunt adaptief onderwijs, zelfs met meerdere, wisselende leerkrachten per klas. Momenteel wordt een zorgmodule ingebouwd. Voor INNOVO geldt ook dat de verticale uitwisseling, door de kolom heen, belangrijker is dan horizontale, binnen het eigen systeem. Wel zien zij het als ideaal wanneer allerlei onderwijsondersteunende en flankerende instanties direct met het systeem zouden moeten kunnen werken. Denk aan schoolartsen en schoolpsychologen. Het gesprek maakt duidelijk dat er een geweldige spanning bestaat tussen de behoefte tot een soepele uitwisseling van gegevens tussen allerlei betrokkenen en de behoefte over een systeem te beschikken (en dus ook een onderliggend informatiemodel) dat naadloos aansluit bij de specifieke pedagogisch-didactische en organisatorische opvattingen van een scholenstichting of zelfs een individuele school. Het is onmogelijk die beide doelstellingen voor elk van de partijen te maximaliseren. De oplossing is dat je strikt onderscheid maakt tussen de stichting (of school) gebonden ambities, die te maken hebben met het maximaal faciliteren van de eigen bedrijfsvoering, en de gezamenlijke ambitie. Die laatste heeft drie componenten. In volgorde van belangrijkheid a. uitwisselen van gegevens verticaal door de kolom en horizontaal tussen scholen van hetzelfde type; b. uitwisseling van gegevens tussen scholen en aanpalende instanties en organisaties; c. monitoring van kwaliteit, zowel transversaal (performance van soortgelijke scholen over zelfde tijdvak) en longitudinaal (performance van groepen leerlingen gedurende hun schoolcarrière).

42


 Gesprek met Fred Lemmens, gemeente Heerlen & Parkstad, 29 juni 2006 Fred Lemmens is namens de gemeentelijke overheid al heel lang betrokken bij pogingen zoiets als een regionaal integraal zorgsysteem op te zetten. Men heeft een hoog ambitieniveau, in de zin van een centrale database volgens een client-server-architectuur. Dit perspectief wordt vooral ingegeven door wettelijke taken die de gemeente heeft. Men ziet de leerling als het middelpunt van een invloedssferencirkel waarin behalve de ‘brede’ school ook participeren de politie en leerplichtambtenaren, het centrum jeugd en gezin, de huisarts. Tegelijk realiseert men zich dat deze ambitie, om allerlei redenen, bij scholen minder goed valt.



Gesprek met Karin Landuyt, hoofd bureau Voortijdig Schoolverlaten, en twee collega’s, 25 juli 2006. Karin en haar team zijn verantwoordelijk voor de gemeentelijke leerlingenregistratie (zij doen dat voor in totaal 8 gemeenten, Parkstad en Nuth) in verband met het bijhouden van de doorlopende schoolloopbaan, de verzuimregistratie en het voortijdig schoolverlaten (ze beheren het regionale meldpunt). Ze verwerken gegevens van zo’n 50.000 leerlingen. Voor de NAW-gegevens vertrouwen ze op de Gemeentelijke Basisadministratie, voor de overige gegevens op de informatie die de scholen verstrekken. Scholen passen hun NAW-gegevens aan op basis van wat de gemeente hun vertelt. Opvallend genoeg gebruiken scholen men geen sofinummer (onderwijsnummer) als unique identifier voor de aangeleverde bestanden, maar een combinatie van naam en geboortedatum. Privacy wordt als reden genoemd. De gegevensaanlevering nog in hoge mate nog op papier plaats. Scholen werken met Excel-bestanden, er wordt aan gewerkt om gegevens aan te leveren als Excel-bestanden; xml als format was niet bekend (maar de technische aspecten zijn in handen van een applicatiebeheerder). Voor de registratie maken ze gebruik van het pakket LL4ALL, van Centric. Centric bouwt op verzoek nieuwe modules.

43


Karin en haar team zijn geïnteresseerd in een uitwisselingsstandaard mits dat hun werk verlicht. Een probleem hierbij kan zijn dat een leerlingrecord in delen (modulen) opgesplitst waarbij verschillende partijen verantwoordelijk zijn (en dus de eigenaar zijn van de moederversie) voor verschillende modulen. NAW-gegevens komen uit de GBA, verzuimgegevens worden wekelijks (wettelijk zo geregeld) door de scholen aangeleverd, meldingen van inschrijving en uitschrijving worden door de school gedaan, etc. Verzuimmeldingen is een goed voorbeeld van wat je via een fatsoenlijk informatiemodel kan regelen (dit hebben we besproken). De school beschikt over gegevens over aan- en afwezigheid op het niveau van lesuren. Strikt genomen moet alles gemeld worden, in de praktijk doet de leerplichtambtenaar alleen wat met sommige gegevens. Hij pleegt pas een interventie wanneer er bijvoorbeeld een aantal achtereenvolgende weken substantieel verzuimd is. Nu zit het bureau gegevens te turven om te beslissen wanneer dat het geval is. Je kunt je voorstellen dat de school wekelijks geaggregeerde gegevens levert (bijvoorbeeld het aantal uren of een slimmere maat als de frequentieverdeling van uren over dagen en het totaal aantal lesuren zodat je ook het percentage uren dat gemist is kunt berekenen en patronen kunt herkennen). De software van de school berekent die op basis van door de concièrge en docenten geleverde gegevens, de software van het leerplichtbureau geeft een waarschuwing als bepaalde criteria worden bereikt. Het informatiemodel bevat een veld ‘verzuim’. De ontologie die daarbij hoort bepaalt hoe de gegevens worden aangeleverd: uren per dag verzuimd en volgens rooster; totaal aantal verzuimde uren per week; etc. Een dergelijke vorm van uitwisseling vonden Karin en haar collega’s een aantrekkelijk perspectief. Een ander voorbeeld waar ze bij gebaat zijn, is het gebruik van het onderwijsnummer als unique identifier. Wat ten slotte opviel is hoeveel de landelijke overheid bij wet regelt en hoe weinig ze voorschrijven (hebben nagedacht) over de facilitering van de uitvoering.

44


Appendix 3

Overzicht van velden in enkele specificaties Hieronder volgt een zeer summiere opsomming van de belangrijkste categorieën en hun elementen (velden) in enkele van de genoemde specificaties. De bedoeling is niet uitputtend te zijn, maar een indruk te geven van de mogelijkheden van de desbetreffende specificatie. Voor meer details, zoals onderlinge relaties, de mogelijkheid attributen mee te geven of applicatieprofielen te maken, zie de oorspronkelijke specificaties. EDEX

Persoon, achternaam, voornamen, roepnaam, geboortedatum, geslacht, etniciteit, land van herkomst, onderwijsnummer, leerlinggewicht. School: brincode, dependence-code, leerkracht, leerling, groep, groepsnaam, jaargroep, schooljaar, instroomdatum, uitstroomdatum. Informatie over de EDEX is te verkrijgen via de NEN: www.nennorm.nl. IMS LIP

Identification: formname (vCard), name, address, contact info (timezone, latitude, longitude, telephone, email, web), demograhics (gender, placeofbirth). Goal: typename, date, priority, goal (nb: tbv subgoals). QCL: title, organisation, registrationno, level, date, description. Accessibility: language, learning preference, disability. Activity: date, status, units, learningactivityref, definition, product, testimonial, evaluation, activity (nb: tbv subactivities). Competency: exrefrecord, description. Interest: product, description. Transcript: exrefrecord, description. Affiliation: classification, affiliationid, role, organisation, date, status, affiliation (nb: tbv subaffiliations). Security Key: keyfields, fielddata, description. Relationship: tuple, description. Her en der in de LIP zitten extension-elementen, die zijn hierboven weggelaten, hetzelfde geldt voor comment-elementen. De LIP-specificatie is te downloaden vanaf de IMS website, registratie is noodzakelijk. CETIS in de UK heeft een korte brochure gemaakt.

45


DOD

School. Leerling. Verzorger. Schoolloopbaan. Overstapadvies. Zorg. Arts. Handelingsplan. Verzuim. Contact overige organisaties. LVS toets. LVS Bijlage. Scorelijst. Onderdeel. Score. Entreetoets Cito. Eindtoets groep 8. IQ test. Cijferlijst. Instrumenten LWOO-PrO. Deze gegevens zijn ontleend aan een de Cinop-publicatie Vergelijking van drie standaarden voor de uitwisseling van gegevens over leren. BRON

Persoonsgegevens, inschrijvingsgegevens, examengegevens, vakgegevens.

46


Appendix 4

Geraadpleegde en aanbevolen websites en documenten -

Anoniem (2006) Functioneel ontwerp LeerlingBegeleidingsSysteem, Heerlen: Onderwijsstichting Sint-Bernardinus en Stichting Limburgs Voortgezet Onderwijs.

-

CBS Statline .

-

CETIS .

-

EDEX .

-

ELDvo-site .

-

Fowler, M. (1999). UML Distilled: A Brief Guide to the Standard Object Modeling Language (2 ed.). Boston etc.: Addison-Wesley.

-

Informatie Beheer Groep (2005) Programma van Eisen elektronische gegevensuitwisseling BRON en VO-scholen; inschrijvingen; versie 1.8. Groningen: Informatie Beheer Groep.

-

IMS Global Learning Consortium (LIP, ePortfolio, Enterprise Services, RDCEO, Content Packaging) .

-

Kennisnet & .

-

Moyle, Kathryn (2004) Open source software and Australian school education, online publicatie education.au .

-

Onderwijsinspectie, .

-

Programma OSSOS & .

-

Rogers, E.M. (2003) Diffusion of Innovations. New York, etc.: Free Press.

47


-

Sloep, P.B. Standaardiseren van leertechnologieën, gebrek aan geld of aan moed? Column Edusite .

-

Sloep, P. B., J. Van Bruggen, et al. (2006). Innovating education with an educational modelling language: two case-studies. Innovations in Education and Teaching International, 43(3): 291-301.

-

Tonneman, J. Van Hoek, F. (2005) Vegelijking van drie standaarden voor de uitwisseling van gegevens over leren. Den Bosch: Cinop. < http://www.eldvo.nl/cms/cm/docs/Standaardenvergelijking _BRON_DOD_IMS.pdf>

-

Vereniging Digitaal Overdrachts Dossier www.vdod.nl. Van der Vlist, E. (2002) XML Schema. Sebastopol,CA: O’Reilly & Associates.

-

Vuorikari, Riina (2004) Why Europe Needs Free and Open Source Software and Content in Schools, online publicatie, European Schoolnet .

-

W3C Webservices werkgroep

-

Wikipedia over Webservices

48

Naar een regionaal integraal leerlingzorgsysteem Parkstad Limburg

Recommend Documents