Health, home
For developers: Deedglass for Developers Talk to us
Talk to us about a pilot Deedglass for Developers

Bring AI into your wards. Keep a clinician in charge.

For hospital chains and single hospitals. AI now drafts discharge summaries, notes and orders. Deedglass holds the ones that matter until a clinician approves. It checks what your HIS saved, and keeps a sealed record for your quality team.

Talk to us See how it works

Try the 15-minute hospital pilot: npx deedglass health pilot. Synthetic data, on your own machine, no Docker. Then read the hospital IT review pack with your security team.

Try it: sign off a summary, estimate what unnoticed AI mistakes could cost your hospital, or see FHIR writes where the server said success and saved something else.

  • Makes no clinical decisions
  • Runs on your own servers
  • Start with one ward

Where AI writes

What waits for a person, and what doesn’t.

These are the free healthcare rules that come with Deedglass.2 Your hospital can change them, and write the same kinds of rules for systems that don’t use FHIR.

  • Discharge summaries

    An AI drafts the summary from the notes. A final summary waits for a clinician before it is saved.

    Waits for a clinician
  • Medicine and lab orders

    An AI scribe drafts orders on the ward round. They wait for a clinician too.

    Waits for a clinician
  • Allergies and the problem list

    Changes to allergies and the problem list wait for a clinician.

    Waits for a clinician
  • Routine entries

    A blood pressure reading or a draft note is saved at once, then read back and checked.

    Saved, then checked
  • Bills and claims

    Changes to claims and other billing records need two different people.

    Two people
  • Deleting a record

    An AI can’t delete a clinical record. A mistake is fixed with a new version.

    Blocked

AI is already at work in Indian hospitals. Google Cloud says Manipal cut nurse handoff time from 90 to 20 minutes with generative AI, live in 23 of its hospitals.1 Manipal doesn’t use Deedglass.

Clinician approval

A change waits. A clinician decides. The record says who.

The request reaches the clinician by email, in the Deedglass console, or in Slack if you use it. Only a person can approve, and nothing is saved until they do.3 Each record then says who approved and when.9

An illustration with made-up data. A medication order an AI drafted waits for a clinician. It goes to the doctor’s approval request, the doctor presses Approve, and only then does the order reach the patient record, marked with who approved it and when.

Try it

You are the consultant. Sign off the summary, or don’t.

An AI has drafted a discharge summary. Approve it, decline it, or let it expire. Then add a problem, and see what the check reports. The approval adds a step before discharge, and your rule sets how long it can wait.

A simulation. Made-up patient, people and ids. It runs only in your browser and sends nothing anywhere.

Try a setting
Patient recordWard 2 · Bed 5 · test patient

Discharge summary

Drafted by AI

By the AI discharge assistant, for Dr. A. Rao, ward round

Diagnosis
Pneumonia, treated
Medicines
Amoxicillin, 5 days
Follow-up
OPD in 2 weeks
Status
Final

Held: waiting for a clinician

What the HIS holds nowNothing yet. The draft is held.

Approval needed

You are Dr. N. Shah, consultant

Discharge summary

From the AI discharge assistant

Expires in 2 hours

Diagnosis
Pneumonia, treatedsha256:c084…46e6
Medicines
Amoxicillin, 5 dayssha256:f50d…9972
Follow-up
OPD in 2 weekssha256:6d86…865a
Status
Finalsha256:f4ed…5523

Rule: Final notes need a clinician

Approve or decline. Both are fine answers here.

What Deedglass did

  1. Your rulesHeld under the rule “Final notes need a clinician”.
  2. The clinicianWaiting for you to decide.
  3. SavingNothing goes to the HIS until you approve.
  4. The checkRuns after saving: it reads the record back.
  5. Sealed recordMade when the request ends, whatever the answer.

The sealed record

Simulated

It fills in when the request ends.

Record
Not yet
What
Not yet
AI agent
Not yet
Acting for
Not yet
Rule
Not yet
Decision
Not yet
Asked
Not yet
Decided
Not yet
Saved in
Not yet
Check
Not yet
Patient
Not yet
Request
Not yet
Result
Not yet
Chain
Not yet

