Database management in de zorg

[Verwijderd]

Hoi mensen,

Ik ben sinds kort gestart als ICT coördinator bij een ouderenzorginstelling.
Hiervoor heb ik in het bedrijfsleven bezig mogen houden met innovatie en beleid m.b.t. data science(gouvernance, datakwaliteit, toekomstige toepassingsmogelijkheden etc)

Nu kom ik er tot mijn verbazing achter dat men hier niet spreekt van data, maar van "koppelingen" waarmee men doelt op de integratie van- en interactie tussen- uiteenlopende typen applicaties van verschillende leveranciers.
Er lijkt niet echt een integrale visie op data te zijn. En da's niet bij één zorginstelling, ik heb er meerdere gesproken. Men vraagt dan doorgaans een IT consultancyclubje om er naar te kijken. Die vragen daar grof geld voor en bieden nul garanties.

Een SQL koppeling is zo ingewikkeld niet, lijkt me dat softwareleveranciers daar, ook in de zorg, gewoon APIs voor ontwikkelen, toch?
Zeker met het oog op GDPR / AVG richtlijnen lijkt grip op data binnen de zorg een absolute prioriteit.

Wat zouden volgens jullie redenen kunnen zijn dat men in de ouderenzorg niet simpelweg een SQL database optuigt en daar de andere applicaties zo goed en kwaad als het kan aan koppelt? En lijkt het jullie strategisch gezien verstandig om daar aan te beginnen? (Het kan dan wel een nobel streven zijn, maar wanneer de volledige markt ontbreekt loop je snel vast)

Alvast bedankt voor jullie ideeën en suggesties.

[tlpeter]

Heel simpel, er werken meestal heel veel vrouwen en die denken niet in koppelingen maar aan software aanpassingen.
Elk pakket moet maar aangepast worden terwijl dat dus serieus geld kost.

[caspar M]

De reden dat men in de zorg (en dan zijn de ouderenzorginstellingen een beetje klein bier (sorry)) spreekt over koppelingen is omdat men in de zorg een specifieke standaard heeft om data / gegevens uit te wisselen. Namelijk Health Level 7 (HL7) deze omvat een zeer uitgebreide set standaarden en regels omtrent het correct uitwisselen van de data. SQL databases zijn hier een onderdeel van als bron of opslag maar veelal op een veel lagere laag dan HL7.

Men werkt in de zorg veelal vanuit zorg / patiënt processen en als je puur vanuit een IT bril kijkt ga je inderdaad veel ruis krijgen als je dit soort processen bespreekt.

De opmerking van tlpeter is een goed voorbeeld hoe hij alleen kijkt vanuit zijn IT loopgraaf...

[ Voor 23% gewijzigd door caspar M op 07-06-2019 10:12 ]

[Wom]

Er is een reden waarom DBA's veel geld kosten als je ze moet inhuren. Het onderhouden en perfomant houden van een grote productiedatabase vereist nu eenmaal bepaalde kennis. Het koppelen van een applicatie aan een database is inderdaad niet je grootste zorg, dat is juist een van de standaard functionaliteiten van een database.

Geen idee over de hoeveelheid data en applicaties, maar ik kan me voorstellen dat men een centrale redundante database heeft waarop meerdere toepassingen connecteren. Op die manier heb je één grote database waar je redudantie, backups en performance kunt bieden met de nodige support. Support gegeven door mensen die weten wat ze kunnen.

Daarnaast gaat het om zeer gevoelige data. Kan me voorstellen dat er binnen de zorg redelijk wat regelgeving is over hoe met deze data om te gaan en hoe deze op te slaan. Dat kan ook al een reden zijn om deze te centraliseren.

[Question Mark]

Verwijderd schreef op vrijdag 7 juni 2019 @ 10:01:
Alvast bedankt voor jullie ideeën en suggesties.

Waar zit je grootste zorg nu of welk probleem probeer je nu weg te nemen?

