Many systems call the appointment screen “the client file.” The difference is not in the name: the appointment record is a list of visits organized by date, while the file is a structure that preserves who the client is, what cases he was treated for, how many episodes of care he went through, and what happened in each session.
This structural difference is what determines whether the system can answer a professional question after two years.
Why is this requirement included in the purchasing decision?
Because changing it later is practically impossible. The data structure is determined when constructing, and it is not possible to convert a list of appointments into a linked file with an update. If you buy a system that only records visits, you’ll stick with it that way.
The effect is daily: a client returns after a year with a different problem. In the appointment log you will find his old visits mixed with the new. In the linked file, you will find a previous care episode that is closed with its result, and a new episode that starts clean with the history remaining available for viewing.
What should the scope cover?
Request that the system distinguish between four interconnected levels:
- Person: One fixed identity, no matter how many services and situations it has, with an identifier that is not repeated.
- Status: The reason for requesting service in a certain period – and a person may have more than one case over the years.
- Care Ring: A service path has a beginning, an end, a responsible professional, a plan, evaluations, and a closing outcome.
- Session: The single meeting within the circle, with its documentation, attendance, and financial impact.
And beyond that: relationships between people (family, guardian), documents, approvals, access history — all linked at the right level and not stacked in one place.
Checklist in demo
- Open a client file: Do you see separate episodes of care or a list of appointments?
- Create a second episode for an existing patron: is the first still archived separately?
- Open a session: Do you know which episode you belong to?
- Add family relationship: Are the two files linked without merging their data?
- Request a report “Average number of sessions per episode” — cannot be built from an appointment log.
The last test is crucial: determining the average sessions for each episode requires knowing where the episode begins and ends. A system that only records visits does not have these limits, so it cannot build the report no matter how many screens you add to it – and the problem is in the structure, not the reports.
Limits that need to be adopted
- Who opens and closes a loop: A professional decision with specific authority, not an administrative procedure.
- What is transferred between episodes: The history is available to view, but old loop data is not automatically copied to new.
- View closed loops: Is subject to the same permissions and is registered — the date does not become open because it is out of date.
- Single file integral: Multiple loops do not mean multiple files, otherwise the loop returns through the back door.
The next step is to document the requirements
Write in your requirements: “Permanent file with multiple independent episodes of care”, and ask for it to be proven in practice. See Files and cases page.
Request a system demo
We open a file with two episodes of care over two years, and you can see how the history remains available without being mixed up with the new case.