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

Show your hospital customers what your AI wrote.

For teams building scribes, discharge tools, copilots and record systems. Put Deedglass between your agent and the record. Your rules decide each call, a person approves the ones that matter, and a check reads back what was stored.

Try it Become a design partner

Try the simulation · What works today · See the FHIR write benchmark: what Deedglass caught on Medplum, and what it missed

  • Free, open-source core
  • Runs next to your stack
  • FHIR, JSON APIs and Postgres

Your agent sent

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

The server answered

200 OK

Deedglass read it back

Doesn’t match: nothing new was stored
A conditional create that matches one record answers 200 and creates nothing.2 In a run against HAPI FHIR JPA v8.12.0-2, Deedglass read that answer back as Doesn’t match.3

Why it matters

Hospitals ask who checks what your AI wrote.

AI in the record has moved from suggesting to writing. Epic says its AI Charting drafts the note and “queues up orders”.1 A hospital’s quality and IT teams will ask what your agent changed, who approved it and how they can check. Deedglass gives you one place to look for all three.

An illustration with made-up data, not a recorded run. The server answered 201 Created. Reading the resource back showed a note that wasn’t stored and a different author, so the check says “Doesn’t match” and names both fields.3

For your product

Rules in plain data, approvals by named people, a check after each write, and one switch to stop every agent. You don’t build any of it yourself.

For your customers

Sealed records they can check offline, exports in FHIR formats their auditors read, and a tool that runs on their servers or yours.

Works today

What you can use now.

Terminal output from Deedglass 0.10.0 on demo data: npx deedglass init --trigger reports UPDATE order 42, Proven, Doesn’t match: Postgres changed 301 rows in public.orders while the agent reported 1, lists the unexpected rows, offers an undo that waits for a person, and npx deedglass verify then shows 22 records with the chain intact. Terminal output from Deedglass 0.10.0 on demo data: npx deedglass init --trigger reports UPDATE order 42, Proven, Doesn’t match: Postgres changed 301 rows in public.orders while the agent reported 1, lists the unexpected rows, offers an undo that waits for a person, and npx deedglass verify then shows 22 records with the chain intact.
A real run on your own app’s Postgres, the Proven path: an agent updates one order, a legacy trigger changes 300 more, and the check names every extra row. Then the records are checked offline. Made-up demo data.
  • A FHIR connector (beta)

    Puts a FHIR R4 server’s API behind Deedglass as one tool per interaction (read, vread, search, history, create, update, patch, delete) on the record types you list. A call naming any other type is refused before anything is sent.3

  • Read-back after every write (Checked)

    Each write is read back at the version the server reported, and the fields your agent sent are compared one by one.3

  • Proven on HAPI FHIR and Medplum

    On HAPI FHIR JPA 8.x and Medplum 5.x running on Postgres, Deedglass reads the server’s own change log and checks that the transaction holds what your agent sent, and nothing else.3

  • Your own app on Postgres

    If your app keeps its data in your own Postgres, each agent write is checked against Postgres’s change log (Proven), and can be undone after a person countersigns.5

  • A free healthcare rules pack

    Denies deletes of clinical records, holds orders, medicines, allergies, the problem list and final notes for a clinician, and needs two different people for claims. No rule judges whether a clinical change is right.6

  • India: ABDM records and NHCX claims

    From Deedglass 0.10.0, the FHIR connector names ABDM health records and NHCX bundles from what they hold, in the terms of the NRCeS FHIR guide for ABDM 6.5.0, and reports a label that doesn’t match.161716 The free india-health pack holds a final claim, or a pre-authorisation of INR 1,00,000 or more, for two people, and a smaller one for one; you set the threshold.16

  • PHI mode

    Once an action is sealed and checked, Deedglass keeps ids and fingerprints of its request and result, not their content.7

  • Records your customers’ auditors can read

    Records export as FHIR R4 AuditEvent and Provenance, with ids and fingerprints instead of clinical content.8 Anyone can check the sealed records offline with your public key.10

  • People approve, never your agent

    A rule can need one or two different people. One person can’t approve twice, one refusal is final, and an agent can never approve itself.9

Everything Deedglass Health uses today is in the free, open-source core.11 The core is under Apache-2.0.12 Coming, with no date promised: clinician approver groups and SSO.6

Today and next

What works today, in plain words.

The same features as above, for readers who aren’t engineers. Each line names, in small type, the feature your IT team will look for.

Show the list in plain words, with the feature names in small type
Works today
  • Holds orders, medicines, allergies, the problem list and final notes until a clinician approves.healthcare-fhir rules pack
  • Never lets an AI delete a clinical record. Corrections are saved as a new version.healthcare-fhir rules pack
  • Asks for two different people before a claim or bill is changed.four-eyes approvals
  • Reads the record back after each change and compares it with what the AI said.read-back checks (Checked)
  • Gives a deeper check on two open-source record systems, by reading their own change history.Proven on HAPI FHIR 8.x and Medplum 5.x on Postgres
  • Connects to record systems that use FHIR, the common standard for sharing health records, with secure sign-in.FHIR connector (beta); SMART Backend Services, tested against a local stand-in so far
  • Connects to other web APIs too, such as an HIS vendor’s JSON API, and reads back the fields you name.REST connector with read-backs (Checked)
  • Keeps only ids and fingerprints of patient data once each action is finished, if you switch this setting on. We recommend it for real patient data.PHI mode (off until you switch it on)
  • Saves its records in formats other health systems already read.FHIR AuditEvent and Provenance export
  • Runs on your own servers. It sends us nothing by default.self-hosted

