Anamya

Anamya is a healthcare software platform designed to improve patient intake, appointment workflows, and clinical information management for dental practices. I am its Chief Technology Officer, responsible for the technical vision, the product architecture, and the engineering execution.

This case study describes the problem, the role, and the architecture at a level that does not expose proprietary implementation. Source code, internal schemas, endpoints, infrastructure details and client information are deliberately omitted.

Dental practices run on a sequence of small administrative steps that each cost clinical time: collecting a medical history, preparing an appointment, recording a treatment plan, producing a quotation, and keeping patients informed.

These steps are frequently handled by a mix of paper, phone calls and disconnected tools. The result is duplicated data entry, information that is unavailable at the moment it is needed, and administrative load carried by clinical staff.

• Medical history collected on paper and re-entered manually
• Appointment preparation depending on staff availability
• Patient communication handled ad hoc
• Information fragmented across systems that do not exchange data

• Reduce the administrative work surrounding each appointment
• Collect structured medical history before the patient arrives
• Make patient, appointment, treatment-plan and quotation workflows continuous rather than disconnected
• Integrate with the practice-management systems already in use rather than replacing them
• Automate routine patient communication across SMS, email and voice
• Keep the interface usable by non-technical clinical staff under time pressure

The platform follows a conventional layered architecture. The value is not in architectural novelty but in keeping the boundaries clean enough that workflow logic stays testable and integrations stay isolated.

1. 01

   Client Application

   Practitioner and patient-facing interfaces

2. 02

   Authenticated API Layer

   Authentication, authorisation, request validation

3. 03

   Business and Workflow Services

   Intake, appointments, treatment plans, quotations

4. 04

   Database and External Integrations

   Persistent records and practice-management systems

5. 05

   Monitoring, Notifications and Background Jobs

   Scheduled communication and observability

The core flow follows the patient rather than the software. A patient is invited to complete an anamnesis before the appointment; the response becomes structured data available to the practitioner at the point of care; the appointment produces a treatment plan; the plan produces a quotation; each transition can trigger communication.

• Structured intake captured ahead of the appointment
• Clinical information presented in the order it is needed during consultation
• Treatment plan and quotation derived from the same record
• Communication triggered by workflow state rather than manual action
• AI-assisted steps used to reduce transcription and summarisation effort, always with practitioner review

Optimization here means reducing the number of actions a practice must take, not reducing milliseconds. The engineering effort concentrated on eliminating duplicated data entry and on making the common path short.

• Data entered once and reused across the workflow
• Defaults derived from context so the common case requires no input
• Background processing for anything that does not need to block the user
• Interface latency budget prioritised for the screens used during consultation

• Managed cloud hosting with environment separation between development and production
• Automated deployment from version control
• Database backups with restore procedures verified rather than assumed
• Configuration and credentials supplied through the environment, never committed

Specific security mechanisms are intentionally not described here.

Anamya is evaluated on workflow outcomes — whether an intake is completed before the appointment, whether a plan converts into a quotation without re-entry — rather than on model or system benchmarks.

The platform is in production use. Adoption, usage and business metrics are confidential and are not published here.

Benchmarking in progress. Results will be published with the hardware, model, runtime and measurement conditions that produced them.

• In clinical software the binding constraint is the practitioner's attention, not compute. Every screen competes with a patient in the chair.
• Integration with incumbent systems determines adoption more than feature breadth does.
• Privacy decisions are cheapest at design time and extremely expensive to retrofit.
• Automated communication needs conservative defaults; the failure mode of over-messaging patients is worse than the failure mode of under-messaging.
• A CTO role in a small team is mostly deciding what not to build.

• Broader practice-management integrations
• Deeper workflow automation where the practitioner review step can be safely shortened
• Continued hardening of access control and auditability as the user base grows
• Scalability work driven by observed load rather than anticipated load

Described at a deliberately general level. Detailed infrastructure and internal architecture are confidential.