#Minimum Viable Go-Live Configuration

DIS-GL-036 v1.0.0, Last Modified On 01 August 2026, Tier: Public

#Applicability

Sections 2 to 5 describe what a hospital needs on its own floor in every deployment model. Sections 6 and 7 add what the hospital additionally owns in DM-3 and DM-4.

#Purpose

This is published so that the hospital's own procurement never sets the go-live date.

The single most common cause of a slipped hospital go-live is not software. It is that somebody counted the workstations in week three, discovered a shortfall, and started a procurement cycle that takes between five days and three weeks. That delay is entirely avoidable by publishing the number before the proposal is accepted, so that procurement runs in parallel with everything else rather than after it.

Issue this document with the proposal, alongside the Infrastructure Readiness Checklist (CHK-GL-036), not after signature.

Figures below are the minimum for a wave-1 go-live at a 150 to 200 bed multi-specialty hospital, and are re-derived per deal against the hospital's own counter count in FRM-GL-004 and FRM-GL-116.

#1. How to read the numbers

There is no third column called "we will manage". The minimum is a floor, not a target.

#2. Endpoints and peripherals

Workstation specification. Any machine that runs a current mainstream browser at 1366×768 or better is sufficient. Pensieve is browser-delivered and imposes no client installation, no fixed operating system and no licence per seat.

#3. Network

#4. Power

Power is the item most often assumed and least often measured. A rating plate is not evidence; a stopwatch is.

#5. What happens when the numbers are not met

Nothing here is a refusal. It is a sequencing rule.

1. The gap is quantified per location, never in total. "Nine short" hides that billing is fine and the laboratory cannot open.
2. Every gap row carries a cost, a lead time and a closure date.
3. Where a gap cannot close before the readiness review, the affected department is removed from wave 1 in writing, signed by the hospital's owner, and goes live in wave 2.
4. Where procurement lead time is the constraint, a rental option is offered so that the hospital's own purchase cycle does not sit on the critical path.
5. A gap whose closure date is "as soon as possible" is treated as unclosed.

Pensieve Labs will not certify go-live readiness for a department that is below the wave-1 minimum. Certifying it produces a queue on go-live morning, and the hospital remembers the queue, not the explanation.

#6. DM-3: hospital's own cloud project

#7. DM-4: on-premise

#8. What this document does not cover

1. It is not a sizing exercise for the hospital's own network refresh. It is the floor for a wave-1 go-live.
2. It does not specify makes or models, and Pensieve Labs does not resell hardware. Where a rental partner is engaged, the hospital contracts with the partner directly.
3. It is not a security standard for the hospital's estate. The hospital's own endpoint, anti-malware and patching posture is its own; Pensieve Labs's platform-side position is WPR-GL-001.
4. It says nothing about performance guarantees. Those are DIS-GL-030 and SLA-GL-001, and they depend on the deployment model.
5. Figures are re-derived per deal. A 40-bed hospital and a 400-bed hospital do not share a floor.

#9. Related documents

#10. Change history