rtware
Practice software for UK dental clinics, starting with endodontics. Web first, then iPhone and iPad. This blueprint separates what the product does from how it gets built.
What the product does, who it serves, and the policies it follows.
Overview
Who the product is for and the principles behind it.
UK dental clinics. The first customers are specialist endodontic practices and general practices that do endodontics. One organization can run several clinics.
- Endodontists and dentists
- Dental nurses
- Reception and treatment coordinators
- Practice managers and owners
- Referring dentists, outside the practice
- Desktop web for desk work
- Mobile web for quick lookups and patient pages
- iPad and iPhone for chairside work, after the web launch
Everything clinical hangs off a tooth on the chart and an item on a treatment plan. Specialist modules such as endodontics add depth where a practice needs it.
Specialist practices receive referrals and send reports with X-rays. General practices refer out and track what came back. Most dental software handles this badly.
GDC numbers, Palmer notation, UK hosting, and a design that's ready for NHS work later.
Consistent across web and iOS, accessible, and tested with real clinical teams.
Reminders, forms, reports, recalls and chasing run on their own. People stay in charge of clinical content.
Clinical workflow
The general dental journey the product is built around, with specialist modules on top. Pick a tooth on the example chart to see its entries.
- 01RegistrationNew patients book and complete their medical history before the visit.
- 02ExaminationCharting, gum screening, X-rays and diagnosis.
- 03Treatment planItems per tooth from the price list, with an estimate and consent to sign.
- 04TreatmentVisits with clinical notes, completed items and lab work.
- 05PaymentInvoices per visit, by card or direct debit.
- 06RecallExams and hygiene visits at each patient's interval.
Endodontics First module
Referrals in, endo cases with canal records, reports back to the referrer, and reviews at 6 and 12 months.
Periodontics Next
Full six-point charting when gum screening finds a code 3 or 4. The screening itself is in the core.
Implants, orthodontics Later
Built on the same chart, plan and imaging when there's demand.
Dental chart
Example patient. Each mark is a chart entry with surfaces and a state: existing, planned or completed. UK clinicians mostly read Palmer notation, so it's the default display. Storage is always FDI, and primary teeth show with Palmer letters A to E.
Gum screening (BPE)
Recorded at every exam: a code from 0 to 4 for each sixth of the mouth, with * for furcation. A 3 or 4 leads to more detailed charting in the periodontics module.
Endo module: canal record for tooth 36
| Canal | Working length | Reference | Master file |
|---|---|---|---|
MB | 20.5 mm | MB cusp | 25/.06 |
ML | 20.0 mm | ML cusp | 25/.06 |
D | 21.5 mm | DB cusp | 35/.04 |
Example values for a lower first molar. Each canal is recorded with its working length, reference point, master apical file and obturation technique. The referral report is drafted from these fields.
Name and brand
The product is called Rootware. In the wordmark, the two letters o are drawn as canal openings. A single opening is the app icon: a root seen in cross-section, with its canal filled.
App icon and favicon. Two rings side by side read as a face in a square, and get too thin at 16px.
Keep one ring's height clear on every side of the wordmark.
96 px wide on screen. 20 mm in print, where it switches to one colour.
The symbol is for app icons, favicons and avatars. It never sits next to the wordmark.
Outfit appears only in the wordmark. Both it and the interface face are under the open font licence.
The final wordmark is redrawn as outlines, not live text, before it ships anywhere.
rootware.comhas been registered since 2003 and is active.getrootware.comwas registered in May 2026.rootwarehq.comanduserootware.comwere free when checked on 22 Oct 2026.rootware.co.ukcouldn't be checked automatically. Look it up at a registrar.- A company called Rootware Technologies Global exists. Search the UK trade mark register in classes 9 and 42, which cover software, before filing.
With the exact .com free when checked: Mesiora, Chairtide, Periapix, Endodesk, Cuspvale and Molarsmith. Strong but on a prefixed domain: Open Wide.
All four logo directions and the refined wordmarkUsers and roles
Who can do what in a practice. Permissions are fixed in the product. Roles are bundles of permissions that each practice can adjust. Pick a role to see what it allows.
| Role | Patient details | Clinical notes | Sign notes | Imaging | Appointments | Referrals | Billing | Staff and roles | Audit log | Data export |
|---|---|---|---|---|---|---|---|---|---|---|
| Endodontist or dentistTreating clinician, GDC registered | Edit | Edit | Own | Edit | Edit | Edit | View | – | – | – |
| Hygienist or therapistTreats within their scope, GDC registered | Edit | Edit | Own | Edit | Edit | View | View | – | – | – |
| Dental nurseCharts chairside, takes radiographs | Edit | Draft | – | Edit | View | View | – | – | – | – |
| ReceptionistFront desk and treatment coordination | Edit | Alerts | – | – | Edit | Edit | Edit | – | – | – |
| Practice managerRuns the practice day to day | Edit | – | – | – | Edit | Edit | Edit | Edit | View | – |
| Owner or adminAccount owner, subscription | Edit | – | – | – | Edit | Edit | Edit | Edit | View | Edit |
| Referring dentistExternal portal, later release | – | – | – | Own | – | Own | – | – | – | – |
An owner who also treats patients holds both Owner and Endodontist. Permissions are the union of their roles.
The practice owner, or your team from the backoffice, copies the defaults and edits them.
Nurses draft. Only the treating clinician signs, and nobody signs while support is acting as them.
Automations
Built-in automations that take repetitive work off reception and clinicians. Each one can be switched on or off per clinic, with its own timing and wording.
Referrals 4
- Online referral formReferrers send tooth, reason and X-rays. It creates the referral and a draft patient, and acknowledges receipt.
- Missing informationNo radiograph attached sends an automatic request back to the referrer.
- Triage deadlineReferrals not reviewed within 2 working days are flagged.
- Report drafts Start hereWhen a case is obturated, the report is built from canals, lengths, materials and X-rays. The endodontist reviews and sends it.
Before the visit 5
- Self-bookingAccepted referrals get a link showing slots where the chair and microscope are both free.
- Reminders Start here48 hours ahead, with confirm and cancel links. No reply after 24 hours creates a task for reception.
- Pre-visit forms Start hereMedical history and consent go out for remote signing. A change such as a new anticoagulant flags the clinician.
- DepositsPayment links for long appointments.
- Cancellation fillA freed slot goes to the waiting list by SMS. The first to accept books it.
Treatment day 5
- Note templatesPrefilled notes per procedure, such as an exam, a filling or RCT visit 1, for the clinician to edit and sign.
- Lab work trackingLab cases not back two days before the fit appointment are flagged to reception.
- Image matchingIncoming scans are matched to patients by their DICOM tags. Unmatched ones go to a review queue.
- X-ray evaluationsIR(ME)R requires a recorded clinical evaluation for every exposure, so images without one prompt the clinician.
- Post-op careInstructions after each visit, and a check-in the next day. A severe pain reply creates an urgent task.
After treatment 3
- Restoration reminderThe patient and referrer are reminded to complete the crown or onlay, and completion is tracked.
- Recalls Start hereExams and hygiene at each patient's interval, and endo reviews at 6 and 12 months, with booking invites and no-show follow-up.
- Outcome to referrerRecall results go back to the referring dentist.
Billing 3
- EstimatesGenerated from the treatment plan and price list, then sent for signing. Acceptance turns the estimate into the plan.
- Invoices and chasing Start hereIssued at the end of each visit with a payment link, followed by a polite overdue sequence.
- ReconciliationStripe and GoCardless payouts are matched to invoices and exported to Xero.
Running the practice 5
- Morning digestToday's patients, medical alerts, unsigned consents, missing X-rays and balances due.
- Unsigned notesA nudge at the end of the day, escalated to the manager after 48 hours.
- Expiry remindersStaff GDC registration, indemnity and CPD, plus equipment servicing and X-ray testing.
- Subject access requestsOne-click export with a tracked deadline.
- Retention reviewsRecords past retention are queued for review, never deleted automatically.
Reports and anything clinical are drafted automatically and sent by a person.
Every message respects the patient's contact preferences and the clinic's quiet hours.
Fixed automations with per-clinic switches, timing and wording. A general rule builder can wait for a later version.
Document signing
Consent forms, estimates and questionnaires, signed remotely or in the surgery. Every signature ends as a sealed, tamper-evident PDF. Step through each flow.
A parent or guardian signs for under-16s unless the clinician judges the child Gillick competent.
The signature records consent. Clinicians still write up the consent discussion in the clinical notes.
Texts and emails name the practice only, because they show on lock screens.
A signed PDF never changes. Fixing it creates a new document and a new signature request.
Backoffice and support access
Your team's internal app for running the platform. It sets up practices, plans and roles, and lets support act as a practice user to help.
Organizations and clinics
Practice details, locations, time zones and contacts. The owner gets an invite to finish setup.
Plans
Choose a plan, set seats, trials and discounts, and override single features for one customer.
Roles
Copy the default roles into a practice and adjust them. Changes appear in the practice's audit log.
Users
Resend invites, reset 2FA after an identity check, and deactivate accounts.
Migrations
Start import batches and review dry-run reports.
Health
Storage used, active users, last activity, and failed messages or jobs.
Acting as a practice user
- 1The practice allows accessThe owner or manager grants support access, for one request or as a standing grant with an expiry date.
- 2An agent starts a sessionThey pick the user to act as and enter a reason and ticket number.
- 3A banner shows on every screenThe practice's admins are notified. Sessions last up to 30 minutes.
- 4Everything is loggedEach action records both identities, in your log and in the practice's own audit log.
- A real user, not root. The agent sees exactly what that user sees. A root account would expose every record, which is hard to justify under UK GDPR.
- A support account for setup. Each practice has a built-in support user with setup permissions and no clinical access.
- Clinical access needs permission. Opening patient records requires a grant with clinical scope.
- Blocked while acting. Signing, changing passwords or 2FA, exporting data, changing billing.
Subscription lifecycle
Practices never lose sight of their records for non-payment, because clinicians need them for patient care.
What a plan controls
Your team signs in with SSO and hardware security keys, from an IP allowlist, on its own subdomain.
Deleting an organization or running a bulk export needs a second team member to approve.
Design and experience
Experience is the priority. The aim is consistency, not sameness: the same brand, words, flows and states everywhere, while each platform still feels native.
Dense, multi-column screens for reception, managers and clinicians at their desks: calendar, referrals, billing, reports.
Quick lookups for staff on the move, and the patient pages for signing and self-booking.
Chairside work: Apple Pencil on X-rays, offline consent, large touch targets, native sheets and navigation.
Allergies and anticoagulants use one locked design on every platform, for patient safety.
The same words in every app, from a shared glossary.
WCAG 2.2 AA on the web, Dynamic Type and VoiceOver on iOS, and dark mode on both.
Observe a working endo practice before designing. Test with endodontists, nurses and receptionists.
Track identical events on every platform, such as time to book a referral.
A feature ships everywhere it belongs, or is logged as web-only on purpose.
Glossary
- Surgery
- The treatment room. Used for chairs and rooms in the calendar.
- Obturation
- Filling the cleaned and shaped canals. Marks the end of active treatment.
- Working length
- The measured length of a canal, in millimetres, from a reference point.
- Recall
- A follow-up review, usually at 6 and 12 months.
- Referring dentist
- The general dentist who sent the patient and receives the report.
- Palmer notation
- UK tooth numbering by quadrant, such as LL6.
Switching from other systems
Practices won't switch without their patients, appointments, notes and X-rays. How hard that is depends on the system they're leaving.
Rough effort for one developer. Each bar is the likely range.
- Dentally is cloud-based with a proper API, but partner access is approved case by case. It shares an owner with Software of Excellence, so a competitor's request may be refused, leaving the practice's own export.
- Software of Excellence, Exact and R4 are widely installed, often on-premise. Their databases are undocumented and vary by version.
- Imaging software such as Romexis, Sidexis and CS Imaging exports CBCT as DICOM, but 2D X-rays often sit in proprietary formats. It's often the biggest job by volume.
- Service first. Run early migrations by hand with scripts. Productise only the sources the first 5 to 10 customers need.
- History stays read-only. Old canal details are buried in free text. Import history as it is, and start structured cases from go-live.
- Balances by cut-off date. Outstanding balances come across as opening balances, not historical invoices.
- Practices own their data. Their old supplier must return it, though the format may be a raw backup. You act as their processor during migration.
Compliance and NHS
What the law requires from launch, what NHS work would add, and where the company can sit.
Add a funding type to each treatment plan and keep claims in a separate module. If NHS work is within 12 to 18 months, bring in a Clinical Safety Officer early, because the clinical safety standard expects risk management across the whole lifecycle.
- Dental records are special-category health data under UK GDPR and the Data Protection Act 2018.
- Practices are the data controllers and you are the processor. Sign a data processing agreement with each one, and register with the ICO.
- Your team touches patient data only on a practice's instructions, so support access needs the practice's permission.
- Adult dental records are kept for 11 years under the NHS Records Management Code, and children's for longer.
- Personal data breaches must be reported to the ICO within 72 hours.
- Simple electronic signatures are valid for consent forms and estimates. The audit trail is what makes them hold up.
- Complete the Data Security and Protection Toolkit every year.
- Meet DCB0129 clinical safety: a named Clinical Safety Officer who is a UK-registered clinician, a risk management plan, a live hazard log and a safety case. The standard is under national review.
- NHS buyers assess you with DTAC, kept current for each product version. A shorter form applies from April 2026.
- Buyers commonly ask for Cyber Essentials Plus and a recent penetration test.
- In England, practices claim on FP17 forms sent through NHSBSA's WebEDI, which means getting on its supplier list.
- Scotland, Wales and Northern Ireland run separate claims systems.
- You don't need to be based in the UK. Host the data in a UK region.
- A non-UK business may need a UK GDPR representative. Get a short legal opinion.
- B2B software sold from Spain to UK practices is normally reverse-charged for VAT. Confirm with an accountant.
- A UK company helps with trust and NHS procurement. Set one up once there's traction, or before NHS work.
- EU data adequacy for the UK runs to December 2031, so a later EU expansion can share the platform.
- Diagnostic measurement tools on X-rays can make the viewer medical device software under MHRA rules. Check before building them.
- Automatic lesion detection on X-rays would bring the same medical device obligations.
Not legal or tax advice.
Product decisions
What's agreed, what's proposed and waiting for a yes, and what's still open.
Spain and the rest of the EU can follow on the same platform.
Endodontics is the first focus and stays a strength, but the product is for dental clinics broadly.
With the orifice wordmark and a single-ring symbol for app icons and favicons.
Native apps follow the web launch and share its API.
Endodontist or dentist, dental nurse, receptionist, practice manager, owner, and a referrer portal later.
Practices, plans, roles and support access, managed by your team.
Remote and in-surgery signing share one pipeline, the practice's roles and its audit log.
One design system for web and iOS, accessible by default.
Avoids the NHS toolkit, clinical safety case and claims work at launch.
Plus a built-in support account with no clinical access for setup work.
Reminders, pre-visit forms, report drafts, recalls and invoice chasing.
Productise only the sources early customers need.
Never a lockout, so clinicians can still see records.
Stored as FDI, with each user able to switch.
A general dental chart, gum screening and treatment plans in the core, with endodontics as the first specialist module and periodontics next.
They treat within their scope, record gum health and sign their own notes.
Open font licence, so it works on the web and inside the iOS apps. Outfit stays in the wordmark only.
Per clinician per month is likely. Decide the tiers and what each includes.
Ship the default roles only, or let practices copy and edit them from launch.
Ask the practice for each request, or allow standing grants with an expiry date.
Decide from the systems the first customers actually use.
Hire or contract one, ideally with healthcare experience, before the first screens.
Xero first, with QuickBooks later if customers ask.
Sell from the existing company at launch, or set up a UK company first.
rootware.com is taken. rootwarehq.com and userootware.com were free. Check rootware.co.uk and the UK trade mark register before buying.
Many UK private practices sell monthly plans that cover check-ups and hygiene, Denplan being the best known. Decide whether v1 runs them itself or integrates.
How the product is built: stack, architecture, data, security and tooling.
Stack
API first, so the web panel and the iOS apps use the same API from day one. Pick a technology to see why it's there.
Services
Only the gateway is reachable from the internet. Everything else runs on a private network in a UK region. Pick a flow to trace it.
The gateway checks with Symfony before it streams a study, so large image traffic skips PHP.
Orthanc keeps its index in its own PostgreSQL database and its files in object storage.
Both databases and object storage back up on one schedule, with point-in-time recovery.
Its database role can't read clinical tables. Patient data is reachable only through the clinic app.
Data model
The patient's chart and treatment plan sit at the centre, with endodontics as the first specialist module on top. The diagram shows the core relationships. The explorer below lists all 40 entities with their fields.
erDiagram
Patient ||--o{ ChartEntry : has
Patient ||--o{ MedicalHistory : completes
Patient ||--o{ TreatmentPlan : has
TreatmentPlan ||--|{ TreatmentItem : contains
Procedure ||--o{ TreatmentItem : prices
TreatmentItem |o--o{ ChartEntry : draws
Appointment |o--o{ TreatmentItem : books
Appointment ||--o| ClinicalNote : records
TreatmentItem |o--o| LabCase : needs
TreatmentItem |o--o| EndoCase : "specialist record"
EndoCase ||--|{ Canal : has
Referral |o--o{ EndoCase : opens
Patient ||--o{ Recall : "returns for"
Access control and impersonation
How permissions, plan entitlements and support sessions are enforced in Symfony. Every request passes these checks in order.
- 1FirewallAuthenticates the user. Support sessions carry the agent's ID on the security token.
- 2Operation securityAPI Platform checks
is_grantedon every operation. - 3VotersClinic membership, permission, ownership, plan entitlements and support-session blocks.
- 4Tenant scopeA Doctrine extension limits every query to the user's clinics. Postgres row-level security backs it up.
- 5Field visibilitySerialization groups per permission, so reception gets patients without clinical notes.
- 6AuditRecord views, role changes and support actions are written to the audit log.
Fixed in a PHP enum. Roles store lists of these codes.
patient.viewpatient.editalerts.viewclinical.viewclinical.draftclinical.editclinical.signimaging.viewimaging.editappointment.editreferral.editbilling.viewbilling.editstaff.manageaudit.viewdata.exportsubscription.manage
{
"user": { "name": "Dr Sam Ellis" },
"clinic": { "timeZone": "Europe/London" },
"permissions": ["patient.edit", "clinical.edit",
"clinical.sign", "imaging.edit"],
"entitlements": { "signing": true, "ipadApp": true },
"impersonation": null,
"preferences": { "toothNotation": "palmer" }
}Web and iOS hide what a user can't do. The API still checks everything.
final class ClinicalNoteVoter extends Voter
{
public function __construct(private AccessResolver $access) {}
protected function supports(string $attribute, mixed $subject): bool
{
return $subject instanceof ClinicalNote
&& Permission::tryFrom($attribute) !== null;
}
protected function voteOnAttribute(string $attribute, mixed $subject, TokenInterface $token): bool
{
$user = $token->getUser();
$clinic = $subject->getPatient()->getClinic();
if (!$user instanceof User || !$this->access->isMember($user, $clinic)) {
return false;
}
if ($attribute === Permission::ClinicalSign->value) {
if ($token->hasAttribute('impersonator_id')) {
return false; // support never signs
}
if ($subject->getClinician() !== $user) {
return false; // only the treating clinician signs
}
}
return $this->access->can($user, $clinic, Permission::from($attribute));
}
}Support sessions
- The backoffice runs on its own firewall with a
PlatformUserprovider, behind SSO and WebAuthn security keys. - It issues a signed token valid for 60 seconds, carrying the target user, clinic and grant. Its unique ID is stored as a hash so it works once.
- A custom authenticator on the clinic firewall accepts the token, loads the target user, and sets
impersonator_idandimpersonation_session_idon the security token. - Sessions expire after 30 minutes, and the backoffice can end them early.
- A voter denies signing, password and 2FA changes, exports and billing changes whenever
impersonator_idis set. - An audit listener writes both identities on every request.
Symfony's built-in switch_user only works within one firewall and user provider, which is why staff and practice users need this token handoff.
Plans and tenants
- A feature voter reads the plan's entitlements plus any per-customer overrides, so features outside the plan are blocked as well as hidden.
- Every tenant-owned table carries
tenant_id. The Doctrine extension and row-level security both enforce it. - The backoffice connects with a separate database role that can read platform tables and nothing clinical.
- Role and plan changes from the backoffice go to the platform audit log and the practice's audit log.
Imaging with Orthanc
Orthanc is an open-source DICOM server. It stores X-rays and CBCT scans and serves them to the viewer, while Symfony decides who can see them.
- PHP's DICOM libraries are thin and barely used.
- A REST API Symfony can call with plain HTTP.
- DICOMweb, which Cornerstone3D reads directly.
- DICOM's network protocol, so imaging devices can send scans to it.
- DICOMweb plugin for the viewer.
- PostgreSQL plugin for its index, in a separate database.
- Object storage plugin for files, in the UK region.
- Private network only. The gateway authorizes every request.
- Resumable uploads with the tus protocol for large CBCT studies on clinic broadband.
- Incoming studies matched to patients by DICOM tags, with a review queue.
- Backed up on the same schedule as the app data.
- GPL and AGPL licensed. Run it unmodified as a separate service and have a lawyer confirm.
A small app on the surgery PC that watches the imaging software's export folder or receives DICOM, then uploads securely. Nobody exports files by hand.
Automatic detection on X-rays would be a separate Python service, and would bring MHRA medical device obligations.
Signing pipeline
Built from open-source parts. The only outside services are an SMS provider and a timestamp authority.
- PAdES-B-LTA seals embed validation data and a timestamp, so signatures stay verifiable after certificates expire and across the 11-year retention period.
- Own CA at launch. It proves a PDF is unaltered, but Adobe Reader shows the signer as unknown. An in-app verification page covers that, and an Adobe-trusted certificate can replace it later with no other changes.
- Seal key in a KMS or HSM, never in an app container.
- Paid timestamp authority in production. FreeTSA is fine for development. Never run your own.
- The signing page runs on its own subdomain.
- Links carry a random single-use token, stored only as a hash. Each opens one request and nothing else.
- Requests expire after 7 days. Codes last 10 minutes, and Symfony RateLimiter locks a request after 5 failed attempts.
- Staff can cancel or resend. Every step is a
SignatureEventwith time, IP and device. - Offline iPad signatures keep device time, and the seal adds server time on sync.
Custom build Chosen
A few weeks of work, mostly on the audit trail and edge cases. Shares the product's roles and audit log, and in-surgery and remote signing use one pipeline.
Documenso Fallback
Open source with templates, an API and webhooks, so it's faster to start. It's a separate Next.js app with its own users and database under AGPL, and a second system to host in the UK and cover in the data protection assessment.
Automation engine
State machines fire events, and handlers decide what to send and to whom. Time-based work runs on a scheduler. Pick a state to see what it triggers.
- Reminders for appointments 48 hours away.
- A reception task when a reminder gets no reply after 24 hours.
- Recall invites as recalls fall due.
- The morning digest for each clinic.
- Unsigned note nudges at the end of the day.
- Expiry checks for registrations, indemnity and equipment.
- Retention reviews for records past their period.
Settings switch automations per clinic. Templates hold the wording. Every message and task is stored.
Design system
One source for design decisions, generated for web and iOS and checked by screenshot tests. Pick a token to see what each platform gets.
Mirrored components
Same names and states on both platforms, each specified once for loading, empty, error and disabled.
Tokens are named by meaning, such as color.status.obturated, never by colour.
The Rootware wordmark and symbol ship as SVG next to the tokens, with the canal colour as color.brand.canal, so both platforms use identical artwork.
Playwright on the web and swift-snapshot-testing on iOS. A token change that breaks a layout fails the build.
Storybook for web components, Xcode previews for SwiftUI.
Copy exports to web JSON and iOS String Catalogs, checked against the glossary.
The type scale maps to iOS text styles so user font sizes still apply.
Status labels, formatting, permissions and notation come from the API, so both apps agree.
Migration engine
One canonical importer with a thin extractor for each source, instead of a full pipeline per competitor.
import/
manifest.json source, version, cut-off date
patients.jsonl
appointments.jsonl
medical_history.jsonl
notes.jsonl
treatment_plans.jsonl
balances.jsonl opening balances only
documents/ original files
images.jsonl manifest for the bridge app- Idempotent. Every row keys on source system and source ID, so re-runs update instead of duplicating.
- Dry run first. A report with counts, warnings and errors per entity, reviewed before anything is written.
- Mapping screen. The practice maps practitioners, appointment types and price lists.
- Top-up run. A final run the night before go-live brings across the last changes.
- Base charts. Where a source has structured charts, missing teeth and existing restorations import as chart entries marked existing.
- Legacy stays legacy. Old notes and free-text history land in read-only records, never parsed into structured plans or cases.
Engineering rules
Set these on day one. They're expensive to add later.
Every tenant-owned table carries tenant_id, enforced by a Doctrine filter and Postgres row-level security.
Time-sortable, not guessable, and safe for the iOS apps to create offline.
A small integer on the record, shown in Palmer or FDI per user. No tooth table.
Stored in UTC and shown in each clinic's time zone.
Changes after signing are saved as new versions.
Clinical records are archived, never deleted, for the retention period.
Opening a patient record writes an audit entry, including the agent's ID during support sessions.
Corrections create a new document and a new signature request.
TLS in transit, encryption at rest for databases, storage and backups, and CipherSweet for sensitive fields that need searching.
With passkeys and security keys supported.
No real patient data in development, test or staging.
OpenTelemetry traces and metrics across the API and workers.
Technical decisions
What's agreed, what's proposed and waiting for a yes, and what's still open.
Checked against the libraries the product needs. Only DICOM is weak in PHP, and Orthanc covers it.
JSONB for clinical detail and row-level security for tenants.
One codebase, with PencilKit and offline signing.
On the private network, behind the gateway.
Gotenberg, PDF.js, signature_pad and pyHanko.
W3C format in Git, generated by Style Dictionary.
For data, backups and object storage.
Keeps large CBCT traffic out of PHP.
One process for serving, TLS and live updates.
Each finding, restoration or procedure is an entry with surfaces and a state. The current chart is computed from them, so history and audit come free.
An EndoCase belongs to a root canal treatment item. Periodontics, implants and orthodontics follow the same pattern and are switched on per plan.
Sortable and safe for offline creation.
Two layers of tenant isolation.
State machines fire events, and the scheduler handles time.
A custom authenticator, because switch_user can't cross firewalls.
Swap in an Adobe-trusted certificate later.
Streams large files and keeps extractors simple.
Either works for the web panel. Pick the one you'll move fastest in.
AWS London, Azure UK South, or another provider with UK data centres.
Own CA at launch, or Adobe-trusted from day one.
Choose a paid provider for production.
Apply early. If it's refused, plan around the practice's own export.
What's available offline, how it's encrypted on the device, and how conflicts resolve.