De zorgsector staat voor immense uitdagingen. De vergrijzing, stijgende kosten en een nijpend personeelstekort vragen om fundamentele veranderingen. De oplossing ligt niet alleen in meer handen aan het bed, maar ook in slimmere processen en effectieve inzet van technologie. Dit is waar de kracht van apps en applicaties in de zorg onmisbaar wordt. Maar hoe navigeer je als CIO, IT-manager of architect door dit complexe landschap van technologische mogelijkheden? Welke use cases zijn het meest relevant voor jullie organisatie, of je nu actief bent in de VVT, GGZ, een ziekenhuis of de JGZ?

‍

In dit artikel duiken we in de wereld van digitale transformatie in de zorg. We verkennen de concrete toepassingen van applicaties, de strategische rol van low-code en hoe je een robuuste IT-architectuur bouwt die innovatie mogelijk maakt. Dit is jouw gids om digitalisering te omarmen en zo de zorg van morgen te bouwen.

‍

De businesscase van digitale transformatie

‍

Digitalisering in de zorg is geen doel op zich, maar een middel om de zorg te verbeteren en de organisatie toekomstbestendig te maken. Voor CIO's en managers I&A is de businesscase helder: investeren in de juiste technologieën leidt tot operationele efficiëntie, hogere patiënt/cliënttevredenheid en een aantrekkelijke werkomgeving voor professionals.

‍

Sneller innoveren met low-code en no-code

‍

Een van de grootste struikelblokken bij innovatie in de zorg is de snelheid. Grote EPD-systemen zijn complex, de implementatie duurt lang en maatwerk is kostbaar. Dit leidt soms tot het ontstaan van 'shadow IT', waarbij afdelingen zelfstandig niet-goedgekeurde softwaretools of AI-tools gaan gebruiken om hun werk gedaan te krijgen. Dit brengt veiligheidsrisico’s met zich mee.

‍

Low-code en no-code bieden een elegant antwoord. Deze platforms stellen ons in staat om sneller en efficienter, in een visuele omgeving, applicaties te bouwen. Denk aan een app voor het aanmelden van nieuwe cliënten of een tool voor de planning van facilitaire diensten. Omdat dit gebeurt binnen één centraal systeem, wordt de controle behouden en de innovatie gestimuleerd. Het is een krachtige manier om de digitale transformatie zorgsector te versnellen en een landschap aan tools te ontwikkelen dat naadloos aansluit bij de realiteit van de zorgwerknemer.

‍

Het belang van een robuuste IT-architectuur

‍

Succesvolle applicaties staan of vallen met hun integratie in de bestaande IT-landschap. Veel zorgorganisaties kampen met een lappendeken van systemen die niet met elkaar communiceren. Het creëren van een robuuste IT-architectuur is daarom de eerste stap. Dit omvat de keuze voor het juiste integratieplatform, het opzetten van een effectieve API-managementstrategie en het naleven van datastandaarden (zoals HL7 en FHIR). Dit zorgt voor naadloze gegevensuitwisseling in de zorg en maakt het mogelijk om nieuwe apps te koppelen aan bestaande systemen.

‍

Daarnaast is cybersecurity een absolute topprioriteit. Met de toename van digitale data en applicaties, neemt ook het risico op datalekken toe. Een gedegen IT-architectuur omvat daarom ook strikte protocollen voor privacy en beveiliging, in lijn met de AVG. De IT-architectuur is de fundering waarop alle digitale innovaties gebouwd worden.

‍

Case studies en succesverhalen uit de praktijk

‍

Theorie is mooi, maar praktijkvoorbeelden spreken meer. We zien overal in Nederland dat zorginstellingen de stap zetten naar digitalisering, met indrukwekkende resultaten.

‍

Casus 1: Slimme thuiszorgapp in de VVT
‍

Een grote Amsterdamse thuiszorgorganisatie kampte met een te hoge administratieve last voor thuisverplegers.
‍

