Overheidsopdracht voor aanneming van diensten

Onderhandelingsprocedure zonder voorafgaande bekend- making voor ontwikkeling webapplicatie digitale Doelzoeker voor zorgverleners.

Dit in het kader van het EFRO 1302 project: digitale zorgon- dersteuning in de praktijk in Limburg, als hefboom voor Vlaanderen.

Ref. POM_2021_MV_Ontwikkeling webapplicatie zorgverle- ners digitale Doelzoeker_01

Uiterste indieningsdatum offertes:

maandag 29 maart 2021 – 10 uur

1. Voorwerp van de opdracht

I Achtergrond

Doelgerichte zorg krijgt meer en meer aandacht. Zorggebruikers geven aan dat het niet meer enkel het aantal levensjaren maximaliseren/verlengen is dat telt. De manier waarop je leeft en functioneert is voor de meesten belangrijker. Levenskwaliteit wordt hier voorop geplaatst. Zorggebruikers ervaren die levenskwaliteit als ze kunnen doen wat voor hen belangrijk is. Ze merken op dat hun eigen doelen nogal eens verschillen van de doelen die zorgverleners voorop stellen.

Uit bevragingen bij patiënten blijkt ook dat deze ‘levensdoelen’ niet standaard meegenomen worden in zorg- trajecten. Zorgverleners zouden standaard moeten polsen of patiënten hebben nagedacht over hun eigen doelen en waar ze naartoe willen in het leven. Patiënten willen dat er meer rekening wordt gehouden met ‘de patiënt’ als geheel (context, levensdomeinen, etc.) en met zijn mening. Ze geven aan dat bijvoorbeeld de huis- arts in het begin van een behandeltraject deze doelen kan bevragen en op zou kunnen nemen in het patiën- tendossier. Hiermee kan dan rekening worden gehouden bij de afspraken die worden gemaakt rond zorg en ondersteuning.

Het Vlaams Patiëntenplatform (VPP) ontwikkelde het papieren instrument ‘Doelzoeker’. Doelzoeker helpt per- sonen met een zorg- en ondersteuningsnood nadenken over wat belangrijk is in hun leven. Het verschaft in- zicht in de eigen situatie en zet aan tot betekenisvolle communicatie met zorgverleners. Aan de hand van Xxxxxxxxxx kunnen ze samen bekijken hoe deze doelen behouden of bereikt kunnen worden en hoe de zorg- doelen hier maximaal op kunnen worden afgestemd. Vanzelfsprekend is dit voor iedereen anders en is de eigen context en omgeving belangrijk. Meer informatie over 'Doelzoeker’ vindt u op www.vlaamspatienten- xxxxxxxx.xx/xxxxxx/xxxxxxxxxx

Voorlopig is Doelzoeker enkel beschikbaar als papieren instrument. Deze papieren versie kan door de indie- ners eenvoudig opgevraagd worden bij het VPP (contactpersoon Xxxxxx Xxxxxxxx: jeroen.brou- xxxx@xxxxxxxxxxxxxxxxxxxxxxx.xx). Dit kan interessant zijn om een beeld te krijgen over de inhoud van dit instrument.

Het VPP is momenteel bezig met de ontwikkeling van een digitale versie van de Doelzoeker voor de patiënt. Dit onderdeel valt dus buiten de scope van deze opdracht.

Ter info: De ontwikkeling door VPP van deze digitale versie houdt volgende aspecten in:

- het ontwikkelen van een webapplicatie voor patiënten die toegankelijk zal zijn via xxx.xxxxxxxxxx.xx;

- het ontwikkelen van de achterliggende applicatie(frontend en backend);

- de connectie met de datapods in Solid;

- de hosting van de webapplicatie;

- de hosting van de data die voortkomt uit deze webapplicatie in de datapods in Solid.

Hieronder zie je de flow die deze applicatie zal volgen:

De patiënt zal zich kunnen aanmelden via de webapplicatie voor de patiënt. Er wordt een koppeling voorzien met CSAM zodat zij kunnen aanmelden via eID of ItsMe. Na aanmelden wordt er in de data pods van Solid nagegaan of er informatie omtrent Doelzoeker beschikbaar is. Zo kunnen patiënten een bestaande Doelzoeker raadplegen en deze aanpassen, of kunnen zij een nieuwe Doelzoeker aanmaken. Daarnaast kunnen patiënten via deze digitale toepassing zelf beslissen met welke zorgverlener ze (bepaalde onderdelen van) hun Doelzoe- ker willen delen. Deze data (Doelzoeker, registratie van rechten van zorgverleners, etc.) wordt bijgehouden in een persoonlijke data pod gebouwd met de Solid-technologie. Dit onderdeel wordt momenteel ontwikkeld door het Vlaams Patiëntenplatform vzw.

Deze overheidsopdracht betreft het ontwikkelen van een webapplicatie Doelzoeker specifiek voor zorgver- leners1. Deze applicatie heeft tot doel de zorgverlener in staat te stellen om inzicht te krijgen in de Doelzoe- ker/levensdoelen van de patiënt, de patiënt te empoweren, een gelijkwaardige relatie tussen patiënt en zorg- verlener te faciliteren, de levenskwaliteit en vreugde van de patiënt te maximaliseren, en de therapietrouw en motivatie te verhogen. De ontwikkeling van een webapplicatie van Doelzoeker voor zorgverleners valt bin- nen het EFRO-project 1302, 'Digitale zorgondersteuning in de praktijk in Limburg, als hefboom voor Vlaande- ren'.

Na de ontwikkeling van de webapplicatie voor zorgverleners zullen de software-aanbieders van eerste en tweedelijnpakketten gestimuleerd worden om een rechtstreekse koppeling te voorzien tussen het software- pakket van de zorgverlener / organisatie en de webapplicatie van Xxxxxxxxxx voor zorgverleners, om het ge- bruik ervan door zorgverleners te maximaliseren en vereenvoudigen.

