Declaris — casusdossier bij deze eerste module

Leeswijzer en casusstatus

Alle organisaties, systemen, personen, bedragen en gebeurtenissen in dit dossier zijn fictieve onderwijsgegevens. De regels zijn expliciete ontwerpkeuzes voor de casus; zij beschrijven geen echte zorgadministratie en zijn geen juridische standaard. We rekenen niet met btw, verzekeringsvergoedingen, creditnota's of rente. Die vereenvoudiging geldt uitsluitend voor de rekenopdrachten. Bedragen in het JSON-bestand zijn gehele eurocenten.

Gebruik dit dossier naast de lessen. Een verwijzing naar A1–A10 gaat naar de onderstaande modellen en tabellen. De gevulde modellen en tabellen zijn uitgewerkte voorbeelden; de losse oefening per les vraagt een volgende denkstap. De eindbeoordeling gebruikt een ander dossier.

A1 — Opdracht, concerns en scope

Declaris verzorgt administratieve facturatie en betalingsopvolging voor aangesloten aanbieders. De organisatie wil betrouwbare rapportages en passende portaaltoegang. De opdrachtgever vraagt of hetzelfde woord patiënt overal hetzelfde moet betekenen. Je opdracht is die vraag te verhelderen voordat een systeemkeuze wordt gemaakt.

In scope: personen, verrichtingen, facturatie, ontvangen betalingen, noodzakelijke gegevensuitwisseling, rapportagetellingen en een afgebakend toegangsvoorbeeld. Buiten scope: medisch dossier, verzekeringsrecht, fiscale verwerking en selectie van een platformproduct.

Een concern is hier de te beantwoorden zorg of interesse. Een wens voor een eigen database is een mogelijke oplossing; vraag eerst welk concern die oplossing dient. Verschillende concerns kunnen tegelijk legitiem zijn.

A2 — Begrippen en expliciete regels

Behandelde persoon is in de telling een persoon met minstens één verrichting in de periode. Het is niet automatisch een tweede identiteit. Een persoon kan ook betaler zijn. Factuuraccount is een ander soort object. De oude term factuurrelatie wordt in deze versie niet als verzamelnaam gebruikt: account, betaler en relatie worden apart benoemd.

Vastgestelde casusregels:

• Elke verrichting verwijst naar precies één persoon. Een persoon kan zonder verrichting bestaan.
• Elke factuur heeft precies één account en minstens één regel. Elke regel verwijst in deze vereenvoudiging naar één verrichting.
• Er is geen algemene regel dat één persoon slechts één account kan gebruiken. Routering wordt per factuur vastgelegd; de gevolgde regel en uitzonderingen moeten uitlegbaar zijn.
• Voor dit scenario geldt op een peildatum precies één aangewezen betaler per actief account. Dit is een oefenregel, geen uitspraak over alle contractvormen. De perioden van opeenvolgende betalers overlappen niet.
• Een betaling kan over facturen worden verdeeld; één factuur kan toerekeningen uit verschillende betalingen hebben. Een ontoegerekende betaling blijft herkenbaar en wordt niet stilzwijgend uit de administratie verwijderd.
• Identificatie, betaalrelatie en toegangsrecht zijn aparte afspraken. Betaler zijn verleent in het portaalvoorbeeld geen automatische toegang tot verrichtingsdetails.

Beslis op basis van betekenis en bedrijfsregels of iets een entiteit, rol, subtype, relatie of afleiding is. Een typeveld of een lege kolom is daarvoor hooguit een aanwijzing. Zonder expliciete regels is het model nog een voorstel.

A3 — Conceptueel en logisch model

De figuur geeft de kernrelaties. Lees de precieze aantallen in de tabel. Dezelfde entiteiten keren terug op verschillende detailniveaus; zij worden niet vervangen door TOGAF-componenten zodra een model gedetailleerder wordt.

Logische uitwerking, onafhankelijk van een gekozen databaseproduct:

Het logische model bevat de betekenis van identificatie en waardedomeinen. Een fysieke uitwerking kiest bijvoorbeeld exacte kolomtypen, indexen en opslag. Dat een logisch model een getal of datum noemt, maakt het nog niet productspecifiek.

De gegevensbestanden gebruiken compacte veldnamen en verwijzingen. Zij zijn een demonstratie van gegevensinstanties, geen productieontwerp voor een database. Toerekening-id's zijn in de kleine JSON-weergave impliciet de rijen; bij een technische realisatie moet identificatie van die rijen expliciet worden gekozen.