Door de ontwikkeling van een low-code app, speciaal op maat gemaakt in samenspraak met de verpleegkundigen, veranderde de situatie radicaal. Van vele losse apps die elk "een deeltje" van de oplossing boden gingen we naar één overkoepelende "superapp" met alle afspraken, taken en notities allerhande.

Zo bekijken verpleegkundigen nu hun geoptimaliseerde routes via de app, kunnen ze direct bij de cliënt rapportages maken en taken beheren. Het resultaat? Een besparing van de administratieve lasten, minder switchen tussen apps en dus een toename van de tijd aan het bed, wat resulteerde in hogere medewerkerstevredenheid en betere cliëntresultaten.

‍

Casus 2: Low-code applicatielandschap in het ziekenhuis
‍

Eén van de grootste private zorggroepen in Portugal, kampte met gefragmenteerde digitale zorgservices die patiënten dwongen om tussen meerdere systemen te schakelen. Door de ontwikkeling van een compleet digitaal ecosysteem met low-code technologie, transformeerde het ziekenhuis naar een geïntegreerd app-landschap van 28 verschillende digitale innovatie-initiatieven.

‍

De kern hiervan vormt de patiënten-app, maar daarnaast ontwikkelde het ziekenhuis ook specifieke applicaties voor verschillende zorgprocessen:
‍

• Remote monitoring via wearables: Zorgprofessionals kunnen nu op afstand patiënten monitoren door data van wearable devices te synchroniseren via GoogleFit en HealthKit naar de app, inclusief hartslag, bloeddruk, slaap en lichaamstemperatuur.
  ‍
• Telefoonzorg: Een 24/7 telefonisch triage-systeem bediend door gespecialiseerde verpleegkundigen dat binnen drie maanden na lancering al 4.000 patiëntoproepen per maand verwerkte.
  ‍
• Centraal Klinisch Record: Een gespecialiseerde applicatie die zorgprofessionals een geïntegreerd overzicht geeft van klinische patiëntdata uit meerdere specialismen en systemen, cruciaal voor complexe pathologieën

‍

Het resultaat is een ecosysteem dat meer dan 1,3 miljoen mensen serveert, waar 70% van alle artsen online afspraken toestaat en online boekingen met 400% stegen. Door alle systemen op één low-code platform te consolideren kan het ziekenhuis snel nieuwe functionaliteiten toevoegen en heeft hetzich gepositioneerd als voorloper in digitale zorgverlening.

‍

‍

Quick Takeaways
‍

• Efficiëntie is de sleutel: Apps verminderen de administratieve last en creëren meer tijd voor directe patiëntenzorg.
• Low-code versnelt innovatie: Platforms stellen zorginstellingen in staat om snel en flexibel applicaties op maat te bouwen.
• Integratie is essentieel: Een robuuste IT-architectuur met API's is nodig voor naadloze gegevensuitwisseling.
• De patiënt/cliënt centraal: Van patiëntportalen tot apps voor thuismetingen, technologie vergroot de regie van de patiënt of cliënt.
• Security is non-negotiable: Investeringen in apps moeten hand in hand gaan met een sterke focus op cybersecurity en gegevensbescherming.
• De toekomst is hybride: De meest succesvolle zorgmodellen combineren fysieke zorg met digitale tools voor optimale resultaten.
  
  ‍

Conclusie

‍

De digitale transformatie in de zorg is een onomkeerbaar proces en de rol van applicaties is hierin leidend. We hebben gezien dat apps niet alleen processen automatiseren, maar ook de kwaliteit van de zorg verbeteren, de patiënt meer regie geven en een antwoord bieden op de toenemende werkdruk.

Low-code in combinatie met AI is hierbij een krachtige versneller, die zorgprofessionals en IT-afdelingen in staat stelt om samen te innoveren en te excelleren, zonder afbreuk te doen aan veiligheid en integriteit. De uitdaging ligt niet in of we moeten digitaliseren, maar in hoe we dit doen: strategisch, geïntegreerd en met de focus op de mens.

