Toelichting_gegevensextractie_LDK_v1.2 aanpassingen in rood

Toelichting Gegevensextractie
Landelijke Database Kwaliteit
Beheer en uitvoering door
Kenmerk:
Toelichting_Gegevensextractie_LDK_v1.2
Versie:
1.2
Datum:
21 september 2015
1
Versiebeheer
Versie
Auteurs
Status
1.0
Di-Janne Barten
Bram Elffers
Jan Gravestein
Di-Janne Barten
Bram Elffers
Jan Gravestein
Lando Koppes
Di-Janne Barten
Bram Elffers
Jan Gravestein
Lando Koppes
Concept
1.1
1.2
Opmerkingen
Definitief
Definitief
Wijzigingen
Versie
1.1
Meest relevante wijzigingen


1.2
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Entiteiten ‘AanvullendOnderzoek’ en ‘MetingAanvullendOnderzoek’ zijn geïntegreerd in de
entiteiten ‘Meetinstrument’ respectievelijk ‘Respons’. Zie
“FunctioneelOntwerp_MeetinstrumentLDK_v1.1” voor de inhoudelijke consequenties van
deze verschuiving
In het document “FunctioneelOntwerp_MeetinstrumentenLDK_v1.1” is onderscheid
aangebracht tussen meetinstrumenten die verplicht moeten worden opgenomen in de
extractie en welke (nog) facultatief zijn. De verplichte meetinstrumenten komen overeen met
de (operationalisatie van) meetinstrumenten zoals beschreven in de laatste versie van MKIB
(3.1) en Achmea.
XSD: Bij ‘Antwoord’ en bij ‘SchaalNaam’ is absolute lengte aangepast naar maximale lengte.
XSD: Bij ‘Prestatiecode’ is de restrictie 'numeriek 6 tekens' aangepast naar 'alfanumeriek,
maximaal 6 tekens'.
XSD: Attribuut 'BehandelplanVastgelegd' is toegevoegd.
Extractieperiode van eerste aanlevering en vervolgaanleveringen is aangepast.
Meetinstrumenten: GPE vervangen door GPE-5.
Meetinstrumenten toegevoegd: 1) GPE dagelijkse activiteiten, 2) GPE tevredenheid, en 3) GPE
loopafstand.
Meetinstrumenten: Active Straight Leg Raise Test (ASLRT) item vragen 2x linker been
gecorrigeerd in 1x linker been en 1x rechter been.
Meetinstrumenten: Acute Low Back Pain Screening Questionnaire (ALBPSQ): Eerste item als
meerkeuzevraag geoperationaliseerd.
Meetinstrumenten: uit Functiescore de Bie is de Tegner score verwijderd. De Tegner score zit
nog wel als afzonderlijk meetinstrument in het Functioneel Ontwerp.
Meetinstrumenten: naamgeving ‘Hand Held Dynamometer (HHD)’ aangepast in
‘Handknijpkrachtmeter (HandKnijp)’.
Meetinstrumenten: PAQ verwijderd.
Meetinstrumenten: Naamgeving gewijzigd: Short Form 36 heet nu RAND 36 (inhoud van SF36
in versie 1.1 betrof al de RAND 36).
Geëxpliciteerd: ‘Opt-out’ is default.
2
Inhoud
1.
Inleiding ......................................................................................................................................... 4
2.
Procedure gegevensaanlevering en -verwerking .......................................................................... 4
3.
Inhoud gegevensextractie ............................................................................................................. 6
3.1 Functioneel ontwerp .................................................................................................. 6
Naamgeving bestand ........................................................................................ 6
Pseudonimisatie................................................................................................ 7
Veld gevuld ja/nee ............................................................................................ 7
3.2 XML Schema Definition .............................................................................................. 8
4.
Gegevensvalidatie ......................................................................................................................... 9
4.1 Inhoudelijk validatieproces door het NIVEL ............................................................... 9
4.2 Verwerkingsverslag van het NIVEL............................................................................ 10
3
1.
Inleiding
Stichting Keurmerk Fysiotherapie richt zich op de kwaliteit van het fysiotherapeutisch handelen.
De ambitie is om fysiotherapeuten inzicht te geven in de kwaliteit van hun fysiotherapeutisch
handelen, als start van een proces waarin continu gewerkt wordt aan het verbeteren daarvan.
Het Keurmerk zorgt er daarmee voor dat fysiotherapeuten die op deze manier werken aan de
kwaliteit van het fysiotherapeutisch handelen herkenbaar zijn voor zorgverzekeraars, patiënten en
overheid, zonder dat zij worden gehinderd door overbodige administratieve lasten.
Het werken aan kwaliteit uit zich in verschillende aspecten. Eén van de aspecten is deelname aan de
Landelijke Database Kwaliteit (LDK). De LDK bevat data uit alle fasen van het fysiotherapeutische
handelen, inclusief de uitkomst van de behandeling van alle patiënten die in de praktijk behandeld
worden én geen bezwaar hebben gemaakt tegen gebruik van hun gegevens. Dataverzameling vindt
plaats op continue basis. Er is gekozen om de dataverzameling zoveel mogelijk aan te laten sluiten bij
de standaard verslaglegging in de praktijksoftware. Dit heeft meerdere voordelen:



