Aan de slag met trefwoordextractie uit meldingen

@hleijen: Binnen Gelre ziekenhuizen hebben we inmiddels trefwoordextractie aangezet.

De dynamische diagrammen die je kunt maken (Veel voorkomende trefwoorden en Opvallende trefwoorden) zien er erg goed uit en bieden veel mogelijkheden voor extra analyse. Graag zouden we nog wat verbeteringen zien:

1. Een zoekveld in de linker kolom van Veel voorkomende trefwoorden. Op die manier hoef je niet de vaak lange lijst af te lopen maar kun je snel gericht zoeken.
2. De mogelijkheid om te kunnen filteren (bijvoorbeeld op organisatie-eenheid) binnen het publieke filter dat gebruikt wordt voor het diagram. Je kunt wel sorteren op de verschillende velden maar niet filteren. 

@JopHelleman :
iProva voert de trefwoordextractie uit voor alle meldingen; je kan dit niet instellen per meldingstype.
In de rapportage (interactieve diagrammen) bepaal je zelf welk filter je toepast, dus daar kan je prima informatie beperken tot een specifiek meldingstype als je dat wilt.

Op dit moment wordt trefwoordextractie toegepast op:

• alle velden op het meldformulier van een melding, van de veldtypes Tekst en Tekst met opmaak.
• Tekst die wordt ingevuld in het "anders, namelijk" tekstveld bij lijstvelden waarbij de "anders, namelijk" optie wordt aangeboden

De trefwoordextractie wordt gestart zodra de melding wordt verzonden. Op dat moment kunnen er dus in potentie nog persoonsgegevens in zitten. Dat wil nog niet zeggen dat die persoonsgegevens ook daadwerkelijk zichtbaar worden in de rapportage - maar het kan inderdaad wel gebeuren. In iProva 5.13 geven we je daarom nog wat aanvullende tools om dergelijke ‘ongewenste’ keywords te kunnen onderdrukken. 

 

Het antwoord op de laatste vraag volgt uit het bovenstaande; nee, de velden op het coordinatorformulier worden vooralsnog niet meegenomen.

@Silvia van Gils ja, die beer op de weg hadden wij wel verwacht ;-)
Vanuit de training wordt daarom gelinkt naar een document wat er wat meer info over geeft, maar ik zal de vraag hier ook beantwoorden.
Wat er naar de trefwoord-extractie service wordt gestuurd is:

• alle velden op het meldformulier van een melding, van de veldtypes Tekst en Tekst met opmaak.
• Tekst die wordt ingevuld in het "anders, namelijk" tekstveld bij lijstvelden waarbij de "anders, namelijk" optie wordt aangeboden

Dat betekent bijvoorbeeld dat als je een apart veld (van type Numeriek) hebt voor het patiëntnummer, dat níet mee wordt verstuurd. Tekstvelden dus wel, en in iProva versie 5.12.0 hebben we verder geen instelmogelijkheden om daarbij zelf nog bepaalde velden te kunnen uitsluiten.

De essentie van het probleem zit hem doorgaans in de beschrijving van het het (bijna-) incident in eigen woorden. In de meeste zorginstellingen is het geloof ik beleid dat daar in generieke termen wordt gesproken (de patiënt; de heer; mevr. ) - maar de praktijk is doorgaans dat er toch wel eens namen of rugnummers voorkomen in die tekst.
Dit lossen we niet op door vóór het versturen van de teksten naar de cloud service velden weg te filteren - want als je het hele 'beschrijving' veld weglaat, dan houdt je niet zinvols over om trefwoorden uit te halen.

We zijn overigens wel actief aan het onderzoeken of we het herkennen en wissen van persoonsnamen kunnen inbouwen ín de pijplijn voor trefwoordextractie.
Daarmee zouden we kunnen voorkomen dat er persoonsnamen terecht komen ín de trefwoorden. Dat gebeurt nu overigens al heel weinig - maar we maken die kans graag nog kleiner.
Voor het versturen naar de cloud maakt het echter geen verschil: pas als de gegevens in de cloud zijn, kunnen we er een scala aan slimme technieken op loslaten om die anonimisering uit te voeren.

Goede suggesties @Erik Balduk. Er komen zeker nog de nodige verbeteringen aan in komende releases. Allereerst werken we aan de mogelijkheid om de trefwoorden die je ziet te optimaliseren (ongewenste trefwoorden onderdrukken, trefwoorden die het zelfde betekenen samenvoegen). 
Onder voorbehoud in iProva 5.13.

Daarna gaan we zeker verder met het verrijken van de functionaliteit. Input zoals deze is daarbij zeer welkom!

Zie Innovatieproject "(Incident)meldingen anonimiseren" - update augustus 2022 | Infoland Community voor een update hierover.

