#Deployment Models Explained

WPR-GL-004 v1.0.0, Last Modified On 31 July 2026, Tier: Public

This document is the single source of truth for the definitions of DM-1 to DM-4. Every other Pensieve Labs artefact references these definitions rather than restating them.

---

#Applicability

---

#Purpose

A hospital buying Pensieve has to answer one question before anything else can be scheduled: where does it run, and who owns the infrastructure it runs on?

Four answers are supported. All four are real products, not a menu with three placeholders and one option that is actually sold. The choice changes the isolation story, the data location, the availability commitment, the security responsibilities, the price shape and, by a very large margin, the date the hospital goes live.

This document is written twice. Part A is for the person who signs, in plain language, with no networking vocabulary. Part B is for the person who has to approve it technically. Part C compares. Part D helps you decide. Part E states Pensieve Labs's honest recommendation, which is that DM-1 is right for most hospitals and that DM-4 will cost you months.

---

#Table of contents

• Part A: For the decision-maker
• Part B: For the technical reviewer
  • DM-1 Dedicated
  • DM-2 Shared
  • DM-3 Customer Cloud
  • DM-4 On-Premise
• Part C: Comparison matrix
• Part D: Decision guide
• Part E: The recommendation, stated honestly
• Part F: Changing model later
• Related documents
• Change history

---

#Part A: For the decision-maker

#A.1 The question, without the jargon

Pensieve is the system your hospital will run on: registration, admission, orders, pharmacy, laboratory, billing, stores, HR, accounts, reporting. It has to run on computers somewhere, and those computers have to be owned, powered, secured, patched, backed up and watched by somebody.

The only question is: whose computers, and who does the watching?

#A.2 The five things that actually change

Everything else in this document is detail. These five are the decision.

1. When you go live. DM-1 and DM-2 are the only models that fit the two-week target. DM-3 adds the time it takes your organisation to create a cloud account, agree an access arrangement and get its own approvals, usually several weeks. DM-4 adds hardware procurement, delivery, room preparation and installation: usually two to three months, and often more. Nobody has ever shortened a hardware delivery by asking nicely.

2. Who you call at 2 a.m. In DM-1 and DM-2, Pensieve Labs is watching, and the availability commitment is Pensieve Labs's. In DM-4, the server is in your building, on your power, on your network, so if the air conditioning fails on a Sunday, that is your event, not Pensieve Labs's, and no contract can change that.

3. Who holds the keys. In DM-3 and DM-4 you hold the encryption keys and you can revoke Pensieve Labs's access yourself, without asking. In DM-1 and DM-2 Pensieve Labs holds them, and your control is contractual and audited rather than structural. If your board's position is "we must be able to cut the vendor off ourselves", that sentence chooses DM-3.

4. What you spend, and how. DM-1 and DM-2 are an operating expense inside the platform fee: no hardware, no cloud bill, no server room, no systems administrator. DM-3 is an operating expense too, but split: you pay your own cloud bill directly. DM-4 is capital expenditure: servers, storage, backup, uninterruptible power, cooling, network equipment, plus the staff to look after them, plus a refresh in four or five years.

5. Where the data physically is. For Indian hospitals, all four models keep patient data inside India. DM-1, DM-2 and DM-3 keep it in an Indian cloud region; DM-4 keeps it in your building. If your requirement is "the data must not leave this campus", only DM-4 satisfies it, and you should choose it knowing what it costs.

#A.3 What does not change

It is worth being equally clear about what is identical across all four:

• The same software. There is no cut-down on-premise edition and no premium hosted edition. The same Pensieve build runs in all four models.
• The same contract structure. One Master Services Agreement, one Data Processing Agreement, one Service Level Agreement, with model-specific variations rather than four separate paper stacks.
• Your ownership of your data. In every model the hospital is the Data Fiduciary and Edsol Edtech Pvt. Ltd. is the Data Processor. Pensieve Labs never owns your data, never sells it, never trains models on it for anyone else.
• Your right to leave with your data. The export commitment in WPR-GL-400 and the deletion process in DIS-GL-023 apply identically in all four models.
• Pensieve Labs's security posture. The controls in the Security Whitepaper (WPR-GL-001) apply in every model; what changes is which of them Pensieve Labs can actually execute for you, and WPR-GL-001 Section 18 sets that out line by line.