De administratieve belasting voor deelnemende fysiotherapeuten wordt geminimaliseerd.
De extractie is uniform voor alle verschillende Elektronische Patiënten Dossiers (EPD’s)
De belasting voor EPD-leveranciers om de extractiefunctionaliteit te realiseren is behapbaar.
Dit document vormt een toelichting op de functionele en technische specificaties voor de
extractiefunctionaliteit – versie 1.2 ten behoeve van de LDK. De specificaties zijn opgesteld door het
NIVEL in opdracht van en in samenwerking met de Stichting Keurmerk Fysiotherapie.
2.
Procedure gegevensaanlevering en -verwerking
Dataverzameling ten behoeve van de LDK vindt plaats in de praktijk. Alle nog openstaande en reeds
afgesloten behandelepisodes, waarin een behandelcontact heeft plaatsgevonden op of na de eerste
dag van de maand voorafgaand aan de maand waarin de eerste aanlevering plaatsvindt, worden
geïncludeerd in de eerste gegevensextractie (dus ook van niet-gedeclareerde zorg). Gegevens van
patiënten die bezwaar hebben gemaakt tegen gegevensextractie worden buiten beschouwing
gelaten. Na de eerste extractie wordt vervolgens eens per maand een gegevensextractie gemaakt.
Deze vervolgextracties bevatten de gegevens van nieuwe behandelepisodes en de gewijzigde en
ongewijzigde gegevens van behandelepisodes waarin een mutatie heeft plaatsgevonden sinds de
laatste aanlevering.
Voordat de gegevensextractie in XML-formaat naar het NIVEL verzonden worden vindt
pseudonimisatie van privacygevoelige gegevens plaats, zodat de gegevens niet meer herleidbaar zijn
tot individuele personen. In het kader van NIVEL Zorgregistraties zijn afspraken vastgelegd over de
omgang met privacygevoelige gegevens in het zogenaamde Privacyreglement. In het kader van de
LDK zullen dezelfde afspraken gehanteerd worden. De pseudonimisatie verloopt via de Privacy- en
4
Verzendmodule en de Centrale Module TTP van ZorgTTP. NIVEL ontvangt een gepseudonimiseerd
bestand via de Doel- en Retour module.
Na ontvangst van het gepseudonimiseerde bestand voert het NIVEL een inhoudelijke validatie uit (zie
hoofdstuk 4). Resultaten worden gerapporteerd in een verwerkingsverslag. Afhankelijk van de
uitkomst van de validatie wordt de gegevensaanlevering afgesloten of wordt de praktijk gevraagd
opnieuw een extractie te maken over dezelfde periode na herstel van onvolkomenheden.
Na opname van de data in de LDK genereert het NIVEL feedbackrapportages voor de Stichting
Keurmerk Fysiotherapie en voor deelnemende praktijken (zie figuur 1)
Praktijk
ZorgTTP
NIVEL
Start (nieuwe)
aanlevering
XML bestand
Privacy- en
Verzendmodule
Herstel van
onvolkomenheden
Centrale Module
TTP
Doel- en Retour
Module
Validering
XML-bestand
Opname in
Landelijke
Database Kwaliteit
Verwerkingsverslag
Feedbackrapportages
Keurmerk &
deelnemende
praktijken
aanlevering voldoet niet
Controle
aanlevering
aanlevering voldoet
Einde
gegevensaanlevering
Einde
gegevensverwerking
Figuur 1 Procedure gegevensaanlevering en gegevensverwerking ten behoeve van Landelijke Database Kwaliteit
5
3.
Inhoud gegevensextractie
3.1 Functioneel ontwerp
Een functionele beschrijving van de volledige gegevensextractie is terug te vinden in het document
‘FunctioneelOntwerp_SpecificatieLDK_v1.2.xlsx’. Hierin worden alle attributen beschreven,
beargumenteerd en geoperationaliseerd. De uit te vragen klinimetrie is beschreven in een
afzonderlijk document, te weten ‘FunctioneelOntwerp_MeetinstrumentenLDK_v1.2.xlsx’. Hierin staat
een gedetailleerde omschrijving van ieder meetinstrument, zoals het versienummer, de itemvragen
en bijbehorende volgorde en de mogelijke antwoorden per item. Veelal betreft de gegevensuitvraag
over klinimetrie zogenaamde Patient Reported Outcome Measures (PROMs). Bij versie 1.2 wordt de
verplichte uitvraag van klinimetrie beperkt tot de meetinstrumenten beschreven in de laatste versie
van MKIB (3.1) en de kwaliteitsindicatoren gevraagd door Achmea. Daarnaast wordt (eveneens
verplicht) een fictief meetinstrument ‘AanvullendOnderzoek’ benoemd, waar therapeuten gegevens
kunnen registeren ten behoeve van deelname van een kortdurend, lokaal, (wetenschappelijk)
onderzoek. De patiënt geeft actief toestemming voor deelname aan zo’n aanvullend onderzoek. De
overige beschreven meetinstrumenten zijn in versie 1.2 van de LDK nog facultatief.
Gegevens worden maandelijks aangeleverd in XML-formaat. Het extractiebestand bevat gegevens
van één of meerdere praktijken. Afhankelijk van de EPD-leverancier kan het voorkomen dat de
aanlevering beperkt wordt tot behandelepisodes uitgevoerd op één locatie / vestiging van een
praktijk; wanneer de praktijk meerdere locaties heeft, zullen meerdere aanleveringen nodig zijn. Het
is echter ook mogelijk dat in één aanlevering de behandelepisodes van meerdere locaties worden
opgenomen. Data uit één praktijk kan één of meerdere patiënten omvatten. Van iedere patiënt
kunnen één of meer behandelepisodes toegevoegd zijn, waarin één of meerdere verrichtingen
hebben plaatsgevonden en/of één of meerdere metingen hebben plaatsgevonden.
Gegevens van een patiënt worden opgenomen op basis van ‘opt-out’. Extractie van de gegevens van
een patiënt is de default-situatie. Indien een patiënt bij zijn behandelaar aangeeft dat hij bezwaar
heeft tegen opname van zijn gegevens in de LDK dan behoort de behandelaar dit aan te geven in het
EPD. Het EPD moet deze mogelijkheid bieden.
Het aangeleverde extractiebestand bevat gegevens aangemaakt / aangepast in de afgelopen 2
maanden. Relaties tussen de verschillende entiteiten in het XML-bestand zijn weergegeven in het
Entiteiten Relatie Diagram van figuur 2.
Naamgeving bestand
Het patroon waaraan de bestandsnaam moet voldoen is:
"LDK_[versienummer extractiespecificatie]_[naam leverancier]_[naam softwarepakket]_[agb-code
FT-praktijk]_[extractiedatum/tijdstip].xml"
6
Bijvoorbeeld:
“LDK_0101_VoorbeeldLeverancier_VoorbeeldPakket_04015432_20150402140657.xml”
De bestandnaam bevat uitsluitend alfanumerieke tekens en underscores voor de extensie.
Toelichting naamgeving
‘LDK’ is nodig omdat de Privacy en Verzendmodule van ZorgTTP het type extractie bepaalt aan de
hand van de bestandsnaam.
‘Versienummer extractiespecificatie’ verwijst naar het versienummer van de extractiespecificatie
waaruit het XML bestand voortvloeit.
‘Naam leverancier’ is de naam van de EPD-leverancier die de extractie instuurt respectievelijk de
naam van de EPD-leverancier die de praktijksoftware aan de praktijk(en) levert.
‘Naam softwarepakket’ is de naam van het EPD waaruit data zijn geëxtraheerd.
‘AGB-code-FT-praktijk’ is de AGB-code van de praktijk waaruit data zijn geëxtraheerd; indien extractie
gegevens van meerdere praktijken bevat, dan de AGB-code van eerste praktijk opnemen.
‘Extractiedatum/tijdstip’ wordt weergegeven in het formaat yyyymmddhhmmss.
Pseudonimisatie
Zoals in hoofdstuk 2 reeds benoemd worden gegevens uit de praktijk via een TTP (ZorgTTP) aan het
NIVEL geleverd. De volgende attributen uit de entiteit Patient worden gepseudonimiseerd:
 het BurgerServiceNummer (BSN; uniek voor alle legale ingezetenen van Nederland);
 de combinatie Geslacht, Geboortedatum en Postcodegebied (uniek voor ±80% van de
bevolking); het NIVEL ontvangt naast dit ‘PGG-pseudoniem’ wel Geboortejaar, Geslacht en
(4-cijferig) Postcodegebied;
 het Patientnummer in de praktijksoftware (Patientid); wanneer het patientnummer
