Legal & privacy

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 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 — 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). On some networks a live session reaches the relay through Cloudflare's network as well as the relay's own host.

  One thing is kept, and it is better spelled out than hidden behind the word “none”: NAP's own relay keeps a short daily record of how it is used, which is how anyone can tell whether it is being used at all. Each day it records:

  • How much was used: sessions started, monitor screens joined, demonstrations run, people who watched one, consoles re-attached.
  • How long each sim ran: its active minutes (a sim is a session with at least one), sorted, with no code, time of day or order; how many sessions had none; and, for now, four rough length bands.
  • What sims used: how many used each feature, such as the 12-lead or a blood gas, and how many had a co-instructor.
  • Returning browsers: how many rooms were created by a browser that had run a class before, a yes or no it sends with no identifier.
  • Limits: 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.
  • How connections end: the one-word reason an instructor's console gives when it reconnects (in the background, offline, went silent, broke, a reload, NAP restarting), how each console connection ended as the relay saw it, whether a screen asking for a missing room had been in it before, and how many connections came through the website's own address. Counts only.
  • When the relay itself restarted: the minute and the version, so a restart can be told apart from an update.

  The daily figures include the country of the console that opened each room, or that brought it back after a restart, worked out from its connection at that moment and kept only as a two-letter code; the address is not stored. IP Geolocation by DB-IP.

  That is the relay's entire record. It contains no session codes, no tokens, no IP addresses, no browser or device details, and no times of day except when the relay itself restarted — nothing that names you, your room or your institution, and nothing beyond the country that tells one user from another. The daily figures are public on the usage page, so on a day with only one or two sims they describe those sims; they never say 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. These daily totals are kept indefinitely, with nothing in them that identifies a person or a room, and are also copied to NAP's database in London (Neon).

  NAP also keeps a daily summary of its Cloudflare Web Analytics figures, because Cloudflare itself keeps the detail for only about a week. For each country it holds a few whole numbers — how many monitor rooms were opened, and how often the controller, the front page, the free tools' pages and the address printed on NAP's flyers were loaded — and how many visits came from a short list of well-known sources such as Google or Reddit, with every other site counted only as “other site”. It holds no session codes, no addresses and nothing about a person or a room, and it is kept indefinitely, with the same copy in that database.

  The free tools count their own use. When one of a tool's buttons is tapped (save as PDF, save as a picture, copy as text, the link to NAP), the page sends the tool's name, the button's name and, for a save, what was saved: the rhythm, 12-lead pattern and age group of an ECG, or which blood-gas picture and sample. Nothing else. Each is kept with only the day it arrived — no address, browser details, time of day or identifier — and becomes a daily count on the usage page. Test browsers are left out. How often the tool pages were opened, and from which of the sources above, comes from the Cloudflare summary.

• 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, your browser's user-agent string and — if NAP itself offered you the form after you had run some sessions — how many sessions that was (a count on your device, nothing else). 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; apart from the restart handover below, nothing is stored server-side.

• A session record, only if an instructor switches it on

  Recording is off by default. When the lead instructor switches it on, NAP keeps a timestamped record of the session — what learners did on the monitor, what the instructors set, scenario steps, and any bookmarks or notes an instructor adds — in each instructor's own browser (localStorage). While the room is live it passes between the room's instructor consoles through the relay, in memory only; monitors and viewers never receive it. Nothing is stored on NAP's servers, and the record carries no assessment decision.

  Past recordings stay on the device for 30 days, or until more than 20 rooms are held, and are then removed automatically. Anyone using that browser can open them, so on a shared device delete them when you are done — Delete this recording and Delete all recordings under Past recordings work whether recording is on or off. An export or a print is a copy you made, and yours to keep or remove.

• The relay is in-memory and ephemeral

  Live sessions pass through a relay that forwards messages between the devices in a room. It holds room state in memory, and 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.

  One exception, when the relay is stopped in an orderly way — a software update, or the host moving it. It hands its open rooms to the new copy of itself through a file on its own encrypted disk:

  • What the file holds: the room codes, each room's country and current state, and any scenario in use.
  • How long it lasts: until the new copy starts, normally seconds later; it reads the file and deletes it whether or not it could use it.
  • Backups: the host keeps a daily encrypted backup of that disk for five days. A backup taken in those seconds would hold the file for that long.
  • When it is never written: when a room ends or the relay fails.