It holds ids and fingerprints, not the patient’s details. Fingerprints of short values, like a UHID, can be guessed until salting ships, so keep identifiers out of what agents send where you can. “Saved as approved” means the record says what was approved. It is not a clinical check.

A second example

When an AI tries to delete a note.

Clinical notes are never deleted under the healthcare rules that come with Deedglass. A mistake is fixed with a new version, and the old one stays in the history.2

  1. 1

    The AI asks to delete a note.

    Maybe it thinks the note is a duplicate. Maybe it is wrong.

  2. 2

    Deedglass blocks it.

    The request never reaches the record system. The attempt itself is recorded.

  3. 3

    It is corrected with a new version.

    A clinician approves the fix. Both versions stay, so anyone can see what changed and when.

For your IT team

Does it fit your HIS?

Deedglass works with what your AI tools write to. Here is what it can sit in front of today.

  • A FHIR API that accepts writes

    Each write is read back and compared, field by field (Checked).4 On HAPI FHIR 8.x and Medplum 5.x running on Postgres, the check reads the server’s own change log too (Proven).4

    Works today

  • Your HIS vendor’s JSON API

    If your HIS has a web API that accepts writes but no FHIR, Deedglass calls it through tools you define and reads back the fields you name (Checked).5 On a vendor’s HIS, expect Checked, not Proven.

    Works today

  • Your own app on Postgres

    Deedglass checks each write against Postgres’s own change log (Proven), and can undo it after a person countersigns.6

    Works today

  • MCP servers

    Your rules decide each call by tool name.7 The depth of the check depends on what sits behind the server.

    Works today

  • SQL Server, Oracle, MySQL, HL7 v2

    There is no connector for these yet.7 For MySQL, a write can be compared with a Debezium change feed of what the database committed (Proven · via Debezium), run beside an action rather than by the gate.8 If your HIS or integration engine has a web API in front of them, use that route instead.

    How hospital IT connects SQL Server and Oracle EHRs via integration engines →

    Not today

  • AI built into your HIS

    An AI feature inside your HIS that writes there directly doesn’t pass through Deedglass, so Deedglass can’t see it.

    Why database change log checks are needed for agent actions →

    Not covered

Deedglass sits only in front of the AI tools you send through it. Staff using the HIS don’t pass through it. Tell us your HIS and we’ll say plainly what fits.

What your AI vendor must do

Send its writes to Deedglass instead of straight to the HIS. If a SaaS tool writes to your HIS on its own, Deedglass can’t see those writes. Ask the vendor whether it can send them through a gate like Deedglass.

Three questions for your HIS vendor

  • Is there a web API that accepts writes?
  • Can a saved record be read back by its id?
  • Is there a test system we can use first?
