#Integration Boundary Statement

DIS-GL-024 v1.0.0, Last Modified On 31 July 2026, Tier: Public Incorporates DIS-GL-026, ABDM / NHCX Responsibility Matrix (RACI), at Section 5.

Read this before you sign, not before you go live. This document exists to prevent the most expensive surprise available in hospital software: discovering at cutover that a regulatory registration nobody obtained is on the critical path, and that it takes six weeks.

---

#Applicability

The boundary described in this document does not change by deployment model. Who holds a credential and who is the regulated participant is a legal and architectural fact, not a hosting decision. What changes in DM-3 and DM-4 is only whose firewall the traffic passes through.

---

#Purpose

Pensieve connects to a large number of systems a hospital already deals with: the national digital health infrastructure, the claims exchange, payment providers, messaging providers, insurers and third-party administrators, laboratory analysers, imaging archives, accounting packages, biometric devices and government reporting portals.

For each of them there are five questions, and a hospital deserves the answers in writing before it signs:

1. Who holds the credential?
2. Who is the regulated or registered participant?
3. What does Pensieve do technically?
4. What does Pensieve deliberately not do?
5. What must the hospital provide, and by when?

This document answers all five, for every integration class, and then sets out the responsibility matrix for the two that most often cause a go-live to slip: ABDM and NHCX.

---

#Table of contents

1. The boundary principle, in one page
2. The credential model: bring your own credential
3. ABDM: ABHA, HFR, HPR, HIE-CM and the Gateway
4. NHCX: the National Health Claims Exchange
5. DIS-GL-026: ABDM / NHCX Responsibility Matrix (RACI)
6. Payment gateways and collections
7. SMS, WhatsApp and e-mail
8. Insurers and third-party administrator portals
9. Laboratory analysers: HL7 and ASTM
10. PACS and DICOM imaging
11. Accounting and finance systems
12. Biometric and attendance devices
13. Government reporting portals
14. The universal boundary: what Pensieve never does
15. What the hospital must supply, and by when
16. Failure modes, support and escalation
17. Limitations
18. Related documents
19. Change history

---

#1. The boundary principle, in one page

#1.1 The principle

Pensieve acts 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.

#1.2 Why it is built this way

Four reasons, in order of how much they matter to the hospital.

1. The registrations belong to the hospital by design. A Health Facility Registry identifier identifies a facility. A Healthcare Professionals Registry identifier identifies a clinician. An NHCX participant code identifies a claims participant. A payment merchant identifier identifies a merchant. In every case the regulator, the exchange or the network 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.

2. It keeps the hospital 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 the hospital and remain the hospital's when the relationship ends.

3. It keeps liability where the law puts it. The hospital is the Data Fiduciary. The hospital is the health facility. The hospital is the claims participant. A vendor asserting those roles takes on regulatory exposure it cannot discharge and confuses the hospital's own compliance position.

4. It removes a certification dependency from the deal clock. Because Pensieve operates on the hospital's credentials, a hospital does not have to wait for Pensieve Labs to complete a national certification programme before it can go live.

#1.3 The one place this can hurt you, stated first

Edsol Edtech Pvt. Ltd. does not hold ABDM M1/M2/M3 milestone certification and is not an ABDM-certified hospital management system.

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 in this document changes that, and Pensieve Labs will not imply otherwise.

Check this at qualification. Section 3.5 tells you exactly what to check and who to ask. It takes one phone call and it can save you two months.

#1.4 The map

