NAP

NAP · Legal & privacy

Legal & privacy

NAP (Not A Patient) is a browser-based simulated patient monitor for healthcare simulation training. It is free to use during its public beta. This page sets out, in plain language, the terms it is offered under and what it does — and does not — do with your data.

For simulation training only

NAP is a teaching simulator, not a medical device and not a patient-monitoring system. Its waveforms and numbers are generated for instruction. Never use NAP for real clinical decisions, diagnosis, treatment or the monitoring of any actual patient.

Terms of use

  • Free to use — all rights reserved

    NAP is free to use during the public beta. It is not open-source. All rights in the software, its design, content and name are reserved by the owner. You may use NAP for teaching and learning; you may not copy, redistribute, resell, rebrand or create derivative versions of it without written permission.

  • Provided as-is, in beta

    NAP is offered on an “as-is” and “as-available” basis, without warranties of any kind. It is beta software: features may change or be removed, and availability, uptime and data persistence are not guaranteed. A live session depends on a relay that may be unavailable or reset without notice.

  • No warranty of accuracy

    NAP makes no warranty that its simulated physiology, waveforms, values or alarms are accurate, complete or clinically valid. Fidelity is deliberately calibrated for teaching, and module-level fidelity remains gated on external clinical face-validation. See the evidence & methodology page for the honest boundary.

  • Use at your own risk — no liability

    You use NAP at your own risk. To the fullest extent permitted by law, the owner accepts no liability for any loss or harm arising from its use — and, in particular, no liability whatsoever for any use in, or affecting, actual patient care. Responsibility for how NAP is used in a session rests with the instructor and their institution.

Privacy