The technical detailFHIR, SMART sign-in, Postgres-backed servers, PHI mode, self-hosting and the exact limits. Show detailsHide details

  • Checked and Proven, in plain words

    Checked: after a write, Deedglass reads the record back through the server’s API and compares the fields. Proven: it also reads the database’s own change log, so it sees exactly what the transaction committed, including anything else it changed. Claimed is the tool’s own report, with no check.6

  • Approvals: who can approve, and what they see

    Only a person can approve: in the Console, through their own one-use emailed link, or with a signed Slack click; one or two approvers per rule, one refusal is final, and an agent can never approve itself.3 An approval nobody decides expires after the time the rule sets (30 minutes by default, 1 minute to 7 days), and nothing runs.3 By default the person an agent acts for may decline but not approve its request; an owner can allow it, for example so a doctor approves the AI’s draft of their own order. Without PHI mode the approval page shows the request; with PHI mode on it shows field names and digests, so the approver reviews the values where the draft was made.23 Sign-in is by emailed link; there is no SSO or SCIM yet.16 A rule can name several people, and any one of them can approve; that is how a rota works today.17 Clinician approver groups and SSO are coming, with no date promised.2

  • FHIR connector (beta), with SMART sign-in

    Puts a FHIR R4 server’s REST API behind Deedglass as one tool per interaction (read, vread, search, history, create, update, patch, delete) on the resource types you list; a call naming any other type is refused before anything is sent.4 It signs in with SMART Backend Services, tested so far against a local stand-in authorization server.4

  • Read-back checks (Checked)

    Each write is read back at the version the server reported and the fields the agent sent are compared one by one, after dropping what the server adds on its own. A conditional create answered with an existing resource is Doesn’t match.4

  • Proven checks on HAPI FHIR and Medplum on Postgres

    On HAPI FHIR JPA 8.x and Medplum 5.x running on Postgres, a write can be Proven: Deedglass reads the FHIR server’s own change log and checks that the transaction holding the version the server reported is what the agent sent, and nothing else.4 A write to the same resource by another client while the call is open is reported as out_of_band.4 Content is kept only as keyed digests of each field, so a difference names the field, never its value.4

  • The healthcare-fhir rules pack (free)

    Denies deletes of clinical records (they are corrected with a new version), holds orders and medication changes, allergies, the problem list and final notes for a clinician’s approval, needs two different people for claims and other billing records, keeps coverage read-only and has every other write read back. No rule judges whether a clinical change is right.2 Break-glass use is an agent labelled for it, and its actions are recorded like any other.

  • PHI mode

    Once an action is sealed and its checks are done, Deedglass keeps ids and digests of its request and result, not their content, and approval requests show argument names and digests from the start.23

  • AuditEvent and Provenance export

    Records export as FHIR R4 AuditEvent, shaped to the IHE Basic Audit Log Patterns profiles, and Provenance, shaped to the HL7 AI Transparency on FHIR ballot’s AI Provenance profile, with ids and digests instead of clinical content.21

  • Health-tech apps on Postgres, any FHIR server through REST, MCP servers

    Apps that keep data in their own Postgres get Proven checks and undo after a person countersigns.6 Any FHIR R4 server can also sit behind the REST connector with field read-backs.5 Existing MCP servers go behind your rules by tool name.

  • Self-hosted: one binary next to your own Postgres

    It sends us nothing by default, so if you run it in India, your records and action history stay on your servers in India.9 Approvals (one or two per rule), one switch that stops every agent, and records anyone can check offline with your public key.9

Where it sits

  1. AI agent or scribecalls Deedglass’s tools instead of the record system
  2. Deedglass, on your serversrules, approvals, the check, sealed records; your Postgres
  3. Your record systema FHIR API (hosted anywhere) or your own app on Postgres

The agent sent

POST /fhir/AllergyIntolerance
If-None-Exist: identifier=…

The server answered

200 OK

The agent reported

“Allergy recorded.”

What the server stored

Nothing new. A matching record already existed.

Said and stored differ
In FHIR R4, a conditional create that matches one existing resource answers 200 and creates nothing.28 Servers should, not must, honour a request to send back what they stored.28 An illustration of the specification, not a recorded run.

Limits, plainly

  • FHIR writes are Proven only on HAPI FHIR JPA 8.x and Medplum 5.x on Postgres; the binding rests on the version the server reported, which is weaker than the marker the Postgres connector writes. Creates, updates and patches are Proven on both; deletes on HAPI only.
  • HAPI FHIR 7.x and older, deletes on Medplum, other FHIR servers and managed EHRs are Checked.
  • SMART sign-in is tested against a local stand-in, not yet against a vendor sandbox.
  • Deedglass only sees what goes through it, and it needs a FHIR API that accepts writes, or your own app on Postgres. Tell us your HIS and we’ll say plainly what fits.
  • The REST connector can’t set FHIR’s conditional headers (If-None-Exist, If-Match) and its read-back doesn’t know FHIR’s version rules; the FHIR connector does.
  • In the pack, clinician approvers are named people until approver groups ship, and ABDM consent artefacts aren’t checked.
  • PHI mode is off until you switch it on. While an action waits for an approval or a check, its payload is held; digests of short values, like a record number, can be guessed (they aren’t salted yet); field paths and ids are kept in clear.
  • Without PHI mode, full requests are kept until you clear them (90 days by default); sealed records are never cleared.
  • The export’s profile checks are Deedglass’s own offline checker, not a validator loaded with the BALP and AI Transparency packages.
  • No SOC 2 report or ISO 27001 audit yet, no SSO yet, and no published latency figures for the healthcare connectors.

