Onderzoeksdatabase, hoe zouden jullie dit aanpakken?

[Verwijderd]

Goedendag allen,

Ik help momenteel als geneeskundestudent met onderzoek in een ziekenhuis ergens in dit land. Nu wordt er in dat ziekenhuis nogal veel onderzoek gedaan. We lopen echter tegen het probleem aan dat we eigenlijk databases op willen zetten. Bij voorkeur databases die meerdere jaren achter elkaar gegevens bijhouden om zo over een paar jaar op een vrij gemakkelijke manier onderzoeksdata te kunnen krijgen.

In het ziekenhuis bestaat er uiteraard een EPD, maar dit EPD is helemaal dichtgetimmerd en heeft geen mogelijkheden om onderzoek mee te doen (enerzijds `veiligheid`, anderzijds omdat het niet gestandaardiseerd is en we vermoeden dat bedrijven er in dat geval een slaatje uit willen slaan). De praktijk is in ieder geval dat men zelfs niet weet hoeveel patiënten men per jaar ziet, hoe het aantal diagnoses zich tot elkaar verhoudt en wat de gemiddelde leeftijd is (basale dingen).

De eisen die men eigenlijk heeft voor het systeem:

• Moet portable zijn of in ieder geval zo, dat als ik vanmiddag geen tijd heb het vanavond onderuitgezakt achter de PC thuis kan invoeren.
• Moet veilig zijn. Het zijn dan wel enigzins geanonimiseerde patiëntgegevens, maar als je ziet te achterhalen wat het nummeringssysteem van het ziekenhuis is, kun je ook de bijbehorende patiënten achterhalen.
• Het moet bij voorkeur zo goedkoop mogelijk zijn.
• Men moet niet afhankelijk worden van andere partijen. Dus als men bepaald dat men tot nog toe de bloeddruk van alle patiënten opslaat, maar men wil vanaf nu ook het bloedglucose opslaan, dan moet dat zonder meer kunnen.
• Bij voorkeur moet het geheel ook wat zwaardere analyses aankunnen. Vnl. statistiekfuncties, zoals mediaan, stdev, gemiddelde, statistische tests, e.d.

Als jullie de bovenstaande eisen zo zien, wat zouden jullie dan aanraden?
Zelf dacht ik aan een webbased iets (PHP + MySQL), maar dan loop je klem met portabiliteit, veiligheid en evt. de afhankelijkheid.
Zij dachten zelf aan iets als MS Access met formulieren, maar dan loop je naar mijn mening te zitten met schaalbaarheid, (te kort aan) functionaliteit en de veiligheid.

Bij voorbaat dank.

[SPee]

Met PHP vastlopen op portabiliteit, veiligheid en afhankelijkheid.
Schrijf een GUI die voldoet aan de HTML standaarden en je kunt deze op elke browser en bijna overal openen. Server OS maakt ook niet uit.
Veiligheid: Maak deze niet direct vanaf buitenaf bereikbaar, maar alleen intern. Dan moeten gebruikers eerst nog op het interne netwerk inloggen.

Het moet bij voorkeur zo goedkoop mogelijk zijn.

Dat is afhankelijk wat je wil en wie het maakt.

Men moet niet afhankelijk worden van andere partijen. Dus als men bepaald dat men tot nog toe de bloeddruk van alle patiënten opslaat, maar men wil vanaf nu ook het bloedglucose opslaan, dan moet dat zonder meer kunnen.

Is in groot contrast met de eerdere eis. Het 'zomaar' aanpassen van je model vereist een grote (en complexe) datamodel. Dat kost tijd en geld. Als die wijziging ook (mag) inhouden dat je de code wijzigd (dus open source) dan dan vereist dat wel dat je de expertise over die applicatie hebt.

Bij voorkeur moet het geheel ook wat zwaardere analyses aankunnen. Vnl. statistiekfuncties, zoals mediaan, stdev, gemiddelde, statistische tests, e.d.

Dat moet dan in het programma worden ingebouwd.

Echter, als ik het zo lees, moet je dit niet willen. 'Je' introduceert dan een nieuw systeem waarin je hetzelfde gaat doen als het bestaande systeem. Enkel kun je hier leuke grafiekjes mee maken. De medewerkers gaan dit niet leuk vinden en/of niet gebruiken. Wordt het 'vergeten' dan krijg je al mis-informatie en dus verkeerde statistieken. Misschien is een (anonieme) export van het EPD systeem een mogelijkheid
En waarom kun je niet de fabrikanten van het EPD systeem vragen (eisen) dat ze bepaalde functionaliteit inbouwen.

Verder zou dit voor een geneeskundestudent geen opdracht zijn. Dit is meer voor een informaticastudent.

[Woy]

Moet veilig zijn. Het zijn dan wel enigzins geanonimiseerde patiëntgegevens, maar als je ziet te achterhalen wat het nummeringssysteem van het ziekenhuis is, kun je ook de bijbehorende patiënten achterhalen.

Alleen om deze reden kun je beter contact zoeken met iemand die wat meer verstand van zaken heeft. NOFI, maar aan de vraag te zien ben je geen software-ontwikkelaar. Dit soort privacy gevoelige dingen moet je over laten aan professionals die weten waar ze mee bezig zijn.

Verder mist er ook nog wel wat informatie om een goed systeem op te kunnen zetten. Je zult eerst een goede analyse moeten doen van wat de wensen en eisen zijn. Je hebt het over "onderzoeken" maar dat is natuurlijk nogal een breed begrip. Wat voor soort gegevens komen er in te zitten.

Pas nadat je de requirements goed duidelijk hebt, is het belangrijk om te gaan kijken hoe je dat technisch gaat implementeren. Denk daarbij ook na over dingen als de hoeveelheid gebruikers, bereikbaarheid, backups, data integriteit.

[Verwijderd]

Je hebt het over "onderzoeken" maar dat is natuurlijk nogal een breed begrip. Wat voor soort gegevens komen er in te zitten.

Het moet een database gaan worden met gegevens over enkele jaren. Je moet dan denken aan patiënten die bijv. voor het eerst komen bij de cardioloog. Van die patiënt registreer je dan bijv. bloeddruk (boven en onderdruk), glucosegehalte, cholestrolgehalte in het bloed, Natrium- en Kaliumgehalte. Je moet echt denken aan gewone labgegevens per patiënt, gestandaardiseerde diagnoses, een aantal Ja/Nee-vragen, e.d.

Dit soort privacy gevoelige dingen moet je over laten aan professionals die weten waar ze mee bezig zijn.

Expert = Duur. We weten nog niet eens of het een succes gaat worden en of we er uiteindelijk veel mee kunnen. Dus wil nog niemand investeren. Daarnaast kost het kijken van een professional ook altijd veel tijd (paralysis by analysis).

Enkel kun je hier leuke grafiekjes mee maken. De medewerkers gaan dit niet leuk vinden en/of niet gebruiken.

Het gaat niet om grafiekjes. Het gaat om registratie van data in eerste opzet. Pas na een jaar of meer gaan we dat analyseren in de hoop dat we daar algemene trends, correlaties, e.d. uit kunnen halen. Het invoerwerk zal voornamelijk voor de rekening komen van enkele personen die dat standaard zullen gaan doen als onderdeel van hun takenpakket. Het is dus geen vraag of ze het `leuk` vinden, ze zullen het `moeten` gebruiken. Alleen willen we daarvoor een zo goed mogelijk werkend systeem.

Veiligheid: Maak deze niet direct vanaf buitenaf bereikbaar, maar alleen intern. Dan moeten gebruikers eerst nog op het interne netwerk inloggen.

Intern maken op een ziekenhuisnetwerk? No way, dan moet je zoveel bestuurslagen afwerken voordat je dat voor elkaar hebt...

Verder zou dit voor een geneeskundestudent geen opdracht zijn. Dit is meer voor een informaticastudent.

