Patient identity & ABHA
Create, search and verify an ABHA at the front desk — via Aadhaar or mobile, or by scanning the patient's ABHA card QR straight into registration.
- ABDM M1 identity flows
- Duplicate-mobile guard
- ABHA masked to last 4 everywhere
Caladrius Health AI Studio — Product brief
Caladrius Health AI Studio is an AI-native revenue intelligence application for hospitals in India, the Middle East and the USA. It brings augmented intelligence capabilities that enable persona-based, data-driven insights and verifiable, explainable AI workflows with in-built evals and benchmarks. It is cloud-agnostic — deliverable on-premise, in a private cloud, or in a public cloud.
It works the revenue cycle end to end — eligibility, pre-authorisation, claim submission, denial management, reconciliation — directly on ABDM and NHCX, the national digital health infrastructure Indian providers are already adopting. Not a dashboard over a manual process, and not a copilot bolted onto a legacy RCM suite: the workflow, the clinical data model and the AI were designed together.
Security by design, in the literal sense. The rules that protect patient data are encoded into how every line of code gets written, and enforced by tooling as it is written — not reviewed for afterwards. How that works
What AI-native means here
"AI-powered" is claimed by every vendor in this category, and it usually describes a chat box beside an unchanged process. Three things separate what we built, and each is verifiable in a demo rather than asserted in a deck.
A claim bundle is assembled from the encounter that actually happened — the facility's real HFR identifier, an HPR-verified care team, coverage resolved by live policy discovery against the payer, conditions coded in SNOMED CT and translated to ICD-10 through the NRCeS Bharat Health Terminology Service, procedures typed as procedures rather than flattened into diagnoses.
Anti-hallucination is a property of the pipeline, not an instruction in the prompt. Where no confident code match exists, the field is left for a human rather than invented — and the assembled bundle is inspectable, resource by resource, before anything is submitted.
The data layer is medical infrastructure in its own right — modelled natively on FHIR R5 and the ABDM Patient Profile rather than a proprietary schema with a translation layer bolted to the edge. Claims move as NHCX ClaimBundles. Records move under ABDM consent artefacts.
The practical consequence: when the national rails change, we change a mapping — not a data model. And a provider's data stays portable to anything else that speaks the same standards.
Every record carries provenance. A visit pulled from another hospital is labelled as theirs; a record we published that comes back through ABDM is recognised as ours and de-duplicated, never double-counted or claimed against twice.
When a payer denies or queries a submission, the resubmission is resolved against the actual denial code and the specific document requested — it answers that question, rather than resubmitting the same bundle and hoping.
And because AI output in a regulated setting has to be measurable, not merely plausible, model behaviour is held to in-built evals and benchmarks rather than to impressions — so a change in accuracy shows up as a number before it shows up as a denial.
The platform
One workspace across identity, clinical records, claims and money. Each capability below is built, tested and deployed through a three-stage promotion pipeline — not roadmap.
Create, search and verify an ABHA at the front desk — via Aadhaar or mobile, or by scanning the patient's ABHA card QR straight into registration.
Consent-gated pull of a patient's records from any ABDM-linked provider, and publication of your own back to the network. Both HIU and HIP.
A ten-step journey from patient preparation to payer response, assembling a complete ClaimBundle from the encounter rather than from a form somebody retyped.
Upload to submission in one inspectable pipeline: OCR, clinical entity extraction, FHIR bundle assembly, a grounded prompt, then preview. Multi-file, with per-file state.
Integrated with the NRCeS Bharat Health Terminology Service (BHTS) — the national health terminology service — for SNOMED CT lookup and ICD-10 translation, so coded clinical meaning survives the trip from the note to the payer intact.
Persona-based views — what a front-desk clerk, a coder, a claims manager and a CFO each need is a different screen, resolved by role rather than by a shared dashboard everyone half-uses. Live alerts the moment a record pull fails or a claim changes state.
Four pillars
The same four dimensions every RCM operation is judged on — benchmarked against the status quo rather than against last quarter. These are the targets the platform is built and measured against.
Claims resolved before they cost you.
Against 70–75% first-pass accuracy in traditional RCM — fewer rework cycles, faster settlement.
70% lower denial rateAutomated end to end. Unlimited scale.
₹12–18L a year of revenue leakage driven toward zero, at any volume — without adding headcount.
60% lower operating costValidated in real time. Not at adjudication.
Errors are caught while the claim is being assembled — before it reaches a payer and becomes a denial.
ABDM · NHCX · WASA — in progressProactive, not reactive.
Live dashboards, instant insight and alerts that fire while a problem is still fixable — not in next month's report.
24/7/365 monitoringOne AI-native platform — revenue, efficiency, quality and service, in one workspace.
Caladrius Health Claims Scorecard™
Caladrius IPThe same claim data answers a different question depending on who is asking it — the operator about to hit Submit, the desk manager deciding where to spend today, and the CFO explaining receivable days on an earnings call. The scorecard ships all three, from one pipeline, with no separate BI project.
One score at the point of submission, the reasons behind it, and the single next-best action for each — computed pre-flight, while the claim can still be fixed rather than appealed.
For the insurance and claims desk manager: performance by payer segment rather than a blended average, so the drag is attributable to a book, a reason and a rupee figure.
Accounts-receivable management and revenue intelligence at board altitude: the metrics already in the investor deck, plus the layer underneath them that moves those metrics — and that the sector currently cannot see.
Caladrius Health Claims Scorecard™ is proprietary to Caladrius Ventures Pvt. Ltd. The scoring model, its dimension weighting, the rupees-at-risk ranking of risk flags and the three-altitude structure are our own design — not a licensed analytics package with our name on it.
The third lens is the differentiated one. Across 17 listed Indian hospital operators, exactly one discloses a first-pass rate, and none report denial-by-reason or receivable-days-by-payer — figures drawn from the operators' own earnings calls. Those are precisely the numbers analysts ask about, and today they are treated as fixed facts of the business rather than as something management can move.
Caladrius Cally™
Caladrius IPCally is the conversational agent built into the workspace. It is not a help widget bolted to the corner of the screen — it can read the page a user is on, carry out the transaction they describe, and render the result back into the conversation.
Two problems it solves that a training programme cannot. New staff become productive without a manual, because the application explains itself. And staff who cannot comfortably drive a dense clinical interface — by mouse, by keyboard, or at all — get a second, equal way in.
A new user asks what a screen is for, where a task lives, or what a clinical term means, and is answered in context — with the answer grounded in this hospital's live data rather than in generic documentation. Onboarding happens during the work instead of before it.
Every instruction can be spoken instead of typed, with speech recognition tuned for Indian languages and accents. A user who cannot navigate a dense interface can still register a patient or file a claim by describing it. Accessibility as an operating mode, not a compliance checkbox.
Register a patient, open an encounter, search and inspect claims, draft a claim, check whether it is ready to submit, validate its codes, submit through the exchange. Around seventy distinct operations, each executed against the real system — not a simulation of it.
When a payer needs documentation the workspace has no form for, Cally generates a structured capture form on the spot — typed fields, coded answers, conditional logic that shows only what applies, and validation before submission. Templates can be saved and reused.
Incomplete documentation is one of the largest single causes of denial. Because the generated forms are coded and validated at the point of capture, the evidence pack reaching the payer is complete the first time — turning a denial-and-appeal cycle into a submission that clears.
Look up a clinical concept, translate between coding systems, test whether one concept subsumes another, expand a hierarchy, retrieve drug information, or read a concept's terms in another Indian language — without leaving the claim being worked on.
What keeps it trustworthy is what it refuses to do. Cally never invents a patient, a claim number, a statistic or an identifier — if it does not have the data from a live lookup it says so and goes and fetches it. Before any action that writes, it states what it is about to do, lists the values it will use, and waits for explicit confirmation; silence is never treated as consent. It can only perform actions the signed-in user is themselves permitted to perform. And a filter sits between the workspace and the model, so identifiers such as mobile numbers, email addresses, ABHA numbers and Aadhaar are stripped before anything is sent — the assistant works with a name and a display ID, and nothing more.
How to read an AI claim in RCM
A useful frame for evaluating anything in this category — ours included. Most tools marketed as AI-powered revenue cycle management sit at L2: they recommend, flag and suggest, while a human still makes every decision. Faster, same headcount. The industry's real difficulty is not reaching L3. It is that L3 automates tasks inside their own silos and multiplies the seams between them.
| Level | Stage & description | Status |
|---|---|---|
| L1 | Visibility Dashboards, reports, analytics. Humans see what is happening. They still decide and act on everything. |
Starting point |
| L2 | Assistance AI recommends, flags, suggests next best actions. Humans make every final decision. Faster — but same headcount. |
Most orgs today |
| L3 | Partial automation Specific tasks automated end-to-end inside their own silo. Humans manage every handoff between automated systems. Seams multiply. |
The plateau |
| L4 | High automation Workflows execute end-to-end across systems, sharing context. Humans handle genuine exceptions and judgment calls. Costs compress materially. |
Realistic goal |
| L5 | Fully autonomous End-to-end autonomous execution. Continuous learning. Human oversight at the governance layer, not the workflow layer. |
Long-term horizon |
The distinction between L3 and L4 is not speed. It is whether the system can run a workflow end-to-end across systems — even when a step stalls — without routing back to a human. That is an architecture question, and it is decided long before the AI is chosen: shared context across steps, a common clinical data model, and somewhere for a genuine exception to go.
AI-native development
We build the way we expect the industry to build within a few years: work is specified as a complete feature, AI agents implement it against an encoded engineering standard, and every change arrives with its own tests, verification evidence and changelog entry in the same commit. It is why a team this size ships at this cadence.
It also creates a specific obligation. When machines write a meaningful share of the code in a system that holds patient data, the safeguards cannot be a review someone does afterwards, when there is time.
The same applies to the model's own output. AI behaviour is held to a registry of 99 application evals across five modules — performance, workflow, experience and safety — alongside 35 runtime evals, each persisted with pass/warn/fail history so a regression shows up as a number before it shows up as a denial. Past incidents become standing evals, so the same failure cannot return unnoticed.
Caladrius Health Vault™
Caladrius IPEvery AI feature in the platform runs on de-identified text. Before any call to an external model, protected health information is replaced with opaque tokens; the model's response is re-identified on the way back. No patient name, ABHA number, Aadhaar, date of birth, phone, email or address leaves your perimeter — and the reasoning quality is unaffected, because the model still sees a consistent entity. It just never learns who.
The Vault is our own privacy engine, built in-house. It is the single control point every flow of patient data passes through on its way to a log, an archive, an API response or a model.
Nine PHI classes are tokenised — name, ABHA, date of birth, phone, email, address, MRN, identifier, Aadhaar. Identical values map to the same token within a batch, so clinical reasoning over the record still holds together.
Known PHI is pulled directly from the patient record — high precision, no guessing. A second pattern pass catches PHI shapes that appear in free text the record does not cover: ABHA addresses and numbers, Aadhaar, email, Indian phone formats, dates. Longest-match-first ordering means a substring can never be tokenised inside a longer value and corrupt it.
If encryption is not configured, de-identification raises rather than degrades — and the model call is abandoned. There is no code path in which a misconfiguration quietly sends raw PHI to a third party. The safe outcome of a broken Vault is a feature that stops working, never a feature that leaks.
Original values are held AES-256-GCM encrypted, keyed outside the table itself. The map needs to outlive exactly one model round-trip plus a short reconciliation window, then it is purged on a timer. Logs record counts, PHI classes and a batch identifier — never a value.
Tokenisation is the second line, not the first. Any flow that moves patient data toward a model passes a consent and audit gate ahead of it: valid, non-expired consent for an acceptable purpose, or the request is refused and recorded. Combined with on-premise or private-cloud deployment, the data can be kept inside the hospital's own perimeter end to end.
De-identification is only worth as much as the data architecture behind it. The Vault governs a medallion archive modelled on how curated clinical datasets such as MIMIC and SAIL are built — so a hospital's own data becomes safely analysable, and eventually becomes training material for a model that runs on its own premises.
The live clinical and claims tables, exactly as the application writes them.
PHI present · in DPDPA scopeFHIR-aligned, with every patient replaced by a stable anonymous linkage key so records still join truthfully.
Pseudonymised · in DPDPA scopeDate-shifted per patient, age-banded, k-anonymised and aggregated under differential privacy.
Anonymised · out of DPDPA scopeThe identity and date-shift maps that make re-identification possible live in their own schemas — and the application cannot read them.
Direct identifiers · ETL role onlyOnce the Gold layer exists, a hospital can train localised models on its own de-identified corpus and progressively take over the work currently sent to third-party AI services — OCR, entity extraction, redaction. That is the end state the Vault is built toward: your data trains your model, on your hardware, and never leaves. The de-identification engine described above is live today; the archive and the on-premise model programme are in build.
Caladrius Health Vault™ is proprietary technology designed and built by Caladrius Ventures Pvt. Ltd. The de-identification engine, token map design, policy model and medallion governance scheme described here are our own work, developed for this platform. Nothing on this page is an off-the-shelf component.
Security by design
This is a PHI codebase heading into ABDM M1/M2/M3 certification and a WASA penetration assessment, under DPDPA's 72-hour breach clock. Security is encoded as an artefact the tooling enforces — four layers, each independent of the one before it.
A governing engineering standard sits in the repository and is loaded into every session: immutable prohibitions on hardcoded secrets and PHI exposure, an explicit instruction hierarchy that no ticket or code comment can override, and a prompt-injection protocol with a required disclosure format for anything suspicious found in a file or a tool response.
Every single edit passes a blocking gate: a secret scan and a PHI-pattern scan run before the change is accepted. The eight most sensitive files — patient controllers, the ABDM health-information handler, the redaction and masking utilities — are locked unless the work is explicitly classified for them. Force-pushes to protected branches are refused at the shell.
Continuous integration runs secret detection, PII scanning, security linting, static analysis across JavaScript and Python, dependency audit and a CycloneDX SBOM on every change. Read-only auditor agents review against WASA criteria, ABDM compliance and general code quality — tiered so the most sensitive changes draw all three.
All database access is parameterised and machine-checked — a guard rejects any query built by string interpolation, so SQL injection is closed structurally rather than by discipline. Consent is verified before health information is read. ABHA identifiers are masked to the last four digits in every interface and every log line. Patient data access writes an audit entry, and data stays resident in India under DPDPA.
Certification status is honest: ABDM M1/M2/M3 and WASA are in progress, not complete. We will show you the current state of each against its test suite rather than a badge.
The Caladrius harness
Caladrius IPA working test for any AI vendor, including this one: what do they own that you could not rebuild with a corporate card and a long weekend? The model layer is now a commodity — capable, cheap and interchangeable. Everything above it is the actual system, and in a regulated Indian hospital every layer of it is load-bearing. Here is the stack, and where we sit on each layer.
Those six layers above the model are what we call the Caladrius Health AI Studio harness for revenue intelligence — the part we built, and the part that does not change when the model underneath it does.
Most teams treat a design system as paint. In an agentic engineering process it is closer to a compiler: the constraint that turns many parallel agents into one product. Ours does four jobs at once.
Colour, type, spacing, radius, shadow and icon foundations, documented and versioned, correct in light and dark. Governed by five stated principles — among them monospace for money, so figures always align, and colour is signal, never decoration.
Primitives, composites, layout, feedback, context providers and hooks — built on Radix accessibility primitives, typed strictly, variant-driven. One shell, one data table, one form stack. No component is hand-rolled twice.
The part no general-purpose kit ships: claim status trails, denial-reason cards, appeal-deadline indicators, financial breakdowns, NHCX coverage and policy cards, OCR pipeline steppers, mCODE graphs, completeness meters. The revenue cycle has its own vocabulary.
The agent reads page state, writes back through registered tool calls routed via user approval, and renders interface inline rather than emitting text. Agent Cards declare skills, connectors, triggers and human-in-the-loop escalation policy — oversight as a component contract.
And it is enforced as an engineering rule, not published as a style guide. Every interface must be mapped onto the existing system before a line is written, with a checked-in visual scaffold as the arbiter when behaviour is ambiguous. Reaching for a raw container with improvised colour instead of the system's card is treated as drift and rejected. That constraint is what makes an agentic process viable at all — it is also why "role-aware by default" is a component contract here rather than a design intention: the same claim record renders differently for a biller, an insurance desk, a CFO and a CEO, because the components take role as an input.
The model is the part anyone can buy. Layers 2 through 7 — the harness — are the part we built.
The Caladrius Health AI Studio harness for revenue intelligence, together with the Caladrius Health Vault™ and the Caladrius Health Claims Scorecard™, is proprietary technology of Caladrius Ventures Pvt. Ltd. The model layer is licensed from third-party providers and is deliberately interchangeable.
The harness, layer by layer
The same seven components, taken one at a time. Scroll the stack — each layer settles onto the one beneath it, in the order they actually depend on each other, from human oversight at the top down to the interchangeable model at the base.
99 application evals across five modules and 35 runtime evals, persisted with pass, warn and fail history and surfaced in an ops console. Every pipeline step is inspectable before submission.
Not a theme over someone else's kit. 165 semantic tokens, 93 interface components and 58 healthcare components built for this domain, enforced as an engineering rule rather than published as a style guide.
ABDM M1/M2/M3, NHCX, NRCeS BHTS terminology, and the HFR and HPR registries — wired in as first-class flows rather than an export folder. Consent artefacts and gateway callbacks are part of the workflow.
Authentication and authorisation on one enforced server-side path: JWT sessions in HttpOnly cookies, role-based access control resolved per feature rather than per page, and consent verified before any health record is read.
NRCeS ClaimBundle rules, the HCX denial-code catalogue, payer-specific adjudication logic and workflow-state resolution that knows a resubmission from a fresh claim — surfaced as the Claims Scorecard.
A medical data infrastructure, not an application database — modelled natively on FHIR R5, the ABDM Patient Profile and the NHCX claim exchange, so clinical meaning survives from the encounter to the payer.
Bought, deliberately. The prompt is generated from the assembled bundle, so the model is swappable without touching a single workflow.
Where this goes next
The platform is real and deployed. What compounds it now is depth in specific settings — and there is more value in a handful of serious collaborations than in a wide, shallow launch.
Hospitals and diagnostic networks willing to run a real claim line with us and be blunt about where it breaks. You get the roadmap shaped around your denial patterns; we get the ground truth no synthetic dataset provides.
NHCX only compresses cycle time if both ends are clean. We want counterparties to test submission quality against — and to co-define what a first-pass-worthy bundle actually looks like.
HMIS and EMR vendors, ABDM integrators, terminology and identity providers. Standards-native means we would rather interoperate with you than rebuild what you already do well.
Clinical coding accuracy, grounded generation, and evaluation methodology for AI in regulated healthcare settings. We have the benchmarks and the real workflow to test against.
Next step
A working session, not a slide walkthrough: we take an encounter end to end — record pull, bundle assembly, pre-authorisation, payer response — and you interrogate every step. Roughly 45 minutes.