Security problems: see how to report one. Questions: hello@deedglass.com.

For doctors and nurses

You stay the one who decides.

AI can save you time on notes and orders. Deedglass makes sure the changes that matter wait for you.

  • Important changes wait for a clinician.

    Orders, medicines, allergies, the problem list and final notes that an AI sends through Deedglass are held until a clinician approves them.2

  • You choose what needs a person.

    Your hospital decides which changes wait for a clinician. Routine entries, like a blood pressure reading, are saved and checked without asking anyone.

  • Approve where you already are.

    Approve or decline by email or in the Deedglass console, or in Slack if you use it, on your phone or computer. Only a person can approve, never an AI or a script.3

  • It doesn’t replace sign-off in your HIS.

    If your HIS asks for sign-off, you still sign there. Deedglass’s approval comes first, before the AI’s change reaches the record, and it keeps a record of who approved it.

  • An AI can’t delete a note through Deedglass.

    A correction is saved as a new version. The old version stays, so the history is complete.

  • Your clinical judgement stays yours.

    Deedglass doesn’t check whether a dose or a diagnosis is right. It checks who approved a change and whether the record says what the AI claimed.

For hospital leaders

Bring in AI with clear lines of responsibility.

For the CEO, COO, medical superintendent and medical director: know what every AI did, who approved it, and how to stop it.

  • See who did what.

    Each record names the AI that acted, the person it acted for, the rule that applied and the person who approved.

  • One switch stops every AI agent.

    If something looks wrong, an admin can stop every agent at once. New actions are refused within 2 seconds.14 Only an owner, such as your CIO, can start them all again.15

  • Patient data stays with you.

    Deedglass runs on your own servers and sends us nothing by default. If you run it in India, your records stay on your servers in India.9 Approval messages go only through the email or Slack you set up; with PHI mode on, they carry field names and fingerprints, not clinical content.23

  • It makes no clinical decisions.

    It doesn’t diagnose, recommend treatment, prioritise patients or change what an AI asks for. It decides whether an action may run under your rules, records it, and checks what the system stored.

For quality and audit teams

Evidence you can show an auditor.

Every AI action leaves a sealed record. Your auditor can check the records on their own computer, with your public key, without asking us.

  • One record per action.

    What was asked, which rule applied, who approved it, when, and whether the record matched.

  • Changes show.

    Each record is signed and linked to the one before it, so changing or removing an earlier record shows when the chain is checked.

  • Find a record later.

    Filter every AI action by date, tool, decision, check result, or the person the AI acted for.19 Deedglass doesn’t search by patient: find the patient in your HIS, then match the record’s id and time. The FHIR export names the record and version each action touched.21 There is no PDF or spreadsheet report yet.

  • Rule changes are recorded too.

    Each change to the rules in force is sealed: who made it, which version and why.20

  • Formats other systems read.

    Records export in the standard formats health systems use for audit logs and the history of a record, with ids and fingerprints instead of clinical content.21

More rules the records help you show

For ABDM, NABH, the DPDP Rules and data in India, see In India, in plain words.

India

ICMR AI guidelines (2023) and India AI Governance Guidelines (2025)

What it asks
ICMR asks for human oversight and manual override for AI that could cause severe or bodily injury, and regular audits.25 The India AI Governance Guidelines, which are not legally binding, call for audit trails and human-in-the-loop checks at critical decision points.26
What Deedglass helps you show
Where a person approved, declined or stopped an AI, and when.
What it doesn’t cover
Testing the AI model, its training data or its clinical accuracy.
If you also serve patients in the US: HIPAA
US

HIPAA, 45 CFR 164.312(b), audit controls