Is ook geen opdracht voor mij. Ik doe op de desbetreffende afdeling onderzoek. Zelf maak ik daarvoor eigenlijk altijd gebruik van databases (o.a. MySQL of MS Access). Alleen: Ik weet hoe dat werkt, gezien ik vroeger nogal veel bijgehobbyt heb (of hoe je dat dan ook schrijft). En mij is dus gevraagd om hier over mee te denken en als het kan mee te helpen met het opzetten.

Wordt het 'vergeten' dan krijg je al mis-informatie en dus verkeerde statistieken. Misschien is een (anonieme) export van het EPD systeem een mogelijkheid

De `wet van de grote getallen` vertelt mij dat het af en toe vergeten van registreren van een patiënt op je uiteindelijke resultaat geen verschil gaat maken. Of er nu 800 of 850 mensen in de database staan, je resultaten zullen in dat geval toch al betrouwbaar genoeg zijn.
En nee, een anonieme export van het EPD zit er niet in. Daarvoor is het een te groot ziekenhuis en dat levert dus een export van een paar terabyte op.

[MueR]

Verwijderd schreef op vrijdag 26 februari 2010 @ 18:44:
Het moet een database gaan worden met gegevens over enkele jaren. Je moet dan denken aan patiënten die bijv. voor het eerst komen bij de cardioloog. Van die patiënt registreer je dan bijv. bloeddruk (boven en onderdruk), glucosegehalte, cholestrolgehalte in het bloed, Natrium- en Kaliumgehalte. Je moet echt denken aan gewone labgegevens per patiënt, gestandaardiseerde diagnoses, een aantal Ja/Nee-vragen, e.d.

Dat is nogal wat hoor. Dat zijn vrij complexe databases.

Expert = Duur. We weten nog niet eens of het een succes gaat worden en of we er uiteindelijk veel mee kunnen. Dus wil nog niemand investeren. Daarnaast kost het kijken van een professional ook altijd veel tijd (paralysis by analysis).

Patientgegevens op straat gooien doordat je geld wilde besparen door een amateur aan te nemen is nog duurder. Ik snap verder niet echt wat "het kijken van een professional" precies inhoudt. Je bedoelt zijn opstarttraject waarin hij van jullie wil horen wat er gebouwd moet worden? Ja, dat kost tijd. Dan heb je ook wat. Als je halsoverkop begint kom je 9 van de 10 keer er halverwege achter dat je opnieuw mag beginnen omdat je jezelf in een hoek hebt geschilderd.

Ik weet hoe dat werkt, gezien ik vroeger nogal veel bijgehobbyt heb (of hoe je dat dan ook schrijft). En mij is dus gevraagd om hier over mee te denken en als het kan mee te helpen met het opzetten.

Dus je bent, in het beste geval, een amateur. Vroeger heb je als handig neefje/buurjongen wat kluswerk gedaan. Sorry, maar dat maakt je net zo geschikt voor het ontwikkelen van een dergelijke applicatie als een willekeurige voorbijganger die ik op het station aan zn jas trek. Je kunt niet voor een duppie op de eerste rij zitten, dat bestaat niet. Ik ga voor mn medische zaken ook naar een professional, niet naar iemand die Wikipedia pagina's er bij trekt om symptomen te verklaren. Waarom zou dat bij software ontwikkeling anders zijn?

[SPee]

Hoeveel je ermee kunt is afhankelijk van welke eisen je eraan stelt en hoe/wat je in de applicatie bouwt.

En enkele gebruikers enkel hiervoor aannemen
Kost dat ook geen geld? En hoeveel data ga je dan missen omdat andere afdelingen die niet willen/kunnen/mogen leveren

Intern maken op een ziekenhuisnetwerk? No way, dan moet je zoveel bestuurslagen afwerken voordat je dat voor elkaar hebt...

Dus je wilt die gevoelige data gewoon 'ergens' op internet zetten
Een server op het interne netwerk (met login) is wel vele malen veiliger.

En nee, een anonieme export van het EPD zit er niet in. Daarvoor is het een te groot ziekenhuis en dat levert dus een export van een paar terabyte op.

1. Met een groot ziekenhuis krijg je veel data. Wil je (veel) onderzoeksresultaten opslaan, dan zal ook deze database groot worden.
2. Wil je een paar medewerkers aanstellen om enorm veel data in te voeren? Die worden gek!


Ik zou aanraden om je meer te richten op wát je met die data wil bereiken, dan om nu al over oplossingen te denken. Dan kun je ook makkelijker andere afdelingen overhalen te investeren.

Wat een democratie in een ziekenhuis. Je zou toch verwachten dat sommige dingen makkelijk(er) te regelen zouden zijn?

[Verwijderd]

En enkele gebruikers enkel hiervoor aannemen

Nee, het zijn gewoon de secretaresses die taakuitbreiding krijgen. Zoveel werk is dat nou ook weer niet om 8-20 nieuwe patiënten per week toe te voegen.

En hoeveel data ga je dan missen omdat andere afdelingen die niet willen/kunnen/mogen leveren

Het is intern in de afdeling. Het gaat enkel om de patiënten die op deze afdeling worden aangenomen en we vragen zelf alle voor ons relevante onderzoeken aan.

1. Met een groot ziekenhuis krijg je veel data. Wil je (veel) onderzoeksresultaten opslaan, dan zal ook deze database groot worden.

Yep, maar wij willen enkel de patiënten van onze afdeling. Dus dat is een selectie. En nee, je mag niet de server belasten met onderzoeksqueries, omdat men die enkel beschikbaar wil houden voor patiëntenzorg.

2. Wil je een paar medewerkers aanstellen om enorm veel data in te voeren? Die worden gek!

Dat is dus de spraakverwarring. Het gaat enkel om onze afdeling.

Ik zou aanraden om je meer te richten op wát je met die data wil bereiken, dan om nu al over oplossingen te denken. Dan kun je ook makkelijker andere afdelingen overhalen te investeren.

Wij willen over een paar jaar conclusies kunnen treken over wat voor soort patiënten er bij ons komen (karakteristieken) en wat onze behandelresultaten zijn.

Wat een democratie in een ziekenhuis. Je zou toch verwachten dat sommige dingen makkelijk(er) te regelen zouden zijn?

Een ziekenhuis is net een overheid. Je hebt een x-aantal bestuurslagen, een y-aantal commissies die zich over jouw voorstellen moeten buigen en z-aantal mensen die je plannen willen dwarsbomen. Als je die x-aantal bestuurslagen en y-aantal commissies ziet te vermijden door het initiatief bij jezelf te houden en binnen de mogelijkheden te blijven dan ontloop je die z-aantal mensen en de zeeën van tijd die over zo'n voorstel heen gaan (denk dan in termen als `jaren`).

Dus je wilt die gevoelige data gewoon 'ergens' op internet zetten
Een server op het interne netwerk (met login) is wel vele malen veiliger.

Yep, dat is ook de reden waarom ik niet zo kapot van ben om het op internet te zetten. Maar als internet tegemoet komt aan al de andere eisen, is dat waarschijnlijk wel de meest voor de hand liggende optie. In dat geval wordt het gewoon ergens op internet een achterdeurtje, met nog wat beveiliging er voor en evt. op een ssl-server. Daarnaast is het gebruik van het ziekenhuisnummer al een grote mate van anonimisering.

[Voutloos]

Als je de informaticastudent wilt uithangen heb je de verkeerde studie gekozen. Ieder zijn vak, dus haal er aub wel een expert bij. Dat is bijv. mijn vak, maar ik haal het niet in mijn hoofd om medische adviezen te gaan geven.

