For IT and procurement
What it needs, what it talks to, and what it cannot show you yet.
What it runs on
- Runtime
- Next.js 15 on Node 20 or newer, with React 19 and TypeScript. A single application server; there is no separate worker, queue or search cluster to operate.
- Database
- PostgreSQL, and it is the only supported engine rather than a preference. The schema depends on database triggers for its append-only guarantees, so a store without triggers cannot hold this data correctly.
- Where it can run
- Either hosted (an application host plus a managed PostgreSQL instance) or entirely inside a hospital network. Nothing in the application requires outbound internet access to serve clinical work.
- State and storage
- Waveforms are stored as rows in the same database as everything else, so there is one store to back up, encrypt and account for — not a database plus an object bucket whose contents drift out of step with the records that reference them.
- What must be configured before it will start
- A database URL, a session signing secret, a password pepper and an encryption key. The process refuses to start in production if any of them is missing, is still the placeholder value, or is too short — rather than starting and failing later in a way nobody can diagnose.
What leaves the network, and when
- Nothing, by default
- The content security policy permits no third-party origin at all, with one exception: the payment provider on the billing screen, and only when a deployment has configured one. There is no font host, no icon CDN, no analytics script and no error-reporting service.
- Narrative reporting, if a deployment enables it
- The language-model layer is off unless it is configured deliberately, and the data-processing policy can be set to refuse external AI outright. Where it is enabled, it receives validated findings and no patient identifier — no name, no record number, no study reference and no exact age.
- Outbound transmission of a signed study
- Only to endpoints an administrator has configured, only for a study whose signature still covers the interpretation, and only ever as a deliberate act by a named person. Every attempt is written to an append-only delivery log with the digest of the payload.
- The payment provider, if billing is on
- A checkout carries an organisation identifier, a plan code, an amount and a receipt reference. No patient data reaches it, ever. On a deployment that is not sold by the analysed study, billing is switched off and nothing is sent.
Who can see what
- Tenancy
- Every clinical record is bound to an organisation and a facility. One organisation cannot reach another’s patients, studies, users, audit trail or usage ledger — enforced in the queries, and by consistency constraints in the database as a second line.
- Roles
- Nine roles, from technician to platform operator. Permissions are derived from the role in one table rather than stored per user, so a privilege change is a single auditable act. The audience pages on this site list what each role can do, generated from that same table.
- Separation of duties that is enforced, not encouraged
- A hospital administrator can configure the service and cannot sign a clinical interpretation. A clinician can interpret and cannot certify their own algorithm. An auditor can read the record of acts and holds no permission that changes a clinical record.
- The audit trail
- Append-only through a database trigger, hash-chained so a deletion or an edit is a detectable gap rather than a quiet success. It is not append-only by convention and it does not depend on the application behaving well.
Operating it
- What is configured and what is not, answerable in one request
- The status endpoint reports every component — database, quality engine, analysis engine, review and signature, alerting, each outbound channel, metering and identity verification — as healthy, configured, degraded or not implemented. It is unauthenticated and returns component state only; never a record, a count of patients or a configuration value.
- A check that runs before a deployment is trusted
- A preflight script verifies that the append-only triggers exist, that no synthetic study is present outside a declared demonstration host, that the AI policy agrees with the model configuration, and that outbound endpoints are coherent. It writes nothing, prints no secret, and exits non-zero on a blocker so it can gate a release.
- Backups
- An ordinary PostgreSQL backup is sufficient and complete: there is one store. Restoring it restores the clinical record, the audit chain and the usage ledger together, consistently.
- Failure behaviour
- Losing the database stops clinical work, and says so. Losing a payment provider does not: an unreadable entitlement is logged and the analysis proceeds uncounted, because clinical decision support must not stop because a billing table was unreachable.
What is not there
Six questions whose answer is no.
Certifications
None. This build holds no SOC 2 report, no ISO 27001 certificate, no ISO 13485 quality management system and no regional health-data accreditation. Nothing on this site should be read as implying otherwise.
Regulatory clearance
None anywhere. It is not a medical device, it has not been registered as one, and it is not approved for diagnostic use in any jurisdiction.
Independent security testing
No third-party penetration test has been performed. The security properties described here are design decisions and are exercised by the project’s own test suite; they have not been adversarially verified by anybody else.
Clinical validation
None. The deployment holds a validation register that records who asserted what about which algorithm version, on what dataset. At present it records no clinical validation for any version — and the analytics screens publish no accuracy figure, because there is none to publish.
Reference sites
None. No hospital is running this in clinical service, so there is no site to speak to. That is the single hardest thing to work around in a procurement, and it is better said here than discovered in a reference call.
Support commitments and terms
There is no signed service-level agreement, no published uptime commitment and no standard contract on this site. Any of those would have to be agreed between your organisation and whoever operates the deployment you would be using.
A reasonable first step
Start on a demonstration deployment.
The hosted deployment behind this site exists to be looked at, not to hold records. It serves labelled synthetic studies, it says so on every screen a study can appear on, and it is refused permission to be anything else by its own configuration.
- Use it to answer the clinical question — does this reading experience make sense to your team — without involving your security function at all.
- Use the walkthrough to answer the integration question: how recordings would arrive from your machines and how signed reports would leave.
- Bring your own deployment into scope only once those two are settled. Nothing about the evaluation requires your patient data to be anywhere near this build.
Then a real one
Whose network, whose data, whose responsibility.
A hospital that runs this for real should run its own deployment, on its own database, inside its own boundary. That is not a licensing restriction; it is the only arrangement in which the answers on this page stay true, because the deployment is the system, and a deployment somebody else operates is a system somebody else administers.
What that means in practice is the checklist on the left, in reverse: your database, your backup policy, your identity provider, your network boundary — and the software’s job is to be honest about its own state rather than to hide it. The status endpoint on this deployment is the same one your own would expose, and you are welcome to read it now.
The deployment procedure, the required environment and the reasoning behind each setting are documented in full in the project’s own deployment guide, which is written for the person doing the install rather than for the person reading a landing page.