Standards first, connected to nothing yet.

How Vital would take readings from phones, wearables and home devices, and hand a clear, coded summary to a clinician’s software. Everything on this page is a concept: no device, platform or health system is connected.

One path, from device to clinician.

How a reading would travel if Vital were built for real. Each stage uses an open standard, and nothing passes the consent gate without the person’s say-so.

Diagram of the designed data path. It is described in words below.
  1. Where data startsThrough the phone’s health platform, from wearables and home devices, or typed in by the person.
  2. How it arrivesOpen mHealth shapes for phone and wearable data; Bluetooth GATT profiles and IEEE 11073 for home devices.
  3. VitalEvery reading passes a consent gate that checks the source and the purpose before anything uses it.
  4. How it leavesAs a FHIR R4 Bundle, each measure coded with LOINC (or a declared local code) and a UCUM unit.
  5. Who may read itAn invited clinician’s software through SMART on FHIR, or My Health Record only through a conformant clinical system.

Health data standards

Open standards first, so a reading means the same thing in Vital as it does in a clinician’s software. Every entry carries two honest markers.

Concept · not connected
True of everything on this page. The demo connects to nothing outside your browser.
Standard supported in design
The concept’s data model and export are already shaped around this standard.
Planned
Would be built in a production version. Nothing exists yet.

Exchange and vocabularies

HL7 FHIR R4

Concept · not connectedStandard supported in design

The exchange format. Each measurement becomes an Observation, the person a Patient, each source a Device, and each permission a Consent resource.

In Vital: The app exports your synthetic record as a FHIR R4 Bundle today. Download it from “Your data and consent”.

  • Observation, Patient, Device and Consent resources
  • Australian Base (AU Base) and AU Core profiles as the target for Australian exchange
  • Bundle export of type “collection”

SMART on FHIR

Concept · not connectedPlanned

How a clinician’s system would launch Vital and how Vital would ask for exactly the data it needs, using OAuth 2.0 scopes.

In Vital: Read-only scopes such as patient/Observation.rs, granted per person and revocable.

  • SMART App Launch with OAuth 2.0 and PKCE
  • Narrow, read-only scopes by default
  • Short-lived tokens; access ends when consent ends

LOINC · SNOMED CT-AU · UCUM

Concept · not connectedStandard supported in design

Shared vocabularies: LOINC names what was measured, SNOMED CT-AU names clinical concepts, UCUM names the unit.

In Vital: Every measure in the demo maps to a checked LOINC code (or says plainly that none fits) and a UCUM unit. SNOMED CT-AU would code clinical terms in clinician notes; the demo uses none.

  • LOINC for observation codes
  • SNOMED CT-AU for clinical terms
  • UCUM for units, e.g. mm[Hg], mmol/L, /min

Open mHealth

Concept · not connectedStandard supported in design

Open JSON schemas for personal health data such as step counts, sleep duration and blood pressure.

In Vital: Used as the shape for data arriving from phone platforms and wearables before it is coded as FHIR.

  • step-count, sleep-duration, heart-rate, blood-pressure, blood-glucose
  • Time frames and units kept with every value

Devices

IEEE 11073 personal health devices

Concept · not connectedPlanned

The family of standards for how personal health devices such as blood-pressure monitors, scales and glucose meters describe their readings.

In Vital: Planned for direct device import. Readings would keep the device’s own metadata (model, time, units).

  • Device specialisations for blood-pressure monitors, weighing scales, glucose meters and pulse oximeters
  • Provenance carried into the FHIR Device resource

Bluetooth GATT health profiles

Concept · not connectedPlanned

Bluetooth Low Energy profiles that many home devices use to send readings to a phone.

In Vital: Planned profiles: Heart Rate, Blood Pressure, Glucose, Weight Scale and Pulse Oximeter.

  • Heart Rate profile
  • Blood Pressure profile
  • Glucose profile
  • Weight Scale profile
  • Pulse Oximeter profile

IHE PCD-01

Concept · not connectedPlanned

The IHE “Communicate PCD Data” transaction for sending device observations to another system.

In Vital: Relevant if a clinic’s device gateway, rather than a phone, sends readings into a care workflow.

  • Device-to-system observation messages
  • Useful for clinic-side devices, not consumer wearables

Phones, wearables and home devices

Described as categories, in plain words. No brand logos, no partnerships and no endorsements: if Vital were built, the person would choose what to share, device by device.

  • Phone health platforms

    Through the phone’s health platform: Apple Health (via HealthKit) on iPhone, or Health Connect on Android. The person chooses which data types to share, on the phone, and can turn them off there.

    Concept · not connectedPlanned

  • Fitness bands and watches

    Steps, active minutes, sleep, resting heart rate and overnight heart-rate variability, usually arriving through the phone’s health platform.

    Concept · not connectedPlanned

  • Smart scales

    Body weight. The demo has no weight data, so nothing from a scale appears in Vital’s index.

    Concept · not connectedPlanned

  • Home blood-pressure monitors

    Systolic and diastolic readings with the time they were taken, by Bluetooth or typed in.

    Concept · not connectedPlanned

  • CGMs and glucose meters

    Glucose readings. Continuous glucose data would need a clinician-facing view; Vital’s demo uses occasional pathology results only.

    Concept · not connectedPlanned

  • Sleep trackers

    Bedside or under-mattress trackers that report sleep duration and time in bed.

    Concept · not connectedPlanned