Verwijderd schreef op vrijdag 26 februari 2010 @ 19:49:
Een ziekenhuis is net een overheid. Je hebt een x-aantal bestuurslagen, een y-aantal commissies die zich over jouw voorstellen moeten buigen en z-aantal mensen die je plannen willen dwarsbomen. Als je die x-aantal bestuurslagen en y-aantal commissies ziet te vermijden door het initiatief bij jezelf te houden en binnen de mogelijkheden te blijven dan ontloop je die z-aantal mensen en de zeeën van tijd die over zo'n voorstel heen gaan (denk dan in termen als `jaren`).

Ik wil best geloven dat er af en toe (te) veel bureaucratie is/lijkt te zijn, maar hier wek je de indruk te denken dat je gewoon even overal voorbij kan schieten. Een deel vd regels is er met een reden.

[Nick The Heazk]

Verwijderd schreef op vrijdag 26 februari 2010 @ 18:44:
Het moet een database gaan worden met gegevens over enkele jaren. Je moet dan denken aan patiënten die bijv. voor het eerst komen bij de cardioloog. Van die patiënt registreer je dan bijv. bloeddruk (boven en onderdruk), glucosegehalte, cholestrolgehalte in het bloed, Natrium- en Kaliumgehalte. Je moet echt denken aan gewone labgegevens per patiënt, gestandaardiseerde diagnoses, een aantal Ja/Nee-vragen, e.d.

Je wilt daar dan ook statistische analyses op gaan uitvoeren, tendenzen zoeken, een paar data-mining algoritmen op los laten om via beslissingsbomen voorspellingen te maken en misschien ook nog een PCA analyse om de meest invloedrijke componenten te detecteren. Om het met een bouw-analogie te stellen: je wilt een huis bouwen.

Expert = Duur. We weten nog niet eens of het een succes gaat worden en of we er uiteindelijk veel mee kunnen.

Jij bouwt vast ook eerst een huis zonder een architect te raadplegen om eens te horen wat je wilt bouwen?

Dus wil nog niemand investeren.

Natuurlijk wil niemand investeren als niet duidelijk is wat de baten van het nieuwe systeem zijn. Waarom wil je dit systeem? Is dat iets wat bij de gebruikers leeft? Of is het eerder een gevalletje "dat zou wel handig kunnen zijn, maar we weten niet wat technisch haalbaar is". In dat laatste geval haal je er een expert bij.

Daarnaast kost het kijken van een professional ook altijd veel tijd (paralysis by analysis).

Hoeveel tijd verwacht je te winnen door halsoverkop een databank op te zetten, een systeem bij elkaar te rapen en dan na 5 dagen te merken dat het op niets trekt. Bovendien ben je bezig met een verwerking van persoonsgegevens (en die worden erg ruim geïnterpreteerd). Daaromtrent bestaat een wettelijk kader. Nogmaals, je probeert een huis te bouwen, geen hondenhok.

Het gaat niet om grafiekjes. Het gaat om registratie van data in eerste opzet. Pas na een jaar of meer gaan we dat analyseren in de hoop dat we daar algemene trends, correlaties, e.d. uit kunnen halen. Het invoerwerk zal voornamelijk voor de rekening komen van enkele personen die dat standaard zullen gaan doen als onderdeel van hun takenpakket. Het is dus geen vraag of ze het `leuk` vinden, ze zullen het `moeten` gebruiken. Alleen willen we daarvoor een zo goed mogelijk werkend systeem.

Waarschijnlijk zul je na verloop van tijd ook willen dat je data-mining technieken e.d. kunt toepassen. In dat geval is het belangrijk om op een goede fundering te bouwen. Een goed ontwerp. Een hondenhok kun je best wel zonder handleiding in elkaar zetten. Bij een huis is de kans op falen veel groter.

Intern maken op een ziekenhuisnetwerk? No way, dan moet je zoveel bestuurslagen afwerken voordat je dat voor elkaar hebt...

Stel je voor ... Ik stel voor dat je het op het internet pleurt op een MySQL databank, plain text en toegankelijk via een PHP-websitje waarbij de eerste de beste SQL injection je hele databank uitspuwt of onze handige buurjongen de server hackt.

Is ook geen opdracht voor mij. Ik doe op de desbetreffende afdeling onderzoek. Zelf maak ik daarvoor eigenlijk altijd gebruik van databases (o.a. MySQL of MS Access). Alleen: Ik weet hoe dat werkt, gezien ik vroeger nogal veel bijgehobbyt heb (of hoe je dat dan ook schrijft). En mij is dus gevraagd om hier over mee te denken en als het kan mee te helpen met het opzetten.

Ik denk dat je de scope verkeerd inschat.

Verwijderd schreef op vrijdag 26 februari 2010 @ 19:49:
Nee, het zijn gewoon de secretaresses die taakuitbreiding krijgen. Zoveel werk is dat nou ook weer niet om 8-20 nieuwe patiënten per week toe te voegen.

Wat denken zij daar van? Ben jij bereid om elke week 8-20 nieuwe patiënten meer te behandelen? "Not in my backyard" denk ik dan.

Het is intern in de afdeling. Het gaat enkel om de patiënten die op deze afdeling worden aangenomen en we vragen zelf alle voor ons relevante onderzoeken aan.

Yep, maar wij willen enkel de patiënten van onze afdeling. Dus dat is een selectie. En nee, je mag niet de server belasten met onderzoeksqueries, omdat men die enkel beschikbaar wil houden voor patiëntenzorg.

Dat het aantal gegevens beperkt blijft, doet weliswaar geen afbreuk aan de complexiteit van het systeem dat je vraagt. Een huis wordt misschien ontworpen voor de 4 personen die erin wonen, maar zal heus niet instorten als de ganse familie van 40 man sterk langskomt. Meer data betekent niet noodzakelijk dat het moeilijker wordt.

Yep, dat is ook de reden waarom ik niet zo kapot van ben om het op internet te zetten. Maar als internet tegemoet komt aan al de andere eisen, is dat waarschijnlijk wel de meest voor de hand liggende optie. In dat geval wordt het gewoon ergens op internet een achterdeurtje, met nog wat beveiliging er voor en evt. op een ssl-server. Daarnaast is het gebruik van het ziekenhuisnummer al een grote mate van anonimisering.

Het blijft een verwerking van persoonsgegevens. Je zult er waarschijnlijk wel kapot van zijn als de gegevens plots lekken en iemand jou op het matje roept.

[Verwijderd]

Bovendien ben je bezig met een verwerking van persoonsgegevens (en die worden erg ruim geïnterpreteerd).

Het blijft een verwerking van persoonsgegevens. Je zult er waarschijnlijk wel kapot van zijn als de gegevens plots lekken en iemand jou op het matje roept.

Wees niet bang, we kennen de regeltjes. Overigens zullen dit persoonsgegevens zijn, maar wij mogen basale meetgegevens gewoon vrij gebruiken voor wetenschappelijk onderzoek. En of we dat nu in een Excel- of Access-bestand op onze PC thuis doen of op een, over het algemeen wat beter beveiligde, server online zal waarschijnlijk om het even zijn als we de data ver genoeg geanonimiseerd hebben. Maar ik zal het meenemen.

Wat denken zij daar van? Ben jij bereid om elke week 8-20 nieuwe patiënten meer te behandelen? "Not in my backyard" denk ik dan.

Nee, ik ben niet bereid om elke week 8-20 patiënten meer te behandelen. Dat zou namelijk neerkomen op een gemiddelde stijging van ca. 14 per week en per jaar dus 700 nieuwe patiënten/week. Maar mocht ik ooit arts worden, zou ik 8-20 nieuwe patiënten per week helemaal geen verkeerd idee vinden.

Meer data betekent niet noodzakelijk dat het moeilijker wordt

Nee, maar naar ik vermoed zegt de term schaalbaarheid je wel iets. En persoonlijk denk ik dat MS Access nu niet zo schaalbaar is. Maar daar zou je een andere mening over kunnen hebben.

