Search all 478 artefacts by title, document ID or content.
Disclosure | Family 3, Security, Privacy & Trust Disclosures
These are the answers to the four questions a hospital actually asks, stated before the detail.
This document is the source of truth for: ai-feature-inventory, ai-training-data-position, ai-opt-out, ai-subprocessor-position, rfp-ai-answer, marketing:/product/ai, marketing:/trust/ai-features
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.
Position as at 31 July 2026. This document is reviewed and republished whenever a feature
using a model is added, changed or removed, which is why its review date is shorter than the rest of the
disclosure set.
DM-1 Dedicated |
DM-2 Shared |
DM-3 Customer Cloud |
DM-4 On-Premise |
|---|---|---|---|
| Yes | Yes | Yes | Features requiring an external model provider are unavailable where the deployment has no permitted egress (Section 6) |
These are the answers to the four questions a hospital actually asks, stated before the detail.
| # | Commitment |
|---|---|
| 1 | No feature using a model makes, supports or influences a clinical decision. No diagnosis, no triage, no clinical risk score, no patient-specific dose, no image or signal interpretation, no treatment recommendation. The boundary is DIS-GL-028 Section 7 and it is enforced at the design gate, not at review |
| 2 | Hospital data is never used to train, fine-tune, or improve a model offered to any other hospital, or to Edsol Edtech Pvt. Ltd. itself. Not aggregated, not de-identified, not "with permission". The answer is no, and it is contractual: DPA-GL-001 |
| 3 | Any third party that would receive hospital data to run a model is a sub-processor, appears in DIS-GL-009 Section 2, and requires 30 days' notice with an objection right. As at 31 July 2026 there is none |
| 4 | Every model-assisted feature is optional and can be switched off per hospital, and where the output reaches a person, a named human reviews it before it has any effect |
This is the complete, dated list. A feature not on this list does not use a model.
| Feature | Function | Data used | Human review | Model runs | Opt-out | Status |
|---|---|---|---|---|---|---|
| Clinical coding suggestion | Suggests billing and diagnosis codes to a coder, from documentation the clinician has already authored, for the purpose of billing, never as a clinical conclusion | The hospital's own documentation, within the tenant | Yes: the coder accepts, edits or rejects every suggestion. Nothing is applied automatically | Within the deployment | Yes, per hospital | [TO BE SUPPLIED] (see Section 3) |
| Claim denial likelihood | Flags a claim as likely to be queried by a payer, so a human checks it before submission, from claim and payer history, not from clinical risk | Claim, tariff and payer-response history, within the tenant | Yes, a billing user decides | Within the deployment | Yes | [TO BE SUPPLIED] |
| Demand and stock forecasting | Forecasts consumption, bed occupancy and staffing demand from historical operational data | Aggregate operational data, within the tenant | Yes, a manager decides | Within the deployment | Yes | [TO BE SUPPLIED] |
| Roster optimisation | Proposes a roster against constraints the hospital sets | Staff availability and constraint data | Yes, the roster is approved by a person | Within the deployment | Yes | [TO BE SUPPLIED] |
| Document classification | Routes a scanned document to the right record and document type | The document and its metadata, within the tenant | Yes, misfiling is correctable and the correction is logged | Within the deployment | Yes | [TO BE SUPPLIED] |
| Natural-language search over the record | Finds records a user is already permitted to see. Search, not summarisation, and not inference | The tenant's own records, subject to the same authorisation as any other read | Not applicable: it returns records, it does not assert anything | Within the deployment | Yes | [TO BE SUPPLIED] |
| Transcription of dictated notes | Converts a clinician's dictation to text for the clinician to review, edit and sign. No clinical interpretation, no structuring into a diagnosis | The audio the clinician dictates | Yes: the clinician signs. Unsigned transcription is not a record | Within the deployment | Yes | [TO BE SUPPLIED] |
| Financial and operational anomaly detection | Flags unusual patterns in billing, stock and access data for human investigation | Financial, inventory and audit data | Yes | Within the deployment | Yes | [TO BE SUPPLIED] |
Every function above is administrative or operational. Not one of them touches a clinical decision, and each is designed so that a person makes the decision the output relates to.
As at
31 July 2026, the enablement status of each feature in Section 2 is[TO BE SUPPLIED]. The table above states the inventory and the boundary that governs any feature using a model, so that a hospital's evaluation can proceed against a published constraint rather than a conversation. A hospital should ask which of these are enabled in its own deployment, and the answer is recorded in the Deployment Record.
Pensieve Labspublishes the constraint before the capability deliberately: a boundary published after a feature ships is a rationalisation, and a boundary published before it is a design rule.
Stated as prohibitions, because positive commitments are easier to satisfy loosely.
DIS-GL-028 Section 7.1 is the operative list, and every item on it applies to
model-based features as much as to rule-based ones.Pensieve Labs product, not de-identified, not aggregated. This is a contractual undertaking in
DPA-GL-001 and a Pensieve Labs position stated in WPR-GL-001 Section 12.1.DM-2.Pensieve Labs's research, benchmarking,
marketing, model evaluation or product analytics.As at 31 July 2026 Edsol Edtech Pvt. Ltd. engages no third-party artificial intelligence
or machine learning provider that receives Customer Personal Data. DIS-GL-009 Section 4 records this as an
empty row rather than an omission.
If that changes:
| Step | What happens |
|---|---|
The provider is added to DIS-GL-009 Section 2, the tier that processes Customer Personal Data |
Not Section 3, and not an unlisted "AI vendor" |
| 30 days' advance notice to every affected hospital, with an objection right | DPA-GL-001 clause 8.4 |
Published in DIS-GL-010 on the day of the change |
None |
| This document is republished naming the provider, the feature, the data sent, the processing location, whether the provider may retain or train on the data (a provider that may is not engaged), and the retention period | None |
| The hospital's opt-out remains available | Section 7 |
The commitment behind the process: Pensieve Labs will not engage a model provider whose terms
permit it to retain hospital data or to train on it. That is a selection criterion, not a negotiating
position.
| Model | Position |
|---|---|
DM-1, DM-2 |
Model-based features run within the deployment's own project, under the same encryption, authorisation and audit controls as every other function |
DM-3 |
Same, inside the hospital's own project. Any egress required by a feature must be permitted by the hospital's own egress policy |
DM-4 |
Features that require an external model provider or an outbound connection are unavailable where the deployment has no permitted egress. Features that run locally are available subject to the hardware specification in ADD-GL-008. This is stated at qualification, not discovered at go-live |
| Control | Position |
|---|---|
| Per-hospital enablement | Every feature in Section 2 is off unless the hospital enables it, and can be switched off at any time through the support channel |
| Per-feature, not all-or-nothing | A hospital may enable coding suggestions and disable transcription |
| Effect of switching off | The feature disappears from the interface. No model output is retained or applied thereafter |
| Visibility of model-assisted output | Where an output originated from a model, the interface says so, and the audit trail records that the suggestion was model-generated and who accepted, edited or rejected it |
| Patient-level opt-out | Not applicable: no feature in Section 2 produces an output about an individual patient's clinical care. Where a hospital nonetheless wants a record class excluded from a feature's scope, it is configurable |
| Control | Position |
|---|---|
| Design gate | Every proposed feature using a model is assessed against DIS-GL-028 Section 7 before it is built, and the assessment is recorded (DIS-GL-018 Section 5.1) |
| Language gate | The banned vocabulary in DIS-GL-028 Section 8 applies to every description of these features, in product, documentation and sales material |
| Change control | A change to a model, a prompt, a threshold or a training set that alters behaviour is a release under DIS-GL-031, with a change record |
| Human accountability | Every feature has a named human decision point. A feature that cannot be given one is not built |
| Ethics position on research use | Using hospital data to develop or validate a model is biomedical research under the applicable Indian ethical guidance, requiring institutional ethics committee review and, in most framings, participant consent. This is a second, independent reason for commitment 2 in Section 1, alongside the data protection analysis. Pensieve Labs does not do it |
| Algorithmic due diligence | The Indian rules place a due-diligence obligation on a significant data fiduciary in respect of algorithmic software. Pensieve Labs is not so designated, and applies the discipline voluntarily: every feature in Section 2 is assessed for whether its output could disadvantage a Data Principal, and the assessment is recorded |
9.1 The enablement status is not yet published. Section 3. The inventory and the boundary are; the per-feature
status is [TO BE SUPPLIED] and is recorded per deployment.
9.2 A model's output is not explainable line by line. Where a feature suggests a code or flags a claim,
Pensieve shows the evidence it drew on, but does not produce a formal explanation of the model's
internal reasoning. This is why every feature has a human decision point rather than an explainability
claim.
9.3 Suggestions can be wrong. A coding suggestion may be incorrect and a forecast may be inaccurate.
The controls are that a person decides, that the decision is logged, and that no output has an automatic
effect. Pensieve Labs does not claim accuracy figures it has not measured and published.
9.4 Transcription is not a clinical record until a clinician signs it. An unsigned transcription is a draft. A hospital that treats it otherwise has created a clinical-safety risk that no software control can address.
9.5 Bias. Any model trained on operational data reflects the patterns in that data. For the
administrative functions in Section 2 the consequence is an inaccurate suggestion rather than a clinical harm,
which is one of the reasons the boundary in DIS-GL-028 matters: it keeps the failure mode financial and
operational rather than clinical. Pensieve Labs does not currently publish bias testing results for
these features.
9.6 No independent assessment. No third party has reviewed these features, their boundaries or their governance.
| Question | Document |
|---|---|
| The regulatory boundary these features must stay inside | DIS-GL-028 Clinical Safety Boundary Statement |
| Whether any model provider receives hospital data | DIS-GL-009 Subprocessor Register Section 2 and Section 4 |
| Notification if a model provider is engaged | DIS-GL-010 |
| The contractual prohibition on training and secondary use | DPA-GL-001 |
| Data classes and what may be processed | DIS-GL-022 |
| The design gate | DIS-GL-018 Section 5.1 |
| Release control over model changes | DIS-GL-031 |
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0.0 | 31 July 2026 |
Pensieve Labs Security |
First published edition. Four commitments, complete feature inventory with human review points, seven prohibitions, and the process for engaging a model provider. Enablement status published as unsupplied rather than asserted. |