Skip to content
Agents draft, clinicians sign — no agent path writes to the record alone
LegosphereHealth

Ambulatory · Inpatient · Agentic

An agentic EMR for
hospitals and clinics

Legosphere Health is a hospital and EMR platform built on FHIR R4, with a roster of agents that draft the note, propose the codes, assemble the claim and coordinate the discharge — and a sign-off machine that keeps every one of them out of the clinical record until a licensed clinician signs.

Talk to usHow the agents are governed
  • Agents draft, clinicians sign
  • Triage escalates, never advises
  • Dose and interaction checks are deterministic
  • One core, two jurisdictions

Three surfaces

A record, a roster of agents, and the screens a clinician actually opens

One clinical record underneath all three: it holds what happened, the agents draft against it without being able to write to it, and the workspaces are where a person decides and signs.

The core

The clinical record

FHIR R4 as the thing that is stored, not the thing that is exported. Registration, encounters, notes, orders, results, problems, allergies, pharmacy and the revenue cycle all sit on one canonical clinical model, so exchange is a projection of the record rather than a rebuild of it.

  • A resource payload holds the canonical FHIR; typed columns index only what the application queries
  • Ambulatory and inpatient on one model — appointment, encounter, ward, bed, census, discharge
  • Orders to results: ServiceRequest through to Observation, DiagnosticReport or an imaging study
  • Pharmacy end to end: formulary, inventory with lot and expiry, dispense, MAR, reconciliation
  • Charge capture, invoice, coverage and claims reading the same encounter the clinician worked in

Clinical informatics · integration teams · anyone who has migrated an EMR before

The clinical record
The agents

The agent roster

One graph, a director that routes to a registry of specialists, and three tiers that decide what each one is allowed to do. Anything touching the record drafts and stops. Anything operational acts but is reversible. Anything computable is not an agent at all — it is a tool the agents call.

  • Tier A touches the record and therefore cannot commit without a clinician’s signature
  • Tier B is operational, acts reversibly, and lands every action in a review and override queue
  • Tier C is deterministic and is not an agent: interactions, dosing, charge maths, bed rules
  • A critic gates every Tier-A draft before a human is ever shown it
  • One module talks to a model provider; every call writes tokens, latency and cost to a ledger

CMIOs · clinical safety officers · engineering leads

The agent roster
The workspace

The clinician workspaces

Where the time is actually saved. Role-scoped workspaces across ambulatory, inpatient, orders, pharmacy, billing, claims, clinical support, engagement, exchange, the patient portal and administration — each one built around the decision the person opening it is holding.

  • Scheduling, encounter, chart, scribe and coding for the ambulatory day
  • A bed board and patient-flow view for the ward, driven by deterministic assignment rules
  • CPOE for orders and results, and a pharmacy surface from formulary through to point of sale
  • Billing, claims, prior authorisation and the agent queues that draft into them
  • A review and override queue that is one screen, not one per agent

Clinicians · nurses · pharmacists · coders · front office · administrators

The clinician workspaces

The specification

What it is, and what it is not

The questions that actually decide this purchase are specification questions. They are answered here rather than on a second call.

What this is

A hospital-facing EMR spanning ambulatory and inpatient care, with FHIR R4 as the canonical clinical model, built to the American certification requirements as its primary jurisdiction and to the Indian national digital-health requirements on the same core. Every agent output that touches the record passes a validator and a clinician’s signature.

What this is not

Not a diagnostic engine, not a treatment-recommendation system, and not an autonomous coder or biller. Agents draft and suggest; licensed humans decide and sign. That is enforced in the code that assembles the record, not asserted in a policy note.

DomainHospital and EMR — ambulatory and inpatient, on one clinical record
Clinical modelFHIR R4, stored FHIR-shaped. Exchange is a projection of the record, not a rebuild of it
JurisdictionsUnited States primary, India on the same core — every country-specific concern behind an adapter
TenancyA facility is the tenant and carries its jurisdiction, so multi-tenant is multi-jurisdiction
AgentsOne graph, a director routing over a specialist registry, and exactly one module that talks to a model provider
Safety modelAnything touching the record is behind mandatory clinician sign-off; anything computable is a deterministic tool the agents call
IdentityTokens are verified, never minted — scoped clinical authorisation in one jurisdiction, the national consent flow in the other
PaymentsNo bespoke gateway. Payment references come from an external service and are confirmed, not processed
Record integrityAgent drafts live outside the clinical record, and a rejected draft is absent from the assembled bundle