Grootste probleem met één grote gemeenschappelijke database, waar alle 3rd party aplicaties maar hun data in kwijt moeten is de beheersbaarheid van die database. Wie gaat hier eignaarschap voor nemen?

Als leverancier X aangeeft dat een door zijn applicatie gebruikte tabel opgesplists moet worden naar meerdere tabellen, hoe ga je garanderen dat de query's op die data van applicatie(s) Y en Z nog functioneren? (hint: dat doen ze dan niet meer).

[Yucon]

Ik snap je vraag eigenlijk niet. Wat voegt die sql database toe? Waar staat het nu dan? "koppelingen" zijn immers geen vervanging voor opslag, eerder voor toegang.

[Lustucru]

Verwijderd schreef op vrijdag 7 juni 2019 @ 10:01:
[...]
Nu kom ik er tot mijn verbazing achter dat men hier niet spreekt van data, maar van "koppelingen" waarmee men doelt op de integratie van- en interactie tussen- uiteenlopende typen applicaties van verschillende leveranciers.
Er lijkt niet echt een integrale visie op data te zijn. [...]
Een SQL koppeling is zo ingewikkeld niet, lijkt me dat softwareleveranciers daar, ook in de zorg, gewoon APIs voor ontwikkelen, toch?
Zeker met het oog op GDPR / AVG richtlijnen lijkt grip op data binnen de zorg een absolute prioriteit.

Wat zouden volgens jullie redenen kunnen zijn dat men in de ouderenzorg niet simpelweg een SQL database optuigt [...]

Om met je laatste vraag te beginnen: simpelweg omdat 'simpelweg een database optuigen' helemaal niks, nada, noppes te maken heeft met een integrale visie op data. En kostenefficiënt is het zeker niet.

[Jazzy]

Verwijderd schreef op vrijdag 7 juni 2019 @ 10:01:
Men vraagt dan doorgaans een IT consultancyclubje om er naar te kijken. Die vragen daar grof geld voor en bieden nul garanties.

"clubje" Dat denigrerende is niet nodig toch? Als je als opdrachtgever een duidelijke vraag stelt dan kan een consultant daar een heldere oplossing voor geven. Dat externe kennis geld kost lijkt me evident.

Verder geen inhoudelijke mening, wilde alleen even reageren op bovenstaande.

edit: Toch nog wat toe te voegen. Dit is een interessante discussie maar heeft natuurlijk weinig te maken met Client Software Algemeen. Omdat je insteek lijkt te gaan over privacy en veiligheid lijkt het topic me meer op zijn plek in Privacy & Beveiliging, ik zal het topic even naar dat deel van het forum verplaatsen.

[ Voor 25% gewijzigd door Jazzy op 07-06-2019 13:11 ]

[Batavia]

Ook vanuit een AVG perspectief is 1 database met een SQL koppeling juist een uitdaging.

Wat de AVG vraagt is dat je voor al je data een grondslag hebt, en dat je privacy by design toepast (de data weggooit die je niet meer nodig hebt, enz enz). Ook laat de AVG expliciet niet toe dat je data verwerkt "omdat je het al hebt"
Dit word veel lastiger als je 1 database hebt waar iedereen maar mee koppelt. Je kan bijvoorbeeld situaties krijgen waarbij in een financieel systeem al jullie clienten 5 jaar bewaard worden om te kunnen voldoen aan wetgeving m.b.t. belastingaangifte. Echter in een klachten systeem bewaar je data tot 30 dagen na afhandeling van de klacht. En in het werkrooster systeem bewaar je clienten 30 dagen na de laatste dag dat ze zorg gehad hebben.

Nu komt de vraag voor mevrouw jansen. Welke data moet ik wel/niet bewaren in jou integraal systeem. Je moet dan naar veel dingen krijgen (loopt er nog een klant, heeft ze nog zorg, etc etc). Het is veel moeilijker om dit "goed" te krijgen dan als je een losse database hebt voor klachten afhandeling, werkroosterplanning enz want dan kan ieder systeem zelf bepalen of/hoeveel data ze nog nodig hebben. En loop je niet het risico dat je data verwerkt waar je geen grondslag voor hebt.

