Glossary

The names below are the parts of one platform and the standards that platform works with. None of them is a separate thing to buy.

A tool is an application inside Pensieve. A core system is plumbing every tool is required to route through. Everything after those two groups belongs to somebody else: a protocol, a terminology, a national rail, a regulator, an accreditation framework. Where a term has a page behind it, the term links to it.

• Pensieve: The single platform a hospital runs its clinical, operational and financial work on: one patient record, one authorization check, one audit trail.
• One product: The tools are applications inside one platform, the way apps sit inside an operating system. None of them is sold, licensed or priced on its own.
• The Chamber: The desktop staff sign in to: a persistent bar across the top, a dock of full-screen tools, and pinnable widgets beside the tool in use.
• Tool: A full-screen application inside Pensieve that staff open to do one job. Every tool shares the same login, the same record and the same audit trail.
• Core system: A system beneath every tool: identity, authorization, the one path to patient data, the event log, audit. A build check fails the moment a tool tries to go around one.
• Organisation: The entity that holds one or more sites. Roles, permissions and reporting are defined against it.
• Site: A physical hospital location. Almost all data and almost all permission is scoped to a site, which is what makes a second site something other than a merge.
• The patient app: The patient’s own copy of the record built during care. A separate surface from the staff web app, and patient-owned.
• Imaging viewer: Opens a study against the right patient and the right order, with zoom, pan and measurement, reachable from wherever a reader happens to be in the app.
• Hospital partner: A hospital running Pensieve in production. Partners are under NDA, which is why this site argues from architecture and standards rather than from logos.
• Forward-deployed engineer: The engineer who deploys a hospital and stays with it after go-live, rather than handing it to a queue.
• Go-live: The day a site stops working in the systems it is replacing and starts working in Pensieve, department by department or all at once.
• Rehearsal site: A modelled copy of a site, used to build and test a configuration before any of it reaches a patient.

• Gate: The front door: registration, outpatient appointments, and every kind of visit from arrival to discharge, opened on one record.
• Atlas: The patient’s clinical record: diagnoses, notes, documents, studies and completed forms on one timeline. Atlas is the only tool that holds patient health information; every other tool asks it.
• Forge: The order system: a drug, a test, a scan, a procedure, a referral or a form, ordered from a hospital-approved catalogue and carried through to the result.
• Vault: Billing and the revenue cycle on the same record as the clinical work: charges, deposits, tariffs, payers, claims, refunds, taxes and the discharge hold.
• Glyph: The form builder and fill engine. Staff design their own forms with validation and calculators, and Scribe drafts the fill for a person to sign.
• Quest: Anything due at a time: medication dose schedules, due-cards for the steps inside a process, and each person’s own list of what is outstanding.
• Cadence: The workflow engine: an administrator designs a repeatable process once, and every live run of it is tracked, timed, and flagged when it is late.
• Raven: One communications layer: push, SMS, WhatsApp, voice, email and in-app, on hospital-approved templates, under consent and quiet hours, with a delivery log.
• Sentinel: The alert ledger and rules engine: an administrator sets when an alert fires, and acknowledgement, grouping and escalation are tracked against it.
• Falcon: Analytics on the governed record. It reads from every other tool without owning or changing anything, and shows where each number came from.
• Vigil: Accreditation and quality: incidents, committees, training, audits, policies and risk registers, kept as the exhaust of daily work rather than as a parallel project.
• Durin: A no-code builder on governed data. Hospital staff compose their own apps for the long tail no vendor hardcodes, and a forward-deployed engineer can build one in for a hospital without involving staff at all.
• Cornea: The site simulation studio: model a site and rehearse its configuration before it goes live. A studio for the deployment, and never a clinical viewer.
• Westron: The interoperability console over the bridge: configure each connection to an outside system, watch its traffic for problems, and keep a forensic trail of every exchange.

• Nexus: The digital twin of the hospital: the organisation, its sites, the wards, rooms and beds inside them, the physical assets, the teams, and the duty roster that says who is on shift.
• Cirith: The authorization decision on every read and every write. Relationship-based, in the Zanzibar lineage, and administered inside Nexus.
• Patient lens: The restriction injected at the database read path, so a user cannot query records they are not entitled to even where a screen forgot to ask.
• Two-plane consent: Patient consent and hospital admission read together as the gate that unlocks a record. Consent is a data object with a history, rather than a checkbox on a form.
• Break-glass access: The emergency path to a record for an urgent case. It exists, and it is always written down as what it was.
• Audit in the same transaction: The record of what happened is written with the change rather than logged after it, then archived to storage that is written once and never altered.
• Event log: How tools notify each other. Placing an order never waits on billing, because the tools react to a shared log rather than calling each other directly.
• Ports and adapters: The boundary rule: the domain does not know which database, queue or vendor sits on the other side, so either side can be replaced without rewriting the other.
• Schema-first: Every boundary validates against one declared schema, so the shape of a message is checked in one place instead of trusted in twenty.
• Errors as values: A failure is returned and handled rather than thrown and hoped about, which is why a failed write surfaces as a message instead of a blank screen.
• Deployables: What actually ships: the Pensieve backend, the staff web app, and the orophin agent that runs inside the hospital.

