Files
triqura-ecd/docs/datamodel/deelmodellen/model-intake-behandeladvies.md
colinislit 7ad50f4e33 docs(datamodel): feitenronde intake en behandeladvies afgerond
Voegt feitenmodel-intake-behandeladvies.md en model-intake-behandeladvies.md
toe: FCO-IM-feitenronde en entiteiten-/cardinaliteitenafleiding voor
Clinical Intake Assessment, Intake Contact, Child Safety Check en Treatment
Advice. Corrigeert de episode-timing (intake start ná het acceptatiebesluit,
niet bij een niet meer bestaande aanmelding-uitkomst "intake").

Sluit feitenmodel-instroom.md §7 vraag 2 af (behandeladvies-uitkomsten,
sinds sessielog 19 juli geparkeerd): behandeladvies wordt een eigen
Treatment Advice-object met vervangt-mechanisme, naar het patroon van Care
Acceptance Decision — geen apart voorafgaand advies. Op basis van volledige
LKS 4.0-teksttoetsing (niet alleen samenvattingen): doorverwijzing/
terugverwijzing zijn een volgtijdelijk paar, extra_diagnostiek is
praktijkgefundeerd niet LKS-genormeerd, en MDT-bespreking is voor settings
3-8 een dwingende norm (minimale hook: intake_mdt_review).

Legt B31-B34 vast in het besluitenlog, synchroniseert begrippenlijst §4
(Clinical Intake Assessment, Intake Contact, Child Safety Check, Treatment
Advice) en markeert het oudere model-intake.md niet-destructief als
vervangen, consistent met hoe model-aanmelding.md eerder is behandeld.
2026-07-19 18:24:34 +02:00

12 KiB
Raw Blame History

Datamodelvoorstel — Intake en behandeladvies

Status: voorstel ter review — eerste entiteiten- en cardinaliteitenafleiding Datum: 19 juli 2026 Scope: Clinical Intake Assessment, Intake Contact, Child Safety Check, Treatment Advice, en een minimale hook voor MDT-bespreking bij het behandeladvies. Contactmoment-generalisatie naar een bredere consult-/afspraakstructuur blijft buiten scope (agenda-ronde). Kader: bouwt rechtstreeks op de bevestigde feitzinnen in ../feitenmodellen/feitenmodel-intake-behandeladvies.md, inclusief het gerichte LKS 4.0-onderzoek naar behandeladvies-uitkomsten en bevoegdheid. Dit is de stap "afleiding van entiteiten en cardinaliteiten" uit diens §7. Naamgeving: entiteiten en attributen zijn Engelstalig, conform besluit B20 — vervangt het oudere, Nederlandstalige model-intake.md, dat als historisch werkdocument blijft staan met verwijzingen hierheen. Autoriteit: ../besluiten/besluitenlog-datamodel-2026-07-18.md blijft leidend.


1. Entiteiten

1.1 clinical_intake_assessment

Doel: het onderzoekstraject voor één samenhangende zorgvraag binnen een zorgepisode, van gepland eerste contact tot behandeladvies (feitenmodel §2).

Attribuut Type Verplicht
clinical_care_episode_id ref clinical_care_episode ja
initiation_reason waardelijst intake_initiation_reason (regulier/intern/crisis) ja
department waardelijst department (afdeling) ja
status waardelijst intake_status (gepland/bezig/afgerond/afgebroken) ja (default gepland)
planned_at tijdstip ja
started_at tijdstip verplicht zodra status bezig of later
ended_at tijdstip verplicht zodra status afgerond of afgebroken
abort_reason waardelijst intake_abort_reason verplicht bij status afgebroken

Uniciteit: één stabiele identiteit; hangt aan precies één clinical_care_episode. Een episode kan nul, één of meerdere intakes hebben. "Maximaal één lopende intake per episode" is een aan/uit-zetbare bedrijfsregel, geen schemabeperking (een crisisintake kan naast een lopende reguliere intake nodig zijn). Statusovergangen: zie §4.

Relatie met instroom: clinical_care_episode_id vervangt de oudere, inmiddels onjuiste relatie met AANMELDING. De intake start op enig moment ná het acceptatiebesluit dat de episode liet ontstaan — mogelijk na een periode op de intakewachtlijst (referral_case.follow_up_route = intakewachtlijst, model-instroom.md §2.12). planned_at dekt precies dat interval.

1.2 intake_contact

Doel: een feitelijk contact binnen een clinical_intake_assessment (feitenmodel §3.2).

Attribuut Type Verplicht
clinical_intake_assessment_id ref clinical_intake_assessment ja
occurred_at tijdstip ja
contact_type waardelijst intake_contact_type (intakegesprek/aanvullend_onderzoek/telefonisch_contact/huisbezoek/beeldcontact/overig) ja
performed_by ref medewerker ja
notes tekst nee
planned_duration_minutes geheel getal nee