flowchart LR
  subgraph HOSP["The hospital: registered participant, credential holder"]
    HFR["HFR facility ID"]
    HPR["HPR clinician IDs"]
    NHCXID["NHCX participant code"]
    MID["Payment merchant ID"]
    SENDER["SMS / WhatsApp sender ID"]
    TPA["Insurer and TPA relationships"]
  end
  subgraph PENS["Pensieve Labs: builds and operates the connection"]
    VAULT[["Per-tenant credential vault<br/>encrypted, write-only"]]
    CONN["Integration services<br/>protocol, mapping, retry, logging"]
  end
  subgraph EXT["External systems"]
    A["ABDM Gateway / HIE-CM"]
    N["NHCX"]
    P["Payment networks"]
    M["Messaging providers"]
    I["Insurers / TPAs"]
    L["Analysers, PACS, devices"]
    G["Government portals"]
  end
  HOSP -->|supplies credentials| VAULT
  VAULT --> CONN
  CONN -->|calls as the hospital| A
  CONN -->|calls as the hospital| N
  CONN -->|calls as the hospital| P
  CONN -->|calls as the hospital| M
  CONN -->|calls as the hospital| I
  CONN --> L
  CONN -->|prepares submissions| G

Text description. The hospital holds every registration and credential: its facility registry identifier, its clinicians' professional registry identifiers, its claims-exchange participant code, its payment merchant identifier, its messaging sender identity and its insurer relationships. It supplies those credentials to Pensieve's per-tenant encrypted vault. Pensieve's integration services use them to call the external systems as the hospital. For government portals that have no machine interface, Pensieve prepares the submission and the hospital files it.

---

#2. The credential model: bring your own credential

The mechanics are set out in full in the BYOK/BYOC Credential Handling Disclosure (DIS-GL-025). The security-relevant summary:

The property that matters most. A hospital can revoke every credential Pensieve holds without asking Pensieve Labs, without waiting for a support ticket, and without a contractual process simply by going to each external system and revoking there. That is the strongest possible control a customer can hold over a vendor's access to its external relationships, and it exists because the credentials were never Pensieve Labs's.

---

#3. ABDM: ABHA, HFR, HPR, HIE-CM and the Gateway

#3.1 What the components are, and whose they are

Sources for the component model: 01-research/india/01-regulatory-landscape.md Section 3, which cites the National Health Authority's implementer documentation.

#3.2 Who holds the credential and who is the regulated participant

#3.3 What Pensieve does technically

Using the hospital's own credentials, and subject to Section 3.5:

• Captures and verifies ABHA identity at registration: ABHA number and ABHA address capture, verification, and linkage to the hospital's own patient record, so that a returning patient is matched rather than duplicated.
• Maintains the clinical record in a structured form suitable for conversion to HL7 FHIR R4 resources: patient, practitioner, encounter, observation, condition, medication request, diagnostic report and document reference, as required for record sharing.
• Creates and maintains care contexts linked to a patient's ABHA, so that records are discoverable under the national model.
• Validates consent artefacts cryptographically on every request and refuses anything outside the artefact's scope: the requested information types, the date range, the purpose and the expiry. A consent artefact is a boundary, not a suggestion, and Pensieve treats it as one.
• Encrypts record transfers as the specification requires and logs every transfer with the requesting party, the consent artefact reference, the information types and the timestamp.
• Binds each clinical document to the clinician's identity, including the professional registry identifier where the clinician holds one.
• Raises and tracks consent requests where the hospital is acting as an information user, honours expiry, and renders retrieved records to authorised staff.
• Keeps ABDM consent separate from consent under the data protection law. They are different instruments with different scopes and different lifecycles, and Pensieve does not conflate them. See WPR-GL-003.

#3.4 What Pensieve does not do

• It does not register the hospital on the HFR. The hospital does that itself, free, on the national facility portal.
• It does not obtain HPR identifiers for clinicians. Each clinician does that personally; the identifier is tied to that clinician's council registration and cannot be obtained by an employer or a vendor.
• It does not create ABHA numbers without the patient's participation and consent.
• It does not hold ABDM credentials in Edsol Edtech Pvt. Ltd.'s name.
• It does not hold ABDM milestone certification, and does not act as a certified ABDM connector.
• It does not decide the hospital's ABDM policy: which record types to share, which departments participate, what the patient is told. Those are the hospital's decisions and Pensieve implements them.
• It does not guarantee the availability, latency or behaviour of the national infrastructure. Downtime at the Gateway or the consent manager is outside Pensieve Labs's control and is excluded from the service level commitments (SLA-GL-001).

