Search all 478 artefacts by title, document ID or content.
Disclosure | Family 3, Security, Privacy & Trust Disclosures
The R/A/C/I allocation itself is published in the Integration Boundary Statement, DIS-GL-024 Section 5. It is not restated here, because a responsibility allocation that exists in two documents will eventually exist in two versions.
This document is the source of truth for: abdm-nhcx-sequencing-plan, abdm-nhcx-owner-schedule, abdm-nhcx-acknowledgement, marketing:/product/abdm
Those surfaces render this text from here. They do not keep their own copy, so they cannot drift from it.
Artefacts this one references or cannot be issued without.
Artefacts that would be blocked if this one were missing or out of date.
DM-1 Dedicated |
DM-2 Shared |
DM-3 Customer Cloud |
DM-4 On-Premise |
|---|---|---|---|
| Yes | Yes | Yes | Yes |
The allocation does not change by deployment model. The hospital is the registered participant in every model, because registration attaches to the facility, not to the infrastructure. Two rows do change, and they are marked in Section 5.
| Fact | Consequence |
|---|---|
| The hospital is the registered health facility. It holds its own facility registry identifier, its clinicians hold their own professional registry identifiers, and it holds its own claims-exchange participant credentials | Every registration step is the hospital's, and cannot be delegated to Pensieve Labs |
Edsol Edtech Pvt. Ltd. does not hold ABDM milestone certification and does not onboard to NHCX in its own name |
This is a deliberate architectural boundary, stated affirmatively (DIS-GL-024 Section 3 and Section 4). It is not a gap and it is not on a roadmap |
Pensieve integrates using the hospital's own credentials, acting as the hospital on the hospital's authority |
Custody, rotation, revocation and deletion of those credentials are in DIS-GL-025 |
| A hospital in a state or a scheme that requires a certified system must establish that at qualification | Row 33 of the matrix. One phone call, made before signature, avoids a discovery at assessment |
This is the plan that keeps the national-programme work off the go-live critical path. It is built on
one principle: Pensieve goes live on the hospital's core operations; the national programme
integrations follow. A hospital that sequences them the other way waits on a third party's queue for its
entire deployment.
| Seq | Milestone | Owner | Starts | Depends on | Blocks go-live? | Target date |
|---|---|---|---|---|---|---|
| A | Determine whether a certified system is required in this state or scheme (matrix row 33) | Hospital, with Pensieve Labs |
Day 1 of qualification, before signature | Nothing | Yes: this is a qualification gate, not an onboarding task | [TO BE SUPPLIED] |
| B | Facility registry registration (row 1) | Hospital | Day 1 of the sales cycle, in parallel with contracting | Nothing. It is free and the hospital can start immediately | No, but everything below waits for it | [TO BE SUPPLIED] |
| C | Professional registry identifiers for each clinician (row 3) | Each clinician, chased by the hospital | Day 1 | Nothing | No | [TO BE SUPPLIED] |
| D | Obtain ABDM client credentials against the facility registration (row 5) | Hospital | On completion of B | B | No | [TO BE SUPPLIED] |
| E | Supply credentials to the Platform vault (row 6) | Hospital | On completion of D | D | No | [TO BE SUPPLIED] |
| F | Configure record types shared, patient notice wording and consent display (rows 11, 12) | Hospital, with Pensieve Labs |
On completion of E | E | No | [TO BE SUPPLIED] |
| G | Health record sharing live | Pensieve Labs |
On completion of F | F | No, after go-live | [TO BE SUPPLIED] |
| H | Claims exchange participant registration (row 21) | Hospital | After B completes | B, and a third party's onboarding queue | No, deliberately sequenced after go-live | [TO BE SUPPLIED] |
| I | Tariffs, packages and payer mappings (row 23) | Hospital, with Pensieve Labs |
Week 1 of onboarding. Large, tedious and always underestimated | The Hospital Input Pack (FRM-GL-100) |
Blocks claims, not go-live | [TO BE SUPPLIED] |
| J | Claims exchange live | Pensieve Labs |
On completion of H and I | H, I | No | [TO BE SUPPLIED] |
The single most important line in this document: milestones G and J are after go-live by
design. Pensieve runs 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.
A responsibility matrix without an escalation path becomes a document people point at after the fact.
| Trigger | Action | Owner | Within |
|---|---|---|---|
| A hospital-owned milestone (B, C, D, E, H, I) has no start date recorded 5 business days after the plan is signed | Pensieve Labs raises it with the hospital's nominated project owner in writing |
Pensieve Labs |
5 business days |
| A hospital-owned milestone passes its target date | Pensieve Labs issues a written Dependency Notice naming the milestone, the date it was due, what it now blocks, and the revised date for the dependent milestones |
Pensieve Labs |
2 business days after the date passes |
| A milestone is blocked by a third party's queue (rows 1, 5, 21) | Both parties record the reference number and the date of submission. Pensieve Labs does not treat a third party's queue as a hospital failure, and the hospital does not treat it as a Pensieve Labs failure |
Both | On becoming known |
A Pensieve Labs-owned milestone passes its target date |
The hospital escalates through the support escalation path in SLA-GL-001, and Pensieve Labs issues a revised date with a reason |
Hospital | None |
| The answer to milestone A turns out to be "yes, a certified system is required" | Stop. Pensieve Labs states in writing that Pensieve does not hold the certification, and the parties decide whether the deal proceeds on a different basis. Pensieve Labs will not proceed on an unstated assumption that this will be resolved later |
Both | Immediately |
A Dependency Notice is not a blame instrument. Its purpose is that a slipped date is visible on the day it slips, to both parties, in writing, because the alternative is a go-live meeting at which the parties discover they each thought the other was doing something.
Pensieve Labs will and will not say to a third partyBecause this is where an unstated assumption becomes a regulatory problem:
| Situation | Pensieve Labs's position |
|---|---|
A hospital asks Pensieve Labs to state that Pensieve is a certified system |
Refused. Pensieve Labs will state precisely what it is and is not, in writing, on letterhead, to any authority, insurer or assessor who asks |
| A tender asks whether the vendor holds milestone certification | Answered no, with the boundary explanation in DIS-GL-024 Section 3 attached |
| An assessor asks how the hospital's records reach the exchange | Pensieve Labs provides the technical description and the audit evidence. The hospital, as participant, gives the compliance answer |
| An authority audits the hospital's participation | Pensieve Labs supports with evidence and technical explanation. The hospital responds (matrix row 39) |
| Matrix row | DM-1 / DM-2 |
DM-3 |
DM-4 |
|---|---|---|---|
| Row 7: store, protect, rotate and delete credentials | Pensieve Labs A/R: the vault is in Pensieve Labs's cloud organisation |
Pensieve Labs R, hospital A: the vault is in the hospital's own project |
Hospital A/R: the vault is on the hospital's own hardware; Pensieve Labs C |
| Row 38: retain processing logs for the statutory minimum, inside India | Pensieve Labs A/R |
Pensieve Labs R configures, hospital A owns the retention configuration |
Hospital A/R: Pensieve Labs specifies the requirement in ADD-GL-008 but cannot enforce it on hardware it does not control |
Row 36 (incident notification content within four hours) is unchanged in DM-1, DM-2 and DM-3. In
DM-4 Pensieve Labs cannot detect an incident on hospital infrastructure at all, and the hospital is
A/R for detection as well as notification. DIS-GL-016 Section 7.
| Role | Name | Designation | Mobile | |
|---|---|---|---|---|
| Hospital project owner, accountable for all hospital-owned milestones | Customer primary contact name |
Customer primary contact designation |
Customer primary contact email |
[TO BE SUPPLIED] |
| Hospital clinical lead, accountable for clinician registry identifiers (row 3) | [TO BE SUPPLIED] |
|||
| Hospital finance lead, accountable for tariffs, packages and payer mappings (row 23) | [TO BE SUPPLIED] |
|||
| Hospital credential custodian, supplies and revokes credentials (rows 6, 8) | [TO BE SUPPLIED] |
|||
Pensieve Labs solutions owner |
[TO BE SUPPLIED] |
info@pensievelabs.org |
||
Pensieve Labs escalation |
[TO BE SUPPLIED] |
A row with no named owner is a row that will not happen. Pensieve Labs will not accept a department
name in place of a person.
7.1 This document does not create obligations between the hospital and any authority. It allocates work
between the hospital and Edsol Edtech Pvt. Ltd.. The hospital's obligations to a registry, an exchange, an
insurer or an accreditation body arise under those bodies' own rules and are not varied by this schedule.
7.2 Pensieve Labs cannot shorten a third party's queue. Milestones B, D, H and their dependencies
sit in queues operated by others. Pensieve Labs can prepare the submission and chase; it cannot
accelerate the decision.
7.3 Target dates are estimates until the dependency is cleared. A date against a milestone that depends on a third party is a plan, not a commitment, and is re-dated in writing when it moves.
7.4 The allocation itself may change if a programme's rules change. Where a registry, exchange or authority changes its participation rules, this schedule is re-issued and re-signed. It is not amended silently.
7.5 This is not legal or regulatory advice. Whether a particular hospital in a particular state must
use a certified system, and what its participation obligations are, is a question for the hospital and its
advisers. Pensieve Labs will state what Pensieve is and is not, in writing, to help them
answer it.
By signing below, both parties confirm that they have read DIS-GL-024 in full, including Section 3 on the ABDM
boundary, Section 4 on the claims exchange, and Section 5 which contains the responsibility matrix, that they accept the
allocation in that matrix as modified by Section 5 of this document, and that the milestones, owners and target
dates in Section 2 and Section 6 are agreed.
The hospital specifically acknowledges that Edsol Edtech Pvt. Ltd. does not hold ABDM milestone
certification, is not a certified system, and does not onboard to the national health claims exchange in
its own name, and that this was disclosed before signature.
| For the Hospital | For Edsol Edtech Pvt. Ltd. |
|---|---|
Customer legal name |
Edsol Edtech Pvt. Ltd. |
Name: Customer signatory name |
Name: [TO BE SUPPLIED] |
Designation: Customer signatory designation |
Designation: Director |
| Signature: ____________________ | Signature: ____________________ |
| Date: ____________________ | Date: ____________________ |
| Question | Document |
|---|---|
| The responsibility matrix itself (all 39 rows) | DIS-GL-024 Section 5 Integration Boundary Statement |
| Why the boundary is drawn this way | DIS-GL-024 Section 1 to Section 4 |
| How the hospital's credentials are held, rotated, revoked and destroyed | DIS-GL-025, ADD-GL-007 |
| What the hospital must supply, and by when, across all integrations | DIS-GL-024 Section 15, FRM-GL-100 Hospital Input Pack |
| Incident notification content and clocks (rows 36, 37) | DIS-GL-016 |
| Log retention and localisation (row 38) | DIS-GL-034 |
| Support escalation | SLA-GL-001 |
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0.0 | 31 July 2026 |
Pensieve Labs Solutions |
First published edition. Sequencing plan, ageing and escalation path, per-model overlay, named-owner schedule and countersignature block. The R/A/C/I allocation itself remains in DIS-GL-024 Section 5 and is not duplicated. |