@Ron Hogeland , @Michel Pot , @Silvia van Gils   excuses, door omstandigheden ben ik een tijd lang minder betrokken geweest bij dit onderwerp, en is reactie uitgebleven.

Het goede nieuws is dat het inmiddels weer terug op de radar is.
In de recente paneldiscussie over Zenya FLOW komt de behoefte om meer inzicht te verkrijgen uit informatie die in de vorm van vrije tekst in meldingen is ingevoerd, opnieuw naar boven.
We gaan hier in doorontwikkeling dan ook zeker weer aandacht aan geven.

Daarbij liggen op dit moment beide eerder genoemde routes nog open:

• verbeteren van de AI voor het automatisch herkennen en anonimiseren/schrappen van persoonsnamen en andere persoonsgegevens uit de teksten
• kunnen uitsluiten van velden waarvan je weet dat ze per definitie persoonsgegevens bevatten

Oproep

Voor de eerste route (verbeteren van de AI) geldt dat we momenteel onderzoeken welke technologische progressie er is geweest sinds 2019. We spreken hierover met bedrijven die gespecialiseerd zijn in (geautomatiseerd) anonimiseren.
Om goed te kunnen beoordelen hoe goed die techniek écht zijn werk doet, hebben we behoefte aan voorbeelden uit de praktijk. Voorbeelden van teksten uit het veld ‘beschrijving incident’ - waarbij de originele schrijfstijl (dus missende leestekens, afkortingen etc.) nog aanwezig is.
Ook de persoonsgegevens moeten in die teksten aanwezig blijven - want doel is immers om te bekijken of de techniek ze kan opsporen - maar deze persoonsgegevens moeten uiteraard gepseudonimiseerd worden alvorens ze met ons te delen.

Alle beetjes helpen; voor een eerste inschatting zijn we al geholpen met een klein aantal voorbeelden uit jullie praktijk!

Hi @Silvia van Gils 

idealiter zou ik de data binnen Infoland houden en hier in een afgesloten labomgeving testen - maar daarmee zouden we ons erg beperken in de systemen die we uberhaupt kunnen onderzoeken.

Om te kunnen evalueren hoe bestaande algoritmen in de markt presteren, zullen we die teksten vaak toch wel door een online testomgeving van een leverancier moeten halen of gegevens moeten aanleveren aan die leveranciers - met de afspraak dat ze die na de test weer vernietigen.
In geen van die gevallen wordt de data eigendom van die leverancier.

Wat we zouden doen, is sec de stukjes tekst aanleveren zónder enige context. De leverancier in kwestie ziet dus niet van welke organisatie het afkomstig is. Mits de tekst zelf ook goed gepseudonimiseerd is, is er dus niet mee te achterhalen waar, wanneer of bij wie het is voorgevallen - alleen dát een dergelijk incident of bijna-incident zich ooit ergens heeft voorgedaan.

Voor het werken met trefwoorden moet je toestemming geven voor het versturen van gegevens naar de trefwoord-extractie service in de cloud. Welke gegevens worden naar de cloud verzonden en heb je hier invloed op? (on premise versie)

Kun je bijvoorbeeld velden met namen van patiënten / medewerkers en patiëntnummers excluderen?

Dit maakt het misschien voor de privacy officer en security officer makkelijker om net zo enthousiast te worden over deze mogelijkheden als wij initieel zijn 😀

@hleijen Dat zou een goede uitbreiding zijn. Nu zie je dat er vaak wel 6 tot 8 verschillende trefwoorden worden gebruikt (inclusief foutief geschreven) voor hetzelfde begrip. Ik zie vol verwachting uit naar iProva 5.13 :-)

 

@Hoogeboom-01, weet je of die namen enkel voorkwamen in het systeemveld “Naam van de melder”, of kwamen ze ook voor in andere tekstvelden op het formulier?

Voor het laatste geval geldt dat je op dit moment niet expliciet velden kunt uitsluiten.
Wel kun je - met ingang van iProva 5.13 die deze week uitkomt - ongewenste trefwoorden onderdrukken.

 

Mocht de naam van de melder alleen maar voorkomen in het systeemveld “Naam van de melder” en verder nergens, geef het dan even aan - want dat veld zou niet meegenomen moeten worden. 

@Hoogeboom-01 Ik heb het even nagevraagd hier. Dat veld zou eigenlijk uitgesloten moeten worden - want het bevat per definitie persoonsgegevens - maar dat gebeurt nu blijkbaar niet.

Ik heb er een bugmelding voor aangemaakt, zodat het in een van de komende iProva-updates opgelost wordt.

@Hoogeboom-01  dat is een sluitende verklaring inderdaad.

Zoals eerder in dit topic aangegeven is het uitsluiten van specifieke velden momenteel (nog) niet mogelijk.