Uniciteit: geen — meerdere contacten van hetzelfde type op dezelfde dag zijn legitiem.

1.3 child_safety_check

Doel: de wettelijk verankerde kindcheck bij de intake (feitenmodel §3.3).

Attribuut Type Verplicht
clinical_intake_assessment_id ref clinical_intake_assessment ja
performed_at tijdstip ja
performed_by ref medewerker ja
responsible_for_minors ja/nee ja
minor_count geheel getal nee (alleen zinvol bij responsible_for_minors = ja)
minor_ages tekst nee (vrije tekst, bewust geen kindrecords — dataminimalisatie)
safety_concern ja/nee ja
safety_concern_notes tekst verplicht bij safety_concern = ja
action_taken ja/nee ja
action_taken_notes tekst verplicht bij action_taken = ja
pregnancy ja/nee ja (vierde vlag, KNMG-kindcheck — feitenmodel §3.3, te verifiëren tegen de meldcode-tekst)
notes tekst nee

Uniciteit: maximaal één child_safety_check per clinical_intake_assessment (uniek op clinical_intake_assessment_id). Een nieuwe intake binnen dezelfde episode krijgt een eigen, nieuwe kindcheck.

1.4 intake_mdt_review (minimale, voorlopige hook — zie §6)

Doel: vastleggen dát een behandeladvies in een multidisciplinair team is besproken, zonder de volledige MDO-workflow (B14-B15, nog een aparte ronde) hier te herhalen. Voor settings 38 is dit volgens LKS 4.0 een dwingende norm, voor setting 2 optioneel, voor vrijgevestigden niet van toepassing (feitenmodel §3.4).

Attribuut Type Verplicht
occurred_at tijdstip ja
participants tekst ja (vrije tekst voorlopig; structurering wacht op de MDO-ronde)
notes tekst nee

Uniciteit: geen eigen FK naar clinical_intake_assessment — wordt gekoppeld via treatment_advice.mdt_review_id (zie 1.5), zodat een MDT-bespreking pas telt zodra zij daadwerkelijk aan een vastgesteld advies hangt.

1.5 treatment_advice

Doel: het object dat een clinical_intake_assessment afrondt: draagt de uitkomst, het geadviseerde zorgprogramma en de toelichting (feitenmodel §2, §3.4).

Attribuut Type Verplicht
clinical_intake_assessment_id ref clinical_intake_assessment ja
decided_at tijdstip ja
decided_by ref medewerker (indicerende regiebehandelaar) ja
outcome waardelijst treatment_advice_outcome (in_zorg/terugverwijzing/doorverwijzing/extra_diagnostiek) ja
recommended_care_program ref care_program verplicht bij outcome in_zorg, anders optioneel
rationale tekst verplicht bij terugverwijzing/doorverwijzing/extra_diagnostiek, optioneel bij in_zorg
mdt_review_id ref intake_mdt_review nee (settingafhankelijk — zie §6, punt 1)
replaces_advice_id ref treatment_advice (zelfreferentie) nee
replacement_reason tekst verplicht als replaces_advice_id gevuld is

Uniciteit: precies één intake, beslisser, besluitdatum en uitkomst per advies. replaces_advice_id is uniek indien gevuld (voorkomt vertakking), onbeperkte kettingdiepte — zelfde constructie als care_acceptance_decision/professional_referral in model-instroom.md. Het geldige advies van een intake is het laatste, niet-vervangen advies in de keten.

doorverwijzing/terugverwijzing als volgtijdelijk paar: LKS 4.0 normeert eerst een inspanningsverplichting tot doorverwijzing, pas daarna terugverwijzing als dat niets oplevert. Dit wordt niet als aparte sequentie-constraint gemodelleerd, maar volgt vanzelf uit het vervangt-mechanisme: een terugverwijzing-advies dat een eerder doorverwijzing-advies vervangt, met de mislukte doorverwijzing als replacement_reason (feitenmodel §3.4, Route 2).

2. Relaties met cardinaliteit

Van Naar Cardinaliteit Toelichting
clinical_care_episode clinical_intake_assessment 1..0..n een episode kan nog geen intake hebben (net ontstaan, wacht op intakewachtlijst)
clinical_intake_assessment intake_contact 1..0..n een geplande intake heeft nog geen contacten
clinical_intake_assessment child_safety_check 1..0..1 "verplicht vóór afronden" is een nudge, geen schema-eis
clinical_intake_assessment treatment_advice 1..0..n 0 zolang nog niet afgerond; n bij heroverweging (Route 4)
treatment_advice treatment_advice 0..1 (self) replaces_advice_id, optioneel en uniek indien gevuld — voorkomt vertakking
treatment_advice intake_mdt_review 0..1..1 een MDT-bespreking hoort bij precies één advies zodra gekoppeld
treatment_advice care_program 0..1 verplicht bij outcome in_zorg

