How it works
High tech backend. Low tech frontend. Human always.
That sentence is our engineering brief, not a slogan. Every difficult decision in the platform resolves the same way: complexity belongs on our side, simplicity belongs on the patient's side, and a human stays in the loop.
The patient's side of almyhealth is a phone ringing. That is the entire interface. There is no app to install, no device to ship, no charger to remember, no password to reset, and no broadband connection required. Any telephone works, including a landline.
Everything else happens behind that call.
The loop, in four parts
- The plan comes from the clinician
- Alma calls
- The conversation becomes data
- Humans are brought in when it matters
1. The plan comes from the clinician
A healthcare organization licenses almyhealth for its population. Care teams configure each patient's treatment plan in the almyhealth for Providers dashboard: which medications, which monitoring steps, which therapy, on what schedule. Plans can also be populated from the provider's existing records, or set up by the patient.
Alma never invents a care plan. She executes one that a clinician wrote.
2. Alma calls
Alma reaches the patient the way that patient prefers, by voice call, SMS or app notification. She works from the plan, adapts her manner to the person and the moment, and holds a real conversation rather than reading a script.
3. The conversation becomes data
What the patient says is turned into structured clinical information: doses confirmed, symptoms reported, weights recorded, exercises completed. This is stored as protected health information and treated accordingly.
4. Humans are brought in when it matters
Alma continuously compares what she hears against what the plan expects. When something falls outside that range, the Safety Network Alert System notifies the care team, with the triggering content documented so the clinician can judge it themselves.
Alma flags. A person decides. That order never reverses.
For technical and clinical readers
This section is for readers evaluating the platform in depth. It is safe to skip.
Conversation layer
Alma runs on large language models orchestrated against a per-patient care plan and context record. Patient context includes the clinical plan and the living context around it, including household situation, preferences and daily routine, because a reminder that ignores someone's actual life gets ignored back.
Prompt construction follows data minimization: the amount of protected health information passed to any model provider is limited to what the interaction requires, and every vendor in that path is covered by a Business Associate Agreement.
Behavioral layer
Two mechanisms govern how Alma speaks.
Empathy Mirroring reads shifts in mood and stress from vocal tone and phrasing, and directs Alma to acknowledge the patient's state before proceeding to clinical content.
Adaptive Support Archetypes shift Alma's behavioral role to fit the task: an instructional role for new post-operative directions, a peer role for encouraging daily habits, and a firmer advocate role when a critical safety step such as insulin has been missed.
Escalation layer
Escalation is tiered. Routine gaps, such as a single missed dose, are logged for the dashboard. Repeated gaps and symptom outliers generate clinical alerts. Signals suggesting acute crisis trigger immediate escalation to a human, plus direct surfacing of the 988 Suicide and Crisis Lifeline and the Crisis Text Line, available independent of app or internet access.
Crisis detection is designed against established clinical frameworks, with the Columbia Suicide Severity Rating Scale as the reference standard, and is tested against standardized scenarios before deployment and on a recurring schedule after it.
Data layer
Interaction data is segregated by category rather than pooled: clinical care data such as medications, vitals and adherence; general emotional support interaction logs; and mental health flagged content. These categories carry different sensitivity and different disclosure rules, and separating them at the architecture level is the only way to honor that at scale. Records falling under federal substance use disorder confidentiality rules are flagged and segregated with higher consent requirements.
Security layer
Encryption at rest and in transit. Role-based access control with unique user identifiers and no shared credentials. Multi-factor authentication on provider-facing and administrative systems. Full audit logging of protected health information access with user identity and timestamp. Automatic session timeouts. Controlled and logged data exports. Automated alerting on anomalous access patterns.
Voice data
Voice recordings are biometric identifiers and are treated as the most sensitive category we hold. Consent for voice capture is collected separately from general medical consent, in plain language, by phone, with verbal acknowledgment captured. No vendor in our processing chain is permitted to retain patient voice data or use it to train their own models. Deletion is a designed function of the platform, not a manual cleanup process.
Integration layer
almyhealth is designed for connection to clinical systems through FHIR APIs, with an API and SDK architecture for custom integration into existing provider workflows and legacy systems. Interoperability with major electronic health record platforms including Epic and Cerner is on the roadmap.