Custom software for electronic access and logging in healthcare
The Wabvpz is usually summarised as the right to electronic access. Almost everyone builds that part. The second right is often overlooked: the patient may see who viewed or made available which data, and when. That is not a small screen but a requirement on your entire architecture, because you can only show what you recorded along the way.
Two rights, and a third that does not exist
The Act on Supplementary Provisions for the Processing of Personal Data in Healthcare gives every patient the right to electronic access to their file and to an electronic copy of it, free of charge. This is Article 15d and has applied since 1 July 2020. In addition, Article 15e grants the right to access the logging: who viewed or made available which data, and when.
The second right is the difficult one. Showing access can be drawn from your existing file; showing logging is only possible if who did what was recorded along the way, in a form understandable to someone without a technical background. Many systems do log something, but in technical terms, spread across components and often without the context the patient is looking for.
There is another point that goes structurally wrong, in the opposite direction. The Act also contains specified consent, whereby the patient would give consent per category of data and per category of healthcare provider. That part has never entered into force: after years of effort, a workable implementation proved not feasible. Anyone who builds a system around specified consent is building around a rule that does not legally exist.
Once a file is also opened outside the institution, the question of who looked changes. How to record that on a shared device is covered in the Wabvpz app.
How we build this
The event is the unit here: one action, one person, one moment. If that is recorded at the moment itself, the logging view is a presentation rather than a reconstruction.
We look at which actions your current systems record and what is missing. At most care providers, the problem is not a lack of data but that it is unusable, because the context is missing.
A log entry stating that a user account accessed a resource is no answer for a patient. For each action, we design what is shown and to whom.
The patient sees a presentation, not your record-keeping. That separates responsibility and prevents a change in your system from affecting the right of access.
We replay a request for access to logging and see how much manual work is involved. That figure is what it will cost you per request.
What the software actually does
Recording events underpins everything; access and copies are presentations of it. Which components you need depends on what your record system already provides.
Logging in an understandable form
For each event: who, when, which data and for what reason, written in a way a patient can read. A technical log entry does not satisfy a right intended for the patient themselves.
Electronic access and copies
The patient views their data and obtains a copy, free of charge. The copy is a presentation of the record at that moment, not a copy of your database.
Making data available recorded separately
Not only who looked, but also to whom data was made available. That is a separate event, and precisely the one patients ask about.
Consents as they actually apply
Recording what a patient has permitted and to whom, under the framework that actually applies. We do not build anything around specified consent, as it never came into force.
Flagging unusual access
A record opened outside the treatment relationship, or unusually often. Noticing this before a patient asks about it is the difference between an internal conversation and a complaint.
Integration with your records system
Data stays in your existing system. We build the access and logging layer alongside it via integrations, rather than creating a second record.
Who we build for
What you need to build yourself depends on your system and your size. Four situations.
Providers with their own record
You manage the record yourself and therefore bear the full obligation. Logging often exists but is spread across components and cannot be presented to a patient. If you also fall under the Cybersecurity Act, a separate care duty file is added.
Practices with a supplier's package
Your supplier provides access, but logging access is often limited or missing. The question is then what you add yourself and what you leave with your supplier; that is as much a contractual question as a technical one. We build a separate environment for patients as a portal on top of your package.
Care with many chain partners
When sharing, making data available matters more than access. Every exchange with another provider is an event the patient is entitled to see, and it occurs outside your screen, usually via integrations with a chain partner.
Occupational health physicians and occupational health services
The relationship is more sensitive here because the employer pays and the employee is the patient. Precisely then, being able to demonstrate who viewed what is not a formality but the core of trust. A reporting channel for incidents is set up separately; see the incident reporting portal.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Technology and integrations
A great deal is changing in healthcare data exchange, including through the Wegiz with designated exchanges. Everything related to this should be configurable and retained per version.
Why Appfront
Logging is the real build
Showing access can be done from your record; showing logs can only be done if you have recorded along the way who did what, in language a patient understands.
We do not build around a rule that does not apply
Specified consent is in the law but has never come into force. We say so rather than selling you a module for it.
Your records system stays in place
We build the access and logging layer alongside it via integrations. A data migration just to meet a right of access is the most expensive route.
The access log is itself sensitive
Anyone who can see who opened which record also learns something about your staff. We set separate permissions for this and show the data subject what concerns them.
Security and privacy
This topic turns the usual security question around. Normally you protect data from being seen; here you must make access possible, for the data subject, without others looking along. The access log is itself sensitive: it shows which employee opened which record. We therefore separate what a patient sees of their own record from what a manager may see about an employee, and we also record access to the log itself.
The identity side is the second half. Electronic access requires you to be certain who is on the other end, and the assurance level in healthcare is high. That isn't something you build yourself but a connection you choose, and that choice determines how many patients actually log in. On the storage side, events must be tamper-proof, and logs must be kept longer than ordinary application logs, because the right of access looks back in time. How we handle security ourselves is set out in our information security policy; reports from outside go through our vulnerability disclosure policy.
Frequently asked questions about the Wabvpz
Free electronic access to their record and an electronic copy of it, and in addition access to the log: who viewed or provided which data and when. Both have applied since 1 July 2020. The second right is in practice far less often fulfilled than the first.
No. Specified consent is in the law but has never come into force; for years people searched for a workable implementation and none proved possible. Building a system around it means building around a rule that does not legally apply. Check with your own lawyer which consent framework applies in your situation.
Enough to answer the patient's question: who, when, which data, and whether it concerned access or provision to someone else. A technical log line with a user number and a table name does not suffice, because the right is intended for the patient themselves. That means translating into plain language is part of the design.
Usually not. Systems generally log for administration and fault diagnosis, with a short retention period and without context. What the law requires is a longer-retained, understandable view for the data subject. We first look at what already exists and build only what is missing; that is almost always cheaper than starting over.
Yes, and that's the recommended route. The data stays where it is, and we build the access and logging side alongside it, connected via integrations. A data migration just to fulfil a right of access is a large project for a small goal.
That is a separate track. The Wabvpz concerns the patient's rights of access and logging; the Wegiz makes electronic data exchange mandatory for designated exchanges between healthcare providers. The two overlap, because every exchange is a making available that the patient is entitled to see. Which exchanges are designated for you changes over time, so check that separately.
The patient, regarding their own record. Within your organisation the overview is more sensitive than it appears, as it also shows which of your staff opened what, and that touches their employment relationship. We set separate permissions for this and also record who has viewed the logging itself.
That depends on what your current system already records, how many systems need connecting and which login method you choose. Log display on existing events is usually quick to put to use; completing the recording in older systems costs more. We'll give you a reasoned estimate after the discovery phase.
Fulfilling access and logging?
Ask your systems administrator who looked at an arbitrary record last month, and whether that answer could be shown to a patient. The gap between those two is the work. We build this as a standalone application and as part of a broader custom software project.