An echo, a DEXA, a coronary calcium score, kept as data instead of a PDF

A study is three different things, kept separate

Every scan you log is keyed to a procedure from a curated catalogue, and it carries three kinds of information that never get merged into one blob. Readings are what the scan measured (LVEF, carotid IMT, liver fat fraction), numeric, classified against a sex-specific reference band by the same engine bloodwork uses, and trended across every study you've logged. Findings are what the scan found: the radiologist's read, coded where a code exists and free text where it doesn't, because "partial supraspinatus tear, articular surface" has no numeric analogue and forcing one would lose it. Assets and DICOM instances are the files themselves: report PDFs, exported stills, and de-identified DICOM series you can page through in the app.

Splitting the three matters because they behave differently. A number can be graphed. A radiologist's conclusion can't be, and shouldn't be treated as if it could. Keeping them apart means the trend chart never quietly absorbs a clinical judgment call as if it were a measurement.

Nothing renders until a person confirms it

A reading MuscleBuddy extracts from an uploaded report with AI arrives unconfirmed, and an unconfirmed reading is inert: it doesn't trend, doesn't flag, doesn't feed a rank, and doesn't count as verification evidence for anything. It sits there until you accept it. Findings never go through that path at all: a finding is never machine-authored, full stop, because a finding is a clinical conclusion, and a machine generating one would be MuscleBuddy issuing a diagnosis. Every finding on your record was typed in by a person reading a report.

DICOM is de-identified before it is stored, not after

Upload the DICOM files a facility hands you on a CD or through a portal, and they're de-identified to the PS3.15 Basic Confidentiality Profile before anything is written to storage (an allow-list of tags, so a tag nobody anticipated can't survive the pass), and every UID is regenerated. A file whose header declares burned-in annotation is refused rather than stored: patient details printed into the pixels can't be removed without reading the image itself, and storing a file with a clean header and a dirty picture would be worse than declining it outright.

Two write-throughs, both one-directional

A whole-body DEXA scan writes its body composition straight onto your weigh-in row, so bodyweight keeps a single source of truth instead of a DEXA number sitting in one screen and your logged weight sitting in another. Every study is also stamped with whichever training phase you were in the day it was taken, blast, PCT, recovery block, so a change in what a scan measured reads against what was actually running, not against a phase inferred after the fact.

What imaging is never allowed to do is drive training on its own. A finding can pre-select a matching rehab pack when you or a coach starts a rehab episode by hand, and that is the entire reach. No imaging write ever creates a rehab episode, advances a stage, or writes a training constraint by itself. The moment a scan starts steering a program automatically, this stops being a data store and starts being medical advice, which it isn't.

What a coach and an export can see

Imaging carries the same privacy rules as the rest of Health: never posted to a feed, never on a leaderboard, never in any export but your own. A coach sees your studies only through a scope you grant, and loses it the instant the relationship ends: your history stays yours. If you attach a study as evidence in a natural-verification check, only its measured half publishes: procedure, modality, region, date, and confirmed readings. Findings, notes, the facility, the ordering clinician, the report and the DICOM series itself never leave your account that way; a reviewer who needs more has to ask you directly.

Exporting your own data is two different things on purpose. The portability export includes unconfirmed readings, tagged with their source and confirmation state, because it's your data and the dump should describe itself honestly. A clinical FHIR export to a provider excludes anything unconfirmed, because a FHIR Observation is a clinical assertion, and an unreviewed machine guess dressed up as one puts a number no person accepted into a record another clinician might act on.