Healthcare
Duke Health
One platform serving an academic health system's public web presence, still in production years after launch.
- Role
- Lead engineer · Multi-year engagement
- Duration
- Multi-year
- Stack
- DrupalPHPPostgreSQLAWS
Multi-year
Engagement length
WCAG AA
Accessibility baseline
On estimate
Delivered
Background
Duke Health is the clinical and academic health enterprise of Duke University: hospitals, hundreds of clinics, a school of medicine, and a research operation, all publishing to the public through one digital front door. For most patients, the website is the first encounter with the health system: finding a doctor, understanding a condition, preparing for a visit.
An organization like that doesn't have one web audience; it has a dozen. Patient education competes with clinical service-line marketing, research communications, news, and public relations, each with its own owners, cadence, and standards, and all of it under the accessibility and privacy expectations that come with healthcare.
Challenge
Duke Health needed a unified, multi-site web platform capable of serving the operational needs of an academic medical center without the cost and brittleness of a separate stack per audience. Every previous-generation approach had the same failure mode: either one monolithic site that every department fought over, or a sprawl of independent sites that drifted apart in brand, quality, and compliance.
The platform had to let content editors across many departments work independently while holding brand and accessibility standards constant, and it had to meet the performance and reliability expectations of a top-tier health system, where the website is treated as patient-facing infrastructure, not marketing collateral.
Approach
Nikkio was engaged from initial planning through final delivery as lead engineer. The core architectural decision was a multi-site Drupal platform with shared components: distinct sites sharing infrastructure, design system, taxonomies, and editorial workflows, without becoming entangled. A department could launch a new property on the shared foundation instead of procuring a new stack: the difference between a platform and a pile of websites.
Accessibility was carried as a design input, not a launch-week audit. The platform was engineered to a WCAG AA baseline: templates, components, and editorial constraints that make the accessible outcome the default rather than a per-page effort.
The deployment and performance layer was built for the operational reality of a health system: predictable releases, caching architecture sized for public traffic, and documentation written so the platform could be operated by people who didn't build it. That last part was deliberate: a system serving an institution has to outlive any vendor relationship, including ours.
Results
The platform launched on the published estimate and has served Duke Health through years of editorial growth and feature expansion. Departments publish independently; the brand and accessibility baseline holds without central bottlenecks.
The engagement continued long past launch, through iterative enhancement, new sections, and evolving editorial needs, which is the outcome we design for. Continued post-launch engagement is what it looks like when architectural decisions stay aligned with an organization's needs instead of expiring with the project plan.
Get in touch
Have a project worth getting right?
Tell us what you're building and we'll respond within two business days. Most engagements start with a 30-minute conversation.