From 10c994b25245daf197a18baf1a1b2ff8fa5bfd88 Mon Sep 17 00:00:00 2001 From: colinislit Date: Tue, 14 Jul 2026 22:21:20 +0200 Subject: [PATCH 01/19] =?UTF-8?q?chore(strip):=20fase=200=20=E2=80=94=20ve?= =?UTF-8?q?rwijder=20marketing,=20leads,=20archive=20en=20sitemap?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Prototype-ballast verwijderd als eerste stap van de ECD-rebuild: - app/(marketing) incl. blog, contact, documentatie + lib/mdx, lib/content, content/ - /api/leads en publieke marketing-routes uit middleware - app/epd/_archive (backup van clients-module) - sitemap.ts (verwees alleen naar blog), globals.css.backup - root / redirect naar /login; robots.txt op disallow-all (afgeschermd systeem) FHIR-routes blijven bewust staan: /api/fhir/Patient is de facto de patienten-API voor dossier, agenda en Cortex — vervangen volgt in fase 3. Co-Authored-By: Claude Fable 5 --- app/(marketing)/blog/page.tsx | 169 -- .../blog/serie/[serieId]/[slug]/page.tsx | 324 ---- app/(marketing)/blog/serie/[serieId]/page.tsx | 178 -- .../components/auth-code-handler.tsx | 38 - app/(marketing)/components/build-timeline.tsx | 273 --- app/(marketing)/components/hero-quote.tsx | 58 - .../components/hero-section-client.tsx | 33 - app/(marketing)/components/insight-box.tsx | 32 - .../components/marketing-shader.tsx | 83 - app/(marketing)/components/minimal-nav.tsx | 154 -- .../components/reading-progress.tsx | 69 - .../components/statement-section.tsx | 51 - app/(marketing)/contact/contact-form.tsx | 326 ---- app/(marketing)/contact/page.tsx | 55 - .../documentatie/[category]/page.tsx | 202 --- .../components/mdx-components.tsx | 191 --- .../components/release-sidebar-wrapper.tsx | 23 - .../components/release-sidebar.tsx | 304 ---- app/(marketing)/documentatie/layout.tsx | 51 - app/(marketing)/documentatie/page.tsx | 155 -- app/(marketing)/layout.tsx | 45 - app/(marketing)/page.tsx | 239 --- app/api/leads/route.ts | 116 -- .../[...path]/route.ts | 31 - .../[id]/components/client-tabs.tsx | 91 - .../[id]/components/intake-tab.tsx | 56 - .../[id]/components/plan-tab.tsx | 143 -- .../[id]/components/profile-tab.tsx | 122 -- .../[id]/dashboard/page.tsx | 101 -- .../[id]/diagnose/page.tsx | 27 - .../[id]/edit/page.tsx | 49 - .../[id]/intake/page.tsx | 27 - .../[intakeId]/components/intake-header.tsx | 65 - .../[intakeId]/components/intake-tabs.tsx | 52 - .../[id]/intakes/[intakeId]/layout.tsx | 29 - .../[id]/intakes/[intakeId]/page.tsx | 52 - .../[id]/intakes/actions.ts | 83 - .../[id]/intakes/components/intake-card.tsx | 70 - .../[id]/intakes/components/intake-list.tsx | 50 - .../intakes/components/new-intake-form.tsx | 137 -- .../[id]/intakes/new/page.tsx | 33 - .../clients_backup_20251122/[id]/page.tsx | 18 - .../[id]/plan/page.tsx | 27 - .../[id]/reports/page.tsx | 27 - .../clients_backup_20251122/actions.ts | 146 -- .../coming-soon-backup.tsx | 191 --- .../components/client-form.tsx | 149 -- .../components/client-list-skeleton.tsx | 56 - .../components/client-list.tsx | 260 --- .../clients_backup_20251122/new/page.tsx | 29 - .../_archive/clients_backup_20251122/page.tsx | 10 - app/globals.css.backup | 248 --- app/page.tsx | 5 + app/robots.ts | 24 +- app/sitemap.ts | 84 - components/ui/why-me.tsx | 117 -- content/nl/about.json | 95 -- content/nl/blog/_series.json | 21 - content/nl/blog/ai-speedrun/01-kickoff.mdx | 33 - .../ai-speedrun/02-authentication-docs.mdx | 48 - .../nl/blog/ai-speedrun/03-fhir-datamodel.mdx | 56 - content/nl/blog/ai-speedrun/04-de-valkuil.mdx | 62 - .../blog/ai-speedrun/05-spraakherkenning.mdx | 33 - .../blog/ai-speedrun/06-ai-tool-of-baas.mdx | 45 - .../nl/blog/ai-speedrun/07-ai-assistent.mdx | 54 - .../blog/ai-speedrun/08-week-4-spruitjes.mdx | 49 - .../09-verpleegkundige-overdracht.mdx | 51 - .../blog/ai-speedrun/10-stop-met-klagen.mdx | 65 - .../11-performance-optimalisatie.mdx | 47 - content/nl/blog/ai-speedrun/12-de-cijfers.mdx | 59 - content/nl/blog/ai-speedrun/13-learnings.mdx | 134 -- content/nl/blog/cortex-intent/introductie.mdx | 18 - content/nl/common.json | 15 - content/nl/contact.json | 118 -- content/nl/documentatie/_index.json | 216 --- content/nl/documentatie/agenda-systeem.mdx | 234 --- .../ai-documentatie-assistent.mdx | 208 --- content/nl/documentatie/authentication.mdx | 198 --- content/nl/documentatie/build-errors-fix.mdx | 79 - content/nl/documentatie/client-management.mdx | 61 - content/nl/documentatie/cortex-blocks.mdx | 176 -- .../nl/documentatie/cortex-intent-systeem.mdx | 154 -- .../cortex-keyboard-shortcuts.mdx | 142 -- .../documentatie/cortex-mention-systeem.mdx | 157 -- content/nl/documentatie/cortex-nudge.mdx | 167 -- content/nl/documentatie/cortex-overzicht.mdx | 121 -- content/nl/documentatie/diagnose-systeem.mdx | 211 --- content/nl/documentatie/fhir-api.mdx | 1508 ----------------- content/nl/documentatie/fhir-datamodel.mdx | 476 ------ content/nl/documentatie/intake-system.mdx | 203 --- content/nl/documentatie/interface-design.mdx | 643 ------- .../nl/documentatie/release-notes-system.mdx | 397 ----- content/nl/documentatie/screening-system.mdx | 203 --- .../spraakgestuurde-verslaglegging.mdx | 152 -- .../nl/documentatie/treatment-planning.mdx | 73 - .../verpleegkundige-overdracht.mdx | 231 --- .../voice-controlled-reporting.mdx | 134 -- .../webpack-module-resolution.mdx | 342 ---- content/nl/epd.json | 80 - content/nl/manifesto.json | 121 -- content/nl/metadata.json | 11 - content/nl/navigation.json | 18 - content/nl/timeline.json | 160 -- content/schemas/manifesto.ts | 248 --- lib/content/loader.ts | 70 - lib/content/markdown-parser.ts | 62 - lib/mdx/blog.ts | 259 --- lib/mdx/documentatie.ts | 240 --- middleware.ts | 5 - 109 files changed, 8 insertions(+), 14533 deletions(-) delete mode 100644 app/(marketing)/blog/page.tsx delete mode 100644 app/(marketing)/blog/serie/[serieId]/[slug]/page.tsx delete mode 100644 app/(marketing)/blog/serie/[serieId]/page.tsx delete mode 100644 app/(marketing)/components/auth-code-handler.tsx delete mode 100644 app/(marketing)/components/build-timeline.tsx delete mode 100644 app/(marketing)/components/hero-quote.tsx delete mode 100644 app/(marketing)/components/hero-section-client.tsx delete mode 100644 app/(marketing)/components/insight-box.tsx delete mode 100644 app/(marketing)/components/marketing-shader.tsx delete mode 100644 app/(marketing)/components/minimal-nav.tsx delete mode 100644 app/(marketing)/components/reading-progress.tsx delete mode 100644 app/(marketing)/components/statement-section.tsx delete mode 100644 app/(marketing)/contact/contact-form.tsx delete mode 100644 app/(marketing)/contact/page.tsx delete mode 100644 app/(marketing)/documentatie/[category]/page.tsx delete mode 100644 app/(marketing)/documentatie/components/mdx-components.tsx delete mode 100644 app/(marketing)/documentatie/components/release-sidebar-wrapper.tsx delete mode 100644 app/(marketing)/documentatie/components/release-sidebar.tsx delete mode 100644 app/(marketing)/documentatie/layout.tsx delete mode 100644 app/(marketing)/documentatie/page.tsx delete mode 100644 app/(marketing)/layout.tsx delete mode 100644 app/(marketing)/page.tsx delete mode 100644 app/api/leads/route.ts delete mode 100644 app/epd/_archive/clients_backup_20251122/[...path]/route.ts delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/components/client-tabs.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/components/intake-tab.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/components/plan-tab.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/components/profile-tab.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/dashboard/page.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/diagnose/page.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/edit/page.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/intake/page.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/intakes/[intakeId]/components/intake-header.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/intakes/[intakeId]/components/intake-tabs.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/intakes/[intakeId]/layout.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/intakes/[intakeId]/page.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/intakes/actions.ts delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/intakes/components/intake-card.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/intakes/components/intake-list.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/intakes/components/new-intake-form.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/intakes/new/page.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/page.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/plan/page.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/[id]/reports/page.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/actions.ts delete mode 100644 app/epd/_archive/clients_backup_20251122/coming-soon-backup.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/components/client-form.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/components/client-list-skeleton.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/components/client-list.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/new/page.tsx delete mode 100644 app/epd/_archive/clients_backup_20251122/page.tsx delete mode 100644 app/globals.css.backup create mode 100644 app/page.tsx delete mode 100644 app/sitemap.ts delete mode 100644 components/ui/why-me.tsx delete mode 100644 content/nl/about.json delete mode 100644 content/nl/blog/_series.json delete mode 100644 content/nl/blog/ai-speedrun/01-kickoff.mdx delete mode 100644 content/nl/blog/ai-speedrun/02-authentication-docs.mdx delete mode 100644 content/nl/blog/ai-speedrun/03-fhir-datamodel.mdx delete mode 100644 content/nl/blog/ai-speedrun/04-de-valkuil.mdx delete mode 100644 content/nl/blog/ai-speedrun/05-spraakherkenning.mdx delete mode 100644 content/nl/blog/ai-speedrun/06-ai-tool-of-baas.mdx delete mode 100644 content/nl/blog/ai-speedrun/07-ai-assistent.mdx delete mode 100644 content/nl/blog/ai-speedrun/08-week-4-spruitjes.mdx delete mode 100644 content/nl/blog/ai-speedrun/09-verpleegkundige-overdracht.mdx delete mode 100644 content/nl/blog/ai-speedrun/10-stop-met-klagen.mdx delete mode 100644 content/nl/blog/ai-speedrun/11-performance-optimalisatie.mdx delete mode 100644 content/nl/blog/ai-speedrun/12-de-cijfers.mdx delete mode 100644 content/nl/blog/ai-speedrun/13-learnings.mdx delete mode 100644 content/nl/blog/cortex-intent/introductie.mdx delete mode 100644 content/nl/common.json delete mode 100644 content/nl/contact.json delete mode 100644 content/nl/documentatie/_index.json delete mode 100644 content/nl/documentatie/agenda-systeem.mdx delete mode 100644 content/nl/documentatie/ai-documentatie-assistent.mdx delete mode 100644 content/nl/documentatie/authentication.mdx delete mode 100644 content/nl/documentatie/build-errors-fix.mdx delete mode 100644 content/nl/documentatie/client-management.mdx delete mode 100644 content/nl/documentatie/cortex-blocks.mdx delete mode 100644 content/nl/documentatie/cortex-intent-systeem.mdx delete mode 100644 content/nl/documentatie/cortex-keyboard-shortcuts.mdx delete mode 100644 content/nl/documentatie/cortex-mention-systeem.mdx delete mode 100644 content/nl/documentatie/cortex-nudge.mdx delete mode 100644 content/nl/documentatie/cortex-overzicht.mdx delete mode 100644 content/nl/documentatie/diagnose-systeem.mdx delete mode 100644 content/nl/documentatie/fhir-api.mdx delete mode 100644 content/nl/documentatie/fhir-datamodel.mdx delete mode 100644 content/nl/documentatie/intake-system.mdx delete mode 100644 content/nl/documentatie/interface-design.mdx delete mode 100644 content/nl/documentatie/release-notes-system.mdx delete mode 100644 content/nl/documentatie/screening-system.mdx delete mode 100644 content/nl/documentatie/spraakgestuurde-verslaglegging.mdx delete mode 100644 content/nl/documentatie/treatment-planning.mdx delete mode 100644 content/nl/documentatie/verpleegkundige-overdracht.mdx delete mode 100644 content/nl/documentatie/voice-controlled-reporting.mdx delete mode 100644 content/nl/documentatie/webpack-module-resolution.mdx delete mode 100644 content/nl/epd.json delete mode 100644 content/nl/manifesto.json delete mode 100644 content/nl/metadata.json delete mode 100644 content/nl/navigation.json delete mode 100644 content/nl/timeline.json delete mode 100644 content/schemas/manifesto.ts delete mode 100644 lib/content/loader.ts delete mode 100644 lib/content/markdown-parser.ts delete mode 100644 lib/mdx/blog.ts delete mode 100644 lib/mdx/documentatie.ts diff --git a/app/(marketing)/blog/page.tsx b/app/(marketing)/blog/page.tsx deleted file mode 100644 index e50f785..0000000 --- a/app/(marketing)/blog/page.tsx +++ /dev/null @@ -1,169 +0,0 @@ -/** - * Blog Overview Page - * - * Landing page with series cards and recent posts - */ - -import Link from 'next/link' -import { getAllPosts, getSeriesWithCounts, type BlogSeries } from '@/lib/mdx/blog' - -export const metadata = { - title: 'Blog - AI Speedrun', - description: 'Artikelen over AI-gestuurde software ontwikkeling, healthcare IT en het bouwen van een EPD.', - openGraph: { - title: 'Blog - AI Speedrun', - description: 'Artikelen over AI-gestuurde software ontwikkeling, healthcare IT en het bouwen van een EPD.', - type: 'website', - siteName: 'AI Speedrun', - locale: 'nl_NL', - }, - twitter: { - card: 'summary', - title: 'Blog - AI Speedrun', - description: 'Artikelen over AI-gestuurde software ontwikkeling, healthcare IT en het bouwen van een EPD.', - }, - alternates: { - canonical: `${process.env.NEXT_PUBLIC_APP_URL || 'https://aispeedrun.vercel.app'}/blog`, - }, -} - -export default async function BlogPage() { - const series = await getSeriesWithCounts() - const posts = await getAllPosts() - - return ( -
-
- {/* Header */} -
-

- Blog -

-

- Artikelen over AI-gestuurde ontwikkeling en de reis van het bouwen van een EPD. -

-
- - {/* Series Section */} - {series.length > 0 && ( -
-

- Series -

-
- {series.map((serie) => ( - - ))} -
-
- )} - - {/* Recent Posts Section */} -
-

- Recente Posts -

- {posts.length === 0 ? ( -

- Nog geen blogposts gepubliceerd. -

- ) : ( -
- {posts.map((post) => ( - -
- - {post.seriesId.replace('-', ' ')} - - • - - • - {post.readingTime} min leestijd -
-

- {post.frontmatter.title} -

-

- {post.frontmatter.description} -

- {post.frontmatter.tags && post.frontmatter.tags.length > 0 && ( -
- {post.frontmatter.tags.map((tag) => ( - - {tag} - - ))} -
- )} - - ))} -
- )} -
-
-
- ) -} - -function SeriesCard({ series }: { series: BlogSeries & { postCount: number } }) { - const colorStyles = { - teal: { - bg: 'bg-teal-50', - border: 'border-teal-200 hover:border-teal-400', - badge: 'bg-teal-100 text-teal-700', - dot: 'bg-teal-500', - }, - amber: { - bg: 'bg-amber-50', - border: 'border-amber-200 hover:border-amber-400', - badge: 'bg-amber-100 text-amber-700', - dot: 'bg-amber-500', - }, - slate: { - bg: 'bg-slate-50', - border: 'border-slate-200 hover:border-slate-400', - badge: 'bg-slate-100 text-slate-700', - dot: 'bg-slate-500', - }, - } - - const styles = colorStyles[series.color] || colorStyles.slate - const statusLabels = { - completed: 'Voltooid', - active: 'Actief', - planned: 'Gepland', - } - - return ( - -
-
- - {statusLabels[series.status]} - -
-

{series.title}

-

{series.description}

-
- {series.postCount} {series.postCount === 1 ? 'deel' : 'delen'} -
- - ) -} - diff --git a/app/(marketing)/blog/serie/[serieId]/[slug]/page.tsx b/app/(marketing)/blog/serie/[serieId]/[slug]/page.tsx deleted file mode 100644 index 0c9932f..0000000 --- a/app/(marketing)/blog/serie/[serieId]/[slug]/page.tsx +++ /dev/null @@ -1,324 +0,0 @@ -/** - * Individual Blog Post Page - * - * Renders MDX content with series navigation - */ - -import { notFound } from 'next/navigation' -import Link from 'next/link' -import { MDXRemote } from 'next-mdx-remote/rsc' -import { getPost, getSeries, getPostsBySeries, getSeriesNavigation, getAllPosts } from '@/lib/mdx/blog' -import { mdxComponents } from '../../../../documentatie/components/mdx-components' - -interface PostPageProps { - params: Promise<{ serieId: string; slug: string }> -} - -export async function generateStaticParams() { - const posts = await getAllPosts() - return posts.map((post) => ({ - serieId: post.seriesId, - slug: post.slug, - })) -} - -export async function generateMetadata({ params }: PostPageProps) { - const { serieId, slug } = await params - const post = await getPost(serieId, slug) - const series = await getSeries(serieId) - - if (!post || !series) { - return { title: 'Post niet gevonden' } - } - - const siteUrl = process.env.NEXT_PUBLIC_APP_URL || 'https://aispeedrun.vercel.app' - const postUrl = `${siteUrl}/blog/serie/${serieId}/${slug}` - // Use post-specific image if provided, otherwise fall back to default - const ogImageUrl = post.frontmatter.image - ? `${siteUrl}${post.frontmatter.image.startsWith('/') ? '' : '/'}${post.frontmatter.image}` - : `${siteUrl}/og-blog-default.png` - - return { - title: `${post.frontmatter.title} - ${series.title}`, - description: post.frontmatter.description, - authors: [{ name: 'Colin van der Heijden', url: 'https://ikbenlit.nl' }], - keywords: post.frontmatter.tags || [], - openGraph: { - title: post.frontmatter.title, - description: post.frontmatter.description, - type: 'article', - publishedTime: post.frontmatter.date, - authors: ['Colin van der Heijden'], - siteName: 'AI Speedrun', - locale: 'nl_NL', - images: [ - { - url: ogImageUrl, - width: 1200, - height: 630, - alt: post.frontmatter.title, - }, - ], - }, - twitter: { - card: 'summary_large_image', - title: post.frontmatter.title, - description: post.frontmatter.description, - images: [ogImageUrl], - }, - alternates: { - canonical: postUrl, - }, - } -} - -export default async function PostPage({ params }: PostPageProps) { - const { serieId, slug } = await params - const post = await getPost(serieId, slug) - const series = await getSeries(serieId) - - if (!post || !series) { - notFound() - } - - const navigation = await getSeriesNavigation(serieId, slug) - const { frontmatter, content, readingTime } = post - - // Generate Article structured data for SEO - const siteUrl = process.env.NEXT_PUBLIC_APP_URL || 'https://aispeedrun.vercel.app' - const postUrl = `${siteUrl}/blog/serie/${serieId}/${slug}` - // Use post-specific image if provided, otherwise fall back to default - const articleImage = frontmatter.image - ? `${siteUrl}${frontmatter.image.startsWith('/') ? '' : '/'}${frontmatter.image}` - : `${siteUrl}/og-blog-default.png` - const articleSchema = { - '@context': 'https://schema.org', - '@type': 'Article', - headline: frontmatter.title, - description: frontmatter.description, - image: articleImage, - datePublished: frontmatter.date, - dateModified: frontmatter.date, - author: { - '@type': 'Person', - name: 'Colin van der Heijden', - url: 'https://ikbenlit.nl', - }, - publisher: { - '@type': 'Organization', - name: 'AI Speedrun', - url: siteUrl, - logo: { - '@type': 'ImageObject', - url: `${siteUrl}/images/aispeedrun-logo.webp`, - }, - }, - mainEntityOfPage: { - '@type': 'WebPage', - '@id': postUrl, - }, - articleSection: series.title, - keywords: frontmatter.tags?.join(', ') || '', - wordCount: content.split(/\s+/).length, - timeRequired: `PT${readingTime}M`, - } - - // Generate BreadcrumbList structured data - const breadcrumbSchema = { - '@context': 'https://schema.org', - '@type': 'BreadcrumbList', - itemListElement: [ - { - '@type': 'ListItem', - position: 1, - name: 'Home', - item: siteUrl, - }, - { - '@type': 'ListItem', - position: 2, - name: 'Blog', - item: `${siteUrl}/blog`, - }, - { - '@type': 'ListItem', - position: 3, - name: series.title, - item: `${siteUrl}/blog/serie/${serieId}`, - }, - { - '@type': 'ListItem', - position: 4, - name: frontmatter.title, - item: postUrl, - }, - ], - } - - const colorStyles = { - teal: { - badge: 'bg-teal-100 text-teal-700 border-teal-200', - link: 'text-teal-600 hover:text-teal-700', - }, - amber: { - badge: 'bg-amber-100 text-amber-700 border-amber-200', - link: 'text-amber-600 hover:text-amber-700', - }, - slate: { - badge: 'bg-slate-100 text-slate-700 border-slate-200', - link: 'text-slate-600 hover:text-slate-700', - }, - } - - const styles = colorStyles[series.color] || colorStyles.slate - - return ( -
- {/* Structured Data for SEO */} - + + diff --git a/docs/datamodel/entiteitenkaart-instroom.html b/docs/datamodel/entiteitenkaarten/entiteitenkaart-instroom.html similarity index 99% rename from docs/datamodel/entiteitenkaart-instroom.html rename to docs/datamodel/entiteitenkaarten/entiteitenkaart-instroom.html index 2618c69..1cd7ca8 100644 --- a/docs/datamodel/entiteitenkaart-instroom.html +++ b/docs/datamodel/entiteitenkaarten/entiteitenkaart-instroom.html @@ -1025,7 +1025,7 @@ erDiagram
- Bron: docs/datamodel/datamodel-discovery.md §5.1–5.5 · volgende stap (§6): statussen + + Bron: docs/datamodel/deelmodellen/datamodel-discovery.md §5.1–5.5 · volgende stap (§6): statussen + eigenaarschap ECD/TIP per entiteit vastleggen, daarna de latere rondes (agenda, rapportage & overdracht, rollen/disciplines) en pas dan de schema-baseline.
diff --git a/docs/datamodel/feitenmodellen/feitenmodel-instroom.md b/docs/datamodel/feitenmodellen/feitenmodel-instroom.md new file mode 100644 index 0000000..2b8eab6 --- /dev/null +++ b/docs/datamodel/feitenmodellen/feitenmodel-instroom.md @@ -0,0 +1,623 @@ +# Feitenmodel instroom — eerste FCO-IM-ronde + +**Status:** concept voor domeinreview, geen logisch model +**Datum:** 18 juli 2026, gesynchroniseerd 19 juli 2026 +**Scope:** zorgverzoek, afzonderlijke binnenkomst, aanmeldingstraject en acceptatie +**Autoriteit:** `../besluiten/besluitenlog-datamodel-2026-07-18.md` blijft leidend +**Aanleiding:** afgesproken vervolg in `../sessielogs/sessielog-2026-07-18.md` §13 +**Synchronisatie:** §2 (Care Acceptance Decision), §3.4–§3.5, §4 en §7 zijn op +19 juli 2026 bijgewerkt conform de screening=acceptatie-beslissing uit +`../sessielogs/sessielog-2026-07-19.md` §5–§9. `Screening Recommendation` als apart +besluitobject vervalt daarmee; de begrippenlijst en `../deelmodellen/model-aanmelding.md` +volgen in een latere synchronisatiestap. + +## 1. Doel van deze ronde + +Deze ronde formuleert elementaire feiten vóórdat entiteiten, attributen, +cardinaliteiten of SQL worden vastgelegd. De feiten worden getoetst met vier +praktijkscenario's: + +1. een huisarts verwijst een cliënt; +2. een cliënt meldt zichzelf aan; +3. later komt aanvullende informatie binnen; +4. twee binnenkomsten blijken dubbel of overlappend. + +De centrale open vraag is of `Referral Request` een eigen identiteit nodig +heeft naast `Referral Submission` en `Referral Case`. + +## 2. Werkbegrippen + +De Engelse namen zijn werktermen en worden pas na domeinreview in de +begrippenlijst vastgesteld. + +### Referral Request — `referral_request` + +Het inhoudelijke verzoek om zorg of beoordeling voor één of meer +samenhangende geuite zorgvragen. Het verzoek kan afkomstig zijn van een +professional, organisatie, cliënt of vertegenwoordiger. Splitsing is pas +nodig wanneer zorgvragen afzonderlijk moeten worden beoordeeld. + +Een Referral Request is niet: + +- de technische of administratieve ontvangst van het verzoek; +- de documentenbundel; +- het interne beoordelingstraject; +- een bewijs dat de zorg is geaccepteerd; +- noodzakelijk een formele Nederlandse verwijzing. + +### Referral Submission — `referral_submission` + +Eén afzonderlijke binnenkomst bij de instelling, via één kanaal en op één +ontvangstmoment. Een submission bewaart wat daadwerkelijk is ontvangen, +inclusief bron, documenten en oorspronkelijke formulering. + +Een Referral Submission is niet: + +- automatisch een nieuw zorgverzoek; +- automatisch een nieuw aanmeldingstraject; +- een overschrijfbare actuele versie van eerder ontvangen informatie. + +### Referral Case — `referral_case` + +Het institutionele aanmeldingstraject waarin de instelling één samenhangende +zorgvraag beoordeelt. Een case kan informatie uit meerdere submissions +gebruiken. + +Een Referral Case is niet: + +- een klinische intake; +- een zorgepisode; +- een financieel traject; +- de zorgvraag of verwijzing zelf. + +### Professional Referral — `professional_referral` + +Voorlopige naam voor de formele Nederlandse **VERWIJZING**: een door een +toegestane verwijzer uitgegeven object met verwijzer, verwijsdatum, +geldigheid en eventuele verwijsspecifieke gegevens. + +De formele verwijzing heeft een eigen identiteit en wordt gekoppeld aan het +bredere Referral Request. Een zelfaanmelding kan zo al worden beoordeeld en, +bij spoed of crisis, tot zorg leiden voordat een formele verwijzing is +ontvangen. De latere verwijzing verandert de identiteit en herkomst van het +oorspronkelijke zorgverzoek niet. + +### Care Acceptance Decision — `care_acceptance_decision` + +Het formele besluit waarin de instelling de beoordeling van een Referral Case +afrondt. Het besluit draagt zelf de onderliggende beoordelingen — inhoudelijke +match, beschikbare plek en capaciteit — samen met de besluituitkomst, de +vervolgroute en, bij afwijzing, de onderbouwing. Er bestaat geen los, +voorafgaand screeningsadvies: het screeningsbesluit **is** het +acceptatiebesluit (bevestigd in domeinreview 19 juli 2026). Een positief +besluit geeft toegang tot de zorginhoudelijke intake; het is niet het latere +behandeladvies. + +Screening blijft wel bestaan als de verzameling activiteiten (contact, +onderzoek, informatie-uitvraag) waarmee de beoordelingsfeiten tot stand +komen — alleen de uitkomst ervan wordt niet meer als apart, voorlopig advies +vastgelegd. + +Acceptatie bewijst niet automatisch: + +- een behandelovereenkomst; +- behandeltoestemming; +- zorgplicht; +- toewijzing van een behandelaar; +- organisatorische of klinische verantwoordelijkheid. + +## 3. Elementaire feitzinnen + +### 3.1 Zorgverzoek + +R1. *Zorgverzoek R-101 betreft persoon Jan de Vries.* + +R2. *Zorgverzoek R-101 is op 1 juli 2026 geïnitieerd.* + +R3. *Zorgverzoek R-101 is geïnitieerd door huisarts P. Pietersen.* + +R4. *Zorgverzoek R-101 vraagt om beoordeling voor gespecialiseerde GGZ.* + +R5. *Bij zorgverzoek R-101 is als zorgvraag geuit: “somberheidsklachten en +slaapproblemen”.* + +R6. *Professionele verwijzing V-111 betreft zorgverzoek R-101.* + +R7. *Professionele verwijzing V-111 is afgegeven op 1 juli 2026.* + +R8. *Professionele verwijzing V-111 is afgegeven door huisarts P. Pietersen.* + +R9. *Professionele verwijzing V-111 vermeldt echelon “gespecialiseerde +GGZ”.* + +R10. *Professionele verwijzing V-111 vermeldt als vermoeden “depressieve +stoornis”.* + +R11. *Zorgverzoek R-102 is op 14 juli 2026 geïnitieerd door Jan de Vries +voor zichzelf.* + +R12. *Zorgverzoek R-102 vraagt om beoordeling voor dezelfde geuite zorgvraag +als zorgverzoek R-101.* + +**Besloten in domeinreview:** + +- Eén request mag meerdere samenhangende zorgvragen bevatten. +- Zorgvragen worden gesplitst over requests wanneer ze afzonderlijk moeten + worden beoordeeld. +- Een formele verwijzing is een zelfstandig object dat aan een request wordt + gekoppeld. +- Het ontbreken van een formele verwijzing blokkeert zorg niet generiek; bij + spoed of crisis kan zorg al worden geleverd voordat de verwijzing is + ontvangen. + +**Te toetsen:** + +- Is “dezelfde geuite zorgvraag” een expliciete relatie tussen verzoeken, of + wordt samenhang uitsluitend binnen de Referral Case beoordeeld? +- Is een verzoek zonder bekende persoon tijdelijk toegestaan? + +### 3.2 Afzonderlijke binnenkomst + +S1. *Submission S-201 is op 14 juli 2026 om 09:14 ontvangen door instelling +Triqura GGZ.* + +S2. *Submission S-201 is ontvangen via ZorgDomein.* + +S3. *Submission S-201 is verzonden door huisarts P. Pietersen.* + +S4. *Submission S-201 bevat document D-301 van type verwijsbrief.* + +S5. *Submission S-201 representeert zorgverzoek R-101.* + +S6. *Submission S-202 is op 16 juli 2026 om 11:32 ontvangen via beveiligde +e-mail.* + +S7. *Submission S-202 is verzonden door huisarts P. Pietersen.* + +S8. *Submission S-202 bevat document D-302 van type diagnostische +aanvulling.* + +S9. *Submission S-202 vult zorgverzoek R-101 aan.* + +S10. *Submission S-203 is op 16 juli 2026 om 15:05 telefonisch vastgelegd +door medewerker K. Jansen.* + +S11. *De informatiebron van submission S-203 is Jan de Vries.* + +S12. *Submission S-203 representeert zorgverzoek R-102.* + +S13. *Submission S-204 is op 17 juli 2026 als duplicaat van submission S-201 +beoordeeld.* + +S14. *Medewerker K. Jansen heeft de duplicaatbeoordeling op 17 juli 2026 +vastgelegd met reden “identieke ZorgDomein-berichtidentificatie”.* + +**Besloten in domeinreview:** + +- Eén submission kan meerdere inhoudelijke requests bevatten of + representeren. +- Ieder request krijgt een expliciete koppeling met de submission; de + oorspronkelijke binnenkomst wordt niet administratief gekopieerd of + gesplitst. + +**Te toetsen:** + +- Kan één request via meerdere submissions worden ontvangen? +- Is “vult aan” een directe relatie met een request, met een eerdere + submission, of met beide? +- Is een telefonisch geregistreerde binnenkomst altijd een submission? + +### 3.3 Aanmeldingstraject en toewijzing + +C1. *Referral Case C-401 is op 14 juli 2026 geopend voor Jan de Vries.* + +C2. *Referral Case C-401 beoordeelt de samenhangende zorgvraag +“somberheidsklachten en slaapproblemen”.* + +C3. *Submission S-201 is op 14 juli 2026 toegewezen aan Referral Case C-401.* + +C4. *Medewerker K. Jansen heeft submission S-201 aan Referral Case C-401 +toegewezen.* + +C5. *De reden voor de toewijzing van submission S-201 is “eerste binnenkomst +voor deze zorgvraag”.* + +C6. *Submission S-202 is op 16 juli 2026 toegewezen aan Referral Case C-401.* + +C7. *Submission S-203 is op 17 juli 2026 toegewezen aan Referral Case C-401.* + +C8. *Zorgverzoek R-101 wordt sinds 14 juli 2026 behandeld in Referral Case +C-401.* + +C9. *Zorgverzoek R-102 wordt sinds 17 juli 2026 behandeld in Referral Case +C-401.* + +C10. *Referral Case C-402 is op 17 juli 2026 als overlappend met Referral +Case C-401 beoordeeld.* + +C11. *Medewerker K. Jansen heeft op 17 juli 2026 Referral Case C-401 als +leidend aangewezen ten opzichte van Referral Case C-402.* + +C12. *De reden voor de leidende aanwijzing is “dezelfde zorgvraag, tweede +case onbedoeld geopend”.* + +C13. *Referral Case C-402 behoudt zijn identiteit en historie na de leidende +aanwijzing.* + +**Besloten in domeinreview:** + +- Eén request kan uitzonderlijk in meerdere Referral Cases worden behandeld + wanneer verschillende proces- of wettelijke kaders dat vereisen. +- Iedere parallelle behandeling krijgt een expliciete reden en volledige + tijdgebonden historie. + +**Te toetsen:** + +- Hoort een Referral Case bij precies één cliënt, of bij een persoon die pas + tijdens de beoordeling cliënt wordt? +- Moet een toewijzing een geldigheidsperiode hebben, of volstaan + toewijzings- en correctiegebeurtenissen? +- Is “leidend” voldoende, of zijn aparte relaties nodig voor duplicaat, + overlap, splitsing en consolidatie? + +### 3.4 Screeningsactiviteiten + +G1. *Screening G-501 wordt uitgevoerd binnen Referral Case C-401.* + +G2. *Screeningsactiviteit G-502 is op 15 juli 2026 uitgevoerd binnen +screening G-501.* + +G3. *Screeningsactiviteit G-502 is van type telefonisch contact.* + +G4. *Medewerker K. Jansen heeft screeningsactiviteit G-502 uitgevoerd.* + +Screening G-501 leidt niet tot een apart screeningsadvies. De activiteiten +binnen de screening leveren de informatie waarop de beoordelingsfeiten in +§3.5 worden vastgesteld, als onderdeel van hetzelfde acceptatiebesluit. + +**Besloten in domeinreview:** + +- Screening toetst of de instelling een match ziet met de zorgvraag. +- Screening toetst daarnaast beschikbare plek, capaciteit en inhoudelijke + passendheid. +- Tijdens screening kan beperkt contact met de cliënt of verwijzer + plaatsvinden. +- Screeningscontact is meestal niet gefinancierd, maar kan dat bij + uitzondering wel zijn. +- Het screeningsbesluit **is** het acceptatiebesluit; er is geen los + tussenliggend advies (sessielog 19 juli 2026 §5). +- Een positief besluit geeft toegang tot een zorginhoudelijke intake. Contact + binnen de intake is doorgaans wel gefinancierd. +- Uit de intake volgt een afzonderlijk behandeladvies; de mogelijke + uitkomsten daarvan zijn nog niet vastgesteld (nader onderzoek, zie §7). + +### 3.5 Beoordeling en acceptatiebesluit + +**Route 1 — inhoudelijke match en capaciteit beschikbaar** + +A1. *Beoordeling van Referral Case C-401 bevestigt op 17 juli 2026 een +inhoudelijke match met de geuite zorgvraag.* + +A2. *Beoordeling van Referral Case C-401 bevestigt op 17 juli 2026 +beschikbare capaciteit bij zorgprogramma Stemming.* + +A3. *Acceptatiebesluit A-701 betreft Referral Case C-401.* + +A4. *Acceptatiebesluit A-701 is genomen op 17 juli 2026 door medewerker +K. Jansen.* + +A5. *Medewerker K. Jansen handelde bij acceptatiebesluit A-701 op grond van +beslisbevoegdheid B-801.* + +A6. *Acceptatiebesluit A-701 heeft besluituitkomst “geaccepteerd”.* + +A7. *Acceptatiebesluit A-701 heeft vervolgroute “intake direct plannen” bij +zorgprogramma Stemming.* + +A8. *Zorgepisode E-901 is ontstaan uit acceptatiebesluit A-701.* + +A9. *Zorgepisode E-901 is gestart op 17 juli 2026.* + +A10. *Referral Case C-401 is na acceptatiebesluit A-701 afgesloten met +uitkomst “geaccepteerd”.* + +**Route 2A — inhoudelijke match, geen capaciteit: accepteren en wachten** + +A11. *Beoordeling van Referral Case C-403 bevestigt op 20 juli 2026 een +inhoudelijke match met de geuite zorgvraag.* + +A12. *Beoordeling van Referral Case C-403 constateert op 20 juli 2026 geen +beschikbare capaciteit bij zorgprogramma Trauma.* + +A13. *Acceptatiebesluit A-711 betreft Referral Case C-403.* + +A14. *Acceptatiebesluit A-711 heeft besluituitkomst “geaccepteerd”.* + +A15. *Acceptatiebesluit A-711 heeft vervolgroute “intakewachtlijst” bij +zorgprogramma Trauma.* + +A16. *Zorgepisode E-902 is ontstaan uit acceptatiebesluit A-711, ook al is de +intake nog niet gestart.* + +**Route 2B — inhoudelijke match, geen capaciteit: afwijzen** + +A17. *Beoordeling van Referral Case C-404 bevestigt op 21 juli 2026 een +inhoudelijke match met de geuite zorgvraag.* + +A18. *Beoordeling van Referral Case C-404 constateert op 21 juli 2026 geen +beschikbare capaciteit bij zorgprogramma Trauma.* + +A19. *Acceptatiebesluit A-721 betreft Referral Case C-404.* + +A20. *Acceptatiebesluit A-721 heeft besluituitkomst “afgewezen”.* + +A21. *Acceptatiebesluit A-721 motiveert de afwijzing met “geen capaciteit bij +zorgprogramma Trauma”.* + +A22. *Acceptatiebesluit A-721 heeft vervolgroute “doorverwijzen”.* + +A23. *Referral Case C-404 is na acceptatiebesluit A-721 afgesloten met +uitkomst “afgewezen”; er ontstaat geen zorgepisode.* + +Route 2A en 2B tonen dat capaciteit invoer is voor het besluit, maar de +uitkomst niet automatisch bepaalt (sessielog 19 juli 2026 §6). Bij afwijzing +is een concrete onderbouwing verplicht; “geen capaciteit” of “geen +acceptatie” zonder verdere duiding is onvoldoende, omdat dat laatste alleen +de uitkomst herhaalt. + +**Beantwoord in domeinreview (19 juli 2026):** + +- Besluituitkomst is beperkt tot `geaccepteerd` / `afgewezen`. `Doorverwijzen` + en het afsluiten van de case zijn vervolgroutes, geen besluituitkomsten. +- Elk positief besluit laat een zorgepisode ontstaan, ook wanneer de + vervolgroute intakewachtlijst is — niet pas bij de feitelijke start van de + intake. + +**Nog te toetsen:** + +- Is `aanvullende_informatie_nodig` een open processtatus vóór een definitief + besluit, of toch een derde besluituitkomst? Voorlopige aanname: open + processtatus, geen besluituitkomst (sessielog 19 juli 2026 §7). +- Kan een case meerdere opeenvolgende besluiten hebben na heroverweging? +- Welk besluit is dan geldig en hoe wordt intrekking of correctie vastgelegd? +- Kan een geaccepteerde case vóór de feitelijke start van de intake alsnog + worden ingetrokken, en wat gebeurt dan met de al ontstane zorgepisode? + +### 3.6 Zorginhoudelijke intake en behandeladvies + +I1. *Klinische intake I-1001 is gestart na acceptatiebesluit A-701.* + +I2. *Intakecontact I-1002 is op 20 juli 2026 uitgevoerd binnen klinische +intake I-1001.* + +I3. *Intakecontact I-1002 is een gefinancierd contact.* + +I4. *Klinische intake I-1001 heeft geleid tot behandeladvies B-1101.* + +I5. *Behandeladvies B-1101 adviseert behandeling binnen zorgprogramma +Stemming.* + +De financiering van een concreet contact is een afzonderlijk feit. Het type +fase bepaalt niet zonder uitzondering of een contact declarabel is. + +## 4. Voorlopige uniqueness- en optionaliteitsregels + +Deze regels zijn hypotheses voor domeinreview, geen definitieve +cardinaliteiten. + +### Referral Request + +- Elk request heeft één stabiele identiteit. +- Elk request betreft op enig moment precies één persoon of cliënt. +- Elk request heeft minstens één initiator. +- Elk request bevat één of meer samenhangende geuite zorgvragen. +- Zorgvragen die afzonderlijk moeten worden beoordeeld horen in afzonderlijke + requests. +- Een request kan zonder formele verwijzing bestaan. +- Een formele verwijzing heeft een eigen identiteit en wordt gekoppeld aan + het request waarop zij betrekking heeft. +- Acceptatie of zorgverlening vereist niet generiek dat de formele verwijzing + al is ontvangen; toepasselijke juridische en financiële gevolgen worden + afzonderlijk door protocolregels bewaakt. +- Een request kan door meerdere submissions worden gerepresenteerd of + aangevuld. +- Een request kan alleen bij uitzondering aan meer dan één case worden + gekoppeld, vanwege verschillende proces- of wettelijke kaders en met een + expliciete reden en tijdgebonden historie. + +### Referral Submission + +- Elke submission heeft één stabiele identiteit. +- Elke submission heeft precies één ontvangstmoment en één ontvangstkanaal. +- Elke submission heeft minstens één informatiebron of afzender, eventueel + “onbekend”. +- Een submission kan nul documenten bevatten, bijvoorbeeld bij telefoon. +- Een submission kan nul, één of meerdere requests representeren; iedere + bekende relatie wordt expliciet vastgelegd. +- Een submission wordt nooit overschreven door een latere aanvulling. +- De koppeling van een submission aan een case is historiseerbaar en wordt + door een mens bevestigd. + +### Referral Case + +- Elke case heeft één stabiele identiteit. +- Elke case behandelt één institutioneel als samenhangend beoordeelde + zorgvraag. +- Een case kan door meerdere submissions en requests worden gevoed. +- Parallelle cases zijn toegestaan met een expliciete reden. +- Logische consolidatie verwijdert geen case, request of submission. +- Een afgesloten case kan bij herbeoordeling een nieuwe besluitronde krijgen; + de precieze statusmachine staat nog open. + +### Care Acceptance Decision + +- Elk besluit betreft precies één Referral Case. +- Elk besluit heeft precies één beslisser en besluitdatum. +- De beslisser moet op het beslismoment de vereiste bevoegdheid hebben. +- Elk besluit heeft precies één besluituitkomst: `geaccepteerd` of + `afgewezen`. +- De onderliggende beoordelingen (inhoudelijke match, beschikbare plek, + capaciteit) zijn losse feiten bij hetzelfde besluit, geen aparte + voorafgaande beslissing. +- Elk besluit heeft precies één vervolgroute, bijvoorbeeld intake direct + plannen, intakewachtlijst, spoedroute, doorverwijzen of case afsluiten. +- Bij besluituitkomst `afgewezen` is een concrete onderbouwing verplicht; + het herhalen van de uitkomst (“geen acceptatie”) is geen geldige + onderbouwing. +- Capaciteit is invoer voor het besluit maar bepaalt de besluituitkomst niet + automatisch: bij ontbrekende capaciteit zijn zowel `geaccepteerd` met + vervolgroute intakewachtlijst als `afgewezen` met onderbouwing + capaciteitstekort geldige uitkomsten. +- Alleen een besluit met uitkomst `geaccepteerd` kan een zorgepisode laten + ontstaan, ongeacht de gekozen vervolgroute. +- Een zorgepisode verwijst naar het acceptatiebesluit waaruit zij ontstond. +- Een besluit bewijst geen behandeltoestemming of verantwoordelijkheid. +- Het behandeladvies na de intake is een afzonderlijk klinisch feit en geen + herhaling van het acceptatiebesluit; welke vervolgrichtingen het + behandeladvies kent en wie daartoe bevoegd is, is nog niet vastgesteld + (nader onderzoek, zie §7). + +## 5. Scenariotoets + +### Scenario 1 — huisartsverwijzing + +Benodigde objecten: + +- één Referral Request; +- één zelfstandig Professional Referral, gekoppeld aan het request; +- één Referral Submission; +- één Referral Case; +- na positief besluit één Care Acceptance Decision en één Clinical Care + Episode. + +Dit scenario toont dat verwijsdatum en ontvangstdatum verschillende feiten +zijn. + +### Scenario 2 — zelfaanmelding + +Benodigde objecten: + +- één Referral Request, geïnitieerd door de cliënt; +- één Referral Submission, bijvoorbeeld telefonisch of via het portaal; +- één Referral Case; +- geen Professional Referral. + +Dit scenario toont dat `Referral Request` breder moet zijn dan de Nederlandse +VERWIJZING. + +### Scenario 3 — spoed of crisis vóór formele verwijzing + +Benodigde objecten: + +- één Referral Request, bijvoorbeeld geïnitieerd door de cliënt, crisisdienst + of andere informatiebron; +- minstens één Referral Submission; +- één Referral Case; +- eventueel een positief Care Acceptance Decision en Clinical Care Episode + voordat een Professional Referral is ontvangen; +- een later ontvangen Professional Referral met een eigen Submission en een + koppeling aan hetzelfde Referral Request. + +Dit scenario toont dat een formele verwijzing geen bestaansvoorwaarde is voor +het request, de case of generiek voor zorgverlening. Financiële en juridische +vereisten blijven afzonderlijke protocolregels. + +### Scenario 4 — aanvullende informatie + +Benodigde objecten: + +- hetzelfde Referral Request; +- een nieuwe Referral Submission met eigen bron, tijdstip en documenten; +- dezelfde Referral Case, na menselijke toewijzing. + +Dit scenario toont waarom request, submission en case niet tot één record +kunnen worden samengevoegd. + +### Scenario 5 — dubbele of overlappende instroom + +Benodigde objecten: + +- oorspronkelijke requests en submissions blijven behouden; +- een mens beoordeelt duplicaat of overlap; +- submissions en requests worden aan de passende case gekoppeld; +- bij twee cases wordt één case eventueel als leidend aangewezen; +- de andere case wordt niet verwijderd of technisch samengevoegd. + +Dit scenario toont dat samenvoegen een expliciete, geaudite relatie is. + +### Scenario 6 — capaciteitstekort bij inhoudelijke match + +Benodigde objecten: + +- twee vergelijkbare Referral Cases met bevestigde inhoudelijke match en + bevestigd capaciteitstekort bij hetzelfde zorgprogramma; +- Route 2A: één Care Acceptance Decision met uitkomst `geaccepteerd` en + vervolgroute intakewachtlijst, gevolgd door een Clinical Care Episode die + al ontstaat vóór de feitelijke start van de intake; +- Route 2B: één Care Acceptance Decision met uitkomst `afgewezen`, een + concrete capaciteitsonderbouwing en vervolgroute doorverwijzen, zonder dat + een Clinical Care Episode ontstaat. + +Dit scenario toont dat capaciteit een beoordelingsfeit is en geen +automatische bepaler van de besluituitkomst, en dat "geaccepteerd" niet +gelijkstaat aan "intake gestart". + +## 6. Voorlopige conclusie over Referral Request + +`Referral Request` heeft naar verwachting een eigen identiteit nodig. + +Zonder dit object ontstaan twee problemen: + +1. meerdere submissions van hetzelfde zorgverzoek zijn alleen via vrije + interpretatie aan elkaar te relateren; +2. een formele verwijzing en een zelfaanmelding moeten kunstmatig in één + Nederlands begrip VERWIJZING worden gedwongen. + +De Nederlandse **VERWIJZING** valt daarom niet volledig samen met Referral +Request. Zij is een zelfstandig, professioneel geïnitieerd object met eigen +feiten, zoals verwijzer, verwijsdatum, echelon en geldigheid, dat aan het +zorgverzoek wordt gekoppeld. + +Hierdoor kan het zorgverzoek al bestaan en kan in spoed- of crisissituaties +zorg worden geleverd voordat de formele verwijzing binnenkomt. De latere +verwijzing vult de formele en financiële onderbouwing aan, maar herschrijft +het oorspronkelijke request niet. + +Of één request achtereenvolgens meerdere formele verwijzingen kan hebben, +bijvoorbeeld bij correctie of vervanging, wordt pas in het logische model +uitgewerkt. De append-only audit voorkomt ondertussen informatieverlies. + +## 7. Eerste domeinreview + +**Beantwoord (domeinreview 19 juli 2026):** + +1. Screeningsadvies en acceptatie zijn in de praktijk hetzelfde vastgelegde + besluit. Dit is verwerkt in §2–§5 hierboven: er is geen apart, voorafgaand + screeningsadvies meer, en het besluit draagt zelf de onderliggende + beoordelingen, de besluituitkomst, de vervolgroute en, bij afwijzing, de + onderbouwing. + +**Nog open, nader onderzoek nodig:** + +2. Welke mogelijke uitkomsten heeft het behandeladvies na de intake, en wie + is bevoegd die vast te stellen? Vastgesteld is alleen dat het + behandeladvies zelf al de vervolgrichting geeft — net als het + acceptatiebesluit is er geen apart, voorafgaand advies. De concrete + vervolgrichtingen en de bijbehorende bevoegdheid zijn geparkeerd (sessielog + 19 juli 2026). +3. Kan een case meerdere opeenvolgende acceptatiebesluiten hebben na + heroverweging, en zo ja, welk besluit is dan geldig? +4. Kan een geaccepteerde case vóór de feitelijke start van de intake alsnog + worden ingetrokken, en wat gebeurt dan met de al ontstane zorgepisode? +5. Is `aanvullende_informatie_nodig` een open processtatus of een derde + besluituitkomst? + +Na beantwoording van 3–5 volgen pas: + +1. definitieve uniqueness- en optionaliteitsconstraints (§4 hierboven is een + tussenstand, nog niet definitief bevestigd); +2. de statusmachine van Referral Case en Care Acceptance Decision; +3. afleiding van entiteiten en cardinaliteiten; +4. verwerking in `../besluiten/besluitenlog-datamodel-2026-07-18.md`; +5. synchronisatie van `../begrippenlijst-kernmodel.md` en + `../deelmodellen/model-aanmelding.md`. diff --git a/docs/datamodel/onderzoek/onderzoek-engelstalige-epd-terminologie.md b/docs/datamodel/onderzoek/onderzoek-engelstalige-epd-terminologie.md new file mode 100644 index 0000000..9f84cb1 --- /dev/null +++ b/docs/datamodel/onderzoek/onderzoek-engelstalige-epd-terminologie.md @@ -0,0 +1,319 @@ +# Onderzoek Engelstalige EPD-terminologie — referral en instroom + +**Status:** onderzoeksrapport, aanbeveling nog niet als begrippenbesluit verwerkt +**Datum:** 18 juli 2026 +**Aanleiding:** de werktermen `Inbound Care Signal` en `Access Assessment Case` uit `../begrippenlijst-kernmodel.md` zijn onvoldoende vanzelfsprekend voor Engelstalige ontwikkelaars en zorgprofessionals +**Scope:** Amerikaanse EHR’s, behavioral-health EHR’s, HL7 FHIR, Amerikaanse closed-loop referral guidance en NHS-terminologie + +## 1. Onderzoeksvraag + +Welke Engelse technische termen passen het beste bij: + +1. **AANMELDSIGNAAL** — iedere afzonderlijke binnenkomst met eigen bron, ontvangsttijd, documenten en oorspronkelijk geuite zorgvraag; +2. **AANMELDINGSTRAJECT** — de institutionele workflow waarin één samenhangende zorgvraag wordt beoordeeld, eventueel gevoed door meerdere binnenkomsten, vóór klinische intake en formele acceptatie? + +## 2. Hoofdconclusie + +De twijfel bij de huidige werktermen is terecht: + +- **`Inbound Care Signal` afwijzen.** `signal` is geen gangbare EHR-term voor een ontvangen aanmelding. In zorg-IT klinkt het eerder als klinisch signaal, alert of vroegsignaal. +- **`Access Assessment Case` afwijzen als canonieke naam.** De woorden zijn begrijpelijk, maar deze combinatie komt niet herkenbaar terug in de onderzochte EHR’s of standaarden. `access assessment` beschrijft eerder een activiteit binnen een workflow dan de beheerde workflow zelf. + +Amerikaanse EHR’s gebruiken vrijwel overal **referral** als overkoepelende term voor de beheerde instroomworkflow. Ze maken in publieke documentatie alleen niet altijd scherp onderscheid tussen: + +- het zorgverzoek; +- de ontvangen verzending of documentenbundel; +- de interne workflow die het verzoek behandelt. + +Dat onderscheid is voor Triqura wel nodig. Daarom is de sterkste oplossing geen simpele hernoeming, maar een model met drie begrippen: + +1. **Referral Request — `referral_request`** + Het semantische verzoek om zorg of beoordeling, geïnitieerd door professional, organisatie, cliënt of vertegenwoordiger. +2. **Referral Submission — `referral_submission`** + Eén afzonderlijke ontvangst of indiening, via bijvoorbeeld portaal, telefoonregistratie, e-mail, eFax of koppeling, met eigen bron en documenten. +3. **Referral Case — `referral_case`** + De door de ontvangende instelling beheerde workflow waarin submissions en requests worden beoordeeld, aangevuld, getrieerd en afgesloten. + +Voor de huidige Nederlandse begrippen betekent dit voorlopig: + +- **AANMELDSIGNAAL → `Referral Submission`** +- **AANMELDINGSTRAJECT → `Referral Case`** +- **VERWIJZING → waarschijnlijk `Referral Request`**, voor zover het de formele zorgvraag/verwijzing representeert + +De precieze grens tussen `Referral Request` en de bestaande Nederlandse entiteit VERWIJZING moet in de volgende feitenronde worden vastgesteld. + +## 3. Wat de leveranciers laten zien + +### 3.1 Epic + +Epic publiceert een eersteklas `REFERRAL`-object: + +- classificeert referrals als `Internal`, `Incoming` of `Outgoing`; +- kent statussen als `New Request`, `Open`, `Pending Review`, `Authorized`, `Denied`, `Closed` en `Incomplete`; +- bewaart bron, reden, prioriteit, ontvangstdatum en besluitdatum; +- kent triage-uitkomsten zoals `Accept`, `Reject`, `Redirect`, `Information Request`, `Respond` en `Convert`; +- heeft een afzonderlijke referralhistorie. + +Dit lijkt sterk op het Nederlandse AANMELDINGSTRAJECT: één beheerd object met lifecycle en triage. Epic noemt dit eenvoudigweg een **Referral**. + +Epic publiceert daarnaast `ServiceRequest (Referral)` als FHIR-projectie en een `Incoming Referral Notification` als uitwisselingsinterface. Dat bevestigt dat een bericht, verzoek en beheerd referralobject niet noodzakelijk hetzelfde zijn. + +**Les voor Triqura:** `referral` is herkenbaar voor de workflow, maar zonder suffix te ambigu wanneer ook request en submission afzonderlijk worden gemodelleerd. + +### 3.2 Oracle Health + +Oracle Health gebruikt eveneens **Referral** voor het beheerde object: + +- actieve en eerdere referrals; +- status; +- referring en referred providers; +- attachments; +- comments; +- activity timeline; +- gekoppelde afspraken; +- requested start date en service-by date. + +Een nieuwe referral begint in de UI als **Referral Order**. De order is het verzoek; de Referral Management-functionaliteit beheert vervolgens de lifecycle. + +**Les voor Triqura:** `Referral Order` is te smal voor zelfaanmelding en informele instroom. `Referral` past bij de ontvangende workflow. + +### 3.3 athenahealth + +athenahealth publiceert vooral: + +- `Referral Order`; +- `Referral/Auth`; +- attachments gekoppeld aan een referral authorization order; +- generieke `Patient Cases`. + +`Referral/Auth` vermengt verwijzing en verzekeringsautorisatie. `Patient Case` is te breed en in de publieke documentatie niet specifiek genoeg verbonden aan instroom. + +**Les voor Triqura:** `order`, `authorization` en een ongekwalificeerde `patient_case` passen niet als generieke kernnamen. + +### 3.4 Netsmart — behavioral health + +Netsmart is voor de GGZ-context bijzonder relevant. Referral Manager: + +- verzamelt **incoming referrals** uit onder andere eFax en PDF-upload; +- organiseert referral packets, tijdlijnen, notities, communicatie, taken en wachtrijen rond één referral; +- ondersteunt acceptatie en afwijzing; +- spreekt expliciet over het **referral intake process**; +- zet een geaccepteerde referral door naar een afzonderlijke **pre-admit workflow** in het EHR. + +Netsmart gebruikt dus: + +- `incoming referral` voor de ontvangen instroom; +- `referral record`/`referral` als beheerd lifecycle-object; +- `referral packet` voor de documentenbundel; +- `referral intake` voor het proces; +- `pre-admit` pas na acceptatie. + +**Les voor Triqura:** referralterminologie past ook bij behavioral health. `intake` is daar echter breder en administratief gebruikt, terwijl Triqura `INTAKE` al reserveert voor het klinische onderzoekstraject. Daarom is `Referral Intake Case` voor Triqura onnodig verwarrend. + +### 3.5 NextGen en Qualifacts + +NextGen gebruikt vooral `Referral Order` binnen een encounter en een `Intake Template` voor gegevens binnen dat contact. `Case` heeft er een andere betekenis: het groepeert encounters voor juridische of verzekeringsdoeleinden. + +Qualifacts gebruikt publiek vooral `intake`, `case management` en configureerbare workflows, maar publiceert onvoldoende technisch detail om een zelfstandig referralobject betrouwbaar af te leiden. + +**Les voor Triqura:** `case` moet altijd worden gekwalificeerd als `referral_case`; een kaal `case` is te breed. + +## 4. Wat de standaarden laten zien + +### 4.1 HL7 FHIR + +FHIR maakt nuttige conceptuele scheidingen: + +- **`ServiceRequest`** — voorstel, plan of order om een dienst te laten uitvoeren; +- **`Task`** — administratieve coördinatie en voortgang van de uitvoering; +- **`EpisodeOfCare`** — periode waarin een organisatie verantwoordelijkheid draagt; +- **`Encounter`** — feitelijk contact of interactie. + +FHIR beschrijft een intakevoorbeeld waarin: + +1. een `ServiceRequest` wordt ontvangen; +2. eligibility en capaciteit worden beoordeeld; +3. een geplande `EpisodeOfCare` kan worden gemaakt; +4. verdere assessment volgt; +5. na acceptatie een plan ontstaat en de episode actief wordt. + +Triqura heeft bewust een andere semantische grens: de ZORGEPISODE ontstaat pas bij formele acceptatie en acceptatie impliceert nog niet automatisch alle behandelverantwoordelijkheid. Daarom moet het pre-acceptatietraject niet rechtstreeks `EpisodeOfCare` worden genoemd. + +Een Triqura Referral Submission kan bij uitwisseling bestaan uit meerdere FHIR-resources, bijvoorbeeld `ServiceRequest`, `DocumentReference`, `Communication` en provenance. Het lokale object hoeft dus geen FHIR-resourcenaam te dragen. + +### 4.2 Amerikaanse ONC/360X + +360X gebruikt: + +- `referral request`; +- `referral order`; +- een persistente `Referral Identifier`; +- een closed-loop `referral workflow`; +- statussen en terugkoppelingen tot de referral is gesloten. + +De Amerikaanse definitie van **Referral Order** is doorgaans provider-authored. Die term sluit zelfaanmelding en instroom vanuit niet-klinische bronnen onvoldoende in. + +**Les voor Triqura:** gebruik `request` in plaats van `order` voor het inhoudelijke verzoek, en modelleer de ontvangende workflow afzonderlijk. + +### 4.3 NHS + +De NHS definieert: + +- **Service Request** — verzoek om zorgdiensten; +- **Referral Request** — subtype voor een zorgdienst, inclusief expliciete zelfverwijzing; +- **Patient Pathway** — de bredere route vanaf het eerste ontvangen verzoek, mogelijk over langere tijd en meerdere behandelperioden. + +De NHS vermeldt bovendien dat een mondeling en later schriftelijk bevestigd verzoek normaliter als één referral wordt verwerkt. Dit ondersteunt het onderscheid tussen: + +- één semantisch request; +- meerdere ontvangsten of representaties van dat request. + +`Patient Pathway` is voor Triqura te breed: het kan chronische of recidiverende zorg en meerdere referral-to-treatment periods omvatten. + +## 5. Beoordeling van naamparen + +### Optie A — Referral Submission / Referral Case + +**Identifiers:** `referral_submission` / `referral_case` +**Advies:** voorkeur + +Sterke punten: + +- voor Amerikaanse developers direct herkenbaar als onderdeel van referral management; +- submission duidt één ontvangst aan; +- case duidt één beheerde workflow-instance aan; +- self-referral kan expliciet als referral request door de cliënt worden geïnitieerd; +- geen botsing met admission, encounter of EpisodeOfCare; +- laat ruimte voor een afzonderlijke Referral Request. + +Risico’s: + +- `Referral Submission` is een lokale technische term, geen universele EHR-standaardterm; +- `case` kan elders financieel of juridisch betekenen en moet daarom altijd als `referral_case` worden geschreven; +- de definitie moet expliciet maken dat referral ook self-referral en andere toegestane bronnen omvat. + +### Optie B — Care Access Submission / Care Access Case + +**Identifiers:** `care_access_submission` / `care_access_case` +**Advies:** inhoudelijk inclusief, maar minder idiomatisch + +Sterke punten: + +- neutraler voor zelfaanmelding en niet-formele bronnen; +- benadrukt toegang tot zorg in plaats van verwijzing door een professional. + +Risico’s: + +- veel minder herkenbaar in de onderzochte EHR-documentatie; +- `access` kan voor developers systeem-, dossier- of autorisatietoegang betekenen; +- het verband met referral management en closed-loop uitwisseling wordt minder zichtbaar. + +### Optie C — Referral Submission / Referral Intake Case + +**Identifiers:** `referral_submission` / `referral_intake_case` +**Advies:** niet kiezen voor Triqura + +Sterke punten: + +- zeer expliciet over de instroomfase; +- sluit aan bij behavioral-healthtaal als `referral intake process`. + +Risico’s: + +- Triqura kent al een afzonderlijke klinische INTAKE; +- Amerikaanse systemen gebruiken intake zowel administratief als klinisch; +- vergroot precies de begripsverwarring die het kernmodel probeert te voorkomen. + +### Optie D — Inbound Care Submission / Access Assessment Case + +**Identifiers:** `inbound_care_submission` / `access_assessment_case` +**Advies:** niet kiezen + +Sterke punten: + +- domeinneutraal; +- inhoudelijk te begrijpen met een definitie ernaast. + +Risico’s: + +- geen herkenbaar naamgebruik in de onderzochte EHR’s; +- te abstract en samengesteld; +- `assessment` klinkt als één activiteit; +- `inbound care` klinkt eerder als gegevenslogistiek dan als cliëntinstroom. + +## 6. Aanbevolen conceptueel model + +De terminologische onduidelijkheid komt mede doordat AANMELDSIGNAAL nu twee betekenissen bevat: de ontvangen verzending én het inhoudelijke zorgverzoek. + +De aanbevolen scheiding is: + +```text +Referral Request + het inhoudelijke verzoek om zorg of beoordeling + +Referral Submission + één ontvangen representatie of aanvulling van een request + +Referral Case + de ontvangende workflow die submissions en requests behandelt +``` + +Voorbeelden: + +- Een huisarts stuurt een verwijzing met brief: één Referral Request, ontvangen via één Referral Submission, behandeld in één Referral Case. +- De huisarts stuurt later aanvullende diagnostiek: dezelfde Referral Request en Referral Case, tweede Referral Submission. +- De cliënt belt daarnaast zelf met aanvullende informatie: derde Referral Submission bij dezelfde Referral Case. +- Twee instanties melden onafhankelijk dezelfde zorgvraag: twee requests of submissions kunnen na menselijke beoordeling aan één Referral Case worden gekoppeld. +- Een gelijktijdige crisisvraag en reguliere hulpvraag kunnen ieder een eigen Referral Case krijgen. + +De cardinaliteiten mogen nog niet uit deze voorbeelden worden afgeleid. Eerst moeten de elementaire feitzinnen worden gevalideerd. + +## 7. Aanbeveling voor de begrippenlijst + +Nog niet automatisch aanpassen; eerst inhoudelijk bevestigen: + +1. vervang `Inbound Care Signal` door **Referral Submission**; +2. vervang `Access Assessment Case` door **Referral Case**; +3. voeg **Referral Request** toe als afzonderlijk begrip; +4. herbeoordeel of de huidige VERWIJZING volledig samenvalt met Referral Request of slechts één subtype/bron daarvan is; +5. behoud **Clinical Intake Assessment** als afzonderlijk klinisch proces na of rond acceptatie; +6. behoud **Clinical Care Episode** voor de geaccepteerde zorgperiode. + +## 8. Betrouwbaarheid en beperkingen + +- Epic EHI-exporttabellen geven sterke aanwijzingen voor het logische exportmodel, maar zijn niet automatisch het operationele interne databaseschema. +- Oracle, athenahealth, Netsmart, NextGen en Qualifacts publiceren vooral product-, UI- en API-termen. +- FHIR is een uitwisselingsmodel en geen verplicht lokaal domeinmodel. +- Marketingdocumentatie is gebruikt om gangbaar taalgebruik te beoordelen, niet om cardinaliteiten of juridische betekenis af te leiden. +- Er bestaat geen universele EHR-term voor “iedere afzonderlijke binnenkomst ongeacht kanaal”. `Referral Submission` is daarom een expliciet gekozen lokale technische term. + +## 9. Bronnen + +### Amerikaanse EHR’s + +- Epic, `REFERRAL`: https://open.epic.com/EHITables/GetTable/REFERRAL.htm +- Epic, `REFERRAL_2` triage decision: https://open.epic.com/EHITables/GetTable/REFERRAL_2.htm +- Epic, `REFERRAL_HIST`: https://open.epic.com/EHITables/GetTable/REFERRAL_HIST.htm +- Epic, FHIR interfaces: https://open.epic.com/Interface/FHIR +- Oracle Health, Referrals: https://docs.oracle.com/en/industries/health/oracle-health-ehr/ehrfg/referrals.html +- Oracle Health, Create Referral: https://docs.oracle.com/en/industries/health/oracle-health-ehr/ehrfg/create-referral.html +- athenahealth, Referral Authorization: https://docs.athenahealth.com/api/api-ref/referral-authorization +- athenahealth, Patient Cases: https://docs.athenahealth.com/api/api-ref/document-type-patient-case +- Netsmart, Referral Management: https://www.ntst.com/carefabric/population-health-management/referral-management +- Netsmart, referral intake workflow: https://www.ntst.com/blog/2025/optimizing-human-services-intake-with-ai-and-automation +- NextGen, Referrals: https://docs.nextgen.com/en-US/nextgenc2ae-adaptive-content-engine-help-enterprise-8-3-1-3288208/add-referrals-251359 +- NextGen, Cases: https://docs.nextgen.com/en-US/nextgenc2ae-enterprise-ehr-help-3270157/cases-in-nextgenc2ae-enterprise-ehr-324977 +- Qualifacts, InSync EHR: https://www.qualifacts.com/about/insync-ehr-platform/ + +### Standaarden en guidance + +- HL7 FHIR ServiceRequest: https://hl7.org/fhir/R5/servicerequest.html +- HL7 FHIR Task: https://hl7.org/fhir/R5/task.html +- HL7 FHIR EpisodeOfCare: https://hl7.org/fhir/R5/episodeofcare.html +- HL7 FHIR Encounter: https://hl7.org/fhir/R5/encounter.html +- HL7 US SDOH Referral Management Task: https://hl7.org/fhir/us/sdoh-clinicalcare/STU2.3/StructureDefinition-SDOHCC-TaskForReferralManagement.html +- ONC 360X: https://oncprojectracking.healthit.gov/wiki/spaces/TechLab360X/pages/18776120/360X+Home +- US Health IT Referral Order: https://isp.healthit.gov/uscdi-data/referral-order +- NHS Service Request: https://www.datadictionary.nhs.uk/classes/service_request.html +- NHS Referral Request: https://archive.datadictionary.nhs.uk/DD%20Release%20May%202024/classes/referral_request.html +- NHS Patient Pathway: https://www.datadictionary.nhs.uk/classes/patient_pathway.html diff --git a/docs/datamodel/onderzoek/onderzoek-leveranciers.md b/docs/datamodel/onderzoek/onderzoek-leveranciers.md new file mode 100644 index 0000000..0e38ccc --- /dev/null +++ b/docs/datamodel/onderzoek/onderzoek-leveranciers.md @@ -0,0 +1,193 @@ +# Onderzoek: datamodellen en publieke API's van Nederlandse ECD/EPD-leveranciers + +**Status:** onderzoeksrapport t.b.v. datamodel-discovery (input, geen besluiten) +**Datum:** 18 juli 2026 +**Onderzoeker:** research-agent "leveranciers" +**Relatie tot discovery:** dit rapport toetst nergens besluiten uit `../deelmodellen/datamodel-discovery.md` terug — het levert vergelijkingsmateriaal per deelgebied (§5-besluiten) en markeert hooguit open vragen. + +--- + +## 1. Aanpak en betrouwbaarheid per bron + +Onderzocht via webresearch (juli 2026): Nedap Ons, Medicore, PinkRoccade Zorg (mijnCaress), Adapcare (Pluriform Zorg), en kort SDB/USER, ZilliZ en Praktijkdata. Betrouwbaarheid verschilt sterk: + +| Leverancier | Publieke API-docs | Diepgang van dit onderzoek | +|---|---|---| +| **Nedap Ons** | ✅ Volledig: [ons-api.nl](https://ons-api.nl/) + downloadbare OpenAPI-spec (2,8 MB, 772 paden) | Hoog — spec integraal geanalyseerd | +| **Medicore** | ❌ Alleen marketingpagina's over "Mint" API-platform | Laag — geen resource-niveau vindbaar | +| **PinkRoccade mijnCaress** | ❌ Geen publieke documentatie | Laag — alleen persberichten/partnerpagina's | +| **Adapcare Pluriform Zorg** | ❌ Geen publieke documentatie ("Care Connector") | Laag — alleen productpagina's | +| **SDB USER (ex-Avinty)** | ❌ Geen publieke documentatie ("Connect Service") | Laag | +| **ZilliZ / Praktijkdata** | ❌ Geen publieke documentatie | Zeer laag | + +**Belangrijkste methodische bevinding:** van de onderzochte leveranciers publiceert alleen **Nedap** zijn API-model openbaar. Al het onderstaande over de anderen is afgeleid uit marketingmateriaal en derden (integratiepartners) — dat is expliciet gemarkeerd. De Nedap-analyse is daarentegen gebaseerd op de letterlijke OpenAPI-specificatie ([ons-api.nl/assets/openapi.json](https://ons-api.nl/assets/openapi.json), opgehaald 18-07-2026). + +--- + +## 2. Nedap Ons — volledige OpenAPI-analyse + +Nedap Ons is primair een VVT/GHZ/GGZ-suite. De API ([ons-api.nl](https://ons-api.nl/)) is REST, zonder versienummers in URL's (resources worden 6 maanden vóór verwijdering gedeprecate), met certificaat-authenticatie en rate limiting ("4 requests tegelijkertijd per certificaat") — bron: [API-eigenschappen](https://ons-api.nl/techniek/apis/API_eigenschappen.html). De huidige API's vervingen op 19-11-2025 de oude per-applicatie-API's ([API-overzicht](https://ons-api.nl/techniek/apis/APIS.html)). + +### 2.1 Domeinindeling (tags in de spec) + +De spec groepeert ~250 resource-typen in modules. Relevant voor het ECD: + +| Module | Kern-resources | +|---|---| +| **administration** | Client, ClientAddress, Bsn, Agbcode, Referral, CareProvider, Practitioner (met AgbCode/BigCode/Profession), ClientContactRelation(+Type), ClientEmployeeRelation(+Type), Location, LocationAssignment (incl. **WaitingList**), Insurance, Document, Team, ExpertiseProfile/ExpertiseGroup | +| **dossier** | Report, ReportType, ReportEntry, SoapReportEntry, CarePlan, CarePlanEntry, CarePlanAgreement, CarePlanSignatureRequirement, Goal/GoalEntry, Demand/DemandEntry, Domain, Action/ActionEntry, ClientNote, MedicalNote, SystemNote, Alert, RestrictiveMeasureRegistration (dwang/vrijheidsbeperking) | +| **dossier.episodes** | Episode, SubGoal, Action | +| **dossier.medical** | Problem, MedicalSummary, PropensityToAdverseReaction (allergieën), advance_directives, involuntary_care (LegalStatus, Incompetence — Wzd/Wvggz), **dsm.Classification / dsm.ClassificationSeries** | +| **dossier.omaha** | Omaha-classificatie (VVT-verpleegkundig: Problem, InterventionCategory, InterventionTarget) | +| **agenda** | AgendaSeries, AgendaOccurrence, ClientAbsenceOccurrence, Label, Unavailability, Reservation | +| **carepath** | CarePath, Template, ModuleTemplate, IntentTemplate (zorgpaden als sjablonen) | +| **dbc.ggz** | Zorgtraject, Subtraject (DBC's — legacy), DiagnoseToekenning | +| **zpm** | CareOrderZpmDetails, ZpmGbggzProfiel, ZpmZorglabel, ZpmSetting (Zorgprestatiemodel) | +| **client_story** | Story, Category, Answer ("levensverhaal" van de cliënt) | +| **survey** | Survey, SurveyResult (vragenlijsten/ROM) | +| **finance** | CareOrder, Invoice, DeclarationRule, FinanceType, VecozoInvoiceRelation | +| **openehr** | ArchetypeWrapper, CompositionWrapper — Nedap gebruikt intern deels openEHR-composities | +| overig | medication, moves (roosteren), payroll, wlz/wmo/jw (Zorglegitimatie per wet!), groupcare, tasque (zorgtaken) | + +**Observatie:** de wettelijke kaders zijn bij Nedap aparte modules met elk een eigen "Zorglegitimatie"-resource (`wlz.WlzZorglegitimatie`, `wmo.WmoZorglegitimatie`, `jw.JwZorglegitimatie`) plus `finance.FinanceType`. Het discovery-besluit "wettelijk kader hoort bij de aanmelding" (§5.0.4) is een schonere generalisatie van hetzelfde principe: financieringskader als expliciet gegeven, niet impliciet. + +### 2.2 Cliënt, persoon en verwijzer + +- **Client** is bij Nedap één platte entiteit (geen persoon/rol-splitsing zoals discovery-besluit §5.1 #1). BSN is een **aparte resource** (`/clients/{id}/bsn`, aparte autorisatie) — zelfde gedachte als spelregel 3.1 #6: BSN afgeschermd op need-to-know, los van het gewone cliëntrecord. +- Relaties zijn expliciet getypeerd: `ClientContactRelation` + `ClientContactRelationType` (waardelijst als resource!) en `ClientEmployeeRelation` + type. Contactpersonen hebben eigen adres-resources. +- **Referral** (verwijzing) heeft: `referrer`, `referrerType`, `referrerCategory`, `agbCode`, `institution`, `specialism`, `date`, `documentId`, `clientId`. Verwijzertype en -categorie zijn strings (waardelijsten), AGB-code en instelling zijn aparte velden, en het verwijs**document** is een losse gekoppelde entiteit. Dit spiegelt de discovery-besluiten §5.1 #2-#3 vrijwel één-op-één (verwijzer ≠ praktijk, AGB op beide, verwijsdocument getypeerd los). +- In de (legacy) DBC-flow zit `SoortVerwijzer` als NZa-waardelijst met `code`, `omschrijving`, `begindatum`, `einddatum` — waardelijst-items met **geldigheidsperioden**. Dat detail (waardelijstwaarden die in de tijd geldig zijn) zit nog niet in de discovery-spelregels en is een aandachtspunt voor de referentietabellen. + +### 2.3 Zorgepisodes en trajecten: twee gescheiden werelden + +Nedap kent **twee losstaande structuren** die beide "episode/traject" heten: + +1. **`dossier.episodes.Episode`** — klinisch-inhoudelijk: `clientId`, `startDate`, `endDate`, `evaluationDate`, `title`, `goal`, `subGoals[]`, gekoppelde `problemIds[]` (medische problemen), `surveyResults[]`, `documents[]`. Plus opvallend: **autorisatie op episode-niveau** (`authorizedExpertiseProfileIds`, `authorizedExpertiseGroupIds`) — wie de episode mag inzien is een eigenschap van de episode. +2. **`dbc.ggz.Zorgtraject`** — financieel/declaratie: `identificatienummer`, `begindatum`, `einddatum` ("Set automatically based on the state of the DBCs... If null, open; if non-null, closed"), `zorgdomein` (NZa-codelijst), `primaireDiagnose`, `subtrajecten[]` (DBC's, met regiebehandelaar-AGB, directe/indirecte minuten, grouper-resultaat/prestatiecode). Voor ZPM is er een aparte module (`zpm.*`) die aan een `CareOrder` hangt. + +**Relevantie voor discovery §5.1 #9 (ZORGEPISODE):** Nedap bevestigt de scheiding klinische episode ↔ declaratietraject als twee entiteiten die naar elkaar verwijzen, niet als één ding. Ook opvallend: rapportages verwijzen naar episodes via `episodeIds[]` — **many-to-many**, één verslag kan bij meerdere episodes horen. De discovery gaat nu impliciet uit van één episode per klinisch record; dit is een beargumenteerde open vraag voor de rapportage-ronde (geen bezwaar tegen genomen besluiten). + +**Diagnose in de DBC-flow:** `DiagnoseToekenning` heeft `primair` (boolean), datum, en een `diagnoseCode` uit een NZa-tabel die per code o.a. `icd9cm`, `icd10`, prestatiecode-mappings en `selecteerbaar`/`sorteervolgorde` bevat. De mapping diagnose→declaratiecode is dus **data in een codetabel**, precies het patroon van discovery-besluit §5.4 #1 (DSM-registratie met ICD-10-mapping via tabel). + +### 2.4 DSM-classificatie (GGZ-module) + +`dossier.medical.dsm.Classification` (binnen een `ClassificationSeries`): `classificationDate`, `beginDate`/`endDate`, `status` ("status of the classification phase" — vrije string, geen enum in de spec), `diagnosisDescription`, `findings`, `evaluations`, GAF-scores (`gafStart/gafCurrent/gafEnd/gafMax`), `immutable` (vergrendeld na vaststelling), `axis3weight`. Het bredere `dossier.medical.Problem` kent `certainty` (≈ werkdiagnose vs. definitief), `severity`, `course`, `onsetApproximateDate`/`onsetPeriodOfLife`, `resolvedApproximateDate`, `snomedExpressionValue` en wederom episode-koppeling + autorisatievelden. De as "zekerheid" (certainty) naast klinische status bevestigt het discovery-patroon van twee status-assen (§5.4 open vraag: verificatiestatus + klinische status) als gangbaar. + +### 2.5 Rapportagemodel + +`dossier.Report` is het centrale verslag-record: + +- **Typering:** `reportTypeId` verwijst naar `ReportType`, maar de spec documenteert een **hardcoded lijst**: 101 Rapportage, 102 Gewicht, 103 Bloeddruk, 104 Temperatuur, 105 Bloedsuiker, 106/107 Vocht in/uit, 108 Defecatie, 109 Medisch, 110 Voortgang, 111 Familie communicatie, 112 Keten communicatie, 309 Stemming, 310 Omaha, 311 Saturatie, 314 Pijnscore, 315 SOEP, 316 Bristol, 317 Klinimetrie. `ReportType` is wél een resource met `enabled`-vlag, maar de magic numbers staan letterlijk in de API-beschrijving — het anti-patroon dat spelregel 3.1 #1 (waardelijsten als data, één bron) wil voorkomen, hier zichtbaar bij een marktleider. +- **Metingen als rapportage:** gewicht, bloeddruk enz. zijn géén aparte observatie-entiteit maar rapportagetypen met `reportEntries[]` (naam/waarde/unit, bv. `systolicPressure, 120, mm[Hg]`). Genericiteit boven aparte tabellen per meetwaarde. +- **SOEP gestructureerd:** `soapReportEntries[]` met `soapPart` (Subjective/Objective/...), `content`, en **vertrouwelijkheid + autorisatie per SOEP-deel** (`confidential`, `expertiseProfileIds`). Een verslag is dus deels afschermbaar per discipline. +- **Koppelingen:** `carePlanEntryId` (rapporteren op zorgplan-regel/doel), `episodeIds[]`, `restrictiveMeasureId`, parent/child (reacties op rapportages), `reportActions[]` (leesbevestiging/actie door discipline X). +- **Auteurschap:** basisvelden uit `AuditedBase` (`createdAt/updatedAt/createdBy`) plus `ReportAuthorType`: `employee` / `caren` (mantelzorger via Caren-portaal!) / `external`. Familie kán rapporteren; het auteurstype is expliciet. Dit is een smallere variant van de provenance-spelregel 3.1 #2 (die met mens/AI verder gaat). +- **Status:** `ReportStatus` is minimaal: 0=OPENED / 1=CLOSED, alleen gebruikt voor communicatie-draden. Rapportages zelf kennen geen workflow-status — wel `flagged`, `confidential`, `hidden` + `hidingReason` (soft delete met reden). + +### 2.6 Zorgplan (behandelplan-equivalent) + +- `CarePlan`: `clientId`, `employeeId`, `beginDate`, `endDate`, `status` — enum **`DRAFT` / `ACTIVE` / `OLD`**. Versiebeheer werkt via nieuwe plannen (endpoints `by_client/active`, `by_client/draft`, `activate`, `archive`): het oude plan wordt `OLD`, er is er hooguit één `ACTIVE`. Dit is het "nieuw record per versie"-model uit de open vraag van discovery §5.5. +- Hiërarchie: `Domain` (leefgebied) → `Demand` (zorgvraag/probleem) → `Goal` → `Action`, elk met een "Entry"-variant (de concrete invulling in dít plan: `DemandEntry`, `GoalEntry`, `ActionEntry`) — sjabloon versus instantie gescheiden. `CarePlanEntry` bundelt demand+goal+acties en draagt `percentageTarget`/`percentageRealized`. +- **Cliëntakkoord is een eigen entiteit, geen status:** `CarePlanAgreement` (carePlanId, clientId, employeeId) plus `CarePlanSignatureRequirement` met `required` en `discussionType`: `discussed` / `discussed_later` / `no_discussion` / `no_agreement`. Dit beantwoordt de open discovery-vraag §5.5 ("is cliëntakkoord een status of los feit?") vanuit de praktijk: **los feit**, met aparte registratie of/hoe het besproken is. +- `carepath.CarePath` + `Template`: zorgpaden als sjablonen met modules, geïnstantieerd per cliënt (`activeModules`, start/einddatum) — vergelijkbaar met "zorgprogramma" als inhoudelijk aanbod (discovery §5.2 #2), maar dan geoperationaliseerd. + +### 2.7 Wachtlijst + +`LocationAssignmentWaitingList` is een subtype van `LocationAssignment` (type `WAITING_LIST`), letterlijk gedocumenteerd als: *"Developed as a (temporary) solution to enable (GGZ) customers to indicate a client is on a 'waiting list'"*. Velden: `waitingFor`, `status` ("Wachtstatus (urgentie)"), `description`, `classification` (alleen Wlz, ZN-classificatie zoals `DREIGENDE_CRISIS_THUIS`), `closingReason` ("Assumed use: BI tooling"). Bij álle waardevelden staat: **"Possible values are defined by the care organisation"** — volledig instellingsconfigureerbare waardelijsten, niets hardcoded. Voorbeeldwaarden: `waitingFor: BESCHIKBARE_PLEK`, `status: ACTIEF_PLAATSEN`, `closingReason: GEPLAATST`. + +**Relevantie voor discovery §5.3:** zelfs de marktleider heeft wachtlijst als noodoplossing aan locatietoewijzing gehangen. Het discovery-besluit (WACHTLIJSTPLAATSING als eigen entiteit met soort aanmeld/behandel, prioriteit en beëindigingsreden) is structureel sterker dan wat Nedap publiek biedt; de Nedap-les die overblijft is: maak prioriteit, wachtreden én beëindigingsreden instellingsconfigureerbare waardelijsten. + +### 2.8 Agenda + +Klassiek series/occurrence-patroon: `AgendaSeries` (herhaalregels: recurrenceType, weekdagen, cycleInterval, validFrom/To) en `AgendaOccurrence` (concrete afspraak, met `clientPresent`, `registered`, `registrationComplete`, `hourTypeId` → koppeling naar tijdregistratie/declaratie, labels, uitnodigingen voor cliënt en medewerkers). Afwezigheid van cliënten (`ClientAbsenceOccurrence` + `ClientAbsenceReason` als waardelijst-resource) is een aparte structuur. `presence_logs` verbinden agenda met aanwezigheidsregistratie (klinisch/verblijf). Les: afspraak-realisatie ("registered") en de afspraak zelf zijn gescheiden assen — relevant voor de agenda-ronde i.c.m. ZPM (planning ≠ geleverde prestatie). + +### 2.9 FHIR/zibs-positie van Nedap + +De eigen API is **niet** FHIR — het is een proprietary REST-model. FHIR/zibs zit in een aparte documentatiesectie ([ZIBs en FHIR](https://ons-api.nl/techniek/FHIR%20en%20ZIBS.html)) als uitwisselingslaag ernaast (o.a. `harmony.ZorgdomeinFhirConnector` in de spec, `nuts.Consent` voor het Nuts-netwerk). Dit ondersteunt de discovery-koers (§4): eigen model als kern, FHIR als adapter aan de rand. Zelfde geldt voor Nedaps interne openEHR-gebruik: wrapper-resources, geen leidend API-model. + +--- + +## 3. Medicore (ECD/EPD, veel gebruikt in GGZ/jeugdzorg) + +**Niet publiek vindbaar:** resource-lijsten, entiteiten, statussen of een developer-portal. Wat wél uit publieke bronnen blijkt: + +- Medicore heeft een API-/integratieplatform **"Mint" (Medicore Integrated)** met "35+ partners"; genoemde integratiedomeinen: medicatie, roosterplanning, speech-to-text, eigen apps. Standaarden: HL7, **FHIR**, OpenID Connect, Azure. Bron: [API-platform](https://medicore.nl/medicore-producten/api-platform/), [Mint-oplossingenpagina](https://medicore.nl/oplossingen/api-platform/). +- De EPD-pagina noemt als product-onderdelen: Mijn Medicore, Zorgapp, UP (AI-assistent), API-platform, Wellbee-cliëntportaal — geen module- of entiteitenlijst op datamodel-niveau. Bron: [EPD-pagina](https://medicore.nl/medicore-producten/epd/). +- Medicore werkt "al jaren met open standaarden zoals MedMij en HL7 FHIR" (bron: [kennisartikel Medicore UP](https://medicore.nl/kennis/de-virtuele-ecd-epd-assistent-die-je-tijd-en-inzichten-teruggeeft/)); dat maakt aannemelijk dat externe koppelingen FHIR-resources gebruiken (MedMij-gegevensdiensten zijn per definitie FHIR), maar **hoe het interne datamodel eruitziet is niet publiek**. +- Toegang tot documentatie loopt via contact/partnerschap; er is geen publieke Swagger/OpenAPI gevonden. + +**Conclusie:** "Medicore = FHIR-based API" (aanname uit de opdracht) is publiek **niet verifieerbaar** op resource-niveau; verifieerbaar is alleen dat hun koppelplatform FHIR als standaard noemt. + +## 4. PinkRoccade Zorg — mijnCaress + +**Niet publiek vindbaar:** API-referentie, entiteiten, waardelijsten. Wat wél blijkt: + +- mijnCaress (VVT/GHZ-ECD, geen GGZ-focus) positioneert zich als "API-based... één platform" en "steeds meer open"; werken met API's wordt genoemd als voorwaarde om data "gestandaardiseerd beschikbaar te stellen voor uitwisseling in de zorgketen". Bronnen: [mijnCaress VVT](https://www.mijncaress.nl/vvt/), zoekresultaat "mijnCaress wordt steeds meer Open" (pagina zelf inmiddels 404). +- Concrete koppelingen die publiek beschreven zijn: **ZorgDomein ↔ mijnCaress via HL7 FHIR** (verwijzingen ontvangen en verwerken in het ECD) — bron: [ICT&health](https://www.icthealth.nl/nieuws/koppeling-zorgdomein-mijncaress-beperkt-administratielast/), [FMT Gezondheidszorg](https://fmtgezondheidszorg.nl/koppeling-zorgdomein-en-mijncaress-verbetert-samenwerking-in-keten/); identity-koppelingen via Tools4ever; zorgapp-koppelingen via CareConnections. +- Het [mijnCaress Platform-overzicht](https://mijncaress.nl/oplossingen/mijncaress-platform/) noemt modules (Medewerkerportaal, Zorgapp, Cliëntportaal, Financieel, Stuurinformatie, Spraakgestuurd rapporteren) maar nul technische documentatie. + +**Conclusie:** geen bruikbaar datamodel-vergelijkingsmateriaal; alleen het signaal dat verwijzingen-instroom via FHIR (ZorgDomein) sectorbreed de norm wordt — relevant voor de latere adapter/instroomkant van AANMELDING. + +## 5. Adapcare — Pluriform Zorg + +**Niet publiek vindbaar:** API-referentie of entiteitenmodel. Wat wél blijkt van de [GGZ-productpagina](https://www.adapcare.nl/pluriform-zorg/ggz/): + +- Pluriform Zorg is een "workflowgestuurd ECD" voor het "complete GGZ-behandeltraject", met als genoemde processtappen: **intake en diagnostiek → behandeling → crisis → nazorg**, voor ambulante gesprekken én klinische opnames; "ondersteunt alle financieringsvormen binnen de GGZ" (incl. forensisch). +- Integratie via de **"Adapcare Care Connector"**: "integreer je op basis van open standaarden (zoals FHIR, ZIB's en openEHR)" plus CACAO-samenwerkingsplatform. Geen documentatie van wat er achter die connector zit. + +**Conclusie:** het proces-vocabulaire (intake/diagnostiek/behandeling/crisis/nazorg als fasen van één traject) bevestigt de fasering die de discovery in AANMELDING → ZORGEPISODE modelleert, maar op datamodel-niveau valt niets te verifiëren. + +## 6. Kort: USER (SDB), ZilliZ, Praktijkdata + +- **USER** is het GGZ-EPD van **Avinty, sinds april 2023 onderdeel van SDB Groep** (níet van ZilliZ — de opdrachttekst suggereerde "Zilliz/USER", dat klopt niet). De [USER-productpagina](https://sdbzorgt.nl/user/) noemt: Agenda als "het centrale punt rondom plannen, rapporteren en registreren", multidisciplinair zorgplan waaraan de cliënt meeschrijft, rapportage-overzicht "Voortgang / Decursus" over alle disciplines, Metingen, Zorgviewer, en facturatiestromen "ZPM, WLZ, WMO en FZ". Koppelingen via een **"Connect Service"** ("fundamenteel open ecosysteem") — geen publieke API-docs. Interessant vocabulaire-detail: GGZ-rapportage heet hier **decursus**, en de agenda is expliciet de spil tussen plannen, rapporteren en (ZPM-)registreren. +- **ZilliZ** ([zilliz.nl](https://zilliz.nl/)) is een ECD voor kleinschalige zorg (rapportage, geleverde zorg boeken, facturatie, Vecozo/CAK-berichtenverkeer). API-koppelingen bestaan (REST/SOAP, via partners zoals [Brixxs](https://brixxs.com/faq/hoe-kan-ik-een-api-koppeling-maken-met-zilliz/)) maar zijn niet publiek gedocumenteerd. +- **Praktijkdata** (Telasoft) is een EPD voor GGZ-praktijken (psychologen/psychiaters/therapeuten) met koppelingen naar o.a. [SnelStart](https://www.snelstart.nl/koppelingen/praktijkdata), [BergOp](https://www.bergop.info/aanbod/functies/koppelingen-epd) (ROM) en [MyMindspace](https://www.mymindspace.nl/praktijkdata-epd-koppelt-met-mymindspace) (eHealth). Documentatie alleen op aanvraag. +- **Koppeltaal 2.0** (geen leverancier, wel hét GGZ-koppelvlak voor eHealth): FHIR R4 + zib2020, met verplichte profielen voor Patient, Practitioner, CareTeam, Organization, **Task**, **ActivityDefinition**, RelatedPerson — eHealth-modules worden als ActivityDefinition aangeboden en als Task aan een cliënt toegewezen. Bronnen: [Simplifier-package](https://simplifier.net/packages/koppeltaalv2.00/0.7.2), [Koppeltaal 2.0 Dev Guide](https://vzvz.gitbook.io/koppeltaal-2.0-dev-guide/technische-howto/resources-managen). Relevant zodra het ECD eHealth-interventies aan behandeldoelen koppelt (discovery §5.5, interventies). + +--- + +## 7. Dwarsdoorsnede: wat dit betekent voor het Triqura-datamodel + +Per discovery-deelgebied, zonder besluiten terug te draaien: + +1. **Waardelijsten (spelregel 3.1 #1)** — Nedap laat beide uitersten zien: `ReportType` met magic numbers ín de API-docs (het anti-patroon) én wachtlijstvelden die volledig "defined by the care organisation" zijn (het gewenste patroon). Extra les: NZa-achtige waardelijsten (SoortVerwijzer, Zorgdomein, diagnosecodes) dragen bij Nedap **geldigheidsperioden** (`begindatum`/`einddatum` per waarde). Overweging voor de referentietabellen: geldig-van/geldig-tot per waarde opnemen. +2. **Episode ↔ declaratietraject (besluit §5.1 #9)** — bevestigd door Nedap: klinische episode en zorgtraject/DBC/ZPM zijn gescheiden structuren die naar elkaar verwijzen. Open vraag voor de rapportage-ronde: Nedap koppelt verslagen many-to-many aan episodes (`episodeIds[]`). +3. **Verwijzer (besluiten §5.1 #2-#3)** — Nedaps `Referral` (referrerType, referrerCategory, agbCode, institution, specialism, documentId) valideert de gekozen decompositie; niets gevonden dat ertegen pleit. +4. **Wachtlijst (besluit §5.3)** — geen leverancier heeft dit publiek beter opgelost dan het discovery-besluit; Nedap noemt zijn eigen oplossing letterlijk tijdelijk. Beëindigingsreden ("closingReason... assumed use: BI tooling") als configureerbare waardelijst wordt door de praktijk bevestigd. +5. **Diagnose (besluiten §5.4)** — twee status-assen (certainty + klinische status) en mappingtabellen met ICD-9/ICD-10-kolommen per diagnosecode zijn bij Nedap staande praktijk; `immutable` na vaststelling is het equivalent van "definitief vastgesteld". GAF-scores op de classificatie zijn DSM-IV-erfgoed — niet overnemen, wel een waarschuwing over hoe classificatie-historie in een model versteent. +6. **Behandelplan (§5.5, open vragen)** — Nedap beantwoordt twee open discovery-vragen vanuit de praktijk: statusmachine minimaal (`DRAFT`/`ACTIVE`/`OLD`, één actief plan, versie = nieuw record) en **cliëntakkoord als los feit** (`CarePlanAgreement`) met een aparte besprekingsstatus (`discussed`/`discussed_later`/`no_discussion`/`no_agreement`) — dat laatste dekt de WGBO-realiteit dat een plan besproken-maar-niet-akkoord kan zijn. +7. **Rapportage (latere ronde)** — Nedap-patronen om mee te nemen: metingen als generiek entry-mechanisme i.p.v. tabel-per-meetsoort; vertrouwelijkheid/autorisatie per verslag-onderdeel (SOEP-deel) en zelfs per episode; auteurstype als enum (medewerker/naaste/extern — bij Triqura komt daar AI bij, spelregel 3.1 #2 gaat verder); verbergen met reden i.p.v. verwijderen. +8. **FHIR-positie (§4 discovery)** — geen enkele onderzochte leverancier gebruikt FHIR als intern datamodel. Nedap: proprietary REST + FHIR/zibs als rand. Medicore/PinkRoccade/Adapcare: FHIR genoemd als koppelstandaard. De discovery-koers (eigen model, FHIR als adapter) is marktconform. +9. **Openheid als onderscheid** — alleen Nedap publiceert zijn API volledig. Een publiek gedocumenteerde, semantisch rijke API (uit FCO-IM-feitzinnen afleidbaar) zou voor Triqura een reëel concurrentievoordeel zijn in een markt waar documentatie achter partnercontracten zit. + +## 8. Expliciet: wat NIET publiek vindbaar is + +- Interne datamodellen/ERD's van álle leveranciers (ook Nedap publiceert alleen het API-vlak, niet het databaseschema). +- Medicore: elke resource-/entiteitenlijst, statussen, waardelijsten; het bestaan van een FHIR-API is aannemelijk maar niet op resource-niveau verifieerbaar. +- PinkRoccade mijnCaress: elke technische API-documentatie; de "steeds meer open"-pagina is inmiddels offline (404). +- Adapcare: alles achter de "Care Connector"; geen spec, geen resources. +- USER/SDB: alles achter de "Connect Service"; ook GGZ-instroomfunctionaliteit (aanmelding/wachtlijst) is publiek onbeschreven. +- Wachtlijst-/aanmeldstatussen en instroomworkflows: bij geen enkele leverancier publiek gedocumenteerd behalve Nedaps wachtlijst-resource. +- Dit onderzoek heeft geen toegang gehad tot partnerportalen, NDA-documentatie of demo-omgevingen; alles hierboven komt uit openbare bronnen d.d. 18-07-2026. + +## 9. Bronnen + +**Nedap Ons (primair, hoge betrouwbaarheid):** +- [ons-api.nl — Wat is Ons API?](https://ons-api.nl/) · [API-overzicht](https://ons-api.nl/techniek/apis/APIS.html) · [API-eigenschappen](https://ons-api.nl/techniek/apis/API_eigenschappen.html) · [ZIBs en FHIR](https://ons-api.nl/techniek/FHIR%20en%20ZIBS.html) +- [OpenAPI-specificatie (json, geanalyseerd 18-07-2026)](https://ons-api.nl/assets/openapi.json) +- [Nedap Ons support — What is Ons API?](https://support.nedap-ons.nl/support/solutions/articles/103000371509-what-is-ons-api-) + +**Medicore:** +- [API-platform](https://medicore.nl/medicore-producten/api-platform/) · [Mint-oplossingen](https://medicore.nl/oplossingen/api-platform/) · [EPD](https://medicore.nl/medicore-producten/epd/) · [Medicore UP / standaarden](https://medicore.nl/kennis/de-virtuele-ecd-epd-assistent-die-je-tijd-en-inzichten-teruggeeft/) + +**PinkRoccade mijnCaress:** +- [mijnCaress Platform](https://mijncaress.nl/oplossingen/mijncaress-platform/) · [mijnCaress VVT](https://www.mijncaress.nl/vvt/) · [ZorgDomein-koppeling via FHIR (ICT&health)](https://www.icthealth.nl/nieuws/koppeling-zorgdomein-mijncaress-beperkt-administratielast/) · [FMT Gezondheidszorg](https://fmtgezondheidszorg.nl/koppeling-zorgdomein-en-mijncaress-verbetert-samenwerking-in-keten/) + +**Adapcare:** +- [Pluriform Zorg GGZ](https://www.adapcare.nl/pluriform-zorg/ggz/) · [Adapcare](https://www.adapcare.nl/) + +**USER / ZilliZ / Praktijkdata:** +- [USER EPD (SDB Zorgt)](https://sdbzorgt.nl/user/) · [SDB EPD GGZ](https://sdbzorgt.nl/oplossingen/epd-geestelijke-gezondheidszorg/) · [ZilliZ](https://zilliz.nl/) · [Brixxs — API-koppeling ZilliZ](https://brixxs.com/faq/hoe-kan-ik-een-api-koppeling-maken-met-zilliz/) · [Praktijkdata ↔ SnelStart](https://www.snelstart.nl/koppelingen/praktijkdata) · [BergOp EPD-koppelingen](https://www.bergop.info/aanbod/functies/koppelingen-epd) · [MyMindspace ↔ Praktijkdata](https://www.mymindspace.nl/praktijkdata-epd-koppelt-met-mymindspace) + +**Koppeltaal (context):** +- [Koppeltaal 2.0 package (Simplifier)](https://simplifier.net/packages/koppeltaalv2.00/0.7.2) · [Koppeltaal 2.0 Dev Guide](https://vzvz.gitbook.io/koppeltaal-2.0-dev-guide/technische-howto/resources-managen) diff --git a/docs/datamodel/onderzoek/onderzoek-rapportage.md b/docs/datamodel/onderzoek/onderzoek-rapportage.md new file mode 100644 index 0000000..2a685e2 --- /dev/null +++ b/docs/datamodel/onderzoek/onderzoek-rapportage.md @@ -0,0 +1,241 @@ +# Onderzoek: voortgangsrapportage & dossiervoering in de Nederlandse GGZ + +**Status:** onderzoeksinput voor datamodel-deelgebied voortgangsrapportage (ronde "rapportage & overdracht") +**Datum:** 18 juli 2026 +**Auteur:** onderzoeksagent "rapportage" (webresearch + prototype-analyse) +**Kader:** dit rapport draait geen besluiten uit `../deelmodellen/datamodel-discovery.md` terug; het levert feiten, bronnen en kandidaat-feitzinnen. Waar iets schuurt met een genomen besluit staat dat expliciet als open vraag gemarkeerd. + +--- + +## 1. Wettelijk kader: wat móet er in het dossier + +### 1.1 WGBO — dossierplicht (BW 7:454) + +- De hulpverlener is verplicht een dossier in te richten en daarin aantekening te houden van "gegevens omtrent de gezondheid van de patiënt en de te diens aanzien uitgevoerde verrichtingen", voor zover dit voor een goede hulpverlening noodzakelijk is. Er is geen limitatieve wettelijke lijst; de norm is *noodzakelijk voor goede zorg* ([KNMG — richtlijn Omgaan met medische gegevens](https://www.knmg.nl/richtlijn-omgaan-met-medische-gegevens/), [Ondernemersplein — medisch dossier bijhouden](https://ondernemersplein.overheid.nl/wetten-en-regels/medisch-dossier-bijhouden-en-delen/)). +- **Bewaartermijn: 20 jaar**, gerekend vanaf de laatste wijziging in het dossier (WGBO-wijziging per 1-1-2020, was 15 jaar vanaf vastlegging) ([LVVP](https://lvvp.info/nieuwsbrief/wijziging-wgbo-waaronder-verlenging-bewaartermijn-15-naar-20-jaar/), [Rijksoverheid](https://www.rijksoverheid.nl/onderwerpen/rechten-van-patient-en-privacy/uw-medisch-dossier/bewaren-medisch-dossier), [KNMG — wijzigingen WGBO](https://www.knmg.nl/advies-richtlijnen/dossiers/behandelingsovereenkomst-wgbo/wijzigingen-wgbo.htm)). Langer bewaren kan (belang van derden, bijv. erfelijke gegevens); bij gedwongen opname geldt aanvullend minimaal 5 jaar na ontslag ([Autoriteit Persoonsgegevens](https://www.autoriteitpersoonsgegevens.nl/en/themes/health/health-data-in-a-file/retention-of-the-health-data-file)). +- **Patiëntrechten op het dossier** ([AP — rechten bij het dossier](https://www.autoriteitpersoonsgegevens.nl/en/themes/health/health-data-in-a-file/rights-regarding-the-health-data-file), [VvAA](https://www.vvaa.nl/nieuws-en-kennis/nieuws-en-artikelen/kopie-wijziging-of-vernietiging-van-medisch-dossier), [KNMG praktijkdilemma vernietiging](https://www.knmg.nl/ik-ben-arts/praktijkdilemmas-1/praktijkdilemma/heeft-mijn-patient-recht-op-vernietiging-van-zijn-medisch-dossier)): + - **Inzage en afschrift** — altijd. + - **Correctie** — alleen voor feitelijke, objectief vaststelbare onjuistheden; indrukken/conclusies van de behandelaar vallen er níet onder. + - **Aanvulling** — de cliënt mag altijd een eigen (afwijkende) verklaring aan het dossier laten toevoegen; de hulpverlener móet die opnemen, ook bij inhoudelijk oneens zijn. + - **Vernietiging** — op verzoek, tenzij een aanmerkelijk belang van een ander zich verzet of een wettelijke bepaling vernietiging verbiedt. (Sinds de herziening 2024 van de KNMG-richtlijn: het vernietigingsverzoek zelf bewaren ná vernietiging.) + +### 1.2 Wabvpz — elektronische inzage en logging + +Per 1 juli 2020 (art. 15d/15e Wabvpz): cliënt heeft recht op **kosteloze elektronische inzage en elektronisch afschrift** van het dossier, en recht op een afschrift van de **logging** (wie keek wanneer in het dossier); logging moet voldoen aan **NEN 7513** ([Eldermans & Geerts](https://www.eldermans-geerts.nl/per-1-juli-2020-het-recht-op-elektronische-inzage-in-en-afschrift-van-het-medisch-dossier/), [Dirkzwager](https://www.dirkzwager.nl/kennis/artikelen/per-1-juli-2020-nieuwe-rechten-en-verplichtingen-met-betrekking-tot-het-elektronisch-patientendossier), [VGN](https://www.vgn.nl/nieuws/elektronische-inzage-afschrift-en-logging-1-juli-2020)). + +**Gevolg voor rapportage:** elke voortgangsrapportage is in beginsel cliënt-leesbaar. Dit is geen portaal-feature-keuze maar een wettelijk recht — een "vertrouwelijk"-vlag in het ECD kan zichtbaarheid in een portaal uitstellen, maar heft het inzagerecht niet op. + +### 1.3 Wkkgz — incidenten in het dossier (art. 10 lid 3) + +- Incidenten met **merkbare gevolgen voor de cliënt** (of die deze in de toekomst kunnen hebben) moeten aan de cliënt worden gemeld én in het **cliëntendossier** worden aangetekend: **aard, toedracht en tijdstip** van het incident plus de **namen van direct betrokkenen**. De cliënt kan hiervan afschrift vragen ([Holla — Wkkgz-meldingen](https://www.holla.nl/nieuws/wkkgz-meldingen), [Dirkzwager — mededeling van een incident](https://www.dirkzwager.nl/kennis/artikelen/inzage-in-het-medisch-dossier-van-een-overleden-pati%C3%ABnt-2-mededeling-van-een-incident)). +- Dit staat **los van** de interne VIM-melding (zie §6): VIM registreert élk incident in een apart register; het dossier krijgt alleen een aantekening bij merkbare gevolgen ([zzp-erindezorg — incident vs calamiteit](https://www.zzp-erindezorg.nl/blog/eisen-uit-de-wkkgz-verschil-tussen-incident-en-calamiteit/)). + +### 1.4 Landelijk Kwaliteitsstatuut GGZ (v4.0, jan 2025) + +- De **regiebehandelaar** (indicerend/coördinerend) is verantwoordelijk voor probleemanalyse, diagnose en behandelplan op hoofdlijnen, en voor **dossiervoering, verslaglegging en het eindverslag**; minimaal jaarlijks een planbespreking met alle betrokken disciplines, vastgelegd in het dossier ([Landelijk Kwaliteitsstatuut GGZ 4.0, Zorginzicht](https://www.zorginzicht.nl/binaries/content/assets/zorginzicht/kwaliteitsinstrumenten/landelijk-kwaliteitsstatuut-ggz-4.0.pdf), [Zorginstituut](https://www.zorginstituutnederland.nl/publicaties/publicatie/2020/12/15/landelijk-kwaliteitsstatuut-ggz)). +- MDO-conclusies en -afspraken horen direct in het dossier (multidisciplinair behandelplan) ([Verenso — handreiking MDO](https://www.verenso.nl/kwaliteit/richtlijnen-en-praktijkvoering/richtlijnendatabase/multidisciplinair-overleg-mdo), [normenkaderzorg — MDO-registratie-eis](https://www.normenkaderzorg.nl/index.php?title=DBC_zonder_geldig_MDO_%28N2220%29)). + +### 1.5 Zorgprestatiemodel — registratie naast rapportage + +Het ZPM registreert **consulten** (declaratie) via "planning = realisatie": afwijking > 15 minuten van de geplande tijd moet worden bijgesteld; tijdschrijven is afgeschaft; de agenda + periodieke controle is de verantwoordingsbron ([Spelregels correct registreren en declareren, zorgprestatiemodel.nl](https://www.zorgprestatiemodel.nl/content/uploads/2023/07/20230628-Spelregels-correct-registreren-en-declareren_definitief.pdf), [Dirkzwager — ZPM registratie](https://www.dirkzwager.nl/kennis/artikelen/het-zorgprestatiemodel-registratie), [NZa V&A](https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/vraag-en-antwoord/vraag-en-antwoord-zorgprestatiemodel)). + +**Gevolg voor het model:** *consultregistratie* (declarabel feit, agenda-gedreven) en *inhoudelijke rapportage* (klinisch feit) zijn twee verschillende feiten die naar elkaar kunnen verwijzen, maar niet één record zijn. Uitzonderingssituaties moeten wel "uit het dossier blijken". + +--- + +## 2. Professionele richtlijnen dossiervoering + +### 2.1 KNMG — Omgaan met medische gegevens (herzien jan 2024) + +Hoofdstuk 2 behandelt dossierplicht, bewaartermijn en patiëntrechten; er is bewust géén uitputtende lijst wat per situatie in het dossier moet — de noodzakelijkheidsnorm geldt ([KNMG-richtlijn 2024, pdf](https://www.knmg.nl/download/knmg-richtlijn-omgaan-met-medische-gegevens-2), [overzichtspagina](https://www.knmg.nl/actueel/publicaties/publicaties-per-onderwerp/omgaan-met-medische-gegevens)). + +### 2.2 V&VN — Richtlijn Verslaglegging (2022) + +Richtlijn voor verpleegkundigen/verzorgenden, ook toepasbaar in de GGZ ([Kennisplatform V&VN — verslaglegging](https://kennisplatform.venvn.nl/onderwerp/verslaglegging/), [richtlijn-pdf](https://www.venvn.nl/media/w02buck0/v-vn-richtlijn-verslaglegging.pdf), [Nursing](https://www.nursing.nl/praktijk/organisatie-van-zorg/nieuwe-richtlijn-moet-verslaglegging-en-overdracht-verbeteren/)): + +- Doel: continuïteit en kwaliteit van zorg, samenwerking tussen zorgverleners. +- Vastleggen in **alle fasen van het verpleegkundig proces**: gegevensverzameling, zorgproblemen/diagnoses, **gezamenlijk vastgestelde doelen**, uitgevoerde zorg, **voortgangsrapportage**, evaluatie, overdracht. +- **Eenduidige taal** die uitwisselbaar is tussen organisaties (eenheid van taal / zibs-terminologie). +- **Cliënt betrekken**: controleer of wat je rapporteert aansluit bij de wensen/behoeften van de zorgvrager. +- Bij overdracht tussen settingen: de informatiestandaard **eOverdracht** gebruiken. + +### 2.3 NIP — dossier vs. persoonlijke werkaantekeningen + +- Het cliëntdossier bevat alles wat relevant is voor kwaliteit en continuïteit van de professionele relatie: behandelplan, gespreksaantekeningen, observaties, testuitslagen, correspondentie ([NIP — dossiervorming](https://www.psynip.nl/uw-beroep/cotan/cotan-beoordelingssysteem-ast-en-beroepscode/algemene-standaard-testgebruik-nip-2017/2-2-onderzoeksprocedure/2-2-2-dossiervorming/)). +- **Persoonlijke werkaantekeningen** (indrukken, vermoedens, vragen als geheugensteun voor het eigen denkproces) horen **niet** in het dossier, zijn tijdelijk en moeten vernietigd worden zodra niet meer relevant. Let op: gespreksnotities en observaties over de cliënt zijn *géén* werkaantekeningen — die horen wél in het dossier ([NIP — persoonlijke werkaantekeningen](https://www.psynip.nl/uw-beroep/cotan/cotan-beoordelingssysteem-ast-en-beroepscode/algemene-standaard-testgebruik-nip-2017/2-2-onderzoeksprocedure/2-2-4-persoonlijke-werkaantekeningen/)). +- **Gevolg voor het model:** werkaantekeningen zijn geen dossier-entiteit. Als het ECD ze faciliteert, dan strikt gescheiden van de rapportage-entiteit, buiten inzage/afschrift, met een vernietigings-levenscyclus. Simpeler: niet faciliteren. + +### 2.4 NVvP / psychiatrie + +Geen aparte NVvP-dossierrichtlijn gevonden naast WGBO/KNMG; dossiervoering is onderdeel van de kwaliteitsvisitatie en elk diagnostisch verslag is een medisch document dat tuchtrechtelijk toetsbaar is ([NVvP — wet- en regelgeving](https://www.psychiatrie.nl/alle-themas/wet-en-regelgeving/), [Richtlijn psychiatrische diagnostiek — wettelijk kader](https://richtlijnendatabase.nl/richtlijn/psychiatrische_diagnostiek/wettelijke_kader_psychiatrische_diagnostiek.html), [NVvP normenkader kwaliteitsvisitatie](https://www.psychiatrie.nl/app/uploads/2024/10/Normenkader-NVvP-Kwaliteitsvisitatie.pdf)). + +--- + +## 3. Rapportagemethodieken + +| Methodiek | Structuur | Gebruik | +|---|---|---| +| **SOEP / SOAP** | Subjectief · Objectief · Evaluatie/Analyse · Plan | Breedst gebruikt; huisartsen (NHG-referentiemodel), verpleging, ook GGZ | +| **DAP** | Data · Assessment · Plan | Internationaal dé behandelnotitie-vorm in mental/behavioral health; S+O samengevoegd tot één Data-sectie | +| **TIP** | Thema · Interventie · Plan | GGZ-specifiek alternatief, cliëntvriendelijker | +| **SBAR(R)** | Situation · Background · Assessment · Recommendation (· Repeat) | Mondelinge/acute overdracht, niet primair dossiernotitie | +| **SMART** | doelformulering, geen notitievorm | doelen in behandelplan | +| **Vrije tekst / decursus** | chronologisch journaal | klassiek medisch EPD-patroon | + +- **SOEP**: S = wat de cliënt zelf zegt/beleeft; O = observaties en meetbare vaststellingen incl. gedane interventie en reactie; E = interpretatie/conclusie uit S+O; P = vervolgplan ([Verslagleggen in de GGZ — SOEP-methode](https://www.verslagleggenindeggz.nl/blog/de-soep-methode-hoe-pas-je-die-toe-in-een-voortgangsrapportages/), [CME-Online — SOEP vs SOAP](https://www.cme-online.nl/blog/wat-is-soep-rapporteren/), [NHG HIS-referentiemodel — SOEP-verslag](https://referentiemodel.nhg.org/node/19)). Nedap Ons ondersteunt SOEP als gestructureerd rapportageformulier ([Nedap Ons — SOEP-rapportage](https://support.nedap-ons.nl/support/solutions/articles/103000267329-rapporteren-volgens-de-soep-methode-in-ons-dossier)). +- **DAP**: Data (uitspraken cliënt + observaties + interventies), Assessment (klinische indruk, voortgang op doelen, risico-overwegingen), Plan (vervolg, huiswerk, verwijzing). Typisch drie alinea's ([Headway — DAP notes](https://headway.co/resources/dap-note), [SimplePractice](https://www.simplepractice.com/resource/how-to-write-dap-notes/), [ICANotes](https://www.icanotes.com/2022/10/11/how-to-write-dap-notes/)). +- **TIP en kritiek op SOEP in de GGZ**: het E/A-veld verleidt tot het vastleggen van niet met de cliënt afgestemde aannames — pijnlijk nu cliënten hun dossier online meelezen (Wabvpz). TIP (Thema-Interventie-Plan) wordt in de GGZ aanbevolen als eenvoudiger en herkenbaarder voor de cliënt ([Verslagleggen in de GGZ — SOEP, SOAP of TIP](https://www.verslagleggenindeggz.nl/blog/soep-soap-of-tip-wat-is-een-handige-opbouw-voor-clientrapportages/)). +- **SBAR/I-PASS**: overdrachtscommunicatie; 66% van psychiatrisch verpleegkundigen is ontevreden over de overdracht en voor de klinische GGZ bestaan geen specifieke richtlijnen ([HBO Kennisbank — SBAR-onderzoeken](https://hbo-kennisbank.nl/details/sharekit_av:oai:surfsharekit.nl:270e77bd-1d30-4d7f-b42d-85d5cdd52b74), [eNurse — SBAR-methode](https://enurse.nl/2019/02/24/sbar-methode/), [Nursing — I-PASS](https://www.nursing.nl/student-corner-gebruik-de-i-pass-voor-een-goede-mondelinge-overdracht-2/)). + +**Modelles:** er is geen landelijk verplichte notitievorm. Instellingen kiezen (en wisselen). De methodiek is dus **configuratie** (template per rapportagetype/sessietype), geen schema-hardcoding — exact spelregel 3.1 #1. De gestructureerde secties (S/O/E/P of D/A/P) zijn wel waardevolle *optionele* structuur naast de vrije tekst (past op AI-voorbereiding §3.2: structuur + tekst in hetzelfde record). + +--- + +## 4. Relatie rapportage ↔ behandelplan (rapporteren op doelen) + +- Het behandelplan is in de GGZ "het hart van het dossier"; elk sessieverslag is een bijdrage aan dat plan: ligt de behandeling op koers, vragen doelen bijstelling, werkt de aanpak ([Kuno — behandelverslag koppelen aan behandelplan](https://www.heykuno.com/nl/blog/ggz-behandelverslag/), [Carecheck — verslaglegging in de GGZ](https://carecheck.nl/verslaglegging-in-ggz/)). +- ECD-praktijk: **rapporteren op een doel** — bij het actuele zorgplan per doel een voortgangsrapportage met een *mate van voortgang* (schaal) plus een notitie ([Nedap Ons — rapporteren op doelen en voortgang](https://support.nedap-ons.nl/support/solutions/articles/103000266084-rapporteren-op-doelen-en-voortgang-in-het-zorgplan-in-ons-dossier), [ZilliZ — rapporteren op zorgdoelen](https://zilliz.nl/kennis/blog/rapportegen-op-zorgdoelen-met-zilliz/)). +- V&VN: evaluatie moet aantoonbaar plaatsvinden — verifieer dat doelen periodiek beoordeeld worden ([Kennisplatform V&VN](https://kennisplatform.venvn.nl/onderwerp/verslaglegging/)). + +**Modelles:** een rapportage moet 0..n **behandeldoelen** kunnen refereren (niet verplicht: verpleegkundige dagrapportage of een incident staat vaak los van een doel). Optioneel per doelkoppeling een voortgangsindicatie uit een waardelijst. Evaluatieverslagen (het geplande evaluatiemoment uit §5.5 van de discovery) zijn een rapportagetype dat aan het behandelplan zelf refereert. + +--- + +## 5. Overdracht tussen diensten en teams + +- **Dienstoverdracht (klinisch/verpleegkundig):** rapportages worden per dienst/dagdeel gelezen; gestandaardiseerde mondelinge vormen zijn SBAR/I-PASS (§3). Het "include in handover"-patroon (rapportage markeren voor de overdracht) is gangbaar in ECD's en zit ook in het prototype. +- **eOverdracht (Nictiz):** landelijke informatiestandaard voor de verpleegkundige overdracht túsen instellingen, gebaseerd op zibs (publicatie 2017), uitwisseling via HL7 FHIR; kandidaat voor verplichting onder de Wegiz ([Nictiz — eOverdracht](https://www.nictiz.nl/informatiestandaarden/eoverdracht/), [functioneel ontwerp v3.1](https://informatiestandaarden.nictiz.nl/wiki/vpk:V3.1_Ontwerp_eOverdracht), [ICT&health — Wegiz](https://www.icthealth.nl/magazine/editie-01-2023/gegevensuitwisseling-vpo-bijna-klaar-voor-verplichting-onder-wegiz)). Conform discovery §4 is dit een **koppelvlak**, geen modelregel — maar de zib-begrippen zijn een gratis checklist voor wat een overdracht inhoudelijk draagt. +- **MDO:** gepland overleg van meerdere disciplines; conclusies en afspraken direct in het dossier vastleggen als (bijstelling van het) multidisciplinair behandelplan; de regiebehandelaar bewaakt voortgang én verslaglegging ([Verenso — handreiking MDO](https://www.verenso.nl/assets/Praktijkvoering_handreikingen/VER00331-HandrMultidoverl-DEF.pdf), [NZa — MDO-vergoeding ggz](https://www.nza.nl/vraag-en-antwoord/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/hoe-wordt-het-mdo-vergoed)). MDO-verslag = rapportagetype op episodeniveau (niet per se één cliëntcontact). + +--- + +## 6. Incidentmelding: twee gescheiden sporen + +Dit is de belangrijkste structurele bevinding voor het incident-rapportagetype: + +| Spoor | Wat | Waar | Wie leest | +|---|---|---|---| +| **VIM-melding** (Wkkgz art. 9) | élk incident, ook zonder gevolgen; doel: leren/verbeteren | intern VIM-register, **buiten het cliëntdossier** | VIM-commissie; beschermd, in beginsel niet voor cliënt/IGJ | +| **Dossieraantekening** (Wkkgz art. 10 lid 3) | alleen incidenten met (mogelijk) merkbare gevolgen: aard, toedracht, tijdstip, namen betrokkenen | **cliëntendossier** | cliënt (inzagerecht, afschrift) | +| **IGJ-melding** | calamiteit (dood of ernstig schadelijk gevolg), geweld in de zorgrelatie; binnen 3 werkdagen | IGJ-portaal | IGJ | + +- Elke zorgaanbieder moet een interne VIM-procedure hebben: signaleren, registreren, analyseren, maatregelen, terugkoppeling ([Erisietsmisgegaan — VIM](https://erisietsmisgegaan.nl/bijna-alles-dat-je-moet-weten-over-veilig-incidenten-melden/), [TPSC — VIM & Wkkgz](https://www.patientsafety.com/nl/blog/vim-wkkgz), [NHG — procedure VIM](https://www.nhg.org/praktijkvoering/patient/patientveiligheid/procedure-veilig-incident-melden/)). +- Calamiteit = onbedoelde/onverwachte gebeurtenis met dood of ernstig schadelijk gevolg; melden bij IGJ binnen 3 werkdagen; in de GGZ vallen daaronder ook suïcide(pogingen) bij tekortschietende zorg en geweld in de zorgrelatie ([IGJ — calamiteit melden](https://www.igj.nl/onderwerpen/klachten-en-melden/calamiteiten/melding-doen-van-een-calamiteit), [IGJ — suïcide(poging) melden ggz](https://www.igj.nl/onderwerpen/klachten-en-melden/suicidepoging)). +- Gangbare GGZ-incidentcategorieën: agressie/geweld, suïcide(poging)/automutilatie, medicatie-incident, vallen, vermissing/onttrekking, seksueel grensoverschrijdend gedrag ([IGJ — cijfers meldingen ggz](https://www.igj.nl/over-ons/igj-in-cijfers/cijfers-over-meldingen/cijfers-meldingen-geestelijke-gezondheidszorg)). + +**Modelles:** het prototype-type `incident` vermengt beide sporen. In het nieuwe model: (a) de **dossieraantekening incident** is een rapportagetype in het cliëntdossier (met de art.-10-velden aard/toedracht/tijdstip/betrokkenen); (b) de **VIM-melding** is een *aparte entiteit buiten het cliëntdossier* met eigen autorisatie, eigen levenscyclus (gemeld → in analyse → afgerond) en eigen categorie-waardelijst, met optionele verwijzing naar cliënt en rapportage. VIM valt mogelijk buiten scope van het ECD-dossierdeel — maar het besluit "waar leeft VIM" moet expliciet genomen worden. + +--- + +## 7. Hoe bestaande ECD's/EPD's rapportage structureren + +### 7.1 Nedap Ons (referentie-ECD in care/GGZ) + +([Cliëntrapportages toegelicht](https://support.nedap-ons.nl/support/solutions/articles/103000266173-cli%C3%ABntrapportages-in-ons-dossier-toegelicht), [rapportages configureren](https://support.nedap-ons.nl/support/solutions/articles/103000265596-rapportages-voor-ons-dossier-configureren), [autorisaties rondom rapportages](https://support.nedap-ons.nl/support/solutions/articles/103000265496-autorisaties-rondom-rapportages-in-ons-dossier)) + +- **Rapporttypen zijn beheer-configuratie**: Beheer → Dossierinstellingen → Rapporttypen; alleen geactiveerde typen zijn bruikbaar. Voorbeelden: *Rapportage* (vrije tekst), *Medische rapportage* (medisch kenmerk, andere autorisatie), *Familie-communicatie* (zichtbaar in cliëntportaal Caren), *Ketencommunicatie* (voor externen, bijv. huisarts/Zorgmail). +- Rapportagevormen: vrije tekst, voortgang op doel (met voortgangsmaat), meetwaarden, gestructureerde formulieren (o.a. SOEP). +- Rapportages koppelen aan zorgplan(doel), medische episode of maatregel. +- **Vertrouwelijkheid per rapportage**: alleen zichtbaar voor bepaalde deskundigheidsprofielen ("groen slotje"), en dan niet zichtbaar voor de cliënt in Caren. +- Moment van rapporteren (achteraf rapporteren toestaan of niet) is instelbaar. + +### 7.2 GGZ-specifieke EPD's (Medicore, Carecheck e.a.) + +- Rapportagetypen die een GGZ-EPD onderscheidt: intake-/behandelverslagen, voortgangsrapportages, evaluatieverslagen, diagnostische rapportages, MDO-verslagen, online sessierapporten, indirecte-tijdregistraties; per **sessietype** een rapportagetemplate en de keuze of het verslag met de cliënt wordt gedeeld via het portaal ([Carecheck — verslaglegging in de GGZ](https://carecheck.nl/verslaglegging-in-ggz/)). +- Signalering op **ontbrekende verslaglegging** (consult gehad, geen verslag) is een gangbare EPD-functie — bij Triqura is dat een natuurlijke Nudge-Engine-regel, geen schema-eis. +- Klassiek medisch patroon: het chronologische journaal heet **decursus** ("beloop") ([Studeersnel — EPD-opbouw en afkortingen](https://www.studeersnel.nl/nl/document/universiteit-twente/vcpg-2/20230719-opbouw-en-afkortingen-in-het-epd/109078787), [NHG — adequate dossiervorming met het EPD](https://www.nhg.org/praktijkvoering/informatisering/richtlijn-adequate-dossiervorming-epd/)). +- Zorgplannen kennen een concept → definitief-cyclus met ondertekening/akkoord van de cliënt ([Nedap Ons — conceptzorgplannen ondertekenen](https://support.nedap-ons.nl/support/solutions/articles/103000265569-conceptzorgplannen-ondertekenen-of-akkoord-laten-verklaren-in-ons-dossier)); voor losse rapportages is accorderen minder universeel, maar concept/definitief + naderhand alleen aanvullen (niet stilzwijgend herschrijven) volgt uit de correctie-systematiek van §1.1. + +--- + +## 8. Prototype-analyse (`app/api/reports`, `lib/types/report.ts`) + +### 8.1 Wat er nu is + +- Eén `reports`-tabel voor **10 typen**: `voortgang`, `observatie`, `incident`, `medicatie`, `contact`, `crisis`, `intake`, `behandeladvies`, `vrije_notitie`, `verpleegkundig` — hardcoded als TypeScript-const, niet als waardelijst in de database. +- **Twee validatieschema's op één tabel**: standaardrapportage (20–5000 tekens, optioneel `encounter_id`/`intake_id`) vs. `verpleegkundig` (1–500 tekens, verplichte `category` in `structured_data`, `include_in_handover`). De subset `VERPLEEG_REPORT_TYPES` (verpleegkundig, observatie, incident, medicatie, crisis) bepaalt wat het verpleegkundig overzicht toont — een derde impliciete typologie in code. +- `structured_data.category` (medicatie/adl/gedrag/incident/observatie) is een **JSON-veld zonder constraint**; categorielabels, iconen en kleuren leven in de UI-code (`CATEGORY_CONFIG`). +- **Shift-logica**: `calculateShiftDate` — vóór 07:00 telt de rapportage bij de dienst van de vorige dag; `shift_date` wordt alleen gezet voor verpleegkundige notities, bij andere typen is hij leeg maar wordt er wél op gefilterd. +- AI-provenance beperkt: `ai_confidence` + `ai_reasoning` (van de classifier), geen model/bronverwijzingen/content-hash zoals spelregel 3.1 #2 eist. +- `created_by` verwijst naar practitioner maar mag `null` zijn; soft delete via `deleted_at` is aanwezig; geen concept/definitief-status, geen versies, updates overschrijven de tekst zonder zichtbaar spoor. +- Rapportage hangt alleen aan `patient_id` (plus losse optionele `intake_id`/`encounter_id`) — geen koppeling aan zorgepisode, behandelplan of doel. + +### 8.2 Gebreken t.o.v. spelregels en wetgeving + +1. Typen/categorieën hardcoded in code → schendt spelregel 3.1 #1 (waardelijsten op één plek). +2. Twee (eigenlijk drie) typologieën door elkaar: rapporttype, verpleegkundige categorie, "telt mee in verpleegoverzicht" — de dimensies *wie schreef het (discipline)*, *wat voor soort inhoud* en *in welke weergave hoort het* zijn niet gescheiden. +3. `intake` en `behandeladvies` als rapporttype dupliceren entiteiten die in de discovery al een eigen plek hebben (intake, screeningsbesluit/behandelplan) — een verslag *over* een intake is iets anders dan de intake zelf. +4. Geen mutatiehistorie: een gewijzigde rapportage is juridisch een gewijzigd dossier; WGBO-correctiesystematiek en de append-only-auditregel (3.1 #3) vragen om versies of een expliciet wijzigingsspoor. +5. `shift_date` half toegepast (alleen verpleegkundig) en de 07:00-grens is hardcoded. +6. Incident-type dekt noch de art.-10-velden (aard/toedracht/tijdstip/betrokkenen), noch het VIM-spoor. +7. Geen cliëntzichtbaarheids-dimensie, terwijl Wabvpz-inzage en portaaldeling per type gangbaar zijn. + +--- + +## 9. Implicaties voor het datamodel (voorstel, geen besluit) + +### 9.1 Kern-entiteit RAPPORTAGE + +- Hangt aan **CLIENT** én (vrijwel altijd) aan **ZORGEPISODE** (consistent met besluiten §5.1 #9, §5.4 #2). Open: mag een rapportage zonder episode bestaan (bijv. tijdens screening/aanmeldfase)? +- **Rapportagetype uit een waardelijst** (referentietabel), met per type configuratie: structuurtemplate (vrij/SOEP/DAP/...), min/max-lengte, standaard-cliëntzichtbaarheid, telt-mee-in-overdracht, toegestane disciplines. Dit vervangt de drie hardcoded lijsten van het prototype en volgt het Nedap-patroon "rapporttypen zijn beheerconfiguratie". +- **Tekst + structuur in één record** (§3.2): verplichte vrije tekst; optionele gestructureerde secties per methodiek als aparte velden of een getypeerde sectietabel (sectiecode uit waardelijst: S/O/E/P, D/A/P, T/I/P) — zodat methodiekwissel configuratie is, geen migratie. +- **Auteur en accordering**: auteur verplicht (mens of AI met provenance conform 3.1 #2); status `concept → definitief`; na definitief geen stille edits — correctie = nieuwe versie of aanvulling, cliëntaanvulling (WGBO) als eigen record/vlag. +- **Referenties**: 0..1 contactmoment/consult (relatie met ZPM-registratie, §1.5), 0..n behandeldoelen (met optionele voortgangsindicatie per doel, §4), 0..1 behandelplan (voor evaluatieverslagen), 0..1 intake (verslag-over). + +### 9.2 Overdracht en diensten + +- `include_in_handover`-markering behouden als vlag óf afleiden via typeconfiguratie. +- **Dienst/dagdeel** (nacht/ochtend/middag/avond) als waardelijst; de shift-toewijzingsgrens (07:00) als instellingsconfiguratie, niet hardcoded. Shift-datum consequent voor alle rapportages die in dienstweergaven meedoen. +- De **overdracht zelf** (al dan niet AI-samengevat) is een afgeleid product; als hij wordt vastgelegd, dan met provenance en bronverwijzingen naar de onderliggende rapportages (spelregel 3.1 #2 + TIP-snapshotafspraak §3.3). +- MDO-verslag: rapportagetype op episodeniveau, meerdere betrokken disciplines vastlegbaar. + +### 9.3 Incident + +- Dossieraantekening incident = rapportagetype met gestructureerde art.-10-velden: aard, toedracht, tijdstip, betrokkenen; incidentcategorie uit waardelijst (agressie, medicatie, val, suïcide(poging), vermissing, seksueel grensoverschrijdend, overig). +- VIM-melding = aparte entiteit buiten het cliëntdossier (eigen autorisatie en levenscyclus), optioneel gelinkt aan de dossieraantekening. Calamiteit/IGJ-melding als status/escalatie op de VIM-melding. **Open besluit: hoort VIM in het ECD-domein of erbuiten?** +- Nudge-kansen: "incident met merkbare gevolgen zonder dossieraantekening", "calamiteit → IGJ-termijn 3 werkdagen". + +### 9.4 Zichtbaarheid en rechten + +- Per rapportage: zichtbaarheidsvlag voor cliëntportaal (default per type), wetende dat het Wabvpz-inzagerecht altijd blijft bestaan — de vlag stuurt portaalweergave, geen juridische afscherming. +- Vertrouwelijkheid per deskundigheid (Nedap-patroon "groen slotje") → rollenronde. +- Persoonlijke werkaantekeningen: **geen dossier-entiteit** (NIP); bewust buiten scope houden of als expliciet niet-dossier-domein modelleren. +- Bewaartermijn: 20 jaar vanaf laatste dossierwijziging → het batchjob-criterium van spelregel 3.1 #4 moet op *dossierniveau* rekenen, niet per record. + +### 9.5 Kandidaat-feitzinnen (startlijst voor de rapportage-ronde) + +1. *Voor de zorgepisode van Jan de Vries is op 2 augustus 2026 een rapportage van type "voortgang" vastgelegd door psycholoog M. de Boer.* +2. *De rapportage van 2 augustus is geschreven volgens structuur "SOEP".* / *...heeft als vrije tekst "..." en als sectie "Plan" de tekst "...".* +3. *De rapportage van 2 augustus hoort bij het contactmoment (consult) van 2 augustus 2026.* +4. *De rapportage van 2 augustus rapporteert op behandeldoel "weer drie nachten doorslapen" met voortgang "licht verbeterd".* +5. *De rapportage van 2 augustus heeft status "definitief" sinds 2 augustus 2026, 17:04.* +6. *Verpleegkundige K. Jansen heeft op 3 augustus 2026 om 06:30 een verpleegkundige notitie vastgelegd; deze telt bij de dienst van 2 augustus (nachtdienst).* +7. *De verpleegkundige notitie is gemarkeerd voor de overdracht.* +8. *De rapportage van 2 augustus is zichtbaar voor de cliënt in het portaal.* +9. *Rapportage Y is gegenereerd door AI-model Z op basis van bronnen A en B, en op 3 augustus bevestigd door M. de Boer.* (= feitzin 9 uit discovery §5.2) +10. *Op 5 augustus 2026 om 21:15 heeft zich een incident van categorie "medicatie-incident" voorgedaan rond cliënt Jan de Vries; aard, toedracht en betrokkenen zijn in het dossier aangetekend.* +11. *Voor het incident van 5 augustus is een VIM-melding gedaan; de VIM-melding heeft status "in analyse".* +12. *Cliënt Jan de Vries heeft op 6 augustus 2026 een eigen verklaring aan zijn dossier laten toevoegen.* +13. *Het MDO van 1 september 2026 over de zorgepisode van Jan de Vries is vastgelegd in een MDO-verslag, met betrokken disciplines psychiatrie en verpleegkunde.* + +### 9.6 Open vragen voor de sessie met Colin + +1. Rapportage zonder zorgepisode toestaan (screeningsfase)? Of hangt vroege verslaglegging aan de AANMELDING? +2. Welke rapportagetypen in de startwaardelijst — en vervallen `intake`/`behandeladvies` als rapporttype ten gunste van de eigen entiteiten? +3. Structuurmethodiek: alleen vrije tekst + optionele secties, of SOEP/DAP/TIP als eersteklas sectiemodel? +4. Versiebeheer rapportage: nieuw record per versie of muteren-met-audittrail (zelfde vraag als behandelplan §5.5)? +5. VIM binnen of buiten het ECD? Zo binnen: autorisatiemodel dat het uit het cliëntdossier houdt. +6. Is "definitief maken" (accorderen) een verplichte stap, en zit daar een termijn-nudge op ("verslag nog concept na X dagen")? +7. Dienstgrenzen (07:00 e.d.) per instelling of per afdeling configureerbaar? + +--- + +## Bronnen (samengevat) + +**Wet & toezicht:** [KNMG-richtlijn Omgaan met medische gegevens 2024](https://www.knmg.nl/download/knmg-richtlijn-omgaan-met-medische-gegevens-2) · [KNMG wijzigingen WGBO](https://www.knmg.nl/advies-richtlijnen/dossiers/behandelingsovereenkomst-wgbo/wijzigingen-wgbo.htm) · [Rijksoverheid bewaartermijn](https://www.rijksoverheid.nl/onderwerpen/rechten-van-patient-en-privacy/uw-medisch-dossier/bewaren-medisch-dossier) · [AP rechten dossier](https://www.autoriteitpersoonsgegevens.nl/en/themes/health/health-data-in-a-file/rights-regarding-the-health-data-file) · [Eldermans & Geerts Wabvpz](https://www.eldermans-geerts.nl/per-1-juli-2020-het-recht-op-elektronische-inzage-in-en-afschrift-van-het-medisch-dossier/) · [Holla Wkkgz-meldingen](https://www.holla.nl/nieuws/wkkgz-meldingen) · [IGJ calamiteiten](https://www.igj.nl/onderwerpen/klachten-en-melden/calamiteiten/melding-doen-van-een-calamiteit) · [IGJ suïcidemeldingen ggz](https://www.igj.nl/onderwerpen/klachten-en-melden/suicidepoging) · [Landelijk Kwaliteitsstatuut GGZ 4.0](https://www.zorginzicht.nl/binaries/content/assets/zorginzicht/kwaliteitsinstrumenten/landelijk-kwaliteitsstatuut-ggz-4.0.pdf) · [ZPM spelregels registreren/declareren](https://www.zorgprestatiemodel.nl/content/uploads/2023/07/20230628-Spelregels-correct-registreren-en-declareren_definitief.pdf) + +**Beroepsgroepen:** [V&VN Richtlijn Verslaglegging](https://kennisplatform.venvn.nl/onderwerp/verslaglegging/) · [NIP dossiervorming](https://www.psynip.nl/uw-beroep/cotan/cotan-beoordelingssysteem-ast-en-beroepscode/algemene-standaard-testgebruik-nip-2017/2-2-onderzoeksprocedure/2-2-2-dossiervorming/) · [NIP persoonlijke werkaantekeningen](https://www.psynip.nl/uw-beroep/cotan/cotan-beoordelingssysteem-ast-en-beroepscode/algemene-standaard-testgebruik-nip-2017/2-2-onderzoeksprocedure/2-2-4-persoonlijke-werkaantekeningen/) · [NVvP wet- en regelgeving](https://www.psychiatrie.nl/alle-themas/wet-en-regelgeving/) · [Verenso handreiking MDO](https://www.verenso.nl/kwaliteit/richtlijnen-en-praktijkvoering/richtlijnendatabase/multidisciplinair-overleg-mdo) + +**Methodieken:** [Verslagleggen in de GGZ — SOEP](https://www.verslagleggenindeggz.nl/blog/de-soep-methode-hoe-pas-je-die-toe-in-een-voortgangsrapportages/) · [Verslagleggen in de GGZ — SOEP/SOAP/TIP](https://www.verslagleggenindeggz.nl/blog/soep-soap-of-tip-wat-is-een-handige-opbouw-voor-clientrapportages/) · [NHG SOEP-verslag](https://referentiemodel.nhg.org/node/19) · [Headway DAP notes](https://headway.co/resources/dap-note) · [SimplePractice DAP](https://www.simplepractice.com/resource/how-to-write-dap-notes/) · [eNurse SBAR](https://enurse.nl/2019/02/24/sbar-methode/) + +**ECD-praktijk:** [Nedap Ons cliëntrapportages](https://support.nedap-ons.nl/support/solutions/articles/103000266173-cli%C3%ABntrapportages-in-ons-dossier-toegelicht) · [Nedap Ons rapporttypen configureren](https://support.nedap-ons.nl/support/solutions/articles/103000265596-rapportages-voor-ons-dossier-configureren) · [Nedap Ons rapporteren op doelen](https://support.nedap-ons.nl/support/solutions/articles/103000266084-rapporteren-op-doelen-en-voortgang-in-het-zorgplan-in-ons-dossier) · [Carecheck verslaglegging GGZ](https://carecheck.nl/verslaglegging-in-ggz/) · [Kuno behandelverslag](https://www.heykuno.com/nl/blog/ggz-behandelverslag/) · [Nictiz eOverdracht](https://www.nictiz.nl/informatiestandaarden/eoverdracht/) · [Medicore ECD](https://medicore.nl/medicore-producten/ecd/) diff --git a/docs/datamodel/onderzoek/onderzoek-standaarden.md b/docs/datamodel/onderzoek/onderzoek-standaarden.md new file mode 100644 index 0000000..f391e62 --- /dev/null +++ b/docs/datamodel/onderzoek/onderzoek-standaarden.md @@ -0,0 +1,214 @@ +# Onderzoek NL-zorgstandaarden als checklist voor het ECD-datamodel + +**Status:** onderzoeksrapport (agent "standaarden") +**Datum:** 18 juli 2026 +**Kader:** conform discovery §4 — standaarden zijn *koppelvlak- en uitwisselingszaken*, geen datamodel-regels. Doel per standaard: welke velden/structuren moet ons eigen model minimaal kunnen uitdrukken om later goedkoop te koppelen. Geen enkele standaard wordt als model overgenomen. + +--- + +## 1. Leeswijzer en conclusie vooraf + +Per standaard beantwoordt dit rapport drie vragen: (a) wat is het en wie beheert het, (b) welke structuren/velden zijn relevant voor ons domein, (c) wat betekent dat concreet als *checklist* voor het eigen model. Hoofdconclusies: + +1. **zibs zijn de goedkoopste checklist** voor klinische entiteiten — maar let op: de zib-wereld is in beweging (publicatie 2024 verving o.a. de zib Probleem door Diagnose/Symptoom/AandoeningOfGesteldheid), terwijl de FHIR-implementatiewereld (nl-core) nog op zib-release **2020** zit. Semantisch aansluiten bij zibs ≈ automatisch goedkoop richting FHIR. +2. **Er bestaat géén zib "Verwijzing".** Verwijzing is in NL geregeld via NZa-regels + veldafspraken (verwijstypen 01–07) en de NHG-richtlijn informatie-uitwisseling huisarts-ggz. Onze VERWIJZER/AANMELDING-entiteiten moeten die administratieve werkelijkheid kunnen uitdrukken, niet een zib. +3. **Het Zorgprestatiemodel stelt de hardste eisen** aan wat het model straks moet kunnen: zorgtrajectnummer, prestatiecode-bepalende velden per consult (beroep, type, duur, setting), verwijstype, zorglabels en zorgvraagtypering (HoNOS+). Dit valideert het besluit ZORGEPISODE als eigen entiteit (§5.1 #9) — mits de episode later een ZPM-zorgtraject kan dragen. +4. **DSM-5-TR → ICD-10**: de officiële afleiding bestaat als beheerde codelijst (WHO-FIC Collaborating Centre NL / RIVM). Het discovery-besluit "DSM als bronregistratie, ICD-10 afgeleid via mappingtabel" (§5.4 #1) is exact hoe de keten het bedoeld heeft. Twee risico's: licentie (DSM is auteursrechtelijk van APA/Boom) en versiegeldigheid van de codelijst. +5. **Koppeltaal 2.0** raakt het ECD-model nauwelijks in de kern — het is een FHIR R4-berichtendomein voor eHealth-taken. Vereist wel: stabiele ID's voor cliënt/behandelaar en het kunnen uitdrukken van "toegewezen eHealth-activiteit" (raakt de behandelplan-interventies). +6. **iWmo/iJw** (gemeente-gefinancierde zorg, o.a. jeugd-GGZ) valideert het besluit "wettelijk kader hoort bij de aanmelding" (§5.0 #4): per kader gelden totaal andere administratieve objecten (beschikking/toewijzing/305-307-berichten i.p.v. verwijsbrief/zorgtraject). + +--- + +## 2. Zibs / Nictiz + +### 2.1 Wat en wie + +Zorginformatiebouwstenen (zibs) zijn semantische definities van klinische begrippen (datamodel + waardelijsten + terminologiebindingen), beheerd door **Nictiz**. Vastgesteld als nationale standaard (Informatieberaad Zorg, 2018). Publicaties per jaar; de actuele grote release is **zib-publicatie 2024**; de meeste implementaties (FHIR nl-core, MedMij) zijn nog gebaseerd op **release 2020** (en Basisgegevens GGZ zelfs op 2017). +Bronnen: [Nictiz — wat is een zib](https://www.nictiz.nl/wat-we-doen/activiteiten/zibs/wat-is-een-zib/) · [zibs.nl publicatie 2024](https://www.zibs.nl/wiki/ZIB_Publicatie_2024(NL)) · [Registratie aan de bron](https://www.registratieaandebron.nl/zorginformatiebouwstenen) + +**Belangrijke wijziging in publicatie 2024** ([bron](https://www.zibs.nl/wiki/ZIB_Publicatie_2024(NL))): de zib **Probleem is vervallen** en vervangen door drie nieuwe zibs: **AandoeningOfGesteldheid v1.1**, **Diagnose v2.0** en **Symptoom v2.0**. Ook AllergieIntolerantie en MedicatieContraIndicatie zijn vervangen. Relevante versies 2024: Patient v4.3, Contactpersoon v5.0, Behandeldoel v4.0, BehandelAanwijzing2 v2.1, TekstUitslag v4.4, Zorgverlener v4.0.1, Zorgaanbieder v3.6, Contact v7.0. + +### 2.2 Relevante zibs per onderwerp (checklist) + +**zib Patient v4.3** ([zibs.nl](https://zibs.nl/wiki/Patient-v4.3(2024NL))) — kernelementen: Identificatienummer 0..* (BSN via OID 2.16.840.1.113883.2.4.6.3), Naamgegevens 1 (achternaam, voorvoegsels, voornamen, initialen, roepnaam), Adresgegevens 0..*, Contactgegevens 0..1 (telefoon/e-mail), Geboortedatum 1, Geslacht 1 (codelijst), **Genderidentiteit 0..1** (nieuw t.o.v. oudere versies), MeerlingIndicator, OverlijdensIndicator + DatumOverlijden. +→ *Checklist PERSOON*: BSN als herhaalbaar identificatienummer-patroon (wij: één BSN, versleuteld — voldoende), gestructureerde naam (niet één naamveld!), meerdere adressen mogelijk, geslacht als code uit waardelijst, overlijden als expliciet feit. Genderidentiteit apart van geslacht is voor GGZ relevant — overwegen als optioneel veld. + +**zib Contactpersoon v5.0** ([2024-publicatie](https://www.zibs.nl/wiki/ZIB_Publicatie_2024(NL)); v4.1-pagina: [zibs.nl](https://www.zibs.nl/wiki/Contactpersoon-v4.1(2024NL))) — kern: naam/adres/contactgegevens + **twee gescheiden assen**: *Relatie* (echtgenoot, ouder, kind, …) en *Rol* (eerste contactpersoon, wettelijk vertegenwoordiger, mantelzorger, …), beide uit waardelijsten. +→ *Checklist*: het discovery-besluit PERSOON/rollen (§5.1 #1) past hier perfect: contactpersoon wordt straks een rol op PERSOON met twee attributen (relatie + rol) uit waardelijsten — niet één "type"-veld. Wettelijk vertegenwoordiger is in de GGZ (Wvggz, WGBO, jeugd) een must-have rolwaarde. + +**Verwijzing — géén zib.** In geen enkele zib-publicatie bestaat een bouwsteen "Verwijzing". De inhoudseisen aan een verwijzing komen uit de **NHG-richtlijn Informatie-uitwisseling huisarts-ggz** en de **verwijsafspraken ggz** (veldafspraak zorgprestatiemodel): AGB-code verwijzer, (vermoeden van) DSM-benoemde psychische stoornis, echelon (basis-ggz vs gespecialiseerde ggz), en of het een heraanmelding betreft; geldigheid **9 maanden (275 dagen) tot aanmelddatum** bij de GGZ-aanbieder. Bij onvolledige verwijzing: inspanningsverplichting om info op te halen, aantoonbaar in dossier, behandeling mag wel starten. +Bronnen: [LVVP — eisen verwijsbrief](https://lvvp.info/nieuws/welke-eisen-worden-gesteld-aan-de-verwijsbrief/) · [Verwijsafspraken GGZ (zorgprestatiemodel, nov 2021)](https://www.zorgprestatiemodel.nl/content/uploads/2021/11/Verwijsafspraken-GGZ_november-2021.pdf) · [Zilveren Kruis — verwijzing naar GGZ](https://www.zilverenkruis.nl/zorgaanbieders/zorgsoort/ggz/declareren/verwijzing-naar-ggz) +→ *Checklist AANMELDING/VERWIJZER*: verwijsdatum én aanmelddatum apart (geldigheidstoets), AGB verwijzer + AGB praktijk (besluit §5.1 #3 klopt), echelon-indicatie, heraanmelding-vlag, vermoeden-DSM-stoornis (vrije tekst of code), en het ZPM-**verwijstype** (zie §6.3) als af te leiden/registreerbaar gegeven. + +**Probleem → Diagnose v2.0 (2024)** ([zibs.nl](https://www.zibs.nl/wiki/Diagnose-v2.0(2024NL))) — kern: DiagnoseNaam 1..* (codelijst: SNOMED CT, ICD-10-nl, DHD-thesaurus, ICF, ICPC-1, **DSM-IV/DSM-5** worden expliciet genoemd als toegestane codesystemen), DiagnoseStatus 1 (codelijst), DiagnoseDatum 1, DiagnoseSteller 1 (verwijzing Zorgverlener), WijzeVanVaststellen 1, Toelichting 0..1, Aanleiding 0..*, AandoeningOfGesteldheid 0..1 (verwijzing). De oude zib Probleem (2020, gebruikt in Basisgegevens GGZ) kende daarnaast ProbleemType, ProbleemStatus (actueel/niet-actueel) en verificatiestatus-achtige noties die in FHIR als `clinicalStatus`/`verificationStatus` terugkomen. +→ *Checklist DIAGNOSE*: code + codesysteem + weergavenaam als drieluik (nooit alleen een code-string), datum gesteld, steller, status als aparte as, toelichting. Het discovery-model (§5.4: verificatiestatus + klinische status als twee assen) is uitdrukbaar in zowel zib 2020 (Probleem) als FHIR Condition — houden zo. DSM-5 is een erkend codesysteem binnen de zib — DSM-bronregistratie botst dus niet met de standaardenwereld. + +**zib Behandeldoel v4.0** ([zibs.nl](https://www.zibs.nl/wiki/Behandeldoel-v4.0(2024NL))) — kern: **GewenstZorgresultaat** (tekstuele weergave van het doel), GewensteGezondheidstoestand 0..1 (verwijzing FunctioneleOfMentaleStatus), en een RedenBehandeling-container die verwijst naar Diagnose / Symptoom / VerpleegkundigeDiagnose / OvergevoeligheidIntolerantie. Oudere versie (2020, in FHIR nl-core) kent ook streefdatum en evaluatie-relatie. +→ *Checklist BEHANDELDOEL*: doel als tekst + expliciete **relatie doel → diagnose/probleem** (discovery-feitzin §5.5 #3 "adresseert diagnose F32.1" — dit moet een echte FK-relatie worden, geen tekst), streefdatum/termijn, en evalueerbaarheid. Onze extra's (cliëntversie B1, prioriteit, leefgebied) zijn eigen verrijkingen bovenop het zib-minimum — prima, exporteerbaar als extensie. + +**zib BehandelAanwijzing2 v2.1** ([zibs.nl](https://www.zibs.nl/wiki/BehandelAanwijzing2-v2.1(2024NL))) — kern: Behandeling (codelijst: reanimatie, beademing, opname, …), BehandelBesluit (wel uitvoeren / niet uitvoeren / anders + SpecificatieAnders), MeestRecenteBespreekdatum, DatumBeeindigd + RedenBeeindigd, AfspraakPartij (patiënt / vertegenwoordiger / zorgverlener). Hangt samen met zib Wilsverklaring. +→ *Checklist*: behandelaanwijzingen/wilsverklaringen zitten nog niet in discovery-ronde 1 — voor een GGZ-ECD (crisis, Wvggz-context) op de roadmap zetten. Minimum om te kunnen uitdrukken: welke behandeling, wel/niet-besluit, met wie afgesproken, laatst besproken, beëindigd + reden. Let op patroon: **"anders"-optie met specificatieveld** i.p.v. dichte enum — nuttig ontwerppatroon voor onze waardelijsten. + +**zib TekstUitslag v4.4** ([zibs.nl](https://www.zibs.nl/wiki/TekstUitslag-v4.4(2024NL))) — kern: TekstResultaat 1 (het verslag), TekstUitslagType 1 (code), TekstUitslagDatumTijd 0..1, TekstUitslagStatus 0..1 (pending/preliminary/**final**/corrected), Verrichting 0..1, VisueelResultaat 0..*. +→ *Checklist VERSLAG/RAPPORTAGE* (latere ronde): elk verslag heeft type (code), datum, status met minimaal concept/definitief/gecorrigeerd, en gestructureerde koppeling aan de aanleiding. Sluit naadloos aan op discovery-spelregel 3.1 #2 (provenance) en de AI-voorbereiding (tekst + structuur in één record). + +**GGZ-specifiek relevant, buiten de gevraagde lijst:** de **Basisgegevens GGZ** (MedMij/PGO-informatiestandaard, [functioneel ontwerp](https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/OntwerpGGZ), [inhoud](https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_InhoudGGZ)) is een selectie van ~24 zibs (release 2017) die de sector zelf als kern voor GGZ-uitwisseling heeft aangemerkt: Patient, Burgerlijke Staat, Betaler, **BehandelAanwijzing, Wilsverklaring, JuridischeStatus** (Wvggz!), Contactpersoon, FunctioneleOfMentaleStatus, Probleem, **Drugsgebruik, Alcoholgebruik, Tabakgebruik**, Woonsituatie, Gezinssituatie(Kind), Taalvaardigheid, ParticipatieInMaatschappij, HulpVanAnderen, LaboratoriumUitslag, AlgemeneMeting, Verrichting, TekstUitslag, Zorgverlener, Zorgaanbieder. Dit is de facto de checklist "wat verwacht een PGO/keten van een GGZ-dossier". +→ Voor ons model: **JuridischeStatus** (rechterlijke machtiging/Wvggz-maatregel) en de leefstijl-/sociale-context-zibs zijn kandidaten voor latere rondes; nu alleen borgen dat het model ze als aparte entiteiten kán toevoegen (episodisch, met begin/eind en bron). + +--- + +## 3. FHIR NL: zib-profielen en nl-core (R4) + +**Wat en wie:** Nictiz publiceert twee R4-packagelijnen op basis van zib-release 2020, gevet door HL7 Nederland ([GitHub Nictiz-R4-zib2020](https://github.com/Nictiz/Nictiz-R4-zib2020)): + +- `nictiz.fhir.nl.r4.zib2020` — 1-op-1 representatie van de zibs, **abstract**, niet voor implementatie ([Simplifier](https://simplifier.net/packages/nictiz.fhir.nl.r4.zib2020/0.11.0-beta.1)). +- `nictiz.fhir.nl.r4.nl-core` — de **implementatieprofielen** (afgeleid van de zib-profielen, verrijkt met o.a. expliciete Patient-referenties), dit is wat je in een adapter gebruikt ([Simplifier](https://simplifier.net/packages/nictiz.fhir.nl.r4.nl-core/) · voorbeeld [nl-core-Patient](https://hl7nl.github.io/Nictiz-R4-zib2020-IG/StructureDefinition-nl-core-Patient.html)). + +Relevante mapping onderwerpen → FHIR-resources: Patient→`Patient` (nl-core-Patient), Contactpersoon→`Patient.contact`/`RelatedPerson`, Probleem/Diagnose→`Condition` (met `clinicalStatus` + `verificationStatus` — exact onze twee status-assen), Behandeldoel→`Goal`, BehandelAanwijzing→`Consent`/ACP-profielen, TekstUitslag→`DiagnosticReport`/`DocumentReference`, Verwijzing→`ServiceRequest` (geen zib, wel een FHIR-resource), Zorgepisode→`EpisodeOfCare`, Behandelplan→`CarePlan`. + +→ *Checklist (adapter-goedkoopte, geen modeleis):* +- Overal **stabiele UUID's** (spelregel 3.1 #5) — FHIR-resources hebben een logical id nodig; onze UUID's kunnen 1-op-1 mee. +- Codes altijd als **(code, systeem, display)** opslaan, nooit alleen een label — FHIR `CodeableConcept` is dan een triviale projectie. Dit is dezelfde les als spelregel 3.1 #1 (waardelijsten als data): geef elke waardelijstrij optioneel een externe code + codesysteem-URI kolom. +- Status-assen gescheiden houden (klinisch vs verificatie op diagnose; plan-status vs cliëntakkoord op behandelplan — FHIR CarePlan kent `status` en separaat `Consent`). +- Versies: nl-core R4 is formeel nog beta (0.x); niets in beton gieten, alleen semantisch niet nodeloos afdrijven (discovery §4, aandachtspunt). + +--- + +## 4. Koppeltaal 2.0 (GGZ-specifiek) + +**Wat en wie:** Koppeltaal is de GGZ-standaard + infrastructuur (beheer: **VZVZ**, eigenaar: Stichting Koppeltaal) om **EPD/ECD, ROM-vragenlijsten en eHealth-modules** binnen een "domein" van een zorgaanbieder te verbinden. Koppeltaal 2.0 is **FHIR R4**-gebaseerd; profielen staan op Simplifier ([project koppeltaalv2.0](https://simplifier.net/koppeltaalv2.0)), documentatie in de [Koppeltaal 2.0 Dev Guide](https://vzvz.gitbook.io/koppeltaal-2.0-dev-guide) en op [koppeltaal.nl](https://www.koppeltaal.nl/koppeltaal/koppeltaal-20). + +**Kernresources/-profielen** (KT2-profielen, o.a. KT2Patient, KT2Practitioner, KT2CareTeam, KT2Task, [KT2ActivityDefinition](https://simplifier.net/Koppeltaal/KoppeltaalActivityDefinition), Endpoint, Device, Subscription; de server dwingt profielconformiteit af, bijv. op [KT2Task](https://vzvz.gitbook.io/koppeltaal-2.0-dev-guide/hackathon-use-cases/crud-task/use-case-1-opvoeren-taak)): + +- **ActivityDefinition** — een aanbieder publiceert een eHealth-activiteit (module, vragenlijst, game) domeinbreed. +- **Task** — toewijzing van zo'n activiteit aan een specifieke cliënt, altijd gebaseerd op een ActivityDefinition; aangemaakt vanuit het behandelaarportaal/ECD. Status-lifecycle: `completed|cancelled|failed|rejected`; resources worden **niet verwijderd** maar end-of-life gemarkeerd (ActivityDefinition `retired`) — zelfde filosofie als onze soft delete ([resources managen](https://vzvz.gitbook.io/koppeltaal-2.0-dev-guide/technische-howto/resources-managen)). +- **Patient/Practitioner/RelatedPerson/CareTeam** — identiteiten binnen het domein; **Endpoint/Device** — aangesloten applicaties; **Subscription** — notificaties bij wijzigingen; launch via **HTI** (Health Tools Interoperability, JWT-gebaseerd). + +→ *Checklist ECD-model:* +1. CLIENT en BEHANDELAAR moeten met stabiele ID's naar buiten te refereren zijn (hebben we: UUID's) en Koppeltaal-traceerbaarheid vergt geen extra ECD-velden. +2. Het behandelplan-deel "interventies" (discovery §5.5) moet een interventie kunnen typeren als **eHealth-activiteit met externe referentie** (welke module, bij welke aanbieder, welke taak-status). Minimaal: een optioneel extern-referentieveld (systeem + id) op interventie/activiteit — dan is een Koppeltaal-adapter later een dunne laag. +3. Taak-/opdrachtstatus (toegewezen → gestart → afgerond/geannuleerd) is proces-state: kandidaat-**TIP-terrein** (grensvlak §3.3), niet per se ECD. De klinische uitkomst (bijv. ROM-uitslag) is wél ECD. + +--- + +## 5. DSM-5-TR → ICD-10-mapping + +**Hoe de officiële mapping werkt en wie hem beheert:** + +- De **DSM-5-TR** zelf is van de American Psychiatric Association; de Nederlandse vertaling/uitgave ligt bij **Boom uitgevers** ([boom.nl](https://www.boom.nl/psychiatrie/101-4_DSM-5-TR)). Auteursrecht en licenties lopen via APA/Boom — de Nederlandse Staat had voor keten-gebruik een licentie ([whofic.nl](https://www.whofic.nl/dsm-5icd-10)). +- Het **WHO-FIC Collaborating Centre Nederland** (ondergebracht bij RIVM) beheert en publiceert de **"Codelijst DSM-5(-TR) met ICD-10 afleidingen"**: per DSM-classificatie de afgeleide ICD-10-code(s) ([whofic.nl — DSM-5/ICD-10](https://www.whofic.nl/dsm-5icd-10) · [codelijst-document](https://www.whofic.nl/documenten/codelijst-dsm-5-tr-met-icd-10-afleidingen)). De DSM-5-TR gebruikt in de VS ICD-10-CM-codes; de NL-codelijst leidt af naar ICD-10 zoals in NL gebruikt. De lijst is versioneerd met ingangs- en einddatum (bijv. publicatie 15-12-2023, geldig per 1-1-2024; die versie is niet meer geldig vanaf 1-1-2026 — er verschijnen dus periodiek opvolgers). +- Gebruiksbeperking: de codelijst mag **uitsluitend** worden gebruikt in "declaratie-, registratie- en informatiesystemen van de ggz en fz" ten behoeve van NZa-regelgeving; ander gebruik vereist afstemming met Boom ([whofic.nl](https://www.whofic.nl/documenten/codelijst-dsm-5-tr-met-icd-10-afleidingen)). +- Voor de relatie met NZa-diagnosehoofdgroepen bestaat aanvullend een afleiding DSM-hoofdgroep/ICD-10 → NZa-diagnosehoofdgroep ([beta.nl/ggzdiagnosen](https://beta.nl/ggzdiagnosen/)). + +**Registratieplicht in beweging (2024–2028):** de NZa-verplichting om DSM-gegevens op de factuur te zetten kreeg per 1-1-2025 een juridisch probleem (grondslag); sindsdien geldt: aanlevering DSM-hoofdgroep aan verzekeraars alleen met **getekende toestemmingsverklaring (opt-in)** van de patiënt, en VWS heeft per aparte ministeriële regeling ([Stcrt. 2025-11955](https://zoek.officielebekendmakingen.nl/stcrt-2025-11955.html)) de registratie-/aanleverplicht van DSM-hoofdgroep of basis-ggz-profiel op de factuur richting 2027/2028 geborgd. In het risicoverevenings-/bekostigingsdenken vervangt **zorgvraagtypering** op termijn de DSM-rol ([zorgprestatiemodel.nl — opt-in](https://www.zorgprestatiemodel.nl/nieuws/tijdelijke-toestemmingsverklaring-opt-in-voor-vermelden-van-gegevens-over-de-dsm-hoofdgroepdiagnose-of-het-basis-ggz-profiel-op-factuur/) · [zorgictzorgen.nl](https://zorgictzorgen.nl/grondslag-ggz-declaraties-per-2025-durft-nza-niet-te-wijzigen/)). + +→ *Checklist DIAGNOSE (bevestigt discovery-besluit §5.4 #1, met verscherping):* +1. **Bronregistratie in DSM-5-TR-termen; ICD-10 afgeleid via de WHO-FIC-codelijst** — als geïmporteerde, **versioneerde referentietabel** (kolommen minimaal: DSM-code, DSM-omschrijving, afgeleide ICD-10-code(s), ingangsdatum, einddatum, lijstversie). Nooit hardcoden. +2. Op het diagnoserecord vastleggen **met welke lijstversie** de afleiding is gedaan (reproduceerbaarheid bij herdeclaratie/controle). +3. Eén DSM-code kan naar **meerdere ICD-10-codes** leiden (en vice versa) — de mappingrelatie is m:n; het model moet dat aankunnen (aparte mappingtabel, geen kolom "icd10_code" met uniciteitsaanname). +4. **DSM-hoofdgroep** als afleidbaar gegeven (voor factuur/verzekeraar) + een plek voor de **opt-in-toestemmingsverklaring** van de cliënt (raakt privacy/toestemmings-entiteit — latere ronde, wel als open punt noteren). +5. **Open punt licentie (nieuw, geen teruggedraaid besluit):** commercieel gebruik van DSM-omschrijvingen in een ECD-product vereist vermoedelijk een licentie bij Boom/APA; de WHO-FIC-codelijst is alleen vrij voor NZa-doeleinden. Uitzoeken vóór de bouw van de diagnosemodule. + +--- + +## 6. Zorgprestatiemodel (ZPM) + +**Wat en wie:** bekostigingsmodel ggz/fz sinds 2022 (NZa + veldpartijen; programma [zorgprestatiemodel.nl](https://www.zorgprestatiemodel.nl)). Regelgeving: jaarlijkse NZa-regeling — voor 2026 is dat **NR-REG-2616b** met tariefbeschikking TB/REG-26628-05 en "Codetabel prestaties en tarieven v20260401" ([NZa — regels 2026](https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/nieuwe-bekostiging-ggz/welke-regels-gelden-voor-de-ggz-en-fz-in-2026) · [Registreren en declareren ggz/fz](https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/nieuwe-bekostiging-ggz) · [Veldafspraken 2025](https://www.zorgprestatiemodel.nl/content/uploads/2025/01/20250131-Veldafspraken-2025-.pdf)). + +### 6.1 Zorgtraject + +Het zorgtraject start zodra een patiënt zich met een psychische zorgvraag meldt; de aanbieder kent een **zorgtrajectnummer** toe en koppelt dat aan **alle** ggz-prestaties voor die patiënt tot einde behandeling. Bij terugval/recidive **binnen een jaar** na de laatste prestatie moet **hetzelfde zorgtrajectnummer** hergebruikt worden ([NZa](https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/nieuwe-bekostiging-ggz)). Prestaties zijn dag-gebonden (losse consulten/verblijfsdagen), niet 365-dagen-trajecten zoals de oude DBC's ([Informatiekaart ZPM](https://puc.overheid.nl/nza/doc/PUC_646523_22/)). + +→ *Checklist ZORGEPISODE*: de episode moet een **zorgtrajectnummer** kunnen dragen (uniek per cliënt-aanbieder-zorgvraag), en de "terugval binnen 1 jaar → zelfde nummer"-regel betekent: episode-einde is geen harde afsluiting van het trajectnummer. Modelmatig: zorgtraject (ZPM/declaratie-object) en zorgepisode (klinisch object) zijn **verwant maar niet identiek** — discovery §5.1 #9 zegt al "sluit straks aan op het ZPM-zorgtraject (declaratie-ronde)"; dit onderzoek bevestigt: maak het t.z.t. een aparte, gekoppelde entiteit, forceer geen 1-op-1. + +### 6.2 Prestatiecodes + +De prestatiecode + het tarief van een consult wordt bepaald door **vier assen**: (1) **beroepscategorie** van de uitvoerder (NZa-beroepenlijst), (2) **type consult** (diagnostiek of behandeling), (3) **duur** (tijdsklassen "vanaf x minuten"; registratie op basis van *geplande* tijd, "planning = realisatie"-principe), (4) **setting** (o.a. ambulant kwaliteitsstatuut sectie II/III, outreachend, klinisch — met varianten hoog/laag). Daarnaast bestaan aparte prestaties voor verblijfsdagen, toeslagen (o.a. tolk) e.d. Codetabellen worden door de NZa gepubliceerd ([Toelichting tabellen ggz/fz](https://www.zorgprestatiemodel.nl/shared/content/uploads/2021/09/20210927-Toelichting-tabellen.pdf) · [Codetabel prestaties en tarieven](https://puc.overheid.nl/nza/doc/PUC_641029_22/4/) · [beroepenlijst-wijzigingen](https://www.zorgprestatiemodel.nl/nieuws/aanpassingen-in-beroepenlijst/)). + +→ *Checklist* (grotendeels agenda/declaratie-rondes, maar het fundament ligt nu): +- Elk contactmoment/consult moet kunnen vastleggen: **uitvoerder + diens beroep** (referentie naar NZa-beroepenlijst als geïmporteerde tabel), **type** (diagnostiek/behandeling), **geplande duur**, **setting** (waardelijst per instelling-locatie). Discovery-contactmomenten (§5.2) hebben al type+uitvoerder; beroep-van-uitvoerder komt via de rollenronde — borgen dat MEDEWERKER straks een beroepscode uit een NZa-lijst kan dragen. +- Prestatie- en tariefcodetabellen zijn **jaarlijks wisselende referentiedata** met geldigheidsperioden → zelfde import-patroon als de DSM-codelijst (versie + ingangs-/einddatum). Nooit hardcoden (spelregel 3.1 #1). + +### 6.3 Verwijstypen en zorglabels + +De ZPM-veldafspraken definiëren **verwijstypen** (registratie naast de AGB-code van de verwijzer) ([Verwijstypen en zorglabels, jan 2022](https://www.zorgprestatiemodel.nl/content/uploads/2022/01/20220111-Verwijstypen-en-zorglabels.pdf)): + +| Nr | Verwijstype | +|---|---| +| 01 | Verwijzing aanwezig (AGB initiële verwijzer) | +| 02 | Doorverwijzing (AGB verwijzende regiebehandelaar) | +| 03 | Geen verwijzing — uitzondering, verlate correspondentie (huisarts binnen 60 dagen informeren) | +| 04 | Geen verwijzing — patiënt staat correspondentie met huisarts niet toe | +| 05 | Geen verwijzing (factuur mag niet naar zorgverzekeraar) | +| 06 | Geen verwijzing, andere rechtmatigheidsgrond (alleen fz) | +| 07 | Verwijzing aanwezig, maar verwijzer heeft geen AGB-code (bijv. buitenlands) | + +Daarnaast **zorglabels** op prestaties voor uitzonderingssituaties: publiek (N01–N04, NZa-regelgeving: o.a. overgang jeugd-ggz → Zvw, tolk-toeslag), generiek privaat (G01–G04, veldafspraken: o.a. uitzonderingen "minimale betrokkenheid regiebehandelaar", Ketenveldnorm levensloopfunctie, acute ggz buiten budget) en specifiek privaat (S01–S03, contractueel: o.a. digitale zorg). + +→ *Checklist*: het discovery-verwijzertype (huisarts/specialist/gemeente/zelfaanmelding/… §5.0 #3) is een **ander begrip** dan het ZPM-verwijstype (01–07, een declaratiestatus van de verwijzing). Beide nodig: ons verwijzertype beschrijft *wie* verwijst; het ZPM-verwijstype is afleidbaar uit (aanwezigheid verwijzing × AGB × toestemmingsvlaggen) maar moet ook overschrijfbaar geregistreerd kunnen worden. Verwijstype 03/04 tonen bovendien twee feiten die het model moet kennen: "huisarts geïnformeerd op datum X" en "cliënt staat correspondentie met huisarts niet toe" (toestemmingsfeit!). Zorglabels: prestatie-niveau, declaratie-ronde — alleen borgen dat prestaties later 0..n labels uit een NZa-tabel kunnen dragen. + +### 6.4 Zorgvraagtypering (HoNOS+) + +Bij de start van een behandeling (en bij herijking) wordt een **HoNOS+**-vragenlijst afgenomen: **19 items, score 0–4** (items 1–12 = klassieke HoNOS, plus 13, A–E en Q). De NZa-**zorgvraagtyperingstool** (een door de NZa gepubliceerd algoritme) adviseert op basis daarvan zorgvraagtypes; de **behandelaar kiest** uiteindelijk zelf het zorgvraagtype (advies is niet bindend). Het zorgvraagtype staat verplicht op de factuur; sinds **1 juli 2023** worden zorgvraagtyperingsgegevens ook verplicht aan de NZa aangeleverd volgens de "Standaard voor gegevensaanlevering zorgvraagtypering" (na een AP-discussie over de rechtmatigheid, met privacyverklaring-optie voor de patiënt) ([Embloom — FAQ HoNOS+](https://www.embloom.nl/veelgestelde-vragen-over-de-honos/) · [NZa zorgvraagtyperingstool](https://www.zorgprestatiemodel.nl/nieuws/zorgvraagtyperingstool-nza-online/) · [algoritmeregister — zorgvraagtypering](https://algoritmes.overheid.nl/nl/algoritme/zb000158/97912239/zorgvraagtypering) · [NZa Q&A aanlevering](https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/vraag-en-antwoord/vraag-en-antwoord-zorgvraagtypering) · [Standaard gegevensaanlevering (PUC_705646_22)](https://puc.overheid.nl/PUC/Handlers/DownloadDocument.ashx?identifier=PUC_705646_22&versienummer=2&type=pdf&ValChk=89nf2n26dv_DAuBfeXxRzVtQuS-8DOi3kmeb1fKvw5g1)) + +→ *Checklist* (nieuwe entiteit voor een latere ronde, hangt aan ZORGEPISODE): +- **Meetinstrument-afname** als generiek patroon: instrument (HoNOS+), afnamedatum, afnemer, 19 itemscores (0–4) als gestructureerde data. +- **Zorgvraagtypering** als apart record: geadviseerd(e) type(s) door algoritme (+ tool-/algoritmeversie!), gekozen type door behandelaar, datum, relatie naar de afname. Advies ≠ keuze — twee velden, en dit is een mooi voorbeeld van het provenance-patroon (spelregel 3.1 #2: algoritme-advies = AI/algoritme-herkomst, keuze = mens). +- Aanlevering NZa + privacyverklaring: raakt dezelfde toestemmings-/opt-outstructuur als §5.4 — één toekomstige toestemmingsentiteit kan beide dragen. + +--- + +## 7. iStandaarden: iWmo en iJw (gemeente-gefinancierde zorg) + +**Wat en wie:** de **iStandaarden** worden beheerd door **Zorginstituut Nederland**; iWmo (Wmo 2015) en iJw (Jeugdwet) regelen het berichtenverkeer tussen zorgaanbieders en gemeenten. Actuele release: **iWmo 3.2 / iJw 3.2** (in productie sinds 3 april 2023, big bang; geen nieuwe major release in 2025) ([istandaarden.nl](https://www.istandaarden.nl/) · [release iWmo 3.2](https://www.istandaarden.nl/iwmo/releases/release-iwmo-3.2) · [informatiemodel iJw 3.2](https://informatiemodel.istandaarden.nl/informatiemodel/ijw/3.2/processen/start-melden/)). + +**Berichtenstructuur** (identiek patroon iWmo/iJw, verschil zit in wet, productcodes en enkele velden; [Heldy — iWmo uitgelegd](https://www.heldy.nl/kennisbank/wmo/iwmo-uitgelegd) · [iJw uitgelegd](https://www.heldy.nl/kennisbank/jeugdzorg/ijw-uitgelegd)): + +- **301/302 Toewijzing**: gemeente wijst zorg toe (toewijzingsnummer, productcategorie/productcode, volume/frequentie, begindatum, ev. einddatum). +- **305/306 Start zorg**: aanbieder meldt werkelijke startdatum. **307/308 Stop zorg**: melding einde + reden. +- **303/304 Declaratie**: periodiek, per toewijzing; regels met productcode, volume, tarief; gemeente keurt per regel goed/af. +- Daarnaast verzoek om toewijzing (315/316) en regieberichten ([analyse regieberichten](https://www.istandaarden.nl/binaries/content/assets/istandaarden/iwmo/iwmo-3.1.0/analyse-08---regieberichten.pdf)). +- **Uitvoeringsvarianten**: inspanningsgericht (p×q), outputgericht, taakgericht — bepalen welke berichten gebruikt worden ([handreiking uitvoeringsvarianten](https://www.istandaarden.nl/binaries/content/assets/istandaarden/iwmo/handreiking-uitvoeringsvarianten-iwmo-en-ijw.pdf)). + +→ *Checklist* (valideert discovery §5.0 #4: wettelijk kader op de aanmelding): +1. Bij kader **Jeugdwet/Wmo** is de "verwijzing" feitelijk een **beschikking/toewijzing van de gemeente** met eigen sleutelgegevens: gemeente(code), toewijzingsnummer, productcategorie + productcode, toegewezen volume/frequentie, begin-/einddatum. Discovery-besluit §5.1 #7 ("beschikking telt ook als verwijzing", waardelijst `verwijsdocument_type`) klopt — maar de toewijzing heeft méér structuur dan een document: op termijn een eigen entiteit TOEWIJZING onder de aanmelding/episode bij gemeentelijk kader. +2. Start-/stopdatum van zorg moeten als harde feiten uit het model af te leiden zijn (305/307 zijn direct te genereren uit episode-start en -einde + reden — beëindigingsredenen-waardelijst van de episode moet t.z.t. mappen op de iStandaarden-redenenlijst). +3. Productcodes zijn (net als ZPM-tabellen en DSM-codelijst) **externe, versioneerde referentiedata** per gemeente/regio — zelfde importpatroon. +4. Woonplaatsbeginsel (jeugd): de verantwoordelijke gemeente is een gegeven aan de aanmelding-/financieringskant, niet aan de persoon. + +--- + +## 8. Geconsolideerde checklist per discovery-entiteit + +| Entiteit (discovery) | Moet minimaal kunnen uitdrukken (uit standaarden) | Bron | +|---|---|---| +| PERSOON | gestructureerde naamdelen; meerdere adressen; geslacht (code) + evt. genderidentiteit; overlijden(sdatum); BSN als geïdentificeerd nummer | zib Patient | +| Rol CONTACTPERSOON (later) | relatie én rol als twee aparte waardelijsten; wettelijk vertegenwoordiger | zib Contactpersoon | +| VERWIJZER / PRAKTIJK | AGB persoonlijk + AGB praktijk (besloten); verwijzertype; "verwijzer zonder AGB" mogelijk | ZPM-verwijsafspraken | +| AANMELDING | verwijsdatum ≠ aanmelddatum (275-dagen-toets); echelon; heraanmelding-vlag; ZPM-verwijstype 01–07 (afleidbaar/overschrijfbaar); huisarts-geïnformeerd-feit + correspondentie-toestemming; bij Wmo/Jw: toewijzingsgegevens (gemeente, nummer, productcode, volume, periode) | ZPM, NHG, iWmo/iJw | +| ZORGEPISODE | koppelbaar aan ZPM-zorgtrajectnummer (hergebruik bij terugval <1 jaar → geen 1-op-1); start/stop + reden (iStd 305/307); draagt zorgvraagtypering | NZa-regeling, iStandaarden | +| DIAGNOSE | (code, systeem, display)-drieluik; DSM-bron + versioneerde m:n-mapping naar ICD-10 incl. lijstversie op het record; DSM-hoofdgroep afleidbaar; steller + datum + wijze van vaststellen; twee status-assen | zib Diagnose, WHO-FIC-codelijst, NZa | +| BEHANDELPLAN / DOEL | doel-tekst + FK naar diagnose; streefdatum/termijn; planstatus ≠ cliëntakkoord (apart feit); interventie met optionele externe eHealth-referentie (systeem+id) | zib Behandeldoel, FHIR CarePlan/Consent, Koppeltaal | +| CONTACTMOMENT (agenda-ronde) | uitvoerder + beroepscode (NZa-lijst); type diagnostiek/behandeling; geplande duur; setting; 0..n zorglabels | ZPM-codetabellen | +| Waardelijsten algemeen | elke rij optioneel externe code + codesysteem-URI + geldigheidsperiode; "anders"-optie met specificatieveld waar zinvol | zibs/FHIR-patroon | +| Referentiedata-import (nieuw patroon) | één generiek mechanisme voor versioneerde externe tabellen: DSM/ICD-10-codelijst, NZa-prestatie-/beroepen-/zorglabeltabellen, iStd-productcodes, AGB (al geparkeerd) — met versie, ingangs- en einddatum | alle | + +## 9. Open vragen en risico's (geen teruggedraaide besluiten) + +1. **DSM-licentie**: gebruik van DSM-5-TR-omschrijvingen in een commercieel ECD vereist vermoedelijk afspraken met Boom/APA; de WHO-FIC-codelijst is alleen vrijgegeven voor NZa-doeleinden. Uitzoeken vóór de diagnosemodule-bouw. +2. **Geldigheid codelijst DSM→ICD-10 in 2026**: de versie van 15-12-2023 is per 1-1-2026 vervallen; bevestigen welke opvolgerversie nu geldt (whofic.nl) en dat abonneren op updates onderdeel wordt van het referentiedata-importpatroon. +3. **zib 2020 vs 2024**: nl-core (FHIR) volgt zib 2020 (Probleem), de zib-wereld is naar 2024 (Diagnose). Ons model volgt geen van beide letterlijk; bij adapterbouw de dan geldende nl-core-versie kiezen. +4. **Zorgtraject ↔ zorgepisode**: hergebruikregel trajectnummer (<1 jaar terugval) botst mogelijk met een strikte episode-afsluiting — ontwerpbeslissing voor de declaratie-ronde, nu alleen niet-1-op-1 aannemen. +5. **Toestemmingen** duiken op drie plekken op (DSM-hoofdgroep op factuur/opt-in, huisarts-correspondentie bij verwijstype 04, privacyverklaring zorgvraagtypering): pleit voor één generieke TOESTEMMING-entiteit in een latere ronde. +6. **DSM-registratieplicht is politiek in beweging** (grondslag-discussie 2025, zorgvraagtypering als opvolger richting 2028): declaratie-gerelateerde DSM-velden flexibel houden, niets aan de factuurketen hardcoden. + +## 10. Bronnen (hoofdlijst) + +- Nictiz zibs: https://www.nictiz.nl/wat-we-doen/activiteiten/zibs/ · https://www.zibs.nl/wiki/ZIB_Publicatie_2024(NL) · https://zibs.nl/wiki/Patient-v4.3(2024NL) · https://www.zibs.nl/wiki/Diagnose-v2.0(2024NL) · https://www.zibs.nl/wiki/Behandeldoel-v4.0(2024NL) · https://www.zibs.nl/wiki/BehandelAanwijzing2-v2.1(2024NL) · https://www.zibs.nl/wiki/TekstUitslag-v4.4(2024NL) +- FHIR NL: https://github.com/Nictiz/Nictiz-R4-zib2020 · https://simplifier.net/packages/nictiz.fhir.nl.r4.nl-core/ · https://hl7nl.github.io/Nictiz-R4-zib2020-IG/StructureDefinition-nl-core-Patient.html +- Basisgegevens GGZ: https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/OntwerpGGZ · https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_InhoudGGZ +- Koppeltaal 2.0: https://www.koppeltaal.nl/koppeltaal/koppeltaal-20 · https://simplifier.net/koppeltaalv2.0 · https://simplifier.net/Koppeltaal/KoppeltaalActivityDefinition · https://vzvz.gitbook.io/koppeltaal-2.0-dev-guide +- DSM/ICD-10: https://www.whofic.nl/dsm-5icd-10 · https://www.whofic.nl/documenten/codelijst-dsm-5-tr-met-icd-10-afleidingen · https://beta.nl/ggzdiagnosen/ · https://zoek.officielebekendmakingen.nl/stcrt-2025-11955.html · https://www.zorgprestatiemodel.nl/nieuws/tijdelijke-toestemmingsverklaring-opt-in-voor-vermelden-van-gegevens-over-de-dsm-hoofdgroepdiagnose-of-het-basis-ggz-profiel-op-factuur/ +- Zorgprestatiemodel/NZa: https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/nieuwe-bekostiging-ggz · https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/nieuwe-bekostiging-ggz/welke-regels-gelden-voor-de-ggz-en-fz-in-2026 · https://www.zorgprestatiemodel.nl/content/uploads/2022/01/20220111-Verwijstypen-en-zorglabels.pdf · https://www.zorgprestatiemodel.nl/content/uploads/2021/11/Verwijsafspraken-GGZ_november-2021.pdf · https://www.zorgprestatiemodel.nl/shared/content/uploads/2021/09/20210927-Toelichting-tabellen.pdf · https://puc.overheid.nl/nza/doc/PUC_641029_22/4/ +- Zorgvraagtypering: https://www.embloom.nl/veelgestelde-vragen-over-de-honos/ · https://algoritmes.overheid.nl/nl/algoritme/zb000158/97912239/zorgvraagtypering · https://www.nza.nl/zorgsectoren/geestelijke-gezondheidszorg-ggz-en-forensische-zorg-fz/vraag-en-antwoord/vraag-en-antwoord-zorgvraagtypering +- iStandaarden: https://www.istandaarden.nl/ · https://www.istandaarden.nl/iwmo/releases/release-iwmo-3.2 · https://www.heldy.nl/kennisbank/wmo/iwmo-uitgelegd · https://www.heldy.nl/kennisbank/jeugdzorg/ijw-uitgelegd · https://www.istandaarden.nl/binaries/content/assets/istandaarden/iwmo/handreiking-uitvoeringsvarianten-iwmo-en-ijw.pdf diff --git a/docs/datamodel/sessielogs/sessielog-2026-07-18.md b/docs/datamodel/sessielogs/sessielog-2026-07-18.md new file mode 100644 index 0000000..ce807d7 --- /dev/null +++ b/docs/datamodel/sessielogs/sessielog-2026-07-18.md @@ -0,0 +1,432 @@ +# Sessielog datamodel — 18 juli 2026 + +**Status:** chronologisch werkverslag +**Doel:** context, redenering, correcties en voortgang van de sessie bewaren +**Autoriteit:** dit sessielog is niet normatief; `../besluiten/besluitenlog-datamodel-2026-07-18.md` blijft leidend voor genomen besluiten +**Vervolg:** eerste FCO-IM-feitenronde voor referral/instroom + +## 1. Aanleiding + +De sessie begon met een beoordeling van de bestaande map `docs/datamodel`. De map bleek een FCO-IM-geïnspireerde discovery en modelleursronde voor het GGZ-ECD te bevatten, van aanmelding tot behandelplan. + +De eerste analyse identificeerde: + +- een bruikbare scheiding tussen ECD-feiten en TIP-procesbewaking; +- een voorgestelde ZORGEPISODE als klinisch anker; +- uitgewerkte modellen voor aanmelding, screening, intake, wachtlijst, diagnose, behandelplan en rapportage; +- ontbrekende of nog niet uitgewerkte rollen, autorisatie, agenda en declaratie; +- een achterlopende HTML-entiteitenkaart; +- een ontbrekend `onderzoek-proces.md`; +- onderlinge spanningen rond episodevorming, toestemming, wachtlijst en behandelplanversies. + +Afgesproken werd de open beslispunten eerst integraal te verzamelen en daarna één voor één inhoudelijk te bespreken. + +## 2. Aanmelding, acceptatie en zorgepisode + +### 2.1 Financiële en zorginhoudelijke start + +Colin corrigeerde het aanvankelijke voorstel dat een zorgepisode eenvoudig bij de uitkomst `intake` ontstaat. + +Belangrijke praktijkinzichten: + +- de financiële start en zorginhoudelijke start zijn niet hetzelfde; +- een aanmeldfase kan tot behandeling leiden, maar hoeft dat niet; +- eerdere aanmeldingen kunnen voor latere zorg relevant zijn; +- de zorgpraktijk is minder lineair dan regels en datamodellen vaak suggereren; +- bewaarplicht en bewaardoel verschillen naar gelang daadwerkelijk zorg tot stand komt. + +Hieruit volgde de scheiding tussen: + +1. aanmelding en institutionele beoordeling; +2. zorginhoudelijke episode; +3. financieel traject. + +De zorgepisode ontstaat bij een formeel acceptatiebesluit. Daarbij is expliciet vastgelegd dat acceptatie alleen toegang tot het zorgproces betekent en niet automatisch een behandelovereenkomst, zorgplicht, toegewezen behandelaar of organisatorische verantwoordelijkheid bewijst. + +Na afsluiting leidt terugkeer tot een nieuwe, gerelateerde zorgepisode. Een historische relatie geeft nooit automatisch inzage. + +### 2.2 Instellingbrede episode + +Colin verduidelijkte dat één zorgepisode binnen een instelling meerdere zorgprogramma’s en organisatorische eenheden kan omvatten. + +Daarom: + +- opent een interne overdracht niet automatisch een nieuwe episode; +- worden programma- en organisatiebetrokkenheid tijdgebonden relaties; +- zijn meerdere gelijktijdige episodes technisch mogelijk, maar binnen één instelling een gemotiveerde uitzondering; +- worden autorisatie en historische episodekoppeling afzonderlijk gemodelleerd. + +## 3. Binnenkomsten en aanmeldingstrajecten + +De mogelijkheid van meerdere aanmeldingen bleek een terminologisch en conceptueel probleem. Een cliënt kan informatie vanuit meerdere stromen of instanties ontvangen, maar iedere binnenkomst hoeft geen nieuw institutioneel traject te openen. + +Daarom werd onderscheid gemaakt tussen: + +- **aanmeldsignaal:** iedere afzonderlijke binnenkomst; +- **aanmeldingstraject:** de institutionele beoordeling van één samenhangende zorgvraag. + +De UX moet bij overlap ondersteunen: + +- koppelen aan een bestaand traject; +- een parallel traject starten met reden; +- als duplicaat registreren; +- logisch samenvoegen. + +Samenvoegen blijft niet-destructief. Alle oorspronkelijke bronnen en auditinformatie blijven behouden. AI mag matches voorstellen, maar nooit zelfstandig samenvoegen. + +Later in de sessie is de Engelse terminologie voor deze begrippen opnieuw onderzocht; zie §10. + +## 4. Intake + +De intake werd aangescherpt tot één dynamisch onderzoekstraject per samenhangende zorgvraag. + +Een intake kan bestaan uit: + +- meerdere gesprekken en contacten; +- meerdere onderzoeken; +- meerdere disciplines; +- meerdere bevindingen en bijdragen. + +Een intern afdelingscontact of organisatorische overgang is geen nieuwe intake. Parallelle intakes zijn alleen zinvol voor aantoonbaar verschillende zorgvragen. + +Open blijft of de intake altijd na formele acceptatie begint of deels vóór acceptatie kan plaatsvinden. Dat bepaalt of intake primair aan het aanmeldingstraject, de zorgepisode of een overgang tussen beide hangt. + +## 5. Wachtlijst + +De aanvankelijke modellering van wachtlijstplaatsing met status en opschortingsperioden bleek te eenvoudig voor de GGZ-wachtlijstproblematiek. + +Vastgelegde uitgangspunten: + +- de volledige tijdlijn blijft behouden; +- oorspronkelijke aanmeld- en wachtdatum worden niet overschreven; +- bruto wachttijd blijft altijd zichtbaar; +- netto of gecorrigeerde wachttijd is een versiegebonden afleiding; +- verplaatsing tussen teams of programma’s mag wachttijd niet ongemerkt resetten; +- capaciteitstekort en cliëntgebonden uitstel moeten afzonderlijk herkenbaar zijn. + +Nog te onderzoeken: + +- regulatoire wachttijd versus operationele wachtrij; +- teldatums; +- aftrekbare perioden; +- aanbodmomenten; +- prioritering; +- beëindigingsredenen; +- actuele NZa-regels en Treeknormrapportage; +- cardinaliteiten van wachtlijstplaatsingen. + +Conclusie: er is genoeg basis om het overkoepelende model voort te zetten, maar het huidige wachtlijstmodel is niet bouwrijp. + +## 6. Behandelplan + +Het behandelplan kreeg tijdens de sessie een fundamenteel andere opzet dan in het eerdere modelvoorstel. + +### 6.1 Eén logisch plan + +Colins praktijkervaring is dat deelplannen snel leiden tot wildgroei, afdelingsspecifieke documenten en verlies van gezamenlijk overzicht. + +Daarom: + +- bestaat per zorgepisode één logisch behandelplan; +- dragen alle betrokken disciplines aan hetzelfde plan bij; +- ontstaan geen afzonderlijke afdelings- of disciplineplannen; +- worden verschillende behoeften opgelost met scopes, filters en weergaven; +- blijft specialistische documentatie koppelbaar zonder concurrerend intern plan. + +### 6.2 Domeinmodel, geen formulier + +Het behandelplan wordt geen plat formulier. De stabiele kern bestaat uit: + +- aandachtgebieden; +- doelen; +- interventies en afspraken; +- betrokkenen en verantwoordelijkheden; +- evaluaties; +- cliëntperspectief en verschillen van inzicht. + +Een aandachtgebied kan meerdere perspectieven hebben: + +- klacht of diagnose; +- leefgebied; +- kracht of beschermende factor; +- risico; +- herstel; +- preventie. + +Dit voorkomt dat één instellingsvisie als rigide formulier op alle afdelingen wordt geprojecteerd. + +### 6.3 Preventie + +Colin benoemde preventie als een onderscheidend thema voor een EPD, juist omdat financieringsmodellen slecht aansluiten op onderwerpen als eenzaamheid, systeem, omgeving en maatschappij. + +Preventie wordt daarom een volwaardig perspectief binnen het behandelplan, bijvoorbeeld voor: + +- eenzaamheid en sociale verbinding; +- beschermende factoren; +- netwerkversterking; +- vroegsignalering; +- terugvalpreventie; +- bewezen helpende strategieën. + +Dataminimalisatie blijft een randvoorwaarde: het EPD wordt geen onbeperkt sociaal dossier. + +### 6.4 Levend plan en snapshots + +Het behandelplan houdt één identiteit tijdens de episode. + +- Het werkplan blijft dynamisch. +- Iedere wijziging krijgt auteurschap en audit. +- Niet iedere wijziging maakt een nieuw plan. +- Formele vaststelling, evaluatie en cliëntbespreking leveren onveranderlijke snapshots op. +- Eerdere snapshots blijven reproduceerbaar. + +Dit vervangt het eerdere voorstel waarin iedere planversie een volledig nieuw BEHANDELPLAN-record was. + +### 6.5 Procespositie + +De hoofdroute is: + +```text +intakebevindingen +→ conceptplan +→ MDO +→ bespreking met cliënt +→ vastgestelde snapshot +→ uitvoering en periodiek MDO +→ formele evaluatie +→ bijgesteld plan en nieuwe snapshot +→ afsluiting +``` + +Een halfjaarlijkse evaluatie wordt een configureerbare protocolregel. TIP bewaakt de termijn; het ECD bewaart het feit en de uitkomst. + +### 6.6 Cliëntakkoord + +Planakkoord en behandeltoestemming zijn afzonderlijke concepten. + +Per plansnapshot kan worden vastgelegd: + +- akkoord; +- gedeeltelijk akkoord; +- niet akkoord; +- akkoord niet verkregen; +- toelichting en bezwaren; +- vertegenwoordiging indien van toepassing. + +Geen akkoord met het behandelplan blokkeert niet automatisch iedere zorg. Behandeling vereist echter wel toestemming of een expliciete geldige juridische grondslag. Een institutioneel besluit is geen generieke bypass. + +## 7. MDO, evaluatie en bevoegdheid + +Colin verduidelijkte dat MDO en evaluatie dynamische processen zijn. + +Een MDO omvat: + +- casusinbreng; +- vraagstelling; +- triage en agendering; +- voorbereiding; +- sessie en panel; +- feitelijke deelnemers; +- gedeelde analyse; +- advies, besluit of nader onderzoek; +- actiepunten; +- planwijzigingsvoorstellen. + +Een formele evaluatie is een vergelijkbaar cliëntgericht proces en kan een MDO-bespreking bevatten, maar is niet hetzelfde als een MDO. + +Het MDO is niet altijd besluitvormend. Bevoegdheid wordt daarom gekoppeld aan: + +- het besluittype; +- de actuele teamrol; +- professionele kwalificaties; +- eventuele consultatie- of quorumeisen. + +Professie, teamrol en bevoegdheid blijven afzonderlijke begrippen. Een psychiater of psycholoog is niet uitsluitend door de professie automatisch regiebehandelaar. + +## 8. Longitudinale cliëntinformatie en rapportage + +Een voorgeschiedenis maakte duidelijk dat sommige informatie episode-overstijgend relevant is. + +Vastgelegd is: + +- het behandelplan blijft episodegebonden; +- geselecteerde informatie kan longitudinaal worden; +- ieder longitudinaal gegeven heeft bron, bronepisode, geldigheid, actualiteit, reviewdatum en eigen autorisatie; +- er komt geen generieke `CLIENT_GEGEVEN`-vergaarbak; +- concrete klinische concepten krijgen later eigen definities. + +Voor rapportage geldt: + +- iedere klinische rapportage heeft één primaire zorgepisode; +- verwijzingen naar eerdere episodes of longitudinale informatie zijn mogelijk; +- een verwijzing verleent geen toegang; +- pre-acceptatieregistraties horen bij instroom/screening en vragen een eigen bewaarbeleid; +- een MDO-verslag vervangt de MDO-workflow niet. + +## 9. Configureerbare behandelvisie + +Visie en taal worden configureerbaar zonder het klinische schema per instelling of afdeling te laten variëren. + +De configuratielaag bevat: + +- versiegebonden behandelvisieprofielen; +- terminologie; +- perspectieven en waardelijsten; +- aanbevolen en verplichte onderdelen; +- evaluatieprotocollen; +- instellings- en afdelingsscope; +- geldigheid en publicatiestatus. + +De klinische kern bewaart stabiele concepten. Plansnapshots verwijzen naar de gebruikte profielversie. Afdelingen mogen accenten toevoegen, maar maken geen eigen behandelplanmodel. + +## 10. Modellering, taal en terminologieonderzoek + +### 10.1 Methode + +Besloten is FCO-IM/NIAM-principes te behouden voor de conceptuele laag: + +- elementaire feitzinnen; +- natuurlijke verbalisatie; +- uniciteit en optionaliteit; +- temporele geldigheid; +- expliciete constraints. + +Dit wordt aangevuld met: + +- procesmodellen; +- statecharts; +- eventcatalogi; +- beslissingstabellen; +- logisch relationeel model; +- traceerbaarheid van besluit naar constraint en test. + +Volledig formele ORM2-diagrammen zijn niet het doel; de bruikbare fact-oriented discipline staat centraal. + +### 10.2 Engelstalig technisch model + +Het uiteindelijke technische datamodel wordt Engelstalig: + +- entiteiten; +- attributen; +- relaties; +- events; +- API-velden; +- constraints. + +Nederlandse UI-labels blijven configureerbaar. Officiële Nederlandse zorg- en wettelijke begrippen blijven met brondefinitie beschikbaar in een tweetalige begrippenlijst. + +### 10.3 Eerste begrippenlijst + +`../begrippenlijst-kernmodel.md` is opgesteld als versie 0.1. De eerste werktermen voor instroom waren: + +- `Inbound Care Signal`; +- `Access Assessment Case`; +- `Presenting Care Need`; +- `Care Acceptance Decision`; +- `Clinical Care Episode`. + +Colin gaf terecht aan dat de eerste twee termen onvoldoende duidend waren. + +### 10.4 Onderzoek Amerikaanse en Engelstalige EHR’s + +Onderzocht zijn: + +- Epic; +- Oracle Health; +- athenahealth; +- Netsmart; +- NextGen; +- Qualifacts; +- HL7 FHIR; +- ONC/360X; +- NHS-dataterminologie. + +Belangrijkste bevindingen: + +- generieke en behavioral-health EHR’s gebruiken vrijwel overal `Referral` als beheerd lifecycle-object; +- `Referral Order` is vaak een provider-authored verzoek en te smal voor generieke instroom; +- `ServiceRequest`, `Task`, `EpisodeOfCare` en `Encounter` hebben verschillende betekenissen; +- `signal` is geen herkenbare EHR-term voor een ontvangen aanmelding; +- `access assessment case` is begrijpelijk maar niet idiomatisch; +- behavioral-healthsystemen spreken over incoming referrals, referral packets, referral intake en pre-admit; +- de meeste GGZ-zorg is ambulant, waardoor `admission` en `pre-admission` ongeschikt zijn als generieke kernbegrippen. + +Het onderzoeksrapport staat in `../onderzoek/onderzoek-engelstalige-epd-terminologie.md`. + +### 10.5 Huidige voorkeursrichting + +De huidige, nog niet volledig in de begrippenlijst verwerkte voorkeursrichting is: + +```text +referral_submission — iedere afzonderlijke binnenkomst +referral — het beheerde aanmeldingstraject +acceptance_decision — formele acceptatie +clinical_care_episode — geaccepteerde zorgperiode +clinical_intake — klinische intake +``` + +Een mogelijke `referral_request` blijft open. Eerst moet worden vastgesteld of de Nederlandse VERWIJZING een zelfstandig inhoudelijk verzoek is naast de ontvangen submission en de beheerde referral. + +De zorgsetting wordt geen onderdeel van de episodenaam, maar een afzonderlijk tijdgebonden kenmerk, bijvoorbeeld ambulant, outreach, dagbehandeling, residentieel of klinisch. + +## 11. Vastgelegde artefacten + +Tijdens deze sessie zijn toegevoegd: + +- `../besluiten/besluitenlog-datamodel-2026-07-18.md`; +- `../begrippenlijst-kernmodel.md`; +- `../onderzoek/onderzoek-engelstalige-epd-terminologie.md`; +- `../entiteitenkaarten/ehr-referral-terminology.html`; +- canvas `EHR-referral-terminology.canvas.tsx`. + +De volgende documenten kregen een waarschuwing dat ze geheel of gedeeltelijk zijn achterhaald: + +- `../deelmodellen/datamodel-discovery.md`; +- `../deelmodellen/model-aanmelding.md`; +- `../deelmodellen/model-screening.md`; +- `../deelmodellen/model-intake.md`; +- `../deelmodellen/model-wachtlijst.md`; +- `../deelmodellen/model-behandelplan.md`; +- `../deelmodellen/model-rapportage.md`. + +De HTML-entiteitenkaart is nog niet bijgewerkt. Die wordt pas opnieuw gegenereerd nadat de Markdown-deelmodellen zijn herzien. + +## 12. Open punten + +### Instroom + +- Is een inhoudelijk Referral Request een zelfstandig object? +- Valt de Nederlandse VERWIJZING volledig samen met Referral Request? +- Kan één request via meerdere submissions binnenkomen? +- Kan één submission meerdere requests bevatten? +- Welke intakehandelingen mogen vóór formele acceptatie plaatsvinden? +- Wat zijn de statusmachine en bevoegdheden van het acceptatiebesluit? + +### Behandelplan en organisatie + +- Welke wijzigingen vereisen een formele snapshot? +- Hoe wordt cliëntreactie bij gedeeltelijk akkoord precies gescopeerd? +- Welke longitudinale informatietypen worden als eerste gemodelleerd? +- Hoe werkt profielmigratie tijdens een lopende episode? +- Welke bevoegdheidsmatrix geldt per besluittype? + +### Onderzoek + +- GGZ-wachtlijst en actuele NZa-definities; +- bewaarbeleid vóór acceptatie en bij afwijzing; +- juridische betekenis van acceptatie; +- autorisatie op historische episodeverwijzingen; +- externe terminologie voor longitudinale en behandelplanconcepten. + +## 13. Afgesproken volgende stap + +De volgende stap is een eerste FCO-IM-feitenronde voor referral/instroom. + +Doel: + +1. de voorkeursbegrippen verwerken; +2. elementaire feiten voor request, submission, referral en acceptatie formuleren; +3. uniciteit, optionaliteit, tijd en bevoegdheid per feit bepalen; +4. scenario’s testen met huisartsverwijzing, zelfaanmelding, aanvullende informatie en dubbele instroom; +5. op basis daarvan besluiten of `Referral Request` een eigen identiteit nodig heeft; +6. pas daarna entiteiten, cardinaliteiten en een logisch ER-model afleiden. diff --git a/docs/datamodel/sessielogs/sessielog-2026-07-19.md b/docs/datamodel/sessielogs/sessielog-2026-07-19.md new file mode 100644 index 0000000..63ab660 --- /dev/null +++ b/docs/datamodel/sessielogs/sessielog-2026-07-19.md @@ -0,0 +1,306 @@ +# Sessielog datamodel — 19 juli 2026 + +**Status:** chronologisch werkverslag +**Doel:** context, redenering, correcties en voortgang van de sessie bewaren +**Autoriteit:** dit sessielog is niet normatief; bevestigde besluiten moeten nog worden verwerkt in `../besluiten/besluitenlog-datamodel-2026-07-18.md` +**Vervolg:** feitenmodel instroom synchroniseren en de uitkomsten van het behandeladvies bepalen + +## 1. Aanleiding + +De sessie vervolgde de op 18 juli afgesproken FCO-IM-feitenronde voor +referral en instroom. Als werkdocument is `../feitenmodellen/feitenmodel-instroom.md` +opgesteld. Het doel is eerst de elementaire domeinfeiten te bevestigen en pas +daarna entiteiten, cardinaliteiten, statusmachines en SQL af te leiden. + +De ronde richtte zich op: + +- het inhoudelijke zorgverzoek; +- afzonderlijke binnenkomsten; +- het institutionele aanmeldingstraject; +- de formele Nederlandse verwijzing; +- screening, acceptatie en capaciteit; +- de overgang naar zorginhoudelijke intake. + +## 2. Referral Request, Submission en Case + +### 2.1 Meerdere samenhangende zorgvragen + +Bevestigd is dat één `Referral Request` meerdere samenhangende geuite +zorgvragen mag bevatten. Splitsing in afzonderlijke requests is pas nodig +wanneer de zorgvragen afzonderlijk moeten worden beoordeeld. + +Daarmee is een request niet beperkt tot één klacht of één tekstveld. Het +representeert één inhoudelijk verzoek om zorg of beoordeling met een +samenhangende scope. + +### 2.2 Eén submission kan meerdere requests bevatten + +Eén `Referral Submission` kan meerdere inhoudelijke requests bevatten of +representeren, bijvoorbeeld wanneer één ontvangen brief twee onafhankelijk +te beoordelen verzoeken bevat. + +De relaties tussen submission en requests worden expliciet vastgelegd. De +oorspronkelijke submission wordt niet gekopieerd of administratief gesplitst, +omdat bron, ontvangstmoment en documentcontext behouden moeten blijven. + +### 2.3 Eén request kan uitzonderlijk in meerdere cases lopen + +Eén request kan bij uitzondering in meerdere `Referral Cases` worden +behandeld wanneer verschillende proces- of wettelijke kaders dat vereisen. +Iedere parallelle behandeling vereist: + +- een expliciete reden; +- tijdgebonden historie; +- behoud van de oorspronkelijke request- en case-identiteiten; +- volledige audit. + +Dit is een uitzondering en geen standaardroute. + +## 3. Formele verwijzing is een zelfstandig object + +De formele Nederlandse **VERWIJZING** valt niet samen met het generieke +zorgverzoek. + +Bevestigd is: + +- `Referral Request` representeert het inhoudelijke verzoek om zorg of + beoordeling; +- `Professional Referral` representeert de formele verwijzing met onder meer + verwijzer, verwijsdatum, geldigheid en verwijsspecifieke gegevens; +- de formele verwijzing heeft een eigen identiteit; +- de formele verwijzing wordt gekoppeld aan het request waarop zij betrekking + heeft; +- een zelfaanmelding kan een request vormen zonder formele verwijzing. + +Deze scheiding sluit aan op de GGZ-praktijk bij spoed en crisis. Zorg kan +soms al worden geleverd voordat de formele verwijzing is ontvangen. Een +later ontvangen verwijzing vult de formele en financiële onderbouwing aan, +maar herschrijft de identiteit of herkomst van het oorspronkelijke request +niet. + +De vraag hoe correcties en vervangende verwijzingen logisch worden +gemodelleerd is geparkeerd. Append-only audit voorkomt ondertussen +informatieverlies. De keuze tussen meerdere verwijzingsidentiteiten en +versies van één verwijzing hoort bij het logische model. + +## 4. Screening in de GGZ-praktijk + +Colin beschreef de screeningsfase als de fase waarin de instelling beoordeelt: + +- of er een match is met de zorgvraag; +- of de benodigde inhoudelijke expertise aanwezig is; +- of er plek beschikbaar is; +- of er voldoende capaciteit is. + +Tijdens screening is meestal beperkt contact met de cliënt, verwijzer of +andere bron. Dit contact is doorgaans niet gefinancierd, maar kan dat bij +uitzondering wel zijn. + +Na een positieve screening volgt de zorginhoudelijke intake. Contacten binnen +de intake zijn meestal wel gefinancierd. Uit de intake volgt vervolgens een +behandeladvies. + +De financiering van een contact mag daarom niet uitsluitend uit de procesfase +worden afgeleid. Per concreet contact moet kunnen worden vastgelegd of en op +welke grond het gefinancierd of declarabel is. + +## 5. Screeningsbesluit is het acceptatiebesluit + +Bevestigd is dat het screeningsbesluit geen vrijblijvend advies is waarna nog +een zelfstandig acceptatiebesluit volgt. Het screeningsbesluit **is** het +acceptatiebesluit. + +Daarmee wordt de eerder veronderstelde scheiding tussen +`Screening Recommendation` en `Care Acceptance Decision` voor deze flow +herzien. De onderliggende beoordelingen blijven wel afzonderlijke feiten: + +1. inhoudelijke match; +2. beschikbare plek; +3. capaciteit; +4. formeel besluit; +5. vervolgroute; +6. onderbouwing. + +Het besluit en de onderliggende beoordelingen mogen niet in één statusveld +worden samengevoegd. + +## 6. Capaciteit bepaalt acceptatie niet automatisch + +Besproken is dat een inhoudelijke match zonder beschikbare capaciteit in de +praktijk tot twee geldige routes kan leiden. + +### Route A — accepteren en wachten + +- inhoudelijke match: ja; +- capaciteit: nee; +- acceptatiebesluit: geaccepteerd; +- vervolgroute: intakewachtlijst; +- gevolg: er ontstaat een zorgepisode. + +### Route B — afwijzen wegens capaciteit + +- inhoudelijke match: ja; +- capaciteit: nee; +- acceptatiebesluit: afgewezen; +- onderbouwing: geen capaciteit; +- eventuele vervolgroute: doorverwijzen; +- gevolg: er ontstaat geen zorgepisode. + +Capaciteit is dus invoer voor het besluit, maar bepaalt de besluituitkomst +niet automatisch. Het acceptatiebesluit bepaalt of een zorgepisode ontstaat. + +Deze scheiding ondersteunt ook andere combinaties: + +- inhoudelijke match en capaciteit beschikbaar → geaccepteerd → intake + plannen; +- geen inhoudelijke match → afgewezen met inhoudelijke onderbouwing; +- onvoldoende informatie → nog geen definitief besluit en aanvullende + informatie opvragen. + +## 7. Besluituitkomst en vervolgroute + +De volgende voorlopige scheiding is ontstaan. + +### Besluituitkomst + +- geaccepteerd; +- afgewezen. + +Mogelijk is `meer_informatie_nodig` geen besluituitkomst maar een open +processtatus, omdat er dan nog geen definitief acceptatiebesluit bestaat. + +### Vervolgroute + +- intake direct plannen; +- op intakewachtlijst plaatsen; +- bij spoed direct doorzetten; +- doorverwijzen; +- case afsluiten. + +`Planning` en `wachtlijst` zijn daarmee geen inhoudelijke besluituitkomsten, +maar operationele vervolgroutes na of naast het besluit. + +### Onderbouwing + +Bij afwijzing is een concrete onderbouwing nodig, bijvoorbeeld: + +- onvoldoende inhoudelijke match; +- benodigde expertise ontbreekt; +- geen capaciteit; +- zorgvraag valt buiten het aanbod of de toelatingscriteria. + +Een onderbouwing als “geen acceptatie” is niet informatief, omdat die alleen +de besluituitkomst herhaalt. + +## 8. Gevolg voor episodevorming + +Het huidige inhoudelijke besluit blijft: de zorgepisode ontstaat bij +acceptatie. + +Nu het screeningsbesluit het acceptatiebesluit blijkt te zijn, kan de episode +al vóór de eerste zorginhoudelijke intake ontstaan. Ook bij acceptatie gevolgd +door een intakewachtlijst bestaat dan al een zorgepisode. + +Dit vervangt het oudere voorstel in `../deelmodellen/model-aanmelding.md` waarin de episode +pas ontstond bij uitkomst “intake” of bij de feitelijke start van de intake. +Het feitenmodel en de oudere deelmodellen zijn op dit punt nog niet volledig +gesynchroniseerd. + +## 9. Huidige conceptuele flow + +```text +request en één of meer submissions +→ referral case +→ screening van zorgvraagmatch, expertise, plek en capaciteit +→ screeningsbesluit = acceptatiebesluit + ├─ geaccepteerd + │ ├─ intake direct plannen + │ ├─ intakewachtlijst + │ └─ spoedroute + │ + └─ afgewezen + ├─ inhoudelijke onderbouwing + ├─ capaciteitsonderbouwing + └─ eventueel doorverwijzen + +geaccepteerd +→ zorgepisode +→ zorginhoudelijke intake +→ behandeladvies +``` + +De formele verwijzing kan vóór of na het acceptatiebesluit worden ontvangen +en blijft een zelfstandig object naast het request. + +## 10. Gewijzigde en toegevoegde artefacten + +Tijdens deze feitenronde is toegevoegd: + +- `../feitenmodellen/feitenmodel-instroom.md`. + +Dat document bevat: + +- werkdefinities; +- elementaire feitzinnen; +- voorlopige uniqueness- en optionaliteitsregels; +- scenariotoetsen voor huisartsverwijzing, zelfaanmelding, spoed/crisis, + aanvullende informatie en dubbele instroom; +- een voorlopige conclusie over de identiteit van Referral Request. + +Het document bevat nog formuleringen die met de besluiten uit deze sessie +moeten worden gesynchroniseerd, met name: + +- screeningsadvies en acceptatie zijn nog deels als afzonderlijke besluiten + beschreven; +- de besluituitkomsten en vervolgroutes moeten worden gescheiden; +- episodevorming bij acceptatie vóór intake moet expliciet worden verwerkt. + +## 11. Open punten + +### Instroom en acceptatie + +- Welke open processtatussen gelden vóór een definitief screeningsbesluit? +- Welke gegevens en bevoegdheid zijn minimaal vereist om het + screenings-/acceptatiebesluit vast te leggen? +- Kan een geaccepteerde case later vóór de intake alsnog worden ingetrokken, + en zo ja, wat gebeurt dan met de zorgepisode? +- Hoe worden intakewachtlijst en regulatoire aanmeldwachttijd precies + gekoppeld nu de episode vóór intake kan ontstaan? + +### Behandeladvies + +- Welke uitkomsten kan het behandeladvies na de intake hebben? +- Is het behandeladvies uitsluitend adviserend, of bevat het ook een bevoegd + besluit over de start of vorm van behandeling? +- Hoe verhoudt het behandeladvies zich tot behandelplan, doorverwijzing en + afsluiting van de episode? + +### Logische uitwerking + +- Hoe worden gecorrigeerde of vervangende formele verwijzingen + gehistoriseerd? +- Welke cardinaliteiten volgen definitief tussen request, submission, case, + verwijzing en acceptatiebesluit? +- Welke statusmachine hoort bij Referral Case wanneer aanvullende informatie, + heroverweging of intrekking mogelijk is? + +## 12. Afgesproken volgende stap + +De eerstvolgende stap is het synchroniseren van +`../feitenmodellen/feitenmodel-instroom.md` met de besluiten uit deze sessie: + +1. screeningsbesluit en acceptatiebesluit samenvoegen; +2. beoordelingen, besluit, vervolgroute en onderbouwing als afzonderlijke + feiten formuleren; +3. beide routes bij ontbrekende capaciteit opnemen; +4. episodevorming vóór intake corrigeren; +5. de mogelijke uitkomsten van het behandeladvies met Colin vaststellen. + +Daarna volgen: + +1. definitieve uniqueness- en optionaliteitsconstraints; +2. de statusmachines van Referral Case en het acceptatiebesluit; +3. afleiding van entiteiten en cardinaliteiten; +4. verwerking in het besluitenlog; +5. synchronisatie van `../begrippenlijst-kernmodel.md` en + `../deelmodellen/model-aanmelding.md`. diff --git a/docs/sessions/2026-07-17-sessielog.md b/docs/sessions/2026-07-17-sessielog.md index a0e2c95..8d63cbe 100644 --- a/docs/sessions/2026-07-17-sessielog.md +++ b/docs/sessions/2026-07-17-sessielog.md @@ -8,8 +8,8 @@ ## 1. Wat er ligt -- **`docs/datamodel/datamodel-discovery.md`** — feitzinnen, besluiten en open vragen per flow (§5.1 t/m §5.5), FCO-IM-werkwijze -- **`docs/datamodel/entiteitenkaart-instroom.html`** — samenhang-diagram + drie ER-diagrammen + waardelijsten, gepubliceerd als artifact ter review +- **`docs/datamodel/deelmodellen/datamodel-discovery.md`** — feitzinnen, besluiten en open vragen per flow (§5.1 t/m §5.5), FCO-IM-werkwijze +- **`docs/datamodel/entiteitenkaarten/entiteitenkaart-instroom.html`** — samenhang-diagram + drie ER-diagrammen + waardelijsten, gepubliceerd als artifact ter review De scope van ronde 1 is deze sessie verbreed: van alleen instroom naar **aanmelding t/m behandelplan** (incl. wachtlijstbeheer, diagnose, behandelplan-kern). Agenda en rapportage & overdracht blijven latere rondes. @@ -59,6 +59,6 @@ De scope van ronde 1 is deze sessie verbreed: van alleen instroom naar **aanmeld ## Referenties -- Discovery: `docs/datamodel/datamodel-discovery.md` -- Entiteitenkaart: `docs/datamodel/entiteitenkaart-instroom.html` (artifact: claude.ai/code/artifact/e2340972-f677-4f0d-af95-b40e8dcac241) +- Discovery: `docs/datamodel/deelmodellen/datamodel-discovery.md` +- Entiteitenkaart: `docs/datamodel/entiteitenkaarten/entiteitenkaart-instroom.html` (artifact: claude.ai/code/artifact/e2340972-f677-4f0d-af95-b40e8dcac241) - Vorige sessie: `docs/sessions/2026-07-14-sessielog.md` -- 2.39.5 From dc15bf60d607488a934d9975ff49ee83886796fe Mon Sep 17 00:00:00 2001 From: colinislit Date: Sun, 19 Jul 2026 11:37:26 +0200 Subject: [PATCH 12/19] docs(datamodel): instroom domeinreview afronden (vraag 3, 4, 5) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Beantwoordt de resterende open vragen uit feitenmodel-instroom.md §7: aanvullende_informatie_nodig wordt een gebeurtenisfeit i.p.v. besluituitkomst of statusfase, heroverweging na afwijzing krijgt een expliciete "vervangt"-relatie tussen acceptatiebesluiten, en intrekking vóór start intake krijgt twee routes (cliënt-intrekking zonder bevoegdheidseis, institutionele correctie met dezelfde bevoegdheid als het origineel) waarbij de al ontstane zorgepisode altijd wordt afgesloten, nooit verwijderd. Referral Case krijgt daarmee een tijdlijn-gebaseerde stand i.p.v. een vaste lineaire statusmachine. Alleen vraag 2 (behandeladvies-uitkomsten) blijft open als apart onderzoek. --- .../feitenmodellen/feitenmodel-instroom.md | 168 +++++++++++++++--- 1 file changed, 148 insertions(+), 20 deletions(-) diff --git a/docs/datamodel/feitenmodellen/feitenmodel-instroom.md b/docs/datamodel/feitenmodellen/feitenmodel-instroom.md index 2b8eab6..08096a9 100644 --- a/docs/datamodel/feitenmodellen/feitenmodel-instroom.md +++ b/docs/datamodel/feitenmodellen/feitenmodel-instroom.md @@ -365,6 +365,87 @@ is een concrete onderbouwing verplicht; “geen capaciteit” of “geen acceptatie” zonder verdere duiding is onvoldoende, omdat dat laatste alleen de uitkomst herhaalt. +**Route 3 — heroverweging na afwijzing** + +A24. *Beoordeling van Referral Case C-405 constateert op 17 juli 2026 geen +inhoudelijke match met de geuite zorgvraag.* + +A25. *Acceptatiebesluit A-731 betreft Referral Case C-405.* + +A26. *Acceptatiebesluit A-731 heeft besluituitkomst “afgewezen”, motivering +“onvoldoende inhoudelijke match”.* + +A27. *Referral Case C-405 is na acceptatiebesluit A-731 afgesloten met +uitkomst “afgewezen”.* + +A28. *Bij Referral Case C-405 is op 24 juli 2026 een informatieverzoek +vastgelegd door medewerker K. Jansen, met gevraagde informatie “aanvullende +diagnostische onderbouwing”.* + +A29. *Submission S-210 is op 26 juli 2026 ontvangen als reactie op het +informatieverzoek van 24 juli 2026 en representeert het zorgverzoek van +Referral Case C-405.* + +A30. *Beoordeling van de heroverweging van Referral Case C-405 bevestigt op +27 juli 2026 alsnog een inhoudelijke match, op basis van submission S-210.* + +A31. *Acceptatiebesluit A-751 betreft Referral Case C-405, heeft +besluituitkomst “geaccepteerd” en vervangt acceptatiebesluit A-731.* + +A32. *De reden voor vervanging van acceptatiebesluit A-731 door A-751 is +“aanvullende diagnostiek toont alsnog inhoudelijke match aan”.* + +A33. *Zorgepisode E-905 is ontstaan uit acceptatiebesluit A-751.* + +Acceptatiebesluit A-731 blijft ongewijzigd bewaard; A-751 draagt de +expliciete vervangt-relatie en de reden. Wie het geldige besluit van +Referral Case C-405 wil weten, volgt de vervangt-keten naar het laatste, +niet-vervangen besluit — dat hoeft niet impliciet uit datums te worden +afgeleid (domeinreview 19 juli 2026, vraag 3). + +**Route 4 — cliënt trekt in vóór start intake** + +A34. *Referral Case C-406 is op 10 augustus 2026 afgesloten met +acceptatiebesluit A-760, uitkomst “geaccepteerd”, vervolgroute +“intakewachtlijst”.* + +A35. *Zorgepisode E-910 is ontstaan uit acceptatiebesluit A-760.* + +A36. *Referral Case C-406 is op 15 augustus 2026, vóór start van de intake, +door de cliënt ingetrokken; vastgelegd door medewerker K. Jansen.* + +A37. *Zorgepisode E-910 is op 15 augustus 2026 afgesloten met reden +“ingetrokken door cliënt vóór start intake”.* + +Cliënt-intrekking is geen Care Acceptance Decision en vereist geen +beslisbevoegdheid — het is een registratie van de cliëntkeuze, niet een +inhoudelijke herbeoordeling. Een cliënt kan een case op elk moment intrekken, +niet uitsluitend ná een positief besluit. + +**Route 5 — institutionele correctie vóór start intake** + +A38. *Referral Case C-407 is op 12 augustus 2026 afgesloten met +acceptatiebesluit A-762, uitkomst “geaccepteerd”, vervolgroute +“intakewachtlijst”.* + +A39. *Zorgepisode E-911 is ontstaan uit acceptatiebesluit A-762.* + +A40. *Acceptatiebesluit A-763 betreft Referral Case C-407, heeft +besluituitkomst “afgewezen” en vervangt acceptatiebesluit A-762, met reden +“capaciteitsinschatting bleek bij nader inzien onjuist”.* + +A41. *Medewerker M. de Boer handelde bij acceptatiebesluit A-763 op grond van +dezelfde beslisbevoegdheid als bij een regulier acceptatiebesluit.* + +A42. *Zorgepisode E-911 is op 16 augustus 2026 afgesloten met reden +“acceptatiebesluit herzien vóór start intake”.* + +Een institutionele correctie is wél een Care Acceptance Decision — hetzelfde +vervangt-mechanisme als Route 3, nu in omgekeerde richting — en vereist +dezelfde bevoegdheid als het oorspronkelijke besluit. In beide routes 4 en 5 +verdwijnt de al ontstane zorgepisode niet: zij wordt afgesloten met een +passende reden, net als iedere andere episode-afsluiting (B3). + **Beantwoord in domeinreview (19 juli 2026):** - Besluituitkomst is beperkt tot `geaccepteerd` / `afgewezen`. `Doorverwijzen` @@ -446,8 +527,18 @@ cardinaliteiten. - Een case kan door meerdere submissions en requests worden gevoed. - Parallelle cases zijn toegestaan met een expliciete reden. - Logische consolidatie verwijdert geen case, request of submission. -- Een afgesloten case kan bij herbeoordeling een nieuwe besluitronde krijgen; - de precieze statusmachine staat nog open. +- Een case heeft geen vaste, eenrichtings-statusmachine. De actuele stand + wordt afgeleid uit een tijdlijn van gebeurtenissen (toewijzingen, + informatieverzoeken, acceptatiebesluiten), niet uit één overschrijfbaar + statusveld (domeinreview 19 juli 2026 — zie ook B7 bij wachtlijst en de + non-lineaire aanmelding-status uit discovery §5.1 #5). +- Een informatieverzoek is een gebeurtenis: wie heeft wanneer welke + aanvullende informatie gevraagd. Deze gebeurtenis kan zich op elk moment + voordoen, ook ná een eerder acceptatiebesluit tijdens een heroverweging — + niet uitsluitend vóór het eerste besluit. +- Een afgesloten case kan bij heroverweging een nieuw acceptatiebesluit + krijgen; hoe het eerdere besluit dan gehistoriseerd wordt (vervangen versus + aanvullend) is nog niet vastgesteld (zie §7 vraag 3). ### Care Acceptance Decision @@ -470,6 +561,23 @@ cardinaliteiten. capaciteitstekort geldige uitkomsten. - Alleen een besluit met uitkomst `geaccepteerd` kan een zorgepisode laten ontstaan, ongeacht de gekozen vervolgroute. +- Een besluit kan optioneel precies één eerder besluit van dezelfde case + vervangen, met een verplichte reden voor vervanging (heroverweging, + domeinreview 19 juli 2026, vraag 3). Het vervangen besluit blijft + ongewijzigd bewaard; vervanging is een expliciete relatie, geen mutatie. +- Het geldige besluit van een case is het laatste besluit in de + vervangt-keten; eerdere besluiten blijven raadpleegbaar maar zijn niet meer + bepalend voor de actuele stand. +- Cliënt-intrekking van een Referral Case is geen Care Acceptance Decision: + het vereist geen beslisbevoegdheid en kan op elk moment plaatsvinden, + inclusief ná een positief besluit (domeinreview 19 juli 2026, vraag 4). +- Een institutionele correctie van een eerder positief besluit ná ontstaan + van de zorgepisode volgt hetzelfde vervangt-mechanisme als heroverweging + (Route 3) en vereist dezelfde beslisbevoegdheid als het oorspronkelijke + besluit. +- Een reeds ontstane zorgepisode wordt bij intrekking of correctie nooit + verwijderd of ongedaan gemaakt; zij wordt afgesloten met een passende + reden, net als elke andere episode-afsluiting. - Een zorgepisode verwijst naar het acceptatiebesluit waaruit zij ontstond. - Een besluit bewijst geen behandeltoestemming of verantwoordelijkheid. - Het behandeladvies na de intake is een afzonderlijk klinisch feit en geen @@ -591,28 +699,48 @@ uitgewerkt. De append-only audit voorkomt ondertussen informatieverlies. **Beantwoord (domeinreview 19 juli 2026):** -1. Screeningsadvies en acceptatie zijn in de praktijk hetzelfde vastgelegde - besluit. Dit is verwerkt in §2–§5 hierboven: er is geen apart, voorafgaand - screeningsadvies meer, en het besluit draagt zelf de onderliggende - beoordelingen, de besluituitkomst, de vervolgroute en, bij afwijzing, de - onderbouwing. +- **Vraag 1.** Screeningsadvies en acceptatie zijn in de praktijk hetzelfde + vastgelegde besluit. Dit is verwerkt in §2–§5 hierboven: er is geen apart, + voorafgaand screeningsadvies meer, en het besluit draagt zelf de + onderliggende beoordelingen, de besluituitkomst, de vervolgroute en, bij + afwijzing, de onderbouwing. +- **Vraag 5.** `aanvullende_informatie_nodig` is geen besluituitkomst en geen + fase in een vaste statusmachine. Er bestaat op dat moment nog geen Care + Acceptance Decision — een besluit vereist een bevoegde beslisser die de + zaak daadwerkelijk afrondt, en dat is hier per definitie nog niet gebeurd. + In plaats daarvan is een informatieverzoek een eigen, gedateerd en + toegeschreven gebeurtenisfeit (vergelijkbaar met een screeningsactiviteit), + en wordt de actuele stand van een Referral Case afgeleid uit de tijdlijn + van gebeurtenissen in plaats van uit één overschrijfbaar statusveld. Dit + sluit aan bij eerdere keuzes om de GGZ-praktijk niet in een te lineair + proces te dwingen (B7 wachtlijst, non-lineaire aanmelding-status discovery + §5.1 #5) en is verwerkt in §4 hierboven. +- **Vraag 3.** Bij heroverweging krijgt een afgesloten case een nieuw + acceptatiebesluit. Het eerdere besluit blijft ongewijzigd bewaard en het + nieuwe besluit krijgt een expliciete "vervangt"-relatie met verplichte + reden — geen impliciete "laatste besluit is geldig"-regel op basis van + datum. Dit komt vaak genoeg voor in de praktijk om de extra structuur te + rechtvaardigen. Verwerkt in §3.5 (Route 3) en §4 hierboven. +- **Vraag 4.** Een geaccepteerde case kan vóór start van de intake worden + teruggedraaid, op twee manieren: cliënt-intrekking (geen besluit, geen + bevoegdheidseis, kan op elk moment) of institutionele correctie (een + vervangend Care Acceptance Decision, zelfde bevoegdheid als het + oorspronkelijke besluit). De al ontstane zorgepisode wordt in beide + gevallen afgesloten met een passende reden, nooit verwijderd. Verwerkt in + §3.5 (Route 4 en 5) en §4 hierboven. **Nog open, nader onderzoek nodig:** -2. Welke mogelijke uitkomsten heeft het behandeladvies na de intake, en wie - is bevoegd die vast te stellen? Vastgesteld is alleen dat het - behandeladvies zelf al de vervolgrichting geeft — net als het - acceptatiebesluit is er geen apart, voorafgaand advies. De concrete - vervolgrichtingen en de bijbehorende bevoegdheid zijn geparkeerd (sessielog - 19 juli 2026). -3. Kan een case meerdere opeenvolgende acceptatiebesluiten hebben na - heroverweging, en zo ja, welk besluit is dan geldig? -4. Kan een geaccepteerde case vóór de feitelijke start van de intake alsnog - worden ingetrokken, en wat gebeurt dan met de al ontstane zorgepisode? -5. Is `aanvullende_informatie_nodig` een open processtatus of een derde - besluituitkomst? +- **Vraag 2.** Welke mogelijke uitkomsten heeft het behandeladvies na de + intake, en wie is bevoegd die vast te stellen? Vastgesteld is alleen dat + het behandeladvies zelf al de vervolgrichting geeft — net als het + acceptatiebesluit is er geen apart, voorafgaand advies. De concrete + vervolgrichtingen en de bijbehorende bevoegdheid zijn geparkeerd (sessielog + 19 juli 2026), en raakt dit feitenmodel niet meer — die uitkomst hangt aan + de intake, niet aan de Referral Case. -Na beantwoording van 3–5 volgen pas: +Vraag 2 vergt apart onderzoek (zie besluitenlog §10) en blokkeert de +volgende stappen niet langer. Nu volgen: 1. definitieve uniqueness- en optionaliteitsconstraints (§4 hierboven is een tussenstand, nog niet definitief bevestigd); -- 2.39.5 From f68d63145a9d09293be3c62126cf7f09d145660b Mon Sep 17 00:00:00 2001 From: colinislit Date: Sun, 19 Jul 2026 17:46:57 +0200 Subject: [PATCH 13/19] docs(datamodel): instroom entiteiten/cardinaliteiten + vier reviewrondes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Voegt model-instroom.md toe: de eerste entiteiten-/cardinaliteitenafleiding uit feitenmodel-instroom.md (20 entiteiten, Engelstalig conform B20, vervangt-patroon voor herzieningen, tijdlijn i.p.v. statusmachine voor Referral Case). Vier reviewrondes verwerkt: - technische en GGZ-domeinreview (vertakkende vervangt-keten gefixed, timestamp-precisie, ontbrekende ZPM-velden hersteld); - tweede ronde met datamodel-, GGZ-domein- en UX-expert-agents (lege screening-entiteit vervallen, naamgeving, cardinaliteitsfout, read-model-eis); - GGZ-wetgeving-onderzoek (Wvggz, Wmo/Jeugdwet, 275-dagentoets, 365-dagenregel, crisisdocumentatie) vertaald naar nieuwe entiteiten (municipal_care_assignment, legal_mandate, crisis_encounter_note); - domeinreview eigenaarschap/urgentie met Colin: herhaalbare urgentiebeoordeling (case_urgency_assessment) en een bewust minimale hook voor teambetrokkenheid (episode_team_involvement) — het volledige zorgteam-model blijft een aparte, nog te plannen ronde. feitenmodel-instroom.md: "verzoek zonder bekende persoon" (crisisaanmelding) beantwoord — geen placeholder-persoon, koppeling als eigen gedateerd feit. --- docs/datamodel/deelmodellen/model-instroom.md | 849 ++++++++++++++++++ .../feitenmodellen/feitenmodel-instroom.md | 18 +- 2 files changed, 865 insertions(+), 2 deletions(-) create mode 100644 docs/datamodel/deelmodellen/model-instroom.md diff --git a/docs/datamodel/deelmodellen/model-instroom.md b/docs/datamodel/deelmodellen/model-instroom.md new file mode 100644 index 0000000..611c41d --- /dev/null +++ b/docs/datamodel/deelmodellen/model-instroom.md @@ -0,0 +1,849 @@ +# Datamodelvoorstel — Instroom (Referral Request/Submission/Case, acceptatiebesluit) + +**Status:** voorstel ter review — eerste entiteiten- en cardinaliteitenafleiding, +op 19 juli 2026 drie reviewrondes doorlopen (technisch, GGZ-domein, UX, en +GGZ-wetgeving — zie §9) +**Datum:** 19 juli 2026 +**Scope:** Referral Request, Referral Submission, Referral Case, Professional +Referral, Care Acceptance Decision, de gebeurtenissen rond een case +(screening, informatieverzoek, intrekking, consolidatie), Wmo/Jeugdwet- +toewijzing en Wvggz-mandaat als alternatieve instroomroutes, crisis­ +documentatie vóór identificatie, en het ontstaan/einde van Clinical Care +Episode. Behandeladvies/intake-uitkomst blijft buiten scope (nog open +onderzoek, zie feitenmodel §7 vraag 2). +**Kader:** bouwt rechtstreeks op de bevestigde feitzinnen in +`../feitenmodellen/feitenmodel-instroom.md`. Alle vragen uit diens §7 zijn +beantwoord, behalve vraag 2. Dit is de stap "afleiding van entiteiten en +cardinaliteiten" uit die §7. +**Naamgeving:** entiteiten en attributen zijn Engelstalig, conform besluit +B20. Dit wijkt af van het oudere, Nederlandstalige `model-aanmelding.md` — +die synchronisatie (AANMELDING/VERWIJZING/ZORGEPISODE vervangen door dit +voorstel) is een aparte, latere stap, niet in dit document. +**Autoriteit:** `../besluiten/besluitenlog-datamodel-2026-07-18.md` blijft +leidend. + +--- + +## 1. Ontwerpprincipe: tijdlijn in plaats van statusmachine + +`Referral Case` heeft geen vaste, eenrichtings-statusmachine (feitenmodel §4, +domeinreview 19 juli 2026). In plaats daarvan zijn dit de gebeurtenis- +entiteiten die aan een case kunnen hangen, in willekeurige volgorde en +herhaalbaar: + +- `submission_case_assignment` — een submission wordt aan de case toegewezen; +- `screening_activity` — een screeningscontact of -onderzoek; +- `case_information_request` — een informatieverzoek; +- `care_acceptance_decision` — een (vervangend) acceptatiebesluit; +- `case_withdrawal` — een cliënt-intrekking; +- `case_consolidation` — een leidend-aanwijzing tussen twee cases. + +§7 werkt uit hoe de actuele stand van een case uit deze gebeurtenissen wordt +afgeleid. + +## 2. Entiteiten + +### 2.1 referral_request + +**Doel:** het inhoudelijke verzoek om zorg of beoordeling. Eigen identiteit, +los van de submission die het aanleverde en los van een eventuele formele +verwijzing (feitenmodel §2, §6). + +| Attribuut | Type | Verplicht | +|---|---|---| +| person_id | ref PERSOON | nee *(zie hieronder — crisisaanmelding met onbekende identiteit)* | +| person_identified_at | tijdstip | verplicht zodra `person_id` gevuld is | +| person_identified_by | ref medewerker | verplicht zodra `person_id` gevuld is | +| initiated_at | tijdstip | ja | +| initiator_type | waardelijst `initiator_type` (professional/organisatie/cliënt/vertegenwoordiger) | ja | +| initiator_reference | tekst of ref VERWIJZER | nee | +| requested_scope | tekst (bv. “gespecialiseerde GGZ”) | ja | +| presenting_need_text | tekst (de geuite zorgvraag) | ja | + +**Uniciteit:** één stabiele identiteit; zodra bekend precies één +persoon/cliënt; minstens één initiator; bevat één of meer samenhangende +geuite zorgvragen (geen los attribuut — volgt uit de scope van het request +zelf, splitsing gebeurt door een nieuw request aan te maken). + +**Waarom `person_id` optioneel is:** bij crisisaanmeldingen kan de +identiteit nog onbekend zijn op het moment dat het request al geregistreerd +moet worden. Een placeholder- of "John Doe"-persoon die later wordt +vervangen is bewust geen oplossing — dat vereist achteraf alle gekoppelde +feiten naar de echte persoon te verplaatsen, wat tegen append-only ingaat. +`person_identified_at`/`_by` maken de koppeling zelf een gedateerd, +toegeschreven feit in plaats van een stille invulling (domeinreview 19 juli +2026, was open punt 1). + +### 2.2 referral_submission + +**Doel:** één afzonderlijke binnenkomst, via één kanaal en op één +ontvangstmoment (feitenmodel §2). + +| Attribuut | Type | Verplicht | +|---|---|---| +| received_at | tijdstip | ja | +| channel | waardelijst `submission_channel` (ZorgDomein/e-mail/telefoon/portaal/…) | ja | +| source_reference | tekst of ref VERWIJZER | nee *(“onbekend” toegestaan)* | +| recorded_by | ref medewerker | nee *(verplicht bij telefonische/handmatige registratie)* | +| raw_note | tekst | nee | + +**Uniciteit:** één ontvangstmoment en kanaal; minstens één bron (evt. +onbekend); nul of meer documenten; nooit overschreven door een latere +aanvulling — een aanvulling is een nieuwe submission. + +### 2.3 submission_document + +**Doel:** een document dat bij een submission is ontvangen (S4, S8). + +| Attribuut | Type | Verplicht | +|---|---|---| +| submission_id | ref referral_submission | ja | +| document_type | waardelijst `document_type` (verwijsbrief/diagnostische aanvulling/…) | ja | +| document_reference | ref documentopslag (UUID) | ja | + +**Uniciteit:** geen — meerdere documenten per submission toegestaan. + +### 2.4 submission_request_link + +**Doel:** de expliciete koppeling van een submission aan één of meer +requests (S5, S9, S12) — de submission zelf wordt nooit gekopieerd of +gesplitst (feitenmodel §3.2). + +| Attribuut | Type | Verplicht | +|---|---|---| +| submission_id | ref referral_submission | ja | +| referral_request_id | ref referral_request | ja | +| established_at | tijdstip | ja | + +**Uniciteit:** een submission kan 0..n requests representeren of aanvullen; +elke bekende relatie is een eigen rij. + +**`link_type` vervalt (voorstel, ter evaluatie):** “representeert” versus +“vult_aan” bleek bij toetsing geen zelfstandig feit met eigen gedrag of +regels — geen enkele uniciteits- of optionaliteitsregel behandelt ze +verschillend. Het onderscheid is puur chronologisch: de vroegste +`submission_request_link` voor een request is per definitie degene die het +representeerde, latere zijn per definitie aanvullingen. Dat volgt al uit +`established_at` in combinatie met de al bestaande volgorde van submissions; +een apart, door een mens te zetten waardelijst-veld zou dezelfde informatie +dubbel opslaan. `established_at` wordt daarom verplicht (was optioneel) om +deze afleiding altijd mogelijk te maken. + +### 2.5 submission_duplicate_assessment + +**Doel:** vastleggen dat een submission als duplicaat van een andere is +beoordeeld (S13, S14). + +| Attribuut | Type | Verplicht | +|---|---|---| +| submission_id | ref referral_submission (het duplicaat) | ja | +| duplicate_of_submission_id | ref referral_submission (het origineel) | ja | +| assessed_by | ref medewerker | ja | +| assessed_at | tijdstip | ja | +| reason | tekst | ja | + +**Uniciteit:** geen destructieve werking — beide submissions blijven bestaan. + +### 2.6 referral_case + +**Doel:** het institutionele aanmeldingstraject voor één samenhangend +beoordeelde zorgvraag (feitenmodel §2). + +| Attribuut | Type | Verplicht | +|---|---|---| +| person_id | ref PERSOON | nee *(zelfde reden als bij referral_request — crisisaanmelding)* | +| person_identified_at | tijdstip | verplicht zodra `person_id` gevuld is | +| person_identified_by | ref medewerker | verplicht zodra `person_id` gevuld is | +| opened_at | tijdstip | ja | +| presenting_need_summary | tekst | ja | +| wettelijk_kader | waardelijst `wettelijk_kader` (zvw/wmo/jeugdwet/wvggz) | ja *(overgenomen van AANMELDING in `model-aanmelding.md` §2.10 / discovery §5.0 besluit 4, was in dit voorstel per abuis niet meegenomen; bepaalt welke instroomroute — `professional_referral`, `municipal_care_assignment`, `legal_mandate` — van toepassing is, reviewronde 19 juli 2026)* | +| zpm_verwijstype | waardelijst `zpm_verwijstype` | nee *(afleidbaar uit professional_referral/initiator_type, overschrijfbaar; verplicht richting declaratie bij Zvw — overgenomen van AANMELDING in `model-aanmelding.md` §2.10, was in dit voorstel per abuis niet meegenomen)* | +| huisarts_geinformeerd_op | datum | nee *(instroom zonder verwijzing; nudge harde termijn 60 dagen — overgenomen van AANMELDING in `model-aanmelding.md` §2.10)* | + +**Uniciteit:** één stabiele identiteit; één institutioneel als samenhangend +beoordeelde zorgvraag; gevoed door 1..n submissions (via +`submission_case_assignment`) en 1..n requests (via `request_case_link`); geen +vast statusveld (zie §1 en §7). + +**AGB-code en correspondentietoestemming:** geen nieuwe velden nodig — AGB +van de verwijzer/praktijk loopt via `professional_referral.referrer_id` → +VERWIJZER/PRAKTIJK_INSTELLING (al aanwezig, `model-aanmelding.md` §2.6–§2.7); +correspondentietoestemming (verwijstype 04) valt onder de al bestaande +generieke TOESTEMMING-entiteit (`model-aanmelding.md` §2.14), met +`scope_aanmelding_id` wijzend naar deze case. + +### 2.7 submission_case_assignment + +**Doel:** de historiseerbare toewijzing van een submission aan een case +(C3–C7). + +| Attribuut | Type | Verplicht | +|---|---|---| +| submission_id | ref referral_submission | ja | +| referral_case_id | ref referral_case | ja | +| assigned_at | tijdstip | ja | +| assigned_by | ref medewerker | ja | +| reason | tekst | nee | + +**Uniciteit:** een submission kan aan meerdere cases worden toegewezen +(uitzondering, feitenmodel §3.3); toewijzing is een gebeurtenis, geen +overschrijfbaar veld. + +### 2.8 request_case_link + +**Doel:** welke requests binnen een case worden behandeld, en sinds wanneer +(C8, C9). + +| Attribuut | Type | Verplicht | +|---|---|---| +| referral_request_id | ref referral_request | ja | +| referral_case_id | ref referral_case | ja | +| since | datum | ja | +| reason | tekst | nee *(verplicht zodra een request aan meer dan één case gekoppeld is — uitzondering, feitenmodel §4)* | + +**Uniciteit:** een request hoort normaliter bij precies één case; koppeling +aan meer dan één case is een expliciete uitzondering met reden en +tijdgebonden historie. + +### 2.9 case_consolidation + +**Doel:** niet-destructieve leidend-aanwijzing tussen twee overlappende cases +(C10–C13). + +| Attribuut | Type | Verplicht | +|---|---|---| +| primary_case_id | ref referral_case (leidend) | ja | +| related_case_id | ref referral_case (niet-leidend, blijft bestaan) | ja | +| overlap_assessed_at | tijdstip | nee | +| designated_at | tijdstip | ja | +| designated_by | ref medewerker | ja | +| reason | tekst | ja | + +**Bevoegdheid (voorstel, ter evaluatie):** geen speciale `decision_authority` +vereist — elke medewerker die de case behandelt kan consolideren, net als bij +`submission_case_assignment` en `submission_duplicate_assessment`. Consolidatie +is een administratieve correctie (welke case leidend is voor rapportage), +geen inhoudelijk besluit over zorgtoegang; zij creëert of beëindigt geen +zorgconsequentie zoals `care_acceptance_decision` dat wel doet. Alleen een +mens mag dit vaststellen — AI mag hooguit een match voorstellen (B1) — maar +dat is een ander soort eis dan beslisbevoegdheid. + +**Uniciteit:** beide cases behouden hun eigen identiteit en historie na +aanwijzing; geen merge, geen verwijdering. `related_case_id` is uniek: een +case kan in hoogstens één consolidatie de niet-leidende rol vervullen +(`UNIQUE(related_case_id)`); `primary_case_id` blijft vrij herhaalbaar. Een +case mag zichzelf niet consolideren (`CHECK(primary_case_id <> +related_case_id)`). Transitieve cykels (A leidend over B, B leidend over A) +worden hierdoor niet uitgesloten en blijven een proces-/applicatie­ +verantwoordelijkheid (reviewronde 19 juli 2026, zie §9). + +### 2.10 screening_activity + +**Doel:** een concrete screeningsactiviteit binnen een case (G1–G4). Levert +zelf geen apart advies op (feitenmodel §3.4). *(De aparte, lege +`screening`-groeperingsentiteit uit de eerste versie is vervallen — geen +enkel eigen attribuut, geen onderscheidend kenmerk tussen meerdere +groeperingen; als een echte, benoembare screeningsronde ooit nodig blijkt, +komt die terug als event-entiteit met eigen attributen. Reviewronde 19 juli +2026, zie §9.)* + +| Attribuut | Type | Verplicht | +|---|---|---| +| referral_case_id | ref referral_case | ja | +| performed_at | tijdstip | ja | +| activity_type | waardelijst `screening_activity_type` (telefonisch contact/dossieronderzoek/vragenlijst/…) | ja | +| performed_by | ref medewerker | ja | +| notes | tekst | nee | +| funded | ja/nee | nee *(default nee — screeningscontact is meestal niet gefinancierd, feitenmodel §3.4)* | + +**Uniciteit:** geen — 0..n activiteiten per screening. + +### 2.11 case_information_request + +**Doel:** een informatieverzoek als eigen gebeurtenisfeit, niet als +besluituitkomst of statusveld (feitenmodel §7 vraag 5, A28–A29). + +| Attribuut | Type | Verplicht | +|---|---|---| +| referral_case_id | ref referral_case | ja | +| requested_at | tijdstip | ja | +| requested_by | ref medewerker | ja | +| requested_information | tekst | ja | +| resolved_by_submission_id | ref referral_submission | nee | + +**Uniciteit:** geen — een case kan meerdere informatieverzoeken hebben, ook +ná een eerder acceptatiebesluit tijdens een heroverweging. + +### 2.12 care_acceptance_decision + +**Doel:** het formele besluit dat de beoordeling van een case afrondt: draagt +zelf de onderliggende beoordelingen, de besluituitkomst, de vervolgroute en, +bij afwijzing, de onderbouwing (feitenmodel §2, §3.5, §4). + +| Attribuut | Type | Verplicht | +|---|---|---| +| referral_case_id | ref referral_case | ja | +| decided_at | tijdstip | ja | +| decided_by | ref medewerker | ja | +| decision_authority_id | ref decision_authority | ja | +| content_match | ja/nee | ja | +| capacity_available | ja/nee | nee | +| program_context | ref care_program of tekst | nee | +| decision_outcome | waardelijst `decision_outcome` (`geaccepteerd`/`afgewezen`) | ja | +| follow_up_route | waardelijst `follow_up_route` (intake_direct/intakewachtlijst/spoedroute/doorverwijzen/case_afsluiten) | ja | +| rationale | tekst | verplicht bij `afgewezen`, anders optioneel | +| replaces_decision_id | ref care_acceptance_decision (zelfreferentie) | nee | +| replacement_reason | tekst | verplicht als `replaces_decision_id` gevuld is | + +**Uniciteit:** precies één case, beslisser, besluitdatum, besluituitkomst en +vervolgroute per besluit. Optioneel precies één eerder besluit van dezelfde +case vervangen — het vervangen besluit blijft ongewijzigd bewaard (feitenmodel +§4, §7 vraag 3). Capaciteit bepaalt de uitkomst niet automatisch (Route 2A/2B). +`replaces_decision_id` is uniek indien gevuld (partial unique index): een +besluit kan door hoogstens één ander besluit worden vervangen, zodat de +vervangt-keten nooit vertakt. Zonder die garantie zouden twee besluiten +tegelijk "niet vervangen" kunnen zijn en zou de afleidingsregel in §5 geen +eenduidig geldig besluit meer opleveren. Het geldige besluit van een case is +het laatste, niet-vervangen besluit in de keten. *(Concurrency bij +gelijktijdige heroverwegingen — bijvoorbeeld via `SELECT ... FOR UPDATE` op +de keten-tail — is een implementatiedetail voor de migratie-/API-laag, niet +voor dit document.)* + +**Kettingdiepte (voorstel, ter evaluatie):** onbeperkt toegestaan, geen aparte +constraint. De afleidingsregel in §5 ("volg de vervangt-keten naar het +laatste, niet-vervangen besluit") werkt voor elke kettinglengte zonder extra +modellering. Een harde grens van één niveau zou een legitieme +correctie-op-een-correctie blokkeren zonder dat daar een aantoonbare +praktijkreden voor is — de feitzinnen tonen alleen één niveau omdat dat het +scenario was, niet omdat een tweede niveau problematisch zou zijn. + +### 2.13 case_withdrawal + +**Doel:** cliënt-intrekking van een case, geen besluit en geen +bevoegdheidseis (feitenmodel §3.5 Route 4, §7 vraag 4). + +| Attribuut | Type | Verplicht | +|---|---|---| +| referral_case_id | ref referral_case | ja | +| withdrawn_at | tijdstip | ja | +| recorded_by | ref medewerker | ja | +| note | tekst | nee | + +**Uniciteit:** geen — kan op elk moment plaatsvinden, ook ná een positief +besluit. + +### 2.14 professional_referral + +**Doel:** de formele Nederlandse VERWIJZING, zelfstandig object gekoppeld aan +een request (R6–R10, feitenmodel §2, §6). + +| Attribuut | Type | Verplicht | +|---|---|---| +| referral_request_id | ref referral_request | ja | +| referrer_id | ref VERWIJZER | ja | +| referral_date | datum | ja | +| echelon | waardelijst `echelon` | nee | +| suspected_condition | tekst | nee | +| heraanmelding | ja/nee | ja (default nee) *(overgenomen van VERWIJZING in `model-aanmelding.md` §2.11, was in dit voorstel per abuis niet meegenomen)* | +| replaces_referral_id | ref professional_referral (zelfreferentie) | nee | +| replacement_reason | tekst | verplicht als `replaces_referral_id` gevuld is | + +**Uniciteit:** eigen identiteit, gekoppeld aan precies één request. Een +request kan 0..n professional referrals hebben: een correctie of aanvulling +op een eerdere verwijzing is geen nieuw request maar een nieuwe +`professional_referral` die de vorige vervangt — dezelfde +vervangt-constructie als bij `care_acceptance_decision` (domeinreview 19 juli +2026, was open punt 1). De vervangen verwijzing blijft ongewijzigd bewaard; +het geldige exemplaar is het laatste, niet-vervangen record in de keten. +`replaces_referral_id` is, net als bij `care_acceptance_decision`, uniek +indien gevuld — zelfde reden: voorkomt vertakking van de keten. + +**AGB-code:** geen apart veld — loopt via `referrer_id` → VERWIJZER, dat al +een `agb_code` draagt (`model-aanmelding.md` §2.6). + +### 2.15 municipal_care_assignment *(voorstel, gebaseerd op juridisch onderzoek 19 juli 2026 — zie §9)* + +**Doel:** de gemeentelijke beschikking/toewijzing (Wmo/Jeugdwet, iWmo/iJw +301-bericht) als toegangsticket naast — niet in plaats van — een eventuele +`professional_referral`. Bij Jeugdwet bestaat een zelfstandige professionele +verwijsroute náást de gemeentelijke toewijzing (een cliënt kan dus beide +hebben); bij Wmo bestaat geen professionele verwijsroute, alleen de +gemeentelijke toegang. + +| Attribuut | Type | Verplicht | +|---|---|---| +| referral_request_id | ref referral_request | ja | +| legal_framework | waardelijst `municipal_legal_framework` (wmo/jeugdwet) | ja | +| municipality_code | tekst (CBS-gemeentecode) | ja | +| assignment_number | tekst (toewijzings-/beschikkingsnummer) | ja | +| product_category | waardelijst `municipal_product_category` | ja | +| product_code | tekst | ja | +| volume | getal | ja | +| unit | waardelijst `municipal_product_unit` | ja | +| frequency | tekst | ja | +| start_date | datum | ja | +| end_date | datum | nee | +| issued_at | tijdstip | ja | +| replaces_assignment_id | ref municipal_care_assignment (zelfreferentie) | nee | +| replacement_reason | tekst | verplicht als `replaces_assignment_id` gevuld is | + +BSN, geboortedatum, geslacht en adres van de cliënt komen niet terug als +eigen velden — die lopen via PERSOON (al bestaand, niet dubbel modelleren). +AGB-code van de aanbieder loopt via de bestaande PRAKTIJK_INSTELLING-entiteit. + +**Uniciteit:** `assignment_number` uniek per `municipality_code`. Zelfde +vervangt-mechaniek als `professional_referral`/`care_acceptance_decision` +(gemeenten sturen herziene 301-berichten) — `replaces_assignment_id` uniek +indien gevuld, onbeperkte kettingdiepte. + +### 2.16 legal_mandate *(voorstel, gebaseerd op juridisch onderzoek 19 juli 2026 — zie §9)* + +**Doel:** het wettelijke mandaat bij gedwongen zorg (Wvggz): crisismaatregel +of zorgmachtiging. Bij een crisismaatregel heeft de instelling geen +discretionaire ruimte — het burgemeesterlijk besluit (op basis van een +medische verklaring) is zelf bindend; er bestaat geen apart institutioneel +acceptatiebesluit ernaast. Dit vervangt dus geen `care_acceptance_decision`, +het is een eigen soort feit met een andere aard (wettelijke plicht, geen +discretionaire beoordeling). + +| Attribuut | Type | Verplicht | +|---|---|---| +| referral_case_id | ref referral_case | ja | +| mandate_type | waardelijst `mandate_type` (crisismaatregel/zorgmachtiging) | ja | +| decision_reference | tekst (besluit-/beschikkingsnummer) | ja | +| decided_by_role | waardelijst `mandate_decider_role` (burgemeester/rechter) | ja | +| decided_at | tijdstip | ja | +| medical_statement_reference | ref document (medische verklaring psychiater) | verplicht bij `crisismaatregel` | +| effectuated_at | tijdstip (tenuitvoerlegging) | ja | +| valid_from | tijdstip | ja | +| valid_until | tijdstip | nee | + +*(Aanname, te bevestigen door een jurist: geen apart institutioneel +acceptatiebesluit náást een mandaat, ook niet bij zorgmachtiging — het +juridisch onderzoek noemt dit "aannemelijk", niet met een wetsartikel +bevestigd. De 24-uurstermijn voor tenuitvoerlegging bij een crisismaatregel +is een nudge-regel, geen opgeslagen constraint.)* + +**Uniciteit:** geen vervangt-mechaniek voorgesteld — een crisismaatregel kan +overgaan in een machtiging tot voortzetting/zorgmachtiging, maar dat is een +nieuw mandaat met eigen `decision_reference`, geen correctie van het vorige. + +### 2.17 crisis_encounter_note *(voorstel, gebaseerd op juridisch onderzoek 19 juli 2026 — zie §9)* + +**Doel:** gestructureerde vastlegging van crisisgerelateerd handelen vóórdat +identificatie of volledige dossiervorming heeft plaatsgevonden (gesignaleerd +thema, zie §6-geschiedenis in §9). Losstaand van `screening_activity`, dat +over het beoordelingsproces gaat, niet over klinisch handelen. + +| Attribuut | Type | Verplicht | +|---|---|---| +| referral_case_id | ref referral_case | ja | +| occurred_at | tijdstip | ja | +| recorded_by | ref medewerker | ja | +| fact_type | waardelijst `crisis_fact_type` (medicatie_toegediend/risico_inschatting/vitale_functie/dwangmaatregel/overig) | ja | +| description | tekst | ja | +| structured_value | tekst/JSON | nee | + +**Onderbouwing:** geen expliciet wetsartikel gevonden dat gestructureerde +vastlegging tíjdens de crisisinterventie zelf verplicht (juridisch onderzoek +19 juli 2026) — de algemene WGBO-dossierplicht ondersteunt dit wel in +algemene zin. Alle gestructureerde velden blijven daarom optioneel op +`description` na. `fact_type = dwangmaatregel` verwijst waar mogelijk naar de +formele Wvggz-dwangregistratie in plaats van die te dupliceren. + +**Nudge, geen constraint:** een generieke termijn van 14 dagen na de +behandeling waarbinnen een cliënt zich alsnog moet identificeren is +gevonden (juridisch onderzoek 19 juli 2026, bron niet met artikelnummer +bevestigd). Dit wordt een signaal-nudge gekoppeld aan +`referral_request.person_identified_at IS NULL`, geen blokkerende regel en +geen attribuut op deze entiteit — de termijn hangt aan identificatie, niet +aan de crisisnotitie. + +### 2.18 clinical_care_episode *(alleen ontstaan/einde — volledig episodemodel is een ander deelgebied)* + +**Doel:** de geaccepteerde zorgperiode die ontstaat uit een positief +acceptatiebesluit óf een geldig wettelijk mandaat, ook vóór de feitelijke +start van de intake (feitenmodel §3.5, §4; mandaat-route: juridisch +onderzoek 19 juli 2026). + +| Attribuut | Type | Verplicht | +|---|---|---| +| originating_decision_id | ref care_acceptance_decision | nee *(zie XOR-regel hieronder)* | +| originating_mandate_id | ref legal_mandate | nee *(zie XOR-regel hieronder)* | +| started_at | tijdstip | ja | +| ended_at | tijdstip | nee | +| end_reason | waardelijst `episode_end_reason` | verplicht zodra `ended_at` gevuld is | +| possible_continuation_of_episode_id | ref clinical_care_episode (zelfreferentie) | nee | + +**Uniciteit:** `CHECK` dat precies één van `originating_decision_id` / +`originating_mandate_id` gevuld is — een episode ontstaat óf uit een +acceptatiebesluit óf uit een mandaat, nooit uit beide of geen van beide. +Maximaal één episode per geldig positief acceptatiebesluit of geldig +mandaat. Een episode wordt nooit verwijderd; intrekking of correctie sluit +haar af met een reden (`ingetrokken_door_client`, `acceptatiebesluit_herzien`, +…) in plaats van haar te laten vervallen. Overige einde-redenen (bijvoorbeeld +“behandeling afgerond”) horen bij een later deelgebied. + +**`possible_continuation_of_episode_id` (voorstel, tussenoplossing — zie +§9):** systeem-gesuggereerd op basis van een gap ≤ 365 dagen tussen +`ended_at` van de vorige episode (zelfde `person_id`) en `started_at` van +deze episode; een mens bevestigt. **Expliciete disclaimer:** dit is een +zorginhoudelijke continuïteitsaanwijzing voor het behandelteam, **geen** +autoritatieve NZa-toets voor zorgtrajectnummer-hergebruik — die toets hangt +aan de datum van de laatst geleverde prestatie bij dezelfde zorgaanbieder +(niet aan de episode-einddatum) en hoort bij een nog niet bestaand +declaratie-/prestatieregistratie-deelgebied. Bewust niet "heraanmelding" +genoemd om verwarring met `professional_referral.heraanmelding` (een +ZPM-verwijstype-vlag, ander begrip) te voorkomen. + +### 2.19 case_urgency_assessment *(voorstel, domeinreview 19 juli 2026 — zie §9)* + +**Doel:** urgentie als herhaalbare beoordeling, geen vast veld. Vastgesteld +tijdens screening/triage door de rol screener of triagist, en kan later +worden aangepast door het intake-team of in een MDO. Consistent met het +tijdlijn-principe van dit document (§1): geen vervangt-relatie nodig zoals +bij `care_acceptance_decision` — de laatste beoordeling geldt, de inzet is +lager dan bij een acceptatiebesluit. + +| Attribuut | Type | Verplicht | +|---|---|---| +| referral_case_id | ref referral_case | ja | +| assessed_at | tijdstip | ja | +| assessed_by | ref medewerker | ja | +| assessed_in_role | waardelijst `urgency_assessor_role` (screener/triagist/intake_team/mdo) | ja | +| urgency_level | waardelijst `urgency_level` | ja | + +**Uniciteit:** geen — 0..n beoordelingen per case; de meest recente bepaalt +de actuele urgentie (zelfde afleidingspatroon als §5). Geen verplichte +onderbouwing bij de urgentiewaarde zelf (bevestigd door Colin — eenvoudige +waardelijst volstaat). + +### 2.20 episode_team_involvement *(minimale, voorlopige hook — zie §9)* + +**Doel:** vastleggen dat een team bij een episode betrokken is, ook wanneer +er nog geen individuele behandelaar is toegewezen (bijvoorbeeld: geaccepteerd +met vervolgroute intakewachtlijst, Route 2A). Dit is **niet** het volledige +zorgteam-concept — zorgteam (het team van betrokken behandelaren, met +regie-/hoofdbehandelaarschap en rollen, en later mogelijk cliëntautorisatie) +is een zelfstandig begrip, los van zorgprogramma en organisatorische eenheid, +en krijgt een eigen feitenronde (besluitenlog §10 punt 3; begrippenlijst +`Episode Clinical Team`). Deze entiteit is een minimale, voorlopige hook die +door die toekomstige ronde wordt vervangen of geabsorbeerd — geen rollen, +geen bevoegdheid, geen individueel lidmaatschap. + +| Attribuut | Type | Verplicht | +|---|---|---| +| clinical_care_episode_id | ref clinical_care_episode | ja | +| team_reference | tekst *(voorlopig vrije tekst — geen Team-entiteit vóór de zorgteam-ronde)* | ja | +| involved_since | tijdstip | ja | +| recorded_by | ref medewerker | ja | + +**Uniciteit:** geen — een episode kan door de tijd heen bij meerdere teams +betrokken zijn (bijvoorbeeld bij op-/afschalen); geen statusveld, zelfde +tijdlijn-principe. + +## 3. Relaties met cardinaliteit + +**Legenda:** `Van | Naar | A..B..C` — A is de multipliciteit van *Van* per +één rij *Naar* (meestal `1` bij een verplichte FK op *Naar*; is die FK +optioneel, dan wordt A zelf `0..1` en vervalt het derde token, dus `A..B`). +`B..C` is de multipliciteit van *Naar* per één rij *Van*, als min..max +(`n` = onbegrensd). Rijen met `(self)` beschrijven alleen het +zelfreferentie-FK-veld, geen relatie tussen twee tabellen (reviewronde 19 +juli 2026, zie §9). + +| Van | Naar | Cardinaliteit | Toelichting | +|---|---|---|---| +| referral_request | PERSOON | n..0..1 | optioneel — zie person_identified_at | +| referral_case | PERSOON | n..0..1 | optioneel — zie person_identified_at | +| referral_request | professional_referral | 1..0..n | correctie/aanvulling is een vervangend record, geen nieuw request | +| referral_submission | submission_document | 1..0..n | een submission kan zonder documenten bestaan | +| referral_submission | submission_request_link | 1..0..n | een submission kan nul, één of meerdere requests representeren/aanvullen | +| referral_request | submission_request_link | 1..1..n | elk request is via minstens één submission binnengekomen | +| referral_submission | submission_duplicate_assessment | 1..0..n | een submission kan als duplicaat van meerdere andere zijn beoordeeld (zeldzaam, toegestaan) | +| referral_case | submission_case_assignment | 1..1..n | een case wordt door minstens één submission gevoed | +| referral_submission | submission_case_assignment | 1..0..n | een submission kan (uitzonderlijk) aan meerdere cases zijn toegewezen | +| referral_case | request_case_link | 1..1..n | een case behandelt minstens één request | +| referral_request | request_case_link | 1..1..n(uitzondering) | normaliter 1 case, bij uitzondering meer (feitenmodel §4) | +| referral_case | case_consolidation | 1..0..n | een case kan leidend zijn over meerdere andere, of zelf niet-leidend zijn in precies één consolidatie (UNIQUE(related_case_id)) | +| referral_case | screening_activity | 1..0..n | direct aan de case, geen aparte groeperingsentiteit meer | +| referral_case | case_information_request | 1..0..n | | +| referral_submission | case_information_request | 0..1 | een submission kan een reactie zijn op hoogstens één informatieverzoek (beide kanten optioneel-enkelvoudig, vandaar geen derde token) | +| referral_case | care_acceptance_decision | 1..0..n | 0 zolang nog geen besluit; n bij heroverweging/correctie | +| care_acceptance_decision | care_acceptance_decision | 0..1 (self) | `replaces_decision_id`, optioneel en uniek indien gevuld — voorkomt vertakking; onbeperkte kettingdiepte (voorstel) | +| professional_referral | professional_referral | 0..1 (self) | `replaces_referral_id`, optioneel en uniek indien gevuld — voorkomt vertakking; onbeperkte kettingdiepte (voorstel) | +| referral_case | case_withdrawal | 1..0..n | doorgaans 0 of 1, technisch meerdere niet uitgesloten | +| referral_request | municipal_care_assignment | 1..0..n | naast, niet in plaats van `professional_referral` (voorstel) | +| municipal_care_assignment | municipal_care_assignment | 0..1 (self) | `replaces_assignment_id`, optioneel en uniek indien gevuld (voorstel) | +| referral_case | legal_mandate | 1..0..n | crisismaatregel kan overgaan in zorgmachtiging: nieuw mandaat, geen vervangt-relatie (voorstel) | +| referral_case | crisis_encounter_note | 1..0..n | werkt al zonder `person_id` (voorstel) | +| care_acceptance_decision | clinical_care_episode | 1..0..1 | XOR met `legal_mandate`; alleen bij uitkomst `geaccepteerd` | +| legal_mandate | clinical_care_episode | 1..0..1 | XOR met `care_acceptance_decision` (voorstel) | +| clinical_care_episode | clinical_care_episode | 0..1 (self) | `possible_continuation_of_episode_id`, optioneel, tussenoplossing (voorstel) | +| referral_case | case_urgency_assessment | 1..0..n | herhaalbaar, laatste geldt (voorstel) | +| clinical_care_episode | episode_team_involvement | 1..0..n | minimale hook, geen individueel lidmaatschap (voorstel) | + +## 4. Waardelijsten (startlijsten, te bevestigen) + +| Waardelijst | Voorlopige waarden | +|---|---| +| `initiator_type` | professional, organisatie, cliënt, vertegenwoordiger | +| `submission_channel` | ZorgDomein, e-mail, telefoon, portaal, post, overig | +| `document_type` | verwijsbrief, diagnostische aanvulling, beschikking, overig | +| `screening_activity_type` | telefonisch contact, dossieronderzoek, vragenlijst, overig | +| `decision_outcome` | geaccepteerd, afgewezen | +| `follow_up_route` | intake_direct, intakewachtlijst, spoedroute, doorverwijzen, case_afsluiten | +| `episode_end_reason` | ingetrokken_door_client, acceptatiebesluit_herzien, *(overige waarden: later deelgebied)* | +| `echelon` | over te nemen uit `model-aanmelding.md` §2.11 (bestaande waardelijst) | +| `zpm_verwijstype` | over te nemen uit `model-aanmelding.md` §2.10 (bestaande waardelijst, ZPM-verwijstypen 01–07) | +| `wettelijk_kader` | over te nemen uit `model-aanmelding.md` §2.10 (bestaande waardelijst: zvw, wmo, jeugdwet, *(wvggz toe te voegen)*) | +| `municipal_legal_framework` | wmo, jeugdwet *(voorstel)* | +| `municipal_product_category` / `municipal_product_unit` | over te nemen uit iWmo/iJw-standaard (voorstel, nog niet uitgezocht) | +| `mandate_type` | crisismaatregel, zorgmachtiging *(voorstel)* | +| `mandate_decider_role` | burgemeester, rechter *(voorstel)* | +| `crisis_fact_type` | medicatie_toegediend, risico_inschatting, vitale_functie, dwangmaatregel, overig *(voorstel)* | +| `urgency_assessor_role` | screener, triagist, intake_team, mdo *(voorstel)* | +| `urgency_level` | laag, normaal, hoog, spoed *(voorstel)* | + +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. + +## 5. Waardelijst-vervanging: geen klassieke statusmachine + +`referral_case` heeft bewust geen `status`-kolom met vaste overgangen. De +actuele stand wordt afgeleid door de gebeurtenissen in tijdsvolgorde te +lezen: + +1. Is er een `case_withdrawal` zonder latere `care_acceptance_decision`? → + case is ingetrokken. +2. Is er een `care_acceptance_decision` die niet door een ander besluit is + vervangen (`replaces_decision_id` wijst niet naar dit besluit)? → dat is + het geldige besluit; de case is besloten met die uitkomst. +3. Is er een openstaand `case_information_request` zonder latere + `care_acceptance_decision` of `case_withdrawal`? → case wacht op + aanvullende informatie. +4. Geen van bovenstaande? → case is in beoordeling (screening loopt of moet + nog beginnen). + +Dit is een leesregel voor de applicatielaag, geen opgeslagen veld — zo blijft +de volledige tijdlijn de bron (consistent met B7 wachtlijst). + +**Implementatie-eis (UX-review 19 juli 2026, zie §9):** deze afleidingsregel +wordt precies één keer geïmplementeerd, in één centrale, herbruikbare +projectie (bijvoorbeeld een view of materialized read-model), niet los per +scherm. Werklijst, dashboard en detailpagina lezen allemaal diezelfde +projectie, nooit de losse events elk apart opnieuw. Zonder die eis ontstaat +het risico dat schermen subtiel verschillende interpretaties van "de actuele +stand" tonen — precies de drift die het tijdlijn-principe moest voorkomen. + +## 6. Buiten scope van dit document + +- Het volledige `clinical_care_episode`-model (programma-/organisatie- + betrokkenheid, zorgteam) — apart deelgebied, alleen ontstaan/einde hier. +- `clinical_intake_assessment` en het behandeladvies — vraag 2 uit het + feitenmodel is nog open onderzoek. +- PERSOON/CLIENT/VERWIJZER/PRAKTIJK_INSTELLING — al uitgewerkt in + `model-aanmelding.md` §2.1–§2.9; dit voorstel refereert ernaar zonder te + dupliceren. +- Waardelijst-governance (wie mag waarden toevoegen) — ADM-ronde. +- Declaratie-/prestatieregistratie-deelgebied — nodig voor de autoritatieve + NZa-365-dagentoets voor zorgtrajectnummer-hergebruik (zie + `possible_continuation_of_episode_id`, §2.18); dit voorstel modelleert + alleen een zorginhoudelijke benadering, geen declaratie-waarheid. +- Productcodes/volumes bij `municipal_care_assignment` — minimale variant nu + (§2.15), net als bij TOEWIJZING in `model-aanmelding.md` §2.13; verdere + detaillering in de declaratie-ronde. +- ~~Gestructureerde crisisdocumentatie vóór identificatie~~ — geadresseerd + met `crisis_encounter_note` (§2.17), gebaseerd op juridisch onderzoek 19 + juli 2026 (zie §9). + +## 7. Open punten voor Colin + +**Beantwoord:** + +- ~~`person_id` verplicht op referral_request/referral_case?~~ Nee, optioneel + — komt voor bij crisisaanmeldingen met nog onbekende identiteit. Geen + placeholder-persoon; de koppeling wordt een eigen gedateerd feit + (`person_identified_at`/`_by`) zodra de identiteit vaststaat (domeinreview + 19 juli 2026). +- ~~Kan een request meerdere professional referrals hebben?~~ Ja — een + correctie of aanvulling is een wijziging, geen nieuwe verwijzing. Dezelfde + vervangt-constructie als bij `care_acceptance_decision` + (`replaces_referral_id` + verplichte reden); de oude verwijzing blijft + bewaard (domeinreview 19 juli 2026). + +**Voorstel op basis van precedent (ter evaluatie — nog niet door jou +bevestigd):** + +- **Bevoegdheid bij case_consolidation.** Geen speciale + `decision_authority` vereist, zoals bij `submission_case_assignment` en + `submission_duplicate_assessment` — een administratieve correctie, geen + inhoudelijk zorgbesluit. Verwerkt in §2.9. +- **Diepte van de vervangt-keten.** Onbeperkt, geen aparte constraint — de + afleidingsregel in §5 werkt voor elke lengte en een harde grens zou een + legitieme correctie-op-een-correctie zonder aantoonbare reden blokkeren. + Verwerkt in §2.12, §2.14, §3. +- **`submission_link_type` vervalt.** Representeert/vult_aan is geen + zelfstandig feit met eigen regels, puur chronologisch afleidbaar uit + `established_at` (nu verplicht). Verwerkt in §2.4, §4. +- **`request_case_link.reason`:** bevestigd zoals al voorgesteld — verplicht + alleen bij de uitzondering (meer dan één case per request), optioneel bij + de normale, enkelvoudige koppeling. Consistent met `submission_case_assignment`, + waar de reden ook alleen bij de eerste/bijzondere toewijzing werd genoemd. + +**Nog echt open:** + +1. **Startwaarden van de waardelijsten in §4** — met name `submission_channel`, + `document_type` en `screening_activity_type` zijn nu overgenomen uit de + voorbeeldfeiten, niet uit een volledige inventarisatie. +2. **Volledig zorgteam-model.** `episode_team_involvement` (§2.20) is bewust + een minimale hook, geen individueel lidmaatschap, geen rollen, geen + regie-/hoofdbehandelaarschap, geen bevoegdheid, geen toekomstige + cliëntautorisatie. Het volledige zorgteam-concept — los van zorgprogramma + en organisatorische eenheid, die op hun beurt gekoppeld kunnen worden + (een organisatorische eenheid kan één of meer zorgprogramma's verzorgen) + — krijgt een eigen feitenronde (besluitenlog §10 punt 3; begrippenlijst + `Episode Clinical Team`/`Episode Team Assignment`/`Episode Team Role`/ + `Lead Clinician Role`/`Decision Authority`). Deze hook wordt daardoor + vervangen of geabsorbeerd, niet doorontwikkeld binnen dit document. +3. **Juridische aannames in §2.15–§2.17 die een jurist moet bevestigen** + (uit het onderzoek van 19 juli 2026, zie §9): geen apart institutioneel + acceptatiebesluit náást een Wvggz-mandaat (ook niet bij zorgmachtiging); + de 24-uurstermijn voor tenuitvoerlegging als nudge, niet als constraint; + de 14-dagentermijn voor identificatie als signaal-nudge; en of de + Jeugdwet-verwijsroute specifiek voor jeugd-ggz hetzelfde "naast elkaar, + geen vervanging"-patroon volgt als voor jeugdhulp in het algemeen. Deze + aannames blokkeren de modellering niet, maar moeten vóór productie + geverifieerd worden. + +## 8. Bronverwijzingen + +| Onderdeel | Bron | +|---|---| +| Alle feitzinnen, besloten regels en scenario's | `../feitenmodellen/feitenmodel-instroom.md` | +| Screening=acceptatie, capaciteitsroutes, episodevorming | `../sessielogs/sessielog-2026-07-19.md` §5–§9 | +| Tijdlijn i.p.v. statusmachine-principe | `../sessielogs/sessielog-2026-07-18.md` §5 (B7 wachtlijst), discovery §5.1 #5 | +| PERSOON/CLIENT/VERWIJZER/PRAKTIJK_INSTELLING (hergebruikt, niet gedupliceerd) | `model-aanmelding.md` §2.1–§2.9 | +| Engelstalig technisch model | besluit B20, `../besluiten/besluitenlog-datamodel-2026-07-18.md` §9 | + +## 9. Reviewronde 19 juli 2026 + +Twee onafhankelijke reviews (technisch datamodel-perspectief, GGZ-domein- +perspectief) op de eerste versie van dit document leverden 9 bevindingen op. +Direct verwerkt in dit document, zonder verdere domeinvraag omdat het +technische correcties of het herstellen van een omissie betrof: + +1. **Vervangt-keten kon vertakken.** `replaces_decision_id`/ + `replaces_referral_id` zijn nu uniek indien gevuld — anders zou §5's + afleidingsregel geen eenduidig geldig besluit meer opleveren. Verwerkt in + §2.12, §2.14, §3. +2. **Timestamp-precisie ondermijnde de tijdlijn-aanpak.** Event-velden die + ten onrechte op `datum` (dagprecisie) stonden zijn naar `tijdstip` + gebracht, consistent met `referral_submission.received_at` — anders zijn + gebeurtenissen op dezelfde kalenderdag niet eenduidig te ordenen. Verwerkt + op alle event-attributen behalve `professional_referral.referral_date` + (een extern documentdatum, geen systeemgebeurtenis) en + `request_case_link.since`. +3. **ZPM-verplichte velden ontbraken.** `professional_referral.heraanmelding` + en `referral_case.zpm_verwijstype`/`huisarts_geinformeerd_op` stonden al + in het oudere `model-aanmelding.md` (AANMELDING/VERWIJZING) en zijn bij + het opnieuw opbouwen van dit deelgebied per abuis niet meegenomen — dit is + hersteld, geen nieuwe ontwerpvraag. AGB-code en correspondentietoestemming + bleken al gedekt via bestaande entiteiten (VERWIJZER, TOESTEMMING) en + kregen alleen een verduidelijkende notitie. + +Vervolgens is een tweede reviewronde uitgevoerd door drie onafhankelijke +expert-agents: een datamodel-expert op de resterende technische punten, een +GGZ-domein-expert op de domeinvragen, en een UX-expert op bruikbaarheid voor +de uiteindelijke gebruikersinterface. + +**Technische punten (datamodel-expert) — direct verwerkt, mechanische +correcties zonder domeinvraag:** + +- de lege, inconsistent gecardinaliseerde `screening`-entiteit is vervallen; + `screening_activity` hangt nu direct aan `referral_case` (§2.10); +- naamgeving gecorrigeerd: `signal_case_assignment` → `submission_case_ + assignment`, `access_case_consolidation` → `case_consolidation`, + `decision_authority_id`/`program_context` kregen Engelse ref-namen + conform B20 (§2.6, §2.7, §2.9, §2.12); +- cardinaliteitsfout `referral_submission → case_information_request` + gecorrigeerd naar `0..1`; notatie-legenda toegevoegd aan §3; +- unique constraint + check toegevoegd op `case_consolidation` (§2.9). + +**UX-punt (UX-expert) — direct verwerkt, implementatie-eis zonder +domeinvraag:** + +- de afleidingsregel in §5 moet als één centrale projectie/read-model + geïmplementeerd worden, niet los per scherm — toegevoegd als expliciete + eis in §5. + +**Derde ronde — GGZ-wetgeving-expert (juridisch onderzoek) gevolgd door +datamodel-expert (schema-integratie), verwerkt in dit document:** + +Een jurist-georiënteerd onderzoek naar Wvggz, Wmo/Jeugdwet, ZPM-regels en +WGBO onderbouwde de vijf GGZ-scope-vragen uit de tweede ronde. De datamodel- +expert vertaalde de bevindingen naar concreet schema. Verwerkt: + +- **Aanmelddatum.** Bevestigd als leesregel (geen nieuw veld): de vroegste + `referral_submission.received_at` die via `submission_request_link` aan het + request hangt, is het regelgevend juiste aanmelddatum-moment voor de + 275-dagentoets. Redelijk zekere juridische basis (NZa-veldafspraken; exact + artikelnummer niet geverifieerd). +- **Wmo/Jeugdwet.** `municipal_care_assignment` toegevoegd (§2.15) — + bestaat náást, niet in plaats van `professional_referral` (Jeugdwet kent + een zelfstandige professionele verwijsroute; Wmo niet). `referral_case. + wettelijk_kader` hersteld (§2.6). *Juridisch minder zeker: of dit patroon + specifiek voor jeugd-ggz identiek is aan jeugdhulp in het algemeen — zie §7 + punt 3.* +- **Wvggz.** `legal_mandate` toegevoegd (§2.16) — geen vervangt-relatie met + `care_acceptance_decision`, want geen institutionele discretie bij een + crisismaatregel (bindend burgemeesterlijk besluit). `clinical_care_episode` + aangepast: `originating_decision_id` optioneel, nieuw `originating_ + mandate_id`, met een XOR-regel — een episode ontstaat óf uit een + acceptatiebesluit óf uit een mandaat (§2.18). *Juridisch minder zeker: of + dit ook voor de zorgmachtiging-route (rechter/officier van justitie) klopt + — zie §7 punt 3.* +- **Heraanmelding/zorgtrajectnummer.** Herzien ten opzichte van het eerdere + voorstel: de NZa-365-dagenregel hangt aan de datum van de laatst geleverde + prestatie bij dezelfde aanbieder, niet aan de episode-einddatum, en is een + ander begrip dan `professional_referral.heraanmelding`. Omdat + prestatieregistratie nog geen deelgebied is, is `possible_continuation_ + of_episode_id` toegevoegd (§2.18) als zorginhoudelijke + continuïteitsaanwijzing (episode-einddatum als benadering), expliciet + gemarkeerd als **geen** autoritatieve declaratietoets. +- **Crisisdocumentatie vóór identificatie.** `crisis_encounter_note` + toegevoegd (§2.17), alle gestructureerde velden optioneel — geen expliciet + wetsartikel gevonden dat gestructureerde vastlegging tíjdens de + interventie verplicht, wel de algemene WGBO-dossierplicht. De gevonden + 14-dagen-identificatietermijn is een signaal-nudge, geen constraint. + +Daarna is het eigenaarschap/urgentie-punt met Colin doorgesproken +(domeinreview 19 juli 2026), met een scherpere uitkomst dan het +UX-voorstel: + +- **Urgentie** is geen vast veld maar een herhaalbare beoordeling — + vastgesteld tijdens screening/triage door de rol screener/triagist, later + aan te passen door het intake-team of in een MDO. `case_urgency_assessment` + toegevoegd (§2.19): herhaalbaar, laatste geldt, geen vervangt-relatie nodig + (lagere inzet dan een acceptatiebesluit), geen verplichte onderbouwing + (bevestigd: eenvoudige waardelijst volstaat). +- **Eigenaarschap** bleek eigenlijk een onderdeel van een groter, apart + begrip: **zorgteam** — het team van betrokken behandelaren (soms 1 persoon, + soms multidisciplinair, kan een organisatorische eenheid overstijgen), met + regie-/hoofdbehandelaarschap en later mogelijk cliëntautorisatie. Dat is + zelfstandig ten opzichte van zorgprogramma (inhoudelijk aanbod) en + organisatorische eenheid (die aan elkaar gekoppeld kunnen worden — een OE + kan één of meer zorgprogramma's verzorgen), en hoort bij een cliënt/case + kunnen staan zonder dat er al een individuele behandelaar is toegewezen + (bijvoorbeeld: geaccepteerd, intakewachtlijst — Route 2A). Op uitdrukkelijk + verzoek van Colin blijft dit nu beperkt tot een minimale, voorlopige hook + — `episode_team_involvement` (§2.20), geen rollen, geen bevoegdheid, geen + individueel lidmaatschap. Het volledige zorgteam-model krijgt een eigen + feitenronde (zie §7 punt 2). + +**Nog open:** + +- De juridische aannames uit de derde ronde (§7 punt 3) zijn in het schema + verwerkt maar nog niet door een jurist bevestigd. +- Het volledige zorgteam-model (§7 punt 2). diff --git a/docs/datamodel/feitenmodellen/feitenmodel-instroom.md b/docs/datamodel/feitenmodellen/feitenmodel-instroom.md index 08096a9..ef6ab91 100644 --- a/docs/datamodel/feitenmodellen/feitenmodel-instroom.md +++ b/docs/datamodel/feitenmodellen/feitenmodel-instroom.md @@ -150,11 +150,21 @@ als zorgverzoek R-101.* spoed of crisis kan zorg al worden geleverd voordat de verwijzing is ontvangen. +**Beantwoord in domeinreview (19 juli 2026):** + +- Een request kan zonder bekende persoon bestaan. Dit komt voor bij + crisisaanmeldingen waarbij de identiteit nog niet vaststaat. Een + placeholder- of "John Doe"-persoon die later moet worden om-gehangen is + bewust geen oplossing — dat vereist het achteraf verplaatsen van alle + gekoppelde feiten naar de echte persoon, wat tegen append-only ingaat. In + plaats daarvan is `person_id` optioneel en wordt de koppeling vastgelegd + als een eigen, gedateerd en toegeschreven feit zodra de identiteit bekend + wordt. + **Te toetsen:** - Is “dezelfde geuite zorgvraag” een expliciete relatie tussen verzoeken, of wordt samenhang uitsluitend binnen de Referral Case beoordeeld? -- Is een verzoek zonder bekende persoon tijdelijk toegestaan? ### 3.2 Afzonderlijke binnenkomst @@ -489,7 +499,11 @@ cardinaliteiten. ### Referral Request - Elk request heeft één stabiele identiteit. -- Elk request betreft op enig moment precies één persoon of cliënt. +- Een request kan zonder bekende persoon bestaan (crisisaanmelding met nog + onbekende identiteit). Zodra de persoon bekend is, betreft het request + precies één persoon of cliënt; de koppeling zelf is een gedateerd, + toegeschreven feit, geen stille invulling van een placeholder (domeinreview + 19 juli 2026). - Elk request heeft minstens één initiator. - Elk request bevat één of meer samenhangende geuite zorgvragen. - Zorgvragen die afzonderlijk moeten worden beoordeeld horen in afzonderlijke -- 2.39.5 From b663851233d24a6069e071ae7f3499b035c520c5 Mon Sep 17 00:00:00 2001 From: colinislit Date: Sun, 19 Jul 2026 17:59:30 +0200 Subject: [PATCH 14/19] docs(datamodel): besluitenlog uitgebreid met B21-B30 (instroom-feitenronde) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Legt de uitkomst van de instroom-feitenronde en het entiteitenmodel formeel vast als besluiten B21-B30: screening=acceptatie, losse besluit-/vervolgroute- /onderbouwingsfeiten, expliciete vervangt-relatie bij herziening, cliënt-intrekking zonder bevoegdheidseis, tijdlijn i.p.v. statusmachine, zorgverzoek zonder bekende persoon, Wmo/Jeugdwet en Wvggz als eigen instroomroutes, crisisdocumentatie vóór identificatie, herhaalbare urgentiebeoordeling, en een minimale hook voor teambetrokkenheid vooruitlopend op een aparte zorgteam-ronde. Werkt §10 (vervolg en nog open) bij: markeert afgeronde punten, voegt de juridische verificatie- en behandeladvies-onderzoekspunten toe, en noteert dat model-aanmelding.md's AANMELDING/VERWIJZING/ZORGEPISODE-deel is vervangen door model-instroom.md (synchronisatie volgt als eerstvolgende stap). --- .../besluitenlog-datamodel-2026-07-18.md | 111 ++++++++++++++++-- 1 file changed, 102 insertions(+), 9 deletions(-) diff --git a/docs/datamodel/besluiten/besluitenlog-datamodel-2026-07-18.md b/docs/datamodel/besluiten/besluitenlog-datamodel-2026-07-18.md index b7f5d08..5af0a13 100644 --- a/docs/datamodel/besluiten/besluitenlog-datamodel-2026-07-18.md +++ b/docs/datamodel/besluiten/besluitenlog-datamodel-2026-07-18.md @@ -1,9 +1,9 @@ -# Besluitenlog datamodel — sessie 18 juli 2026 +# Besluitenlog datamodel — sessie 18 juli 2026 (bijgewerkt 19 juli 2026) **Status:** inhoudelijke besluiten en ontwerpuitgangspunten uit gesprek met Colin **Werking:** dit document is leidend waar het oudere `../deelmodellen/datamodel-discovery.md` of een `model-*.md`-voorstel ermee conflicteert -**Context en verloop:** zie `../sessielogs/sessielog-2026-07-18.md` -**Vervolg:** structurele besluiten verwerken in de deelmodellen voordat SQL of migrations worden gemaakt +**Context en verloop:** zie `../sessielogs/sessielog-2026-07-18.md` en `../sessielogs/sessielog-2026-07-19.md` (§2 uitgebreid met B21–B30, instroom feitenronde en entiteitenmodel) +**Vervolg:** structurele besluiten verwerken in de deelmodellen voordat SQL of migrations worden gemaakt — voor instroom inmiddels gedaan in `../feitenmodellen/feitenmodel-instroom.md` en `../deelmodellen/model-instroom.md`; begrippenlijst- en `../deelmodellen/model-aanmelding.md`-synchronisatie volgt als eerstvolgende stap ## 1. Legenda @@ -75,6 +75,97 @@ De definitie, statussen en bevoegdheden van het acceptatiebesluit moeten nog wor Bewaarbeleid voor afgewezen trajecten, pre-acceptatiegegevens en screeningsinformatie moet juridisch verder worden onderzocht. De WGBO-bewaartermijn mag niet zonder grondslaganalyse op alle instroomgegevens worden toegepast. +### B21 — Screeningsbesluit is het acceptatiebesluit + +**Besluit** + +- Er is geen apart, voorafgaand screeningsadvies naast het acceptatiebesluit; **Care Acceptance Decision** draagt zelf de onderliggende beoordelingen (inhoudelijke match, plek, capaciteit), de besluituitkomst, de vervolgroute en, bij afwijzing, de onderbouwing. +- Dit vervangt de eerder in `../deelmodellen/datamodel-discovery.md` §5.2 en `../deelmodellen/model-screening.md` veronderstelde scheiding tussen screeningsbesluit/-advies en een apart acceptatiebesluit. +- Screening blijft bestaan als de verzameling activiteiten (contact, onderzoek) die de beoordeling voeden, niet als eigen besluitobject. + +### B22 — Besluituitkomst, vervolgroute en onderbouwing zijn losse feiten + +**Besluit** + +- Besluituitkomst is beperkt tot `geaccepteerd`/`afgewezen`; doorverwijzen en case afsluiten zijn vervolgroutes, geen besluituitkomsten. +- Capaciteit is invoer voor het besluit maar bepaalt de uitkomst niet automatisch: bij ontbrekende capaciteit zijn zowel "geaccepteerd + intakewachtlijst" als "afgewezen + capaciteitsonderbouwing" geldige uitkomsten. +- Bij afwijzing is een concrete onderbouwing verplicht; het herhalen van de uitkomst is geen geldige onderbouwing. +- Elk positief besluit laat een zorgepisode ontstaan, ook wanneer de vervolgroute intakewachtlijst is — niet pas bij de feitelijke start van de intake. Dit corrigeert het eerdere voorstel in `../deelmodellen/model-aanmelding.md` §2.15 waarin de episode pas bij uitkomst "intake" ontstond. + +### B23 — Herziening via expliciete vervangt-relatie + +**Besluit** + +- Een acceptatiebesluit of professionele verwijzing kan optioneel precies één eerder exemplaar vervangen, met een verplichte reden. Het vervangen exemplaar blijft ongewijzigd bewaard; er is geen impliciete "laatste is geldig"-regel op basis van datum. +- Dit geldt zowel bij heroverweging na afwijzing als bij institutionele correctie van een eerder positief besluit, met dezelfde bevoegdheidseis als het oorspronkelijke besluit. +- De vervangt-relatie is uniek per vervangen exemplaar (voorkomt vertakking) en kan onbeperkt diep zijn. + +**Ontwerpuitwerking** + +Of dit patroon ook voor andere herzienbare objecten in latere deelgebieden geldt, wordt per deelgebied opnieuw beoordeeld. + +### B24 — Cliënt-intrekking is geen besluit + +**Besluit** + +- Cliënt-intrekking van een aanmeldingstraject vereist geen beslisbevoegdheid en kan op elk moment plaatsvinden, ook ná een positief besluit. +- Een reeds ontstane zorgepisode wordt bij intrekking of institutionele correctie altijd afgesloten met een reden, nooit verwijderd of ongedaan gemaakt. + +### B25 — Geen statusmachine, actuele stand afgeleid uit een gebeurtenistijdlijn + +**Besluit** + +- Het aanmeldingstraject heeft geen vaste, eenrichtings-statusmachine. De actuele stand (in beoordeling, wacht op informatie, besloten, ingetrokken) wordt afgeleid uit een tijdlijn van gebeurtenissen (toewijzing, informatieverzoek, besluit, intrekking, consolidatie), niet uit één overschrijfbaar statusveld. +- Dit sluit aan bij B7 (wachtlijst: volledige tijdlijn is de bron) en de non-lineaire aanmelding-status uit `../deelmodellen/datamodel-discovery.md` §5.1 #5. +- Een informatieverzoek is een eigen gebeurtenisfeit, geen besluituitkomst en geen statusfase — er bestaat op dat moment nog geen besluit. + +**Ontwerpuitwerking** + +De afleidingsregel wordt in de applicatielaag als één centrale, herbruikbare projectie geïmplementeerd, niet los per scherm. + +### B26 — Zorgverzoek kan zonder bekende persoon bestaan + +**Besluit** + +- Bij crisisaanmeldingen kan de identiteit nog onbekend zijn op het moment dat het zorgverzoek al geregistreerd moet worden. Een placeholder- of "John Doe"-persoon die later wordt vervangen is bewust geen oplossing, omdat dat vereist alle gekoppelde feiten achteraf naar de echte persoon te verplaatsen. +- De koppeling aan een persoon wordt in plaats daarvan een eigen, gedateerd en toegeschreven feit, vastgelegd zodra de identiteit bekend wordt. + +### B27 — Wmo/Jeugdwet-toewijzing en Wvggz-mandaat zijn eigen instroomroutes + +**Besluit** + +- Een gemeentelijke toewijzing (Wmo/Jeugdwet) bestaat náást, niet in plaats van een professionele verwijzing — bij Jeugdwet bestaat een zelfstandige professionele verwijsroute naast de gemeentelijke toegang; bij Wmo bestaat geen professionele verwijsroute. +- Een Wvggz-mandaat (crisismaatregel/zorgmachtiging) kent geen institutionele acceptatiediscretie en vervangt het acceptatiebesluit niet: het besluit tot gedwongen zorg is al genomen door burgemeester of rechter. Een zorgepisode kan daarom ook rechtstreeks uit een geldig mandaat ontstaan, niet uitsluitend uit een acceptatiebesluit. + +**Onderzoek** + +De juridische aannames achter dit besluit — met name of de zorgmachtiging-route (officier van justitie/rechter) hetzelfde patroon volgt als de crisismaatregel, en of de Jeugdwet-verwijsroute specifiek voor jeugd-ggz identiek is aan jeugdhulp in het algemeen — zijn nog niet door een jurist bevestigd. + +### B28 — Gestructureerde crisisdocumentatie vóór identificatie + +**Ontwerpuitwerking** + +Crisisgerelateerd handelen (medicatie, risico-inschatting, dwangmaatregelen) kan vóór identificatie of dossiervorming al gestructureerd worden vastgelegd, los van het beoordelingsproces (screening). Geen expliciet wetsartikel gevonden dat dit tijdens de interventie zelf verplicht; de algemene WGBO-dossierplicht ondersteunt het wel. Concrete velden blijven daarom grotendeels optioneel. + +### B29 — Urgentie is een herhaalbare beoordeling + +**Besluit** + +- Urgentie van een aanmeldingstraject is geen vast veld maar een herhaalbare beoordeling: vastgesteld tijdens screening/triage door de rol screener/triagist, en later aan te passen door het intake-team of in een MDO. +- De waarde zelf is een eenvoudige waardelijst zonder verplichte onderbouwing. + +### B30 — Minimale hook voor teambetrokkenheid, volledig zorgteam-model blijft aparte ronde + +**Besluit** + +- Een team kan bij een zorgepisode betrokken zijn vóórdat een individuele behandelaar is toegewezen (bijvoorbeeld tijdens een intakewachtlijst). +- Zorgteam (het team van betrokken behandelaren, met regie-/hoofdbehandelaarschap) is een zelfstandig begrip, los van zorgprogramma (inhoudelijk aanbod) en organisatorische eenheid — die laatste twee kunnen aan elkaar gekoppeld worden (een organisatorische eenheid kan één of meer zorgprogramma's verzorgen). +- Voor nu wordt alleen een minimale, voorlopige hook voor teambetrokkenheid vastgelegd, zonder rollen, bevoegdheid of individueel lidmaatschap. Dit bevestigt en verscherpt B16 en §10 punt 3: het volledige zorgteam-model (leden, rollen, regiebehandelaarschap, bevoegdheid, mogelijk toekomstige cliëntautorisatie) blijft een aparte, nog te plannen ronde. + +--- + +B21–B30 zijn de uitkomst van de FCO-IM-feitenronde en de daaropvolgende entiteiten-/cardinaliteitenafleiding voor instroom (sessie 19 juli 2026). Volledige feitzinnen, scenariotoetsen, het uitgewerkte entiteitenmodel (20 entiteiten) en de reviewgeschiedenis staan in `../feitenmodellen/feitenmodel-instroom.md` en `../deelmodellen/model-instroom.md`; dit besluitenlog vat de richting samen en dupliceert niet de volledige attribuuttabellen. + ## 3. Intake ### B6 — Eén intaketraject per samenhangende zorgvraag @@ -324,14 +415,14 @@ Niet ieder Nederlands zorgbegrip heeft een exacte Engelse vertaling. Begrippen z ### Eerst ontwerpen -1. AANMELDSIGNAAL, AANMELDINGSTRAJECT, toewijzing en niet-destructieve samenvoeging. -2. ACCEPTATIEBESLUIT en de relatie met intake en ZORGEPISODE. -3. Tijdgebonden programma-, organisatie- en zorgteambetrokkenheid. +1. ~~AANMELDSIGNAAL, AANMELDINGSTRAJECT, toewijzing en niet-destructieve samenvoeging.~~ **Gedaan** (19 juli 2026) — als Referral Submission/Referral Case/Signal-to-Case Assignment/Access Case Consolidation, zie B21–B25 en `../deelmodellen/model-instroom.md`. +2. ~~ACCEPTATIEBESLUIT en de relatie met intake en ZORGEPISODE.~~ **Gedaan** (19 juli 2026), zie B21–B27 en `../deelmodellen/model-instroom.md`. De relatie met het behandeladvies ná de intake blijft apart onderzoek (`../feitenmodellen/feitenmodel-instroom.md` §7 vraag 2). +3. Tijdgebonden programma-, organisatie- en zorgteambetrokkenheid. **Deels gestart:** een minimale, voorlopige hook voor teambetrokkenheid bestaat nu in het instroomdeelgebied (B30, `episode_team_involvement`); het volledige zorgteam-model (leden, rollen, regiebehandelaarschap, bevoegdheid) staat hierdoor als eerstvolgende ronde met concrete urgentie. 4. Eén levend BEHANDELPLAN met immutable snapshots. 5. MDO- en evaluatieworkflows. 6. Bevoegdheidsmatrix per besluittype en teamrol. 7. Versiegebonden BEHANDELVISIEPROFIEL in ADM. -8. Engelse werktermen in `../begrippenlijst-kernmodel.md` reviewen en vóór het logische model definitief bevestigen. +8. Engelse werktermen in `../begrippenlijst-kernmodel.md` reviewen en vóór het logische model definitief bevestigen — voor instroom is dit de eerstvolgende stap (zie hieronder). ### Parallel onderzoeken @@ -341,13 +432,15 @@ Niet ieder Nederlands zorgbegrip heeft een exacte Engelse vertaling. Begrippen z 4. Autorisatie op historische episode- en longitudinale verwijzingen. 5. Concrete typen en governance van longitudinale cliëntinformatie. 6. Profielmigratie wanneer de behandelvisie tijdens een lopende episode wijzigt. +7. **Nieuw (19 juli 2026):** juridische verificatie van de Wvggz/Wmo-Jeugdwet-aannames in B27 — met name de zorgmachtiging-route en de jeugd-ggz-specifieke Jeugdwet-relatie (zie `../deelmodellen/model-instroom.md` §7 punt 3). +8. **Nieuw (19 juli 2026):** mogelijke uitkomsten van het behandeladvies na de intake en de bijbehorende bevoegdheid (`../feitenmodellen/feitenmodel-instroom.md` §7 vraag 2) — geparkeerd sinds sessielog 19 juli. ### Documenten synchroniseren De volgende documenten bevatten nog voorstellen die door dit log geheel of gedeeltelijk zijn achterhaald: - `../deelmodellen/datamodel-discovery.md` -- `../deelmodellen/model-aanmelding.md` +- `../deelmodellen/model-aanmelding.md` — het AANMELDING/VERWIJZING/ZORGEPISODE-deel is vervangen door `../deelmodellen/model-instroom.md`; PERSOON/CLIENT/VERWIJZER/PRAKTIJK_INSTELLING/TOESTEMMING blijven ongewijzigd geldig en worden door `../deelmodellen/model-instroom.md` hergebruikt, niet gedupliceerd. Synchronisatie (secties laten vervallen, verwijzen naar het nieuwe document) is de eerstvolgende stap. - `../deelmodellen/model-screening.md` - `../deelmodellen/model-intake.md` - `../deelmodellen/model-wachtlijst.md` @@ -355,4 +448,4 @@ De volgende documenten bevatten nog voorstellen die door dit log geheel of gedee - `../deelmodellen/model-rapportage.md` - `../entiteitenkaarten/entiteitenkaart-instroom.html` -De entiteitenkaart wordt pas opnieuw gegenereerd nadat de Markdown-deelmodellen zijn herzien. +De entiteitenkaart wordt pas opnieuw gegenereerd nadat de Markdown-deelmodellen zijn herzien — voor instroom is de bron nu `../deelmodellen/model-instroom.md`. -- 2.39.5 From 890704a0f4902eb0223a5822dfaba2e59b1294da Mon Sep 17 00:00:00 2001 From: colinislit Date: Sun, 19 Jul 2026 18:08:43 +0200 Subject: [PATCH 15/19] docs(datamodel): synchroniseer begrippenlijst en model-aanmelding met instroom MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit begrippenlijst-kernmodel.md §3: vervangt de voorlopige werktermen (Inbound Care Signal, Access Assessment Case, Presenting Care Need, Screening Recommendation) door de bevestigde instroom-begrippen uit model-instroom.md (Referral Request/Submission/Case, Professional/Municipal Referral, Legal Mandate, Case Information Request/Withdrawal, Crisis Encounter Note, Case Urgency Assessment). §10 bijgewerkt: opgeloste terminologievragen gemarkeerd, Wvggz/Wmo-Jeugdwet-aannames als nieuw juridisch te bevestigen punt. model-aanmelding.md: AANMELDING/VERWIJZING/VERWIJSDOCUMENT/TOEWIJZING/ ZORGEPISODE (§2.10-§2.13, §2.15) niet-destructief gemarkeerd als vervallen met verwijzing naar de vervangende entiteit in model-instroom.md — tekst blijft als historisch werkdocument staan, consistent met het niet-destructieve patroon dat elders in het datamodel wordt toegepast. PERSOON/CLIENT/CLIENTRELATIE/VERWIJZER/PRAKTIJK_INSTELLING/CLIENT_HUISARTS/ VERZEKERING/TOESTEMMING/CLIENTPORTAAL_ACCOUNT (§2.1-§2.9, §2.14, §2.16) blijven ongewijzigd en behouden hun sectienummers, waar model-instroom.md extern naar verwijst. §7 (open besluitpunten) per punt van een status voorzien, inclusief waar de uiteindelijke beslissing afweek van het advies. Corrigeert ook twee foutieve paden in model-instroom.md (§4 waardelijsten verwezen naar de verkeerde sectie in model-aanmelding.md). --- docs/datamodel/begrippenlijst-kernmodel.md | 185 ++++++++++++------ .../deelmodellen/model-aanmelding.md | 110 +++++++---- docs/datamodel/deelmodellen/model-instroom.md | 6 +- 3 files changed, 200 insertions(+), 101 deletions(-) diff --git a/docs/datamodel/begrippenlijst-kernmodel.md b/docs/datamodel/begrippenlijst-kernmodel.md index 45e95c7..1265ba3 100644 --- a/docs/datamodel/begrippenlijst-kernmodel.md +++ b/docs/datamodel/begrippenlijst-kernmodel.md @@ -1,9 +1,9 @@ # Begrippenlijst kernmodel — Nederlands/Engels -**Status:** versie 0.1, ter inhoudelijke en terminologische review -**Datum:** 18 juli 2026 -**Bron:** `besluiten/besluitenlog-datamodel-2026-07-18.md` -**Terminologieonderzoek:** `onderzoek/onderzoek-engelstalige-epd-terminologie.md` adviseert voor de instroom een driedeling in Referral Request, Referral Submission en Referral Case; nog niet als begrippenbesluit verwerkt +**Status:** versie 0.2 — §3 (instroom) bijgewerkt na de FCO-IM-feitenronde en het entiteitenmodel +**Datum:** 18 juli 2026, §3 bijgewerkt 19 juli 2026 +**Bron:** `besluiten/besluitenlog-datamodel-2026-07-18.md` (B1–B30) +**Terminologieonderzoek:** de driedeling Referral Request/Referral Submission/Referral Case uit `onderzoek/onderzoek-engelstalige-epd-terminologie.md` is verwerkt en bevestigd in `feitenmodellen/feitenmodel-instroom.md` en `deelmodellen/model-instroom.md` **Doel:** één gedeelde betekenis en één Engelse technische naam per kernbegrip, vóór uitwerking van feitzinnen, ERD of SQL ## 1. Gebruik en naamgeving @@ -47,92 +47,145 @@ De instellingsgebonden rol van een persoon voor wie zorg of mogelijke zorg wordt ## 3. Instroom en beoordeling -### Inbound Care Signal — `inbound_care_signal` +Bijgewerkt 19 juli 2026 na de FCO-IM-feitenronde (`feitenmodellen/feitenmodel-instroom.md`) en de entiteiten-/cardinaliteitenafleiding (`deelmodellen/model-instroom.md`, B21–B30). Vervangt de eerdere werktermen `Inbound Care Signal`, `Access Assessment Case`, `Presenting Care Need` en `Screening Recommendation` (zie toelichting per begrip hieronder). -**Nederlandse domeinterm:** aanmeldsignaal -**Status Engelse naam:** bevestigen +### Referral Request — `referral_request` -Eén afzonderlijke binnenkomst bij de instelling, met een eigen bron, tijdstip, documenten en oorspronkelijk geuite zorgvraag. +**Nederlandse domeinterm:** zorgverzoek +**Status Engelse naam:** aanbevolen -**Is niet:** een verwijzing, aanmeldingstraject, intake of geaccepteerd zorgverzoek. Een zelfaanmelding en informatie van een derde kunnen beide een aanmeldsignaal zijn. +Het inhoudelijke verzoek om zorg of beoordeling voor één of meer samenhangende geuite zorgvragen, met een eigen identiteit los van de submission die het aanleverde en los van een eventuele formele verwijzing. Kan afkomstig zijn van een professional, organisatie, cliënt of vertegenwoordiger. -**Terminologienotitie:** `referral` is te smal; `signal` is internationaal minder gangbaar maar dekt wel dat iedere binnenkomst als zelfstandig bronfeit behouden blijft. +**Is niet:** de technische ontvangst van het verzoek (dat is `Referral Submission`), het interne beoordelingstraject (`Referral Case`), of een bewijs dat de zorg is geaccepteerd. Bevat geen aparte `Presenting Care Need`-entiteit — de geuite zorgvraag is een attribuut (`presenting_need_text`) op dit object; die eerdere kandidaat-entiteit is niet doorgezet. -### Access Assessment Case — `access_assessment_case` +**Terminologienotitie:** dit is de derde term uit de driedeling die `Inbound Care Signal`/`Access Assessment Case` verving (zie hieronder). Kan bij crisisaanmeldingen zonder bekende persoon bestaan (B26). + +### Referral Submission — `referral_submission` + +**Nederlandse domeinterm:** afzonderlijke binnenkomst +**Status Engelse naam:** aanbevolen + +Eén afzonderlijke binnenkomst bij de instelling, via één kanaal en op één ontvangstmoment, met eigen bron, tijdstip en documenten. + +**Is niet:** automatisch een nieuw zorgverzoek of aanmeldingstraject; een overschrijfbare actuele versie van eerder ontvangen informatie. + +**Terminologienotitie:** vervangt `Inbound Care Signal` (`inbound_care_signal`, aanmeldsignaal) — dezelfde betekenis, definitieve naam bevestigd na de feitenronde. `Referral` bleek te smal voor deze rol (een zelfaanmelding is ook een submission); `Signal` is internationaal minder gangbaar dan `Submission`. + +### Referral Case — `referral_case` **Nederlandse domeinterm:** aanmeldingstraject -**Status Engelse naam:** bevestigen +**Status Engelse naam:** aanbevolen -Het institutionele beoordelingsproces voor één samenhangende zorgvraag, gevoed door één of meer aanmeldsignalen. +Het institutionele beoordelingsproces voor één samenhangende zorgvraag, gevoed door één of meer submissions en requests. Heeft geen vaste, eenrichtings-statusmachine — de actuele stand wordt afgeleid uit een tijdlijn van gebeurtenissen (B25). **Is niet:** een opname, verwijzing, klinische intake, zorgepisode of financieel traject. -**Terminologienotitie:** `case` duidt hier een behandelbare workflowcase aan, nog geen klinische casus of zorgepisode. +**Terminologienotitie:** vervangt `Access Assessment Case` (`access_assessment_case`) — dezelfde betekenis, definitieve naam bevestigd. `Case` duidt hier een behandelbare workflowcase aan, nog geen klinische casus of zorgepisode. -### Presenting Care Need — `presenting_care_need` +### Professional Referral — `professional_referral` -**Nederlandse domeinterm:** zorgvraag -**Status Engelse naam:** bevestigen - -De door cliënt of bron geuite behoefte, klacht of gewenste ondersteuning waarop de instroombeoordeling en mogelijke zorg zich richten. - -**Is niet:** een diagnose, vastgesteld behandeltekort, bestelling van zorg of FHIR `ServiceRequest`. - -**Open nuance:** bij de verdere modellering moet onderscheid worden gemaakt tussen de oorspronkelijk geuite zorgvraag en de later professioneel beoordeelde zorgbehoefte. - -### Referral — `referral` - -**Nederlandse domeinterm:** verwijzing +**Nederlandse domeinterm:** formele verwijzing **Status Engelse naam:** aanbevolen -Een formele verwijzing door een bevoegde of toegestane bron, inclusief relevante verwijzer, context en geldigheid. +De formele Nederlandse VERWIJZING: een door een toegestane verwijzer uitgegeven object met verwijzer, verwijsdatum, geldigheid en verwijsspecifieke gegevens, gekoppeld aan een `Referral Request`. Kan een eerdere `Professional Referral` op hetzelfde request vervangen bij correctie of aanvulling (B23). -**Is niet:** ieder aanmeldsignaal. Een zelfaanmelding of los aanvullend document is niet automatisch een verwijzing. +**Is niet:** ieder zorgverzoek. Een zelfaanmelding heeft geen `Professional Referral`. Bewijst niet dat zorg al is geaccepteerd. -### Signal-to-Case Assignment — `signal_case_assignment` +**Terminologienotitie:** verfijnt de eerdere bredere term `Referral` (`referral`) — die naam bleek dubbelzinnig zodra `Referral Request`/`Referral Submission`/`Referral Case` als aparte objecten bestonden. `Professional` maakt expliciet dat dit de formele, door een verwijzer uitgegeven verwijzing is, niet het bredere zorgverzoek. -**Nederlandse domeinterm:** toewijzing van aanmeldsignaal aan aanmeldingstraject +### Municipal Care Assignment — `municipal_care_assignment` + +**Nederlandse domeinterm:** gemeentelijke toewijzing +**Status:** bevestigen (juridisch nog niet door een jurist bevestigd, zie B27) + +De gemeentelijke beschikking/toewijzing (Wmo/Jeugdwet, iWmo/iJw 301-bericht) als toegangsticket náást — niet in plaats van — een eventuele `Professional Referral`. + +**Is niet:** een vervanging van de professionele verwijsroute (die bestaat bij Jeugdwet zelfstandig ernaast); bij Wmo het enige toegangsdocument, omdat daar geen professionele verwijsroute bestaat. + +### Legal Mandate — `legal_mandate` + +**Nederlandse domeinterm:** wettelijk mandaat (Wvggz) +**Status:** bevestigen (juridisch nog niet door een jurist bevestigd, zie B27) + +Het wettelijke mandaat bij gedwongen zorg: crisismaatregel of zorgmachtiging. Werkt zelf als bindend besluit; de instelling heeft geen institutionele acceptatiediscretie. + +**Is niet:** een `Care Acceptance Decision` of een vervanging daarvan — een ander soort feit (wettelijke plicht, geen discretionaire beoordeling). Een zorgepisode kan rechtstreeks uit een geldig mandaat ontstaan. + +### Submission-to-Case Assignment — `submission_case_assignment` + +**Nederlandse domeinterm:** toewijzing van submission aan aanmeldingstraject **Status Engelse naam:** aanbevolen -De historiseerbare koppeling waarmee een aanmeldsignaal aan een beoordelingscase wordt toegewezen. +De historiseerbare koppeling waarmee een submission aan een `Referral Case` wordt toegewezen. -**Is niet:** destructieve verplaatsing. Het oorspronkelijke signaal en eerdere toewijzingen blijven bestaan. +**Is niet:** destructieve verplaatsing. De oorspronkelijke submission en eerdere toewijzingen blijven bestaan. -### Access Case Consolidation — `access_case_consolidation` +**Terminologienotitie:** hernoemd van `Signal-to-Case Assignment` (`signal_case_assignment`) — het "signal_"-voorvoegsel kwam nergens anders terug en week af van het "submission_"-patroon; technische correctie bij de tweede reviewronde (19 juli 2026), geen betekenisverandering. + +### Case Consolidation — `case_consolidation` **Nederlandse domeinterm:** logische samenvoeging van aanmeldingstrajecten -**Status Engelse naam:** bevestigen +**Status Engelse naam:** aanbevolen -Een niet-destructieve relatie waarbij één aanmeldingstraject als leidend wordt aangewezen en de oorspronkelijke trajecten, signalen en herkomst behouden blijven. +Een niet-destructieve relatie waarbij één aanmeldingstraject als leidend wordt aangewezen ten opzichte van een ander, overlappend traject; beide behouden hun identiteit en historie. -**Is niet:** database-merge, verwijderen, overschrijven of stil hernummeren. +**Is niet:** database-merge, verwijderen, overschrijven of stil hernummeren. Vereist geen speciale beslisbevoegdheid — een administratieve correctie, geen inhoudelijk zorgbesluit. + +**Terminologienotitie:** hernoemd van `Access Case Consolidation` (`access_case_consolidation`) — het "access_"-voorvoegsel was ongemotiveerd en suggereerde ten onrechte een besluit over zorgtoegang; technische correctie bij de tweede reviewronde (19 juli 2026), geen betekenisverandering. ### Screening — `screening` **Nederlandse domeinterm:** screening **Status Engelse naam:** aanbevolen -Een institutionele beoordelingsstap binnen het aanmeldingstraject waarin informatie wordt verzameld en een inhoudelijk advies kan worden voorbereid. +De verzameling activiteiten (contact, onderzoek, informatie-uitvraag) binnen een `Referral Case` waarmee de beoordeling voor het acceptatiebesluit tot stand komt. -**Is niet:** de formele acceptatie, klinische intake of zorgepisode. - -### Screening Recommendation — `screening_recommendation` - -**Nederlandse domeinterm:** screeningsbesluit / screeningsadvies -**Status Engelse naam:** bevestigen - -De inhoudelijke uitkomst van de screening, bijvoorbeeld geschiktheid, geadviseerde bestemming en urgentie. - -**Is niet:** het formele acceptatiebesluit. De Engelse naam gebruikt bewust `recommendation`, omdat de screening niet altijd besluitvormend is. +**Is niet:** een zelfstandig besluitobject. Screening levert geen apart advies op — het screeningsbesluit **is** het acceptatiebesluit (B21). ### Care Acceptance Decision — `care_acceptance_decision` **Nederlandse domeinterm:** acceptatiebesluit **Status Engelse naam:** aanbevolen -Het formele besluit waarmee een cliënt voor een samenhangende zorgvraag tot het zorgproces wordt toegelaten en een zorgepisode kan ontstaan. +Het formele besluit dat de beoordeling van een `Referral Case` afrondt: draagt zelf de onderliggende beoordelingen (inhoudelijke match, plek, capaciteit), de besluituitkomst (`geaccepteerd`/`afgewezen`), de vervolgroute en, bij afwijzing, de onderbouwing. Kan een eerder besluit van dezelfde case vervangen bij heroverweging of institutionele correctie (B23). -**Is niet:** behandelovereenkomst, behandeltoestemming, opnamebesluit, zorgplicht of toewijzing van verantwoordelijkheid. +**Is niet:** behandelovereenkomst, behandeltoestemming, opnamebesluit, zorgplicht of toewijzing van verantwoordelijkheid. Geen apart, voorafgaand screeningsadvies ernaast (B21) — dat eerdere kandidaat-begrip `Screening Recommendation` (`screening_recommendation`) is niet doorgezet. + +### Case Information Request — `case_information_request` + +**Nederlandse domeinterm:** informatieverzoek +**Status Engelse naam:** aanbevolen + +Een gedateerd, toegeschreven gebeurtenisfeit: wie heeft wanneer welke aanvullende informatie gevraagd bij een `Referral Case`. + +**Is niet:** een besluituitkomst of statusfase — er bestaat op dat moment nog geen `Care Acceptance Decision` (B25). Kan zich op elk moment voordoen, ook ná een eerder besluit tijdens een heroverweging. + +### Case Withdrawal — `case_withdrawal` + +**Nederlandse domeinterm:** cliënt-intrekking +**Status Engelse naam:** aanbevolen + +De registratie dat een cliënt een `Referral Case` intrekt. + +**Is niet:** een `Care Acceptance Decision` — vereist geen beslisbevoegdheid en kan op elk moment plaatsvinden, ook ná een positief besluit (B24). + +### Crisis Encounter Note — `crisis_encounter_note` + +**Nederlandse domeinterm:** crisisnotitie vóór identificatie +**Status:** bevestigen (grotendeels optionele velden, geen wettelijke structuurplicht gevonden, zie B28) + +Gestructureerde vastlegging van crisisgerelateerd handelen (bijvoorbeeld medicatie, risico-inschatting, dwangmaatregel) bij een `Referral Case`, ook vóórdat identificatie of volledige dossiervorming heeft plaatsgevonden. + +**Is niet:** de screening zelf (`Screening` gaat over het beoordelingsproces, niet over klinisch handelen) of een vervanging van de formele Wvggz-dwangregistratie. + +### Case Urgency Assessment — `case_urgency_assessment` + +**Nederlandse domeinterm:** urgentiebeoordeling +**Status Engelse naam:** aanbevolen + +Een herhaalbare beoordeling van de urgentie van een `Referral Case`, vastgesteld tijdens screening/triage en later aan te passen door het intake-team of in een MDO (B29). + +**Is niet:** een vast statusveld — de meest recente beoordeling geldt, zonder vervangt-relatie (lagere inzet dan een acceptatiebesluit). ## 4. Intake @@ -236,6 +289,8 @@ De tijdgebonden betrokkenheid van een organisatorische eenheid bij een zorgepiso ## 6. Zorgteam, rol en bevoegdheid +Dit volledige begrippenkader wacht nog op een eigen feitenronde (besluitenlog §10 punt 3). Vooruitlopend daarop bestaat sinds 19 juli 2026 een bewust minimale, voorlopige hook — `episode_team_involvement` (`deelmodellen/model-instroom.md` §2.20) — die alleen vastlegt dát een team bij een episode betrokken is, zonder rollen, bevoegdheid of individueel lidmaatschap. Deze hook wordt door onderstaand begrippenkader vervangen of geabsorbeerd zodra die ronde plaatsvindt; hij krijgt hier bewust geen eigen kernbegrip-entry om verwarring met `Episode Team Assignment` te voorkomen (B30). + ### Episode Clinical Team — `episode_clinical_team` **Nederlandse domeinterm:** zorgteam rond de zorgepisode @@ -467,18 +522,26 @@ Expliciet geselecteerde en getypeerde klinische informatie met bron, bronepisode ## 10. Open terminologiebesluiten +**Opgelost bij de instroom-feitenronde (19 juli 2026), zie §3:** + +- `inbound_care_signal` → vervangen door `referral_submission`; +- `access_assessment_case` → vervangen door `referral_case`; +- `presenting_care_need` → geen aparte entiteit doorgezet, nu attribuut op `referral_request`; +- `access_case_consolidation` → hernoemd naar `case_consolidation`, naam bevestigd; +- `screening_recommendation` → vervallen, geen apart besluitobject naast `care_acceptance_decision` (B21). + De betekenis van onderstaande begrippen staat vast, maar de Engelse naam moet nog expliciet worden bevestigd: -1. `inbound_care_signal` — aanmeldsignaal; -2. `access_assessment_case` — aanmeldingstraject; -3. `presenting_care_need` — zorgvraag; -4. `access_case_consolidation` — logische samenvoeging; -5. `screening_recommendation` — screeningsbesluit/-advies; -6. `clinical_intake_assessment` — intake als proces; -7. `funding_case` — financieel traject; -8. `lead_clinician_role` — regiebehandelaar; -9. `care_goal` — behandel-/zorgdoel; -10. `care_planning_profile` — behandelvisieprofiel; -11. `cross_episode_clinical_concept` — voorlopige naam voor de longitudinale architectuurlaag. +1. `clinical_intake_assessment` — intake als proces; +2. `funding_case` — financieel traject; +3. `lead_clinician_role` — regiebehandelaar; +4. `care_goal` — behandel-/zorgdoel; +5. `care_planning_profile` — behandelvisieprofiel; +6. `cross_episode_clinical_concept` — voorlopige naam voor de longitudinale architectuurlaag. + +Daarnaast, uit de instroom-ronde, nog juridisch te bevestigen (niet een naamskwestie maar een inhoudelijke aanname, zie B27 en `deelmodellen/model-instroom.md` §7 punt 3): + +7. `municipal_care_assignment` — gemeentelijke toewijzing; +8. `legal_mandate` — wettelijk mandaat (Wvggz). Deze namen worden vóór het logische ER-model één voor één beoordeeld. Tot dat moment zijn ze bruikbaar als werktermen, niet als definitieve database-identifiers. diff --git a/docs/datamodel/deelmodellen/model-aanmelding.md b/docs/datamodel/deelmodellen/model-aanmelding.md index bcf3fb9..19a69c1 100644 --- a/docs/datamodel/deelmodellen/model-aanmelding.md +++ b/docs/datamodel/deelmodellen/model-aanmelding.md @@ -1,11 +1,11 @@ # Datamodelvoorstel — Aanmelding & instroombasis -**Status:** herziening nodig — structureel deels achterhaald door `../besluiten/besluitenlog-datamodel-2026-07-18.md` -**Datum:** 18 juli 2026 -**Deelgebied:** PERSOON, CLIENT, VERWIJZER, PRAKTIJK_INSTELLING, AANMELDING, ZORGEPISODE, CLIENTPORTAAL_ACCOUNT + aanvullingen voor een volwassen instroommodel +**Status:** gesynchroniseerd 19 juli 2026 — AANMELDING/VERWIJZING/VERWIJSDOCUMENT/TOEWIJZING/ZORGEPISODE (§2.10–§2.13, §2.15) zijn vervangen door `model-instroom.md`; PERSOON/CLIENT/CLIENTRELATIE/VERWIJZER/PRAKTIJK_INSTELLING/CLIENT_HUISARTS/VERZEKERING/TOESTEMMING/CLIENTPORTAAL_ACCOUNT (§2.1–§2.9, §2.14, §2.16) blijven ongewijzigd geldig en worden door `model-instroom.md` hergebruikt, niet gedupliceerd +**Datum:** 18 juli 2026, gesynchroniseerd 19 juli 2026 +**Deelgebied (na sync):** PERSOON, CLIENT, CLIENTRELATIE, VERWIJZER, PRAKTIJK_INSTELLING, CLIENT_HUISARTS, VERZEKERING, TOESTEMMING, CLIENTPORTAAL_ACCOUNT **Bronnen:** `datamodel-discovery.md`, onderzoek-proces, onderzoek-leveranciers, onderzoek-standaarden, onderzoek-rapportage (details in §8) -> **Let op:** het besluitenlog splitst de huidige AANMELDING in AANMELDSIGNAAL en AANMELDINGSTRAJECT. De ZORGEPISODE ontstaat bij formele acceptatie en heeft een onafhankelijke levenscyclus. Gebruik de huidige entiteiten, cardinaliteiten en statusmachines daarom nog niet als basis voor SQL. +> **Let op:** dit document behandelde oorspronkelijk ook de instroomflow (AANMELDING, VERWIJZING, ZORGEPISODE). Die deelgebieden zijn na de FCO-IM-feitenronde van 19 juli 2026 volledig herzien en staan nu in `model-instroom.md` (feitzinnen: `../feitenmodellen/feitenmodel-instroom.md`; besluiten: B21–B30 in `../besluiten/besluitenlog-datamodel-2026-07-18.md`). De secties hieronder die nog AANMELDING/VERWIJZING/ZORGEPISODE beschrijven zijn behouden als historisch werkdocument, niet als actuele bron — gebruik ze niet als basis voor SQL. **Conventies (gelden voor alle entiteiten, niet per entiteit herhaald):** - Elke entiteit heeft `id` (UUID, stabiel — spelregel 3.1 #5), `created_at`, `updated_at`, `deleted_at` (soft delete — spelregel 3.1 #4) en auditvelden conform spelregel 3.1 #3. @@ -44,7 +44,9 @@ 15. De verzekering van Jan de Vries is op 14 juli 2026 geverifieerd via een COV-controle. 16. Bij de aanmelding van 14 juli 2026 onder wettelijk kader "Jeugdwet" hoort gemeentelijke toewijzing 301-20260714-001 van gemeente Utrecht (gemeentecode 0344), met periode 1 augustus 2026 t/m 31 januari 2027. *(alleen bij kader Jeugdwet/Wmo — iJw/iWmo, onderzoek-standaarden §7)* -### Verwijzing (verrijking van de aanmelding) +### Verwijzing (verrijking van de aanmelding) — **vervallen, zie `model-instroom.md`** + +*(Feitzinnen 17–25 hieronder zijn vervangen door `../feitenmodellen/feitenmodel-instroom.md` en de entiteiten in `model-instroom.md` — Professional Referral, Municipal Care Assignment, Referral Case. Behouden als historisch werkdocument.)* 17. *(verfijnt §5.1 feitzin 8)* Bij de aanmelding van 14 juli 2026 hoort een verwijzing, afgegeven op 1 juli 2026 door verwijzer P. Pietersen. *(verwijsdatum ≠ aanmelddatum; 275-dagentoets en per 2026 verplicht op de declaratie — onderzoek-proces §2.3/§2.10)* 18. De verwijzing vermeldt echelon "gespecialiseerde ggz". @@ -54,7 +56,7 @@ 22. De aanmelding van 14 juli 2026 volgt doorverwijsroute "doorverwijzing tussen ggz-aanbieders". *(optioneel; alleen bij één van de vijf erkende routes — onderzoek-proces §2.7)* 23. Voor de aanmelding van 15 juli 2026 zonder verwijzing (crisis) is de huisarts op 20 juli 2026 geïnformeerd. *(60-dagentermijn — onderzoek-proces §2.6)* -### Aanmelding (aanvullingen) +### Aanmelding (aanvullingen) — **vervallen, zie `model-instroom.md`** 24. De aanmelding van 14 juli 2026 is ontvangen via aanmeldkanaal "ZorgDomein". 25. *(verfijnt §5.1 besluit 5)* De aanmelding van 14 juli 2026 heeft uitkomst "intake", vastgesteld op 17 juli 2026. *(uitkomst + uitkomstdatum als aparte feiten naast de status)* @@ -65,7 +67,9 @@ 27. Cliënt Jan de Vries heeft op 1 september 2026 de toestemming van type "vermelding DSM-hoofdgroep op factuur" geweigerd. 28. Cliënt Jan de Vries heeft de toestemming van type "correspondentie met huisarts/verwijzer" op 1 december 2026 ingetrokken. -### Zorgepisode +### Zorgepisode — **vervallen, zie `model-instroom.md`** + +*(Feitzinnen 29–30 zijn achterhaald: de episode ontstaat sinds B22/B23 bij het acceptatiebesluit zelf, niet bij uitkomst "intake" — zie `model-instroom.md` §2.18 `clinical_care_episode`.)* 29. Voor cliënt Jan de Vries is op 17 juli 2026 een zorgepisode gestart, voortkomend uit de aanmelding van 14 juli 2026. *(ontstaat bij uitkomst "intake" — zie §5 en besluitpunt 1)* 30. De zorgepisode van Jan de Vries is op 15 maart 2027 afgesloten met reden "behandeling afgerond". @@ -216,7 +220,9 @@ **Uniciteit:** max één actuele verzekering per cliënt. Nudge: "Zvw-aanmelding zonder actuele COV-controle". Wlz-indicatie en forensische titel: declaratie-ronde (besluitpunt 7). -### 2.10 AANMELDING +### 2.10 AANMELDING — **vervallen, zie `model-instroom.md`** + +*(Vervangen door `referral_request` en `referral_case` in `model-instroom.md` §2.1, §2.6 — inclusief de daar herstelde velden `zpm_verwijstype`, `huisarts_geinformeerd_op` en `wettelijk_kader`. Behouden als historisch werkdocument; de waardelijsten `aanmeldkanaal`, `echelon`, `zpm_verwijstype` en `wettelijk_kader` in §4 hieronder blijven wel in gebruik.)* **Doel:** de binnenkomst-*gebeurtenis* (discovery §5.1 besluit 9). Draagt aanmelddatum (wettelijk controleerbaar gegeven — onderzoek-proces §2.3), kanaal, kader, hulpvraag, status en uitkomst. Screening en aanmeldwachttijd hangen hieraan (§5.2, §5.3). @@ -237,7 +243,9 @@ **Uniciteit:** geen harde beperking op parallelle aanmeldingen; "max één actieve aanmelding per cliënt" is een aan/uit-zetbare bedrijfsregel (§5.0 besluit 5) — in TIP/Nudge, niet in schema. -### 2.11 VERWIJZING *(nieuw — besluitpunt 2)* +### 2.11 VERWIJZING *(nieuw — besluitpunt 2)* — **vervallen, zie `model-instroom.md`** + +*(Vervangen door `professional_referral` in `model-instroom.md` §2.14, inclusief het herstelde `heraanmelding`-veld en de vervangt-relatie voor correctie/aanvulling — zie B23.)* **Doel:** de verwijzing als eigen registratie-object bij de aanmelding. Verfijnt §5.1 feitzin 8: "ontvangen via verwijzer X" blijft waar, maar de verwijzing draagt eigen wettelijk relevante feiten die niet op de aanmelding of de verwijzer thuishoren: **verwijsdatum** (275-dagentoets; per 1-1-2026 verplicht op elke declaratie), echelon, DSM-vermoeden, heraanmelding-vlag (onderzoek-proces §2, onderzoek-standaarden §8). Een zelfaanmelding heeft géén verwijzing. @@ -253,7 +261,9 @@ **Uniciteit:** max één verwijzing per aanmelding. Geldigheidstoets (aanmelddatum − verwijsdatum ≤ 275 dagen) is een nudge, geen constraint (onvolledige/late verwijzing mag — inspanningsverplichting, onderzoek-proces §2.5). -### 2.12 VERWIJSDOCUMENT +### 2.12 VERWIJSDOCUMENT — **vervallen, zie `model-instroom.md`** + +*(Vervangen door `submission_document` in `model-instroom.md` §2.3 — nu gekoppeld aan de submission die het document aanleverde, niet aan de aanmelding.)* **Doel:** ontvangen documenten bij de aanmelding, getypeerd (verwijsbrief, beschikking, …) — discovery §5.1 besluit 7. @@ -266,7 +276,9 @@ **Uniciteit:** geen (meerdere documenten per aanmelding toegestaan). -### 2.13 TOEWIJZING *(nieuw — gemeentelijk kader)* +### 2.13 TOEWIJZING *(nieuw — gemeentelijk kader)* — **vervallen, zie `model-instroom.md`** + +*(Vervangen door `municipal_care_assignment` in `model-instroom.md` §2.15 — zelfde minimale opzet, nu expliciet náást in plaats van in plaats van `professional_referral` gemodelleerd, met een vervangt-relatie voor herziene 301-berichten. Juridisch nog niet door een jurist bevestigd, zie B27.)* **Doel:** bij kader Jeugdwet/Wmo is de "verwijzing" feitelijk een gemeentelijke beschikking/toewijzing met eigen sleutelgegevens (iWmo/iJw 301-bericht) — meer structuur dan een document alleen (onderzoek-standaarden §7). Minimale variant nu; productcodes/volume volgen in de declaratie-ronde (besluitpunt 6). @@ -300,7 +312,9 @@ **Uniciteit:** max één actuele (niet-ingetrokken) rij per (client, toestemmingstype, scope). Intrekken = nieuw statusfeit, historie blijft (append-only audit). -### 2.15 ZORGEPISODE +### 2.15 ZORGEPISODE — **vervallen, zie `model-instroom.md`** + +*(Vervangen door `clinical_care_episode` in `model-instroom.md` §2.18 — belangrijkste wijziging: ontstaat bij het acceptatiebesluit zelf (of een Wvggz-mandaat), niet meer bij uitkomst "intake". Alleen ontstaan/einde zijn daar uitgewerkt; het volledige episodemodel — programma-/organisatiebetrokkenheid, zorgteam — blijft een apart deelgebied.)* **Doel:** de periode van zorg (discovery §5.1 besluit 9). Draagt intakes, diagnoses, behandelplannen, behandelwachttijd, zorgvraagtypering (latere ronde). Klinisch object, **niet** het ZPM-zorgtraject — verwant, gekoppeld, geen 1-op-1 (onderzoek-standaarden §6.1; onderzoek-leveranciers §2.3). @@ -331,6 +345,8 @@ ## 3. Relaties met cardinaliteit +**Geldig (PERSOON/CLIENT-laag):** + | Van | Naar | Cardinaliteit | Toelichting | |---|---|---|---| | PERSOON | ADRES | 1 — 0..n | max 1 actueel per adrestype | @@ -342,6 +358,16 @@ | CLIENT | CLIENT_HUISARTS | 1 — 0..n | max 1 actueel | | CLIENT_HUISARTS | VERWIJZER / PRAKTIJK_INSTELLING | — 0..1 / 0..1 | minstens één gevuld | | CLIENT | VERZEKERING | 1 — 0..n | max 1 actueel | +| CLIENT | TOESTEMMING | 1 — 0..n | | +| CLIENT | CLIENTPORTAAL_ACCOUNT | 1 — 0..1 | | + +**Vervallen (AANMELDING/VERWIJZING/VERWIJSDOCUMENT/TOEWIJZING/ZORGEPISODE) — +zie `model-instroom.md` §3 voor de actuele cardinaliteitentabel +van `referral_request`/`referral_submission`/`referral_case`/ +`professional_referral`/`municipal_care_assignment`/`clinical_care_episode`:** + +| Van | Naar | Cardinaliteit | Toelichting | +|---|---|---|---| | CLIENT | AANMELDING | 1 — 0..n | episodisch (§5.0 besluit 2) | | AANMELDING | VERWIJZING | 1 — 0..1 | zelfaanmelding: geen | | VERWIJZING | VERWIJZER | 0..n — 1 | | @@ -349,10 +375,10 @@ | AANMELDING | TOEWIJZING | 1 — 0..n | alleen kader Jeugdwet/Wmo | | AANMELDING | ZORGEPISODE | 1 — 0..1 | alleen bij uitkomst "intake" | | CLIENT | ZORGEPISODE | 1 — 0..n | | -| CLIENT | TOESTEMMING | 1 — 0..n | | -| CLIENT | CLIENTPORTAAL_ACCOUNT | 1 — 0..1 | | -**Naar andere deelgebieden:** +**Naar andere deelgebieden** *(AANMELDING/ZORGEPISODE hieronder zijn de oude +ankers; lees deze als `referral_case`/`clinical_care_episode` totdat +screening/wachtlijst/intake/diagnose/behandelplan zelf zijn gesynchroniseerd)*: | Van | Naar (deelgebied) | Cardinaliteit | |---|---|---| @@ -372,6 +398,8 @@ Alle lijsten volgen het conventie-patroon (code, omschrijving, externe code, geldigheid). Startwaarden: +*(Nummering ongewijzigd gelaten — `model-instroom.md` §4 verwijst naar 12, 17 en 18 hieronder. Items 13–16, 19, 23 zijn vervallen ten gunste van waardelijsten in `model-instroom.md`; zie annotaties per item.)* + 1. **geslacht** — man, vrouw, anders, onbekend *(externe code: HL7 AdministrativeGender)* 2. **genderidentiteit** — man, vrouw, non-binair, anders, zegt_het_niet *(zib Patient v4.3)* 3. **adrestype** — woonadres, postadres, tijdelijk_verblijf @@ -397,24 +425,26 @@ Alle lijsten volgen het conventie-patroon (code, omschrijving, externe code, gel 11. **praktijk_soort** — huisartsenpraktijk, ziekenhuis, ggz_instelling, gemeente, arbodienst, overig 12. **wettelijk_kader** — met attribuut `verwijsnudge_severity` (§5.1 besluit 7): zvw (blokkade), jeugdwet (signaal), wmo (signaal), wlz (waarschuwing), forensisch (waarschuwing) *(severity-startwaarden te bevestigen in de nudge-ronde; NB bij Zvw zonder spoed/Wvggz is ontbrekende verwijzing feitelijk declaratie-blokkerend — onderzoek-proces §10.3)* -13. **aanmeldkanaal** — zorgdomein, brief_post, e_mail, telefonisch, clientportaal, crisis, intern, overig -14. **aanmelding_status** — nieuw, in_screening, besloten *(§5.1 besluit 5)* -15. **aanmelding_uitkomst** — intake, afgewezen, doorverwezen, wachtlijst *(§5.1 besluit 5)* -16. **verwijsdocument_type** — verwijsbrief, beschikking, wlz_indicatiebesluit, huisartsmelding_60dagen, medische_verklaring_wvggz, overig *(§5.1 besluit 7, uitgebreid)* -17. **echelon** — gb_ggz, g_ggz, onbekend -18. **zpm_verwijstype** — 01 t/m 07 conform ZPM-veldafspraken (externe code = Vektis/ZPM-code; onderzoek-standaarden §6.3): 01 verwijzing_aanwezig, 02 doorverwijzing_regiebehandelaar, 03 geen_verwijzing_verlate_correspondentie, 04 geen_verwijzing_correspondentie_niet_toegestaan, 05 geen_verwijzing_niet_declarabel, 06 geen_verwijzing_andere_grond_fz, 07 verwijzing_zonder_agb -19. **doorverwijsroute** — justitieel_traject, einde_wlz_indicatie, overgang_jeugdwet, vervolg_acute_ggz, ggz_naar_ggz *(de vijf erkende routes; moet uit het dossier blijken — onderzoek-proces §2.7)* +13. **aanmeldkanaal** — zorgdomein, brief_post, e_mail, telefonisch, clientportaal, crisis, intern, overig *(vervallen — komt terug als `submission_channel` in `model-instroom.md` §4, met vergelijkbare waarden)* +14. **aanmelding_status** — nieuw, in_screening, besloten *(vervallen — `referral_case` heeft geen statusveld meer, zie B25 en `model-instroom.md` §5)* +15. **aanmelding_uitkomst** — intake, afgewezen, doorverwezen, wachtlijst *(vervallen — vervangen door de gesplitste `decision_outcome`/`follow_up_route` in `model-instroom.md` §4, zie B22)* +16. **verwijsdocument_type** — verwijsbrief, beschikking, wlz_indicatiebesluit, huisartsmelding_60dagen, medische_verklaring_wvggz, overig *(vervallen — komt terug als `document_type` in `model-instroom.md` §4; de Wvggz-waarde hoort inmiddels bij `legal_mandate.medical_statement_reference`)* +17. **echelon** — gb_ggz, g_ggz, onbekend *(blijft in gebruik — hergebruikt door `professional_referral` in `model-instroom.md`)* +18. **zpm_verwijstype** — 01 t/m 07 conform ZPM-veldafspraken (externe code = Vektis/ZPM-code; onderzoek-standaarden §6.3): 01 verwijzing_aanwezig, 02 doorverwijzing_regiebehandelaar, 03 geen_verwijzing_verlate_correspondentie, 04 geen_verwijzing_correspondentie_niet_toegestaan, 05 geen_verwijzing_niet_declarabel, 06 geen_verwijzing_andere_grond_fz, 07 verwijzing_zonder_agb *(blijft in gebruik — hergebruikt door `referral_case.zpm_verwijstype` in `model-instroom.md`)* +19. **doorverwijsroute** — justitieel_traject, einde_wlz_indicatie, overgang_jeugdwet, vervolg_acute_ggz, ggz_naar_ggz *(de vijf erkende routes; moet uit het dossier blijken — onderzoek-proces §2.7)* **— nog niet geïntegreerd in `model-instroom.md`.** Dit is reële, niet-gedekte inhoud: `model-instroom.md` heeft alleen de grovere `follow_up_route`-waarde `doorverwijzen`, niet welke van de vijf erkende routes. Op te pakken bij de volgende instroom-ronde, niet stilzwijgend laten vervallen. 20. **toestemming_type** — met attribuut `grondslag` (tekst): correspondentie_huisarts_verwijzer (WGBO/verwijsafspraken), dsm_hoofdgroep_op_factuur (Stcrt. 2025-11955, opt-in), privacyverklaring_zorgvraagtypering (NZa), gegevensdeling_derden (AVG), inzage_naasten (WGBO) 21. **toestemming_status** — verleend, geweigerd, ingetrokken 22. **toestemming_wijze** — mondeling, schriftelijk, portaal -23. **episode_status** — lopend, afgesloten -24. **episode_einde_reden** — behandeling_afgerond, doorverwezen, client_beeindigt, geen_contact, overleden, overig *(startlijst; mapping op iStandaarden-redenen in de declaratie-ronde)* +23. **episode_status** — lopend, afgesloten *(vervallen — `clinical_care_episode` heeft geen statusveld, status volgt uit `ended_at`/`end_reason`, zie `model-instroom.md` §2.18)* +24. **episode_einde_reden** — behandeling_afgerond, doorverwezen, client_beeindigt, geen_contact, overleden, overig *(startlijst; mapping op iStandaarden-redenen in de declaratie-ronde)* *(komt terug als `episode_end_reason` in `model-instroom.md` §4, aangevuld met `ingetrokken_door_client`/`acceptatiebesluit_herzien`, zie B24)* --- ## 5. Statusmachine -### AANMELDING +### AANMELDING — **vervallen, zie `model-instroom.md`** + +*(`referral_case` heeft bewust geen statusveld meer — de actuele stand wordt afgeleid uit een gebeurtenistijdlijn, zie B25 en `model-instroom.md` §1/§5. Behouden als historisch werkdocument.)* Statussen: `nieuw` → `in_screening` → `besloten`. Flexibel, geen eenrichtingsflow (§5.1 besluit 5). @@ -429,7 +459,9 @@ Regels in het model (spelregel 3.1 #7/#9): check-constraint "status = besloten **Wie mag zetten: rollenronde** (§5.1 besluit 6). Kandidaat-inperking om daar te toetsen: `besloten` alleen door een rol met indicatiebevoegdheid (LKS: indicerende rol regiebehandelaar). -### ZORGEPISODE +### ZORGEPISODE — **vervallen, zie `model-instroom.md`** + +*(`clinical_care_episode` ontstaat bij het acceptatiebesluit zelf — ook tijdens de intakewachtlijst — niet meer bij uitkomst "intake"; zie B22 en `model-instroom.md` §2.18. Behouden als historisch werkdocument.)* Statussen: `lopend` → `afgesloten`. @@ -442,12 +474,14 @@ Statussen: `lopend` → `afgesloten`. ### Overige entiteiten -PERSOON, CLIENT, VERWIJZER, PRAKTIJK_INSTELLING, VERWIJZING, TOEWIJZING, CLIENT_HUISARTS, VERZEKERING: geen statusmachine — levenscyclus via geldigheidsperioden en soft delete. TOESTEMMING: `verleend`/`geweigerd` → `ingetrokken` (eenrichting; nieuwe toestemming = nieuwe rij). CLIENTPORTAAL_ACCOUNT: statusmachine in de auth/ADM-ronde. +PERSOON, CLIENT, VERWIJZER, PRAKTIJK_INSTELLING, CLIENT_HUISARTS, VERZEKERING: geen statusmachine — levenscyclus via geldigheidsperioden en soft delete. TOESTEMMING: `verleend`/`geweigerd` → `ingetrokken` (eenrichting; nieuwe toestemming = nieuwe rij). CLIENTPORTAAL_ACCOUNT: statusmachine in de auth/ADM-ronde. --- ## 6. ECD/TIP-eigenaarschap en events richting TIP +> **Vervallen voor het instroomdeel, nog niet opnieuw uitgewerkt.** De events hieronder (`aanmelding_*`, `verwijzing_*`, `toewijzing_*`, `zorgepisode_*`) verwijzen naar entiteiten die niet meer bestaan. `model-instroom.md` bevat nog geen TIP-event-ontwerp — dat vereist een eigen ontwerpstap (welke gebeurtenis uit de nieuwe tijdlijn-aanpak een TIP-event triggert), niet alleen een naamsvervanging. Behouden als historisch werkdocument en als checklist van wat opnieuw moet worden doordacht. De rijen voor CLIENT/CLIENTRELATIE/CLIENT_HUISARTS/TOESTEMMING blijven wel geldig. + **Eigenaarschap:** alle entiteiten in dit deelgebied zijn **leidend in het ECD** (klinische/administratieve feiten — discovery §3.3). TIP houdt de proces-state: screeningstaken, termijnbewaking, wachtlijst-nudges, "max één actieve aanmelding"-bedrijfsregel. **Events naar TIP** (mutatie-events, zelfde mechanisme als her-embedding — §3.3 koppelafspraak; payload bevat UUID + content-hash, **nooit BSN** — spelregel 3.1 #6): @@ -473,16 +507,18 @@ TIP-snapshots van deze data zijn doelgebonden auditkopieën met herkomst (afstem ## 7. Open besluitpunten voor Colin -1. **Ontstaansmoment ZORGEPISODE — ter bekrachtiging.** Voorstel: episode ontstaat bij uitkomst "intake", niet bij "wachtlijst" (onderbouwing §5). **Advies: bekrachtigen** — alle bronnen (LKS-verantwoordelijkheidsoverdracht, NZa-wachttijddefinities) wijzen dezelfde kant op, en de aanmeldwachtlijst hangt toch al aan de AANMELDING. -2. **VERWIJZING als eigen entiteit** tussen AANMELDING en VERWIJZER (verwijsdatum, echelon, DSM-vermoeden, heraanmelding). **Advies: ja** — de verwijsdatum is per 2026 verplicht op elke declaratie en de 275-dagentoets vereist verwijsdatum ≠ aanmelddatum; dat hoort niet als los veld op de aanmelding (zelfaanmelding heeft er geen) en niet op de verwijzer (die verwijst vaker). -3. **Vaste huisarts via hergebruik van VERWIJZER/PRAKTIJK_INSTELLING** (CLIENT_HUISARTS verwijst ernaar) of een aparte generalisatie EXTERNE_ZORGVERLENER. **Advies: hergebruik nu** — een huisarts is per definitie een potentiële verwijzer; generaliseren pas als er meer externe rollen bijkomen (ketenpartners, apotheek). Semantische scheefheid ("verwijzer die nooit verwees") accepteren als bekende schuld. -4. **TOESTEMMING nu al als generieke entiteit opnemen** (i.p.v. uitstellen naar een latere ronde zoals onderzoek-standaarden §9.5 suggereert). **Advies: nu opnemen met kleine startwaardelijst** — verwijstype 04 en de intakebrief maken toestemming al in de instroomflow nodig; uitstellen betekent losse vlaggen die later gemigreerd moeten worden. -5. **Echelon op twee plekken:** bron-echelon op VERWIJZING én actueel echelon op ZORGEPISODE (op-/afschalen binnen één aanbieder is geen doorverwijzing). **Advies: beide, episode-veld optioneel** — nodig voor wachttijd-uitsplitsing en factuurinhoud (g-ggz vs gb-ggz). -6. **TOEWIJZING minimaal nu** (gemeente, nummer, periode) en productcategorie/-code/volume in de declaratie-ronde. **Advies: akkoord met minimale variant** — het toewijzingsnummer is de sleutel die alle latere iWmo/iJw-berichten nodig hebben; de rest is declaratie-detail. -7. **Financieringsdetail Wlz/forensisch** (indicatiebesluit, strafrechtelijke titel) doorschuiven naar de declaratie-ronde; nu alleen VERZEKERING (Zvw) en TOEWIJZING (gemeentelijk). **Advies: doorschuiven** — het wettelijk kader zelf staat al op de aanmelding; de bronnen geven voor Wlz/fz nog te weinig structuurzekerheid. -8. **Terugval binnen 1 jaar:** nieuwe ZORGEPISODE met hergebruik van het ZPM-zorgtrajectnummer, of heropening van de oude episode? **Advies: nieuwe episode** — klinisch is het een nieuwe zorgperiode; het trajectnummer-hergebruik (NZa-regel) is een declaratie-koppeling, geen reden om episodes samen te smelten. Definitief te maken in de declaratie-ronde (episode ↔ zorgtraject niet 1-op-1). -9. **Huisarts-informeren als attribuut** (`huisarts_geinformeerd_op` op AANMELDING) of als onderdeel van een toekomstige CORRESPONDENTIE-entiteit (intakebrief, beloopsbrief, afrondingsbrief). **Advies: attribuut nu, CORRESPONDENTIE-entiteit in de rapportage-ronde** — de 60-dagentermijn is een hard wettelijk feit dat nu al een nudge nodig heeft; de brievenstroom is een groter onderwerp dat een eigen ronde verdient (onderzoek-proces §10.3 verrijking 9). -10. **Startwaarden `verwijsnudge_severity` per wettelijk kader** (waardelijst 12): bij Zvw is ontbrekende verwijzing zonder spoed/Wvggz-grond feitelijk declaratie-blokkerend — is `blokkade` daar de juiste severity, en welke voor Wlz/forensisch? **Advies: vaststellen in de nudge-/declaratie-ronde**, waardelijst-attribuut staat er klaar voor. +**Status per punt na de instroom-sync (19 juli 2026):** + +1. **Ontstaansmoment ZORGEPISODE.** **Herzien, niet bekrachtigd zoals hier geadviseerd.** De uiteindelijke beslissing (B22) is dat de episode ontstaat bij het acceptatiebesluit zelf, óók bij vervolgroute intakewachtlijst — niet pas bij uitkomst "intake" zoals hier geadviseerd. Zie `model-instroom.md` §2.18. +2. **VERWIJZING als eigen entiteit.** **Bevestigd zoals geadviseerd**, nu `professional_referral` (`model-instroom.md` §2.14), met als aanvulling een vervangt-relatie voor correctie/aanvulling (B23) die hier nog niet was voorzien. +3. **Vaste huisarts via hergebruik van VERWIJZER/PRAKTIJK_INSTELLING.** **Al verwerkt** — CLIENT_HUISARTS (§2.8) gebruikt deze opzet al, geen open vraag meer. Blijft ongewijzigd bij de sync. +4. **TOESTEMMING nu al als generieke entiteit.** **Al verwerkt** — TOESTEMMING (§2.14) bestaat al met deze opzet, geen open vraag meer. Blijft ongewijzigd bij de sync; `model-instroom.md` hergebruikt deze entiteit voor correspondentietoestemming. +5. **Echelon op twee plekken.** **Deels opgelost.** Bron-echelon staat op `professional_referral.echelon`. Een "actueel echelon" op de episode zelf (voor op-/afschalen na de instroom) is niet meegenomen — `clinical_care_episode` in `model-instroom.md` is bewust beperkt tot ontstaan/einde; dit hoort bij het bredere, nog te ontwerpen episodemodel. +6. **TOEWIJZING minimaal nu.** **Verder uitgewerkt dan hier geadviseerd.** `municipal_care_assignment` (`model-instroom.md` §2.15) bevat, op basis van juridisch onderzoek naar het WMO301/iJw301-bericht, al productcategorie/-code/volume/eenheid — verder dan de hier voorgestelde minimale variant. +7. **Financieringsdetail Wlz/forensisch.** **Nog steeds open** — niet opgepakt in de instroom-ronde. `wettelijk_kader` kent de waarden wlz/forensisch al (waardelijst 12), maar een indicatiebesluit- of titel-registratie ontbreekt nog. +8. **Terugval binnen 1 jaar.** **Bevestigd (nieuwe episode), met een aanvulling.** `possible_continuation_of_episode_id` (`model-instroom.md` §2.18) legt optioneel een zorginhoudelijke continuïteitsrelatie tussen de oude en nieuwe episode, expliciet **geen** autoritatieve trajectnummer-toets — die blijft, zoals hier al voorzien, bij de declaratie-ronde. +9. **Huisarts-informeren als attribuut.** **Bevestigd zoals geadviseerd**, nu op `referral_case.huisarts_geinformeerd_op` (`model-instroom.md` §2.6) in plaats van op AANMELDING. +10. **Startwaarden `verwijsnudge_severity` per wettelijk kader** (waardelijst 12): bij Zvw is ontbrekende verwijzing zonder spoed/Wvggz-grond feitelijk declaratie-blokkerend — is `blokkade` daar de juiste severity, en welke voor Wlz/forensisch? **Nog steeds open** — niet opgepakt in de instroom-ronde; **advies blijft: vaststellen in de nudge-/declaratie-ronde**, waardelijst-attribuut staat er klaar voor. --- diff --git a/docs/datamodel/deelmodellen/model-instroom.md b/docs/datamodel/deelmodellen/model-instroom.md index 611c41d..b3007b0 100644 --- a/docs/datamodel/deelmodellen/model-instroom.md +++ b/docs/datamodel/deelmodellen/model-instroom.md @@ -594,9 +594,9 @@ juli 2026, zie §9). | `decision_outcome` | geaccepteerd, afgewezen | | `follow_up_route` | intake_direct, intakewachtlijst, spoedroute, doorverwijzen, case_afsluiten | | `episode_end_reason` | ingetrokken_door_client, acceptatiebesluit_herzien, *(overige waarden: later deelgebied)* | -| `echelon` | over te nemen uit `model-aanmelding.md` §2.11 (bestaande waardelijst) | -| `zpm_verwijstype` | over te nemen uit `model-aanmelding.md` §2.10 (bestaande waardelijst, ZPM-verwijstypen 01–07) | -| `wettelijk_kader` | over te nemen uit `model-aanmelding.md` §2.10 (bestaande waardelijst: zvw, wmo, jeugdwet, *(wvggz toe te voegen)*) | +| `echelon` | over te nemen uit `model-aanmelding.md` §4 waardelijst 17 (bestaande waardelijst) | +| `zpm_verwijstype` | over te nemen uit `model-aanmelding.md` §4 waardelijst 18 (bestaande waardelijst, ZPM-verwijstypen 01–07) | +| `wettelijk_kader` | over te nemen uit `model-aanmelding.md` §4 waardelijst 12 (bestaande waardelijst: zvw, wmo, jeugdwet, *(wvggz toe te voegen)*) | | `municipal_legal_framework` | wmo, jeugdwet *(voorstel)* | | `municipal_product_category` / `municipal_product_unit` | over te nemen uit iWmo/iJw-standaard (voorstel, nog niet uitgezocht) | | `mandate_type` | crisismaatregel, zorgmachtiging *(voorstel)* | -- 2.39.5 From 7ad50f4e3396edaa60097886cb052006d3ad0633 Mon Sep 17 00:00:00 2001 From: colinislit Date: Sun, 19 Jul 2026 18:24:34 +0200 Subject: [PATCH 16/19] docs(datamodel): feitenronde intake en behandeladvies afgerond MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- docs/datamodel/begrippenlijst-kernmodel.md | 86 +++- .../besluitenlog-datamodel-2026-07-18.md | 63 ++- .../model-intake-behandeladvies.md | 234 +++++++++ docs/datamodel/deelmodellen/model-intake.md | 12 +- .../feitenmodel-intake-behandeladvies.md | 486 ++++++++++++++++++ 5 files changed, 850 insertions(+), 31 deletions(-) create mode 100644 docs/datamodel/deelmodellen/model-intake-behandeladvies.md create mode 100644 docs/datamodel/feitenmodellen/feitenmodel-intake-behandeladvies.md diff --git a/docs/datamodel/begrippenlijst-kernmodel.md b/docs/datamodel/begrippenlijst-kernmodel.md index 1265ba3..ad037a6 100644 --- a/docs/datamodel/begrippenlijst-kernmodel.md +++ b/docs/datamodel/begrippenlijst-kernmodel.md @@ -1,7 +1,7 @@ # Begrippenlijst kernmodel — Nederlands/Engels -**Status:** versie 0.2 — §3 (instroom) bijgewerkt na de FCO-IM-feitenronde en het entiteitenmodel -**Datum:** 18 juli 2026, §3 bijgewerkt 19 juli 2026 +**Status:** versie 0.3 — §3 (instroom) en §4 (intake/behandeladvies) bijgewerkt na hun FCO-IM-feitenrondes en entiteitenmodellen +**Datum:** 18 juli 2026, §3 en §4 bijgewerkt 19 juli 2026 **Bron:** `besluiten/besluitenlog-datamodel-2026-07-18.md` (B1–B30) **Terminologieonderzoek:** de driedeling Referral Request/Referral Submission/Referral Case uit `onderzoek/onderzoek-engelstalige-epd-terminologie.md` is verwerkt en bevestigd in `feitenmodellen/feitenmodel-instroom.md` en `deelmodellen/model-instroom.md` **Doel:** één gedeelde betekenis en één Engelse technische naam per kernbegrip, vóór uitwerking van feitzinnen, ERD of SQL @@ -187,14 +187,21 @@ Een herhaalbare beoordeling van de urgentie van een `Referral Case`, vastgesteld **Is niet:** een vast statusveld — de meest recente beoordeling geldt, zonder vervangt-relatie (lagere inzet dan een acceptatiebesluit). -## 4. Intake +## 4. Intake en behandeladvies + +Bijgewerkt 19 juli 2026 na de FCO-IM-feitenronde voor intake en +behandeladvies (`feitenmodellen/feitenmodel-intake-behandeladvies.md`, +`deelmodellen/model-intake-behandeladvies.md`). ### Clinical Intake Assessment — `clinical_intake_assessment` **Nederlandse domeinterm:** intake / intaketraject -**Status Engelse naam:** bevestigen +**Status Engelse naam:** aanbevolen -Een dynamisch klinisch onderzoekstraject voor één samenhangende zorgvraag, met meerdere contacten, onderzoeken, disciplines en bevindingen. +Een dynamisch klinisch onderzoekstraject voor één samenhangende zorgvraag, +met meerdere contacten, onderzoeken, disciplines en bevindingen. Hangt aan +de Clinical Care Episode; start op enig moment ná het acceptatiebesluit dat +de episode liet ontstaan, mogelijk na een periode op de intakewachtlijst. **Is niet:** één gesprek, screening, aanmeldingstraject of FHIR `Encounter`. @@ -209,14 +216,44 @@ Eén feitelijk contact binnen de intake. **Is niet:** de intake zelf of automatisch een declarabel consult. -### Intake Assessment Activity — `intake_assessment_activity` +**Terminologienotitie:** `Intake Assessment Activity` (`intake_assessment_activity`) +is niet als aparte entiteit doorgezet — onderzoeksactiviteiten (aanvullend +onderzoek, telefonisch contact, huisbezoek, beeldcontact) zijn getypeerde +waarden van `intake_contact.contact_type`, geen zelfstandig object. -**Nederlandse domeinterm:** intakeonderzoek / onderzoeksactiviteit -**Status Engelse naam:** bevestigen +### Child Safety Check — `child_safety_check` -Een diagnostische, somatische of andere onderzoeksactiviteit binnen de intake. +**Nederlandse domeinterm:** kindcheck +**Status Engelse naam:** aanbevolen -**Is niet:** de uiteindelijke diagnose of automatisch een uitgevoerde declarabele prestatie. +De wettelijk verankerde kindcheck (Wet verplichte meldcode huiselijk geweld +en kindermishandeling; KNMG-meldcode) bij de intake van een volwassen +cliënt: is de cliënt verantwoordelijk voor minderjarigen, zijn er zorgen +over hun veiligheid, en is daarop actie ondernomen. + +**Is niet:** het volledige meldcode-stappenplan — dat is proces-state, +TIP-terrein. Alleen de klinische feiten horen in het ECD. + +### Treatment Advice — `treatment_advice` + +**Nederlandse domeinterm:** behandeladvies +**Status Engelse naam:** aanbevolen + +Het object dat een Clinical Intake Assessment afrondt: draagt de uitkomst +(in zorg, terug- of doorverwijzing, aanvullende diagnostiek nodig), het +geadviseerde zorgprogramma en de toelichting. Kan een eerder advies van +dezelfde intake vervangen bij heroverweging. + +**Is niet:** een apart, voorafgaand advies naast een later formeel besluit — +het advies zelf ís de vervolgrichting, net als bij Care Acceptance +Decision. Geen behandelplan — het advies wijst een richting, het +behandelplan werkt die uit. + +**Terminologienotitie:** `doorverwijzing` en `terugverwijzing` zijn volgens +LKS 4.0 een volgtijdelijk paar (eerst doorverwijzen proberen, dan pas +terugverwijzen), geen onafhankelijke alternatieven — gedekt door de +vervangt-relatie, niet door een aparte sequentie-regel. `extra_diagnostiek` +is een praktijkgefundeerde uitkomst, niet LKS-genormeerd. ## 5. Episode en financiering @@ -530,18 +567,31 @@ Expliciet geselecteerde en getypeerde klinische informatie met bron, bronepisode - `access_case_consolidation` → hernoemd naar `case_consolidation`, naam bevestigd; - `screening_recommendation` → vervallen, geen apart besluitobject naast `care_acceptance_decision` (B21). +**Opgelost bij de intake-/behandeladvies-feitenronde (19 juli 2026), zie §4:** + +- `clinical_intake_assessment` — naam bevestigd (was: te bevestigen); +- `intake_assessment_activity` → niet als aparte entiteit doorgezet, nu waarde van `intake_contact.contact_type`; +- `treatment_advice` — nieuw, bevestigd (loste `feitenmodellen/feitenmodel-instroom.md` §7 vraag 2 op). + De betekenis van onderstaande begrippen staat vast, maar de Engelse naam moet nog expliciet worden bevestigd: -1. `clinical_intake_assessment` — intake als proces; -2. `funding_case` — financieel traject; -3. `lead_clinician_role` — regiebehandelaar; -4. `care_goal` — behandel-/zorgdoel; -5. `care_planning_profile` — behandelvisieprofiel; -6. `cross_episode_clinical_concept` — voorlopige naam voor de longitudinale architectuurlaag. +1. `funding_case` — financieel traject; +2. `lead_clinician_role` — regiebehandelaar; +3. `care_goal` — behandel-/zorgdoel; +4. `care_planning_profile` — behandelvisieprofiel; +5. `cross_episode_clinical_concept` — voorlopige naam voor de longitudinale architectuurlaag. Daarnaast, uit de instroom-ronde, nog juridisch te bevestigen (niet een naamskwestie maar een inhoudelijke aanname, zie B27 en `deelmodellen/model-instroom.md` §7 punt 3): -7. `municipal_care_assignment` — gemeentelijke toewijzing; -8. `legal_mandate` — wettelijk mandaat (Wvggz). +6. `municipal_care_assignment` — gemeentelijke toewijzing; +7. `legal_mandate` — wettelijk mandaat (Wvggz). + +En uit de intake-/behandeladvies-ronde, eveneens een inhoudelijke aanname +i.p.v. een naamskwestie (zie `deelmodellen/model-intake-behandeladvies.md` +§6 punt 3): + +8. `child_safety_check` — de vierde vlag (zwangerschap) is toegevoegd op + basis van algemene domeinkennis, niet uit de eerder verzamelde + onderzoeksrapporten. Deze namen worden vóór het logische ER-model één voor één beoordeeld. Tot dat moment zijn ze bruikbaar als werktermen, niet als definitieve database-identifiers. diff --git a/docs/datamodel/besluiten/besluitenlog-datamodel-2026-07-18.md b/docs/datamodel/besluiten/besluitenlog-datamodel-2026-07-18.md index 5af0a13..3a02a0a 100644 --- a/docs/datamodel/besluiten/besluitenlog-datamodel-2026-07-18.md +++ b/docs/datamodel/besluiten/besluitenlog-datamodel-2026-07-18.md @@ -180,6 +180,48 @@ B21–B30 zijn de uitkomst van de FCO-IM-feitenronde en de daaropvolgende entite Het eigenaarschap van de intake — aanmeldingstraject, zorgepisode of een overgang tussen beide — hangt samen met het nog uit te werken acceptatieproces. +### B31 — Intake hangt aan de zorgepisode, start ná het acceptatiebesluit + +**Besluit** + +Sluit de ontwerpuitwerking van B6 af, nu het acceptatieproces is uitgewerkt (B21-B27). De intake hangt aan de zorgepisode, niet aan het aanmeldingstraject. Zij start op enig moment ná het acceptatiebesluit dat de episode liet ontstaan — mogelijk pas na een periode op de intakewachtlijst (vervolgroute `intakewachtlijst`, B22). De eerdere aanname dat de episode zelf pas bij aanmelding-uitkomst "intake" ontstaat (`../deelmodellen/model-intake.md`, open besluitpunt 7) is met B22 al herzien; dit besluit trekt de consequentie daarvan door voor de intake zelf. + +### B32 — Behandeladvies is een eigen object dat de intake afrondt, geen apart voorafgaand advies + +**Besluit** + +- Net als bij het acceptatiebesluit (B21) bestaat er geen apart, voorafgaand behandeladvies naast een later formeel besluit — het behandeladvies zelf draagt de uitkomst en de vervolgrichting. +- Het behandeladvies krijgt wel een eigen identiteit, los van de intake zelf (Treatment Advice), naar het patroon van Care Acceptance Decision — niet als platte velden op de intake-entiteit. +- Een behandeladvies kan een eerder advies van dezelfde intake vervangen bij heroverweging, met dezelfde vervangt-constructie als bij herziening van het acceptatiebesluit (B23): verplichte reden, uniek per vervangen exemplaar, onbeperkte kettingdiepte. + +Dit sluit `../feitenmodellen/feitenmodel-instroom.md` §7 vraag 2 af, die sinds sessielog 19 juli 2026 geparkeerd stond. + +### B33 — Vier behandeladvies-uitkomsten, deels LKS-genormeerd + +**Besluit** + +- Vier uitkomsten: `in_zorg`, `terugverwijzing`, `doorverwijzing`, `extra_diagnostiek`. +- `Doorverwijzing` en `terugverwijzing` zijn volgens LKS 4.0 (patient journey fase 2-3, §3.6.2) een volgtijdelijk paar — eerst een inspanningsverplichting tot doorverwijzing naar een beter passende aanbieder, pas daarna terugverwijzing als dat niets oplevert — geen twee gelijkwaardige, onafhankelijke uitkomsten. De volgorde wordt gedekt door het vervangt-mechanisme uit B32, niet door een aparte sequentie-regel. +- `Extra_diagnostiek` is een praktijkgefundeerde uitkomst, nergens in LKS 4.0 als zodanig benoemd — bewust behouden, maar expliciet gemarkeerd als praktijkkeuze, niet als landelijke norm. +- Gedeeld/onduidelijk advies bij twijfel tussen behandelaren krijgt geen eigen uitkomstwaarde: LKS 4.0 §3.6.2 lost dit institutioneel op (de zorgaanbieder bepaalt wie de doorslaggevende stem heeft, vaak in het professioneel statuut). +- Een cliënt die afziet van het geadviseerde vervolg is een later, apart feit, geen behandeladvies-uitkomst — analoog aan hoe planakkoord al los van het behandelplan wordt vastgelegd (B13). +- Wachtlijst voor behandelcapaciteit is geen aparte uitkomst maar een vervolgroute na `in_zorg`, zelfde precedent als bij het acceptatiebesluit (Route 2A/2B). + +**Onderzoek** + +De exacte bevoegdheidsmatrix is deels wél een landelijke norm: LKS 4.0 Tabel 2 schrijft voor settings 3–8 (multidisciplinair ambulant, outreachend, klinisch, forensisch, hoogspecialistisch) dwingend MDT-bespreking voor; voor setting 2 is dat optioneel; voor vrijgevestigden niet van toepassing. Het model biedt hiervoor een minimale hook (`intake_mdt_review`); de precieze verplichtingsregel per setting hoort bij de bevoegdheidsronde (B16) en vereist een setting-registratie die nu nog niet bestaat. + +### B34 — Kindcheck-structuur bevestigd, vierde vlag toegevoegd + +**Besluit** + +- De bestaande prototypestructuur (drie ja/nee-vlaggen met verplichte toelichting bij "ja") blijft de kern, met vlag 1 verbreed van "thuiswonende kinderen" naar "verantwoordelijk voor minderjarigen" (KNMG-meldcode: ook co-ouderschap en andere zorgrelaties tellen). +- Een vierde vlag ("zwangerschap van cliënt of partner") wordt toegevoegd — de KNMG-kindcheck rekent het ongeboren kind expliciet mee. + +**Onderzoek** + +De vierde vlag is toegevoegd op basis van algemene domeinkennis (KNMG-meldcode), niet uit de eerder verzamelde onderzoeksrapporten — te verifiëren tegen de actuele meldcode-tekst. + ## 4. Wachtlijst ### B7 — Volledige tijdlijn is de bron @@ -416,13 +458,13 @@ Niet ieder Nederlands zorgbegrip heeft een exacte Engelse vertaling. Begrippen z ### Eerst ontwerpen 1. ~~AANMELDSIGNAAL, AANMELDINGSTRAJECT, toewijzing en niet-destructieve samenvoeging.~~ **Gedaan** (19 juli 2026) — als Referral Submission/Referral Case/Signal-to-Case Assignment/Access Case Consolidation, zie B21–B25 en `../deelmodellen/model-instroom.md`. -2. ~~ACCEPTATIEBESLUIT en de relatie met intake en ZORGEPISODE.~~ **Gedaan** (19 juli 2026), zie B21–B27 en `../deelmodellen/model-instroom.md`. De relatie met het behandeladvies ná de intake blijft apart onderzoek (`../feitenmodellen/feitenmodel-instroom.md` §7 vraag 2). +2. ~~ACCEPTATIEBESLUIT en de relatie met intake en ZORGEPISODE.~~ **Gedaan** (19 juli 2026), zie B21–B27 en `../deelmodellen/model-instroom.md`. ~~De relatie met het behandeladvies ná de intake blijft apart onderzoek.~~ **Ook gedaan** (19 juli 2026) — zie B31–B33 en `../deelmodellen/model-intake-behandeladvies.md`. 3. Tijdgebonden programma-, organisatie- en zorgteambetrokkenheid. **Deels gestart:** een minimale, voorlopige hook voor teambetrokkenheid bestaat nu in het instroomdeelgebied (B30, `episode_team_involvement`); het volledige zorgteam-model (leden, rollen, regiebehandelaarschap, bevoegdheid) staat hierdoor als eerstvolgende ronde met concrete urgentie. 4. Eén levend BEHANDELPLAN met immutable snapshots. -5. MDO- en evaluatieworkflows. -6. Bevoegdheidsmatrix per besluittype en teamrol. +5. MDO- en evaluatieworkflows. **Deels gestart:** een minimale, voorlopige hook voor MDT-bespreking bij het behandeladvies bestaat nu (B33, `intake_mdt_review`); de volledige MDO-workflow (B14-B15) blijft een aparte ronde. +6. Bevoegdheidsmatrix per besluittype en teamrol. **Aangescherpt** (19 juli 2026): LKS 4.0 vereist voor settings 3–8 dwingend MDT-bespreking bij het behandeladvies, voor setting 2 optioneel — een concrete, setting-afhankelijke eis die de matrix straks moet dekken (zie B33-onderzoek). 7. Versiegebonden BEHANDELVISIEPROFIEL in ADM. -8. Engelse werktermen in `../begrippenlijst-kernmodel.md` reviewen en vóór het logische model definitief bevestigen — voor instroom is dit de eerstvolgende stap (zie hieronder). +8. Engelse werktermen in `../begrippenlijst-kernmodel.md` reviewen en vóór het logische model definitief bevestigen — voor instroom en intake/behandeladvies is dit gedaan (§3, §4 aldaar); overige secties nog open. ### Parallel onderzoeken @@ -432,20 +474,21 @@ Niet ieder Nederlands zorgbegrip heeft een exacte Engelse vertaling. Begrippen z 4. Autorisatie op historische episode- en longitudinale verwijzingen. 5. Concrete typen en governance van longitudinale cliëntinformatie. 6. Profielmigratie wanneer de behandelvisie tijdens een lopende episode wijzigt. -7. **Nieuw (19 juli 2026):** juridische verificatie van de Wvggz/Wmo-Jeugdwet-aannames in B27 — met name de zorgmachtiging-route en de jeugd-ggz-specifieke Jeugdwet-relatie (zie `../deelmodellen/model-instroom.md` §7 punt 3). -8. **Nieuw (19 juli 2026):** mogelijke uitkomsten van het behandeladvies na de intake en de bijbehorende bevoegdheid (`../feitenmodellen/feitenmodel-instroom.md` §7 vraag 2) — geparkeerd sinds sessielog 19 juli. +7. Juridische verificatie van de Wvggz/Wmo-Jeugdwet-aannames in B27 — met name de zorgmachtiging-route en de jeugd-ggz-specifieke Jeugdwet-relatie (zie `../deelmodellen/model-instroom.md` §7 punt 3). Nog open. +8. ~~Mogelijke uitkomsten van het behandeladvies na de intake en de bijbehorende bevoegdheid.~~ **Gedaan** (19 juli 2026) — zie B32–B33, op basis van volledige LKS 4.0-teksttoetsing. Setting-afhankelijke bevoegdheidsdetails blijven bij de bevoegdheidsronde (punt 6 hierboven). +9. **Nieuw (19 juli 2026):** KNMG-kindcheck-vierde-vlag (zwangerschap) verifiëren tegen de actuele meldcode-tekst — nu op basis van algemene domeinkennis toegevoegd (B34). ### Documenten synchroniseren De volgende documenten bevatten nog voorstellen die door dit log geheel of gedeeltelijk zijn achterhaald: - `../deelmodellen/datamodel-discovery.md` -- `../deelmodellen/model-aanmelding.md` — het AANMELDING/VERWIJZING/ZORGEPISODE-deel is vervangen door `../deelmodellen/model-instroom.md`; PERSOON/CLIENT/VERWIJZER/PRAKTIJK_INSTELLING/TOESTEMMING blijven ongewijzigd geldig en worden door `../deelmodellen/model-instroom.md` hergebruikt, niet gedupliceerd. Synchronisatie (secties laten vervallen, verwijzen naar het nieuwe document) is de eerstvolgende stap. -- `../deelmodellen/model-screening.md` -- `../deelmodellen/model-intake.md` +- ~~`../deelmodellen/model-aanmelding.md`~~ — **gesynchroniseerd** (19 juli 2026): het AANMELDING/VERWIJZING/ZORGEPISODE-deel is niet-destructief gemarkeerd als vervallen met verwijzing naar `../deelmodellen/model-instroom.md`; PERSOON/CLIENT/VERWIJZER/PRAKTIJK_INSTELLING/TOESTEMMING blijven ongewijzigd geldig. +- `../deelmodellen/model-screening.md` — nog niet gesynchroniseerd; inhoudelijk grotendeels opgegaan in `../deelmodellen/model-instroom.md` (screening = onderdeel van Referral Case, geen apart besluitobject, B21). +- ~~`../deelmodellen/model-intake.md`~~ — **gesynchroniseerd** (19 juli 2026): vervangen door `../deelmodellen/model-intake-behandeladvies.md`, niet-destructief gemarkeerd. - `../deelmodellen/model-wachtlijst.md` - `../deelmodellen/model-behandelplan.md` - `../deelmodellen/model-rapportage.md` -- `../entiteitenkaarten/entiteitenkaart-instroom.html` +- `../entiteitenkaarten/entiteitenkaart-instroom.html` — nog niet geregenereerd; bron is nu `../deelmodellen/model-instroom.md` en `../deelmodellen/model-intake-behandeladvies.md`. De entiteitenkaart wordt pas opnieuw gegenereerd nadat de Markdown-deelmodellen zijn herzien — voor instroom is de bron nu `../deelmodellen/model-instroom.md`. diff --git a/docs/datamodel/deelmodellen/model-intake-behandeladvies.md b/docs/datamodel/deelmodellen/model-intake-behandeladvies.md new file mode 100644 index 0000000..646bedb --- /dev/null +++ b/docs/datamodel/deelmodellen/model-intake-behandeladvies.md @@ -0,0 +1,234 @@ +# 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 3–8 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: `gepland` → `bezig` → `afgerond`/`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: `gepland` → `afgerond` rechtstreeks (afronden zonder +geregistreerd contact); `afgerond` ↔ `afgebroken` 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 3–8 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 | diff --git a/docs/datamodel/deelmodellen/model-intake.md b/docs/datamodel/deelmodellen/model-intake.md index 8685306..9a887c9 100644 --- a/docs/datamodel/deelmodellen/model-intake.md +++ b/docs/datamodel/deelmodellen/model-intake.md @@ -1,6 +1,12 @@ # Datamodelvoorstel — Deelgebied Intake -**Status:** herziening nodig — deels achterhaald door `../besluiten/besluitenlog-datamodel-2026-07-18.md` +**Status:** **vervangen door `model-intake-behandeladvies.md`** (19 juli +2026) — Engelstalige entiteiten, gecorrigeerde episode-timing (intake start +ná het acceptatiebesluit, niet bij aanmelding-uitkomst "intake"), en het +behandeladvies uitgewerkt als eigen `treatment_advice`-object in plaats van +platte velden op INTAKE. Deze tekst blijft als historisch werkdocument +staan — de kindcheck-/contactmoment-inhoud is grotendeels 1-op-1 hergebruikt +(niet-destructief), gebruik dit document zelf niet als basis voor SQL. **Datum:** 18 juli 2026 **Modelleur:** Claude (deelgebied "Intake", discovery §5.2) **Scope:** INTAKE, CONTACTMOMENT, KINDCHECK, intake-uitkomst, relatie intake–zorgepisode @@ -103,7 +109,7 @@ Gewijzigde zinnen vervangen de genoemde discovery-zin; nieuwe zinnen komen erbij | Relatie | Cardinaliteit | Toelichting | |---|---|---| | ZORGEPISODE — INTAKE | 1 — 0..* | besluit §5.2 #1; een episode kan (nog) geen intake hebben (crisisinstroom in aanmeldfase) en meerdere intakes (regulier + intern + crisis) | -| AANMELDING — ZORGEPISODE | 1 — 0..1 | context uit §5.1 #9: episode ontstaat bij aanmelding-uitkomst `intake`; afgewezen aanmelding heeft nooit een episode | +| AANMELDING — ZORGEPISODE | 1 — 0..1 | **vervallen** — context uit §5.1 #9: episode ontstaat bij aanmelding-uitkomst `intake`; afgewezen aanmelding heeft nooit een episode. Overruled door B22: de episode ontstaat al bij het acceptatiebesluit zelf, zie `model-instroom.md` §2.18. | | INTAKE — CONTACTMOMENT | 1 — 0..* | een geplande intake heeft nog geen contactmomenten | | INTAKE — KINDCHECK | 1 — 0..1 | 0..1 in het schema; "verplicht vóór afronden" is een nudge (zie §6), geen schema-eis — bij een geplande of afgebroken intake kan hij ontbreken | | INTAKE — waardelijst AFDELING | * — 1 | besluit §5.2 #2 | @@ -199,7 +205,7 @@ De status van het prototype (`bezig`/`afgerond`) blijft een subset; `gepland` en 4. **Statussen `gepland` en `afgebroken` toevoegen** naast prototype-`bezig`/`afgerond`. **Advies: ja.** Zonder `gepland` is de aanmeldwachttijd (aanmelding → eerste intakecontact) niet uit het model af te leiden; zonder `afgebroken` wordt staken door de cliënt een oneigenlijke "uitkomst". 5. **Kinderen als platte velden (`aantal_kinderen` + `leeftijden`-tekst) of als aparte kindrecords?** **Advies: plat houden.** De kinderen zijn geen cliënt; aparte persoonsrecords van derden in het dossier schuren met dataminimalisatie. Wordt een kind zelf cliënt, dan ontstaat een eigen PERSOON via de normale route. 6. **"Max één lopende intake per episode" als aan/uit-bedrijfsregel — standaard aan of uit?** **Advies: standaard uit** (crisis-intake naast lopende reguliere intake moet kunnen), met een `signaal`-nudge bij een tweede lopende intake. -7. **Episode-ontstaan bevestigen: pas bij aanmelding-uitkomst `intake`, niet bij `wachtlijst`** (open detail §5.1 #9). Onderzoek-proces §10.3 ondersteunt dit: aanmeldwachttijd hoort bij de AANMELDING, verantwoordelijkheidsoverdracht ligt ná de intake. **Advies: bevestigen zoals al voorgesorteerd** — geen wijziging, alleen het open detail sluiten. +7. **Episode-ontstaan bevestigen: pas bij aanmelding-uitkomst `intake`, niet bij `wachtlijst`** (open detail §5.1 #9). Onderzoek-proces §10.3 ondersteunt dit: aanmeldwachttijd hoort bij de AANMELDING, verantwoordelijkheidsoverdracht ligt ná de intake. **Advies: bevestigen zoals al voorgesorteerd** — geen wijziging, alleen het open detail sluiten. **Niet gevolgd — herzien door B22 (19 juli 2026):** de episode ontstaat al bij het acceptatiebesluit zelf, óók bij vervolgroute intakewachtlijst, niet pas bij aanmelding-uitkomst "intake". Zie `model-intake-behandeladvies.md` §1.1. 8. **`beeldcontact` toevoegen aan `contactmoment_type`?** **Advies: ja** — gangbare contactvorm, en ZPM-zorglabels voor digitale zorg (S-labels) vragen er later om. De waardelijst is instellingsconfigureerbaar, dus dit is alleen een startwaarde-keuze. 9. **Contactmoment nu exclusief aan INTAKE hangen** (deze ronde) en generalisatie naar behandeling/agenda uitstellen tot de agenda-ronde. **Advies: akkoord gaan met deze scope-afbakening**; de agenda-ronde beslist of CONTACTMOMENT opgaat in een generieke consult-/afspraakstructuur of ernaast blijft bestaan (ZPM: planning ≠ geleverde prestatie, onderzoek-leveranciers §2.8). diff --git a/docs/datamodel/feitenmodellen/feitenmodel-intake-behandeladvies.md b/docs/datamodel/feitenmodellen/feitenmodel-intake-behandeladvies.md new file mode 100644 index 0000000..78730c0 --- /dev/null +++ b/docs/datamodel/feitenmodellen/feitenmodel-intake-behandeladvies.md @@ -0,0 +1,486 @@ +# Feitenmodel intake en behandeladvies — FCO-IM-ronde + +**Status:** concept voor domeinreview, geen logisch model +**Datum:** 19 juli 2026 +**Scope:** zorginhoudelijke intake, intakecontact, kindcheck, en het behandeladvies waarmee de intake wordt afgerond +**Autoriteit:** `../besluiten/besluitenlog-datamodel-2026-07-18.md` blijft leidend +**Aanleiding:** sessiedoel "ronde de feitenronde van intake en behandeladvies af"; vervolg op de instroom-feitenronde (`feitenmodel-instroom.md`) en op `feitenmodel-instroom.md` §7 vraag 2 (behandeladvies-uitkomsten, tot nu toe geparkeerd) +**Bronmateriaal:** het oudere `../deelmodellen/model-intake.md` bevat al een grondig doordachte, LKS-onderbouwde intake-uitkomst-structuur — deze ronde herbruikt die inhoud, corrigeert de inmiddels achterhaalde episode-timing-aanname, hernoemt naar het Engelstalige werkbegrippenkader (B20) en lost de opengebleven vraag over het behandeladvies op + +## 1. Doel van deze ronde + +Deze ronde formuleert elementaire feiten voor het vervolg ná een positief +acceptatiebesluit: de zorginhoudelijke intake, de contacten en onderzoeken +daarbinnen, de kindcheck, en de afronding van de intake met een +behandeladvies. Net als bij instroom komen eerst de feiten, dan pas +entiteiten en cardinaliteiten. + +**Centrale correctie ten opzichte van het oudere `../deelmodellen/model-intake.md`:** dat +document ging nog uit van "episode ontstaat bij aanmelding-uitkomst +`intake`". Dat is met B22 (19 juli 2026) achterhaald — de zorgepisode +ontstaat al bij het acceptatiebesluit zelf, óók bij vervolgroute +intakewachtlijst. De intake start dus niet gelijktijdig met het ontstaan van +de episode, maar op enig moment daarna, mogelijk na een periode op de +intakewachtlijst. + +**Centrale ontwerpkeuze deze ronde:** het behandeladvies wordt, net als het +eerdere acceptatiebesluit (B21), **geen apart, voorafgaand advies-object** +zonder eigen gewicht — maar wél een eigen entiteit los van de intake zelf, +naar het patroon van Care Acceptance Decision. De intake is het +onderzoekstraject (proces-container); het behandeladvies is het object dat +de intake afrondt en de vervolgrichting draagt, met dezelfde +vervangt-mogelijkheid bij heroverweging die bij het acceptatiebesluit al is +vastgesteld (B23). Dit vervangt het oudere voorstel waarin uitkomst en +advies platte velden op INTAKE zelf waren. + +## 2. Werkbegrippen + +De Engelse namen zijn werktermen en worden pas na domeinreview in de +begrippenlijst vastgesteld. Waar een werkterm al in +`../begrippenlijst-kernmodel.md` §4 staat, wordt die hergebruikt. + +### Clinical Intake Assessment — `clinical_intake_assessment` + +Een dynamisch klinisch onderzoekstraject voor één samenhangende zorgvraag, +met meerdere contacten, onderzoeken, disciplines en bevindingen. Hangt aan +de Clinical Care Episode, niet direct aan de Referral Case. + +Een Clinical Intake Assessment is niet: +- één gesprek of contact; +- de screening (die hoort bij instroom, vóór acceptatie); +- FHIR `Encounter`; +- automatisch gestart op het moment dat de episode ontstaat — er kan tijd + tussen zitten (intakewachtlijst). + +### Intake Contact — `intake_contact` + +Eén feitelijk contact (gesprek, telefonisch contact, huisbezoek, aanvullend +onderzoek, beeldcontact) binnen een Clinical Intake Assessment. + +Een Intake Contact is niet: de intake zelf, of automatisch een declarabel +consult — dat is een latere, aparte ZPM-consultregistratie die hiernaar kan +verwijzen. + +### Child Safety Check — `child_safety_check` + +De wettelijk verankerde kindcheck (Wet verplichte meldcode huiselijk geweld +en kindermishandeling; KNMG-meldcode) bij de intake van een volwassen +cliënt: is de cliënt verantwoordelijk voor minderjarigen, zijn er zorgen +over hun veiligheid, en is daarop actie ondernomen. + +Een Child Safety Check is niet: het volledige meldcode-stappenplan (dat is +proces-state, TIP-terrein) — alleen de klinische feiten (de vlaggen en +toelichtingen) horen in het ECD. + +### Treatment Advice — `treatment_advice` + +Het object dat een Clinical Intake Assessment afrondt: draagt de uitkomst +(bijvoorbeeld in zorg, terug- of doorverwijzing, aanvullende diagnostiek +nodig), het geadviseerde zorgprogramma, en de inhoudelijke toelichting. Kan +een eerder behandeladvies van dezelfde intake vervangen bij heroverweging, +met dezelfde vervangt-constructie als Care Acceptance Decision (B23). + +Een Treatment Advice is niet: +- een apart, voorafgaand advies naast een later formeel besluit — het + advies zelf ís de vervolgrichting, net als bij het acceptatiebesluit + (B21-patroon toegepast); +- het acceptatiebesluit (dat gaat over toegang tot het zorgproces, dit gaat + over de inhoudelijke richting na onderzoek); +- een behandelplan — het advies wijst een richting, het behandelplan werkt + die vervolgens uit. + +## 3. Elementaire feitzinnen + +### 3.1 Intake start en verloop + +N1. *Clinical Intake Assessment N-1201 is op 18 juli 2026 aangemaakt voor +Zorgepisode E-901, met aanleiding "regulier".* + +N2. *Clinical Intake Assessment N-1201 heeft status "gepland" sinds 18 juli +2026.* + +N3. *Clinical Intake Assessment N-1201 heeft status "bezig" sinds 22 juli +2026.* + +N4. *Clinical Intake Assessment N-1201 is toegewezen aan afdeling +"Volwassenen".* + +N5. *Binnen dezelfde Zorgepisode E-901 is op 1 oktober 2026 een tweede +Clinical Intake Assessment N-1205 gestart met aanleiding "intern", op +afdeling "Ouderen".* + +N6. *Voor Zorgepisode E-903 is op 2 augustus 2026 een Clinical Intake +Assessment N-1210 gestart met aanleiding "crisis", zonder voorafgaande +screening.* + +N7. *Clinical Intake Assessment N-1201 is op 15 augustus 2026 heropend en +heeft weer status "bezig", nadat zij eerder was afgerond.* + +N8. *Clinical Intake Assessment N-1215 is op 25 juli 2026 afgebroken met +reden "cliënt trekt zich terug".* + +**Besloten in domeinreview (hergebruikt van `../deelmodellen/model-intake.md`, tijdlijn +gecorrigeerd):** + +- Eén Clinical Intake Assessment per samenhangend onderzoekstraject; een + interne overgang (afdelingswissel) vormt geen nieuwe intake. +- Een episode kan meerdere intakes hebben: regulier, intern (bijvoorbeeld + overgang naar een andere afdeling binnen dezelfde episode), en crisis. +- Screening vóór intake blijft een nudge, geen harde eis — ook niet nu de + intake pas na het acceptatiebesluit start; crisis-instroom kan intake en + screening (bijna) gelijktijdig laten plaatsvinden. +- Heropening (afgerond/afgebroken → bezig) is toegestaan, zelfde + flexibiliteitsprincipe als bij de Referral Case (B25) — geen + eenrichtingsstatus. + +**Gecorrigeerd ten opzichte van `../deelmodellen/model-intake.md`:** + +- De intake start niet "op basis van de aanmelding-uitkomst intake", maar + ergens ná het acceptatiebesluit, aan de Clinical Care Episode. Tussen het + ontstaan van de episode en de feitelijke start van de intake kan een + intakewachtlijst-periode zitten (Route 2A, `feitenmodel-instroom.md`). + Status "gepland" dekt precies dat interval. + +### 3.2 Intakecontact + +N9. *Intake Contact N-1301 is op 22 juli 2026 uitgevoerd binnen Clinical +Intake Assessment N-1201, van type "intakegesprek", door psycholoog +M. de Boer, met toelichting "eerste gesprek, anamnese afgenomen".* + +N10. *Intake Contact N-1301 had een geplande duur van 60 minuten.* + +N11. *Intake Contact N-1302 is op 24 juli 2026 uitgevoerd binnen Clinical +Intake Assessment N-1201, van type "aanvullend onderzoek".* + +N12. *Intake Contact N-1303 is op 26 juli 2026 uitgevoerd binnen Clinical +Intake Assessment N-1201, van type "beeldcontact".* + +**Besloten in domeinreview:** + +- Meerdere contacten van hetzelfde type op dezelfde dag zijn legitiem (geen + uniciteitsbeperking). +- Contacttype-waardelijst bevat in elk geval: intakegesprek, aanvullend + onderzoek, telefonisch contact, huisbezoek, beeldcontact, overig. + Beeldcontact is toegevoegd ten opzichte van het oorspronkelijke + prototype — gangbare GGZ-contactvorm en ZPM-relevant. +- Een Intake Contact hangt in deze ronde exclusief aan één Clinical Intake + Assessment. Generalisatie naar een bredere consult-/afspraakstructuur + (agenda, behandelcontacten) is uitdrukkelijk een latere ronde. + +### 3.3 Kindcheck + +N13. *Child Safety Check N-1401 is op 22 juli 2026 uitgevoerd door +M. de Boer binnen Clinical Intake Assessment N-1201: cliënt is +verantwoordelijk voor minderjarige kinderen: nee.* + +N14. *Child Safety Check N-1402 is op 3 augustus 2026 uitgevoerd binnen +Clinical Intake Assessment N-1205: verantwoordelijk voor 2 minderjarige +kinderen (leeftijden "4 en 7"); zorgen over veiligheid: ja, met toelichting +"moeder oververmoeid, geen netwerk"; actie ondernomen: ja, met toelichting +"adviesvraag Veilig Thuis, 3 augustus".* + +N15. *Child Safety Check N-1402 registreert daarnaast: zwangerschap van de +cliënt of partner: nee.* + +**Besloten in domeinreview (hergebruikt van `../deelmodellen/model-intake.md`):** + +- Drie ja/nee-vlaggen plus verplichte toelichting bij "ja" blijft de kern — + bevestigd prototypepatroon. +- Vlag 1 is verbreed van "thuiswonende kinderen" naar "verantwoordelijk voor + minderjarigen" (KNMG-meldcode: ook co-ouderschap en andere zorgrelaties + tellen). +- Een vierde vlag "zwangerschap van cliënt of partner" wordt toegevoegd — + de KNMG-kindcheck rekent het ongeboren kind expliciet mee. *(Algemene + domeinkennis, niet uit de eerdere onderzoeksrapporten — bij twijfel apart + te verifiëren tegen de meldcode-tekst.)* +- Uitvoerder en datum zijn verplicht (provenance); de namen van eventuele + kinderen worden bewust niet als aparte persoonsrecords vastgelegd + (dataminimalisatie) — alleen aantal en leeftijden als vrije tekst. +- Maximaal één Child Safety Check per Clinical Intake Assessment; een nieuwe + intake binnen dezelfde episode krijgt een eigen, nieuwe kindcheck (de + situatie kan gewijzigd zijn). + +### 3.4 Behandeladvies (afronding van de intake) + +**Route 1 — in zorg** + +N16. *Clinical Intake Assessment N-1201 heeft op 30 juli 2026 geleid tot +Treatment Advice N-1501.* + +N17. *Treatment Advice N-1501 heeft uitkomst "in_zorg", geadviseerd +zorgprogramma "Algemeen GGZ".* + +N18. *Treatment Advice N-1501 is vastgesteld door M. de Boer, handelend als +regiebehandelaar van Zorgepisode E-901.* + +N19. *Clinical Intake Assessment N-1201 is op 30 juli 2026 afgerond met +Treatment Advice N-1501.* + +**Route 2 — doorverwijzing, gevolgd door terugverwijzing (LKS-volgorde)** + +N20. *Treatment Advice N-1503 heeft uitkomst "doorverwijzing", met +toelichting "beter passend bij aanbieder X, specialisatie trauma".* + +N20a. *Aanbieder X laat op 10 augustus 2026 weten geen plek te hebben.* + +N20b. *Treatment Advice N-1502 heeft uitkomst "terugverwijzing", met +toelichting "geen doorverwijzing gelukt; advies aan huisarts: begeleiding +POH-GGZ", en vervangt Treatment Advice N-1503.* + +Dit toont de LKS-volgorde (§3.6.2/patient journey fase 2-3): eerst een +inspanningsverplichting tot doorverwijzing naar een beter passende +aanbieder; pas als dat niets oplevert, of de cliënt komt niet in aanmerking +voor GGZ, terugverwijzing naar de verwijzer met advies. Dit zijn dus geen +twee gelijkwaardige, onafhankelijke uitkomsten maar een volgtijdelijk paar — +het vervangt-mechanisme (Route 5 hieronder) dekt deze opvolging al. + +**Route 3 — aanvullende diagnostiek** + +N22. *Treatment Advice N-1504 heeft uitkomst "extra_diagnostiek", met +toelichting "vermoeden persoonlijkheidsproblematiek, aanvullend +psychodiagnostisch onderzoek nodig".* + +**Route 4 — heroverweging van het behandeladvies** + +N23. *Treatment Advice N-1505 betreft Clinical Intake Assessment N-1210, +heeft uitkomst "extra_diagnostiek".* + +N24. *Op 20 augustus 2026 blijkt, na afronding van de aanvullende +diagnostiek, dat Treatment Advice N-1506 nodig is: uitkomst "in_zorg", +geadviseerd zorgprogramma "Trauma", en vervangt Treatment Advice N-1505.* + +N25. *De reden voor vervanging van Treatment Advice N-1505 door N-1506 is +"aanvullende diagnostiek afgerond, duidelijk beeld voor zorgprogramma +Trauma".* + +**Besloten in domeinreview, verscherpt door gericht LKS 4.0-onderzoek (19 +juli 2026 — volledige teksttoetsing, niet alleen samenvattingen):** + +- Behandeladvies is geen apart, voorafgaand advies naast een later + besluit — het draagt zelf de uitkomst, het richting-advies + (zorgprogramma) en de toelichting, analoog aan Care Acceptance Decision + (B21-patroon). +- Vier uitkomstwaarden blijven het startpunt: `in_zorg`, `terugverwijzing`, + `doorverwijzing`, `extra_diagnostiek` — maar niet als vier gelijkwaardige + alternatieven. + - **`doorverwijzing` en `terugverwijzing` zijn LKS-genormeerd en + volgtijdelijk, geen onafhankelijke keuzes** (patient journey fase 2-3, + §3.6.2): eerst een inspanningsverplichting tot doorverwijzing naar een + beter passende aanbieder; pas als dat niets oplevert (of de cliënt komt + niet in aanmerking voor GGZ), volgt terugverwijzing naar de verwijzer + met advies. Als waardelijst-codes blijven het twee losse waarden; de + volgorde wordt gedekt door het vervangt-mechanisme (zie Route 2 + hierboven), niet door een aparte sequentie-regel. + - **`extra_diagnostiek` is een praktijkgefundeerde toevoeging, geen + LKS-genormeerde uitkomst** — nergens in LKS 4.0 als zodanig benoemd. + Blijft behouden (de praktijk kent dit als reële afrondingsuitkomst), + maar expliciet gemarkeerd als zodanig, niet als landelijke norm + voorgesteld. +- `Afgewezen` is bewust geen behandeladvies-uitkomst — afwijzen gebeurt al + bij het acceptatiebesluit (instroom); wie de intake bereikt, wordt niet + meer "afgewezen". +- **Gedeeld/onduidelijk advies bij twijfel tussen behandelaren krijgt geen + eigen uitkomstwaarde.** LKS 4.0 §3.6.2 lost dit institutioneel op: bij + verschil van inzicht bepaalt de zorgaanbieder wie de doorslaggevende stem + heeft (vaak vastgelegd in het professioneel statuut) — een + escalatiemechanisme vóór afronding, geen apart feit in dit model. +- **Cliënt die afziet van het geadviseerde vervolg is een later, apart + feit, geen intake-uitkomstwaarde** — analoog aan hoe planakkoord al los + van het behandelplan wordt vastgelegd (B13). LKS 4.0 gaat uit van + overeenstemming tussen regiebehandelaar en cliënt als vertrekpunt van de + uitkomst zelf; een latere weigering hoort dus bij een vervolgfeit, niet + bij `Treatment Advice`. +- Vervolgroute bij wachtlijst voor behandelcapaciteit is geen aparte + uitkomst: uitkomst `in_zorg` kan gevolgd worden door plaatsing op een + behandelwachtlijst (apart wachtlijst-deelgebied), net zoals capaciteit bij + het acceptatiebesluit invoer is maar de besluituitkomst niet automatisch + bepaalt (Route 2A/2B-precedent). LKS 4.0 biedt hier geen aanknopingspunt, + dus dit blijft consistentie-redenering, geen LKS-citaat. + +**Bevoegdheid — LKS 4.0 maakt dit onderscheid expliciet zelf, verscherpt +ten opzichte van de eerdere aanname van een simpele FK-placeholder:** + +- LKS 4.0 onderscheidt uitdrukkelijk "wie de intake verricht" van wie + bevoegd is de uitkomst vast te stellen (§2, fase 2) — dat kán dezelfde + persoon zijn, hoeft niet. De **regiebehandelaar in de indicerende rol** + is verantwoordelijk voor het (doen) vaststellen van de uitkomst + (§3.6.2). Bij vrijgevestigden (sectie II, §4.3) is dit altijd dezelfde + persoon als de intakebehandelaar; bij instellingen (sectie III) kan dat + uiteenlopen. +- **MDT-bespreking is voor een deel van de settings een dwingende + landelijke norm, geen instellingsbeleid.** Voor settings 3 t/m 8 + (multidisciplinair ambulant, outreachend, klinisch, forensisch, + hoogspecialistisch) schrijft LKS 4.0 Tabel 2 dwingend voor dat een + art. 14 BIG-beroep betrokken is bij diagnostiek/indicatiestelling **en** + bespreking plaatsvindt in het multidisciplinair team (MDT), met de + betrokken discipline als lid. Voor setting 2 (monodisciplinair ambulant) + is een MDT niet verplicht — direct contact, een MDT, of bilaterale + afstemming volstaan. Bij sectie II (vrijgevestigd) bestaat geen MDT, + alleen een professioneel netwerk voor advies/consultatie. +- **Modelconsequentie:** bevoegdheid is niet één simpele FK naar een + persoon, maar minimaal een rol-attribuut (indicerende regiebehandelaar, + eventueel afwijkend van de intakebehandelaar) plus een optioneel, + settingafhankelijk MDT-feit — vergelijkbaar met hoe bij het + acceptatiebesluit beslisbevoegdheid al los van het besluit zelf is + gehouden (`decision_authority`). De exacte bevoegdheidsmatrix per setting + blijft een detail voor de rollenronde/bevoegdheidsmatrix (B16); wat hier + al vaststaat is dát het model ruimte moet bieden voor een optioneel + MDT-feit naast de indicerende regiebehandelaar, niet uitsluitend een + enkele beslisser. + +## 4. Voorlopige uniqueness- en optionaliteitsregels + +Deze regels zijn hypotheses voor domeinreview, geen definitieve +cardinaliteiten. + +### Clinical Intake Assessment + +- Elke intake heeft één stabiele identiteit en hangt aan precies één + Clinical Care Episode. +- Een episode kan nul, één of meerdere intakes hebben (regulier, intern, + crisis); "maximaal één lopende intake per episode" is een aan/uit-zetbare + bedrijfsregel, geen schemabeperking — een crisisintake kan naast een + lopende reguliere intake nodig zijn. +- Elke intake heeft een aanleiding (regulier/intern/crisis) en een + afdeling. +- Statussen: gepland → bezig → afgerond/afgebroken, met heropening + toegestaan vanuit afgerond of afgebroken. Niet toegestaan: rechtstreeks + gepland → afgerond (afronden zonder geregistreerd contact), of + afgerond ↔ afgebroken rechtstreeks. +- Bij status afgerond hoort precies één (het laatst geldige, niet-vervangen) + Treatment Advice; bij status afgebroken hoort een afbreekreden, geen + Treatment Advice. + +### Intake Contact + +- Elk contact hoort bij precies één Clinical Intake Assessment. +- Geen uniciteitsbeperking op type/datum-combinaties. + +### Child Safety Check + +- Maximaal één per Clinical Intake Assessment. +- Uitvoerder en uitvoeringsdatum verplicht; per vlag is de toelichting + verplicht zodra die vlag "ja" is. + +### Treatment Advice + +- Elk advies hoort bij precies één Clinical Intake Assessment. +- Elk advies heeft precies één uitkomst, één vaststeller en één + vaststellingsdatum. +- Optioneel precies één eerder advies van dezelfde intake vervangen, met + verplichte reden — zelfde constructie als Care Acceptance Decision + (uniek per vervangen exemplaar, voorkomt vertakking, onbeperkte + kettingdiepte). +- Geadviseerd zorgprogramma is verplicht bij uitkomst `in_zorg`, optioneel + anders. +- Toelichting is verplicht bij `terugverwijzing`, `doorverwijzing` en + `extra_diagnostiek` (een ontvangende partij of vervolgstap moet + navolgbaar zijn); optioneel bij `in_zorg`. +- Elk advies heeft precies één indicerende regiebehandelaar (kan dezelfde + persoon zijn als de intakebehandelaar, hoeft niet — LKS 4.0 §2/§3.6.2). + Optioneel, settingafhankelijk, een MDT-bespreking als apart feit + (deelnemers, datum) — voor settings 3 t/m 8 een verplicht feit, voor + setting 2 optioneel, voor sectie II (vrijgevestigd) niet van toepassing. + De exacte verplichtingsregel per setting is een detail voor de + bevoegdheidsronde (B16), niet voor deze feitenronde. + +## 5. Scenariotoets + +### Scenario 1 — reguliere intake, in zorg + +Benodigde objecten: één Clinical Intake Assessment (aanleiding regulier), +minstens één Intake Contact, één Child Safety Check, één Treatment Advice +met uitkomst `in_zorg`. + +Dit scenario toont de hoofdroute: acceptatie → (eventueel intakewachtlijst) +→ intake → behandeladvies. + +### Scenario 2 — crisisintake zonder voorafgaande screening + +Benodigde objecten: één Clinical Intake Assessment met aanleiding `crisis`, +gekoppeld aan een episode die is ontstaan uit een acceptatiebesluit of een +Wvggz-mandaat (`feitenmodel-instroom.md` §3.5 Route 5/B27), zonder dat +daaraan een screeningsactiviteit voorafging. + +Dit scenario toont dat screening vóór intake een nudge blijft, ook nu de +volgorde acceptatie-vóór-intake vaststaat. + +### Scenario 3 — aanvullende diagnostiek en heroverweging + +Benodigde objecten: één Clinical Intake Assessment, een eerste Treatment +Advice met uitkomst `extra_diagnostiek`, aanvullende Intake Contacten, en +een tweede Treatment Advice dat het eerste vervangt met uitkomst `in_zorg`. + +Dit scenario toont dat het vervangt-patroon uit de instroomronde (B23) +identiek toepasbaar is op het behandeladvies. + +### Scenario 4 — interne intake binnen een lopende episode + +Benodigde objecten: dezelfde Clinical Care Episode, een tweede Clinical +Intake Assessment met aanleiding `intern` op een andere afdeling, eigen +Intake Contacten en een eigen Treatment Advice. + +Dit scenario toont dat een episode meerdere, onafhankelijke intakes met elk +hun eigen behandeladvies kan hebben. + +### Scenario 5 — kindcheck met positieve vlaggen + +Benodigde objecten: één Clinical Intake Assessment, één Child Safety Check +met vlag "verantwoordelijk voor minderjarigen" = ja, verplichte toelichting, +vlag "zorgen over veiligheid" = ja met verplichte toelichting, vlag "actie +ondernomen" = ja met verplichte toelichting. + +Dit scenario toetst de conditionele verplichting van de toelichtingsvelden. + +## 6. Domeinreview + +**Beantwoord (domeinreview + gericht LKS 4.0-onderzoek, 19 juli 2026):** + +- Episode-timing gecorrigeerd: intake start ná het acceptatiebesluit, niet + gelijktijdig met een aanmelding-uitkomst die niet meer bestaat. +- Behandeladvies-uitkomsten (`feitenmodel-instroom.md` §7 vraag 2, tot nu + toe geparkeerd): vier uitkomsten bevestigd (`in_zorg`, `terugverwijzing`, + `doorverwijzing`, `extra_diagnostiek`), hergebruikt uit het al bestaande + voorstel in `../deelmodellen/model-intake.md`, met een correctie na + volledige LKS 4.0-teksttoetsing: `doorverwijzing`/`terugverwijzing` zijn + LKS-genormeerd maar volgtijdelijk (eerst doorverwijzen proberen), niet + onafhankelijk; `extra_diagnostiek` is praktijkgefundeerd, niet + LKS-genormeerd — beide nuances zijn nu expliciet in §3.4 vastgelegd. +- Behandeladvies is, net als het acceptatiebesluit, geen apart voorafgaand + advies — het object zelf geeft de vervolgrichting, met een vervangt- + mechanisme voor heroverweging. +- Bevoegdheid: LKS 4.0 maakt zelf onderscheid tussen wie de intake verricht + en wie de uitkomst vaststelt (regiebehandelaar, indicerende rol). Voor + settings 3–8 is MDT-bespreking een dwingende landelijke norm, niet + instellingsbeleid; voor setting 2 optioneel; voor vrijgevestigden niet + van toepassing. Verwerkt als rol-attribuut plus optioneel MDT-feit in §4. + +**Nog open:** + +1. Exacte bevoegdheidsmatrix per setting (welke settings precies wanneer + MDT-bespreking vereisen, en de rolinvulling daarvan) — deel van de + bredere bevoegdheidsronde (B16); het principe (rol + optioneel MDT-feit) + staat al vast, de detailinvulling niet. +2. Is `extra_diagnostiek` altijd een volledig nieuw, vervangend Treatment + Advice, of kan de bestaande intake simpelweg langer "bezig" blijven + zonder tussentijdse afronding? Beide patronen zijn nu toegestaan (zie + §3.1 N7 heropening); welke de praktijk het vaakst gebruikt is nog niet + getoetst. +3. Vierde kindcheck-vlag (zwangerschap) is toegevoegd op basis van + algemene domeinkennis, niet uit de eerder verzamelde onderzoeksrapporten + — te verifiëren tegen de actuele meldcode-tekst. +4. Contactmoment-generalisatie naar een bredere consult-/afspraakstructuur + blijft uitdrukkelijk een latere (agenda-)ronde. + +## 7. Volgende stap + +Na bevestiging van bovenstaande volgen: + +1. definitieve uniqueness- en optionaliteitsconstraints; +2. afleiding van entiteiten en cardinaliteiten (`../deelmodellen/model-intake.md` her­zien + naar Engelse namen en de gecorrigeerde episode-relatie, analoog aan hoe + `../deelmodellen/model-instroom.md` uit `feitenmodel-instroom.md` is afgeleid); +3. verwerking in `../besluiten/besluitenlog-datamodel-2026-07-18.md`; +4. synchronisatie van `../begrippenlijst-kernmodel.md` (Treatment Advice, + Child Safety Check zijn nieuw; Clinical Intake Assessment/Intake Contact + bestonden al als werkterm) en `../deelmodellen/model-intake.md`. -- 2.39.5 From ea4c0c836f8f2b524eda382097fd3efc41d9fda4 Mon Sep 17 00:00:00 2001 From: colinislit Date: Mon, 20 Jul 2026 08:57:12 +0200 Subject: [PATCH 17/19] feat(db): technisch datamodel instroom/intake/behandeladvies (SQL-migraties) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Vertaalt de FCO-IM-feitenrondes en logische modellen naar 37 nieuwe PostgreSQL-tabellen, verdeeld over vier migraties: - create_reference_data: één generieke value_list_item-tabel (spelregel 3.1 #1) i.p.v. ~30 losse waardelijst-tabellen, met alle startwaarden uit model-aanmelding.md/model-instroom.md/model-intake-behandeladvies.md. - create_person_client_domain: person, address, contact_detail, client, client_relation, referrer, practice_organization, client_general_practitioner, insurance, consent, client_portal_account (model-aanmelding.md §2.1-2.9, 2.14, 2.16). BSN als bsn_hash (SHA-256), conform de platform-privacyregel — geen raw BSN, geen reversibele encryptie. - create_referral_domain: 20 entiteiten uit model-instroom.md (referral_ request t/m episode_team_involvement), inclusief de vervangt-constraints als partial unique index (voorkomt vertakking) en de XOR-check op clinical_care_episode tussen acceptatiebesluit en Wvggz-mandaat. - create_intake_treatment_advice_domain: 5 entiteiten uit model-intake-behandeladvies.md. Scope: dit zijn nieuwe, additieve tabellen naast de bestaande prototype- tabellen (patients, screenings, intakes, patients.is_john_doe, intakes.kindcheck_data) — die tabellen zijn bewust niet aangeraakt. Wiring van de live app op dit schema, en migratie van prototype-data, is een aparte, nog te nemen beslissing. Migraties zijn nog niet toegepast op een database. decision_authority_id (care_acceptance_decision) is tijdelijk nullable zonder FK — het doeltabel volgt uit de bevoegdheidsronde (B16). Perifere waardelijst-kolommen zijn TEXT met een verwijzing naar de bedoelde lijst in een comment, geen harde FK naar value_list_item — applicatievalidatie (Zod) dekt die laag; business-kritieke uitkomsten (decision_outcome, treatment_advice_outcome, mandate_type) hebben wel een CHECK-constraint. --- .../20260720000001_create_reference_data.sql | 293 +++++++++ ...0720000002_create_person_client_domain.sql | 349 +++++++++++ .../20260720000003_create_referral_domain.sql | 567 ++++++++++++++++++ ..._create_intake_treatment_advice_domain.sql | 178 ++++++ 4 files changed, 1387 insertions(+) create mode 100644 supabase/migrations/20260720000001_create_reference_data.sql create mode 100644 supabase/migrations/20260720000002_create_person_client_domain.sql create mode 100644 supabase/migrations/20260720000003_create_referral_domain.sql create mode 100644 supabase/migrations/20260720000004_create_intake_treatment_advice_domain.sql diff --git a/supabase/migrations/20260720000001_create_reference_data.sql b/supabase/migrations/20260720000001_create_reference_data.sql new file mode 100644 index 0000000..fe10e7c --- /dev/null +++ b/supabase/migrations/20260720000001_create_reference_data.sql @@ -0,0 +1,293 @@ +-- ============================================================================ +-- REFERENCE DATA (WAARDELIJSTEN) — instroom / intake / behandeladvies +-- ============================================================================ +-- Created: 2026-07-20 +-- Purpose: shared reference-list table for the redesigned instroom/intake/ +-- behandeladvies domain (docs/datamodel/deelmodellen/model-instroom.md, +-- model-intake-behandeladvies.md, model-aanmelding.md §4). +-- +-- Design note: spelregel 3.1 #1 ("elke waardelijst is een referentietabel") +-- is honoured with ONE shared, generic table (list_name-discriminated) +-- instead of ~30 near-identical single-purpose tables. Each row still +-- carries code/label/external_code/code_system/geldig_van/geldig_tot/actief. +-- List-specific extra attributes (agb_verplicht, verwijsnudge_severity, ...) +-- live in `extra` (JSONB) rather than one-off columns. +-- +-- Scope note: this migration and the ones that follow (create_person_client_ +-- domain, create_referral_domain, create_intake_treatment_advice_domain) +-- implement the REDESIGNED target schema from the 19-20 juli 2026 FCO-IM +-- rounds. They are new, additive tables — the existing prototype tables +-- (patients, screenings, intakes, patients.is_john_doe, intakes.kindcheck_data) +-- are intentionally left untouched. Wiring the live app to this schema, and +-- migrating prototype data into it, is a separate follow-up decision. +-- ============================================================================ + +CREATE TABLE value_list_item ( + list_name TEXT NOT NULL, + code TEXT NOT NULL, + label TEXT NOT NULL, + external_code TEXT, + code_system TEXT, + extra JSONB NOT NULL DEFAULT '{}'::jsonb, + valid_from DATE, + valid_to DATE, + active BOOLEAN NOT NULL DEFAULT true, + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + + PRIMARY KEY (list_name, code) +); + +CREATE INDEX idx_value_list_item_list_active ON value_list_item(list_name, active); + +COMMENT ON TABLE value_list_item IS 'Generieke waardelijst-tabel (spelregel 3.1 #1): één rij per (list_name, code). Startlijsten, geen definitieve besluiten (zie modeldocumenten).'; +COMMENT ON COLUMN value_list_item.extra IS 'List-specifieke attributen, bv. agb_verplicht (verwijzertype), verwijsnudge_severity (wettelijk_kader).'; + +ALTER TABLE value_list_item ENABLE ROW LEVEL SECURITY; + +CREATE POLICY "Enable read for authenticated users" ON value_list_item + FOR SELECT USING (auth.role() = 'authenticated'); + +CREATE TRIGGER update_value_list_item_updated_at + BEFORE UPDATE ON value_list_item + FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- Seed data — startlijsten uit de modeldocumenten, geen definitieve besluiten +-- ============================================================================ + +INSERT INTO value_list_item (list_name, code, label, extra) VALUES +-- geslacht (model-aanmelding.md §4.1) — externe code: HL7 AdministrativeGender +('geslacht', 'man', 'Man', '{}'), +('geslacht', 'vrouw', 'Vrouw', '{}'), +('geslacht', 'anders', 'Anders', '{}'), +('geslacht', 'onbekend', 'Onbekend', '{}'), + +-- genderidentiteit (zib Patient v4.3) +('genderidentiteit', 'man', 'Man', '{}'), +('genderidentiteit', 'vrouw', 'Vrouw', '{}'), +('genderidentiteit', 'non_binair', 'Non-binair', '{}'), +('genderidentiteit', 'anders', 'Anders', '{}'), +('genderidentiteit', 'zegt_het_niet', 'Zegt het niet', '{}'), + +-- adrestype +('adrestype', 'woonadres', 'Woonadres', '{}'), +('adrestype', 'postadres', 'Postadres', '{}'), +('adrestype', 'tijdelijk_verblijf', 'Tijdelijk verblijf', '{}'), + +-- contactgegeven_type +('contactgegeven_type', 'telefoon', 'Telefoon', '{}'), +('contactgegeven_type', 'email', 'E-mail', '{}'), + +-- contactgegeven_soort +('contactgegeven_soort', 'mobiel_prive', 'Mobiel privé', '{}'), +('contactgegeven_soort', 'vast_prive', 'Vast privé', '{}'), +('contactgegeven_soort', 'werk', 'Werk', '{}'), +('contactgegeven_soort', 'overig', 'Overig', '{}'), + +-- relatie +('relatie', 'partner', 'Partner', '{}'), +('relatie', 'ouder', 'Ouder', '{}'), +('relatie', 'kind', 'Kind', '{}'), +('relatie', 'broer_zus', 'Broer/zus', '{}'), +('relatie', 'familielid_overig', 'Familielid overig', '{}'), +('relatie', 'vriend_kennis', 'Vriend/kennis', '{}'), +('relatie', 'professional', 'Professional', '{}'), +('relatie', 'overig', 'Overig', '{}'), + +-- relatierol (twee assen relatie x rol — zib Contactpersoon) +('relatierol', 'eerste_contactpersoon', 'Eerste contactpersoon', '{}'), +('relatierol', 'wettelijk_vertegenwoordiger', 'Wettelijk vertegenwoordiger', '{}'), +('relatierol', 'gezaghebbende_ouder', 'Gezaghebbende ouder', '{}'), +('relatierol', 'mantelzorger', 'Mantelzorger', '{}'), +('relatierol', 'naaste', 'Naaste', '{}'), + +-- vertegenwoordigingsgrond (WGBO-volgorde) +('vertegenwoordigingsgrond', 'curator', 'Curator', '{}'), +('vertegenwoordigingsgrond', 'mentor', 'Mentor', '{}'), +('vertegenwoordigingsgrond', 'schriftelijk_gemachtigde', 'Schriftelijk gemachtigde', '{}'), +('vertegenwoordigingsgrond', 'ouder_voogd', 'Ouder/voogd', '{}'), +('vertegenwoordigingsgrond', 'partner_familie', 'Partner/familie', '{}'), + +-- huisarts_situatie (voedt zpm_verwijstype 04/05) +('huisarts_situatie', 'bekend', 'Bekend', '{}'), +('huisarts_situatie', 'geen_huisarts', 'Geen huisarts', '{}'), +('huisarts_situatie', 'geen_toestemming_correspondentie', 'Geen toestemming correspondentie', '{}'), +('huisarts_situatie', 'onbekend', 'Onbekend', '{}'), + +-- verwijzertype (extra.agb_verplicht — discovery §5.0 besluit 3) +('verwijzertype', 'huisarts', 'Huisarts', '{"agb_verplicht": true}'), +('verwijzertype', 'medisch_specialist', 'Medisch specialist', '{"agb_verplicht": true}'), +('verwijzertype', 'straatdokter', 'Straatdokter', '{"agb_verplicht": true}'), +('verwijzertype', 'bedrijfsarts', 'Bedrijfsarts', '{"agb_verplicht": true}'), +('verwijzertype', 'regiebehandelaar', 'Regiebehandelaar', '{"agb_verplicht": true}'), +('verwijzertype', 'ggz_instelling', 'GGZ-instelling', '{"agb_verplicht": true}'), +('verwijzertype', 'gemeente', 'Gemeente', '{"agb_verplicht": false}'), +('verwijzertype', 'zelfaanmelding', 'Zelfaanmelding', '{"agb_verplicht": false}'), +('verwijzertype', 'crisis', 'Crisis', '{"agb_verplicht": false}'), + +-- praktijk_soort +('praktijk_soort', 'huisartsenpraktijk', 'Huisartsenpraktijk', '{}'), +('praktijk_soort', 'ziekenhuis', 'Ziekenhuis', '{}'), +('praktijk_soort', 'ggz_instelling', 'GGZ-instelling', '{}'), +('praktijk_soort', 'gemeente', 'Gemeente', '{}'), +('praktijk_soort', 'arbodienst', 'Arbodienst', '{}'), +('praktijk_soort', 'overig', 'Overig', '{}'), + +-- wettelijk_kader (extra.verwijsnudge_severity — te bevestigen in de nudge-/declaratieronde; wvggz toegevoegd bij B27) +('wettelijk_kader', 'zvw', 'Zorgverzekeringswet', '{"verwijsnudge_severity": "blokkade"}'), +('wettelijk_kader', 'jeugdwet', 'Jeugdwet', '{"verwijsnudge_severity": "signaal"}'), +('wettelijk_kader', 'wmo', 'Wmo', '{"verwijsnudge_severity": "signaal"}'), +('wettelijk_kader', 'wlz', 'Wlz', '{"verwijsnudge_severity": "waarschuwing"}'), +('wettelijk_kader', 'forensisch', 'Forensisch', '{"verwijsnudge_severity": "waarschuwing"}'), +('wettelijk_kader', 'wvggz', 'Wvggz', '{"verwijsnudge_severity": null}'), + +-- submission_channel (was aanmeldkanaal — model-instroom.md §4) +('submission_channel', 'zorgdomein', 'ZorgDomein', '{}'), +('submission_channel', 'e_mail', 'E-mail', '{}'), +('submission_channel', 'telefoon', 'Telefoon', '{}'), +('submission_channel', 'portaal', 'Cliëntportaal', '{}'), +('submission_channel', 'post', 'Post', '{}'), +('submission_channel', 'overig', 'Overig', '{}'), + +-- document_type (model-instroom.md §4) +('document_type', 'verwijsbrief', 'Verwijsbrief', '{}'), +('document_type', 'diagnostische_aanvulling', 'Diagnostische aanvulling', '{}'), +('document_type', 'beschikking', 'Beschikking', '{}'), +('document_type', 'overig', 'Overig', '{}'), + +-- screening_activity_type +('screening_activity_type', 'telefonisch_contact', 'Telefonisch contact', '{}'), +('screening_activity_type', 'dossieronderzoek', 'Dossieronderzoek', '{}'), +('screening_activity_type', 'vragenlijst', 'Vragenlijst', '{}'), +('screening_activity_type', 'overig', 'Overig', '{}'), + +-- decision_outcome (B22) +('decision_outcome', 'geaccepteerd', 'Geaccepteerd', '{}'), +('decision_outcome', 'afgewezen', 'Afgewezen', '{}'), + +-- follow_up_route +('follow_up_route', 'intake_direct', 'Intake direct plannen', '{}'), +('follow_up_route', 'intakewachtlijst', 'Intakewachtlijst', '{}'), +('follow_up_route', 'spoedroute', 'Spoedroute', '{}'), +('follow_up_route', 'doorverwijzen', 'Doorverwijzen', '{}'), +('follow_up_route', 'case_afsluiten', 'Case afsluiten', '{}'), + +-- episode_end_reason (model-aanmelding.md §4.24 + B24-aanvullingen) +('episode_end_reason', 'ingetrokken_door_client', 'Ingetrokken door cliënt', '{}'), +('episode_end_reason', 'acceptatiebesluit_herzien', 'Acceptatiebesluit herzien', '{}'), +('episode_end_reason', 'behandeling_afgerond', 'Behandeling afgerond', '{}'), +('episode_end_reason', 'doorverwezen', 'Doorverwezen', '{}'), +('episode_end_reason', 'client_beeindigt', 'Cliënt beëindigt', '{}'), +('episode_end_reason', 'geen_contact', 'Geen contact meer', '{}'), +('episode_end_reason', 'overleden', 'Overleden', '{}'), +('episode_end_reason', 'overig', 'Overig', '{}'), + +-- echelon +('echelon', 'gb_ggz', 'Generalistische basis-ggz', '{}'), +('echelon', 'g_ggz', 'Gespecialiseerde ggz', '{}'), +('echelon', 'onbekend', 'Onbekend', '{}'), + +-- zpm_verwijstype (Vektis/ZPM-code als external_code) +('zpm_verwijstype', '01', 'Verwijzing aanwezig', '{}'), +('zpm_verwijstype', '02', 'Doorverwijzing regiebehandelaar', '{}'), +('zpm_verwijstype', '03', 'Geen verwijzing, verlate correspondentie', '{}'), +('zpm_verwijstype', '04', 'Geen verwijzing, correspondentie niet toegestaan', '{}'), +('zpm_verwijstype', '05', 'Geen verwijzing, niet declarabel', '{}'), +('zpm_verwijstype', '06', 'Geen verwijzing, andere grond fz', '{}'), +('zpm_verwijstype', '07', 'Verwijzing zonder AGB', '{}'), + +-- municipal_legal_framework (B27) +('municipal_legal_framework', 'wmo', 'Wmo', '{}'), +('municipal_legal_framework', 'jeugdwet', 'Jeugdwet', '{}'), + +-- municipal_product_category / municipal_product_unit — minimale startwaarden (declaratie-ronde volgt) +('municipal_product_category', 'overig', 'Overig (nader te bepalen)', '{}'), +('municipal_product_unit', 'overig', 'Overig (nader te bepalen)', '{}'), + +-- mandate_type / mandate_decider_role (B27, Wvggz) +('mandate_type', 'crisismaatregel', 'Crisismaatregel', '{}'), +('mandate_type', 'zorgmachtiging', 'Zorgmachtiging', '{}'), +('mandate_decider_role', 'burgemeester', 'Burgemeester', '{}'), +('mandate_decider_role', 'rechter', 'Rechter', '{}'), + +-- crisis_fact_type +('crisis_fact_type', 'medicatie_toegediend', 'Medicatie toegediend', '{}'), +('crisis_fact_type', 'risico_inschatting', 'Risico-inschatting', '{}'), +('crisis_fact_type', 'vitale_functie', 'Vitale functie', '{}'), +('crisis_fact_type', 'dwangmaatregel', 'Dwangmaatregel', '{}'), +('crisis_fact_type', 'overig', 'Overig', '{}'), + +-- urgency_assessor_role / urgency_level +('urgency_assessor_role', 'screener', 'Screener', '{}'), +('urgency_assessor_role', 'triagist', 'Triagist', '{}'), +('urgency_assessor_role', 'intake_team', 'Intake-team', '{}'), +('urgency_assessor_role', 'mdo', 'MDO', '{}'), +('urgency_level', 'laag', 'Laag', '{}'), +('urgency_level', 'normaal', 'Normaal', '{}'), +('urgency_level', 'hoog', 'Hoog', '{}'), +('urgency_level', 'spoed', 'Spoed', '{}'), + +-- initiator_type +('initiator_type', 'professional', 'Professional', '{}'), +('initiator_type', 'organisatie', 'Organisatie', '{}'), +('initiator_type', 'client', 'Cliënt', '{}'), +('initiator_type', 'vertegenwoordiger', 'Vertegenwoordiger', '{}'), + +-- intake_initiation_reason +('intake_initiation_reason', 'regulier', 'Regulier', '{}'), +('intake_initiation_reason', 'intern', 'Intern', '{}'), +('intake_initiation_reason', 'crisis', 'Crisis', '{}'), + +-- intake_status +('intake_status', 'gepland', 'Gepland', '{}'), +('intake_status', 'bezig', 'Bezig', '{}'), +('intake_status', 'afgerond', 'Afgerond', '{}'), +('intake_status', 'afgebroken', 'Afgebroken', '{}'), + +-- intake_abort_reason +('intake_abort_reason', 'client_trekt_terug', 'Cliënt trekt zich terug', '{}'), +('intake_abort_reason', 'geen_contact_meer', 'Geen contact meer', '{}'), +('intake_abort_reason', 'overleden', 'Overleden', '{}'), +('intake_abort_reason', 'overig', 'Overig', '{}'), + +-- intake_contact_type +('intake_contact_type', 'intakegesprek', 'Intakegesprek', '{}'), +('intake_contact_type', 'aanvullend_onderzoek', 'Aanvullend onderzoek', '{}'), +('intake_contact_type', 'telefonisch_contact', 'Telefonisch contact', '{}'), +('intake_contact_type', 'huisbezoek', 'Huisbezoek', '{}'), +('intake_contact_type', 'beeldcontact', 'Beeldcontact', '{}'), +('intake_contact_type', 'overig', 'Overig', '{}'), + +-- treatment_advice_outcome (B33 — doorverwijzing/terugverwijzing volgtijdelijk, extra_diagnostiek praktijkgefundeerd) +('treatment_advice_outcome', 'in_zorg', 'In zorg', '{}'), +('treatment_advice_outcome', 'terugverwijzing', 'Terugverwijzing', '{"lks_genormeerd": true, "volgt_op": "doorverwijzing"}'), +('treatment_advice_outcome', 'doorverwijzing', 'Doorverwijzing', '{"lks_genormeerd": true}'), +('treatment_advice_outcome', 'extra_diagnostiek', 'Extra diagnostiek', '{"lks_genormeerd": false}'), + +-- department / care_program — instellingsconfigureerbaar, minimale startwaarden +('department', 'volwassenen', 'Volwassenen', '{}'), +('department', 'jeugd', 'Jeugd', '{}'), +('department', 'ouderen', 'Ouderen', '{}'), +('department', 'forensisch', 'Forensisch', '{}'), +('department', 'overig', 'Overig', '{}'), +('care_program', 'algemeen_ggz', 'Algemeen GGZ', '{}'), +('care_program', 'stemming', 'Stemming', '{}'), +('care_program', 'trauma', 'Trauma', '{}'), +('care_program', 'verslaving', 'Verslaving', '{}'), +('care_program', 'overig', 'Overig', '{}'), + +-- toestemming_type (extra.grondslag) +('toestemming_type', 'correspondentie_huisarts_verwijzer', 'Correspondentie huisarts/verwijzer', '{"grondslag": "WGBO/verwijsafspraken"}'), +('toestemming_type', 'dsm_hoofdgroep_op_factuur', 'DSM-hoofdgroep op factuur', '{"grondslag": "Stcrt. 2025-11955, opt-in"}'), +('toestemming_type', 'privacyverklaring_zorgvraagtypering', 'Privacyverklaring zorgvraagtypering', '{"grondslag": "NZa"}'), +('toestemming_type', 'gegevensdeling_derden', 'Gegevensdeling derden', '{"grondslag": "AVG"}'), +('toestemming_type', 'inzage_naasten', 'Inzage naasten', '{"grondslag": "WGBO"}'), + +-- toestemming_status / toestemming_wijze +('toestemming_status', 'verleend', 'Verleend', '{}'), +('toestemming_status', 'geweigerd', 'Geweigerd', '{}'), +('toestemming_status', 'ingetrokken', 'Ingetrokken', '{}'), +('toestemming_wijze', 'mondeling', 'Mondeling', '{}'), +('toestemming_wijze', 'schriftelijk', 'Schriftelijk', '{}'), +('toestemming_wijze', 'portaal', 'Portaal', '{}'); diff --git a/supabase/migrations/20260720000002_create_person_client_domain.sql b/supabase/migrations/20260720000002_create_person_client_domain.sql new file mode 100644 index 0000000..ba74133 --- /dev/null +++ b/supabase/migrations/20260720000002_create_person_client_domain.sql @@ -0,0 +1,349 @@ +-- ============================================================================ +-- PERSON / CLIENT DOMAIN +-- ============================================================================ +-- Created: 2026-07-20 +-- Source: docs/datamodel/deelmodellen/model-aanmelding.md §2.1-2.9, §2.14, §2.16 +-- (PERSOON, ADRES, CONTACTGEGEVEN, CLIENT, CLIENTRELATIE, VERWIJZER, +-- PRAKTIJK_INSTELLING, CLIENT_HUISARTS, VERZEKERING, TOESTEMMING, +-- CLIENTPORTAAL_ACCOUNT) — the AANMELDING/VERWIJZING/ZORGEPISODE part of +-- that document is superseded by the referral/intake domains that follow +-- this migration, not translated here. +-- +-- Naming: English identifiers per besluit B20. Dutch field names in the +-- source document are translated 1:1 in meaning; nothing renamed to a +-- different concept. +-- +-- Privacy: raw BSN is never stored, only a SHA-256 hash (bsn_hash) — this +-- follows the platform-wide privacy rule (root CLAUDE.md), which is a +-- stricter requirement than the source document's "versleuteld (pgcrypto)" +-- wording. Reversible BSN storage for declaratie/Vecozo purposes, if ever +-- needed, is a separate, explicitly-scoped decision — not implemented here. +-- ============================================================================ + +CREATE EXTENSION IF NOT EXISTS pgcrypto; + +-- ============================================================================ +-- person +-- ============================================================================ +CREATE TABLE person ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + family_name TEXT NOT NULL, + name_prefix TEXT, + given_names TEXT, + initials TEXT, + preferred_name TEXT, + birth_date DATE NOT NULL, + gender TEXT NOT NULL, -- waardelijst geslacht + gender_identity TEXT, -- waardelijst genderidentiteit + bsn_hash TEXT, -- SHA-256, optioneel op PERSOON (rolgebonden eis via nudge) + deceased BOOLEAN NOT NULL DEFAULT false, + deceased_at DATE, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT person_family_name_not_empty CHECK (length(trim(family_name)) > 0), + CONSTRAINT person_deceased_at_requires_flag CHECK (deceased_at IS NULL OR deceased) +); + +CREATE UNIQUE INDEX idx_person_bsn_hash ON person(bsn_hash) WHERE bsn_hash IS NOT NULL AND deleted_at IS NULL; +CREATE INDEX idx_person_name ON person(family_name, given_names) WHERE deleted_at IS NULL; + +COMMENT ON TABLE person IS 'Natuurlijke persoon, onafhankelijk van rollen (cliënt, contactpersoon, vertegenwoordiger, medewerker). model-aanmelding.md §2.1.'; +COMMENT ON COLUMN person.bsn_hash IS 'SHA-256 hash van het BSN; geen raw BSN opgeslagen (platform-privacyregel). Naam+geboortedatum-duplicaten zijn een nudge, geen constraint.'; + +ALTER TABLE person ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON person FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_person_updated_at BEFORE UPDATE ON person FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- address +-- ============================================================================ +CREATE TABLE address ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + person_id UUID NOT NULL REFERENCES person(id) ON DELETE CASCADE, + address_type TEXT NOT NULL, -- waardelijst adrestype + street TEXT NOT NULL, + house_number TEXT NOT NULL, + house_number_addition TEXT, + postal_code TEXT NOT NULL, + city TEXT NOT NULL, + country TEXT NOT NULL DEFAULT 'NL', + valid_from DATE, + valid_to DATE, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +-- max één actueel (valid_to leeg) adres per persoon per adrestype +CREATE UNIQUE INDEX idx_address_current_per_type ON address(person_id, address_type) + WHERE valid_to IS NULL AND deleted_at IS NULL; +CREATE INDEX idx_address_person ON address(person_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE address IS 'model-aanmelding.md §2.2 — 0..n adressen per persoon (zib Patient).'; + +ALTER TABLE address ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON address FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_address_updated_at BEFORE UPDATE ON address FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- contact_detail +-- ============================================================================ +CREATE TABLE contact_detail ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + person_id UUID NOT NULL REFERENCES person(id) ON DELETE CASCADE, + contact_type TEXT NOT NULL, -- waardelijst contactgegeven_type (telefoon/e-mail) + contact_subtype TEXT, -- waardelijst contactgegeven_soort + value TEXT NOT NULL, + is_preferred BOOLEAN NOT NULL DEFAULT false, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +-- max één voorkeursgegeven per persoon per contacttype +CREATE UNIQUE INDEX idx_contact_detail_preferred ON contact_detail(person_id, contact_type) + WHERE is_preferred AND deleted_at IS NULL; +CREATE INDEX idx_contact_detail_person ON contact_detail(person_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE contact_detail IS 'model-aanmelding.md §2.3 — telefoonnummers en e-mailadressen per persoon.'; + +ALTER TABLE contact_detail ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON contact_detail FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_contact_detail_updated_at BEFORE UPDATE ON contact_detail FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- client (rol op person) +-- ============================================================================ +CREATE TABLE client ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + person_id UUID NOT NULL REFERENCES person(id) ON DELETE RESTRICT, + client_number BIGINT NOT NULL, + client_since DATE NOT NULL, + gp_situation TEXT NOT NULL DEFAULT 'onbekend', -- waardelijst huisarts_situatie + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +-- max één CLIENT-rol per PERSOON +CREATE UNIQUE INDEX idx_client_person ON client(person_id) WHERE deleted_at IS NULL; +CREATE UNIQUE INDEX idx_client_number ON client(client_number) WHERE deleted_at IS NULL; + +COMMENT ON TABLE client IS 'model-aanmelding.md §2.4 — instellingsgebonden rol op PERSOON. Nudge (geen constraint): cliënt zonder bsn_hash (Wabvpz).'; + +ALTER TABLE client ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON client FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_client_updated_at BEFORE UPDATE ON client FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- client_relation (contactpersoon / wettelijk vertegenwoordiger) +-- ============================================================================ +CREATE TABLE client_relation ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + client_id UUID NOT NULL REFERENCES client(id) ON DELETE CASCADE, + person_id UUID NOT NULL REFERENCES person(id) ON DELETE RESTRICT, + relation_type TEXT, -- waardelijst relatie (partner, ouder, kind, ...) + relation_role TEXT NOT NULL, -- waardelijst relatierol + representation_basis TEXT, -- waardelijst vertegenwoordigingsgrond (alleen bij rol wettelijk_vertegenwoordiger) + valid_from DATE NOT NULL, + valid_to DATE, + notes TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +-- max één actuele rij per (client, persoon, rol) +CREATE UNIQUE INDEX idx_client_relation_current ON client_relation(client_id, person_id, relation_role) + WHERE valid_to IS NULL AND deleted_at IS NULL; +CREATE INDEX idx_client_relation_client ON client_relation(client_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE client_relation IS 'model-aanmelding.md §2.5 — contactpersonen/vertegenwoordigers, twee assen relatie x rol (zib Contactpersoon). Leeftijdsafhankelijke rechten (12/16 WGBO) zijn autorisatie, geen schema.'; + +ALTER TABLE client_relation ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON client_relation FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_client_relation_updated_at BEFORE UPDATE ON client_relation FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- Zelfrelatie (persoon = cliënt-persoon) niet toegestaan. CHECK-constraints +-- kunnen geen subquery bevatten in Postgres, dus dit is een trigger i.p.v. +-- een CHECK — functioneel identiek aan wat model-aanmelding.md §2.5 vraagt. +CREATE OR REPLACE FUNCTION prevent_client_relation_self_reference() +RETURNS TRIGGER AS $$ +BEGIN + IF NEW.person_id = (SELECT person_id FROM client WHERE client.id = NEW.client_id) THEN + RAISE EXCEPTION 'client_relation: person_id mag niet gelijk zijn aan de cliënt-persoon zelf'; + END IF; + RETURN NEW; +END; +$$ LANGUAGE plpgsql; + +CREATE TRIGGER client_relation_no_self_reference + BEFORE INSERT OR UPDATE ON client_relation + FOR EACH ROW EXECUTE FUNCTION prevent_client_relation_self_reference(); + +-- ============================================================================ +-- practice_organization (moet vóór referrer bestaan i.v.m. FK) +-- ============================================================================ +CREATE TABLE practice_organization ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + name TEXT NOT NULL, + practice_type TEXT, -- waardelijst praktijk_soort + agb_code TEXT, + address_text TEXT, + phone TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +CREATE UNIQUE INDEX idx_practice_organization_agb ON practice_organization(agb_code) WHERE agb_code IS NOT NULL AND deleted_at IS NULL; + +COMMENT ON TABLE practice_organization IS 'model-aanmelding.md §2.7 — organisatie waaraan verwijzers/huisartsen verbonden zijn.'; + +ALTER TABLE practice_organization ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON practice_organization FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_practice_organization_updated_at BEFORE UPDATE ON practice_organization FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- referrer +-- ============================================================================ +CREATE TABLE referrer ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + name TEXT NOT NULL, + referrer_type TEXT NOT NULL, -- waardelijst verwijzertype (extra.agb_verplicht bepaalt nudge) + agb_code TEXT, + practice_organization_id UUID REFERENCES practice_organization(id) ON DELETE SET NULL, + phone TEXT, + email TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +CREATE UNIQUE INDEX idx_referrer_agb ON referrer(agb_code) WHERE agb_code IS NOT NULL AND deleted_at IS NULL; +CREATE INDEX idx_referrer_practice ON referrer(practice_organization_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE referrer IS 'model-aanmelding.md §2.6 — persoon/functionaris die verwijst, los van practice_organization. Kan zonder praktijk bestaan (gemeente-ambtenaar). Ook referent voor de vaste huisarts.'; + +ALTER TABLE referrer ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON referrer FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_referrer_updated_at BEFORE UPDATE ON referrer FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- client_general_practitioner (vaste huisarts) +-- ============================================================================ +CREATE TABLE client_general_practitioner ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + client_id UUID NOT NULL REFERENCES client(id) ON DELETE CASCADE, + referrer_id UUID REFERENCES referrer(id) ON DELETE SET NULL, + practice_organization_id UUID REFERENCES practice_organization(id) ON DELETE SET NULL, + valid_from DATE NOT NULL, + valid_to DATE, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT client_gp_at_least_one_ref CHECK (referrer_id IS NOT NULL OR practice_organization_id IS NOT NULL) +); + +-- max één actuele registratie per cliënt +CREATE UNIQUE INDEX idx_client_gp_current ON client_general_practitioner(client_id) + WHERE valid_to IS NULL AND deleted_at IS NULL; + +COMMENT ON TABLE client_general_practitioner IS 'model-aanmelding.md §2.8 — vaste huisarts, los van de incidentele verwijzer. "Geen huisarts"/"geen toestemming" staat op client.gp_situation, niet hier.'; + +ALTER TABLE client_general_practitioner ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON client_general_practitioner FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_client_gp_updated_at BEFORE UPDATE ON client_general_practitioner FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- insurance +-- ============================================================================ +CREATE TABLE insurance ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + client_id UUID NOT NULL REFERENCES client(id) ON DELETE CASCADE, + uzovi_code TEXT NOT NULL, + insurer_name TEXT, + policy_number TEXT, + valid_from DATE NOT NULL, + valid_to DATE, + cov_checked_at DATE, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +-- max één actuele verzekering per cliënt +CREATE UNIQUE INDEX idx_insurance_current ON insurance(client_id) WHERE valid_to IS NULL AND deleted_at IS NULL; + +COMMENT ON TABLE insurance IS 'model-aanmelding.md §2.9 — Zvw-verzekeringsgegevens. Nudge: Zvw-aanmelding zonder actuele COV-controle. Wlz/forensisch: declaratie-ronde.'; + +ALTER TABLE insurance ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON insurance FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_insurance_updated_at BEFORE UPDATE ON insurance FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- consent +-- ============================================================================ +-- referral_case_id/clinical_care_episode_id FKs are added by later migrations +-- (create_referral_domain, create_intake_treatment_advice_domain) once those +-- tables exist — see ALTER TABLE at the bottom of create_referral_domain. +CREATE TABLE consent ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + client_id UUID NOT NULL REFERENCES client(id) ON DELETE CASCADE, + consent_type TEXT NOT NULL, -- waardelijst toestemming_type (extra.grondslag) + status TEXT NOT NULL, -- waardelijst toestemming_status + consent_date DATE NOT NULL, + method TEXT, -- waardelijst toestemming_wijze + recorded_by UUID REFERENCES practitioners(id), + valid_to DATE, + revoked_at DATE, + scope_referral_case_id UUID, -- optioneel; default cliëntbreed + notes TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +-- max één actuele (niet-ingetrokken) rij per (client, type, scope) +CREATE UNIQUE INDEX idx_consent_current ON consent(client_id, consent_type, COALESCE(scope_referral_case_id, '00000000-0000-0000-0000-000000000000')) + WHERE status <> 'ingetrokken' AND deleted_at IS NULL; +CREATE INDEX idx_consent_client ON consent(client_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE consent IS 'model-aanmelding.md §2.14 — generieke WGBO/AVG-toestemming. Cliëntakkoord op het behandelplan is een apart feit bij het behandelplan, geen consent-rij. scope_referral_case_id FK volgt in create_referral_domain.sql.'; + +ALTER TABLE consent ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON consent FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_consent_updated_at BEFORE UPDATE ON consent FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- client_portal_account +-- ============================================================================ +CREATE TABLE client_portal_account ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + client_id UUID NOT NULL REFERENCES client(id) ON DELETE CASCADE, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +CREATE UNIQUE INDEX idx_client_portal_account_client ON client_portal_account(client_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE client_portal_account IS 'model-aanmelding.md §2.16 — relatie-placeholder (Wabvpz elektronische inzage). Authenticatiedetails: auth/ADM-ronde.'; + +ALTER TABLE client_portal_account ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON client_portal_account FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_client_portal_account_updated_at BEFORE UPDATE ON client_portal_account FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); diff --git a/supabase/migrations/20260720000003_create_referral_domain.sql b/supabase/migrations/20260720000003_create_referral_domain.sql new file mode 100644 index 0000000..5f4dfb7 --- /dev/null +++ b/supabase/migrations/20260720000003_create_referral_domain.sql @@ -0,0 +1,567 @@ +-- ============================================================================ +-- REFERRAL / INSTROOM DOMAIN +-- ============================================================================ +-- Created: 2026-07-20 +-- Source: docs/datamodel/deelmodellen/model-instroom.md (20 entiteiten), +-- docs/datamodel/feitenmodellen/feitenmodel-instroom.md, besluiten B21-B30. +-- +-- Design principles carried over from the model documents: +-- - referral_case has NO status column — the current state is derived from +-- the event timeline (signal_case_assignment/screening_activity/ +-- case_information_request/care_acceptance_decision/case_withdrawal/ +-- case_consolidation). See model-instroom.md §5. Application code (or a +-- read-model view, per the UX review) computes "actuele stand", not this +-- schema. +-- - "vervangt"-relations (care_acceptance_decision, professional_referral, +-- municipal_care_assignment) are enforced unique-if-set (partial unique +-- index) so the chain can never fork. +-- - `medewerker`/beslisser references point at the existing `practitioners` +-- table (already used by the prototype screening/intake schema). +-- - `decision_authority_id` on care_acceptance_decision is left nullable +-- for now: the target table for decision authority does not exist yet +-- (bevoegdheidsronde, B16/B33). The model calls it "verplicht"; enforcing +-- NOT NULL today would make every insert impossible. Tighten once that +-- ronde delivers a real authority table. +-- ============================================================================ + +-- ============================================================================ +-- referral_request +-- ============================================================================ +CREATE TABLE referral_request ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + person_id UUID REFERENCES person(id) ON DELETE RESTRICT, + person_identified_at TIMESTAMPTZ, + person_identified_by UUID REFERENCES practitioners(id), + initiated_at TIMESTAMPTZ NOT NULL, + initiator_type TEXT NOT NULL, -- waardelijst initiator_type + referrer_id UUID REFERENCES referrer(id), + requested_scope TEXT NOT NULL, + presenting_need_text TEXT NOT NULL, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT referral_request_person_identification CHECK ( + (person_id IS NULL AND person_identified_at IS NULL AND person_identified_by IS NULL) + OR (person_id IS NOT NULL AND person_identified_at IS NOT NULL AND person_identified_by IS NOT NULL) + ) +); + +COMMENT ON TABLE referral_request IS 'model-instroom.md §2.1. person_id optioneel: crisisaanmelding met onbekende identiteit (B26) — geen placeholder-persoon, de koppeling is een eigen feit.'; + +ALTER TABLE referral_request ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON referral_request FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_referral_request_updated_at BEFORE UPDATE ON referral_request FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- referral_submission +-- ============================================================================ +CREATE TABLE referral_submission ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + received_at TIMESTAMPTZ NOT NULL, + channel TEXT NOT NULL, -- waardelijst submission_channel + source_reference TEXT, -- vrije tekst of naam verwijzer; "onbekend" toegestaan + recorded_by UUID REFERENCES practitioners(id), + raw_note TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +COMMENT ON TABLE referral_submission IS 'model-instroom.md §2.2. Nooit overschreven door een latere aanvulling — een aanvulling is een nieuwe submission.'; + +ALTER TABLE referral_submission ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON referral_submission FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_referral_submission_updated_at BEFORE UPDATE ON referral_submission FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- submission_document +-- ============================================================================ +CREATE TABLE submission_document ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + submission_id UUID NOT NULL REFERENCES referral_submission(id) ON DELETE CASCADE, + document_type TEXT NOT NULL, -- waardelijst document_type + document_reference UUID NOT NULL, -- documentopslag + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +CREATE INDEX idx_submission_document_submission ON submission_document(submission_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE submission_document IS 'model-instroom.md §2.3.'; + +ALTER TABLE submission_document ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON submission_document FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_submission_document_updated_at BEFORE UPDATE ON submission_document FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- submission_request_link +-- ============================================================================ +CREATE TABLE submission_request_link ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + submission_id UUID NOT NULL REFERENCES referral_submission(id) ON DELETE CASCADE, + referral_request_id UUID NOT NULL REFERENCES referral_request(id) ON DELETE CASCADE, + established_at TIMESTAMPTZ NOT NULL, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + UNIQUE (submission_id, referral_request_id) +); + +CREATE INDEX idx_submission_request_link_request ON submission_request_link(referral_request_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE submission_request_link IS 'model-instroom.md §2.4. "representeert" vs "vult_aan" is niet opgeslagen — af te leiden als vroegste established_at per referral_request_id.'; + +ALTER TABLE submission_request_link ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON submission_request_link FOR ALL USING (auth.role() = 'authenticated'); + +-- ============================================================================ +-- submission_duplicate_assessment +-- ============================================================================ +CREATE TABLE submission_duplicate_assessment ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + submission_id UUID NOT NULL REFERENCES referral_submission(id) ON DELETE CASCADE, + duplicate_of_submission_id UUID NOT NULL REFERENCES referral_submission(id) ON DELETE CASCADE, + assessed_by UUID NOT NULL REFERENCES practitioners(id), + assessed_at TIMESTAMPTZ NOT NULL, + reason TEXT NOT NULL, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT submission_duplicate_not_self CHECK (submission_id <> duplicate_of_submission_id) +); + +COMMENT ON TABLE submission_duplicate_assessment IS 'model-instroom.md §2.5. Niet-destructief: beide submissions blijven bestaan.'; + +ALTER TABLE submission_duplicate_assessment ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON submission_duplicate_assessment FOR ALL USING (auth.role() = 'authenticated'); + +-- ============================================================================ +-- referral_case +-- ============================================================================ +CREATE TABLE referral_case ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + person_id UUID REFERENCES person(id) ON DELETE RESTRICT, + person_identified_at TIMESTAMPTZ, + person_identified_by UUID REFERENCES practitioners(id), + opened_at TIMESTAMPTZ NOT NULL, + presenting_need_summary TEXT NOT NULL, + legal_framework TEXT NOT NULL, -- waardelijst wettelijk_kader + zpm_referral_type TEXT, -- waardelijst zpm_verwijstype + gp_informed_at DATE, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT referral_case_person_identification CHECK ( + (person_id IS NULL AND person_identified_at IS NULL AND person_identified_by IS NULL) + OR (person_id IS NOT NULL AND person_identified_at IS NOT NULL AND person_identified_by IS NOT NULL) + ) +); + +COMMENT ON TABLE referral_case IS 'model-instroom.md §2.6. Geen statusveld — zie §5 aldaar en de opmerking bovenaan dit bestand. legal_framework/zpm_referral_type/gp_informed_at hersteld van het oudere AANMELDING (B21-B27).'; + +ALTER TABLE referral_case ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON referral_case FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_referral_case_updated_at BEFORE UPDATE ON referral_case FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- Now that referral_case exists: wire the consent scope FK from the person/client migration +ALTER TABLE consent + ADD CONSTRAINT consent_scope_referral_case_fk FOREIGN KEY (scope_referral_case_id) REFERENCES referral_case(id) ON DELETE SET NULL; + +-- ============================================================================ +-- submission_case_assignment +-- ============================================================================ +CREATE TABLE submission_case_assignment ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + submission_id UUID NOT NULL REFERENCES referral_submission(id) ON DELETE CASCADE, + referral_case_id UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE, + assigned_at TIMESTAMPTZ NOT NULL, + assigned_by UUID NOT NULL REFERENCES practitioners(id), + reason TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + UNIQUE (submission_id, referral_case_id) +); + +CREATE INDEX idx_submission_case_assignment_case ON submission_case_assignment(referral_case_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE submission_case_assignment IS 'model-instroom.md §2.7 (hernoemd van signal_case_assignment). Toewijzing is een gebeurtenis, geen overschrijfbaar veld.'; + +ALTER TABLE submission_case_assignment ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON submission_case_assignment FOR ALL USING (auth.role() = 'authenticated'); + +-- ============================================================================ +-- request_case_link +-- ============================================================================ +CREATE TABLE request_case_link ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + referral_request_id UUID NOT NULL REFERENCES referral_request(id) ON DELETE CASCADE, + referral_case_id UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE, + since_date DATE NOT NULL, + reason TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + UNIQUE (referral_request_id, referral_case_id) +); + +COMMENT ON TABLE request_case_link IS 'model-instroom.md §2.8. reason verplicht (applicatieniveau) zodra een request aan >1 case gekoppeld is.'; + +ALTER TABLE request_case_link ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON request_case_link FOR ALL USING (auth.role() = 'authenticated'); + +-- ============================================================================ +-- case_consolidation +-- ============================================================================ +CREATE TABLE case_consolidation ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + primary_case_id UUID NOT NULL REFERENCES referral_case(id) ON DELETE RESTRICT, + related_case_id UUID NOT NULL REFERENCES referral_case(id) ON DELETE RESTRICT, + overlap_assessed_at TIMESTAMPTZ, + designated_at TIMESTAMPTZ NOT NULL, + designated_by UUID NOT NULL REFERENCES practitioners(id), + reason TEXT NOT NULL, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT case_consolidation_no_self CHECK (primary_case_id <> related_case_id) +); + +-- een case kan hoogstens één keer de niet-leidende rol vervullen +CREATE UNIQUE INDEX idx_case_consolidation_related_unique ON case_consolidation(related_case_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE case_consolidation IS 'model-instroom.md §2.9 (hernoemd van access_case_consolidation). Geen speciale decision_authority vereist (administratieve correctie). Transitieve cykels niet uitgesloten op schemaniveau — applicatieverantwoordelijkheid.'; + +ALTER TABLE case_consolidation ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON case_consolidation FOR ALL USING (auth.role() = 'authenticated'); + +-- ============================================================================ +-- screening_activity +-- ============================================================================ +CREATE TABLE screening_activity ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + referral_case_id UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE, + performed_at TIMESTAMPTZ NOT NULL, + activity_type TEXT NOT NULL, -- waardelijst screening_activity_type + performed_by UUID NOT NULL REFERENCES practitioners(id), + notes TEXT, + funded BOOLEAN NOT NULL DEFAULT false, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +CREATE INDEX idx_screening_activity_case ON screening_activity(referral_case_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE screening_activity IS 'model-instroom.md §2.10. Directe koppeling aan referral_case — de aparte "screening"-groeperingsentiteit is vervallen (reviewronde 19 juli).'; + +ALTER TABLE screening_activity ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON screening_activity FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_screening_activity_updated_at BEFORE UPDATE ON screening_activity FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- case_information_request +-- ============================================================================ +CREATE TABLE case_information_request ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + referral_case_id UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE, + requested_at TIMESTAMPTZ NOT NULL, + requested_by UUID NOT NULL REFERENCES practitioners(id), + requested_information TEXT NOT NULL, + resolved_by_submission_id UUID REFERENCES referral_submission(id), + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +CREATE UNIQUE INDEX idx_case_information_request_resolved_submission ON case_information_request(resolved_by_submission_id) WHERE resolved_by_submission_id IS NOT NULL AND deleted_at IS NULL; +CREATE INDEX idx_case_information_request_case ON case_information_request(referral_case_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE case_information_request IS 'model-instroom.md §2.11. Geen besluituitkomst en geen statusfase (B21/vraag 5) — een gedateerd gebeurtenisfeit; kan zich ook ná een eerder besluit voordoen tijdens heroverweging.'; + +ALTER TABLE case_information_request ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON case_information_request FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_case_information_request_updated_at BEFORE UPDATE ON case_information_request FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- care_acceptance_decision +-- ============================================================================ +CREATE TABLE care_acceptance_decision ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + referral_case_id UUID NOT NULL REFERENCES referral_case(id) ON DELETE RESTRICT, + decided_at TIMESTAMPTZ NOT NULL, + decided_by UUID NOT NULL REFERENCES practitioners(id), + decision_authority_id UUID, -- ref decision_authority — tabel volgt uit bevoegdheidsronde (B16); tijdelijk geen FK/NOT NULL + content_match BOOLEAN NOT NULL, + capacity_available BOOLEAN, + program_context TEXT, -- waardelijst care_program of vrije tekst + decision_outcome TEXT NOT NULL, -- waardelijst decision_outcome + follow_up_route TEXT NOT NULL, -- waardelijst follow_up_route + rationale TEXT, + replaces_decision_id UUID REFERENCES care_acceptance_decision(id), + replacement_reason TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT care_acceptance_decision_outcome_check CHECK (decision_outcome IN ('geaccepteerd', 'afgewezen')), + CONSTRAINT care_acceptance_decision_rationale_required CHECK ( + decision_outcome <> 'afgewezen' OR (rationale IS NOT NULL AND length(trim(rationale)) > 0) + ), + CONSTRAINT care_acceptance_decision_replacement_reason_required CHECK ( + replaces_decision_id IS NULL OR (replacement_reason IS NOT NULL AND length(trim(replacement_reason)) > 0) + ), + CONSTRAINT care_acceptance_decision_no_self_replace CHECK (replaces_decision_id <> id) +); + +-- vervangt-keten kan nooit vertakken (B23 / reviewronde 19 juli, kritieke bevinding) +CREATE UNIQUE INDEX idx_care_acceptance_decision_replaces_unique ON care_acceptance_decision(replaces_decision_id) WHERE replaces_decision_id IS NOT NULL AND deleted_at IS NULL; +CREATE INDEX idx_care_acceptance_decision_case ON care_acceptance_decision(referral_case_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE care_acceptance_decision IS 'model-instroom.md §2.12. Geen apart voorafgaand screeningsadvies (B21). Concurrency bij gelijktijdige heroverwegingen (SELECT ... FOR UPDATE op de keten-tail) is applicatieverantwoordelijkheid.'; + +ALTER TABLE care_acceptance_decision ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON care_acceptance_decision FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_care_acceptance_decision_updated_at BEFORE UPDATE ON care_acceptance_decision FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- case_withdrawal +-- ============================================================================ +CREATE TABLE case_withdrawal ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + referral_case_id UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE, + withdrawn_at TIMESTAMPTZ NOT NULL, + recorded_by UUID NOT NULL REFERENCES practitioners(id), + note TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +CREATE INDEX idx_case_withdrawal_case ON case_withdrawal(referral_case_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE case_withdrawal IS 'model-instroom.md §2.13. Geen beslisbevoegdheid vereist; kan op elk moment, ook ná een positief besluit (B24).'; + +ALTER TABLE case_withdrawal ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON case_withdrawal FOR ALL USING (auth.role() = 'authenticated'); + +-- ============================================================================ +-- professional_referral +-- ============================================================================ +CREATE TABLE professional_referral ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + referral_request_id UUID NOT NULL REFERENCES referral_request(id) ON DELETE RESTRICT, + referrer_id UUID NOT NULL REFERENCES referrer(id), + referral_date DATE NOT NULL, + echelon TEXT, -- waardelijst echelon + suspected_condition TEXT, + is_readmission BOOLEAN NOT NULL DEFAULT false, + replaces_referral_id UUID REFERENCES professional_referral(id), + replacement_reason TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT professional_referral_replacement_reason_required CHECK ( + replaces_referral_id IS NULL OR (replacement_reason IS NOT NULL AND length(trim(replacement_reason)) > 0) + ), + CONSTRAINT professional_referral_no_self_replace CHECK (replaces_referral_id <> id) +); + +CREATE UNIQUE INDEX idx_professional_referral_replaces_unique ON professional_referral(replaces_referral_id) WHERE replaces_referral_id IS NOT NULL AND deleted_at IS NULL; +CREATE INDEX idx_professional_referral_request ON professional_referral(referral_request_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE professional_referral IS 'model-instroom.md §2.14. Correctie/aanvulling = nieuw, vervangend record, geen nieuw request (was open punt 1, opgelost).'; + +ALTER TABLE professional_referral ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON professional_referral FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_professional_referral_updated_at BEFORE UPDATE ON professional_referral FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- municipal_care_assignment +-- ============================================================================ +CREATE TABLE municipal_care_assignment ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + referral_request_id UUID NOT NULL REFERENCES referral_request(id) ON DELETE RESTRICT, + legal_framework TEXT NOT NULL, -- waardelijst municipal_legal_framework + municipality_code TEXT NOT NULL, + assignment_number TEXT NOT NULL, + product_category TEXT NOT NULL, -- waardelijst municipal_product_category + product_code TEXT NOT NULL, + volume NUMERIC NOT NULL, + unit TEXT NOT NULL, -- waardelijst municipal_product_unit + frequency TEXT NOT NULL, + start_date DATE NOT NULL, + end_date DATE, + issued_at TIMESTAMPTZ NOT NULL, + replaces_assignment_id UUID REFERENCES municipal_care_assignment(id), + replacement_reason TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT municipal_care_assignment_replacement_reason_required CHECK ( + replaces_assignment_id IS NULL OR (replacement_reason IS NOT NULL AND length(trim(replacement_reason)) > 0) + ), + CONSTRAINT municipal_care_assignment_no_self_replace CHECK (replaces_assignment_id <> id) +); + +CREATE UNIQUE INDEX idx_municipal_care_assignment_replaces_unique ON municipal_care_assignment(replaces_assignment_id) WHERE replaces_assignment_id IS NOT NULL AND deleted_at IS NULL; +CREATE UNIQUE INDEX idx_municipal_care_assignment_number ON municipal_care_assignment(municipality_code, assignment_number) WHERE deleted_at IS NULL; + +COMMENT ON TABLE municipal_care_assignment IS 'model-instroom.md §2.15 (voorstel, juridisch onderzoek 19 juli). Naast, niet in plaats van professional_referral (Jeugdwet kent een eigen professionele verwijsroute).'; + +ALTER TABLE municipal_care_assignment ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON municipal_care_assignment FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_municipal_care_assignment_updated_at BEFORE UPDATE ON municipal_care_assignment FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- legal_mandate +-- ============================================================================ +CREATE TABLE legal_mandate ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + referral_case_id UUID NOT NULL REFERENCES referral_case(id) ON DELETE RESTRICT, + mandate_type TEXT NOT NULL, -- waardelijst mandate_type + decision_reference TEXT NOT NULL, + decided_by_role TEXT NOT NULL, -- waardelijst mandate_decider_role + decided_at TIMESTAMPTZ NOT NULL, + medical_statement_reference UUID, -- documentopslag + effectuated_at TIMESTAMPTZ NOT NULL, + valid_from TIMESTAMPTZ NOT NULL, + valid_until TIMESTAMPTZ, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT legal_mandate_type_check CHECK (mandate_type IN ('crisismaatregel', 'zorgmachtiging')), + CONSTRAINT legal_mandate_medical_statement_required CHECK ( + mandate_type <> 'crisismaatregel' OR medical_statement_reference IS NOT NULL + ) +); + +CREATE INDEX idx_legal_mandate_case ON legal_mandate(referral_case_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE legal_mandate IS 'model-instroom.md §2.16 (voorstel, juridisch onderzoek 19 juli). Geen vervangt-relatie: een crisismaatregel die overgaat in een zorgmachtiging is een nieuw mandaat.'; + +ALTER TABLE legal_mandate ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON legal_mandate FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_legal_mandate_updated_at BEFORE UPDATE ON legal_mandate FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- crisis_encounter_note +-- ============================================================================ +CREATE TABLE crisis_encounter_note ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + referral_case_id UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE, + occurred_at TIMESTAMPTZ NOT NULL, + recorded_by UUID NOT NULL REFERENCES practitioners(id), + fact_type TEXT NOT NULL, -- waardelijst crisis_fact_type + description TEXT NOT NULL, + structured_value JSONB, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +CREATE INDEX idx_crisis_encounter_note_case ON crisis_encounter_note(referral_case_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE crisis_encounter_note IS 'model-instroom.md §2.17 (voorstel). Werkt al zonder geïdentificeerde persoon. 14-dagen-identificatienudge hangt aan referral_request.person_identified_at IS NULL, geen constraint hier.'; + +ALTER TABLE crisis_encounter_note ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON crisis_encounter_note FOR ALL USING (auth.role() = 'authenticated'); + +-- ============================================================================ +-- clinical_care_episode +-- ============================================================================ +CREATE TABLE clinical_care_episode ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + originating_decision_id UUID REFERENCES care_acceptance_decision(id) ON DELETE RESTRICT, + originating_mandate_id UUID REFERENCES legal_mandate(id) ON DELETE RESTRICT, + started_at TIMESTAMPTZ NOT NULL, + ended_at TIMESTAMPTZ, + end_reason TEXT, -- waardelijst episode_end_reason + possible_continuation_of_episode_id UUID REFERENCES clinical_care_episode(id), + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT clinical_care_episode_origin_xor CHECK ( + (originating_decision_id IS NOT NULL AND originating_mandate_id IS NULL) + OR (originating_decision_id IS NULL AND originating_mandate_id IS NOT NULL) + ), + CONSTRAINT clinical_care_episode_end_reason_required CHECK ( + ended_at IS NULL OR end_reason IS NOT NULL + ), + CONSTRAINT clinical_care_episode_no_self_continuation CHECK (possible_continuation_of_episode_id <> id) +); + +CREATE UNIQUE INDEX idx_clinical_care_episode_decision ON clinical_care_episode(originating_decision_id) WHERE originating_decision_id IS NOT NULL AND deleted_at IS NULL; +CREATE UNIQUE INDEX idx_clinical_care_episode_mandate ON clinical_care_episode(originating_mandate_id) WHERE originating_mandate_id IS NOT NULL AND deleted_at IS NULL; + +COMMENT ON TABLE clinical_care_episode IS 'model-instroom.md §2.18 (alleen ontstaan/einde — volledig episodemodel is een ander deelgebied). XOR: ontstaat óf uit een acceptatiebesluit óf uit een mandaat. possible_continuation_of_episode_id is een zorginhoudelijke aanwijzing, GEEN NZa-trajectnummertoets.'; + +ALTER TABLE clinical_care_episode ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON clinical_care_episode FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_clinical_care_episode_updated_at BEFORE UPDATE ON clinical_care_episode FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- case_urgency_assessment +-- ============================================================================ +CREATE TABLE case_urgency_assessment ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + referral_case_id UUID NOT NULL REFERENCES referral_case(id) ON DELETE CASCADE, + assessed_at TIMESTAMPTZ NOT NULL, + assessed_by UUID NOT NULL REFERENCES practitioners(id), + assessed_in_role TEXT NOT NULL, -- waardelijst urgency_assessor_role + urgency_level TEXT NOT NULL, -- waardelijst urgency_level + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +CREATE INDEX idx_case_urgency_assessment_case ON case_urgency_assessment(referral_case_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE case_urgency_assessment IS 'model-instroom.md §2.19. Herhaalbaar, laatste assessed_at geldt; geen vervangt-relatie (lagere inzet dan een acceptatiebesluit).'; + +ALTER TABLE case_urgency_assessment ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON case_urgency_assessment FOR ALL USING (auth.role() = 'authenticated'); + +-- ============================================================================ +-- episode_team_involvement (minimale, voorlopige hook — zie besluitenlog §10 punt 3) +-- ============================================================================ +CREATE TABLE episode_team_involvement ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + clinical_care_episode_id UUID NOT NULL REFERENCES clinical_care_episode(id) ON DELETE CASCADE, + team_reference TEXT NOT NULL, -- vrije tekst; geen Team-entiteit vóór de zorgteam-ronde + involved_since TIMESTAMPTZ NOT NULL, + recorded_by UUID NOT NULL REFERENCES practitioners(id), + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +CREATE INDEX idx_episode_team_involvement_episode ON episode_team_involvement(clinical_care_episode_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE episode_team_involvement IS 'model-instroom.md §2.20. Bewust minimaal — geen rollen, geen bevoegdheid, geen individueel lidmaatschap. Wordt vervangen/geabsorbeerd door het volledige zorgteam-model (besluitenlog §10 punt 3).'; + +ALTER TABLE episode_team_involvement ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON episode_team_involvement FOR ALL USING (auth.role() = 'authenticated'); diff --git a/supabase/migrations/20260720000004_create_intake_treatment_advice_domain.sql b/supabase/migrations/20260720000004_create_intake_treatment_advice_domain.sql new file mode 100644 index 0000000..43f4659 --- /dev/null +++ b/supabase/migrations/20260720000004_create_intake_treatment_advice_domain.sql @@ -0,0 +1,178 @@ +-- ============================================================================ +-- INTAKE / TREATMENT ADVICE DOMAIN +-- ============================================================================ +-- Created: 2026-07-20 +-- Source: docs/datamodel/deelmodellen/model-intake-behandeladvies.md (5 +-- entiteiten), docs/datamodel/feitenmodellen/feitenmodel-intake-behandeladvies.md, +-- besluiten B31-B34. +-- +-- clinical_intake_assessment hangs off clinical_care_episode (not off +-- referral_case) — it starts at some point after the acceptance decision, +-- possibly after a wait-list period (status = 'gepland' covers that). +-- ============================================================================ + +-- ============================================================================ +-- clinical_intake_assessment +-- ============================================================================ +CREATE TABLE clinical_intake_assessment ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + clinical_care_episode_id UUID NOT NULL REFERENCES clinical_care_episode(id) ON DELETE RESTRICT, + initiation_reason TEXT NOT NULL, -- waardelijst intake_initiation_reason + department TEXT NOT NULL, -- waardelijst department + status TEXT NOT NULL DEFAULT 'gepland', -- waardelijst intake_status + planned_at TIMESTAMPTZ NOT NULL, + started_at TIMESTAMPTZ, + ended_at TIMESTAMPTZ, + abort_reason TEXT, -- waardelijst intake_abort_reason + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT clinical_intake_assessment_status_check CHECK (status IN ('gepland', 'bezig', 'afgerond', 'afgebroken')), + CONSTRAINT clinical_intake_assessment_started_required CHECK ( + status NOT IN ('bezig', 'afgerond', 'afgebroken') OR started_at IS NOT NULL + ), + CONSTRAINT clinical_intake_assessment_ended_required CHECK ( + status NOT IN ('afgerond', 'afgebroken') OR ended_at IS NOT NULL + ), + CONSTRAINT clinical_intake_assessment_abort_reason_required CHECK ( + status <> 'afgebroken' OR abort_reason IS NOT NULL + ) +); + +CREATE INDEX idx_clinical_intake_assessment_episode ON clinical_intake_assessment(clinical_care_episode_id) WHERE deleted_at IS NULL; +CREATE INDEX idx_clinical_intake_assessment_status ON clinical_intake_assessment(status) WHERE deleted_at IS NULL; + +COMMENT ON TABLE clinical_intake_assessment IS 'model-intake-behandeladvies.md §1.1. Start ná het acceptatiebesluit (B31), niet gelijktijdig met episode-ontstaan — planned_at dekt een eventuele intakewachtlijst-periode. "Maximaal één lopende intake per episode" is een aan/uit-zetbare bedrijfsregel, geen schemabeperking.'; + +ALTER TABLE clinical_intake_assessment ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON clinical_intake_assessment FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_clinical_intake_assessment_updated_at BEFORE UPDATE ON clinical_intake_assessment FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- intake_contact +-- ============================================================================ +CREATE TABLE intake_contact ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + clinical_intake_assessment_id UUID NOT NULL REFERENCES clinical_intake_assessment(id) ON DELETE CASCADE, + occurred_at TIMESTAMPTZ NOT NULL, + contact_type TEXT NOT NULL, -- waardelijst intake_contact_type + performed_by UUID NOT NULL REFERENCES practitioners(id), + notes TEXT, + planned_duration_minutes INTEGER, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT intake_contact_duration_non_negative CHECK (planned_duration_minutes IS NULL OR planned_duration_minutes >= 0) +); + +CREATE INDEX idx_intake_contact_assessment ON intake_contact(clinical_intake_assessment_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE intake_contact IS 'model-intake-behandeladvies.md §1.2. Exclusief aan één clinical_intake_assessment; generalisatie naar een bredere consult-/afspraakstructuur is de agenda-ronde.'; + +ALTER TABLE intake_contact ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON intake_contact FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_intake_contact_updated_at BEFORE UPDATE ON intake_contact FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- child_safety_check +-- ============================================================================ +CREATE TABLE child_safety_check ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + clinical_intake_assessment_id UUID NOT NULL REFERENCES clinical_intake_assessment(id) ON DELETE CASCADE, + performed_at TIMESTAMPTZ NOT NULL, + performed_by UUID NOT NULL REFERENCES practitioners(id), + responsible_for_minors BOOLEAN NOT NULL, + minor_count INTEGER, + minor_ages TEXT, -- vrije tekst, bewust geen kindrecords (dataminimalisatie) + safety_concern BOOLEAN NOT NULL, + safety_concern_notes TEXT, + action_taken BOOLEAN NOT NULL, + action_taken_notes TEXT, + pregnancy BOOLEAN NOT NULL, -- vierde vlag, te verifiëren tegen KNMG-meldcode (B34) + notes TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT child_safety_check_safety_notes_required CHECK (NOT safety_concern OR safety_concern_notes IS NOT NULL), + CONSTRAINT child_safety_check_action_notes_required CHECK (NOT action_taken OR action_taken_notes IS NOT NULL) +); + +-- maximaal één per intake +CREATE UNIQUE INDEX idx_child_safety_check_assessment ON child_safety_check(clinical_intake_assessment_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE child_safety_check IS 'model-intake-behandeladvies.md §1.3 (B34). Wet verplichte meldcode / KNMG-kindcheck.'; + +ALTER TABLE child_safety_check ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON child_safety_check FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_child_safety_check_updated_at BEFORE UPDATE ON child_safety_check FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- ============================================================================ +-- intake_mdt_review (minimale, voorlopige hook — zie §6 aldaar) +-- ============================================================================ +CREATE TABLE intake_mdt_review ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + occurred_at TIMESTAMPTZ NOT NULL, + participants TEXT NOT NULL, -- vrije tekst; structurering wacht op de MDO-ronde (B14-B15) + notes TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ +); + +COMMENT ON TABLE intake_mdt_review IS 'model-intake-behandeladvies.md §1.4. Geen eigen FK naar clinical_intake_assessment — gekoppeld via treatment_advice.mdt_review_id, telt pas zodra hij aan een vastgesteld advies hangt. LKS 4.0: dwingend voor settings 3-8, optioneel setting 2, n.v.t. vrijgevestigden.'; + +ALTER TABLE intake_mdt_review ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON intake_mdt_review FOR ALL USING (auth.role() = 'authenticated'); + +-- ============================================================================ +-- treatment_advice +-- ============================================================================ +CREATE TABLE treatment_advice ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + clinical_intake_assessment_id UUID NOT NULL REFERENCES clinical_intake_assessment(id) ON DELETE RESTRICT, + decided_at TIMESTAMPTZ NOT NULL, + decided_by UUID NOT NULL REFERENCES practitioners(id), -- indicerende regiebehandelaar + outcome TEXT NOT NULL, -- waardelijst treatment_advice_outcome + recommended_care_program TEXT, -- waardelijst care_program + rationale TEXT, + mdt_review_id UUID REFERENCES intake_mdt_review(id), + replaces_advice_id UUID REFERENCES treatment_advice(id), + replacement_reason TEXT, + + created_at TIMESTAMPTZ NOT NULL DEFAULT now(), + updated_at TIMESTAMPTZ NOT NULL DEFAULT now(), + deleted_at TIMESTAMPTZ, + + CONSTRAINT treatment_advice_outcome_check CHECK (outcome IN ('in_zorg', 'terugverwijzing', 'doorverwijzing', 'extra_diagnostiek')), + CONSTRAINT treatment_advice_care_program_required CHECK ( + outcome <> 'in_zorg' OR recommended_care_program IS NOT NULL + ), + CONSTRAINT treatment_advice_rationale_required CHECK ( + outcome = 'in_zorg' OR (rationale IS NOT NULL AND length(trim(rationale)) > 0) + ), + CONSTRAINT treatment_advice_replacement_reason_required CHECK ( + replaces_advice_id IS NULL OR (replacement_reason IS NOT NULL AND length(trim(replacement_reason)) > 0) + ), + CONSTRAINT treatment_advice_no_self_replace CHECK (replaces_advice_id <> id) +); + +-- vervangt-keten kan nooit vertakken, zelfde patroon als care_acceptance_decision +CREATE UNIQUE INDEX idx_treatment_advice_replaces_unique ON treatment_advice(replaces_advice_id) WHERE replaces_advice_id IS NOT NULL AND deleted_at IS NULL; +CREATE INDEX idx_treatment_advice_assessment ON treatment_advice(clinical_intake_assessment_id) WHERE deleted_at IS NULL; + +COMMENT ON TABLE treatment_advice IS 'model-intake-behandeladvies.md §1.5 (B32-B33). Geen apart voorafgaand advies — dit object zelf geeft de vervolgrichting. doorverwijzing/terugverwijzing zijn LKS-genormeerd volgtijdelijk (via replaces_advice_id); extra_diagnostiek is praktijkgefundeerd, niet LKS-genormeerd.'; + +ALTER TABLE treatment_advice ENABLE ROW LEVEL SECURITY; +CREATE POLICY "Enable all for authenticated users" ON treatment_advice FOR ALL USING (auth.role() = 'authenticated'); +CREATE TRIGGER update_treatment_advice_updated_at BEFORE UPDATE ON treatment_advice FOR EACH ROW EXECUTE FUNCTION update_updated_at_column(); + +-- Een afgeronde intake vereist minimaal één (niet noodzakelijk het laatst +-- vervangen) treatment_advice — afgedwongen op applicatieniveau, niet als +-- schema-constraint (zou een circulaire FK-afhankelijkheid vereisen). +COMMENT ON COLUMN clinical_intake_assessment.status IS 'gepland/bezig/afgerond/afgebroken. Bij afgerond hoort minimaal één treatment_advice (applicatieniveau, geen FK-constraint i.v.m. circulaire afhankelijkheid).'; -- 2.39.5 From d5b583e24ad5751cb6575425e5fea3814e62d158 Mon Sep 17 00:00:00 2001 From: colinislit Date: Wed, 29 Jul 2026 08:01:25 +0200 Subject: [PATCH 18/19] docs(datamodel): sessielog avondronde 19 juli Legt de middag-/avondsessie van 19 juli vast die tot nu toe alleen in commit messages en het besluitenlog terug te vinden was: afronding van de instroom-feitenronde (vraag 3-5, entiteiten/cardinaliteiten, B21-B30, synchronisatie begrippenlijst/model-aanmelding) en de nieuwe feitenronde intake/behandeladvies (episode-timing, Treatment Advice, B31-B34). Co-Authored-By: Claude Fable 5 --- .../sessielogs/sessielog-2026-07-19b.md | 266 ++++++++++++++++++ 1 file changed, 266 insertions(+) create mode 100644 docs/datamodel/sessielogs/sessielog-2026-07-19b.md diff --git a/docs/datamodel/sessielogs/sessielog-2026-07-19b.md b/docs/datamodel/sessielogs/sessielog-2026-07-19b.md new file mode 100644 index 0000000..1429179 --- /dev/null +++ b/docs/datamodel/sessielogs/sessielog-2026-07-19b.md @@ -0,0 +1,266 @@ +# Sessielog datamodel — 19 juli 2026 (middag/avond) + +**Status:** chronologisch werkverslag +**Doel:** context, redenering, correcties en voortgang van de sessie bewaren +**Autoriteit:** dit sessielog is niet normatief; bevestigde besluiten staan al +verwerkt in `../besluiten/besluitenlog-datamodel-2026-07-18.md` (B21-B34) +**Vervolg:** bevoegdheidsronde (B16), statusmachines, definitieve +uniqueness-/optionaliteitsconstraints + +## 1. Aanleiding + +Vervolg op `sessielog-2026-07-19.md` (ochtendronde). Deze sessie bestaat uit +twee delen: + +1. afronding van de instroom-feitenronde: entiteiten/cardinaliteiten + afleiden, formaliseren in het besluitenlog, en de begrippenlijst en + `model-aanmelding.md` synchroniseren; +2. een nieuwe, aparte feitenronde voor zorginhoudelijke intake en + behandeladvies, die ook vraag 2 uit `feitenmodel-instroom.md` §7 + (behandeladvies-uitkomsten, sinds de ochtendronde geparkeerd) afsluit. + +Kort na de ochtendronde zijn eerst nog de resterende open vragen 3, 4 en 5 +uit `feitenmodel-instroom.md` §7 afgehandeld (zie §2). Daarna volgde een +langere pauze; het werk aan entiteiten en de nieuwe feitenronde is +'s middags/'s avonds gedaan. + +## 2. Afronding resterende instroomvragen (vraag 3, 4, 5) + +Direct aansluitend op de ochtendronde zijn drie openstaande punten uit +`feitenmodel-instroom.md` §7 beantwoord: + +- **Aanvullende informatie nodig** wordt een gebeurtenisfeit, geen + besluituitkomst en geen statusfase — er bestaat op dat moment nog geen + besluit. +- **Heroverweging na afwijzing** krijgt een expliciete "vervangt"-relatie + tussen acceptatiebesluiten, met verplichte reden en dezelfde + bevoegdheidseis als het origineel. +- **Intrekking vóór start intake** krijgt twee routes: cliënt-intrekking + zonder bevoegdheidseis, en institutionele correctie met dezelfde + bevoegdheid als het origineel. In beide gevallen wordt een al ontstane + zorgepisode altijd afgesloten, nooit verwijderd. + +Referral Case krijgt daarmee een tijdlijn-gebaseerde stand in plaats van een +vaste lineaire statusmachine. Alleen vraag 2 (behandeladvies-uitkomsten) +bleef op dit moment nog open. + +## 3. Entiteiten en cardinaliteiten instroom + +`../deelmodellen/model-instroom.md` is toegevoegd: de eerste +entiteiten-/cardinaliteitenafleiding uit `feitenmodel-instroom.md`. 20 +entiteiten, Engelstalig conform B20, met een vervangt-patroon voor +herzieningen en een tijdlijn in plaats van een statusmachine voor Referral +Case. + +Vier reviewrondes zijn verwerkt vóór het model als afgerond werd beschouwd: + +1. **Technische en GGZ-domeinreview** — vertakkende vervangt-keten gefixed + (uniek per vervangen exemplaar, geen boomstructuur), timestamp-precisie + gecorrigeerd, ontbrekende ZPM-velden hersteld. +2. **Tweede ronde met datamodel-, GGZ-domein- en UX-expert-agents** — lege + screening-entiteit vervallen verklaard (screening is activiteit, geen + besluitobject — consistent met B21), naamgeving aangescherpt, + cardinaliteitsfout gecorrigeerd, een read-model-eis toegevoegd. +3. **GGZ-wetgeving-onderzoek** (Wvggz, Wmo/Jeugdwet, 275-dagentoets, + 365-dagenregel, crisisdocumentatie) vertaald naar nieuwe entiteiten: + `municipal_care_assignment`, `legal_mandate`, `crisis_encounter_note`. +4. **Domeinreview eigenaarschap/urgentie met Colin** — een herhaalbare + urgentiebeoordeling (`case_urgency_assessment`, geen vast veld) en een + bewust minimale hook voor teambetrokkenheid + (`episode_team_involvement`); het volledige zorgteam-model blijft een + aparte, nog te plannen ronde (bevestigt B16). + +Ook is in `feitenmodel-instroom.md` de vraag "verzoek zonder bekende +persoon" (crisisaanmelding) beantwoord: geen placeholder-persoon, de +koppeling aan een persoon wordt een eigen, gedateerd feit dat pas ontstaat +zodra de identiteit bekend is. + +## 4. Formalisering in het besluitenlog: B21-B30 + +De uitkomst van de instroom-feitenronde en het entiteitenmodel is +vastgelegd als B21-B30 in +`../besluiten/besluitenlog-datamodel-2026-07-18.md`: + +| # | Kern | +|---|------| +| B21 | Screeningsbesluit = acceptatiebesluit, geen apart voorafgaand advies | +| B22 | Besluituitkomst (`geaccepteerd`/`afgewezen`), vervolgroute en onderbouwing zijn losse feiten; elk positief besluit laat een episode ontstaan, ook bij vervolgroute intakewachtlijst | +| B23 | Herziening via expliciete, unieke vervangt-relatie met verplichte reden en gelijke bevoegdheidseis | +| B24 | Cliënt-intrekking vereist geen beslisbevoegdheid; een ontstane episode wordt altijd afgesloten, nooit verwijderd | +| B25 | Geen statusmachine — actuele stand afgeleid uit een gebeurtenistijdlijn (aansluitend bij B7) | +| B26 | Zorgverzoek kan zonder bekende persoon bestaan; koppeling is een eigen, gedateerd feit | +| B27 | Wmo/Jeugdwet-toewijzing en Wvggz-mandaat zijn eigen instroomroutes naast de professionele verwijzing | +| B28 | Gestructureerde crisisdocumentatie kan vóór identificatie al vastgelegd worden | +| B29 | Urgentie is een herhaalbare beoordeling, geen vast veld | +| B30 | Minimale hook voor teambetrokkenheid; het volledige zorgteam-model blijft een aparte ronde | + +Ook §10 van het besluitenlog is bijgewerkt: afgeronde punten gemarkeerd, +de juridische verificatie- en behandeladvies-onderzoekspunten toegevoegd, +en genoteerd dat het AANMELDING/VERWIJZING/ZORGEPISODE-deel van +`model-aanmelding.md` is vervangen door `model-instroom.md` +(synchronisatie als eerstvolgende stap). + +## 5. Synchronisatie begrippenlijst en model-aanmelding + +`../begrippenlijst-kernmodel.md` §3 vervangt de voorlopige werktermen +(Inbound Care Signal, Access Assessment Case, Presenting Care Need, +Screening Recommendation) door de bevestigde instroom-begrippen: Referral +Request/Submission/Case, Professional/Municipal Referral, Legal Mandate, +Case Information Request/Withdrawal, Crisis Encounter Note, Case Urgency +Assessment. §10 bijgewerkt: opgeloste terminologievragen gemarkeerd, +Wvggz/Wmo-Jeugdwet-aannames toegevoegd als nieuw juridisch te bevestigen +punt. + +`../deelmodellen/model-aanmelding.md`: AANMELDING/VERWIJZING/ +VERWIJSDOCUMENT/TOEWIJZING/ZORGEPISODE (§2.10-§2.13, §2.15) +niet-destructief gemarkeerd als vervallen met verwijzing naar de +vervangende entiteit in `model-instroom.md` — de tekst blijft als +historisch werkdocument staan, consistent met het niet-destructieve +patroon dat elders in het datamodel wordt toegepast. +PERSOON/CLIENT/CLIENTRELATIE/VERWIJZER/PRAKTIJK_INSTELLING/ +CLIENT_HUISARTS/VERZEKERING/TOESTEMMING/CLIENTPORTAAL_ACCOUNT +(§2.1-§2.9, §2.14, §2.16) blijven ongewijzigd en behouden hun +sectienummers, waar `model-instroom.md` extern naar verwijst. + +Ook zijn twee foutieve padverwijzingen in `model-instroom.md` §4 +gecorrigeerd (waardelijsten verwezen naar de verkeerde sectie in +`model-aanmelding.md`). + +## 6. Nieuwe feitenronde: intake en behandeladvies + +Na afronding van de instroomronde is direct doorgewerkt aan een nieuwe +FCO-IM-feitenronde voor de zorginhoudelijke intake. Als werkdocument is +`../feitenmodellen/feitenmodel-intake-behandeladvies.md` opgesteld, met +feitzinnen, scenariotoetsen en domeinreview voor Clinical Intake +Assessment, Intake Contact, Child Safety Check en Treatment Advice. + +### 6.1 Episode-timing gecorrigeerd + +De intake hangt aan de zorgepisode, niet aan het aanmeldingstraject, en +start op enig moment ná het acceptatiebesluit dat de episode liet +ontstaan — mogelijk pas na een periode op de intakewachtlijst. Dit trekt +de consequentie door van B22 (episode ontstaat al bij acceptatie, niet bij +een aanmelding-uitkomst "intake" die niet meer bestaat) voor de intake +zelf. + +### 6.2 Behandeladvies als eigen object + +Net als bij het acceptatiebesluit (B21) bestaat er geen apart, voorafgaand +behandeladvies naast een later formeel besluit: het behandeladvies zelf +draagt de uitkomst en de vervolgrichting. Het krijgt wel een eigen +identiteit los van de intake (Treatment Advice), naar het patroon van Care +Acceptance Decision. Een behandeladvies kan een eerder advies van dezelfde +intake vervangen bij heroverweging, met dezelfde vervangt-constructie als +bij herziening van het acceptatiebesluit (B23). + +Dit sluit `feitenmodel-instroom.md` §7 vraag 2 af, die sinds de +ochtendronde geparkeerd stond. + +### 6.3 Vier behandeladvies-uitkomsten + +Op basis van volledige LKS 4.0-teksttoetsing (niet alleen samenvattingen): + +- Vier uitkomsten: `in_zorg`, `terugverwijzing`, `doorverwijzing`, + `extra_diagnostiek`. +- `Doorverwijzing` en `terugverwijzing` zijn volgens LKS 4.0 (patient + journey fase 2-3, §3.6.2) een **volgtijdelijk paar** — eerst een + inspanningsverplichting tot doorverwijzing, pas daarna terugverwijzing — + geen twee gelijkwaardige, onafhankelijke uitkomsten. De volgorde wordt + gedekt door het vervangt-mechanisme uit §6.2, niet door een aparte + sequentie-regel. +- `Extra_diagnostiek` is praktijkgefundeerd, nergens in LKS 4.0 als + zodanig benoemd — bewust behouden, maar expliciet gemarkeerd als + praktijkkeuze, geen landelijke norm. +- Gedeeld/onduidelijk advies bij twijfel tussen behandelaren krijgt geen + eigen uitkomstwaarde: LKS 4.0 §3.6.2 lost dit institutioneel op. +- Een cliënt die afziet van het geadviseerde vervolg is een later, apart + feit, geen behandeladvies-uitkomst (analoog aan planakkoord, B13). +- Wachtlijst voor behandelcapaciteit is een vervolgroute na `in_zorg`, + zelfde precedent als bij het acceptatiebesluit. + +### 6.4 Bevoegdheid en MDT-bespreking + +LKS 4.0 maakt onderscheid tussen wie de intake verricht en wie de uitkomst +vaststelt (regiebehandelaar, indicerende rol). Voor settings 3-8 is +MDT-bespreking een **dwingende landelijke norm** (LKS 4.0 Tabel 2), niet +instellingsbeleid; voor setting 2 optioneel; voor vrijgevestigden niet van +toepassing. Verwerkt als rol-attribuut plus een optionele MDT-hook +(`intake_mdt_review`) — de precieze verplichtingsregel per setting hoort +bij de bredere bevoegdheidsronde (B16) en vereist een setting-registratie +die nu nog niet bestaat. + +### 6.5 Kindcheck-structuur + +De bestaande prototypestructuur (drie ja/nee-vlaggen met verplichte +toelichting bij "ja") blijft de kern, met vlag 1 verbreed van +"thuiswonende kinderen" naar "verantwoordelijk voor minderjarigen" +(KNMG-meldcode: ook co-ouderschap en andere zorgrelaties tellen). Een +vierde vlag ("zwangerschap van cliënt of partner") is toegevoegd — de +KNMG-kindcheck rekent het ongeboren kind expliciet mee. Deze vierde vlag +is op basis van algemene domeinkennis toegevoegd, niet uit eerder +verzamelde onderzoeksrapporten, en moet nog tegen de actuele +meldcode-tekst geverifieerd worden. + +## 7. Nieuwe entiteiten en besluiten B31-B34 + +`../deelmodellen/model-intake-behandeladvies.md` is toegevoegd: +entiteiten-/cardinaliteitenafleiding voor Clinical Intake Assessment, +Intake Contact, Child Safety Check en Treatment Advice. + +In het besluitenlog vastgelegd: + +- **B31** — Intake hangt aan de zorgepisode, start ná het + acceptatiebesluit (§6.1). +- **B32** — Behandeladvies is een eigen object dat de intake afrondt, geen + apart voorafgaand advies (§6.2). +- **B33** — Vier behandeladvies-uitkomsten, deels LKS-genormeerd (§6.3), + met de bevoegdheidsmatrix-vraag doorverwezen naar B16 (§6.4). +- **B34** — Kindcheck-structuur bevestigd, vierde vlag toegevoegd (§6.5). + +`../begrippenlijst-kernmodel.md` §4 is gesynchroniseerd (Treatment Advice +en Child Safety Check zijn nieuwe begrippen; Clinical Intake Assessment en +Intake Contact bestonden al als werkterm). Het oudere +`../deelmodellen/model-intake.md` is niet-destructief gemarkeerd als +vervangen, consistent met hoe `model-aanmelding.md` eerder is behandeld. + +## 8. Open punten + +### Instroom + +Vrijwel volledig afgerond via B21-B30; het enige resterende punt is de +bevoegdheidsmatrix (zie hieronder, gedeeld met intake/behandeladvies). + +### Intake en behandeladvies + +1. Exacte bevoegdheidsmatrix per setting (welke settings precies wanneer + MDT-bespreking vereisen, en de rolinvulling daarvan) — deel van de + bredere bevoegdheidsronde (B16); het principe (rol + optioneel + MDT-feit) staat al vast, de detailinvulling niet. +2. Is `extra_diagnostiek` altijd een volledig nieuw, vervangend Treatment + Advice, of kan de bestaande intake simpelweg langer "bezig" blijven + zonder tussentijdse afronding? Beide patronen zijn nu toegestaan, welke + de praktijk het vaakst gebruikt is nog niet getoetst. +3. Vierde kindcheck-vlag (zwangerschap) nog te verifiëren tegen de actuele + meldcode-tekst. +4. Contactmoment-generalisatie naar een bredere consult-/afspraakstructuur + blijft uitdrukkelijk een latere (agenda-)ronde. + +### Nog niet opgepakt (aansluitend, uit eerdere sessies) + +- Het volledige zorgteam-model (leden, rollen, regiebehandelaarschap, + bevoegdheid, mogelijk toekomstige cliëntautorisatie) — bevestigd als + aparte ronde in B30. +- Definitieve statusmachines waar die nog ontbreken. + +## 9. Afgesproken volgende stap + +1. Definitieve uniqueness- en optionaliteitsconstraints voor zowel + instroom als intake/behandeladvies. +2. Bevoegdheidsronde (B16): setting-registratie en de volledige + bevoegdheidsmatrix (MDT-bespreking, regiebehandelaarschap, indicerende + rol). +3. Verificatie van de vierde kindcheck-vlag tegen de actuele + meldcode-tekst. +4. Beslissen of `extra_diagnostiek` altijd een vervangend Treatment Advice + vereist, op basis van praktijktoetsing. +5. Zorgteam-model als aparte ronde plannen (B30). -- 2.39.5 From 0db3ec2ce11ab4eb9d6b8d2fff678e8e86a38051 Mon Sep 17 00:00:00 2001 From: colinislit Date: Wed, 29 Jul 2026 08:01:38 +0200 Subject: [PATCH 19/19] docs(datamodel): Mermaid ER-diagrammen voor alle actuele deelmodellen MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Voegt docs/datamodel/diagrammen/ toe: één self-contained HTML per deelmodel (instroom, aanmelding, behandelplan, diagnose, intake-behandeladvies, rapportage, screening, wachtlijst), elk met een Mermaid erDiagram, blueprint-vormgeving en sleep/scroll pan-zoom (mermaid.js + svg-pan-zoom via CDN, geen serverside build nodig). Per diagram alleen sleutel-/FK-attributen en de kernrelaties uit de §2/§3 entiteiten-/cardinaliteitensecties van het bijbehorende deelmodel, niet elk veld — bedoeld als navigeerbaar overzicht naast de tabelvorm, niet als vervanging ervan. Scope-keuzes: - model-intake.md en datamodel-discovery.md zijn overgeslagen: eerstgenoemde is volledig vervangen door model-intake-behandeladvies.md, laatstgenoemde is een prosedocument zonder entiteitenstructuur. - model-aanmelding.md toont alleen de nog geldige PERSOON/CLIENT-kern; AANMELDING/VERWIJZING/ZORGEPISODE zijn vervangen door model-instroom.md en daar al gediagrammeerd. - model-screening.md krijgt een expliciete waarschuwing in titel en bronregel: het losse screeningsbesluit is achterhaald door besluit B21 (screeningsbesluit = acceptatiebesluit, nu care_acceptance_decision in model-instroom.md). - model-behandelplan.md, model-rapportage.md en model-wachtlijst.md tonen een statusnotitie (in herziening resp. deels herzien resp. voorlopig onderzoeksmodel) conform hun documentstatus. Co-Authored-By: Claude Fable 5 --- .../diagrammen/model-aanmelding-erd.html | 332 +++++++++++++++ .../diagrammen/model-behandelplan-erd.html | 336 +++++++++++++++ .../diagrammen/model-diagnose-erd.html | 345 ++++++++++++++++ .../diagrammen/model-instroom-erd.html | 390 ++++++++++++++++++ .../model-intake-behandeladvies-erd.html | 295 +++++++++++++ .../diagrammen/model-rapportage-erd.html | 339 +++++++++++++++ .../diagrammen/model-screening-erd.html | 303 ++++++++++++++ .../diagrammen/model-wachtlijst-erd.html | 297 +++++++++++++ 8 files changed, 2637 insertions(+) create mode 100644 docs/datamodel/diagrammen/model-aanmelding-erd.html create mode 100644 docs/datamodel/diagrammen/model-behandelplan-erd.html create mode 100644 docs/datamodel/diagrammen/model-diagnose-erd.html create mode 100644 docs/datamodel/diagrammen/model-instroom-erd.html create mode 100644 docs/datamodel/diagrammen/model-intake-behandeladvies-erd.html create mode 100644 docs/datamodel/diagrammen/model-rapportage-erd.html create mode 100644 docs/datamodel/diagrammen/model-screening-erd.html create mode 100644 docs/datamodel/diagrammen/model-wachtlijst-erd.html diff --git a/docs/datamodel/diagrammen/model-aanmelding-erd.html b/docs/datamodel/diagrammen/model-aanmelding-erd.html new file mode 100644 index 0000000..4a0c9f6 --- /dev/null +++ b/docs/datamodel/diagrammen/model-aanmelding-erd.html @@ -0,0 +1,332 @@ + + + + + +Aanmelding — entiteit-relatiediagram + + + + +
+
+
+

Aanmelding — entiteit-relatiediagram

+ model-aanmelding.md §2 · 11 entiteiten · 12 relaties · AANMELDING/VERWIJZING/ZORGEPISODE vervangen door model-instroom.md (niet getoond) +
+
+ + + + +
+
+ +
+
Diagram wordt geladen…
+
+erDiagram + PERSOON { + uuid id PK + string achternaam + date geboortedatum + string bsn + } + ADRES { + uuid id PK + uuid persoon_id FK + string adrestype + string postcode + date geldig_tot + } + CONTACTGEGEVEN { + uuid id PK + uuid persoon_id FK + string contacttype + string waarde + boolean voorkeur + } + CLIENT { + uuid id PK + uuid persoon_id FK + string clientnummer + date client_sinds + string huisarts_situatie + } + CLIENTRELATIE { + uuid id PK + uuid client_id FK + uuid persoon_id FK + string relatie + string rol + date geldig_van + } + VERWIJZER { + uuid id PK + uuid praktijk_instelling_id FK + string naam + string verwijzertype + string agb_code + } + PRAKTIJK_INSTELLING { + uuid id PK + string naam + string soort + string agb_code + } + CLIENT_HUISARTS { + uuid id PK + uuid client_id FK + uuid verwijzer_id FK + uuid praktijk_instelling_id FK + date geldig_van + } + VERZEKERING { + uuid id PK + uuid client_id FK + string uzovi_code + string polisnummer + date geldig_van + } + TOESTEMMING { + uuid id PK + uuid client_id FK + string toestemmingstype + string status + date datum + } + CLIENTPORTAAL_ACCOUNT { + uuid id PK + uuid client_id FK + } + + PERSOON ||--o{ ADRES : "persoon_id" + PERSOON ||--o{ CONTACTGEGEVEN : "persoon_id" + PERSOON ||--o| CLIENT : "persoon_id" + CLIENT ||--o{ CLIENTRELATIE : "client_id" + PERSOON ||--o{ CLIENTRELATIE : "persoon_id" + PRAKTIJK_INSTELLING |o--o{ VERWIJZER : "praktijk_instelling_id" + CLIENT ||--o{ CLIENT_HUISARTS : "client_id" + VERWIJZER |o--o{ CLIENT_HUISARTS : "verwijzer_id" + PRAKTIJK_INSTELLING |o--o{ CLIENT_HUISARTS : "praktijk_instelling_id" + CLIENT ||--o{ VERZEKERING : "client_id" + CLIENT ||--o{ TOESTEMMING : "client_id" + CLIENT ||--o| CLIENTPORTAAL_ACCOUNT : "client_id" +
+
sleep om te pannen · scroll om te zoomen
+
+
+ + + + + + + diff --git a/docs/datamodel/diagrammen/model-behandelplan-erd.html b/docs/datamodel/diagrammen/model-behandelplan-erd.html new file mode 100644 index 0000000..6d8a58d --- /dev/null +++ b/docs/datamodel/diagrammen/model-behandelplan-erd.html @@ -0,0 +1,336 @@ + + + + + +Behandelplan — entiteit-relatiediagram + + + + +
+
+
+

Behandelplan — entiteit-relatiediagram

+ model-behandelplan.md §2 · 12 entiteiten · 20 relaties · in structurele herziening — zie besluitenlog §5 B11 (één levend behandelplan met formele snapshots i.p.v. losse versie-records) +
+
+ + + + +
+
+ +
+
Diagram wordt geladen…
+
+erDiagram + ZORGEPISODE { + uuid id PK + } + DIAGNOSE { + uuid id PK + } + INTAKE { + uuid id PK + } + MEDEWERKER { + uuid id PK + } + PERSOON { + uuid id PK + } + BEHANDELPLAN { + uuid id PK + uuid zorgepisode_id FK + uuid vervangt_plan_id FK + uuid gebaseerd_op_intake_id FK + uuid opgesteld_door FK + uuid regiebehandelaar_id FK + uuid vastgesteld_door FK + integer versienummer + string status + date vastgesteld_op + } + BEHANDELPLAN_DIAGNOSE { + uuid behandelplan_id FK + uuid diagnose_id FK + } + BEHANDELDOEL { + uuid id PK + uuid behandelplan_id FK + uuid diagnose_id FK + uuid overgenomen_van_doel_id FK + string omschrijving + string prioriteit + string status + } + INTERVENTIE { + uuid id PK + uuid behandelplan_id FK + uuid uitvoerder_id FK + string interventietype + string extern_systeem + string extern_kenmerk + } + INTERVENTIE_DOEL { + uuid interventie_id FK + uuid behandeldoel_id FK + } + EVALUATIEMOMENT { + uuid id PK + uuid behandelplan_id FK + uuid uitgevoerd_door FK + string evaluatietype + date gepland_op + string uitkomst + } + BEHANDELPLAN_AKKOORD { + uuid id PK + uuid behandelplan_id FK + uuid gegeven_door_persoon_id FK + uuid vastgelegd_door FK + date datum + string wijze + string gegeven_door_type + } + + ZORGEPISODE ||--o{ BEHANDELPLAN : "zorgepisode_id" + BEHANDELPLAN |o--o| BEHANDELPLAN : "vervangt_plan_id (self)" + INTAKE |o--o{ BEHANDELPLAN : "gebaseerd_op_intake_id (0..1)" + BEHANDELPLAN ||--o{ BEHANDELPLAN_DIAGNOSE : "diagnoses" + DIAGNOSE ||--o{ BEHANDELPLAN_DIAGNOSE : "plannen" + BEHANDELPLAN ||--o{ BEHANDELDOEL : "doelen" + DIAGNOSE |o--o{ BEHANDELDOEL : "diagnose_id (optioneel)" + BEHANDELDOEL |o--o{ BEHANDELDOEL : "overgenomen_van_doel_id (self)" + BEHANDELPLAN ||--o{ INTERVENTIE : "interventies" + INTERVENTIE ||--o{ INTERVENTIE_DOEL : "doelkoppelingen" + BEHANDELDOEL ||--o{ INTERVENTIE_DOEL : "interventiekoppelingen" + BEHANDELPLAN ||--o{ EVALUATIEMOMENT : "evaluatiemomenten" + BEHANDELPLAN ||--o{ BEHANDELPLAN_AKKOORD : "akkoorden" + MEDEWERKER ||--o{ BEHANDELPLAN : "opgesteld_door" + MEDEWERKER |o--o{ BEHANDELPLAN : "regiebehandelaar_id" + MEDEWERKER |o--o{ BEHANDELPLAN : "vastgesteld_door" + MEDEWERKER |o--o{ INTERVENTIE : "uitvoerder_id" + MEDEWERKER |o--o{ EVALUATIEMOMENT : "uitgevoerd_door" + MEDEWERKER ||--o{ BEHANDELPLAN_AKKOORD : "vastgelegd_door" + PERSOON |o--o{ BEHANDELPLAN_AKKOORD : "gegeven_door_persoon_id" +
+
sleep om te pannen · scroll om te zoomen
+
+
+ + + + + + + diff --git a/docs/datamodel/diagrammen/model-diagnose-erd.html b/docs/datamodel/diagrammen/model-diagnose-erd.html new file mode 100644 index 0000000..507078d --- /dev/null +++ b/docs/datamodel/diagrammen/model-diagnose-erd.html @@ -0,0 +1,345 @@ + + + + + +Diagnose — entiteit-relatiediagram + + + + +
+
+
+

Diagnose — entiteit-relatiediagram

+ model-diagnose.md §2–§3 · 13 entiteiten · 19 relaties +
+
+ + + + +
+
+ +
+
Diagram wordt geladen…
+
+erDiagram + ZORGEPISODE { + uuid id PK + } + INTAKE { + uuid id PK + } + MEDEWERKER { + uuid id PK + } + BEHANDELPLAN { + uuid id PK + } + DIAGNOSE { + uuid id PK + uuid zorgepisode_id FK + uuid dsm_classificatie_id FK + uuid gesteld_tijdens_intake_id FK + uuid definitief_door FK + uuid geregistreerd_door FK + uuid vervangen_door_diagnose_id FK + string verificatiestatus + string klinische_status + string afgeleide_icd10_code + } + DSM_CLASSIFICATIE { + uuid id PK + uuid dsm_hoofdgroep_id FK + string dsm_code + string omschrijving + boolean selecteerbaar + } + DSM_HOOFDGROEP { + uuid id PK + string code + string omschrijving + } + DSM_ICD10_MAPPING { + uuid id PK + uuid dsm_classificatie_id FK + string icd10_code + boolean voorkeur + string lijstversie + } + HOOFDDIAGNOSE_AANWIJZING { + uuid id PK + uuid zorgepisode_id FK + uuid diagnose_id FK + uuid aangewezen_door FK + date geldig_van + date geldig_tot + } + HONOS_AFNAME { + uuid id PK + uuid zorgepisode_id FK + uuid afgenomen_door FK + string instrument + date afgenomen_op + } + HONOS_ITEMSCORE { + uuid id PK + uuid honos_afname_id FK + string honos_item + int score + } + ZORGVRAAGTYPERING { + uuid id PK + uuid zorgepisode_id FK + uuid honos_afname_id FK + uuid gekozen_door FK + string soort + string gekozen_zorgvraagtype + date gekozen_op + } + ZORGVRAAGTYPE_ADVIES { + uuid id PK + uuid zorgvraagtypering_id FK + string zorgvraagtype + int rangorde + } + + ZORGEPISODE ||--o{ DIAGNOSE : "zorgepisode_id (extern, module zorgepisode)" + INTAKE |o--o{ DIAGNOSE : "gesteld_tijdens_intake_id (extern, module intake)" + DSM_CLASSIFICATIE ||--o{ DIAGNOSE : "dsm_classificatie_id" + DSM_HOOFDGROEP ||--o{ DSM_CLASSIFICATIE : "dsm_hoofdgroep_id" + DSM_CLASSIFICATIE ||--o{ DSM_ICD10_MAPPING : "dsm_classificatie_id (mapping naar ICD-10)" + ZORGEPISODE ||--o{ HOOFDDIAGNOSE_AANWIJZING : "zorgepisode_id (extern)" + DIAGNOSE ||--o{ HOOFDDIAGNOSE_AANWIJZING : "diagnose_id" + DIAGNOSE |o--o| DIAGNOSE : "vervangen_door_diagnose_id (self)" + ZORGEPISODE ||--o{ HONOS_AFNAME : "zorgepisode_id (extern)" + HONOS_AFNAME ||--o{ HONOS_ITEMSCORE : "honos_afname_id (max 19 items)" + HONOS_AFNAME ||--o| ZORGVRAAGTYPERING : "honos_afname_id (uniek)" + ZORGEPISODE ||--o{ ZORGVRAAGTYPERING : "zorgepisode_id (extern)" + ZORGVRAAGTYPERING ||--o{ ZORGVRAAGTYPE_ADVIES : "zorgvraagtypering_id" + MEDEWERKER ||--o{ DIAGNOSE : "geregistreerd_door (extern, module medewerker)" + MEDEWERKER |o--o{ DIAGNOSE : "definitief_door (optioneel, extern)" + MEDEWERKER ||--o{ HONOS_AFNAME : "afgenomen_door (extern)" + MEDEWERKER ||--o{ ZORGVRAAGTYPERING : "gekozen_door (extern)" + MEDEWERKER ||--o{ HOOFDDIAGNOSE_AANWIJZING : "aangewezen_door (extern)" + BEHANDELPLAN }o--o{ DIAGNOSE : "adresseert diagnose (extern, module behandelplan)" +
+
sleep om te pannen · scroll om te zoomen
+
+
+ + + + + + + diff --git a/docs/datamodel/diagrammen/model-instroom-erd.html b/docs/datamodel/diagrammen/model-instroom-erd.html new file mode 100644 index 0000000..409279f --- /dev/null +++ b/docs/datamodel/diagrammen/model-instroom-erd.html @@ -0,0 +1,390 @@ + + + + + +Instroom — entiteit-relatiediagram + + + + +
+
+
+

Instroom — entiteit-relatiediagram

+ model-instroom.md §2–§3 · 20 entiteiten · 29 relaties +
+
+ + + + +
+
+ +
+
Diagram wordt geladen…
+
+erDiagram + PERSOON { + uuid id PK + } + referral_request { + uuid id PK + uuid person_id FK + timestamp initiated_at + string initiator_type + text presenting_need_text + } + referral_submission { + uuid id PK + timestamp received_at + string channel + } + submission_document { + uuid id PK + uuid submission_id FK + string document_type + } + submission_request_link { + uuid submission_id FK + uuid referral_request_id FK + timestamp established_at + } + submission_duplicate_assessment { + uuid submission_id FK + uuid duplicate_of_submission_id FK + timestamp assessed_at + } + referral_case { + uuid id PK + uuid person_id FK + timestamp opened_at + string wettelijk_kader + } + submission_case_assignment { + uuid submission_id FK + uuid referral_case_id FK + timestamp assigned_at + } + request_case_link { + uuid referral_request_id FK + uuid referral_case_id FK + date since + } + case_consolidation { + uuid primary_case_id FK + uuid related_case_id FK + timestamp designated_at + } + screening_activity { + uuid id PK + uuid referral_case_id FK + string activity_type + } + case_information_request { + uuid id PK + uuid referral_case_id FK + uuid resolved_by_submission_id FK + timestamp requested_at + } + care_acceptance_decision { + uuid id PK + uuid referral_case_id FK + uuid replaces_decision_id FK + string decision_outcome + string follow_up_route + } + case_withdrawal { + uuid id PK + uuid referral_case_id FK + timestamp withdrawn_at + } + professional_referral { + uuid id PK + uuid referral_request_id FK + uuid replaces_referral_id FK + date referral_date + } + municipal_care_assignment { + uuid id PK + uuid referral_request_id FK + uuid replaces_assignment_id FK + string legal_framework + } + legal_mandate { + uuid id PK + uuid referral_case_id FK + string mandate_type + } + crisis_encounter_note { + uuid id PK + uuid referral_case_id FK + string fact_type + } + clinical_care_episode { + uuid id PK + uuid originating_decision_id FK + uuid originating_mandate_id FK + uuid possible_continuation_of_episode_id FK + timestamp started_at + } + case_urgency_assessment { + uuid id PK + uuid referral_case_id FK + string urgency_level + } + episode_team_involvement { + uuid id PK + uuid clinical_care_episode_id FK + string team_reference + } + + PERSOON |o--o{ referral_request : "person_id" + PERSOON |o--o{ referral_case : "person_id" + referral_submission ||--o{ submission_document : "documenten" + referral_submission ||--o{ submission_request_link : "koppelingen" + referral_request ||--|{ submission_request_link : "min 1 submission" + referral_submission ||--o{ submission_duplicate_assessment : "als duplicaat" + referral_submission ||--o{ submission_duplicate_assessment : "als origineel" + referral_case ||--|{ submission_case_assignment : "min 1 toewijzing" + referral_submission ||--o{ submission_case_assignment : "toewijzingen" + referral_case ||--|{ request_case_link : "min 1 request" + referral_request ||--|{ request_case_link : "normaliter 1 case" + referral_case ||--o{ case_consolidation : "primary (leidend)" + referral_case ||--o| case_consolidation : "related (uniek)" + referral_case ||--o{ screening_activity : "activiteiten" + referral_case ||--o{ case_information_request : "informatieverzoeken" + referral_submission |o--o| case_information_request : "resolved_by (0..1)" + referral_case ||--o{ care_acceptance_decision : "besluiten" + care_acceptance_decision |o--o| care_acceptance_decision : "vervangt (self)" + referral_case ||--o{ case_withdrawal : "intrekkingen" + referral_request ||--o{ professional_referral : "verwijzingen" + professional_referral |o--o| professional_referral : "vervangt (self)" + referral_request ||--o{ municipal_care_assignment : "toewijzingen" + municipal_care_assignment |o--o| municipal_care_assignment : "vervangt (self)" + referral_case ||--o{ legal_mandate : "mandaten" + referral_case ||--o{ crisis_encounter_note : "notities" + care_acceptance_decision ||--o| clinical_care_episode : "XOR met mandaat" + legal_mandate ||--o| clinical_care_episode : "XOR met besluit" + clinical_care_episode |o--o| clinical_care_episode : "mogelijke vervolg (self)" + referral_case ||--o{ case_urgency_assessment : "beoordelingen" + clinical_care_episode ||--o{ episode_team_involvement : "team-betrokkenheid" +
+
sleep om te pannen · scroll om te zoomen
+
+
+ + + + + + + diff --git a/docs/datamodel/diagrammen/model-intake-behandeladvies-erd.html b/docs/datamodel/diagrammen/model-intake-behandeladvies-erd.html new file mode 100644 index 0000000..b2a67dd --- /dev/null +++ b/docs/datamodel/diagrammen/model-intake-behandeladvies-erd.html @@ -0,0 +1,295 @@ + + + + + +Intake en behandeladvies — entiteit-relatiediagram + + + + +
+
+
+

Intake en behandeladvies — entiteit-relatiediagram

+ model-intake-behandeladvies.md §1–§2 · 7 entiteiten · 7 relaties +
+
+ + + + +
+
+ +
+
Diagram wordt geladen…
+
+erDiagram + clinical_care_episode { + uuid id PK + } + care_program { + uuid id PK + } + clinical_intake_assessment { + uuid id PK + uuid clinical_care_episode_id FK + string initiation_reason + string status + timestamp planned_at + } + intake_contact { + uuid id PK + uuid clinical_intake_assessment_id FK + timestamp occurred_at + string contact_type + int planned_duration_minutes + } + child_safety_check { + uuid id PK + uuid clinical_intake_assessment_id FK + boolean responsible_for_minors + boolean safety_concern + boolean action_taken + } + intake_mdt_review { + uuid id PK + timestamp occurred_at + text participants + } + treatment_advice { + uuid id PK + uuid clinical_intake_assessment_id FK + uuid mdt_review_id FK + uuid replaces_advice_id FK + uuid recommended_care_program FK + string outcome + timestamp decided_at + } + + clinical_care_episode ||--o{ clinical_intake_assessment : "clinical_care_episode_id" + clinical_intake_assessment ||--o{ intake_contact : "clinical_intake_assessment_id" + clinical_intake_assessment ||--o| child_safety_check : "clinical_intake_assessment_id" + clinical_intake_assessment ||--o{ treatment_advice : "clinical_intake_assessment_id" + treatment_advice |o--o| treatment_advice : "vervangt (self)" + intake_mdt_review |o--o| treatment_advice : "mdt_review_id" + care_program |o--o{ treatment_advice : "recommended_care_program" +
+
sleep om te pannen · scroll om te zoomen
+
+
+ + + + + + + diff --git a/docs/datamodel/diagrammen/model-rapportage-erd.html b/docs/datamodel/diagrammen/model-rapportage-erd.html new file mode 100644 index 0000000..561a318 --- /dev/null +++ b/docs/datamodel/diagrammen/model-rapportage-erd.html @@ -0,0 +1,339 @@ + + + + + +Rapportage — entiteit-relatiediagram + + + + +
+
+
+

Rapportage — entiteit-relatiediagram

+ model-rapportage.md §2 · 14 entiteiten · 18 relaties · deels herzien — zie besluitenlog-datamodel-2026-07-18.md §§6, 8 +
+
+ + + + +
+
+ +
+
Diagram wordt geladen…
+
+erDiagram + ZORGEPISODE { + uuid id PK + } + MEDEWERKER { + uuid id PK + } + PERSOON { + uuid id PK + } + INTAKE { + uuid id PK + } + CONTACTMOMENT { + uuid id PK + } + BEHANDELPLAN { + uuid id PK + } + BEHANDELDOEL { + uuid id PK + } + RAPPORTAGE { + uuid id PK + uuid zorgepisode_id FK + uuid auteur_medewerker_id FK + uuid auteur_persoon_id FK + uuid bevestigd_door_medewerker_id FK + uuid vorige_versie_id FK + uuid intake_id FK + uuid contactmoment_id FK + uuid behandelplan_id FK + string rapportagetype_code + text vrije_tekst + string status_code + } + RAPPORTAGESECTIE { + uuid id PK + uuid rapportage_id FK + string sectietype_code + text tekst + } + RAPPORTAGE_DOELKOPPELING { + uuid rapportage_id FK + uuid behandeldoel_id FK + string voortgang_code + } + AI_BRONVERWIJZING { + uuid id PK + string eigenaar_entiteit + uuid eigenaar_id + string bron_entiteit + uuid bron_id + text bron_content_hash + } + INCIDENTDETAIL { + uuid rapportage_id PK, FK + string incidentcategorie_code + text aard + boolean merkbare_gevolgen + } + INCIDENT_BETROKKENE { + uuid id PK + uuid incident_rapportage_id FK + uuid medewerker_id FK + string naam_vrij + } + OVERDRACHTSSAMENVATTING { + uuid id PK + uuid zorgepisode_id FK + uuid bevestigd_door_medewerker_id FK + text samenvatting_tekst + timestamp periode_van + string status_code + } + + ZORGEPISODE ||--o{ RAPPORTAGE : "zorgepisode_id" + MEDEWERKER |o--o{ RAPPORTAGE : "auteur_medewerker_id" + PERSOON |o--o{ RAPPORTAGE : "auteur_persoon_id" + MEDEWERKER |o--o{ RAPPORTAGE : "bevestigd_door_medewerker_id" + RAPPORTAGE |o--o| RAPPORTAGE : "vorige_versie_id (self)" + CONTACTMOMENT |o--o{ RAPPORTAGE : "contactmoment_id" + INTAKE |o--o{ RAPPORTAGE : "intake_id" + BEHANDELPLAN |o--o{ RAPPORTAGE : "behandelplan_id" + RAPPORTAGE ||--o{ RAPPORTAGE_DOELKOPPELING : "rapportage_id" + BEHANDELDOEL ||--o{ RAPPORTAGE_DOELKOPPELING : "behandeldoel_id" + RAPPORTAGE ||--o{ RAPPORTAGESECTIE : "secties (max 1 per sectietype)" + RAPPORTAGE ||--o| INCIDENTDETAIL : "1-op-1 (alleen bij type incident)" + INCIDENTDETAIL ||--o{ INCIDENT_BETROKKENE : "betrokkenen" + MEDEWERKER |o--o{ INCIDENT_BETROKKENE : "medewerker_id (optioneel, xor naam_vrij)" + RAPPORTAGE |o--o{ AI_BRONVERWIJZING : "eigenaar (polymorf, indien eigenaar_entiteit=rapportage)" + OVERDRACHTSSAMENVATTING |o--o{ AI_BRONVERWIJZING : "eigenaar (polymorf, indien eigenaar_entiteit=overdrachtssamenvatting)" + ZORGEPISODE ||--o{ OVERDRACHTSSAMENVATTING : "zorgepisode_id" + MEDEWERKER |o--o{ OVERDRACHTSSAMENVATTING : "bevestigd_door_medewerker_id" +
+
sleep om te pannen · scroll om te zoomen
+
+
+ + + + + + + diff --git a/docs/datamodel/diagrammen/model-screening-erd.html b/docs/datamodel/diagrammen/model-screening-erd.html new file mode 100644 index 0000000..a716c9b --- /dev/null +++ b/docs/datamodel/diagrammen/model-screening-erd.html @@ -0,0 +1,303 @@ + + + + + +Screening — entiteit-relatiediagram (achterhaald) + + + + +
+
+
+

Screening — entiteit-relatiediagram (achterhaald)

+ model-screening.md §2 · 8 entiteiten · 11 relaties · ACHTERHAALD door B21 (screeningsbesluit = acceptatiebesluit, geen apart voorafgaand besluit meer) — zie model-instroom.md (care_acceptance_decision) +
+
+ + + + +
+
+ +
+
Diagram wordt geladen…
+
+erDiagram + AANMELDING { + uuid id PK + } + MEDEWERKER { + uuid id PK + } + VERWIJZER { + uuid id PK + } + DOCUMENT { + uuid id PK + } + SCREENING { + uuid id PK + uuid aanmelding_id FK + uuid screener_id FK + date gestart_op + string status + string urgentie_id + } + SCREENING_ACTIVITEIT { + uuid id PK + uuid screening_id FK + uuid uitgevoerd_door FK + string type_id + timestamp uitgevoerd_op + boolean crisis_signaal + } + SCREENING_BESLUIT { + uuid id PK + uuid screening_id FK + uuid genomen_door FK + string uitkomst_id + string urgentie_id + text motivatie + } + INFORMATIE_UITVRAAG { + uuid id PK + uuid screening_id FK + uuid gericht_aan_verwijzer_id FK + uuid uitgevraagd_door FK + uuid ontvangen_document_id FK + string type_id + string status + } + + AANMELDING ||--o{ SCREENING : "aanmelding_id" + SCREENING ||--o{ SCREENING_ACTIVITEIT : "activiteiten" + SCREENING ||--o| SCREENING_BESLUIT : "besluit (max 1)" + SCREENING ||--o{ INFORMATIE_UITVRAAG : "uitvragen" + MEDEWERKER ||--o{ SCREENING_ACTIVITEIT : "uitgevoerd_door" + MEDEWERKER |o--o{ SCREENING : "screener_id" + MEDEWERKER ||--o{ SCREENING_BESLUIT : "genomen_door" + MEDEWERKER ||--o{ INFORMATIE_UITVRAAG : "uitgevraagd_door" + VERWIJZER |o--o{ INFORMATIE_UITVRAAG : "gericht_aan_verwijzer_id" + DOCUMENT |o--o{ INFORMATIE_UITVRAAG : "ontvangen_document_id" + SCREENING_BESLUIT |o--o| AANMELDING : "onderbouwing uitkomst (0..1)" +
+
sleep om te pannen · scroll om te zoomen
+
+
+ + + + + + + diff --git a/docs/datamodel/diagrammen/model-wachtlijst-erd.html b/docs/datamodel/diagrammen/model-wachtlijst-erd.html new file mode 100644 index 0000000..b457bd3 --- /dev/null +++ b/docs/datamodel/diagrammen/model-wachtlijst-erd.html @@ -0,0 +1,297 @@ + + + + + +Wachtlijst — entiteit-relatiediagram + + + + +
+
+
+

Wachtlijst — entiteit-relatiediagram

+ model-wachtlijst.md §2–§3 · 9 entiteiten · 8 relaties · voorlopig onderzoeksmodel, niet bouwrijp +
+
+ + + + +
+
+ +
+
Diagram wordt geladen…
+
+erDiagram + WACHTLIJSTPLAATSING { + uuid id PK + string soort + uuid aanmelding_id FK + uuid zorgepisode_id FK + uuid afdeling_id FK + uuid zorgprogramma_id FK + date teldatum + string status + } + WACHTLIJSTACTIVITEIT { + uuid id PK + uuid wachtlijstplaatsing_id FK + uuid uitgevoerd_door FK + string type + date datum + } + WACHTLIJSTOPSCHORTING { + uuid id PK + uuid wachtlijstplaatsing_id FK + date begindatum + date einddatum + string reden + } + referral_case { + uuid id PK + } + clinical_care_episode { + uuid id PK + } + AFDELING { + uuid id PK + } + ZORGPROGRAMMA { + uuid id PK + } + MEDEWERKER { + uuid id PK + } + VESTIGING { + uuid id PK + } + + referral_case ||--o{ WACHTLIJSTPLAATSING : "aanmelding_id (soort aanmeld)" + clinical_care_episode ||--o{ WACHTLIJSTPLAATSING : "zorgepisode_id (soort behandel)" + AFDELING ||--o{ WACHTLIJSTPLAATSING : "afdeling_id" + ZORGPROGRAMMA |o--o{ WACHTLIJSTPLAATSING : "zorgprogramma_id (optioneel)" + WACHTLIJSTPLAATSING ||--o{ WACHTLIJSTACTIVITEIT : "wachtlijstplaatsing_id" + WACHTLIJSTPLAATSING ||--o{ WACHTLIJSTOPSCHORTING : "wachtlijstplaatsing_id" + MEDEWERKER ||--o{ WACHTLIJSTACTIVITEIT : "uitgevoerd_door" + VESTIGING |o--o{ AFDELING : "vestiging_id (voorgesteld, open §7.2)" +
+
sleep om te pannen · scroll om te zoomen
+
+
+ + + + + + + -- 2.39.5