#3.5 The check that must happen at qualification

Do this before signing. It takes one call.

Pensieve Labs asks these questions in the first qualification conversation. If the answer to any of them makes certified-vendor status a hard requirement, Pensieve Labs will say plainly that Pensieve does not meet it, rather than proceeding and hoping. That conversation is unpleasant on day two and catastrophic on day sixty.

#3.6 What the hospital must provide, and by when

---

#4. NHCX: the National Health Claims Exchange

#4.1 What it is

The National Health Claims Exchange is a standardised digital gateway routing health insurance claims between providers, payers and beneficiaries, built by the National Health Authority in consultation with the insurance regulator, under the national digital health umbrella. It replaces a hospital's separate integrations with each insurer and third-party administrator portal with a single standards-based submission.

The commercial point for a 50 to 200-bed hospital is receivables, not compliance: insurance is a large share of revenue and the claims cycle is where the money sits. Source: 01-research/india/01-regulatory-landscape.md Section 4.

#4.2 Who holds the credential and who is the regulated participant

#4.3 What Pensieve does technically

• Assembles the pre-authorisation and claim packet from the clinical and billing record: coverage eligibility, the pre-authorisation request, the claim, supporting documents and the communications that follow, mapped to the required standard resources.
• Validates completeness before submission. This is the feature that matters commercially: the regulator's timelines for cashless authorisation are obligations on the insurer, and they are unachievable unless the hospital submits a complete, structured, conformant packet. Pensieve refuses to send an incomplete packet and tells the user what is missing, at the point of care, rather than generating a rejection three days later.
• Transmits using the hospital's participant credentials.
• Tracks the claim lifecycle (submitted, queried, approved, rejected, settled) and surfaces ageing and the reason codes for rejection so the billing office can work the queue.
• Reconciles payment notifications against the hospital's receivables.
• Logs every exchange with the counterparty, the timestamp and the outcome.

#4.4 What Pensieve does not do

• It does not onboard the hospital to NHCX. The hospital registers as a participant.
• It does not hold the participant code or credentials in Edsol Edtech Pvt. Ltd.'s name.
• It does not decide clinical or billing content. What is claimed, at what tariff, with what documentation, is the hospital's decision and the hospital's responsibility.
• It does not adjudicate, negotiate or guarantee a claim outcome. Pensieve Labs has no relationship with any insurer or third-party administrator and no ability to influence a decision.
• It does not guarantee the availability or behaviour of the exchange or of any payer's systems.
• It does not replace the hospital's obligation to hold and produce the underlying clinical record.

#4.5 What the hospital must provide

#4.6 The honest sequencing advice

NHCX does not block a go-live. A hospital can be fully live on Pensieve for registration, clinical, pharmacy, billing, stores, with claims still being filed the way they are filed today, and switch to the exchange afterwards. Pensieve Labs recommends exactly that: go live first, then move claims. Sequencing NHCX into the initial cutover adds a dependency on a third party's onboarding queue to a date the hospital has already announced to its staff.

---

#5. DIS-GL-026: ABDM / NHCX Responsibility Matrix (RACI)

This section is the artefact DIS-GL-026. It is published here rather than separately so that no hospital reads the boundary without the matrix, or the matrix without the boundary.

Legend. R = Responsible, does the work; A = Accountable, owns the outcome and cannot delegate it and C = Consulted before it happens, I = Informed after it happens. Every row has exactly one A.

#5.1 Registration and identity

#5.2 Record sharing and consent

#5.3 Claims through the exchange

#5.4 Certification, audit and compliance

#5.5 The five rows that decide whether a go-live slips

If a hospital reads nothing else in this document, read these.

---

#6. Payment gateways and collections

Covers online payment gateways, card terminals, unified payments interface collections, and any payment aggregator the hospital uses.

What Pensieve does technically. Initiates a payment request against the hospital's bill, using the hospital's gateway credentials; renders the payment interface or generates the collection link or code; receives the gateway's callback; reconciles the payment against the invoice, the patient and the encounter; posts the receipt; handles refunds initiated by an authorised hospital user; and produces the day-end collection and reconciliation reports the cashier and the accounts department need.

