From the OPD Queue to Claim Settlement.
Every Record Linked. Every Decision Yours.
For nursing homes, hospitals, diagnostic labs and clinics — whether you run on a hospital software system or on paper and WhatsApp. GUARDIAN registers patients with their ABHA, turns the reports you already print into national-standard records, prepares pre-authorisations and claims, and follows up abnormal results — with your staff approving every step, and patients approving every share.
See Exactly Where GUARDIAN Fits Into Your Hospital
Your software, printers and people stay as they are. GUARDIAN reads what you already produce, prepares records and claims, and nothing leaves the hospital until a named person approves it.
Which best describes your facility?
Choose yours. In Step 2, the problems that apply to you are marked ✓ — and Step 3 shows how GUARDIAN connects to what you already use.
The problems GUARDIAN solves for hospitals, labs and clinics
Pick a problem to see what happens today, how GUARDIAN fixes it, where your staff stay in control — and what happens in the awkward cases.
The morning OPD queue is typed in by hand — and almost no patient's ABHA is captured.
It's 9:30 on a Monday at Krishna Nursing Home in Guntur. Forty patients are waiting at one counter. Lakshmi, 54, spells her name for the receptionist, who types it — differently from her last visit — into the billing system. Nobody asks for her ABHA, so nothing done for her today can ever be linked to her national health record.
Sound familiar?
- A long morning queue at a single counter
- The same patient under three spellings, in three files
- "Do you have your old file with you?"
- Nothing ABHA-linked to show when a patient or insurer asks
Why it matters
- The queue is the first thing patients judge you on.
- Duplicate files split a patient's history — a doctor can miss an earlier result or an allergy.
- Without a verified ABHA, a record can't be shared through ABDM or counted in any national digital-health scheme.
Where a person decides: the receptionist confirms every match. A patient without an ABHA can create one at the counter — only if she wants to — with an OTP on her Aadhaar-linked mobile.
How Scan & Share works — and what it doesn't do
- Your hospital is listed in the national Health Facility Registry (HFR). We help you register at setup if you aren't already.
- ABDM issues a QR code for each counter. You print it and put it on the desk.
- The patient scans it with her own phone and taps "share". Her verified profile reaches GUARDIAN and she gets a token number.
- No Aadhaar number is ever stored. For a new ABHA, the OTP is encrypted with ABDM's key and passed straight through.
- Scan & Share only registers the visit. Linking today's reports and summaries to her ABHA is a separate step — see "Records stuck on paper".
The current Digital Health Incentive Scheme pays nothing for Scan & Share on its own.
What happens when… — the situations we've planned for
- No smartphone, or no ABHA — registered exactly as today; the ABHA can be added at a later visit
- A child patient — the ABHA and every consent come from the parent or guardian
- An emergency — treatment comes first; registration is completed afterwards by staff
- A family sharing one phone — patients are never matched on phone number — the ABHA number is the key
- An ABHA created with a mobile number only (not KYC-verified) — she is registered, but the file is flagged: records linked to it don't count for incentives
- The same patient scans twice — she gets the same token; no second file is opened
- Your billing system has no connection — GUARDIAN prints a registration slip with your file number for the receptionist
What setup involves: your hospital's HFR registration (we guide it) · ABDM approval for GUARDIAN at your facility · a QR standee at each counter · your receptionists try it with a few patients before go-live.
What we'd measure in your pilot: share of OPD patients with a verified ABHA, minutes per registration at peak hours, and duplicate files opened per week.
For your IT team — how it connects
- Scan & Share: ABDM calls GUARDIAN's registered callback (v3
/api/v3/hip/patient/share); GUARDIAN replies with the token number. - ABHA creation and verification use ABDM's M1 v3 APIs. Aadhaar numbers and OTPs are RSA-encrypted with ABDM's public key and never stored or logged.
- Patient identifiers are replaced with tokens (FPE, NIST SP 800-38G) before any AI model sees them. Healthcare deployments are hosted in an Indian cloud region.
- Going live needs ABDM's functional test, a security audit (WASA) and NHA approval — GUARDIAN completes these once; your facility is then linked.
Discharge summaries and lab reports are printed, filed and forgotten — none of them linked to the patient's ABHA.
Lakshmi's ultrasound report and discharge summary are printed on Thursday and put in her file. Six months later a specialist in Vijayawada asks what the scan showed. She doesn't have the paper, and the specialist can't see it.
Sound familiar?
- Stacks of printed reports and summaries
- Patients coming back for copies
- "Digital records" means PDFs on one PC
- Nothing to show when ABDM record sharing comes up
Why it matters
- Patients lose continuity of care every time they see a new doctor.
- You can't take part in ABDM record sharing — something patients and insurers increasingly expect.
- Only records linked to a KYC-verified ABHA count when national incentive schemes run.
Where a person decides: records staff confirm flagged fields and the patient match before anything is linked — and the patient decides every share from her own ABHA app.
How record sharing works under ABDM
- Your records stay with you. Your hospital becomes a "Health Information Provider": GUARDIAN tells ABDM that a record exists for Lakshmi — not what's in it.
- Another doctor asks. The specialist's hospital requests her records through ABDM.
- Lakshmi decides. She sees the request in her ABHA app and chooses which record types and dates to share, and for how long.
- Only then is anything sent — encrypted end to end for that doctor alone.
- Corrections create a new version. A linked record is never silently changed.
What happens when… — the situations we've planned for
- A handwritten prescription — stored as a scanned-document record and clearly labelled — not turned into typed text the doctor didn't write
- A corrected lab report — the new version is linked and the old one marked as superseded
- A patient without an ABHA — the record stays in your system and can be linked later
- Sensitive results — HIV status, mental-health notes, pre-natal scans — handled under your hospital's confidentiality rules and never included in automated messages
- A medico-legal case — records are kept and access restricted, as the law requires
- The same report printed twice — recognised and linked once
What setup involves: your discharge-summary and report formats · the GUARDIAN Edge Agent on the PC your desk prints from (or WhatsApp photos, with no install) · ABDM approval for your facility · a test on past discharges before go-live.
What we'd measure in your pilot: records linked per month by type, share of patients with a KYC-verified ABHA, and staff minutes per discharge.
For your IT team — how it connects
- ABDM M2 (v3): care contexts linked with
/api/hiecm/hip/v3/link/carecontext; consented requests answered with FHIR R4 bundles (NRCeS profiles), encrypted with ABDM's Fidelius scheme (ECDH Curve25519 + AES-GCM). - Text is read (OCR) inside the Data Privacy Shield. Clinical values stay readable; identifiers are tokenised.
- The Edge Agent is a small signed installer: it captures print jobs, connects outbound only over TLS, and keeps no patient data after delivery.
Your TPA desk retypes every case into insurer and scheme portals — then waits for the queries.
Lakshmi needs a laparoscopic cholecystectomy. If she's covered by a private policy through a TPA, your desk types her diagnosis, the procedure and the estimate into that TPA's portal. If she's covered by Dr NTR Vaidya Seva, the Vaidya Mithra types it all again into the Trust's system and uploads the scans. Two days later a query arrives: "ultrasound report not attached".
Sound familiar?
- A different portal for every payer
- Queries for a missing report
- Patients waiting at discharge for approval
- Weeks between discharge and payment
Why it matters
- Every query delays cash — and a small hospital feels every day of it.
- Retyping errors can mean a rejected or reduced claim.
- The desk is the bottleneck at discharge — the moment patients remember.
Where a person decides: your TPA desk approves every pre-authorisation and claim. For Dr NTR Vaidya Seva, Aarogyasri and PM-JAY, your desk or Vaidya Mithra uploads the prepared pack through their own login — GUARDIAN never submits to those portals.
Two claim routes — and why GUARDIAN handles them differently
- NHCX is the national claims exchange, and many insurers and TPAs have joined it. For them, GUARDIAN sends your approved claim electronically — encrypted so only the payer can read it — and tracks the reply.
- State schemes and PM-JAY run their own portals. Dr NTR Vaidya Seva (Andhra Pradesh), Aarogyasri (Telangana) and PM-JAY's claims system have no route for outside software to submit claims today.
- For those, GUARDIAN prepares a claim pack: the fields in the portal's own order, the documents named and in sequence, and a checklist of what the package needs — so the upload takes minutes and nothing is missing.
- If a payer joins NHCX, the claim simply changes route. Nothing changes for your desk.
- GUARDIAN never stores portal passwords or OTPs.
What happens when… — the situations we've planned for
- The payer sends a query — it goes to the desk with the original claim and documents attached
- Partial approval — the difference is shown to the desk — and to the patient — before discharge, not after
- Extension of stay or a change in procedure — a new pre-authorisation is prepared, so it isn't forgotten
- The patient switches to paying herself — the claim is closed with the reason recorded
- A package needs a specific report — flagged before approval, not after a rejection
- A scheme portal is down — the pack waits; deadline reminders continue
- A diagnosis or package code GUARDIAN isn't sure about — shown as a suggestion only — your desk or coder chooses
What setup involves: the list of payers you work with (and which are on NHCX) · your scheme empanelment details and package lists · NHCX registration for your hospital (we guide it) · a test on past claims before go-live.
What we'd measure in your pilot: minutes per pre-authorisation, queries per 100 claims, and days from discharge to settlement.
For your IT team — how it connects
- NHCX uses the HCX protocol:
/v1/preauth/submitand/v1/claim/submit, with the payer's answer arriving asynchronously on GUARDIAN's callback. Payloads are JWE-encrypted (RSA-OAEP, A256GCM) for the recipient. - Claims are FHIR ClaimBundles following the NRCeS profiles; the callback handler is idempotent on the correlation ID because NHCX retries.
- For scheme portals no submission API is used — GUARDIAN produces the claim pack only. Diagnosis and package codes are suggestions until a named person approves them.
A patient's report comes back abnormal — and nobody notices she never came back.
Lakshmi's haemoglobin is 9.2 g/dL — flagged low. The printed report waits at the lab counter; she was told to collect it "any time". Nobody calls. Three months later she's back, more tired, with the same untreated anaemia.
Sound familiar?
- Uncollected reports piling up at the counter
- Front-desk staff calling patients from a register
- Doctors unaware a flagged result was never seen
- "Your report is ready" calls taking up the afternoon
Why it matters
- A missed abnormal result is a clinical risk — and a hard conversation later.
- A patient who doesn't return is a follow-up visit lost.
- Routine calls use staff time that the front desk doesn't have.
Where a person decides: the doctor's desk decides every follow-up. Messages never contain results or diagnoses — they ask the patient to get in touch.
What happens when… — the situations we've planned for
- A critical value — your lab's existing phone protocol stays in charge; GUARDIAN only adds a reminder that the call was made
- A value GUARDIAN can't read clearly — never treated as normal — it goes to staff
- The patient has opted out of WhatsApp — a call task is created for staff instead
- Sensitive tests (e.g. HIV, pre-natal) — excluded from automated messages entirely
- The patient prefers Telugu — messages go out in the wording your team has approved for each language
What setup involves: your lab's report format(s) · the message wording you approve (English and Telugu) · your WhatsApp Business number · the list of tests that must never be messaged.
What we'd measure in your pilot: flagged results followed up within 14 days, staff calls saved, and uncollected reports at month end.
For your IT team — how it connects
- HL7 ORU^R01 results arrive through the Edge Agent (the OBX-8 field carries the lab's H/L flag), or values are read from printed reports inside the Data Privacy Shield.
- Units are normalised (UCUM) and never re-scaled silently; reference ranges come from the report.
- Patient messages use pre-approved WhatsApp templates; delivery is logged.
Patient data goes to insurers, labs and TPAs — and nobody can say where, or stop it.
Over a year, Lakshmi's reports went to a TPA, an external lab and — through ABDM — a specialist in Vijayawada. Now she asks the hospital to stop sharing her data. The administrator has no list of where it went.
Sound familiar?
- Consent on paper forms in the file
- No central record of who received what
- Requests handled from memory
- No clear answer to "who has my data?"
Why it matters
- From 13 May 2027, the DPDP Act's core duties — notice, consent, withdrawal, erasure and breach reporting — apply to every hospital.
- You'll need to show what was shared, why, and that a withdrawal was acted on everywhere.
- Patients notice when a hospital can answer the question straight away.
Where a person decides: the person your hospital designates for data protection approves every action. Records you're legally required to keep stay kept, with access restricted — and the patient is told why.
Two kinds of consent — and why you need both on record
- ABDM consent is given by the patient in her ABHA app whenever a doctor asks for her records. She can revoke it there, and ABDM enforces that.
- Your hospital's own consent under the DPDP Act covers what you do — messaging, claims, sharing with an external lab.
- GUARDIAN records both in one ledger per patient, so one answer covers every question.
- Withdrawal stops future use. It doesn't undo lawful past use, and medical records you must keep are kept, with access restricted.
- Emergencies come first. The DPDP Act allows processing without consent to respond to a medical emergency involving a threat to life (Section 7).
This explains the design; confirm how it applies to your hospital with your own legal adviser.
What happens when… — the situations we've planned for
- A child patient — consent comes from a parent or guardian, recorded as such
- A request from a deceased patient's family — recorded and routed to your designated person for a decision under your policy
- A medico-legal case — records are retained; the request is answered with the reason
- An ABDM consent expires — records fetched under it are deleted automatically, and the deletion is logged
- A request by phone — staff record it in GUARDIAN; identity is checked before anything is actioned
What setup involves: your consent wording (we provide a starting draft to review with your adviser) · the list of systems and partners patient data goes to · the person you designate for data-protection requests.
What we'd measure in your pilot: requests completed and time to complete, and shares logged against those you know about.
For your IT team — how it connects
- Append-only ledger per patient, fed by every outbound share; ABDM consent notifications update it automatically.
- Retention rules are configuration per record type, so legally required records are never erased by mistake.
- DPDP timeline: Rules notified 13 Nov 2025; Consent Manager provisions 13 Nov 2026; core duties 13 May 2027.
Patients arrive without their earlier reports — so tests get repeated.
Lakshmi sees a physician at your hospital for the first time. Her last blood tests and scan were done in Guntur and Vijayawada; the papers are at home. To be safe, the doctor orders them again.
Sound familiar?
- "Please get these tests done again"
- Bags of papers from other hospitals
- Patients refusing a repeat scan
Why it matters
- Repeat tests cost the patient money and time.
- Missing history can hide what matters.
- "We found your last scan" is a service patients remember.
Where a person decides: the patient approves every request in her own app, and the doctor makes every clinical decision. The summary never offers a diagnosis.
What happens when… — the situations we've planned for
- She says no, or ignores the request — nothing is fetched or stored
- The consent period ends — fetched records are deleted automatically
- A source hospital doesn't respond — the summary says so — no silent gaps
What setup involves: ABDM approval for GUARDIAN to request records for your facility · the purposes your doctors will use · a trial with consenting patients.
What we'd measure in your pilot: repeat tests avoided (doctor-reported) and consent requests approved versus sent.
For your IT team — how it connects
- ABDM M3 (v3):
/api/hiecm/consent/v3/request/init, consent notifications, then/api/hiecm/data-flow/v3/health-information/request. - Received bundles are decrypted with GUARDIAN's key pair, identifiers tokenised, and deleted when the consent expires.
NABH certification stalls on hundreds of documents one quality manager has to write.
Krishna Nursing Home wants NABH Entry Level Certification to strengthen its insurer empanelments. The quality manager has a folder of old policies, photos of registers, and a consultant's quote.
Sound familiar?
- Policies that don't reflect how the hospital really works
- A consultant's invoice for templates
- Accreditation plans that keep slipping
Why it matters
- NABH helps with insurer empanelment and patient trust.
- The documentation burden usually falls on one person.
Where a person decides: the quality manager decides what's needed and approves every document.
What happens when… — the situations we've planned for
- The standards are revised — the gap check is re-run against the new edition
- A register must be kept on paper — listed as a checklist item, not generated
What setup involves: your existing policies and registers · the scope you're applying for.
What we'd measure in your pilot: standards covered and weeks to readiness.
For your IT team — how it connects
- Standards kept as versioned configuration; drafts cite the source documents they were built from.
- Contains little patient data; any that appears is tokenised.
Your hospital software already holds the data — but it gets printed and read again.
Your HIS records every admission, result and charge. To get anything out, staff print it — and the vendor quotes months for a custom interface.
Sound familiar?
- Printing data that already exists digitally
- Vendor quotes for every new interface
Why it matters
- Double handling of the same data.
- Staff time on work software could do.
Where a person decides: your IT person or HIS vendor approves the message mapping, and every downstream record or claim still goes through its own approval.
What happens when… — the situations we've planned for
- The HIS corrects or merges a patient — GUARDIAN updates the record — never duplicates it
- The internet connection drops — messages wait securely on the agent and are sent when it's back; you're alerted if the queue grows
What setup involves: HL7 export enabled by your HIS vendor · a PC or small VM for the Edge Agent · a test with real messages.
What we'd measure in your pilot: messages processed without error and mapping exceptions per week.
For your IT team — how it connects
- Mirth Connect MLLP listener on the Edge Agent; ACK/NAK per message; outbound TLS 1.3 (optionally IPsec VPN).
- Per-hospital mapping profile; unknown codes queued for review.
You don't know what the government's digital-health incentive should pay you — or whether it will continue.
Krishna Nursing Home heard that linking records to ABHA earns an incentive. Nobody can say how much of this month's work qualifies, or what should be paid.
Sound familiar?
- Unsure which records qualify
- Surprise at the payout — or none
Why it matters
- The current terms are short-term. NHA's Digital Health Incentive Scheme (Corrigendum 7) covers April–September 2026, subject to funds.
- The rules are specific: KYC-verified ABHAs only, per-patient caps, and a monthly baseline.
Where a person decides: your accounts team checks every figure; claims on the incentive portal are made by your staff.
What happens when… — the situations we've planned for
- The scheme isn't extended — the tracker is switched off; past reports are kept
What setup involves: nothing extra — it runs on records GUARDIAN already links.
What we'd measure in your pilot: difference between expected and received.
For your IT team — how it connects
- Scheme rules are configuration, versioned per corrigendum.
How GUARDIAN connects to your facility
No Hospital Software Needed. Your Printer and WhatsApp Are Enough to Start.
Pick a Template. Connect It. Teach It Your Rules.
Every problem on this page comes as a designed workflow template for hospitals, labs and clinics, set up with you in a pilot. You do not start from a blank page: choose one, give it your name, connect your systems and upload your own rules. Your team approves every important step.
- ChoosePick a template for your problem
- RenameGive it your own name
- ConnectLink your systems through NEXUS
- Set the startA new record, a file, a message or a time
- TeachUpload your rules, letters and FAQs to its expert
- TestRun it on your past cases
- ShadowIt runs on real work; your team checks every step
- LiveSteps go automatic only once your team agrees they are right
Every template has its own expert: the SME Agent
Each workflow step can ask its SME Agent (subject-matter expert) a question, such as "which documents does our policy accept here?". It answers from your material only, and always shows where the answer came from.
If it is not sure, it says so, and the step waits for your team. A step moves on by itself only when the rules are met and the confidence is high enough. Important decisions always go to a person.
- Current rulesRegulations and deadlines, kept up to date by Guideazy, with the date each rule starts
- Your policiesYour SOPs, limits and ways of working
- Your letters and formsThe wording and formats you already use
- Your historyPast tickets, customers and orders, read from your systems with personal details hidden
- Your team's decisionsWhat your approvers agreed or changed, so it learns your way
- Nothing sharedEach customer's expert is separate. The AI works on tokenised data, not real names or numbers.
Front-Desk ABHA Registration (Scan & Share)
Receives the patient's verified profile when they scan the hospital's QR with their ABHA app, gives them a queue token, finds or creates their hospital file for the receptionist to confirm, and helps patients without an ABHA create one at the counter.
What it needs
- Connects to
- ABDM gateway (Scan & Share callback), ABHA service (M1), Hospital patient index (HIS or GUARDIAN's own)
- Your team approves
- Receptionist
- Its expert learns from
- Front-desk registration SOP, Patient ID and duplicate-file policy, Counter and department list with HFR details and 1 more
Clinical Documents to ABHA-Linked Records
Turns the discharge summaries, lab reports and prescriptions the hospital already produces into national-standard FHIR records, puts each on the records desk's worklist for approval, links approved records to the patient's ABHA, and sends them encrypted when the patient approves a request.
What it needs
- Connects to
- Edge Agent — print capture (Tier 1), Edge Agent — HL7 (Tier 2), WhatsApp / email / upload (Tier 0), Hospital patient index and 1 more
- Your team approves
- Medical records staff
- Its expert learns from
- Medical records SOP (what is filed, by whom, when), Sample of each document template the hospital prints, Department and doctor code list and 1 more
Pre-Authorisation & Claims (NHCX + Claim Pack)
Collects the case, checks the payer's document list, suggests codes and amounts for the TPA desk to approve, then submits through NHCX where the payer is on it — or prepares a complete claim pack for staff to upload to PM-JAY TMS, Dr NTR Vaidya Seva or Aarogyasri.
What it needs
- Connects to
- Edge Agent / upload, Patient coverage (desk entry or HIS), NHCX participant registry
- Your team approves
- TPA desk, Billing manager
- Its expert learns from
- Payer and TPA agreements (tariffs, packages, document lists), TPA desk SOP, Past query and rejection letters and 1 more
- Where there is no API
- GUARDIAN prepares the work; your team completes that step by hand, and it is recorded.
HIS Event Intake (HL7 Edge Agent)
Connects a hospital system that already sends HL7 v2 to GUARDIAN once, through the on-site Edge Agent, so admissions, discharges, results and charges start the other templates automatically — no printing or photos.
What it needs
- Connects to
- HIS (ADT)
- Your team approves
- Hospital IT / records lead
- Its expert learns from
- HIS vendor's HL7 interface specification, Code lists (departments, doctors, services, tests), Sample messages for each event type
Prior Records with Patient Consent (HIU)
When a doctor asks, requests the patient's earlier records from other providers through ABDM; only if the patient approves in their own app does GUARDIAN fetch them, list them for the doctor with links to each source, and delete them on the consent's expiry date.
What it needs
- Connects to
- Doctor / staff request, ABDM gateway (M3)
- Your team approves
- Requesting doctor, Patient
- Its expert learns from
- Hospital policy on requesting outside records, Consent request wording in patient languages
Abnormal Result Follow-Up
Puts every flagged lab result on the ordering doctor's worklist; when the doctor asks for a follow-up, GUARDIAN invites the patient back on WhatsApp — without mentioning results — and reminds staff if the patient has not booked.
What it needs
- Connects to
- LIS (HL7 ORU) or lab print / photo, Hospital patient index
- Your team approves
- Ordering doctor (or covering doctor)
- Its expert learns from
- Lab's critical-value phone protocol (for reference; unchanged), Follow-up booking SOP, Covering-doctor rota
NABH Entry-Level Documentation Assistant
Maps the policies and registers the hospital already has to NABH Entry Level standards, shows each gap with evidence, and drafts missing documents from the hospital's own facts for the quality manager to sign off.
What it needs
- Connects to
- Email / WhatsApp / upload, NABH standards (reference)
- Your team approves
- Quality manager, Medical superintendent
- Its expert learns from
- Existing policies and SOPs, Hospital facts sheet (beds, departments, services, staff roles), Document template / letterhead
Consent & Sharing Ledger
Records every place a patient's data goes and why, as a side effect of the other templates, and lets the hospital answer "who has my data?" for any patient in one view.
What it needs
- Connects to
- ABDM gateway
- Your team approves
- Designated data-protection person
- Its expert learns from
- Hospital privacy notice and consent forms, List of external recipients (labs, TPAs, insurers)
Patient Data Requests & One-Click Erasure with Legal Holds
Verifies the patient, lists the data held about them, applies the hospital's retention rules (medical records usually must be kept), and — after approval — erases what may be erased from GUARDIAN in one click by destroying the patient's personal key, keeping held records under a separate key until their retention ends.
What it needs
- Connects to
- Request channels
- Your team approves
- Designated data-protection person, Security lead (CISO or equivalent)
- Its expert learns from
- Hospital privacy notice and retention schedule, Data request / grievance SOP, Response letter templates
DHIS Incentive Tracker (only if DHIS continues)
Each month, counts ABHA-linked records that qualify under the DHIS rules in force, applies caps and the baseline, and gives accounts an expected amount to check against the DHIS portal. Switched off when no rule set covers the month.
What it needs
- Connects to
- Canonical Health Record, DHIS rule set
- Your team approves
- Accounts
- Its expert learns from
- DHIS portal statements received (for comparison)
10 templates. Each one is fully designed and documented for our engineering team. We set it up with you in a pilot, and it starts in shadow mode before any step runs on its own. Some steps, like final approvals, never run on their own.
The Questions Hospital Owners Ask. Straight Answers.
Healthcare should be careful with new software. These are the concerns we hear most — and how GUARDIAN is designed around them.
How the 4 Pillars Work Together — Healthcare
GUARDIAN Doesn't Diagnose, Code or Submit on Its Own. Your Team Does.
In a hospital, the cost of a wrong automated decision is too high. So GUARDIAN is built to prepare and flag — and to stop for a person every time.
What a pilot looks like
You don't have to change your hospital at once. Start with one problem, prove it on real work, then decide.
Anything that touches ABDM or NHCX has a few extra steps
ABDM and NHCX connections follow NHA's standard certification — functional tests, security audit and approval. We manage this for you; founding hospitals go live on them as soon as it completes.
Problems that don't touch ABDM or NHCX — abnormal-result follow-up, NABH documentation, the consent ledger — can start without these steps.
Less Typing at the Desk. Faster Claims. No Patient Left Without Follow-Up.
We're looking for our first founding hospitals. Start a 14-day free trial with follow-ups, the consent ledger, NABH documentation and claim packs — we'll add your ABDM and NHCX connections as part of onboarding.
Hosted in India. Built for the DPDP Act and ABDM's consent model. GUARDIAN never diagnoses, and nothing is submitted without a named person's approval.