Need something that isn’t here?

Tell us the workflow you want covered first, such as discharge summaries, lab orders or pre-authorisations.

Talk to us as a design partner

Try it

What your customer’s doctor would see.

Your agent drafts an order. The doctor approves or declines, and Deedglass checks and seals it. Switch on PHI mode to see what the approver sees then.

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

Try a setting
Patient recordWard 4 · Bed 12 · test patient

Medication order

Drafted by AI

By the AI scribe, for Dr. A. Rao, ward round

Medicine
Metformin
Dose
500 mg
Route
By mouth
How often
Twice daily

Held: waiting for a clinician

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

Approval needed

You are Dr. N. Shah, consultant

Medication order

From the AI scribe

Expires in 30 minutes

Medicine
Metforminsha256:ca31…9044
Dose
500 mgsha256:8708…6a36
Route
By mouthsha256:5380…32d9
How often
Twice dailysha256:3922…49a4

Rule: Medication changes need a clinician

Approve or decline. Both are fine answers here.

What Deedglass did

  1. Your rulesHeld under the rule “Medication changes 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.

What you see follows the product: only a person can approve9, an approval nobody decides expires and nothing runs9, each write is read back and compared3, and the record holds what a sealed record holds.18 With PHI mode on, the approver sees field names and fingerprints.7

Where it sits

In front of what your agent writes to.

Your agent calls Deedglass’s tools instead of the record system. Deedglass applies your rules, waits for a person when a rule says so, then calls the system and checks the result.

  • A FHIR API that accepts writes

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

    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).4 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.5

    Works today

  • MCP servers

    Your rules decide each call by tool name.13 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.13 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.14 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.

Limits, plainly

  • SMART sign-in is tested against a local stand-in, not yet against a vendor sandbox.3
  • FHIR writes are Proven only on HAPI FHIR JPA 8.x and Medplum 5.x on Postgres. Deletes are Proven on HAPI only. Other servers and managed EHRs are Checked.
  • Clinician approvers are named people until approver groups ship. ABDM consent artefacts aren’t checked.
  • PHI mode is off until you switch it on. Digests of short values, like a record number, can be guessed: they aren’t salted yet.
  • No SOC 2 report or ISO 27001 audit yet, no SSO yet, no high-availability guide, and no published sizing or latency figures.15

Price

Free while we grow.

Free

The core, the FHIR connector, the healthcare rules pack, PHI mode and the exports. Apache-2.0.

What used to be Pro

Free too, while we grow: the security review pack for your customers’ reviewers, every policy pack and one-step session undo. Paid support, SLAs and a hosted version for organisations come later, and anything free today stays free for teams that run Deedglass themselves.

Build it into your product with us.

Tell us what your agent writes to, which hospitals you sell to, 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. 1Epic: Epic AI Charting rolls out alongside an expanding set of built-in AI capabilities · epic.com · checked 19 October 2026
  2. 2HL7 FHIR R4: RESTful API (conditional create, Prefer, managing versions) · hl7.org · checked 19 October 2026
  3. 3Deedglass docs: the FHIR connector · docs.deedglass.com · checked 19 October 2026
  4. 4Deedglass docs: Use Deedglass with a FHIR server today · docs.deedglass.com · checked 19 October 2026
  5. 5Deedglass docs: Check levels · docs.deedglass.com · checked 19 October 2026
  6. 6Deedglass docs: the healthcare-fhir policy pack · docs.deedglass.com · checked 19 October 2026
  7. 7Deedglass docs: PHI mode · docs.deedglass.com · checked 19 October 2026
  8. 8Deedglass docs: Exports, records as FHIR AuditEvent and Provenance · docs.deedglass.com · checked 19 October 2026
  9. 9Deedglass docs: Approvals · docs.deedglass.com · checked 19 October 2026
  10. 10Deedglass docs: Records and the record chain · docs.deedglass.com · checked 19 October 2026
  11. 11Deedglass source: docs/LICENSING.md, the licences (every feature free while we grow) · github.com · checked 19 October 2026
  12. 12Deedglass source: LICENSE (Apache-2.0) and ee/LICENSE (FSL-1.1-ALv2) · github.com · checked 19 October 2026
  13. 13Deedglass source: docs/CONNECTORS.md · github.com · checked 19 October 2026
  14. 14Deedglass source: docs/WITNESS_DEBEZIUM.md · github.com · checked 19 October 2026
  15. 15Deedglass docs: Limitations, identity and Stop · docs.deedglass.com · checked 19 October 2026
  16. 16Deedglass source: docs/healthcare/INDIA.md, ABDM records, NHCX bundles and the india-health pack · github.com · checked 19 October 2026
  17. 17NRCeS: ABDM FHIR implementation guide, NHCX profiles · nrces.in · checked 19 October 2026
  18. 18Deedglass source: spec/v2/DEED_SPEC.md, what a record shows · github.com · 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.