ongepseudonimiseerd bij het NIVEL bekend zou zijn, zou iemand die toegang heeft tot
zowel de praktijkadministratie als de NIVEL-data de laatste kunnen herleiden.
BehandelEpisodeNummer wordt niet gepseudonimiseerd door de TTP. Echter, eveneens om privacyredenen mag voor het attribuut BehandelEpisodeNummer in entiteit BehandelEpisode geen
variabele zonder meer worden gebruikt die ook in de praktijkadministratie voorkomt (om
vergelijkbare redenen als het Patientnummer). In het geval dat een bestaande variabele uit de
praktijksoftware als basis hiervoor dient, moet deze door de softwareleverancier zelf versleuteld
(bijvoorbeeld gehashed) worden. Het BehandelEpisodeNummer mag per praktijk maar één keer
voorkomen en dient consistent en herkenbaar te zijn over verschillende aanleveringen.
Veld gevuld ja/nee
Een aantal attributen betreft de vraag: is de rubriek gevuld of niet. In dergelijke gevallen wordt
gecontroleerd of er één of meer tekens staat die geen ‘white space’ zijn.
7
Figuur 2
Entiteiten-Relatie-Diagram Landelijke Database Kwaliteit – versie 1.2
3.2 XML Schema Definition
Naast een functioneel ontwerp wordt een XSD aangeleverd ('extractie_ldk_v1_1.xsd'). De XSD is
direct gekoppeld aan de Privacy en Verzend Module van ZorgTTP. De XSD voor de huidige extractie is
te vinden op de website van de Stichting Keurmerk Fysiotherapie.
8
4.
Gegevensvalidatie
Gegevens die via ZorgTTP aan het NIVEL geleverd worden, worden door ZorgTTP en door het NIVEL
inhoudelijk gevalideerd. De resultaten van de validaties worden aan de praktijk teruggegeven via
anonieme verwerkingsverslagen op geaggregeerd niveau waarin de frequenties van foutcodes en
waarschuwingscodes vermeld worden.
Na verzending van een gegevensbestand via de Privacy- en Verzendmodule stuurt ZorgTTP een
verwerkingsverslag naar de praktijk (zie documentatie ZorgTTP).
4.1 Inhoudelijk validatieproces door het NIVEL
Bij de inhoudelijke validatie wordt onderscheid gemaakt tussen:

