Four surfaces
Patient web (form, documents, status), clinical workspace (desk board, doctor sign-off, queries), admin console, and an advisor view with status and money but no clinical data.
Claims Ignite · for IT and security
It runs in your cloud account, from your repository, under your keys.
You own the data, the pipeline and the brand. Zyanta is a processor with no standing access to production. This page covers the deployment model, integration, roles and the service levels we propose.
Your cloud account · India region
Your keys, your pipeline
- Source mirrored to your Git Done
- Built and scanned by your CI/CD Done
- Your approval gate Done
- Deployed to production Now
0Standing access for Zyanta to production
Illustrative screen
Deployment model
Everything sits inside your boundary. Data leaves it in two places, each on a person's action.
Core, adapters, storage
Core services with payer-channel and integration adapters; storage, audit timelines and backups, all in your account.
Your infrastructure and pipeline
Infrastructure code, CI/CD and monitoring. Your pipeline builds, scans and deploys behind your approval gate.
You own the data
You are the data fiduciary under the DPDP Act. Zyanta is a processor with no standing access to production.
Exit 1 · document reading
The call to the AI model that reads policy and identity photos. With a cloud-hosted model, it stays in your account.
Exit 2 · filing with the payer
Sent when the desk presses submit, to the TPA portal, NHCX, the insurer's API or your claims platform.
Where the AI runs
In your cloud or through the Claude API. Switching is a configuration change.
| Where the AI runs | How it works | Best for |
|---|---|---|
| Microsoft Foundry, on Azure | Claude deployed as a model in your own Azure subscription, in the region you choose, billed on your Azure agreement. The document-reading call never leaves Azure. | Hospitals on Azure |
| Amazon Bedrock or Google Vertex AI | The same approach on AWS or Google Cloud, inside your account and chosen region. | Hospitals on AWS or Google Cloud |
| Anthropic's Claude API | Direct from Anthropic, under your contract or ours. API data is not used to train models. | Fastest start |
Designedone adapter, not a rebuild. Which models each cloud offers in an India region is confirmed with your provider before go-live.
Your hospital information system
We read what your HIS already knows, so nobody types it again.
| From your HIS | What Claims Ignite does with it | When |
|---|---|---|
| Patient registration and UHID | Matches the phone form to your patient by UHID, mobile and date of birth; links ABHA where the patient has one. | On registration |
| Admission (IP number, bed, date) | Fills the admission section and stops a duplicate admission being filed twice. | On admit |
| Doctor master | Name, qualification, registration number, department. Powers the doctor's QR and the sign-off identity. | Nightly |
| Room classes and tariff | Prices each room against the policy's limit and feeds the estimate. | On change |
| Estimate and interim bill | Fills the cost lines and supports enhancement requests during the stay. | On request |
| Back to your HIS | Pre-auth status, approved amount and the episode reference, for billing and discharge. | On each change |
Four routes, in order of preference
HL7 v2 ADT messages for registration and admission. FHIR R4 (Patient, Encounter, Practitioner, Coverage) where your HIS offers it. Read-only database views agreed with your team. A scheduled CSV file over SFTP where nothing else is available.
Works standalone on day one
The doctor master and tariff load from a spreadsheet, and the desk enters the UHID and IP number. Integration removes typing; it is never a precondition for the pilot.
LivestandaloneDesignedHIS connectors, built during set-up
Roles and permissions
Each role sees only what its work needs, enforced in the database.
| Can… | Patient | Doctor | Desk | Desk lead | Admin | Advisor | Auditor |
|---|---|---|---|---|---|---|---|
| Fill the patient's half | own | — | assist | assist | — | — | — |
| Read clinical details | own | ✓ | ✓ | ✓ | — | — | read |
| Write advice and the clinical half | — | ✓ | draft | draft | — | — | — |
| Sign off the clinical content | — | ✓ | — | — | — | — | — |
| Estimate, documents, submit | — | — | ✓ | ✓ | — | — | — |
| Answer a payer query | — | attest | ✓ | ✓ | — | — | — |
| See status and money only | own | ✓ | ✓ | ✓ | ✓ | own clients | ✓ |
| Reassign, override, reports | — | — | — | ✓ | — | — | — |
| Configure the hospital | — | — | — | — | ✓ | — | — |
| Read the audit trail | own log | — | — | ✓ | ✓ | — | ✓ |
Livepatient, doctor, desk, admin and advisor, enforced by row-level securityDesigneddesk lead and auditor, and role mapping from your directory groups through SSO
Service levels
The service levels we propose for production.
| Priority | Example | First response | Restore or fix |
|---|---|---|---|
| P1 · critical, 24×7 | The desk cannot file, or patients cannot open the form | 30 min | 4 hours |
| P2 · high | A feature is down and a workaround exists | 2 hours | 1 business day |
| P3 · normal | A defect with little effect on the day's work | 8 business hours | 5 business days |
| P4 · request | A change, a report, a new template | 2 business days | Next release |
99.5%
Monthly availability for the application
Measured at your edge
<15 min
Data loss after a failure
Service back within 4 hours
72 hrs
Critical security fixes
High severity within 7 days
Monthly
Releases, through your approval gate
With a monthly service review
Proposedagreed in the contract. When the platform runs in your cloud, availability also depends on your infrastructure; the contract sets out who answers for which layer.
For your colleagues
Send the right page to the right person.
Read next
For hospital leadership
Patient satisfaction, what a pilot asks of you, and what gets measured.
OpenRead next
For the insurance desk
What changes in the day, after-submit options, and what you configure.
OpenThe product
Claims Ignite, end to end
The problem, the eight-step flow and what is live today.
OpenQuestions
What this audience asks us.
Where does patient data sit?
Inside your own cloud account in an India region, deployed from your repository and under your keys. You are the data fiduciary under the DPDP Act. Zyanta is a processor with no standing access to production.
When does data leave our cloud boundary?
In two places, each on a person's action: the document-reading call to the AI model, and filing with the payer. On Azure with Microsoft Foundry, or on Amazon Bedrock or Google Vertex AI, the model is reached inside your own account and chosen region.
Do we need to integrate our HIS before a pilot?
No. Claims Ignite works on day one with no HIS connection: the doctor master and tariff load from a spreadsheet and the desk enters the UHID and IP number. Integration removes typing; it is never a precondition for the pilot.
How are roles enforced?
In the database, by row-level security, not only in the user interface. Patient, doctor, desk, admin and advisor roles run today. Desk lead and auditor roles, and mapping roles from your directory groups through SSO, are designed and built during set-up.
What service levels do you propose?
For production: 99.5% monthly availability measured at your edge, P1 first response in 30 minutes and restore in 4 hours around the clock, under 15 minutes of data loss and service back within 4 hours after a failure, and critical security fixes within 72 hours. These are proposed and agreed in the contract.
A 60-minute technical session
Bring your IT and cyber security leads. We bring the architecture and the security review.
A separate architecture and security review answers the questions your teams will ask, and lists what we close before production.