Stel je voor ... Ik stel voor dat je het op het internet pleurt op een MySQL databank, plain text en toegankelijk via een PHP-websitje waarbij de eerste de beste SQL injection je hele databank uitspuwt of onze handige buurjongen de server hackt.

Yep, misschien wel. Ten eerste ben ik niet per definitie degene die het gaat bouwen. Ik ben degene die meedenk in het proces en meehelp de mogelijkheden in kaart te brengen. En zelfs al zou ik het bouwen, dan weet ik ook wat SQL-Injection is.

Om het met een bouw-analogie te stellen: je wilt een huis bouwen.

Om dezelfde bouw-analogie er op los te laten: Ik wil enkel de stenen en het hout verzamelen waarmee we het huis kunnen bouwen (analoog aan de data). Daarna (= over paar jaar) gaan we pas serieus kijken naar evt. verbanden e.d. Dat is het idee van prospectief onderzoek doen.

Jij bouwt vast ook eerst een huis zonder een architect te raadplegen om eens te horen wat je wilt bouwen?

I got it, ik weet dat jullie mij graag willen overtuigen om een expert te zoeken op dit gebied. Maar dat is nu even niet aan de orde. Ik wil eerst gewoon de evt. mogelijkheden in kaart brengen. En als die mogelijkheden gewoon te ver boven onze pet uit gaan, dan kunnen we altijd nog kiezen voor het inhuren van iemand die er meer kaas van gegeten heeft.

Natuurlijk wil niemand investeren als niet duidelijk is wat de baten van het nieuwe systeem zijn. Waarom wil je dit systeem? Is dat iets wat bij de gebruikers leeft?

Het leeft in elk geval op de afdeling. Nu houdt men de gegevens ongeveer `op de achterkant van een bierviltje` bij (om maar iemand te citeren).


Om even bij de discussie te blijven. Jullie gaan naar mijn mening veel te sterk in op de punten `wat als`. Ik wil eigenlijk enkel weten `welke mogelijkheden zijn er`. Daarna gaan we kijken of dit juridisch etc. mogelijk is. Wees niet bang dat jij je labgegevens gaat terugvinden tegen de tijd dat jij in het ziekenhuis zou komen te liggen.
Dus mijn vraag is gewoon simpel: Wat zijn de mogelijkheden? Als er uiteindelijk niets voor ons bij blijkt te zijn kunnen we altijd nog kiezen voor MS Access of het geheel een voortijdige dood laten sterven.

[ Voor 4% gewijzigd door Verwijderd op 26-02-2010 22:16 ]

[MueR]

Verwijderd schreef op vrijdag 26 februari 2010 @ 22:12:
I got it, ik weet dat jullie mij graag willen overtuigen om een expert te zoeken op dit gebied. Maar dat is nu even niet aan de orde. Ik wil eerst gewoon de evt. mogelijkheden in kaart brengen. En als die mogelijkheden gewoon te ver boven onze pet uit gaan, dan kunnen we altijd nog kiezen voor het inhuren van iemand die er meer kaas van gegeten heeft.

Om het simpel te zeggen:
Alles wat je wil kan gebouwd worden, dus die mogelijkheden mag je vinkjes achter zetten. Je zal echter direct er van uit kunnen gaan dat het je heel veel te ver boven de pet gaat, zonder je intelligentie in twijfel te willen trekken. Ieder zijn vak, wij het onze (database en software architecten), jij het jouwe.

[Verwijderd]

Alles wat je wil kan gebouwd worden, dus die mogelijkheden mag je vinkjes achter zetten.

Yep, maar alles wat je laat bouwen kost geld. En als je even naar de eisen hebt gekeken conflicteren sommige dingen nogal met elkaar --> Dus kost het wss. veel geld.
Denk aan portabiliteit vs. robuustheid, portabele databases zoals MS Access, SQLite, TextDB, Berkely DB, etc. zijn nou niet bepaald de meest robuuste mogelijkheden.
Dan heb je nog veiligheid vs. portabiliteit. Iets wat portable is, is per definitie onveilig. Of het nou die database online is met het achterdeurtje, of dat het dat Excel- of Access-bestand is, wat men per ongeluk ergens op een stick liet slingeren of op de thuis-PC is blijven staan toen men deze weggooide.
Dan kunnen we het nog gaan hebben over de afhankelijkheid, die je krijgt wanneer je het geheel professioneel laat oplossen en de tijd die daar over heen gaat.

Kortom: Het is nu gewoon de bedoeling dat we een relatief simpele oplossing zoeken voor het gehele probleem. In eerste instantie willen we gewoon proberen zelf een kleine database opzetten, wanneer dit zichzelf bewijst (doordat er bijv. een publicatie uit geschreven kan worden o.i.d.) is het veel gemakkelijker om daar vervolgens (veel) geld voor vrij te maken en het volledig professioneel op te laten lossen.
Dus mijn vraag is gewoon simpel: Als jullie dit lijstje voor jullie zien, aan welke richting zouden jullie dan beginnen te denken?
- Access of Base met formulieren
- PHP/ASP.NET met een online database
- Een stand-alone app met flatfile database of databaseserver ergens online
- Mogelijke andere optie?

[Remus]

Verwijderd schreef op vrijdag 26 februari 2010 @ 18:01:
In het ziekenhuis bestaat er uiteraard een EPD, maar dit EPD is helemaal dichtgetimmerd en heeft geen mogelijkheden om onderzoek mee te doen (enerzijds `veiligheid`, anderzijds omdat het niet gestandaardiseerd is en we vermoeden dat bedrijven er in dat geval een slaatje uit willen slaan). De praktijk is in ieder geval dat men zelfs niet weet hoeveel patiënten men per jaar ziet, hoe het aantal diagnoses zich tot elkaar verhoudt en wat de gemiddelde leeftijd is (basale dingen).

Ik zou eerst maar eens door een jurist laten onderzoeken of jullie uberhaupt wel het recht hebben om een dergelijke gegevensverzameling aan te leggen. Zeker met betrekking tot medische gegevens zal de Wet bescherming persoonsgegevens denk ik wel beperkingen opleggen. Daarnaast moet je bij mijn weten toestemming hebben van het College bescherming persoonsgegevens.

[Caelorum]

Er is natuurlijk ook een reden dat het EPD helemaal dichtgetimmerd is.
Ik zou als patient in ieder geval wel willen weten welke afdeling in welk ziekenhuis dit is zodat ik daar met een grote boog omheen kan lopen.

[gambieter]

Verwijderd schreef op zaterdag 27 februari 2010 @ 11:00:
Yep, maar alles wat je laat bouwen kost geld. En als je even naar de eisen hebt gekeken conflicteren sommige dingen nogal met elkaar --> Dus kost het wss. veel geld.

Goedkoop is duurkoop. Ik ben geen databaseexpert of programmeur, maar wetenschapper en heb een jaar of 9 in 2 academische ziekenhuizen gewerkt, en ben betrokken geweest bij verschillende grote patienten-onderzoeken, dus ik weet wel hoe het in ziekenhuizen er aan toe gaat.

Je gebruikt nu de "bureaucratie" als excuus om te gaan beunhazen, maar dat is onterecht. Dit is met uitstek iets waar je juist bij het begin experts moet hebben voor een goede opbouw en beveiliging, en waar je daarna de invulling gaat bekijken.

[BCC]

@gambieter, dat kan maar er is natuurlijk wel een tussenweg in het geheel. Voordat je leegloopt op honderden uren consultancy kun je vraag ook neerleggen bij een paar goede webdesign bureaus. Met natuurlijk de vraag of ze dit kunnen en wat de kosten dan zijn. Of een samenwerking met de informatica afdeling van een universiteit of hogeschool?

[Verwijderd]

Ik zou eerst maar eens door een jurist laten onderzoeken of jullie uberhaupt wel het recht hebben om een dergelijke gegevensverzameling aan te leggen

