Secure datasets

Where each dataset in Rainbone comes from, where it is kept, who can reach it and what happens to a scan you import. Every line restates what the code or the data files in the repository do.

Research prototype — not a medical device. The HFValid femur and CTPelvic1K pelvic scans come from public research datasets, and the sample the overview runs is a synthetic test volume. There are no real patient accounts: the clinician in the header is the Dr. Rowan demo profile, or your own Google name and photo if you used Sign in with Google on /enter; those stay in this browser and are never sent to the API, and Google's button sets its own g_state cookie. Only import scans you are allowed to share.

HFValid femur CT

Aldieri, La Mattina, Szyszko, Baruffaldi, Viceconti (2025) · University of Bologna

Static files

Source: HFValid collection, DOI 10.6092/unibo/amsacta/8431 · CC BY 4.0
Subject: Pat001, complete right femur: CT of 256 × 331 × 220 voxels at 0.70 × 0.70 × 2.0 mm, with the authors' segmentation.
Derived here: Slicer 5.12.4 surface of 143,016 triangles; TetGen 1.6.0 mesh of 60,819 tetrahedra and 17,361 nodes; SfePy linear-elastic solve under 800 N with an assumed, uniform Young's modulus of 10 GPa.
Risk table: The study's published table: 101 de-identified records (Pat001–Pat101), each with age, height, weight and side, ARF0 (absolute risk of fracture at time 0), MSF (minimum sideways-fall strength) and the 5-year fracture outcome (4 fractured). No names or dates.
Stored: Static files served with the site: public/models/hfvalid-femur/ (meshes, FE results and a manifest describing how they were made) and public/models/hfvalid-risk.json. Public, read-only research data.

Changes: Slicer import and export, surface reduction, tetrahedral meshing and a new illustrative finite-element analysis. It does not reproduce the dataset authors' own fracture-risk analyses.

CTPelvic1K pelvic CT

Liu et al. (2021) · sub-dataset 6, CLINIC

Private bucket

Source: Zenodo record 10.5281/zenodo.4588403 · CC BY 4.0. Sub-dataset 6 is preoperative pelvic-fracture CT, as its authors describe it.
Derived here: Three CLINIC cases segmented with TotalSegmentator 2.18.0 (Apache-2.0): bone masks and one surface mesh per bone, scored against the dataset's own expert masks.
Stored: A private Vultr Object Storage bucket, under ctpelvic1k/: the masks, the meshes and a manifest with each file's sha256. Nothing in it can be downloaded without a signed link.
Access: GET /api/bones reads the bucket manifest with the server's storage key and signs one download link per file, valid 15 minutes. The browser fetches the meshes straight from the bucket through those links, without the secret key, and gets fresh links first when the current ones are within a minute of expiring.
Integrity: Before a case is drawn, the browser computes the sha256 of every mesh and compares it with the manifest; one mismatch and nothing is drawn. The check needs HTTPS or localhost (Web Crypto); anywhere else the viewer says the meshes were not checked.

The masks are automatic segmentations, not reviewed by a clinician: research data, not for clinical use.

Simulation history

Tiger Cloud · TimescaleDB

Results only

Table: simulation_runs, a hypertable in 7-day chunks, plus an hourly summary of peak stress (simulation_runs_hourly). The API writes one row after each successful solve, only when a database is configured; a failed save never fails the solve.
Columns: timerun_idsource_filenamemax_von_mises_stress_mpaaverage_youngs_modulus_gpabone_volume_cm3fracture_risk_index_percentload_newtonsmesh_verticesmesh_facessolversolver_versionssolve_msThe run id is random. There is no column for names, accounts, patient identifiers or the scan itself.
Retention: Not configured: no retention or compression policy, so rows stay until someone deletes them by hand.
Who can read it: GET /api/history returns the latest runs (up to 500), file names included, to any caller; there is no login.

The file name is stored exactly as it was sent and anyone can read it, so name files without patient details.

Scans you import

Import scan · Solve your own CT

File not kept

What is sent: One .nii or .nii.gz volume of at most 512 MiB, posted to POST /api/simulate. The API solves one scan at a time.
Processing: The API reads the file into memory and parses it there; its code does not save the upload to the bucket or the database, and writes it to disk only as described next. The web framework (Starlette) buffers uploads larger than 1 MB in a temporary file that is deleted when the request ends. When FSL is installed, the CT volume is written to a temporary folder for two FSL commands and the folder is deleted straight after.
Kept afterwards: The result numbers and the file name, as a row in the simulation history (when configured). The solver also emits an info-level log record with the file name and solve details; uvicorn's default logging, which the README's run command uses, does not print it. When Gemini words the explanation, the result numbers and Gemini's text are also saved in the API's answer file (AI_ANSWER_STORE, up to 500 answers), so that when Gemini is unavailable a request with the same numbers gets that Gemini answer back, marked as saved. The scan is not kept.

The explanation cards pass numbers to AI providers, not uploaded scans or their file names. Ask Rainbone also sends the question you type and checked source statements; do not put personal or patient details in questions.

Recent AI answers

Recent answers recorded in Tiger Cloud (TimescaleDB). Facts and answer fingerprints, not their text.

Loading saved records…

Logging is best effort. Reused and saved answers do not add a new record. Preparation time excludes the logging write. These records do not store a verification or cache status.

Keys and secrets

AI, database and storage credentials

Server only

Where they live: The keys are set only on the API server: the Gemini and Groq keys, the database connection string and the lesion-progression storage keys in its environment, backend/.env or a .env at the repository root; the VULTR_S3_* storage keys in its process environment. The API never logs or returns a secret: the signed storage links carry only the access key ID, as S3 requires, never the secret key. The only settings built into the browser code are the API's address and the Google sign-in client ID, which is public by design.
Same origin: With API_PROXY_TARGET set and NEXT_PUBLIC_API_BASE_URL pointing at the site, the site forwards /api/* and /health to the API, so API calls stay on the site's own origin. The pelvic meshes still come straight from the Vultr bucket through signed links. This page calls the API at rainbone.health.
In transit: In production the site is served over HTTPS by Vercel, and the API sits behind a Caddy HTTPS reverse proxy on Vultr Compute.
AI text: Gemini, then a Gemini answer saved earlier for exactly the same numbers (labelled as saved), then Groq, then a built-in template word the explanations. The two explanation cards send the femur's solved values and Pat001's published HFValid figures; their text is checked against those facts. Ask Rainbone additionally sends your question and a fixed source-statement catalogue, then renders only checked selections with citations. Uploaded scans are not included in Ask Rainbone.

HFValid and CTPelvic1K are published under CC BY 4.0; TotalSegmentator under Apache-2.0. Rainbone's simulations use assumed material properties and are not validated for clinical diagnosis or treatment decisions.