Reference table
Open standards
Lists the message standards, transports, security standards and clinical terminologies Pensieve speaks, with the part of the platform that uses each one.
Pensieve exchanges data in published standards, and this page lists the standards it speaks at each crossing, what each one carries and the part of the platform that uses it. Protocol detail sits on the reference pages linked in each section.
Messaging and documents
Systems on the hospital network reach the bridge in these standards, and Forge sends orders out in HL7 v2 or FHIR. Studies bypass the bridge on a DICOMweb path of their own.
| Standard | What it carries | Where Pensieve uses it |
|---|---|---|
| HL7 v2 | Clinical messages in ER7 encoding over MLLP, with delimiters and character set read from the MSH segment and original-mode acknowledgements | Results, admissions, visits and orders through the bridge, on port 2575 by default, and orders sent out by Forge |
| FHIR R4, version 4.0.1 | Resources and bundles as application/fhir+json, with an OperationOutcome for each pushed message | Resources a hospital FHIR system pushes through the bridge, and transaction bundles sent to a partner's FHIR server |
| ASTM E1381 | The low-level link to an analyser: ENQ, ACK and NAK, framed blocks with checksums, timeouts and retries | Analysers connected to the bridge over TCP, on port 2576 by default |
| ASTM E1394 | The analyser's records: header, patient, order, result, comment and terminator | Each result, mapped into the record against its order |
| DICOMweb | Imaging studies, stored with STOW-RS, found with QIDO-RS and retrieved with WADO-RS | The imaging path from the imaging source to the Pensieve imaging store |
| DICOM modality worklist | Scheduled imaging work for a modality to pick up | Scheduled imaging orders, sent as worklist entries for each modality |
| Delimited text | Rows of delimited text, mapped through the connection's field mapping | Folders the bridge watches on the hospital network, with a large file uploaded to platform storage over a signed upload |
An HL7 v2 sender reads the platform's verdict as an original-mode acknowledgement and a FHIR sender as an OperationOutcome, and from message to record follows how each verdict is built and returned. An analyser on the ASTM link reads an ACK or NAK for each frame it sends, and resends a frame answered with a NAK.
HL7 v2 message types and segments are listed in HL7 v2, and FHIR resources and operations in FHIR. Folder layout and collection are set out in file drops, and the imaging path from study to order in imaging.
National and financial exchange
ABDM and the National Health Claims Exchange are called from the platform under the hospital's own registration and credentials, each configured as a connection in Westron. Gate captures the ABHA at registration, and Vault carries the claims, e-invoice and finance exchanges.
| Standard | What it carries | Where Pensieve uses it |
|---|---|---|
| ABDM | The ABHA number and address, consent through the ABDM consent manager, and shared records as FHIR R4 bundles to the NRCeS profiles, encrypted end to end | ABHA capture, creation or verification at registration in Gate, and consented sharing called from the platform |
| National Health Claims Exchange | Eligibility, pre-authorisation and claim bundles in FHIR R4, signed with JWS and encrypted with JWE, with ClaimResponse and PaymentReconciliation read back | Vault, sending from the platform with the hospital's own keys |
| Invoice Registration Portal | Registration of a B2B e-invoice under GST, returning its IRN, acknowledgement number and signed QR code | Vault, where the site's turnover requires e-invoicing |
| FHIR R4 finance resources | Invoices and charges as Invoice, ChargeItem and ChargeItemDefinition | Vault's finance lane to an external finance system, through a billing connector in Westron |
ABDM and the claims exchange are followed in national digital health and insurers and claims, and e-invoicing and the finance lane in tax and finance systems.
Security and identity
The bridge link, staff sign-in and calls to partner services rest on the published standards below. How each system proves itself is set out in authentication between systems.
| Standard | What it carries | Where Pensieve uses it |
|---|---|---|
| TLS 1.2 or higher | Encryption in transit, restricted to authenticated-encryption cipher suites | The bridge link |
| HTTPS | Encrypted web traffic | The imaging path and the browser path on port 443, and every call the platform makes to a partner service |
| WebSocket with mutual TLS | One long-lived outbound connection on port 443, both ends proving themselves by certificate, with the platform's certificate pinned | The bridge link, with a bridge token and a signed challenge checked at every connection |
| SAML 2.0 | Single sign-on, started from Pensieve | Staff sign-in through the hospital's identity provider, set up per organisation |
| OpenID Connect | Single sign-on by the authorisation code flow with PKCE | The same staff sign-in, for an identity provider that speaks OpenID Connect |
| SMART Backend Services | A signed assertion exchanged for an access token, with no person signed in | Direct connections to a partner's FHIR server |
| HMAC-SHA256 | A keyed hash, used as a signature its receiver verifies and as a stable key derived from content | Payment gateway notifications, verified over the raw body before they are read, and the outbound idempotency key |
| AES-256-GCM | Authenticated encryption | The bridge's local queue, and ABDM payloads after an elliptic-curve key agreement |
| SHA-256 | A content hash | The integrity record of each inbound message, and the payload hash on each boundary record |
| RFC 8785 | Canonical JSON, so equal content serialises to equal bytes | The payload under each outbound idempotency key |
| W3C Trace Context | A trace identifier carried from system to system | Every crossing, inbound and outbound, under one identifier per exchange |
Messaging providers sign their delivery receipts too, and Pensieve verifies each one before reading it, as messaging providers describes.
Clinical terminologies
Codes from every sending system are translated on the platform into the terminologies below, through a central base, a site overlay and an unmapped-code queue that keeps the original code.
| Terminology | What it codes | Where Pensieve uses it |
|---|---|---|
| SNOMED CT | Findings, problems and procedures, in the International edition with the NRCeS India extensions for drug codes, AYUSH and patient instructions | Coded clinical entries across the record |
| LOINC | Laboratory tests and observations | The identity of each laboratory result, mapped from OBX-3 |
| ICD-11 | Diagnoses, as the authoritative classification | Each diagnosis on the record |
| ICD-10 | Diagnoses, derived from ICD-11 | Claims, where a primary diagnosis carries its derived ICD-10 code |
| UCUM | Units of measure | Result units, validated as each result is mapped |
The translation rules are in terminology mapping, and the fields each terminology codes are in clinical vocabulary.
Leaving in the same standards
Standards also keep a hospital free to take its data elsewhere. The export described in export and exit carries the clinical record as FHIR R4 bundles and imaging as DICOM, coded in the terminologies above. A hospital's own warehouse receives its data through the same export, and analytics and data out traces that route.
Common confusions
Where does FHIR enter and leave Pensieve?
A hospital FHIR system pushes resources and bundles through the bridge and reads an OperationOutcome for each. Pensieve sends transaction bundles to a partner's FHIR server over a direct connection, after reading the partner's declared capability. Claim bundles, shared records and finance resources also leave in FHIR R4, for the claims exchange, ABDM and an external finance system, as the tables above show.
Is the leg from a hospital system to the bridge encrypted?
Where the sending system supports it, that leg is wrapped in TLS. Otherwise the hospital network segment is that leg's trust boundary, as networks and trust zones sets out, and every leg past the bridge runs over TLS.
Do ABDM and the claims exchange use FHIR the same way as a partner server?
All three use FHIR R4 and differ in profile and protection. ABDM payloads follow the NRCeS profiles and are encrypted end to end, claim bundles are signed with JWS and encrypted with JWE, and a partner FHIR server is reached with SMART Backend Services.
Read how each standard becomes a way of connecting in connection methods.