transe careb mwhitepaper_finaal

White Paper Maart 2010

Analyse van business modellen

TranseCare

TranseCare – Business Modellering white paper IBBT/SMIT/VUB Annelies Veys

2

!"#$%&'()*+,-

!"#$%&%"'(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( )!

*(*(+,-./$0'01"& (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((()!

*(2(+345167+7.%/$+484$0((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((()!

2(+908":$;80$+4#8/<10=(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( >!

2(*(+?$<%"%@0%"'(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((>!

2(2(+,<58A$"%"' ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((>!

)(+B1675#1AA$"+7880&$"$/7$0A+908":$;80$ (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( C!

)(*(+D$"$0%$A$+01##$"((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((C!

"#$#$#!%&'())*+),- ########################################################################################################################.!

"#$#/#!0)12314564'+),- ###################################################################################################################7!

"#$#"#!8366)9(5+5()5('+),- ##############################################################################################################7!

"#$#:#!;56<695)1564'13,,)6 ##############################################################################################################7!

)(2(+D$"$0%$A$+8-/10$" (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((E!

>(+3"&$0F1$A:401/1-1#+710A:.14(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( E!

>(*(+?1$#+710A:.14 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((E!

>(2(+?$$#"$=$0:+710A:.14(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((G!

>()(+H$0#114+710A:.14 (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((G!

:#"#$#!=6(13->9(5)! ##########################################################################################################################?!

:#"#/#!@5(A)1B)6!56!()<*'!+<6!>')1C4)6)1<()-!'9)6<153!##############################################################?!

:#"#"#!@5(A)1B)6!56!()<*'!+<6!>')1C4)6)1<()-!'9)6<153!############################################################$$!

:#"#:#!D,)6<51)!+331'(),,564!>')1C4)6)1<()-!'9)6<153E'!F!+1<4)6!################################################$$!

C(+?8/8I$0F8=$#%"'+710A:.14 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( *2!

J(+K$:6#/8/$"((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( *2!

J(*(+K$<#$-/%$+0$:6#/8/$" ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( *2!

J(2(+,"8#L:$+:-$"80%1M: (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((*)!

.#/#$#!GH()16)!36(A5BB),<<1!-3*56<6( ########################################################################################$"!

.#/#/#!0)12)B)1<<1!-3*56<6(#######################################################################################################$I!

.#/#"#!J+)1K)5-!-3*56<6( ###########################################################################################################//!

.#/#:#!8366)9(5+5()5(',)+)1<695)1!-3*56<6( ################################################################################/I!

J()(+N:$0O'$"$08/$&+:-$"80%1M: ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( ))!

D01$4+* (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( ))!

D01$4+2 (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( )C!

D01$4+) (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( )P!

D01$4+> (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( )E!

P(+Q%"&5$I%"&%"'$"(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( >R!

K$<$0$"/%$: ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( >C!


3

Inleiding

1.1. Achtergrond

!

Het IBBT1 project TranseCare heeft tot doel een ICT-platform te ontwikkelen dat het onafhankelijk

leven van ouderen met degeneratieve beperkingen in hun eigen huis te faciliteren. Hiertoe wil men

een platform ontwikkelen dat zorgt voor data-uitwisseling via een beveiligd netwerk en dat ook de

mobiliteit van de gebruikers ondersteunt. Om na te gaan of dit platform in de hedendaagse

maatschappij wenselijk is, is het zinvol stil te blijven staan bij de mogelijke impact van het platform op

het economische waardenetwerk van de gezondheidszorg. Een geïntegreerd business model wordt

uitgetekend om de complexiteit te structureren. Er moet immers rekening gehouden worden met het

dynamische, multi-stakeholder karakter van de ICT markt (Ballon, 2007). In een businessmodel van

een multi-sited platform is het aan boord krijgen van de verschillende actoren en de interesses van

deze groepen in evenwicht krijgen cruciaal (Evans, 2003). Met andere woorden, een succesvol

businessmodel voor dergelijke platform is niet zozeer een zaak van kostgeoriënteerde prijzen, maar

van een evenwichtige vraag (Cortade, 2006) en een strategische fit tussen actoren (Bouwman, 2003).

De gezondheidszorg is een ingewikkeld domein waar rekening moet worden gehouden met een

waaier aan actoren (De Maesschalck et al., 2006). Voor een analyse van het waardenetwerk zijn

verschillende scenario’s getoetst bij onafhankelijke experts en/of zakelijke stakeholders die de

belangrijke actoren uit het generieke waardenetwerk vertegenwoordigen. Aan de hand van een

interactieve workshop werd gepoogd de sterke punten, opportuniteiten, zwaktes en bedreigingen

weer te geven voor verschillende scenario’s van het waardenetwerk voor een TranseCare platform.

1.2. Opbouw white paper

Deel één van deze white paper omschrijft de afbakening van het TranseCare platform voor deze

analyse. In een tweede wordt de definiëring en afbakening van het TranseCare platform

weergegeven. Het derde deel specificeert de bouwblokken van het waardenetwerk van TranseCare.

Deel vier gaat dieper in op de organisatie en het onderzoeksprotocol van een workshop met de

actoren van het waardenetwerk. Vervolgens staat het vijfde deel stil bij het analyseren van de

workshopdata en deel zes geeft de analyses voor verschillende scenario’s weer. Deel zes sluit af met

enkele conclusies.

1 IBBT= Interdisciplinary Institute for Broadband Technology (http://www.ibbt.be)


4

2. TranseCare platform

2.1. Definiëring

Het projectvoorstel stelt als doel binnen het TranseCare project een platform te creëren. Een platform

kan op verschillende manieren worden geïnterpreteerd.

In dit project wordt het platform begrepen als:

het samenbrengen van verschillende ICT-ondersteunde zorgdiensten die als one stop shop naar de eindgebruiker fungeren, mogelijk ook hardware hiervoor leveren, en aldus een centrale plaats innemen.

Dit platformidee past ook in de huidige trend van netwerking tussen de zorgverleners . Meer en meer

wordt werk gemaakt van overlegstructuren van zorgverleners en medici, zowel intramuraal als

extramuraal, om de patiënt een totaalzorg en -behandeling op maat aan te bieden. Eveneens komt

herhaaldelijk uit expertengesprekken en een domeinanalyse naar voor dat de compatibiliteit van

verschillende software (applicaties) een groot probleem vormt voor het gebruik binnen de zorg. Het

platformconcept heeft het potentieel en de ambitie om deze problemen achterwege te laten en de

verschillende hardware en software modulair en compatibel aan te bieden aan de eindgebruiker.

2.2. Afbakening

In de voorstelling van het platform tijdens de workshop werd gekozen voor een analytische

vereenvoudiging van de werkelijkheid. Deze keuze werd gemaakt om verlammende complexiteit in

deze eerste denkoefening te vermijden en toch voldoende discussie te stimuleren. Volgende diensten

werden voorzien (Figuur 1):

- Beeldcommunicatie via tv met meldcentrale (steun: vragen, begeleiding, etc.)

- Beeldcommunicatie via tv met alarmfunctie + extra camerabeelden voor meldcentrale indien nodig

- Beeldcommunicatie via pc met het sociaal netwerk

- Beeldcommunicatie via tv met sociaal netwerk


5

Figuur 1: Architectuur e-thuiszorgdiensten voor workshop

Wat volgt in deze white paper heeft dus deze diensten als uitgangspunt voor een e-

thuiszorgdienstplatform.

3. Bouwblokken waardenetwerk TranseCare

Het waardenetwerk is het netwerk van alle actoren die actief betrokken zijn in het ontwerpen,

produceren en leveren van een goed of dienst. De waardestromen binnen het waardenetwerk van het

TranseCare platform worden aan de hand van een model met de generieke rollen (3.1) en generieke

actoren (3.2) besproken. Er wordt hier duidelijk geopteerd om voor een waardenetwerk te kiezen,

omdat een waardeketen een te lineair beeld geeft van de waardestromen binnen dit platform.

3.1. Generieke rollen

Een rol staat voor een discrete waarde toevoegende activiteit. Onderstaand generiek model

omschrijft de opgenomen generieke rollen voor het waardenetwerk (Figuur 2).

Dit model is opgedeeld in een ontwikkelingsfase, een organisatiefase en een consumptiefase.

Deze fasen beschrijven een type activiteit (ontwikkeling, organisatie en consumptie) van een continu

doorlopend proces. Hierin wordt een systeemveld, verzorgingsveld en connectiviteitsveld

onderscheiden. Deze waardecreatiestromen beschrijven de transactie van ‘waarde’ binnen een

specifiek veld van het platform. Hiernaast krijgt ook de financiering een plaats aangezien deze rol van

invloed is op alle verschillende fasen en waardecreatiestromen.


6

Figuur 2: Generieke rollen van het waardenetwerk

3.1.1.Systeemveld

De rollen in het systeemveld zijn verdeeld over de ontwikkelingsfase, de organisatiefase en de

consumptiefase.

Rollen ontwikkelingsfase:

- Applicatieontwikkeling: het ontwikkelen van verschillende applicaties en diensten voor het platform

- Databeheer: beheer van database die nodig is om het platform te beheren (administratieve gegevens, zorggegevens, medische gegevens)

Rollen organisatiefase:

- Platformbeheer: beheren van applicaties, diensten en data op het platform

o Platformaggregatie: samenbrengen en aanbieden van applicaties op het platform o Platformaanbod: het voorzien van het technische platform dat de link legt tussen

inhoud en technologie o Dienstenaanbod: aanbieden van diensten op het platform

Rollen consumptiefase:

- Applicatiegebruik: gebruiken van applicatie/dienst van het platform


7

3.1.2.Verzorgingsveld

Rollen in het verzorgingsveld zijn verdeeld over de verschillende fasen van ontwikkeling, organisatie

en consumptie.


- Zorgontwikkeling: ontwikkelen van zorgdiensten, inclusief het opzetten en organiseren van samenwerking tussen de verschillende zorgdiensten


- Zorgverstrekking: verstrekken van zorgdiensten:

o Zorgaggregatie: samenbrengen en aanbieden van bepaalde zorgdiensten o Zorgaanbod: overkoepelende organisatie die de link legt tussen de verschillende

zorgdiensten o Dienstaanbod: aanbieden van de diensten van het platform


- Thuiszorggebruik: het gebruiken van zorgdiensten door de eindconsument

3.1.3.Connectiviteitsveld

De rollen in het connectiviteitsveld zijn verspreid over de ontwikkelingsfase, organisatiefase en

consumptiefase.


- Netwerkinfrastructuur eigendom: eigendom van de infrastructuur die nodig is om connectiviteit te leveren


- Netwerktoegang aanbod: beschikbaar stellen van de nodige connectiviteit voor het leveren (een deel van) een dienst


- Netwerktoegang consumptie: het gebruiken van het netwerk dat beschikbaar werd gesteld voor het leveren van (een deel van) een dienst

3.1.4.Financieringsrollen Subsidiëren: Financiële overheidsondersteuning

Verzekeren: Aangaan van een overeenkomst verstaan tussen een verzekeringsmaatschappij en een verzekeringsnemer om tegenover betaling van een premie een risico af te dekken Persoonlijk financieren: Het financieren met eigen middelen .


8

3.2. Generieke actoren

Een actor staat voor een getypeerde weergave van een real-life economische speler. Hieronder

worden de generieke actoren van het waardenetwerk weergegeven (Figuur 3).

Figuur 3: Generieke actoren van het waardenetwerk

Het framework van deze generieke rollen (3.1) en generieke actoren (3.2) vormen de bouwblokken

van het waardenetwerk van het TranseCare e-thuiszorgplatform.

4. Onderzoeksprotocol workshop

4.1. Doel workshop

Er werd een workshop georganiseerd om tot een validatie te komen van enkele scenario’s die het

eindresultaat zijn van een domeinanalyse, literatuuronderzoek en expertinterviews. Het uiteindelijke

doel is een duidelijker beeld krijgen van de markt, zijn rollen en actoren. Om de heersende en

conflicterende (toekomst)ideeën te ontwaren van alle actoren van het waardenetwerk omtrent het in

de markt brengen van een e-thuiszorgplatform zoals TranseCare, drong een interactieve

onderzoeksmethode zich op waarbij alle actoren bij elkaar gebracht worden.


9

4.2. Deelnemers workshop

Er werden deelnemers geselecteerd die alle actoren van het waardenetwerk vertegenwoordigen. Via

connecties van de consortiumleden en een internet-search werden een 35-tal mensen gerekruteerd.

Hierbij werd gepoogd een evenwichtige vertegenwoordiging van de actoren te selecteren. 26

bevestigden hun deelname en 23 hebben de workshop bijgewoond.

4.3. Verloop workshop

De workshop “e-thuiszorgdiensten succesvol naar huis brengen” werd 18 mei 2009 bij

consortiumpartner InHam in Gits georganiseerd. Dit deel geeft de opbouw van de workshop weer.

4.3.1.Introductie

De workshop werd ingeleid met een toelichting van het IBBT project TranseCare. Het platform met de

diensten werd besproken, ondersteund door een filmpje. De bouwblokken van het theoretische

generieke waardenetwerk uit deel 3 werden toegelicht (Figuur 2 en 3). Deze bouwblokken vormden

de basis van de workshop.

Vervolgens werd aan de hand hiervan het doel van de workshop uiteen gezet. Dit doel is het

uitwerken van het waardenetwerk (economisch en maatschappelijk) van een e-thuiszorgdienst.

Welke mogelijke actoren nemen welke mogelijke rollen op en wat zijn hier de consequenties van? De

denkoefening in de workshop dient als eerste oefening om een analyse te maken van het

waardenetwerk van een e-thuiszorgdienst, met uiteindelijk doel een strategische fit te vinden tussen

actoren en rollen. De resultaten zijn vervolgens verwerkt in de berekening van een aantal mogelijke

economische terugverdienmodellen.

4.3.2.Uitwerken in teams van user-generated scenario

De participanten werden in 4 groepen verdeeld met een moderator en twee observatoren. Elke groep

kreeg 2 scenario’s ter discussie, zodat uiteindelijk volgende 4 scenario’s werden besproken. In elk

van de geselecteerde scenario’s staat een verschillende centraal:


10

- scenario 1: externe ontwikkelaar dominant

- scenario 2: connectiviteitsleverancier dominant

- scenario 3: verzekeraar dominant

- scenario 4: overheid dominant

In de teams werd het eerste scenario door de moderator uiteengezet aan de hand van een poster

waarop de rollen van het waardenetwerk voorgesteld zijn (Foto 1). Op de poster werden de actoren

gepositioneerd. De actoren werden voorgesteld met kneedbaar creatief materiaal (Play Doh). Elke

actor kreeg een vaste kleur die tijdens de hele workshop behouden bleef. De rollen van elke actor

werden besproken. Zo werd ook duidelijk hoe de dominante actor in het scenario het waardenetwerk

domineert. De moderator liet de participanten de actoren zelf plaatsen om hen actief te introduceren

in de logica van het theoretische generieke waardenetwerk.

Foto 1 : Visualisering van de actoren en rollen van het waardenetwerk van een scenario

Vervolgens werden de actoren één voor één besproken. De moderator vroeg hierbij wat volgens de

deelnemers voor elke actor de drijvende krachten en knelpunten zijn om in dit scenario deze rollen op

te nemen. Om deze ideeën over knelpunten en drijvende krachten vast te leggen, kregen de

participanten post-its die ze individueel maakten en op wandaffiches per actor dienden te kleven.


11

Foto 2: Opkleven van drijvende krachten en knelpunten voor een bepaalde actor in een bepaald scenario

Na deze individuele oefening overliep de moderator alle post-its. Hierbij werd verduidelijking

gevraagd en discussie toegelaten. Na dit rondje kregen alle participanten 3 prioriteitenklevertjes: 3

groene voor de meest doorwegende opportuniteiten en 3 rode voor de meest doorwegende

knelpunten voor dit scenario. Elke deelnemer mocht deze kleven bij de meest doorwegende

argumenten.

Foto 3: Prioritiseren van argumenten door klevertjes

Vervolgens werd op dezelfde manier een tweede scenario met een andere dominante actor

overlopen binnen één team.

Hierna werd een pauze voorzien van een kwartier.

4.3.3.Uitwerken in teams van user-generated scenario

Na de twee opgelegde scenario’s werd aan de teams gevraagd de rollen en actoren in het netwerk

zelf een plaats te geven. Op deze manier werd discussie uitgelokt bij de deelnemers over de beste

strategische fit tussen actoren en rollen. Hierbij stuurde de moderator vooral aan op beargumentering

van de keuzes. Indien de deelnemers de generieke actor concreet wilden specificeren konden ze

gebruik maken van vlagjes met de naam van de specifieke actor.

4.3.4.Plenaire voorstelling user-generated scenario’s + vragen

In een achtereenvolgende plenaire sessie werd per groep het ideale scenario voorgesteld. Een foto

van de visuele voorstelling werd geprojecteerd. De moderator gaf hierbij de overwegingen aan die het


12

team maakte om tot hun scenario te komen. Na elke voorstelling was er ruimte voor enkele vragen

en/of tegenargumenten vanuit het publiek.

Foto 4: Plenaire voorstelling van user-generated scenario’s

5. Dataverzameling workshop

Elk team beschikte over 2 observatoren die de observatieschema’s invullen. Na elk scenario werd

een foto gemaakt van de posters van knelpunten en drijvende factoren van de actor. Ook werd een

foto gemaakt van de visuele voorstelling van het ‘user-generated scenario’. De ‘break-out’ sessies in

teams werden gefilmd. Op het einde van de workshop werd aan de deelnemers gevraagd een

deelnemersformulier in te vullen.

Deze data is de basis voor de analyse waar in het volgende deel de resultaten van worden

weergegeven.

6. Resultaten

6.1. Reflectie resultaten

De resultaten worden in het volgende punt (6.2) besproken per scenario. Een matrix geeft voor elk

scenario een puntsgewijze opsomming van enerzijds de sterktes en opportuniteiten en anderzijds de

zwaktes en bedreigingen per actor. Na elke matrix volgt een bondige bespreking. 6.3 geeft de user-

generated scenario’s weer per groep, telkens gevolgd door de beargumentering van de gemaakte

keuzes.

Deze resultaten pretenderen zeker niet een volledig overzicht te geven. Het doel van dit onderzoek

was in de eerste plaats een inzicht te verwerven in de SWOT factoren die volgens de actoren zelf een

rol spelen in de keuze van een business-scenario. De resultaten dienen dan ook in dit opzicht te

worden geïnterpreteerd.


13

6.2. Analyse scenario’s

6.2.1.Externe ontwikkelaar dominant


14

MATRIX EXTERNE ONTWIKKELAAR DOMINANT

EXTERNE ONTWIKKELAAR DOMINANT

Sterktes/Opportuniteiten

Zwaktes/Bedreigingen

Ex

tern

e o

ntw

ikk

ela

ar

" samenwerking met connectiviteitsleverancier mogelijk voor interessante pakketten

" machtspositie

" controle over aanbod en oplossingen " controle over productiekosten " weinig concurrentie: winst en controle bij

zelfde

" aansturen en domineren van de markt

" mogelijkheid om zelf oplossingen te maken

" controle over oplossingen/aanbod

" winstpositie

" koppeling hard- en software binnen één organisatie

" moeilijke inschatting prijszetting en ROI; prijszetting afhankelijk van financiering

" machtspositie kan ten nadele zijn voor andere externe ontwikkelaars: risico monopolie: vendor lock-in

2 (geldt ook

voor verzekeraar, thuiszorgorganisatie, etc)

" hoge promotie- en verkoopkosten (o.a. doordat het product niet afgestemd is op de gebruiker)

2 Vendor lock-in beschrijft een vorm van koppelverkoop waarmee klanten afhankelijk gemmaakt worden van een bepaald

product of dienst door een externe ontwikkelaar die mededinging van de markt belemmert.


15

Ein

dg

eb

ruik

er

" snellere service & product updates o.a. door technische expertise van de ontwikkelaar

" één actor veel in handen: ten goede van de gebruiksvriendelijkheid en transparantie

" duidelijk aanspreekpunt bij problemen: firma is gekend

" garantie op privacy <-> commerciële belangen

" vrije keuze van zorgaanbod? (lock-in)

" betaalbaarheid? (voor iedereen)

" toegankelijkheid: hoog technologische ontwikkelingen (teveel technologie, te hoog gegrepen voor de gebruiker)

" monopolieagenda op termijn: ontwikkelaar kan beslissen om dienst niet meer te leveren omdat het voor hem niet meer interessant is

" weinig aandacht voor en weinig inspraak

van de eindgebruiker (bv niet de diensten die nodig zijn)

" onzekerheid omtrent duurzaamheid

" onbereikbaarheid bij vragen wegens anonieme gezicht van de ontwikkelaar

Co

nn

ec

tiv

ite

its

-le

ve

ran

cie

r

" mogelijkheden wanneer mobiel netwerk gebruikt wordt (bv voor een 5-tal euro /dag/gebruik)

" tussenpersoon (ondergeschikte rol): geen extra effort

" connectiviteitsleverancier zal liever pakket verkopen (met tv all in)

" krijgt de klachten over de application provider en kan ze niet behandelen

Th

uis

zo

rgo

rga

nis

ati

e

" ontlasting indien ontwikkelaar ervoor zorgt dat de interventies gebeuren (bv technisch luik, aanleren gebruik, etc.)

" duidelijk aanspreekpunt bij problemen, bij vragen naar nieuwe functionaliteiten van de gebruiker, voor optimalisatie dienst/product

" geen medezeggenschap in nieuwe producten: mogelijk geen gevolg op vragen wegens machtspositie

" toegankelijkheid voor alle zorgorganisaties <-> geprefereerde partners

" krijgen de klachten over externe ontwikkelaar binnen, maar kunnen er niks mee aanvangen


16

Ve

rze

ke

raa

r

" technische ontwikkelingen gegarandeerd

" investering minimaal aangezien het geen hoofdactiviteit is

" hoeft kernactiviteit niet te wijzigen; ontwikkeling diensten/producten is geen kernactiviteit van de verzekeraar

" duur wegens o.a. niet modulair; verplicht

pakket van functionaliteiten, connectiviteit

" geen inzicht in het huidige en/of toekomstige aanbod

" niet de mogelijkheid om een health efficiency index te bepalen

" geen inzicht in financiering en kostefficiëntie (health technology assessment)

Ov

erh

eid

" technische ontwikkelingen gegarandeerd

" weinig controle

" afhankelijk van ontwikkelaar

" moeilijk aan te tonen meerwaarde

" (te) late betrokkenheid => oog voor competitiviteit, beperking van de middelen (<-> the sky is the limit), technologische interoperabiliteit

" geen inzicht in effecten van financiering

BESPREKING MATRIX EXTERNE ONTWIKKELAAR DOMINANT

Hieronder wordt voor elke actor een samenvatting gegeven van de sterktes, opportuniteiten, zwaktes

en bedreigingen die het meest doorwogen tijdens de discussie van dit scenario:

• De externe ontwikkelaar heeft in dit scenario het voordeel van macht, controle en grote

winstmogelijkheden. De externe ontwikkelaar kan de markt aansturen en domineren. Ook kan

hij gaan samenwerken met een connectiviteitsleverancier. Aangezien slechts één actor het

systeemveld domineert, wordt verwacht dat de dienst en applicaties sneller zullen worden

geüpdatet. Ook wordt verwacht dat de dienst gebruiksvriendelijker en transparanter zal zijn.

De monopoliepositie van de externe ontwikkelaar kan echter enkele belangrijke aspecten

voor de eindgebruiker in het gedrang brengen. Zo’n positie heeft namelijk invloed op de

betaalbaarheid, de toegankelijkheid en de duurzaamheid. De garantie op privacy wordt ook in

vraag gesteld omdat dit in conflict kan zijn met de commerciële doelstellingen van de externe

ontwikkelaar.


17

• De connectiviteitsleverancier krijgt in dit scenario geen vooraanstaande rol. Dit heeft

volgens de deelnemers als voordeel dat deze actor geen extra inspanning dient te leveren bij

implementatie van het platform. Tegelijkertijd biedt dit scenario het voordeel om via het

mobiel netwerk te opereren en zonder veel moeite een ‘nieuwe’ populatie aan te spreken. De

deelnemers denken echter dat de connectiviteitsleverancier eerder geïnteresseerd zal zijn in

het aanbieden van pakketten en de diensten liever niet door de externe ontwikkelaar alleen

laat bepalen. Dit scenario heeft ook als mogelijk nadeel dat de connectiviteitsleverancier de

klachten over de diensten ontvangt, maar deze aldus niet kan behandelen omdat het platform

wordt beheerd door de externe ontwikkelaar.

• Dit scenario heeft volgens de deelnemers als voordeel dat ook de thuiszorgorganisatie een

duidelijk aanspreekpunt heeft aangezien één actor het platform beheert. Het is ook mogelijk

dat dit scenario ervoor zorgt dat de thuiszorgorganisatie ontlast is in zorg (tijd, technische

ondersteuning, personeel). Een mogelijke zwakte in dit scenario is volgens hen dat de

thuiszorgorganisatie niet betrokken wordt in het ontwikkelen en updaten van (nieuwe)

diensten. Een ander knelpunt is dat de externe ontwikkelaar mogelijk enkel in zee wil gaan

met de geprefereerde zorgpartners. Het is ook mogelijk dat de thuiszorgorganisatie klachten

over de dienst ontvangt, maar ze aldus niet kan behandelen (cfr de

connectiviteitsleverancier).

• In dit scenario kan de overheid volgens de deelnemers zeker zijn dat de technische

ontwikkelingen gegarandeerd zullen zijn. Anderzijds heeft de overheid weinig of geen

controle in dit scenario en is ze volledig afhankelijk van de ontwikkelaar. De meerwaarde van

(de diensten op) het platform is moeilijk aan te tonen. Er wordt ook gevreesd voor een late

betrokkenheid in het ontwikkelen en implementeren van het platform waardoor de overheid

geen greep heeft op o.a. het garanderen van competitiviteit; het beperken van middelen en

technologische interoperabiliteit.

Opvallend in de discussies rond dit scenario is dat verwacht wordt dat er op geen subsidiëring kan

gerekend worden. Er worden ook vragen gesteld bij de bereidheid van eindgebruikers om de diensten

zelf te financieren. Er wordt onder andere opgemerkt dat uit een bevraging gebleken is dat mensen

niet meer willen betalen voor een personenalarmsysteem met beeld dan voor een klassiek model.

Daarom is de prijszetting in dit scenario een belangrijk discussiepunt. De meeste actoren (exclusief

de externe ontwikkelaar) gaan ervan uit dat de dominante externe ontwikkelaar niet zal luisteren naar

de markt en het terrein en de klant niet kent.


18

6.2.2.Verzekeraar dominant


19

MATRIX VERZEKERAAR DOMINANT

VERZEKERAAR DOMINANT



Ex

tern

e

on

twik

ke

laa

r

/

/

Ein

dg

eb

ruik

er

" compatibiliteit van verschillende zorgdiensten

" één aanspreekpunt (bvb mutualiteit) " inspraak

" pakket op maat van noden

" netwerkconnectiviteit prijs concurrentie => lagere kost

" veilig, betrouwbaar

" eenzijdige keuze (één verzekeraar voor bepaalde dienst; grote variatie in zorgvragen)

" aanbod beperkt (afhankelijk van prioriteiten van verzekeraar)

" verschillend aanbod per verzekeraar

" betaalbaar voor iedereen (focus op kostenbeheersing door verzekeraar)

" privé verzekeraar: minder inspraak

" privacy

" sturend monopolie

" langere ontwikkelingsduur (niet gedreven vanuit privé)

" niet transparant en eenvoudig op servicevlak: verzekeraar is aanspreekpunt, maar moet doorverwijzen naar externe partners voor oplossing -> duurt langer

Co

nn

ec

tiv

i-te

its

lev

era

nc

ier

" kleine rol in het geheel: geen extra moeite


20

Th

uis

zo

rgo

rga

nis

ati

e

" samenwerkingsmogelijkheden tussen verschillende disciplines

" zelfstandige thuisverpleegkundigen vallen buiten het model

" moeilijk voor onafhankelijke zorgorganisaties

Ve

rze

ke

raa

r

" keuze van aanbod functionaliteiten

" reeds cliënten; totaal aanbod aan eigen leden

" coördinerende functie

" kostenbeheersing

" organisatie/integratie in de thuiszorg

" onvoldoende ervaring

" kostprijs netwerkinfrastructuur

" moeilijke integratie tussen alle netwerken- verschillende actoren/ gegevensuitwisseling

Ov

erh

eid

" doorzichtige prijspolitiek " weinig (nieuwe) actoren en partners

" kost

BESPREKING MATRIX VERZEKERAAR DOMINANT



• Voor de externe ontwikkelaar worden geen specifieke aspecten aangehaald.

• De deelnemers vinden dit scenario positief voor de eindgebruiker omwille van een

vermoedelijk grotere compatibiliteit met de zorgdiensten. Omdat de zorgverzekeraars ‘dichter’

bij de eindgebruiker staan wordt inspraak van de eindgebruiker verwacht met een veiligere,

betrouwbare dienst op maat tot gevolg. Concurrentie tussen de verschillende verzekeraars

zou er bovendien kunnen voor zorgen dat de kost voor de eindgebruiker laag blijft. Een

eenzijdig aanbod per verzekeraar en verschillend aanbod bij de verzekeraars onderling kan

dan weer ten nadele zijn van de eindgebruiker en net de keuzevrijheid en compatibiliteit van

applicaties en diensten in de weg staan. Kostenbeheersing door de verzekeraar zou volgens


21

de deelnemers ook de betaalbaarheid voor de eindgebruiker in de weg staan. De verzekeraar

kan de beschikbare gegevens ook gebruiken voor eigen doeleinden wat de privacy van de

eindgebruiker in het gedrang kan brengen. Sommigen vrezen door de verscheidenheid aan

verzekeraars (mutualiteiten) dat het zorgaanbod niet transparant en eenvoudig zal zijn voor

de eindgebruiker. Wanneer het systeem door een privéverzekeraar wordt aangeboden,

verwacht de deelnemers dat de eindgebruiker nog minder inspraak zal hebben.

• De kleine rol van de connectiviteitsleverancier in dit scenario heeft volgens de deelnemers

als voordeel dat extra inspanning voor deze e-thuiszorgdiensten voor deze actor beperkt blijft.

• Het voordeel in dit scenario voor de thuiszorgorganisatie is volgens de deelnemers dat de

samenwerking tussen verschillende zorgdisciplines beter zal verlopen omdat er reeds

samenwerkingsverbanden bestaan tussen zorgverzekeraars en thuiszorgorganisaties.

Thuiszorgorganisaties die geen directe link hebben met een zorgverzekeraar en zelfstandige

thuisverpleegkundigen vallen dan echter wel uit de boot.

• De deelnemers vinden een sterk punt voor verzekeraar in dit scenario dat deze actor zelf de

functionaliteiten en/of diensten kan bepalen en coördineren. De verzekeraar heeft het

voordeel al over een groot potentieel klantenbestand te beschikken. Door de dominante

positie in dit scenario is de verzekeraar ook in staat de kosten te beheersen. Sommigen zien

het gebrek aan ervaring van de verzekeraar in dit domein als een struikelblok voor de

organisatie en integratie in alle zorgnetwerken. Het wordt ook als een nadeel beschouwd dat

de verzekeraar afhankelijk is van (de kostprijs van) de netwerkinfrastructuur in dit scenario.

• Een sterkte voor de overheid is volgens de deelnemers dat er een doorzichtige prijspolitiek is

in dit scenario. Er zijn ook weinig (nieuwe) actoren en partners voor de overheid. Een zwakte

voor de overheid is dan volgens hen weer de kost van deze diensten waar de overheid geen

controle over heeft.

Tijdens de discussie komen ook bedenkingen naar boven over de huidige rol van de verzekeraar. De

rol van die zorgverzekeraar is geëvolueerd, waardoor hij voor een stuk het persoonlijke contact met

de eindgebruiker dreigt te verliezen. Ziekenfondsen nemen steeds meer en verscheidene taken op,

zodat ze steeds minder kunnen gezien worden als de belangenverdediger van de eindgebruiker.


22

6.2.3.Overheid dominant


23

MATRIX OVERHEID DOMINANT

OVERHEID DOMINANT



Ex

tern

e o

ntw

ikk

ela

ar

" lock-in door overheidsopdrachten: beperktere concurrentie

" overheid kan noden beter aanbrengen via beschikbare data en onderzoek (link tussen aanbieder en vraag)

" schaalvoordeel: mogelijk om op grote schaal uit te rollen

" marktverstorend, tragere innovatie

" winstmarges dalen: overheid kan maximumtarieven opleggen

" lobbywerk

" onzekerheid voor de producent: langere termijnvisie overheid?

" overheid kan strikt kader oplegt => inboeten zorgaanbod/functionaliteiten

" onzekerheid voor de externe ontwikkelaar (openbare aanbestedingen met de overheid levert minimaal -10% in tijd en kost)

" overheid belemmert (applicatie/box) opportuniteiten

" verschillende staatsstructuren => complexiteit in ontwikkeling


24

Ein

dg

eb

ruik

er

" toegankelijkheid gegevens is (beter) gegarandeerd

" kwaliteitsgarantie doordat overheid dit kan opleggen

" overheid kan standaardisatie opleggen

" diensten beter afgestemd op elkaar door overzicht van de kostenstructuur (geconsumeerde diensten en producten per gebruiker)

" verzuiling vervalt

" betere controle patiëntengegevens (vertrouwen)

" betrouwbaarheid

" betaalbaarheid " laagdrempeligheid

" duur: openbare aanbestedingen maken

de kosten hoger

" marktwerking sterk verstoord; trage innovatie

" gebrek aan flexibiliteit

" meer verzuiling als via de mutualiteiten wordt aangeboden

" aanbod gestuurd

" helpdesk?

" traceerbaarheid persoonlijke gegevens is moeilijker

" “Big brother”: transparantie-privacy=> overheid weet/ziet alles

" stemmenwinnerij versus lange termijnvisie?

Co

nn

ec

tiv

i-te

its

lev

era

nc

ier

" positief als overheid kiest voor verschillende leveranciers

" dienst met bijhorende connectiviteit wordt

op grote schaal uitgerold

" negatief als overheid één leverancier

kiest om de dienst aan te bieden

Th

uis

zo

rgo

rga

nis

ati

e

" meer kans toe dat alle

thuiszorgorganisaties kunnen instappen, niet enkel geprefereerde partners

" centrale aanbieder: weet tot wie richten

" subsidiëring => betaalbaarheid

"

" aanbestedingsregels

" teveel controle vanuit de overheid " welke instantie zal zorgen voor centrale

aanbod " aanspreekpunt? (traditie van niet

bereikbare overheidsinstanties) " centrale aanbieder kan ook negatief zijn

omdat er geen alternatieven zijn " in principe geen thuiszorgorganisaties

betrokken in dit scenario " marktverstorend, tragere innovatie


25

Ve

rze

ke

raa

r

" door dominantie van overheid vervalt verschil tussen ziekenfondsen (overheid betaalt iedereen evenveel terug; geen competitie)

" zicht op kostenstructuur

" overheid als “Big Brother” door

toenemende transparantie: overheid heeft instrumenten in handen om controles op verzekeraars op te voeren

" minder snelle ontwikkeling door de overheid

Ov

erh

eid

" beter inzicht in de kostenstructuur (door grote transparantie en centralisatie van gegevens)

" betere controle patiëntengegevens " verder bouwen op bestaande databases

(bv kruispuntbank etc.) " prijssturing " grotere implementatie thuiszorgsystemen " minder kosten voor opnames, RVT

" trage innovatie

" tegelijk kennis verwerven en uitvoeren van diensten is dubbele kost, terwijl ze toch beroep zal doen op externe ontwikkelaars voor realisatie

" kostenstijging door aanbestedingsprocedures

" spanningsveld tussen overheden (provincie, Vlaams, federaal,...)

" subsidies: duur

" winst zit mogelijk niet bij de plaats waar het gesubsidieerd wordt

BESPREKING MATRIX OVERHEID DOMINANT



• In het scenario heeft de externe ontwikkelaar volgens de deelnemers de opportuniteit om

via overheidsopdrachten een monopoliepositie in te nemen. De deelnemers zien het als een

sterkte dat de overheid de gebruikersnoden kan aanbrengen aan de externe ontwikkelaar. De

overheid beschikt volgens hen immers over accurate data en onderzoek hiervoor. Een

andere grote opportuniteit voor de externe ontwikkelaar is de mogelijkheid tot uitrollen van het

platform op grote schaal. Voor de externe ontwikkelaar kan de overheid volgens de

deelnemers echter ook verlammend werken gezien de trage innovatie door (over)regulering.

De overheid kan ook maximumtarieven en restricties opleggen waardoor de winstmarges

voor de externe ontwikkelaar kunnen dalen en de uitbouwmogelijkheden verkleinen. Dit

brengt heel wat onzekerheid mee voor de externe ontwikkelaar. Een lange termijnvisie bij de

overheid ontbreekt volgens de deelnemers ook dikwijls, wat deze onzekerheid versterkt. Dit

vraagt volgens hen ook extra tijd en kosten voor de externe ontwikkelaar (lobbywerk en


26

verlies van potentiële winsten). Volgens de deelnemers maken de verschillende

staatsstructuren de onderhandelingen, regelgeving en ontwikkeling bovendien complex.

• De toegankelijkheid, betrouwbaarheid, betaalbaarheid, laagdrempeligheid, kwaliteit en

compatibiliteit (via standaardisatie) kunnen, volgens de deelnemers, in dit scenario beter aan

de eindgebruiker gegarandeerd worden omdat de overheid geen commerciële doelen

nastreeft. Diensten kunnen beter op elkaar afgestemd worden doordat er een duidelijk

overzicht is van de kostenstructuur. De verzuiling vervalt als de overheid zelf organiseert en

de taken niet doorschuift naar de mutualiteiten. Het vertrouwen bij de eindgebruiker zou

volgens de deelnemers ook groter kunnen zijn omwille van een betere controle van het

gebruik en toegang tot patiëntengegevens. Anderzijds kan volgens hen de kostprijs in dit

scenario hoog worden omdat openbare aanbestedingen meestal hoge kosten maken. De

marktwerking kan volgens de deelnemers sterk verstoord zijn wanneer de overheid domineert

waardoor de ontwikkelingen trager gaan en de eindgebruiker geen of laat gebruik kan maken

van de diensten. Gebrek aan flexibiliteit van de overheid speelt volgens hen ook in het nadeel

van de eindgebruiker. De eindgebruiker heeft volgens de deelnemers geen vrije keuze in het

aanbod en krijgt hierdoor een passieve rol in het waardenetwerk. Er wordt ook gevreesd voor

een overheid die alles weet en ziet (“Big Brother”) in dit scenario. De privacy voor de

eindgebruiker kan volgens hen hierdoor in het gedrang komen. Traceerbaarheid van

persoonlijke gegevens kan moeilijker worden voor de eindgebruiker. Eveneens vrezen de

deelnemers dat de overheid niet over een lange termijnvisie beschikt, maar vooral legislatuur

(stemgebonden) optreedt. Indien de overheid de mutualiteiten betrekt bij het aanbieden van

de diensten, kan dit volgens hen zorgen voor een verdere verzuiling van de thuiszorg. De

overheid wordt door de deelnemers niet gezien als een geloofwaardige actor voor o.a. een

helpdesk-rol omdat de overheid beschouwd wordt als een actor die ver van de concrete

praktijk staat.

• Voor de connectiviteitsleverancier is dit scenario positief als de overheid gaat kiezen voor

verschillende leveranciers omdat alle leveranciers hier dan kunnen op inspelen. Voor de

connectiviteitsleverancier kan dit scenario negatief zijn als de overheid kiest voor één

leverancier (tenzij voor de leverancier die zelf over het monopolierecht beschikt) omdat de

andere leveranciers dan uit de boot vallen.

• Wanneer de overheid het scenario domineert, is er meer kans dat alle

thuiszorgorganisaties betrokken zullen worden en niet alleen geprefereerde partners (zoals

in de andere scenario’s). De thuiszorgorganisaties weten ook tot wie ze zich moeten richten

omdat er een centrale aanbieder is. Anderzijds worden diensten die door de overheid

aangeboden volgens de deelnemers geassocieerd met omslachtige aanbestedingsregels,


27

trage innovatie, onbereikbaarheid en controle. De vraag wordt ook gesteld welke

overheidsinstantie zal instaan voor het centrale aanbod. In principe kan dit scenario volledig

zonder thuiszorgorganisaties op til worden gezet. Indien de overheid taken doorgeeft aan de

ziekenfondsen blijven een aantal thuiszorgorganisaties (die geen vaste samenwerking

hebben met een ziekenfonds) buiten spel. Het centrale aanbod van de overheid kan ook een

zwakte zijn voor de thuiszorgorganisatie, omdat er op deze manier geen alternatief is.

• Door de dominantie van de overheid kan het verschil tussen de verzekeraars (mutualiteiten)

volgens de deelnemers ten dele vervallen omdat de overheid op een gelijke manier

subsidieert en er geen competitie is. Een sterkte van dit scenario voor de mutualiteiten kan

zijn dat ze een overzicht krijgen op de kostenstructuur. Anderzijds is de overheid volgens de

deelnemers ook de verzekeraar een controlerend orgaan. Door de dominante positie in dit

scenario kan een overheid als “Big Brother” optreden. De overheid heeft volgens hen

instrumenten in handen die zorgen voor een toenemende transparantie wat controles op

verzekeraars mogelijk maakt. De deelnemers zijn ook van mening dat trage innovatie bij een

overheid dominant scenario een zwakte is voor de verzekeraar.

• Voor de overheid zelf heeft dit scenario volgens de deelnemers als grote sterkte dat ze

controle krijgt op de diensten, kostenstructuur, patiëntengegevens en databases. De overheid

kan de prijs sturen en via het platform kosten besparen (minder kosten voor opnames,

residentiële zorg). De overheid kan ook zorgen voor een grotere inbedding in de bestaande

thuiszorgsystemen. De belemmerende factoren zijn volgens de deelnemers de trage

innovatie, de kosten die gepaard gaan met aanbestedingsprocedures en het spanningsveld

tussen de verschillende overheden. De vraag wordt ook gesteld of het verwerven van kennis

en applicatieontwikkeling wel een rol is voor de overheid, als die toch beroep moet doen op

externe ontwikkelaars. De winsten komen ook mogelijk niet terecht op de plaats waar ze

gesubsidieerd worden.

Bij het scenario waarbij de overheid dominant is in het waardenetwerk, overheerst het idee van

overheid als log orgaan met sowieso verlies aan tijd en middelen. De deelnemers nemen aan dat

innovaties trager zouden doorbreken en minder op de markt inspelen ten nadele van alle actoren.

Zelfs voor de overheid zou dit een nadeel zijn aangezien ze investeert in iets dat niet (voldoende)

oplevert (kwaliteit, middelen).

De opmerking valt ook dat gesubsidieerde projecten niet als een voorbeeld van dit scenario kunnen

gezien worden, omdat de overheid wel initiatiefnemer is, maar alle rollen door andere actoren worden

opgenomen.


28

6.2.4.Connectiviteitsleverancier dominant


29

MATRIX CONNECTIVITEITSLEVERANCIER DOMINANT

CONNECTIVITEITSLEVERANCIER DOMINANT



Ex

tern

e

on

twik

ke

laa

r

" samenwerking met connectiviteitsleverancier => economies of scope (meer diensten dan thuiszorg)

" kan buitenspel worden gezet indien één connectiviteitsleverancier dominant is

" in concurrentie met box ontwikkelaars van connectiviteitsleverancier

Ein

dg

eb

ruik

er

" reeds gebruiker van dienst (infrastructuur/basispakket is aanwezig)

" gekende actor; centraal aanspreekpunt

" goedkoper door minder investering in hardware en economy of scale

" digitale kloof dichten door andere services aan te bieden

" monopoliepositie (“virtuele privatisatie”): beperkte keuze, grote kost, verplicht bij één connectiviteitsleverancier diensten te nemen en/of andere diensten bij te nemen

" privacy: wie heeft klant zijn gegevens?

" geen of weinig controle

" gebruiker staat niet centraal => teveel aandacht voor commerciële diensten; korte termijndenken

" pay per use

" onpersoonlijk

" lage kennis van first line helpers

" verschillende connectiviteitsleveranciers die dienst aanleveren: problematiek voor interoperabiliteit tussen mensen, artsen, thuiszorgorganisaties, verzekeraars,...

" connectiviteitsleveranciers zullen enkel focussen op grote doelgroepen; bepaalde zorgafhankelijken vallen uit de boot


30

Co

nn

ec

tiv

ite

its

lev

era

nc

ier

" monopoliesituatie " bepaalde (nieuwe) doelgroepen bereiken

met groter marktaandeel als gevolg " infrastructuur bestaat al bij veel mensen " korte time to market " uitbreiding van bestaande

infrastructuur/diensten (bv. digitaal platform)

" klantenwerving/binding: alle actoren op

zelfde netwerk " makkelijker afgeleide diensten aanbieden

in samenwerking met bvb een privéverzekeraar

" probleem als de gebruiker niet wil veranderen van leverancier voor deze dienst(en)

" subsidiëring moeilijker

" afhankelijk van tegemoetkomingen, terugbetaling, premies (overheid/mutualiteiten)

" argwaan van klanten i.v.m. privacy

" geen core business

" cliënteel afhankelijk van thuiszorgorganisaties

" concurrentie tussen verschillende aanbieders

Th

uis

zo

rgo

rga

nis

ati

e

" contact met alle leden van het verzorgingsnetwerk: kunnen coördinerende rol opnemen

" ontwikkeling extern – in samenwerking met de connectiviteitsleverancier (thuiszorgorganisatie heeft niet de expertise in huis)

" één aanspreekpunt

" moeilijke prijszetting (monopolie op de markt)

" moeilijkere concurrentie – moeite om te differentiëren

" opleiding van medewerkers – snelle evolutie van technologie

" weinig inspraak in het ontwikkelingsproces

Ve

rze

ke

raa

r

" één aanbieder – één factuur

" minder visibiliteit

" nomenclatuur? RIZIV?

Ov

erh

eid

" schaalvoordeel: snel grote doelgroep die bereikt kan worden

" monopolie

" weinig ruimte om beleid te sturen

" kostefficiënt?

BESPREKING MATRIX CONNECTIVITEITSLEVERANCIER DOMINANT




31

• De deelnemers zijn van mening dat de externe ontwikkelaar in dit scenario de opportuniteit

heeft om op grotere schaal applicaties aan te bieden. De connectiviteitsleverancier heeft

immers het potentieel veel mensen te bereiken, in combinatie met andere (meer) diensten

dan (thuis)zorg. Anderzijds kan de externe ontwikkelaar gemakkelijk buitenspel worden gezet

gezien de dominante positie van de connectiviteitslevancier. De deelnemers nemen aan dat

door dit risico de motivatie voor de externe ontwikkelaar klein zal zijn om te investeren in

dergelijke diensten en/of applicaties in dit scenario. Bovendien vermoeden de deelnemers dat

de externe ontwikkelaar met het ontwikkelen van dergelijke applicaties en diensten in

concurrentie treedt met de ‘set-top box’ ontwikkelaars van de connectiviteitsleverancier.

• De deelnemers menen dat de eindgebruiker in dit scenario het voordeel heeft dat er al

gebruik kan gemaakt worden van bestaande en/of aanwezige infrastructuur (bvb. decoder,

internetconnectie). Bovendien is de connectiveitsleverancier een gekende actor en heeft de

eindgebruiker dus een centraal aanspreekpunt (er is al sprake van een klantenrelatie). Het is

volgens hen ook mogelijk dat de applicatie en/of dienst goedkoper wordt doordat er minder

investering in hardware nodig is en door de voornoemde economies of scale. Sommigen zien

hierin een brug om een populatie te bereiken die (nog) niet met internet vertrouwd is en op

deze manier voor een stuk de digitale kloof te dichten. Anderzijds kan door de beperkte

concurrentie (monopoliepositie) de keuze kleiner en kostprijs hoger (o.a. door pay per use)

worden voor de eindgebruiker. Door deze monopoliepositie kan de eindgebruiker verplicht

worden om bij één connectiviteitsleverancier alle diensten te nemen. Een deelnemer heeft het

in deze context over ‘virtuele privatisering’. Eveneens is het voor de eindgebruiker niet meer

duidelijk wie over zijn/haar gegevens beschikt. Er wordt ook gevreesd dat de

connectiviteitsleverancier teveel aandacht zal hebben voor commerciële diensten en een

korte termijnvisie zal hanteren. De deelnemers vrezen dat de connectiviteitsleverancier

bijvoorbeeld enkel zal focussen op grote doelgroepen waardoor bepaalde zorgafhankelijken

uit de boot vallen. De connectiviteitsleverancier wordt ook beschouwd als een onpersoonlijke

actor met weinig/geen ervaring met eerstelijnswerkers en aldus moeilijk bereikbaar voor de

eindgebruiker.

• De connectiviteitsleverancier heeft in dit scenario een sterke positie. Met deze e-

thuiszorgdiensten kan de connectiviteitsleverancier volgens de deelnemers (nieuwe)

doelgroepen bereiken en bestaande infrastructuur/diensten uitbreiden (bvb. digitaal platform).

Het is een ideale positie voor klantenwerving en klantenbinding aangezien de leverancier kan

afdwingen dat alle actoren op hetzelfde netwerk dienen te opereren. De deelnemers zien ook

als voordeel dat ze al over een groot klantenbestand beschikt en er al een deel van de

infrastructuur bij de eindgebruikers aanwezig is met een korte time to market als gevolg.

Bovendien kan de leverancier gemakkelijk afgeleide diensten aanbieden in samenwerking


32

met bvb. een privéverzekeraar. Anderzijds bestaat volgens de deelnemers de kans dat de

eindgebruiker niet zal willen veranderen van leverancier voor deze dienst(en). De

eindgebruiker zal deze actor ook meer argwanen in verband met privacy. Ondanks de sterke

positie van de connectiviteitsleverancier denken de deelnemers dat deze actor afhankelijk is

van de overheid en de verzekeraar voor tegemoetkomingen, terugbetaling en premies. De

connectiviteitsleverancier heeft volgens hen als bijkomend nadeel dat ‘zorg’ niet behoort tot

haar kerntaken en dat er concurrentie zal zijn tussen de verschillende leveranciers.

• De deelnemers denken dat de thuiszorgorganisatie in dit scenario een coördinerende rol

zou kunnen opnemen om de connectiviteitsleverancier in contact te brengen met alle leden

van het verzorgingsnetwerk. De deelnemers zijn van mening dat het een sterkte is voor de

thuiszorgorganisatie dat er een duidelijk aanspreekpunt is. De monopoliepositie van de

connectiviteitsleverancier in dit scenario zorgt volgens hen echter voor een moeilijke

prijszetting voor de thuiszorgorganisatie. Bovendien heeft de thuiszorgorganisatie volgens

hen geen of weinig inspraak in dit scenario. De thuiszorgorganisatie kan moeilijk concurreren

en differentiëren als ze geen rol speelt in dit scenario. De vraag wordt ook gesteld hoe en

door wie zorgmedewerkers opgeleid zullen worden om met de snel evoluerende technologie

te leren werken.

• Een groot pluspunt dat aangehaald wordt is het geraffineerd factuursysteem dat de

connectiviteitsleveranciers reeds hanteren. Dit bespaart de verzekeraar veel werk. Er worden

wel vragen gesteld hoe deze diensten van de connectiviteitsleverancier een plaats zullen

krijgen in de nomenclatuur. De verzekeraar verliest volgens de deelnemers de kans op het

beheer van interessante data.

• De deelnemers halen aan dat de overheid in dit scenario over de opportuniteit beschikt om

snel een grote doelgroep te bereiken. De overheid krijgt volgens hen evenwel minder ruimte

om het beleid te sturen en er worden vragen gesteld bij de kostefficiëntie wanneer de

connectiviteitsleverancier dergelijke monopoliepositie heeft.

Opvallend is dat de meeste deelnemers niet voor dit scenario gewonnen zijn. De grootste nadelen

ziet men in de beperkte inspraak van de thuiszorg; de lock-in voor de eindgebruiker; het gebrek aan

ervaring op het domein voor de connectiviteitsleverancier (geen kernactiviteit). Vele knelpunten en

bedreigingen in dit scenario kunnen eventueel gedeeltelijk opgevangen worden door een strikt

lastenboek van de overheid dat kwaliteitsgaranties biedt waartegenover subsidiëring kan staan. De

grootste positieve punten zijn hier: één duidelijk gekend aanspreekpunt; integratie in bestaande

systemen en korte time to market.


33

6.3. User-generated scenario’s

Groep 1

Foto’s 5: User-generated scenario’s groep 1

WAARDENETWERK USER-GENERATED SCENARIO GROEP 1

De eerste groep raakt niet tot een consensus en werkt 2 verschillende scenario’s uit.

• In een eerste scenario (Foto’s 5 links) krijgt de overheid binnen het financieringsveld de rol

van subsidiëren; de verzekeraar de rol van verzekeren en de overheid samen met de

eindgebruiker de rol van persoonlijk financieren.


34

Binnen het systeemveld krijgt de overheid samen met de externe ontwikkelaar de rol van

applicatieontwikkeling. De thuiszorgorganisatie krijgt de rol van databasebeheer en het

platformbeheer wordt toegewezen aan de actoren overheid, verzekeraar,

thuiszorgorganisatie en externe ontwikkelaar.

Binnen het verzorgingsveld krijgt de overheid de rol van zorgontwikkeling. Het zorgaanbod

wordt aan de actor thuiszorgorganisatie toegewezen.

In de consumptiefase worden de rollen applicatiegebruik, thuiszorggebruik en

netwerktoegangconsumptie opgenomen door de eindgebruiker.

• Het tweede scenario (Foto’s 5 rechts) verschilt met het eerste in het verzorgingsveld. De

zorgontwikkeling wordt hier door de actoren overheid, verzekeraar, thuiszorgorganisatie en

eindgebruiker opgenomen. Het zorgaanbod gebeurt in dit scenario door de verzekeraar en de

overheid.

In dit scenario krijgt de overheid ook een rol in de netwerkinfrastructuureigendom.

BESPREKING USER-GENERATED SCENARIO GROEP 1

Wat de financiering betreft denkt deze groep aan een subsidiëring door de overheid (afhankelijk van

het inkomen). Er gaan ook stemmen op om het principe van de maximumfactuur te hanteren.

De keuze bij deze groep voor een dominante rol voor de overheid in beide user-generated

scenario’s dient om de eindgebruiker een transparant systeem te verzekeren dat integratie van de

verschillende diensten en applicaties toelaat. De overheid krijgt dan de taak om een lastenboek te

maken met alle applicatie/dienstvereisten voor het ontwerp, gebruik, toepassing en regelgeving met

garantie op privacy en efficiëntie. Het lijkt de deelnemers duidelijk dat de externe ontwikkelaar

bepaalde protocollen moet respecteren. Hierin geeft men de overheid een sturende rol. Volgens

groep 1 kennen de Vlaamse en regionale overheden de weg wel niet om een lastenboek samen te

stellen. De vraag wordt ook gesteld of zorg aanbieden wel tot het takenpakket van de overheid

behoort. Lokale overheden hebben het voordeel dat ze dichter bij de werkelijkheid staan, maar dat

kan dan weer tot versnippering leiden. Het grootste struikelblok is dat de overheid een

maatschappelijke verantwoordelijkheid heeft en zolang e-thuiszorgdiensten geen aangetoonde

meerwaarde hebben, zal de overheid niet over de brug komen om dit te steunen (wettelijk,

organisatorisch, financieel). Dit zorgt voor een zekere patstelling. Opvallend is het overheersende

idee van groep 1 dat zorg geen commerciële activiteit mag zijn (geen winst mag opleveren).

Nochtans worden in landen zoals Nederland en Denemarken winstmarges van de zorg gebruikt voor

nieuwe zorgontwikkelingen.


35

Bij een aanbesteding is een Service Level Agreement (SLA) van de overheid nodig zodat de dienst

verzekerd wordt. De rolverdeling van alle verschillende actoren binnen het waardenetwerk kan in het

SLA worden opgenomen om discussies achteraf te vermijden. Het databasebeheer wordt best niet

opgesplitst omdat op die manier het gevaar bestaat dat de hete aardappel wordt doorgegeven.

Het aanbieden van de dienst gebeurt volgens deze groep bij voorkeur door OCMW en mutualiteiten

omdat deze dichtst bij de eindgebruiker staan.

Volgens deze groep is het voor de verzekeraar vooral belangrijk om diensten aan te bieden die een

duidelijke meerwaarde bewezen hebben. Als voorbeeld wordt het personenalarmsysteem (PAS)

aangehaald. Zowel het veiligheidsgevoel wordt door PAS verhoogd als het mantelcircuit wordt

aangewend.

Groep 2

Foto 6: User-generated scenario groep 2


Groep 2 kiest voor een scenario waarin de thuiszorgorganisatie dominant is (Foto 6). De

thuiszorgorganisatie krijgt samen met de externe ontwikkelaar en de eindgebruiker de rol van

applicatieontwikkeling. De thuiszorgorganisatie krijgt eveneens de rol van databasebeheer en

platformbeheer.


36

In het verzorgingsveld wordt de rol van zorgontwikkeling opgenomen door de actoren

thuiszorgorganisatie, verzekeraar en eindgebruiker. Het zorgaanbod gebeurt door de

thuiszorgorganisatie en verzekeraar.

De netwerkinfrastructuureigendom en de netwerktoegangsprovisie gebeurt door de

connectiviteitsleverancier.




In groep 2 gaat men er vanuit dat de gebruiker deze diensten niet zelf kan betalen. De financiering

dient hun inziens te komen van de zorgverzekering of overheid. De overheid kan baat hebben hierin

te investeren omdat langer thuisblijven goedkoper is. Dit wordt echter door een aantal deelnemers

ontkracht. Bepaalde studies zouden dit volgend een deelnemer tegenspreken in het geval van hoge

zorgniveaus en professionele zorg. Voor de verzekeraar is thuiszorg goedkoper dan residentiële zorg.

Het databasebeheer dient gedeeld te zijn volgens groep 2. Een aantal deelnemers geven aan dat

een databasebeheer zonder de overheid geen garantie biedt op privacy. Databasebeheer kan

volgens groep 2 zeker niet overgelaten worden aan de externe ontwikkelaar of overheid omdat zij

geen rechtstreekse link met de eindgebruiker hebben.

De zorgverzekeraar kan een grote rol spelen in de zorgontwikkeling. Hiervoor verwijst men naar het

Nederlandse model waar kwaliteit van zorg voorop staat. Dit model heeft daar geleid tot meer

integratie en meer “evidence based medicine” (predictieve modelling). Dit staat wel haaks op het

huidige Belgische model. Deelnemers stellen zich de vraag waarom een zorgverzekeraar

geïnteresseerd zou zijn om inspanningen te doen om deze diensten betaalbaar te houden voor

iedereen. Evenzeer wordt de opmerking gemaakt dat de complexiteit van zorgontwikkeling moeilijk

kan veranderen gezien dit een aanpassing van een maatschappelijke institutie betreft en dit niet

realistisch is (op korte termijn). Er worden vragen gesteld bij de consequenties van dit

databasebeheer. Een verzekeraar kan bijvoorbeeld bij teveel metingen iemand uitsluiten. Groep 2

geeft de voorkeur aan een neutrale zorgkoepelorganisatie om deze rol op zich te nemen.

Elke gebruiker moet volgens groep 2 de kans krijgen zelf zijn connectiviteitsleverancier te kiezen. De

realiteit leert echter dat een connectiviteitsleverancier ook de rol van externe ontwikkelaar kan

opnemen (bvb. Belgacom in Care For Life). Bundeling van deze rollen is iets wat ten zeerste zou

vermeden moeten worden omdat dit de vrije keuze van connectiviteitsleverancier in het gedrang

brengt.


37

Groep 2 kiest voor een overheid met een regulerende rol (interoperabiliteitsgarantie,

kwaliteitsgarantie, privacygarantie, Europese coördinatie, audits,...).

Groep 3



Het user-generated scenario van groep 3 beschrijft een scenario waarin de rollen binnen de

financiering als volgt zijn verdeeld: subsidiëring door de overheid, verzekering door de verzekeraar

en persoonlijke financiering door de eindgebruiker (Foto 7).

Binnen de systeemstroom wordt de rol van applicatieontwikkeling opgenomen door de externe

ontwikkelaar. Het databasebeheer gebeurt door de overheid en de thuiszorgorganisatie. Voor het

platformbeheer komt de actor overheid samen met de thuiszorgorganisatie in aanmerking in dit

scenario.

In het verzorgingsveld krijgt de overheid en de thuiszorgorganisatie de rol van zorgontwikkeling. Het

zorgaanbod is hier een exclusieve rol voor de thuiszorgorganisatie.

De netwerkinfrastructuureigendom en de netwerktoegangsprovisie gebeurt door de





38


Het databasebeheer wordt toevertrouwd aan de overheid zodat deze erop kan toezien dat deze data

statistisch anoniem wordt gebruikt en kan instaan voor privacy. De overheid lijkt groep 3 best geschikt

om onafhankelijk en transparant deze rol op te nemen. De thuiszorgdienst heeft deze data nodig om

zorg aan te bieden en krijgt daarom een rol in het beheer. Er gaan ook stemmen op om de

eindgebruiker een rol te geven in het databasebeheer gezien deze toegang moet krijgen tot zijn eigen

data en (virtuele) toestemming moet kunnen geven tot wie deze data kan gebruiken.

De grootste discussie en twijfel bestaat rond de actorkeuze voor het platformbeheer.

Hoewel de overheid voor vele rollen naar voor wordt geschoven, geeft groep 3 aan dat dit ook het

struikelblok is van de keuzes binnen hun user-generated scenario. De hoge verwachtingen ten

opzichte van de overheid zijn misschien niet realistisch. Overheid en innovatie zijn immers geen voor

de hand liggende match. De vraag wordt ook gesteld hoe de coördinatie tussen de overheid en

zorgorganisaties dient te gebeuren.

Groep 4



39


Groep 4 kiest voor een scenario waarin de rollen binnen de financiering als volgt zijn verdeeld:

subsidiëring door de overheid, verzekering door de verzekeraar en persoonlijke financiering door de

eindgebruiker (Foto 8).

In de systeemstroom is de rol van applicatieontwikkeling toegeschreven aan alle actoren van het

waardenetwerk: de eindgebruiker, verzekeraar, externe ontwikkelaar, thuiszorgorganisatie,

connectiviteitsleverancier en overheid. Het databasebeheer gebeurt door de overheid en het

plaftormbeheer door zowel de actor als de thuiszorgorganisatie.

Binnen het verzorgingsveld is de rol van zorgontwikkeling voor de thuiszorgorganisatie en

verzekeraar. Het zorgaanbod is voor de thuiszorgorganisatie.

De netwerkinfrastructuureigendom en de netwerktoegangsprovisie zijn rollen voor de





De opportuniteiten van hun scenario liggen volgens groep 4 in de logische link met de

thuiszorgorganisatie. Dit kan tot een geïntegreerde uitgebouwde thuiszorg op maat leiden. De

thuiszorgorganisatie zal in dit scenario ook de kans krijgen om te wegen op technische innovaties en

daardoor zullen e-thuiszorgdiensten/applicaties beter aansluiten op de werkelijke noden en vragen

van de eindgebruikers. Ook kan de thuiszorgorganisatie in dit user-generated scenario een grote

coördinerende rol opnemen. De grootste struikelblok daarentegen is dat dit niet de hoofdbezigheid

van de thuiszorgorganisatie is. De investering moet in dit scenario aangestuurd worden vanuit de

thuiszorgorganisatie. Dat is tevens een zwakte omdat dan heel componenten van deze actor

afhankelijk zijn.


40

7. Eindbevindingen

De workshop ontketende discussies die naar verschillende scenario’s leidden. Uit de

groepsbesprekingen omtrent de opgelegde dominantiescenario’s van het waardenetwerk voor een e-

thuiszorgplatform als TranseCare kwamen volgende doorslaggevende pro’s en contra’s bij de

prioritaire aandachtpunten aan bod:

In het externe ontwikkelaar dominante scenario heeft de externe ontwikkelaar het grote voordeel

van macht, controle en mogelijk grote winst omdat ze de markt kan aansturen en domineren. Aan dit

scenario wordt een efficiëntere dienst en dienst/product update gekoppeld. De monopoliepositie kan

voor de eindgebruiker wel de betaalbaarheid, privacy, toegankelijkheid en duurzaamheid in het

gedrang brengen gezien de commerciële drijfveren van deze actor. De connectiviteitsleverancier zal

volgens de deelnemers wellicht geen medewerking verlenen gezien deze actor in dit scenario geen

meerwaarde genereert. Een ander belangrijk nadeel van dit scenario is dat de externe ontwikkelaar

deze diensten enkel zal aanbieden via geprefereerde zorgpartners. De niet of laat betrokken overheid

heeft in dit scenario weinig greep op het garanderen van competitiviteit, kwaliteit van zorg,

kostefficiëntie en technologische interoperabiliteit.

Een scenario waarin de verzekeraar een dominante positie heeft, wordt gezien als een realistisch

scenario omdat de verzekeraar (mutualiteiten) reeds dicht bij de eindgebruiker staat en daardoor een

betere (veilige, compatibele, betrouwbare) dienst zal aanbieden. Ook zijn er reeds

samenwerkingsverbanden met de thuiszorgorganisatie, waardoor het opzetten en implementeren van

dergelijke diensten vlot kan verlopen. Anderzijds zal dit (in de toekomst) door de veranderende rol

van de verzekeraar (mutualiteiten) misschien niet meer gelden. De verzekeraar (mutualiteiten) als

dominante actor houdt ook een gevaar voor (verdere) verzuiling en versnippering in en legt ook wel

een hypotheek op de keuzevrijheid. Doorgedreven kostenbeheersing van de verzekeraar in

combinatie met zijn rol van databasebeheer kan ook leiden tot exclusie van cliënten.

Het overheid dominant scenario wordt voornamelijk gewaardeerd omwille van de neutraliteit van

deze actor. Dit zou een garantie zijn op toegankelijkere, betrouwbaardere, meer betaalbare,

laagdrempelige, kwalitatieve en compatibele diensten dan wanneer een andere actor het

waardenetwerk domineert. Een bijkomend voordeel is de mogelijkheid om het platform op grote

schaal uit te rollen. Bovendien zou dit het vervagen van de verzuiling in de hand kunnen werken

wanneer niet gekozen wordt om samen te werken met mutualiteiten, maar met overheidsinstanties.

Alle zorgorganisaties kunnen hierbij betrokken worden en niet alleen de geprefereerde zoals in een

verzekeraar dominant scenario. Een belangrijk nadeel is de logge trage structuur en traditie die de

overheid typeert bij innovatie. Eveneens wordt gevreesd een alles controlerende overheid (“Big

Brother”) wanneer deze actor het platformbeheer domineert en daarnaast de rol van databasebeheer


41

opneemt. De vaak legislatuurgebonden korte termijnvisie van de overheid kan de duurzaamheid van

het platform hypothekeren.

Het grote voordeel van een connectiviteitsleverancier dominant scenario is de mogelijkheid van

uitrol op grote schaal in combinatie met niet-zorgdiensten. Connectiviteitsleveranciers beschikken ook

reeds over infrastructuur die bij eindgebruikers aanwezig is. Bovendien is het mogelijk eindgebruikers

die nog niet over connectiviteit beschikken te bereiken met deze nieuwe diensten en zo de digitale

kloof een stuk te helpen dichten. Voor de connectiviteitsleverancier is dit een ideale manier voor

klantenwerving en –binding. Het geïntegreerd, individueel gedifferentieerd facturatiesysteem

waarover deze actor reeds beschikt, wordt ook beschouwd als een grote sterkte omdat dit veel werk

kan besparen. Anderzijds kan de eindgebruiker door een monopoliepositie van één

connectiviteitsleverancier verplicht worden om bij deze leverancier diverse diensten te nemen. Het

gevaar bestaat erin dat deze actor vooral zal focussen op commerciële diensten en een korte

termijnvisie zal hanteren. Ze kan focussen op grote doelgroepen bepaalde noden van

zorgafhankelijken negeren. De connectiviteitsleverancier wordt ook beschouwd als een

onpersoonlijke actor met weinig ervaring met eerstelijnswerkers. De kans bestaat dat de

eindgebruiker niet van operator zal willen veranderen voor diensten van het platform. De

eindgebruiker heeft ook meer argwaan ten aanzien van deze actor wat privacy betreft. De meeste

participanten zijn niet voor dit scenario gewonnen omwille van de beperkte inspraak van de thuiszorg

en de monopoliepositie ten koste van de eindgebruiker.

Als we de die user-generated scenario’s van de vier groepen overschouwen liggen de grootste

discussiepunten in de fit tussen actoren en de rollen van de ontwikkelingsfase en organisatiefase van

het systeem- en verzorgingsveld (Figuur 5). Hierbij moet ook vermeld worden dat bij de deelnemers

slechts een kleine vertegenwoordiging was van de connectiviteitsleverancier en dit zeker ook een

invloed heeft op de resultaten van de workshop. Deze actoren zijn ook dikwijls bekenden voor elkaar,

maar het minst met de connectiviteitsleverancier, die tot nog toe geen deel uitmaakte van de

waardeketen. De eindgebruiker moest volgens de deelnemers van de workshop de vrijheid krijgen

van leverancier te kiezen en dus moet het platform bijgevolg connectiviteitsleverancieronafhankelijk

zijn.


42

Figuur 5: Zwaartepunt discussie workshop

In onderstaande figuren (6 en 7) wordt een overzicht gegeven van de keuzes die de vier groepen

maakten voor de rollen van de ontwikkelings- en organisatiefase van het systeem- en

verzorgingsveld.

Figuur 6: Actorkeuze groepen voor systeemveld


43

In het systeemveld (Figuur 6) kiezen de groepen voor de applicatie-ontwikkeling voor een externe

ontwikkelaar. Groep 1 verkiest deze rol uit te voeren in combinatie met de overheid, groep 2 met

thuiszorgorganisatie en eindgebruiker, groep 3 alle actoren.

Het databasebeheer schrijven drie groepen toe aan de thuiszorgorganisatie. Groep 4 ziet dit als een

taak voor de overheid en groep 3 als een gecombineerde rol voor de thuiszorgorganisatie en

overheid.

Alle groepen geven het platformbeheer aan de thuiszorgorganisatie. Groep 1 wil dit wel combineren

met de actor verzekeraar en verzekeraar, groep 3 en 4 met de overheid.

Figuur 7: Actorkeuze groepen voor verzorgingsveld

In het verzorgingsveld kiezen de vier groepen voor de thuiszorgorganisatie voor de

zorgontwikkeling. Groep 2 wil deze rol gecombineerd zien met de actor eindgebruiker. Groep 1 wil

hier bovenop ook de overheid en verzekeraar betrekken. Groep 1 werkte ook een scenario uit waarin

de zorgontwikkeling door de overheid alleen wordt uitgeoefend.

Ook voor het zorgaanbod kiezen alle groepen voor de thuiszorgorganisatie. Groep 2 verkiest ook de

verzekeraar in deze rol te betrekken; groep 1 de overheid. Groep 1 schuift in een tweede scenario de

verzekeraar samen met de overheid naar voor als actoren voor de zorgaanbodsrol.

Alle resultaten (Figuur 6 en 7) bij elkaar genomen, leiden naar onderstaand voorgesteld scenario

(Figuur 8). Opvallend is het overheersende idee van een overheid met sturende rol in de vorm van

een lastenboek of SLA op wettelijk, organisatorisch en financieel vlak om garantie te hebben op o.a.

interoperabiliteit, kwaliteit, privacy, Europese coördinatie en audits. De deelnemers zijn voor geen

enkel dominantiemodel te vinden gezien een (te) grote machtspositie van één actor leidt tot een

monopoliepositie ten nadele van de eindgebruiker. Er wordt ook opgemerkt dat er in de realiteit geen

duidelijke afbakening is tussen de actoren. In bepaalde gevallen neemt de connectiviteitsleverancier


44

bijvoorbeeld de rol op van externe ontwikkelaar; de overheid de rol van verzekeraar (mutualiteiten);

de thuiszorgorganisatie de rol van verzekeraar en vice versa (samenwerkingsverbanden met vaste

partner); thuiszorgorganisatie en overheid (bvb OCMW). Deze verweven realiteit maakt ook dat de

sterktes, zwaktes, kansen en bedreigingen niet telkens eenduidig vanuit één actor kunnen bekeken

worden gezien deze niet steeds in de hoedanigheid van deze actor alleen optreedt.

Figuur 8: Samenvatting user-generated scenario’s deelnemers workshop

Het vraagstuk naar een realistische strategische fit in het waardenetwerk van de e-thuiszorgdienst

blijkt niet zozeer een financiële vraag, maar het uitklaren van een grijze en subtiele zone. Deze white

paper geeft een methode weer om hier op een gestructureerde manier over te reflecteren, rekening

houdend met de verschillende spelers van het economisch veld. De techno-economische methode

die in dit project werd uitgewerkt, kan vervolgens voor de verschillende scenario’s de

terugverdienmodellen weergeven. Dieper en grootschaliger onderzoek kan de resultaten nog verder

verfijnen. Het opzetten van pilootstudies volgens verschillende scenario’s zou eveneens meer inzicht

verschaffen hoe de actoren en rollen zich werkelijk zullen gaan verhouden.


45

Referenties

Ballon, P (2007) Business modelling revisited: the configuration of control and value. Info, The Journal of policy, regulation and strategy for telecommunications, information and media, 9 (5). Bouwman, H. (2003), State of the art on Business Models, Freeband B4U D3.2 Report, Telematica Instituut, Enschede.

Cortade, T. (2006), A Strategic guide on two-sided markets applied to the ISP market, Communication & Strategies, Vol.61, 1st Quarer, 17-35.

De Maesschalck, S., Morlion, B., Ackaert, A., Leys M. (2006). eHealth. White paper ivm waardeketen in de e-gezondheidszorg. IBBT werkdocument.

Evans, D.S. (2003), Some emperical aspect of multi-sided platform industries, Review of Network Economics, Vol. 2, 3, 191-209.

transe careb mwhitepaper_finaal

Documents