What Pensieve does not do.

• It does not hold, receive, route or settle funds. Edsol Edtech Pvt. Ltd. is not a payment intermediary and is not licensed as one.
• It does not store full card numbers, card verification values, unified payments interface personal identification numbers or bank credentials. Card data handling stays with the gateway or the terminal; Pensieve stores only the non-sensitive references the gateway returns: a transaction reference, the last four digits, the instrument type, the status.
• It does not decide refund policy. It enforces the hospital's.
• It does not guarantee gateway availability, settlement timing or dispute outcomes.
• It does not act as merchant of record.

What the hospital must provide. An active merchant account with its chosen gateway; API credentials issued to the hospital; the settlement bank account details for reconciliation; the refund authorisation matrix; the receipt numbering series and the tax treatment; and a named owner in accounts.

---

#7. SMS, WhatsApp and e-mail

Covers transactional messaging to patients and staff: appointment confirmations, admission and discharge notifications, report-ready alerts, payment receipts and reminders.

What Pensieve does technically. Triggers a message on a clinical or administrative event; populates the hospital's approved template with the correct values; calls the hospital's messaging provider using the hospital's credentials; records delivery status; retries on transient failure; and suppresses sending where the patient has opted out or where the hospital's configuration says not to send.

What Pensieve does not do.

• It does not register sender identities, headers or templates. That is done by the hospital with its provider and, where applicable, with the telecom regulator's registry.
• It does not send marketing or promotional messages. Pensieve sends transactional messages arising from a clinical or administrative event. A hospital that wants to run a marketing campaign must do it elsewhere, on a consent basis it manages.
• It does not decide what a patient is told. The template content is the hospital's, and the hospital is responsible for its accuracy and its confidentiality implications.
• It does not guarantee delivery. Carrier delivery, template approval delays and provider outages are outside Pensieve Labs's control.

The confidentiality point a hospital should think about before configuring templates. A message containing a diagnosis, a test result or a department name discloses health information to whoever is holding the phone. Pensieve supports minimised templates: "your report is ready, please collect" rather than the result itself, and Pensieve Labs recommends them. The choice is the hospital's, and it is a Data Fiduciary decision.

What the hospital must provide. A messaging provider account with credentials issued to the hospital; registered sender identity and approved templates; the template content and language variants; the opt-out handling policy; and a named owner.

---

#8. Insurers and third-party administrator portals

Covers direct integrations and portal-based working with insurers, third-party administrators and government-funded scheme portals, where these are used instead of, or alongside, the claims exchange.

What Pensieve does technically. Maintains payer masters, tariffs, package definitions and exclusion rules; assembles the pre-authorisation and claim documentation set from the clinical and billing record; validates completeness against the payer's requirements before submission; where the payer offers a machine interface, transmits on the hospital's credentials; where the payer offers only a portal, produces the complete submission pack for a hospital user to upload; tracks status, queries, approvals, rejections and ageing; and reconciles settlements and short-payments against receivables.

What Pensieve does not do.

• It does not obtain or maintain the hospital's empanelment with any payer or scheme.
• It does not perform automated logins to payer portals using stored credentials where the payer's terms prohibit it. Where a payer requires a human session, Pensieve prepares the pack and a hospital user files it.
• It does not decide clinical content, coding or claim value.
• It does not negotiate, adjudicate or guarantee an outcome, and it does not represent the hospital in a dispute.
• It does not commit to any payer's response time. Those are obligations between the hospital, the payer and the payer's regulator.

What the hospital must provide. Its empanelment list and provider identifiers; portal credentials where integration is possible and permitted; agreed tariffs and package definitions per payer; the documentation checklist each payer requires; the authorisation matrix for who may submit and who may accept a short-payment; and a named owner in the billing office.

---

#9. Laboratory analysers: HL7 and ASTM

