DIS-GL-024DisclosureGL1234PublicCritical path31 July 2026
Interoperability
ABDM, NHCX and the integration boundary
The hospital is the registered health facility. It holds its own HFR facility identifier, its clinicians hold their own HPR identifiers, and it holds its own NHCX participant credentials.
Pensieve stores those credentials encrypted in a per-tenant vault and calls those systems as the hospital, on the hospital’s own authority. Edsol Edtech Pvt. Ltd. is therefore not the regulated participant, does not hold ABDM milestone certification, does not onboard to the claims exchange in its own name, and does not represent that it does. This is a deliberate architectural boundary. It is not a gap, and this page does not apologise for it.
The principle, in one sentence
Pensieveacts as the hospital, on the hospital’s own authority, using the hospital’s own credentials. Edsol Edtech Pvt. Ltd. is never the regulated participant, never the registered entity, never the merchant, never the sender of record and never the counterparty to the external system.
Pensieve Labs builds and operates the connection. The hospital owns the relationship at the other end of it.
Why it is built this way
1The registrations belong to the hospital by design
A facility registry identifier identifies a facility. A professional registry identifier identifies a clinician. A claims participant code identifies a claims participant. In every case the regulator or the exchange intends to know who the hospital is, not who its software vendor is. Putting the vendor in the middle of that relationship is an architectural error disguised as a convenience.
2It keeps you free to change software
A hospital whose ABDM credentials, merchant identifier and insurer relationships are held in its vendor’s name is a hospital that cannot leave. Pensieve Labs regards vendor lock-in through credential custody as a form of hostage-taking and does not practise it. The credentials are issued to you and they remain yours when the relationship ends.
3It keeps liability where the law puts it
You are the Data Fiduciary. You are the health facility. You are the claims participant. A vendor asserting those roles takes on regulatory exposure it cannot discharge and confuses your own compliance position.
4It removes a certification dependency from the deal clock
Because Pensieve operates on your credentials, you do not have to wait for Pensieve Labs to complete a national certification programme before you can go live. That is worth days, and days are the whole point.
Section 1
Who holds what
Every credential in the table below is issued to the hospital, because the hospital is the party the issuer intends to identify. Pensieve holds a reference to it and uses it for the purpose it was supplied for, and nothing else.
| Credential or registration | Issued to | What Pensieve does with it |
|---|---|---|
| Health Facility Registry (HFR) facility identifier | The hospital | Identifies your facility to the national digital health infrastructure. Pensieve stores it as configuration and quotes it on calls made on your behalf. Pensieve cannot obtain one for you and does not hold one. |
| Healthcare Professionals Registry (HPR) identifiers | Each clinician, personally | Linked to the clinician's record inside Pensieve so that a shared record carries the correct author. Each clinician must obtain their own; nobody can do it for them, and this is the step that most often runs late. |
| ABDM client credentials | The hospital | Issued against your facility registration, supplied to the per-tenant vault, and used to call the gateway as you. |
| NHCX participant credentials and signing material | The hospital | Used to transmit pre-authorisation and claim packets on your participant code. Pensieve does not onboard to the exchange in its own name and holds no participant code. |
| Payment gateway merchant identifier and API keys | The hospital | Pensieve is never the merchant of record. Settlement goes to your bank account, from your merchant identifier. |
| SMS, WhatsApp, voice and email sender identifiers | The hospital | Messages go out under your sender identity and your template registrations, because a patient receiving a message from an unfamiliar sender is a complaint waiting to happen. |
| Insurer and TPA portal credentials | The hospital | Used to file and follow up on your own empanelment relationships. Pensieve has no relationship with your payers. |
| Laboratory analyser, PACS and reporting-portal credentials | The hospital | Used to move results, images and statutory returns. Interface specifications are agreed bilaterally per device. |
Section 2
The responsibility matrix
R responsible, does the work; A accountable, owns the outcome and cannot delegate it; C consulted before it happens; I informed after it happens. Every row has exactly one A. The selection below is representative; all thirty-nine rows are published in the Integration Boundary Statement Section 5, and the responsibility matrix turns them into a dated, owned, countersigned plan for one deal.
| Activity | Hospital | Clinician | Pensieve Labs | Authority, payer or patient |
|---|---|---|---|---|
| Registration and identity | ||||
| Register the facility on the health facility registry | A/R | I | C | I |
| Obtain a professional registry identifier | C | A/R | C | I |
| Obtain ABDM client credentials against the facility registration | A/R | None | C | I |
| Supply those credentials to the platform vault | A/R | None | C | None |
| Store, protect, rotate on instruction, delete on offboarding | I | None | A/R | None |
| Revoke credentials at the source system | A/R | None | I | I |
| Record sharing and consent | ||||
| Decide which record types the hospital shares | A/R | C | C | I |
| Grant, vary or withdraw consent | I | None | R (mechanism) | A/R (patient) |
| Validate the consent artefact on every request and refuse out-of-scope access | I | None | A/R | I |
| Ensure the clinical content of a shared record is accurate | C | A/R | None | I |
| Log every share with consent reference, information types and timestamp | I | None | A/R | None |
| Claims through the exchange | ||||
| Register as a participant and obtain the participant code | A/R | None | C | I |
| Configure tariffs, packages and payer mappings | A/R | None | R | C |
| Decide what is claimed, at what value, with what documentation | A/R | C | None | I |
| Assemble, validate and transmit the packet on the hospital's credentials | I | None | A/R | I |
| Adjudicate the claim | I | None | None | A/R (payer) |
| Certification, audit and compliance | ||||
| Hold ABDM milestone certification for the software | None | None | Not held. Not sought. | None |
| Determine whether a certified system is required in this state or scheme | A/R | None | C | I/C |
| Maintain the security of the record system | C | None | A/R | None |
| Notify a security incident to the national computer emergency response team | A/R | None | R (content, ≤4 hours) | I |
| Retain processing logs for the statutory minimum, inside India | C | None | A/R in DM-1 to DM-3 | I |
| Respond to an audit or inspection by the authority | A/R | None | R (evidence and support) | C |
The two rows that change by deployment model
The allocation itself does not change by deployment model: registration attaches to the facility, not to the infrastructure. Two rows do. Credential custody sits in Pensieve Labs’s cloud organisation in DM-1 and DM-2, in your own project in DM-3, and on your own hardware in DM-4, where you are accountable and responsible for it. Log retention inside India is Pensieve Labs’s in DM-1 to DM-3 and yours in DM-4, where Pensieve Labs specifies the requirement but cannot enforce it on hardware it does not control. Incident notification within four hours is unchanged in DM-1 to DM-3; in DM-4, Pensieve Labs cannot detect an incident on your infrastructure at all.
The four deployment models, comparedSection 3
How your credentials are held
Bring-your-own-key and bring-your-own-credential is the mechanism that makes the boundary operable. The model is identical in all four deployment models; what changes is whose infrastructure the vault sits on, and therefore who could in principle reach the ciphertext.
Encrypted at rest under the deployment's own key
Held in a managed secret store, under the same key hierarchy as clinical data.
Write-only from your perspective
Once supplied, a credential is never rendered back to any screen, export, report, support view or API response, not to your administrators and not to Pensieve Labs’s. If you lose your own credential you obtain a new one from the issuer; you do not retrieve it from Pensieve.
Never written to a log
Redaction is applied at the logging boundary rather than by asking developers to remember. The integration log records which system was called, which credential reference was used, when, and the outcome, never the value.
Bound to the workload that needs it
Access is granted per secret to the specific service that makes the call. No general “read all secrets” permission exists on any workload identity.
Tenant-scoped
A credential supplied by one hospital cannot be resolved or used by another tenant’s workload, in any deployment model, including the shared one.
Used only for the purpose supplied
A payment credential is used for payments. Pensieve Labs does not use your credential for its own testing, for another hospital, for a demonstration, or to explore an API.
Not readable by Pensieve personnel in the ordinary course
There is no support screen or export that displays a credential value. Reading one would require the elevated production access path: approved by a second person, time-bound, and immutably logged where you can see it.
Destroyed on offboarding
Credentials are deleted from the vault as part of the deletion process and named on the deletion certificate. Revoking them at the source system is yours to do, and you should do it anyway.
The disclosure is the BYOK/BYOC credential handling and the contract that binds it is the BYOK/BYOC addendum. The disclosure explains; the addendum obliges.
Section 4
Sequencing, and the one thing to check first
Pensieveruns a hospital’s registration, clinical record, pharmacy, billing, inventory and reporting without any national-programme connection. Connecting to the programme is an enhancement to a running system, not a precondition for one, which is why record sharing and claims are deliberately sequenced aftergo-live. A hospital that sequences them the other way waits on a third party’s queue for its entire deployment.
| Seq | Milestone | Owner | Blocks go-live? | When it starts |
|---|---|---|---|---|
| A | Determine whether a certified system is required in your state or scheme | Hospital, with Pensieve | Yes, a qualification gate, not an onboarding task | Day 1 of qualification, before signature. One phone call. It can save two months. |
| B | Facility registry registration | Hospital | No, but everything below waits for it | Day 1 of the sales cycle, in parallel with contracting. It is free and you can start immediately. |
| C | Professional registry identifiers for each clinician | Each clinician, chased by the hospital | No | Day 1. Expect weeks of chasing rather than days: doctors are busy and nobody can do it for them. |
| D to E | Obtain ABDM client credentials, then supply them to the vault | Hospital | No | On completion of B. |
| F to G | Configure shared record types, patient notice and consent display; record sharing live | Hospital, with Pensieve | No, after go-live by design | On completion of E. |
| H | Claims exchange participant registration | Hospital | No, deliberately sequenced after go-live | After B completes. It also depends on a third party's onboarding queue, which Pensieve cannot shorten. |
| I to J | Tariffs, packages and payer mappings; claims live | Hospital, with Pensieve | Blocks claims, not go-live | Week 1 of onboarding. Large, tedious, and always underestimated. It is issued as a dated item in the Hospital Input Pack rather than as a request made in week three. |
The one place this can hurt you, stated first
If your state health department, an incentive scheme, a payer or an accreditation criterion requires that the software itself hold ABDM milestone certification, Pensieve does not satisfy that requirement. Nothing on this page changes that and Pensieve Labs will not imply otherwise.
Check it at qualification, not at cutover. If a hospital tells Pensieve Labs that certified-vendor status is a hard requirement, Pensieve Labs will say so and stop, rather than proceed on an unstated assumption that it will be resolved later. Pensieve Labs will also state, in writing and on letterhead, exactly what Pensieve is and is not, to any authority, insurer or assessor who asks, and it will refuse to state that Pensieve is a certified system, because it is not.
Section 5
Standards, terminologies and conformance status
Interoperability claims are cheap and conformance evidence is not. Where a conformance artefact exists it is named; where it is not yet published, the row says [TO BE SUPPLIED] rather than implying a status Pensieve Labs cannot evidence.
| Standard | Version | Where it is used | Conformance status |
|---|---|---|---|
| HL7 FHIR | R4 | The primary clinical representation: patient, encounter, condition, observation, medication, diagnostic report, coverage and claim resources. Used for export, for the national integrations and for hospital-to-hospital exchange. | Implemented. A resource-by-resource Capability Statement is published at [TO BE SUPPLIED]. |
| HL7 v2 | v2.x, per interface | The working standard for laboratory analysers, middleware and most existing hospital systems: ADT, ORM, ORU and MDM. | Implemented per interface. An interface specification is issued per integration, because v2 conformance is always a bilateral negotiation and never a certificate. |
| DICOM | PS3.0 | Imaging: storage, query and retrieve, worklist, and non-diagnostic display. No image analysis. That would cross the medical-device boundary. | Implemented. A Conformance Statement naming supported SOP classes, transfer syntaxes and roles is published at [TO BE SUPPLIED]. |
| ASTM | As the device requires | Older laboratory analysers that predate HL7 support. | Implemented per device. |
| SNOMED CT | International Release [TO BE SUPPLIED] | The primary clinical encoding system: problems, procedures, findings, substances, and the codes used when communicating clinical information to other record systems. | An Affiliate Licence is required. India is a member country, so the licence is free, but free does not mean unlicensed. Licence status: [TO BE SUPPLIED]. A hospital or an assessor can and should ask to see it. |
| LOINC | [TO BE SUPPLIED] | Laboratory tests, measurements and observations; result and report processing with laboratory and imaging systems. | Free with registration. Registration status: [TO BE SUPPLIED]. |
| ICD-10 | [TO BE SUPPLIED] | Diagnosis classification and statutory statistical reporting. ICD-11 is implemented as a mapping layer only, because the Indian EHR standards name ICD-10 and the national transition path is not settled. | Free from the World Health Organization. |
The full position, including the per-market standards stance and the export formats a hospital can take away, is the Interoperability & Standards Disclosure. Australia’s My Health Record and the UAE health information exchanges are not implemented, and that document says so with the reason.
Section 6
The documents behind this page
Four published disclosures. Every claim on this page is a summary of one of them, and where the two differ the document is correct.
DIS-GL-025DisclosureGL1234NDACritical path31 July 2026
Accept the mutual NDA to request access to this tier. Your acceptance is recorded at once and protects both sides; an administrator then grants access, with a target of four business hours.Accept the mutual NDAWait: target 4 business hours
DIS-GL-026DisclosureIN1234PublicCritical path31 July 2026
DIS-GL-029DisclosureGL1234PublicCritical path31 July 2026
ADD-GL-007ContractGL1234NDACritical path31 July 2026
Accept the mutual NDA to request access to this tier. Your acceptance is recorded at once and protects both sides; an administrator then grants access, with a target of four business hours.Accept the mutual NDAWait: target 4 business hours
The boundary is surfaced here rather than at contracting, because the most expensive surprise available in hospital software is discovering at cutover that a registration nobody obtained is on the critical path.