Design-build (DB) gives a healthcare owner single-point accountability and an earlier, more certain price — but it does so by shifting design authorship to the design-build entity and overlapping design with construction. In a hospital, where the design is shaped by clinicians, infection preventionists, biomedical engineering, and a dense stack of life-safety and licensing codes, that shift creates a specific set of risks. The DB contract must be engineered so the owner keeps the right kind of control (over what the building must do clinically and operationally) without reclaiming the design liability that makes DB worth using. This article covers what changes when DB is applied to a healthcare facility and the mechanisms that make it work.

Healthcare design is owner-knowledge-intensive, which strains the DB premise

The core DB premise is that the owner can define the project up front through performance criteria, then step back and let the DB entity author the design. That premise is easiest to satisfy when the building's requirements live in codes, standards, and a clear program — a warehouse, a parking structure, a fit-out to a known template.

Healthcare strains the premise because a large share of the requirements live in the owner's clinical and operational knowledge, not in published standards:

• Clinical adjacencies and workflow — how a patient moves from triage to imaging to OR to recovery; whether the cath lab needs to be hybrid; how nursing sightlines are configured; where clean and soiled flows separate. These are operator decisions, not code outputs.
• Equipment and modality intent — the specific imaging, surgical, sterilization, lab, and pharmacy equipment a department will run, including future modalities the owner wants to accommodate. Equipment dictates structure, shielding, power, cooling, gas, and clearances.
• Standard-of-care and brand commitments — service-line ambitions, patient-experience standards, and system design guidelines that exceed code minimums.
• Operational constraints — phasing around an occupied, licensed, operating facility (interim life-safety measures, infection-control risk assessment), and the realities of running the department during construction.

Published frameworks set the floor, not the design: the FGI Guidelines for Design and Construction (with ASHRAE 170 for ventilation incorporated by reference), NFPA 99 (health care facilities), NFPA 101 (Life Safety Code), NEC Article 517 (health care wiring/essential electrical systems), the applicable IBC, ADA/ABA accessibility, and the CMS Conditions of Participation enforced through TJC or DNV accreditation. DB can satisfy all of these and still produce a building the clinicians cannot work in if the owner's tacit knowledge never reaches the design table. The central healthcare-DB problem is therefore not code compliance — it is capturing operator intent before the DB entity commits the design, and validating it as the design develops.

The owner's program criteria must encode clinical and operational intent, not just rooms

In DB the owner's design criteria (often a bridging document or a performance program) are the contract's center of gravity — they define what the DB entity is obligated to deliver. For healthcare these criteria have to carry more than a space program and a code list. A healthcare DB criteria package should typically include:

• A clinically-vetted functional program and room-by-room space program, reviewed by the actual user groups, expressed in net/departmental gross areas with adjacency diagrams.
• Room data sheets / equipment templates for clinical rooms, specifying utilities, finishes, infection-control attributes, and clearances at a level the DB designer can carry into design without guessing.
• An equipment responsibility matrix (owner-furnished vs. contractor-furnished; owner-installed vs. contractor-installed) for the major medical equipment, because equipment intent drives the building.
• Performance criteria tied to named standards — FGI/ASHRAE 170 ventilation parameters by room type, NFPA 99 risk categories and the resulting gas/electrical provisions, essential electrical system scope per NEC 517 and NFPA 110, USP 797/800 compounding-pharmacy requirements where applicable.
• Owner design standards (system guidelines, preferred manufacturers, IT/low-voltage, security) that the DB team must honor.
• The licensing and accreditation path and AHJs — state department of health licensing, CMS/TJC or DNV, plus state plan-review where it applies (e.g., California's HCAI, the former OSHPD, with its own structural and design-review regime). Naming the AHJs in the criteria forces them into the DB schedule.

The discipline here is that anything not encoded as a criterion becomes a design decision the DB entity is free to make — and may make to optimize cost or schedule. Encoding intent is how the owner keeps control without holding design liability.

User-group control is a structured, scheduled input — not open-ended redesign

Clinician and staff input ("user groups") is how a healthcare design earns operational fit. In design-bid-build, user-group meetings run through the owner's own architect during a long design phase. In DB, the architect works for the DB entity, and design is compressed and overlapped with construction — so user-group involvement has to be structured, time-boxed, and contractually bounded, or it becomes the leading source of DB change orders and schedule slip.