Your record, on your terms.

The principles a real Vital would be built to, and how the demo already behaves. These are design intentions, not compliance claims: nothing here has been assessed, certified or approved.

The rules it is designed around

These are the frameworks a real Vital would have to meet. Today they shape the design; none of them has been assessed, and nothing here claims compliance.

Privacy Act 1988 and the Australian Privacy Principles

Australia

Health information is sensitive information under the Act, which raises the bar for every step. Vital is designed to align with the APPs that matter most here:

  • APP 1 Open and transparent handling, with a privacy policy people can actually read.
  • APP 3 and 5 Collect only what is needed, with consent, and say so at the time of collection.
  • APP 6 Use and disclose information only for the purpose it was given for.
  • APP 8 No cross-border disclosure; data stays in Australia by design.
  • APP 11 Keep it secure, and destroy or de-identify it when it is no longer needed.
  • APP 12 and 13 Give people access to their information and let them correct it.

Notifiable Data Breaches scheme

Australia

A production build would require a breach response plan: assess a suspected breach quickly, contain it, and notify affected people and the Office of the Australian Information Commissioner when it is likely to cause serious harm.

My Health Records Act 2012

Australia

Vital would never upload to or read from My Health Record on its own. Any exchange would happen through a conformant clinical system used by a registered provider, under that Act’s rules for access, use and disclosure, and a production build would need legal advice on each step.

TGA: software as a medical device

Australia

Vital is designed to stay a wellness information tool: it shows and explains a person’s own numbers. Any feature that diagnoses, predicts risk or recommends treatment could make the software a medical device, and would need assessment by the Therapeutic Goods Administration before it shipped. The demo has had no such assessment and makes no such claims.

GDPR and HIPAA

Elsewhere

Relevant if Vital ever served people in the European Union (GDPR, where health data is a special category) or handled information for covered entities in the United States (HIPAA). The same principles carry over: lawful basis and consent, minimisation, access and deletion rights, and safeguards. Each market would need its own legal review.

How data would be handled

The principles a production build would be held to.

Data minimisation
Collect only the measures a view needs. If a dimension can be explained without a data type, that data type is not requested.
Local-first where possible
Index maths, summaries and charts run on the device where they can, so fewer raw readings need to leave it.
Encryption in transit and at rest
Every connection encrypted, every stored record encrypted, keys managed separately from the data.
Australian data residency
Data stored and processed in Australia, with no cross-border disclosure.
Audit and access logs
Every read is logged with who, what and when, including an invited clinician and AI agents, and the person can see that log.
Export and delete
Download everything as a FHIR R4 Bundle or CSV at any time. Delete means delete, including backups on a stated schedule.
No selling, no advertising
Health information is never sold, never used for advertising and never used to profile people for anyone else.
Grounded AI explanations
Explanations draw only on the person’s own records and cite them. In the demo, summaries are generated from templates and every sentence links to its records.

Two modes, one record

Self-help

The default for the person. Plain-language readings of their own numbers, small general-wellness next steps, a journal, and questions to take to a GP or health professional. Calm, never alarming, never a diagnosis.

Open the self-help plan

Clinician review

Only by invitation. A denser workspace with tables, trends against general population references (labelled as not personalised), data freshness and missing days. Notes and flags go back to the person; their records stay read-only.

Open the clinician review

This demo today, and what production would need

The concept is honest about the gap. Here is what actually happens in your browser, and what a real product would require before handling anyone’s health information.

Demo behaviour compared with production requirements
AreaThis demo, todayA production build would require
DataSynthetic only. Three fictional personas generated from a fixed seed.A privacy impact assessment before any real health information is collected.
Where it livesIn your browser’s localStorage. Nothing is uploaded. The workspace resets daily at 03:00 Sydney time.Australian hosting with encryption in transit and at rest, backups, key management and a tested restore.
ConsentThe toggles really change what the index, the clinician view and in-app AI agents can see.Legal review of consent wording, a durable consent record, and withdrawal honoured across every system and copy.
Clinician accessA simulated invite code for a fictional clinician, with scope and expiry, and every action logged.Verified practitioner identity, secure sign-in, and expiry enforced on the server, not just in the interface.
Access logKept locally in the workspace, including AI-agent and clinician entries.Tamper-evident audit logs, retained to a policy and monitored.
ExportFHIR R4 Bundle and CSV generated in the browser and structurally self-checked.Validation with the official FHIR validator and AU Core profiles, and conformance testing with each receiving system.
SecurityNo accounts and no server, so nothing leaves your browser.Independent security testing and a breach response plan under the Notifiable Data Breaches scheme.
Clinical safetyNot a medical device. No diagnosis, risk prediction or treatment advice.A clinical safety review, and TGA assessment for anything that would cross into diagnosis, prediction or treatment.
ConnectionsNothing connected to any device, platform or health system.Agreements, registration and conformance testing with each platform and system, where applicable.

What the export looks like

One blood-pressure reading from the synthetic record, as it appears in the FHIR R4 Bundle the explorer builds. The reading is a panel (LOINC 85354-9) with systolic and diastolic components in UCUM mm[Hg], and every resource is marked as test data.

{
  "resourceType": "Observation",
  "meta": {
    "security": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
        "code": "HTEST",
        "display": "test health data"
      }
    ]
  },
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "vital-signs",
          "display": "Vital Signs"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "85354-9",
        "display": "Blood pressure panel with all children optional"
      }
    ],
    "text": "Blood pressure"
  },
  "subject": {"display": "Malik (fictional)"},
  "effectiveDateTime": "2026-09-21",
  "device": {"display": "Home blood-pressure monitor (synthetic)"},
  "component": [
    {
      "code": {
        "coding": [
          {
            "system": "http://loinc.org",
            "code": "8480-6",
            "display": "Systolic blood pressure"
          }
        ],
        "text": "Blood pressure, systolic"
      },
      "valueQuantity": {"value": 127, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}
    },
    {
      "code": {
        "coding": [
          {
            "system": "http://loinc.org",
            "code": "8462-4",
            "display": "Diastolic blood pressure"
          }
        ],
        "text": "Blood pressure, diastolic"
      },
      "valueQuantity": {"value": 83, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}
    }
  ]
}

Trimmed for reading: identifiers, notes and the full Patient and Device references are left out. The full Bundle uses base FHIR R4 resources; AU Core is the design target but is not declared, because the export has not been validated against it.

See it with your own switches

Turn sources and purposes on and off, read the access log, download the FHIR Bundle, and reset everything. It is all synthetic and it all stays in your browser.

Your data and consent