A4 — Kleine, narekenbare gegevensset

Alle datums in deze tabel zijn in 2026. F01 is uitgegeven op 12 augustus, F02 op 20 augustus en F03 op 31 augustus. P01 is de betaler van A01. P03 is tot 1 september de betaler van A02; vanaf 1 september wordt dit P04. De uitgereikte facturen behouden de vastgelegde betaler bij uitgifte. Een correctie daarop wordt afzonderlijk beoordeeld en niet via de actuele accountrelatie afgeleid.

Uitgewerkt voorbeeld, zakelijke peildatum 31 augustus en kennisdatum 2 september:

• F01: €120 gefactureerd minus €70 toegerekend = €50 open.
• F02: €80 gefactureerd minus €80 toegerekend = €0 open.
• F03: €40 gefactureerd minus €0 toegerekend = €40 open.
• Totaal: €240 gefactureerd, €150 toegerekend en €90 open.

Deze bedragen zijn geen uitspraak over omzetverantwoording. Zij volgen uitsluitend uit de administratieve rekenregels van de casus. Er zijn geen ontoegerekende betalingen in de basisset. In een echt dossier moet je die expliciet meenemen in reconciliatie.

A5 — Metriekdefinities en herkomst

M03 telt P03. Dat P01 betaler is, betekent niet dat betaling B01 volledig aan de zorg van P01 kan worden toegeschreven. De toerekening is hier op factuurniveau, niet op persoons- of regelniveau. Die granulariteit begrenst welke conclusies je kunt trekken.

Een metriekkaart bevat verder eigenaar, doel, filters, periode, peildatum, kennisdatum, versie en herkomst. In deze casus beslist de directie over het gebruiksdoel; de verantwoordelijke voor rapportages beheert de metriekkaart samen met de betrokken gegevensverantwoordelijken. Een nieuwe rapportagevraag wordt niet opgelost door alle bestaande metrieken te hernoemen.

Vraag je wat op 31 augustus bekend was, dan ontbreekt B02: toegerekend €70, open €170. Vraag je op 2 september naar de effectieve stand van 31 augustus, dan telt B02 wel: €150 en €90. Beide uitkomsten zijn reproduceerbaar als beide tijdsvragen zijn vastgelegd. Een herzien cijfer is niet hetzelfde als een ongemerkt veranderd historisch rapport.

A6 — Verantwoordelijkheden en componenten

De volgende indeling is een ontwerpvoorstel voor Declaris. Zij is geen normatieve TOGAF-catalogus en geen voorschrift dat iedere organisatie deze componenten nodig heeft.

Een groep gegevens kan om beheers-, beveiligings- of realisatieredenen worden afgebakend. Een model beschrijft de structuur en samenhang; een component begrenst een samenhangend deel daarvan. Het voorbeeld laat verschillende schema's zien om het onderscheid uit te leggen; het schrijft geen vijf losse databaseproducten voor.

Organisatorisch besluitmandaat ligt bij benoemde functies: Identiteitsbeheer beslist over matchingregels, Facturatiebeheer over account- en factuurregels, Betalingsbeheer over toerekening, Aanleverbeheer over acceptatie van verrichtingen, en de aangewezen beleidsverantwoordelijke over toegangsregels. De definitieve mandaten zijn in de casus een expliciet goed te keuren ontwerpbesluit. Een applicatie heeft geen bestuurlijk mandaat.

Gegevens-/applicatiematrix van de target

Legenda: B = beheert de aangewezen registratie; A = aanleveren via afgesproken interface; L = lezen onder voorwaarden; G = afgeleide rapportagekopie. B betekent hier niet dat een systeem ook de organisatorische eigenaar is. De tabel is bewust geen volledige CRUD-specificatie; verwijderen en correctie krijgen een eigen levenscyclusbesluit.

Dit is een voorstel voor taakverdeling, geen algemene eis dat iedere entiteit exact één systeem moet hebben. Een verdedigbaar alternatief kan meerdere aangewezen registraties hebben, mits scope, conflictregels en uitwisseling expliciet zijn. Iedere L of G moet nog worden vertaald naar toegestane gegevens en doeleinden. Leestoegang tot financiële referenties betekent bijvoorbeeld niet leestoegang tot verrichtingsdetails.