The advice problem
Search for how to build healthcare software and you will find the same sentence in every result: embed compliance from the first sprint. It is true. It is also unfalsifiable and unusable. Nobody tells you which decisions they mean, so teams read it, agree with it, feel prepared, and then discover eighteen months later that "compliance-ready" meant six specific things and they got four of them wrong. This article names the six. They come from building an ENT patient pathway platform for a UK healthtech startup - referral through triage, questionnaire, appointment, audiology results, clinical review and outcome - designed for NHS adoption from the first architecture conversation.
Decision 1: Data residency, before anything else
What we decided: UK-region Azure, fixed at the start, before the first line of application code. Why it goes first: residency is not a hosting preference. It propagates into every subsequent choice - which managed services are available in region, where backups live, which monitoring tools you can use, which support model your cloud provider offers, and whether your own engineers in another country can access production. Why reversing it is expensive: migrating a running system with patient data between regions is not a deployment, it is a project. Every downstream service that quietly defaulted to a different region has to be found. What it costs on day one: an hour of discussion and occasionally a slightly smaller menu of managed services.
Decision 2: Authentication model
What we decided: passwordless access via magic link over email or SMS, for patients. Why: patient-facing healthcare products have a specific problem. Your users are not employees, they log in rarely, and password reset flows are both a support burden and an attack surface. Removing stored passwords removes an entire class of risk — credential stuffing, weak password policy arguments, reset-flow abuse, and the storage question itself. The honest trade-off, which most write-ups of passwordless skip: you do not eliminate risk, you move it. The link becomes the credential. That makes link lifetime, single use, delivery channel security and what happens on a shared device into design decisions, not implementation details. An expired-link experience that frustrates patients is a real cost of this model. Why reversing it is expensive: authentication touches the identity model, the session model, and every access path. It is not a swappable module in practice, whatever the architecture diagram says.
Decision 3: Role model designed for three constituencies
What we decided: role-based access control covering patients, clinicians and administrators, modelled at the start rather than grown. Why it goes early: healthcare products have structurally different user classes with genuinely different data visibility. A patient sees their own case. A clinician sees assigned cases. An administrator sees configuration but should not necessarily see clinical content. If you start with one role and add others, you end up with permission checks scattered through the codebase and no single place that answers "who can see this." What "designed" means concretely: one authorisation layer that every data access path passes through, and the ability to answer the question "what can this role see" by reading one place rather than auditing the codebase. Why this matters beyond security: every assessment asks you to describe access control. If your answer requires reading the code, you do not have a describable control.
Decision 4: Audit trail in the domain model, not in the logs
This is the one teams most often get wrong, and the distinction is worth stating precisely. Logging is an operational concern. It captures what the system did, it is for engineers, it rotates, and it is not a source of truth. An audit trail is a product feature. It captures what happened to a case - who reviewed it, what outcome was recorded, when status changed - it is for clinicians and assessors, and it must be durable and complete. What we decided: case status tracking and an auditable flow from onboarding to outcome, built into the domain model as a first-class concept. Why retrofitting fails: if you decide later that you need an audit trail, you can only reconstruct it from logs, and logs were never designed to be complete or durable. You end up with a partial history, or you start collecting properly from today and have nothing before that date.
Decision 5: Key management, decided when the first key is created
What we decided: encryption in transit and at rest, with key handling as an explicit decision rather than a platform default. The distinction that matters: almost every cloud platform gives you encryption at rest by ticking a box. That satisfies the sentence "data is encrypted." It does not answer who can access keys, how they rotate, and who approved that access which is the actual question in any outcome-based assessment. The cost difference: deciding this when you create the first key is a short conversation. Reconstructing a key management story for a running system, retroactively, is one of the most expensive items in retrofit work.
Decision 6: Configuration outside the code
What we decided: a dynamic form builder letting non-technical users create and modify clinical questionnaires without developer involvement, and a pathway engine configurable enough to support multiple clinical routes. Why this is a compliance decision, not a convenience feature: in a regulated environment, every deployment is a change with consequences. If altering a questionnaire requires a release, then clinical content changes are engineering changes - they queue behind the roadmap and each one carries deployment risk. Moving configuration out of code separates "the clinical team changed a question" from "we shipped software," which are two very different events from a governance standpoint. What it cost: more work upfront than hardcoding the first questionnaire. What it bought: a platform that extends to new clinical pathways without a rebuild which is the reason the same system can move from audiology into other routes.
The part that surprises people
All six decisions were made inside a two-month MVP build with one developer and one QA engineer. That is the point of the article, and it is worth stating plainly because the prevailing assumption runs the other way. Teams believe compliance-aware architecture is the thing that makes healthcare projects slow, so they defer it in order to move fast, and the deferral is what eventually costs them quarters. None of these six decisions cost meaningful time at the start. Every one of them is expensive to reverse. That asymmetry is the entire argument.
What this means in practice
If you are starting a healthcare product now, spend the first week on six decisions rather than on the first feature: region, authentication model, role model, audit trail placement, key management, configuration boundary. None of them require knowing which assessment you will eventually face. All of them are harder the day after you have users.
