Data protection

How the Helios Casemix Engine handles data.

What is stored, where it is processed, who can see it and how it is protected — for data-protection officers assessing the service.

What this page is

This page describes, in plain terms, how the Helios Casemix Engine handles data on behalf of its customers. It is meant to give a hospital's or region's data-protection officer the facts needed to assess the service. It is not a signed data-processing agreement; one is agreed separately with each customer.

Draft for review: the wording below has to be checked by Helios's legal adviser, and the hosting region confirmed in the hosting provider's settings, before it is given to a customer as a statement of fact.

Roles

The customer decides why and how patient contacts are grouped and is the data controller for any patient data it sends. Helios provides the grouping service and acts as data processor for that data. For the names and work email addresses of the customer's own staff who use the portal, Helios is a controller of account data needed to run the service.

What is stored

DataPurposeKept
User accounts: name (optional), work email address, role and customer, sign-in credentials (managed by the login provider)Signing in and access controlUntil the account is removed
Second-factor secret (encrypted) and hashed recovery codes, for accounts that switch on two-factor sign-inTwo-factor sign-inUntil it is turned off or reset
Logics: grouping rules, tariffs and the customer's own variants, change log, earlier versions, release notesProviding the grouping serviceUntil the customer or Helios deletes the logic; the last 15 versions of a logic are kept
API keys: a one-way hash of the key, its first characters, name, expiry, allowed addresses, last-used timeAuthenticating API callsUntil the key is deleted
Audit trail: who did what and when, and the IP address at sign-inAccountability and securityKept per month (2,500 entries at most per month); not deleted automatically
Usage counters: number of requests, contacts, errors per day, key and logicShowing the customer its useNot deleted automatically; the portal shows the last 400 days
Notifications and problem reports (page, logic and year that were open, recent technical errors)SupportUntil resolved or removed
Validation tests: test contacts and the DRG each should produceChecking a logic before it goes liveUntil deleted
Bulk grouping jobs: the uploaded file as coded fields only (diagnoses, procedures, age, sex, contact codes and the customer's own contact number), and the resultGrouping big files in the background, and repeating a saved jobA job that does not repeat: deleted 30 days after it finished. A repeating job: until the customer deletes it
Status checks: whether the API and portal answered, and how fast, per dayThe public status pageAbout four months; no customer data
Getting-started progress per customer (whether a test contact was grouped, whether the checklist is hidden)The checklist in the portalUntil the customer is removed

What is not stored

  • Patient contacts sent to the grouping API or entered in "Grouper" are processed to produce the DRG and are not saved by the service. The service stores only counts (how many contacts, how many errors).
  • Contacts uploaded in "Group from files" are processed in the user's browser and sent to the grouping function for the result; they are not saved. The exception is Bulk grouping: a job stores the uploaded contacts (coded fields only) and its result so that it can run in the background and be downloaded; see "What is stored" for how long.
  • Problem reports never contain request or response contents.
  • Validation tests are for synthetic or de-identified test cases. Do not enter real patient data in validation tests — they are stored.

Customers are advised to send only the fields grouping needs (diagnoses, procedures, age, sex and the coded contact fields) and to use their own internal contact number rather than a personal identity number. The service never needs a name or civil registration number.

Where data is processed

The service runs on Netlify (web hosting, serverless functions, file storage and the login service). The processing region is set in the hosting account. To be confirmed by Helios before this page is shared: the region of the functions and storage. Data is transmitted over HTTPS only.

Sub-processors

ProviderWhat it doesData involved
Netlify, Inc.Hosting, functions, storage, login (Netlify Identity)Everything listed under "What is stored"; patient contacts pass through the functions in memory
Resend (only if email notifications are switched on)Sending notification emailsRecipient email address and the notification text (logic names, who did what — no patient data)

Helios will tell customers before adding or replacing a sub-processor, as the agreement requires.

Who can see what

  • A customer's users see only their own customer's logics, keys, release notes and activity. This is enforced on the server for every request, not only on screen.
  • Helios staff can see all customers' logic data and account data in order to support them. Helios administrators can also view the service "as" a customer. Changes made that way are recorded under the Helios user's own name, and the customer's audit trail shows what Helios did on their behalf.
  • Inside a customer, each user has a level — read-only, editor, approver or administrator — that decides what they may change; for example only approvers can accept a logic or approve a change, and only administrators manage users. Levels are enforced on the server.
  • Customer administrators invite and remove their own users, set their level, and see their own audit trail.
  • The public production pages of a customer show Atlas and "Grouper" for the years the customer has put in production; they hold no account data.

Security measures

  • Encrypted transport (HTTPS). Storage encryption is as provided by the hosting provider — to be confirmed by Helios before this page is shared.
  • Role-based access with a strict separation between customers.
  • Optional two-factor sign-in with an authenticator app, which Helios can require for administrators; checked on the server.
  • Automatic sign-out after 45 minutes of inactivity.
  • Automatic checks before every release, and a separate test environment with its own empty data store, so changes are tried without touching customers' data.
  • API keys stored only as one-way hashes; keys can expire, be revoked and be limited to the customer's own IP addresses.
  • A change log with a required reason and a second person's approval for every change to a logic; restorable versions; production rollback.
  • An audit trail of sign-ins, changes, pushes and key and user management, which cannot be edited.

Retention and deletion

Customer data is kept while the agreement runs. When a customer is deleted, its production snapshots are removed; its logics, users and keys can be removed on request. The audit trail and usage counters are kept for the periods shown above. At the end of the agreement Helios deletes or returns the customer's data on request.

Your questions and rights

Questions about this page, data-subject requests concerning staff accounts, or reports of a suspected security incident: use the contact page. Helios will notify a customer without undue delay of a personal-data breach affecting its data.

Points to settle in your agreement

  • Hosting region and any transfers outside the EU/EEA.
  • The list of sub-processors and the notice period for changes.
  • Whether patient contacts will be sent to the API at all, and which fields.
  • Retention of the audit trail and of usage data.
  • Right to audit, incident-notification time and contact persons.