Capability Register
This is the list we would want to read if we were buying. Every capability in Maree-CareFlow is marked real, partly real, simulated, or planned, and where something is not fully real the row says what is missing rather than leaving you to find out after you have moved your practice across.
It is generated from one file in the source tree and checked on every build against the running application: a row cannot claim an interface the software does not serve, and a limitation we have written down internally cannot be missing from this page. That is the only reason a page like this is worth anything.
Two words we use precisely. "Simulated" means the screen, the data and the records are real, and the connection to the outside party is not made yet - usually because it needs credentials that only your practice can obtain. "Unavailable" means the payer or regulator publishes no interface to submit to, so no setting and no future release of ours can turn it on.
Real 17
Built, shipped, and exercised by an automated test against a real database.
| Capability | What it does |
|---|---|
| Browser push notifications | Notifications are delivered to a browser or the app shell's web view over the W3C Web Push standard, signed with this install's own VAPID key, so no account with Google or Apple is needed. A subscription the push service reports as gone is removed automatically. This is the delivery path the product actually uses for push today. |
| Calendar and appointments | Appointments, recurring series, cancellations with a reason, completion, and a one-way calendar feed staff can subscribe to. |
| Care plans | Care plans written, shared with the people who need them, and visible to the participant in their own portal. |
| Clinical notes | Progress notes per participant, locked once signed, with an import path for notes brought across from another system. |
| Compliance checks and the practice standards | Rules evaluated against your own data, a history of every check, and a digest that tells the right person what is falling due. |
| Custom report builder | Saved queries over a fixed set of safe datasets, run on demand and exported, without anybody writing SQL. |
| Data import from another system | Bring a practice across from a competitor's export: preview every record, commit, sign off, and roll the whole job back if it is wrong. |
| Outcome measures | Standardised measures recorded against a participant over time, so progress is evidence rather than recollection. |
| Participant portal | Participants activate an invited account, see their appointments, funding, agreements and care plans, and request a booking - which staff approve by choosing the time, at which point the appointment is actually created. |
| Participant records | Participants, contacts, funding details and alerts, with the sensitive identifiers encrypted at rest and every practice's rows walled off in the database itself. |
| Payroll export and the SCHADS pay preview | A fortnight of shifts interpreted against the SCHADS Award line by line, with the clause on each line, and payroll files for Xero and MYOB. |
| Plan management | Plans, budgets, an invoice inbox, participant statements, payment runs with an ABA file, and reconciliation against the bank. |
| Report template library | Thirty seeded report templates plus your own, with merge fields answered from the participant's record, and a rendered template becomes an editable report draft that goes through the same approval and export as any other. |
| Restrictive practice authorisations | Authorisations recorded per participant, with the register acting as the gate: a behaviour support plan cannot name a restrictive practice that has no current authorisation. |
| Support worker roster | A week of shifts with overtime and rest-break warnings, published to workers by SMS, priced under the Award, and now aware of staff leave: a shift on somebody's leave day is flagged and listed as needing cover. |
| Travel and day trips | Travel recorded, capped to the funding rules, approved, and turned into an invoice line - the step that used to be calculated and then claimed by nothing. |
| Work delivered but never billed | The appointments that finished, had a participant, and never became a billable entry - found by the anti-join the product never had, and billable from the diary in one step. |
Partly real 20
Genuinely works, with a named boundary. What is missing is stated on the row.
| Capability | What it does | What is missing |
|---|---|---|
| Accessibility | Every page the product declares - staff, participant, case manager and public - is opened in a real browser at desktop and phone widths on every build, and the build fails on a serious or critical accessibility violation, on sideways scrolling, or on a page with no title. | Nineteen grouped form captions still need a proper fieldset and legend, the focus trap is not yet on every dialog, PDFs are not tagged for screen readers, and no human specialist has audited the product with assistive technology. |
| Accounting sync | Invoices and payments sync to Xero, QuickBooks Online and MYOB over each vendor's real OAuth flow, with the connection state shown per practice. | Reckon, Sage and WIISE are not supported. With no MYOB client credentials configured the MYOB path answers from a mock company file instead of contacting MYOB, and says so on screen. |
| AI report drafting | Where your practice has a model configured, a draft report is generated from the participant's own records, and a practitioner must read, edit and attest it before it can be exported. | You supply the model - there is no AI included and nothing is sent to a third party without your configuration. With no model reachable the draft comes back as a structured skeleton for the practitioner to complete, and behaviour support plans are refused outright. |
| AI summary of a participant's note history | Where your practice has a model configured, the notes your clinicians have already written about a participant are summarised into what is being worked on, what has changed and what is unresolved - so somebody picking up a participant after a colleague's leave does not have to read forty entries to find the thread. It refuses unless that participant's AI consent is recorded. | You supply the model. With no model reachable NOTHING is produced: the answer says plainly that no summary was made, because a paragraph written without a model would be an invention about a real person's clinical record. It is a reading aid, not a report - there is no approval, no attestation and no export, and the notes themselves remain the record. |
| Audit log | Every change to a record is written to an audit log that the database itself refuses to let anybody edit or delete, and administrators can read it on screen. READS ARE RECORDED TOO: opening a participant's file, their clinical notes, their documents, their billing or an export is logged with who, what and when - across 48 groups of routes that disclose participant or clinical information. Looking at the audit log is itself logged. The row never stores the content that was returned, so the log does not become a second copy of the information it describes. | Routine reads that disclose nothing about a participant - dashboards, settings, price lookups - are deliberately not logged, so this is a record of sensitive access rather than of every request. The log is immutable rather than hash-chained, so it is not tamper-evident in the cryptographic sense: the database refuses edits and deletes, but the rows carry no chain of hashes that would let you prove that for yourself. |
| Bank feed reconciliation | Bank lines are imported from CSV, or pulled through Basiq where your practice has an account, and matched against expected payments. | There is no direct bank connection of our own. Matching suggests; a person confirms. |
| Behaviour support plans | A ten-section plan, versioned, frozen and hash-stamped when the specialist attests it, with every restrictive practice requiring an authorisation from the register before it can be named. | Nothing lodges a plan with the NDIS Commission. There is no interface to lodge to; plans are exported and lodged by your practice, and a test keeps the product from pretending otherwise. WRITING a plan is a paid add-on ($39/month, included on Enterprise); READING, listing and exporting a plan you have already written are never gated, because a behaviour support plan is a document a provider is required to hold and a lapsed add-on must not make it unopenable. |
| Complaints and feedback | A complaint can be raised by staff, on the practice's public page, from inside the participant portal, or from inside the external case-manager portal. Its acknowledgement and resolution clocks are tracked. An anonymous complaint records no participant record, no account, no name, no email and no phone - nothing that identifies who lodged it - and the audit trail records that a complaint was lodged without recording who lodged it, including no IP address. Once lodged, the database itself refuses to let anybody change the words, the date, the practice or the anonymity of it, or to delete it; only the handling can move. Notes on a complaint cannot be edited or deleted at all. | The two in-portal front doors are off until a practice switches them on. Nothing is lodged with the NDIS Commission for you - escalation is recorded here and sent by a person. A superuser on your own database could still remove the protection, which is inherent to PostgreSQL. And anonymity is a guarantee about what is stored with the complaint, not a guarantee that no correlation is possible: somebody with full database access who can see that a participant was signed in at the same minute could still draw an inference, which no product-side control can prevent. |
| Exports, evidence packs and backup | A participant's whole file, an audit evidence pack, or an encrypted backup of everything, produced as a job you can download. | Backups are yours to keep and to test. The product takes them and proves in its own build that an encrypted backup restores and decrypts, but where the file goes and how long you keep it is your practice's decision. |
| Hosting and installation | Install on Docker, on a bare Ubuntu server, or on cPanel shared hosting with no root access at all. Three of those are installed for real in our build pipeline whenever that surface changes - on a clean machine, through the same script you run, with the upgrade re-run included: Docker (also from the published package, into an empty directory), the Ubuntu server (the runner's own PostgreSQL is purged first, so the installer must provision its own), and cPanel with no root, through the real browser wizard against real PHP and a real database. | The root-level WHM installer for cPanel resellers needs a real WHM host, which our build pipeline cannot provide, so it is reviewed rather than executed; the same is true of two optional cPanel terminal helpers. There is no multi-region deployment, no automatic scaling and no content delivery network. The Kubernetes chart is usable but thinner than the other two paths. |
| NDIA PACE system | Claims for NDIA-managed participants go out as the bulk payment request file described above, which the agency accepts today. | The NDIA publishes no interface for a practice management system to submit to, so no setting and no future release of ours can make direct submission live - for us or for anyone. The code that once simulated it has been deleted rather than left to look like an integration. |
| NDIS claiming | Time entries become invoices and invoice batches, and a batch becomes the NDIS bulk payment request file plus a CSV you upload to the portal. A rejected batch records the funder's reason, who recorded it and when. | The file is uploaded by a person. There is no machine interface to the NDIA that we can submit through, so nothing is transmitted from inside the product. |
| NDIS price catalogue | Support items and price limits are held in the database and checked when a line is billed, so an item that is not in the catalogue cannot be claimed by accident. | Refreshing the catalogue when the NDIS price guide changes needs a feed URL your operator supplies; the product does not fetch it from the NDIA by itself. |
| Practitioner credentials and expiry | Registrations, insurances and checks are recorded with their expiry dates, reminders are sent before they lapse, and an expired credential blocks billing for that practitioner. | The dates are entered and attested by your practice from the register itself. The product makes no request to the Ahpra register - there is no lawful public interface for that - so it cannot verify a registration for you. |
| Public booking page and intake | A member of the public requests an appointment from your website and fills in an intake form; the request lands in a staff inbox to confirm or decline with a reason. | A booking is a request, not a self-service confirmation: nothing is committed to the diary until your practice says yes. |
| Session transcription | An uploaded recording is transcribed and turned into a draft note, behind an explicit consent record for the participant. | One provider only (AssemblyAI), with your own key, and consent must be on file before anything is uploaded. |
| Single sign-on | OpenID Connect single sign-on for staff, with a break-glass local login so a broken identity provider cannot lock your practice out. | OIDC only: no SAML, no SCIM provisioning, no automatic de-provisioning, no group-to-role mapping and no single log-out. |
| Telehealth | A video consultation runs from the appointment itself. Jitsi is the built-in default - no third-party account and nothing for the practice to buy - and the room name is 96 bits of randomness generated once and stored on the appointment, never derived from any record id, so knowing an appointment id does not let anybody into a consultation. Beside the video there are session guides from the template library, a timer against the booked end, and quick notes that are written into a DRAFT CLINICAL NOTE for the participant through the ordinary note endpoints - the same encrypted column and the same finalise rules, not a side-store. Ending the session writes a structured handover and pre-fills the telehealth clinical-appropriateness form from the cue cards that were ticked. A practice that already pays for Coviu can use its own room instead. | Coviu is a LINK-OUT, not an integration: Coviu publishes no public API usable without a partner agreement, so the practice pastes its own room URL and the appointment carries it. There is no Zoom, Teams or Meet integration, and Maree-CareFlow makes no recording of any session. |
| White labelling | Your name, logo and three palette colours applied through the product and its documents. | A custom domain is recorded but not served for you, and several surfaces - some emails and generated files - still carry our name. |
| Workflow engine | Definitions with dated steps, assignees and escalations, instanced against a participant and driven by a real scheduler - including an eight-week plan timeline anchored to a date. Included on every paid plan at no extra charge: there is no workflow add-on to buy. | Not available on the Free plan. Five older compliance clocks still run as hand-written schedules rather than as workflow definitions, notifications are by email, and working days are Monday to Friday in the install's own timezone. There is no Zapier or Make app and no public REST API for your own automations. |
Simulated 6
The screen and the data are real; the outside connection is not made yet.
| Capability | What it does | What is missing |
|---|---|---|
| Electronic signing of service agreements | A service agreement is prepared, sent for signature, tracked and filed against the participant. | Without DocuSign credentials the envelope and signing link are local stand-ins for development, clearly marked as such, and no document reaches a signer. |
| Healthcare Identifiers (IHI lookup) | An IHI lookup is built against the Healthcare Identifiers Service, with the result recorded against the participant. | It needs your practice's NASH certificate and service URL. Until both are present the lookup returns a result marked as unverified and says the path is a mock; half-configured is refused rather than faked. |
| Medicare and HICAPS claiming | Claim assembly, item validation and a funding-balance estimate are built, and the Admin screen reports exactly which credentials are missing. | Lodgement is not implemented: there is no terminal or PRODA transport, so nothing is submitted. The balance shown is our own estimate from your records, not an answer from Medicare. |
| My Health Record upload | A clinical document can be prepared and sent to My Health Record, with the attempt recorded. | Without the conformance credentials no document leaves the install; the attempt is logged as a mock so nobody believes a record was uploaded. |
| Native push notifications to a phone | A phone running the app shell can register its operating-system push token and the registration is stored against the user, walled by practice. | Nothing delivers a NATIVE push: there is no Firebase or Apple transport wired up, so the send function counts the stored tokens, delivers zero and says so rather than implying a phone was reached. This row is about NATIVE push only - browser push notifications are a separate, working capability (see "Browser push notifications"), and email and SMS also work. |
| Single Touch Payroll Phase 2 | Pay events are assembled, validated and recorded in the shape the ATO's SBR service expects, with a submission history per practice. | Without your practice's ATO credentials the submission is recorded as pending rather than sent - the mode is reported as a mock on the Admin screen, never as lodged. Lodging for real also needs the ATO's own software provider onboarding, which is your practice's to obtain. |
Planned 7
Not built. Listed so nobody has to guess whether it is.
| Capability | What it does | What is missing |
|---|---|---|
| Business intelligence connector | Reporting is done inside the product and by export. | There is no Power BI or Tableau connector, no streaming data feed, no benchmarking against other practices and no predictive analytics. |
| Certifications and independent assurance | The product is built to the controls described in our compliance documentation, and those controls are gated by automated tests. | Maree-CareFlow holds no ISO 27001, SOC 2 or IRAP certification, no third-party penetration test has been commissioned, and no accessibility specialist has audited it with assistive technology. There is no web application firewall and no data loss prevention product in front of it. |
| Live location and route optimisation | Visits are recorded with their times, and a lone-worker check-in is available for home visits. | There is no live GPS tracking of staff, no minute-by-minute location without a native app, and no multi-stop route optimisation. |
| Medication management | A medication RISK can be recorded on a risk assessment and a medication ERROR can be recorded as an incident, with the same follow-up clock as any other incident. Medication can be written about in a clinical note or an intake form as free text. | There is no medication administration record, no chart, no PRN log, no schedule, no interaction or allergy checking, no webster-pack workflow, no prescribing and no connection to a dispensary. A provider delivering high-intensity daily personal activities will be asked for an administration record at registration, and this product does not hold it - it must be held in a system that does. This row was absent from the register and from the dossier's limitations chapter until 2026-09-23, when an internal cross-check found it; an undisclosed gap is the thing that makes an assessor discount everything else. |
| Native mobile app | The product is a web application and works on a phone: the whole interface is checked at 390 pixels wide on every build. | There is no iOS or Android app in a store, no offline note-taking, no biometric unlock and no native camera capture. |
| Outside Australia | Maree-CareFlow is built for Australian practice: NDIS, Medicare, the SCHADS Award, Australian privacy law and Australian dates and currency. | There is no New Zealand or other jurisdiction support, no second currency, no translation, and no GDPR tooling. |
| Worker training, induction and CPD register | The product tracks a practitioner's CREDENTIALS and their expiry dates - AHPRA registration with a recorded register-check attestation, NDIS worker screening, working-with-children check, police check, first aid, CPR, professional indemnity and public liability - and blocks billing on several of them once they lapse. | There is no record of what a worker was TRAINED in, when they were inducted, what competency was assessed, or what continuing professional development they have completed. No training, induction, competency or CPD table exists in the data model at all. An NDIS human-resource-management assessment and an AHPRA registrant's CPD obligation both ask for that record, and the practice must hold it in another system. Credentials are not competence; this product holds only the first. Disclosed 2026-09-23 after an internal cross-check found the absence stated nowhere. |
## What this register does not do
It does not certify anything. Maree-CareFlow is not ISO 27001, SOC 2 or IRAP certified, no third-party penetration test has been commissioned, and no accessibility specialist has audited the product with assistive technology. Those are named here because a register that lists only software would be quietly flattering itself.
## If a row is wrong
Tell us and we will correct it in the same release. We also keep a longer and more specific internal limitations document; if you are evaluating the product seriously, ask us for it and we will send it.
All features · FAQ · Home