01
Policy
Consent
The patient and clinician follow the provider’s approved capture policy.
Industry · Healthcare
Healthcare software that assists the work without pretending to replace clinical judgement.
Thalenor designs appointment, patient communication, portal and clinical documentation workflows with careful permissions, explicit human review and clear boundaries around what an AI-assisted system may do.
PATIENT · PROFESSIONAL · RECORD02
A clear answer
What does Thalenor build for healthcare organisations?
Thalenor builds healthcare-adjacent digital systems for clinics, providers and health-service businesses: appointment journeys, patient portals, administrative workflows, documentation assistance and operational tools. The software can reduce repeated handling and make information easier to retrieve, but diagnosis, treatment and other clinical decisions remain with qualified professionals. Applicable privacy, medical-device, record-retention and interoperability requirements must be established with the organisation and its advisers for the jurisdiction involved.
Workflow in view
A credible product should make the work visible before it tries to make it fast.
Follow the record, the responsible role and the decision that must remain human.
ILLUSTRATIVE MODEL · FICTIONAL RECORDS
A consultation note is drafted for review, never silently committed to the record.
The useful system reduces typing while protecting authorship and clinical responsibility.
ENCOUNTER → DRAFT → SIGNED RECORD
ILLUSTRATIVE OPERATING MODEL · 06 STATES02
Care team
Encounter
Authorised audio or structured inputs are collected for the visit.
03
Assistance
Draft
A note is proposed with uncertainty and missing fields visible.
04
Clinician
Review
The clinician checks against the encounter, edits and rejects unsupported content.
05
Record system
Sign
Only the approved version enters the designated record system.
06
Governance
Audit
Source, review and authorship events remain traceable under policy.
Illustrative product workflow, not medical guidance. Final controls depend on jurisdiction, care setting, risk classification and the provider’s policies.
Boundaries built into the product
Responsible software states what it will not decide.
A disclaimer cannot compensate for a workflow that hides uncertainty or lets sensitive actions happen without ownership.
01
No autonomous diagnosis
A general software or language-model feature should not present itself as a qualified clinician or make unsupervised diagnostic decisions.
02
Human sign-off
Clinical notes, instructions and consequential messages require an identified professional review path.
03
Minimum necessary data
Collect and expose only the information required for the stated task and role.
04
Safe failure
Low confidence, conflicting information or integration failure should stop or escalate—not improvise.
05
Regulatory classification
The organisation must determine with qualified advisers whether a feature falls under healthcare, privacy or medical-device obligations in its market.
Operating landscape
One connected operation. Six places where context can break.
The system should carry meaning across these hand-offs, not leave users to rebuild it in messages and spreadsheets.
01
Appointment lifecycle
Service selection, availability, booking, eligibility information, preparation, reminders, rescheduling, arrival and follow-up.
02
Patient portals
Secure access to appointments, approved documents, messages, forms, instructions and account information.
03
Clinical documentation assistance
Drafting structured notes or summaries from clinician-authorised inputs, followed by review and sign-off before the record is saved.
04
Administrative coordination
Referrals, intake, consent, document requests, task ownership and status visibility across authorised staff.
05
Patient communication
Useful reminders and instructions through appropriate channels without exposing sensitive information in notifications.
06
Operational insight
Waiting times, no-show patterns, workload and process exceptions using data appropriate for the reporting purpose.
Where design judgement matters
The hard part is rarely the screen someone asks for first.
01
Booking is a clinical-administrative workflow, not just a calendar slot.
The right service, duration, practitioner, location and preparation may depend on information collected before confirmation. The design must also handle cancellations, urgent symptoms, prerequisites and capacity without implying that software has assessed the patient clinically.
- ASeparate scheduling rules from clinical triage
- BShow preparation and document requirements before arrival
- CDesign explicit reschedule and cancellation states
- DRoute urgent or ambiguous situations to people
02
AI may prepare a draft. A clinician owns the record.
Documentation assistance can reduce clerical burden, but transcripts and model output can omit, distort or overstate. A safe workflow keeps the source available, marks generated content as a draft, supports rapid correction and requires an authorised sign-off.
- AObtain appropriate consent for recording or transcription
- BKeep draft and signed states distinct
- CNever silently insert unsupported facts
- DLog review, edits and final author
03
The data boundary should be visible in the architecture.
Health data should not move through services simply because integration is convenient. The organisation needs an inventory of collected data, purpose, access, storage location, retention, processors and deletion or correction routes.
- AApply least-privilege role access
- BKeep sensitive content out of casual notification channels
- CSeparate production data from testing
- DAgree incident, export and retention procedures
04
An integration is a responsibility boundary.
Patient, practitioner, appointment and clinical records may exist in an EHR, practice-management product, laboratory system or payer workflow. Interoperability work must identify the authoritative system, supported standards or APIs and behaviour when data is delayed or rejected.
- AMap identifiers and source-of-truth systems
- BValidate inbound and outbound data
- CSurface sync failures to an owner
- DUse recognised standards such as FHIR only where supported and appropriate
Relevant capabilities
The engineering disciplines this work usually touches.
Decision guide
A practical review before introducing AI into a healthcare workflow.
The most important design decision is not the model. It is the boundary between assistance, administrative action and clinical judgement.
Begin with a narrow, reviewable administrative or documentation task whose source, reviewer and failure path can be made explicit.
01
Classify the decision
Is the output clerical, informational, operational or clinical? Consequence and required oversight rise sharply across those categories.
02
Identify the source
A summary or suggestion should be traceable to authorised information. Retrieval cannot be allowed to cross patient or role boundaries.
03
Define the reviewer
‘Human in the loop’ is incomplete unless a qualified person has time, context and a clear interface for review.
04
Design uncertainty
Low confidence should trigger clarification, abstention or escalation. Smooth language must not conceal weak evidence.
05
Measure the right failure
Evaluate omissions, unsupported additions, wrong-patient context, delayed data and review overrides—not only whether the prose reads well.
06
Plan the record
Decide what is a temporary draft, what enters the clinical record, who authors it and how corrections are represented.
Practical questions about healthcare software.
It can prepare a draft from authorised inputs. The product should preserve the source context, distinguish draft from signed record and require review by the responsible clinician.
Start with the care boundary, not the AI feature.
Describe the users, information, clinical or administrative decision, reviewer and failure path. That context determines whether the system should automate, assist or stay out of the way.