#A.4 The honest summary, in four sentences

Most 50 to 200-bed hospitals should choose DM-1. It is the fastest, it needs nothing from your IT team, and its isolation story is short enough to satisfy a board in one meeting. Choose DM-3 if your organisation has a genuine policy requiring you to own the cloud account and has people who can operate one. Choose DM-4 only if you cannot use public cloud at all, and accept, before you start, that you are choosing a timeline measured in months rather than weeks.

---

#Part B: For the technical reviewer

Each model below follows the same structure: what it is, architecture, who controls what, data location, isolation model, availability, RTO and RPO, security responsibilities, cost shape, time to go-live, who it suits, when it is the wrong answer.

---

#B.1 DM-1: Dedicated, Pensieve-hosted, isolated

#What it is

One isolated Google Cloud project per hospital, created inside Edsol Edtech Pvt. Ltd.'s cloud organisation. Inside that project: dedicated Cloud Run services, a dedicated PostgreSQL instance, dedicated storage buckets, a dedicated Cloud KMS key ring, a dedicated log bucket and a dedicated network. Nothing in the project is shared with any other hospital.

#Architecture

flowchart TB
  subgraph ORG["Pensieve Labs cloud organisation"]
    subgraph P1["GCP project: Hospital A (dedicated)"]
      A1["Cloud Run services"]
      A2[("PostgreSQL")]
      A3[("Object storage")]
      A4[["KMS key ring A"]]
      A5[("Log bucket A, ≥365d, locked")]
    end
    subgraph P2["GCP project: Hospital B (dedicated)"]
      B1["Cloud Run services"]
      B2[("PostgreSQL")]
    end
  end
  UA["Hospital A users"] -->|HTTPS| A1
  UB["Hospital B users"] -->|HTTPS| B1
  A1 --> A2
  A1 --> A3
  A4 -.encrypts.-> A2
  A4 -.encrypts.-> A3
  A1 --> A5
  OPS["Pensieve Labs engineer<br/>time-bound, approved, logged"] -.->|IAM grant| P1

Text description. Each hospital has its own Google Cloud project inside Pensieve Labs's organisation. Hospital A's project contains its own Cloud Run services, database, object storage, KMS key ring and log bucket; Hospital B's project contains a separate set. Users reach only their own project. A Pensieve Labs engineer can reach a project only through a time-bound, approved and logged IAM grant.

#Who controls what

#Data location

Google Cloud India region, recorded as Deal data region on the Order Form. All customer personal data and all system logs remain within Indian jurisdiction. Per-market positions are in DIS-GL-008.

#Isolation model

Project-level isolation. Separate cloud tenancy, separate IAM boundary, separate network, separate database instance, separate encryption keys. There is no code path by which a session authenticated in one project can read data in another, because the projects do not share a data plane. This is the strongest isolation available without the hospital owning the infrastructure, and it is short enough to explain in a paragraph, which matters more than it should, because a security review that can be closed in one meeting is worth days on the deal clock.

#Availability, RTO and RPO

Committed in SLA-GL-001, with the measurement method and exclusions stated there. The deal-specific values are Deal RTO hours and Deal RPO minutes on the Order Form. Pensieve Labs executes the restore. Restore drills are run quarterly and the measured results published (DIS-GL-014).

#Security responsibilities

Pensieve Labs holds everything below the application boundary: infrastructure, patching, backup, monitoring, key management, network. The hospital holds user lifecycle, roles, endpoint security, external credentials and its own regulatory obligations. WPR-GL-001 Section 18 is the line-by-line matrix.

#Cost shape

Included in the platform fee. There is no separate cloud bill, no hardware, no server room and no systems administrator. Per-hospital infrastructure costs more to run than shared infrastructure, and the price reflects that; the Order Form carries Deal platform fee.

#Time to go-live