Foutcodes die leiden tot het apart houden van data; gegevens moeten hersteld worden en
opnieuw worden aangeleverd door de praktijk.

Waarschuwingscodes die leiden tot een waarschuwing voor ontbrekend / ongeldige
gegevens in de aanlevering; gegevens worden facultatief opnieuw aangeleverd.
Foutcodes
 Ontbreken van PraktijkAGBCode
 Ontbreken van Softwareleverancier
 Ontbreken van VersienummerSoftware
 Ontbreken van Postcode
 Ontbreken van Huisnummer
 Systematisch ontbreken van BurgerServiceNummer, de combinatie Postcodegebied,
Geslacht en Geboortedatum en/of Patientid; er is sprake van ‘systematisch ontbreken’
wanneer in 100% van de patiënten (één van de) genoemde gegevens ontbreken.
 Systematisch ontbreken van BehandelEpisodeNummer; er is sprake van ‘systematisch
ontbreken’ wanneer in 100% van de behandelepisodes het BehandelEpisodeNummer
ontbreekt.
Waarschuwingscodes
In de volgende gevallen worden de aangeleverde data opgenomen in de LDK, maar krijgt de
aanleverende partij een waarschuwing voor het foutief invoeren van een attribuut met de vraag deze
fout(en) in de volgende aanlevering te herstellen.
Op niveau praktijk:
 Postcode is geen geldige postcode. Een geldige postcode heeft de vorm van 4 cijfers en
