A clinical practice was building a patient application: measurements, images, an eventual integration with clinical records, and later a connected measuring device. The brief was written as a list of screens. The decision that sets the monthly running cost, the legal exposure, and whether the device and the records integration can ever be added without starting again does not appear on any of them.
Every piece of data has one official copy, and wherever it lives inherits the obligations.
A system of record is the system whose copy of a piece of data is authoritative. Other systems may hold copies, caches or summaries, but when they disagree, the system of record wins, and any correction is made there first. The idea applies per datum, not per product. A single application might keep its patients' identity in one system, their measurements in another and their images in a third, and each of those can have a different system of record.
The choice matters because obligations follow data. Whoever holds regulated health data has to meet rules about access, logging, retention and breach handling, and has to have the right contractual agreements in place with every provider that stores or processes it. A hosting platform that is willing to sign those agreements and operate under those rules usually charges for the privilege, often through a separate tier or contract. So deciding where each official copy lives is also deciding which systems must operate under the regulated posture, and what that will cost each month. Data that never needed the posture but lives beside data that does ends up paying for it anyway.
The choice is hard to reverse because data accumulates and other things attach to it. Identifiers issued by the system of record spread into other systems, integrations are built against its interface, and its history becomes part of the clinical record. Moving the official copy later is a migration of a regulated dataset while the service is live. External constraints can also fix the choice before anyone notices it was made: what a mobile browser is permitted to reach, where a jurisdiction requires data to be stored, and what a platform's terms allow. Each of those is a fact at a date, and has to be re-verified before a design depends on it.
The first architecture call is which system holds the official copy of each piece of data, and it is the one call that cannot be revisited cheaply. It sets the compliance posture, because a platform that holds regulated data takes on obligations that a platform without it does not. It sets the cost, because platforms price that posture very differently. And it constrains the roadmap. On one major mobile platform, no browser exposes the interface a connected device needs, so a device on the roadmap decides the application's form factor before any screen is drawn.
Storage decided by default becomes a compliance posture decided by accident.
Products designed screen first tend to make the data decision implicitly, by keeping whatever the first prototype used. The prototype's backend becomes the place everything lives, including data that carries regulatory obligations, and the platform then has to be upgraded or replaced to meet them. That usually happens after launch, when moving is most expensive and most disruptive to patients.
A second pattern is the constraint that arrives from outside the product. A device on the roadmap, a records integration, a requirement about where data is stored: each one limits what the architecture can be. Treated as later features, they get designed around an architecture chosen without them, and sometimes that architecture turns out to exclude them entirely.
The reflex, and the fix.
Design the screens and decide storage later
Screens are what the practice can see and react to, and the data layer feels like an implementation detail to settle once the product has taken shape.
Storage determines the compliance agreement, the monthly cost and whether the device can ever be reached. Left until later, it is never actually decided. It is discovered, as a rebuild.
Decide the system of record for each datum first
An architecture phase before any interface work, and a form factor imposed by a platform constraint whatever anyone's preference.
A cost and compliance position that was chosen deliberately, and a roadmap on which the device and the records integration are additions.
The irreversible decision comes first, because every reversible one depends on it.
A separate decision for each kind of data
Measurements, images, identity and clinical notes do not have to live in the same place. Deciding them as a single block is how an expensive posture ends up applied to data that never needed it.
The compliance posture follows the data
What the platform holds determines what it has to be. On otherwise comparable stacks, the cost difference between postures is large enough to change the business case, so it is weighed datum by datum.
The device decides the form factor
On one major mobile platform no browser exposes the interface a connected device needs. If the device is on the roadmap the application cannot be browser-only. That is a constraint the platform imposes, and the plan treats it as one.
Jurisdiction before storage region
Requirements on where data is stored come with attestations that somebody signs periodically. Choosing a region is therefore a legal commitment, and it is made once the jurisdiction's requirements are known.
Estimates carry the direction of their error
When a value is estimated from an image instead of measured, the error tends to be systematic, leaning consistently one way. Wherever the estimate is displayed clinically, the direction and magnitude of that error are displayed with it.
What each choice cost, and what it bought.
ADoing architecture before interfaces
A practice commissioning an app expects to see screens early, and an architecture phase delays them. That is a real cost in confidence and in momentum. It buys a plan in which every screen sits on data whose home, posture and cost were chosen on purpose. The alternative produces faster early progress and a later conversation about why the platform has to change, held after patients are already using it.
BAllocating each datum separately
Putting everything in one system is simpler to build and simpler to reason about. Allocating per datum means more than one system and an integration between them, which adds work and some operational surface. In return, the regulated posture and its cost attach only to the data that requires them, and data with lighter obligations can live somewhere cheaper. On comparable stacks the difference in cost is large enough to change the business case.
CLetting the device set the form factor
A browser application is quicker to ship and easier to update. Because the connected device needs an interface that one major mobile platform's browsers do not expose, choosing the browser would have quietly removed the device from the roadmap. Accepting an application that is not browser-only from the start costs build effort and, on most routes to a phone, a store review process. It keeps the device as a future addition, not a future rewrite.
DLabelling estimates with their error direction
Showing an estimated value beside measured ones is visually clean and invites clinicians to treat them alike. A systematic error does not average away with more readings, so an estimate that consistently leans one way will mislead in a consistent way. Displaying the direction and magnitude of the error costs interface space and characterisation work. It means a clinician reading the value knows which way to discount it.
A single headline number hides where a system fails. This work was scored on the dimensions that actually decide whether it holds in production, measured on real, held-out cases rather than the demo path.
Third-party pricing, platform and regulatory facts are cited with their source and the date they were established. No client outcomes are published.
A finished set of screens, a storage decision made by whatever the prototype happened to use, a compliance posture discovered after launch, and a connected device that the chosen form factor can never reach.
A system of record chosen for each datum, a compliance posture and running cost that follow from it by design, a form factor set by the device constraint, and estimated values labelled with the direction of their error.
What it owns, and what it hands to a person.
Platform pricing, browser capability and jurisdictional requirements all change, and each was established at a particular point in time with its source recorded. An architecture built on them needs every one restated and re-verified at build time. Inheriting them from a planning document is how a sound plan quietly becomes a wrong one. Clinical decisions made from the data, and regulatory approval of the practice itself, sit outside this work.
Any product with regulated data and a device on the roadmap faces this order of decisions. Settle what holds the official copy of each item first. The compliance posture, the running cost and the achievable roadmap are all consequences of that call, and none of them can be fixed cheaply once it has been made by accident.
A system of record is the copy that wins when copies disagree. Decide it for each kind of data separately, because each decision carries its own obligations and cost.
A connected device on the roadmap is an architecture constraint today. Check what the target platforms let a browser reach before choosing a form factor.
A requirement about where data is stored can carry periodic signed attestations, which turns a region choice into a legal commitment.
An estimate with a systematic error should be shown with the direction of that error, because collecting more readings does not cancel it.
Pricing, platform capability and regulation are facts at a date. Re-verify each of them at build time before trusting a plan that relies on them.