Ik werk ook voor zo'n "clubje" en het is niet dat we je hier niet mee kunnen helpen. Het is vaak dat de oplossing die nodig is moeilijk voor jullie organisatie is. Want waar het mee BEGINT is dat jullie in kaart hebben welke data jullie waarom hebben. Omdat de opdracht "huur mij en 3 collega's een jaar in om ALLE processen in kaart te brengen" vaak een slag te groot is (en geen draagvlak voor is) krijg je kleinere opdrachtjes die om het probleem heen draaien. Bijvoorbeeld een specifieke koppeling maken in de hoop dat er daarmee in ieder geval een deel van het probleem beschreven word en je zo kleine stapjes maakt die jullie helpen en langzaam richting het einddoel bewegen.

[Stoelpoot]

Om ook het ICT perspectief er nog eens op te gooien, is een enkele database ook niet meer zo standaard. Zeker in een zorginstelling is er meer kans dat je met microservices werkt. Denk daarnaast ook aan een implementatie van CQRS om o.a. accountability te kunnen waarborgen, wat je wel met een SQL-server kan doen natuurlijk maar wat nog steeds niet zomaar even een SQL server is.

Overigens is het koppelen van applicaties dmv SQL toegang al lang acherhaald, en zou je sowieso een oplossing hebben waarbij die SQL database enkel een achterliggende opslag is voor een centrale API die business rules en authorisatie waarborgt. Als je al een centrale API zou gebruiken wat zoals ik hierboven zeg allang niet meer de enige gangbare oplossing is.

[downtime]

Verwijderd schreef op vrijdag 7 juni 2019 @ 10:01:

Nu kom ik er tot mijn verbazing achter dat men hier niet spreekt van data, maar van "koppelingen" waarmee men doelt op de integratie van- en interactie tussen- uiteenlopende typen applicaties van verschillende leveranciers.
Er lijkt niet echt een integrale visie op data te zijn.

Waarom denk jij dat het gebruik van meerdere gekoppelde applicaties een integrale visie op data uitsluit? Jouw werk verandert toch niet omdat de data verspreid is over 10 verschillende databases die bij uiteenlopende applicaties horen? Het wordt er hooguit wat complexer van.

En da's niet bij één zorginstelling, ik heb er meerdere gesproken. Men vraagt dan doorgaans een IT consultancyclubje om er naar te kijken. Die vragen daar grof geld voor en bieden nul garanties.

Dat snap ik niet. Waar kijkt die "IT consultancyclub" dan naar? Welke vraag leg je dan aan hen voor?

Een SQL koppeling is zo ingewikkeld niet, lijkt me dat softwareleveranciers daar, ook in de zorg, gewoon APIs voor ontwikkelen, toch?

Ja. Vanuit de techniek gezien is er niks simpelers. Maar je kunt dit niet vanuit de techniek bekijken.

Zeker met het oog op GDPR / AVG richtlijnen lijkt grip op data binnen de zorg een absolute prioriteit.

Opnieuw: Waarom denk je dat het ene het andere uitsluit?

Wat zouden volgens jullie redenen kunnen zijn dat men in de ouderenzorg niet simpelweg een SQL database optuigt en daar de andere applicaties zo goed en kwaad als het kan aan koppelt? En lijkt het jullie strategisch gezien verstandig om daar aan te beginnen? (Het kan dan wel een nobel streven zijn, maar wanneer de volledige markt ontbreekt loop je snel vast)

Honderd verschillende applicaties, honderd verschillende leveranciers, en in gebruik bij meerdere bedrijven die samenwerken in die zorginstelling. Als één applicatie vereist dat de structuur van de database wijzigt dan heb je een flinke uitdaging. Eén applicatie die geen deugdelijke queries doet en de hele boel kan omvallen. Maar gooi er een webservice o.i.d. voor en je kunt een boel wijzigingen afvangen door alleen de code van die webservice aan te passen.