Fastest of the four. DM-1 is the only model Pensieve Labs will underwrite on the TRK_EXPRESS track: a go-live target of 14 days or fewer from first contact, provided the hospital's own inputs arrive on schedule. There is no procurement, no hardware, no third-party account creation and no inter-organisation access negotiation on the critical path. Provisioning a dedicated project is automated.

What can still delay it, and all of it is hospital-side: master data (departments, services, tariffs, users), legacy data migration if any, external-system credentials, and the decision-maker's own calendar. These are tracked as the Hospital Input Pack.

#Who it suits

Private hospitals from roughly 50 to 200 beds; single-site and small multi-site groups; any hospital that wants a dedicated-infrastructure answer for its board without acquiring cloud competence; any hospital whose priority is being live this month.

#When DM-1 is the wrong answer

• A written policy requires the hospital to own the cloud account → DM-3.
• A written policy or a connectivity reality prohibits public cloud entirely → DM-4.
• A small clinic for which dedicated infrastructure is not economically sensible → DM-2.

---

#B.2 DM-2: Shared, Pensieve-hosted, multi-tenant

#What it is

A shared Pensieve platform serving multiple tenants from common infrastructure, with isolation enforced logically: tenant binding at authentication, PostgreSQL row-level security, per-tenant encryption keys and per-tenant storage prefixes.

#Architecture

flowchart TB
  subgraph SHARED["Shared GCP project, one per region"]
    R["Cloud Run services<br/>tenant bound at authentication"]
    DB[("PostgreSQL<br/>row-level security per tenant")]
    OBJ[("Object storage<br/>per-tenant prefix + per-tenant key")]
    KMS[["KMS key ring<br/>per-tenant data keys"]]
    LOG[("Log bucket, ≥365d, locked")]
  end
  T1["Tenant A users"] -->|HTTPS| R
  T2["Tenant B users"] -->|HTTPS| R
  R --> DB
  R --> OBJ
  KMS -.per-tenant keys.-> DB
  KMS -.per-tenant keys.-> OBJ
  R --> LOG

Text description. One shared cloud project per region holds shared Cloud Run services, one PostgreSQL instance with row-level security policies scoping every row to a tenant, one object store with per-tenant prefixes encrypted under per-tenant keys, a KMS key ring holding those keys, and a shared immutable log bucket. All tenants' users reach the same services; the tenant is bound server-side at authentication and cannot be changed by the client.

#Who controls what

Identical to DM-1 on the hospital side. On the Pensieve Labs side the difference is that the infrastructure is shared, so infrastructure-level changes affect more than one hospital and are scheduled accordingly.

#Data location

Same as DM-1: Indian region for Indian hospitals, Deal data region on the Order Form.

#Isolation model

Logical, in four layers. Detailed in WPR-GL-001 Section 3.4 and in full in DIS-GL-032:

1. Tenant identity is derived server-side from the authenticated principal. It cannot be supplied, guessed or altered by the client.
2. PostgreSQL row-level security policies are attached to the tables. A query missing the tenant predicate returns nothing rather than returning another tenant's rows.
3. Each tenant's data is encrypted with its own data encryption key. Storage-level access to another tenant's ciphertext does not produce plaintext.
4. Object storage access is authorised per tenant prefix and encrypted under the tenant's key.

The honest statement. Shared infrastructure means an application-layer flaw has a larger potential blast radius than in DM-1. The layers above are designed so a single flaw is not sufficient. Pensieve Labs does not claim DM-2 is equivalent to DM-1, and a hospital that will not accept logical isolation should choose DM-1, which Pensieve Labs will not argue with.

#Availability, RTO and RPO

Committed in SLA-GL-001 on the same basis as DM-1. One operational difference worth knowing: a maintenance window in DM-2 is common to all tenants on that platform, so a hospital cannot choose its own window. In DM-1 it can.

#Security responsibilities

Identical to DM-1, with the added Pensieve Labs obligation to maintain and test tenant isolation, which is why isolation testing is part of the release pipeline rather than an annual exercise.

#Cost shape

The lowest of the four. Shared infrastructure amortises across tenants and the price reflects it.

#Time to go-live

As fast as DM-1, sometimes marginally faster: there is no project to provision, only a tenant to create. Eligible for TRK_EXPRESS.