• orophin: The on-premises bridge: one agent, a single binary on one Windows or Linux machine, carrying every connection between Pensieve and the systems a hospital already runs.
• Outbound mTLS link: The one mutually authenticated connection the agent opens to the cloud. The hospital firewall gets no inbound rule, because nothing calls in.
• Durable outbox: The queue held on the agent’s own disk. A network drop delays a message instead of losing it.
• Connector: One configured connection to one outside system: its protocol, its credentials, its direction of travel, and the tools on the record for it.
• Normalisation: Turning an inbound message into the record’s own units, codes and identity before it is written, so a result means the same thing wherever it arrived from.
• Compatibility only: Naming an external system describes protocol-level compatibility through the bridge. It is never a claim of a deployment, a partnership or a certification with that vendor.

• HL7 v2: The messaging standard most hospital systems already speak for admissions, orders, results and charges. Version 2.8.2 is the one named in India’s EHR Standards.
• MLLP: Minimal Lower Layer Protocol: how an HL7 v2 message is framed and carried over TCP/IP. A transport detail of HL7 rather than a standard of its own.
• ADT, ORM, ORU, DFT: The HL7 v2 message types that carry most traffic: admit, discharge and transfer; an order; an observation result; a financial transaction. MDM carries documents, SIU carries scheduling.
• ASTM: What most laboratory analysers speak to report a result: E1381 for transport, E1394 for message content, and the LIS02 revision of both.
• DICOM: The imaging standard: studies, series and images, plus the service classes that move them (C-STORE, C-FIND, C-MOVE, Storage Commitment).
• Modality worklist: The DICOM service that tells a scanner which patient and which order it is about to image, so a study is filed against the right person without anyone re-typing it.
• FHIR R4: The modern exchange standard, resource by resource: Patient, Encounter, Observation, ServiceRequest, DiagnosticReport, Claim, Coverage.
• CSV / flat file: The fallback when a system has no interface at all: a file dropped in a watched folder, on an agreed schedule and an agreed layout.
• DB polling / CDC: The other fallback: a read-only account against the incumbent database, or its change feed, when the vendor will open nothing else.
• REST / JSON API: What a custom hospital application usually offers instead of a health standard. The bridge speaks it and normalises the payload like any other source.

• ICD-11: The World Health Organization’s classification of diseases, and the coding a diagnosis is recorded against.
• SNOMED CT: The clinical terminology used for findings, procedures and problems, where a diagnosis code is too coarse to carry the meaning.
• LOINC: The naming system for laboratory observations, which is what makes one analyser’s potassium and another analyser’s potassium the same measurement.

• ABDM: The Ayushman Bharat Digital Mission: India’s national digital health programme, and the registries and consent machinery underneath it.
• ABHA: The Ayushman Bharat Health Account: a patient’s national health identity, created or linked at registration.
• HFR: The Health Facility Registry: the national record of the facility itself.
• HPR: The Healthcare Professionals Registry: the national record of the clinician.
• HIE-CM: The Health Information Exchange and Consent Manager: the national machinery through which a patient grants and withdraws access to records held elsewhere.
• Scan and Share: The ABDM flow where a patient scans a facility QR code to share an ABHA at the desk instead of filling in a form.
• ABDM milestones: M1, M2 and M3: the programme’s own staged alignment framework. A target to build to rather than a certificate anybody issues.
• NHCX: The National Health Claims Exchange: the common rail for insurance claims between hospitals, insurers and third-party administrators.
• PMJAY: Ayushman Bharat Pradhan Mantri Jan Arogya Yojana: the national scheme, with its own package rates, pre-authorisation and claim envelope.
• ECHS and CGHS: The ex-servicemen and central government health schemes: two more payers, each with its own entitlement rules and its own rate list.
• IRDAI: India’s insurance regulator. Its settlement rules are what a cashless or reimbursement claim is judged against.
• GST and the IRP: India’s goods and services tax, and the Invoice Registration Portal an invoice is reported to. Both land in billing rather than in a separate finance system.
• UPI: The national payments rail. A payment collected on it settles against the same bill the clinical work raised.
• DPDPA: The Digital Personal Data Protection Act: India’s data protection law, and the reason consent is a first-class object with a history.
• India’s EHR Standards: The set notified by the Ministry of Health and Family Welfare in 2016, naming HL7 v2.8.2, FHIR, DICOM, SNOMED CT, LOINC and ICD. Attributed as the standard rather than as a Pensieve certification.

• NABH: The National Accreditation Board for Hospitals and Healthcare Providers: India’s hospital accreditation framework, and the standard most quality departments work to.
• NABH Digital Health: The digital health accreditation inside NABH, which asks what the software can prove rather than what the policy document says.
• JCI: Joint Commission International: the international accreditation framework, carried alongside NABH.
• HIPAA: The United States health information privacy framework. It is present in the compliance surface, and it is not the law Indian operations are governed by.
• 42 CFR Part 2: United States confidentiality rules for substance use disorder records, which the consent model accounts for because they are stricter than the general case.

• SAML: The older enterprise single sign-on standard, and still the one most hospital identity providers offer first.
• OIDC: OpenID Connect: the modern single sign-on standard, layered over OAuth 2.0.
• mTLS: Mutual TLS: both ends present a certificate, so the server proves itself to the client and the client proves itself to the server.
• Passkeys (WebAuthn): Sign-in bound to a device and a person rather than to a shared password, which is what removes the ward password written on a sticky note.
• ReBAC: Relationship-based access control: permission derived from a relationship (this clinician, this patient, this admission) rather than from a role name alone. Cirith is in this lineage.