Data flow & governance · one-pager

Where your data goes, and where it doesn’t.

A forwardable answer, for a practice manager or IG lead evaluating Practice Atlas, to the reasonable information-governance questions: where does our data go, do we need a DPIA line for this, what would our DSPT return say. It describes the flows and the safeguards, not the internals.

Practice Atlas supplies search logic; the searches run inside your own EMIS. Patient data never leaves your web browser, stored locally on your machine. You can export it to take with you to another machine and import it back. The only data we process is for login authentication and for compiling searches from your search definitions, never patient data. We don’t want your data; the product was built to keep it where it belongs, in your practice.

Patient records sent to us

Trackers, cookies or CDNs

Auth and compile hosted here

AES‑256

Page encrypted at rest

What Practice Atlas is

A decision-support and search-authoring tool for general practice: QOF, local incentive schemes, recalls. It supplies search logic to the practice; the searches themselves run inside the practice’s own clinical system (EMIS). There is no analytics, no telemetry, no advertising or tracking of any kind, and no third-party scripts, fonts or CDNs on the pages.

Data categories, and where each one lives

Data	Processed	Stored	Sent to Practice Atlas?
Patient data records, results, lists	Inside your own EMIS when a search runs; or in the user’s browser when the practice loads its own exports	Your clinical system; the user’s own browser storage on the practice machine	Never No mechanism transmits it to us
Practice figures achievement counts, forecast entries	In the user’s browser only	Local browser storage; moved between machines only by your own export/import files	Never
Search logic rule structures and code-list references, with no patient data by construction	Our UK-hosted compile service, only when a user builds or edits a search	Not retained: compiled and returned in the request	Definitions only
Account data work email, sign-in records	Our authentication provider, for access control	The authentication provider	Yes The only personal data connected with the service

The flows, end to end

Reading & planning (indicator pages, X-Ray, Forecast, Recalls): the page is a self-contained encrypted document; after sign-in it decrypts and runs entirely in the browser. Files the user loads (search exports, recall CSVs) are read locally in the browser and are never uploaded to us. If the user then chooses to open one of those searches in the builder, the search definition alone is sent to the compile service (below); the file itself, and any patient data in it, stays on the machine.
Search downloads: the practice downloads EMIS-importable XML from the page and imports it into its own system. Exports contain rules only. EMIS itself does not put patient data in them.
Building or editing a search: the search definition is sent over HTTPS to our compile service (Microsoft Azure, UK region) and the compiled XML returned. Definitions describe rules and code lists; they cannot contain patient data. Every request is authenticated and the submissions are not retained.
Drafting a search with the assistant (a beta feature available to signed-in users): the user’s typed description of the search they want is sent over HTTPS to Microsoft’s Azure OpenAI service, which returns a draft. That description is free text the user writes to describe rules, not patients, and we do not filter or retain it. The assistant is constrained never to emit clinical codes itself, and every draft lands in the guided builder for a person to confirm before anything is compiled.
Looking up a clinical code: the search term alone is sent from our server to the NHS England Terminology Server. A code lookup is a dictionary question: no patient data is involved, and the practice’s browser never contacts them directly.
Sign-in: email and password against our authentication provider; access is individually approved and revocable.

Security measures

Encrypted at rest. The application page is AES-256-GCM encrypted and unlocks only for approved accounts; approval is checked server-side on every unlock.

Authenticated, rate-limited transport. All transport is HTTPS. The compile service accepts only authenticated requests from approved users, and is rate-limited.

Personal, revocable access. Accounts are individual, non-shared, and revocable at any time.

Nothing of yours to breach. No patient-identifiable data is ever held by us, so there is nothing of the practice’s to breach, hand back, or delete at contract end beyond the account email.

DPIA, DSPT & clinical-safety positioning

DPIA

Likely a short screening record

The product introduces no new processing of patient data (it stays in EMIS and in the practice’s browser), so most practices will conclude a full DPIA is not triggered; a short screening record referencing this document is the expected outcome. We’re happy to answer an IG lead’s questions directly.

DSPT

Not in the patient-data supplier chain

Practice Atlas does not hold or process patient data on the practice’s behalf, so it does not enter the supplier chain in the way a hosted clinical system does. The account relationship (staff work emails) is the only personal-data processing to note.

Clinical safety · DCB0129

Applicable, and actively worked towards

Because Practice Atlas carries clinical functionality (recall lists, register logic, decision support), we treat the NHS clinical risk management standard for manufacturers, DCB0129, as applicable, and are actively working towards compliance ahead of general release: clinical risk management file, hazard log, and named clinical-safety oversight by a practising GP. The core design is itself the primary mitigation: it assists and never acts. Every output is presented for verification against the record before anyone acts on it; nothing auto-codes, and nothing bypasses clinical judgement.

Controller & processors

Practice Atlas Ltd is the data controller for account data: the work email you register with, and your sign-in records. Your practice remains the controller for patient data, which we never receive. The organisations below process data on our instructions.

Microsoft Azure: compile service, UK region Supabase: authentication, hosted on AWS eu-west-2 (London) IONOS: static web host, currently a Germany / EU region; serves the encrypted application and landing pages only (never patient data, account credentials or search logic; sees standard request metadata such as IP addresses only) Microsoft Azure OpenAI: drafting assistant for the search builder (beta); the resource is hosted in the UK (Azure UK South). It receives the user’s typed description of a search, never patient data, and we retain none of it. Microsoft may process an individual request in another Azure region, so we do not claim UK-only processing for this component NHS England Terminology Server: clinical code lookups; receives search terms only, never patient data, and is contacted by our server rather than the practice’s browser

Retention, in one line each

Patient dataNever held, so no retention.
Practice figuresOn the practice’s own machines, under the practice’s control, deletable at any time.
Compile submissionsNot retained beyond the request.
Account dataFor the life of the account; removed when the account is.