Why it is built this way

The dangerous failure here is the one that looks like care

Clinical software is read by people who are busy, tired and trusting the screen. A note in the chart is treated as something a clinician wrote. A code on a claim is treated as something a coder chose. A dose that renders without a warning is treated as a dose that was checked. None of those readings survive contact with a system that let a model write directly into the record.

That is what makes the expensive failures quiet ones. A draft that entered the chart without a signature is indistinguishable, three months later, from a note somebody wrote. An interaction check a language model reasoned about looks exactly like one an engine computed — until the one case where the reasoning was fluent and wrong. An autonomous coder that upcoded produces a claim that pays, and a problem that arrives as an audit.

So the architecture is aimed at those specifically. Anything that touches the clinical record drafts into a holding area and stops there. A rejected draft is provably absent from the assembled record rather than merely flagged. The computations that decide patient safety — drug–drug and allergy checks, dose ranges, controlled-substance refill rules, bed assignment, charge maths — are deterministic engines the model is allowed to call and explain but never to perform.

Which is why most of what follows is written as a rule about what the software will not do. In this domain, the refusals are the product.

How it works

What happens to an encounter

Five stages between a patient arriving and a claim going out, each with a rule attached. The rules are the interesting part — most exist because of a way a system like this fails quietly.

  1. 01

    Identify and register

    Patient matching is an adapter decision, not a global one: weighted demographics where there is no national identifier, a deterministic key where there is. A merge is reversible and every merge and unmerge is written to a ledger, because a wrong merge is two people’s histories in one chart.

  2. 02

    Open the encounter

    Ambulatory, inpatient or virtual, all as one FHIR Encounter. Slots cannot double-book, a check-in opens the visit, and an admission takes a bed from a deterministic assignment engine rather than from a model’s suggestion.

  3. 03

    Draft, outside the record

    A scribe drafts the note, a coder proposes plain-language terms, a summariser dedupes and cites. All of it lands in a draft store that is not the chart, and a critic gates it before a human is ever shown it.

  4. 04

    Sign, or it never existed

    A draft is preliminary until a clinician signs, and preliminary cannot be exchanged. A rejected or critic-failed draft is provably absent from the assembled record — not hidden from a view, absent from the bundle.

  5. 05

    Order, dispense, bill, exchange

    The signed encounter carries into orders, e-prescribing, the medication administration record, charge capture and the claim. Codes come from a terminology adapter, never from the model; safety checks come from a rules engine that hard-blocks.

The record, layer by layer

What it has to satisfy

Twelve rules that constrain the software

Each one is a constraint rather than a capability, and each is written so a customer can hold the software to it. Most of them describe something it refuses to do.

  • Agents draft, humans sign

    No agent path writes to the clinical record without a clinician’s sign-off. This is enforced by the code that assembles the record, not by a policy note in an onboarding deck — a rejected draft is absent from the bundle, and there is a test that fails if it ever is not.

  • Triage escalates, never advises

    The intake agent is not permitted to suggest what is wrong or what to do about it. On any red-flag pattern it hands off to a human and says plainly that it has done so. A triage surface that reassures somebody is the worst thing this software could build.

  • Rules first, the model never computes

    Drug–drug and allergy checks, dose ranges, controlled-substance refill limits, charge maths and bed assignment are deterministic engines. The model may orchestrate them and explain their output; it is never the thing that decides the number.

Read all twelve

Questions

What people ask first

The ones that decide whether this software is safe to put between a clinician and a patient’s record.

No, and that is a design constraint rather than a disclaimer. There is no diagnostic engine and no treatment-recommendation path in the product. Agents draft documentation, propose codes for a human to accept, summarise records with citations, and coordinate operational work. Clinical judgement is the clinician’s, and the software is built so that it cannot quietly become anything else.

Point it at the way your hospital actually runs

The useful conversation starts from your wards and your clinics rather than from a deck: what the doctors are typing twice, where the discharge stalls, which claim keeps coming back denied. Tell us that and we will tell you plainly whether this fits.

Talk to usSee pricing

Get in touch

Talk to the people building it

No chatbot and no ticket queue. Tell us what your hospital or practice actually looks like — how many beds, which departments, what the doctors are doing twice, what your billing team keeps chasing — and someone who works on the software will reply.

info@legosphere.com

Please keep patient identifiers, clinical details and credentials out of this box — it is an ordinary enquiry form, not a channel for protected health information.