normenkaderzorg.nl - Gebruikersbijdragen [nl]

Routine Outcome Monitoring (ROM)

2024-08-08T11:28:13Z

Cbruin: De ruwe scores zijn aangepast in het VC model. De informatie op de pagina is nu up-to-date.

Vragenlijsten (GGZ)

2023-12-01T10:55:44Z

Cbruin: /* KPI's en dashboards */

{{VALUECARE}}

== Introductie ==
=== Doel ===
Gestandaardiseerde vragenlijsten spelen een belangrijke rol in het verbeteren van zorgkwaliteit en het monitoren van behandeleffectiviteit. Op deze pagina worden twee belangrijke soorten vragenlijsten toegelicht. Dit zijn de Routine Outcome Monitoring (ROM) en Consumer Quality Index (CQI) vragenlijsten.

=== Overzicht van de inhoud ===
Dit is een algemene informatiepagina over de ROM en CQI vragenlijsten, en beschrijft hun functie in de GGZ, en praktische toepassing. ROM- en CQI-specifieke informatie, zoals opbouw van de berekeningen, is te vinden op de eigen pagina's van [[Routine Outcome Monitoring (ROM)|ROM]] en [[Consumer Quality Index (CQI)|CQI]] op Normenkaderzorg.nl.

== Routine Outcome Monitoring (ROM) ==
ROM is een systematische benadering waarbij op regelmatige basis informatie wordt verzameld over de gezondheid en het welzijn van cliënten tijdens behandeling in de GGZ. Middels ROM kan niet alleen het type en de ernst van de psychopathologie worden beschreven, maar het geeft door de reguliere metingen ook informatie over de effectiviteit van de behandeling. Het geeft dus ook feedback voor patiënt en behandelaar over de progressie die is gemaakt gedurende het behandeltraject. Verschillende ROM vragenlijsten zijn ontworpen om diverse aspecten van de geestelijke gezondheid objectief te meten, zoals symptomen, functioneren en kwaliteit van leven.

Enkele voorbeelden van veelgebruikte ROM-vragenlijsten zijn HoNOS (Health of the Nation Outcome Scales), SDQ (Strengths and Difficulties Questionnaire), MANSA (Manchester Short Assessment of Quality of Life) en OQ45 (Outcome Questionnaire 45). Deze vragenlijsten bieden een gestandaardiseerde manier om de voortgang van de behandeling te volgen en het behandelplan, indien nodig, aan te passen.

=== T-scores en delta-T (ROM) ===
De pluriformiteit van de vragenlijsten die gebruikt worden voor ROM heeft als gevolg dat verschillende vragenlijsten ook verschillende uitkomsten geven. Hierdoor is het lastig om de hoogte van de score betekenis te kunnen geven. Om deze uitkomsten met elkaar te kunnen vergelijken gebruikt men de t-scores. Dit is een score binnen een uniforme meetschaal, die loopt van 0-100. De verschillende uitkomsten van de vragenlijsten worden dus getransformeerd naar uitkomsten tussen 0 en 100.

Delta-T staat voor de verandering in T-scores over tijd. Bijvoorbeeld wanneer er een bepaling van het welzijn van de cliënt vóór- en na behandeling wordt gedaan, kan hiermee dus de voortgang van de behandeling worden bepaald. Als een delta-T score een positieve waarde heeft, betekent dit dat het welzijn van de patiënt is verbeterd over de gemeten tijdsperiode. Als een delta-T score een negatieve waarde heeft, betekent dit dat het welzijn van de patiënt is verslechterd over de gemeten tijdsperiode.

Hoe ValueCare de (delta) T-scores weergeeft, is te vinden op de specifieke [[Routine Outcome Monitoring (ROM)|ROM]] pagina.

=== ROM Subschalen ===
Subschalen binnen ROM vragenlijsten verwijzen naar specifieke categorieën of domeinen waarin symptomen, klachten, of het functioneren van de cliënt worden gemeten. Elke subschaal is gericht op een specifiek aspect van de psychische gezondheid of het welzijn van de cliënt. Hiermee kan dus de voortgang van cliënten middels ROM vragenlijsten worden beoordeeld op de verschillende subschalen. Voorbeelden van subschalen kunnen zijn:

# Depressie: meet symptomen zoals somberheid, gebrek aan interesse, vermoeidheid en gevoelens van waardeloosheid.
# Angst: richt zich op symptomen van angst, zoals nervositeit, paniek en fysieke angstverschijnselen.
# Sociaal Functioneren: beoordeelt hoe iemand functioneert in sociale situaties, inclusief relaties en communicatie.
# Kwaliteit van Leven: meet hoe iemand zijn of haar levenskwaliteit ervaart, waaronder tevredenheid met het leven, levensomstandigheden, en algemeen welzijn.
# Somatische Symptomen: beoordeelt lichamelijke klachten die kunnen samenhangen met psychische problemen.

De specifieke subschalen die in een ROM-vragenlijst worden gebruikt, kunnen variëren afhankelijk van de focus van de behandeling en de specifieke behoeften van de cliënt. Deze zijn belangrijk om een gedetailleerd en genuanceerd beeld te krijgen van de problematiek, en voortgang, van de cliënt.
===Consumer Quality Index (CQI)===
De CQI is een meetinstrument om ervaringen van cliënten met hun geleverde zorg te beschrijven. Het beschrijft aspecten zoals communicatie met zorgverleners, toegankelijkheid van zorg, en tevredenheid over de ontvangen behandeling. CQI-vragenlijsten worden vaak ingezet om de kwaliteit van zorg vanuit het perspectief van de patiënt te beoordelen. Hierbij worden patiënten actief betrokken bij het evalueren en verbeteren van de zorgkwaliteit. Voorbeelden van CQI-vragenlijsten omvatten vragen over de behandelrelatie, wachttijden, en de mate waarin de ontvangen zorg aansluit bij de behoeften van de patiënt.

=== CQI Subschalen ===
Subschalen binnen CQI vragenlijsten verwijzen naar specifieke categorieën of domeinen binnen de ervaringen van de cliënt met het zorgtraject. Hiermee kunnen dus verschillende delen van de ervaring worden beoordeeld ter verbetering van de zorgkwaliteit. Er zijn 4 belangrijke subschalen van elkaar te onderscheiden.

# Bejegening: een respectvolle en empathische bejegening draagt bij aan een positieve zorgervaring. Deze subschaal meet de kwaliteit van de interacties tussen cliënt en zorgverlener en benadrukt het belang van respectvolle communicatie.
# Informatievoorziening: het beoordelen van de informatieverstrekking is essentieel voor een begrijpelijke en transparante communicatie tussen zorgverlener en cliënt. Deze subschaal evalueert de helderheid en relevantie van verstrekte informatie.
# Samen beslissen: deze subschaal richt zich op de samenwerking tussen verschillende zorgverleners en de mate waarin de cliënten mee konden beslissen over hun zorgtraject. Een goede samenwerking verbetert de algehele zorgcoördinatie en resulteert in een meer samenhangende behandeling.
# Uitvoering behandeling: deze subschaal richt zich op de tevredenheid van de cliënt met het behandeltraject. Hier wordt beoordeeld op tevredenheid met de behandeling, maar ook met de uitkomsten.

== Combinatie ROM en CQI ==
Door een combinatie te gebruiken van ROM- en CQI-vragenlijsten, kan er een holistisch beeld worden gevormd van de kwaliteit van de geleverde zorg in de GGZ. Hier wordt niet alleen de effectiviteit van de behandeling beschreven, maar ook de cliënt-ervaring en tevredenheid. Dit draagt bij aan het streven naar continue kwaliteitsverbetering binnen de GGZ.

=== Toepassing van ROM en CQI in de GGZ ===
Nederlandse GGZ instellingen gebruiken deze gestandaardiseerde vragenlijsten voor diverse doeleinden. Enkele belangrijke toepassingsgebieden zijn:

* Behandelmonitoring en evaluatie: hier speelt voornamelijk ROM een belangrijke rol. De vragenlijsten binnen ROM geven namelijk belangrijke informatie over de voortgang van het behandelplan, middels systematische metingen. Het geeft ook een indicatie van de effectiviteit van de behandeling, waardoor gestuurd kan worden op behandelingsmethoden.
* Kwaliteitsverbetering: hier speelt voornamelijk CQI een belangrijke rol. Zoals eerder aangegeven kan via vragenlijsten binnen de CQI de ervaring van de patiënt worden beschreven, die informatie kan geven over de kwaliteit van zorg vanuit hun perspectief. Deze feedback kan worden gebruikt om verbeteringen in de zorgverlening door te voeren.
* Beleidsvorming en benchmarking: verzamelde gegevens uit vragenlijsten dienen als waardevolle informatie voor beleidsvorming en benchmarking. Instellingen kunnen trends analyseren, vergelijkingen maken met nationale benchmarks, en beleidsbeslissingen nemen op basis van deze gegevens.
* Patiëntgerichte zorg: het gebruik van CQI vragenlijsten benadrukt het belang van patiëntgerichte zorg. Door de ervaringen en behoeften van patiënten actief te meten en te integreren in het zorgproces, streven instellingen naar zorg die beter aansluit bij de individuele verwachtingen en wensen van de patiënt.
* Kwaliteitsaccreditatie: het systematische gebruik van ROM en CQI draagt bij aan het voldoen aan kwaliteitsnormen en accrediteringseisen binnen de GGZ. Het helpt instellingen bij het aantonen van hun inzet voor continue verbetering en transparantie.
* Wetenschappelijk onderzoek: de verzamelde gegevens uit ROM-vragenlijsten worden ook vaak gebruikt voor wetenschappelijk onderzoek. Deze data dragen bij aan het vergroten van kennis over behandeleffectiviteit en het begrijpen van psychische gezondheidstrends

== KPI's en dashboards ==
Voor ROM biedt ValueCare verschillende dashboards in het portaal.

Deze zijn te vinden onder <code>Meer dashboards > ROM > ROM - Delta t-score</code> en <code>Meer dashboards > ROM > ROM - Proces valide metingen</code>.

Zie hieronder een overzicht:
{| class="wikitable"
|+
!Dashboard
!Tegel
!Toelichting
|-
| rowspan="4" |Delta t-score
|Delta T-score ROM per maand
| rowspan="4" |Delta-T wordt per patient/behandeling berekend als de verschilscore tussen de vorige meting en huidige meting.
|-
|Delta T-score ROM per organisatieniveau
|-
|Delta T-score ROM per soort vragenlijst
|-
|Delta T-score ROM per RCI
|-
| rowspan="4" |Proces valide metingen
|Valide ROM metingen per maand
| rowspan="4" |De rapportage toont het aantal valide metingen. De rapportagedatum is gelijk aan de datum waarop de meting is afgenomen of anders de uiterlijke datum waarop de meting verwacht wordt.
|-
|Valide ROM metingen per organisatieniveau
|-
|Valide ROM metingen per soort vragenlijst
|-
|Valide ROM metingen per soort meetmoment
|-
| rowspan="4" |Effectmeting
|ROM RCI score per maand
|Alle RCI waarden van diverse meetinstrumenten zoals IDS-SR, HoNOS65, etc. gegroepeerd per dbc sluitdatum (einddatum DBC)
Deze rapportage laat de gemiddelde ROM Deltra-t score zien.
|-
|ROM HoNOS65 subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 11 vragen uit de HoNOS65 vragenlijst.
|-
|ROM RCI score per diagnosegroep
|Deze rapportage laat de ROM RCI score zien per diagnosegroep. In de tabel onder de grafiek is meer verdiepende data te vinden. Deze rapportage laat de gemiddelde ROM Delta-T score zien.
|-
|ROM CANSAS subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 25 vragen uit de CANVAS vragenlijst.
Proportie cliënten met onopgeloste zorgbehoeften is het percentage cliënten dat minimaal 1 heeft gescoord op de subschaal "onopgeloste zorgbehoeften" tov het totaal aantal cliënten.
|-
| rowspan="4" |Effectmeting Delta t-score
|ROM Delta-T score per maand
|Rapportage: gemiddelde ROM Delta-T score per maand.
|-
|ROM Delta-T score per org. niv.
|Rapportage: gemiddelde ROM Delta-T score per organisatie niveau.
|-
|ROM Delta-T score per diagnosegroep
|Rapportage: gemiddelde Delta-T score per diagnosegroep.
|-
|ROM Delta-T score per jaar
|Rapportage: gemiddelde Delta-T score per jaar.
|}{{VALUECARE}}

Vragenlijsten (GGZ)

2023-12-01T10:55:04Z

Cbruin: /* KPI's en dashboards */

{{VALUECARE}}

== Introductie ==
=== Doel ===
Gestandaardiseerde vragenlijsten spelen een belangrijke rol in het verbeteren van zorgkwaliteit en het monitoren van behandeleffectiviteit. Op deze pagina worden twee belangrijke soorten vragenlijsten toegelicht. Dit zijn de Routine Outcome Monitoring (ROM) en Consumer Quality Index (CQI) vragenlijsten.

=== Overzicht van de inhoud ===
Dit is een algemene informatiepagina over de ROM en CQI vragenlijsten, en beschrijft hun functie in de GGZ, en praktische toepassing. ROM- en CQI-specifieke informatie, zoals opbouw van de berekeningen, is te vinden op de eigen pagina's van [[Routine Outcome Monitoring (ROM)|ROM]] en [[Consumer Quality Index (CQI)|CQI]] op Normenkaderzorg.nl.

== Routine Outcome Monitoring (ROM) ==
ROM is een systematische benadering waarbij op regelmatige basis informatie wordt verzameld over de gezondheid en het welzijn van cliënten tijdens behandeling in de GGZ. Middels ROM kan niet alleen het type en de ernst van de psychopathologie worden beschreven, maar het geeft door de reguliere metingen ook informatie over de effectiviteit van de behandeling. Het geeft dus ook feedback voor patiënt en behandelaar over de progressie die is gemaakt gedurende het behandeltraject. Verschillende ROM vragenlijsten zijn ontworpen om diverse aspecten van de geestelijke gezondheid objectief te meten, zoals symptomen, functioneren en kwaliteit van leven.

Enkele voorbeelden van veelgebruikte ROM-vragenlijsten zijn HoNOS (Health of the Nation Outcome Scales), SDQ (Strengths and Difficulties Questionnaire), MANSA (Manchester Short Assessment of Quality of Life) en OQ45 (Outcome Questionnaire 45). Deze vragenlijsten bieden een gestandaardiseerde manier om de voortgang van de behandeling te volgen en het behandelplan, indien nodig, aan te passen.

=== T-scores en delta-T (ROM) ===
De pluriformiteit van de vragenlijsten die gebruikt worden voor ROM heeft als gevolg dat verschillende vragenlijsten ook verschillende uitkomsten geven. Hierdoor is het lastig om de hoogte van de score betekenis te kunnen geven. Om deze uitkomsten met elkaar te kunnen vergelijken gebruikt men de t-scores. Dit is een score binnen een uniforme meetschaal, die loopt van 0-100. De verschillende uitkomsten van de vragenlijsten worden dus getransformeerd naar uitkomsten tussen 0 en 100.

Delta-T staat voor de verandering in T-scores over tijd. Bijvoorbeeld wanneer er een bepaling van het welzijn van de cliënt vóór- en na behandeling wordt gedaan, kan hiermee dus de voortgang van de behandeling worden bepaald. Als een delta-T score een positieve waarde heeft, betekent dit dat het welzijn van de patiënt is verbeterd over de gemeten tijdsperiode. Als een delta-T score een negatieve waarde heeft, betekent dit dat het welzijn van de patiënt is verslechterd over de gemeten tijdsperiode.

Hoe ValueCare de (delta) T-scores weergeeft, is te vinden op de specifieke [[Routine Outcome Monitoring (ROM)|ROM]] pagina.

=== ROM Subschalen ===
Subschalen binnen ROM vragenlijsten verwijzen naar specifieke categorieën of domeinen waarin symptomen, klachten, of het functioneren van de cliënt worden gemeten. Elke subschaal is gericht op een specifiek aspect van de psychische gezondheid of het welzijn van de cliënt. Hiermee kan dus de voortgang van cliënten middels ROM vragenlijsten worden beoordeeld op de verschillende subschalen. Voorbeelden van subschalen kunnen zijn:

# Depressie: meet symptomen zoals somberheid, gebrek aan interesse, vermoeidheid en gevoelens van waardeloosheid.
# Angst: richt zich op symptomen van angst, zoals nervositeit, paniek en fysieke angstverschijnselen.
# Sociaal Functioneren: beoordeelt hoe iemand functioneert in sociale situaties, inclusief relaties en communicatie.
# Kwaliteit van Leven: meet hoe iemand zijn of haar levenskwaliteit ervaart, waaronder tevredenheid met het leven, levensomstandigheden, en algemeen welzijn.
# Somatische Symptomen: beoordeelt lichamelijke klachten die kunnen samenhangen met psychische problemen.

De specifieke subschalen die in een ROM-vragenlijst worden gebruikt, kunnen variëren afhankelijk van de focus van de behandeling en de specifieke behoeften van de cliënt. Deze zijn belangrijk om een gedetailleerd en genuanceerd beeld te krijgen van de problematiek, en voortgang, van de cliënt.
===Consumer Quality Index (CQI)===
De CQI is een meetinstrument om ervaringen van cliënten met hun geleverde zorg te beschrijven. Het beschrijft aspecten zoals communicatie met zorgverleners, toegankelijkheid van zorg, en tevredenheid over de ontvangen behandeling. CQI-vragenlijsten worden vaak ingezet om de kwaliteit van zorg vanuit het perspectief van de patiënt te beoordelen. Hierbij worden patiënten actief betrokken bij het evalueren en verbeteren van de zorgkwaliteit. Voorbeelden van CQI-vragenlijsten omvatten vragen over de behandelrelatie, wachttijden, en de mate waarin de ontvangen zorg aansluit bij de behoeften van de patiënt.

=== CQI Subschalen ===
Subschalen binnen CQI vragenlijsten verwijzen naar specifieke categorieën of domeinen binnen de ervaringen van de cliënt met het zorgtraject. Hiermee kunnen dus verschillende delen van de ervaring worden beoordeeld ter verbetering van de zorgkwaliteit. Er zijn 4 belangrijke subschalen van elkaar te onderscheiden.

# Bejegening: een respectvolle en empathische bejegening draagt bij aan een positieve zorgervaring. Deze subschaal meet de kwaliteit van de interacties tussen cliënt en zorgverlener en benadrukt het belang van respectvolle communicatie.
# Informatievoorziening: het beoordelen van de informatieverstrekking is essentieel voor een begrijpelijke en transparante communicatie tussen zorgverlener en cliënt. Deze subschaal evalueert de helderheid en relevantie van verstrekte informatie.
# Samen beslissen: deze subschaal richt zich op de samenwerking tussen verschillende zorgverleners en de mate waarin de cliënten mee konden beslissen over hun zorgtraject. Een goede samenwerking verbetert de algehele zorgcoördinatie en resulteert in een meer samenhangende behandeling.
# Uitvoering behandeling: deze subschaal richt zich op de tevredenheid van de cliënt met het behandeltraject. Hier wordt beoordeeld op tevredenheid met de behandeling, maar ook met de uitkomsten.

== Combinatie ROM en CQI ==
Door een combinatie te gebruiken van ROM- en CQI-vragenlijsten, kan er een holistisch beeld worden gevormd van de kwaliteit van de geleverde zorg in de GGZ. Hier wordt niet alleen de effectiviteit van de behandeling beschreven, maar ook de cliënt-ervaring en tevredenheid. Dit draagt bij aan het streven naar continue kwaliteitsverbetering binnen de GGZ.

=== Toepassing van ROM en CQI in de GGZ ===
Nederlandse GGZ instellingen gebruiken deze gestandaardiseerde vragenlijsten voor diverse doeleinden. Enkele belangrijke toepassingsgebieden zijn:

* Behandelmonitoring en evaluatie: hier speelt voornamelijk ROM een belangrijke rol. De vragenlijsten binnen ROM geven namelijk belangrijke informatie over de voortgang van het behandelplan, middels systematische metingen. Het geeft ook een indicatie van de effectiviteit van de behandeling, waardoor gestuurd kan worden op behandelingsmethoden.
* Kwaliteitsverbetering: hier speelt voornamelijk CQI een belangrijke rol. Zoals eerder aangegeven kan via vragenlijsten binnen de CQI de ervaring van de patiënt worden beschreven, die informatie kan geven over de kwaliteit van zorg vanuit hun perspectief. Deze feedback kan worden gebruikt om verbeteringen in de zorgverlening door te voeren.
* Beleidsvorming en benchmarking: verzamelde gegevens uit vragenlijsten dienen als waardevolle informatie voor beleidsvorming en benchmarking. Instellingen kunnen trends analyseren, vergelijkingen maken met nationale benchmarks, en beleidsbeslissingen nemen op basis van deze gegevens.
* Patiëntgerichte zorg: het gebruik van CQI vragenlijsten benadrukt het belang van patiëntgerichte zorg. Door de ervaringen en behoeften van patiënten actief te meten en te integreren in het zorgproces, streven instellingen naar zorg die beter aansluit bij de individuele verwachtingen en wensen van de patiënt.
* Kwaliteitsaccreditatie: het systematische gebruik van ROM en CQI draagt bij aan het voldoen aan kwaliteitsnormen en accrediteringseisen binnen de GGZ. Het helpt instellingen bij het aantonen van hun inzet voor continue verbetering en transparantie.
* Wetenschappelijk onderzoek: de verzamelde gegevens uit ROM-vragenlijsten worden ook vaak gebruikt voor wetenschappelijk onderzoek. Deze data dragen bij aan het vergroten van kennis over behandeleffectiviteit en het begrijpen van psychische gezondheidstrends

== KPI's en dashboards ==
Voor ROM biedt ValueCare verschillende dashboards in het portaal.

Deze zijn te vinden onder <code>Meer dashboards > ROM > ROM - Delta t-score</code> en <code>Meer dashboards > ROM > ROM - Proces valide metingen</code>.

Zie hieronder een overzicht:
{| class="wikitable"
|+
!CQI / ROM
!Dashboard
!Tegel
!Toelichting
|-
| rowspan="16" |ROM
| rowspan="4" |Delta t-score
|Delta T-score ROM per maand
| rowspan="4" |Delta-T wordt per patient/behandeling berekend als de verschilscore tussen de vorige meting en huidige meting.
|-
|Delta T-score ROM per organisatieniveau
|-
|Delta T-score ROM per soort vragenlijst
|-
|Delta T-score ROM per RCI
|-
| rowspan="4" |Proces valide metingen
|Valide ROM metingen per maand
| rowspan="4" |De rapportage toont het aantal valide metingen. De rapportagedatum is gelijk aan de datum waarop de meting is afgenomen of anders de uiterlijke datum waarop de meting verwacht wordt.
|-
|Valide ROM metingen per organisatieniveau
|-
|Valide ROM metingen per soort vragenlijst
|-
|Valide ROM metingen per soort meetmoment
|-
| rowspan="4" |Effectmeting
|ROM RCI score per maand
|Alle RCI waarden van diverse meetinstrumenten zoals IDS-SR, HoNOS65, etc. gegroepeerd per dbc sluitdatum (einddatum DBC)
Deze rapportage laat de gemiddelde ROM Deltra-t score zien.
|-
|ROM HoNOS65 subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 11 vragen uit de HoNOS65 vragenlijst.
|-
|ROM RCI score per diagnosegroep
|Deze rapportage laat de ROM RCI score zien per diagnosegroep. In de tabel onder de grafiek is meer verdiepende data te vinden. Deze rapportage laat de gemiddelde ROM Delta-T score zien.
|-
|ROM CANSAS subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 25 vragen uit de CANVAS vragenlijst.
Proportie cliënten met onopgeloste zorgbehoeften is het percentage cliënten dat minimaal 1 heeft gescoord op de subschaal "onopgeloste zorgbehoeften" tov het totaal aantal cliënten.
|-
| rowspan="4" |Effectmeting Delta t-score
|ROM Delta-T score per maand
|Rapportage: gemiddelde ROM Delta-T score per maand.
|-
|ROM Delta-T score per org. niv.
|Rapportage: gemiddelde ROM Delta-T score per organisatie niveau.
|-
|ROM Delta-T score per diagnosegroep
|Rapportage: gemiddelde Delta-T score per diagnosegroep.
|-
|ROM Delta-T score per jaar
|Rapportage: gemiddelde Delta-T score per jaar.
|}{{VALUECARE}}

Routine Outcome Monitoring (ROM)

2023-12-01T09:11:31Z

Cbruin: /* Berekening ROM scores */

{{VALUECARE}}

== Samenvatting ==

ROM, oftewel Routine Outcome Monitoring, vormt een essentieel onderdeel van de Geestelijke Gezondheidszorg (GGZ). Door regelmatig gegevens te verzamelen, biedt ROM niet alleen inzicht in de aard en ernst van psychische klachten, maar geeft het ook waardevolle feedback over de effectiviteit van behandelingen. Op deze pagina wordt uitgebreid beschreven wat veelgebruikte definities zijn binnen ROM vragenlijsten, welk stappenplan wordt gevolgd om ROM berekeningen te maken, hoe ValueCare de meetmomenten heeft gedefinieerd, hoe ValueCare met verschillende ROM vragenlijsten inzichtelijke gestandaardiseerde ROM waardes berekent, en wordt een toelichting gegeven over verschillende ROM dashboards die ValueCare presenteert aan GGZ instellingen.
== Inleiding ==
Deze pagina dient als naslagwerk om de managementrapportages op de Routine Outcome Monitoring (ROM) te interpreteren en gebruiken.

De doelen van managementrapportage inzake ROM betreft het bieden van inzicht in:

* De (tijdige) inzet van ROM instrumenten op de juiste momenten
* De effecten van de ingezette behandeling

Op deze pagina is een overzicht van definities te vinden, gevolgd door een toelichting op de totstandkoming. De relevante toepassing van de ROM wordt als laatste uitgelicht.

== Definities ==
Hieronder staan alle relevante termen met betrekking tot de ROM gedefinieerd en waar relevant extra toegelicht.

Let op: inmiddels zijn er ook ROM metingen te monitoren voor soorten GGZ Zorg anders dan ZPM (ZVW/FM). De functionaliteiten van reeksen werkt hierbij anders. Deze informatie is inmiddels toegevoegd aan deze pagina.
{| class="wikitable"
|+
!Term
!Definitie
!Toelichting
|-
|Voor- en nametingen
|De voor- en nametingen vormen de kapstok voor het bepalen of er een geldige ROM voormetingen dan wel nametingen uitgevoerd is voor het ZPM zorgtraject. Voor andere financieringsstromen geschiedt dit voor de daarvoor leidende zorgproducten (bijvoorbeeld een jeugdproduct). Daarnaast wordt per meting de T-score bepaald, zodat het effect kan worden gemeten door de T-score van de nameting te vergelijken met de voormeting.
| Note: de organisataie-eenheid van metingen/meetmomenten wordt bepaald aan de hand van de organisatie-eenheid die bij het zorgproduct zit.
|-
|Voormeting
|Het eerste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de voormeting. Hierop is een (instelbare) marge in dagen van toepassing om als geldige voormeting te tellen.
| nvt
|-
|Nameting
|Het laatste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de nameting. Ook hierop is een (instelbare) marge in dagen van toepassing om als geldige nameting te tellen.
|De nameting van het voorgaande zorgtraject mag gezien worden als voormeting van het nieuwe traject, indien het voldoen aan de eisen:

* Marge in dagen t.o.v. eerste behandelcontact in nieuwe zorgtraject

* Vragenlijst wordt gebruikt binnen de diagnose hoofdgroep

Notes:

* Als er nog geen einddatum is bepaald voor een behandelreeks, verwachten we dat er nog behandelcontacten gaan volgen. In dit geval bepalen we wel een laatste (ofwel meest recente) behandelcontact, maar valideren we nog niet of er een geldige nameting is geweest.
* Als er een verwachte einddatum (in de toekomst) is ingevuld voor een behandelreeks, dan kijken we voor een valide nameting binnen het tijdsinterval rondom de einddatum van de behandelreeks
* Als de einddatum van een zorgtraject reeds voorbij is, dan kijken we naar het laatste (ofwel meest recente) behandelcontact
|-
|Tussenmetingen
|Voor mensen die langdurig in zorg zijn (en hetzelfde zorgtraject hebben) zijn regelmatigere tussentijdse metingen van ROM is wenselijk. Het gewenste tijdsinterval verschilt per instelling, daarom is een tijdsinterval in te stellen. Voor informatie over het instelbare tijdsinterval, zie ''Tijdsinterval''.
|
|-
|Valide meting
|Een valide meting is een meting die:

* is aangemerkt als ROM
* volledig is ingevuld
* Als de diagnosegroep van het zorgtraject gevuld is, wordt met Beheer BI: Vragenlijst per diagnose bepaald of de vragenlijst in aanmerking komt voor de diagnose hoofdgroep.
** Indien de diagnosegroep leeg is, tonen we op dit moment geen meetmomenten in de dataset.
|
|-
|Tijdsinterval
|Hiermee wordt gedoeld op de gewenste tijd tussen ROM metingen. Zie ook definitie ''tussenmetingen''. De tijdsinterval is door de instelling zelf in te stellen. De tijdsinterval kan verschillen per type vragenlijst en diagnose en kan ingesteld worden via de beheertabel Beheer BI: Vragenlijst per diagnose
|<code>Stuurinformatie > Beheer BI > Beheer BI: Vragenlijst per diagnose</code>
|-
|Meetmoment
|Indien er geen meting plaatsvindt binnen het ingestelde tijdsinterval, wordt er een meetmoment aangemaakt. Dit is dus een moment waarop er een meting verwacht werd, maar deze niet is gedaan.
|Zie ook "Totstandkoming - Stappenplan - stap 3: Nummering metingen" hieronder.
|-
|Initiële meting
|Dit is de eerste valide meting binnen een reeks. De initiële meting is nodig als aanvulling op de voormeting voor de gevallen waarin de voormeting gegenereerd is (en dus geen valide meting is). In deze gevallen is de initiële meting de eerste valide meting binnen een reeks.
|Zie ook "Toepassing - (Delta) t-score" hieronder.
|-
|Behandelreeks
|Alle meetmomenten binnen een zorgtraject in combinatie met de DBC’s.
Binnen één behandelreeksmoeten de onderstaande aspecten overeenkomen. Komen deze aspecten niet overeen, dan geldt dat als een andere behandelreeks.

*'''Inschrijving (en daarmee ook cliënt)'''
** Als een inschrijving eindigt, eindigt de behandelreeks

*'''Diagnose '''
** Is er een nieuwe diagnose gesteld is, eindigt de behandelreeks
*'''Zorgtraject / DBC / Jeugd / WMO '''
** Als er een nieuw zorgtraject, jeugdproduct, of wmo product is, eindigt de behandelreeks
|Bij Jeugd en WMO worden aansluitende toewijzingen als een en dezelfde behandelreeks gezien.

Als er voor een Jeugd product of WMO product een nieuw product is aangemaakt met een zelfde product-code wordt dit ondervangen in dezelfde behandelreeks. Dit geldt enkel als het nieuwe product binnen 35 dagen na sluiting van het vorige product is aangemaakt. Hierbij moet er ook sprake zijn van dezelfde product-code, zelfde diagnose, en dezelfde inschrijving (en dus cliënt).
|-
|Reeks
|Een behandelreeks kan bestaan uit meerdere reeksen. Dit is afhankelijk van de instelling van GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST. Mits er meerdere type vragenlijsten zijn afgenomen, kan er voor elk type vragenlijst een aparte reeks worden aangemaakt. De voor- en nameting worden op het niveau van de behandelreeks gedefinieerd. Oftewel, mits er een voormeting is afgenomen binnen één van de reeksen met dezelfde behandelreeks, zal deze voormeting getoond worden voor al die reeksen.

* '''Behandelreeks'''

*'''(Optioneel) vragenlijst code'''
** Instelbaar
** Wordt enkel toegepast op behandelreeksen met één of meer geldige metingen
** Mits parameter = ‘JA’: dan geldt dat voor een andere vragenlijst-code een andere reeks wordt gemaakt (
*** T-scores worden enkel vergeleken voor vragenlijsten met hetzelfde type (bijv. enkel HoNOS vragenlijsten binnen één behandelreeks).
*** Meetmomenten worden gegenereerd voor elke type vragenlijst. Bijvoorbeeld, is er een HoNOS U verwacht dan voor elk type vragenlijst een nieuw meetmoment. (
** Mits parameter = ‘Nee’: dan geldt dat voor een andere vragenlijst-code dezelfde reeks wordt gebruikt
*** T-scores worden vergelijken onafhankelijk van het type vragenlijsten (Bijvoorbeeld, HoNOS en FARE worden afwisselend gebruikt).
*** Verwachtte meetmomenten worden enkel gegenereerd als er geen meting is geweest binnen het tijdsinterval voor alle type vragenlijsten.
|[[Bestand:ROM reeks.jpg|gecentreerd|392x392px]]
|-
|(Delta)-T score
|De T-score is een uniforme maat om de diverse vragenlijsten naar scores te transformeren en loopt van 0-100. Een succesvolle behandeling zorgt voor een lagere nametingen dan de voormeting (behalve bij het meetinstrument MANSA-16). De Delta-T score is het verschil in T score tussen twee T scores.

Zie voor interpretatie van de Delta T-score de tabel onder "Toepassing - interpretatie delta T-score"
|
|-
|Gekoppeld meetmoment
|Een gekoppeld meetmoment is een valide meting die binnen de data van een behandelreeks valt. Een ongekoppelde meetmoment kan een valide meting zijn die buiten de behandelreeks valt. Of het kan een invalide meting zijn (die binnen of buiten een eventuele behandelreeks valt).
|Zie ook de visualisatie in de executive summary bovenaan deze pagina.
|}

== Totstandkoming ==

=== Stappenplan ===
Hieronder is het stappenplan uitgewerkt dat gevolgd wordt om de berekeningen voor de ROM te maken.

Per stap is toelichting gegeven en zo nodig een extra visualisatie toegevoegd.
{| class="wikitable"
|+
!Stap
!Toelichting
!
|-
|0: Bepalen behandelingen binnen behandelreeks
|Eerst wordt bepaald naar welke behandelingen we moeten kijken om de uitersten van behandelreeks te kunnen bepalen.

* Mits het ZPM zorgtraject is aangemaakt met zorglabel N02 (''Overgang oude bekostiging met direct tijd naar Zorgprestatiemodel''), wordt de voormeting bepaald op basis van de voorafgaande DBC(s). De DBCs die worden meegenomen bij de betreffende zorgtrajecten, zijn DBCs die dezelfde (1) diagnose en (2) inschrijvingsnummer hebben als het zorgtraject.

* Voor de combinatie van de zorgtrajecten met eventuele DBCs (en losse DBCs) kijken we naar alle behandelcontacten met directe tijd.
** Voor een dergelijke behandelreeks moeten we het eerste/laatste behandelcontact bepalen.
|[[Bestand:Stap 0 ROM .png|gecentreerd|miniatuur|800x800px]]
|-
|1: Bepalen uitersten van behandelreeks
|Als er bepaald is welke behandelingen in een behandelreeks vallen, wordt er per behandelreeks bepaald:

* Het eerste behandelcontact
* Het laatste behandelcontact

LET OP

Er moet directe tijd zijn geschreven op het behandelcontact en er moet een diagnose bekend zijn voor de behandelreeks. De diagnose is nodig om te bepalen of een eventuele ROM-meting met een vragenlijst is afgenomen die geldig is bij die specifieke diagnose
|[[Bestand:ROMstap1 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|-
|2: Bepalen valide metingen
|Dan wordt er gekeken of er binnen de vastgestelde uiterste waarden van een behandelreeks, valide metingen te vinden zijn.

* Mits er een valide meting te vinden is, dan wordt de behandelreeks, en (optioneel) type vragenlijst meegenomen in de behandelreeks.

* Mits er geen valide meting te vinden is, dan is een reeks enkel bepaald op basis van de behandelreeks. In dit geval zullen er dan ook geen geldige metingen te tonen zijn in de dataset. Er worden wel twee meetmomenten gegenereerd, namelijk het verwachte voormeetmoment en het verwachte nameetmoment.
|[[Bestand:ValueCare - ROM (1).png|gecentreerd|miniatuur|800x800px]]
|-
|3:Nummering metingen
|We nummeren de opvolgende metingen binnen een behandelreeks op basis van de datum van afname.
Hierdoor kunnen we de opvolgende metingen makkelijk koppelen.

Met behulp van het tijdsinterval per type vragenlijst en diagnose, kunnen we bepalen of de opvolgende metingen plaats hebben gevonden binnen het tijdsinterval (t.o.v. de vorige meting), waarbinnen ze worden verwacht.
{| class="wikitable"
|+
!Optie
! colspan="2" |Situatie
!Gevolg
|-
|A
| colspan="2" |De volgende meting valt binnen tijdsinterval
|De volgende meting is een valide meting. Let op: alle valide metingen moeten voldoen aan de criteria gedefinieerd in stap 2.
|-
|B
| colspan="2" |De volgende meting valt buiten tijdsinterval
|Genereren meetmoment (dus geen valide meting). Dit meetmoment moet duidelijk maken aan instellingen dat er een meting verwacht wordt, maar deze meting niet (valide of volledig) is afgenomen.
|-
|C
| rowspan="2" |Geen volgende meting
|Laatste behandelcontact is in het verleden geweest
|Genereren meetmomenten tot en met het laatste behandelcontact.
|-
|D
|Laatste behandelcontact wordt in de toekomst verwacht
|Genereren meetmomenten tot en met de aanleverdatum.
|}
|[[Bestand:ROM stap 3 diagram update .jpg|alt=|gecentreerd|miniatuur|1300x1300px]]
|-
|4: Bepalen voor- en nameting
|Het bepalen van de voor- en nametingen:

De metingen die binnen een reeks het dichtste bij het eerste/laatste behandelcontact liggen worden bestempeld als voor- of nameting.

Indien er enkel een voormeting of een nameting is en niet beide, dan genereren we een meetmoment voor de missende voor- of nameting, met als datum het eerste/laatste behandelcontact.

* Mits er een valide meting heeft plaatsgevonden in de reeks, bepalen we of de meting een valide voor- of nameting is aan de hand van een marge rondom het eerste- of laatste behandelcontact. Deze marges worden bepaald aan de hand van parameters BI_MARGE_RONDOM_EERSTE_BEHANDELCONTACT_VOORMETING en BI_MARGE_RONDOM_LAATSTE_BEHANDELCONTACT_NAMETING .
* Optioneel: Instelbaar
** Mits er voor een reeks meerdere type vragenlijst worden gebruikt (bijv. zowel Honos-12 als SQ48) dan wordt er voor elk type vragenlijst een aparte reeks aangemaakt. De voor- en nametingen worden onafhankelijk van type vragenlijst bepaald. Dit wordt dus gedaan voor de overkoepelende behandelreeks.
|[[Bestand:ROMstap4 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|}

=== Gebruikte beheertabellen en parameters ===
Hieronder zijn de parameters en beheertabellen met relevante toelichting te vinden. De dataset die voor de ROM gebruikt wordt is <code>ROM meetmomenten.</code>
{| class="wikitable"
|+
!Parameters
!Toelichting
|-
|BI_MARGE_RONDOM_EERSTE_BEHANDELCONTACT_VOORMETING
|Bandbreedte in dagen rondom eerste behandelcontact zorgtraject waarbinnen een geldige voormeting afgenomen moet zijn
|-
|BI_MARGE_RONDOM_LAATSTE_BEHANDELCONTACT_NAMETING
|Bandbreedte in dagen rondom laatste behandelcontact zorgtraject waarbinnen een geldige nameting afgenomen moet zijn
|-
|GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST
|Of een reeks rekening moet houden met aparte type vragenlijsten of niet.

Mits parameter = JA, genereren we voor elke verschillende vragenlijst-code binnen een behandelreeks, een aparte reeks

Mits parameter = NEE, mogen de vragenlijsten onafhankelijk van elkaar afgenomen zijn

''NOTE: deze parameter wil ik nog hernoemen naar GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST''
|-
|''GGZBI_TIJDSINTERVAL_ROM_MEETMOMENTEN_ONAFHANKELIJK_VAN_TYPE''
|Het tijdsinterval dat gebruikt wordt voor reeksen, waarbij geen tijdsinterval bepaald is in de beheertabel 'Beheer BI: Vragenlijst per diagnose'
|}
{| class="wikitable"
|+
!Beheertabel
!Toelichting
|-
|Beheer BI: Vragenlijst per diagnose
|Per diagnosehoofdgroep kan het gebruikte ROM-instrument aangegeven worden.
In deze beheertabel kan ook het interval per type vragenlijst en diagnose ingesteld worden. (NIEUW!)
|-
|Beheer BI: Vragenlijst
|Per vragenlijst kan worden aangegeven of deze wordt gebruikt als ROM- en/of CQI-instrument
|-
|Beheer BI: Parameters
|Voor het instellen van o.a. de hierboven genoemde parameters.
|}

== Toepassing ==

In dit deel worden de toepassingen toegelicht, deze toepassingen zijn gericht op het behalen van de doelen van de managementrapportage inzake ROM zoals beschreven in de inleiding van deze pagina.

=== Beheertabel ===

Zoals hierboven al vaker aangegeven zijn er een aantal dingen instelbaar via beheertabellen. Zie ook het overzicht van beheertabellen hierboven.

De instellingen van deze beheertabellen hebben invloed om de onderstaande toepassingen en dienen dus correct ingevuld te zijn om de toepassing zo nuttig en accuraat mogelijk te laten zijn.

=== ROM Meetmomenten ===
De Routine Outcome Monitoring (ROM) is een complex product met tal van mogelijkheden en variaties.

Om de ROM behapbaar te maken is deze executive summary gemaakt met 1 figuur waarin de werking van de ROM gevisualiseerd is.

De verdiepende informatie (bv definities en stappenplan) is ook op deze pagina te vinden, onder deze samenvatting.

Er zijn twee verschillende situaties:

#<code>GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST = 'NEE'</code>: hier mogen verschillende type vragenlijsten gecombineerd worden.
#<code>GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST = 'JA'</code>: hier mogen de verschillende type vragenlijsten niet gecombineerd worden.
Deze twee situaties zijn onder elkaar gevisualiseerd.

[[Bestand:Exe sum (1).jpg|alt=|geen|miniatuur|1549x1549px|Executive summary ROM]]

=== Berekening ROM scores ===
Voor instellingen die gebruik maken van bronsysteem 'Questmanager' berekent ValueCare zelf de ruwe scores, op basis van onderstaande codes per vragenlijst type. Voor andere bronsystemen wordt de ruwe score direct uit de bron gehaald.

==== Berekening ruwe scores ====
{| class="wikitable"
!Type Vragenlijst
!Eigenschappen
!Definities
|-
| rowspan="3" |SQ48
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen groter is dan, of gelijk is aan 30. Dit betekent dat er minimaal 30 vragen moeten zijn ingevuld om de berekening uit te voeren.
|-
|Berekening ruwe score
|Ruwe score wordt berekend met de formule: som_ingevulde_scores * 37 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores (som_ingevulde_scores) vermenigvuldigd met 37 (het totale aantal vragen in de vragenlijst) en gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van missende waardes met de gemiddelde waarde.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal. De vraagcodes verschillen per instelling.
|-
| rowspan="3" |OQ45
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen (aantal_vragen_ingevuld) groter is dan of gelijk is aan 20. Dit betekent dat er minimaal 20 vragen moeten zijn ingevuld om de berekening uit te voeren.
|-
| Berekening ruwe score
|Ruwe score wordt berekend met de formule: som_ingevulde_scores * 25 / aantal_vragen_ingevuld.
Hierbij wordt de som van ingevulde scores (som_ingevulde_scores) (zie onderstaand kopje) vermenigvuldigd met 25 (het totale aantal vragen in de lijst) en gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van missende waardes met de gemiddelde waarde.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal. De vraagcodes verschillen per instelling.
|-
| rowspan="3" |SDQ-P
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen groter is dan, of gelijk is aan 16. Dit betekent dat er minimaal 16 vragen moeten zijn ingevuld om de berekening uit te voeren.
|-
|Berekening ruwe score
|Ruwe score wordt berekend met de formule: som_ingevulde_scores * 20 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores (som_ingevulde_scores) vermenigvuldigd met 20 (het totale aantal vragen in de vragenlijst) en gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van de missende waardes met de gemiddelde waarde.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal. De vraagcodes verschillen per instelling.
|-
| rowspan="5" |SDQ-s11-17
| Voorwaarden voor berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen groter is dan of gelijk is aan 16. Dit betekent dat er minimaal 16 vragen moeten zijn ingevuld om de berekening uit te voeren.
|-
|Berekening ruwe score
|Ruwe score wordt berekend met de formule: som_ingevulde_scores * 20 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores (som_ingevulde_scores) vermenigvuldigd met 20 (het totale aantal vragen in de vragenlijst) en gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van missende waardes met de gemiddelde waarde.
|-
|Berekening van de som_ingevulde_scores
|Er wordt een som berekend op basis van een 'case'-statement dat specifieke vragen identificeert (vragen met bepaalde codes) en hun antwoordwaarden omschrijft. De specifieke vragen zijn gedefinieerd in de lijst met vraagcodes, en voor sommige van deze vragen wordt de waarde omgerekend met de formule: '2 - t0.vragenlijst_antwoord_waarde::int', anders blijft de oorspronkelijke waarde behouden. Deze omgerekende of onveranderde waarden worden vervolgens opgeteld om de 'som_ingevulde_scores' te verkrijgen. Deze vraagcodes verschillen per instelling.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal. De vraagcodes verschillen per instelling.
|-
|Groeperen van resultaten
|De resultaten worden gegroepeerd op basis van kolommen aangeduid met 'group by 1, 2'.
|-
| rowspan="4" |BSI
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen (aantal_vragen_ingevuld) groter is dan of gelijk is aan 43. Dit betekent dat er minimaal 43 vragen moeten zijn ingevuld om de berekening uit te voeren.
|-
|Berekening van de ruwe score
|Ruwe score wordt berekend met de formule: som_ingevulde_scores * 1 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores gedeeld door het aantal ingevulde vragen. Er is geen omrekening van de scores; het is gewoon het gemiddelde.
|-
|Berekening van de som_ingevulde_scores
|Er wordt een som berekend van de ingevulde scores. Deze som wordt verkregen door de waarden van de kolom 't0.vragenlijst_antwoord_waarde' op te tellen.
|-
|Filteren van de gegevens
|De antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal.
|-
| rowspan="3" |HoNOS-12
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen groter is dan, of gelijk is aan, 10. Dit betekent dat er minimaal 10 vragen moeten worden ingevuld om de berekening uit te voeren.
|-
|Berekening ruwe score
|Ruwe score wordt berekend met de formule: som_ingevulde_scores * 12 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores (som_ingevulde_scores) vermenigvuldigd met 12 (het totale aantal vragen in de lijst) en gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van missende waardes met de gemiddelde waarde.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal. De vraagcodes verschillen per instelling.
|-
| rowspan="3" |HoNOS-65
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen groter is dan, of gelijk is aan, 10. Dit betekent dat er minimaal 10 vragen moeten worden ingevuld om de berekening uit te voeren.
|-
|Berekening van de ruwe score
|De ruwe score wordt berekend met de formule: som_ingevulde_scores * 12 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores (som_ingevulde_scores) vermenigvuldigd met 12 (het totale aantal vragen in de lijst) en gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van missende waardes met de gemiddelde waarde.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal. De vraagcodes verschillen per instelling.
|-
| rowspan="3" |MANSA-16
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen groter is dan, of gelijk is aan, 10. Dit betekent dat er minimaal 10 vragen moeten worden ingevuld om de berekening uit te voeren.
*
|-
| Berekening ruwe score
|De ruwe score wordt berekend met de formule: som_ingevulde_scores * 1 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores (som_ingevulde_scores) gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van de missende waardes met de gemiddelde waarde.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', '4' '5', '6', of '7'. De vraagcodes verschillen per instelling.
|}

==== Berekening T-scores ====
{| class="wikitable"
! Type vragenlijst
!Berekening
|-
|SQ48
|De T-score wordt berekend met de volgende formule: 24.70535964913392 + (0.3751176991148195 * ruwe_score_vc) + (-0.0009187118790624546 * ruwe_score_vc^2) + (0.00000670607402179293 * ruwe_score_vc^3).

Hier staat ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
|OQ45
|De T-score wordt berekend met de volgende formule: 17.9856940411384 + (2.56446078269377 * ruwe_score_vc) + (-0.0558628542617925 * ruwe_score_vc^2) + (0.000976254840029574 * ruwe_score_vc^3).

Hier staat ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
|SDQ-P
|De T-score wordt berekend met de volgende formule: 17.9856940411384 + (2.56446078269377 * ruwe_score_vc) + (-0.0558628542617925 * ruwe_score_vc^2) + (0.000976254840029574 * ruwe_score_vc^3).

Hier staat ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
| SDQ-s11-17
|De T-score wordt berekend met de volgende formule: 20.3713833471163 + (2.49157128999528 * ruwe_score_vc) + (-0.0493700167712384 * ruwe_score_vc^2) + (0.000942819943550291 * ruwe_score_vc^3).

Hier staat ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
|BSI
|De T-score wordt berekend met de volgende formule: 26.42038565180546 + (26.8200050937306 * ruwe_score_vc) +(-8.284911648378781 * ruwe_score_vc^2) + (1.350267912166433 * ruwe_score_vc^3).

Hier staat ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
|HoNOS-12
|De T-score wordt berekend met de volgende formule: 27.00023405117865 + (2.450806391090429 * ruwe_score_vc) + (-0.04649228749948154 * ruwe_score_vc^2 ) + (0.0005045255416624083 * ruwe_score_vc^3).

Hier staat ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
|HoNOS-65
|De T-score wordt berekend met de volgende formule: 23.3163221392 + (2.7836900604 * ruwe_score_vc) + (-0.0672989375* ruwe_score_vc^2) + (0.0009265311* ruwe_score_vc^3).

Hier staat de ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
|MANSA-16
|De T-score wordt berekend met de volgende formule: t_score = ruwe_score_vc. Dit betekent dat voor deze vragenlijst de ruwe score hetzelfde is als de uiteindelijke T-score.
|}
===Andere bronsystemen===
==== Ruwe score = T-score====
Voor sommige bronsystemen komt de T-score vanuit de bron zelf. ValueCare doet dat geen berekening voor een ruwe score of een T-score.

Via beheertabel 'Beheer BI: Vragenlijst subschalen' kan de T-score worden ingericht. Deze T-score zal als één van de subschalen zijn ingericht. Mocht deze T-score vanuit de bron niet goed worden overgenomen, dan kan deze worden aangepast door de gebruiker. Als de subschalen voor een vragenlijst-type nog niet zichtbaar zijn, dan moet het vinkje 'Subschalen inrichten' in 'Beheer BI: Vragenlijsten' nog worden aangeklikt.
=== (Delta) t-score ===
De instellingen vinden het vooral belangrijk om de t-scores te weten die bij een ROM meting hoorde. Daarnaast willen ze de delta t-score weten, zodat ze kunnen zien of een cliënt verbeterd of juist verslechterd in de loop der tijd.

Voor een gegenereerd meetmoment hebben we geen t-score. Daardoor kunnen we enkel t-scores vergelijken van valide metingen. We tonen in dataset ROM meetmomenten daarom enkel delta t-scores voor valide metingen ten opzichte van valide metingen. Dit houdt ook in dat voor gegenereerde voormeetmomenten, we geen delta t-score ten opzichte van de voormeting kunnen doen. Om dit te voorkomen, hebben we de ‘initiële meting’ geïntroduceerd. Dit is de eerste valide meting binnen een reeks. We hebben op deze manier dus twee type delta t-scores in de dataset: (1) delta t-score t.o.v. de vorige valide meting, (2) delta t-score t.o.v. de initiële meting.

[[Bestand:Deltat nieuw.jpg|alt=|gecentreerd|miniatuur|800x800px]]

==== Interpretatie Delta T-score ====
Zie de tabel hieronder voor de interpretatie van de Delta T-score:
{| class="wikitable"
|+
!Code
!Classificatie
!Delta T-score
|-
|1
|Hersteld
|> 5 <code>AND</code> voormeting t > 42,5 <code>AND</code> nameting t < 42,5
|-
|2
|Verbeterd
|> 5
|-
|3
|Onveranderd
| -5 < delta t < 5
|-
|4
|Verslechterd
|< -5
|}

=== KPI's en dashboards ===
Voor de ROM biedt ValueCare verschillende dashboards in het portaal.

Deze zijn te vinden onder <code>Meer dashboards > ROM > ROM - Delta t-score</code> en <code>Meer dashboards > ROM > ROM - Proces valide metingen</code>.

Zie hieronder een overzicht:
{| class="wikitable"
|+
!Dashboard
!Tegel
!Toelichting
|-
| rowspan="4" |Delta t-score
|Delta T-score ROM per maand
| rowspan="4" |Delta-T wordt per patient/behandeling berekend als de verschilscore tussen de vorige meting en huidige meting.
|-
|Delta T-score ROM per organisatieniveau
|-
|Delta T-score ROM per soort vragenlijst
|-
|Delta T-score ROM per RCI
|-
| rowspan="4" |Proces valide metingen
|Valide ROM metingen per maand
| rowspan="4" |De rapportage toont het aantal valide metingen. De rapportagedatum is gelijk aan de datum waarop de meting is afgenomen of anders de uiterlijke datum waarop de meting verwacht wordt.
|-
|Valide ROM metingen per organisatieniveau
|-
|Valide ROM metingen per soort vragenlijst
|-
|Valide ROM metingen per soort meetmoment
|-
| rowspan="4" |Effectmeting
|ROM RCI score per maand
|Alle RCI waarden van diverse meetinstrumenten zoals IDS-SR, HoNOS65, etc. gegroepeerd per dbc sluitdatum (einddatum DBC)

Deze rapportage laat de gemiddelde ROM Deltra-t score zien.
|-
|ROM HoNOS65 subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 11 vragen uit de HoNOS65 vragenlijst.
|-
|ROM RCI score per diagnosegroep
|Deze rapportage laat de ROM RCI score zien per diagnosegroep. In de tabel onder de grafiek is meer verdiepende data te vinden. Deze rapportage laat de gemiddelde ROM Delta-T score zien.
|-
|ROM CANSAS subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 25 vragen uit de CANVAS vragenlijst.

Proportie cliënten met onopgeloste zorgbehoeften is het percentage cliënten dat minimaal 1 heeft gescoord op de subschaal "onopgeloste zorgbehoeften" tov het totaal aantal cliënten.
|-
| rowspan="4" |Effectmeting Delta t-score
|ROM Delta-T score per maand
|Rapportage: gemiddelde ROM Delta-T score per maand.
|-
|ROM Delta-T score per org. niv.
|Rapportage: gemiddelde ROM Delta-T score per organisatie niveau.
|-
|ROM Delta-T score per diagnosegroep
|Rapportage: gemiddelde Delta-T score per diagnosegroep.
|-
|ROM Delta-T score per jaar
|Rapportage: gemiddelde Delta-T score per jaar.
|}
{{VALUECARE}}

Routine Outcome Monitoring (ROM)

2023-12-01T09:02:48Z

Cbruin:

{{VALUECARE}}

== Samenvatting ==

ROM, oftewel Routine Outcome Monitoring, vormt een essentieel onderdeel van de Geestelijke Gezondheidszorg (GGZ). Door regelmatig gegevens te verzamelen, biedt ROM niet alleen inzicht in de aard en ernst van psychische klachten, maar geeft het ook waardevolle feedback over de effectiviteit van behandelingen. Op deze pagina wordt uitgebreid beschreven wat veelgebruikte definities zijn binnen ROM vragenlijsten, welk stappenplan wordt gevolgd om ROM berekeningen te maken, hoe ValueCare de meetmomenten heeft gedefinieerd, hoe ValueCare met verschillende ROM vragenlijsten inzichtelijke gestandaardiseerde ROM waardes berekent, en wordt een toelichting gegeven over verschillende ROM dashboards die ValueCare presenteert aan GGZ instellingen.
== Inleiding ==
Deze pagina dient als naslagwerk om de managementrapportages op de Routine Outcome Monitoring (ROM) te interpreteren en gebruiken.

De doelen van managementrapportage inzake ROM betreft het bieden van inzicht in:

* De (tijdige) inzet van ROM instrumenten op de juiste momenten
* De effecten van de ingezette behandeling

Op deze pagina is een overzicht van definities te vinden, gevolgd door een toelichting op de totstandkoming. De relevante toepassing van de ROM wordt als laatste uitgelicht.

== Definities ==
Hieronder staan alle relevante termen met betrekking tot de ROM gedefinieerd en waar relevant extra toegelicht.

Let op: inmiddels zijn er ook ROM metingen te monitoren voor soorten GGZ Zorg anders dan ZPM (ZVW/FM). De functionaliteiten van reeksen werkt hierbij anders. Deze informatie is inmiddels toegevoegd aan deze pagina.
{| class="wikitable"
|+
!Term
!Definitie
!Toelichting
|-
|Voor- en nametingen
|De voor- en nametingen vormen de kapstok voor het bepalen of er een geldige ROM voormetingen dan wel nametingen uitgevoerd is voor het ZPM zorgtraject. Voor andere financieringsstromen geschiedt dit voor de daarvoor leidende zorgproducten (bijvoorbeeld een jeugdproduct). Daarnaast wordt per meting de T-score bepaald, zodat het effect kan worden gemeten door de T-score van de nameting te vergelijken met de voormeting.
| Note: de organisataie-eenheid van metingen/meetmomenten wordt bepaald aan de hand van de organisatie-eenheid die bij het zorgproduct zit.
|-
|Voormeting
|Het eerste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de voormeting. Hierop is een (instelbare) marge in dagen van toepassing om als geldige voormeting te tellen.
| nvt
|-
|Nameting
|Het laatste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de nameting. Ook hierop is een (instelbare) marge in dagen van toepassing om als geldige nameting te tellen.
|De nameting van het voorgaande zorgtraject mag gezien worden als voormeting van het nieuwe traject, indien het voldoen aan de eisen:

* Marge in dagen t.o.v. eerste behandelcontact in nieuwe zorgtraject

* Vragenlijst wordt gebruikt binnen de diagnose hoofdgroep

Notes:

* Als er nog geen einddatum is bepaald voor een behandelreeks, verwachten we dat er nog behandelcontacten gaan volgen. In dit geval bepalen we wel een laatste (ofwel meest recente) behandelcontact, maar valideren we nog niet of er een geldige nameting is geweest.
* Als er een verwachte einddatum (in de toekomst) is ingevuld voor een behandelreeks, dan kijken we voor een valide nameting binnen het tijdsinterval rondom de einddatum van de behandelreeks
* Als de einddatum van een zorgtraject reeds voorbij is, dan kijken we naar het laatste (ofwel meest recente) behandelcontact
|-
|Tussenmetingen
|Voor mensen die langdurig in zorg zijn (en hetzelfde zorgtraject hebben) zijn regelmatigere tussentijdse metingen van ROM is wenselijk. Het gewenste tijdsinterval verschilt per instelling, daarom is een tijdsinterval in te stellen. Voor informatie over het instelbare tijdsinterval, zie ''Tijdsinterval''.
|
|-
|Valide meting
|Een valide meting is een meting die:

* is aangemerkt als ROM
* volledig is ingevuld
* Als de diagnosegroep van het zorgtraject gevuld is, wordt met Beheer BI: Vragenlijst per diagnose bepaald of de vragenlijst in aanmerking komt voor de diagnose hoofdgroep.
** Indien de diagnosegroep leeg is, tonen we op dit moment geen meetmomenten in de dataset.
|
|-
|Tijdsinterval
|Hiermee wordt gedoeld op de gewenste tijd tussen ROM metingen. Zie ook definitie ''tussenmetingen''. De tijdsinterval is door de instelling zelf in te stellen. De tijdsinterval kan verschillen per type vragenlijst en diagnose en kan ingesteld worden via de beheertabel Beheer BI: Vragenlijst per diagnose
|<code>Stuurinformatie > Beheer BI > Beheer BI: Vragenlijst per diagnose</code>
|-
|Meetmoment
|Indien er geen meting plaatsvindt binnen het ingestelde tijdsinterval, wordt er een meetmoment aangemaakt. Dit is dus een moment waarop er een meting verwacht werd, maar deze niet is gedaan.
|Zie ook "Totstandkoming - Stappenplan - stap 3: Nummering metingen" hieronder.
|-
|Initiële meting
|Dit is de eerste valide meting binnen een reeks. De initiële meting is nodig als aanvulling op de voormeting voor de gevallen waarin de voormeting gegenereerd is (en dus geen valide meting is). In deze gevallen is de initiële meting de eerste valide meting binnen een reeks.
|Zie ook "Toepassing - (Delta) t-score" hieronder.
|-
|Behandelreeks
|Alle meetmomenten binnen een zorgtraject in combinatie met de DBC’s.
Binnen één behandelreeksmoeten de onderstaande aspecten overeenkomen. Komen deze aspecten niet overeen, dan geldt dat als een andere behandelreeks.

*'''Inschrijving (en daarmee ook cliënt)'''
** Als een inschrijving eindigt, eindigt de behandelreeks

*'''Diagnose '''
** Is er een nieuwe diagnose gesteld is, eindigt de behandelreeks
*'''Zorgtraject / DBC / Jeugd / WMO '''
** Als er een nieuw zorgtraject, jeugdproduct, of wmo product is, eindigt de behandelreeks
|Bij Jeugd en WMO worden aansluitende toewijzingen als een en dezelfde behandelreeks gezien.

Als er voor een Jeugd product of WMO product een nieuw product is aangemaakt met een zelfde product-code wordt dit ondervangen in dezelfde behandelreeks. Dit geldt enkel als het nieuwe product binnen 35 dagen na sluiting van het vorige product is aangemaakt. Hierbij moet er ook sprake zijn van dezelfde product-code, zelfde diagnose, en dezelfde inschrijving (en dus cliënt).
|-
|Reeks
|Een behandelreeks kan bestaan uit meerdere reeksen. Dit is afhankelijk van de instelling van GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST. Mits er meerdere type vragenlijsten zijn afgenomen, kan er voor elk type vragenlijst een aparte reeks worden aangemaakt. De voor- en nameting worden op het niveau van de behandelreeks gedefinieerd. Oftewel, mits er een voormeting is afgenomen binnen één van de reeksen met dezelfde behandelreeks, zal deze voormeting getoond worden voor al die reeksen.

* '''Behandelreeks'''

*'''(Optioneel) vragenlijst code'''
** Instelbaar
** Wordt enkel toegepast op behandelreeksen met één of meer geldige metingen
** Mits parameter = ‘JA’: dan geldt dat voor een andere vragenlijst-code een andere reeks wordt gemaakt (
*** T-scores worden enkel vergeleken voor vragenlijsten met hetzelfde type (bijv. enkel HoNOS vragenlijsten binnen één behandelreeks).
*** Meetmomenten worden gegenereerd voor elke type vragenlijst. Bijvoorbeeld, is er een HoNOS U verwacht dan voor elk type vragenlijst een nieuw meetmoment. (
** Mits parameter = ‘Nee’: dan geldt dat voor een andere vragenlijst-code dezelfde reeks wordt gebruikt
*** T-scores worden vergelijken onafhankelijk van het type vragenlijsten (Bijvoorbeeld, HoNOS en FARE worden afwisselend gebruikt).
*** Verwachtte meetmomenten worden enkel gegenereerd als er geen meting is geweest binnen het tijdsinterval voor alle type vragenlijsten.
|[[Bestand:ROM reeks.jpg|gecentreerd|392x392px]]
|-
|(Delta)-T score
|De T-score is een uniforme maat om de diverse vragenlijsten naar scores te transformeren en loopt van 0-100. Een succesvolle behandeling zorgt voor een lagere nametingen dan de voormeting (behalve bij het meetinstrument MANSA-16). De Delta-T score is het verschil in T score tussen twee T scores.

Zie voor interpretatie van de Delta T-score de tabel onder "Toepassing - interpretatie delta T-score"
|
|-
|Gekoppeld meetmoment
|Een gekoppeld meetmoment is een valide meting die binnen de data van een behandelreeks valt. Een ongekoppelde meetmoment kan een valide meting zijn die buiten de behandelreeks valt. Of het kan een invalide meting zijn (die binnen of buiten een eventuele behandelreeks valt).
|Zie ook de visualisatie in de executive summary bovenaan deze pagina.
|}

== Totstandkoming ==

=== Stappenplan ===
Hieronder is het stappenplan uitgewerkt dat gevolgd wordt om de berekeningen voor de ROM te maken.

Per stap is toelichting gegeven en zo nodig een extra visualisatie toegevoegd.
{| class="wikitable"
|+
!Stap
!Toelichting
!
|-
|0: Bepalen behandelingen binnen behandelreeks
|Eerst wordt bepaald naar welke behandelingen we moeten kijken om de uitersten van behandelreeks te kunnen bepalen.

* Mits het ZPM zorgtraject is aangemaakt met zorglabel N02 (''Overgang oude bekostiging met direct tijd naar Zorgprestatiemodel''), wordt de voormeting bepaald op basis van de voorafgaande DBC(s). De DBCs die worden meegenomen bij de betreffende zorgtrajecten, zijn DBCs die dezelfde (1) diagnose en (2) inschrijvingsnummer hebben als het zorgtraject.

* Voor de combinatie van de zorgtrajecten met eventuele DBCs (en losse DBCs) kijken we naar alle behandelcontacten met directe tijd.
** Voor een dergelijke behandelreeks moeten we het eerste/laatste behandelcontact bepalen.
|[[Bestand:Stap 0 ROM .png|gecentreerd|miniatuur|800x800px]]
|-
|1: Bepalen uitersten van behandelreeks
|Als er bepaald is welke behandelingen in een behandelreeks vallen, wordt er per behandelreeks bepaald:

* Het eerste behandelcontact
* Het laatste behandelcontact

LET OP

Er moet directe tijd zijn geschreven op het behandelcontact en er moet een diagnose bekend zijn voor de behandelreeks. De diagnose is nodig om te bepalen of een eventuele ROM-meting met een vragenlijst is afgenomen die geldig is bij die specifieke diagnose
|[[Bestand:ROMstap1 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|-
|2: Bepalen valide metingen
|Dan wordt er gekeken of er binnen de vastgestelde uiterste waarden van een behandelreeks, valide metingen te vinden zijn.

* Mits er een valide meting te vinden is, dan wordt de behandelreeks, en (optioneel) type vragenlijst meegenomen in de behandelreeks.

* Mits er geen valide meting te vinden is, dan is een reeks enkel bepaald op basis van de behandelreeks. In dit geval zullen er dan ook geen geldige metingen te tonen zijn in de dataset. Er worden wel twee meetmomenten gegenereerd, namelijk het verwachte voormeetmoment en het verwachte nameetmoment.
|[[Bestand:ValueCare - ROM (1).png|gecentreerd|miniatuur|800x800px]]
|-
|3:Nummering metingen
|We nummeren de opvolgende metingen binnen een behandelreeks op basis van de datum van afname.
Hierdoor kunnen we de opvolgende metingen makkelijk koppelen.

Met behulp van het tijdsinterval per type vragenlijst en diagnose, kunnen we bepalen of de opvolgende metingen plaats hebben gevonden binnen het tijdsinterval (t.o.v. de vorige meting), waarbinnen ze worden verwacht.
{| class="wikitable"
|+
!Optie
! colspan="2" |Situatie
!Gevolg
|-
|A
| colspan="2" |De volgende meting valt binnen tijdsinterval
|De volgende meting is een valide meting. Let op: alle valide metingen moeten voldoen aan de criteria gedefinieerd in stap 2.
|-
|B
| colspan="2" |De volgende meting valt buiten tijdsinterval
|Genereren meetmoment (dus geen valide meting). Dit meetmoment moet duidelijk maken aan instellingen dat er een meting verwacht wordt, maar deze meting niet (valide of volledig) is afgenomen.
|-
|C
| rowspan="2" |Geen volgende meting
|Laatste behandelcontact is in het verleden geweest
|Genereren meetmomenten tot en met het laatste behandelcontact.
|-
|D
|Laatste behandelcontact wordt in de toekomst verwacht
|Genereren meetmomenten tot en met de aanleverdatum.
|}
|[[Bestand:ROM stap 3 diagram update .jpg|alt=|gecentreerd|miniatuur|1300x1300px]]
|-
|4: Bepalen voor- en nameting
|Het bepalen van de voor- en nametingen:

De metingen die binnen een reeks het dichtste bij het eerste/laatste behandelcontact liggen worden bestempeld als voor- of nameting.

Indien er enkel een voormeting of een nameting is en niet beide, dan genereren we een meetmoment voor de missende voor- of nameting, met als datum het eerste/laatste behandelcontact.

* Mits er een valide meting heeft plaatsgevonden in de reeks, bepalen we of de meting een valide voor- of nameting is aan de hand van een marge rondom het eerste- of laatste behandelcontact. Deze marges worden bepaald aan de hand van parameters BI_MARGE_RONDOM_EERSTE_BEHANDELCONTACT_VOORMETING en BI_MARGE_RONDOM_LAATSTE_BEHANDELCONTACT_NAMETING .
* Optioneel: Instelbaar
** Mits er voor een reeks meerdere type vragenlijst worden gebruikt (bijv. zowel Honos-12 als SQ48) dan wordt er voor elk type vragenlijst een aparte reeks aangemaakt. De voor- en nametingen worden onafhankelijk van type vragenlijst bepaald. Dit wordt dus gedaan voor de overkoepelende behandelreeks.
|[[Bestand:ROMstap4 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|}

=== Gebruikte beheertabellen en parameters ===
Hieronder zijn de parameters en beheertabellen met relevante toelichting te vinden. De dataset die voor de ROM gebruikt wordt is <code>ROM meetmomenten.</code>
{| class="wikitable"
|+
!Parameters
!Toelichting
|-
|BI_MARGE_RONDOM_EERSTE_BEHANDELCONTACT_VOORMETING
|Bandbreedte in dagen rondom eerste behandelcontact zorgtraject waarbinnen een geldige voormeting afgenomen moet zijn
|-
|BI_MARGE_RONDOM_LAATSTE_BEHANDELCONTACT_NAMETING
|Bandbreedte in dagen rondom laatste behandelcontact zorgtraject waarbinnen een geldige nameting afgenomen moet zijn
|-
|GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST
|Of een reeks rekening moet houden met aparte type vragenlijsten of niet.

Mits parameter = JA, genereren we voor elke verschillende vragenlijst-code binnen een behandelreeks, een aparte reeks

Mits parameter = NEE, mogen de vragenlijsten onafhankelijk van elkaar afgenomen zijn

''NOTE: deze parameter wil ik nog hernoemen naar GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST''
|-
|''GGZBI_TIJDSINTERVAL_ROM_MEETMOMENTEN_ONAFHANKELIJK_VAN_TYPE''
|Het tijdsinterval dat gebruikt wordt voor reeksen, waarbij geen tijdsinterval bepaald is in de beheertabel 'Beheer BI: Vragenlijst per diagnose'
|}
{| class="wikitable"
|+
!Beheertabel
!Toelichting
|-
|Beheer BI: Vragenlijst per diagnose
|Per diagnosehoofdgroep kan het gebruikte ROM-instrument aangegeven worden.
In deze beheertabel kan ook het interval per type vragenlijst en diagnose ingesteld worden. (NIEUW!)
|-
|Beheer BI: Vragenlijst
|Per vragenlijst kan worden aangegeven of deze wordt gebruikt als ROM- en/of CQI-instrument
|-
|Beheer BI: Parameters
|Voor het instellen van o.a. de hierboven genoemde parameters.
|}

== Toepassing ==

In dit deel worden de toepassingen toegelicht, deze toepassingen zijn gericht op het behalen van de doelen van de managementrapportage inzake ROM zoals beschreven in de inleiding van deze pagina.

=== Beheertabel ===

Zoals hierboven al vaker aangegeven zijn er een aantal dingen instelbaar via beheertabellen. Zie ook het overzicht van beheertabellen hierboven.

De instellingen van deze beheertabellen hebben invloed om de onderstaande toepassingen en dienen dus correct ingevuld te zijn om de toepassing zo nuttig en accuraat mogelijk te laten zijn.

=== ROM Meetmomenten ===
De Routine Outcome Monitoring (ROM) is een complex product met tal van mogelijkheden en variaties.

Om de ROM behapbaar te maken is deze executive summary gemaakt met 1 figuur waarin de werking van de ROM gevisualiseerd is.

De verdiepende informatie (bv definities en stappenplan) is ook op deze pagina te vinden, onder deze samenvatting.

Er zijn twee verschillende situaties:

#<code>GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST = 'NEE'</code>: hier mogen verschillende type vragenlijsten gecombineerd worden.
#<code>GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST = 'JA'</code>: hier mogen de verschillende type vragenlijsten niet gecombineerd worden.
Deze twee situaties zijn onder elkaar gevisualiseerd.

[[Bestand:Exe sum (1).jpg|alt=|geen|miniatuur|1549x1549px|Executive summary ROM]]

=== Berekening ROM scores ===
Voor instellingen die gebruik maken van bronsysteem 'Questmanager' berekent ValueCare zelf de ruwe scores, op basis van onderstaande codes per vragenlijst type.

==== Berekening ruwe scores ====
{| class="wikitable"
!Type Vragenlijst
!Eigenschappen
!Definities
|-
| rowspan="3" |SQ48
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen groter is dan, of gelijk is aan 30. Dit betekent dat er minimaal 30 vragen moeten zijn ingevuld om de berekening uit te voeren.
|-
|Berekening ruwe score
|Ruwe score wordt berekend met de formule: som_ingevulde_scores * 37 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores (som_ingevulde_scores) vermenigvuldigd met 37 (het totale aantal vragen in de vragenlijst) en gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van missende waardes met de gemiddelde waarde.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal. De vraagcodes verschillen per instelling.
|-
| rowspan="3" |OQ45
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen (aantal_vragen_ingevuld) groter is dan of gelijk is aan 20. Dit betekent dat er minimaal 20 vragen moeten zijn ingevuld om de berekening uit te voeren.
|-
| Berekening ruwe score
|Ruwe score wordt berekend met de formule: som_ingevulde_scores * 25 / aantal_vragen_ingevuld.
Hierbij wordt de som van ingevulde scores (som_ingevulde_scores) (zie onderstaand kopje) vermenigvuldigd met 25 (het totale aantal vragen in de lijst) en gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van missende waardes met de gemiddelde waarde.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal. De vraagcodes verschillen per instelling.
|-
| rowspan="3" |SDQ-P
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen groter is dan, of gelijk is aan 16. Dit betekent dat er minimaal 16 vragen moeten zijn ingevuld om de berekening uit te voeren.
|-
|Berekening ruwe score
|Ruwe score wordt berekend met de formule: som_ingevulde_scores * 20 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores (som_ingevulde_scores) vermenigvuldigd met 20 (het totale aantal vragen in de vragenlijst) en gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van de missende waardes met de gemiddelde waarde.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal. De vraagcodes verschillen per instelling.
|-
| rowspan="5" |SDQ-s11-17
| Voorwaarden voor berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen groter is dan of gelijk is aan 16. Dit betekent dat er minimaal 16 vragen moeten zijn ingevuld om de berekening uit te voeren.
|-
|Berekening ruwe score
|Ruwe score wordt berekend met de formule: som_ingevulde_scores * 20 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores (som_ingevulde_scores) vermenigvuldigd met 20 (het totale aantal vragen in de vragenlijst) en gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van missende waardes met de gemiddelde waarde.
|-
|Berekening van de som_ingevulde_scores
|Er wordt een som berekend op basis van een 'case'-statement dat specifieke vragen identificeert (vragen met bepaalde codes) en hun antwoordwaarden omschrijft. De specifieke vragen zijn gedefinieerd in de lijst met vraagcodes, en voor sommige van deze vragen wordt de waarde omgerekend met de formule: '2 - t0.vragenlijst_antwoord_waarde::int', anders blijft de oorspronkelijke waarde behouden. Deze omgerekende of onveranderde waarden worden vervolgens opgeteld om de 'som_ingevulde_scores' te verkrijgen. Deze vraagcodes verschillen per instelling.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal. De vraagcodes verschillen per instelling.
|-
|Groeperen van resultaten
|De resultaten worden gegroepeerd op basis van kolommen aangeduid met 'group by 1, 2'.
|-
| rowspan="4" |BSI
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen (aantal_vragen_ingevuld) groter is dan of gelijk is aan 43. Dit betekent dat er minimaal 43 vragen moeten zijn ingevuld om de berekening uit te voeren.
|-
|Berekening van de ruwe score
|Ruwe score wordt berekend met de formule: som_ingevulde_scores * 1 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores gedeeld door het aantal ingevulde vragen. Er is geen omrekening van de scores; het is gewoon het gemiddelde.
|-
|Berekening van de som_ingevulde_scores
|Er wordt een som berekend van de ingevulde scores. Deze som wordt verkregen door de waarden van de kolom 't0.vragenlijst_antwoord_waarde' op te tellen.
|-
|Filteren van de gegevens
|De antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal.
|-
| rowspan="3" |HoNOS-12
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen groter is dan, of gelijk is aan, 10. Dit betekent dat er minimaal 10 vragen moeten worden ingevuld om de berekening uit te voeren.
|-
|Berekening ruwe score
|Ruwe score wordt berekend met de formule: som_ingevulde_scores * 12 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores (som_ingevulde_scores) vermenigvuldigd met 12 (het totale aantal vragen in de lijst) en gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van missende waardes met de gemiddelde waarde.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal. De vraagcodes verschillen per instelling.
|-
| rowspan="3" |HoNOS-65
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen groter is dan, of gelijk is aan, 10. Dit betekent dat er minimaal 10 vragen moeten worden ingevuld om de berekening uit te voeren.
|-
|Berekening van de ruwe score
|De ruwe score wordt berekend met de formule: som_ingevulde_scores * 12 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores (som_ingevulde_scores) vermenigvuldigd met 12 (het totale aantal vragen in de lijst) en gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van missende waardes met de gemiddelde waarde.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', of '4'. De antwoorden komen dus uit op een 5-punts Likert-schaal. De vraagcodes verschillen per instelling.
|-
| rowspan="3" |MANSA-16
|Voorwaarden voor de berekening
|De ruwe score wordt alleen berekend als het aantal ingevulde vragen groter is dan, of gelijk is aan, 10. Dit betekent dat er minimaal 10 vragen moeten worden ingevuld om de berekening uit te voeren.
*
|-
| Berekening ruwe score
|De ruwe score wordt berekend met de formule: som_ingevulde_scores * 1 / aantal_vragen_ingevuld.
Hierbij wordt de som van de ingevulde scores (som_ingevulde_scores) gedeeld door het aantal ingevulde vragen. Dit geeft een gemiddelde score, inclusief de imputatie van de missende waardes met de gemiddelde waarde.
|-
|Filteren van de gegevens
|De vraagcodes moeten overeenkomen met specifieke lijsten van vragen, en de antwoordwaarden moeten overeenkomen met '0', '1', '2', '3', '4' '5', '6', of '7'. De vraagcodes verschillen per instelling.
|}

==== Berekening T-scores ====
{| class="wikitable"
! Type vragenlijst
!Berekening
|-
|SQ48
|De T-score wordt berekend met de volgende formule: 24.70535964913392 + (0.3751176991148195 * ruwe_score_vc) + (-0.0009187118790624546 * ruwe_score_vc^2) + (0.00000670607402179293 * ruwe_score_vc^3).

Hier staat ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
|OQ45
|De T-score wordt berekend met de volgende formule: 17.9856940411384 + (2.56446078269377 * ruwe_score_vc) + (-0.0558628542617925 * ruwe_score_vc^2) + (0.000976254840029574 * ruwe_score_vc^3).

Hier staat ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
|SDQ-P
|De T-score wordt berekend met de volgende formule: 17.9856940411384 + (2.56446078269377 * ruwe_score_vc) + (-0.0558628542617925 * ruwe_score_vc^2) + (0.000976254840029574 * ruwe_score_vc^3).

Hier staat ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
| SDQ-s11-17
|De T-score wordt berekend met de volgende formule: 20.3713833471163 + (2.49157128999528 * ruwe_score_vc) + (-0.0493700167712384 * ruwe_score_vc^2) + (0.000942819943550291 * ruwe_score_vc^3).

Hier staat ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
|BSI
|De T-score wordt berekend met de volgende formule: 26.42038565180546 + (26.8200050937306 * ruwe_score_vc) +(-8.284911648378781 * ruwe_score_vc^2) + (1.350267912166433 * ruwe_score_vc^3).

Hier staat ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
|HoNOS-12
|De T-score wordt berekend met de volgende formule: 27.00023405117865 + (2.450806391090429 * ruwe_score_vc) + (-0.04649228749948154 * ruwe_score_vc^2 ) + (0.0005045255416624083 * ruwe_score_vc^3).

Hier staat ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
|HoNOS-65
|De T-score wordt berekend met de volgende formule: 23.3163221392 + (2.7836900604 * ruwe_score_vc) + (-0.0672989375* ruwe_score_vc^2) + (0.0009265311* ruwe_score_vc^3).

Hier staat de ruwe_score_vc voor de ruwe score die is berekend met behulp van de formule in de tabel hierboven.
|-
|MANSA-16
|De T-score wordt berekend met de volgende formule: t_score = ruwe_score_vc. Dit betekent dat voor deze vragenlijst de ruwe score hetzelfde is als de uiteindelijke T-score.
|}
===Andere bronsystemen===
==== Ruwe score = T-score====
Voor sommige bronsystemen komt de T-score vanuit de bron zelf. ValueCare doet dat geen berekening voor een ruwe score of een T-score.

Via beheertabel 'Beheer BI: Vragenlijst subschalen' kan de T-score worden ingericht. Deze T-score zal als één van de subschalen zijn ingericht. Mocht deze T-score vanuit de bron niet goed worden overgenomen, dan kan deze worden aangepast door de gebruiker. Als de subschalen voor een vragenlijst-type nog niet zichtbaar zijn, dan moet het vinkje 'Subschalen inrichten' in 'Beheer BI: Vragenlijsten' nog worden aangeklikt.
=== (Delta) t-score ===
De instellingen vinden het vooral belangrijk om de t-scores te weten die bij een ROM meting hoorde. Daarnaast willen ze de delta t-score weten, zodat ze kunnen zien of een cliënt verbeterd of juist verslechterd in de loop der tijd.

Voor een gegenereerd meetmoment hebben we geen t-score. Daardoor kunnen we enkel t-scores vergelijken van valide metingen. We tonen in dataset ROM meetmomenten daarom enkel delta t-scores voor valide metingen ten opzichte van valide metingen. Dit houdt ook in dat voor gegenereerde voormeetmomenten, we geen delta t-score ten opzichte van de voormeting kunnen doen. Om dit te voorkomen, hebben we de ‘initiële meting’ geïntroduceerd. Dit is de eerste valide meting binnen een reeks. We hebben op deze manier dus twee type delta t-scores in de dataset: (1) delta t-score t.o.v. de vorige valide meting, (2) delta t-score t.o.v. de initiële meting.

[[Bestand:Deltat nieuw.jpg|alt=|gecentreerd|miniatuur|800x800px]]

==== Interpretatie Delta T-score ====
Zie de tabel hieronder voor de interpretatie van de Delta T-score:
{| class="wikitable"
|+
!Code
!Classificatie
!Delta T-score
|-
|1
|Hersteld
|> 5 <code>AND</code> voormeting t > 42,5 <code>AND</code> nameting t < 42,5
|-
|2
|Verbeterd
|> 5
|-
|3
|Onveranderd
| -5 < delta t < 5
|-
|4
|Verslechterd
|< -5
|}

=== KPI's en dashboards ===
Voor de ROM biedt ValueCare verschillende dashboards in het portaal.

Deze zijn te vinden onder <code>Meer dashboards > ROM > ROM - Delta t-score</code> en <code>Meer dashboards > ROM > ROM - Proces valide metingen</code>.

Zie hieronder een overzicht:
{| class="wikitable"
|+
!Dashboard
!Tegel
!Toelichting
|-
| rowspan="4" |Delta t-score
|Delta T-score ROM per maand
| rowspan="4" |Delta-T wordt per patient/behandeling berekend als de verschilscore tussen de vorige meting en huidige meting.
|-
|Delta T-score ROM per organisatieniveau
|-
|Delta T-score ROM per soort vragenlijst
|-
|Delta T-score ROM per RCI
|-
| rowspan="4" |Proces valide metingen
|Valide ROM metingen per maand
| rowspan="4" |De rapportage toont het aantal valide metingen. De rapportagedatum is gelijk aan de datum waarop de meting is afgenomen of anders de uiterlijke datum waarop de meting verwacht wordt.
|-
|Valide ROM metingen per organisatieniveau
|-
|Valide ROM metingen per soort vragenlijst
|-
|Valide ROM metingen per soort meetmoment
|-
| rowspan="4" |Effectmeting
|ROM RCI score per maand
|Alle RCI waarden van diverse meetinstrumenten zoals IDS-SR, HoNOS65, etc. gegroepeerd per dbc sluitdatum (einddatum DBC)

Deze rapportage laat de gemiddelde ROM Deltra-t score zien.
|-
|ROM HoNOS65 subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 11 vragen uit de HoNOS65 vragenlijst.
|-
|ROM RCI score per diagnosegroep
|Deze rapportage laat de ROM RCI score zien per diagnosegroep. In de tabel onder de grafiek is meer verdiepende data te vinden. Deze rapportage laat de gemiddelde ROM Delta-T score zien.
|-
|ROM CANSAS subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 25 vragen uit de CANVAS vragenlijst.

Proportie cliënten met onopgeloste zorgbehoeften is het percentage cliënten dat minimaal 1 heeft gescoord op de subschaal "onopgeloste zorgbehoeften" tov het totaal aantal cliënten.
|-
| rowspan="4" |Effectmeting Delta t-score
|ROM Delta-T score per maand
|Rapportage: gemiddelde ROM Delta-T score per maand.
|-
|ROM Delta-T score per org. niv.
|Rapportage: gemiddelde ROM Delta-T score per organisatie niveau.
|-
|ROM Delta-T score per diagnosegroep
|Rapportage: gemiddelde Delta-T score per diagnosegroep.
|-
|ROM Delta-T score per jaar
|Rapportage: gemiddelde Delta-T score per jaar.
|}
{{VALUECARE}}

Vragenlijsten (GGZ)

2023-11-29T13:25:15Z

Cbruin: /* Doel */

ZPM Omzetprognose

2023-08-02T07:07:22Z

Cbruin: /* Unieke cliënten */

{{VALUECARE}}

== Inleiding ==
De ZPM omzetprognose ondersteunt zorgorganisaties bij het bewaken van de omzet. Hiervoor worden winskundige modellen ingezet. De ZPM omzetprognose doet een voorspelling op de bruto omzetprognose (zie ook diagram ''Totstandkoming ZPM Omzetprognose'' hieronder).

De ZPM omzetprognose is in het portaal te vinden onder <code>Omzetprognose > ZPM Omzetprognose</code> (zie schermafbeeldingen hieronder).
[[Bestand:Balk.jpg|gecentreerd|miniatuur|1500x1500px]]
[[Bestand:ValueCare - Pagina 9 (1).jpg|gecentreerd|miniatuur|500x500px]]

== Totstandkoming ==
Volgens het ZPM worden voorspellingen gedaan per ZPM declaratiecode-categorie, te weten: consulten, verblijfsdagen, toeslagen en overige zorgprestaties (OZP). Voor (groeps)consulten, toeslagen en OZP wordt er gebruik gemaakt van een trendlijn die doorgetrokken wordt naar het voorspelde jaar. Voor de prognose van verblijf wordt gebruik gemaakt van het gemiddelde aantal bedden per dag binnen een instelbare referentieperiode.

[[Bestand:DiagamB0.jpg|gecentreerd|miniatuur|900x900px|Totstandkoming ZPM Omzetprognose ]]

=== (Groeps)consulten, OZP en toeslag consult ===
De voorspellingen op (groeps)consulten, OZP en toeslagen worden gemaakt aan de hand van een trendlijn (zie ook diagram ''Trendlijn voor prognose (groeps)consulten, OZP en toeslagen'' hieronder). Deze trendlijn neemt de realisatie van het voorgaande jaar (jaar n-1) en de realisatie van het huidige jaar minus twee weken geleden (jaar n-2w) als input. Op aanvraag kan de referentieperiode van een jaar aangepast worden naar bijvoorbeeld twee jaar. Daarnaast wordt rekening gehouden met de seizoensgebonden afwijkingen. De trendlijn wordt doorgetrokken van het gerealiseerde jaar naar de rest van het voorspelde jaar.

Om tot een voorspelling per maand en week te komen wordt er gekeken naar de procentuele afwijking van de gerealiseerde omzet ten opzichte van de trendlijn. Om bijvoorbeeld de omzet van april te voorspellen wordt er gerekend met de afwijking van april in de referentieperiode ten opzichte van de trendlijn. Als deze afwijking 5% boven de trendlijn is, dan ligt de voorspelling van in het voorspelde jaar ook 5% boven de trendlijn. Op deze manier kan de gehele voorspelling worden gedaan per maand en per week. In deze voorspelling wordt ook rekening gehouden met feestdagen en schrikkeldagen, waardoor week en maand voorspellingen representatief blijven.

[[Bestand:Trendlijn prognose omzetprognose diagram.jpg|gecentreerd|miniatuur|900x900px|Trendlijn voor prognose (groeps)consulten, OZP en toeslagen ]]

=== Verblijf en toeslag verblijfsdag ===
Voor de omzetprognose van verblijf hanteren we een instelbare referentieperiode. Binnen deze periode kijken we naar het gemiddelde aantal bedden per dag. Er wordt gekeken naar de verdeling van het aantal bedden per verzekeraar en aan de hand van deze verdeling wordt een verdere voorspelling gedaan.

Dit maakt de voorspelling verblijfsdagen als volgt:

a + b*c, waarbij

a = gerealiseerde verblijfsdagen huidige kalenderjaar

b = gemiddeld aantal bedden per dag in referentieperiode

c = aantal resterende dagen in kalenderjaar

N.B.: deze verblijfsdagen worden verdeeld naar financier en verblijfszwaarte op basis van de gerealiseerde proportie verblijfsdagen per financier en verblijfszwaarte in huidige kalenderjaar

=== '''Unieke cliënten''' ===
ZPM Omzetprognose bevat tevens een voorspelling op het aantal unieke cliënten in het betreffende kalenderjaar bij betreffende financier.
Een unieke cliënt is als volgt geoperationaliseerd: Unieke telling van geanonimeerde BSN code van cliënten met binnen het kalenderjaar bij betreffende financier:

- Een declarabele zorgprestatie

- Mét gekoppelde declaratiecode

- Waarvan niet een OZP “crisis binnen budget”

- Waarvan niet een OZP "FZ-ZZP"

De prognose werkt als volgt: d = a / b * c, waarbij

a = totaal aantal unieke cliënten in referentiejaar

b = gerealiseerd aantal unieke cliënten tot datum van prognosticeren in referentiejaar (vorig jaar)

c = gerealiseerd aantal unieke cliënten in huidige kalenderjaar tot datum van prognosticeren

d = totaal aantal unieke cliënten in huidige kalenderjaar

N.B.: voor voorspelling van unieke cliënten op lagere aggregatieniveaus (bijv. setting) werkt de prognose hetzelfde.
=== Realisatiedatum t/m ===
De prognose werkt met een vertraging van 2 weken, omdat het rekening houdt met na-registratie. Uit onze gegevens blijkt dat bijna alle registraties binnen 2 weken worden geregistreerd. De realisatie is dus pas na 2 weken nagenoeg compleet en wordt daarom dan pas getoond. Zonder deze vertraging zou er een vertekend beeld van de realisatie ten opzichte van de prognose kunnen ontstaan. In het menu is onder ''“Realisatiedatum t/m”'' de huidige realisatiedatum zichtbaar. De realisatiedatum t/m wordt iedere week geüpdatet.

==Parameters==
De ZPM omzetprognose berust op verschillende parameters, standaard (tabel ''Standaard parameters'') en instelbaar (tabel ''Instelbare parameters'').

De waardes van deze parameters worden gebruikt voor het prognosticeren.

{| class="wikitable"
|+Standaard parameters
!Parameter
!Omschrijving
|-
|Voorspelde jaar
|Dit is het jaar waarvoor geprognosticeerd wordt en waarvoor de VAR berekend wordt
|-
|Begindatum referentieperiode
|Vanaf deze datum gebruikt het model data als input
|-
|Einddatum referentieperiode
|Tot en met deze datum gebruikt het model data als input
|-
|Huidige bedcapaciteit
|Dit is de huidige bedcapaciteit zoals berekend door het model
|-
|Begindatum getoonde realisatie
|Vanaf deze datum wordt realisatie getoond in de omzetprognose
|}

=== Alternatief scenario ===
Standaard wordt er geprognotiseerd met het default scenario (1 - Default).

Mocht er sprake zijn van een toename in directe tijd, dan is er de mogelijkheid om hiervoor een alternatief scenario te gebruiken.

Dit is scenario 2 - Toename direct tijd. Hiervoor moeten drie instelbare parameters worden ingevuld, te weten: ''Factor meer directe tijd, Ingangsdatum toename directe tijd'' en ''Scenario UPM''.

De ''Factor meer directe tijd'' bepaalt met wat voor een factor de directe tijd toeneemt. Een factor van 1.2 staat bijvoorbeeld voor een toename van 20%.

Vervolgens moet ingesteld per wanneer deze toename doorgevoerd moet worden (''Ingangsdatum toename directe tijd'').

Om te bepalen welk scenario gebruikt moet worden voor de vulling van de prognose in de UPM, moet dit aangegeven worden bij ''Scenario UPM''.

In het geval van scenario 2 - Toename directe tijd wordt er dan in de UPM gerekend met de aangegeven toename voor omzet en aantal declarabele uren.

Op dit moment is er één alternatief scenario beschikbaar en zijn de overige alternatieve scenario's nog niet in gebruik.

{| class="wikitable"
|+Instelbare parameters
!Parameter
!Omschrijving
|-
|Factor meer directe tijd
|Met deze factor (bijv. 1.2 voor 20% toename) wordt de input van omzet en het aantal declarabele uren verhoogd
|-
|Ingangsdatum toename directe tijd
|Vanaf deze datum wordt de input van omzet en het aantal declarabele uren verhoogd
|-
|Scenario UPM
|Dit is het scenario dat gebruikt wordt voor de vulling van de prognose in de UPM
|-
|Aangepaste bedcapaciteit
|Het model rekent met deze bedcapaciteit vanaf de ingestelde ingangsdatum
|-
|Ingangsdatum aangepaste bedcapaciteit
|Vanaf deze datum rekent het model met de aangepaste bedcapaciteit
|-
|Referentieperiode verblijf voorspelling
|Dit is het aantal dagen dat we terugkijken voor de voorspelling van verblijf
|-
|Bepaling laatste verblijfsdag
|Dit is het minimaal aantal bedden dat geregistreerd moet zijn om in aanmerking te komen als laatste verblijfsdag
|}

=== Onzekere omzet ===
Een component van de ZPM Omzet prognose is de "onzekere omzet".

De operationalisering van hiervan is: alle omzet op de ZPM blokkadelijst van de Horizontaal Toezicht module.

Deze is te vinden onder <code>Horizontaal Toezicht > Horizontaal Toezicht: ZPM Blokkadelijst.</code>

Alle omzet op deze blokkadelijst wordt onder de component "onzekere omzet" geschaard.

== UPM ==
Door middel van de Uniforme Productiemonitor (UPM) kunnen gegevens worden verantwoord aan de verzekeraars. De gegevens in de UPM worden uit het portaal gehaald. ValueCare zet de UPM klaar in het portaal waar deze vervolgens gedownload kan worden.

De UPM is te vinden onder <code>Omzetprognose > Overzichten.</code>
[[Bestand:ValueCare - Pagina 9 (4).jpg|miniatuur|353x353px|alt=|gecentreerd]]

De UPM wordt vervolgens geopend in Excel. Bij het kopje verzekeraar kan de gewenste verzekeraar worden gekozen. Om vervolgens de Excel in te vullen moet er gebruikt worden gemaakt van CTRL + ALT + F9, hierna wordt de UPM ingevuld. Als er hierna een andere verzekeraar wordt gekozen dan wordt de UPM automatisch opnieuw ingevuld.

N.B.: Wacht met gebruiken van de UPM tot er rechts onderin gereed staat.

In de UPM:

* Realisatie cliënten
* Realisatie prestaties
* Omzetprognose

Naast dat de gerealiseerde cijfers met betrekking tot cliënten en prestaties worden ingevuld, wordt dus ook de omzetprognose meegenomen.

=== Peildatum ===
In de UPM wordt er gewerkt met peildata. Let bij het genereren van de UPM dan ook goed op de het juist kiezen van de invuldatum op het voorblad (C6). Nadat hier de invuldatum is gekozen, worden de tabbladen ''Realisatie cliënten, Realisatie prestaties'' en ''Prognose'' gevuld.

vb: peildatum op 1 juni → prognose kolom peildatum 1 juli relevant

N.b.: De realisatiecijfers in de UPM werken niet met dezelfde vertraging van twee weken als de ZPM Omzetprognose. Dit houdt in dat de realisatiecijfers UPM aansluiten op gerealiseerde omzet ZPM Omzetprognose en loggingstabel (zie hieronder) wanneer draaidatum UPM = realisatiedatum t/m van de ZPM Omzetprognose

=== Logging ===
ValueCare doet wat betreft de parameters van de prognose en de realisatie aan dagelijkse logging. Dit houdt in dat de prognose en realisatie data dagelijks wordt vastgelegd. Ondanks dat er met de UPM maandelijkse verantwoording af wordt gelegd, is er dus dagelijks inzichtelijk hoe de prognose en realisatie zich ontwikkelen (of ontwikkeld hebben).

De dagelijkse logging maakt tot op zeer nauwkeurig niveau (1 dag) de veranderingen in prognose en realisatie inzichtelijk. Een dergelijk verloop over een week, maand of specifieke dagen en periodes kan waardevolle inzichten geven.

Deze logging is te vinden op het portaal door in de zoekbalk onderstaande in te vullen:

<code>ZPM Afsprakenmonitor – Logging Parameters Prognose</code>.

== Performance monitor ==
In de performance monitor is te zien hoeveel de prognose afwijkt van de realisatie door middel van percentages en absolute waardes. Met de performance monitor wordt het functioneren van de omzetprognose gevolgd en kunnen afwijkingen snel gesignaleerd worden. Binnen de performance monitor kan gefilterd worden op bijvoorbeeld financier en rapportagedatum.

De performance monitor is te vinden onder <code>Omzetprognose > ZPM Omzetprognose – Performance monitor</code>

[[Bestand:ValueCare - Pagina 9 (3).jpg|miniatuur|350x350px|alt=|gecentreerd]]

== Validatie ==
Zie voor de validatie van het gehele proces van ZPM Bronregistratie tot de ZPM Afsprakenmonitor de pagina [[ZPM Afsprakenmonitor|ZPM Afsprakenmonitor.]]
{{VALUECARE}}

ZPM Omzetprognose

2023-08-01T13:52:08Z

Cbruin: /* Unieke cliënten */

Klant Query Server

2023-05-25T09:23:59Z

Cbruin: /* Van een dashboard of tegel naar de juiste tabel op de Query Server */

== Inleiding ==
Op verzoek stelt ValueCare aan de instellingen een Query Server beschikbaar met daarop een Postgres database met alle source data en BI resultaat data. De door de instelling aangemerkte gebruikers kunnen een connectie maken met de database en er queries op los laten. Ook is het mogelijk om een tool, zoals bijvoorbeeld PowerBI, te connecten tot de database.

== Implementatie ==
Het volgende is nodig vanuit de instelling:

* Een server en het IP adres van de server, tenzij de server wordt gehost door ValueCare.
* Een VPN verbinding van het klantnetwerk naar het ValueCare netwerk.
* Een lijst met gebruikers.

De rest van de implementatie wordt door ValueCare verzorgd.

== Hoe werkt het? ==
In het kort wordt het volgende dagelijks gedaan:

* Er wordt een kopie van de source data en BI resultaat data op de ValueCare Productie server gemaakt.
* Op de Query Server zijn er 2 database schema's: vcs en public. Het vcs schema wordt leeg gemaakt.
* De kopie van de source data en BI resultaat data wordt in het vcs schema geplaatst.
De gebruiker kan vervolgens data in het vcs schema inzien, maar niet wijzigen. In het public schema kan de gebruiker tabellen aanmaken, wijzigen en verwijderen.

== Toelichting data ==

=== De data ===
Er zijn twee schema's beschikbaar op de Query Server: public en vcs. In het vcs schema worden alle bi- en bron-data neergezet, zodat de ValueCare data beschikbaar is. Deze data worden elke dag ververst, zodat het elke dag overeen komt met de data op de Productie-omgeving. Als u op schema vcs een eigen tabel zou aanmaken, wordt deze verwijderd tijdens de verversing. Om met eigen tabellen te werken, is het public-schema beschikbaar. De tabellen die hierop staan, blijven beschikbaar op de Query Server. Hoe u data overzet van schema vcs naar schema public leest u hieronder.

==='''Tabellen kopiëren van schema VCS naar schema Public'''===
Er zijn verschillende manieren om een tabel van schema vcs over te zetten naar schema public. Hieronder is de query uitgeschreven voor één van die manieren. Als je dit vaak wil gebruiken, is het handig om hier een template van te maken (specifiek voor DBeaver). Hier vind je meer over in “Templates”.

CREATE TABLE public.table_name (LIKE vcs.table_name INCLUDING ALL);

INSERT INTO public.table_name

SELECT *

FROM vcs.table_name;

=== '''Van een dashboard of tegel naar de juiste tabel op de Query Server''' ===
Om te begrijpen welke tabellen op de Query Server gebruikt zijn om de tegels en dashboards in het portaal op te bouwen, is de tabel bi_queryserver_tegels_en_dashboards beschikbaar op de Query Server. Hierin kan je zien welke tabellen worden gebruikt in een tegel en/of dashboard. In onderstaand voorbeeld, ziet u dat voor de tegel ‘Waarde verblijfsdagen per maand’, die te vinden is in dataset ‘Verblijf ZPM’, de onderliggende tabel ‘bi_zis_verblijf_zpm’ is. Tabel bi_zis_verblijf_zpm is dan te vinden op de Query Server.
{| class="wikitable"
|'''tegel_naam'''
|'''dataset_naam'''
|'''tabel_naam'''
|'''tegel_beschrijving'''
|-
|Waarde verblijfsdagen per maand
|Verblijf ZPM
|bi_zis_verblijf_zpm
|Deze rapportage toont waarde van de verblijfsdagen voor …
|}
Daarnaast kunt u vanuit het portaal ook het filter 'Paginanaam' gebruiken. Als je deze toevoegt vanuit [+ nieuw filter] onderaan de linker balk met filters, dan ziet u ook welke tabellen er gebruikt worden voor het opstellen van de tegel en/of dashboard. Zoekt u bijvoorbeeld van een dashboard de bijbehorende dataset, dan kunt u ook het filter 'Paginanaam' gebruiken, om deze vervolgens als dataset_naam op de Query Server terug te vinden.

De logica achter de benaming van tabellen op de Query Server is hieronder weergegeven.
{| class="wikitable"
|'''Voorvoegsel'''
|'''Betekenis'''
|'''Uitleg'''
|-
|src_
|Source (bron)
|Alle tabellen die wij direct vanuit een bron ophalen krijgen het voorvoegsel src_. Dit zijn dus tabellen vanuit bronnen, zoals XMCare, MijnQuarant, Beaufort, QuestManager, etc. Ook bestanden die we ophalen vanaf een SFTP server of andere bronnen, krijgen dit voorvoegsel.
|-
|bi_
|Business intelligence
|Alle tabellen die gebruikt worden voor het samenstellen van dashboards en tegels hebben het voorvoegsel bi.
|-
|bi_personeel
|Business intelligence personeel
|Deze data komen vanuit het personeelssysteem. Voor meer informatie, zie [[Stuurinformatie op Financiën|Stuurinformatie op Financiën.]]
|-
|bi_financieel
|Business intelligence financieel
|Deze data komen vanuit het financiële systeem. Voor meer informatie, zie [[Stuurinformatie op Personeel]].
|-
|bi_zis
|Business intelligence ziekenhuis informatie systeem
|Deze data komen vanuit het zis (Ziekenhuis Informatie Systeem) ofwel het EPD (elektronisch patiëntendossier).
|}

== Connectie opzetten ==

# Vraag om de hostname en de databasename bij ValueCare
#* Het kan ook zijn dat de Query Server lokaal gehost wordt, in dat geval is de hostname doorgaans te achterhalen bij uw ICT-afdeling
# Vraag om de username en password bij uw ValueCare contactpersoon.
# Maak de connectie vanuit de tool die u gebruikt, door de hostname en de databasename in te vullen en in te loggen met uw username en password.
#* De Query Server beschikt over een postgres database, dus het poortnummer is de standaard postgres poort (5432)

== Werken met DBeaver en de Query Server ==
Er zijn tal van goede programma's die u kunt gebruiken om te querieën op de Query Server. Mits u gebruik maakt of wilt maken van DBeaver om op de Query Server te querieën, dan vindt u hieronder een aantal instructies en een aantal tips & tricks die het gebruik van DBeaver nog fijner maken.

=== '''Installeren DBeaver''' ===

* Via <nowiki>https://dbeaver.io/download/</nowiki> kunt u DBeaver downloaden.
* Met de standaard instellingen van de installatie kunt u prima op de Query Server komen, maar voelt u zich vooral vrij om de instellingen naar wens aan te passen.

=== '''Connectie opzetten met de database''' ===

# Klik linksboven op het stekkertje om een nieuwe connectie op te zetten. (Dit kan eventueel ook via het menu: Database > New Database Connection
# Selecteer PostgreSQL
# Vul de juiste naam voor de Host in (het poortnummer staat default al goed: 5432)
# Vul de juiste naam voor de Database in
# Vul de juiste Username in (deze heb je ontvangen vanuit ValueCare. Heb je deze nog niet, dan kan je die aanvragen via jouw contactpersoon)
# Ga naar het kopje “Driver properties” en zet hier het veld tcpKeepAlive op ‘True’
# Klik op Finish
# Nu verschijnt er links in de “Database Navigator” een connectie met de naam van de database. Dubbelklik hierop om de connectie te openen
# Vul je wachtwoord in en voilà!

=== '''Tips & Tricks om snel met DBeaver te werken''' ===
'''Overzicht van de functietoetsen'''

Uitvoeren van een query: ctrl + enter

Openen van new script: F3

Geavanceerd kopiëren: ctrl + shift + c (uitgebreidere uitleg onder “Geavanceerd kopiëren”)

'''Templates'''

Templates zijn erg handig in DBeaver. Hiermee kunt u veelgebruikte queries opslaan en hoeft u die niet volledig te typen, als u ze de volgende keer wil gebruiken. Bijvoorbeeld: In plaats van ‘SELECT * FROM table_name;’, type je enkel ‘saf’ en druk je op tab.

Om een template aan te maken gaat u naar: Window > Preferences > SQL Editor > Templates > New.

''Name'': de combinatie aan woorden of letters die u wil typen in plaats van de query

''Pattern'': de query die moet verschijnen als u de Name typt en op Tab drukt.

''Insert variable'': Hiermee kunt u een bepaalde variabele aanroepen nadat u het template gebruikt. Bijvoorbeeld, SELECT * FROM '''${table}'''; zorgt ervoor dat u makkelijk een bestaande tabel kunt selecteren als u het template gebruikt.

'''Geavanceerd kopiëren'''

Met ctrl + shift + c kunt u geavanceerd kopiëren. Dit is handig als u de geselecteerde rijen wil gebruiken, bijvoorbeeld in een volgende query. Er staan dan automatisch quotes omheen en een komma tussen elk item, zoals hieronder weergegeven.

'item1',

'item2',

...

==== Exporteren naar Excel (xlsx) ====
U kunt een extensie installeren waarmee u direct Excels kunt downloaden. Dus niet eerst csv-bestanden die nog met de hand geconverteerd moeten worden. Volg de stappen in de link 'extensie installeren'.

LET OP!: Sluit DBeaver eerst af en start het op als Administrator. Bijv. door Ctrl + Shift + Rechtermuisknop op de taakbalk en dan 'Als administrator uitvoeren'.

==== CSV-bestanden als database benaderen ====
Klik op het plusje met New Database Connection, zoek naar 'csv'.

Onder Path kiest u een map waarin u alle .csv-bestanden neer gaat zetten. Klik op Finish.

Alle csv's die u in de map (die je hierboven aangemaakt hebt) plaatst, zijn dan beschikbaar om op te queryen.

In de Driver Properties kunt u onder separator instellen wat het scheidingsteken is.

==== Regels afsterren: ====
Regels zijn op twee manieren als tekst neer te zetten.

-- door middel van twee streepjes voor

/*

Of door middel van /* en */

<nowiki>*</nowiki>/

Als u al tekst heeft geschreven kunt u gebruiken maken van ctrl + / om automatisch streepjes voor de tekst te laten zetten. Selecteer de betreffende regels en druk op CTRL + /

==== Databasenaam in export ====
Een export doet u door in een Resultset met de Rechtermuisknop op 'Export data ...' te klikken. Als u wil dat de file-name automatisch de databasenaam, tabelnaam, en/of een timestamp bevat, kunt u dat doen door het volgende te doen.

Bij Export data ... > Output (stap 4) > File name pattern, kunt u de naam van de te exporteren file bepalen. Als u daarin gebruik maakt van onderstaande variabelen, krijgt de export automatisch de naam van de betreffende variabele.

De databasenaam: ${datasource}

De tabelnaam: ${table}

De timestamp: ${timestamp}

Een combinatie hiervan is ook mogelijk. Bijvoorbeeld ${datasource}_${table}_${timestamp}.

==== Naar hoofdletters/kleine letters van selectie ====
Ctrl + Shift + X -> selectie naar hoofdletters

Ctrl + Shift + Y -> selectie naar kleine letters

== Werken met PowerBI en de Query Server ==
Mocht u met PowerBI de data op de Query Server willen gebruiken, dan dient u de volgende stappen te volgen:

* Installeer PowerBI
* Open PowerBI
* Klik op "Gegevens ophalen" en "Meer" in het lint of "Gegevens ophalen" in het startscherm.
* Kies vervolgens in het menu "Gegevens ophalen" de optie "PostgreSQL-database" en klik op "Verbinding maken".

[[Bestand:VC BI QueryServer PowerBI1.png|geen|miniatuur]]

* Voer vervolgens in het menu "PostgreSQL-database" waarden in voor "Server" en "Database".
** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.

[[Bestand:VC BI QueryServer PowerBI2.png|geen|miniatuur]]

* Voer in het volgende menu uw login en wachtwoord in.
** Uw ValueCare contactpersoon heeft u op een veilige manier voorzien van deze gegevens.
** Dit hoeft u maar 1 keer te doen voor een connectie. De volgende keer wordt uw login en wachtwoord niet meer gevraagd.
* Kies vervolgens in het menu "Navigator" de gewenste tabel uit de lijst. Kies vervolgens op "Laden" als u de hele tabel wilt downloaden of kies "Gegevens transformeren" om data te limiteren en te bewerken.
* U kunt nu aan de slag.

NB:

* Via de knop "Recente bronnen" kunt u de verbinding met de Query Server selecteren en dan snel een extra tabel met data toevoegen

== Werken met Excel en de Query Server ==

Mocht u met Excel de data op de Query Server willen gebruiken, dan dient u de onderstaande stappen te volgen. Het is noodzakelijk dat u een programma installeert op uw computer, namelijk een ODBC driver. Als u geen programma's op uw eigen computer kunt installeren, hebt u hulp nodig van uw ICT service desk.

Instructies:

* Download Postgres ODBC driver via <nowiki>https://www.postgresql.org/ftp/odbc/versions/msi/</nowiki>
** Neem de laatste versie! Neem de 64 bit versie!
* Installeer de ODBC driver op uw computer
** Start het programma "psqlodbc_x64" in de msi file.
** Klik op Next, vink aan "I accept the terms in the License Agreement", klik Next, klik Next, klik Install
** Klik Ja op vraag of programma wijzigingen aan laptop/PC mag aanbrengen
** Klik Finish
* Configureer ODBC koppeling op uw computer
** Zoek via de Windows knop de app "ODBC-gegevensbronbeheer (64-bits)"
** Open deze app
** Klik op Toevoegen
** Klik op "PostgreSQL Unicode(x64)" en op "Voltooien"
** Vul de database gegevens en login gegevens in
*** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.
*** Geef bij Data Source een begrijpelijke naam aan (laat de default naam niet staan). Bijvoorbeeld: Klant Qserver X
*** Klik op Test om te checken of de connectie werkt.

[[Bestand:VC BI QueryServer Excel1.png|geen|miniatuur]]

* Open Excel
* Zet de Excel connectie op
** Klik op Gegevens, Gegevens ophalen, Uit andere bronnen, Uit ODBC
** Klik in het scherm op de Data Source zoals net aangemaakt (bijvoorbeeld Bijvoorbeeld: Klant Qserver X) en klik op OK
** Vul in het volgende scherm wederom de gebruikersgegevens in en klik op OK
** Kies vervolgens in het scherm Navigator de gewenste tabellen en laadt deze in Excel
* U kunt nu aan de slag.

{{VALUECARE}}

Klant Query Server

2023-05-25T08:02:51Z

Cbruin: /* Van een dashboard of tegel naar de juiste tabel op de Query Server */

== Inleiding ==
Op verzoek stelt ValueCare aan de instellingen een Query Server beschikbaar met daarop een Postgres database met alle source data en BI resultaat data. De door de instelling aangemerkte gebruikers kunnen een connectie maken met de database en er queries op los laten. Ook is het mogelijk om een tool, zoals bijvoorbeeld PowerBI, te connecten tot de database.

== Implementatie ==
Het volgende is nodig vanuit de instelling:

* Een server en het IP adres van de server, tenzij de server wordt gehost door ValueCare.
* Een VPN verbinding van het klantnetwerk naar het ValueCare netwerk.
* Een lijst met gebruikers.

De rest van de implementatie wordt door ValueCare verzorgd.

== Hoe werkt het? ==
In het kort wordt het volgende dagelijks gedaan:

* Er wordt een kopie van de source data en BI resultaat data op de ValueCare Productie server gemaakt.
* Op de Query Server zijn er 2 database schema's: vcs en public. Het vcs schema wordt leeg gemaakt.
* De kopie van de source data en BI resultaat data wordt in het vcs schema geplaatst.
De gebruiker kan vervolgens data in het vcs schema inzien, maar niet wijzigen. In het public schema kan de gebruiker tabellen aanmaken, wijzigen en verwijderen.

== Toelichting data ==

=== De data ===
Er zijn twee schema's beschikbaar op de Query Server: public en vcs. In het vcs schema worden alle bi- en bron-data neergezet, zodat de ValueCare data beschikbaar is. Deze data worden elke dag ververst, zodat het elke dag overeen komt met de data op de Productie-omgeving. Als u op schema vcs een eigen tabel zou aanmaken, wordt deze verwijderd tijdens de verversing. Om met eigen tabellen te werken, is het public-schema beschikbaar. De tabellen die hierop staan, blijven beschikbaar op de Query Server. Hoe u data overzet van schema vcs naar schema public leest u hieronder.

==='''Tabellen kopiëren van schema VCS naar schema Public'''===
Er zijn verschillende manieren om een tabel van schema vcs over te zetten naar schema public. Hieronder is de query uitgeschreven voor één van die manieren. Als je dit vaak wil gebruiken, is het handig om hier een template van te maken (specifiek voor DBeaver). Hier vind je meer over in “Templates”.

CREATE TABLE public.table_name (LIKE vcs.table_name INCLUDING ALL);

INSERT INTO public.table_name

SELECT *

FROM vcs.table_name;

=== '''Van een dashboard of tegel naar de juiste tabel op de Query Server''' ===
Om te begrijpen welke tabellen op de Query Server gebruikt zijn om de tegels en dashboards in het portaal op te bouwen, is de tabel bi_queryserver_tegels_en_dashboards beschikbaar op de Query Server. Hierin kan je zien welke tabellen worden gebruikt in een tegel en/of dashboard. In onderstaand voorbeeld, ziet u dat voor de tegel ‘Waarde verblijfsdagen per maand’, die te vinden is in dataset ‘Verblijf ZPM’, de onderliggende tabel ‘bi_zis_verblijf_zpm’ is. Tabel bi_zis_verblijf_zpm is dan te vinden op de Query Server.
{| class="wikitable"
|'''tegel_naam'''
|'''dataset_naam'''
|'''tabel_naam'''
|'''tegel_beschrijving'''
|-
|Waarde verblijfsdagen per maand
|Verblijf ZPM
|bi_zis_verblijf_zpm
|Deze rapportage toont waarde van de verblijfsdagen voor …
|}
Daarnaast kunt u vanuit het portaal ook het filter 'Paginanaam' gebruiken. Als je deze toevoegt vanuit [+ nieuw filter] onderaan de linker balk met filters, dan ziet u ook welke tabellen er gebruikt worden voor het opstellen van de tegel en/of dashboard. Zoekt u bijvoorbeeld van een dashboard de bijbehorende dataset, dan kunt u ook het filter 'Paginanaam' gebruiken, om deze vervolgens als dataset_naam op de Query Server terug te vinden.

De logica achter de benaming van tabellen op de Query Server is hieronder weergegeven.
{| class="wikitable"
|'''Voorvoegsel'''
|'''Betekenis'''
|'''Uitleg'''
|-
|src_
|Source (bron)
|Alle tabellen die wij direct vanuit een bron ophalen krijgen het voorvoegsel src_. Dit zijn dus tabellen vanuit bronnen, zoals XMCare, MijnQuarant, Beaufort, QuestManager, etc. Ook bestanden die we ophalen vanaf een SFTP server of andere bronnen, krijgen dit voorvoegsel.
|-
|bi_
|Business intelligence
|Alle tabellen die gebruikt worden voor het samenstellen van dashboards en tegels hebben het voorvoegsel bi.
|}

== Connectie opzetten ==

# Vraag om de hostname en de databasename bij ValueCare
#* Het kan ook zijn dat de Query Server lokaal gehost wordt, in dat geval is de hostname doorgaans te achterhalen bij uw ICT-afdeling
# Vraag om de username en password bij uw ValueCare contactpersoon.
# Maak de connectie vanuit de tool die u gebruikt, door de hostname en de databasename in te vullen en in te loggen met uw username en password.
#* De Query Server beschikt over een postgres database, dus het poortnummer is de standaard postgres poort (5432)

== Werken met DBeaver en de Query Server ==
Er zijn tal van goede programma's die u kunt gebruiken om te querieën op de Query Server. Mits u gebruik maakt of wilt maken van DBeaver om op de Query Server te querieën, dan vindt u hieronder een aantal instructies en een aantal tips & tricks die het gebruik van DBeaver nog fijner maken.

=== '''Installeren DBeaver''' ===

* Via <nowiki>https://dbeaver.io/download/</nowiki> kunt u DBeaver downloaden.
* Met de standaard instellingen van de installatie kunt u prima op de Query Server komen, maar voelt u zich vooral vrij om de instellingen naar wens aan te passen.

=== '''Connectie opzetten met de database''' ===

# Klik linksboven op het stekkertje om een nieuwe connectie op te zetten. (Dit kan eventueel ook via het menu: Database > New Database Connection
# Selecteer PostgreSQL
# Vul de juiste naam voor de Host in (het poortnummer staat default al goed: 5432)
# Vul de juiste naam voor de Database in
# Vul de juiste Username in (deze heb je ontvangen vanuit ValueCare. Heb je deze nog niet, dan kan je die aanvragen via jouw contactpersoon)
# Ga naar het kopje “Driver properties” en zet hier het veld tcpKeepAlive op ‘True’
# Klik op Finish
# Nu verschijnt er links in de “Database Navigator” een connectie met de naam van de database. Dubbelklik hierop om de connectie te openen
# Vul je wachtwoord in en voilà!

=== '''Tips & Tricks om snel met DBeaver te werken''' ===
'''Overzicht van de functietoetsen'''

Uitvoeren van een query: ctrl + enter

Openen van new script: F3

Geavanceerd kopiëren: ctrl + shift + c (uitgebreidere uitleg onder “Geavanceerd kopiëren”)

'''Templates'''

Templates zijn erg handig in DBeaver. Hiermee kunt u veelgebruikte queries opslaan en hoeft u die niet volledig te typen, als u ze de volgende keer wil gebruiken. Bijvoorbeeld: In plaats van ‘SELECT * FROM table_name;’, type je enkel ‘saf’ en druk je op tab.

Om een template aan te maken gaat u naar: Window > Preferences > SQL Editor > Templates > New.

''Name'': de combinatie aan woorden of letters die u wil typen in plaats van de query

''Pattern'': de query die moet verschijnen als u de Name typt en op Tab drukt.

''Insert variable'': Hiermee kunt u een bepaalde variabele aanroepen nadat u het template gebruikt. Bijvoorbeeld, SELECT * FROM '''${table}'''; zorgt ervoor dat u makkelijk een bestaande tabel kunt selecteren als u het template gebruikt.

'''Geavanceerd kopiëren'''

Met ctrl + shift + c kunt u geavanceerd kopiëren. Dit is handig als u de geselecteerde rijen wil gebruiken, bijvoorbeeld in een volgende query. Er staan dan automatisch quotes omheen en een komma tussen elk item, zoals hieronder weergegeven.

'item1',

'item2',

...

==== Exporteren naar Excel (xlsx) ====
U kunt een extensie installeren waarmee u direct Excels kunt downloaden. Dus niet eerst csv-bestanden die nog met de hand geconverteerd moeten worden. Volg de stappen in de link 'extensie installeren'.

LET OP!: Sluit DBeaver eerst af en start het op als Administrator. Bijv. door Ctrl + Shift + Rechtermuisknop op de taakbalk en dan 'Als administrator uitvoeren'.

==== CSV-bestanden als database benaderen ====
Klik op het plusje met New Database Connection, zoek naar 'csv'.

Onder Path kiest u een map waarin u alle .csv-bestanden neer gaat zetten. Klik op Finish.

Alle csv's die u in de map (die je hierboven aangemaakt hebt) plaatst, zijn dan beschikbaar om op te queryen.

In de Driver Properties kunt u onder separator instellen wat het scheidingsteken is.

==== Regels afsterren: ====
Regels zijn op twee manieren als tekst neer te zetten.

-- door middel van twee streepjes voor

/*

Of door middel van /* en */

<nowiki>*</nowiki>/

Als u al tekst heeft geschreven kunt u gebruiken maken van ctrl + / om automatisch streepjes voor de tekst te laten zetten. Selecteer de betreffende regels en druk op CTRL + /

==== Databasenaam in export ====
Een export doet u door in een Resultset met de Rechtermuisknop op 'Export data ...' te klikken. Als u wil dat de file-name automatisch de databasenaam, tabelnaam, en/of een timestamp bevat, kunt u dat doen door het volgende te doen.

Bij Export data ... > Output (stap 4) > File name pattern, kunt u de naam van de te exporteren file bepalen. Als u daarin gebruik maakt van onderstaande variabelen, krijgt de export automatisch de naam van de betreffende variabele.

De databasenaam: ${datasource}

De tabelnaam: ${table}

De timestamp: ${timestamp}

Een combinatie hiervan is ook mogelijk. Bijvoorbeeld ${datasource}_${table}_${timestamp}.

==== Naar hoofdletters/kleine letters van selectie ====
Ctrl + Shift + X -> selectie naar hoofdletters

Ctrl + Shift + Y -> selectie naar kleine letters

== Werken met PowerBI en de Query Server ==
Mocht u met PowerBI de data op de Query Server willen gebruiken, dan dient u de volgende stappen te volgen:

* Installeer PowerBI
* Open PowerBI
* Klik op "Gegevens ophalen" en "Meer" in het lint of "Gegevens ophalen" in het startscherm.
* Kies vervolgens in het menu "Gegevens ophalen" de optie "PostgreSQL-database" en klik op "Verbinding maken".

[[Bestand:VC BI QueryServer PowerBI1.png|geen|miniatuur]]

* Voer vervolgens in het menu "PostgreSQL-database" waarden in voor "Server" en "Database".
** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.

[[Bestand:VC BI QueryServer PowerBI2.png|geen|miniatuur]]

* Voer in het volgende menu uw login en wachtwoord in.
** Uw ValueCare contactpersoon heeft u op een veilige manier voorzien van deze gegevens.
** Dit hoeft u maar 1 keer te doen voor een connectie. De volgende keer wordt uw login en wachtwoord niet meer gevraagd.
* Kies vervolgens in het menu "Navigator" de gewenste tabel uit de lijst. Kies vervolgens op "Laden" als u de hele tabel wilt downloaden of kies "Gegevens transformeren" om data te limiteren en te bewerken.
* U kunt nu aan de slag.

NB:

* Via de knop "Recente bronnen" kunt u de verbinding met de Query Server selecteren en dan snel een extra tabel met data toevoegen

== Werken met Excel en de Query Server ==

Mocht u met Excel de data op de Query Server willen gebruiken, dan dient u de onderstaande stappen te volgen. Het is noodzakelijk dat u een programma installeert op uw computer, namelijk een ODBC driver. Als u geen programma's op uw eigen computer kunt installeren, hebt u hulp nodig van uw ICT service desk.

Instructies:

* Download Postgres ODBC driver via <nowiki>https://www.postgresql.org/ftp/odbc/versions/msi/</nowiki>
** Neem de laatste versie! Neem de 64 bit versie!
* Installeer de ODBC driver op uw computer
** Start het programma "psqlodbc_x64" in de msi file.
** Klik op Next, vink aan "I accept the terms in the License Agreement", klik Next, klik Next, klik Install
** Klik Ja op vraag of programma wijzigingen aan laptop/PC mag aanbrengen
** Klik Finish
* Configureer ODBC koppeling op uw computer
** Zoek via de Windows knop de app "ODBC-gegevensbronbeheer (64-bits)"
** Open deze app
** Klik op Toevoegen
** Klik op "PostgreSQL Unicode(x64)" en op "Voltooien"
** Vul de database gegevens en login gegevens in
*** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.
*** Geef bij Data Source een begrijpelijke naam aan (laat de default naam niet staan). Bijvoorbeeld: Klant Qserver X
*** Klik op Test om te checken of de connectie werkt.

[[Bestand:VC BI QueryServer Excel1.png|geen|miniatuur]]

* Open Excel
* Zet de Excel connectie op
** Klik op Gegevens, Gegevens ophalen, Uit andere bronnen, Uit ODBC
** Klik in het scherm op de Data Source zoals net aangemaakt (bijvoorbeeld Bijvoorbeeld: Klant Qserver X) en klik op OK
** Vul in het volgende scherm wederom de gebruikersgegevens in en klik op OK
** Kies vervolgens in het scherm Navigator de gewenste tabellen en laadt deze in Excel
* U kunt nu aan de slag.

{{VALUECARE}}

Jeugdmonitor

2023-05-03T14:44:16Z

Cbruin: Uitnutting en Omzet & kosten zijn toegevoegd.

De eerste versie van de Jeugdmonitor was beschikbaar als Excel-bestand. Vanaf de tweede versie is de jeugdmonitor niet meer beschikbaar als Excel-bestand, maar als tegels en dashboards die te vinden zijn in het ValueCare portaal.

== '''Doelgroep''' ==
De jeugdmonitor is gemaakt om de financiële resultaten binnen de Jeugdzorg per jaar per gemeente te monitoren. Kinderen en jongeren onder de 18 jaar die hulp, zorg of ondersteuning nodig hebben vallen in de meeste gevallen onder de Jeugdwet. Deze worden gemonitord in de Jeugdwet.

=== Verlengde jeugdhulp ===
Normaal gesproken komen cliënten die jonger zijn dan 18 jaar in aanmerking voor hulp binnen de Jeugdwet. Echter, cliënten van 18 tot 23 jaar kunnen in aanmerking komen voor verlengde jeugdhulp, als er sprake is van de volgende voorwaarden:

# Er is geen financiering beschikbaar (bijv. vanuit ZvW, Wlz, WMO, ZvW) nadat de cliënt 18 is geworden.
# Naast (1) wordt er voldaan minstens één van volgende criteria:
#* Cliënt heeft jeugdhulp gehad vóór het 18e jaar en de gemeente vindt verdere jeugdhulp noodzakelijk
#* Cliënt heeft jeugdhulp gehad vóór het 18e jaar en binnen een half jaar na het 18 jaar komt cliënt opnieuw in aanmerking voor jeugdhulp
#* Cliënt heeft pleegzorg en voortzetting van de pleegzorg is nodig

Een maatregel is uitgesproken met betrekking op een strafbaar feit dat is begaan tussen het 18e en 23e jaar.

== Financiering vanuit gemeenten ==
In de GGZ wordt de jeugdzorg sinds 1 januari 2018 gefinancierd vanuit gemeenten. Er is onder andere gekozen voor gemeentelijke financiering, zodat de zorg lokaal georganiseerd kan worden, dichter bij het gezin. Met de introductie van de Jeugdwet is de DBC-systematiek die vóór 2018 van toepassing was op de Jeugdzorg, niet meer in gebruik. Vóór 2018 werd de jeugdzorg geregistreerd in DBC's en viel de bekostiging onder de ZvW (Zorgverzekeringswet), waarvan een groot deel binnen de AWBZ (Algemene Wet Bijzondere Ziektekosten) viel.

Om de financiering en administratie binnen de Jeugdwet goed te organiseren is er een landelijke berichtenstandaard opgezet. Dit betreft met name een standaard voor het berichtenverkeer tussen gemeenten en zorgaanbieders. Hoe deze berichtenstandaard werkt, lees je hieronder. Allereerst vind je een korte uitleg van de berichten met betrekking tot het starten en beëindigen van de zorg. Dat zijn de berichten die actief gecontroleerd binnen ValueCare. Daarnaast vind je een overzicht van alle berichten.

=== Verzoek om toewijzing (JW315) ===
De zorgaanbieder verzoekt de gemeente om een toewijzing te sturen voor het leveren van jeugdhulp waarvoor reeds een titel tot levering bestaat. Het Verzoek om toewijzing-bericht kan alleen gebruikt worden voor situaties waarbij het recht op jeugdhulp al vaststaat en is daarmee één van de rechtmatigheidsberichten. Met het Verzoek om toewijzing geeft de aanbieder aan dat de zorg is gestart. De gemeente stuurt altijd binnen drie werkdagen een retourbericht om aan te geven dat het Verzoek om toewijzing ontvangen is. De gemeente die het Verzoek om toewijzing ontvangt is verplicht om te toetsen of, op basis van het woonplaatsbeginsel, de client onder haar verantwoordelijkheid valt. Wanneer dat zo is, stuurt de gemeente de aanbieder een officiële toewijzing voor de te leveren jeugdhulp.

=== Toewijzing/beschikking (JW301) ===
Met de toewijzing geeft de gemeente een aanbieder opdracht tot levering van jeugdhulp voor een specifieke client. Het geeft de aanbieder het recht om de zorg te gaan leveren en is daarmee één van de rechtmatigheidsberichten. In het bericht wordt het toegewezen product omschreven. Dit toegewezen product kan aspecifiek zijn (dat wil zeggen dat alleen een productcategorie wordt toegewezen) of specifiek (dat wil zeggen dat binnen de productcategorie ook een specifieke productcode wordt toegewezen). In de toewijzing wordt aangegeven welke specifieke aanbieder welk product moet leveren, met een bepaalde omvang en voor een bepaalde periode. Dit kan een periode zonder einddatum zijn.

=== Starten Jeugdhulp (JW305) ===
Met het Startbericht geeft de aanbieder aan de gemeente door wanneer de levering gestart is. Het bericht is bedoeld om de gemeente inzicht te geven in het daadwerkelijk plaatsvinden van de levering van zorg en ondersteuning. Er kunnen geen rechten ontleend worden aan dit bericht, dat wil bijvoorbeeld zeggen dat er geen afhankelijkheid met de betaling (declaratie of facturatie) mag bestaan. Het Startbericht is daarmee één van de regieberichten.

=== Beeindigen jeugdhulp (JW307) ===
Met het Stopbericht geeft de aanbieder aan de gemeente door wanneer de levering beëindigd is en wat de reden is van de beëindiging. Het bericht is bedoeld om de gemeente inzicht te geven in het daadwerkelijk plaatsvinden van de levering van zorg en ondersteuning. Er kunnen geen rechten ontleend worden aan dit bericht, dat wil bijvoorbeeld zeggen dat er geen afhankelijkheid met de betaling (facturatie) mag bestaan. Het Stopbericht is daarmee één van de regieberichten. Indien de start van de levering is doorgegeven met een Startbericht, wordt de beëindiging van de levering altijd doorgegeven met een Stopbericht. De beëindiging kan plaatsvinden op initiatief van de gemeente: de aanbieder ontvangt een intrekkingsbericht van de gemeente. Met het Stopbericht geeft de aanbieder door wanneer de levering definitief gestopt is.

=== Verzoek om wijziging (JW317) ===
Als de zorgaanbieder vaststelt dat de geleverde zorg tijdens de levering van de zorg aangepast moet worden, kan er een verzoek om wijziging (VOW) worden aangevraagd bij de gemeente.

=== Antwoordbericht (JW319) ===
Als een gemeente nader onderzoek moet doen met betrekking tot een VOW of VOT, of als een verzoek wordt afgewezen, wordt het Jw319-antwoordbericht gebruikt.

== Registratie ==

=== Productcategorie ===
Voor de Jeugdwet-producten is landelijk een aantal productcategorieën vastgesteld, die verplicht gebruikt moeten worden in de berichten. Deze categorieën zijn over en weer vertaalbaar in de indeling die de Vereniging van Nederlandse Gemeenten (VNG) voorstelt voor de financiële verantwoording van Jeugdwet-voorzieningen. Zo kunnen de productcategorieën een plek krijgen in de landelijke financiële verantwoording die gemeenten moeten afleggen aan het ministerie van Binnenlandse Zaken. Ook uit de afstemming met CAK en SVB blijkt dat hun productindelingen goed passen.

=== Productcode ===
Onder de productcategorieën zijn productcodes gedefinieerd, als verbijzondering binnen een productcategorie. Deze codes, die specifieker beschrijven om welk product of welke dienst het gaat, zijn opgenomen in de standaardproductcodelijst Jeugdwet (JZ21). Gemeenten en aanbieders spreken onderling af welke van deze productcodes zij gebruiken, zodat de codes passen bij de gekozen Jeugdwet-uitvoering.

Zorginstituut Nederland adviseert gemeenten en aanbieders om zoveel mogelijk gebruik te maken van de codes op de standaardproductcodelijst, omdat dit bijdraagt aan minder administratieve variëteit. Gemeenten mogen besluiten om de standaardproductcodelijst niet te gebruiken. Zij mogen dan zelf productcodes definiëren, binnen de productcategorieën die zijn vastgesteld. Samen met de aanbieder leggen ze dan vast welke codes gebruikt mogen worden bij welke productcategorie. In dat geval adviseert het Zorginstituut om codes te kiezen die ''niet'' voorkomen op de standaardproductcodelijst.

=== Eenheid ===
De eenheid zegt iets over hoe de afrekening verloopt. De volgende eenheden zijn vanuit de informatiestandaard iJw 3.0 vastgesteld:

* 01 - Facturatie in geregistreerde minuten
* 04 - Facturatie in geregistreerde uren
* 14 - Facturatie in geregistreerde verblijfsdagen
* 16 - Facturatie in geregistreerde dagdelen
* 82 - Facturatie stuks output
* 83 - Facturatie volgens vastgesteld tarief (€)
* 84 – Facturatie stuks inspanningsgericht

Sinds 1 januari 2021 wordt de informatiestandaard iJw 3.0 gebruikt binnen de Jeugdwet. Vóór 2021 werd eenheid ’82 – Facturatie volgens arrangement’ gebruikt. Dit is opgesplitst in ‘82 – Facturatie stuks output’ en ’84 – stuks inspanningsgericht’. Outputgericht houdt in dat er afspraken zijn tussen gemeente en zorgaanbieder over de te behalen output. Daarbij hoeft niet vastgelegd te zijn hoe deze output wordt behaald. Inspanningsgericht houdt in dat er afspraken zijn tussen gemeente en zorgaanbieder wat betreft de levering van een product of dienst in een afgesproken tijdseenheid.

=== Frequentie ===
De frequentie geeft aan hoe frequent er gefactureerd zal gaan worden. De volgende frequenties zijn vastgesteld:

# - Per dag
# - Per week
# - Per 4 weken
# - Per maand
# - Per jaar
# - Totaal binnen geldigheidsduur beschikking

=== Volume ===
Het volume geeft het vastgestelde maximum aan en is afhankelijk van de eenheid. Met andere woorden, een volume van 10.000 betekent bij eenheid 01, 10.000 minuten, maar betekent bij eenheid 83, 10.000 euro.

=== Status ===
Er zijn 4 verschillende statussen van financiering in de jeugdmonitor, namelijk:

# ''Gefactureerd - V''an alle producten alle factuurmomenten.
# ''Onderhanden werk (OHW)-'' Van alle producten de waarde die nog niet gefactureerd is. De OHW waarde van een product wordt per eenheid anders berekend:
#* '''01:''' Som van de tijd van alle contacten na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''04:''' Som van de tijd van alle contacten na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''14:''' Som van alle verblijfsdagen na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''16:''' Som van alle dagdelen na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''82:''' Som van alle mijlpalen die wel behaald zijn maar nog niet gefactureerd zijn vermenigvuldigd met het afgesproken tarief.
#* '''83:''' Het afgesproken volume maal de restende looptijd (afhankelijk van frequentie) na laatste datum uit factuur.
#* '''84:''' Som van de productie
# ''Extra waarde reeds geopend -'' Van alle openstaande producten de extra verwachte waarde. Dit betreft met name toewijzingen met een einddatum in de toekomst.
# ''Nog te openen -'' De waarde van alle producten die naar verwachting nog geopend gaan worden (dus nog niet bestaan). Dit is een prognose op basis van het afgelopen jaar.

'''De prognose wordt als volgt berekend:'''

Per betalende instantie wordt de gemiddelde duur van een jeugd-product vermenigvuldigd met de gemiddelde productie op een jeugd-product. Deze wordt vermenigvuldigd met het aantal nog te verwachten te openen producten. Deze verwachting is gebaseerd op het aantal reeds geopende producten en het aantal nog resterende dagen in een jaar. Zodoende kan op elk moment van het schadelastjaar een schatting worden gemaakt van de nog te openen productie. Naarmate het jaar vordert, komt er meer data beschikbaar van reeds geopende producten en zal de prognose steeds nauwkeuriger worden.

== Uitnutting ==
Uitnutting verwijst naar de verhouding tussen de hoeveelheid geleverde zorg en de hoeveelheid toegewezen zorg. Een uitnutting van 100%, betekent dat het volledige toegewezen budget is verbruikt. Als de uitnutting boven de 100% komt, is er een financieel risico voor de zorg die geleverd wordt voor die toewijzing.

=== P x Q ===
Voor PxQ toewijzingen (eenheden 01, 04, 14, 16) wordt er toegewezen in minuten, uren, verblijfsdagen, of in dagdelen. Hiervoor wordt de berekening van de uitnutting berekend op basis van de geschreven tijd.
{| class="wikitable"
|Eenheid
|Uitnutting
|Te besteden uren
|-
|01 - Per minuut
|Aantal geschreven minuten / toegewezen minuten
|Toegewezen minuten - aantal geschreven minuten
|-
|04 - Per uur
|Aantal geschreven uren / toegewezen uren
|Toegewezen uren - aantal geschreven uren
|-
|14 - Per verblijfsdag
|Aantal geschreven verblijfsdagen / toegewezen verblijfsdagen
|Toegewezen verblijfsdagen - aantal geschreven verblijfsdagen
|-
|16 - Per dagdeel
|Aantal geschreven dagdelen / toegewezen dagdelen
|Toegewezen dagdelen - aantal geschreven dagdelen
|}

=== Arrangementen ===
Voor product-eenheden 82, 83, en 84 wordt er toegewezen in een bedrag. Daardoor gaat de berekening voor de uitnutting en de te besteden uren net wat anders dan bij P x Q producten. Om van een toegewezen bedrag tot het aantal toegewezen uren te komen, werkt de Jeugdmonitor met een steltarief. Dit tarief is in te stellen in de beheertabel "Tarieven per soort GGZ zorg".
{| class="wikitable"
|Eenheid
|Uitnutting
|Te besteden uren
|Toegewezen uren
|-
|82 - Stuks (output)
83 - Euros

84 - Stuks (inspanning)
|Geschreven tijd * steltarief / toegewezen bedrag
|( Toegewezen bedrag / steltarief ) - geschreven tijd
|Toegewezen bedrag / steltarief
|}

== Omzet & kosten ==
Om een compleet overzicht te hebben van alle omzet en kosten vanuit verschillende perspectieven is er een overzicht beschikbaar in de Jeugdmonitor. Hierin worden verschillende begrippen gebruikt voor de kosten en opbrengsten. Hieronder meer uitleg over deze begrippen:
{| class="wikitable"
|Begrip
|Defintie
|Berekening
|-
|Waarde productie
|De waarde van de geleverde productie. Dit wordt berekend aan de hand van het steltarief
wat instelbaar is per soort GGZ zorg en per beroep.
|Steltarief obv beroep * geschreven tijd
|-
|Kosten totaal
|De totale kosten die zijn gemaakt. De kostprijs per beroep is instelbaar in beheertabel in
beheertabel Kostprijs per beroep
|Kostprijs obv beroep * geschreven tijd per beroep
|-
|Bedrag gefactureerd
|Het bedrag dat is gefactureerd
|Zie Registratie - Status - 1
|-
|Bedrag OHW
|Het onderhanden werk. Ook het bedrag dat nog niet is gefactureerd,
maar waarvoor wel declarabele zorg geleverd is
|Zie Registratie - Status - 2
|-
|Bedrag totaal
|De totale opbrengsten
|Bedrag gefactureerd + Bedrag OHW
|}
{{VALUECARE}}

Jeugdmonitor

2023-02-15T15:50:03Z

Cbruin: /* Status */

Jeugdmonitor

2023-02-15T11:12:39Z

Cbruin: /* Verlengde jeugdhulp */

De eerste versie van de Jeugdmonitor was beschikbaar als Excel-bestand. Vanaf de tweede versie is de jeugdmonitor niet meer beschikbaar als Excel-bestand, maar als tegels en dashboards die te vinden zijn in het ValueCare portaal.

== '''Doelgroep''' ==
De jeugdmonitor is gemaakt om de financiële resultaten binnen de Jeugdzorg per jaar per gemeente te monitoren. Kinderen en jongeren onder de 18 jaar die hulp, zorg of ondersteuning nodig hebben vallen in de meeste gevallen onder de Jeugdwet. Deze worden gemonitord in de Jeugdwet.

=== Verlengde jeugdhulp ===
Normaal gesproken komen cliënten die jonger zijn dan 18 jaar in aanmerking voor hulp binnen de Jeugdwet. Echter, cliënten van 18 tot 23 jaar kunnen in aanmerking komen voor verlengde jeugdhulp, als er sprake is van de volgende voorwaarden:

# Er is geen financiering beschikbaar (bijv. vanuit ZvW, Wlz, WMO, ZvW) nadat de cliënt 18 is geworden.
# Naast (1) wordt er voldaan minstens één van volgende criteria:
#* Cliënt heeft jeugdhulp gehad vóór het 18e jaar en de gemeente vindt verdere jeugdhulp noodzakelijk
#* Cliënt heeft jeugdhulp gehad vóór het 18e jaar en binnen een half jaar na het 18 jaar komt cliënt opnieuw in aanmerking voor jeugdhulp
#* Cliënt heeft pleegzorg en voortzetting van de pleegzorg is nodig

Een maatregel is uitgesproken met betrekking op een strafbaar feit dat is begaan tussen het 18e en 23e jaar.

== Financiering vanuit gemeenten ==
In de GGZ wordt de jeugdzorg sinds 1 januari 2018 gefinancierd vanuit gemeenten. Er is onder andere gekozen voor gemeentelijke financiering, zodat de zorg lokaal georganiseerd kan worden, dichter bij het gezin. Met de introductie van de Jeugdwet is de DBC-systematiek die vóór 2018 van toepassing was op de Jeugdzorg, niet meer in gebruik. Vóór 2018 werd de jeugdzorg geregistreerd in DBC's en viel de bekostiging onder de ZvW (Zorgverzekeringswet), waarvan een groot deel binnen de AWBZ (Algemene Wet Bijzondere Ziektekosten) viel.

Om de financiering en administratie binnen de Jeugdwet goed te organiseren is er een landelijke berichtenstandaard opgezet. Dit betreft met name een standaard voor het berichtenverkeer tussen gemeenten en zorgaanbieders. Hoe deze berichtenstandaard werkt, lees je hieronder. Allereerst vind je een korte uitleg van de berichten met betrekking tot het starten en beëindigen van de zorg. Dat zijn de berichten die actief gecontroleerd binnen ValueCare. Daarnaast vind je een overzicht van alle berichten.

=== Verzoek om toewijzing (JW315) ===
De zorgaanbieder verzoekt de gemeente om een toewijzing te sturen voor het leveren van jeugdhulp waarvoor reeds een titel tot levering bestaat. Het Verzoek om toewijzing-bericht kan alleen gebruikt worden voor situaties waarbij het recht op jeugdhulp al vaststaat en is daarmee één van de rechtmatigheidsberichten. Met het Verzoek om toewijzing geeft de aanbieder aan dat de zorg is gestart. De gemeente stuurt altijd binnen drie werkdagen een retourbericht om aan te geven dat het Verzoek om toewijzing ontvangen is. De gemeente die het Verzoek om toewijzing ontvangt is verplicht om te toetsen of, op basis van het woonplaatsbeginsel, de client onder haar verantwoordelijkheid valt. Wanneer dat zo is, stuurt de gemeente de aanbieder een officiële toewijzing voor de te leveren jeugdhulp.

=== Toewijzing/beschikking (JW301) ===
Met de toewijzing geeft de gemeente een aanbieder opdracht tot levering van jeugdhulp voor een specifieke client. Het geeft de aanbieder het recht om de zorg te gaan leveren en is daarmee één van de rechtmatigheidsberichten. In het bericht wordt het toegewezen product omschreven. Dit toegewezen product kan aspecifiek zijn (dat wil zeggen dat alleen een productcategorie wordt toegewezen) of specifiek (dat wil zeggen dat binnen de productcategorie ook een specifieke productcode wordt toegewezen). In de toewijzing wordt aangegeven welke specifieke aanbieder welk product moet leveren, met een bepaalde omvang en voor een bepaalde periode. Dit kan een periode zonder einddatum zijn.

=== Starten Jeugdhulp (JW305) ===
Met het Startbericht geeft de aanbieder aan de gemeente door wanneer de levering gestart is. Het bericht is bedoeld om de gemeente inzicht te geven in het daadwerkelijk plaatsvinden van de levering van zorg en ondersteuning. Er kunnen geen rechten ontleend worden aan dit bericht, dat wil bijvoorbeeld zeggen dat er geen afhankelijkheid met de betaling (declaratie of facturatie) mag bestaan. Het Startbericht is daarmee één van de regieberichten.

=== Beeindigen jeugdhulp (JW307) ===
Met het Stopbericht geeft de aanbieder aan de gemeente door wanneer de levering beëindigd is en wat de reden is van de beëindiging. Het bericht is bedoeld om de gemeente inzicht te geven in het daadwerkelijk plaatsvinden van de levering van zorg en ondersteuning. Er kunnen geen rechten ontleend worden aan dit bericht, dat wil bijvoorbeeld zeggen dat er geen afhankelijkheid met de betaling (facturatie) mag bestaan. Het Stopbericht is daarmee één van de regieberichten. Indien de start van de levering is doorgegeven met een Startbericht, wordt de beëindiging van de levering altijd doorgegeven met een Stopbericht. De beëindiging kan plaatsvinden op initiatief van de gemeente: de aanbieder ontvangt een intrekkingsbericht van de gemeente. Met het Stopbericht geeft de aanbieder door wanneer de levering definitief gestopt is.

=== Verzoek om wijziging (JW317) ===
Als de zorgaanbieder vaststelt dat de geleverde zorg tijdens de levering van de zorg aangepast moet worden, kan er een verzoek om wijziging (VOW) worden aangevraagd bij de gemeente.

=== Antwoordbericht (JW319) ===
Als een gemeente nader onderzoek moet doen met betrekking tot een VOW of VOT, of als een verzoek wordt afgewezen, wordt het Jw319-antwoordbericht gebruikt.

== Registratie ==

=== Productcategorie ===
Voor de Jeugdwet-producten is landelijk een aantal productcategorieën vastgesteld, die verplicht gebruikt moeten worden in de berichten. Deze categorieën zijn over en weer vertaalbaar in de indeling die de Vereniging van Nederlandse Gemeenten (VNG) voorstelt voor de financiële verantwoording van Jeugdwet-voorzieningen. Zo kunnen de productcategorieën een plek krijgen in de landelijke financiële verantwoording die gemeenten moeten afleggen aan het ministerie van Binnenlandse Zaken. Ook uit de afstemming met CAK en SVB blijkt dat hun productindelingen goed passen.

=== Productcode ===
Onder de productcategorieën zijn productcodes gedefinieerd, als verbijzondering binnen een productcategorie. Deze codes, die specifieker beschrijven om welk product of welke dienst het gaat, zijn opgenomen in de standaardproductcodelijst Jeugdwet (JZ21). Gemeenten en aanbieders spreken onderling af welke van deze productcodes zij gebruiken, zodat de codes passen bij de gekozen Jeugdwet-uitvoering.

Zorginstituut Nederland adviseert gemeenten en aanbieders om zoveel mogelijk gebruik te maken van de codes op de standaardproductcodelijst, omdat dit bijdraagt aan minder administratieve variëteit. Gemeenten mogen besluiten om de standaardproductcodelijst niet te gebruiken. Zij mogen dan zelf productcodes definiëren, binnen de productcategorieën die zijn vastgesteld. Samen met de aanbieder leggen ze dan vast welke codes gebruikt mogen worden bij welke productcategorie. In dat geval adviseert het Zorginstituut om codes te kiezen die ''niet'' voorkomen op de standaardproductcodelijst.

=== Eenheid ===
De eenheid zegt iets over hoe de afrekening verloopt. De volgende eenheden zijn vanuit de informatiestandaard iJw 3.0 vastgesteld:

* 01 - Facturatie in geregistreerde minuten
* 04 - Facturatie in geregistreerde uren
* 14 - Facturatie in geregistreerde verblijfsdagen
* 16 - Facturatie in geregistreerde dagdelen
* 82 - Facturatie stuks output
* 83 - Facturatie volgens vastgesteld tarief (€)
* 84 – Facturatie stuks inspanningsgericht

Sinds 1 januari 2021 wordt de informatiestandaard iJw 3.0 gebruikt binnen de Jeugdwet. Vóór 2021 werd eenheid ’82 – Facturatie volgens arrangement’ gebruikt. Dit is opgesplitst in ‘82 – Facturatie stuks output’ en ’84 – stuks inspanningsgericht’. Outputgericht houdt in dat er afspraken zijn tussen gemeente en zorgaanbieder over de te behalen output. Daarbij hoeft niet vastgelegd te zijn hoe deze output wordt behaald. Inspanningsgericht houdt in dat er afspraken zijn tussen gemeente en zorgaanbieder wat betreft de levering van een product of dienst in een afgesproken tijdseenheid.

=== Frequentie ===
De frequentie geeft aan hoe frequent er gefactureerd zal gaan worden. De volgende frequenties zijn vastgesteld:

# - Per dag
# - Per week
# - Per 4 weken
# - Per maand
# - Per jaar
# - Totaal binnen geldigheidsduur beschikking

=== Volume ===
Het volume geeft het vastgestelde maximum aan en is afhankelijk van de eenheid. Met andere woorden, een volume van 10.000 betekent bij eenheid 01, 10.000 minuten, maar betekent bij eenheid 83, 10.000 euro.

=== Status ===
Er zijn 4 verschillende statussen van financiering in de jeugdmonitor, namelijk:

# ''Gefactureerd - V''an alle producten alle factuurmomenten.
# ''Onderhanden werk (OHW)-'' Van alle producten de waarde die nog niet gefactureerd is. De OHW waarde van een product wordt per eenheid anders berekend:
#* '''01:''' Som van de tijd van alle contacten na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''04:''' Som van de tijd van alle contacten na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''14:''' Som van alle verblijfsdagen na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''16:''' Som van alle dagdelen na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''82:''' Som van alle mijlpalen die wel behaald zijn maar nog niet gefactureerd zijn vermenigvuldigd met het afgesproken tarief.
#* '''83:''' Het afgesproken volume maal de restende looptijd (afhankelijk van frequentie) na laatste datum uit factuur.
#* '''84:''' Som van de productie
# ''Extra waarde reeds geopend -'' Van alle openstaande producten de extra verwachte waarde
# ''Nog te openen -'' De waarde van alle producten die nog geopend gaan worden (dus nog niet bestaan)

'''De prognose wordt als volgt berekend:'''

Per betalende instantie wordt de gemiddelde duur van een jeugd-product vermenigvuldigd met de gemiddelde productie op een jeugd-product. Deze wordt vermenigvuldigd met het aantal nog te verwachten te openen producten. Deze verwachting is gebaseerd op het aantal reeds geopende producten en het aantal nog resterende dagen in een jaar. Zodoende kan op elk moment van het schadelastjaar een schatting worden gemaakt van de nog te openen productie. Naarmate het jaar vordert, komt er meer data beschikbaar van reeds geopende producten en zal de prognose steeds nauwkeuriger worden.

{{VALUECARE}}

Routine Outcome Monitoring (ROM)

2022-12-23T13:41:56Z

Cbruin: /* Definities */

{{VALUECARE}}

== Executive summary ==
De Routine Outcome Monitoring (ROM) is een complex product met tal van mogelijkheden en variaties.

Om de ROM behapbaar te maken is deze executive summary gemaakt met 1 figuur waarin de werking van de ROM gevisualiseerd is.

De verdiepende informatie (bv definities en stappenplan) is ook op deze pagina te vinden, onder deze samenvatting.

Er zijn twee verschillende situaties:

# <code>GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST = 'NEE'</code>: hier mogen verschillende type vragenlijsten gecombineerd worden.
# <code>GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST = 'JA'</code>: hier mogen de verschillende type vragenlijsten niet gecombineerd worden.
Deze twee situaties zijn onder elkaar gevisualiseerd.

[[Bestand:Exe sum (1).jpg|alt=|geen|miniatuur|1549x1549px|Executive summary ROM]]

== Inleiding ==
Deze pagina dient als naslagwerk om de managementrapportages op de Routine Outcome Monitoring (ROM) te interpreteren en gebruiken.

De doelen van managementrapportage inzake ROM betreft het bieden van inzicht in:

* De (tijdige) inzet van ROM instrumenten op de juiste momenten
* De effecten van de ingezette behandeling

Op deze pagina is een overzicht van definities te vinden, gevolgd door een toelichting op de totstandkoming. De relevante toepassing van de ROM wordt als laatste uitgelicht.

== Definities ==
Hieronder staan alle relevante termen met betrekking tot de ROM gedefinieerd en waar relevant extra toegelicht.

Let op: inmiddels zijn er ook ROM metingen te monitoren voor soorten GGZ Zorg anders dan ZPM (ZVW/FM). De functionaliteiten van reeksen werkt hierbij anders. Deze informatie is inmiddels toegevoegd aan deze pagina.
{| class="wikitable"
|+
!Term
!Definitie
!Toelichting
|-
|Voor- en nametingen
|De voor- en nametingen vormen de kapstok voor het bepalen of er een geldige ROM voormetingen dan wel nametingen uitgevoerd is voor het ZPM zorgtraject. Voor andere financieringsstromen geschiedt dit voor de daarvoor leidende zorgproducten (bijvoorbeeld een jeugdproduct). Daarnaast wordt per meting de T-score bepaald, zodat het effect kan worden gemeten door de T-score van de nameting te vergelijken met de voormeting.
| Note: de organisataie-eenheid van metingen/meetmomenten wordt bepaald aan de hand van de organisatie-eenheid die bij het zorgproduct zit.
|-
|Voormeting
|Het eerste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de voormeting. Hierop is een (instelbare) marge in dagen van toepassing om als geldige voormeting te tellen.
| nvt
|-
|Nameting
|Het laatste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de nameting. Ook hierop is een (instelbare) marge in dagen van toepassing om als geldige nameting te tellen.
|De nameting van het voorgaande zorgtraject mag gezien worden als voormeting van het nieuwe traject, indien het voldoen aan de eisen:

* Marge in dagen t.o.v. eerste behandelcontact in nieuwe zorgtraject

* Vragenlijst wordt gebruikt binnen de diagnose hoofdgroep

Notes:

* Als er nog geen einddatum is bepaald voor een behandelreeks, verwachten we dat er nog behandelcontacten gaan volgen. In dit geval bepalen we wel een laatste (ofwel meest recente) behandelcontact, maar valideren we nog niet of er een geldige nameting is geweest.
* Als er een verwachte einddatum (in de toekomst) is ingevuld voor een behandelreeks, dan kijken we voor een valide nameting binnen het tijdsinterval rondom de einddatum van de behandelreeks
* Als de einddatum van een zorgtraject reeds voorbij is, dan kijken we naar het laatste (ofwel meest recente) behandelcontact
|-
|Tussenmetingen
|Voor mensen die langdurig in zorg zijn (en hetzelfde zorgtraject hebben) zijn regelmatigere tussentijdse metingen van ROM is wenselijk. Het gewenste tijdsinterval verschilt per instelling, daarom is een tijdsinterval in te stellen. Voor informatie over het instelbare tijdsinterval, zie ''Tijdsinterval''.
|
|-
|Valide meting
|Een valide meting is een meting die:

* is aangemerkt als ROM
* volledig is ingevuld
* Als de diagnosegroep van het zorgtraject gevuld is, wordt met Beheer BI: Vragenlijst per diagnose bepaald of de vragenlijst in aanmerking komt voor de diagnose hoofdgroep.
** Indien de diagnosegroep leeg is, tonen we op dit moment geen meetmomenten in de dataset.
|
|-
|Tijdsinterval
|Hiermee wordt gedoeld op de gewenste tijd tussen ROM metingen. Zie ook definitie ''tussenmetingen''. De tijdsinterval is door de instelling zelf in te stellen. De tijdsinterval kan verschillen per type vragenlijst en diagnose en kan ingesteld worden via de beheertabel Beheer BI: Vragenlijst per diagnose
|<code>Stuurinformatie > Beheer BI > Beheer BI: Vragenlijst per diagnose</code>
|-
|Meetmoment
|Indien er geen meting plaatsvindt binnen het ingestelde tijdsinterval, wordt er een meetmoment aangemaakt. Dit is dus een moment waarop er een meting verwacht werd, maar deze niet is gedaan.
|Zie ook "Totstandkoming - Stappenplan - stap 3: Nummering metingen" hieronder.
|-
|Initiële meting
|Dit is de eerste valide meting binnen een reeks. De initiële meting is nodig als aanvulling op de voormeting voor de gevallen waarin de voormeting gegenereerd is (en dus geen valide meting is). In deze gevallen is de initiële meting de eerste valide meting binnen een reeks.
|Zie ook "Toepassing - (Delta) t-score" hieronder.
|-
|Behandelreeks
|Alle meetmomenten binnen een zorgtraject in combinatie met de DBC’s.
Binnen één behandelreeksmoeten de onderstaande aspecten overeenkomen. Komen deze aspecten niet overeen, dan geldt dat als een andere behandelreeks.

*'''Inschrijving (en daarmee ook cliënt)'''
** Als een inschrijving eindigt, eindigt de behandelreeks

*'''Diagnose '''
** Is er een nieuwe diagnose gesteld is, eindigt de behandelreeks
*'''Zorgtraject / DBC / Jeugd / WMO '''
** Als er een nieuw zorgtraject, jeugdproduct, of wmo product is, eindigt de behandelreeks
|Bij Jeugd en WMO worden aansluitende toewijzingen als een en dezelfde behandelreeks gezien.

Als er voor een Jeugd product of WMO product een nieuw product is aangemaakt met een zelfde product-code wordt dit ondervangen in dezelfde behandelreeks. Dit geldt enkel als het nieuwe product binnen 35 dagen na sluiting van het vorige product is aangemaakt. Hierbij moet er ook sprake zijn van dezelfde product-code, zelfde diagnose, en dezelfde inschrijving (en dus cliënt).
|-
|Reeks
|Een behandelreeks kan bestaan uit meerdere reeksen. Dit is afhankelijk van de instelling van GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST. Mits er meerdere type vragenlijsten zijn afgenomen, kan er voor elk type vragenlijst een aparte reeks worden aangemaakt. De voor- en nameting worden op het niveau van de behandelreeks gedefinieerd. Oftewel, mits er een voormeting is afgenomen binnen één van de reeksen met dezelfde behandelreeks, zal deze voormeting getoond worden voor al die reeksen.

* '''Behandelreeks'''

*'''(Optioneel) vragenlijst code'''
** Instelbaar
** Wordt enkel toegepast op behandelreeksen met één of meer geldige metingen
** Mits parameter = ‘JA’: dan geldt dat voor een andere vragenlijst-code een andere reeks wordt gemaakt (
*** T-scores worden enkel vergeleken voor vragenlijsten met hetzelfde type (bijv. enkel HoNOS vragenlijsten binnen één behandelreeks).
*** Meetmomenten worden gegenereerd voor elke type vragenlijst. Bijvoorbeeld, is er een HoNOS U verwacht dan voor elk type vragenlijst een nieuw meetmoment. (
** Mits parameter = ‘Nee’: dan geldt dat voor een andere vragenlijst-code dezelfde reeks wordt gebruikt
*** T-scores worden vergelijken onafhankelijk van het type vragenlijsten (Bijvoorbeeld, HoNOS en FARE worden afwisselend gebruikt).
*** Verwachtte meetmomenten worden enkel gegenereerd als er geen meting is geweest binnen het tijdsinterval voor alle type vragenlijsten.
|[[Bestand:ROM reeks.jpg|gecentreerd|392x392px]]
|-
|(Delta)-T score
|De T-score is een uniforme maat om de diverse vragenlijsten naar scores te transformeren en loopt van 0-100. Een succesvolle behandeling zorgt voor een lagere nametingen dan de voormeting (behalve bij het meetinstrument MANSA-16). De Delta-T score is het verschil in T score tussen twee T scores.

Zie voor interpretatie van de Delta T-score de tabel onder "Toepassing - interpretatie delta T-score"
|
|-
|Gekoppeld meetmoment
|Een gekoppeld meetmoment is een valide meting die binnen de data van een behandelreeks valt. Een ongekoppelde meetmoment kan een valide meting zijn die buiten de behandelreeks valt. Of het kan een invalide meting zijn (die binnen of buiten een eventuele behandelreeks valt).
|Zie ook de visualisatie in de executive summary bovenaan deze pagina.
|}

== Totstandkoming ==

=== Stappenplan ===
Hieronder is het stappenplan uitgewerkt dat gevolgd wordt om de berekeningen voor de ROM te maken.

Per stap is toelichting gegeven en zo nodig een extra visualisatie toegevoegd.
{| class="wikitable"
|+
!Stap
!Toelichting
!
|-
|0: Bepalen behandelingen binnen behandelreeks
|Eerst wordt bepaald naar welke behandelingen we moeten kijken om de uitersten van behandelreeks te kunnen bepalen.

* Mits het ZPM zorgtraject is aangemaakt met zorglabel N02 (''Overgang oude bekostiging met direct tijd naar Zorgprestatiemodel''), wordt de voormeting bepaald op basis van de voorafgaande DBC(s). De DBCs die worden meegenomen bij de betreffende zorgtrajecten, zijn DBCs die dezelfde (1) diagnose en (2) inschrijvingsnummer hebben als het zorgtraject.

* Voor de combinatie van de zorgtrajecten met eventuele DBCs (en losse DBCs) kijken we naar alle behandelcontacten met directe tijd.
** Voor een dergelijke behandelreeks moeten we het eerste/laatste behandelcontact bepalen.
|[[Bestand:Stap 0 ROM .png|gecentreerd|miniatuur|800x800px]]
|-
|1: Bepalen uitersten van behandelreeks
|Als er bepaald is welke behandelingen in een behandelreeks vallen, wordt er per behandelreeks bepaald:

* Het eerste behandelcontact
* Het laatste behandelcontact

LET OP

Er moet directe tijd zijn geschreven op het behandelcontact en er moet een diagnose bekend zijn voor de behandelreeks. De diagnose is nodig om te bepalen of een eventuele ROM-meting met een vragenlijst is afgenomen die geldig is bij die specifieke diagnose
|[[Bestand:ROMstap1 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|-
|2: Bepalen valide metingen
|Dan wordt er gekeken of er binnen de vastgestelde uiterste waarden van een behandelreeks, valide metingen te vinden zijn.

* Mits er een valide meting te vinden is, dan wordt de behandelreeks, en (optioneel) type vragenlijst meegenomen in de behandelreeks.

* Mits er geen valide meting te vinden is, dan is een reeks enkel bepaald op basis van de behandelreeks. In dit geval zullen er dan ook geen geldige metingen te tonen zijn in de dataset. Er worden wel twee meetmomenten gegenereerd, namelijk het verwachte voormeetmoment en het verwachte nameetmoment.
|[[Bestand:ValueCare - ROM (1).png|gecentreerd|miniatuur|800x800px]]
|-
|3:Nummering metingen
|We nummeren de opvolgende metingen binnen een behandelreeks op basis van de datum van afname.
Hierdoor kunnen we de opvolgende metingen makkelijk koppelen.

Met behulp van het tijdsinterval per type vragenlijst en diagnose, kunnen we bepalen of de opvolgende metingen plaats hebben gevonden binnen het tijdsinterval (t.o.v. de vorige meting), waarbinnen ze worden verwacht.
{| class="wikitable"
|+
!Optie
! colspan="2" |Situatie
!Gevolg
|-
|A
| colspan="2" |De volgende meting valt binnen tijdsinterval
|De volgende meting is een valide meting. Let op: alle valide metingen moeten voldoen aan de criteria gedefinieerd in stap 2.
|-
|B
| colspan="2" |De volgende meting valt buiten tijdsinterval
|Genereren meetmoment (dus geen valide meting). Dit meetmoment moet duidelijk maken aan instellingen dat er een meting verwacht wordt, maar deze meting niet (valide of volledig) is afgenomen.
|-
|C
| rowspan="2" |Geen volgende meting
|Laatste behandelcontact is in het verleden geweest
|Genereren meetmomenten tot en met het laatste behandelcontact.
|-
|D
|Laatste behandelcontact wordt in de toekomst verwacht
|Genereren meetmomenten tot en met de aanleverdatum.
|}
|[[Bestand:ROM stap 3 diagram update .jpg|alt=|gecentreerd|miniatuur|1300x1300px]]
|-
|4: Bepalen voor- en nameting
|Het bepalen van de voor- en nametingen:

De metingen die binnen een reeks het dichtste bij het eerste/laatste behandelcontact liggen worden bestempeld als voor- of nameting.

Indien er enkel een voormeting of een nameting is en niet beide, dan genereren we een meetmoment voor de missende voor- of nameting, met als datum het eerste/laatste behandelcontact.

* Mits er een valide meting heeft plaatsgevonden in de reeks, bepalen we of de meting een valide voor- of nameting is aan de hand van een marge rondom het eerste- of laatste behandelcontact. Deze marges worden bepaald aan de hand van parameters BI_MARGE_RONDOM_EERSTE_BEHANDELCONTACT_VOORMETING en BI_MARGE_RONDOM_LAATSTE_BEHANDELCONTACT_NAMETING .
* Optioneel: Instelbaar
** Mits er voor een reeks meerdere type vragenlijst worden gebruikt (bijv. zowel Honos-12 als SQ48) dan wordt er voor elk type vragenlijst een aparte reeks aangemaakt. De voor- en nametingen worden onafhankelijk van type vragenlijst bepaald. Dit wordt dus gedaan voor de overkoepelende behandelreeks.
|[[Bestand:ROMstap4 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|}

=== Gebruikte beheertabellen en parameters ===
Hieronder zijn de parameters en beheertabellen met relevante toelichting te vinden. De dataset die voor de ROM gebruikt wordt is <code>ROM meetmomenten.</code>
{| class="wikitable"
|+
!Parameters
!Toelichting
|-
|BI_MARGE_RONDOM_EERSTE_BEHANDELCONTACT_VOORMETING
|Bandbreedte in dagen rondom eerste behandelcontact zorgtraject waarbinnen een geldige voormeting afgenomen moet zijn
|-
|BI_MARGE_RONDOM_LAATSTE_BEHANDELCONTACT_NAMETING
|Bandbreedte in dagen rondom laatste behandelcontact zorgtraject waarbinnen een geldige nameting afgenomen moet zijn
|-
|GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST
|Of een reeks rekening moet houden met aparte type vragenlijsten of niet.

Mits parameter = JA, genereren we voor elke verschillende vragenlijst-code binnen een behandelreeks, een aparte reeks

Mits parameter = NEE, mogen de vragenlijsten onafhankelijk van elkaar afgenomen zijn

''NOTE: deze parameter wil ik nog hernoemen naar GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST''
|-
|''GGZBI_TIJDSINTERVAL_ROM_MEETMOMENTEN_ONAFHANKELIJK_VAN_TYPE''
|Het tijdsinterval dat gebruikt wordt voor reeksen, waarbij geen tijdsinterval bepaald is in de beheertabel 'Beheer BI: Vragenlijst per diagnose'
|}
{| class="wikitable"
|+
!Beheertabel
!Toelichting
|-
|Beheer BI: Vragenlijst per diagnose
|Per diagnosehoofdgroep kan het gebruikte ROM-instrument aangegeven worden.
In deze beheertabel kan ook het interval per type vragenlijst en diagnose ingesteld worden. (NIEUW!)
|-
|Beheer BI: Vragenlijst
|Per vragenlijst kan worden aangegeven of deze wordt gebruikt als ROM- en/of CQI-instrument
|-
|Beheer BI: Parameters
|Voor het instellen van o.a. de hierboven genoemde parameters.
|}

== Toepassing ==

In dit deel worden de toepassingen toegelicht, deze toepassingen zijn gericht op het behalen van de doelen van de managementrapportage inzake ROM zoals beschreven in de inleiding van deze pagina.

=== Beheertabel ===

Zoals hierboven al vaker aangegeven zijn er een aantal dingen instelbaar via beheertabellen. Zie ook het overzicht van beheertabellen hierboven.

De instellingen van deze beheertabellen hebben invloed om de onderstaande toepassingen en dienen dus correct ingevuld te zijn om de toepassing zo nuttig en accuraat mogelijk te laten zijn.

=== (Delta) t-score ===
De instellingen vinden het vooral belangrijk om de t-scores te weten die bij een ROM meting hoorde. Daarnaast willen ze de delta t-score weten, zodat ze kunnen zien of een cliënt verbeterd of juist verslechterd in de loop der tijd.

Voor een gegenereerd meetmoment hebben we geen t-score. Daardoor kunnen we enkel t-scores vergelijken van valide metingen. We tonen in dataset ROM meetmomenten daarom enkel delta t-scores voor valide metingen ten opzichte van valide metingen. Dit houdt ook in dat voor gegenereerde voormeetmomenten, we geen delta t-score ten opzichte van de voormeting kunnen doen. Om dit te voorkomen, hebben we de ‘initiële meting’ geïntroduceerd. Dit is de eerste valide meting binnen een reeks. We hebben op deze manier dus twee type delta t-scores in de dataset: (1) delta t-score t.o.v. de vorige valide meting, (2) delta t-score t.o.v. de initiële meting.

[[Bestand:Deltat nieuw.jpg|alt=|gecentreerd|miniatuur|800x800px]]

==== Interpretatie Delta T-score ====
Zie de tabel hieronder voor de interpretatie van de Delta T-score:
{| class="wikitable"
|+
!Code
!Classificatie
!Delta T-score
|-
|1
|Hersteld
|> 5 <code>AND</code> voormeting t > 42,5 <code>AND</code> nameting t < 42,5
|-
|2
|Verbeterd
|> 5
|-
|3
|Onveranderd
| -5 < delta t < 5
|-
|4
|Verslechterd
|< -5
|}

=== KPI's en dashboards ===
Voor de ROM biedt ValueCare verschillende dashboards in het portaal.

Deze zijn te vinden onder <code>Meer dashboards > ROM > ROM - Delta t-score</code> en <code>Meer dashboards > ROM > ROM - Proces valide metingen</code>.

Zie hieronder een overzicht:
{| class="wikitable"
|+
!Dashboard
!Tegel
!Toelichting
|-
| rowspan="4" |Delta t-score
|Delta T-score ROM per maand
| rowspan="4" |Delta-T wordt per patient/behandeling berekend als de verschilscore tussen de vorige meting en huidige meting.
|-
|Delta T-score ROM per organisatieniveau
|-
|Delta T-score ROM per soort vragenlijst
|-
|Delta T-score ROM per RCI
|-
| rowspan="4" |Proces valide metingen
|Valide ROM metingen per maand
| rowspan="4" |De rapportage toont het aantal valide metingen. De rapportagedatum is gelijk aan de datum waarop de meting is afgenomen of anders de uiterlijke datum waarop de meting verwacht wordt.
|-
|Valide ROM metingen per organisatieniveau
|-
|Valide ROM metingen per soort vragenlijst
|-
|Valide ROM metingen per soort meetmoment
|-
| rowspan="4" |Effectmeting
|ROM RCI score per maand
|Alle RCI waarden van diverse meetinstrumenten zoals IDS-SR, HoNOS65, etc. gegroepeerd per dbc sluitdatum (einddatum DBC)

Deze rapportage laat de gemiddelde ROM Deltra-t score zien.
|-
|ROM HoNOS65 subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 11 vragen uit de HoNOS65 vragenlijst.
|-
|ROM RCI score per diagnosegroep
|Deze rapportage laat de ROM RCI score zien per diagnosegroep. In de tabel onder de grafiek is meer verdiepende data te vinden. Deze rapportage laat de gemiddelde ROM Delta-T score zien.
|-
|ROM CANSAS subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 25 vragen uit de CANVAS vragenlijst.

Proportie cliënten met onopgeloste zorgbehoeften is het percentage cliënten dat minimaal 1 heeft gescoord op de subschaal "onopgeloste zorgbehoeften" tov het totaal aantal cliënten.
|-
| rowspan="4" |Effectmeting Delta t-score
|ROM Delta-T score per maand
|Rapportage: gemiddelde ROM Delta-T score per maand.
|-
|ROM Delta-T score per org. niv.
|Rapportage: gemiddelde ROM Delta-T score per organisatie niveau.
|-
|ROM Delta-T score per diagnosegroep
|Rapportage: gemiddelde Delta-T score per diagnosegroep.
|-
|ROM Delta-T score per jaar
|Rapportage: gemiddelde Delta-T score per jaar.
|}
{{VALUECARE}}

Routine Outcome Monitoring (ROM)

2022-11-28T14:01:28Z

Cbruin: /* Definities */

{{VALUECARE}}
== Inleiding ==
Deze pagina dient als naslagwerk om de managementrapportages op de Routine Outcome Monitoring (ROM) te interpreteren en gebruiken.

De doelen van managementrapportage inzake ROM betreft het bieden van inzicht in:

* De (tijdige) inzet van ROM instrumenten op de juiste momenten
* De effecten van de ingezette behandeling

Op deze pagina is een overzicht van definities te vinden, gevolgd door een toelichting op de totstandkoming. De relevante toepassing van de ROM wordt als laatste uitgelicht.

== Definities ==
Hieronder staan alle relevante termen met betrekking tot de ROM gedefinieerd en waar relevant extra toegelicht.
{| class="wikitable"
|+
!Term
!Definitie
!Toelichting
|-
|Voor- en nametingen
|De voor- en nametingen vormen de kapstok voor het bepalen of er een geldige ROM voormetingen dan wel nametingen uitgevoerd is voor het ZPM zorgtraject. Voor andere financieringsstromen geschiedt dit voor de daarvoor leidende zorgproducten (bijvoorbeeld een jeugdproduct). Daarnaast wordt per meting de T-score bepaald, zodat het effect kan worden gemeten door de T-score van de nameting te vergelijken met de voormeting.
| nvt
|-
|Voormeting
|Het eerste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de voormeting. Hierop is een (instelbare) marge in dagen van toepassing om als geldige voormeting te tellen.
| nvt
|-
|Nameting
|Het laatste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de nameting. Ook hierop is een (instelbare) marge in dagen van toepassing om als geldige nameting te tellen.
|De nameting van het voorgaande zorgtraject mag gezien worden als voormeting van het nieuwe traject, indien het voldoen aan de eisen:

* Marge in dagen t.o.v. eerste behandelcontact in nieuwe zorgtraject

* Vragenlijst wordt gebruikt binnen de diagnose hoofdgroep

Notes:

* Als er nog geen einddatum is bepaald voor een behandelreeks, verwachten we dat er nog behandelcontacten gaan volgen. In dit geval bepalen we wel een laatste (ofwel meest recente) behandelcontact, maar valideren we nog niet of er een geldige nameting is geweest.
* Als er een verwachte einddatum (in de toekomst) is ingevuld voor een behandelreeks, dan kijken we voor een valide nameting binnen het tijdsinterval rondom de einddatum van de behandelreeks
* Als de einddatum van een zorgtraject reeds voorbij is, dan kijken we naar het laatste (ofwel meest recente) behandelcontact
|-
|Tussenmetingen
|Voor mensen die langdurig in zorg zijn (en hetzelfde zorgtraject hebben) zijn regelmatigere tussentijdse metingen van ROM is wenselijk. Het gewenste tijdsinterval verschilt per instelling, daarom is een tijdsinterval in te stellen. Voor informatie over het instelbare tijdsinterval, zie ''Tijdsinterval''.
|
|-
|Valide meting
|Een valide meting is een meting die:

* is aangemerkt als ROM
* volledig is ingevuld
* Als de diagnosegroep van het zorgtraject gevuld is, wordt met Beheer BI: Vragenlijst per diagnose bepaald of de vragenlijst in aanmerking komt voor de diagnose hoofdgroep.
** Indien de diagnosegroep leeg is, tonen we op dit moment geen meetmomenten in de dataset.
|
|-
|Tijdsinterval
|Hiermee wordt gedoeld op de gewenste tijd tussen ROM metingen. Zie ook definitie ''tussenmetingen''. De tijdsinterval is door de instelling zelf in te stellen. De tijdsinterval kan verschillen per type vragenlijst en diagnose en kan ingesteld worden via de beheertabel Beheer BI: Vragenlijst per diagnose
|<code>Stuurinformatie > Beheer BI > Beheer BI: Vragenlijst per diagnose</code>
|-
|Meetmoment
|Indien er geen meting plaatsvindt binnen het ingestelde tijdsinterval, wordt er een meetmoment aangemaakt. Dit is dus een moment waarop er een meting verwacht werd, maar deze niet is gedaan.
|Zie ook "Totstandkoming - Stappenplan - stap 3: Nummering metingen" hieronder.
|-
|Initiële meting
|Dit is de eerste valide meting binnen een reeks. De initiële meting is nodig als aanvulling op de voormeting voor de gevallen waarin de voormeting gegenereerd is (en dus geen valide meting is). In deze gevallen is de initiële meting de eerste valide meting binnen een reeks.
|Zie ook "Toepassing - (Delta) t-score" hieronder.
|-
|Behandelreeks
|Alle meetmomenten binnen een zorgtraject in combinatie met de DBC’s.
Binnen één behandelreeksmoeten de onderstaande aspecten overeenkomen. Komen deze aspecten niet overeen, dan geldt dat als een andere behandelreeks.

*'''Inschrijving (en daarmee ook cliënt)'''
** Als een inschrijving eindigt, eindigt de behandelreeks

*'''Diagnose '''
** Is er een nieuwe diagnose gesteld is, eindigt de behandelreeks
*'''Zorgtraject / DBC / Jeugd / WMO '''
** Als er een nieuw zorgtraject, jeugdproduct, of wmo product is, eindigt de behandelreeks
|Als er voor een Jeugd product of WMO product een nieuw product is aangemaakt met een zelfde product-code wordt dit ondervangen in dezelfde behandelreeks. Dit geldt enkel als het nieuwe product binnen 35 dagen na sluiting van het vorige product is aangemaakt.
|-
|Reeks
|Een behandelreeks kan bestaan uit meerdere reeksen. Dit is afhankelijk van de instelling van GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST. Mits er meerdere type vragenlijsten zijn afgenomen, kan er voor elk type vragenlijst een aparte reeks worden aangemaakt. De voor- en nameting worden op het niveau van de behandelreeks gedefinieerd. Oftewel, mits er een voormeting is afgenomen binnen één van de reeksen met dezelfde behandelreeks, zal deze voormeting getoond worden voor al die reeksen.

* '''Behandelreeks'''

*'''(Optioneel) vragenlijst code'''
** Instelbaar
** Wordt enkel toegepast op behandelreeksen met één of meer geldige metingen
** Mits parameter = ‘JA’: dan geldt dat voor een andere vragenlijst-code een andere reeks wordt gemaakt (
*** T-scores worden enkel vergeleken voor vragenlijsten met hetzelfde type (bijv. enkel HoNOS vragenlijsten binnen één behandelreeks).
*** Meetmomenten worden gegenereerd voor elke type vragenlijst. Bijvoorbeeld, is er een HoNOS U verwacht dan voor elk type vragenlijst een nieuw meetmoment. (
** Mits parameter = ‘Nee’: dan geldt dat voor een andere vragenlijst-code dezelfde reeks wordt gebruikt
*** T-scores worden vergelijken onafhankelijk van het type vragenlijsten (Bijvoorbeeld, HoNOS en FARE worden afwisselend gebruikt).
*** Verwachtte meetmomenten worden enkel gegenereerd als er geen meting is geweest binnen het tijdsinterval voor alle type vragenlijsten.
|[[Bestand:ROM reeks.jpg|gecentreerd|392x392px]]
|-
|(Delta)-T score
|De T-score is een uniforme maat om de diverse vragenlijsten naar scores te transformeren en loopt van 0-100. Een succesvolle behandeling zorgt voor een lagere nametingen dan de voormeting (behalve bij het meetinstrument MANSA-16). De Delta-T score is het verschil in T score tussen twee T scores.

Zie voor interpretatie van de Delta T-score de tabel onder "Toepassing - interpretatie delta T-score"
|
|}

== Totstandkoming ==

=== Stappenplan ===
Hieronder is het stappenplan uitgewerkt dat gevolgd wordt om de berekeningen voor de ROM te maken.

Per stap is toelichting gegeven en zo nodig een extra visualisatie toegevoegd.
{| class="wikitable"
|+
!Stap
!Toelichting
!
|-
|0: Bepalen behandelingen binnen behandelreeks
|Eerst wordt bepaald naar welke behandelingen we moeten kijken om de uitersten van behandelreeks te kunnen bepalen.

* Mits het ZPM zorgtraject is aangemaakt met zorglabel N02 (''Overgang oude bekostiging met direct tijd naar Zorgprestatiemodel''), wordt de voormeting bepaald op basis van de voorafgaande DBC(s). De DBCs die worden meegenomen bij de betreffende zorgtrajecten, zijn DBCs die dezelfde (1) diagnose en (2) inschrijvingsnummer hebben als het zorgtraject.

* Voor de combinatie van de zorgtrajecten met eventuele DBCs (en losse DBCs) kijken we naar alle behandelcontacten met directe tijd.
** Voor een dergelijke behandelreeks moeten we het eerste/laatste behandelcontact bepalen.
|[[Bestand:Stap 0 ROM .png|gecentreerd|miniatuur|800x800px]]
|-
|1: Bepalen uitersten van behandelreeks
|Als er bepaald is welke behandelingen in een behandelreeks vallen, wordt er per behandelreeks bepaald:

* Het eerste behandelcontact
* Het laatste behandelcontact

LET OP

Er moet directe tijd zijn geschreven op het behandelcontact en er moet een diagnose bekend zijn voor de behandelreeks. De diagnose is nodig om te bepalen of een eventuele ROM-meting met een vragenlijst is afgenomen die geldig is bij die specifieke diagnose
|[[Bestand:ROMstap1 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|-
|2: Bepalen valide metingen
|Dan wordt er gekeken of er binnen de vastgestelde uiterste waarden van een behandelreeks, valide metingen te vinden zijn.

* Mits er een valide meting te vinden is, dan wordt de behandelreeks, en (optioneel) type vragenlijst meegenomen in de behandelreeks.

* Mits er geen valide meting te vinden is, dan is een reeks enkel bepaald op basis van de behandelreeks. In dit geval zullen er dan ook geen geldige metingen te tonen zijn in de dataset. Er worden wel twee meetmomenten gegenereerd, namelijk het verwachte voormeetmoment en het verwachte nameetmoment.
|[[Bestand:ValueCare - ROM (1).png|gecentreerd|miniatuur|800x800px]]
|-
|3:Nummering metingen
|We nummeren de opvolgende metingen binnen een behandelreeks op basis van de datum van afname.
Hierdoor kunnen we de opvolgende metingen makkelijk koppelen.

Met behulp van het tijdsinterval per type vragenlijst en diagnose, kunnen we bepalen of de opvolgende metingen plaats hebben gevonden binnen het tijdsinterval (t.o.v. de vorige meting), waarbinnen ze worden verwacht.
{| class="wikitable"
|+
!Optie
! colspan="2" |Situatie
!Gevolg
|-
|A
| colspan="2" |De volgende meting valt binnen tijdsinterval
|De volgende meting is een valide meting. Let op: alle valide metingen moeten voldoen aan de criteria gedefinieerd in stap 2.
|-
|B
| colspan="2" |De volgende meting valt buiten tijdsinterval
|Genereren meetmoment (dus geen valide meting). Dit meetmoment moet duidelijk maken aan instellingen dat er een meting verwacht wordt, maar deze meting niet (valide of volledig) is afgenomen.
|-
|C
| rowspan="2" |Geen volgende meting
|Laatste behandelcontact is in het verleden geweest
|Genereren meetmomenten tot en met het laatste behandelcontact.
|-
|D
|Laatste behandelcontact wordt in de toekomst verwacht
|Genereren meetmomenten tot en met de aanleverdatum.
|}
|[[Bestand:ROM stap 3 diagram update .jpg|alt=|gecentreerd|miniatuur|1300x1300px]]
|-
|4: Bepalen voor- en nameting
|Het bepalen van de voor- en nametingen:

De metingen die binnen een reeks het dichtste bij het eerste/laatste behandelcontact liggen worden bestempeld als voor- of nameting.

Indien er enkel een voormeting of een nameting is en niet beide, dan genereren we een meetmoment voor de missende voor- of nameting, met als datum het eerste/laatste behandelcontact.

* Mits er een valide meting heeft plaatsgevonden in de reeks, bepalen we of de meting een valide voor- of nameting is aan de hand van een marge rondom het eerste- of laatste behandelcontact. Deze marges worden bepaald aan de hand van parameters BI_MARGE_RONDOM_EERSTE_BEHANDELCONTACT_VOORMETING en BI_MARGE_RONDOM_LAATSTE_BEHANDELCONTACT_NAMETING .
* Optioneel: Instelbaar
** Mits er voor een reeks meerdere type vragenlijst worden gebruikt (bijv. zowel Honos-12 als SQ48) dan wordt er voor elk type vragenlijst een aparte reeks aangemaakt. De voor- en nametingen worden onafhankelijk van type vragenlijst bepaald. Dit wordt dus gedaan voor de overkoepelende behandelreeks.
|[[Bestand:ROMstap4 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|}

=== Gebruikte beheertabellen en parameters ===
Hieronder zijn de parameters en beheertabellen met relevante toelichting te vinden. De dataset die voor de ROM gebruikt wordt is <code>ROM meetmomenten.</code>
{| class="wikitable"
|+
!Parameters
!Toelichting
|-
|BI_MARGE_RONDOM_EERSTE_BEHANDELCONTACT_VOORMETING
|Bandbreedte in dagen rondom eerste behandelcontact zorgtraject waarbinnen een geldige voormeting afgenomen moet zijn
|-
|BI_MARGE_RONDOM_LAATSTE_BEHANDELCONTACT_NAMETING
|Bandbreedte in dagen rondom laatste behandelcontact zorgtraject waarbinnen een geldige nameting afgenomen moet zijn
|-
|GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST
|Of een reeks rekening moet houden met aparte type vragenlijsten of niet.

Mits parameter = JA, genereren we voor elke verschillende vragenlijst-code binnen een behandelreeks, een aparte reeks

Mits parameter = NEE, mogen de vragenlijsten onafhankelijk van elkaar afgenomen zijn

''NOTE: deze parameter wil ik nog hernoemen naar GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST''
|-
|''GGZBI_TIJDSINTERVAL_ROM_MEETMOMENTEN_ONAFHANKELIJK_VAN_TYPE''
|Het tijdsinterval dat gebruikt wordt voor reeksen, waarbij geen tijdsinterval bepaald is in de beheertabel 'Beheer BI: Vragenlijst per diagnose'
|}
{| class="wikitable"
|+
!Beheertabel
!Toelichting
|-
|Beheer BI: Vragenlijst per diagnose
|Per diagnosehoofdgroep kan het gebruikte ROM-instrument aangegeven worden.
In deze beheertabel kan ook het interval per type vragenlijst en diagnose ingesteld worden. (NIEUW!)
|-
|Beheer BI: Vragenlijst
|Per vragenlijst kan worden aangegeven of deze wordt gebruikt als ROM- en/of CQI-instrument
|-
|Beheer BI: Parameters
|Voor het instellen van o.a. de hierboven genoemde parameters.
|}

== Toepassing ==

In dit deel worden de toepassingen toegelicht, deze toepassingen zijn gericht op het behalen van de doelen van de managementrapportage inzake ROM zoals beschreven in de inleiding van deze pagina.

=== Beheertabel ===

Zoals hierboven al vaker aangegeven zijn er een aantal dingen instelbaar via beheertabellen. Zie ook het overzicht van beheertabellen hierboven.

De instellingen van deze beheertabellen hebben invloed om de onderstaande toepassingen en dienen dus correct ingevuld te zijn om de toepassing zo nuttig en accuraat mogelijk te laten zijn.

=== (Delta) t-score ===
De instellingen vinden het vooral belangrijk om de t-scores te weten die bij een ROM meting hoorde. Daarnaast willen ze de delta t-score weten, zodat ze kunnen zien of een cliënt verbeterd of juist verslechterd in de loop der tijd.

Voor een gegenereerd meetmoment hebben we geen t-score. Daardoor kunnen we enkel t-scores vergelijken van valide metingen. We tonen in dataset ROM meetmomenten daarom enkel delta t-scores voor valide metingen ten opzichte van valide metingen. Dit houdt ook in dat voor gegenereerde voormeetmomenten, we geen delta t-score ten opzichte van de voormeting kunnen doen. Om dit te voorkomen, hebben we de ‘initiële meting’ geïntroduceerd. Dit is de eerste valide meting binnen een reeks. We hebben op deze manier dus twee type delta t-scores in de dataset: (1) delta t-score t.o.v. de vorige valide meting, (2) delta t-score t.o.v. de initiële meting.

[[Bestand:Deltat nieuw.jpg|alt=|gecentreerd|miniatuur|800x800px]]

==== Interpretatie Delta T-score ====
Zie de tabel hieronder voor de interpretatie van de Delta T-score:
{| class="wikitable"
|+
!Code
!Classificatie
!Delta T-score
|-
|1
|Hersteld
|> 5 <code>AND</code> voormeting t > 42,5 <code>AND</code> nameting t < 42,5
|-
|2
|Verbeterd
|> 5
|-
|3
|Onveranderd
| -5 < delta t < 5
|-
|4
|Verslechterd
|< -5
|}

=== KPI's en dashboards ===
Voor de ROM biedt ValueCare verschillende dashboards in het portaal.

Deze zijn te vinden onder <code>Meer dashboards > ROM > ROM - Delta t-score</code> en <code>Meer dashboards > ROM > ROM - Proces valide metingen</code>.

Zie hieronder een overzicht:
{| class="wikitable"
|+
!Dashboard
!Tegel
!Toelichting
|-
| rowspan="4" |Delta t-score
|Delta T-score ROM per maand
| rowspan="4" |Delta-T wordt per patient/behandeling berekend als de verschilscore tussen de vorige meting en huidige meting.
|-
|Delta T-score ROM per organisatieniveau
|-
|Delta T-score ROM per soort vragenlijst
|-
|Delta T-score ROM per RCI
|-
| rowspan="4" |Proces valide metingen
|Valide ROM metingen per maand
| rowspan="4" |De rapportage toont het aantal valide metingen. De rapportagedatum is gelijk aan de datum waarop de meting is afgenomen of anders de uiterlijke datum waarop de meting verwacht wordt.
|-
|Valide ROM metingen per organisatieniveau
|-
|Valide ROM metingen per soort vragenlijst
|-
|Valide ROM metingen per soort meetmoment
|-
| rowspan="4" |Effectmeting
|ROM RCI score per maand
|Alle RCI waarden van diverse meetinstrumenten zoals IDS-SR, HoNOS65, etc. gegroepeerd per dbc sluitdatum (einddatum DBC)

Deze rapportage laat de gemiddelde ROM Deltra-t score zien.
|-
|ROM HoNOS65 subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 11 vragen uit de HoNOS65 vragenlijst.
|-
|ROM RCI score per diagnosegroep
|Deze rapportage laat de ROM RCI score zien per diagnosegroep. In de tabel onder de grafiek is meer verdiepende data te vinden. Deze rapportage laat de gemiddelde ROM Delta-T score zien.
|-
|ROM CANSAS subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 25 vragen uit de CANVAS vragenlijst.

Proportie cliënten met onopgeloste zorgbehoeften is het percentage cliënten dat minimaal 1 heeft gescoord op de subschaal "onopgeloste zorgbehoeften" tov het totaal aantal cliënten.
|-
| rowspan="4" |Effectmeting Delta t-score
|ROM Delta-T score per maand
|Rapportage: gemiddelde ROM Delta-T score per maand.
|-
|ROM Delta-T score per org. niv.
|Rapportage: gemiddelde ROM Delta-T score per organisatie niveau.
|-
|ROM Delta-T score per diagnosegroep
|Rapportage: gemiddelde Delta-T score per diagnosegroep.
|-
|ROM Delta-T score per jaar
|Rapportage: gemiddelde Delta-T score per jaar.
|}
{{VALUECARE}}

Klant Query Server

2022-10-19T14:33:34Z

Cbruin: /* spelling */

== Inleiding ==
Op verzoek stelt ValueCare aan de instellingen een Query Server beschikbaar met daarop een Postgres database met alle source data en BI resultaat data. De door de instelling aangemerkte gebruikers kunnen een connectie maken met de database en er queries op los laten. Ook is het mogelijk om een tool, zoals bijvoorbeeld PowerBI, te connecten tot de database.

== Implementatie ==
Het volgende is nodig vanuit de instelling:

* Een server en het IP adres van de server, tenzij de server wordt gehost door ValueCare.
* Een VPN verbinding van het klantnetwerk naar het ValueCare netwerk.
* Een lijst met gebruikers.

De rest van de implementatie wordt door ValueCare verzorgd.

== Hoe werkt het? ==
In het kort wordt het volgende dagelijks gedaan:

* Er wordt een kopie van de source data en BI resultaat data op de ValueCare Productie server gemaakt.
* Op de Query Server zijn er 2 database schema's: vcs en public. Het vcs schema wordt leeg gemaakt.
* De kopie van de source data en BI resultaat data wordt in het vcs schema geplaatst.
De gebruiker kan vervolgens data in het vcs schema inzien, maar niet wijzigen. In het public schema kan de gebruiker tabellen aanmaken, wijzigen en verwijderen.

== Toelichting data ==

=== De data ===
Er zijn twee schema's beschikbaar op de Query Server: public en vcs. In het vcs schema worden alle bi- en bron-data neergezet, zodat de ValueCare data beschikbaar is. Deze data worden elke dag ververst, zodat het elke dag overeen komt met de data op de Productie-omgeving. Als u op schema vcs een eigen tabel zou aanmaken, wordt deze verwijderd tijdens de verversing. Om met eigen tabellen te werken, is het public-schema beschikbaar. De tabellen die hierop staan, blijven beschikbaar op de Query Server. Hoe u data overzet van schema vcs naar schema public leest u hieronder.

==='''Tabellen kopiëren van schema VCS naar schema Public'''===
Er zijn verschillende manieren om een tabel van schema vcs over te zetten naar schema public. Hieronder is de query uitgeschreven voor één van die manieren. Als je dit vaak wil gebruiken, is het handig om hier een template van te maken (specifiek voor DBeaver). Hier vind je meer over in “Templates”.

CREATE TABLE public.table_name (LIKE vcs.table_name INCLUDING ALL);

INSERT INTO public.table_name

SELECT *

FROM vcs.table_name;

=== '''Van een dashboard of tegel naar de juiste tabel op de Query Server''' ===
Om te begrijpen welke tabellen op de Query Server onderliggend zijn aan de tegels en dashboards die zichtbaar zijn in het portaal is de tabel bi_queryserver_tegels_en_dashboards beschikbaar. Hierin kan je zien welke tabellen worden gebruikt in een tegel en/of dashboard. In onderstaand voorbeeld, ziet u dat voor de tegel ‘Waarde verblijfsdagen per maand’, die te vinden is in dataset ‘Verblijf ZPM’, de onderliggende tabel ‘bi_zis_verblijf_zpm’ is. Tabel bi_zis_verblijf_zpm is dan te vinden op de Query Server.
{| class="wikitable"
|'''tegel_naam'''
|'''dataset_naam'''
|'''tabel_naam'''
|'''tegel_beschrijving'''
|-
|Waarde verblijfsdagen per maand
|Verblijf ZPM
|bi_zis_verblijf_zpm
|Deze rapportage toont waarde van de verblijfsdagen voor …
|}
Daarnaast kunt u vanuit het portaal ook het filter 'Paginanaam' gebruiken. Als je deze toevoegt vanuit [+ nieuw filter] onderaan de linker balk met filters, dan ziet u ook welke tabellen er gebruikt worden voor het opstellen van de tegel en/of dashboard. Zoekt u bijvoorbeeld van een dashboard de bijbehorende dataset, dan kunt u ook het filter 'Paginanaam' gebruiken, om deze vervolgens als dataset_naam op de Query Server terug te vinden.

De logica achter de benaming van tabellen op de Query Server is hieronder weergegeven.
{| class="wikitable"
|'''Voorvoegsel'''
|'''Betekenis'''
|'''Uitleg'''
|-
|src_
|Source (bron)
|Alle tabellen die wij direct vanuit een bron ophalen krijgen het voorvoegsel src_. Dit zijn dus tabellen vanuit bronnen, zoals XMCare, MijnQuarant, Beaufort, QuestManager, etc. Ook bestanden die we ophalen vanaf een SFTP server of andere bronnen, krijgen dit voorvoegsel.
|-
|bi_
|Business intelligence
|Alle tabellen die gebruikt worden voor het samenstellen van dashboards en tegels hebben het voorvoegsel bi.
|}

=== '''Connectie opzetten''' ===

# Vraag om de hostname en de databasename bij ValueCare
#* Het kan ook zijn dat de Query Server lokaal gehost wordt, in dat geval is de hostname doorgaans te achterhalen bij uw ICT-afdeling
# Vraag om de username en password bij uw ValueCare contactpersoon.
# Maak de connectie vanuit de tool die u gebruikt, door de hostname en de databasename in te vullen en in te loggen met uw username en password.
#* De Query Server beschikt over een postgres database, dus het poortnummer is de standaard postgres poort (5432)

== Werken met DBeaver en de Query Server ==
Er zijn tal van goede programma's die u kunt gebruiken om te querieën op de Query Server. Mits u gebruik maakt of wilt maken van DBeaver om op de Query Server te querieën, dan vindt u hieronder een aantal instructies en een aantal tips & tricks die het gebruik van DBeaver nog fijner maken.

=== '''Installeren DBeaver''' ===

* Via <nowiki>https://dbeaver.io/download/</nowiki> kunt u DBeaver downloaden.
* Met de standaard instellingen van de installatie kunt u prima op de Query Server komen, maar voelt u zich vooral vrij om de instellingen naar wens aan te passen.

=== '''Connectie opzetten met de database''' ===

# Klik linksboven op het stekkertje om een nieuwe connectie op te zetten. (Dit kan eventueel ook via het menu: Database > New Database Connection
# Selecteer PostgreSQL
# Vul de juiste naam voor de Host in (het poortnummer staat default al goed: 5432)
# Vul de juiste naam voor de Database in
# Vul de juiste Username in (deze heb je ontvangen vanuit ValueCare. Heb je deze nog niet, dan kan je die aanvragen via jouw contactpersoon)
# Ga naar het kopje “Driver properties” en zet hier het veld tcpKeepAlive op ‘True’
# Klik op Finish
# Nu verschijnt er links in de “Database Navigator” een connectie met de naam van de database. Dubbelklik hierop om de connectie te openen
# Vul je wachtwoord in en voilà!

=== '''Tips & Tricks om snel met DBeaver te werken''' ===
'''Overzicht van de functietoetsen'''

Uitvoeren van een query: ctrl + enter

Openen van new script: F3

Geavanceerd kopiëren: ctrl + shift + c (uitgebreidere uitleg onder “Geavanceerd kopiëren”)

'''Templates'''

Templates zijn erg handig in DBeaver. Hiermee kunt u veelgebruikte queries opslaan en hoeft u die niet volledig te typen, als u ze de volgende keer wil gebruiken. Bijvoorbeeld: In plaats van ‘SELECT * FROM table_name;’, type je enkel ‘saf’ en druk je op tab.

Om een template aan te maken gaat u naar: Window > Preferences > SQL Editor > Templates > New.

''Name'': de combinatie aan woorden of letters die u wil typen in plaats van de query

''Pattern'': de query die moet verschijnen als u de Name typt en op Tab drukt.

''Insert variable'': Hiermee kunt u een bepaalde variabele aanroepen nadat u het template gebruikt. Bijvoorbeeld, SELECT * FROM '''${table}'''; zorgt ervoor dat u makkelijk een bestaande tabel kunt selecteren als u het template gebruikt.

'''Geavanceerd kopiëren'''

Met ctrl + shift + c kunt u geavanceerd kopiëren. Dit is handig als u de geselecteerde rijen wil gebruiken, bijvoorbeeld in een volgende query. Er staan dan automatisch quotes omheen en een komma tussen elk item, zoals hieronder weergegeven.

'item1',

'item2',

...

==== Exporteren naar Excel (xlsx) ====
U kunt een extensie installeren waarmee u direct Excels kunt downloaden. Dus niet eerst csv-bestanden die nog met de hand geconverteerd moeten worden. Volg de stappen in de link 'extensie installeren'.

LET OP!: Sluit DBeaver eerst af en start het op als Administrator. Bijv. door Ctrl + Shift + Rechtermuisknop op de taakbalk en dan 'Als administrator uitvoeren'.

==== CSV-bestanden als database benaderen ====
Klik op het plusje met New Database Connection, zoek naar 'csv'.

Onder Path kiest u een map waarin u alle .csv-bestanden neer gaat zetten. Klik op Finish.

Alle csv's die u in de map (die je hierboven aangemaakt hebt) plaatst, zijn dan beschikbaar om op te queryen.

In de Driver Properties kunt u onder separator instellen wat het scheidingsteken is.

==== Regels afsterren: ====
Regels zijn op twee manieren als tekst neer te zetten.

-- door middel van twee streepjes voor

/*

Of door middel van /* en */

<nowiki>*</nowiki>/

Als u al tekst heeft geschreven kunt u gebruiken maken van ctrl + / om automatisch streepjes voor de tekst te laten zetten. Selecteer de betreffende regels en druk op CTRL + /

==== Databasenaam in export ====
Een export doet u door in een Resultset met de Rechtermuisknop op 'Export data ...' te klikken. Als u wil dat de file-name automatisch de databasenaam, tabelnaam, en/of een timestamp bevat, kunt u dat doen door het volgende te doen.

Bij Export data ... > Output (stap 4) > File name pattern, kunt u de naam van de te exporteren file bepalen. Als u daarin gebruik maakt van onderstaande variabelen, krijgt de export automatisch de naam van de betreffende variabele.

De databasenaam: ${datasource}

De tabelnaam: ${table}

De timestamp: ${timestamp}

Een combinatie hiervan is ook mogelijk. Bijvoorbeeld ${datasource}_${table}_${timestamp}.

==== Naar hoofdletters/kleine letters van selectie ====
Ctrl + Shift + X -> selectie naar hoofdletters

Ctrl + Shift + Y -> selectie naar kleine letters

== Werken met PowerBI en de Query Server ==
Mocht u met PowerBI de data op de Query Server willen gebruiken, dan dient u de volgende stappen te volgen:

* Installeer PowerBI
* Open PowerBI
* Klik op "Gegevens ophalen" en "Meer" in het lint of "Gegevens ophalen" in het startscherm.
* Kies vervolgens in het menu "Gegevens ophalen" de optie "PostgreSQL-database" en klik op "Verbinding maken".

[[Bestand:VC BI QueryServer PowerBI1.png|geen|miniatuur]]

* Voer vervolgens in het menu "PostgreSQL-database" waarden in voor "Server" en "Database".
** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.

[[Bestand:VC BI QueryServer PowerBI2.png|geen|miniatuur]]

* Voer in het volgende menu uw login en wachtwoord in.
** Uw ValueCare contactpersoon heeft u op een veilige manier voorzien van deze gegevens.
** Dit hoeft u maar 1 keer te doen voor een connectie. De volgende keer wordt uw login en wachtwoord niet meer gevraagd.
* Kies vervolgens in het menu "Navigator" de gewenste tabel uit de lijst. Kies vervolgens op "Laden" als u de hele tabel wilt downloaden of kies "Gegevens transformeren" om data te limiteren en te bewerken.
* U kunt nu aan de slag.

NB:

* Via de knop "Recente bronnen" kunt u de verbinding met de Query Server selecteren en dan snel een extra tabel met data toevoegen

== Werken met Excel en de Query Server ==

Mocht u met Excel de data op de Query Server willen gebruiken, dan dient u de onderstaande stappen te volgen. Het is noodzakelijk dat u een programma installeert op uw computer, namelijk een ODBC driver. Als u geen programma's op uw eigen computer kunt installeren, hebt u hulp nodig van uw ICT service desk.

Instructies:

* Download Postgres ODBC driver via <nowiki>https://www.postgresql.org/ftp/odbc/versions/msi/</nowiki>
** Neem de laatste versie! Neem de 64 bit versie!
* Installeer de ODBC driver op uw computer
** Start het programma "psqlodbc_x64" in de msi file.
** Klik op Next, vink aan "I accept the terms in the License Agreement", klik Next, klik Next, klik Install
** Klik Ja op vraag of programma wijzigingen aan laptop/PC mag aanbrengen
** Klik Finish
* Configureer ODBC koppeling op uw computer
** Zoek via de Windows knop de app "ODBC-gegevensbronbeheer (64-bits)"
** Open deze app
** Klik op Toevoegen
** Klik op "PostgreSQL Unicode(x64)" en op "Voltooien"
** Vul de database gegevens en login gegevens in
*** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.
*** Geef bij Data Source een begrijpelijke naam aan (laat de default naam niet staan). Bijvoorbeeld: Klant Qserver X
*** Klik op Test om te checken of de connectie werkt.

[[Bestand:VC BI QueryServer Excel1.png|geen|miniatuur]]

* Open Excel
* Zet de Excel connectie op
** Klik op Gegevens, Gegevens ophalen, Uit andere bronnen, Uit ODBC
** Klik in het scherm op de Data Source zoals net aangemaakt (bijvoorbeeld Bijvoorbeeld: Klant Qserver X) en klik op OK
** Vul in het volgende scherm wederom de gebruikersgegevens in en klik op OK
** Kies vervolgens in het scherm Navigator de gewenste tabellen en laadt deze in Excel
* U kunt nu aan de slag.

{{VALUECARE}}

Klant Query Server

2022-10-19T14:18:32Z

Cbruin: /* spelling */

== Inleiding ==
Op verzoek stelt ValueCare aan de instellingen een Query Server beschikbaar met daarop een Postgres database met alle source data en BI resultaat data. De door de instelling aangemerkte gebruikers kunnen een connectie maken met de database en er queries op los laten. Ook is het mogelijk om een tool, zoals bijvoorbeeld PowerBI, te connecten tot de database.

== Implementatie ==
Het volgende is nodig vanuit de instelling:

* Een server en het IP adres van de server, tenzij de server wordt gehost door ValueCare.
* Een VPN verbinding van het klantnetwerk naar het ValueCare netwerk.
* Een lijst met gebruikers.

De rest van de implementatie wordt door ValueCare verzorgd.

== Hoe werkt het? ==
In het kort wordt het volgende dagelijks gedaan:

* Er wordt een kopie van de source data en BI resultaat data op de ValueCare Productie server gemaakt.
* Op de Query Server zijn er 2 database schema's: vcs en public. Het vcs schema wordt leeg gemaakt.
* De kopie van de source data en BI resultaat data wordt in het vcs schema geplaatst.
De gebruiker kan vervolgens data in het vcs schema inzien, maar niet wijzigen. In het public schema kan de gebruiker tabellen aanmaken, wijzigen en verwijderen.

== Toelichting data ==

=== De data ===
Er zijn twee schema's beschikbaar op de Query Server: public en vcs. In het vcs schema worden alle bi- en bron-data neergezet, zodat de ValueCare data beschikbaar is. Deze data worden elke dag ververst, zodat het elke dag overeen komt met de data op de Productie-omgeving. Als u op schema vcs een eigen tabel zou aanmaken, wordt deze verwijderd tijdens de verversing. Om met eigen tabellen te werken, is het public-schema beschikbaar. De tabellen die hierop staan, blijven beschikbaar op de Query Server. Hoe u data overzet van schema vcs naar schema public leest u hieronder.

==='''Tabellen kopiëren van schema VCS naar schema Public'''===
Er zijn verschillende manieren om een tabel van schema vcs over te zetten naar schema public. Hieronder is de query uitgeschreven voor één van die manieren. Als je dit vaak wil gebruiken, is het handig om hier een template van te maken (specifiek voor DBeaver). Hier vind je meer over in “Templates”.

CREATE TABLE public.table_name (LIKE vcs.table_name INCLUDING ALL);

INSERT INTO public.table_name

SELECT *

FROM vcs.table_name;

=== '''Van een dashboard of tegel naar de juiste tabel op de Query Server''' ===
Om te begrijpen welke tabellen op de Query Server onderliggend zijn aan de tegels en dashboards die zichtbaar zijn in het portaal is de tabel bi_queryserver_tegels_en_dashboards beschikbaar. Hierin kan je zien welke tabellen worden gebruikt in een tegel en/of dashboard. In onderstaand voorbeeld, zie je dus dat voor de tegel ‘Waarde verblijfsdagen per maand’, die te vinden is in dataset ‘Verblijf ZPM’, de onderliggende tabel ‘bi_zis_verblijf_zpm’ is. Tabel bi_zis_verblijf_zpm is dan te vinden op de Query Server.
{| class="wikitable"
|'''tegel_naam'''
|'''dataset_naam'''
|'''tabel_naam'''
|'''tegel_beschrijving'''
|-
|Waarde verblijfsdagen per maand
|Verblijf ZPM
|bi_zis_verblijf_zpm
|Deze rapportage toont waarde van de verblijfsdagen voor …
|}
Daarnaast kan je vanuit het portaal ook het filter paginanaam gebruiken. Als je deze toevoegt vanuit [+ nieuw filter] onderaan de linker balk met filters, dan zie je ook welke tabellen er gebruikt worden voor het opstellen van de tegel en/of dashboard.

De logica achter de benaming van tabellen op de Query Server is hieronder weergegeven.
{| class="wikitable"
|'''Voorvoegsel'''
|'''Betekenis'''
|'''Uitleg'''
|-
|src_
|Source (bron)
|Alle tabellen die wij direct vanuit een bron ophalen krijgen het voorvoegsel src_. Dit zijn dus tabellen vanuit bronnen, zoals XMCare, MijnQuarant, Beaufort, QuestManager, etc. Ook bestanden die we ophalen vanaf een SFTP server of andere bronnen, krijgen dit voorvoegsel.
|-
|bi_
|Business intelligence
|Alle tabellen die gebruikt worden voor het samenstellen van dashboards en tegels hebben het voorvoegsel bi.
|}

=== '''Connectie opzetten''' ===

# Vraag om de hostname en de databasename bij ValueCare
#* Het kan ook zijn dat de Query Server lokaal gehost wordt, in dat geval is de hostname doorgaans te achterhalen bij uw ICT-afdeling
# Vraag om de username en password bij jouw ValueCare contactpersoon.
# Maak de connectie vanuit de tool die u gebruikt, door de hostname en de databasename in te vullen en in te loggen met uw username en password.
#* De Query Server beschikt over een postgres database, dus het poortnummer is de standaard postgres poort (5432)

== Werken met DBeaver en de Query Server ==
Er zijn tal van goede programma's die u kunt gebruiken om te querieën op de Query Server. Mits u gebruik maakt of wilt maken van DBeaver om op de Query Server te querieën, dan vindt u hieronder een aantal instructies en een aantal tips & tricks die het gebruik van DBeaver nog fijner maken.

=== '''Installeren DBeaver''' ===

* Via <nowiki>https://dbeaver.io/download/</nowiki> kunt u DBeaver downloaden
* Met de standaard instellingen van de installatie kan je prima op de Query Server komen, maar voel je vrij om de instellingen naar wens aan te passen.

=== '''Connectie opzetten met de database''' ===

# Klik linksboven op het stekkertje om een nieuwe connectie op te zetten. (Dit kan eventueel ook via het menu: Database > New Database Connection
# Selecteer PostgreSQL
# Vul de juiste naam voor de Host in (het poortnummer staat default al goed: 5432)
# Vul de juiste naam voor de Database in
# Vul de juiste Username in (deze heb je ontvangen vanuit ValueCare. Heb je deze nog niet, dan kan je die aanvragen via jouw contactpersoon)
# Ga naar het kopje “Driver properties” en zet hier het veld tcpKeepAlive op ‘True’
# Klik op Finish
# Nu verschijnt er links in de “Database Navigator” een connectie met de naam van de database. Dubbelklik hierop om de connectie te openen
# Vul je wachtwoord in en voilà!

=== '''Tips & Tricks om snel met DBeaver te werken''' ===
'''Overzicht van de functietoetsen'''

Uitvoeren van een query: ctrl + enter

Openen van new script: F3

Geavanceerd kopiëren: ctrl + shift + c (uitgebreidere uitleg onder “Geavanceerd kopiëren”)

'''Templates'''

Templates zijn erg handig in DBeaver. Hiermee kan je veelgebruikte queries opslaan en hoef je die niet volledig te typen, als je ze de volgende keer wil gebruiken. Bijvoorbeeld: In plaats van ‘SELECT * FROM table_name;’, type je enkel ‘saf’ en druk je op tab.

Om een template aan te maken ga je naar: Window > Preferences > SQL Editor > Templates > New.

''Name'': de combinatie aan woorden of letters die jij wil typen in plaats van de query

''Pattern'': de query die moet verschijnen als je de Name typt en op Tab drukt.

''Insert variable'': Hiermee kan je een bepaalde variabele aanroepen nadat je het template gebruikt. Bijvoorbeeld, SELECT * FROM '''${table}'''; zorgt ervoor dat je makkelijk een bestaande tabel kan selecteren als je het template gebruikt.

'''Geavanceerd kopiëren'''

Met ctrl + shift + c kunt u geavanceerd kopiëren. Dit is handig als u de geselecteerde rijen wil gebruiken, bijvoorbeeld in een volgende query. Er staan dan automatisch quotes omheen en een komma tussen elk item, zoals hieronder weergegeven.

'item1',

'item2',

...

==== Exporteren naar Excel (xlsx) ====
Je kunt een extensie installeren waarmee je direct Excels kunt downloaden. Dus niet eerst csv-bestanden die nog met de hand geconverteerd moeten worden. Volg de stappen in de link 'extensie installeren'.

LET OP!: Sluit DBeaver eerst af en start het op als Administrator. Bijv. door Ctrl + Shift + Rechtermuisknop op de taakbalk en dan 'Als administrator uitvoeren'.

==== CSV-bestanden als database benaderen ====
Klik op het plusje met New Database Connection, zoek naar 'csv'.

Onder Path kies je een map waarin je alle .csv-bestanden neer gaat zetten. Klik op Finish.

Alle csv's die je in de map (die je hierboven aangemaakt hebt) plaatst, zijn dan beschikbaar om op te queryen.

In de Driver Properties kun je onder seperator instellen wat het scheidingsteken is.

==== Regels afsterren: ====
Regels zijn op twee manieren als tekst neer te zetten.

-- door middel van twee streepjes voor

/*

Of door middel van /* en */

<nowiki>*</nowiki>/

Als u al tekst heeft geschreven kunt u gebruiken maken van ctrl + / om automatisch streepjes voor de tekst te laten zetten. Selecteer de betreffende regels en druk op CTRL + /

==== Databasenaam in export ====
Een export doe je door in een Resultset met de Rechtermuisknop op 'Export data ...' te klikken. Als u wil dat de file-name automatisch de databasenaam, tabelnaam, en/of een timestamp bevat, kan je dat doen door het volgende te doen.

Bij Export data ... > Output (stap 4) > File name pattern, kan je de naam van de te exporteren file bepalen. Als je daarin gebruik maakt van onderstaande variabelen, krijgt de export automatisch de naam van de betreffende variabele.

De databasenaam: ${datasource}

De tabelnaam: ${table}

De timestamp: ${timestamp}

Een combinatie hiervan is ook mogelijk. Bijvoorbeeld ${datasource}_${table}_${timestamp}.

==== Naar hoofdletters/kleine letters van selectie ====
Ctrl + Shift + X -> selectie naar hoofdletters

Ctrl + Shift + Y -> selectie naar kleine letters

== Werken met PowerBI en de Query Server ==
Mocht u met PowerBI de data op de Query Server willen gebruiken, dan dient u de volgende stappen te volgen:

* Installeer PowerBI
* Open PowerBI
* Klik op "Gegevens ophalen" en "Meer" in het lint of "Gegevens ophalen" in het startscherm.
* Kies vervolgens in het menu "Gegevens ophalen" de optie "PostgreSQL-database" en klik op "Verbinding maken".

[[Bestand:VC BI QueryServer PowerBI1.png|geen|miniatuur]]

* Voer vervolgens in het menu "PostgreSQL-database" waarden in voor "Server" en "Database".
** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.

[[Bestand:VC BI QueryServer PowerBI2.png|geen|miniatuur]]

* Voer in het volgende menu uw login en wachtwoord in.
** Uw ValueCare contactpersoon heeft u op een veilige manier voorzien van deze gegevens.
** Dit hoeft u maar 1 keer te doen voor een connectie. De volgende keer wordt uw login en wachtwoord niet meer gevraagd.
* Kies vervolgens in het menu "Navigator" de gewenste tabel uit de lijst. Kies vervolgens op "Laden" als u de hele tabel wilt downloaden of kies "Gegevens transformeren" om data te limiteren en te bewerken.
* U kunt nu aan de slag.

NB:

* Via de knop "Recente bronnen" kunt u de verbinding met de Query Server selecteren en dan snel een extra tabel met data toevoegen

== Werken met Excel en de Query Server ==

Mocht u met Excel de data op de Query Server willen gebruiken, dan dient u de onderstaande stappen te volgen. Het is noodzakelijk dat u een programma installeert op uw computer, namelijk een ODBC driver. Als u geen programma's op uw eigen computer kunt installeren, hebt u hulp nodig van uw ICT service desk.

Instructies:

* Download Postgres ODBC driver via <nowiki>https://www.postgresql.org/ftp/odbc/versions/msi/</nowiki>
** Neem de laatste versie! Neem de 64 bit versie!
* Installeer de ODBC driver op uw computer
** Start het programma "psqlodbc_x64" in de msi file.
** Klik op Next, vink aan "I accept the terms in the License Agreement", klik Next, klik Next, klik Install
** Klik Ja op vraag of programma wijzigingen aan laptop/PC mag aanbrengen
** Klik Finish
* Configureer ODBC koppeling op uw computer
** Zoek via de Windows knop de app "ODBC-gegevensbronbeheer (64-bits)"
** Open deze app
** Klik op Toevoegen
** Klik op "PostgreSQL Unicode(x64)" en op "Voltooien"
** Vul de database gegevens en login gegevens in
*** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.
*** Geef bij Data Source een begrijpelijke naam aan (laat de default naam niet staan). Bijvoorbeeld: Klant Qserver X
*** Klik op Test om te checken of de connectie werkt.

[[Bestand:VC BI QueryServer Excel1.png|geen|miniatuur]]

* Open Excel
* Zet de Excel connectie op
** Klik op Gegevens, Gegevens ophalen, Uit andere bronnen, Uit ODBC
** Klik in het scherm op de Data Source zoals net aangemaakt (bijvoorbeeld Bijvoorbeeld: Klant Qserver X) en klik op OK
** Vul in het volgende scherm wederom de gebruikersgegevens in en klik op OK
** Kies vervolgens in het scherm Navigator de gewenste tabellen en laadt deze in Excel
* U kunt nu aan de slag.

{{VALUECARE}}

Klant Query Server

2022-10-19T14:10:38Z

Cbruin: /* spelling */

== Inleiding ==
Op verzoek stelt ValueCare aan de instellingen een Query Server beschikbaar met daarop een Postgres database met alle source data en BI resultaat data. De door de instelling aangemerkte gebruikers kunnen een connectie maken met de database en er queries op los laten. Ook is het mogelijk om een tool, zoals bijvoorbeeld PowerBI, te connecten tot de database.

== Implementatie ==
Het volgende is nodig vanuit de instelling:

* Een server en het IP adres van de server, tenzij de server wordt gehost door ValueCare.
* Een VPN verbinding van het klantnetwerk naar het ValueCare netwerk.
* Een lijst met gebruikers.

De rest van de implementatie wordt door ValueCare verzorgd.

== Hoe werkt het? ==
In het kort wordt het volgende dagelijks gedaan:

* Er wordt een kopie van de source data en BI resultaat data op de ValueCare Productie server gemaakt.
* Op de Query Server zijn er 2 database schema's: vcs en public. Het vcs schema wordt leeg gemaakt.
* De kopie van de source data en BI resultaat data wordt in het vcs schema geplaatst.
De gebruiker kan vervolgens data in het vcs schema inzien, maar niet wijzigen. In het public schema kan de gebruiker tabellen aanmaken, wijzigen en verwijderen.

== Toelichting data ==

=== De data ===
Er zijn twee schema's beschikbaar op de Query Server: public en vcs. In het vcs schema worden alle bi- en bron-data neergezet, zodat de ValueCare data beschikbaar is. Deze data worden elke dag ververst, zodat het elke dag overeen komt met de data op de Productie-omgeving. Als u op schema vcs een eigen tabel zou aanmaken, wordt deze verwijderd tijdens de verversing. Om met eigen tabellen te werken, is het public-schema beschikbaar. De tabellen die hierop staan, blijven beschikbaar op de Query Server. Hoe u data overzet van schema vcs naar schema public leest u hieronder.

==='''Tabellen kopiëren van schema VCS naar schema Public'''===
Er zijn verschillende manieren om een tabel van schema vcs over te zetten naar schema public. Hieronder is de query uitgeschreven voor één van die manieren. Als je dit vaak wil gebruiken, is het handig om hier een template van te maken (specifiek voor DBeaver). Hier vind je meer over in “Templates”.

CREATE TABLE public.table_name (LIKE vcs.table_name INCLUDING ALL);

INSERT INTO public.table_name

SELECT *

FROM vcs.table_name;

=== '''Van een dashboard of tegel naar de juiste tabel op de Query Server''' ===
Om te begrijpen welke tabellen op de Query Server onderliggend zijn aan de tegels en dashboards die zichtbaar zijn in het portaal is de tabel bi_queryserver_tegels_en_dashboards beschikbaar. Hierin kan je zien welke tabellen worden gebruikt in een tegel en/of dashboard. In onderstaand voorbeeld, zie je dus dat voor de tegel ‘Waarde verblijfsdagen per maand’, die te vinden is in dataset ‘Verblijf ZPM’, de onderliggende tabel ‘bi_zis_verblijf_zpm’ is. Tabel bi_zis_verblijf_zpm is dan te vinden op de Query Server.
{| class="wikitable"
|'''tegel_naam'''
|'''dataset_naam'''
|'''tabel_naam'''
|'''tegel_beschrijving'''
|-
|Waarde verblijfsdagen per maand
|Verblijf ZPM
|bi_zis_verblijf_zpm
|Deze rapportage toont waarde van de verblijfsdagen voor …
|}
Daarnaast kan je vanuit het portaal ook het filter paginanaam gebruiken. Als je deze toevoegt vanuit [+ nieuw filter] onderaan de linker balk met filters, dan zie je ook welke tabellen er gebruikt worden voor het opstellen van de tegel en/of dashboard.

De logica achter de benaming van tabellen op de Query Server is hieronder weergegeven.
{| class="wikitable"
|'''Voorvoegsel'''
|'''Betekenis'''
|'''Uitleg'''
|-
|src_
|Source (bron)
|Alle tabellen die wij direct vanuit een bron ophalen krijgen het voorvoegsel src_. Dit zijn dus tabellen vanuit bronnen, zoals XMCare, MijnQuarant, Beaufort, QuestManager, etc. Ook bestanden die we ophalen vanaf een SFTP server of andere bronnen, krijgen dit voorvoegsel.
|-
|bi_
|Business intelligence
|Alle tabellen die gebruikt worden voor het samenstellen van dashboards en tegels hebben het voorvoegsel bi.
|}

=== '''Connectie opzetten''' ===

# Vraag om de hostname en de databasename bij ValueCare
#* Het kan ook zijn dat de Query Server lokaal gehost wordt, in dat geval is de hostname doorgaans te achterhalen bij de ICT-afdeling
# Vraag om de username en password bij jouw ValueCare contactpersoon.
# Maak de connectie vanuit de tool die u gebruikt, door de hostname en de databasename in te vullen en in te loggen met uw username en password.
#* De Query Server beschikt over een postgres database, dus het poortnummer is de standaard postgres poort (5432)

== Werken met DBeaver en de Query Server ==
Er zijn tal van goede programma's die u kunt gebruiken om te querieën op de Query Server. Mits u gebruik maakt of wilt maken van DBeaver om op de Query Server te querieën, dan vindt u hieronder een aantal instructies en een aantal tips & tricks die het gebruik van DBeaver nog fijner maken.

=== '''Installeren DBeaver''' ===

* Via <nowiki>https://dbeaver.io/download/</nowiki> kan je DBeaver downloaden
* Met de standaard instellingen van de installatie kan je prima op de Query Server komen, maar voel je vrij om de instellingen naar wens aan te passen.

=== '''Connectie opzetten met de database''' ===

# Klik linksboven op het stekkertje om een nieuwe connectie op te zetten. (Dit kan eventueel ook via het menu: Database > New Database Connection
# Selecteer PostgreSQL
# Vul de juiste naam voor de Host in (het poortnummer staat default al goed: 5432)
# Vul juiste naam voor de Database in
# Vul de juiste Username in (deze heb je ontvangen vanuit ValueCare. Heb je deze nog niet, dan kan je die aanvragen via jouw contactpersoon)
# Ga naar het kopje “Driver properties” en zet hier het veld tcpKeepAlive op ‘True’
# Klik op Finish
# Nu verschijnt er links in de “Database Navigator” een connectie met de naam van de database. Dubbelklik hierop om de connectie te openen
# Vul je wachtwoord in en voilà!

=== '''Tips & Tricks om snel met DBeaver te werken''' ===
'''Overzicht van de functie-toetsen'''

Uitvoeren van een query: ctrl + enter

Openen van new script: F3

Geavanceerd kopiëren: ctrl + shift + c (uitgebreidere uitleg onder “Geavanceerd kopiëren”)

'''Templates'''

Templates zijn erg handig in DBeaver. Hiermee kan je veelgebruikte queries opslaan en hoef je die niet volledig te typen, als je ze de volgende keer wil gebruiken. Bijvoorbeeld: In plaats van ‘SELECT * FROM table_name;’, type je enkel ‘saf’ en druk je op tab.

Om een template aan te maken ga je naar: Window > Preferences > SQL Editor > Templates > New.

''Name'': de combinatie aan woorden of letters die jij wil typen in plaats van de query

''Pattern'': de query die moet verschijnen als je de Name typt en op Tab drukt.

''Insert variable'': Hiermee kan je een bepaalde variabele aanroepen nadat je het template gebruikt. Bijvoorbeeld, SELECT * FROM '''${table}'''; zorgt ervoor dat je makkelijk een bestaande tabel kan selecteren als je het template gebruikt.

'''Geavanceerd kopiëren'''

Met ctrl + shift + c kunt u geavanceerd kopiëren. Dit is handig als u de geselecteerde rijen wil gebruiken, bijvoorbeeld in een volgende query. Er staan dan automatisch quotes omheen en een komma tussen elk item, zoals hieronder weergegeven.

'item1',

'item2',

...

==== Exporteren naar Excel (xlsx) ====
Je kunt een extensie installeren waarmee je direct Excels kunt downloaden. Dus niet eerst csv-bestanden die nog met de hand geconverteerd moeten worden. Volg de stappen in de link 'extensie installeren'.

LET OP!: Sluit DBeaver eerst af en start het op als Administrator. Bijv. door Ctrl + Shift + Rechtermuisknop op de taakbalk en dan 'Als administrator uitvoeren'.

==== CSV-bestanden als database benaderen ====
Klik op het plusje met New Database Connection, zoek naar 'csv'.

Onder Path kies je een map waarin je alle .csv-bestanden neer gaat zetten. Klik op Finish.

Alle csv's die je in de map (die je hierboven aangemaakt hebt) plaatst, zijn dan beschikbaar om op te queryen.

In de Driver Properties kun je onder seperator instellen wat het scheidingsteken is.

==== Regels afsterren: ====
Regels zijn op twee manieren als tekst neer te zetten.

-- door middel van twee streepjes voor

/*

Of door middel van /* en */

<nowiki>*</nowiki>/

Als u al tekst heeft geschreven kunt u gebruiken maken van ctrl + / om automatisch streepjes voor de tekst te laten zetten. Selecteer de betreffende regels en druk op CTRL + /

==== Databasenaam in export ====
Een export doe je door in een Resultset met de Rechtermuisknop op 'Export data ...' te klikken. Als u wil dat de file-name automatisch de databasenaam, tabelnaam, en/of een timestamp bevat, kan je dat doen door het volgende te doen.

Bij Export data ... > Output (stap 4) > File name pattern, kan je de naam van de te exporteren file bepalen. Als je daarin gebruik maakt van onderstaande variabelen, krijgt de export automatisch de naam van de betreffende variabele.

De databasenaam: ${datasource}

De tabelnaam: ${table}

De timestamp: ${timestamp}

Een combinatie hiervan is ook mogelijk. Bijvoorbeeld ${datasource}_${table}_${timestamp}.

==== Naar hoofdletters/kleine letters van selectie ====
Ctrl + Shift + X -> selectie naar hoofdletters

Ctrl + Shift + Y -> selectie naar kleine letters

== Werken met PowerBI en de Query Server ==
Mocht u met PowerBI de data op de Query Server willen gebruiken, dan dient u de volgende stappen te volgen:

* Installeer PowerBI
* Open PowerBI
* Klik op "Gegevens ophalen" en "Meer" in het lint of "Gegevens ophalen" in het startscherm.
* Kies vervolgens in het menu "Gegevens ophalen" de optie "PostgreSQL-database" en klik op "Verbinding maken".

[[Bestand:VC BI QueryServer PowerBI1.png|geen|miniatuur]]

* Voer vervolgens in het menu "PostgreSQL-database" waarden in voor "Server" en "Database".
** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.

[[Bestand:VC BI QueryServer PowerBI2.png|geen|miniatuur]]

* Voer in het volgende menu uw login en wachtwoord in.
** Uw ValueCare contactpersoon heeft u op een veilige manier voorzien van deze gegevens.
** Dit hoeft u maar 1 keer te doen voor een connectie. De volgende keer wordt uw login en wachtwoord niet meer gevraagd.
* Kies vervolgens in het menu "Navigator" de gewenste tabel uit de lijst. Kies vervolgens op "Laden" als u de hele tabel wilt downloaden of kies "Gegevens transformeren" om data te limiteren en te bewerken.
* U kunt nu aan de slag.

NB:

* Via de knop "Recente bronnen" kunt u de verbinding met de Query Server selecteren en dan snel een extra tabel met data toevoegen

== Werken met Excel en de Query Server ==

Mocht u met Excel de data op de Query Server willen gebruiken, dan dient u de onderstaande stappen te volgen. Het is noodzakelijk dat u een programma installeert op uw computer, namelijk een ODBC driver. Als u geen programma's op uw eigen computer kunt installeren, hebt u hulp nodig van uw ICT service desk.

Instructies:

* Download Postgres ODBC driver via <nowiki>https://www.postgresql.org/ftp/odbc/versions/msi/</nowiki>
** Neem de laatste versie! Neem de 64 bit versie!
* Installeer de ODBC driver op uw computer
** Start het programma "psqlodbc_x64" in de msi file.
** Klik op Next, vink aan "I accept the terms in the License Agreement", klik Next, klik Next, klik Install
** Klik Ja op vraag of programma wijzigingen aan laptop/PC mag aanbrengen
** Klik Finish
* Configureer ODBC koppeling op uw computer
** Zoek via de Windows knop de app "ODBC-gegevensbronbeheer (64-bits)"
** Open deze app
** Klik op Toevoegen
** Klik op "PostgreSQL Unicode(x64)" en op "Voltooien"
** Vul de database gegevens en login gegevens in
*** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.
*** Geef bij Data Source een begrijpelijke naam aan (laat de default naam niet staan). Bijvoorbeeld: Klant Qserver X
*** Klik op Test om te checken of de connectie werkt.

[[Bestand:VC BI QueryServer Excel1.png|geen|miniatuur]]

* Open Excel
* Zet de Excel connectie op
** Klik op Gegevens, Gegevens ophalen, Uit andere bronnen, Uit ODBC
** Klik in het scherm op de Data Source zoals net aangemaakt (bijvoorbeeld Bijvoorbeeld: Klant Qserver X) en klik op OK
** Vul in het volgende scherm wederom de gebruikersgegevens in en klik op OK
** Kies vervolgens in het scherm Navigator de gewenste tabellen en laadt deze in Excel
* U kunt nu aan de slag.

{{VALUECARE}}

Bestand:Afsterren DBeaver.png

2022-10-19T14:08:14Z

Cbruin:

Afsterren in DBeaver

Klant Query Server

2022-10-19T14:01:41Z

Cbruin: /* De data */

== Inleiding ==
Op verzoek stelt ValueCare aan de instellingen een Query Server beschikbaar met daarop een Postgres database met alle source data en BI resultaat data. De door de instelling aangemerkte gebruikers kunnen een connectie maken met de database en er queries op los laten. Ook is het mogelijk om een tool, zoals bijvoorbeeld PowerBI, te connecten tot de database.

== Implementatie ==
Het volgende is nodig vanuit de instelling:

* Een server en het IP adres van de server, tenzij de server wordt gehost door ValueCare.
* Een VPN verbinding van het klantnetwerk naar het ValueCare netwerk.
* Een lijst met gebruikers.

De rest van de implementatie wordt door ValueCare verzorgd.

== Hoe werkt het? ==
In het kort wordt het volgende dagelijks gedaan:

* Er wordt een kopie van de source data en BI resultaat data op de ValueCare Productie server gemaakt.
* Op de Query Server zijn er 2 database schema's: vcs en public. Het vcs schema wordt leeg gemaakt.
* De kopie van de source data en BI resultaat data wordt in het vcs schema geplaatst.
De gebruiker kan vervolgens data in het vcs schema inzien, maar niet wijzigen. In het public schema kan de gebruiker tabellen aanmaken, wijzigen en verwijderen.

== Toelichting data ==

=== De data ===
Er zijn twee schema's beschikbaar op de Query Server: public en vcs. In het vcs schema worden alle bi- en bron-data neergezet, zodat de ValueCare data beschikbaar is. Deze data worden elke dag ververst, zodat het elke dag overeen komt met de data op de Productie-omgeving. Als u op schema vcs een eigen tabel zou aanmaken, wordt deze verwijderd tijdens de verversing. Om met eigen tabellen te werken, is het public-schema beschikbaar. De tabellen die hierop staan, blijven beschikbaar op de Query Server. Hoe u data overzet van schema vcs naar schema public leest u hieronder.

==='''Tabellen kopiëren van schema VCS naar schema Public'''===
Er zijn verschillende manieren om een tabel van schema vcs over te zetten naar schema public. Hieronder is de query uitgeschreven voor één van die manieren. Als je dit vaak wil gebruiken, is het handig om hier een template van te maken (specifiek voor DBeaver). Hier vind je meer over in “Templates”.

CREATE TABLE public.table_name (LIKE vcs.table_name INCLUDING ALL);

INSERT INTO public.table_name

SELECT *

FROM vcs.table_name;

=== '''Van een dashboard of tegel naar de juiste tabel op de Query Server''' ===
Om te begrijpen welke tabellen op de Query Server onderliggend zijn aan de tegels en dashboards die zichtbaar zijn in het portaal is de tabel bi_queryserver_tegels_en_dashboards beschikbaar. Hierin kan je zien welke tabellen worden gebruikt in een tegel en/of dashboard. In onderstaand voorbeeld, zie je dus dat voor de tegel ‘Waarde verblijfsdagen per maand’, die te vinden is in dataset ‘Verblijf ZPM’, de onderliggende tabel ‘bi_zis_verblijf_zpm’ is. Tabel bi_zis_verblijf_zpm is dan te vinden op de Query Server.
{| class="wikitable"
|'''tegel_naam'''
|'''dataset_naam'''
|'''tabel_naam'''
|'''tegel_beschrijving'''
|-
|Waarde verblijfsdagen per maand
|Verblijf ZPM
|bi_zis_verblijf_zpm
|Deze rapportage toont waarde van de verblijfsdagen voor …
|}
Daarnaast kan je vanuit het portaal ook het filter paginanaam gebruiken. Als je deze toevoegt vanuit [+ nieuw filter] onderaan de linker balk met filters, dan zie je ook welke tabellen er gebruikt worden voor het opstellen van de tegel en/of dashboard.

De logica achter de benaming van tabellen op de Query Server is hieronder weergegeven.
{| class="wikitable"
|'''Voorvoegsel'''
|'''Betekenis'''
|'''Uitleg'''
|-
|src_
|Source (bron)
|Alle tabellen die wij direct vanuit een bron ophalen krijgen het voorvoegsel src_. Dit zijn dus tabellen vanuit bronnen, zoals XMCare, MijnQuarant, Beaufort, QuestManager, etc. Ook bestanden die we ophalen vanaf een SFTP server of andere bronnen, krijgen dit voorvoegsel.
|-
|bi_
|Business intelligence
|Alle tabellen die gebruikt worden voor het samenstellen van dashboards en tegels hebben het voorvoegsel bi.
|}

=== '''Connectie opzetten''' ===

# Vraag om de hostname en de databasename bij ValueCare
#* Het kan ook zijn dat de Query Server lokaal gehost wordt, in dat geval is de hostname doorgaans te achterhalen bij de ICT-afdeling
# Vraag om de username en password bij jouw ValueCare contactpersoon.
# Maak de connectie vanuit de tool die u gebruikt, door de hostname en de databasename in te vullen en in te loggen met uw username en password.
#* De Query Server beschikt over een postgres database, dus het poortnummer is de standaard postgres poort (5432)

== Werken met DBeaver en de Query Server ==
Er zijn tal van goede programma's die u kunt gebruiken om te querieën op de Query Server. Mits u gebruik maakt of wilt maken van DBeaver om op de Query Server te querieën, dan vindt u hieronder een aantal instructies en een aantal tips & tricks die het gebruik van DBeaver nog fijner maken.

=== '''Installeren DBeaver''' ===

* Via <nowiki>https://dbeaver.io/download/</nowiki> kan je DBeaver downloaden
* Met de standaard instellingen van de installatie kan je prima op de Query Server komen, maar voel je vrij om de instellingen naar wens aan te passen.

=== '''Connectie opzetten met de database''' ===

# Klik linksboven op het stekkertje om een nieuwe connectie op te zetten. (Dit kan eventueel ook via het menu: Database > New Database Connection
# Selecteer PostgreSQL
# Vul de juiste naam voor de Host in (het poortnummer staat default al goed: 5432)
# Vul juiste naam voor de Database in
# Vul de juiste Username in (deze heb je ontvangen vanuit ValueCare. Heb je deze nog niet, dan kan je die aanvragen via jouw contactpersoon)
# Ga naar het kopje “Driver properties” en zet hier het veld tcpKeepAlive op ‘True’
# Klik op Finish
# Nu verschijnt er links in de “Database Navigator” een connectie met de naam van de database. Dubbelklik hierop om de connectie te openen
# Vul je wachtwoord in en voilà!

=== '''Tips & Tricks om snel met DBeaver te werken''' ===
'''Overzicht van de functie-toetsen'''

Uitvoeren van een query: ctrl + enter

Openen van new script: F3

Geavanceerd kopiëren: ctrl + shift + c (uitgebreidere uitleg onder “Geavanceerd kopiëren”)

'''Templates'''

Templates zijn erg handig in DBeaver. Hiermee kan je veelgebruikte queries opslaan en hoef je die niet volledig te typen, als je ze de volgende keer wil gebruiken. Bijvoorbeeld: In plaats van ‘SELECT * FROM table_name;’, type je enkel ‘saf’ en druk je op tab.

Om een template aan te maken ga je naar: Window > Preferences > SQL Editor > Templates > New.

''Name'': de combinatie aan woorden of letters die jij wil typen in plaats van de query

''Pattern'': de query die moet verschijnen als je de Name typt en op Tab drukt.

''Insert variable'': Hiermee kan je een bepaalde variabele aanroepen nadat je het template gebruikt. Bijvoorbeeld, SELECT * FROM '''${table}'''; zorgt ervoor dat je makkelijk een bestaande tabel kan selecteren als je het template gebruikt.

'''Geavanceerd kopiëren'''

Met ctrl + shift + c kunt u geavanceerd kopiëren. Dit is handig als u de geselecteerde rijen wil gebruiken, bijvoorbeeld in een volgende query. Er staan dan automatisch quotes omheen en een komma tussen elk item, zoals hieronder weergegeven.

'item1',

'item2',

...

==== Exporteren naar Excel (xlsx) ====
Je kunt een extensie installeren waarmee je direct Excels kunt downloaden. Dus niet eerst csv-bestanden die nog met de hand geconverteerd moeten worden. Volg de stappen in de link 'extensie installeren'.

LET OP!: Sluit DBeaver eerst af en start het op als Administrator. Bijv. door Ctrl + Shift + Rechtermuisknop op de taakbalk en dan 'Als administrator uitvoeren'.

==== CSV-bestanden als database benaderen ====
Klik op het plusje met New Database Connection, zoek naar 'csv'.

Onder Path kies je een map waarin je alle .csv-bestanden naar gaat zetten. Klik op Finish.

Alle csv's die je in de map die je hierboven getypt hebt plaatst, zijn dan beschikbaar om op te queryen.

In de Driver Properties kun je onder seperator instellen wat het scheidingsteken is.

==== Regels afsterren: ====
Regels zijn op twee manieren als tekst neer te zetten.

-- door middel van twee streepjes voor

/*

Of door middel van /* en */

<nowiki>*</nowiki>/

Als u al tekst heeft geschreven kunt u gebruiken maken van ctrl + / om automatisch streepjes voor de tekst te laten zetten. Selecteer de betreffende regels en druk op CTRL + /

==== Databasenaam in export ====
Een export doe je door in een Resultset met de Rechtermuisknop op 'Export data ...' te klikken. Als u wil dat de file-name automatisch de databasenaam, tabelnaam, en/of een timestamp bevat, kan je dat doen door het volgende te doen.

Bij Export data ... > Output (stap 4) > File name pattern, kan je de naam van de te exporteren file bepalen. Als je daarin gebruik maakt van onderstaande variabelen, krijgt de export automatisch de naam van de betreffende variabele.

De databasenaam: ${datasource}

De tabelnaam: ${table}

De timestamp: ${timestamp}

Een combinatie hiervan is ook mogelijk. Bijvoorbeeld ${datasource}_${table}_${timestamp}.

==== Naar hoofdletters/kleine letters van selectie ====
Ctrl + Shift + X -> selectie naar hoofdletters

Ctrl + Shift + Y -> selectie naar kleine letters

== Werken met PowerBI en de Query Server ==
Mocht u met PowerBI de data op de Query Server willen gebruiken, dan dient u de volgende stappen te volgen:

* Installeer PowerBI
* Open PowerBI
* Klik op "Gegevens ophalen" en "Meer" in het lint of "Gegevens ophalen" in het startscherm.
* Kies vervolgens in het menu "Gegevens ophalen" de optie "PostgreSQL-database" en klik op "Verbinding maken".

[[Bestand:VC BI QueryServer PowerBI1.png|geen|miniatuur]]

* Voer vervolgens in het menu "PostgreSQL-database" waarden in voor "Server" en "Database".
** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.

[[Bestand:VC BI QueryServer PowerBI2.png|geen|miniatuur]]

* Voer in het volgende menu uw login en wachtwoord in.
** Uw ValueCare contactpersoon heeft u op een veilige manier voorzien van deze gegevens.
** Dit hoeft u maar 1 keer te doen voor een connectie. De volgende keer wordt uw login en wachtwoord niet meer gevraagd.
* Kies vervolgens in het menu "Navigator" de gewenste tabel uit de lijst. Kies vervolgens op "Laden" als u de hele tabel wilt downloaden of kies "Gegevens transformeren" om data te limiteren en te bewerken.
* U kunt nu aan de slag.

NB:

* Via de knop "Recente bronnen" kunt u de verbinding met de Query Server selecteren en dan snel een extra tabel met data toevoegen

== Werken met Excel en de Query Server ==

Mocht u met Excel de data op de Query Server willen gebruiken, dan dient u de onderstaande stappen te volgen. Het is noodzakelijk dat u een programma installeert op uw computer, namelijk een ODBC driver. Als u geen programma's op uw eigen computer kunt installeren, hebt u hulp nodig van uw ICT service desk.

Instructies:

* Download Postgres ODBC driver via <nowiki>https://www.postgresql.org/ftp/odbc/versions/msi/</nowiki>
** Neem de laatste versie! Neem de 64 bit versie!
* Installeer de ODBC driver op uw computer
** Start het programma "psqlodbc_x64" in de msi file.
** Klik op Next, vink aan "I accept the terms in the License Agreement", klik Next, klik Next, klik Install
** Klik Ja op vraag of programma wijzigingen aan laptop/PC mag aanbrengen
** Klik Finish
* Configureer ODBC koppeling op uw computer
** Zoek via de Windows knop de app "ODBC-gegevensbronbeheer (64-bits)"
** Open deze app
** Klik op Toevoegen
** Klik op "PostgreSQL Unicode(x64)" en op "Voltooien"
** Vul de database gegevens en login gegevens in
*** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.
*** Geef bij Data Source een begrijpelijke naam aan (laat de default naam niet staan). Bijvoorbeeld: Klant Qserver X
*** Klik op Test om te checken of de connectie werkt.

[[Bestand:VC BI QueryServer Excel1.png|geen|miniatuur]]

* Open Excel
* Zet de Excel connectie op
** Klik op Gegevens, Gegevens ophalen, Uit andere bronnen, Uit ODBC
** Klik in het scherm op de Data Source zoals net aangemaakt (bijvoorbeeld Bijvoorbeeld: Klant Qserver X) en klik op OK
** Vul in het volgende scherm wederom de gebruikersgegevens in en klik op OK
** Kies vervolgens in het scherm Navigator de gewenste tabellen en laadt deze in Excel
* U kunt nu aan de slag.

{{VALUECARE}}

Klant Query Server

2022-10-12T06:33:26Z

Cbruin: benaming

== Inleiding ==
Op verzoek stelt ValueCare aan de instellingen een Query Server beschikbaar met daarop een Postgres database met alle source data en BI resultaat data. De door de instelling aangemerkte gebruikers kunnen een connectie maken met de database en er queries op los laten. Ook is het mogelijk om een tool, zoals bijvoorbeeld PowerBI, te connecten tot de database.

== Implementatie ==
Het volgende is nodig vanuit de instelling:

* Een server en het IP adres van de server, tenzij de server wordt gehost door ValueCare.
* Een VPN verbinding van het klantnetwerk naar het ValueCare netwerk.
* Een lijst met gebruikers.

De rest van de implementatie wordt door ValueCare verzorgd.

== Hoe werkt het? ==
In het kort wordt het volgende dagelijks gedaan:

* Er wordt een kopie van de source data en BI resultaat data op de ValueCare Productie server gemaakt.
* Op de Query Server zijn er 2 database schema's: vcs en public. Het vcs schema wordt leeg gemaakt.
* De kopie van de source data en BI resultaat data wordt in het vcs schema geplaatst.
De gebruiker kan vervolgens data in het vcs schema inzien, maar niet wijzigen. In het public schema kan de gebruiker tabellen aanmaken, wijzigen en verwijderen.

== Toelichting data ==

=== De data ===
Er zijn twee schema's beschikbaar op de Query Server: public en vcs. In het vcs schema wordt alle bi- en bron-data neergezet, zodat de ValueCare data beschikbaar is. Deze data worden elke dag ververst, zodat het elke dag overeen komt met de data op de Productie-omgeving. Als u op schema vcs een eigen tabel zou aanmaken, wordt deze verwijderd tijdens de verversing. Om met eigen tabellen te werken, is het public-schema beschikbaar. De tabellen die hierop staan, blijven beschikbaar op de Query Server. Hoe u data overzet van schema vcs naar schema public leest u hieronder.

==='''Tabellen kopiëren van schema VCS naar schema Public'''===
Er zijn verschillende manieren om een tabel van schema vcs over te zetten naar schema public. Hieronder is de query uitgeschreven voor één van die manieren. Als je dit vaak wil gebruiken, is het handig om hier een template van te maken (specifiek voor DBeaver). Hier vind je meer over in “Templates”.

CREATE TABLE public.table_name (LIKE vcs.table_name INCLUDING ALL);

INSERT INTO public.table_name

SELECT *

FROM vcs.table_name;

=== '''Van een dashboard of tegel naar de juiste tabel op de Query Server''' ===
Om te begrijpen welke tabellen op de Query Server onderliggend zijn aan de tegels en dashboards die zichtbaar zijn in het portaal is de tabel bi_queryserver_tegels_en_dashboards beschikbaar. Hierin kan je zien welke tabellen worden gebruikt in een tegel en/of dashboard. In onderstaand voorbeeld, zie je dus dat voor de tegel ‘Waarde verblijfsdagen per maand’, die te vinden is in dataset ‘Verblijf ZPM’, de onderliggende tabel ‘bi_zis_verblijf_zpm’ is. Tabel bi_zis_verblijf_zpm is dan te vinden op de Query Server.
{| class="wikitable"
|'''tegel_naam'''
|'''dataset_naam'''
|'''tabel_naam'''
|'''tegel_beschrijving'''
|-
|Waarde verblijfsdagen per maand
|Verblijf ZPM
|bi_zis_verblijf_zpm
|Deze rapportage toont waarde van de verblijfsdagen voor …
|}
Daarnaast kan je vanuit het portaal ook het filter paginanaam gebruiken. Als je deze toevoegt vanuit [+ nieuw filter] onderaan de linker balk met filters, dan zie je ook welke tabellen er gebruikt worden voor het opstellen van de tegel en/of dashboard.

De logica achter de benaming van tabellen op de Query Server is hieronder weergegeven.
{| class="wikitable"
|'''Voorvoegsel'''
|'''Betekenis'''
|'''Uitleg'''
|-
|src_
|Source (bron)
|Alle tabellen die wij direct vanuit een bron ophalen krijgen het voorvoegsel src_. Dit zijn dus tabellen vanuit bronnen, zoals XMCare, MijnQuarant, Beaufort, QuestManager, etc. Ook bestanden die we ophalen vanaf een SFTP server of andere bronnen, krijgen dit voorvoegsel.
|-
|bi_
|Business intelligence
|Alle tabellen die gebruikt worden voor het samenstellen van dashboards en tegels hebben het voorvoegsel bi.
|}

=== '''Connectie opzetten''' ===

# Vraag om de hostname en de databasename bij ValueCare
#* Het kan ook zijn dat de Query Server lokaal gehost wordt, in dat geval is de hostname doorgaans te achterhalen bij de ICT-afdeling
# Vraag om de username en password bij jouw ValueCare contactpersoon.
# Maak de connectie vanuit de tool die u gebruikt, door de hostname en de databasename in te vullen en in te loggen met uw username en password.
#* De Query Server beschikt over een postgres database, dus het poortnummer is de standaard postgres poort (5432)

== Werken met DBeaver en de Query Server ==
Er zijn tal van goede programma's die u kunt gebruiken om te querieën op de Query Server. Mits u gebruik maakt of wilt maken van DBeaver om op de Query Server te querieën, dan vindt u hieronder een aantal instructies en een aantal tips & tricks die het gebruik van DBeaver nog fijner maken.

=== '''Installeren DBeaver''' ===

* Via <nowiki>https://dbeaver.io/download/</nowiki> kan je DBeaver downloaden
* Met de standaard instellingen van de installatie kan je prima op de Query Server komen, maar voel je vrij om de instellingen naar wens aan te passen.

=== '''Connectie opzetten met de database''' ===

# Klik linksboven op het stekkertje om een nieuwe connectie op te zetten. (Dit kan eventueel ook via het menu: Database > New Database Connection
# Selecteer PostgreSQL
# Vul de juiste naam voor de Host in (het poortnummer staat default al goed: 5432)
# Vul juiste naam voor de Database in
# Vul de juiste Username in (deze heb je ontvangen vanuit ValueCare. Heb je deze nog niet, dan kan je die aanvragen via jouw contactpersoon)
# Ga naar het kopje “Driver properties” en zet hier het veld tcpKeepAlive op ‘True’
# Klik op Finish
# Nu verschijnt er links in de “Database Navigator” een connectie met de naam van de database. Dubbelklik hierop om de connectie te openen
# Vul je wachtwoord in en voilà!

=== '''Tips & Tricks om snel met DBeaver te werken''' ===
'''Overzicht van de functie-toetsen'''

Uitvoeren van een query: ctrl + enter

Openen van new script: F3

Geavanceerd kopiëren: ctrl + shift + c (uitgebreidere uitleg onder “Geavanceerd kopiëren”)

'''Templates'''

Templates zijn erg handig in DBeaver. Hiermee kan je veelgebruikte queries opslaan en hoef je die niet volledig te typen, als je ze de volgende keer wil gebruiken. Bijvoorbeeld: In plaats van ‘SELECT * FROM table_name;’, type je enkel ‘saf’ en druk je op tab.

Om een template aan te maken ga je naar: Window > Preferences > SQL Editor > Templates > New.

''Name'': de combinatie aan woorden of letters die jij wil typen in plaats van de query

''Pattern'': de query die moet verschijnen als je de Name typt en op Tab drukt.

''Insert variable'': Hiermee kan je een bepaalde variabele aanroepen nadat je het template gebruikt. Bijvoorbeeld, SELECT * FROM '''${table}'''; zorgt ervoor dat je makkelijk een bestaande tabel kan selecteren als je het template gebruikt.

'''Geavanceerd kopiëren'''

Met ctrl + shift + c kunt u geavanceerd kopiëren. Dit is handig als u de geselecteerde rijen wil gebruiken, bijvoorbeeld in een volgende query. Er staan dan automatisch quotes omheen en een komma tussen elk item, zoals hieronder weergegeven.

'item1',

'item2',

...

==== Exporteren naar Excel (xlsx) ====
Je kunt een extensie installeren waarmee je direct Excels kunt downloaden. Dus niet eerst csv-bestanden die nog met de hand geconverteerd moeten worden. Volg de stappen in de link 'extensie installeren'.

LET OP!: Sluit DBeaver eerst af en start het op als Administrator. Bijv. door Ctrl + Shift + Rechtermuisknop op de taakbalk en dan 'Als administrator uitvoeren'.

==== CSV-bestanden als database benaderen ====
Klik op het plusje met New Database Connection, zoek naar 'csv'.

Onder Path kies je een map waarin je alle .csv-bestanden naar gaat zetten. Klik op Finish.

Alle csv's die je in de map die je hierboven getypt hebt plaatst, zijn dan beschikbaar om op te queryen.

In de Driver Properties kun je onder seperator instellen wat het scheidingsteken is.

==== Regels afsterren: ====
Regels zijn op twee manieren als tekst neer te zetten.

-- door middel van twee streepjes voor

/*

Of door middel van /* en */

<nowiki>*</nowiki>/

Als u al tekst heeft geschreven kunt u gebruiken maken van ctrl + / om automatisch streepjes voor de tekst te laten zetten. Selecteer de betreffende regels en druk op CTRL + /

==== Databasenaam in export ====
Een export doe je door in een Resultset met de Rechtermuisknop op 'Export data ...' te klikken. Als u wil dat de file-name automatisch de databasenaam, tabelnaam, en/of een timestamp bevat, kan je dat doen door het volgende te doen.

Bij Export data ... > Output (stap 4) > File name pattern, kan je de naam van de te exporteren file bepalen. Als je daarin gebruik maakt van onderstaande variabelen, krijgt de export automatisch de naam van de betreffende variabele.

De databasenaam: ${datasource}

De tabelnaam: ${table}

De timestamp: ${timestamp}

Een combinatie hiervan is ook mogelijk. Bijvoorbeeld ${datasource}_${table}_${timestamp}.

==== Naar hoofdletters/kleine letters van selectie ====
Ctrl + Shift + X -> selectie naar hoofdletters

Ctrl + Shift + Y -> selectie naar kleine letters

== Werken met PowerBI en de Query Server ==
Mocht u met PowerBI de data op de Query Server willen gebruiken, dan dient u de volgende stappen te volgen:

* Installeer PowerBI
* Open PowerBI
* Klik op "Gegevens ophalen" en "Meer" in het lint of "Gegevens ophalen" in het startscherm.
* Kies vervolgens in het menu "Gegevens ophalen" de optie "PostgreSQL-database" en klik op "Verbinding maken".

[[Bestand:VC BI QueryServer PowerBI1.png|geen|miniatuur]]

* Voer vervolgens in het menu "PostgreSQL-database" waarden in voor "Server" en "Database".
** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.

[[Bestand:VC BI QueryServer PowerBI2.png|geen|miniatuur]]

* Voer in het volgende menu uw login en wachtwoord in.
** Uw ValueCare contactpersoon heeft u op een veilige manier voorzien van deze gegevens.
** Dit hoeft u maar 1 keer te doen voor een connectie. De volgende keer wordt uw login en wachtwoord niet meer gevraagd.
* Kies vervolgens in het menu "Navigator" de gewenste tabel uit de lijst. Kies vervolgens op "Laden" als u de hele tabel wilt downloaden of kies "Gegevens transformeren" om data te limiteren en te bewerken.
* U kunt nu aan de slag.

NB:

* Via de knop "Recente bronnen" kunt u de verbinding met de Query Server selecteren en dan snel een extra tabel met data toevoegen

== Werken met Excel en de Query Server ==

Mocht u met Excel de data op de Query Server willen gebruiken, dan dient u de onderstaande stappen te volgen. Het is noodzakelijk dat u een programma installeert op uw computer, namelijk een ODBC driver. Als u geen programma's op uw eigen computer kunt installeren, hebt u hulp nodig van uw ICT service desk.

Instructies:

* Download Postgres ODBC driver via <nowiki>https://www.postgresql.org/ftp/odbc/versions/msi/</nowiki>
** Neem de laatste versie! Neem de 64 bit versie!
* Installeer de ODBC driver op uw computer
** Start het programma "psqlodbc_x64" in de msi file.
** Klik op Next, vink aan "I accept the terms in the License Agreement", klik Next, klik Next, klik Install
** Klik Ja op vraag of programma wijzigingen aan laptop/PC mag aanbrengen
** Klik Finish
* Configureer ODBC koppeling op uw computer
** Zoek via de Windows knop de app "ODBC-gegevensbronbeheer (64-bits)"
** Open deze app
** Klik op Toevoegen
** Klik op "PostgreSQL Unicode(x64)" en op "Voltooien"
** Vul de database gegevens en login gegevens in
*** Uw ValueCare contactpersoon kan u helpen met de in te vullen waarden.
*** Geef bij Data Source een begrijpelijke naam aan (laat de default naam niet staan). Bijvoorbeeld: Klant Qserver X
*** Klik op Test om te checken of de connectie werkt.

[[Bestand:VC BI QueryServer Excel1.png|geen|miniatuur]]

* Open Excel
* Zet de Excel connectie op
** Klik op Gegevens, Gegevens ophalen, Uit andere bronnen, Uit ODBC
** Klik in het scherm op de Data Source zoals net aangemaakt (bijvoorbeeld Bijvoorbeeld: Klant Qserver X) en klik op OK
** Vul in het volgende scherm wederom de gebruikersgegevens in en klik op OK
** Kies vervolgens in het scherm Navigator de gewenste tabellen en laadt deze in Excel
* U kunt nu aan de slag.

{{VALUECARE}}

Routine Outcome Monitoring (ROM)

2022-09-23T12:03:50Z

Cbruin:

{{VALUECARE}}
== Inleiding ==
Deze pagina dient als naslagwerk om de managementrapportages op de Routine Outcome Monitoring (ROM) te interpreteren en gebruiken.

De doelen van managementrapportage inzake ROM betreft het bieden van inzicht in:

* De (tijdige) inzet van ROM instrumenten op de juiste momenten
* De effecten van de ingezette behandeling

Op deze pagina is een overzicht van definities te vinden, gevolgd door een toelichting op de totstandkoming. De relevante toepassing van de ROM wordt als laatste uitgelicht.

== Definities ==
Hieronder staan alle relevante termen met betrekking tot de ROM gedefinieerd en waar relevant extra toegelicht.
{| class="wikitable"
|+
!Term
!Definitie
!Toelichting
|-
|Voor- en nametingen
|De voor- en nametingen vormen de kapstok voor het bepalen of er een geldige ROM voormetingen dan wel nametingen uitgevoerd is voor het ZPM zorgtraject. Voor andere financieringsstromen geschiedt dit voor de daarvoor leidende zorgproducten (bijvoorbeeld een jeugdproduct). Daarnaast wordt per meting de T-score bepaald, zodat het effect kan worden gemeten door de T-score van de nameting te vergelijken met de voormeting.
| nvt
|-
|Voormeting
|Het eerste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de voormeting. Hierop is een (instelbare) marge in dagen van toepassing om als geldige voormeting te tellen.
| nvt
|-
|Nameting
|Het laatste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de nameting. Ook hierop is een (instelbare) marge in dagen van toepassing om als geldige nameting te tellen.
|De nameting van het voorgaande zorgtraject mag gezien worden als voormeting van het nieuwe traject, indien het voldoen aan de eisen:

* Marge in dagen t.o.v. eerste behandelcontact in nieuwe zorgtraject

* Vragenlijst wordt gebruikt binnen de diagnose hoofdgroep

Notes:

* Als er nog geen einddatum is bepaald voor een reeks, verwachten we dat er nog behandelcontacten gaan volgen. In dit geval bepalen we wel een laatste (ofwel meest recente) behandelcontact, maar valideren we nog niet of er een geldige nameting is geweest.
* Als er een verwachte einddatum (in de toekomst) is ingevuld voor een reeks, dan kijken we voor een valide nameting binnen het tijdsinterval rondom de einddatum van de reeks
* Als de einddatum van een zorgtraject reeds voorbij is, dan kijken we naar het laatste (ofwel meest recente) behandelcontact
|-
|Tussenmetingen
|Voor mensen die langdurig in zorg zijn (en hetzelfde zorgtraject hebben) zijn regelmatigere tussentijdse metingen van ROM is wenselijk. Het gewenste tijdsinterval verschilt per instelling, daarom is een tijdsinterval in te stellen. Voor informatie over het instelbare tijdsinterval, zie ''Tijdsinterval''.
|
|-
|Valide meting
|Een valide meting is een meting die:

* is aangemerkt als ROM
* volledig is ingevuld
* Als de diagnosegroep van het zorgtraject gevuld is, wordt met Beheer BI: Vragenlijst per diagnose bepaald of de vragenlijst in aanmerking komt voor de diagnose hoofdgroep.
** Indien de diagnosegroep leeg is, tonen we op dit moment geen meetmomenten in de dataset.
|[[Bestand:ROM validemeting.jpg|gecentreerd|300x300px]]
|-
|Tijdsinterval
|Hiermee wordt gedoeld op de gewenste tijd tussen ROM metingen. Zie ook definitie ''tussenmetingen''. De tijdsinterval is door de instelling zelf in te stellen. De tijdsinterval kan verschillen per type vragenlijst en diagnose en kan ingesteld worden via de beheertabel Beheer BI: Vragenlijst per diagnose
|<code>Stuurinformatie > Beheer BI > Beheer BI: Vragenlijst per diagnose</code>
|-
|Meetmoment
|Indien er geen meting plaatsvindt binnen het ingestelde tijdsinterval, wordt er een meetmoment aangemaakt. Dit is dus een moment waarop er een meting verwacht werd, maar deze niet is gedaan.
|Zie ook "Totstandkoming - Stappenplan - stap 3: Nummering metingen" hieronder.
|-
|Initiële meting
|Dit is de eerste valide meting binnen een reeks. De initiële meting is nodig als aanvulling op de voormeting voor de gevallen waarin de voormeting gegenereerd is (en dus geen valide meting is). In deze gevallen is de initiële meting de eerste valide meting binnen een reeks.
|Zie ook "Toepassing - (Delta) t-score" hieronder.
|-
|Reeks
|Alle meetmomenten binnen een zorgtraject in combinatie met de DBC’s.

Binnen één reeks moeten de onderstaande aspecten overeenkomen. Komen deze aspecten niet overeen, dan geldt dat als een andere reeks.

*'''Inschrijving (en daarmee ook cliënt)'''
** Als een inschrijving eindigt, eindigt de reeks

*'''Diagnose '''
** Is er een nieuwe diagnose gesteld is, eindigt de reeks
*'''Zorgtraject / DBC '''
** Als er een nieuw zorgtraject is, eindigt de reeks
*'''Vragenlijst type respondent (cliënt of behandelaar) '''
** Enkel voor reeksen met één of meer geldige metingen
** Als er een andere type respondent is, dan is dat een andere reeks

*'''(Optioneel) vragenlijst code'''
** Instelbaar
** Enkel voor reeksen met één of meer geldige metingen
** Mits parameter = ‘JA’: dan geldt dat voor een andere vragenlijst-code een andere reeks wordt gemaakt
** Mits parameter = ‘Nee’: dan geldt dat voor een andere vragenlijst-code dezelfde reeks wordt gebruikt
|[[Bestand:ROM reeks.jpg|gecentreerd|392x392px]]
|-
|(Delta)-T score
|De T-score is een uniforme maat om de diverse vragenlijsten naar scores te transformeren en loopt van 0-100. Een succesvolle behandeling zorgt voor een lagere nametingen dan de voormeting (behalve bij het meetinstrument MANSA-16). De Delta-T score is het verschil in T score tussen twee T scores.

Zie voor interpretatie van de Delta T-score de tabel onder "Toepassing - interpretatie delta T-score"
|
|}

== Totstandkoming ==

=== Stappenplan ===
Hieronder is het stappenplan uitgewerkt dat gevolgd wordt om de berekeningen voor de ROM te maken.

Per stap is toelichting gegeven en zo nodig een extra visualisatie toegevoegd.
{| class="wikitable"
|+
!Stap
!Toelichting
!
|-
|0: Bepalen behandelingen reeks
|Eerst wordt bepaald naar welke behandelingen we moeten kijken om de uitersten van reeks te kunnen bepalen.

* Mits het ZPM zorgtraject is aangemaakt met zorglabel N02 (''Overgang oude bekostiging met direct tijd naar Zorgprestatiemodel''), wordt de voormeting bepaald op basis van de voorafgaande DBC(s). De DBCs die worden meegenomen bij de betreffende zorgtrajecten, zijn DBCs die dezelfde (1) diagnose en (2) inschrijvingsnummer hebben als het zorgtraject.

* Voor de combinatie van de zorgtrajecten met eventuele DBCs (en losse DBCs) kijken we naar alle behandelcontacten met directe tijd.
** Voor een dergelijke reeks moeten we het eerste/laatste behandelcontact bepalen.
|[[Bestand:Stap 0 ROM .png|gecentreerd|miniatuur|800x800px]]
|-
|1: Bepalen uitersten van reeks
|Als er bepaald is welke behandelingen in een reeks vallen, wordt er per reeks bepaald:

* Het eerste behandelcontact
* Het laatste behandelcontact

LET OP

Er moet directe tijd zijn geschreven op het behandelcontact en er moet een diagnose bekend zijn voor de reeks. De diagnose is nodig om te bepalen of een eventuele ROM-meting met een vragenlijst is afgenomen die geldig is bij die specifieke diagnose
|[[Bestand:ROMstap1 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|-
|2: Bepalen valide metingen
|Dan wordt er gekeken of er binnen de vastgestelde uiterste waarden van een reeks, valide metingen te vinden zijn.

* Mits er een valide meting te vinden is, dan worden de facetten inschrijving (en daarmee cliënt), diagnose, zorgtraject / dbcs, vragenlijst type respondent, en (optioneel) vragenlijst code meegenomen in de reeks.

* Mits er geen valide meting te vinden is, dan is een reeks enkel bepaald op basis van de inschrijving, diagnose, en het zorgtraject. In dit geval zullen er dan ook geen geldige metingen te tonen zijn in de dataset. Er worden wel twee meetmomenten gegenereerd, namelijk het verwachte voormeetmoment en het verwachte nameetmoment.
|[[Bestand:ValueCare - ROM (1).png|gecentreerd|miniatuur|800x800px]]
|-
|3:Nummering metingen
|We nummeren de opvolgende metingen binnen een reeks op basis van de datum van afname.
Hierdoor kunnen we de opvolgende metingen makkelijk koppelen.

Met behulp van het tijdsinterval per type vragenlijst en diagnose, kunnen we bepalen of de opvolgende metingen plaats hebben gevonden binnen het tijdsinterval (t.o.v. de vorige meting), waarbinnen ze worden verwacht.
{| class="wikitable"
|+
!Optie
! colspan="2" |Situatie
!Gevolg
|-
|A
| colspan="2" |De volgende meting valt binnen tijdsinterval
|De volgende meting is een valide meting. Let op: alle valide metingen moeten voldoen aan de criteria gedefinieerd in stap 2.
|-
|B
| colspan="2" |De volgende meting valt buiten tijdsinterval
|Genereren meetmoment (dus geen valide meting). Dit meetmoment moet duidelijk maken aan instellingen dat er een meting verwacht wordt, maar deze meting niet (valide of volledig) is afgenomen.
|-
|C
| rowspan="2" |Geen volgende meting
|Laatste behandelcontact is in het verleden geweest
|Genereren meetmomenten tot en met het laatste behandelcontact.
|-
|D
|Laatste behandelcontact wordt in de toekomst verwacht
|Genereren meetmomenten tot en met de aanleverdatum + 1 x tijdsinterval.
Er zal dus voor alle reeksen die doorlopen naar de toekomst, één meetmoment aangemaakt worden, die in de toekomst ligt.
|}
|[[Bestand:ROMstap3 nieuw 3.jpg|alt=|gecentreerd|miniatuur|1300x1300px]]
|-
|4: Bepalen voor- en nameting
|Het bepalen van de voor- en nametingen:

De metingen die binnen een reeks het dichtste bij het eerste/laatste behandelcontact liggen worden bestempeld als voor- of nameting.

Indien er enkel een voormeting of een nameting is en niet beide, dan genereren we een meetmoment voor de missende voor- of nameting, met als datum het eerste/laatste behandelcontact.

* Mits er een valide meting heeft plaatsgevonden in de reeks, bepalen we de marge op basis van het tijdsinterval dat geldt voor het type vragenlijst en de gestelde diagnose.

* Mits er geen valide meting heeft plaatsgevonden in de reeks, bepalen we de marge op basis van de BI parameter ''GGZBI_TIJDSINTERVAL_ROM_MEETMOMENTEN_ONAFHANKELIJK_VAN_TYPE''.
* Optioneel: Instelbaar
** Mits er voor een reeks meerdere type vragenlijst worden gebruikt (bijv. zowel Honos-12 als SQ48) dan wordt er voor elk type vragenlijst een aparte reeks aangemaakt. Binnen deze aparte reeksen wordt dan ook weer bepaald of er een valide voor- en/of nameting was.
|[[Bestand:ROMstap4 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|}

=== Gebruikte beheertabellen en parameters ===
Hieronder zijn de parameters en beheertabellen met relevante toelichting te vinden. De dataset die voor de ROM gebruikt wordt is <code>ROM meetmomenten.</code>
{| class="wikitable"
|+
!Parameters
!Toelichting
|-
|BI_MARGE_RONDOM_EERSTE_BEHANDELCONTACT_VOORMETING
|Bandbreedte in dagen rondom eerste behandelcontact zorgtraject waarbinnen een geldige voormeting afgenomen moet zijn
|-
|BI_MARGE_RONDOM_LAATSTE_BEHANDELCONTACT_NAMETING
|Bandbreedte in dagen rondom laatste behandelcontact zorgtraject waarbinnen een geldige nameting afgenomen moet zijn
|-
|GGZBI_TUSSENMETINGEN_ZELFDE_TYPE_VRAGENLIJST
|Of een reeks rekening moet houden met aparte vragenlijst_codes of niet.

Mits parameter = JA, genereren we voor elke verschillende vragenlijst-code binnen een reeks, een nieuwe reeks

Mits parameter = NEE, mogen de vragenlijsten onafhankelijk van elkaar afgenomen zijn

''NOTE: deze parameter wil ik nog hernoemen naar GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST''
|-
|''GGZBI_TIJDSINTERVAL_ROM_MEETMOMENTEN_ONAFHANKELIJK_VAN_TYPE''
|Het tijdsinterval dat gebruikt wordt voor reeksen, waarbij geen tijdsinterval bepaald is in de beheertabel 'Beheer BI: Vragenlijst per diagnose'
|}
{| class="wikitable"
|+
!Beheertabel
!Toelichting
|-
|Beheer BI: Vragenlijst per diagnose
|Per diagnosehoofdgroep kan het gebruikte ROM-instrument aangegeven worden.
In deze beheertabel kan ook het interval per type vragenlijst en diagnose ingesteld worden. (NIEUW!)
|-
|Beheer BI: Vragenlijst
|Per vragenlijst kan worden aangegeven of deze wordt gebruikt als ROM- en/of CQI-instrument
|-
|Beheer BI: Parameters
|Voor het instellen van o.a. de hierboven genoemde parameters.
|}

== Toepassing ==

In dit deel worden de toepassingen toegelicht, deze toepassingen zijn gericht op het behalen van de doelen van de managementrapportage inzake ROM zoals beschreven in de inleiding van deze pagina.

=== Beheertabel ===

Zoals hierboven al vaker aangegeven zijn er een aantal dingen instelbaar via beheertabellen. Zie ook het overzicht van beheertabellen hierboven.

De instellingen van deze beheertabellen hebben invloed om de onderstaande toepassingen en dienen dus correct ingevuld te zijn om de toepassing zo nuttig en accuraat mogelijk te laten zijn.

=== (Delta) t-score ===
De instellingen vinden het vooral belangrijk om de t-scores te weten die bij een ROM meting hoorde. Daarnaast willen ze de delta t-score weten, zodat ze kunnen zien of een cliënt verbeterd of juist verslechterd in de loop der tijd.

Voor een gegenereerd meetmoment hebben we geen t-score. Daardoor kunnen we enkel t-scores vergelijken van valide metingen. We tonen in dataset ROM meetmomenten daarom enkel delta t-scores voor valide metingen ten opzichte van valide metingen. Dit houdt ook in dat voor gegenereerde voormeetmomenten, we geen delta t-score ten opzichte van de voormeting kunnen doen. Om dit te voorkomen, hebben we de ‘initiële meting’ geïntroduceerd. Dit is de eerste valide meting binnen een reeks. We hebben op deze manier dus twee type delta t-scores in de dataset: (1) delta t-score t.o.v. de vorige valide meting, (2) delta t-score t.o.v. de initiële meting.

[[Bestand:Deltat nieuw.jpg|alt=|gecentreerd|miniatuur|800x800px]]

==== Interpretatie Delta T-score ====
Zie de tabel hieronder voor de interpretatie van de Delta T-score:
{| class="wikitable"
|+
!Code
!Classificatie
!Delta T-score
|-
|1
|Hersteld
|> 5 <code>AND</code> voormeting t > 42,5 <code>AND</code> nameting t < 42,5
|-
|2
|Verbeterd
|> 5
|-
|3
|Onveranderd
| -5 < delta t < 5
|-
|4
|Verslechterd
|< -5
|}

=== KPI's en dashboards ===
Voor de ROM biedt ValueCare verschillende dashboards in het portaal.

Deze zijn te vinden onder <code>Meer dashboards > ROM > ROM - Delta t-score</code> en <code>Meer dashboards > ROM > ROM - Proces valide metingen</code>.

Zie hieronder een overzicht:
{| class="wikitable"
|+
!Dashboard
!Tegel
!Toelichting
|-
| rowspan="4" |Delta t-score
|Delta T-score ROM per maand
| rowspan="4" |Delta-T wordt per patient/behandeling berekend als de verschilscore tussen de vorige meting en huidige meting.
|-
|Delta T-score ROM per organisatieniveau
|-
|Delta T-score ROM per soort vragenlijst
|-
|Delta T-score ROM per RCI
|-
| rowspan="4" |Proces valide metingen
|Valide ROM metingen per maand
| rowspan="4" |De rapportage toont het aantal valide metingen. De rapportagedatum is gelijk aan de datum waarop de meting is afgenomen of anders de uiterlijke datum waarop de meting verwacht wordt.
|-
|Valide ROM metingen per organisatieniveau
|-
|Valide ROM metingen per soort vragenlijst
|-
|Valide ROM metingen per soort meetmoment
|-
| rowspan="4" |Effectmeting
|ROM RCI score per maand
|Alle RCI waarden van diverse meetinstrumenten zoals IDS-SR, HoNOS65, etc. gegroepeerd per dbc sluitdatum (einddatum DBC)

Deze rapportage laat de gemiddelde ROM Deltra-t score zien.
|-
|ROM HoNOS65 subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 11 vragen uit de HoNOS65 vragenlijst.
|-
|ROM RCI score per diagnosegroep
|Deze rapportage laat de ROM RCI score zien per diagnosegroep. In de tabel onder de grafiek is meer verdiepende data te vinden. Deze rapportage laat de gemiddelde ROM Delta-T score zien.
|-
|ROM CANSAS subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 25 vragen uit de CANVAS vragenlijst.

Proportie cliënten met onopgeloste zorgbehoeften is het percentage cliënten dat minimaal 1 heeft gescoord op de subschaal "onopgeloste zorgbehoeften" tov het totaal aantal cliënten.
|-
| rowspan="4" |Effectmeting Delta t-score
|ROM Delta-T score per maand
|Rapportage: gemiddelde ROM Delta-T score per maand.
|-
|ROM Delta-T score per org. niv.
|Rapportage: gemiddelde ROM Delta-T score per organisatie niveau.
|-
|ROM Delta-T score per diagnosegroep
|Rapportage: gemiddelde Delta-T score per diagnosegroep.
|-
|ROM Delta-T score per jaar
|Rapportage: gemiddelde Delta-T score per jaar.
|}
{{VALUECARE}}

Routine Outcome Monitoring (ROM)

2022-09-23T12:01:11Z

Cbruin:

{{VALUECARE}}
== Inleiding ==
Deze pagina dient als naslagwerk om de managementrapportages op de Routine Outcome Monitoring (ROM) te interpreteren en gebruiken.

De doelen van managementrapportage inzake ROM betreft het bieden van inzicht in:

* De (tijdige) inzet van ROM instrumenten op de juiste momenten
* De effecten van de ingezette behandeling

Op deze pagina is een overzicht van definities te vinden, gevolgd door een toelichting op de totstandkoming. De relevante toepassing van de ROM wordt als laatste uitgelicht.

== Definities ==
Hieronder staan alle relevante termen met betrekking tot de ROM gedefinieerd en waar relevant extra toegelicht.
{| class="wikitable"
|+
!Term
!Definitie
!Toelichting
|-
|Voor- en nametingen
|De voor- en nametingen vormen de kapstok voor het bepalen of er een geldige ROM voormetingen dan wel nametingen uitgevoerd is voor het ZPM zorgtraject. Voor andere financieringsstromen geschiedt dit voor de daarvoor leidende zorgproducten (bijvoorbeeld een jeugdproduct). Daarnaast wordt per meting de T-score bepaald, zodat het effect kan worden gemeten door de T-score van de nameting te vergelijken met de voormeting.
| nvt
|-
|Voormeting
|Het eerste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de voormeting. Hierop is een (instelbare) marge in dagen van toepassing om als geldige voormeting te tellen.
| nvt
|-
|Nameting
|Het laatste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de nameting. Ook hierop is een (instelbare) marge in dagen van toepassing om als geldige nameting te tellen.
|De nameting van het voorgaande zorgtraject mag gezien worden als voormeting van het nieuwe traject, indien het voldoen aan de eisen:

* Marge in dagen t.o.v. eerste behandelcontact in nieuwe zorgtraject

* Vragenlijst wordt gebruikt binnen de diagnose hoofdgroep

Notes:

* Als er nog geen einddatum is bepaald voor een reeks, verwachten we dat er nog behandelcontacten gaan volgen. In dit geval bepalen we wel een laatste (ofwel meest recente) behandelcontact, maar valideren we nog niet of er een geldige nameting is geweest.
* Als er een verwachte einddatum (in de toekomst) is ingevuld voor een reeks, dan kijken we voor een valide nameting binnen het tijdsinterval rondom de einddatum van de reeks
* Als de einddatum van een zorgtraject reeds voorbij is, dan kijken we naar het laatste (ofwel meest recente) behandelcontact
|-
|Tussenmetingen
|Voor mensen die langdurig in zorg zijn (en hetzelfde zorgtraject hebben) zijn regelmatigere tussentijdse metingen van ROM is wenselijk. Het gewenste tijdsinterval verschilt per instelling, daarom is een tijdsinterval in te stellen. Voor informatie over het instelbare tijdsinterval, zie ''Tijdsinterval''.
|
|-
|Valide meting
|Een valide meting is een meting die:

* is aangemerkt als ROM
* volledig is ingevuld
* Als de diagnosegroep van het zorgtraject gevuld is, wordt met Beheer BI: Vragenlijst per diagnose bepaald of de vragenlijst in aanmerking komt voor de diagnose hoofdgroep.
** Indien de diagnosegroep leeg is, tonen we op dit moment geen meetmomenten in de dataset.
|[[Bestand:ROM validemeting.jpg|gecentreerd|300x300px]]
|-
|Tijdsinterval
|Hiermee wordt gedoeld op de gewenste tijd tussen ROM metingen. Zie ook definitie ''tussenmetingen''. De tijdsinterval is door de instelling zelf in te stellen. De tijdsinterval kan verschillen per type vragenlijst en diagnose en kan ingesteld worden via de beheertabel Beheer BI: Vragenlijst per diagnose
|<code>Stuurinformatie > Beheer BI > Beheer BI: Vragenlijst per diagnose</code>
|-
|Meetmoment
|Indien er geen meting plaatsvindt binnen het ingestelde tijdsinterval, wordt er een meetmoment aangemaakt. Dit is dus een moment waarop er een meting verwacht werd, maar deze niet is gedaan.
|Zie ook "Totstandkoming - Stappenplan - stap 3: Nummering metingen" hieronder.
|-
|Initiële meting
|Dit is de eerste valide meting binnen een reeks. De initiële meting is nodig als aanvulling op de voormeting voor de gevallen waarin de voormeting gegenereerd is (en dus geen valide meting is). In deze gevallen is de initiële meting de eerste valide meting binnen een reeks.
|Zie ook "Toepassing - (Delta) t-score" hieronder.
|-
|Reeks
|Alle meetmomenten binnen een zorgtraject in combinatie met de DBC’s.

Binnen één reeks moeten de onderstaande aspecten overeenkomen. Komen deze aspecten niet overeen, dan geldt dat als een andere reeks.

*'''Inschrijving (en daarmee ook cliënt)'''
** Als een inschrijving eindigt, eindigt de reeks

*'''Diagnose '''
** Is er een nieuwe diagnose gesteld is, eindigt de reeks
*'''Zorgtraject / DBC '''
** Als er een nieuw zorgtraject is, eindigt de reeks
*'''Vragenlijst type respondent (cliënt of behandelaar) '''
** Enkel voor reeksen met één of meer geldige metingen
** Als er een andere type respondent is, dan is dat een andere reeks

*'''(Optioneel) vragenlijst code'''
** Instelbaar
** Enkel voor reeksen met één of meer geldige metingen
** Mits parameter = ‘JA’: dan geldt dat voor een andere vragenlijst-code een andere reeks wordt gemaakt
** Mits parameter = ‘Nee’: dan geldt dat voor een andere vragenlijst-code dezelfde reeks wordt gebruikt
|[[Bestand:ROM reeks.jpg|gecentreerd|392x392px]]
|-
|(Delta)-T score
|De T-score is een uniforme maat om de diverse vragenlijsten naar scores te transformeren en loopt van 0-100. Een succesvolle behandeling zorgt voor een lagere nametingen dan de voormeting (behalve bij het meetinstrument MANSA-16). De Delta-T score is het verschil in T score tussen twee T scores.

Zie voor interpretatie van de Delta T-score de tabel onder "Toepassing - interpretatie delta T-score"
|
|}

== Totstandkoming ==

=== Stappenplan ===
Hieronder is het stappenplan uitgewerkt dat gevolgd wordt om de berekeningen voor de ROM te maken.

Per stap is toelichting gegeven en zo nodig een extra visualisatie toegevoegd.
{| class="wikitable"
|+
!Stap
!Toelichting
!
|-
|0: Bepalen behandelingen reeks
|Eerst wordt bepaald naar welke behandelingen we moeten kijken om de uitersten van reeks te kunnen bepalen.

* Mits het ZPM zorgtraject is aangemaakt met zorglabel N02 (''Overgang oude bekostiging met direct tijd naar Zorgprestatiemodel''), wordt de voormeting bepaald op basis van de voorafgaande DBC(s). De DBCs die worden meegenomen bij de betreffende zorgtrajecten, zijn DBCs die dezelfde (1) diagnose en (2) inschrijvingsnummer hebben als het zorgtraject.

* Voor de combinatie van de zorgtrajecten met eventuele DBCs (en losse DBCs) kijken we naar alle behandelcontacten met directe tijd.
** Voor een dergelijke reeks moeten we het eerste/laatste behandelcontact bepalen.
|[[Bestand:Stap 0 ROM .png|gecentreerd|miniatuur|800x800px]]
|-
|1: Bepalen uitersten van reeks
|Als er bepaald is welke behandelingen in een reeks vallen, wordt er per reeks bepaald:

* Het eerste behandelcontact
* Het laatste behandelcontact

LET OP

Er moet directe tijd zijn geschreven op het behandelcontact en er moet een diagnose bekend zijn voor de reeks. De diagnose is nodig om te bepalen of een eventuele ROM-meting met een vragenlijst is afgenomen die geldig is bij die specifieke diagnose
|[[Bestand:ROMstap1 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|-
|2: Bepalen valide metingen
|Dan wordt er gekeken of er binnen de vastgestelde uiterste waarden van een reeks, valide metingen te vinden zijn.

* Mits er een valide meting te vinden is, dan worden de facetten inschrijving (en daarmee cliënt), diagnose, zorgtraject / dbcs, vragenlijst type respondent, en (optioneel) vragenlijst code meegenomen in de reeks.

* Mits er geen valide meting te vinden is, dan is een reeks enkel bepaald op basis van de inschrijving, diagnose, en het zorgtraject. In dit geval zullen er dan ook geen geldige metingen te tonen zijn in de dataset. Er worden wel twee meetmomenten gegenereerd, namelijk het verwachte voormeetmoment en het verwachte nameetmoment.
|[[Bestand:ValueCare - ROM (1).png|gecentreerd|miniatuur|800x800px]]
|-
|3:Nummering metingen
|We nummeren de opvolgende metingen binnen een reeks op basis van de datum van afname.
Hierdoor kunnen we de opvolgende metingen makkelijk koppelen.

Met behulp van het tijdsinterval per type vragenlijst en diagnose, kunnen we bepalen of de opvolgende metingen plaats hebben gevonden binnen het tijdsinterval (t.o.v. de vorige meting), waarbinnen ze worden verwacht.
{| class="wikitable"
|+
!Optie
! colspan="2" |Situatie
!Gevolg
|-
|A
| colspan="2" |De volgende meting valt binnen tijdsinterval
|De volgende meting is een valide meting. Let op: alle valide metingen moeten voldoen aan de criteria gedefinieerd in stap 2.
|-
|B
| colspan="2" |De volgende meting valt buiten tijdsinterval
|Genereren meetmoment (dus geen valide meting). Dit meetmoment moet duidelijk maken aan instellingen dat er een meting verwacht wordt, maar deze meting niet (valide of volledig) is afgenomen.
|-
|C
| rowspan="2" |Geen volgende meting
|Laatste behandelcontact is in het verleden geweest
|Genereren meetmomenten tot en met het laatste behandelcontact.
|-
|D
|Laatste behandelcontact wordt in de toekomst verwacht
|Genereren meetmomenten tot en met de aanleverdatum + 1 x tijdsinterval.
Er zal dus voor alle reeksen die doorlopen naar de toekomst, één meetmoment aangemaakt worden, die in de toekomst ligt.
|}
|[[Bestand:ROMstap3 nieuw 3.jpg|alt=|gecentreerd|miniatuur|1300x1300px]]
|-
|4: Bepalen voor- en nameting
|Het bepalen van de voor- en nametingen:

De metingen die binnen een reeks het dichtste bij het eerste/laatste behandelcontact liggen worden bestempeld als voor- of nameting.

Indien er enkel een voormeting of een nameting is en niet beide, dan genereren we een meetmoment voor de missende voor- of nameting, met als datum het eerste/laatste behandelcontact.

* Mits er een valide meting heeft plaatsgevonden in de reeks, bepalen we de marge op basis van het tijdsinterval dat geldt voor het type vragenlijst en de gestelde diagnose.

* Mits er geen valide meting heeft plaatsgevonden in de reeks, bepalen we de marge op basis van de BI parameter ''GGZBI_TIJDSINTERVAL_ROM_MEETMOMENTEN_ONAFHANKELIJK_VAN_TYPE''.
* Optioneel: Instelbaar
** Mits er voor een reeks meerdere type vragenlijst worden gebruikt (bijv. zowel Honos-12 als SQ48) dan wordt er voor elk type vragenlijst een aparte reeks aangemaakt. Binnen deze aparte reeksen wordt dan ook weer bepaald of er een valide voor- en/of nameting was.
|[[Bestand:ROMstap4 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|}

=== Gebruikte beheertabellen en parameters ===
Hieronder zijn de parameters en beheertabellen met relevante toelichting te vinden. De dataset die voor de ROM gebruikt wordt is <code>ROM meetmomenten.</code>
{| class="wikitable"
|+
!Parameters
!Toelichting
|-
|BI_MARGE_RONDOM_EERSTE_BEHANDELCONTACT_VOORMETING
|Bandbreedte in dagen rondom eerste behandelcontact zorgtraject waarbinnen een geldige voormeting afgenomen moet zijn
|-
|BI_MARGE_RONDOM_LAATSTE_BEHANDELCONTACT_NAMETING
|Bandbreedte in dagen rondom laatste behandelcontact zorgtraject waarbinnen een geldige nameting afgenomen moet zijn
|-
|BI_INTERVAL_TUSSENMETINGEN_ZORGTRAJECT
|Interval dat bepaalt hoeveel dagen na de vorige meting binnen het zorgtraject een tussenmeting afgenomen moet zijn
|-
|BI_MARGE_TUSSENMETING
|Bandbreedte in dagen rondom het tijdstip bepaald in ''BI_INTERVAL_TUSSENMETINGEN_ZORGTRAJECT'' waarbinnen een geldige tussenmeting afgenomen moet zijn
|-
|GGZBI_TUSSENMETINGEN_ZELFDE_TYPE_VRAGENLIJST
|Of een reeks rekening moet houden met aparte vragenlijst_codes of niet.

Mits parameter = JA, genereren we voor elke verschillende vragenlijst-code binnen een reeks, een nieuwe reeks

Mits parameter = NEE, mogen de vragenlijsten onafhankelijk van elkaar afgenomen zijn

''NOTE: deze parameter wil ik nog hernoemen naar GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST''
|}
{| class="wikitable"
|+
!Beheertabel
!Toelichting
|-
|Beheer BI: Vragenlijst per diagnose
|Per diagnosehoofdgroep kan het gebruikte ROM-instrument aangegeven worden.
In deze beheertabel kan ook het interval per type vragenlijst en diagnose ingesteld worden. (NIEUW!)
|-
|Beheer BI: Vragenlijst
|Per vragenlijst kan worden aangegeven of deze wordt gebruikt als ROM- en/of CQI-instrument
|-
|Beheer BI: Parameters
|Voor het instellen van o.a. de hierboven genoemde parameters.
|}

== Toepassing ==

In dit deel worden de toepassingen toegelicht, deze toepassingen zijn gericht op het behalen van de doelen van de managementrapportage inzake ROM zoals beschreven in de inleiding van deze pagina.

=== Beheertabel ===

Zoals hierboven al vaker aangegeven zijn er een aantal dingen instelbaar via beheertabellen. Zie ook het overzicht van beheertabellen hierboven.

De instellingen van deze beheertabellen hebben invloed om de onderstaande toepassingen en dienen dus correct ingevuld te zijn om de toepassing zo nuttig en accuraat mogelijk te laten zijn.

=== (Delta) t-score ===
De instellingen vinden het vooral belangrijk om de t-scores te weten die bij een ROM meting hoorde. Daarnaast willen ze de delta t-score weten, zodat ze kunnen zien of een cliënt verbeterd of juist verslechterd in de loop der tijd.

Voor een gegenereerd meetmoment hebben we geen t-score. Daardoor kunnen we enkel t-scores vergelijken van valide metingen. We tonen in dataset ROM meetmomenten daarom enkel delta t-scores voor valide metingen ten opzichte van valide metingen. Dit houdt ook in dat voor gegenereerde voormeetmomenten, we geen delta t-score ten opzichte van de voormeting kunnen doen. Om dit te voorkomen, hebben we de ‘initiële meting’ geïntroduceerd. Dit is de eerste valide meting binnen een reeks. We hebben op deze manier dus twee type delta t-scores in de dataset: (1) delta t-score t.o.v. de vorige valide meting, (2) delta t-score t.o.v. de initiële meting.

[[Bestand:Deltat nieuw.jpg|alt=|gecentreerd|miniatuur|800x800px]]

==== Interpretatie Delta T-score ====
Zie de tabel hieronder voor de interpretatie van de Delta T-score:
{| class="wikitable"
|+
!Code
!Classificatie
!Delta T-score
|-
|1
|Hersteld
|> 5 <code>AND</code> voormeting t > 42,5 <code>AND</code> nameting t < 42,5
|-
|2
|Verbeterd
|> 5
|-
|3
|Onveranderd
| -5 < delta t < 5
|-
|4
|Verslechterd
|< -5
|}

=== KPI's en dashboards ===
Voor de ROM biedt ValueCare verschillende dashboards in het portaal.

Deze zijn te vinden onder <code>Meer dashboards > ROM > ROM - Delta t-score</code> en <code>Meer dashboards > ROM > ROM - Proces valide metingen</code>.

Zie hieronder een overzicht:
{| class="wikitable"
|+
!Dashboard
!Tegel
!Toelichting
|-
| rowspan="4" |Delta t-score
|Delta T-score ROM per maand
| rowspan="4" |Delta-T wordt per patient/behandeling berekend als de verschilscore tussen de vorige meting en huidige meting.
|-
|Delta T-score ROM per organisatieniveau
|-
|Delta T-score ROM per soort vragenlijst
|-
|Delta T-score ROM per RCI
|-
| rowspan="4" |Proces valide metingen
|Valide ROM metingen per maand
| rowspan="4" |De rapportage toont het aantal valide metingen. De rapportagedatum is gelijk aan de datum waarop de meting is afgenomen of anders de uiterlijke datum waarop de meting verwacht wordt.
|-
|Valide ROM metingen per organisatieniveau
|-
|Valide ROM metingen per soort vragenlijst
|-
|Valide ROM metingen per soort meetmoment
|-
| rowspan="4" |Effectmeting
|ROM RCI score per maand
|Alle RCI waarden van diverse meetinstrumenten zoals IDS-SR, HoNOS65, etc. gegroepeerd per dbc sluitdatum (einddatum DBC)

Deze rapportage laat de gemiddelde ROM Deltra-t score zien.
|-
|ROM HoNOS65 subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 11 vragen uit de HoNOS65 vragenlijst.
|-
|ROM RCI score per diagnosegroep
|Deze rapportage laat de ROM RCI score zien per diagnosegroep. In de tabel onder de grafiek is meer verdiepende data te vinden. Deze rapportage laat de gemiddelde ROM Delta-T score zien.
|-
|ROM CANSAS subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 25 vragen uit de CANVAS vragenlijst.

Proportie cliënten met onopgeloste zorgbehoeften is het percentage cliënten dat minimaal 1 heeft gescoord op de subschaal "onopgeloste zorgbehoeften" tov het totaal aantal cliënten.
|-
| rowspan="4" |Effectmeting Delta t-score
|ROM Delta-T score per maand
|Rapportage: gemiddelde ROM Delta-T score per maand.
|-
|ROM Delta-T score per org. niv.
|Rapportage: gemiddelde ROM Delta-T score per organisatie niveau.
|-
|ROM Delta-T score per diagnosegroep
|Rapportage: gemiddelde Delta-T score per diagnosegroep.
|-
|ROM Delta-T score per jaar
|Rapportage: gemiddelde Delta-T score per jaar.
|}
{{VALUECARE}}

Routine Outcome Monitoring (ROM)

2022-09-23T08:31:30Z

Cbruin: Kleine aanpassing

{{VALUECARE}}
== Inleiding ==
Deze pagina dient als naslagwerk om de managementrapportages op de Routine Outcome Monitoring (ROM) te interpreteren en gebruiken.

De doelen van managementrapportage inzake ROM betreft het bieden van inzicht in:

* De (tijdige) inzet van ROM instrumenten op de juiste momenten
* De effecten van de ingezette behandeling

Op deze pagina is een overzicht van definities te vinden, gevolgd door een toelichting op de totstandkoming. De relevante toepassing van de ROM wordt als laatste uitgelicht.

== Definities ==
Hieronder staan alle relevante termen met betrekking tot de ROM gedefinieerd en waar relevant extra toegelicht.
{| class="wikitable"
|+
!Term
!Definitie
!Toelichting
|-
|Voor- en nametingen
|De voor- en nametingen vormen de kapstok voor het bepalen of er een geldige ROM voormetingen dan wel nametingen uitgevoerd is voor het ZPM zorgtraject. Voor andere financieringsstromen geschiedt dit voor de daarvoor leidende zorgproducten (bijvoorbeeld een jeugdproduct). Daarnaast wordt per meting de T-score bepaald, zodat het effect kan worden gemeten door de T-score van de nameting te vergelijken met de voormeting.
| nvt
|-
|Voormeting
|Het eerste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de voormeting. Hierop is een (instelbare) marge in dagen van toepassing om als geldige voormeting te tellen.
| nvt
|-
|Nameting
|Het laatste behandelcontact binnen het zorgtraject (of ander zorgproduct) is het ijkpunt voor de nameting. Ook hierop is een (instelbare) marge in dagen van toepassing om als geldige nameting te tellen.
|De nameting van het voorgaande zorgtraject mag gezien worden als voormeting van het nieuwe traject, indien het voldoen aan de eisen:

* Marge in dagen t.o.v. eerste behandelcontact in nieuwe zorgtraject

* Vragenlijst wordt gebruikt binnen de diagnose hoofdgroep

Notes:

* Als er nog geen einddatum is bepaald voor een reeks, verwachten we dat er nog behandelcontacten gaan volgen. In dit geval bepalen we wel een laatste (ofwel meest recente) behandelcontact, maar valideren we nog niet of er een geldige nameting is geweest.
* Als er een verwachte einddatum (in de toekomst) is ingevuld voor een reeks, dan kijken we voor een valide nameting binnen het tijdsinterval rondom de einddatum van de reeks
* Als de einddatum van een zorgtraject reeds voorbij is, dan kijken we naar het laatste (ofwel meest recente) behandelcontact
|-
|Tussenmetingen
|Voor mensen die langdurig in zorg zijn (en hetzelfde zorgtraject hebben) zijn regelmatigere tussentijdse metingen van ROM is wenselijk. Het gewenste tijdsinterval verschilt per instelling, daarom is een tijdsinterval in te stellen. Voor informatie over het instelbare tijdsinterval, zie ''Tijdsinterval''.
|
|-
|Valide meting
|Een valide meting is een meting die:

* is aangemerkt als ROM
* volledig is ingevuld
* Als de diagnosegroep van het zorgtraject gevuld is, wordt met Beheer BI: Vragenlijst per diagnose bepaald of de vragenlijst in aanmerking komt voor de diagnose hoofdgroep.
** Indien de diagnosegroep leeg is, tonen we op dit moment geen meetmomenten in de dataset.
|[[Bestand:ROM validemeting.jpg|gecentreerd|300x300px]]
|-
|Tijdsinterval
|Hiermee wordt gedoeld op de gewenste tijd tussen ROM metingen. Zie ook definitie ''tussenmetingen''. De tijdsinterval is door de instelling zelf in te stellen. De tijdsinterval kan verschillen per type vragenlijst en diagnose en kan ingesteld worden via de beheertabel Beheer BI: Vragenlijst per diagnose
|<code>Stuurinformatie > Beheer BI > Beheer BI: Vragenlijst per diagnose</code>
|-
|Meetmoment
|Indien er geen meting plaatsvindt binnen het ingestelde tijdsinterval, wordt er een meetmoment aangemaakt. Dit is dus een moment waarop er een meting verwacht werd, maar deze niet is gedaan.
|Zie ook "Totstandkoming - Stappenplan - stap 3: Nummering metingen" hieronder.
|-
|Initiële meting
|Dit is de eerste valide meting binnen een reeks. De initiële meting is nodig als aanvulling op de voormeting voor de gevallen waarin de voormeting gegenereerd is (en dus geen valide meting is). In deze gevallen is de initiële meting de eerste valide meting binnen een reeks.
|Zie ook "Toepassing - (Delta) t-score" hieronder.
|-
|Reeks
|Alle meetmomenten binnen een zorgtraject in combinatie met de DBC’s.

Binnen één reeks moeten de onderstaande aspecten overeenkomen. Komen deze aspecten niet overeen, dan geldt dat als een andere reeks.

*'''Inschrijving (en daarmee ook cliënt)'''
** Als een inschrijving eindigt, eindigt de reeks

*'''Diagnose '''
** Is er een nieuwe diagnose gesteld is, eindigt de reeks
*'''Zorgtraject / DBC '''
** Als er een nieuw zorgtraject is, eindigt de reeks
*'''Vragenlijst type respondent (cliënt of behandelaar) '''
** Enkel voor reeksen met één of meer geldige metingen
** Als er een andere type respondent is, dan is dat een andere reeks

*'''(Optioneel) vragenlijst code'''
** Instelbaar
** Enkel voor reeksen met één of meer geldige metingen
** Mits parameter = ‘JA’: dan geldt dat voor een andere vragenlijst-code een andere reeks wordt gemaakt
** Mits parameter = ‘Nee’: dan geldt dat voor een andere vragenlijst-code dezelfde reeks wordt gebruikt
|[[Bestand:ROM reeks.jpg|gecentreerd|392x392px]]
|-
|(Delta)-T score
|De T-score is een uniforme maat om de diverse vragenlijsten naar scores te transformeren en loopt van 0-100. Een succesvolle behandeling zorgt voor een lagere nametingen dan de voormeting (behalve bij het meetinstrument MANSA-16). De Delta-T score is het verschil in T score tussen twee T scores.

Zie voor interpretatie van de Delta T-score de tabel onder "Toepassing - interpretatie delta T-score"
|
|}

== Totstandkoming ==

=== Stappenplan ===
Hieronder is het stappenplan uitgewerkt dat gevolgd wordt om de berekeningen voor de ROM te maken.

Per stap is toelichting gegeven en zo nodig een extra visualisatie toegevoegd.
{| class="wikitable"
|+
!Stap
!Toelichting
!
|-
|0: Bepalen behandelingen reeks
|Eerst wordt bepaald naar welke behandelingen we moeten kijken om de uitersten van reeks te kunnen bepalen.

* Mits het ZPM zorgtraject is aangemaakt met zorglabel N02 (''Overgang oude bekostiging met direct tijd naar Zorgprestatiemodel''), wordt de voormeting bepaald op basis van de voorafgaande DBC(s). De DBCs die worden meegenomen bij de betreffende zorgtrajecten, zijn DBCs die dezelfde (1) diagnose en (2) inschrijvingsnummer hebben als het zorgtraject.

* Voor de combinatie van de zorgtrajecten met eventuele DBCs (en losse DBCs) kijken we naar alle behandelcontacten met directe tijd.
** Voor een dergelijke reeks moeten we het eerste/laatste behandelcontact bepalen.
|[[Bestand:Stap 0 ROM .png|gecentreerd|miniatuur|800x800px]]
|-
|1: Bepalen uitersten van reeks
|Als er bepaald is welke behandelingen in een reeks vallen, wordt er per reeks bepaald:

* Het eerste behandelcontact
* Het laatste behandelcontact

LET OP

Er moet directe tijd zijn geschreven op het behandelcontact en er moet een diagnose bekend zijn voor de reeks. De diagnose is nodig om te bepalen of een eventuele ROM-meting met een vragenlijst is afgenomen die geldig is bij die specifieke diagnose
|[[Bestand:ROMstap1 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|-
|2: Bepalen valide metingen
|Dan wordt er gekeken of er binnen de vastgestelde uiterste waarden van een reeks, valide metingen te vinden zijn.

* Mits er een valide meting te vinden is, dan worden de facetten inschrijving (en daarmee cliënt), diagnose, zorgtraject / dbcs, vragenlijst type respondent, en (optioneel) vragenlijst code meegenomen in de reeks.

* Mits er geen valide meting te vinden is, dan is een reeks enkel bepaald op basis van de inschrijving, diagnose, en het zorgtraject. In dit geval zullen er dan ook geen geldige metingen te tonen zijn in de dataset. Er worden wel twee meetmomenten gegenereerd, namelijk het verwachte voormeetmoment en het verwachte nameetmoment.
|[[Bestand:ValueCare - ROM (1).png|gecentreerd|miniatuur|800x800px]]
|-
|3:Nummering metingen
|We nummeren de opvolgende metingen binnen een reeks op basis van de datum van afname.
Hierdoor kunnen we de opvolgende metingen makkelijk koppelen.

Met behulp van het tijdsinterval per type vragenlijst en diagnose, kunnen we bepalen of de opvolgende metingen plaats hebben gevonden binnen het tijdsinterval (t.o.v. de vorige meting), waarbinnen ze worden verwacht.
{| class="wikitable"
|+
!Optie
! colspan="2" |Situatie
!Gevolg
|-
|A
| colspan="2" |De volgende meting valt binnen tijdsinterval
|De volgende meting is een valide meting. Let op: alle valide metingen moeten voldoen aan de criteria gedefinieerd in stap 2.
|-
|B
| colspan="2" |De volgende meting valt buiten tijdsinterval
|Genereren meetmoment (dus geen valide meting). Dit meetmoment moet duidelijk maken aan instellingen dat er een meting verwacht wordt, maar deze meting niet (valide of volledig) is afgenomen.
|-
|C
| rowspan="2" |Geen volgende meting
|Laatste behandelcontact is in het verleden geweest
|Genereren meetmomenten tot en met het laatste behandelcontact.
|-
|D
|Laatste behandelcontact wordt in de toekomst verwacht
|Genereren meetmomenten tot en met de aanleverdatum + 1 x tijdsinterval.
Er zal dus voor alle reeksen die doorlopen naar de toekomst, één meetmoment aangemaakt worden, die in de toekomst ligt.
|}
|[[Bestand:ROMstap3 nieuw 3.jpg|alt=|gecentreerd|miniatuur|1300x1300px]]
|-
|4: Bepalen voor- en nameting
|Het bepalen van de voor- en nametingen:

De metingen die binnen een reeks het dichtste bij het eerste/laatste behandelcontact liggen worden bestempeld als voor- of nameting.

Indien er enkel een voormeting of een nameting is en niet beide, dan genereren we een meetmoment voor de missende voor- of nameting, met als datum het eerste/laatste behandelcontact.

* Mits er een valide meting heeft plaatsgevonden in de reeks, bepalen we de marge op basis van het tijdsinterval dat geldt voor het type vragenlijst en de gestelde diagnose.

* Mits er geen valide meting heeft plaatsgevonden in de reeks, bepalen we de marge op basis van de BI parameter GGZBI_TIJDSINTERVAL_TUSSENMETINGEN_ONAFHANKELIJK-_VAN_TYPE (''ik zal dit nog hernoemen naar GGZBI_TIJDSINTERVAL_ROM_MEETMO-MENTEN_ONAFHANKELIJK_VAN_TYPE)''.
* Optioneel: Instelbaar
** Mits er voor een reeks meerdere type vragenlijst worden gebruikt (bijv. zowel Honos-12 als SQ48) dan wordt er voor elk type vragenlijst een aparte reeks aangemaakt. Binnen deze aparte reeksen wordt dan ook weer bepaald of er een valide voor- en/of nameting was.
|[[Bestand:ROMstap4 nieuw.jpg|alt=|gecentreerd|miniatuur|1000x1000px]]
|}

=== Gebruikte beheertabellen en parameters ===
Hieronder zijn de parameters en beheertabellen met relevante toelichting te vinden. De dataset die voor de ROM gebruikt wordt is <code>ROM meetmomenten.</code>
{| class="wikitable"
|+
!Parameters
!Toelichting
|-
|BI_MARGE_RONDOM_EERSTE_BEHANDELCONTACT_VOORMETING
|Bandbreedte in dagen rondom eerste behandelcontact zorgtraject waarbinnen een geldige voormeting afgenomen moet zijn
|-
|BI_MARGE_RONDOM_LAATSTE_BEHANDELCONTACT_NAMETING
|Bandbreedte in dagen rondom laatste behandelcontact zorgtraject waarbinnen een geldige nameting afgenomen moet zijn
|-
|BI_INTERVAL_TUSSENMETINGEN_ZORGTRAJECT
|Interval dat bepaalt hoeveel dagen na de vorige meting binnen het zorgtraject een tussenmeting afgenomen moet zijn
|-
|BI_MARGE_TUSSENMETING
|Bandbreedte in dagen rondom het tijdstip bepaald in ''BI_INTERVAL_TUSSENMETINGEN_ZORGTRAJECT'' waarbinnen een geldige tussenmeting afgenomen moet zijn
|-
|GGZBI_TUSSENMETINGEN_ZELFDE_TYPE_VRAGENLIJST
|Of een reeks rekening moet houden met aparte vragenlijst_codes of niet.

Mits parameter = JA, genereren we voor elke verschillende vragenlijst-code binnen een reeks, een nieuwe reeks

Mits parameter = NEE, mogen de vragenlijsten onafhankelijk van elkaar afgenomen zijn

''NOTE: deze parameter wil ik nog hernoemen naar GGZBI_ROM_MEETMOMENTEN_ZELFDE_TYPE_VRAGENLIJST''
|}
{| class="wikitable"
|+
!Beheertabel
!Toelichting
|-
|Beheer BI: Vragenlijst per diagnose
|Per diagnosehoofdgroep kan het gebruikte ROM-instrument aangegeven worden.
In deze beheertabel kan ook het interval per type vragenlijst en diagnose ingesteld worden. (NIEUW!)
|-
|Beheer BI: Vragenlijst
|Per vragenlijst kan worden aangegeven of deze wordt gebruikt als ROM- en/of CQI-instrument
|-
|Beheer BI: Parameters
|Voor het instellen van o.a. de hierboven genoemde parameters.
|}

== Toepassing ==

In dit deel worden de toepassingen toegelicht, deze toepassingen zijn gericht op het behalen van de doelen van de managementrapportage inzake ROM zoals beschreven in de inleiding van deze pagina.

=== Beheertabel ===

Zoals hierboven al vaker aangegeven zijn er een aantal dingen instelbaar via beheertabellen. Zie ook het overzicht van beheertabellen hierboven.

De instellingen van deze beheertabellen hebben invloed om de onderstaande toepassingen en dienen dus correct ingevuld te zijn om de toepassing zo nuttig en accuraat mogelijk te laten zijn.

=== (Delta) t-score ===
De instellingen vinden het vooral belangrijk om de t-scores te weten die bij een ROM meting hoorde. Daarnaast willen ze de delta t-score weten, zodat ze kunnen zien of een cliënt verbeterd of juist verslechterd in de loop der tijd.

Voor een gegenereerd meetmoment hebben we geen t-score. Daardoor kunnen we enkel t-scores vergelijken van valide metingen. We tonen in dataset ROM meetmomenten daarom enkel delta t-scores voor valide metingen ten opzichte van valide metingen. Dit houdt ook in dat voor gegenereerde voormeetmomenten, we geen delta t-score ten opzichte van de voormeting kunnen doen. Om dit te voorkomen, hebben we de ‘initiële meting’ geïntroduceerd. Dit is de eerste valide meting binnen een reeks. We hebben op deze manier dus twee type delta t-scores in de dataset: (1) delta t-score t.o.v. de vorige valide meting, (2) delta t-score t.o.v. de initiële meting.

[[Bestand:Deltat nieuw.jpg|alt=|gecentreerd|miniatuur|800x800px]]

==== Interpretatie Delta T-score ====
Zie de tabel hieronder voor de interpretatie van de Delta T-score:
{| class="wikitable"
|+
!Code
!Classificatie
!Delta T-score
|-
|1
|Hersteld
|> 5 <code>AND</code> voormeting t > 42,5 <code>AND</code> nameting t < 42,5
|-
|2
|Verbeterd
|> 5
|-
|3
|Onveranderd
| -5 < delta t < 5
|-
|4
|Verslechterd
|< -5
|}

=== KPI's en dashboards ===
Voor de ROM biedt ValueCare verschillende dashboards in het portaal.

Deze zijn te vinden onder <code>Meer dashboards > ROM > ROM - Delta t-score</code> en <code>Meer dashboards > ROM > ROM - Proces valide metingen</code>.

Zie hieronder een overzicht:
{| class="wikitable"
|+
!Dashboard
!Tegel
!Toelichting
|-
| rowspan="4" |Delta t-score
|Delta T-score ROM per maand
| rowspan="4" |Delta-T wordt per patient/behandeling berekend als de verschilscore tussen de vorige meting en huidige meting.
|-
|Delta T-score ROM per organisatieniveau
|-
|Delta T-score ROM per soort vragenlijst
|-
|Delta T-score ROM per RCI
|-
| rowspan="4" |Proces valide metingen
|Valide ROM metingen per maand
| rowspan="4" |De rapportage toont het aantal valide metingen. De rapportagedatum is gelijk aan de datum waarop de meting is afgenomen of anders de uiterlijke datum waarop de meting verwacht wordt.
|-
|Valide ROM metingen per organisatieniveau
|-
|Valide ROM metingen per soort vragenlijst
|-
|Valide ROM metingen per soort meetmoment
|-
| rowspan="4" |Effectmeting
|ROM RCI score per maand
|Alle RCI waarden van diverse meetinstrumenten zoals IDS-SR, HoNOS65, etc. gegroepeerd per dbc sluitdatum (einddatum DBC)

Deze rapportage laat de gemiddelde ROM Deltra-t score zien.
|-
|ROM HoNOS65 subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 11 vragen uit de HoNOS65 vragenlijst.
|-
|ROM RCI score per diagnosegroep
|Deze rapportage laat de ROM RCI score zien per diagnosegroep. In de tabel onder de grafiek is meer verdiepende data te vinden. Deze rapportage laat de gemiddelde ROM Delta-T score zien.
|-
|ROM CANSAS subschalen
|Deze rapportage laat de ruwe scores van de voor- en nameting zien voor 25 vragen uit de CANVAS vragenlijst.

Proportie cliënten met onopgeloste zorgbehoeften is het percentage cliënten dat minimaal 1 heeft gescoord op de subschaal "onopgeloste zorgbehoeften" tov het totaal aantal cliënten.
|-
| rowspan="4" |Effectmeting Delta t-score
|ROM Delta-T score per maand
|Rapportage: gemiddelde ROM Delta-T score per maand.
|-
|ROM Delta-T score per org. niv.
|Rapportage: gemiddelde ROM Delta-T score per organisatie niveau.
|-
|ROM Delta-T score per diagnosegroep
|Rapportage: gemiddelde Delta-T score per diagnosegroep.
|-
|ROM Delta-T score per jaar
|Rapportage: gemiddelde Delta-T score per jaar.
|}
{{VALUECARE}}

Klant Query Server

2022-07-14T14:57:55Z

Cbruin: /* Handleiding */

== Inleiding ==
Op verzoek stelt ValueCare aan de instellingen een Query Server beschikbaar met daarop een Postgres database met alle source data en BI resultaat data. De door de instelling aangemerkte gebruikers kunnen een connectie maken met de database en er queries op los laten. Ook is het mogelijk om een tool, zoals bijvoorbeeld PowerBI, te connecten tot de database.

== Implementatie ==
Het volgende is nodig vanuit de instelling:

* Een server en het IP adres van de server, tenzij de server wordt gehost door ValueCare.
* Een VPN verbinding van het klantnetwerk naar het ValueCare netwerk.
* Een lijst met gebruikers.

De rest van de implementatie wordt door ValueCare verzorgd.

== Hoe werkt het? ==
In het kort wordt het volgende dagelijks gedaan:

* Er wordt een kopie van de source data en BI resultaat data op de ValueCare Productie server gemaakt.
* Op de Query Server zijn er 2 database schema's: vcs en public. Het vcs schema wordt leeg gemaakt.
* De kopie van de source data en BI resultaat data wordt in het vcs schema geplaatst.
De gebruiker kan vervolgens data in het vcs schema inzien, maar niet wijzigen. In het public schema kan de gebruiker tabellen aanmaken, wijzigen en verwijderen.

== Handleiding ==

=== De data ===
Er zijn twee schema's beschikbaar op de queryserver: public en vcs. In het vcs schema wordt alle bi- en bron-data neergezet, zodat de ValueCare data beschikbaar is. Deze data worden elke dag ververst, zodat het elke dag overeen komt met de data op de Productie-omgeving. Als u op schema vcs een eigen tabel zou aanmaken, wordt deze verwijderd tijdens de verversing. Om met eigen tabellen te werken, is het public-schema beschikbaar. De tabellen die hierop staan, blijven beschikbaar op de Queryserver. Hoe u data overzet van schema vcs naar schema public leest u hieronder.

==='''Tabellen kopiëren van schema VCS naar schema Public'''===
Er zijn verschillende manieren om een tabel van schema vcs over te zetten naar schema public. Hieronder is de query uitgeschreven voor één van die manieren. Als je dit vaak wil gebruiken, is het handig om hier een template van te maken (specifiek voor DBeaver). Hier vind je meer over in “Templates”.

CREATE TABLE public.table_name (LIKE vcs.table_name INCLUDING ALL);

INSERT INTO public.table_name

SELECT *

FROM vcs.table_name;

=== '''Van een dashboard of tegel naar de juiste tabel op de Queryserver''' ===
Om te begrijpen welke tabellen op de queryserver onderliggend zijn aan de tegels en dashboards die zichtbaar zijn in het portaal is de tabel bi_queryserver_tegels_en_dashboards beschikbaar. Hierin kan je zien welke tabellen worden gebruikt in een tegel en/of dashboard. In onderstaand voorbeeld, zie je dus dat voor de tegel ‘Waarde verblijfsdagen per maand’, die te vinden is in dataset ‘Verblijf ZPM’, de onderliggende tabel ‘bi_zis_verblijf_zpm’ is. Tabel bi_zis_verblijf_zpm is dan te vinden op de queryserver.
{| class="wikitable"
|'''tegel_naam'''
|'''dataset_naam'''
|'''tabel_naam'''
|'''tegel_beschrijving'''
|-
|Waarde verblijfsdagen per maand
|Verblijf ZPM
|bi_zis_verblijf_zpm
|Deze rapportage toont waarde van de verblijfsdagen voor …
|}
Daarnaast kan je vanuit het portaal ook het filter paginanaam gebruiken. Als je deze toevoegt vanuit [+ nieuw filter] onderaan de linker balk met filters, dan zie je ook welke tabellen er gebruikt worden voor het opstellen van de tegel en/of dashboard.

De logica achter de benaming van tabellen op de queryserver is hieronder weergegeven.
{| class="wikitable"
|'''Voorvoegsel'''
|'''Betekenis'''
|'''Uitleg'''
|-
|src_
|Source (bron)
|Alle tabellen die wij direct vanuit een bron ophalen krijgen het voorvoegsel src_. Dit zijn dus tabellen vanuit bronnen, zoals XMCare, MijnQuarant, Beaufort, QuestManager, etc. Ook bestanden die we ophalen vanaf een SFTP server of andere bronnen, krijgen dit voorvoegsel.
|-
|bi_
|Business intelligence
|Alle tabellen die gebruikt worden voor het samenstellen van dashboards en tegels hebben het voorvoegsel bi.
|}

=== '''Connectie opzetten''' ===

# Vraag om de hostname en de databasename bij ValueCare
#* Het kan ook zijn dat de queryserver lokaal gehost wordt, in dat geval is de hostname doorgaans te achterhalen bij de ICT-afdeling
# Vraag om de username en password bij jouw ValueCare contactpersoon.
# Maak de connectie vanuit de tool die u gebruikt, door de hostname en de databasename in te vullen en in te loggen met uw username en password.
#* De Queryserver beschikt over een postgres database, dus het poortnummer is de standaard postgres poort (5432)

== DBeaver ==
Er zijn tal van goede programma's die u kunt gebruiken om te querieën op de Queryserver. Mits u gebruik maakt of wilt maken van DBeaver om op de Queryserver te querieën, dan vindt u hieronder een aantal instructies en een aantal tips & tricks die het gebruik van DBeaver nog fijner maken.

=== '''Installeren DBeaver''' ===

* Via <nowiki>https://dbeaver.io/download/</nowiki> kan je DBeaver downloaden
* Met de standaard instellingen van de installatie kan je prima op de Queryserver komen, maar voel je vrij om de instellingen naar wens aan te passen.

=== '''Connectie opzetten met de database''' ===

# Klik linksboven op het stekkertje om een nieuwe connectie op te zetten. (Dit kan eventueel ook via het menu: Database > New Database Connection
# Selecteer PostgreSQL
# Vul de juiste naam voor de Host in (het poortnummer staat default al goed: 5432)
# Vul juiste naam voor de Database in
# Vul de juiste Username in (deze heb je ontvangen vanuit ValueCare. Heb je deze nog niet, dan kan je die aanvragen via jouw contactpersoon)
# Ga naar het kopje “Driver properties” en zet hier het veld tcpKeepAlive op ‘True’
# Klik op Finish
# Nu verschijnt er links in de “Database Navigator” een connectie met de naam van de database. Dubbelklik hierop om de connectie te openen
# Vul je wachtwoord in en voilà!

=== '''Tips & Tricks om snel met DBeaver te werken''' ===
'''Overzicht van de functie-toetsen'''

Uitvoeren van een query: ctrl + enter

Openen van new script: F3

Geavanceerd kopiëren: ctrl + shift + c (uitgebreidere uitleg onder “Geavanceerd kopiëren”)

'''Templates'''

Templates zijn erg handig in DBeaver. Hiermee kan je veelgebruikte queries opslaan en hoef je die niet volledig te typen, als je ze de volgende keer wil gebruiken. Bijvoorbeeld: In plaats van ‘SELECT * FROM table_name;’, type je enkel ‘saf’ en druk je op tab.

Om een template aan te maken ga je naar: Window > Preferences > SQL Editor > Templates > New.

''Name'': de combinatie aan woorden of letters die jij wil typen in plaats van de query

''Pattern'': de query die moet verschijnen als je de Name typt en op Tab drukt.

''Insert variable'': Hiermee kan je een bepaalde variabele aanroepen nadat je het template gebruikt. Bijvoorbeeld, SELECT * FROM '''${table}'''; zorgt ervoor dat je makkelijk een bestaande tabel kan selecteren als je het template gebruikt.

'''Geavanceerd kopiëren'''

Met ctrl + shift + c kunt u geavanceerd kopiëren. Dit is handig als u de geselecteerde rijen wil gebruiken, bijvoorbeeld in een volgende query. Er staan dan automatisch quotes omheen en een komma tussen elk item, zoals hieronder weergegeven.

'item1',

'item2',

...

==== Exporteren naar Excel (xlsx) ====
Je kunt een extensie installeren waarmee je direct Excels kunt downloaden. Dus niet eerst csv-bestanden die nog met de hand geconverteerd moeten worden. Volg de stappen in de link 'extensie installeren'.

LET OP!: Sluit DBeaver eerst af en start het op als Administrator. Bijv. door Ctrl + Shift + Rechtermuisknop op de taakbalk en dan 'Als administrator uitvoeren'.

==== CSV-bestanden als database benaderen ====
Klik op het plusje met New Database Connection, zoek naar 'csv'.

Onder Path kies je een map waarin je alle .csv-bestanden naar gaat zetten. Klik op Finish.

Alle csv's die je in de map die je hierboven getypt hebt plaatst, zijn dan beschikbaar om op te queryen.

In de Driver Properties kun je onder seperator instellen wat het scheidingsteken is.

==== Regels afsterren: ====
Regels zijn op twee manieren als tekst neer te zetten.

-- door middel van twee streepjes voor

/*

Of door middel van /* en */

<nowiki>*</nowiki>/

Als u al tekst heeft geschreven kunt u gebruiken maken van ctrl + / om automatisch streepjes voor de tekst te laten zetten. Selecteer de betreffende regels en druk op CTRL + /

==== Databasenaam in export ====
Een export doe je door in een Resultset met de Rechtermuisknop op 'Export data ...' te klikken. Als u wil dat de file-name automatisch de databasenaam, tabelnaam, en/of een timestamp bevat, kan je dat doen door het volgende te doen.

Bij Export data ... > Output (stap 4) > File name pattern, kan je de naam van de te exporteren file bepalen. Als je daarin gebruik maakt van onderstaande variabelen, krijgt de export automatisch de naam van de betreffende variabele.

De databasenaam: ${datasource}

De tabelnaam: ${table}

De timestamp: ${timestamp}

Een combinatie hiervan is ook mogelijk. Bijvoorbeeld ${datasource}_${table}_${timestamp}.

==== Naar hoofdletters/kleine letters van selectie ====
Ctrl + Shift + X -> selectie naar hoofdletters

Ctrl + Shift + Y -> selectie naar kleine letters

{{VALUECARE}}

Klant Query Server

2022-07-13T10:24:54Z

Cbruin: /* Overzicht van de functie-toetsen */

Klant Query Server

2022-07-13T10:24:25Z

Cbruin:

Klant Query Server

2022-07-13T10:23:39Z

Cbruin:

Klant Query Server

2022-07-13T10:22:45Z

Cbruin: De handleiding van de queryserver is toegevoegd. Hiermee kunnen klanten met een queryserver, makkelijker gebruik maken van de queryserver

Jeugdmonitor

2022-02-14T10:00:19Z

Cbruin: /* Beeindigen jeugdhulp (JW317) */

De eerste versie van de Jeugdmonitor was beschikbaar als Excel-bestand. Vanaf de tweede versie is de jeugdmonitor niet meer beschikbaar als Excel-bestand, maar als tegels en dashboards die te vinden zijn in het ValueCare portaal.

== '''Doelgroep''' ==
De jeugdmonitor is gemaakt om de financiële resultaten binnen de Jeugdzorg per jaar per gemeente te monitoren. Kinderen en jongeren onder de 18 jaar die hulp, zorg of ondersteuning nodig hebben vallen in de meeste gevallen onder de Jeugdwet. Deze worden gemonitord in de Jeugdwet.

=== Verlengde jeugdhulp ===
Normaal gesproken komen cliënten die jonger zijn dan 18 jaar in aanmerking voor hulp binnen de Jeugdwet. Echter, kunnen cliënten van 18 tot 23 jaar in aanmerking komen voor verlengde jeugdhulp, als er sprake is van de volgende voorwaarden:

# Er is geen financiering beschikbaar (bijv. vanuit ZvW, Wlz, WMO, ZvW) nadat de cliënt 18 is geworden.
# Naast (1) wordt er voldaan minstens één van volgende criteria:
#* Cliënt heeft jeugdhulp gehad vóór het 18e jaar en de gemeente vindt verdere jeugdhulp noodzakelijk
#* Cliënt heeft jeugdhulp gehad vóór het 18e jaar en binnen een half jaar na het 18 jaar komt cliënt opnieuw in aanmerking voor jeugdhulp
#* Cliënt heeft pleegzorg en voortzetting van de pleegzorg is nodig

Een maatregel is uitgesproken met betrekking op een strafbaar feit dat is begaan tussen het 18e en 23e jaar.

== Financiering vanuit gemeenten ==
In de GGZ wordt de jeugdzorg sinds 1 januari 2018 gefinancierd vanuit gemeenten. Er is onder andere gekozen voor gemeentelijke financiering, zodat de zorg lokaal georganiseerd kan worden, dichter bij het gezin. Met de introductie van de Jeugdwet is de DBC-systematiek die vóór 2018 van toepassing was op de Jeugdzorg, niet meer in gebruik. Vóór 2018 werd de jeugdzorg geregistreerd in DBC's en viel de bekostiging onder de ZvW (Zorgverzekeringswet), waarvan een groot deel binnen de AWBZ (Algemene Wet Bijzondere Ziektekosten) viel.

Om de financiering en administratie binnen de Jeugdwet goed te organiseren is er een landelijke berichtenstandaard opgezet. Dit betreft met name een standaard voor het berichtenverkeer tussen gemeenten en zorgaanbieders. Hoe deze berichtenstandaard werkt, lees je hieronder. Allereerst vind je een korte uitleg van de berichten met betrekking tot het starten en beëindigen van de zorg. Dat zijn de berichten die actief gecontroleerd binnen ValueCare. Daarnaast vind je een overzicht van alle berichten.

=== Verzoek om toewijzing (JW315) ===
De zorgaanbieder verzoekt de gemeente om een toewijzing te sturen voor het leveren van jeugdhulp waarvoor reeds een titel tot levering bestaat. Het Verzoek om toewijzing-bericht kan alleen gebruikt worden voor situaties waarbij het recht op jeugdhulp al vaststaat en is daarmee één van de rechtmatigheidsberichten. Met het Verzoek om toewijzing geeft de aanbieder aan dat de zorg is gestart. De gemeente stuurt altijd binnen drie werkdagen een retourbericht om aan te geven dat het Verzoek om toewijzing ontvangen is. De gemeente die het Verzoek om toewijzing ontvangt is verplicht om te toetsen of, op basis van het woonplaatsbeginsel, de client onder haar verantwoordelijkheid valt. Wanneer dat zo is, stuurt de gemeente de aanbieder een officiële toewijzing voor de te leveren jeugdhulp.

=== Toewijzing/beschikking (JW301) ===
Met de toewijzing geeft de gemeente een aanbieder opdracht tot levering van jeugdhulp voor een specifieke client. Het geeft de aanbieder het recht om de zorg te gaan leveren en is daarmee één van de rechtmatigheidsberichten. In het bericht wordt het toegewezen product omschreven. Dit toegewezen product kan aspecifiek zijn (dat wil zeggen dat alleen een productcategorie wordt toegewezen) of specifiek (dat wil zeggen dat binnen de productcategorie ook een specifieke productcode wordt toegewezen). In de toewijzing wordt aangegeven welke specifieke aanbieder welk product moet leveren, met een bepaalde omvang en voor een bepaalde periode. Dit kan een periode zonder einddatum zijn.

=== Starten Jeugdhulp (JW305) ===
Met het Startbericht geeft de aanbieder aan de gemeente door wanneer de levering gestart is. Het bericht is bedoeld om de gemeente inzicht te geven in het daadwerkelijk plaatsvinden van de levering van zorg en ondersteuning. Er kunnen geen rechten ontleend worden aan dit bericht, dat wil bijvoorbeeld zeggen dat er geen afhankelijkheid met de betaling (declaratie of facturatie) mag bestaan. Het Startbericht is daarmee één van de regieberichten.

=== Beeindigen jeugdhulp (JW307) ===
Met het Stopbericht geeft de aanbieder aan de gemeente door wanneer de levering beëindigd is en wat de reden is van de beëindiging. Het bericht is bedoeld om de gemeente inzicht te geven in het daadwerkelijk plaatsvinden van de levering van zorg en ondersteuning. Er kunnen geen rechten ontleend worden aan dit bericht, dat wil bijvoorbeeld zeggen dat er geen afhankelijkheid met de betaling (facturatie) mag bestaan. Het Stopbericht is daarmee één van de regieberichten. Indien de start van de levering is doorgegeven met een Startbericht, wordt de beëindiging van de levering altijd doorgegeven met een Stopbericht. De beëindiging kan plaatsvinden op initiatief van de gemeente: de aanbieder ontvangt een intrekkingsbericht van de gemeente. Met het Stopbericht geeft de aanbieder door wanneer de levering definitief gestopt is.

=== Verzoek om wijziging (JW317) ===
Als de zorgaanbieder vaststelt dat de geleverde zorg tijdens de levering van de zorg aangepast moet worden, kan er een verzoek om wijziging (VOW) worden aangevraagd bij de gemeente.

=== Antwoordbericht (JW319) ===
Als een gemeente nader onderzoek moet doen met betrekking tot een VOW of VOT, of als een verzoek wordt afgewezen, wordt het Jw319-antwoordbericht gebruikt.

== Registratie ==

=== Productcategorie ===
Voor de Jeugdwet-producten is landelijk een aantal productcategorieën vastgesteld, die verplicht gebruikt moeten worden in de berichten. Deze categorieën zijn over en weer vertaalbaar in de indeling die de Vereniging van Nederlandse Gemeenten (VNG) voorstelt voor de financiële verantwoording van Jeugdwet-voorzieningen. Zo kunnen de productcategorieën een plek krijgen in de landelijke financiële verantwoording die gemeenten moeten afleggen aan het ministerie van Binnenlandse Zaken. Ook uit de afstemming met CAK en SVB blijkt dat hun productindelingen goed passen.

=== Productcode ===
Onder de productcategorieën zijn productcodes gedefinieerd, als verbijzondering binnen een productcategorie. Deze codes, die specifieker beschrijven om welk product of welke dienst het gaat, zijn opgenomen in de standaardproductcodelijst Jeugdwet (JZ21). Gemeenten en aanbieders spreken onderling af welke van deze productcodes zij gebruiken, zodat de codes passen bij de gekozen Jeugdwet-uitvoering.

Zorginstituut Nederland adviseert gemeenten en aanbieders om zoveel mogelijk gebruik te maken van de codes op de standaardproductcodelijst, omdat dit bijdraagt aan minder administratieve variëteit. Gemeenten mogen besluiten om de standaardproductcodelijst niet te gebruiken. Zij mogen dan zelf productcodes definiëren, binnen de productcategorieën die zijn vastgesteld. Samen met de aanbieder leggen ze dan vast welke codes gebruikt mogen worden bij welke productcategorie. In dat geval adviseert het Zorginstituut om codes te kiezen die ''niet'' voorkomen op de standaardproductcodelijst.

=== Eenheid ===
De eenheid zegt iets over hoe de afrekening verloopt. De volgende eenheden zijn vanuit de informatiestandaard iJw 3.0 vastgesteld:

* 01 - Facturatie in geregistreerde minuten
* 04 - Facturatie in geregistreerde uren
* 14 - Facturatie in geregistreerde verblijfsdagen
* 16 - Facturatie in geregistreerde dagdelen
* 82 - Facturatie stuks output
* 83 - Facturatie volgens vastgesteld tarief (€)
* 84 – Facturatie stuks inspanningsgericht

Sinds 1 januari 2021 wordt de informatiestandaard iJw 3.0 gebruikt binnen de Jeugdwet. Vóór 2021 werd eenheid ’82 – Facturatie volgens arrangement’ gebruikt. Dit is opgesplitst in ‘82 – Facturatie stuks output’ en ’84 – stuks inspanningsgericht’. Outputgericht houdt in dat er afspraken zijn tussen gemeente en zorgaanbieder over de te behalen output. Daarbij hoeft niet vastgelegd te zijn hoe deze output wordt behaald. Inspanningsgericht houdt in dat er afspraken zijn tussen gemeente en zorgaanbieder wat betreft de levering van een product of dienst in een afgesproken tijdseenheid.

=== Frequentie ===
De frequentie geeft aan hoe frequent er gefactureerd zal gaan worden. De volgende frequenties zijn vastgesteld:

# - Per dag
# - Per week
# - Per 4 weken
# - Per maand
# - Per jaar
# - Totaal binnen geldigheidsduur beschikking

=== Volume ===
Het volume geeft het vastgestelde maximum aan en is afhankelijk van de eenheid. Met andere woorden, een volume van 10.000 betekent bij eenheid 01, 10.000 minuten, maar betekent bij eenheid 83, 10.000 euro.

=== Status ===
Er zijn 4 verschillende statussen van financiering in de jeugdmonitor, namelijk:

# ''Gefactureerd - V''an alle producten alle factuurmomenten.
# ''Onderhanden werk (OHW)-'' Van alle producten de waarde die nog niet gefactureerd is. De OHW waarde van een product wordt per eenheid anders berekend:
#* '''01:''' Som van de tijd van alle contacten na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''04:''' Som van de tijd van alle contacten na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''14:''' Som van alle verblijfsdagen na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''16:''' Som van alle dagdelen na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''82:''' Som van alle mijlpalen die wel behaald zijn maar nog niet gefactureerd zijn vermenigvuldigd met het afgesproken tarief.
#* '''83:''' Het afgesproken volume maal de restende looptijd (afhankelijk van frequentie) na laatste datum uit factuur.
#* '''84:''' Som van de productie
# ''Extra waarde reeds geopend -'' Van alle openstaande producten de extra verwachte waarde
# ''Nog te openen -'' De waarde van alle producten die nog geopend gaan worden (dus nog niet bestaan)

'''De prognose wordt als volgt berekend:'''

Per betalende instantie wordt de gemiddelde duur van een jeugd-product vermenigvuldigd met de gemiddelde productie op een jeugd-product. Deze wordt vermenigvuldigd met het aantal nog te verwachten te openen producten. Deze verwachting is gebaseerd op het aantal reeds geopende producten en het aantal nog resterende dagen in een jaar. Zodoende kan op elk moment van het schadelastjaar een schatting worden gemaakt van de nog te openen productie. Naarmate het jaar vordert, komt er meer data beschikbaar van reeds geopende producten en zal de prognose steeds nauwkeuriger worden.

{{VALUECARE}}

Jeugdmonitor

2021-12-21T09:30:56Z

Cbruin: /* Verlengde jeugdhulp */ Zinsstructuur

De eerste versie van de Jeugdmonitor was beschikbaar als Excel-bestand. Vanaf de tweede versie is de jeugdmonitor niet meer beschikbaar als Excel-bestand, maar als tegels en dashboards die te vinden zijn in het ValueCare portaal.

== '''Doelgroep''' ==
De jeugdmonitor is gemaakt om de financiële resultaten binnen de Jeugdzorg per jaar per gemeente te monitoren. Kinderen en jongeren onder de 18 jaar die hulp, zorg of ondersteuning nodig hebben vallen in de meeste gevallen onder de Jeugdwet. Deze worden gemonitord in de Jeugdwet.

=== Verlengde jeugdhulp ===
Normaal gesproken komen cliënten die jonger zijn dan 18 jaar in aanmerking voor hulp binnen de Jeugdwet. Echter, kunnen cliënten van 18 tot 23 jaar in aanmerking komen voor verlengde jeugdhulp, als er sprake is van de volgende voorwaarden:

# Er is geen financiering beschikbaar (bijv. vanuit ZvW, Wlz, WMO, ZvW) nadat de cliënt 18 is geworden.
# Naast (1) wordt er voldaan minstens één van volgende criteria:
#* Cliënt heeft jeugdhulp gehad vóór het 18e jaar en de gemeente vindt verdere jeugdhulp noodzakelijk
#* Cliënt heeft jeugdhulp gehad vóór het 18e jaar en binnen een half jaar na het 18 jaar komt cliënt opnieuw in aanmerking voor jeugdhulp
#* Cliënt heeft pleegzorg en voortzetting van de pleegzorg is nodig

Een maatregel is uitgesproken met betrekking op een strafbaar feit dat is begaan tussen het 18e en 23e jaar.

== Financiering vanuit gemeenten ==
In de GGZ wordt de jeugdzorg sinds 1 januari 2018 gefinancierd vanuit gemeenten. Er is onder andere gekozen voor gemeentelijke financiering, zodat de zorg lokaal georganiseerd kan worden, dichter bij het gezin. Met de introductie van de Jeugdwet is de DBC-systematiek die vóór 2018 van toepassing was op de Jeugdzorg, niet meer in gebruik. Vóór 2018 werd de jeugdzorg geregistreerd in DBC's en viel de bekostiging onder de ZvW (Zorgverzekeringswet), waarvan een groot deel binnen de AWBZ (Algemene Wet Bijzondere Ziektekosten) viel.

Om de financiering en administratie binnen de Jeugdwet goed te organiseren is er een landelijke berichtenstandaard opgezet. Dit betreft met name een standaard voor het berichtenverkeer tussen gemeenten en zorgaanbieders. Hoe deze berichtenstandaard werkt, lees je hieronder. Allereerst vind je een korte uitleg van de berichten met betrekking tot het starten en beëindigen van de zorg. Dat zijn de berichten die actief gecontroleerd binnen ValueCare. Daarnaast vind je een overzicht van alle berichten.

=== Verzoek om toewijzing (JW315) ===
De zorgaanbieder verzoekt de gemeente om een toewijzing te sturen voor het leveren van jeugdhulp waarvoor reeds een titel tot levering bestaat. Het Verzoek om toewijzing-bericht kan alleen gebruikt worden voor situaties waarbij het recht op jeugdhulp al vaststaat en is daarmee één van de rechtmatigheidsberichten. Met het Verzoek om toewijzing geeft de aanbieder aan dat de zorg is gestart. De gemeente stuurt altijd binnen drie werkdagen een retourbericht om aan te geven dat het Verzoek om toewijzing ontvangen is. De gemeente die het Verzoek om toewijzing ontvangt is verplicht om te toetsen of, op basis van het woonplaatsbeginsel, de client onder haar verantwoordelijkheid valt. Wanneer dat zo is, stuurt de gemeente de aanbieder een officiële toewijzing voor de te leveren jeugdhulp.

=== Toewijzing/beschikking (JW301) ===
Met de toewijzing geeft de gemeente een aanbieder opdracht tot levering van jeugdhulp voor een specifieke client. Het geeft de aanbieder het recht om de zorg te gaan leveren en is daarmee één van de rechtmatigheidsberichten. In het bericht wordt het toegewezen product omschreven. Dit toegewezen product kan aspecifiek zijn (dat wil zeggen dat alleen een productcategorie wordt toegewezen) of specifiek (dat wil zeggen dat binnen de productcategorie ook een specifieke productcode wordt toegewezen). In de toewijzing wordt aangegeven welke specifieke aanbieder welk product moet leveren, met een bepaalde omvang en voor een bepaalde periode. Dit kan een periode zonder einddatum zijn.

=== Starten Jeugdhulp (JW305) ===
Met het Startbericht geeft de aanbieder aan de gemeente door wanneer de levering gestart is. Het bericht is bedoeld om de gemeente inzicht te geven in het daadwerkelijk plaatsvinden van de levering van zorg en ondersteuning. Er kunnen geen rechten ontleend worden aan dit bericht, dat wil bijvoorbeeld zeggen dat er geen afhankelijkheid met de betaling (declaratie of facturatie) mag bestaan. Het Startbericht is daarmee één van de regieberichten.

=== Beeindigen jeugdhulp (JW307) ===
Met het Stopbericht geeft de aanbieder aan de gemeente door wanneer de levering beëindigd is en wat de reden is van de beëindiging. Het bericht is bedoeld om de gemeente inzicht te geven in het daadwerkelijk plaatsvinden van de levering van zorg en ondersteuning. Er kunnen geen rechten ontleend worden aan dit bericht, dat wil bijvoorbeeld zeggen dat er geen afhankelijkheid met de betaling (facturatie) mag bestaan. Het Stopbericht is daarmee één van de regieberichten. Indien de start van de levering is doorgegeven met een Startbericht, wordt de beëindiging van de levering altijd doorgegeven met een Stopbericht. De beëindiging kan plaatsvinden op initiatief van de gemeente: de aanbieder ontvangt een intrekkingsbericht van de gemeente. Met het Stopbericht geeft de aanbieder door wanneer de levering definitief gestopt is.

=== Beeindigen jeugdhulp (JW317) ===
Als de zorgaanbieder vaststelt dat de geleverde zorg tijdens de levering van de zorg aangepast moet worden, kan er een verzoek om wijziging (VOW) worden aangevraagd bij de gemeente.

=== Beeindigen jeugdhulp (JW319) ===
Als een gemeente nader onderzoek moet doen met betrekking tot een VOW of VOT, of als een verzoek wordt afgewezen, wordt het Jw319-antwoordbericht gebruikt.

== Registratie ==

=== Productcategorie ===
Voor de Jeugdwet-producten is landelijk een aantal productcategorieën vastgesteld, die verplicht gebruikt moeten worden in de berichten. Deze categorieën zijn over en weer vertaalbaar in de indeling die de Vereniging van Nederlandse Gemeenten (VNG) voorstelt voor de financiële verantwoording van Jeugdwet-voorzieningen. Zo kunnen de productcategorieën een plek krijgen in de landelijke financiële verantwoording die gemeenten moeten afleggen aan het ministerie van Binnenlandse Zaken. Ook uit de afstemming met CAK en SVB blijkt dat hun productindelingen goed passen.

=== Productcode ===
Onder de productcategorieën zijn productcodes gedefinieerd, als verbijzondering binnen een productcategorie. Deze codes, die specifieker beschrijven om welk product of welke dienst het gaat, zijn opgenomen in de standaardproductcodelijst Jeugdwet (JZ21). Gemeenten en aanbieders spreken onderling af welke van deze productcodes zij gebruiken, zodat de codes passen bij de gekozen Jeugdwet-uitvoering.

Zorginstituut Nederland adviseert gemeenten en aanbieders om zoveel mogelijk gebruik te maken van de codes op de standaardproductcodelijst, omdat dit bijdraagt aan minder administratieve variëteit. Gemeenten mogen besluiten om de standaardproductcodelijst niet te gebruiken. Zij mogen dan zelf productcodes definiëren, binnen de productcategorieën die zijn vastgesteld. Samen met de aanbieder leggen ze dan vast welke codes gebruikt mogen worden bij welke productcategorie. In dat geval adviseert het Zorginstituut om codes te kiezen die ''niet'' voorkomen op de standaardproductcodelijst.

=== Eenheid ===
De eenheid zegt iets over hoe de afrekening verloopt. De volgende eenheden zijn vanuit de informatiestandaard iJw 3.0 vastgesteld:

* 01 - Facturatie in geregistreerde minuten
* 04 - Facturatie in geregistreerde uren
* 14 - Facturatie in geregistreerde verblijfsdagen
* 16 - Facturatie in geregistreerde dagdelen
* 82 - Facturatie stuks output
* 83 - Facturatie volgens vastgesteld tarief (€)
* 84 – Facturatie stuks inspanningsgericht

Sinds 1 januari 2021 wordt de informatiestandaard iJw 3.0 gebruikt binnen de Jeugdwet. Vóór 2021 werd eenheid ’82 – Facturatie volgens arrangement’ gebruikt. Dit is opgesplitst in ‘82 – Facturatie stuks output’ en ’84 – stuks inspanningsgericht’. Outputgericht houdt in dat er afspraken zijn tussen gemeente en zorgaanbieder over de te behalen output. Daarbij hoeft niet vastgelegd te zijn hoe deze output wordt behaald. Inspanningsgericht houdt in dat er afspraken zijn tussen gemeente en zorgaanbieder wat betreft de levering van een product of dienst in een afgesproken tijdseenheid.

=== Frequentie ===
De frequentie geeft aan hoe frequent er gefactureerd zal gaan worden. De volgende frequenties zijn vastgesteld:

# - Per dag
# - Per week
# - Per 4 weken
# - Per maand
# - Per jaar
# - Totaal binnen geldigheidsduur beschikking

=== Volume ===
Het volume geeft het vastgestelde maximum aan en is afhankelijk van de eenheid. Met andere woorden, een volume van 10.000 betekent bij eenheid 01, 10.000 minuten, maar betekent bij eenheid 83, 10.000 euro.

=== Status ===
Er zijn 4 verschillende statussen van financiering in de jeugdmonitor, namelijk:

# ''Gefactureerd - V''an alle producten alle factuurmomenten.
# ''Onderhanden werk (OHW)-'' Van alle producten de waarde die nog niet gefactureerd is. De OHW waarde van een product wordt per eenheid anders berekend:
#* '''01:''' Som van de tijd van alle contacten na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''04:''' Som van de tijd van alle contacten na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''14:''' Som van alle verblijfsdagen na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''16:''' Som van alle dagdelen na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''82:''' Som van alle mijlpalen die wel behaald zijn maar nog niet gefactureerd zijn vermenigvuldigd met het afgesproken tarief.
#* '''83:''' Het afgesproken volume maal de restende looptijd (afhankelijk van frequentie) na laatste datum uit factuur.
#* '''84:''' Som van de productie
# ''Extra waarde reeds geopend -'' Van alle openstaande producten de extra verwachte waarde
# ''Nog te openen -'' De waarde van alle producten die nog geopend gaan worden (dus nog niet bestaan)

'''De prognose wordt als volgt berekend:'''

Per betalende instantie wordt de gemiddelde duur van een jeugd-product vermenigvuldigd met de gemiddelde productie op een jeugd-product. Deze wordt vermenigvuldigd met het aantal nog te verwachten te openen producten. Deze verwachting is gebaseerd op het aantal reeds geopende producten en het aantal nog resterende dagen in een jaar. Zodoende kan op elk moment van het schadelastjaar een schatting worden gemaakt van de nog te openen productie. Naarmate het jaar vordert, komt er meer data beschikbaar van reeds geopende producten en zal de prognose steeds nauwkeuriger worden.

{{VALUECARE}}

Jeugdmonitor

2021-12-17T07:46:52Z

Cbruin: /* Volume */ zinstructuur

De eerste versie van de Jeugdmonitor was beschikbaar als Excel-bestand. Vanaf de tweede versie is de jeugdmonitor niet meer beschikbaar als Excel-bestand, maar als tegels en dashboards die te vinden zijn in het ValueCare portaal.

== '''Doelgroep''' ==
De jeugdmonitor is gemaakt om de financiële resultaten binnen de Jeugdzorg per jaar per gemeente te monitoren. Kinderen en jongeren onder de 18 jaar die hulp, zorg of ondersteuning nodig hebben vallen in de meeste gevallen onder de Jeugdwet. Deze worden gemonitord in de Jeugdwet.

=== Verlengde jeugdhulp ===
Normaal gesproken vallen cliënten die jonger zijn dan 18 jaar in aanmerking voor hulp binnen de Jeugdwet. Echter, kunnen cliënten van 18 tot 23 jaar in aanmerking komen voor verlengde jeugdhulp, als er sprake is van de volgende voorwaarden:

# Er is geen financiering beschikbaar (bijv. vanuit ZvW, Wlz, WMO, ZvW) nadat de cliënt 18 is geworden.
# Naast (1) wordt er voldaan minstens één van volgende criteria:
#* Cliënt heeft jeugdhulp gehad vóór het 18e jaar en de gemeente vindt verdere jeugdhulp noodzakelijk
#* Cliënt heeft jeugdhulp gehad vóór het 18e jaar en binnen een half jaar na het 18 jaar komt cliënt opnieuw in aanmerking voor jeugdhulp
#* Cliënt heeft pleegzorg en voortzetting van de pleegzorg is nodig

Een maatregel is uitgesproken met betrekking op een strafbaar feit dat is begaan tussen het 18e en 23e jaar.

== Financiering vanuit gemeenten ==
In de GGZ wordt de jeugdzorg sinds 1 januari 2018 gefinancierd vanuit gemeenten. Er is onder andere gekozen voor gemeentelijke financiering, zodat de zorg lokaal georganiseerd kan worden, dichter bij het gezin. Met de introductie van de Jeugdwet is de DBC-systematiek die vóór 2018 van toepassing was op de Jeugdzorg, niet meer in gebruik. Vóór 2018 werd de jeugdzorg geregistreerd in DBC's en viel de bekostiging onder de ZvW (Zorgverzekeringswet), waarvan een groot deel binnen de AWBZ (Algemene Wet Bijzondere Ziektekosten) viel.

Om de financiering en administratie binnen de Jeugdwet goed te organiseren is er een landelijke berichtenstandaard opgezet. Dit betreft met name een standaard voor het berichtenverkeer tussen gemeenten en zorgaanbieders. Hoe deze berichtenstandaard werkt, lees je hieronder. Allereerst vind je een korte uitleg van de berichten met betrekking tot het starten en beëindigen van de zorg. Dat zijn de berichten die actief gecontroleerd binnen ValueCare. Daarnaast vind je een overzicht van alle berichten.

=== Verzoek om toewijzing (JW315) ===
De zorgaanbieder verzoekt de gemeente om een toewijzing te sturen voor het leveren van jeugdhulp waarvoor reeds een titel tot levering bestaat. Het Verzoek om toewijzing-bericht kan alleen gebruikt worden voor situaties waarbij het recht op jeugdhulp al vaststaat en is daarmee één van de rechtmatigheidsberichten. Met het Verzoek om toewijzing geeft de aanbieder aan dat de zorg is gestart. De gemeente stuurt altijd binnen drie werkdagen een retourbericht om aan te geven dat het Verzoek om toewijzing ontvangen is. De gemeente die het Verzoek om toewijzing ontvangt is verplicht om te toetsen of, op basis van het woonplaatsbeginsel, de client onder haar verantwoordelijkheid valt. Wanneer dat zo is, stuurt de gemeente de aanbieder een officiële toewijzing voor de te leveren jeugdhulp.

=== Toewijzing/beschikking (JW301) ===
Met de toewijzing geeft de gemeente een aanbieder opdracht tot levering van jeugdhulp voor een specifieke client. Het geeft de aanbieder het recht om de zorg te gaan leveren en is daarmee één van de rechtmatigheidsberichten. In het bericht wordt het toegewezen product omschreven. Dit toegewezen product kan aspecifiek zijn (dat wil zeggen dat alleen een productcategorie wordt toegewezen) of specifiek (dat wil zeggen dat binnen de productcategorie ook een specifieke productcode wordt toegewezen). In de toewijzing wordt aangegeven welke specifieke aanbieder welk product moet leveren, met een bepaalde omvang en voor een bepaalde periode. Dit kan een periode zonder einddatum zijn.

=== Starten Jeugdhulp (JW305) ===
Met het Startbericht geeft de aanbieder aan de gemeente door wanneer de levering gestart is. Het bericht is bedoeld om de gemeente inzicht te geven in het daadwerkelijk plaatsvinden van de levering van zorg en ondersteuning. Er kunnen geen rechten ontleend worden aan dit bericht, dat wil bijvoorbeeld zeggen dat er geen afhankelijkheid met de betaling (declaratie of facturatie) mag bestaan. Het Startbericht is daarmee één van de regieberichten.

=== Beeindigen jeugdhulp (JW307) ===
Met het Stopbericht geeft de aanbieder aan de gemeente door wanneer de levering beëindigd is en wat de reden is van de beëindiging. Het bericht is bedoeld om de gemeente inzicht te geven in het daadwerkelijk plaatsvinden van de levering van zorg en ondersteuning. Er kunnen geen rechten ontleend worden aan dit bericht, dat wil bijvoorbeeld zeggen dat er geen afhankelijkheid met de betaling (facturatie) mag bestaan. Het Stopbericht is daarmee één van de regieberichten. Indien de start van de levering is doorgegeven met een Startbericht, wordt de beëindiging van de levering altijd doorgegeven met een Stopbericht. De beëindiging kan plaatsvinden op initiatief van de gemeente: de aanbieder ontvangt een intrekkingsbericht van de gemeente. Met het Stopbericht geeft de aanbieder door wanneer de levering definitief gestopt is.

=== Beeindigen jeugdhulp (JW317) ===
Als de zorgaanbieder vaststelt dat de geleverde zorg tijdens de levering van de zorg aangepast moet worden, kan er een verzoek om wijziging (VOW) worden aangevraagd bij de gemeente.

=== Beeindigen jeugdhulp (JW319) ===
Als een gemeente nader onderzoek moet doen met betrekking tot een VOW of VOT, of als een verzoek wordt afgewezen, wordt het Jw319-antwoordbericht gebruikt.

== Registratie ==

=== Productcategorie ===
Voor de Jeugdwet-producten is landelijk een aantal productcategorieën vastgesteld, die verplicht gebruikt moeten worden in de berichten. Deze categorieën zijn over en weer vertaalbaar in de indeling die de Vereniging van Nederlandse Gemeenten (VNG) voorstelt voor de financiële verantwoording van Jeugdwet-voorzieningen. Zo kunnen de productcategorieën een plek krijgen in de landelijke financiële verantwoording die gemeenten moeten afleggen aan het ministerie van Binnenlandse Zaken. Ook uit de afstemming met CAK en SVB blijkt dat hun productindelingen goed passen.

=== Productcode ===
Onder de productcategorieën zijn productcodes gedefinieerd, als verbijzondering binnen een productcategorie. Deze codes, die specifieker beschrijven om welk product of welke dienst het gaat, zijn opgenomen in de standaardproductcodelijst Jeugdwet (JZ21). Gemeenten en aanbieders spreken onderling af welke van deze productcodes zij gebruiken, zodat de codes passen bij de gekozen Jeugdwet-uitvoering.

Zorginstituut Nederland adviseert gemeenten en aanbieders om zoveel mogelijk gebruik te maken van de codes op de standaardproductcodelijst, omdat dit bijdraagt aan minder administratieve variëteit. Gemeenten mogen besluiten om de standaardproductcodelijst niet te gebruiken. Zij mogen dan zelf productcodes definiëren, binnen de productcategorieën die zijn vastgesteld. Samen met de aanbieder leggen ze dan vast welke codes gebruikt mogen worden bij welke productcategorie. In dat geval adviseert het Zorginstituut om codes te kiezen die ''niet'' voorkomen op de standaardproductcodelijst.

=== Eenheid ===
De eenheid zegt iets over hoe de afrekening verloopt. De volgende eenheden zijn vanuit de informatiestandaard iJw 3.0 vastgesteld:

* 01 - Facturatie in geregistreerde minuten
* 04 - Facturatie in geregistreerde uren
* 14 - Facturatie in geregistreerde verblijfsdagen
* 16 - Facturatie in geregistreerde dagdelen
* 82 - Facturatie stuks output
* 83 - Facturatie volgens vastgesteld tarief (€)
* 84 – Facturatie stuks inspanningsgericht

Sinds 1 januari 2021 wordt de informatiestandaard iJw 3.0 gebruikt binnen de Jeugdwet. Vóór 2021 werd eenheid ’82 – Facturatie volgens arrangement’ gebruikt. Dit is opgesplitst in ‘82 – Facturatie stuks output’ en ’84 – stuks inspanningsgericht’. Outputgericht houdt in dat er afspraken zijn tussen gemeente en zorgaanbieder over de te behalen output. Daarbij hoeft niet vastgelegd te zijn hoe deze output wordt behaald. Inspanningsgericht houdt in dat er afspraken zijn tussen gemeente en zorgaanbieder wat betreft de levering van een product of dienst in een afgesproken tijdseenheid.

=== Frequentie ===
De frequentie geeft aan hoe frequent er gefactureerd zal gaan worden. De volgende frequenties zijn vastgesteld:

# - Per dag
# - Per week
# - Per 4 weken
# - Per maand
# - Per jaar
# - Totaal binnen geldigheidsduur beschikking

=== Volume ===
Het volume geeft het vastgestelde maximum aan en is afhankelijk van de eenheid. Met andere woorden, een volume van 10.000 betekent bij eenheid 01, 10.000 minuten, maar betekent bij eenheid 83, 10.000 euro.

=== Status ===
Er zijn 4 verschillende statussen van financiering in de jeugdmonitor, namelijk:

# ''Gefactureerd - V''an alle producten alle factuurmomenten.
# ''Onderhanden werk (OHW)-'' Van alle producten de waarde die nog niet gefactureerd is. De OHW waarde van een product wordt per eenheid anders berekend:
#* '''01:''' Som van de tijd van alle contacten na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''04:''' Som van de tijd van alle contacten na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''14:''' Som van alle verblijfsdagen na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''16:''' Som van alle dagdelen na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''82:''' Som van alle mijlpalen die wel behaald zijn maar nog niet gefactureerd zijn vermenigvuldigd met het afgesproken tarief.
#* '''83:''' Het afgesproken volume maal de restende looptijd (afhankelijk van frequentie) na laatste datum uit factuur.
#* '''84:''' Som van de productie
# ''Extra waarde reeds geopend -'' Van alle openstaande producten de extra verwachte waarde
# ''Nog te openen -'' De waarde van alle producten die nog geopend gaan worden (dus nog niet bestaan)

'''De prognose wordt als volgt berekend:'''

Per betalende instantie wordt de gemiddelde duur van een jeugd-product vermenigvuldigd met de gemiddelde productie op een jeugd-product. Deze wordt vermenigvuldigd met het aantal nog te verwachten te openen producten. Deze verwachting is gebaseerd op het aantal reeds geopende producten en het aantal nog resterende dagen in een jaar. Zodoende kan op elk moment van het schadelastjaar een schatting worden gemaakt van de nog te openen productie. Naarmate het jaar vordert, komt er meer data beschikbaar van reeds geopende producten en zal de prognose steeds nauwkeuriger worden.

{{VALUECARE}}

Jeugdmonitor

2021-12-14T09:03:40Z

Cbruin: Opmaak

De eerste versie van de Jeugdmonitor was beschikbaar als Excel-bestand. Vanaf de tweede versie is de jeugdmonitor niet meer beschikbaar als Excel-bestand, maar als tegels en dashboards die te vinden zijn in het ValueCare portaal.

== '''Doelgroep''' ==
De jeugdmonitor is gemaakt om de financiële resultaten binnen de Jeugdzorg per jaar per gemeente te monitoren. Kinderen en jongeren onder de 18 jaar die hulp, zorg of ondersteuning nodig hebben vallen in de meeste gevallen onder de Jeugdwet. Deze worden gemonitord in de Jeugdwet.

=== Verlengde jeugdhulp ===
Normaal gesproken vallen cliënten die jonger zijn dan 18 jaar in aanmerking voor hulp binnen de Jeugdwet. Echter, kunnen cliënten van 18 tot 23 jaar in aanmerking komen voor verlengde jeugdhulp, als er sprake is van de volgende voorwaarden:

# Er is geen financiering beschikbaar (bijv. vanuit ZvW, Wlz, WMO, ZvW) nadat de cliënt 18 is geworden.
# Naast (1) wordt er voldaan minstens één van volgende criteria:
#* Cliënt heeft jeugdhulp gehad vóór het 18e jaar en de gemeente vindt verdere jeugdhulp noodzakelijk
#* Cliënt heeft jeugdhulp gehad vóór het 18e jaar en binnen een half jaar na het 18 jaar komt cliënt opnieuw in aanmerking voor jeugdhulp
#* Cliënt heeft pleegzorg en voortzetting van de pleegzorg is nodig

Een maatregel is uitgesproken met betrekking op een strafbaar feit dat is begaan tussen het 18e en 23e jaar.

== Financiering vanuit gemeenten ==
In de GGZ wordt de jeugdzorg sinds 1 januari 2018 gefinancierd vanuit gemeenten. Er is onder andere gekozen voor gemeentelijke financiering, zodat de zorg lokaal georganiseerd kan worden, dichter bij het gezin. Met de introductie van de Jeugdwet is de DBC-systematiek die vóór 2018 van toepassing was op de Jeugdzorg, niet meer in gebruik. Vóór 2018 werd de jeugdzorg geregistreerd in DBC's en viel de bekostiging onder de ZvW (Zorgverzekeringswet), waarvan een groot deel binnen de AWBZ (Algemene Wet Bijzondere Ziektekosten) viel.

Om de financiering en administratie binnen de Jeugdwet goed te organiseren is er een landelijke berichtenstandaard opgezet. Dit betreft met name een standaard voor het berichtenverkeer tussen gemeenten en zorgaanbieders. Hoe deze berichtenstandaard werkt, lees je hieronder. Allereerst vind je een korte uitleg van de berichten met betrekking tot het starten en beëindigen van de zorg. Dat zijn de berichten die actief gecontroleerd binnen ValueCare. Daarnaast vind je een overzicht van alle berichten.

=== Verzoek om toewijzing (JW315) ===
De zorgaanbieder verzoekt de gemeente om een toewijzing te sturen voor het leveren van jeugdhulp waarvoor reeds een titel tot levering bestaat. Het Verzoek om toewijzing-bericht kan alleen gebruikt worden voor situaties waarbij het recht op jeugdhulp al vaststaat en is daarmee één van de rechtmatigheidsberichten. Met het Verzoek om toewijzing geeft de aanbieder aan dat de zorg is gestart. De gemeente stuurt altijd binnen drie werkdagen een retourbericht om aan te geven dat het Verzoek om toewijzing ontvangen is. De gemeente die het Verzoek om toewijzing ontvangt is verplicht om te toetsen of, op basis van het woonplaatsbeginsel, de client onder haar verantwoordelijkheid valt. Wanneer dat zo is, stuurt de gemeente de aanbieder een officiële toewijzing voor de te leveren jeugdhulp.

=== Toewijzing/beschikking (JW301) ===
Met de toewijzing geeft de gemeente een aanbieder opdracht tot levering van jeugdhulp voor een specifieke client. Het geeft de aanbieder het recht om de zorg te gaan leveren en is daarmee één van de rechtmatigheidsberichten. In het bericht wordt het toegewezen product omschreven. Dit toegewezen product kan aspecifiek zijn (dat wil zeggen dat alleen een productcategorie wordt toegewezen) of specifiek (dat wil zeggen dat binnen de productcategorie ook een specifieke productcode wordt toegewezen). In de toewijzing wordt aangegeven welke specifieke aanbieder welk product moet leveren, met een bepaalde omvang en voor een bepaalde periode. Dit kan een periode zonder einddatum zijn.

=== Starten Jeugdhulp (JW305) ===
Met het Startbericht geeft de aanbieder aan de gemeente door wanneer de levering gestart is. Het bericht is bedoeld om de gemeente inzicht te geven in het daadwerkelijk plaatsvinden van de levering van zorg en ondersteuning. Er kunnen geen rechten ontleend worden aan dit bericht, dat wil bijvoorbeeld zeggen dat er geen afhankelijkheid met de betaling (declaratie of facturatie) mag bestaan. Het Startbericht is daarmee één van de regieberichten.

=== Beeindigen jeugdhulp (JW307) ===
Met het Stopbericht geeft de aanbieder aan de gemeente door wanneer de levering beëindigd is en wat de reden is van de beëindiging. Het bericht is bedoeld om de gemeente inzicht te geven in het daadwerkelijk plaatsvinden van de levering van zorg en ondersteuning. Er kunnen geen rechten ontleend worden aan dit bericht, dat wil bijvoorbeeld zeggen dat er geen afhankelijkheid met de betaling (facturatie) mag bestaan. Het Stopbericht is daarmee één van de regieberichten. Indien de start van de levering is doorgegeven met een Startbericht, wordt de beëindiging van de levering altijd doorgegeven met een Stopbericht. De beëindiging kan plaatsvinden op initiatief van de gemeente: de aanbieder ontvangt een intrekkingsbericht van de gemeente. Met het Stopbericht geeft de aanbieder door wanneer de levering definitief gestopt is.

=== Beeindigen jeugdhulp (JW317) ===
Als de zorgaanbieder vaststelt dat de geleverde zorg tijdens de levering van de zorg aangepast moet worden, kan er een verzoek om wijziging (VOW) worden aangevraagd bij de gemeente.

=== Beeindigen jeugdhulp (JW319) ===
Als een gemeente nader onderzoek moet doen met betrekking tot een VOW of VOT, of als een verzoek wordt afgewezen, wordt het Jw319-antwoordbericht gebruikt.

== Registratie ==

=== Productcategorie ===
Voor de Jeugdwet-producten is landelijk een aantal productcategorieën vastgesteld, die verplicht gebruikt moeten worden in de berichten. Deze categorieën zijn over en weer vertaalbaar in de indeling die de Vereniging van Nederlandse Gemeenten (VNG) voorstelt voor de financiële verantwoording van Jeugdwet-voorzieningen. Zo kunnen de productcategorieën een plek krijgen in de landelijke financiële verantwoording die gemeenten moeten afleggen aan het ministerie van Binnenlandse Zaken. Ook uit de afstemming met CAK en SVB blijkt dat hun productindelingen goed passen.

=== Productcode ===
Onder de productcategorieën zijn productcodes gedefinieerd, als verbijzondering binnen een productcategorie. Deze codes, die specifieker beschrijven om welk product of welke dienst het gaat, zijn opgenomen in de standaardproductcodelijst Jeugdwet (JZ21). Gemeenten en aanbieders spreken onderling af welke van deze productcodes zij gebruiken, zodat de codes passen bij de gekozen Jeugdwet-uitvoering.

Zorginstituut Nederland adviseert gemeenten en aanbieders om zoveel mogelijk gebruik te maken van de codes op de standaardproductcodelijst, omdat dit bijdraagt aan minder administratieve variëteit. Gemeenten mogen besluiten om de standaardproductcodelijst niet te gebruiken. Zij mogen dan zelf productcodes definiëren, binnen de productcategorieën die zijn vastgesteld. Samen met de aanbieder leggen ze dan vast welke codes gebruikt mogen worden bij welke productcategorie. In dat geval adviseert het Zorginstituut om codes te kiezen die ''niet'' voorkomen op de standaardproductcodelijst.

=== Eenheid ===
De eenheid zegt iets over hoe de afrekening verloopt. De volgende eenheden zijn vanuit de informatiestandaard iJw 3.0 vastgesteld:

* 01 - Facturatie in geregistreerde minuten
* 04 - Facturatie in geregistreerde uren
* 14 - Facturatie in geregistreerde verblijfsdagen
* 16 - Facturatie in geregistreerde dagdelen
* 82 - Facturatie stuks output
* 83 - Facturatie volgens vastgesteld tarief (€)
* 84 – Facturatie stuks inspanningsgericht

Sinds 1 januari 2021 wordt de informatiestandaard iJw 3.0 gebruikt binnen de Jeugdwet. Vóór 2021 werd eenheid ’82 – Facturatie volgens arrangement’ gebruikt. Dit is opgesplitst in ‘82 – Facturatie stuks output’ en ’84 – stuks inspanningsgericht’. Outputgericht houdt in dat er afspraken zijn tussen gemeente en zorgaanbieder over de te behalen output. Daarbij hoeft niet vastgelegd te zijn hoe deze output wordt behaald. Inspanningsgericht houdt in dat er afspraken zijn tussen gemeente en zorgaanbieder wat betreft de levering van een product of dienst in een afgesproken tijdseenheid.

=== Frequentie ===
De frequentie geeft aan hoe frequent er gefactureerd zal gaan worden. De volgende frequenties zijn vastgesteld:

# - Per dag
# - Per week
# - Per 4 weken
# - Per maand
# - Per jaar
# - Totaal binnen geldigheidsduur beschikking

=== Volume ===
Het volume geeft het vastgestelde maximum aan en afhankelijk van de eenheid. Met andere woorden een volume van 10.000 betekent bij eenheid 01, 10.000 minuten, maar betekent bij eenheid 83, 10.000 euro.

=== Status ===
Er zijn 4 verschillende statussen van financiering in de jeugdmonitor, namelijk:

# ''Gefactureerd - V''an alle producten alle factuurmomenten.
# ''Onderhanden werk (OHW)-'' Van alle producten de waarde die nog niet gefactureerd is. De OHW waarde van een product wordt per eenheid anders berekend:
#* '''01:''' Som van de tijd van alle contacten na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''04:''' Som van de tijd van alle contacten na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''14:''' Som van alle verblijfsdagen na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''16:''' Som van alle dagdelen na de laatste datum tot uit factuur vermenigvuldigd met het afgesproken tarief.
#* '''82:''' Som van alle mijlpalen die wel behaald zijn maar nog niet gefactureerd zijn vermenigvuldigd met het afgesproken tarief.
#* '''83:''' Het afgesproken volume maal de restende looptijd (afhankelijk van frequentie) na laatste datum uit factuur.
#* '''84:''' Som van de productie
# ''Extra waarde reeds geopend -'' Van alle openstaande producten de extra verwachte waarde
# ''Nog te openen -'' De waarde van alle producten die nog geopend gaan worden (dus nog niet bestaan)

'''De prognose wordt als volgt berekend:'''

Per betalende instantie wordt de gemiddelde duur van een jeugd-product vermenigvuldigd met de gemiddelde productie op een jeugd-product. Deze wordt vermenigvuldigd met het aantal nog te verwachten te openen producten. Deze verwachting is gebaseerd op het aantal reeds geopende producten en het aantal nog resterende dagen in een jaar. Zodoende kan op elk moment van het schadelastjaar een schatting worden gemaakt van de nog te openen productie. Naarmate het jaar vordert, komt er meer data beschikbaar van reeds geopende producten en zal de prognose steeds nauwkeuriger worden.

{{VALUECARE}}