What it asks
Audit controls that “record and examine activity” in systems that contain or use ePHI.27
What Deedglass helps you show
Records of what each AI agent did in those systems, that you can search and examine.
What it doesn’t cover
Activity outside Deedglass, and staff access inside the EHR.
US

HIPAA, 45 CFR 164.312(c), integrity

What it asks
Protecting ePHI from improper alteration or destruction, and an addressable way to confirm it hasn’t been altered.27
What Deedglass helps you show
Which AI writes were checked against what the system stored, and which didn’t match, in linked, sealed records.
What it doesn’t cover
Writes made by other routes, and errors inside the EHR itself.

These duties belong to the hospital, insurer or developer. Deedglass produces records you can use as evidence. Using it doesn’t, by itself, meet any law or standard.

Who gets what

What each team gets.

CEO and COO

  • See which AI did what, for whom, under which rule, and who approved it.
  • Stop every AI agent with one switch. New actions are refused within 2 seconds.14 Only an owner, such as your CIO, can start them all again.15
  • Start small: one hospital, one workflow, test data first.

Medical superintendent and doctors

  • Approve or decline in the Deedglass console or through a one-use emailed link, or in Slack if you use it. WhatsApp isn’t a channel.3
  • A rule can name several doctors, and any one of them can approve. That is how a duty rota works today.17 Groups, such as the doctors on duty, are coming.2
  • If your HIS also asks for sign-off, the doctor signs there too. Deedglass’s approval comes first, before the AI’s draft reaches the HIS. With PHI mode on, the doctor checks the values in the draft, then approves.23
  • It never judges whether a dose or a diagnosis is right.

Quality and the medical records team

  • Filter every AI action by date, decision, check result, or the person the AI acted for.19 There is no search by patient, and no PDF or spreadsheet report yet.
  • Each change to the rules in force is sealed: who made it, which version and why.20
  • Records export as FHIR AuditEvent files, and anyone can check the sealed records offline.21

IT

  • It runs on your own servers with your own Postgres database, and sends us nothing by default.9
  • If Deedglass is down, AI actions that go through it don’t run until it is back.16 There is no high-availability guide or sizing figure yet; we size it with you in the pilot.
  • Sign-in is by emailed link, with no SSO yet.16 SSO is coming.2 Your team can run its own security test on it, since it runs on your servers.
Terminal output from Deedglass 0.10.0: deedglass lockdown on with the reason Ward pilot, a sealed record, then deedglass lockdown status listing what still needs setting up, such as a second admin and a connector label for each agent. Terminal output from Deedglass 0.10.0: deedglass lockdown on with the reason Ward pilot, a sealed record, then deedglass lockdown status listing what still needs setting up, such as a second admin and a connector label for each agent.
For IT: lockdown on, then its status, from a real run on demo data. The status lists what is still missing for the strictest setup.
What lockdown changes, in full
  • Lockdown mode, from Deedglass 0.9.0, is one switch for the strictest setup. Every AI write waits for a person, even when the rules allow it; a high-risk write needs two different people, and every approval expires within 15 minutes.24 DROP, TRUNCATE, schema and permission changes, and UPDATE or DELETE without a WHERE never run through the native Postgres connector.24
  • In lockdown, each AI agent reaches only the one connector it is labelled for.24 After an action ends Can’t check, that agent’s writes are refused until a person acknowledges it; reads still run.24 Turning lockdown off needs two different owners or admins, and both steps are sealed.24

Who is responsible stays the same. A sealed record shows who approved what, and when. It doesn’t move responsibility away from the hospital, the clinician or the AI vendor. Ask your own lawyer how you use it. Nothing here is legal advice.

Chains and single hospitals

Start with one ward, wherever you are.

A hospital chain

Start in one hospital, on one workflow. Then copy the rules to the next one. Each hospital can run its own Deedglass next to its own HIS, or you can run one for the group, so one stop switch covers every hospital in it. Tell us how your HIS is set up and we’ll plan it with you.

A single hospital

