21 Case Study: A Composable Review Platform

The first case is the experience-and-operations spine of the reference architecture, as actually operated: a clinical data-review platform for a small, fully outsourced biotech, reported in the PHUSE paper Beyond a Single Shiny Server (anonymized vendor detail aside, the system is the one this book’s author runs in production). Its lessons are about what a team of two can hold — and where the honest boundary of self-build lies.

21.1 The situation

Review applications had outgrown a vendor-hosted single Shiny server: the workload included Python microservices the R-only server could not host at all, wanted per-application resource control, and needed a deployment discipline of its own. The fork: buy a commercial hosting product, or compose a platform from open-source parts and own the consequences. The team built — and the paper is explicit that this is a decision, not a virtue — the second.

21.2 What was built

One Docker Compose stack on one virtual machine, twenty-one services in production: fourteen Shiny review applications (eight cross-study, six study-specific), one R API, five Python services (including a safety monitor and a document question-answering service), and one reverse proxy. The architecture fits the reference model’s layers 2–5 almost exactly, and each load-bearing choice is a rule worth stealing:

One door. The proxy is the only externally reachable service, TLS-terminating at the edge; everything else binds to localhost. Exposure is a decision recorded in one reviewed file, never an accident of a container default.
Authentication written once. The CRO partner’s SSO issues signed JWTs; one shared module verifies tokens locally in every application, with layered dataset-level permissions. New apps inherit security by inclusion, not by reimplementation.
Data through one API. No app mounts a shared drive or opens its own database connection; authorization lives server-side in exactly one place. Applications stay stateless; the storage story stays movable.
Pipeline-only deployment. Nothing changes by hand: automated backup, protected environment configuration, rebuild, and a thirteen-point health check that must fully pass or the deployment is declared failed; rollback is one command. Ten one-page decision records (ADRs) document why the system is shaped as it is.
The trampoline. Migration preserved the users’ one-login experience via a 38-line forwarding app on the legacy platform — the entire migration surface auditable in a sitting.

21.3 The honest boundary

The paper’s most valuable contribution is its scope statement: this platform is internal exploratory-review infrastructure, not a validated system, and validated commercial platforms remain the answer for GxP-facing delivery. Its decision rules follow from that honesty. Compose when the workload is multi-language, the use is internal exploration, and someone will own the pipeline. Buy the validated platform when the deliverable is GxP-facing or nobody will own the process. And two clarifications keep the rules real: health checks are not validation, and the layers are complements, not competitors.

21.4 What this case adds to the book

Two things. First, proof that layers 2–5 of the reference architecture run in production at small-team scale, with discipline substituting for headcount. Second, the boundary itself: the platform stops where the evidence layer is missing — exactly the empty cell of Chapter 7. The next case is what happens when the same instincts are pointed at that cell directly.

The test. For any self-built platform, ask: “Which decision did you last refuse to make without a one-page record — and which capability do you explicitly not claim?” Teams that can answer both are composing. Teams that can’t are improvising with a diagram.