Yep, dat mogen we. Het is alleen op dit moment (nog) niet mogelijk om gebruik te maken van het EPD, afgezien nog van dat de opslag van gegevens daar ook vrij ongestandaardiseerd is. Vrijwel alle gegevens zijn onherleidbaar naar personen, bijv. een bloeddruk van 150/70 kan evengoed bij jou passen, als bij jouw buurman als bij mij. Hetzelfde geldt voor bijna alle labwaarden. Daarnaast is een ziekenhuis een gezondheidsinstelling en mogen we dus de basale gegevens vrij registreren.
We vallen onder de gedragscode van VSNU (http://www.cbpweb.nl/downloads_gedragscodes/gedr_vsnu.pdf).

1. De verwerking van persoonsgegevens ten behoeve van onderzoek dient te
worden gemeld bij het College Bescherming Persoonsgegevens, tenzij:
a. het uitsluitend indirect identificerende gegevens betreft en
b. deze persoonsgegevens niet zijn gecodeerd en slechts worden verwerkt voor
het desbetreffende onderzoek;
2. Indien sprake is van direct identificerende persoonsgegevens dient de verwerking
ten behoeve van onderzoek te worden gemeld bij het College Bescherming
Persoonsgegevens, tenzij:
a. een onderscheid wordt aangebracht tussen de communicatiegegevens en
de onderzoeksgegevens zoals beschreven in art. 3.6;
b. de communicatiegegevens met uitzondering van geslacht, woonplaats en
geboortejaar, niet langer worden bewaard dan 6 maanden nadat zij bij
betrokkene zijn verkregen en evenmin worden gecodeerd en
c. de gegevens uitsluitend worden gebruikt voor het desbetreffende onderzoek.

[gambieter]

BCC schreef op zaterdag 27 februari 2010 @ 15:21:
@gambieter, dat kan maar er is natuurlijk wel een tussenweg in het geheel. Voordat je leegloopt op honderden uren consultancy kun je vraag ook neerleggen bij een paar goede webdesign bureaus. Met natuurlijk de vraag of ze dit kunnen en wat de kosten dan zijn. Of een samenwerking met de informatica afdeling van een universiteit of hogeschool?

Je hoeft inderdaad niet geljik voor de hoofdprijs te gaan, maar nu wordt het andere extreem opgezocht. Of een webdesignbureau de beste keuze is, of meer een bedrijfje dat alleen databases doet? Anyway, een deel van de "blokkerende bureaucratie" is er juist om gevoelige data als patienten- en andere gegevens te beschermen tegen hobbyprojecten. Dat klinkt lullig, maar ik weet uit ervaring dat niet alle specialisten even zorgvuldig zijn of zich druk maken om dergelijke zaken, en dan krijg je nog wel eens dergelijke studentenprojecten. Ik zag ook wel van dat soort projecten langskomen

[ Voor 3% gewijzigd door gambieter op 27-02-2010 15:33 ]

[kKaltUu]

Ben met een soortgelijk project bezig, meetgegevens van verscheidene takken (gewichtspatroon, bloedsuiker, psychologische testresultaten) aan een EPD koppelen.
Het voordeel van mijn project is dat dit IN het EPD geïntegreerd word.

Wat jij nu probeert te doen, met de eisen die je krijgt, heeft nadelen.
Als je het goedkoop wilt doen, gaat het lang duren.
Als je het goed wil doen, gaat het wat kosten.

Je spreekt zelf in je OP over dat je zit te denken aan een webbased systeempje met PHP en een MySQL achterkantje, waar je opdrachtgevers dachten aan een access achtig iets, heb je zelf al de eisen en wensenlijst kritisch besproken? (centraal vs decentraal opslag, en je zit nu al naar het technisch ontwerp te kijken IPV functioneel ontwerp.)

JWvdV schreef op vrijdag 26 februari 2010 @ 22:12:
I got it, ik weet dat jullie mij graag willen overtuigen om een expert te zoeken op dit gebied. Maar dat is nu even niet aan de orde. Ik wil eerst gewoon de evt. mogelijkheden in kaart brengen. En als die mogelijkheden gewoon te ver boven onze pet uit gaan, dan kunnen we altijd nog kiezen voor het inhuren van iemand die er meer kaas van gegeten heeft.

Je kan toch altijd een gesprek plannen met consultants van bedrijven die deze pakketten verzorgen? Dezen geven vaak een nieuwe kijk op de zaak, het is vrijblijvend of je hun pakketten aanschaft of niet, als ze precies hebben wat jij wilt, kan je altijd overstag gaan en een tweede gesprek aangaan.

Ik kan niet al teveel zeggen over mijn project, maar probeer eens te kijken welke pakketten er al zijn, en welke functionaliteiten deze hebben.

[superduper]

Simpelweg niet aan beginnen. Ik ben benieuwd wie je de opdracht heeft gegeven. Een arts-onderzoeker (die zijn eigen administratie niet op orde kan krijgen en een veredelde secretaresse zoekt), of moet je voldoen aan de wensen van een heel team.

Is het het eerste: dan kan het heel simpel, maar moet er niet al teveel verwacht worden aan veiligheid en reuze stabiliteit.

Is het het tweede: er zijn al redelijk veel medische databases voor onderzoeken in omloop. Terecht ook niet gratis. Laat ze dat maar eens uitzoeken.

[Verwijderd]

Ik kan niet al teveel zeggen over mijn project, maar probeer eens te kijken welke pakketten er al zijn, en welke functionaliteiten deze hebben.

Over welk EPD-systeem gaat het in dit geval? Gaat het over het regionale of nationale EPD?

Je kan toch altijd een gesprek plannen met consultants van bedrijven die deze pakketten verzorgen?

Yep, is al gebeurd. Alleen hebben zij ook niet het antwoord op `een systeem waarin je data gesystematiseerd opslaat en achteraf kunt analyseren`.

Je hoeft inderdaad niet geljik voor de hoofdprijs te gaan, maar nu wordt het andere extreem opgezocht.

Wees realistisch, alles is beter dan de excel-bestandjes en word-documentjes die ze nu toch al overal gebruiken (en die je in de praktijk ook overal en nergens tegenkomt). Het voordeel van een beetje centraler systeem is gewoon dat je wat systematischer achteraf kunt analyseren. Daarnaast kun je de registratie van die gegevens dan zoveel mogelijk bij één of enkele personen neerleggen (de secretaresses), waardoor je ons inziens al veel wint (meer veiligheid, minder slingerende bestanden en meer analysedata).

Dat klinkt lullig, maar ik weet uit ervaring dat niet alle specialisten even zorgvuldig zijn of zich druk maken om dergelijke zaken, en dan krijg je nog wel eens dergelijke studentenprojecten. Ik zag ook wel van dat soort projecten langskomen

Zoals ik al meer heb aangehaald hierboven: ik ben niet degene die verantwoordelijk is, waarschijnlijk ook niet degene die het uitvoert. Maar wel degene die informatie probeert te verzamelen om tot een lopend project te komen. En het boeit niet als we eerst met een systeem zitten wat niet 100% werkt zoals we willen. Als het zich eenmaal bewijst, kunnen we later veel makkelijker geld lospeuteren om het te laten doen en naar een ander systeem te migreren. Nu is er gewoon niet meer dan enkele honderden euro's vanuit het `experiment`-potje en daar ga je het gewoon niet mee doen.

[gambieter]

Verwijderd schreef op zaterdag 27 februari 2010 @ 16:16:
Wees realistisch, alles is beter dan de excel-bestandjes en word-documentjes die ze nu toch al overal gebruiken (en die je in de praktijk ook overal en nergens tegenkomt). Het voordeel van een beetje centraler systeem is gewoon dat je wat systematischer achteraf kunt analyseren. Daarnaast kun je de registratie van die gegevens dan zoveel mogelijk bij één of enkele personen neerleggen (de secretaresses), waardoor je ons inziens al veel wint (meer veiligheid, minder slingerende bestanden en meer analysedata).

Dat voordeel is gelijk het nadeel: als de beveiliging van een dergelijke database faalt, dan ligt er veel en veel meer op straat. Dat is nu juist de reden om pas op de plaats te maken en niet voor een dubbeltje op de eerste rij te zitten.

Zoals ik al meer heb aangehaald hierboven: ik ben niet degene die verantwoordelijk is, waarschijnlijk ook niet degene die het uitvoert. Maar wel degene die informatie probeert te verzamelen om tot een lopend project te komen.

Dat is echter geen reden om alle adviezen in de wind te slaan. Als je een goed project wilt hebben, dan geef je het ook aan als iets niet goed gedaan wordt, zoals hier. Geef aan dat het als een omgekeerde pyramide wordt opgezet, dwz instabiel.

Nu is er gewoon niet meer dan enkele honderden euro's vanuit het `experiment`-potje en daar ga je het gewoon niet mee doen.

Dan moet je het niet doen. Of goed, of niet. Da zijn beslissingen die ik als projectleider vaak zat moet nemen, halve aanpakken resulteren in de meeste falende projecten.

[Robino]

Laat ik beginnen met zeggen, gezien vanuit mijn vakgebied de Medische Informatiekunde, dat dit een interessant topic is

Er zijn goeie reden, die uiteraard tegelijk consequenties hebben, waarom een ZIS dichtgetimmerd is. Ten eerste speelt geld daarbij natuurlijk een grote rol. Een ziekenhuis schaft een ZIS aan en de softwareleverancier geeft aan wat hij daarvoor gaat implementeren. Uitzonderingen (lees: eisen van verschillende afdelingen) zullen daarbij zoveel mogelijk worden strakgetrokken, omdat maatwerk nu eenmaal meer tijd & geld kost. Maar anderzijds ook om de kwaliteit van het geregistreerde te waarborgen. Immers, afdelingen willen allemaal net wat anders (wat uiteraard begrijpelijk is), met redundantie van data tot gevolg. Vandaar ook dat je een ZIS wilt dichttimmeren, om de huidige eilandjesstructuur (elke afdeling heeft zijn eigen DB's) zoveel mogelijk te centraliseren. Het gevolg is echter wel dat de flexibiliteit enigszins verloren gaat, wat ik ook haal uit het verhaal van de TS. Je ziet dus wat het gevolg kan zijn, dat afdelingen alsnog "buiten de deur" een eigenlijk onderzoeksdatabase gaan opzetten. Vanuit het ziekenhuis gezien is dit dus juist wat je niet wilt hebben!

Echter, wat ik ook uit jouw verhaal afleid, is dat het ZIS niet geheel aan de eisen lijkt te voldoen. Je hebt het nu over dat de productiecijfers onbekend zijn, wat mij vanuit het oogpunt van een RvB toch ronduit onwenselijk lijkt te zijn. Ik kan niet geheel uit jouw verhaal opmaken of alleen de afdelingen zelf dit soort productiecijfers niet weten. In dat geval zal jouw afdeling geen uitzondering moeten zijn en is dit een ziekenhuisbreed probleem! Ook in dat geval is het opzetten van een aparte onderzoeksdatabase eigenlijk onwenselijk, want je krijgt dan weer dataredundantie. Het probleem zou dus eigenlijk ziekenhuisbreed opgepakt moeten worden.

Wat je mooi ziet bij het zelf opzetten van een onderzoeksdatabase (en dat is dus juist waarom ze een dichtgetimmerd ZIS hebben geïmplementeerd), is dat een van jouw eisen is dat je thuis eraan moet kunnen werken. Vanuit het oogpunt van het ziekenhuis is dit natuurlijk niet wenselijk. En verder zie je dus, dat het gaat zoals het al jaren gaat: Persoon A op Afdeling B krijgt de taak om iets van een onderzoeksdatabase op te zetten. Deze Persoon A heeft wat verstand van Techniek C & D en bouwt de onderzoeksdatabase. Vervolgens wordt hier een aantal jaren meegewerkt, totdat Persoon A Afdeling B verlaat en niemand op de afdeling eigenlijk kennis heeft van hoe Techniek C & D zijn gebruikt om de onderzoeksdatabase draaiende te houden. Wat dat betreft adviseer ik jou dus ook: denk goed na over het belang van deze onderzoeksdatabase. Als jouw afdeling echt niet zonder kan, ga er dan mee aan de slag. Maar bedenk goed dat jouw product over 10 jaar nog steeds draaiende kan zijn. Dus: documenteer, documenteer en documenteer! Er komt altijd wel een moment dat de gegevens nog nodig zijn, maar de kennis er niet meer is in persoonlijke vorm

Wat verder van belang is om te weten, is dat dubbel registreren de eerste tijd zal gaan werken, maar op een gegeven moment zal dat stoppen. Je bent namelijk data redundant aan het opslaan en mensen daartoe dwingen het te moeten doen, zal de datakwaliteit zeker niet helpen. En met een slechte datakwaliteit heb je helemaal niets aan je onderzoeksdatabase, dus dit is een punt waar je nog zeer goed over na moet denken. Het invoeren van 8-20 nieuwe patiënten per week door de secretaresse lijkt namelijk wel goed te doen. Maar het is niet het enige werk dat gedaan moet worden en het moet wel elke week, week na week, worden geregistreerd. Daarnaast zullen mensen ook de afdeling verlaten, waardoor werk weer overgegeven moet worden. En nogmaals: je blijft daarbij dus continu data dubbel registreren. Ik zeg niet dat het onmogelijk is, maar ook zeker niet gemakkelijk.

Het argument dat je professionals nodig hebt, vind ik trouwens wel deels overdreven. De praktijk is dat er al jaren lang ontelbare soortgelijke onderzoeksdatabases door mensen zijn opgezet. Ook gewoon door artsen, die toevallig tijd hebben om wat met Access te proberen. En het leuke is dat ze ook echt werken Alleen voor de langetermijn is het wel van belang dat er goed over nagedacht wordt, waarbij "professionals" dan wel weer van belang zijn. Het is dus ook niet voor niets dat een ZIS dichtgetimmerd wordt, want je moet de grenzen afbakenen om een doel te kunnen behalen

Caelorum schreef op zaterdag 27 februari 2010 @ 14:56:
Er is natuurlijk ook een reden dat het EPD helemaal dichtgetimmerd is.
Ik zou als patient in ieder geval wel willen weten welke afdeling in welk ziekenhuis dit is zodat ik daar met een grote boog omheen kan lopen.

Denk dus ook niet dat dit in geen enkel ziekenhuis zal voorkomen Wij leven misschien wel anno 2010, maar de ICT loopt in ziekenhuizen makkelijk 20 jaar achter

Mocht de afdeling trouwens de Cardiologie betreffen, dan wil ik je graag doorverwijzen naar 2 registraties die daar al voor zijn. De eerste is de BHN Registratie en de tweede is de NCDR.

Mocht het ziekenhuis het UMCU betreffen, dan wil ik je graag wijzen op de komst van een nieuw ZIS. In dat geval zou ik de onderzoeksdatabase nog maar eens goed overwegen

[Verwijderd]

Denk dus ook niet dat dit in geen enkel ziekenhuis zal voorkomen Wij leven misschien wel anno 2010, maar de ICT loopt in ziekenhuizen makkelijk 20 jaar achter

Sterker nog, op elke afdeling waar ik tot nog toe ben geweest heb je wel een paar mensen rondlopen met sticks met heel veel onderzoeksdata (soms volledig ongeanonimiseerd), waarvan je niet zou willen dat deze in verkeerde handen vallen. En ik heb niet het idee dat het enkel het ziekenhuis betreft waar ik nu op het moment rondloop (gezien de dingen die soms via de mail onderling verstuurd wordt).

Vandaar ook dat je een ZIS wilt dichttimmeren, om de huidige eilandjesstructuur (elke afdeling heeft zijn eigen DB's) zoveel mogelijk te centraliseren. Het gevolg is echter wel dat de flexibiliteit enigszins verloren gaat, wat ik ook haal uit het verhaal van de TS.

Het verhaal van de TS is eigenlijk meer: het EPD is niet toegankelijk voor onderzoeksdoeleinden, tenzij je daar een hele waslijst voor invult in de hoop dat men een keertje op een rustig moment ('s nachts) die data voor je ophaalt uit het EPD. Wat overigens nadien ook nog vaak onbruikbaar blijkt, omdat een groot deel van de data in het EPD ongestandaardiseerd is en je dus uiteindelijk alsnog iemand aan het werk moet gaan zetten om de data te standaardiseren (Dokter A noemt de ziekte zo, dokter B noemt hem zo, Dokter C gebruikt een afkorting, maar het zijn allemaal synoniemen voor hetzelfde (denk aan `H. Zoster`, `Herpes Zoster`, `Gordelroos`, etc.).

Mocht de afdeling trouwens de Cardiologie betreffen, dan wil ik je graag doorverwijzen naar 2 registraties die daar al voor zijn. De eerste is de BHN Registratie en de tweede is de NCDR.

Nee, het betreft niet een afdeling cardiologie. Welke wel, laat ik in het midden omwille van het onidentificeerbaar houden van de afdeling (mede gezien opmerkingen hierboven).

Echter, wat ik ook uit jouw verhaal afleid, is dat het ZIS niet geheel aan de eisen lijkt te voldoen. Je hebt het nu over dat de productiecijfers onbekend zijn, wat mij vanuit het oogpunt van een RvB toch ronduit onwenselijk lijkt te zijn.

Yep, het zal ongetwijfeld best bij de raad van het bestuur bekend zijn. Maar EPD is per slot van rekening toch voornamelijk gericht op de incasso en het functioneel delen van patiëntdata. In elk geval werd mij meegedeeld dat men van de afdeling niet wist hoeveel nieuwe patiënten ze kregen per jaar, wat hun gemiddelde leeftijd was, aantal patiënten per dokter, etc.

Het argument dat je professionals nodig hebt, vind ik trouwens wel deels overdreven. De praktijk is dat er al jaren lang ontelbare soortgelijke onderzoeksdatabases door mensen zijn opgezet. Ook gewoon door artsen, die toevallig tijd hebben om wat met Access te proberen. En het leuke is dat ze ook echt werken

Wij zijn helemaal niet te beroerd om professionals in te huren. Maar op dit moment is gewoon het geld er niet voor. Als je ergens geld voor wilt vrijmaken moet je dat ook kunnen verantwoorden. Op dit moment is er totaal nog geen garantie dat er uiteindelijk veel zinnigs uit die databases gaat komen en dat de kosten/baten-analyse wel positief gaat uitvallen. Hooguit kun je dus iets uit het `Experimenteer`-potje halen en daarmee gaat het niet lukken. Op lange termijn zijn wij ook van plan om evt. via API's/SOA o.i.d. het geheel gelinkt te krijgen aan het EPD, alleen wordt dat wel een termijn van enkele jaren.

Maar ik ben eigenlijk wel benieuwd naar die ervaringen: Ging het registreren in Access gemiddeld genomen goed? Was het later makkelijk te migreren naar een ander systeem? Wat waren de fouten die men gemiddeld genomen maakte met die databases?

[Robino]

Verwijderd schreef op zaterdag 27 februari 2010 @ 17:15:

[...]
Het verhaal van de TS is eigenlijk meer: het EPD is niet toegankelijk voor onderzoeksdoeleinden, tenzij je daar een hele waslijst voor invult in de hoop dat men een keertje op een rustig moment ('s nachts) die data voor je ophaalt uit het EPD. Wat overigens nadien ook nog vaak onbruikbaar blijkt, omdat een groot deel van de data in het EPD ongestandaardiseerd is en je dus uiteindelijk alsnog iemand aan het werk moet gaan zetten om de data te standaardiseren (Dokter A noemt de ziekte zo, dokter B noemt hem zo, Dokter C gebruikt een afkorting, maar het zijn allemaal synoniemen voor hetzelfde (denk aan `H. Zoster`, `Herpes Zoster`, `Gordelroos`, etc.).

Dan ga ik meteen een vraag terug stellen: gebeurd dit op de desbetreffende afdeling dan wel Als je geen vrije tekstvelden toestaat en dus alleen opties, betekent dit wel dat de werkwijze op de afdeling daarop moet aansluiten. Oftewel: wil je correct registreren zonder extra werk, dan moet je standaardiseren en alle artsen dus "Herpes Zoster" opschrijven. Anders moet de secretaresse iedere keer bij het invoeren de vertaalslag maken (met invoerfouten ten gevolgen). Denk dus niet dat met het opzetten van een eigen onderzoeksdatabase, je van de beschreven problemen bij het extraheren van de gegevens uit het EPD af bent. Het is niet voor niets dat data niet gestandaardiseerd in het ZIS zit. Standaardiseren vereist namelijk hervorming van de afdelingsprocessen, terwijl het implementeren van een ZIS op zichzelf ook al de afdelingsprocessen veranderd.

[...]

Maar ik ben eigenlijk wel benieuwd naar die ervaringen: Ging het registreren in Access gemiddeld genomen goed? Was het later makkelijk te migreren naar een ander systeem? Wat waren de fouten die men gemiddeld genomen maakte met die databases?

De geregistreerde gegevens zijn zo goed als het doel waarvoor ze geregistreerd zijn Een Access-database zal door zijn ontwerper, in eerste instantie niet ontworpen zijn om later gemigreerd te worden, dan wel te koppelen met een ander systeem. Maar als je daar in de ontwerpfase rekening mee houdt, dan is het uiteraard een ander verhaal

[Verwijderd]

Dan ga ik meteen een vraag terug stellen: gebeurd dit op de desbetreffende afdeling dan wel

In het EPD niet, omdat je dan niet meer makkelijk kunt specificeren (één ziekte kent meerdere varianten). Maar in het systeem wat ze zelf opstellen wel. Het systeem van ziekten heeft een algemene classificatie (ICD) en sommige specialismen en subspecialismen hebben eigen classificatiesystemen (DSM voor Psychiatrie is de bekendste). Wij willen een soortgelijke classificatie gebruiken.

Anders moet de secretaresse iedere keer bij het invoeren de vertaalslag maken (met invoerfouten ten gevolgen).

De wet van grote getallen leert mij dat zoiets bij genoeg patiënten niet zo'n heel groot probleem gaat worden. Daarnaast zijn er niet zo gruwelijk heel veel diagnoses (aantal veel voorkomende standaarddiagnoses en slechts een paar afwijkende). Maar ik zal het meenemen.

De geregistreerde gegevens zijn zo goed als het doel waarvoor ze geregistreerd zijn

Maar je bent dus geen specifieke fouten tegen gekomen die men vrij algemeen maakte?

[Robino]

Verwijderd schreef op zaterdag 27 februari 2010 @ 18:33:
[...]
In het EPD niet, omdat je dan niet meer makkelijk kunt specificeren (één ziekte kent meerdere varianten). Maar in het systeem wat ze zelf opstellen wel. Het systeem van ziekten heeft een algemene classificatie (ICD) en sommige specialismen en subspecialismen hebben eigen classificatiesystemen (DSM voor Psychiatrie is de bekendste). Wij willen een soortgelijke classificatie gebruiken.


[...]
De wet van grote getallen leert mij dat zoiets bij genoeg patiënten niet zo'n heel groot probleem gaat worden. Daarnaast zijn er niet zo gruwelijk heel veel diagnoses (aantal veel voorkomende standaarddiagnoses en slechts een paar afwijkende). Maar ik zal het meenemen.


[...]
Maar je bent dus geen specifieke fouten tegen gekomen die men vrij algemeen maakte?

Dat is in ieder geval goed om te horen dat men bereid is volgens de ICD-9 te registeren

[Alex]

Ik vind je streven nobel, je argumenten zijn niet altijd even valide, maar och, daar hebben software techneuten ook vaak last van.
Wat ik mij wél afvraag is ofdat je a) een haalbaarheidsstudie niet moet doen voordat je een database op gaat zetten, b) wel eens exact de problematiek hebt voorgeschoteld aan de corporate IT-afdeling. Mogelijk zijn er alternatieven denkbaar, die inpasbaar zijn binnen het ziekenhuis, en in de toekomst 'forward compatible' zijn.
Als de corporate IT(in de vorm van een business analist) niet wil praten, dan moet je jezelf afvragen of de jouw superieuren(afdelingshoofd) je niet met een taak heeft opgezadeld die niet oplosbaar is vanuit zijn machtspositie.

Het is namelijk in dit soort gevallen geen kwestie van budget, maar prioriteit. Met de juiste prioriteit komt het juiste budget er wel .

[BCC]

Ik kwam gisteren toevallig het volgende opensouce project tegen:
http://projectpophealth.org/

Volgens mij doet dit in basis precies wat je wil. De code kun je hier vandaan trekken:
http://github.com/pophealth/popHealth

Veel makkelijker gaat het volgens mij niet worden .

[eghie]

Ik zelf zou het in PostgreSQL doen + PHP + HTML 5 + Mozilla Prism client ofzo.

Dan zou ik het als volgt aanpakken:
• Installeren van SSL client certificaat aan de client kant, in Prism. Voor elke medewerker met de hand uitgegeven. Dus iedereen krijgt dan z'n eigen Prism kopie.
• Prism als portable APP binnen een TrueCrypt usb stick installeren of zo'n beveiligd USB stick geval.
• Een RIA app bouwen die gebruik maakt van JavaScript (via jQuery) en locale encryptie + HTML 5 offline ondersteuning om ermee te werken.
• Bij het online zijn, worden de ingevoerde gegevens bij het opslaan, naar de server verstuurd via Javascript AES + SSL verbinding.
• Vervolgens worden de gegevens in een database gezet. En die gegevens worden vervolgens geencrypt, via bijvoorbeeld de pgcrypto module van PostgreSQL.
• Een extreem aggresief auditing en IDS systeem omheen bouwen.
• Houd je verre van externe diensten, zoals Google maps enzo!

Dit systeem lijkt me redelijk portable en toekomst gericht. Daarnaast is het ook nog wel redelijk veilig.

Voor elke gebruiker zou ik dan een UUID + een herkennings naam (ziekenhuis nummer) aan meegeven in de database, maar niet meer dan dat.

Dit systeem is bepaald niet top of the bill en wat niet meer. Als het echt aan hoge gekwalificeerde beveiliging zou moeten voldoen, had ik het in JAVA geprogrammeerd. Die heeft daar bewezen platformen voor, maar voor zoiets zou dat dat via bovenstaand doen.

Zo gauw alles in SQL staat, of in vergelijkbaar standaard formaat, is het redelijk portable. Niet alles in 1 string douwen though.

Dingen als een PHP programmatje maken die alle gegevens uit de database haalt en in een ander formaat over zet is ook nog altijd te doen als het over moet naar een ander systeem.

Maar voor je begint, zou ik eerst een onderzoek doen naar: Secure data mining

Het beveiligingsaspect is wel erg belangrijk. Lees deze citaat maar eens:

quote: http://www.wisdom.weizman...rivacy_Yehuda_Lindell.ppt

I was able to show how the medical record of William Weld, the governor of Massachusetts of the time could be re-identified using only his date of birth, gender and ZIP. In fact, 87% of the population of the United States is uniquely identified by date of birth (e.g., month, day and year), gender, and their 5-digit ZIP codes. The point is that data that may look anonymous is not necessarily anonymous.

[ Voor 40% gewijzigd door eghie op 01-03-2010 22:55 ]

[Woy]

Verwijderd schreef op zaterdag 27 februari 2010 @ 16:16:
[...]
Yep, is al gebeurd. Alleen hebben zij ook niet het antwoord op `een systeem waarin je data gesystematiseerd opslaat en achteraf kunt analyseren`.

En dat geeft dus meteen het hele probleem aan. Op die vraag is ook geen goed antwoord, want de requirements zijn dus nog niet duidelijk. Op de manier dat je het nu vertelt gaat het meer om een grote meta-base, en dat is echt niet iets wat je even in elkaar draait. En dan zeker niet op een manier dat je er later nog wat aan hebt.

Zorg dus eerst dat je de requirements eens goed op een rij gaat zetten. Je bent nu al aan het denken aan technische oplossingen aan het denken. Terwijl je nog niet eens compleet duidelijk hebt wat de functionele requirements zijn.

@eghie: Sorry hoor, maar je idee klinkt misschien heel leuk, en misschien is het wel een goede aanpak, maar met de informatie die de TS geeft zijn er nog tig manieren om het te implementeren. Het is IMHO niet de goede aanpak om eerst in technische oplossingen te gaan denken.

[ Voor 14% gewijzigd door Woy op 01-03-2010 23:45 ]

[eghie]

Woy schreef op maandag 01 maart 2010 @ 23:43:
...

@eghie: Sorry hoor, maar je idee klinkt misschien heel leuk, en misschien is het wel een goede aanpak, maar met de informatie die de TS geeft zijn er nog tig manieren om het te implementeren. Het is IMHO niet de goede aanpak om eerst in technische oplossingen te gaan denken.

Nee ben ik met je eens. Ik kreeg het gevoel dat de TS er wat te makkelijk mee om gaat en ik verwacht dat als ik niet een voorbeeld systeempje zou geven, dat hij het ging proberen in een standaard PHP/MySQL applicatie. Dan heb ik liever dat hij zoiets kiest, want dan heb je al minder de kans dat er iets mis gaat en het is niet heel moeilijk, maar daarnaast ziet hij mogelijk dan ook een beetje welke beveiligings eisen er een beetje zijn. Dit leek me sowieso beter dan een standaard PHP/MySQL oplossing. En vaak gebeurd het als ze hier geen oplossing kunnen vinden, dat ze het zelf gaan proberen op hun eigen manier en dat kan soms onvoorziene problemen veroorzaken. Ik probeer de TS daar een beetje tegen te beschermen.

[Robino]

eghie schreef op maandag 01 maart 2010 @ 23:58:
[...]

Nee ben ik met je eens. Ik kreeg het gevoel dat de TS er wat te makkelijk mee om gaat en ik verwacht dat als ik niet een voorbeeld systeempje zou geven, dat hij het ging proberen in een standaard PHP/MySQL applicatie. Dan heb ik liever dat hij zoiets kiest, want dan heb je al minder de kans dat er iets mis gaat en het is niet heel moeilijk, maar daarnaast ziet hij mogelijk dan ook een beetje welke beveiligings eisen er een beetje zijn. Dit leek me sowieso beter dan een standaard PHP/MySQL oplossing. En vaak gebeurd het als ze hier geen oplossing kunnen vinden, dat ze het zelf gaan proberen op hun eigen manier en dat kan soms onvoorziene problemen veroorzaken. Ik probeer de TS daar een beetje tegen te beschermen.

Maar eigenlijk moet de TS gewoon nog terug naar het begin en de vraag eerste beantwoorden of het opzetten van een onderzoeksdatabase noodzakelijk is