Deedglass is one program and a Postgres database, on a server you choose.9 Your IT team runs it. We help set the rules and check in each week during the pilot.

If something goes wrong

The questions to ask first.

  • Nobody approves in time.

    The request expires and nothing is saved. You choose how long it waits, from one minute to seven days.3 A webhook can tell your own systems, so a nurse or the ward desk follows up.18

  • The HIS saved something else.

    The check says “Doesn’t match” and names the line.4 Your team decides what to do next.

  • Deedglass is down.

    AI actions that go through it don’t run until it is back. It fails closed instead of letting them through.16 Your staff keep working in the HIS as usual.

  • You need to stop every AI agent.

    One switch refuses every agent’s new actions within 2 seconds. An action a record system has already received still happens.14

  • An AI tries to delete a record.

    It is blocked under the healthcare rules, and the attempt is recorded.2

  • Someone edits an old record.

    Each record is signed and linked to the one before it, so changing or removing an earlier record shows when the chain is checked.9

In India

ABDM, NABH, DPDP and your data, in plain words.

ABDM consent

What it asks
ABDM’s consent manager is a gateway for digital health data. It makes sure the person agrees to every exchange of their data.10
What Deedglass helps you show
A record of each AI action that goes through Deedglass: which record, under which rule, and who approved it.
What it doesn’t do
Deedglass isn’t part of the ABDM network. It doesn’t check ABDM consent today.2 Your ABDM software still does that.

NABH digital health standards

What it asks
Element DIS.2(d), at the Achievement level, asks for a digital system that “captures the audit trails of each transaction”.11
What Deedglass helps you show
A record for each AI action, with who approved it and what the check found.9
What it doesn’t do
It adds to your HIS audit trail for AI actions. It doesn’t replace it, and it doesn’t see what staff do in the HIS. NABH accredits hospitals, not software.

DPDP Rules: logs for a year

What it asks
The rules ask for logs, monitoring and review, and for logs to be kept for one year. These parts start eighteen months after the rules came out on 13 November 2025, so in May 2027.12
What Deedglass helps you show
Sealed records are never cleared, so they cover the year and more. You choose how long full requests are kept, from 1 to 3,650 days.9 Keep those only as long as you need them.
What it doesn’t do
Consent, notices to patients, breach reports and the encryption of your own data.

Data in India, on your servers

What it asks
CERT-In asks many organisations to keep system logs for a rolling 180 days, within India.13
What Deedglass helps you show
Deedglass runs on your own servers and sends us nothing by default. If your servers are in India, your records stay in India.9
What it doesn’t do
Where your HIS, email or Slack keep data. Without PHI mode, approval emails carry the request through the email service you chose.

These duties belong to the hospital, insurer or developer. Deedglass gives you records you can use as evidence. Using it doesn’t, by itself, meet any law or standard.

A pilot

How a pilot runs.

No hours or results are promised. Design partners help set the plan.

  1. 1
    Pick one workflow

    For example, AI-drafted discharge summaries on one ward. Name the clinicians who approve.

  2. 2
    Set it up on your servers

    Your IT team runs Deedglass next to the HIS, on test data first. We set the rules with you.

  3. 3
    Run it and review

    We check in every week and fix what gets in your way. You see every record it made.

  4. 4
    Keep it or leave

    Switch it off at any time. Your sealed records stay with you, and anyone can check them without us.

Plainly

What it is not.

  • No clinical decisions.

    It doesn’t diagnose, recommend treatment, prioritise patients or change what an AI asks for.

  • Only what goes through it.

    An AI built into your HIS that writes there directly isn’t covered.

  • Not audited yet.

    We don’t have a SOC 2 report or an ISO 27001 audit yet.9

  • Patient data stays out of records only with PHI mode.

    Switch PHI mode on for real patient data. Then records keep ids and fingerprints, not the content. Fingerprints of short values, like a UHID, can be guessed until salting ships.23

  • One founder.

    You deal with the founder directly. Everything Deedglass Health uses today is in the free, open-source core, so you can keep running it without us.22

  • What you pay.

    Nothing. Every feature is free while we grow, and design partners get a free pilot with a direct line to the founder. Paid support, SLAs and a hosted version for organisations come later; anything free today stays free for hospitals that run Deedglass themselves.