1 In kader van deze tender bedoelen wij met zorgverleners alle zorgverleners, hulpverleners, en welzijnsmede- werkers.

II Proces

Het project is erop gericht een 'webapplicatie van Doelzoeker' te verwezenlijken voor zorgverleners1, die ge- integreerd kan worden in bestaande softwarepakketten.

Via deze webapplicatie zal de zorgverlener zich kunnen aanmelden, waarna een toegangscontrole volgt via:

1. De basisdiensten van het eHealth-platform voor KB78 zorgverleners/zorgberoepen (bijvoorbeeld huisart- sen, verpleegkundigen, etc.).

2. CSAM voor niet KB78 zorgverleners/zorgberoepen (bijvoorbeeld de thuiszorgdiensten).

Na toegangscontrole kan de (aangemelde) zorgverlener in de webapplicatie een patiënt opzoeken op basis van zijn/haar rijksregisternummer. Deze request wordt verstuurd naar de data pod van Solid waar informatie over desbetreffende patiënt bewaard wordt. Op dat ogenblik zijn er twee mogelijkheden:

1. De zorgverlener krijgt een melding dat er geen Doelzoeker teruggevonden werd (er is geen info beschikbaar) OF de zorgverlener krijgt een melding dat er wel informatie of een Doelzoeker aanwezig is maar dat de patiënt geen toestemming gaf (via zijn applicatie van Xxxxxxxxxx) om deze te delen met de zorgverlener. Dit wil zeg- gen dat de toestemming die een patiënt geeft via zijn applicatie van Xxxxxxxxxx de algemene informed con- sent tot gegevensdeling overruled.

2. Er is informatie uit de ingevulde Doelzoeker beschikbaar voor de zorgverlener. De zorgverlener krijgt de visualisatie van Xxxxxxxxxx te zien in de webapplicatie voor de zorgverlener.

Deze tool dient een user webapplicatie voor zorgverlener te ontwikkelen zodat ze de digitale Doel- zoeker van patiënten kunnen raadplegen. Een zorgverlener krijgt leesrechten indien: hij/zij erkend wordt als zorgverlener, er een therapeutische relatie bestaat met de patiënt, en de patiënt toestem- ming gaf tot inzage via de webapplicatie van Doelzoeker voor patiënten. Een automatische koppe- ling met zowel het eHealth-platform als met de data pods in Solid is dus noodzakelijk.

1 In kader van deze tender bedoelen wij met zorgverleners alle zorgverleners, hulpverleners, en welzijnsmede- werkers.

III Technologie en platform

1. Build: Eén van de vereisten van de opdrachtgever is dat deze webapplicatie interoperabel is met andere softwarepakketten uit de eerste en tweede lijn (zowel huidige pakketten als toekomstige ontwikkelingen). Hiermee wordt bedoeld dat er een link kan ingebouwd wor- den in softwarepakketten waarmee zorgverleners onmiddellijk de webapplicatie van Doel- zoeker voor zorgverleners kunnen openen. Het aanmelden in doelzoeker voor zorgverle- ners moet gebeuren via het eHealth X.XX. Indien een zorgverlener in zijn eigen software- toepassing reeds een eHealth sessie heeft lopen dient deze hergebruikt te worden bij het aanmelden in Doelzoeker. Met andere woorden: de zorgverlener hoeft niet opnieuw aan te melden in Doelzoeker. Dit noemt met een Single Sign On koppeling.

2. Frontend: Er wordt verwacht dat de ontwikkeling van de applicatie gebeurt in een react based technologie.

Waarbij telkens met JavaScript wordt gewerkt. Bij de start van het project kiest men voor de laatste versie van het geselecteerde framework.

De taal van de UI van de applicatie dient Nederlands te zijn. De tekstvelden moeten op één plaats beheersbaar zijn zodat deze eventueel later makkelijk kunnen vertaald worden.

De applicatie is beschikbaar in alle recente browsers (Chrome, Edge, Firefox & Safari) en moet responsief zijn.

Met responsief bedoelen we een aangepaste schermlayout op smartphones & tablets, zo- danig dat deze applicatie op deze toestellen ook bruikbaar is.

3. Backend

We wensen dat de applicatie de Belgische FHIR standaard ondersteunt of kan ondersteu- nen. Dit wil zeggen dat:

- De applicatie uitgaat van een backend die conform is aan de algemene, internationale FHIR specificaties. Het ophalen van data gebeurt dan op een gestandaardiseerde ma- nier in de vorm van FHIR Resources.

- De opgehaalde FHIR Resources komen in de door HL7 België opgelegde vorm. De defi- nitie van deze datablokken zijn in een definitieve versie te vinden op de eHealth FHIR Implementation Guide en in draft versie op de eHealth Simplifier website .

Het ondersteunen van de FHIR standaard zorgt ervoor dat de frontend applicatie bruikbaar is voor alle FHIR backends en dus makkelijk integreerbaar is in andere databanken. Ook hoe- ven er geen assumpties gemaakt te worden over de structuur van de data.

IV Ontwikkelingsfases

De ontwikkeling gebeurt iteratief, in co-creatie. De ontwikkeling wordt zo opgezet dat er gewerkt wordt met korte iteraties, duidelijke afspraken en snelle communicatielijnen. Gedurende het ont- wikkelingsproces worden er validatiemeetings georganiseerd om de webapplicatie voor zorgverle- ners samen vorm te geven en waar nodig worden gebruikerstesten georganiseerd. Tijdens deze va- lidatiemeetings wordt er feedback gegeven om gedurende het proces de ontwikkeling vorm te ge- ven/bij te sturen.

