A patient's pathway crosses ten systems. And none of them governs it.
Booking, admission, tests, reports, follow-ups: every step has its own application and nothing holds the thread. Pwas describes the pathway the way the clinical protocol describes it and has the system govern it, with minimum access and a complete trace.
Healthcare doesn't lack data. It lacks something that holds the pathway together.
A healthcare provider already has a system for bookings, one for the laboratory, one for imaging, one for administration and often one for records. Each does its job well. What's almost always missing is the object that crosses them: that patient's pathway, with its expected steps, its deadlines and its outcomes. Without that object, coordination is done by people — with phone calls, reminders and lists kept on the side — and the quality of the pathway depends on how good they are and how present they are.
illustrative scenario
A follow-up pathway at an outpatient clinic group.
A patient completes a procedure and enters a follow-up pathway: three checks at defined intervals, each with different preparatory tests. The clinical protocol is clear and written down. The system, however, doesn't know the concept of a pathway: it knows individual bookings. So the pathway is held by a nurse, on a sheet, with reminder calls made when she finds the time.
At the ninety-day check the patient doesn't attend. No system notices: the booking simply shows as not honoured, like a thousand others. The fact that this missed attendance interrupts a specific clinical pathway is information that exists only in the head of whoever followed the case. If that person is on leave, the information exists for nobody.
What changes with Pwas
We start from the protocol, together with the people who apply it: this type of pathway has three checks with deadlines calculated from an index date; each check requires certain preparatory tests within a window; a missed check triggers a recall action whose priority depends on the pathway type; certain outcomes activate a different branch; responsibility for each phase belongs to a role, not a person.
From that description come the screens for whoever manages pathways, the departmental dashboards, the visibility rules and the automatic activities. Above all, the missing object appears: the pathway as data, with its state, its deadlines and its history. Bookings, reports and tests keep living in the systems that manage them; the pathway links them by reading from there.
The same follow-up, afterwards
On day ninety the missed attendance isn't a silent event: it creates an activity assigned to the role responsible, with a priority the system derives from the pathway type. The dashboard shows in real time how many patients are outside their window and on which pathways, with no need for anyone to keep a separate list.
The clinical data, meanwhile, hasn't multiplied: the report stays where it is, the pathway knows it exists and whoever is entitled opens it from there. The person making the recall call sees that a check needs rescheduling and by when, not the test results — because visibility is defined by role, field by field, and the principle applied is that each person sees the minimum necessary to do their job.
When a new protocol is introduced
The medical director introduces a pathway for a different case type, with four checks, different tests and a suspension rule for intercurrent events. Conventionally this is a project: analysis, development, testing, release.
Here it is the description of a new pathway in the same model: phases, deadlines, required tests, branching conditions. Screens, dashboards and automatic recalls know about it without anyone modifying them. Introducing a protocol stops being an IT project and goes back to being a clinical and organisational decision, which is where it belongs.
the comparison
What happens today, what happens afterwards.
Situations that repeat weekly in a healthcare provider.
Today
People hold the pathway together
Follow-up pathways live on sheets and staff members' personal diaries.
A missed check surfaces by chance, often months later.
Finding out where a patient stands means opening three different applications.
Whoever makes the recall call sees more clinical information than they need.
A new protocol requires an IT project before it can start.
Adherence indicators are produced by hand, late and with effort.
With Pwas
The pathway is an object the system governs
The pathway is data with state, deadlines and responsibility by role.
A missed attendance creates an assigned activity, with priority derived from the protocol.
Pathway state is one screen linking bookings, tests and outcomes where they reside.
Each role sees the minimum necessary: visibility is declared field by field.
A new protocol is the description of a new pathway, not a development project.
Adherence indicators are readable in real time, by pathway and by site.
how you get there
The path, concretely.
Without replacing clinical systems and without asking staff to enter data twice.
01
We start from one protocol and those who apply it
Medical leadership and operational staff describe a real pathway, exceptions included. The exceptions determine whether the system will be used or worked around.
02
We formalise the pathway
Phases, deadlines, required tests, responsibility by role, branching and suspension conditions. The description is readable by clinical staff, who validate it before anything gets built.
03
We define who sees what
A dedicated step, because in healthcare it's the most delicate. We declare field by field which information each role can reach, applying the minimum-necessary principle, and document the choice for the record of processing activities.
04
We connect existing systems
Bookings, laboratory and imaging stay where they are. Pwas reads from them what the pathway needs through available interfaces, avoiding duplication of clinical data and double entry.
05
One pathway live, then the others
One pathway goes into use at one site, we observe and correct. Then we extend: the other protocols are repetitions of a validated pattern, and can be described by trained internal staff.
an example flow
A pathway that remembers its own steps.
Appointments and prerequisites come from the protocol, reminders go out on time and results are filed against the pathway.
what changes structurally
Properties of the system, not clinical promises.
Operating characteristics verifiable in a demonstration. No claims about clinical outcomes or results obtained at other providers.
by role
data visibility, field by field
Whoever accesses sees the minimum necessary for their task: the rule is declared in the model and holds in every screen, dashboard and automated flow.
1
object holding the pathway together
Bookings, tests and reports stay in their own systems; the pathway links them without duplicating clinical data.
100%
of accesses and changes traced
Every read and every write retains author, moment and context — a necessary condition for audits and for incident handling.
on-premise
installation inside your own perimeter
The system can run entirely in your infrastructure, as a deployment mode and not a reduced version of the product.
Pwas is an application platform for organisational and document support. It is not a medical device, provides no diagnostic or therapeutic functions and does not replace clinical judgement. Every healthcare project requires a specific assessment of the regulatory requirements applicable to the provider and the processing.
in depth
The questions medical directors and IT leads ask us.
"Do we have to replace the clinical record or the booking system?"
No. In healthcare, clinical systems carry their own requirements, certifications and liabilities, and replacing them is an entirely different kind of project from the one discussed here.
Pwas covers the layer that in most providers has no owner: the pathway and the coordination between systems. It knows that this patient is inside a protocol, knows which steps are due and when, knows the report exists and where — but the report stays in the system that produces and retains it, and the record stays the record.
This has an important practical effect too: it reduces the project's surface area and therefore its risk. Nothing that currently works, with compliance already verified, is put in question; what gets added is what today is entrusted to sheets and phone calls.
"Our number one concern is sensitive data. How do you handle it?"
With three structural choices, all verifiable in the system's description and none left to the goodwill of whoever uses it.
Declared minimisation. Which data exists in the model, who can see it and at what level of detail is written explicitly, field by field and role by role. Whoever handles recalls doesn't see outcomes; whoever handles administration doesn't see reports. This isn't a screen setting: it's a rule of the data, holding in automated interfaces as well.
No needless duplication. Clinical data stays in the system entitled to hold it. The pathway references rather than copies it, which reduces both the risk and the number of places to protect.
Access traceability. Every read and every write leaves a reconstructable trace, which is what's needed when you have to establish who saw what and when — in an audit or in handling an incident.
This assists the provider's obligations as data controller — record of processing, impact assessment, technical measures — but doesn't replace them. They are and remain the provider's responsibility; we act as processor under the appropriate agreements.
"Staff are already overloaded. We won't add another system to fill in."
Correct, and it would be the fastest way to sink the project. The constraint we set ourselves is that the system must ask staff for less than the current manual method, not more.
Concretely that means three things. First: the pathway isn't filled in, it's inferred. If the booking exists in the booking system and the test exists in the laboratory system, the pathway reads them from there — nobody re-enters them. Second: staff receive activities, not generic reminders. Not "check the follow-ups", but "patient X missed the scheduled check, reschedule by". Third: screens show that pathway's fields and nothing else, not a generic form with forty entries of which thirty-five are irrelevant.
The result you observe when it works is that time spent coordinating goes down — not that more is added to feed a system.
"AI in healthcare worries us. Where do you use it and where don't you?"
We don't use it, and it shouldn't be used, for anything resembling clinical decision support: that's a field with its own regulatory requirements and it isn't what this platform does. Pwas is not a medical device and produces no clinical assessments.
Where it is useful and safe is in the document and organisational work that currently consumes clinical professionals' time. Reading inbound documents: a referral, a request or an external report arriving as a PDF is read and its organisational data proposed pre-filled, for a person to verify. Searching the document estate: retrieving documents and precedents with a natural-language question. Preparing communications: draft appointment letters, recall letters and reminders, compiled from the pathway's organisational data.
The structural guarantee is the same as in every industry, and here it matters more than anywhere: the agent cannot perform actions that aren't declared as possible for the user who asked. It builds a plan, the plan is verified against real permissions, sensitive actions require explicit confirmation and everything stays traced. An agent doesn't modify clinical data, doesn't close a pathway and doesn't communicate anything to a patient on its own initiative.
quick check
Is this your organisation?
Probably yes
You run pathways or protocols crossing several services, coordinated today by people.
You don't know in real time how many patients are outside their window on a pathway.
You have several vertical applications that work but don't connect.
You must produce adherence or activity indicators and today you build them by hand.
You need to limit, verifiably, who can see which information.
You have constraints requiring installation inside your own perimeter.
Probably not
You're looking for an electronic health record or a diagnostic system.
You need a medical device or a clinical decision support tool.
Your pathways are already well governed by an existing vertical application.
No clinical staff are available to help formalise the protocols.
frequently asked
Healthcare: the specific questions.
Is Pwas a medical device?
No. Pwas is an application platform for organisational and document support: it manages pathways, activities, deadlines, permissions and documents. It provides no diagnostic or therapeutic functions, produces no clinical assessments and is not intended for medical purposes under medical device regulation. If a project required functions of that nature, a different regulatory route applies and must be assessed before starting.
Does it integrate with the healthcare systems we use?
It integrates with systems that expose data exchange interfaces, following the interoperability standards in use at the provider. The approach is always the same: clinical systems remain the owners of their data, Pwas references it to build the pathway rather than duplicating it. Feasibility and integration scope are verified case by case with the suppliers involved, because they depend on what those systems expose.
Where does the data reside?
Where you decide: in your own infrastructure, on European cloud or in a mixed setup. For healthcare providers, installation within their own perimeter is the most frequent choice and is a full deployment mode, not a reduced version. The choice stays reversible and is documented in the project.
How do you handle consent and minimisation?
Visibility is declared in the model, field by field and role by role, so that the minimum-necessary principle is enforced by the system rather than by operator discipline. Purposes and lawful bases remain determined by the provider as controller; the declarative configuration makes them easier to document in the record of processing activities and the impact assessment, which remain your obligations.
How long to the first pathway in operation?
For a single, well-defined pathway the order of magnitude is a few weeks from the agreed formalisation, plus the time needed for connections to existing systems, which depends on their willingness and ability to exchange data. Later pathways take considerably less, because they repeat a validated pattern.
Who maintains it afterwards?
Ordinary changes — adding a phase, changing a deadline, describing a new protocol — are within reach of trained internal staff, typically from IT or medical management with reasonable IT confidence, because the configuration is a readable structured document. Deeper work, such as a new integration, needs a technical profile: yours, a partner's or ours.
We use technical cookies and, with your consent, analytics cookies (Google Analytics) to understand how the site is used. Read our Privacy & Cookie Policy.