3. Waardelijsten (startlijsten, te bevestigen)

Waardelijst Voorlopige waarden
intake_initiation_reason regulier, intern, crisis
intake_status gepland, bezig, afgerond, afgebroken
intake_abort_reason client_trekt_terug, geen_contact_meer, overleden, overig
intake_contact_type intakegesprek, aanvullend_onderzoek, telefonisch_contact, huisbezoek, beeldcontact, overig
treatment_advice_outcome in_zorg, terugverwijzing, doorverwijzing, extra_diagnostiek
department over te nemen uit model-aanmelding.md/instellingsconfiguratie (afdeling, instellingsconfigureerbaar)
care_program over te nemen uit bestaande zorgprogramma-waardelijst (model-instroom.md program_context)

Alle waardelijsten volgen het bestaande patroon (referentietabel met code, omschrijving, geldig_van/geldig_tot, actief — spelregel 3.1 #1) en zijn hier nog geen definitieve besluiten.

4. Statusmachine clinical_intake_assessment

Statussen: geplandbezigafgerond/afgebroken, met heropening.

Van Naar Voorwaarde
gepland intake aangemaakt
gepland bezig eerste intake_contact geregistreerd
gepland afgebroken abort_reason verplicht
bezig afgerond een niet-vervangen treatment_advice verplicht
bezig afgebroken abort_reason verplicht
afgerond bezig heropening, audit-event verplicht
afgebroken bezig heropening (cliënt meldt zich alsnog), audit-event verplicht

Niet toegestaan: geplandafgerond rechtstreeks (afronden zonder geregistreerd contact); afgerondafgebroken rechtstreeks. Regels in het model als check-constraints en een referentietabel voor overgangen, consistent met spelregel 3.1 #7/#9.

5. Buiten scope van dit document

  • Het volledige MDO-workflowmodel (casusinbreng, triage, agendering, formele uitkomsttypen) — intake_mdt_review is een minimale hook, geen vervanging van B14-B15.
  • Contactmoment-generalisatie naar een bredere consult-/afspraakstructuur — agenda-ronde.
  • De volledige bevoegdheidsmatrix per setting (welke settings exact MDT-bespreking vereisen, en de rolinvulling) — bevoegdheidsronde (B16).
  • ZPM-consultregistratie (planning versus geleverde prestatie) — hangt aan intake_contact maar wordt in de declaratie-ronde uitgewerkt.

6. Open punten voor Colin

  1. intake_mdt_review als verplicht of optioneel veld op treatment_advice? Voorstel hierboven: optioneel op schemaniveau (mdt_review_id nee), met een nudge/constraint die per setting bepaalt of afronden zonder MDT-koppeling is toegestaan — settings 38 volgens LKS 4.0 in principe niet. Dit vereist een settingregistratie die nu nog niet bestaat in het model (welke setting geldt voor deze episode/case); zonder die registratie kan de regel niet worden afgedwongen, alleen als nudge worden voorgesteld.
  2. Is extra_diagnostiek altijd een nieuw, vervangend treatment_advice zodra het vervolgonderzoek is afgerond, of kan de intake ook gewoon "bezig" blijven zonder tussentijdse afronding? Beide zijn nu schema-technisch mogelijk (heropening bestaat); welke de praktijk prefereert is niet getoetst.
  3. pregnancy-vlag op child_safety_check is toegevoegd op basis van algemene domeinkennis (KNMG-meldcode), niet uit de eerder verzamelde onderzoeksrapporten — te verifiëren.
  4. Startwaarden van de waardelijsten — met name intake_contact_type en intake_abort_reason zijn overgenomen uit het oudere model-intake.md zonder nieuwe validatie.

7. Bronverwijzingen

Onderdeel Bron
Alle feitzinnen, besloten regels, scenario's ../feitenmodellen/feitenmodel-intake-behandeladvies.md
LKS 4.0-onderzoek behandeladvies-uitkomsten en bevoegdheid zie onderzoeksresultaat verwerkt in feitenmodel §3.4
Intake aan zorgepisode, meerdere intakes, aanleiding-waardelijst (basis) model-intake.md §1/§2 (ouder, Nederlandstalig, episode-timing gecorrigeerd)
Instroom-precedenten (vervangt-mechanisme, tijdlijn-principe) model-instroom.md
Engelstalig technisch model besluit B20, ../besluiten/besluitenlog-datamodel-2026-07-18.md §9