De validatiegroep “Doelzoeker” binnen EFRO zal deelnemen aan deze validatiemeetings. Deze vali- datiegroep bestaat uit experten die Doelzoeker kennen en de papieren versie reeds gebruiken. Daarnaast moeten tussentijdse opleveringen voldoende tijdig beschikbaar gesteld worden zodanig dat de verschillende stakeholders (die deel uitmaken van de werkgroep “Doelzoeker” binnen EFRO) de meetings met de validatiegroep grondig kunnen voorbereiden. De snelle communicatielijnen worden voorzien met de trekker(s) van het project.

Er wordt getracht om te werken in vier verschillende fases (uitgaande van start midden mei 2021): Onderstaande timings zijn minima. Aanbieders worden verwacht een realistische planning in hun offerte op te nemen.

1. Opstartvergadering: vooronderzoek en vereisten worden toegelicht, vragen worden beant- woord, planning wordt overlopen en overlegmomenten worden vastgelegd. Nadien kan de ontwikkelaar aan de slag om een eerste voorstel met wireframes te ontwikkelen (midden mei).

2. Ontvangen wireframes: dient gebaseerd te zijn op de digitale doelzoeker – versie webap- plicatie voor patiënten (midden juni)

3. Ontvangen clickable prototype: de aangepaste wireframes vormen de basis voor het clic- kable prototype. (midden augustus)

4. Definitieve tool af: de besproken onvolmaaktheden/aanpassingen werden doorgevoerd. (eind september)

V Inhoud tool

1. Ontwerp webinterface:

Het designconcept wordt gebaseerd op de recent ontwikkelde webapplicatie van de digitale Doel- zoeker voor patiënten. Concreet dient er een visuele gebruikersinterface gegenereerd te worden die de Doelzoeker overzichtelijk en intuïtief kan weergeven zonder de gebruiker (de zorgverlener) te overweldigen. De webapplicatie voor zorgverleners moet enkel gegevens kunnen tonen, dus niet wijzigen.

Enkele basisvereisten hierbij zijn:

• De look en feel van webapplicatie voor patiënten wordt overgenomen in de web- applicatie voor zorgverleners.

• De data waar deze webapplicatie een view op geeft worden aangeleverd door de digitale Doelzoeker voor patiënten. Deze data worden bewaard in datapods van Solid. De webapplicatie voor zorgverleners zal dus data moeten ophalen uit Solid en visualiseren in de tool. Er moet dus geen dataopslag voorzien worden. Dit ge- beurt allemaal via de datapods van Solid.

• Een webapplicatie voor zorgverleners met verschillende lagen (zie inhoudelijke re- quirements).

2. Inhoudelijke requirements:

De lijst van requirements is tot stand gekomen door interviews met patiënten en zorgver- leners. We zoomden in op het proces dat met Doelzoeker doorlopen wordt en keken zo waar de noden en wensen lagen. De ingevulde Doelzoeker wordt toegankelijk gemaakt voor zorgverleners die toegang mogen hebben, en dit via een logische opbouw:

• Laag 1: Het eerste wat zorgverleners willen zien is een algemeen overzicht van de levensdoelen (afkomstig uit de ‘doelenfiche’ van de digitale Doelzoeker van de pa- tiënt).

Onderstaande printscreen geeft een idee over de inhoud van de doelenfiche. Deze printscreen komt uit de webapplicatie voor patiënten. Deze zit nog in een conceptuele fase en kan nog aangepast worden. Deze dient louter ter illustratie.

• Laag 2: Vanuit dit overzicht van de levensdoelen/doelenfiche van de patiënt moet het mogelijk zijn om als zorgverlener door te klikken op individuele doelen. Na doorklikken op een individueel doel krijg je als zorgverlener specificaties uit de doelenfiche ingevuld door de patiënt, bijvoorbeeld:

o doel = ‘Kunnen gaan wandelen met kleinkinderen’;

o achterliggende info na doorklikken: ‘Wil dit doel bespreken met arts, kiné en partner. Voorlopig nog niet tevreden over dit doel, eerste stap is ont- wikkelen van meer uithoudingsvermogen’.

• Laag 3: Vanuit laag 1 en laag 2 willen zorgverleners kunnen doorklikken naar de levensweg van Doelzoeker. (De levensweg is een beschrijving van het verleden, het heden, en de toekomst van de patiënt waarop de levensdoelen gebaseerd zijn.)

Onderstaande printscreen geeft een idee over de inhoud van de levensweg in Doelzoeker. Deze printscreen komt uit de webapplicatie voor patiënten. Deze zit nog in een conceptuele fase en kan nog aangepast worden. Deze dient louter ter illustratie.

Daarnaast moet het mogelijk zijn om in te zoomen op bepaalde concrete levensdoelen uit de digitale Doel-

zoeker door xxxxxxxx filters te gebruiken wanneer je enkel geïnteresseerd bent in een bepaald levensdoel.

3. Technische requirements:

Enkel patiënten hebben standaard zicht op alle informatie in de digitale Doelzoeker. De webapplicatie voor de patiënt houdt een flexibele filterinstelling in waarbij patiënten kunnen aanduiden welke zorgverlener(s) informatie uit hun Doelzoeker kunnen ophalen. Deze functionaliteit, die patiënten toelaat om zorgverleners waar ze een therapeutische relatie mee hebben toegang te geven tot de inhoud van hun Doelzoeker, zal aan de basis liggen van de webapplicatie voor zorgverleners. Dit houdt in dat volgende technische requirements noodzakelijk zijn:

• Identificatie als zorgverlener op de webapplicatie xxx.xxxxxxxxxx.xx (via de dien- sten van het eHealth-platform of het standaard CSAM inlogmechanisme voor zorg- verleners zonder RIZIV nummer).

• Ontwikkeling van een landingspagina voor zorgverleners (vb www.doelzoe- xxx.xx/xxxxxxxxxxxx) waarop zorgverleners een patiënt kunnen opzoeken op basis van het rijksregisternummer (via de diensten van het eHealth-platform).

• Het inbouwen van controle, via het eHealth-platform, op:

o Informed consent tot gegevensdeling van de patiënt;

o Therapeutische relatie met de patiënt.