twee letters
Op niveau patiënt:
 Incidenteel ontbreken van PatientId
 Incidenteel ontbreken van Geslacht of registratie van ongeldig Geslacht; waarde ongelijk
aan 0,1,2 of 9
 Incidenteel ontbreken van Geboortedatum
 Incidenteel ontbreken van Postcodegebied
 Incidenteel ontbreken van BurgerServiceNummer
9

Ontbreken van Zorgverzekeraar of registratie van ongeldige Zorgverzekeraar; waarde is
numeriek en bestaat uit 4 karakters
Op niveau BehandelEpisode:
 Incidenteel ontbreken van BehandelEpisodeNummer
 Ontbreken van DatumAanmelding
 Ontbreken van ToegangParamedicus
 Ontbreken van HulpvraagVastgelegd
 Ontbreken van DiagnoseVastgelegd
 Ontbreken van HoofddoelVastgelegd
 Ontbreken van LocatiePathologieCode
 Registratie van ongeldig DuurFunctioneringsProblemen (negatief getal)
 Registratie van ongeldig BeloopFunctioneringsProblemen (code komt niet voor op codelijst
LDK001)
 Registratie van ongeldig VerwachtHerstel (code komt niet voor op codelijst LDK002)
 Registratie van ongeldig EindresultaatBehaald (code komt niet voor op de codelijst LDK003)
Op niveau Verrichting:
 Ontbreken van DatumVerrichting wanneer er een verrichting heeft plaatsgevonden
 Ontbreken van BehandelaarAGBCode wanneer er een verrichting of meting heeft
plaatsgevonden
 Ontbreken van PrestatieCode wanneer er een verrichting heeft plaatsgevonden of
registratie van een prestatiecode die niet voorkomt op Vektis standaard PM304
Op niveau Meetinstrument:
 Ontbreken van MeetinstrumentCode wanneer er een meting heeft plaatsgevonden of
registratie van een meetinstrumentcode die niet voorkomt op codelijst LDK004
 Ontbreken van VersieNummer wanneer er een meting heeft plaatsgevonden
 Ontbreken van DatumAfname wanneer er een meting heeft plaatsgevonden
 Ontbreken van BehandelaarAGBCode wanneer er een meting heeft plaatsgevonden
4.2 Verwerkingsverslag van het NIVEL
Na inhoudelijke validatie van elke gegevensaanlevering wordt een verwerkingsverslag naar de
praktijk gestuurd. Dit verwerkingsverslag koppelt op geaggregeerd niveau de resultaten van de
inhoudelijke validatie terug aan de praktijk. Drie scenario’s zijn mogelijk:
 Scenario 1: er worden foutcodes en/of waarschuwingscodes gemeld. Fouten moeten
hersteld worden en praktijken wordt gevraagd een nieuwe aanlevering te doen over
dezelfde periode.
 Scenario 2: er worden waarschuwingscodes gemeld. Praktijken bepalen zelf of ze de
onvolkomenheden herstellen en een nieuwe aanlevering doen of de gegevensaanlevering
afsluiten.

Scenario 3: er worden foutcodes noch waarschuwingscodes gemeld. Praktijken wordt
gemeld dat de gegevensaanlevering is afgerond.
10