#Who it suits

Small clinics, single-speciality units, day-care centres, diagnostic centres, and hospitals below roughly 50 beds where dedicated infrastructure is not economically proportionate. Also appropriate for a group's smaller units where the flagship hospital runs DM-1.

#When DM-2 is the wrong answer

• The hospital's board, insurer or accreditation body requires dedicated infrastructure.
• The hospital needs to control its own maintenance window.
• The hospital's security review will not accept logical isolation. This is a legitimate position and it points to DM-1.

---

#B.3 DM-3: Customer Cloud

#What it is

The hospital owns a Google Cloud project and pays Google directly for it. Pensieve Labs deploys Pensieve into that project and operates it there, under a Delegated Cloud Access & Administration Agreement that names the IAM roles granted, the least-privilege scope, the break-glass procedure, the logging the hospital can see, and what happens to access on termination.

#Architecture

flowchart TB
  subgraph HOSP["Hospital's own GCP organisation and billing account"]
    subgraph P["GCP project, owned by the hospital"]
      R["Cloud Run services"]
      DB[("PostgreSQL")]
      OBJ[("Object storage")]
      KMS[["Hospital's KMS key ring"]]
      AUD[("Cloud Audit Logs<br/>hospital-owned, Pensieve Labs cannot alter")]
    end
    POL["Hospital organisation policy<br/>quotas, budget, VPC design"]
  end
  U["Hospital users"] -->|HTTPS| R
  R --> DB
  R --> OBJ
  KMS -.encrypts.-> DB
  KMS -.encrypts.-> OBJ
  R --> AUD
  OPS["Pensieve Labs engineer"] -.->|IAM roles granted by the hospital<br/>revocable by the hospital| P
  POL -.constrains.-> P

Text description. The cloud project sits inside the hospital's own cloud organisation and billing account. It contains the Platform's services, database, object storage and a KMS key ring the hospital owns. The hospital's organisation policy, quotas and budget constrain the project. Every Pensieve Labs action is written to Cloud Audit Logs the hospital owns and Pensieve Labs cannot alter. Pensieve Labs engineers reach the project only through IAM roles the hospital grants and can revoke unilaterally.

#Who controls what

#Data location

The region the hospital selects, inside its own project. This is the model to choose if a hospital's policy requires it to be able to point at a region it selected in an account it owns.

#Isolation model

Project-level isolation, as in DM-1, but the project is in the hospital's own cloud organisation, so the isolation boundary is also an ownership boundary. The hospital does not have to trust Pensieve Labs to maintain the boundary; the boundary is the hospital's cloud account.

#Availability, RTO and RPO

Committed, but conditional, and SLA-GL-001 states the conditions rather than burying them:

• The hospital's project must remain funded. A suspended billing account stops the Platform, and no availability commitment survives that.
• The hospital's quotas must be adequate. A quota Pensieve Labs cannot raise is a quota that can cause an outage Pensieve Labs cannot prevent.
• The hospital's organisation policy must permit the services the Platform requires. A policy change made by the hospital's cloud team can break a deployment Pensieve Labs did not touch.
• Patching can be delayed by the hospital's own maintenance windows (WPR-GL-001 Section 8.3).

None of these is a reason to avoid DM-3. They are the reasons the SLA reads differently, and a hospital choosing DM-3 should have someone who understands why.

#Security responsibilities

The largest shift of the four models. The hospital takes: cloud account security, organisation policy, network design, IAM administration for its own staff, key custody, and detection tooling if it operates any. Pensieve Labs retains: Platform security, patching, application-layer controls and its own personnel controls. WPR-GL-001 Section 18.1 is the matrix.

The key-custody consequence, stated so it is never a surprise: if the hospital disables or destroys the key, Pensieve Labs cannot decrypt, restore or recover the data. That is correct behaviour for a key the hospital controls, and the hospital should protect key operations with its own approval process.

#Cost shape

Split. The hospital pays Google directly for infrastructure (a variable bill it owns and can see in full) and pays Pensieve Labs a platform fee for the software and its operation. Total cost is usually higher than DM-1, not lower, because a single hospital's project does not benefit from Pensieve Labs's aggregate commitment pricing and because the hospital carries its own cloud administration overhead. Hospitals frequently assume DM-3 is cheaper. It generally is not; it buys control, not savings.