A one-page brief for hospital leaders

What it does, what it doesn’t, what works today and how a pilot runs. For your CEO, medical superintendent, quality or IT head.

Download the brief (PDF) Read it as a web page

Try it on one of your wards.

Tell us your hospital, your HIS, the AI tools you use, and the workflow to start with.

Become a design partnerhello@deedglass.com

Hospitals and teams that need help with setup, support or a pilot: talk to us.

Sources

  1. 1Google Cloud: How Manipal Hospitals sped up nurse handoffs · cloud.google.com · checked 19 October 2026
  2. 2Deedglass docs: the healthcare-fhir policy pack · docs.deedglass.com · checked 19 October 2026
  3. 3Deedglass docs: Approvals · docs.deedglass.com · checked 19 October 2026
  4. 4Deedglass docs: the FHIR connector · docs.deedglass.com · checked 19 October 2026
  5. 5Deedglass docs: Use Deedglass with a FHIR server today · docs.deedglass.com · checked 19 October 2026
  6. 6Deedglass docs: Check levels · docs.deedglass.com · checked 19 October 2026
  7. 7Deedglass source: docs/CONNECTORS.md · github.com · checked 19 October 2026
  8. 8Deedglass source: docs/WITNESS_DEBEZIUM.md · github.com · checked 19 October 2026
  9. 9Deedglass docs: Records and the record chain · docs.deedglass.com · checked 19 October 2026
  10. 10ABDM: Health Information Exchange and Consent Manager · abdm.gov.in · checked 19 October 2026
  11. 11NABH: Digital Health Standards for Hospitals, 2nd Edition (September 2025) · nabh-portal-live.s3.ap-south-1.amazonaws.com · checked 19 October 2026
  12. 12MeitY: Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E)) · meity.gov.in · checked 19 October 2026
  13. 13CERT-In: Directions under section 70B(6), 28 April 2022 · cert-in.org.in · checked 19 October 2026
  14. 14Deedglass docs: Stop and Stop all · docs.deedglass.com · checked 19 October 2026
  15. 15Deedglass source: docs/STOP.md, who can stop and start agents · github.com · checked 19 October 2026
  16. 16Deedglass docs: Limitations, identity and Stop · docs.deedglass.com · checked 19 October 2026
  17. 17Deedglass source: docs/APPROVALS.md, who may approve · github.com · checked 19 October 2026
  18. 18Deedglass source: docs/WEBHOOKS.md, events · github.com · checked 19 October 2026
  19. 19Deedglass source: docs/LEDGER.md, filters and exports · github.com · checked 19 October 2026
  20. 20Deedglass source: docs/POLICIES_GUIDE.md, activation records · github.com · checked 19 October 2026
  21. 21Deedglass docs: Exports, records as FHIR AuditEvent and Provenance · docs.deedglass.com · checked 19 October 2026
  22. 22Deedglass source: docs/LICENSING.md, the licences (every feature free while we grow) · github.com · checked 19 October 2026
  23. 23Deedglass docs: PHI mode · docs.deedglass.com · checked 19 October 2026
  24. 24Deedglass source: docs/LOCKDOWN.md, lockdown mode · github.com · checked 19 October 2026
  25. 25ICMR: Ethical Guidelines for Application of AI in Biomedical Research and Healthcare (2023) · icmr.gov.in · checked 19 October 2026
  26. 26MeitY: India AI Governance Guidelines (published through PIB, November 2025) · static.pib.gov.in · checked 19 October 2026
  27. 27eCFR: 45 CFR 164.312, Technical safeguards · ecfr.gov · checked 19 October 2026
  28. 28HL7 FHIR R4: RESTful API (conditional create, Prefer, managing versions) · hl7.org · checked 19 October 2026

Vendor figures are the vendors’ own. Nothing on this page is legal advice. If something here is wrong, write to hello@deedglass.com.