Healthcare SaaS·Australia
clinicOS
Staff operations for Australian GP practices
Australian general practices were running operations across spreadsheets, group chats and email. Fluid Web deployed an eight-person team to build clinicOS — rostering, internal communications, AI document intake and invoicing — now in use across seven practices with mobile apps live on both stores.
What we walked into
General practices run on a surprising amount of informal infrastructure. Rosters live in spreadsheets, announcements happen in group chats, correspondence arrives by email and invoicing sits in a separate system entirely — with staff acting as the integration layer between all of them.
The operator behind clinicOS runs practices directly, so the product is built from the inside rather than from market research. Fluid Web deployed a team of eight in March to build it.
The problem
Healthcare makes the obvious shortcut unavailable. Practices were losing hours every week to administrative glue, and the fastest fix — pasting patient correspondence into a general-purpose AI tool — is exactly the thing a medical practice cannot responsibly do.
So the product had to deliver the time savings people wanted from AI while keeping data inside a controlled environment and keeping a human in front of anything that gets filed to a record.
One practice directory underneath every module
Rostering, communications, document intake and invoicing all resolve against a single practice directory with role-based access. That sounds obvious and it is the thing most practice software gets wrong — separate modules with separate user lists is how staff end up maintaining the same information four times.
Because roles are defined once, a practice manager, a nurse and a receptionist see appropriately different products without anyone maintaining three configurations.
- Single staff directory shared across every module
- Role-based access so practices stay audit-ready
- Multi-tenant isolation between practices at the data layer
- Consistent permissions across web and mobile clients
AI intake with a human in front of the record
Document intake is where the time savings are. Incoming correspondence gets read, classified and structured automatically, which removes the manual sorting that consumes administrative hours every week.
What it does not do is file anything unreviewed. Extracted output goes to a person before it reaches a record, with the source document alongside it so verification takes seconds. In healthcare the review step is not a limitation of the technology — it is the design.
- Automated classification and extraction of incoming correspondence
- Human review before anything is filed to a record
- Source document retained alongside extracted values for verification
- Data kept within a controlled environment rather than pasted into consumer tools
Mobile because practice staff are not at a desk
Clinical and reception staff spend their day moving. A rostering and communications product that only exists on a desktop gets used at the start and end of a shift and ignored in between, which is precisely when it would be useful.
Mobile applications are live on both iOS and Android, built in parallel with the web product against the same permission model rather than trailing it.
Australian data posture from the start
Hosting and data residency were settled early rather than discovered during a customer's security review. For Australian healthcare, that is a prerequisite to the first serious conversation, not a compliance task to schedule later.
The hard parts
AI in a setting that cannot tolerate silent errors
A wrong extraction that reaches a patient record is a materially different category of failure from a wrong extraction in most products. Confidence thresholds and review queues had to be designed before the feature shipped, not tuned after complaints.
Modules that would rather be separate products
Rostering, messaging, intake and invoicing have little in common functionally. Keeping them coherent under one directory and one permission model takes deliberate restraint against letting each grow its own concepts.
Web and mobile parity from day one
Shipping both surfaces simultaneously with a team of eight means the API contract has to be right early, because divergence between clients is far more expensive to unwind than to prevent.
How it ran
Team deployed
Eight Fluid Web engineers embedded from around March, covering web, mobile, AI and the marketing site.
Core modules
Rostering, internal communications, document intake and invoicing built against a shared practice directory.
Mobile launch
Applications shipped to both the iOS App Store and Google Play.
Early access
Seven practices now using the platform, with development continuing.
Results
clinicOS is in early access with seven Australian practices, replacing an assortment of spreadsheets, group chats and separate invoicing with a single staff workspace.
Mobile applications are live on both iOS and Android, built in parallel with the web product rather than behind it.
AI document intake is in production with human review before anything reaches a record — the time savings practices wanted from AI, without the data posture they could not accept.
Built with
Scope of our work
Fluid Web delivers engineering across web, mobile, AI and the marketing site. Clinical workflow decisions come from the practice operators behind the product. We do not name the client here given the healthcare context.
Got something similar?
Tell us where delivery is stuck. We will give you an honest read on scope and shape before anyone talks contracts.
Book a technical review