• Het raadplegen van informatie, via de data pods in Solid, omtrent:

o De specifieke toegang verleend door de patiënt in kader van Doelzoeker. Deze informatie wordt opgeslagen in Solid en bepaalt wat de zorgverlener kan consulteren als de algemene informed consent tot gegevensdeling

/therapeutische relatie die geraadpleegd wordt via het eHealth-platform in orde is.

o Controle op extra toegang verleend door de patiënt aan derden, bijvoor- beeld niet KB78ers.

o Digitale Doelzoeker opgeslagen door de patiënt.

• De patiënt kan zijn consent te allen tijde intrekken (zowel deze voor algemene ge- gevensdeling als deze specifiek voor het delen van info omtrent Doelzoeker).

• Na aanmeldingsprocedure en controle hierboven beschreven komen zorgverleners terecht op de viewer die opgedeeld wordt in lagen (zie inhoudelijke require- ments).

De hieronder beschreven technische requirements zijn noodzakelijke vereisten. We verwachten dat de ontwikkelaar minstens alle noodzakelijke requirements aanbiedt. De aanbieder zal in diens offerte duidelijk aangeven welke optionele vereisten tevens aangeboden zullen worden binnen het voorziene budget en tijdskader.

Requirements op het vlak van technologie van de webapplicatie: Noodzakelijk:

• De ‘digitale visualisatie van Doelzoeker voor zorgverleners’ is een webapplicatie die centraal via het internet beschikbaar wordt gesteld en beschikbaar/toeganke- lijk is:

o via de courant gebruikte browsers Chrome, Safari, Edge, Firefox;

o vanop zowel PC als Mac en volwaardig resp. Windows 7 of hoger en Mac OSX 10.10 of hoger ondersteunt;

o vanop zowel iPad als Android tablets als iPhones als Android phones, waarbij een aangepaste schermlay-out (responsive design) wordt gebruikt.

• De ontwikkelaar gebruikt de technologie zoals hierboven omschreven (gebruik maken van react based technologie, JavaScript, etc.) om de webapplicatie te ont- wikkelen. Een belangrijk uitgangspunt hierbij is dat er verder gebouwd kan worden op de reeds ontwikkelde webapplicatie van Doelzoeker voor patiënten. De ontwik- kelaar zal in de offerte de gebruikte technologie en strategie/toekomstmogelijk- heden degelijk onderbouwen.

• De broncode van de ontwikkelde webapplicatie wordt na afloop van het pilootpro- ject beschikbaar gesteld van de opdrachtgever, alsook alle nodige documentatie en procedures.

• De ontwikkelaar voorziet de mogelijkheid om de webapplicatie te openen vanuit een softwarepakket van zorgverleners of welzijnswerkers. Op deze manier moet het mogelijk gemaakt worden dat zorgverstrekker in zijn eigen applicatie op een knop of link duwt, waarna er een browservenster opengaat en Doelzoeker opent. Indien de zorgverstrekker in zijn eigen software reeds een eHealth sessie geopend heeft dient hij zich niet opnieuw te verifiëren (single sign on) op de webapplicatie van Xxxxxxxxxx voor zorgverstrekkers.

• De ontwikkelaar voorziet de mogelijkheid om loggings bij te houden van zorgverle- ners die Doelzoeker raadplegen.

Optioneel:

• De ontwikkelaar voorziet de mogelijkheid om de laatste aanpassingsdatum aan de Doelzoeker, door de patiënt, weer te geven in de webapplicatie voor de zorgverle- ner.

• De ontwikkelaar voorziet de mogelijkheid om als gebruiker van Doelzoeker mel- dingen, triggers, push-notificaties te verzenden naar andere gebruiker(s) om op het juiste moment geattendeerd te worden op relevante informatie. (van patiënt naar zorgverlener)

• Communicatiefunctie tussen patiënt en zorgverlener. De ontwikkelaar voorziet een vrij tekstveld waar elke gebruiker van Doelzoeker (zowel patiënten als zorg- verleners) schrijfrechten in heeft. Patiënten kunnen vanuit de webapplicatie voor patiënten klikken op een communicatiefunctie. Zorgverleners kunnen vanuit de webapplicatie voor zorgverleners klikken op een communicatiefunctie. Deze com- municatiefunctie wordt per patiënt weergegeven voor alle zorgverleners waar de patiënt Doelzoeker mee deelt. (1 communicatie tussen alle betrokken actoren)

Requirements op het vlak van toegangsbeheer & beveiliging van de webapplicatie:

• Op het vlak van toegangsbeheer en –rechten dient technisch gezien te worden voldaan aan de Europese GDPR-wetgeving en de wet betreffende de rechten van de patiënt. Dit kan bijvoorbeeld door een expliciete goedkeuring te vragen op een gebruikersverklaring bij het eerste gebruik.

• Gebruikers moeten veilig kunnen aanloggen in de webapplicatie. De ontwikkelaar voorziet toegang tot de webapplicatie via identificatie met eID/its me gekoppeld met de beveiligde diensten van de overheid (CSAM). Ook dit wordt in de offerte duidelijk beschreven.

• De webapplicatie voorziet in een log-out functie voor de gebruiker. Deze is bij ge- bruik van de applicatie steeds zichtbaar. De gebruiker wordt bij elk gebruik stan- daard uitgelogd na 30 minuten inactiviteit.

• Gebruikers moeten een patiënt kunnen opzoeken op basis van het rijksregister- nummer. De ontwikkelaar voorziet toegang tot BePatient Resources die uniek te identificeren zijn via het rijksregisternummer.

• Het inbouwen van controle op de informed consent en de therapeutische relatie via de basisdiensten van het eHealthplatform;

• Identity & Acces Management (Geïntegreerd gebruikers- en toegangsbe- heer)

1. Deze requirement vereist kennis met betrekking tot de architec- tuur van het eHealth-platform.