Het opzetten van een robuuste IT-architectuur, het omarmen van low-code, en het starten met concrete, kleine pilotprojecten zijn cruciale stappen voor elke zorgorganisatie. Als externe IT-partner gespecialiseerd in de care en cure, begeleidt Harmony al jarenlang zorginstellingen bij deze complexe transitie. Wij helpen u de juiste strategische keuzes te maken en de technologische oplossingen te implementeren die uw organisatie en uw patiënten écht verder helpen.

‍

Veelgestelde vragen (FAQ's)

‍

V1: Wat is low-code en waarom is het relevant voor zorgorganisaties?
‍Low-code is een softwareontwikkelingsmethode die het mogelijk maakt applicaties te bouwen met minimale code, voornamelijk door middel van visuele interfaces en kant-en-klare modules. Het is relevant omdat het zorginstellingen in staat stelt om snel te reageren op veranderende behoeften, specifieke zorg apps ontwikkelen en de afhankelijkheid van traditionele, langdurige IT-projecten te verminderen.
‍

V2: Hoe kan ik de beveiliging van mijn apps garanderen in de zorgsector?
‍Beveiliging is van het grootste belang. Dit begint met een robuuste IT-architectuur die voldoet aan de AVG-richtlijnen en specifieke zorgnormen. Gebruik platforms met ingebouwde beveiligingsfuncties, voer regelmatige audits uit en zorg voor een strikt toegangsbeheer. Een cybersecurity strategie moet integraal onderdeel zijn van elke applicatie-ontwikkeling.
‍

V3: Wat is het verschil tussen een EPD en een Persoonlijke Gezondheidsomgeving (PGO)?
‍Een EPD (Elektronisch Patiëntendossier) wordt beheerd door de zorginstelling en bevat de medische geschiedenis van een patiënt. Een PGO is een app of online omgeving die door de patiënt zelf wordt beheerd en waarin de patiënt medische gegevens uit verschillende bronnen kan verzamelen, zoals uit het EPD van een ziekenhuis of de gegevens van een huisarts. De PGO vergroot de autonomie van de patiënt en ondersteunt de digitale patiëntreis.
‍

‍V4: Hoe kan mijn organisatie beginnen met de digitalisering van processen?
‍Begin klein. Identificeer een specifiek proces met een duidelijke pijnpunt, zoals de registratie van cliënten of de planning van afspraken. We ontwikkelen graag een kleinschalige pilot met een low-code platform en betrekken hierbij zowel IT als de eindgebruikers (zorgprofessionals). De lessen die jullie leren van dit project helpen het succes geleidelijk op te schalen.

‍

At Harmony Group, we believe that the well-being of our employees is the basis for a healthy and productive workplace. We are therefore actively committed to creating an environment where everyone feels supported, both professionally and personally.
‍

Focus on people

Our employees are number 1, which is why we believe it is important to promote a healthy work-life balance and provide space for personal growth. In addition to helping you develop skills, we also offer personal coaching with an eye for both professional growth and mental well-being.
‍

Annual Survey

Every year, we measure via the Happy Harmony Survey in Belgium and the B-Happy Survey in the Netherlands the commitment and well-being of our employees. We translate the feedback we receive into concrete actions, which we lay down in our welfare policy. In this way, we are constantly improving and responding to the needs of our team.
‍

Wellbeing Team Initiatives

Within our Business Consultancy section, we have a Wellbeing Team, part of the People Tribe. They regularly organize actions to strengthen well-being. One Wellbeing Day, including mindfulness sessions, ergonomics tips, massages and healthy food, for example.

We also regularly exercise together: walking, running, paddling... This is how employees recharge and feel good at the workplace.

‍

Our wellbeing charter

To clarify where employees can go if they are not feeling well, we have drawn up a wellbeing charter. This charter hangs in a visible location and provides all necessary information about available support options.

‍

Health partner Alan

Finally, through Alan, our personal health partner, we offer preventative health care. With our hospitalisation and outpatient insurance, employees can receive advice on topics such as stress, sleep, nutrition and sports. Health costs, such as consultations and therapies, are also reimbursed so that our employees can optimally focus on their health.

‍

Working for happiness, together

At Harmony Group, the well-being of our employees remains our top priority. We believe that a healthy and happy work environment contributes to the joint success of our company.

‍

At Harmony Group, we believe cutting-edge tech like AI and VR should be accessible, not intimidating. That's why our tech lead Owen Corstens set out to prove just how easy it is to integrate these technologies using OutSystems' low-code platform.

In this blog series, Owen shares his experiments step-by-step.

Whether you're a developer, business leader, or tech enthusiast, you'll see how low-code platforms like OutSystems can accelerate innovation. Let's dive in!

‍

---

‍

When I first imagined this project, I had one clear goal: I wanted to create a Virtual Reality scene in OutSystems where I could build the entire world around me just by talking to it. And the best part? I didn't want anything to be predefined—not in the environment, not in the OutSystems database. AI should be doing all the heavy lifting for me. I mean, why would I bother doing it myself? 😉

‍

One important thing to note: we're building a web application. Since we're using OutSystems, and we want this to work in VR, that just seemed like the most straightforward path.

‍

Cool goal, but where do you even start?

‍

I figured the first step was making sure my voice could actually be heard by the application.

‍

So I started simple. The goal was just to talk to the app. There are loads of ways to make that happen, but when I began experimenting with speech listeners—about a year ago—I had almost no experience with any of it. I decided to go with something familiar: the built-in WebKitSpeechRecognition API. I'd used it before while prepping for a hackathon, so it felt like a safe starting point.

‍

This web speech API is part of the browser, but here's something I didn't realize at the time (and only found out during implementation): it's still considered an experimental feature. That's going to matter soon.

‍

After setting up the necessary listeners and methods, things actually seemed to work pretty smoothly. All I had to do was trigger it—and voilà, it started listening.

‍

‍

Cool, I was definitely on the right track—getting my voice to show up on the screen felt like a win 😎😎 Sadly, the Web Speech API didn't turn out to be the best option. It really struggled with my beautiful accent. I didn't let it bother me too much though, since I was mainly just aiming for a happy flow.

‍

Still, I got a lot of weird and wrong results. Like this one time, I said “make the box with ID object one smaller,” and somehow it thought I said something about warmth. That was already my third attempt.

‍

So yeah, not ideal.

‍

Anyway, we kept going. The next step in our speech-enabled journey was figuring out how to trigger the speech listener automatically—no more needing to press a button or do something manually every single time. That meant I needed something called a Wake Word Function. Not gonna lie, that's a pretty cool term.

‍

Some quick research showed me there are third-party tools like Picovoice that can handle this kind of thing for you. But of course, I wanted to build it myself. Easier said than done, though.

‍

I started getting creative with WebKit Speech Recognition again. By using continuous listeners, I managed to keep the mic connection open. Then we added logic to only react to a specific command—so it wouldn't respond to every single word I said, just the comman I chose.

‍

‍

‍

After quite a few rounds of trial and error, it finally worked—I had an app that responded when I said the right command. As you can see in the title (and here), my trigger phrase was “Hey Daisy.” Originally, I wanted it to be “Hey AIRY,” since that's the name of the project, but the speech API just couldn't make sense of AIRY the way I played at home. So I had to swap to Daisy 😅

‍

To make it a fully functioning Wake Word, I also needed it to listen even when I wasn't actively using the app. And that's where I hit a wall. After a bit of digging, I found out that both iOS and Android were blocking me from using background services with a continuously open audio connection. There are some shady workarounds, but I didn't want to go down that road just yet. It wasn't a deal breaker, so I left that part for what it was.

‍

‍

ALRIGHT! You'd think everything was set now, right? Yeah... me too. Ha ha.

‍

‍

Later in the project, I made a test application for a VR environment. That's when I hit a new problem: the environment didn't respond to any of my commands. It was like it couldn't even hear me. Which was weird, because everything worked fine in the regular browser during testing.

‍

‍

After a ton of testing and debugging, I finally figured it out: the environment really wasn't hearing me. And get this—the browser speech APIs weren't supported at all in the META browser on the Quest 2. I tried some unofficial browsers too, but none of them worked either. So, I had to start thinking about alternatives. Remember how I said this API is experimental? Yeah, it really shows here. Bad luck, I guess.

‍

So I pivoted. For some reason, I started thinking: what if I pass the commands from another device? Since the speech stuff worked on both my phone and desktop, that didn't seem like a bad idea.

‍

New challenge unlocked: how do I get the commands from that device into the headset?

‍

Passing them to the server was easy with OutSystems. But getting them up to the client in the headset? That was the tricky part.

‍

First, I tried polling. But that created way too much load on the client just to catch a few commands. Bad idea. Plus, I would've had to expose APIS—Something I already got roasted for by an OutSystems tech expert in another project. Then I looked into timers, but that idea got scrapped quickly. Didn't really solve anything.

‍

After some ChatGpting (we're making it a verb, like “googling,” okay?) , I stumbled onto web sockets. That got me excited. This could work!

‍

So I dove in and started learning how to set up a websocket from scratch. And Boom—I landed in the Amazon Universe 😖 So much new stuff I had absolutely zero experience with. But hey, I love a challenge, right? We'll talk about how to set up a websocket in OutSystems in the next article—let's keep our focus on the speech stuff for now.

‍

And yes, we got it working with a websocket! Now the environment could actually hear me. Perfect! But of course, fix one problem and two new ones show up.

‍

Problem #1 was one I already knew about but kinda ignored. The speech API didn't recognize my commands properly. I had to repeat the same sentence like ten times—no exaggeration. I got so fed up. And worst of all, I never knew what exactly failed. Was it the speech API? The web socket? The AI? Or just a misheard command?

‍

So... I threw it all away:) Sometimes starting fresh is the way to go.

‍

Yes, we scrapped the entire command-passing functionality (I almost cried 🥺). I decided to switch to the Azure Speech APIs. I'd used them during the hackathon and avoided them at first because they're not free—but honestly, it was worth it after all the headaches. I could have used the Amazon APIs too, especially since they offer free credits. But I'm stuck with Azure.

‍

‍

Just a side note: OutSystems handles library imports in a specific way, but I'll cover that later. For now, just remember to import the Azure Speech SDK webpack into your OS project.

‍

‍

Alright, this article's getting long, but hang in there—we're almost there! And yes, you'll get to see the component 😉

‍

After introducing the Azure Speech API, everything almost worked perfectly. Yup, I still stand by what I said: every time you fix a problem, another one pops up. In this case, I got two more.

‍

First: the API is trained by a very smart AI model that tries to improve your sentence. Sounds nice, but it messed up my trigger phrase. It started adding commas between the words in my command, which made it unrecognizable. I fixed it in a super dirty way (again, just trying to keep my happy flow alive). I changed the command to just “Daisy” instead of “Hey Daisy.” I am still say “Hey Daisy,” but the continuous listeners sometimes miss the first characters, and that just made the original version fail too often.

‍

‍

Second problem: autoplay policies in browsers. If you've ever tried to open a camera or microphone immediately after a redirect, you'll know what I mean—it doesn't work. Browsers are getting stricter for good reasons, but it does make things harder. The WebKit Speech Recognition used to work fine and kicked in as soon as the screen loaded. But the Azure Speech SDK? Not so much. It wouldn't start after being initialized, and it didn't even throw a proper warning.

‍

To fix it, I needed a specific user gesture to trigger the whole thing. You can work around this in a SPA setup or with some trickery, but I didn't need to go that far. Instead, I just added a start screen with one nice, big button to launch the app.

‍

There we go—my final fix!

‍

‍

It's been an amazing ride to get the speech system working the way I wanted. After solving so many problems, I finally ended up with a working Wakeword Function that could turn my voice commands into real actions in the application.

The WakewordFunction Forge components are ready to download! You'll get both a library component and a demo application (ODC only for now). Try it out, improve it, and come back with feedback:) I'm 100% ready to keep making better WakewordFunctions! 💖

‍

‍

I had a few meltdowns along the way, but I'm really glad I stuck with it—this speech setup is a core part of my project.

‍

‍

‍