Covers bidirectional interfacing with laboratory instruments: haematology, biochemistry, immunoassay, coagulation, urine analysers and microbiology systems.

What Pensieve does technically. Sends the work order to the instrument or to the middleware (order-entry direction); receives results over the instrument's supported protocol, typically HL7 v2 messaging over a network connection, or ASTM over serial or network where the instrument is older; maps instrument test codes to the hospital's test master and to standard terminology where the hospital has adopted it; applies the hospital's configured reference ranges, delta checks and critical-value rules; routes results to the technologist's validation queue; and publishes only after the hospital's authorised person validates.

What Pensieve does not do.

• It does not perform, calibrate, control or maintain any analytical process. Calibration, internal quality control, external quality assurance and instrument maintenance are the laboratory's.
• It does not auto-release a result without the hospital's configured validation rule. Where a hospital configures auto-release for a defined set of tests within defined limits, that is the hospital's clinical governance decision, recorded as such.
• It does not interpret results, generate a diagnosis, or make a clinical recommendation. Delta checks and critical-value flags are the hospital's configured thresholds surfaced to a human, not a clinical judgement by Pensieve. See DIS-GL-028.
• It does not modify instrument firmware or configuration.
• It does not warrant the behaviour of a third-party instrument or its middleware.

The security limitation, stated rather than glossed. Many analysers and their middleware speak protocols that predate modern transport security, and some cannot be configured for encrypted transport at all. Where such a device is in scope, the connection is confined to the hospital's own network segment, is not exposed beyond it, and the limitation is recorded in the deployment record. Pensieve Labs does not describe such a link as encrypted. See WPR-GL-001 Section 17.6.

What the hospital must provide. The instrument list with make, model, protocol and interface capability; instrument vendor engagement where an interface licence or a driver is required: many instrument vendors charge for the interface, and this is a hospital cost, not a Pensieve Labs cost; network connectivity and addressing to each instrument; the test master and reference ranges; the validation and auto-release policy; and a named owner in the laboratory.

---

#10. PACS and DICOM imaging

Covers radiology and other imaging modalities, the picture archiving and communication system, and the worklist that connects them.

What Pensieve does technically. Publishes the modality worklist so a technologist sees the correct patient, order and accession number at the modality rather than typing it; receives and stores the study reference; links the study to the patient record, the encounter, the order and the invoice; launches the hospital's viewer in context so a clinician moves from the order to the images without re-searching; and manages the reporting workflow: assignment, draft, verification, sign-off, addendum and distribution.

What Pensieve does not do.

• It is not a picture archiving and communication system and does not replace one. It integrates with the hospital's.
• It is not a diagnostic viewer. Pensieve does not render images for diagnostic interpretation and must not be used for it. Diagnostic reading happens in the hospital's own validated viewer on the hospital's own display.
• It does not perform image processing, reconstruction, measurement, computer-aided detection or any form of automated interpretation. See DIS-GL-028.
• It does not warrant the hospital's archive, its storage capacity, its retention configuration or its vendor's behaviour.

What the hospital must provide. The modality and archive inventory with connection details; the archive vendor's cooperation and any interface licence it requires; agreed application entity titles, ports and network paths; storage capacity and retention policy for images, which remain in the hospital's archive; the reporting workflow definition and the sign-off authority; and a named owner in radiology.

---

#11. Accounting and finance systems

Covers the hospital's statutory books, whether kept in a desktop accounting package, an enterprise finance system or a chartered accountant's own system.

What Pensieve does technically. Maintains the operational financial record: billing, receipts, refunds, credit notes, purchases, goods receipt, supplier invoices, payables ageing, receivables ageing, stock valuation and consumption; produces posting-ready exports mapped to the hospital's chart of accounts; and, where the hospital's accounting system exposes a supported interface and the hospital supplies credentials, posts entries directly and reconciles what was posted against what was intended.

What Pensieve does not do.