2. Er zal voor deze requirement een dossier ingediend moeten wor- den bij het eHealth-platform). De aanbieder biedt ondersteuning in het maken van dit dossier.

• Het inbouwen van controle op extra toegang toegekend door de patiënt op basis van het rijksregisternummer van derden (vb. toegang door de thuiszorgdiensten).

• Er moet nagegaan kunnen worden voor welke zorgverleners de patiënt zijn levens- doelen openstelde in de webapplicatie voor patiënten. Er moet dus een link (inter- operabiliteit) zijn tussen de bestaande patiënten webapplicatie en zijn databank, en de te ontwikkelen webapplicatie voor zorgverleners.

• Inzake beveiliging worden de nodige technische beveiligingsmaatregelen voor- zien om persoons- en medische gegevens tegen verlies of onrechtmatige verwer- king te beschermen. Ook worden de nodige technische maatregelen genomen, zo- wel aan code kant als aan server kant, om de tool te beschermen tegen internet- aanvallen. De ontwikkelaar doet in de offerte een overtuigend voorstel van de technische beveiligingsmaatregelen die men voorziet om de webapplicatie te be- veiligen en dit zowel aan de code kant als aan de server kant.

Requirements op het vlak van data-opslag van de webapplicatie:

• De ontwikkelaar staat niet in voor de hosting van de applicatie of de data. De ap- plicatie van zorgverleners wordt gehost waar ook de applicatie voor patiënten wordt gehost. De data die gevisualiseerd zal worden wordt opgehaald uit data pods die gebaseerd zijn op de Solid technologie. Deze staan dan ook in voor de hosting van de data.

Requirements op het vlak van structuur en gebruikservaring van de webapplicatie:

• De webapplicatie laat toe een duidelijk gestructureerde omgeving aan te bieden aan de eindgebruikers. De digitale Doelzoeker wordt op een gebruiksvriendelijke manier gevisualiseerd.

• De webapplicatie kan gebruikt worden door 2 types eindgebruikers (zorgverleners en welzijnswerkers). De webapplicatie is integreerbaar in eigen softwarepakket- ten indien beschikbaar en tevens bruikbaar als webapplicatie voor beroepsgroe- pen zonder eigen softwarepakket.

• Tevens is de webapplicatie voor ieder type gebruiker afhankelijk van de toege- kende rechtenstructuur vanuit de webapplicatie voor patiënten (de patiënt kan kiezen om doelen, verleden, heden en toekomst te delen met zorgverleners naar keuze). Hierbij zal er vanuit de webapp voor zorgverleners een technische vraag via webservice naar de back-office gaan van de tool. Deze geeft een antwoord te- rug aan de webapp. De tool toont wat hij terugkrijgt van de back-office.

Requirements op het vlak van project administrator features van de webapplicatie:

Noodzakelijk:

• De webapplicatie voorziet de mogelijkheid om gebruikersstatistieken bij te hou- den waarmee de projecteigenaars de webapplicatie kunnen optimaliseren. Bv. Hoe vaak wordt de webapplicatie geopend, welke inhoud wordt gelezen, op welke functies wordt geklikt, etc. De project administrator kan deze gebruikersstatistie- ken raadplegen.

• De webapplicatie voorziet in een uitgebreide logging voor probleemonderzoek en beveiliging.

Requirements op het vlak van het ontwikkelingsproces van de webapplicatie:

Noodzakelijk:

• De webapplicatie wordt iteratief opgeleverd. Tussentijdse versies worden beschik- baar gesteld via een staging server zodat een validatiegroep bestaande uit de ver- schillende segmenten eindgebruikers de tool in een labo-omgeving kan testen en beoordelen.

• De webapplicatie wordt iteratief bijgestuurd op basis van de feedback.

• De webapplicatie wordt voor finalisatie in productie-omgeving uitgetest en gevali- deerd.

2. Plaatsingsprocedure

De opdracht wordt geplaatst bij een onderhandelingsprocedure zonder voorafgaande bekendmaking, met toepassing van artikel 42, §1, 1°, a van de Wet inzake overheidsopdrachten van 17 juni 2016.

De aanbesteder kan met de inschrijvers over de initiële offertes en over alle volgende offertes die door hen werden ingediend onderhandelen met het oog op de verbetering van de inhoud ervan. Hij behoudt zich echter het recht voor om meteen de initiële offerte te gunnen.

3. Indiening offertes

De offertes worden per e-mail ingediend en dienen gericht aan xxxxxxx.xxxxxx@xxxxxxxxxx.xx

De uiterste indieningsdatum van de offertes is op maandag 29 maart – 10uur. Dit uiterste tijdstip is bepalend voor de tijdige indiening door de inschrijvers. Elke offerte moet vóór dit tijdstip aankomen. Laattijdige offertes worden niet aanvaard.

De inschrijver ondertekent de offerte en voegt hierbij de vertegenwoordigingsbevoegdheid van de onder- tekenaar (bv afschrift Belgisch Staatsblad).

4. Gunningscriteria

De aanbestedende overheid zal de economisch meest voordelige offerte vaststellen rekening houdende met de beste prijs-kwaliteitsverhouding die als volgt wordt ingevuld:

De gunningscriteria zijn, samen met het hen toegekende gewicht:

1. Methodiek & projectplanning: 50% (50 punten op een totaal van 100 voor alle gunningscriteria).

In de omschrijving van de opdracht wordt uitgebreider ingegaan op de verwachtingen van de opdrachtgever. Er wordt van de opdrachtnemer een plan van aanpak verwacht bestaande uit een voorstel voor methodiek en bronnen die voor de ontwikkeling zullen worden gehanteerd en bestaande uit een duidelijke projectplanning met acties, mijlpalen en met realistische timing. Gelieve (voor elk projectonderdeel) indicatief aan te geven hoeveel uren voorzien worden om de opdracht uit te voeren.

De voorgestelde methodieken worden afgemeten aan relevantie en doelmatigheid.

