Care software starts with who may see it.
In healthcare the data is the most sensitive there is. So a portal or an app here is never only a build question: it is just as much about access, retention periods and what you can demonstrate when someone asks.
We build alongside the record system you already have. A portal for clients, an app for staff, an integration that fetches data from where it belongs, with NEN 7510 and the GDPR as the starting point rather than an appendix.
In care a leak is not an outage but an incident.
Care organisations usually have their record system in order. The trouble is around it: registrations arriving by email, rosters in Excel, photos in a chat group and forms that differ per municipality. All of it born of necessity, and all of it outside the system where the controls live.
As long as nothing happens, nobody notices. During an audit, a staff change or an incident they do. Then it turns out the rights were never recorded, that data is sitting there which should have gone long ago, and that nobody can demonstrate who viewed what and when.
Access arranged on trust turns out to be recorded nowhere.
On top of that, most of the budget goes into keeping things running. Licences, management and a vendor charging per change, while what municipalities and inspectorates ask for shifts every year. Anyone keeping a second administration to answer those questions is paying twice for the same data.
NEN 7510 applies to the supplier too, so to us. That is why we start not with what the software should do but with which data is genuinely needed. Usually that is half of what was asked for, which makes building simpler and safer at the same time.
What we build in healthcare.
Not an electronic patient or client record: we leave that to the parties who already do it. Everything needed alongside it that now runs by hand or outside the system is another matter.
-
A portal for client or family
Viewing appointments, filling in forms, sending secure messages and finding documents. With a login that matches the risk, and without data ending up somewhere it does not belong.
-
An app for staff
Roster, route, client details and reporting on the phone, including at a client's home without coverage. Only the data someone needs at that moment, and nothing more.
-
Intake and waiting list
From first registration to intake in one flow, with the status visible to everyone. That stops the calls from referrers and the hunt for forms that arrived by email.
-
Integrations with the record
Data to or from the electronic record via HL7 FHIR, a vendor integration or a secure exchange. One source, and no second administration slowly drifting apart.
-
Reporting and accountability
The figures municipalities, care offices or your board ask for, built from what was already recorded during the work. Printed rather than reconstructed.
-
Access and logging
Roles, rights and a log recording who viewed what and when. That is not only a requirement; it is also the only thing that lets you show after an incident what did and did not happen.
Four things we see in healthcare.
The record system is usually well arranged. The trouble sits around it: intake, rosters, reporting and the emails drifting in between.
-
Data wanders outside the record
Intake forms by email, rosters in Excel, photos in a chat group. All of it arose for understandable reasons and all of it is exactly what you do not want to explain during an audit or after a breach.
-
The record system almost fits
An electronic record is built for the record itself, not for your waiting list, your transport planning or the form your municipality requires. So someone keeps that beside it, by hand.
-
Reporting costs care time
Municipalities, care offices and inspectorates each want something different. Whatever does not build up during the work has to be gathered afterwards, and those hours come off the care itself.
-
Access is a habit, not a setting
Who may see what is often arranged on trust and routine. When staff change or an external audit arrives, it turns out the rights were never actually recorded.
How we usually start in care.
With the question of which data is genuinely needed. Here that is not a formality up front; it determines how you build.
-
Go through the data first
Which data, about whom, for how long and who may access it. Half of what is asked for often turns out to be unnecessary, which makes building simpler and safer at once.
-
Live small and bounded
One department or one process first, with real users and a fallback. That way you find out in practice whether it fits before it touches your whole organisation.
-
Record what is there
Documentation, rights model and processing agreement in order, so an audit or a client question does not become a search. We deliver that with the work, not afterwards.
What it connects to.
The central record stays with your current vendor. We build alongside it and connect through the routes intended for that.
If your vendor will not cooperate, we say so before we start. Promising an integration that depends on a third party is a promise we cannot keep.
- HL7 FHIR The standard for exchanging data with a record system.
- MedMij Let clients retrieve their own data.
- Nictiz / Twiin The national agreements exchange has to comply with.
- ChipSoft HiX Through their layer; their lead time sets the schedule.
- Epic Large hospitals; we connect through their FHIR endpoints.
- Nedap ONS Widely used in long-term care, with an API.
- Ecare Exchange reports and care plans.
- Topicus Pull record data for a portal or reporting.
- iWmo / iJw Message exchange with municipalities on the national standard.
- VECOZO / GGK The route those messages travel to reach the municipality.
- ZorgMail / Zivver Exchange messages securely with colleagues and clients.
- AFAS Bring in rosters, hours and payroll.
- Two-factor login Required for access to client data.
- NEN 7510 The standard we have to meet as a supplier too.
Is your record vendor not listed?
Name them. What makes an integration hard in care is rarely the technology but the vendor's cooperation. We find that out before we commit to a schedule.
Questions from this sector.
If your question is not here, give us a call. We also say honestly when something falls outside what we do.
Book a callAre you NEN 7510 certified?
We work to the requirements the standard places on a supplier: Dutch servers, encrypted traffic, recorded access and retention, and a processing agreement. We do not hold a certificate of our own, and we would rather say that up front than have you discover it during a tender. If your organisation does require one, we discuss whether that is feasible before we start.
Where is the data stored?
On our servers in Rotterdam, with a failover location in the Netherlands. Not with an American provider, and not somewhere we cannot send anyone when hands are needed.
Do you build electronic patient records?
No. There are parties who have done that for years and do it better than we would. We build what stands next to it: a portal, an app, an integration or a piece of reporting. If you ask us for a record system, we will tell you we do not do it.
Can you connect to our current record system?
Usually yes, via FHIR or the vendor's integration. What makes it hard is rarely the technology but the cooperation and lead time at that vendor. We find that out before we commit to a schedule.
How do you handle a data breach?
We agree in advance who we call and within what time. We report to you, you are the controller towards the Dutch data protection authority, and we supply the logs you need for that.