Jurisdiction
Which jurisdiction's law reaches this data, and does any processing move it across a border?
INSIGHTUse case · Healthcare
Healthcare AI infrastructure, sited on your own property
Health systems put AI compute on their own property for two reasons: the data is governed where it sits, and imaging archives are too large and too sensitive to move casually. The obstacle is rarely the decision — it is that a hospital estate has no room, power, or cooling for a dense GPU cluster. This page covers the workloads, the siting constraints, what infrastructure can and cannot carry for compliance, and where a modular unit is the wrong answer.
PUBLISHED LAST VERIFIED BY JOSEF ELIMELECHREVIEWED PODOS AI ENGINEERING
- 06
- Siting constraints
- 08
- Governance questions
- 0
- Certifications claimed
What actually pulls compute onto a hospital campus
01
Data is governed where it sits
The Security Rule obligation follows electronic protected health information wherever it is held. It does not transfer to a supplier.
02
The archive decides the location
Retrospective imaging archives are large and awkward to move. The archive, not the model, dictates where compute goes.
03
The estate has no room for it
Floor area is allocated to care delivery, the electrical system is classified around life safety, and construction inside an operating facility is slow by design.
04
Compliance stays with the institution
Infrastructure can support a compliance architecture the institution owns. It cannot deliver compliance on the institution's behalf.
H-00 · Governance first
Data residency is a governance question before it is a technical one
"Where does the data live" is the first question a health system's privacy office asks about an AI programme, and the answer decides the architecture. In the United States, the HIPAA Security Rule — 45 CFR Part 160 and Subparts A and C of Part 164 — obliges regulated entities to apply administrative, physical, and technical safeguards to electronic protected health information wherever it is held.[1] That obligation follows the data; it does not transfer to a supplier. Where a cloud provider handles that information, HHS guidance is explicit that the provider becomes a business associate and a written agreement is required — including for encrypted, so-called no-view services.[2]
Cross-border research adds a second layer. Under Chapter V of the GDPR, personal data may leave the European Union only under an adequacy decision, appropriate safeguards, or a specific derogation — which is why multi-site studies stall on transfer mechanics rather than science.[9] On-premises processing does not answer the transfer question so much as remove it. The tradeoff is real, and we set it out in full in on-prem AI infrastructure vs cloud.
Workload profile
The workloads that actually pull compute onto the campus
Medical imaging is the anchor. Studies are exchanged and archived under DICOM, the standard maintained by the Medical Imaging & Technology Alliance, a division of NEMA,[6] and a research-grade retrospective archive is measured in years of studies rather than gigabytes of text. Imaging is also where AI has the most production traffic: the FDA publishes a list of AI-enabled medical devices authorised for marketing in the United States, and radiology is by far the most common lead review panel on that list.[7] Large resident data plus live inference against it is what makes the archive, not the model, decide where compute goes.
Three quieter workloads sit around it with the same gravity: ambient clinical documentation, where latency is felt by clinicians in the room; genomics pipelines, which are batch but enormous; and internal model development on retrospective records, which governance committees scrutinise hardest. Academic medical centres carry a second profile on top of this one — shared clusters, grant cycles, mixed research tenancy — treated separately in universities and research computing.
The two halves place opposite demands on infrastructure. Training is bursty and tolerant of interruption; clinical inference is modest in compute but runs against a live service expectation, where an outage is felt in a reading room rather than in a job queue. One site usually carries both, so availability is set by the inference path while capacity is set by the training path.
Site survey
Why a hospital building is the wrong place for a GPU cluster
A hospital estate is unusually constrained: floor area is allocated to care delivery, the electrical system is classified around life safety, and construction inside an operating facility is slow by design.
| # | Constraint | Why an in-building cluster struggles | What a separately sited unit changes |
|---|---|---|---|
| H-01 | Clinical floor area | A GPU room competes directly with imaging suites, procedure rooms, and beds. | Moves the compute off the clinical floorplate and onto a utility pad the institution already owns. |
| H-02 | Electrical capacity | Adding hundreds of kilowatts behind distribution classified around life safety is an engineering project, not a rack install. | Own service, so the hospital's existing distribution and its essential-power classification stay untouched. |
| H-03 | Rack density | Operator-reported rack densities were climbing into the 10–30 kW band in Uptime Institute's 2025 survey, past what hospital IT rooms were built to serve.[8] | Density is designed into the enclosure rather than retrofitted into a room never sized for it. |
| H-04 | Cooling and heat rejection | Air cannot economically remove heat at AI-rack densities, and cutting liquid pipework into an occupied clinical building is slow. | The closed liquid loop and its heat rejection ship as part of the unit — no clinical space is opened up. |
| H-05 | Physical access control | The NIST physical and environmental control family sets what an auditor expects to see: access authorisations, monitoring, and visitor records.[5] | A discrete, lockable, separately monitored envelope: a small perimeter to authorise, log, and inspect. |
| H-06 | Data gravity | Retrospective imaging archives are large and awkward to move; the archive, not the model, dictates location.[6] | Compute on the same campus as the archive removes the transfer problem instead of engineering around it. |
H-05 · Control posture
What infrastructure can and cannot do for compliance
This is the part vendors overclaim, so we will be blunt. PODOS holds no healthcare certification and makes no compliance claim. Compliance is a property of a regulated entity and its whole programme — risk analysis, policies, training, agreements, safeguards — not a property of a box. HHS itself states that covered entities are not required to certify compliance and that it does not endorse or otherwise recognise private organisations' certifications.[3]
What infrastructure can do is support a compliance architecture the institution owns. A discrete, access-controlled envelope on institution-controlled land gives a privacy office a defined perimeter to authorise and audit — the shape the physical safeguards standard and the NIST physical and environmental controls describe.[1][5]NIST's HIPAA Security Rule resource guide is the practical reference for mapping those standards onto evidenceable controls.[4] That mapping stays with the operator.
Compliance is a property of a regulated entity and its whole programme — risk analysis, policies, training, agreements, safeguards — not a property of a box.
Before the infrastructure conversation
Eight questions a governance review will ask first
Bring answers to these before the infrastructure conversation. They decide more programmes than hardware selection does.
Agreements
Who is the covered entity, who is the business associate, and is every agreement executed?
Risk analysis
Where does the risk analysis put this workload, and has it been re-run for the new location?
Physical access
Who holds physical access authorisation, and how is entry logged and reviewed?
Network separation
How is administrative access to the cluster separated from the clinical network?
Training data
What is the de-identification or minimum-necessary boundary for training data, and who signs it off?
Clinical dependency
Does any clinical process depend on this workload during a planned outage?
Operations ownership
Which team owns monitoring, patching, and incident response for the infrastructure itself?
HONEST LIMITS
When this is not the right fit
A whole unit is a coarse increment of capacity. These are the cases where a health system should not be talking to us.
- The workload is one or two inference models at low volume. A few GPUs in the data room the institution already operates is right-sized; buying a whole unit to run a rack-scale problem is waste dressed up as strategy.
- There is no site. A dense urban campus with no exterior pad and no adjacent institution-controlled land cannot host a unit — modularity does not invent land.
- There is no operations owner. A unit needs monitoring, maintenance, coolant chemistry, and an incident path. Where facilities engineering cannot take that on, a cloud region under a business associate agreement is more honest.
- Demand is spiky. Irregular research bursts are what elastic capacity is for; owned infrastructure is economic only against a sustained load.
- Approval, not compute, is the bottleneck. If review and privacy assessment outlast any build, buying capacity first solves nothing.
- A compliance certificate is what is actually wanted. No infrastructure supplier can provide one, ours included, and any vendor offering it is describing something HHS does not recognise.
In the product
How a PODOS unit fits a health system estate
The PODOS Pod is designed as a standardized 1 MW building block and designed for 128 GPUs, with power, closed-loop liquid cooling, racks, and monitoring integrated into one enclosure rather than built into a room. For a hospital that matters less as a specification than as a siting property: the unit lands on a prepared pad outside clinical space, so the archive stays on campus while the construction stays off the clinical floorplate. PODOS targets a 90-day window from order to commissioning for a standard unit — useful mainly because institutional review runs on its own clock and the two can proceed in parallel.
How a unit arrives and is commissioned is in the deployment model; adjacent verticals and their limits are on the use-case hub; terms are defined in the AI infrastructure glossary.
QUESTIONS
Frequently asked questions
Is a PODOS Pod HIPAA compliant?
No product is. HIPAA compliance is a property of a regulated entity and its whole programme, not of hardware. PODOS holds no healthcare certification and claims none. Infrastructure can support a compliance architecture the institution owns; it cannot deliver compliance on the institution's behalf.
Does HHS certify vendors as HIPAA compliant?
It does not. HHS states that covered entities are not required to certify compliance, and that it does not endorse or otherwise recognise private organisations' certifications — such a certificate does not relieve a regulated entity of its own obligations.
Why not just use a cloud region with a business associate agreement?
That is a legitimate architecture, and for many workloads the right one. HHS guidance sets out how a cloud provider handling electronic protected health information becomes a business associate. On-premises compute wins when governance, egress economics on large imaging archives, or a transfer restriction make institution-controlled infrastructure simpler.
Can a compute unit go inside the hospital building?
Usually not, and usually it should not. Dense GPU racks compete with clinical floor area, add hundreds of kilowatts behind distribution sized for care delivery, and need liquid cooling that occupied clinical buildings host poorly. A separately sited unit on institution-controlled property is the more common answer.
Sources
- [1] The Security Rule (45 CFR Part 160 and Subparts A and C of Part 164) — U.S. Department of Health and Human Services, accessed 2026-08-31
- [2] Guidance on HIPAA & Cloud Computing — U.S. Department of Health and Human Services, Office for Civil Rights, accessed 2026-08-31
- [3] FAQ 2003 — Are we required to certify our organization's compliance with the standards? — U.S. Department of Health and Human Services, accessed 2026-08-31
- [4] SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide — NIST, Feb 2024
- [5] SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (PE control family) — NIST, Sep 2020, upd. Dec 2020
- [6] DICOM Standard — current edition — Medical Imaging & Technology Alliance, a division of NEMA, accessed 2026-08-31
- [7] Artificial Intelligence-Enabled Medical Devices (authorised device list) — U.S. Food and Drug Administration, accessed 2026-08-31
- [8] Global Data Center Survey 2025 — Uptime Institute, Jul 2025
- [9] Regulation (EU) 2016/679 (GDPR), Chapter V — Transfers of personal data to third countries — European Union (EUR-Lex), 2016
Size it against your campus
Bring the archive, the governance answers, and the pad. The configurator walks the same variables an engineering review would.