Custom app development for record access and logging in healthcare
Once a record is also opened outside the organisation, the logging question changes. A district nurse in a living room, a doctor on an out-of-hours service, a clinician at a second location: each of those moments is an action for which the patient may request access, and they occur on a device that does not have to belong to the organisation.
Why mobile use makes this harder
The Wabvpz gives patients the right to free electronic access to their record and to an electronic copy, and additionally the right to access the logging: who viewed or made available which data, and when. Both rights have applied since 1 July 2020.
As long as all access takes place from a workstation on the premises, this is a technical question within a single system. With mobile use, it shifts. The question of who looked becomes who was actually sitting behind that screen, and that is harder to answer on a shared device in a car than at a workstation with a access badge.
This is where the capacity comes in. A care professional can open a record from a treatment relationship, from locum cover, or from a service. For the logging, that difference matters, because it is exactly what a patient wants to know when they see a name they don't recognise. An app that only records that a record was viewed leaves that question open.
How we build this
The action on the device is the unit here. If it records who looked and why, the logging on the office side is complete rather than partial.
Which roles open a record outside the institution, and on which device. In most organisations there are more than expected, and some use a personal phone.
Treatment relationship, locum cover or service. Not as a free choice afterwards but as a precondition beforehand, otherwise the logging contains a reason nobody actually chose.
Whatever is on the device can leave with it. We show what is needed for the visit and not the full record, and we clear it up as soon as the visit is closed.
Access by the patient is a different app with different requirements for identity verification. We deliberately keep the two apart, even though they partly display the same data.
What the app does in practice
The app serves two groups that must not see each other's data. Which components you need depends on whether you build only the care professional side or the patient side as well.
Opening with a reason
When opening a record, the care professional records the capacity: treatment relationship, locum cover or service. That is the detail that gives the logging its meaning and that cannot be reconstructed afterwards.
Every action logged, including on the device
Viewing, changing, sharing and exporting are recorded with timestamp and person, even when the action took place offline. An action that only arises on synchronisation receives the time at which it actually happened.
Access for the patient
The patient views their data and their logging in plain language, with identity verification suited to the sensitivity. That is a separate environment and not an extra screen within the same app.
Working offline
In a living room, a lift or a basement, the network drops out. The app carries on with what is needed for that visit and synchronises afterwards, with the logging intact.
Flagging unusual access
A record opened without a treatment relationship, or unusually often. Noticing that before a patient asks about it is the difference between an internal conversation and a complaint.
Integration with your records system
The data stays in your existing system. We build the mobile layer alongside it via integrations and write the logging back to the same place as the office side.
Who we build for
Where work takes place outside the institution differs greatly by type of care. Four situations.
District nursing and home care
The record is opened in the client's living room, on a device shared between shifts. Here, establishing who actually looked is the hardest question and at the same time the most important.
Ambulant and mobile teams
On the move, with changing locations and sometimes no coverage. What is recorded offline must later end up in the logging with the correct time, not with the moment of synchronisation.
Locum cover and services
Outside office hours, someone opens a record without a fixed treatment relationship. That is precisely the access about which patients ask questions, and precisely where recording the reason is usually missing.
Occupational health physicians and occupational health services
The relationship is more sensitive because the employer pays and the employee is the patient. Being able to demonstrate who viewed what is here not a formality but the core of trust. Complaints arising from this run through a separate route; see complaints management software.
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
The app is a window onto your records system and not a second record. Everything it records enters the same logging stream that fills the office side.
Why Appfront
On a shared device, who looked is a genuine question
We link permissions to the user rather than the device, and enforce the role when a record is opened. Without those two, your logging is formally complete but substantively empty.
Offline, logging must not shift
An action is given the time it actually took place, not the time of synchronisation. Otherwise the timeline the patient sees will not be accurate.
Don't show the patient your technical log
What is recorded is technical; what is shown should be readable. That translation is part of the design, not a presentation layer added afterwards.
One logging stream, not a second reality
The app writes to the same place as your office systems; see Wabvpz software for that side.
Security and privacy
A device holding patient data that leaves the premises calls for stricter choices than a workstation. We keep offline storage limited to what the current visit needs, clear it on closure, link permissions to the user rather than the device, and make sure a lost device can be unlinked remotely without stopping colleagues' work.
The patient side requires its own considerations, which weigh more heavily than for an ordinary app. Electronic access means you must be certain who is on the other end, and the level of assurance expected in care is high. That choice determines not only security but also how many patients actually manage to log in. The logging overview is itself sensitive, as it shows which member of staff opened which record; we therefore separate what a patient sees about themselves from what a line manager may see about an employee. How we handle security ourselves is set out in our information security policy; reports from outside come through our vulnerability disclosure policy.
Frequently asked questions about the Wabvpz app
That is possible, and for some of the work it is enough. What a web version rarely does well is work offline and limit what remains stored locally. In district nursing and outpatient teams, those are precisely the two things that decide whether it gets used in practice or a paper list emerges instead.
No. Specified consent is written into the law but has never come into force; a workable implementation was sought for years and proved impossible. Building an app around it means building around a rule that does not legally apply. Which consent framework applies in your situation is for you to agree with your own legal adviser.
By linking permissions to the user rather than the device, and by enforcing the role when a record is opened. A shared login makes your logging formally complete but substantively worthless, because a team name stands where a person should be.
It is given the time at which the action actually took place, not the moment of synchronisation. Otherwise the timeline the patient sees will not be accurate, and that is precisely the overview on which they base their question.
We advise against it. Healthcare providers and patients need different rights, different identity checks and a different presentation. We build that as two environments on the same data source, even though they may look alike.
Usually, provided that system offers an integration to retrieve data and write events back. What is available varies greatly by supplier, so we map this in advance and make no promises about an integration until we have seen what the system provides.
This app is about the moment a record is opened outside the organisation. The Wabvpz software collects the events from all your systems and translates them into an overview a patient can read. They share a single logging stream.
That depends on whether only the provider side needs to be included or the patient side too, and on which login method you choose. Mobile access with logging is typically quick to deliver; the patient side with identity verification takes more effort. We will give you a reasoned estimate after the discovery phase.
Recording access outside the organisation?
Ask how many records were opened outside the premises last week and whether it was recorded in what capacity. The difference between those two answers is the work. We build this as a standalone app and as part of a broader custom app development or custom software development project.