Er wordt van de opdrachtnemer verwacht dat deze de timing kan aanhouden, en een finale versie van de digitale Doelzoeker webapplicatie voor zorgverleners kan opleveren tegen ten laatste eind september.

Voeg een gedetailleerd prestatie inschattingsschema toe waarin per fase de uitvoeringstaken worden weer- gegeven en hoeveel uren er gespendeerd worden aan deze taak. In het plan van aanpak moet ook het iteratief co-creatie proces duidelijk zijn. Opdrachtnemers die sneller dan de voorziene timing kunnen opleveren heb- ben voordeel.

2. Kostprijs: 25% (25 punten op een totaal van 100 voor alle gunningscriteria).

Voor het criterium van de kostprijs is de volgende formule van toepassing:

Maximum te behalen punten voor het criterium prijs x Offerteprijs laagste regelmatige inschrijver

Offerteprijs van de beoordeelde inschrijver

De maximale kostprijs voor de uitvoering van deze opdracht (vast + voorwaardelijk gedeelte) bedraagt 20.000 euro incl. BTW. Indien de ingediende offerteprijs hoger ligt, wordt de offerte als onregelmatig beschouwd.

Om de punten voor het criterium prijs te bepalen, worden de offerteprijzen van de inschrijvers met elkaar vergeleken, inclusief BTW, aangezien deze belasting een kost met zich meebrengt voor de aanbesteder.

3. Samenstelling/Kwaliteit van het voorgestelde projectteam en referenties: 25 % (25 punten op een totaal van 100 voor alle gunningscriteria).

De puntentoekenning voor dit criterium wordt bepaald op basis van de relevante knowhow van de project- manager en het projectteam aangetoond via een CV en de deelname aan gelijkaardige projecten waaraan in het verleden werd meegewerkt met vermelding van de taken die daarin verricht werden. Uit de CV dient duidelijk te blijken wat de exact uitgevoerde taak inhield bij de uitvoering van gelijkaardige projecten. Gelieve ook minstens drie vergelijkbare referenties en contactgegevens m.b.t. vroegere gelijkaardige projecten te voorzien.

Er wordt gevraagd dat de projectmanager en het projectteam over kennis, competenties en aangetoonde ervaring beschikken m.b.t. het agile (bv SCRUM) ontwikkelen van webapplicaties (niet enkel websites) in een zorg- en health context. Voorts heeft het team ervaring in het gebruik van open source componenten en het incorporeren van data-standaarden (FIHR) om interoperabiliteit met andere systemen te voorzien.

Geef ook aan welke back-up (vervangers) voorzien worden.

De samenstelling van en de taakverdeling binnen het projectteam mogen tijdens de uitvoering van de op- dracht niet worden gewijzigd zonder voorafgaande toestemming van de opdrachtgever. Wanneer in voorko- mend geval vervangers worden voorzien, moeten deze laatsten een gelijkwaardig kwaliteitsniveau hebben.

Indien het de bedoeling is om (een gedeelte van) de opdracht in onderaanneming te geven, moet dit duidelijk worden aangegeven in de offerte (met vermelding van al de onderaannemers), en moet tevens bovenstaande gevraagde informatie worden aangereikt m.b.t. de onderaannemers. Van iedere onderaannemer moet een verklaring bij de offerte zijn gevoegd waarin hij zich akkoord verklaart met de onderaanneming tegen de voor- waarden van het bestek en de offerte.

5. Uitsluitingsgronden en corrigerende maatregelen

De inschrijver mag zich niet bevinden in één van de in de artikelen 67 en 68 van de Wet inzake overheidsop- drachten bedoelde situaties. Dit behelst de verplichte uitsluitingsgronden en de uitsluitingsgronden in ver- band met fiscale en sociale schulden.

Door het indienen van een offerte verklaart de inschrijver dat er geen van volgende uitsluitingsgronden op hem van toepassing is

1. deelneming aan een criminele organisatie;

2. omkoping;

3. fraude;

4. terroristische misdrijven of strafbare feiten in verband met terroristische activiteiten, dan wel uit- lokking van, medeplichtigheid aan of poging tot het plegen van een dergelijk misdrijf of strafbaar feit;

5. witwassen van geld en financiering van terrorisme;

6. kinderarbeid en andere vormen van mensenhandel;

7. het tewerkstellen van illegaal verblijvende onderdanen van derde landen.

Indien een bovenvermelde uitsluitingsgrond van toepassing is op de inschrijver, mag deze bewijzen dat de corrigerende maatregelen die hij genomen heeft voldoende zijn om zijn betrouwbaarheid aan te tonen on- danks de toepasselijke uitsluitingsgrond. Als de aanbesteder dat bewijs toereikend acht, wordt de betrokken inschrijver niet uitgesloten van de plaatsingsprocedure.

De aanbesteder zal volgende uitsluitingsgronden automatisch screenen:

- RSZ-attest (document waaruit blijkt dat de inschrijver voldoet aan de voorschriften inzake bijdragen voor sociale zekerheid en bestaanszekerheid);

- Fiscaal attest (document waaruit blijkt dat de inschrijver voldoet aan de verplichtingen inzake beta- ling van de fiscale schulden t.a.v. de FOD Financiën);

- Attest van niet-faillissement (document waaruit blijkt dat de inschrijver geen aangifte heeft gedaan van faillissement of geen gerechtelijk akkoord aangevraagd heeft of niet in staat van faillissement, vereffening of een gelijkaardige situatie verkeert).

Eventuele corrigerende maatregelen moet de inschrijver echter bewijzen door schriftelijke stukken toe te voe- gen aan de offerte.

6. Toepasselijke wettelijke bepalingen

Op deze opdracht zijn onder meer toepasselijk :

- de Wet inzake overheidsopdrachten van 17 juni 2016;

- het Koninklijk Besluit van 18 april 2017 betreffende de plaatsing van overheidsopdrachten in klas- sieke sectoren;