NAP is built to need as little of your data as possible — this is a deliberate design choice, not an afterthought.

  • Accounts are optional, and only for instructors

    Learners and observers never need an account. They join a room with a short code, exactly as before — no name, no email, no sign-up, and nothing stored about them at all. That will not change.

    An instructor may optionally create an account. It is currently in limited preview and not open to everyone. Everything NAP does works without one, and nothing you save is uploaded automatically — your scenarios, decks and presets stay in your own browser unless you explicitly copy them to a cloud library, which is a deliberate act with its own button.

    There is no password. Signing in means typing a six-digit code I email you, so NAP never holds a password for you — nothing here can leak a credential you use anywhere else.

    An account stores your email address, when it was created and last used, and a record of each signed-in browser (a session identifier I cannot read back, and the browser's user-agent string) so you can be signed out. Nothing else. No tier, no plan, no usage history, no record of what you taught.

    Signed-in sessions expire after 30 days. To delete your account and everything attached to it, email [email protected] — it is removed, not deactivated.

  • No profiling — one cookieless measurement, and sessions are counted

    NAP runs no profiling and no cross-site tracking — there is no Google Analytics, Plausible, PostHog or similar, nothing that follows you between sites, and no advertising or tracking cookies.

    There is one measurement on the pages themselves, and it is named here rather than left to the word “none”: the site is hosted on Cloudflare, and Cloudflare Web Analytics counts page views. It sets no cookies, stores no identifier in your browser, and does not follow you to any other site. What it records includes: that a page was loaded, roughly where in the world from, which site linked you here, which page you moved to next, your browser, operating system and device type, and page-performance measurements — which can carry the page address and details of the elements and files involved in drawing it. That list is a summary, not an exhaustive one; Cloudflare documents what it collects. It is how anyone can tell whether NAP is reaching people at all. Like any website, the hosting and network infrastructure that serves NAP and carries relay traffic may also process ordinary connection metadata (IP, timestamps).

    One thing is kept, and it is better spelled out than hidden behind the word “none”: NAP's own relay counts how many sessions happen, which is how anyone can tell whether it is being used at all. Each day it records a short list of whole numbers, and nothing else: how much was used — sessions started, monitor screens joined, demonstrations run, people who watched one, consoles re-attached; roughly how long sessions lasted, as four bands (under two minutes, up to fifteen, up to forty-five, longer); what the relay had to turn away, so I can tell when a limit is stopping someone teaching; and the busiest moment of the day. That is the entire record.

    It contains no session codes, no tokens, no IP addresses, no browser or device details, and no times of day — nothing that could be traced to you, your room, or your institution, and nothing that could distinguish one user from another. The length bands say how long some session ran, never which one or whose. There is no account, name or identifier anywhere in the relay that any of it could be attached to — instructor accounts live in a separate service that the relay cannot see, and none of these counts is linked to one. Daily counts are kept for about thirteen months and then discarded.

  • If you send feedback

    The feedback form is part of NAP — there is no separate form provider, and you no longer leave the site to use it. The cookieless Cloudflare measurement described above runs on this page as it does on every other.

    It asks how likely you are to use NAP again, what you were teaching, what you had to work around or found missing, and what you liked most. Every question is optional. It stores your answers, which version of NAP you were using, and your browser's user-agent string. The contact email is optional too — leave it blank to send anonymously, or fill it in if you would like a reply. It is used for nothing else.

    Three of the questions are free text, so please don't put anything about a real patient in them — they are about the software, and a person reads them.

    There are two copies, both kept for 24 months. One is in a database in London (Neon), and that copy is deleted automatically once it is older than that. The other is an email to me, so that it actually gets read — sent via Cloudflare and arriving in a mailbox hosted by Google; that copy is deleted on the same schedule. Nobody else receives it, and it is never used for marketing.

    To ask what I hold about you, or to have it deleted, email [email protected] — deletion covers both copies. If you sent feedback without an address there is nothing linking it to you, so there is nothing to look up.

  • Your saved work stays on your device

    Anything you save in NAP is kept in your own browser (localStorage) — a small controller record (nap.controller) so an instructor's console survives a page reload, plus anything you deliberately save: your scenarios, question decks, patient presets and display preferences. These stay on your device unless you deliberately copy them elsewhere — nothing is uploaded automatically, and clearing your browser storage removes them.

    If you sign in and use a cloud library (limited preview), the items you choose to copy there are stored on my server — the same database in London described above. Copying is always explicit and in one direction at a time: the copy on your device and the copy in the cloud are separate, and changing one does not change the other.

    How long I keep it: a cloud item stays until you delete it — there is no expiry and nothing is removed on a schedule. Deleting it removes it from my database; the copy on your own device, if you kept one, is yours and is untouched.

    An organisation you belong to may publish a shared library its members can use. Its administrators decide what is in it; you can read and copy from it, and your own copy is yours. ⚠ Your personal library is never visible to an organisation, and joining one never gives it access to anything you already had. An organisation's administrators can see the email address you signed in with, your role, and when your membership expires — and nothing else. Not what you run, when, how often, nor which other organisations you belong to.

    An organisation may also hand out course access: a code a device scans to read that organisation's shared scenarios for the length of a course. ⚠ No account is involved and no email address is given — nobody joins anything, and the organisation is told only how many devices are using each code. I hold nothing else about a course device: no name, no address, no browser or network details, and no record of what it looked at. The access ends on the date the organisation set, or sooner if they end it, and the device is told plainly when that happens. Scenarios already saved to the device are yours and are not affected.

    If an organisation is dissolved by one of its administrators, its shared library disappears for everyone straight away and is permanently deleted after 30 days. The window exists so that a mistake can be undone — it is not an archive, and nobody can reach the content during it. Anything you had already copied into your own library, or onto your own device, is yours and is not affected.

    The one deliberate exception: when you use a saved scenario, patient or question in a live session, that content is sent through the relay to the other devices in the room — that is how the room works. Live room state and audience answers travel the same way; nothing is stored server-side (see below).

  • The relay is in-memory and ephemeral

    Live sessions pass through a relay that simply forwards messages between the devices in a room. It holds room state in memory only — nothing is written to a database. Rooms expire after a period of inactivity (and after a maximum lifetime), and when a room ends its state is gone.

A beta baseline.

This is an honest, plain-language baseline for a beta product, not formal legal advice. As NAP matures these terms may be expanded. If you are adopting NAP at an institution and need something more formal, check with your own legal and information-governance teams.

Rotate your device to portrait

NAP is built for portrait. Turn your phone upright to continue.