Custom app for start, stop and hours in youth care
A start message should reflect the day care actually began. In practice, that is the day a care worker first stepped into a family's home, yet that date ends up in the system a week later when someone updates their weekly timesheet. That gap of a few days is exactly where a claim later gets rejected.
Why the moment itself matters
In the Youth Act chain, messages follow one another: the municipality allocates, the provider reports that care starts, later reports that it ends, and invoices for what was delivered. Each of those messages contains data, and that data must align with each other and with the allocation.
The start is the hardest part, because it happens outside the office. A care worker makes a home visit, and whether that conversation already counts as care or is still an introduction is a substantive judgement they make on the spot. If that judgement is only recorded a week later, it is no longer the judgement itself but a reconstruction.
The same applies at the end. Care rarely ends on an announced date; it fades out, or stops because a family moves. Anyone who only notices this at the quarterly review ends up claiming for a period in which nothing was delivered, and that comes back as a rejection or a reclaim.
How we build this
The contact moment is the unit here. If what happened and when is recorded there, the messages follow from that, rather than from a weekly closing exercise.
We look at what a day looks like, when recording happens and why not sooner. Nearly always the answer is that it doesn't work after a home visit.
Who, when, what type of contact, how long. Anything beyond that is postponed, and postponing is exactly the problem we solve.
In a family home, in a car or at a school. The app works offline and synchronises later, with the actual time.
From what has been recorded, the administration assembles the start, stop and claim messages. The care worker has no part in that and doesn't need to.
What the app does in practice
The app does little, and that little should be easy to use in a stairwell. Which components you need depends on your types of care.
Start and end at the actual moment
The care worker records that care has started or ended, with the date that is correct. That is the date the message rests on, and it cannot be reliably reconstructed afterwards.
Recording contact in a few taps
Type of contact, duration and whether it concerns delivered care. Fixed choices, with room for a short note; anything longer does not happen after a home visit.
Fully offline operation
In a living room, a car or a school the network drops out. Recording continues with the actual time and synchronises afterwards.
Alert when deviating from the allocation
More hours than allocated, care outside the allocated period, a product that doesn't match. Seeing that in the moment is the difference between correcting course and reclaiming.
As little as possible on the device
A care worker needs the data of their own clients for that day, not the file. That limits what is held offline and what is at risk if a device is lost on the street.
Passing it on to bookkeeping
What is recorded travels via integrations to the system that compiles the messages. That side sits in Youth Act software.
Who we build for
Where and when recording takes place differs considerably by type of care. Four situations.
Outpatient youth care
The care worker is out all day and seldom in the office. This is where the gap between recording in the moment and at the end of the week is greatest.
Residential care and day treatment
The care is continuous and the start point is clear, but changes such as absence and leave determine what can be claimed. Those arise on the group.
Youth mental health and specialist care
Treatments run long and change shape. The alignment with the allocation therefore shifts over time, and the clinician notices this sooner than the administration does.
Self-employed care workers and small practices
You are the administration yourself. Then what matters most is that recording happens during the work, because no one is there to put it right afterwards.
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 the field side of your care administration and does not compile messages itself. What it records ends up in the system that builds and sends the iJw messages.
Why Appfront
The date in the message must be the real date
We record start and end at the moment itself. A week later it is a reconstruction, and your claim is rejected because of it.
At a family's home there is no signal
Offline is the starting point, with the actual time. An app that stalls there gets replaced by a note on a phone.
The care worker notices deviation from the allocation first
We show the signal there, because correcting course during the treatment is cheaper than reclaiming afterwards.
This concerns young people on a device outside the office
We show only the clients for that day and not the file, and keep offline storage as small as possible.
Security and privacy
A device holding data on young people that goes along on home visits calls for stricter choices than a workstation. We limit offline storage to the clients and appointments of that day, do not show full records in the app, tie permissions to the user rather than the device, and ensure a lost device can be remotely disconnected.
There is also a substantive boundary that shapes the design. An app that records *that* care was provided does not need to record *what* was discussed; that belongs in the file, not in a register that administration also reads. We therefore do not build a free-text field for substantive reporting, however handy it may seem. What the app does record, the moments and the duration, must be immutable, because a financial accountability depends on it. 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 youth care app
Because the date in a start or stop message must be the date on which the care actually began or ended. If it is entered a week later, it becomes a reconstruction, and that is exactly where the differences with the allocation arise that lead to claims being rejected. Entering things afterwards costs no time, but it does cost money.
No, and that is deliberate. The app records what happened; the administration then drafts the messages and sends them via the switching point or data hub. That way, a care worker does not need to know message numbers, and responsibility for the claim stays where it belongs.
Yes, that is the starting point. Registrations are stored locally with the actual time and sent as soon as there is a connection. During home visits that is not an edge case but the normal situation, especially in older houses and in the car.
They can, and it makes a big difference. When they see how many hours or which product has been allocated, they notice for themselves when they go beyond it, and a new allocation can be requested in good time. That is the difference between steering in advance and recovering costs afterwards.
We advise against it. What was discussed belongs in the client file, not in a registration that is also viewed by administration and auditors. Keeping the two separate keeps the circle of people who see substantive information small, which is exactly what you want for this client group.
Yes, and it is usually the reason for the project. Each municipality uses its own product codes and agreements within the same standard. The app shows the care worker only what applies to their client; the differences sit in the administration behind it.
No. Your package continues to handle client administration and messaging; see also WMO and youth care software. What we add is the field side, so the data is created at the moment it is correct.
That depends on the number of care types, whether the signal has to be sent with the assignment, and which package it connects to. Start, stop and contact registration are usually quick to put to use; the integration and the alerting cost more. We give you a reasoned estimate after the discovery phase.
Record moments when they happen?
Ask a care worker when they last recorded care for their most recent new client and compare that with the start date. That gap is what causes your claims to be rejected. We build this as a standalone app and as part of a wider custom app development or custom software development project.