- het Koninklijk Besluit van 22 juni 2017 tot wijziging van het Koninklijk Besluit van 14 januari 2013 tot bepaling van de algemene uitvoeringsregels van de overheidsopdrachten en van de concessies voor openbare werken en tot bepaling van de datum van inwerkingtreding van de Wet van 16 fe- bruari 2017 tot wijziging van de Wet van 17 juni 2013 betreffende de motivering, de informatie en de rechtsmiddelen inzake overheidsopdrachten en bepaalde opdrachten voor werken, leveringen en diensten;

- Koninklijk besluit van 14 januari 2013 tot bepaling van de algemene uitvoeringsregels van de over- heidsopdrachten;

- de Wet van 16 februari 2017 betreffende de motivering, de informatie en de rechtsmiddelen inzake overheidsopdrachten, bepaalde opdrachten voor werken, leveringen en diensten en concessies;

- alle wijzigingen in de voormelde wetten en besluiten die van toepassing zijn op de dag van de ope- ning van de offertes.

7. Looptijd van de opdracht

De opdracht loopt vanaf het sluiten van de overeenkomst, gedurende het volledige ontwikkelingsproces, in- clusief de testfase en terugkoppelingsfase. De aanbestedende overheid geeft het einde van aanbesteding aan met een PV van oplevering. De looptijd zal de maximale duurtijd (tot juni 2022) van het EFRO-1302 project niet overschrijden.

8. Varianten en opties

Er zijn geen varianten of opties toegelaten.

9. Verbintenistermijn

De inschrijvers blijven gebonden door hun offerte gedurende een termijn van 120 kalenderdagen vanaf de dag na de uiterste indieningsdatum van de offertes.

10. Verplichtingen van de dienstverlener

- De inschrijver geeft het primaire aanspreekpunt(en) en contactgegevens aan voor het verloop van de opdracht.

- De inschrijver dient te allen tijde de continuïteit van de dienstverlening te verzekeren. In geval van afwezigheid (ziekte, vakantie, …) geeft hij de naam op van diegene die tijdens zijn afwezigheid, onder zijn verantwoordelijkheid, de opdracht zal behandelen en met wie de aanbesteder desgevallend con- tact kan opnemen. Het kantoor dient op werkdagen steeds bereikbaar te zijn tijdens de kantooruren van 9u tot 12u en van 14u tot 17.30 u.

11. Algemene bepalingen

De informatie die de aanbesteder in het kader van de gunning van deze opdracht ter beschikking stelt, mag niet voor andere doeleinden worden aangewend, noch aan derden worden meegedeeld.

De inschrijver gebruikt uitsluitend het Nederlands in zijn mondelinge en schriftelijke relatie met de aanbeste- der.

Overeenkomstig de Belgische overheidsopdrachtenreglementering heeft de aanbestedende overheid, in elke fase van de plaatsingsprocedure, de mogelijkheid om de inschrijver uit te sluiten indien de aanbestedende overheid met elk passend middel aantoont dat de kandidaat of inschrijver de in artikel 7 van de Wet Over- heidsopdrachten genoemde toepasselijke verplichtingen op het vlak van het milieu-, sociaal en arbeidsrecht, heeft geschonden.

12. Facturatie

Na het afsluiten van het project dient de inschrijver een eindfactuur in met een overzicht van de geleverde prestaties.

De ondertekende factuur worden gericht aan:

Xxxxxxx Xxxxxx POM Limburg Xxxxx Xxxxxx 0X

Xxxxxxxxx Xxxxxxxx 000 xxx 000, 0000 Xxxxxxx

De aanbesteder beschikt over een verificatietermijn van dertig dagen. De betaling vindt plaats binnen een betalingstermijn van dertig dagen vanaf het verstrijken van de bovenvermelde verificatietermijn.

13. Toezicht op de uitvoering van de overeenkomst

De leiding en het toezicht op de uitvoering van deze overeenkomst worden uitgeoefend door Xxxxxxx Xxxxxx, Xxxxxxxxx Xxxxxxxx 000/000, 0000 Xxxxxxx, 0471/38 04 59, xxxxxxx.xxxxxx@xxxxxxxxxx.xx

14. Geschillen

Het Belgisch recht is van toepassing voor de interpretatie van de contractuele clausules en voor het bepalen van de rechten en plichten die niet door deze clausules geregeld zijn.

Enkel de Belgische rechtscolleges zijn bevoegd om de geschillen te behandelen waartoe dit contract aanleiding kan geven.

De voertaal is het Nederlands.

De aanbesteder is in geen geval aansprakelijk voor de schade aan personen of goederen die rechtstreeks of onrechtstreeks het gevolg is van de activiteiten die nodig zijn voor de uitvoering van deze opdracht. De op- drachtnemer vrijwaart de aanbesteder tegen elke vordering van schadevergoeding door derden in dit ver- band.

15.

Intellectuele rechten

Alle Intellectuele Eigendomsrechten met betrekking tot de software in hoofde van de Opdrachtnemer worden door uitvoering van de opdracht onmiddellijk, onherroepelijk en exclusief overgedragen aan het Vlaams Patiëntenplatform.

Onder Intellectuele Eigendomsrechten worden verstaan: alle systemen, (computer)programma’s,

documenten, tekeningen, plans, designs, modellen, producten, formules, documentatie,

databanken, teksten, handleidingen, rapporten, schema’s, analyses, technologieën, fabrieks- en za- kengeheimen, handelsnamen, merken, domeinnamen, patenten, octrooien, tools, werkwijzen, me- thodes, uitvindingen, ontdekkingen, verbeteringen, vernieuwingen, knowhow en elk ander werk ge-

creëerd, ontworpen, ontwikkeld of geproduceerd door de Opdrachtnemer, alleen of samen met an- deren, en die betrekking hebben op de software. Onder de Intellectuele Eigendomsrechten wordt onder meer, doch niet uitsluitend begrepen, de bron- en doelcode van de software.