• It does not replace the hospital's accounting system or its statutory books.
• It does not prepare, sign or file any statutory return (tax, payroll, or otherwise). It produces the data the hospital's accountant uses.
• It does not determine tax treatment, rates, exemptions or classifications. Pensieve applies the treatment the hospital configures, on the hospital's accountant's advice.
• It does not give accounting, tax or audit advice, and nothing in the Platform's output should be treated as such.

What the hospital must provide. The chart of accounts and the mapping to Pensieve's transaction types; the accounting system's version and interface capability; credentials where direct posting is used; the tax configuration confirmed by the hospital's accountant; the financial year, document numbering series and the period-close calendar; and a named owner in accounts.

---

#12. Biometric and attendance devices

Covers fingerprint, facial-recognition and card-based attendance terminals, and access-control devices where the hospital wants attendance and duty rosters connected.

What Pensieve does technically. Reads attendance events, employee identifier, timestamp, direction, device, from the device or its controller; maps them to the hospital's employee master; applies the hospital's shift, roster, grace, overtime and leave rules; produces attendance registers, duty rosters, exception reports and payroll inputs; and reconciles attendance against rostered clinical cover.

What Pensieve does not do.

• It does not store raw biometric images or biometric templates. Pensieve consumes the attendance event, not the biometric. The template stays where the device vendor keeps it.
• It does not perform biometric matching or enrolment.
• It does not decide whether biometric attendance is lawful or appropriate for the hospital's workforce. That is the hospital's decision as the employer and Data Fiduciary, and it carries notice and purpose-limitation obligations the hospital must discharge.
• It does not operate physical access control. Where an access-control system exists, Pensieve may consume its events; it does not grant or deny physical access.

What the hospital must provide. The device inventory with make, model and interface; device credentials or controller access; the employee master with device identifiers mapped; the shift, roster and overtime policy; its own lawful basis and notice for biometric processing; and a named owner in human resources.

---

#13. Government reporting portals

Covers statutory and public-health reporting: notifiable disease surveillance, birth and death reporting, district and state health returns, government-funded scheme portals, and employment-related statutory returns.

What Pensieve does technically. Captures the underlying data as a by-product of ordinary clinical and administrative work, so that a notifiable diagnosis, a birth, a death, an adverse drug reaction or an infection-surveillance event is recorded when it happens rather than reconstructed at month-end; maintains the statutory registers a hospital is required to keep; generates the return in the required format and to the required schedule; flags a due or overdue return to a named hospital owner; and, where a portal offers a supported machine interface and the hospital supplies credentials, submits on the hospital's behalf and records the acknowledgement.

What Pensieve does not do.

• It does not file a return in Edsol Edtech Pvt. Ltd.'s name, and is never the reporting entity.
• It does not hold the hospital's portal credentials in Edsol Edtech Pvt. Ltd.'s name.
• It does not determine what is reportable. Notifiable-disease lists vary by state and change; Pensieve applies the list the hospital configures and flags when the configuration was last reviewed. Keeping it current is the hospital's obligation.
• It does not replace the clinician's or the hospital's own statutory duty to notify, particularly for time-critical notifications, where the duty is on a person and not on a system.
• It does not guarantee a portal's availability, its format stability, or that a submission will be accepted. Government portals change formats without notice; Pensieve Labs treats a format change as a defect and fixes it under the support process, but cannot pre-empt it.

What the hospital must provide. The applicable return list for its state, district and facility type; portal registrations and credentials; the state notifiable-disease list and a review cadence; the format specifications for local returns; the named accountable person for each return; and confirmation of the filing calendar.

---

#14. The universal boundary: what Pensieve never does

Across every integration class in this document, without exception:

1. Edsol Edtech Pvt. Ltd. is never the regulated participant, the registered entity, the empanelled provider, the merchant, the sender of record, the reporting entity or the licence holder.
2. Edsol Edtech Pvt. Ltd. never holds a credential in its own name on a hospital's behalf. Every credential is issued to the hospital and is revocable by the hospital, unilaterally, at the source.
3. Edsol Edtech Pvt. Ltd. never handles the hospital's money. Funds move between the hospital, its payers and its patients through the hospital's own accounts.
4. Edsol Edtech Pvt. Ltd. never makes a clinical decision. Pensieve does not diagnose, triage, score, calculate a patient-specific dose or recommend treatment, in any integration. DIS-GL-028 is the binding statement.
5. Edsol Edtech Pvt. Ltd. never warrants a third party's system. Availability, latency, format stability, adjudication outcomes and regulatory behaviour of external systems are outside Pensieve Labs's control and are excluded from the service level commitments in SLA-GL-001.
6. Edsol Edtech Pvt. Ltd. never uses a hospital's credential for any purpose other than the hospital's own integration, and never for another tenant.
7. Edsol Edtech Pvt. Ltd. never retains a hospital's credential after offboarding. Deletion is covered by the Certificate of Deletion (DIS-GL-023).

---

#15. What the hospital must supply, and by when

This is the consolidated list. It is issued as part of the Hospital Input Pack at Stage 2, with per-item ageing, because hospital-side inputs are the dominant schedule risk in every deployment.

How Pensieve Labs handles this list. It is issued once, as a single pack, at Stage 2, not dribbled out over six weeks. Every line has an owner, a due date and an ageing counter. Every line that Pensieve Labs can pre-fill from information already supplied is pre-filled. The purpose is to make the hospital's own critical path visible to the hospital on day two rather than on day forty.

---

#16. Failure modes, support and escalation

#16.1 Who fixes what

#16.2 Queueing and retry

Where an external system is unavailable, Pensieve queues and retries in accordance with the protocol, and surfaces the backlog rather than hiding it. Where a protocol does not permit safe retry, because a duplicate submission would create a duplicate claim, a duplicate payment or a duplicate record, Pensieve stops and asks a human rather than retrying blind. A hospital should expect an integration failure to appear as a visible queue with an owner, not as a silence.

#16.3 Escalation

Integration failures follow the severity model and escalation path in SLA-GL-001. An integration failure that prevents patient care (a laboratory interface down during a working shift, a worklist not reaching a modality) is a high-severity incident regardless of whose system caused it, and Pensieve Labs engages on that basis while the underlying ownership is established.

---

#17. Limitations

17.1 Edsol Edtech Pvt. Ltd. holds no ABDM milestone certification and no NHCX participant status. Where a state, scheme, payer or accreditation criterion requires the software itself to be certified, Pensieve does not satisfy it. Section 3.5 tells you how to check in one call.

17.2 Not every payer, instrument, archive or portal has a machine interface. Where one does not, Pensieve prepares the submission and a human files it. Pensieve Labs will say which is the case for a hospital's actual list during the technical review, rather than describing a general capability.

17.3 Some instrument vendors charge for the interface. Interface licences, drivers and middleware licences demanded by an instrument or archive vendor are a hospital cost. Pensieve Labs will identify them during the technical review; it cannot waive another vendor's commercial terms.

17.4 Some legacy devices cannot support modern transport security. See Section 9. The limitation is recorded, the link is confined to the hospital's network segment, and it is not described as encrypted.

17.5 Government portal formats change without notice. Pensieve Labs fixes format breaks as defects. It cannot pre-empt them, and a return may need manual filing for one cycle.

17.6 The availability of every external system is outside Pensieve Labs's control, and is excluded from the availability commitments in SLA-GL-001.

17.7 In DM-4, outbound connectivity is the hospital's. An integration cannot function through a firewall Pensieve Labs cannot see, on an internet link Pensieve Labs does not control. DM-4 hospitals must plan outbound connectivity and its resilience as part of the deployment.

17.8 The integration list is not exhaustive. A hospital with an integration not listed here should raise it at qualification. Pensieve Labs will say whether it is supported, whether it can be built, and what it would cost, before signature, not after.

---

#18. Related documents

---

#19. Change history

---

Document control. DIS-GL-024 v1.0.0, Last Modified On 31 July 2026, Review due 31 January 2027 | Tier: Public | Applies to DM-1, DM-2, DM-3, DM-4. Incorporates DIS-GL-026.