Curriculumontwerp verdient eigen gereedschap
Wat willen we dat studenten leren? Waar bouwen we dat op? Welke opdracht of toets laat zien of dat lukt? Dat zijn ontwerpvragen. Een lijst met cursusnamen en studiepunten geeft daar nog geen antwoord op.
In Curriculum Playground breng je leerresultaten, onderwijsactiviteiten, toetsing en planning bij elkaar. Je groepeert onderdelen, onderzoekt relaties en bespreekt met het team wat je wilt veranderen. Het inhoudelijke oordeel blijft bij de onderwijsprofessionals.
Registratie is een onderdeel van dat werk. De onderbouwing, volgorde en samenhang ontstaan ervoor en worden daarna opnieuw onderzocht. Wij vinden dat de digitale ondersteuning die hele beweging moet dienen.
Van ontwerp naar uitvoering, zonder steeds opnieuw te beginnen
Een docententeam heeft ruimte nodig om een ontwerp te veranderen. Een planner of onderwijsadministratie moet juist weten welke versie gebruikt mag worden. Die verschillende behoeften horen in hetzelfde proces thuis.
Ontwerpen
Het team verbindt doelen, onderwijs en toetsing.
Vaststellen
De instelling bepaalt wat gereed is voor gebruik.
Uitwisselen
Afgesproken gegevens gaan naar de juiste systemen.
Uitvoeren
Ondersteuners organiseren het onderwijs met die informatie.
Verbeteren
Ervaringen uit de uitvoering voeden het volgende ontwerp.
Dit is onze visie op de keten. Het schema is geen overzicht van al beschikbare automatische koppelingen.
Een module verhuist naar een andere periode
Stel dat een opleiding een module later in het programma wil aanbieden. Het team onderzoekt eerst wat dat betekent voor de voorbereiding van studenten en de toetsing. Daarna wordt de nieuwe versie vastgesteld. De planning en studiegids hebben vervolgens diezelfde vastgestelde periode nodig.
Onze inzet: de keuze één keer zorgvuldig uitwerken en daarna gecontroleerd hergebruiken. Zo hoeven ondersteuning en docenten geen losse Excel-versies en tekstbestanden met elkaar te blijven vergelijken.
Waarom we kiezen voor open standaarden
Onderwijsinformatie moet niet vastzitten in één toepassing. Een instelling moet kunnen bepalen waar zij ontwerpt, waar zij het aanbod publiceert en waarmee zij het onderwijs organiseert. Een gedeelde standaard biedt afspraken waarmee systemen informatie op een herkenbare manier uitwisselen.
OEAPI, bekend als OOAPI
De Open Education API (OEAPI), voorheen Open Onderwijs API (OOAPI), beschrijft afspraken voor de uitwisseling van onderwijsdata. Denk aan programma’s, cursussen en onderdelen daarvan. De ondersteunde versie en het toepassingsprofiel bepalen welke gegevens en handelingen daarbij horen.
Dat maakt de standaard voor ons relevant: het ontwerp kan in een daarvoor geschikte omgeving ontstaan, terwijl andere toepassingen afgesproken informatie gebruiken. Open betekent hier een gedeelde specificatie, niet dat curriculum- of studentgegevens voor iedereen toegankelijk worden.
De aansluiting op Npuls en OKX
Binnen Npuls krijgt het ontsluiten van onderwijsaanbod nadrukkelijk aandacht. OKX, Onderwijs Koppelingen, richt zich op uitwisseling tussen onder meer onderwijscatalogi, studentinformatiesystemen, leeromgevingen en planning. Het bouwt voort op het werk rond OKE, Onderwijs Koppelingen Examinering.
Die beweging past bij onze visie. We willen dat het ontwerpwerk van teams goed aansluit op de informatieketen. We volgen de ontwikkeling van deze afspraken en nemen ze mee in de uitwerking met onze samenwerkingspartners.
Een API alleen maakt nog geen werkend proces
Een technisch bericht kan correct zijn en toch de verkeerde versie of betekenis overbrengen. Daarom horen bij een koppeling ook afspraken tussen onderwijs, informatiemanagement en ondersteuning.
- Betekenis en structuur
- Wat bedoelen we met dezelfde gegevens?
Spreek af wat een opleiding, module of onderwijseenheid is en welke relaties nodig zijn. De eigen woorden van een team moeten zorgvuldig aansluiten op het afgesproken datamodel.
- Bron en richting
- Wie beheert welk gegeven?
Bepaal per gegeven het leidende systeem, de eigenaar en de uitwisselrichting. Eén bronsysteem voor álle informatie is niet het doel; tegenstrijdige bronnen voor hetzelfde gegeven voorkomen wel.
- Identiteit en versie
- Over welk onderdeel en welke versie gaat het?
Gebruik stabiele identificaties en leg de relevante opleiding, periode, cohort en geldigheid vast. Een naamswijziging mag geen nieuw onderdeel suggereren; een nieuw curriculum mag het vorige niet ongemerkt vervangen.
- Status en vrijgave
- Wanneer mag informatie verder?
Maak expliciet welke informatie nog een ontwerp is en welke versie is vastgesteld. Spreek af wie de overdracht vrijgeeft en wanneer een ontvangend systeem een wijziging verwerkt.
- Toegang en gegevens
- Wat is echt nodig voor deze uitwisseling?
Beperk gegevens en rechten tot het afgesproken doel. Curriculumgegevens uitwisselen betekent niet dat ook studentgegevens gedeeld moeten worden. Een open standaard maakt gegevens niet openbaar.
- Controle en herstel
- Hoe weten we of de overdracht klopt?
Controleer verplichte velden en relaties. Maak zichtbaar wat is ontvangen, wat is afgewezen en wie dat herstelt. Leg ook vast hoe je een overdracht opnieuw uitvoert zonder onbedoelde dubbelen.
Dit zijn ontwerp- en acceptatiecriteria voor een gegevensstroom. Welke gegevens CP aanlevert, welke informatie uit een ander systeem komt en hoe vaak er wordt uitgewisseld, spreken we per toepassing af. De aanwezigheid van een standaard bewijst nog geen werkende koppeling.
In ontwikkeling
Samen met CACI/Osiris
We werken samen met CACI, de organisatie achter Osiris, aan het werkbaar maken van de OOAPI-koppeling. Curriculum Playground brengt de ontwerpomgeving voor onderwijsteams in; Osiris ondersteunt de onderwijslogistieke en administratieve kant. CACI heeft de samenwerking ook publiek toegelicht.
Het doel is dat vastgestelde informatie uit het curriculumontwerp bruikbaar wordt in het vervolgproces, met minder handmatige overdracht. Deze koppeling is in ontwikkeling. Beschikbaarheid, gegevensstromen, ondersteunde versie en benodigde inrichting stemmen we per instelling af voordat we een aansluiting toezeggen.
Stand van deze toelichting: .
Eerst een betrouwbare gegevensstroom, dan verder
Onze vervolgrichting is om van een concrete onderwijsvraag naar een afgebakende, controleerbare uitwisseling te werken. De precieze planning spreken we met betrokken partijen af.
Het overdrachtsmoment kiezen
Bepalen welke informatie een team oplevert, wie die nodig heeft en welke handmatige stap daarmee kan vervallen.
Gegevens en afspraken toetsen
De betekenis, identificaties, versies en verantwoordelijkheden samen uitwerken. Ook testen wat er gebeurt bij ontbrekende of gewijzigde informatie.
De hele werkwijze beproeven
Met ontwerpers én ondersteuners controleren of informatie op de juiste plek aankomt en begrijpelijk blijft. Een werkend technisch bericht is daarbij één van de controles.
Verantwoord uitbreiden
Pas daarna verbreden naar andere gegevens en toepassingen. Documenteren wat wordt ondersteund, welke inrichting nodig is en wie het beheer en herstel oppakt.
Veelgestelde vragen
Wat is het verschil tussen OOAPI en OEAPI?
OOAPI staat voor Open Onderwijs API. De standaard is hernoemd naar Open Education API, afgekort OEAPI. Je komt beide namen nog tegen. Bij een koppeling moet daarnaast worden afgesproken welke versie en welk toepassingsprofiel de systemen ondersteunen.
Is de koppeling tussen Curriculum Playground en Osiris al overal beschikbaar?
De koppeling is in ontwikkeling. We werken samen met CACI aan het werkbaar maken ervan. Per instelling bevestigen we beschikbaarheid, gegevensstromen, versie, inrichting en voorwaarden voordat we een koppeling toezeggen.
Kun je al met curriculumontwerp beginnen zonder een koppeling?
Ja. In Curriculum Playground kun je doelen, onderwijsactiviteiten, toetsen en planning bij elkaar brengen en met je team verder uitwerken. Spreek daarbij alvast af welke informatie later elders nodig is. Een bestandsexport en een automatische systeemkoppeling zijn verschillende dingen.
Waar schuurt de overdracht bij jullie?
Neem één curriculumonderdeel en de bijbehorende documenten of systemen als vertrekpunt. Dan bekijken we samen wat het team nodig heeft om te ontwerpen en welke informatie daarna waar nodig is.
Bespreek jullie gegevensuitwisseling