Healthcare
Administrative and operational AI for providers, life sciences and health platforms, engineered for privacy, consent and audit rather than clinical judgement.
Healthcare buyers rarely have a model problem. They have a data problem wrapped in a consent problem, sitting inside an estate of clinical, billing and scheduling systems that were never designed to talk to each other. Caltor works on the administrative and operational side of that estate: the scheduling, documentation, billing and communication workflows that surround care without deciding it.
Where the work sits
Our work in healthcare sits around care rather than inside it: intake and scheduling, documentation and correspondence, billing and claims support, retrieval over administrative records, and the integration that connects those systems to one another. These are the workflows where staff time disappears and where a mistake is expensive but recoverable. They are also the workflows where correct behaviour can be written down precisely enough to test, and a definition we can test against is the condition we set before agreeing to build anything at all.
Privacy, consent and audit are design inputs
Health data carries obligations that arrive before the architecture does, so we treat them as inputs rather than as a review at the end. Access is designed to the minimum a function actually needs, not to whatever the integration makes convenient. Consent and permitted use are represented in the data layer instead of asserted in a policy document. Every read, every model call and every action taken against a record is logged in a form your compliance function can reconstruct. Where a workflow does not need identified data, we design it not to receive any.
The systems already in place
Nothing in health runs alone. An administrative system has to sit beside an electronic health record, a practice management system, a claims clearing house and whatever has been built around them over the years. We treat that estate as the design constraint it is and work through the interfaces those systems genuinely expose, including HL7 and FHIR where they exist and far plainer integration where they do not. Interoperability and information blocking obligations shape what a system is permitted to move, and we read them before the design, not after it.
What we do not build
We do not build systems that make clinical judgements. Nothing we design diagnoses, triages, recommends treatment, calculates a dose or determines medical necessity, and we do not build software intended to function as a regulated medical device. Where an administrative workflow runs close to a clinical decision, the system prepares and presents information to the licensed person who makes that call, and the record shows what was presented to them. If a problem requires the other thing, we tell you at the start and decline it rather than stretching our scope to fit.
Where this grounding comes from
Caltor is a young firm and will not present anyone else's work as its own. What we can point to is our own: the founders built and operate Miravio, a clinical operations platform for behavioural-therapy practices in the United States, carrying regulated clinical data, scheduling, billing and family communication with strict separation between practices. Miravio is a founder-built venture, not a client engagement, and we will always describe it that way. It is why interoperability standards and HIPAA obligations are familiar ground here rather than something to be learned on your engagement.
What we build in health
- Retrieval and drafting over administrative records, policies and correspondence, with the source of every answer shown next to it.
- Intake, scheduling and follow-up workflows that remove manual handling around an appointment without touching the clinical content of it.
- Billing, claims and prior authorization support that assembles and checks documentation while a person makes the submission decision, with each step recorded.
- Integration between clinical, scheduling, billing and reporting systems, built on the interfaces those systems actually expose.
- Access control, consent handling, separation between tenants and audit logging designed into the system rather than added before a review.
- An evaluation suite that states what a correct output looks like, with runbooks and training so your own team can operate and defend the system.
What this is not
This page describes administrative and operational work only. Caltor does not build clinical decision support, diagnostic or triage tools, does not build software intended to function as a regulated medical device, and does not take on care delivery or clinical research. It is also not the description of a staffed sector practice. Caltor is a firm led by its founding partners, and the healthcare grounding described here is the founders' own venture rather than client work.
Talk to a partner
Describe the administrative workflow and the records it would touch, and a founder will tell you plainly whether it is work we should take.