#Time to go-live

Slower than DM-1, by weeks rather than months. The additional critical-path items are:

DM-3 is normally assigned the TRK_STANDARD or TRK_COMPLEX track. Pensieve Labs will not promise a 14-day go-live for DM-3, because the items above sit inside the hospital's organisation and Pensieve Labs cannot compress somebody else's approval chain.

#Who it suits

Hospital groups with a real cloud team; institutions whose information-security policy requires ownership of the cloud account; hospitals with existing enterprise cloud commitments they wish to draw down; any buyer whose board position is "we must be able to revoke the vendor ourselves."

#When DM-3 is the wrong answer

• The hospital has no one who can administer a cloud account. DM-3 transfers real work; without a capable owner it produces outages nobody is accountable for.
• The hospital wants it because it assumes it is cheaper. It generally is not.
• The hospital needs to be live in two weeks.

---

#B.4 DM-4: On-Premise

#What it is

Pensieve deployed on hardware the hospital owns, in a room the hospital controls, on a network the hospital operates. Pensieve Labs supplies the software, the deployment, the upgrade path and support. Pensieve Labs operates none of the infrastructure.

#Architecture

flowchart TB
  subgraph SITE["Hospital premises"]
    subgraph SR["Server room, hospital-controlled"]
      H["Application servers<br/>containers"]
      D[("PostgreSQL")]
      S[("Storage")]
      K[["Hospital-held keys"]]
      L[("Local log store<br/>retention configured, hospital-enforced")]
      BK[("Backup target<br/>hospital custody")]
    end
    NET["Hospital LAN, firewall, UPS, cooling"]
    U["Hospital users"]
  end
  U --> NET --> H
  H --> D
  H --> S
  K -.encrypts.-> D
  H --> L
  D --> BK
  OPS["Pensieve Labs engineer"] -.->|only through a session<br/>the hospital opens| NET

Text description. Everything sits on the hospital's premises: application servers, database, storage, hospital-held encryption keys, a local log store and a backup target in the hospital's custody, all behind the hospital's own network, firewall, uninterruptible power and cooling. Users connect over the hospital's LAN. A Pensieve Labs engineer can reach the system only through a session the hospital explicitly opens.

#Who controls what

#Data location

The hospital's building. This is the strongest possible residency answer and it is one of only two legitimate reasons to choose DM-4.

#Isolation model

Physical. There is no shared infrastructure and no cloud tenancy. The isolation boundary is the hospital's own perimeter, which is also the limitation: an unlocked server-room door defeats every cryptographic control in the Platform. Pensieve Labs specifies minimum physical requirements in the On-Premise Supplement; it cannot enforce them.

#Availability, RTO and RPO

Pensieve Labs publishes no availability commitment for DM-4 and no RTO or RPO commitment.

This is not a negotiating position; it is arithmetic. Availability of a system depends on the power, the cooling, the network, the hardware and the person who notices at 03:00. Pensieve Labs controls none of those in DM-4. What SLA-GL-001 does commit to in DM-4 is Pensieve Labs's own response times: how quickly Pensieve Labs engages once the hospital raises an incident, which is a promise Pensieve Labs can actually keep.

A vendor offering you the same uptime percentage for your server room as for its own cloud is either not thinking about it or not telling you the truth. It is worth asking any competing on-premise proposal how its uptime figure survives a power failure in your building.

#Security responsibilities

The hospital takes the large majority: physical security, environmental control, network perimeter, operating-system patching, backup execution and custody, log retention, monitoring, detection and incident declaration. Pensieve Labs retains application security, the secure development lifecycle, patch supply and support. WPR-GL-001 Section 18.1 is the matrix and WPR-GL-001 Section 15.2 covers physical security.

Two consequences that are easy to underestimate:

• Detection. Pensieve Labs cannot detect an incident on a network it cannot see. A DM-4 hospital needs its own detection capability, or it will find out about an incident from its patients.
• Patching. Pensieve Labs ships patches; the hospital applies them or authorises a window. A hospital that defers patches carries the residual risk, and Pensieve Labs records the notification and the deferral. This is the single largest security difference between DM-4 and the other three models.

#Cost shape

The highest total cost of the four, by a wide margin, and the only one that is capital expenditure. The line items a hospital must budget:

Pensieve Labs's platform fee is additional to all of this. DM-4 also carries an implementation fee that DM-1 does not, because installation, environment validation and joint testing are genuine work.

#Time to go-live

DM-4 materially extends the timeline. Pensieve Labs says so at qualification, not at cutover.

[ESTIMATE: ranges reflect typical Indian mid-market procurement and delivery experience, not a Pensieve Labs measurement. The hospital's own procurement calendar dominates.]

DM-4 is assigned TRK_COMPLEX or TRK_INST. A 14-day go-live is not available in DM-4 under any circumstances, and any proposal that offers one, from Pensieve Labs or anyone else, is not describing a hardware delivery honestly.

#Who it suits

Hospitals with a written policy prohibiting public cloud; hospitals in locations where internet connectivity is genuinely unreliable enough that a cloud-hosted clinical system is unsafe; institutions under a regulatory or contractual obligation to hold data on their own premises; hospitals that already operate a competent data centre and want to use it.

#When DM-4 is the wrong answer

• It is being chosen for security reasons alone. A well-run cloud region has better physical security, better power redundancy and better patching discipline than almost any hospital server room. Choosing DM-4 for security usually reduces security.
• It is being chosen because it feels safer to have the box in the building. That instinct is understandable and it is expensive.
• The hospital has no one to look after the hardware.
• The hospital needs to go live soon.

---

#Part C: Comparison matrix

The tables below are split so they print on A4. Together they are the comparison matrix.

#C.1 Ownership and control

#C.2 Technical properties

#C.3 Commercial and schedule properties

#C.4 What is identical in all four

The same Pensieve build, the same feature set, the same contract stack (MSA-IN-001, DPA-GL-001, SLA-GL-001, Order Form), hospital as Data Fiduciary and Edsol Edtech Pvt. Ltd. as Data Processor, the same export and deletion commitments (WPR-GL-400, DIS-GL-023), the same integration boundary and BYOK/BYOC credential model (DIS-GL-024, DIS-GL-025), the same secure development lifecycle (DIS-GL-018), the same personnel controls (DIS-GL-020).

---

#Part D: Decision guide

#D.1 The decision tree

flowchart TD
  START["Which deployment model?"] --> Q1{"Is public cloud prohibited<br/>by written policy, or is<br/>connectivity genuinely unreliable?"}
  Q1 -->|Yes| DM4["DM-4 On-Premise<br/>Accept a months-long timeline<br/>and capital expenditure"]
  Q1 -->|No| Q2{"Does a written policy require<br/>the hospital to own the cloud<br/>account and hold the keys?"}
  Q2 -->|Yes| Q3{"Does the hospital have staff<br/>who can administer a cloud<br/>account and its IAM?"}
  Q3 -->|Yes| DM3["DM-3 Customer Cloud"]
  Q3 -->|No| WARN["Resolve this before choosing.<br/>DM-3 without a capable owner<br/>produces unowned outages.<br/>Consider DM-1 with contractual<br/>access controls instead."]
  Q2 -->|No| Q4{"Is dedicated infrastructure<br/>required by the board, an insurer<br/>or an accreditation body?"}
  Q4 -->|Yes| DM1["DM-1 Dedicated"]
  Q4 -->|No| Q5{"Is the site under ~50 beds,<br/>or a clinic or diagnostic centre?"}
  Q5 -->|Yes| DM2["DM-2 Shared"]
  Q5 -->|No| DM1

Text description. Start by asking whether public cloud is prohibited by written policy, or whether connectivity is genuinely unreliable. If yes, the answer is DM-4, accepting a months-long timeline and capital expenditure. If no, ask whether a written policy requires the hospital to own the cloud account and hold the keys. If yes, ask whether the hospital has staff who can administer a cloud account; if it does, choose DM-3, and if it does not, resolve that before choosing, because DM-3 without a capable owner produces outages nobody owns. If no policy requires account ownership, ask whether dedicated infrastructure is required by the board, an insurer or an accreditation body; if yes, choose DM-1. Otherwise, if the site is under about 50 beds or is a clinic or diagnostic centre, choose DM-2; if not, choose DM-1.

#D.2 The seven questions that settle it

Answer these in a single meeting and the model is decided.

#D.3 The three arguments Pensieve Labs hears most, answered

"On-premise is more secure." Usually the opposite. A hyperscale cloud region has independently audited physical access control, redundant power, fire suppression, hardware lifecycle management and patching discipline that almost no hospital server room matches. The genuine advantages of DM-4 are residency and control, not security. If the requirement is residency, say residency. It is a better argument and it survives scrutiny.

"Our own cloud account will be cheaper." Generally not. A single hospital's project does not benefit from aggregate commitment pricing, and the hospital adds its own cloud administration overhead. DM-3 buys control, and control is worth paying for if the policy requires it. It is not a discount.

"We will start on shared and move to dedicated later." Reasonable, and supported (see Part F). Do it deliberately with a planned migration window rather than discovering at an accreditation assessment that the model on the Order Form is not the one the board believes it bought.

---

#Part E: The recommendation, stated honestly

#E.1 DM-1 is the default

For a private hospital of roughly 50 to 200 beds, DM-1 is the right answer in the large majority of cases, for four reasons:

1. It is the fastest. It is the only model with nothing on the critical path that Pensieve Labs cannot control. That is what makes a 14-day go-live real rather than aspirational.
2. Its isolation story is short. "Your own cloud project, your own database, your own keys" closes a security review in one meeting. DM-2 needs four paragraphs; DM-3 needs a second contract.
3. It requires nothing from the hospital's IT function, which in a 120-bed hospital is often one person who is also responsible for the printers.
4. It is operationally the safest for the hospital, because the party with the most experience of running Pensieve is running it.

Pensieve Labs steers to DM-1 unless the hospital has a specific, articulated reason to choose otherwise. Where the hospital does have one, Pensieve Labs supports the model it chooses properly rather than treating it as an exception.

#E.2 DM-4 materially extends the timeline, and Pensieve Labs will say so before you sign

A DM-4 deployment does not go live in 14 days. It usually does not go live in 45. The hardware alone, specification, quotation, approval, delivery, commonly consumes six weeks before anyone touches the software, and the server room is often not ready when the hardware arrives.

Pensieve Labs's position:

• DM-4 is fully supported, not tolerated. The On-Premise Supplement, the hardware specification, the environmental requirements, the physical security expectations, the backup custody arrangements, the patching windows and the remote-access mechanism all exist as finished documents.
• Pensieve Labs will not quote a 14-day go-live for DM-4, will not commit an availability figure for hardware it does not control, and will not commit an RTO for media it never sees.
• Pensieve Labs will say all of this at qualification. A hospital that discovers it at cutover has been badly served, and that is a failure of the vendor, not of the model.

If a hospital's requirement is genuinely on-premise, DM-4 is correct and Pensieve Labs will deliver it. If the requirement is an assumption that has never been written down, it is worth ten minutes to check because that ten minutes can be worth two months.

#E.3 What Pensieve Labs will not do

• Sell DM-2 to a hospital whose board has been told it is getting dedicated infrastructure.
• Quote a DM-1 timeline for a DM-3 or DM-4 deployment.
• Publish an availability percentage for DM-4.
• Describe DM-2 isolation as equivalent to DM-1.
• Recommend DM-3 to a hospital with nobody to administer the account.

---

#Part F: Changing model later

Models are not permanent. The same Pensieve build runs in all four, so a migration is a data and infrastructure exercise rather than a re-implementation.

In every direction the same three rules apply: the migration is planned with a written cutover and rollback plan; the hospital's data is exported and verified before anything is decommissioned; and the source environment is not deleted until the hospital has signed acceptance of the target. The Order Form is amended to record the new DM-1, and the Security Addendum, SLA schedule and residency statement change with it.

---

#Related documents

---

#Change history

---