De overdracht van de vermelde Intellectuele Eigendomsrechten omvat doch is niet beperkt tot de overdracht van het recht om de Intellectuele Eigendomsrechten te reproduceren, te bewerken, aan te passen, te gebruiken voor het maken van afgeleide werken, te verspreiden op welke wijze ook, zowel in oorspronkelijke als in gewijzigde vorm.

De software, met inbegrip van de Intellectuele Eigendomsrechten, zal ten dienste van het algemeen belang ingezet worden. Daarbij worden door het Vlaams Patiëntenplatform geen commerciële dien- sten nagestreefd.

De opdrachtnemer mag zonder schriftelijke toestemming van de aanbestedende overheid geen arti- kelen publiceren die betrekking hebben op de resultaten van deze opdracht. Bij het uitvoeren van diensten voor derde partijen mag de opdrachtnemer niet van de resultaten van huidige overheids- opdracht gebruik maken. De opdrachtnemer mag echter wel het uitgevoerd hebben van onderhavige opdracht voor de aanbestedende overheid als referentie gebruiken.

De opdrachtnemer erkent en garandeert de geldigheid van de Intellectuele Eigendomsrechten en zal zich onthouden van het ontkennen of aanvallen van de geldigheid en van het bijstaan van een derde partij in het ontkennen of aanvallen van de geldigheid door het overmaken van informatie of advies of op enige andere wijze. De opdrachtnemer zal het Vlaams Patiëntenplatform volledig vrijwaren en schadeloos stellen indien het Vlaams Patiëntenplatform schade zou lijden ten gevolge van een vor- dering die een derde partij zou hebben ten aanzien van de Intellectuele Eigendomsrechten.

16. Verwerking persoonsgegevens

De inschrijver verbindt zich ertoe om de toepasselijke privacywetgeving (zijnde (i) de EU Verordening 2016/679 van 27 april 2016 betreffende de bescherming van natuurlijke personen in verband met de verwer- king van persoonsgegevens en betreffende het vrije verkeer van die gegevens en tot intrekking van Richtlijn 95/46/EG (GDPR/AVG) en (ii) de wet van 30 juli 2018 betreffende de bescherming van natuurlijke personen met betrekking tot de verwerking van persoonsgegevens) te respecteren.

BIJLAGE 1

Offerteformulier

PRIJSOFFERTE VOOR DE OPDRACHT MET ALS VOORWERP:

“Ontwikkeling webapplicatie digitale Doelzoeker voor zorgverleners” POM_2021_MV_Ontwikkeling webapplicatie zorgverleners digitale Doelzoeker_01

Onderhandelingsprocedure zonder voorafgaande bekendmaking

DOOR U BIJ TE VOEGEN

U dient deze offerte in met bewijs van vertegenwoordigingsbevoegdheid/volmacht van de ondertekenaar (af- schrift Belgisch Staatsblad).

Offerte

De vennootschap (handelsnaam of benaming, en rechtsvorm):

…………………………………………………………………………………………..…………………………………………………………….. Met zetel te

………………………………………………………..……………………………………………………………..……………………………….. Ondernemingsnummer: ……………………………….………………………………………………………………………………….. RSZ-nummer: ……………………………….………………………………………………………………………..………………………… Telefoon: ……………………………….………………………………………………………………………..………………………………. E-mail: ……………………………….………………………………………………………………………..……………………………………

vertegenwoordigd door de ondergetekende(n):

...........................................................................................................................................................

in hoedanigheid van ..........................................................................................................................

Nationaliteit : .....................................................................................................................................

Wettelijke woonplaats (land, gemeente met postnummer, straat en huisnummer) :

...........................................................................................................................................................

verklaart dat de offerte voldoet aan de specificatie zoals omschreven in de prijsaanvraag en zal de diensten uitvoeren voor:

	Prijs excl. BTW	Prijs incl. BTW
Totale prijs

Gedaan te ............................................................................................

Op ............................................................................................

Handtekening: ................................................................................................................................

(De gemachtigden voegen bij hun offerte de authentieke of onderhandse akte waaruit hun bevoegdheid blijkt of een gewaarmerkt afschrift van hun volmacht; zij kunnen zich ook beperken tot een verwijzing naar het nr. van de bijlage van het Belgisch Staatsblad waarin hun bevoegdheden zijn bekendgemaakt.)

Door de indiening van mijn offerte aanvaard ik al de clausules van het bestek en verzaak ik aan alle andere voorwaarden, zoals mijn eigen verkoopsvoorwaarden, zelfs wanneer deze op een of andere bijlage van mijn

offerte of factuur voorkomen. Elk voorbehoud of het niet nakomen van verbintenissen inzake één van deze clausules of beschikkingen leidt tot de substantiële onregelmatigheid van mijn offerte.

Ik aanvaard dat:

het volgen van de procedure van onderhandelingen geen verplichting inhoudt tot het toewijzen van de op- dracht. De aanbestedende overheid kan zowel afzien van het gunnen van de opdracht als de procedure her- beginnen, desnoods op een andere wijze). Ik heb geen recht op een schadevergoeding als het bestuur beslist om een bepaalde deelopdracht of de opdracht niet te laten uitvoeren. Wanneer de opdracht in zijn geheel gegund wordt, wordt ze fasegewijs in deelonderzoeken gerealiseerd/uitgevoerd. Ik erken door het indienen van mijn offerte dat ik enkel een deelopdracht mag starten na een uitdrukkelijk bevel van de aanbestedende overheid. Ik aanvaard dat de aanbestedende overheid zich het recht voorbehoudt een fase niet te laten uit- voeren. Ik heb geen recht op een schadevergoeding als het bestuur beslist om een bepaalde deelopdracht niet te laten uitvoeren.

Document Metadata

Table of Contents

Overheidsopdracht voor aanneming van diensten

Document Metadata