The Australian health system

Where a clinician is involved, Vital would work through the systems they already use rather than around them. All of this is a concept and all of it is planned, not built.

My Health Record

Concept · not connectedPlanned

Only through a conformant clinical system. Vital would not upload to My Health Record itself; a clinician could choose to include a summary.

Secure messaging between clinicians

Concept · not connectedPlanned

A clinician who reviews a Vital summary could forward it to another provider through their existing secure messaging, never by email.

Clinical software FHIR summary

Concept · not connectedPlanned

The provider’s clinical software could import Vital’s FHIR summary, or export a FHIR summary (for example, recent pathology) that Vital shows beside home data.

How each measure is coded

All 13 measures in the synthetic data, in the order Vital stores them. 7 have an exact LOINC code, 1 uses the closest available code and says so, and 5 use a declared local code because no LOINC code fits. A near miss is never forced.

LOINC codes were checked against the LOINC table (through the NLM Clinical Tables LOINC service) when the mapping was written, and their check digits are verified by the test suite. Local codes live in sevn-vital.example/fhir/CodeSystem/vital-measures, a placeholder namespace.

Measure, LOINC code, how well it fits, UCUM unit and typical source. Units in the export use UCUM; Vital shows the friendlier unit beside the measure.
MeasureLOINCMatchUCUMTypical source
Stepssteps/day 41950-7Number of steps in 24 hour Measured

55423-8 (Number of steps in unspecified time, pedometer) suits readings with no fixed period; Vital’s values are daily totals.

Exact {steps}/d Wrist wearable or phone motion sensor, through the phone’s health platform
Active minutesmin/day 55411-3Exercise duration

Vital counts minutes of moderate-or-vigorous activity per day. 55411-3 is the nearest general code; a production build would confirm the coding with a terminology service.

Closest, not exact min Wrist wearable (activity minutes), through the phone’s health platform
Sleep durationh/night 93832-4Sleep duration Exact h Wearable or bedside sleep tracker
Sleep efficiency% No LOINC codesleep-efficiency

No LOINC code for sleep efficiency (time asleep ÷ time in bed) was found.

Local code % Wearable or bedside sleep tracker
Vegetable & fruit servesserves/day No LOINC codeveg-fruit-serves

68511-5 exists but is a questionnaire item about the past 7 days, not a daily log entry, so it is not used.

Local code {serving}/d Self-reported in a daily habits log
WaterL/day No LOINC codewater-intake

9108-2 (Fluid intake total 24 hour) covers all fluids, which is broader than Vital’s water log.

Local code L/d Self-reported in a daily habits log
Heart-rate variability (RMSSD)ms No LOINC codehrv-rmssd

80404-7 is HRV as the standard deviation of R-R intervals (SDNN). Vital’s value is RMSSD, a different statistic, so 80404-7 would be wrong here.

Local code ms Wrist wearable, overnight
Wellbeing check-inof 5 No LOINC codewellbeing-checkin

A simple 1–5 self-rating, not a validated wellbeing instrument.

Local code {score} Self-rated check-in in the app
Resting heart ratebpm 40443-4Heart rate --resting

8867-4 (Heart rate) is the general vital-sign code; 40443-4 says the reading is a resting rate.

Exact /min Wrist wearable or chest strap
Blood pressure, systolicmmHg 8480-6Systolic blood pressureGrouped in the panel 85354-9 Blood pressure panel with all children optional Exact mm[Hg] Home blood-pressure monitor (upper-arm cuff)
Blood pressure, diastolicmmHg 8462-4Diastolic blood pressureGrouped in the panel 85354-9 Blood pressure panel with all children optional Exact mm[Hg] Home blood-pressure monitor (upper-arm cuff)
Fasting glucosemmol/L 14771-0Fasting glucose [Moles/volume] in Serum or Plasma

2339-0 is glucose in whole blood by mass (mg/dL). Australian pathology reports serum or plasma in mmol/L, so 14771-0 fits.

Exact mmol/L Pathology result, through the provider’s clinical software
Waist circumferencecm 8280-0Waist Circumference at umbilicus by Tape measure Exact cm Tape measure, self-measured

Not in the demo data

Codes a smart scale or a pulse oximeter would use. The synthetic personas have no such readings, so these never appear in the index.

MeasureLOINCUCUMTypical source
Body weight 29463-7Body weight kg Smart scale · Weight Scale profile
Oxygen saturation (pulse oximetry) 59408-5Oxygen saturation in Arterial blood by Pulse oximetry % Pulse oximeter · Pulse Oximeter profile

Try it in the explorer

The profile explorer shows the same mapping against each persona’s own records, and builds a real FHIR R4 Bundle from the synthetic data in your browser.

The boundaries

  • Live connectionsNo phone platform, device, clinical system or My Health Record is connected.
  • PartnershipsNaming a platform or standard here implies no relationship with its owner.
  • CertificationNothing here has been tested, registered or approved by anyone.

A production build would require conformance testing against each standard and system it exchanges with, registration and agreements where applicable (for example, with platform owners and for My Health Record access through a conformant system), and validation of the FHIR export against AU Core.