Overview

Helios offers customers two ways to use a finished logic, both managed from the Helios Casemix Engine under Admin:

• The grouping API — the customer's own systems send contacts and receive DRGs as JSON. Access is controlled by API keys that you create and revoke. The customer-facing description is in the API guide.
• Production sites — every customer gets two public web pages, heliosgroup.dk/<customer>/flow (Atlas) and heliosgroup.dk/<customer>/group (Grouper), with a year picker. They are read-only and open to anyone with the link.

Both only ever serve logics that have been fully approved, so nothing half-reviewed reaches a customer.

Who can do what

Access is set per account with roles in Netlify Identity.

Helios's own accounts are not limited by these levels. The levels are enforced on the server, not only by hiding buttons.

The public production pages need no login and cannot change anything.

Customers and their users

A customer can have any number of users (for example 11 users at Region X). Customers are kept strictly apart: a customer's users can never see, open, group with, edit, export, use, edit, export or delete another customer's logics, and never see Helios's own.

Set up a customer's users

1. In Netlify Identity, invite each user.
2. Give every one of them two roles: grouper and customer-<slug>, where the slug is the customer's address under Production sites (Region X → customer-regionx). The slug must match exactly.
3. Do not give customer users grouper-admin — that role sees everything.

What a customer user sees

• Only the logics tagged with their customer, in Library, Atlas, Developer and Grouper. Their logic names are prefixed with the customer, e.g. regionx-….
• Their own users share one set of logics, and the active logic is per customer — activating one logic switches off only that customer's previous one.
• New and imported logics are created under their own customer automatically. They cannot choose another customer.
• API calls with their key use their customer's API default logic, never a logic belonging to anyone else.
• Production sites shows only their own site. They can push their own approved logics to it, but cannot add or delete customers.
• They can upload their own SKS catalogue under Creator — one file per year, or one file ticked for several years. A year without a file of their own uses the standard catalogue that you import; only Helios administrators can change that one. They see no Helios-only section in the client portal.

What you do as Helios staff

• Add the customer under Production sites first — it then appears in the client portal's customer list.
• To work as a customer, open the client portal, scroll to Helios team and choose the customer under View the portal as a customer. The engine then opens exactly as that customer's own login sees it, and a bar at the top says so. Choose Helios — my own view (or press Back to the Helios view) to return.
• A logic belongs to the customer you were viewing as when it was created or imported; logics created in your own Helios view belong to Helios. There is no way to move an existing logic to another customer — import or duplicate it while viewing as the right customer instead.
• Logics without a customer are Helios-internal: only Helios accounts see them. Customers never see shared or standard Helios logics — give a customer a copy with Push to client: on a Helios logic in Library, choose the client in the drop-down and press Push. That puts an independent, inactive copy in Library of the client's own account (later edits to either logic do not affect the other; pushing again makes another copy).
• Every logic and every client has a logic type (DK-DRG unless you set another, shown as a small label that you click to change; clients are changed under Production sites). A logic can only be pushed to a client of the same type — clients of another type are greyed out in the drop-down. As with Set as API default, a logic whose change log still has changes waiting for approval cannot be pushed.
• A plain grouper account with no customer role is a Helios user: it sees only Helios-internal logics and has no Production sites panel.

The approval rule

Every edit to a logic in the editor is written to its change log. A logic can only be set as API default, pushed to production or used through the API by name when its change log has no entries waiting for approval. Accepted and declined entries do not block; only pending ones do.

In Library, a logic with outstanding approvals shows a warning icon; hover it to see how many. Open the change log, accept or decline each entry (a different person than the editor should do this — the four-eyes principle), and the icon disappears.

Use Lock on a logic row in Library to protect a logic from being edited: rules, labels, code groups, tariff data, year and deletion are all blocked, here and on the server, until someone chooses Unlock. A locked logic shows a lock tag. It can still be duplicated (the copy starts unlocked), set as API default, pushed to production and used for grouping.

API keys

Open the client portal and scroll to Helios team → API keys. Only grouper-admin accounts see it, and it is hidden while you are viewing as a customer.

Create a key

1. Type the customer or system name — one key per customer system, so a single key can be revoked on its own.
2. Choose Customer. The key is bound to that customer and can only ever group with that customer's logics.
3. Choose Logic (the list shows that customer's logics): All approved logics, or restrict the key to one logic (for example a customer who must stay on the 2025 logic).
4. Choose Expires: never, after 90 days or after 1 year.
5. Press Create key.
6. Copy the key immediately. It begins with hgk_ and is shown only this once; Helios stores just a one-way hash and the first characters so you can recognise it later. If it is lost, create a new key and revoke the old one.
7. Send the key to the customer by a secure channel (not plain e-mail if you can avoid it), together with the API guide.

The key list

Each key shows its name, first characters, created date, expiry, logic restriction and last used time (updated at most every ten minutes — useful for seeing whether a customer has actually started calling the API).

• Revoke switches the key off immediately. Calls with it answer revoked_key.
• Delete is available only on revoked keys and removes the record completely.

Rotating a key

Create the new key, let the customer switch over, check that last used on the old key stops moving, then revoke it.

Production sites

Tick Production sites in the menu on the left (below the line).

Add a customer

Type the customer's name (for example Region X) and press Add customer. The name is turned into the web address: Region X becomes regionx or similar, shown next to the customer once created. Names that cannot be used as an address, or that collide with an existing page or an internal word (such as api, admin, portal, about, contact), are refused; try another. The two pages for each customer are:

https://heliosgroup.dk/regionx/flow     Atlas
https://heliosgroup.dk/regionx/group    Grouper

Both stay empty ("Nothing is published here yet") until you push a logic.

Delete a customer

Delete customer removes the customer and all its pushed snapshots; the addresses then show "This page doesn't exist". Your own logics in Library are not touched.

Pushing a logic into production

Each customer card has one row per year. For a year:

1. Pick the logic in Logic to push. The list contains the logics that have that year, so give a logic its year under Library first.
2. Press Push to production. If the logic still has pending changes, the push is refused — approve its change log first.
3. The row then reads live: <logic name> — pushed <date> by <who>. The year now appears in the year picker on the customer's public pages.

• A push is a snapshot. It copies the logic exactly as it is at that moment. Editing the logic afterwards does not change what the public sees. To publish a correction, approve the change and press Push again.
• A customer can have one live logic per year. Pushing another logic for the same year replaces the previous one.
• Take offline removes that year from the public pages. If it was the last year, the pages show the "nothing published" message.
• Pushing copies several large tables and can take a few seconds. Wait for the row to update before pressing anything else.

Staged push: the customer accepts first

When you push a logic to a customer from Library, the customer gets their own copy. By default that copy is pending: they have to open it and press Accept before it can be set as their API default, be used by their API keys, or be put in production. This lets them try it in the Casemix Engine first — it is their sandbox.

• Type a short What changed? note next to the Push button. It is shown on the customer's copy, in their release notes and in the notification they receive.
• Untick Client must accept first for a push that needs no review (for example an urgent correction). The copy is then usable straight away.
• The row shows Awaiting customer review, Accepted by … or Declined. A customer who declines must give a reason; you see it on the row and get a notification. Push a new version to start again.
• A copy that is pending or declined cannot go to production and is ignored by the API until it is accepted.

Versions, restore and rollback

Versions of a logic

The Versions button on a logic opens its history. A version is saved automatically when the last change waiting for approval is approved, before every push to a customer or to production, and before every restore. You can also press Save a version now (with a label such as "before the January tariff update"). The last 15 are kept; identical states are not saved twice.

• Compare with now shows how many rules were added, removed or changed since that version, with examples.
• Restore puts that version's tables back as the live logic. A reason is required; it goes in the change log ("Version restored") and the audit trail, and the customer is told if the logic is theirs. The state before the restore is saved as a version too, so a restore can itself be undone. A locked logic cannot be restored — unlock it first.
• A version saved when everything was approved restores as approved. One saved by hand mid-edit still needs a second pair of eyes in the change log.

Rolling back production

Each year on a customer card keeps the three previous versions that were live. Under Earlier versions, press Roll back to this (twice, to confirm). The public pages switch at once; the version that was live moves into the history, so a rollback can be undone the same way. A rollback is recorded in the release notes and the customer is notified.

Type a What changed? note when you push to production; it appears under Live in production in the customer's portal.

Usage, release notes and the audit trail

In the client portal, the card Usage, releases and activity shows, for the customer you choose (customers see only their own):

• API usage — requests, contacts grouped, contacts with an error and refused requests for 7, 30 or 90 days, per day, per API key and per logic. The figures are close but not exact: two requests landing in the same instant can be counted once.
• Release notes — what is live per year and every push, rollback, acceptance and restore with its note.
• Audit trail (Helios administrators and customer administrators) — who did what to logics, users, keys and sign-in security, with the address people signed in from. The last three months are shown; Export saves them as a CSV. Customers see everything that concerns their account, including what Helios did on their behalf. Entries cannot be edited or deleted. A month holds at most 2,500 entries.

Security: two-factor, IP limits, idle sign-out

Two-factor sign-in (authenticator app)

Netlify Identity has no two-factor login of its own, so the engine adds one on top: a 6-digit code from an authenticator app (Microsoft Authenticator, Google Authenticator, 1Password …). It is checked on the server for every request, not just on screen.

1. In Netlify's site settings add the environment variable TWOFA_SECRET with a long random string (at least 16 characters; 40 is better). Without it the feature stays off. Do not change it later: it protects the stored secrets, and changing it locks everyone who enrolled out.
2. Optional: add REQUIRE_2FA with the value admins to make Helios administrators and customer administrators set it up before they can do anything else.
3. Everyone can switch it on under Sign-in security in the client portal. The portal shows a key to type into the app (or a link that opens it on a phone) and eight one-time recovery codes — shown once, to be stored safely.

• Lost phone and recovery codes: a Helios administrator uses Reset someone's two-factor sign-in in the same card. The person signs in normally and sets it up again.
• If every Helios administrator is locked out: open Netlify Identity, find the account and remove the mfa role. Two-factor is then off for that account.
• If TWOFA_SECRET is removed while accounts carry the mfa role, those accounts are refused (fail closed). Put the secret back, or remove the role.
• The proof of the code is valid for 12 hours in that browser; each code can be used once.

Single sign-on (the customer's own identity provider, such as Entra ID or a regional login) is not possible with Netlify Identity as it is used here. It requires moving sign-in to an identity provider that supports SAML or OIDC; the engine's roles and customers would carry over. Plan it as a separate project.

Allowed addresses for an API key

When you create a key, Allowed addresses can limit it to your customer's servers: IPv4 addresses, IPv4 ranges such as 198.51.100.0/24, or IPv6 addresses, separated by commas. The Addresses button on a key changes the list later. A request from any other address gets 403 ip_not_allowed. Leave it empty to allow every address. Customers behind a changing address (mobile networks, some proxies) should not be limited.

Inactivity sign-out

After 45 minutes without activity in any open tab, people are signed out; two minutes before, a notice offers Stay signed in.

Data protection page

The Data protection page describes in plain terms what is stored, where and who can see it. It is a starting point for a data-processing agreement, not the agreement itself; have it reviewed by your legal adviser and confirm the hosting region in Netlify before you send it to a customer.

What the public sees

The two pages are the same engine, with every way to change data removed. They have no login and nothing links to them — anyone who knows the address can open them, so share the address only with the customer. Do not put confidential information in a logic that is pushed to production.

Not available on the public pages: editing rules, labels, group codes or tariffs, the change log, importing, exporting, logics, and grouping from files.

Validation tests

Every logic can carry a set of validation tests: test contacts together with the DRG each one must group to (and, if you like, the tariff and trim point). They are the safety net before anything reaches a customer.

• Adding tests. In Grouper, group a contact and choose Save as validation test; or open Validation tests on the logic in Library and import a CSV (download the template there). Up to 300 tests per logic.
• Running them. Run validation groups every test against the logic's current rules and shows pass or fail per test. Download report saves the result as a CSV.
• Automatic gate. Pushing a logic to a customer, and pushing to a production site, runs the tests first. If any fail the push is stopped and the failing tests are listed. A Helios administrator can choose to push anyway; the override is recorded on the validation run.
• When a logic is pushed or duplicated its tests travel with the copy, so the customer's copy can be re-tested after later changes.

Notifications, problem reports and customer users

The bell and the "Report a problem" button

Signed-in users see a small bell and a Report a problem button at the bottom right of the portal and the engine. The bell lists what matters to them: a new logic in their library, a logic that went live in production, an approved or declined change, an API key about to expire. Helios sees new problem reports and new invitations.

A problem report carries the description, the page, the logic and year that were open, and recent errors and failed requests. It never contains patient data. Helios administrators work through them under Problem reports in the Helios section of the client portal (mark resolved, reopen).

Customer users

Under Your team in the portal, a customer's administrator can invite colleagues, make someone an administrator, or remove access. A Helios administrator sees the same card with a customer selector. The first administrator of each customer has to be given the portal-admin role by a Helios administrator in Netlify Identity (in addition to grouper and customer-<name>); after that the customer manages their own users. There must always be one administrator left, and nobody can remove their own access.

Optional email

Notifications always appear in the bell. To also send email, set RESEND_API_KEY and NOTIFY_FROM (a verified sender address) as environment variables on the site; set REPORT_TO to receive problem reports by email too. Without them nothing is sent and nothing breaks.

Roles inside a customer

Every customer user has one of four levels: Read-only, Editor, Approver or Administrator (see Who can do what). A customer's administrator sets them under Your team in the client portal: pick the level when inviting someone, or change it afterwards in the drop-down next to the person. A Helios administrator can do the same for any customer.

• An account that already existed before this feature has none of these roles and counts as an Approver, which is everything it could do before (managing users stays with the administrators). Nothing is taken away; set someone to Editor or Read-only to limit them.
• Keep at least two people in each customer at Approver level (or administrator): nobody can approve their own change, so a single approver cannot approve their own work. Someone invited as Editor cannot accept a pushed logic or approve a change.
• A Read-only user sees the Grouper and Atlas panels only. If they try something else the server answers insufficient_role and the screen says their role does not allow it.
• Each level change is written to the audit trail.

Bulk grouping jobs

For big files, Bulk grouping (under Grouper, below Group from files) groups up to about 20,000 contacts on the server, so nobody has to keep a browser open.

• The user picks a logic, uploads an Excel workbook (the same Stam / Diag / Proc / Forl layout as Group from files, with forløb grouped by the loop method) or a CSV with one contact per row (a template can be downloaded), and presses Upload and start.
• The job shows its progress; when it is ready the person who started it gets an email (if email is set up) and a notification, and the result can be downloaded as Excel or CSV. Open the page again at any time — the jobs are listed there.
• A saved job can repeat every week or month against the logic as it is at that time. The repeat is started by the daily scheduled function; it needs JOBS_SECRET (any long random text) in the site's environment settings, or else TWOFA_SECRET, which is used if it is set. Without either, repeats do not start.
• A repeat or a run uses a logic only if the customer has accepted it and it has its tables — otherwise the job fails with a clear reason and the person is told.
• Only Editors and above can create jobs; Read-only users can download results. A customer sees only its own jobs, Helios sees all.
• Limits: 50,000 records per job (a forløb counts once per contact), 20 saved jobs per customer.
• Data: the uploaded file is stored as coded fields only (diagnoses, procedures, age, sex and the contact codes, plus the customer's own contact number), together with the result. A job that does not repeat is deleted automatically 30 days after it finished; a repeating job is kept until someone deletes it. Say so to customers — see the Data protection page.

The getting-started checklist

Customer users see a Getting started card at the top of the client portal: accept the logic, group a test contact, get an API key, send a first API request, and (optional) try a whole file and see the live site. The ticks come from what has actually happened, so nobody has to tick anything. Each customer can hide the card and show it again.

The card also links two sample files, sample-contacts.xlsx and sample-contacts.csv, for trying Group from files and Bulk grouping. The codes in them are examples; check the results against your own logic before showing them to a customer.

Alerts and the status page

Alerts

• Error spike. When a customer's errors for the day pass 20 and make up at least 20 % of what was sent, the customer's bell gets a notice and Helios's bell does too (and an email, if email is set up). At most one a day per customer. Change the limits with ALERT_MIN_ERRORS and ALERT_ERROR_RATE (for example 0.3 for 30 %).
• Key about to expire. Customers already see it in the bell. In addition, an email goes to the customer's users when a key has 14 days left and again at 3 days, and Helios gets a notice.
• These run from the daily scheduled function and the API itself, so they work on the live site only.

The status page

status.html is public. Every hour the site asks its own grouping API (/api/v1/health) and the portal page whether they answer, and keeps the result per day. The page shows whether each is up now, uptime for the last 90 days with one bar per day, and recent incidents. It holds no customer data. If the checks stop for more than 90 minutes the page says unknown rather than operational. Helios gets a notice when something stops answering.

The page links from the footer of every page. The checks are Netlify scheduled functions, which run only on the published (production) deploy.

Supporting a customer

• "Which logic is my key using?" If no logic is named in the request, the one that is active in Library. The result of every call includes the logic's id, name and year.
• "Results changed." A new logic was set as API default, or an edit to the API default logic was approved. Customers who need stable results should name a logic id in their requests, or have their key restricted to one logic.
• Edits reach the API within about a minute (logics are cached briefly). Production pages change only when you push.
• Limits: 500 contacts per request, 100 codes per list. Larger files are sent in several requests.
• Contacts sent through the API are not stored; only the key's last-used time is recorded.

Troubleshooting

Staging site and automatic checks

Try changes before they reach customers.

• Automatic checks. Every deploy runs npm test first (the build command in netlify.toml). If a check fails, Netlify does not publish that deploy and the live site stays as it was. GitHub runs the same checks on every pull request (.github/workflows/test.yml).
• A staging copy. Make a branch called staging in GitHub and, in Netlify, enable Branch deploys for it (Site configuration → Build & deploy). It gets its own address, like staging--heliosgroup.netlify.app. Pull requests get a deploy preview the same way.
• Separate data. A staging or preview deploy uses its own store (grouper-branch-deploy, grouper-deploy-preview), so nothing done there touches the live logics, keys or customers. It starts empty: import a logic or two to test with. A banner at the top says Test environment.
• Settings. The environment variables must be available for the contexts Branch deploys and Deploy Previews, not only Production (Site configuration → Environment variables). Use different values for TWOFA_SECRET and for the Resend settings if you do not want test emails going out. Scheduled checks and bulk repeats do not run on staging.
• Moving a change to the live site. Merge the branch into the main branch; the build runs the checks again before publishing.

First-time setup

1. Deploy the site with the API and production functions and the updated netlify.toml. The redirects /api/v1/* and /<customer>/flow, /<customer>/group only exist after that deploy.
2. Check https://heliosgroup.dk/api/v1/health in a browser; it should answer {"ok":true,"apiVersion":"1"}.
3. Make sure a logic has been set as API default and has its tariff data, then create the first key and test it with the curl example in the customer guide.
4. Add the first customer, push a logic and open both customer pages in a private browser window (not signed in) to confirm they work for the public.

Overblik

Helios tilbyder kunderne to måder at bruge en færdig logik på, og begge administreres fra Helios Casemix Engine under Admin:

• Grupperings-API'et — kundens egne systemer sender kontakter og modtager DRG'er som JSON. Adgangen styres af API-nøgler, som du opretter og tilbagekalder. Beskrivelsen til kunden findes i API-vejledningen.
• Produktionssider — hver kunde får to offentlige websider, heliosgroup.dk/<customer>/flow (Atlas) og heliosgroup.dk/<customer>/group (Grouper), med en årsvælger. Siderne er skrivebeskyttede og åbne for alle, der har linket.

Begge leverer kun logikker, der er fuldt godkendt, så intet halvgennemgået når frem til en kunde.

Hvem kan hvad

Adgang styres pr. konto med roller i Netlify Identity.

Helios' egne konti er ikke begrænset af disse niveauer. Niveauerne håndhæves på serveren og ikke kun ved at skjule knapper.

De offentlige produktionssider kræver ikke logon og kan ikke ændre noget.

Kunder og deres brugere

En kunde kan have et vilkårligt antal brugere (for eksempel 11 brugere hos Region X). Kunderne holdes strengt adskilt: en kundes brugere kan aldrig se, åbne, gruppere med, redigere, eksportere, bruge eller slette en anden kundes logikker og ser aldrig Helios' egne.

Opsæt en kundes brugere

1. Inviter hver bruger i Netlify Identity.
2. Giv hver enkelt to roller: grouper og customer-<slug>, hvor slug er kundens adresse under Produktionssider (Region X → customer-regionx). Sluggen skal stemme nøjagtigt overens.
3. Giv ikke kundebrugere grouper-admin — den rolle ser alt.

Hvad en kundebruger ser

• Kun de logikker, der er mærket med deres kunde, i Library, Atlas, Developer og Grouper. Logikkernes navne har kunden som præfiks, fx regionx-….
• Kundens egne brugere deler ét sæt logikker, og den aktive logik gælder pr. kunde — når du aktiverer en logik, slukkes kun den pågældende kundes tidligere aktive logik.
• Nye og importerede logikker oprettes automatisk under deres egen kunde. De kan ikke vælge en anden kunde.
• API-kald med deres nøgle bruger deres kundes API-standardlogik, aldrig en logik, der tilhører andre.
• Produktionssider viser kun deres eget site. De kan pushe deres egne godkendte logikker dertil, men kan ikke tilføje eller slette kunder.
• De kan uploade deres eget SKS-katalog under Creator — én fil pr. år, eller én fil markeret til flere år. Et år uden en egen fil bruger standardkataloget, som du importerer; kun Helios-administratorer kan ændre det. De ser ingen sektion, der kun er for Helios, i kundeportalen.

Hvad du gør som Helios-medarbejder

• Tilføj først kunden under Produktionssider — så vises den i kundeportalens kundeliste.
• For at arbejde som en kunde skal du åbne kundeportalen, rulle ned til Helios-teamet og vælge kunden under Se portalen som en kunde. Engine'en åbner så præcis, som den ser ud for kundens egen logon, og en bjælke øverst viser det. Vælg Helios — min egen visning (eller tryk på Tilbage til Helios-visningen) for at vende tilbage.
• En logik tilhører den kunde, du så som, da den blev oprettet eller importeret; logikker oprettet i din egen Helios-visning tilhører Helios. Det er ikke muligt at flytte en eksisterende logik til en anden kunde — importér eller duplikér den i stedet, mens du ser som den rigtige kunde.
• Logikker uden kunde er interne for Helios: kun Helios-konti ser dem. Kunder ser aldrig delte eller standardlogikker fra Helios — giv en kunde en kopi med Push til klient: vælg klienten i rullelisten på en Helios-logik i Library, og tryk på Push. Det lægger en uafhængig, inaktiv kopi i Library på klientens egen konto (senere rettelser af den ene logik påvirker ikke den anden; hvis du pusher igen, laves endnu en kopi).
• Hver logik og hver klient har en logiktype (DK-DRG, medmindre du angiver en anden, vist som en lille etiket, du klikker på for at ændre; klienter ændres under Produktionssider). En logik kan kun pushes til en klient af samme type — klienter af en anden type er nedtonede i rullelisten. Som ved Sæt som API-standard kan en logik, hvis ændringslog stadig har ændringer, der afventer godkendelse, ikke pushes.
• En almindelig grouper-konto uden kunderolle er en Helios-bruger: den ser kun Helios-interne logikker og har ikke panelet Produktionssider.

Godkendelsesreglen

Hver rettelse af en logik i editoren skrives i dens ændringslog. En logik kan kun sættes som API-standard, skubbes i produktion eller bruges via API'et med navn, når dens ændringslog ikke har nogen poster, der afventer godkendelse. Godkendte og afviste poster blokerer ikke; det gør kun afventende poster.

I Library vises et advarselsikon ved en logik med udestående godkendelser; hold musen over det for at se hvor mange. Åbn ændringsloggen, godkend eller afvis hver post (det bør være en anden person end den, der har redigeret — fireøjneprincippet), og ikonet forsvinder.

Brug Lås på en logikrække i Library for at beskytte en logik mod redigering: regler, etiketter, kodegrupper, takstdata, år og sletning er alle blokeret, både her og på serveren, indtil nogen vælger Lås op. En låst logik har et låsemærke. Den kan stadig duplikeres (kopien starter ulåst), sættes som API-standard, skubbes i produktion og bruges til gruppering.

API-nøgler

Åbn kundeportalen og rul ned til Helios-teamet → API-nøgler. Kun grouper-admin-konti ser den, og den er skjult, mens du ser som en kunde.

Opret en nøgle

1. Skriv kundens eller systemets navn — én nøgle pr. kundesystem, så en enkelt nøgle kan tilbagekaldes for sig.
2. Vælg Kunde. Nøglen er bundet til den pågældende kunde og kan kun gruppere med kundens logikker.
3. Vælg Logik (listen viser kundens logikker): Alle godkendte logikker, eller begræns nøglen til én logik (for eksempel en kunde, der skal blive på 2025-logikken).
4. Vælg Udløber: aldrig, efter 90 dage eller efter 1 år.
5. Tryk på Opret nøgle.
6. Kopiér nøglen med det samme. Den begynder med hgk_ og vises kun denne ene gang; Helios gemmer kun en envejs-hash og de første tegn, så du kan genkende den senere. Hvis den går tabt, skal du oprette en ny nøgle og tilbagekalde den gamle.
7. Send nøglen til kunden via en sikker kanal (helst ikke almindelig e-mail), sammen med API-vejledningen.

Nøglelisten

Hver nøgle viser sit navn, de første tegn, oprettelsesdato, udløb, logikbegrænsning og tidspunktet for sidst brugt (opdateres højst hvert tiende minut — nyttigt til at se, om en kunde faktisk er begyndt at kalde API'et).

• Tilbagekald slukker nøglen øjeblikkeligt. Kald med den besvares med revoked_key.
• Slet kan kun bruges på tilbagekaldte nøgler og fjerner posten helt.

Udskiftning af en nøgle

Opret den nye nøgle, lad kunden skifte over, tjek at sidst brugt på den gamle nøgle ikke længere ændrer sig, og tilbagekald den derefter.

Produktionssider

Vælg Produktionssider i menuen til venstre (under linjen).

Tilføj en kunde

Skriv kundens navn (for eksempel Region X) og tryk på Tilføj kunde. Navnet omdannes til webadressen: Region X bliver til regionx eller lignende, vist ved siden af kunden, når den er oprettet. Navne, der ikke kan bruges som adresse, eller som kolliderer med en eksisterende side eller et internt ord (såsom api, admin, portal, about, contact), afvises; prøv et andet. De to sider for hver kunde er:

https://heliosgroup.dk/regionx/flow     Atlas
https://heliosgroup.dk/regionx/group    Grouper

Begge forbliver tomme ("Der er intet udgivet her endnu"), indtil du pusher en logik.

Slet en kunde

Slet kunde fjerner kunden og alle dens pushede snapshots; adresserne viser derefter "Denne side findes ikke". Dine egne logikker i Library berøres ikke.

Pushe en logik i produktion

Hvert kundekort har én række pr. år. For et år:

1. Vælg logikken under Logik der skal i produktion. Listen indeholder de logikker, der har det pågældende år, så giv først logikken dens år under Library.
2. Tryk på Skub i produktion. Hvis logikken stadig har afventende ændringer, afvises pushet — godkend først dens ændringslog.
3. Rækken viser derefter live: <logic name> — pushed <date> by <who>. Året vises nu i årsvælgeren på kundens offentlige sider.

• Et push er et snapshot. Det kopierer logikken præcis, som den er i det øjeblik. Hvis du redigerer logikken bagefter, ændrer det ikke, hvad offentligheden ser. For at udgive en rettelse skal du godkende ændringen og trykke på Skub igen.
• En kunde kan have én live-logik pr. år. Hvis du pusher en anden logik for samme år, erstatter den den forrige.
• Tag offline fjerner det pågældende år fra de offentlige sider. Hvis det var det sidste år, viser siderne beskeden om, at intet er udgivet.
• Et push kopierer flere store tabeller og kan tage nogle sekunder. Vent, til rækken er opdateret, før du trykker på noget andet.

Trinvis push: kunden godkender først

Når du pusher en logik til en kunde fra Library, får kunden sin egen kopi. Som standard er kopien afventende: kunden skal åbne den og trykke på Godkend, før den kan sættes som deres API-standard, bruges af deres API-nøgler eller sættes i produktion. Det lader dem prøve den i Casemix Engine først — det er deres sandkasse.

• Skriv en kort note under Hvad er ændret? ved siden af Push-knappen. Den vises på kundens kopi, i deres udgivelsesnoter og i den notifikation, de modtager.
• Fjern markeringen i Kunden skal først godkende ved et push, der ikke behøver gennemgang (for eksempel en hastende rettelse). Kopien kan så bruges med det samme.
• Rækken viser Afventer kundens gennemgang, Godkendt af … eller Afvist. En kunde, der afviser, skal angive en begrundelse; du ser den på rækken og får en notifikation. Push en ny version for at begynde forfra.
• En kopi, der er afventende eller afvist, kan ikke gå i produktion og ignoreres af API'et, indtil den er godkendt.

Versioner, gendannelse og tilbagerulning

Versioner af en logik

Knappen Versioner på en logik åbner dens historik. En version gemmes automatisk, når den sidste ændring, der afventede godkendelse, er godkendt, før hvert push til en kunde eller til produktion og før hver gendannelse. Du kan også trykke på Gem en version nu (med en etiket som "før januar-takstopdateringen"). De seneste 15 gemmes; identiske tilstande gemmes ikke to gange.

• Sammenlign med nu viser, hvor mange regler der er tilføjet, fjernet eller ændret siden den version, med eksempler.
• Gendan lægger den pågældende versions tabeller tilbage som den aktuelle logik. En begrundelse er påkrævet; den skrives i ændringsloggen ("Version gendannet") og i aktivitetsloggen, og kunden får besked, hvis logikken er deres. Tilstanden før gendannelsen gemmes også som en version, så en gendannelse selv kan fortrydes. En låst logik kan ikke gendannes — lås den op først.
• En version, der blev gemt, da alt var godkendt, gendannes som godkendt. En version, der er gemt manuelt midt i en redigering, kræver stadig endnu et par øjne i ændringsloggen.

Rulle produktion tilbage

Hvert år på et kundekort gemmer de tre foregående versioner, der var live. Under Tidligere versioner trykker du på Gå tilbage til denne (to gange for at bekræfte). De offentlige sider skifter med det samme; den version, der var live, flyttes til historikken, så en tilbagerulning kan fortrydes på samme måde. En tilbagerulning registreres i udgivelsesnoterne, og kunden får besked.

Skriv en note under Hvad er ændret?, når du skubber i produktion; den vises under I produktion nu i kundens portal.

Brug, udgivelsesnoter og aktivitetslog

I kundeportalen viser kortet Brug, udgivelser og aktivitet for den kunde, du vælger (kunder ser kun deres egen):

• API-brug — forespørgsler, grupperede kontakter, kontakter med fejl og afviste forespørgsler for 7, 30 eller 90 dage, pr. dag, pr. API-nøgle og pr. logik. Tallene er tæt på, men ikke nøjagtige: to forespørgsler, der rammer i samme øjeblik, kan blive talt som én.
• Udgivelsesnoter — hvad der er live pr. år, og hvert push, hver tilbagerulning, godkendelse og gendannelse med sin note.
• Aktivitetslog (Helios-administratorer og kundeadministratorer) — hvem der har gjort hvad ved logikker, brugere, nøgler og sikkerhed ved logon, med den adresse, folk loggede ind fra. De seneste tre måneder vises; Eksportér gemmer dem som en CSV. Kunder ser alt, hvad der vedrører deres konto, herunder hvad Helios har gjort på deres vegne. Poster kan ikke redigeres eller slettes. En måned rummer højst 2.500 poster.

Sikkerhed: totrinslogon, IP-begrænsninger, automatisk logaf

Totrinslogon (autentificeringsapp)

Netlify Identity har ikke sin egen totrinslogon, så engine'en lægger en oven på: en 6-cifret kode fra en autentificeringsapp (Microsoft Authenticator, Google Authenticator, 1Password …). Den kontrolleres på serveren for hver forespørgsel og ikke kun på skærmen.

1. Tilføj miljøvariablen TWOFA_SECRET med en lang tilfældig streng (mindst 16 tegn; 40 er bedre) i Netlifys site-indstillinger. Uden den forbliver funktionen slået fra. Ændr den ikke senere: den beskytter de gemte hemmeligheder, og hvis den ændres, bliver alle, der har tilmeldt sig, låst ude.
2. Valgfrit: tilføj REQUIRE_2FA med værdien admins for at kræve, at Helios-administratorer og kundeadministratorer opsætter den, før de kan gøre andet.
3. Alle kan slå den til under Sikkerhed ved logon i kundeportalen. Portalen viser en nøgle, der skal skrives ind i appen (eller et link, der åbner den på en telefon), og otte engangs-gendannelseskoder — vist én gang og skal opbevares sikkert.

• Mistet telefon og gendannelseskoder: en Helios-administrator bruger Nulstil en persons totrinslogon på samme kort. Personen logger ind som normalt og opsætter den igen.
• Hvis alle Helios-administratorer er låst ude: åbn Netlify Identity, find kontoen og fjern rollen mfa. Totrinslogon er så slået fra for den konto.
• Hvis TWOFA_SECRET fjernes, mens konti har rollen mfa, afvises disse konti (fail closed). Sæt hemmeligheden tilbage, eller fjern rollen.
• Beviset for koden er gyldigt i 12 timer i den pågældende browser; hver kode kan kun bruges én gang.

Single sign-on (kundens egen identitetsudbyder, såsom Entra ID eller en regional logon) er ikke mulig med Netlify Identity, som det bruges her. Det kræver, at logon flyttes til en identitetsudbyder, der understøtter SAML eller OIDC; engine'ens roller og kunder kan tages med over. Planlæg det som et selvstændigt projekt.

Tilladte adresser for en API-nøgle

Når du opretter en nøgle, kan Tilladte adresser begrænse den til kundens servere: IPv4-adresser, IPv4-intervaller som 198.51.100.0/24 eller IPv6-adresser, adskilt af kommaer. Knappen Adresser på en nøgle ændrer listen senere. En forespørgsel fra en anden adresse får 403 ip_not_allowed. Lad feltet stå tomt for at tillade alle adresser. Kunder bag en skiftende adresse (mobilnet, nogle proxyer) bør ikke begrænses.

Automatisk logaf ved inaktivitet

Efter 45 minutter uden aktivitet i nogen åben fane bliver folk logget ud; to minutter før vises en besked med mulighed for at vælge Bliv logget ind.

Siden om databeskyttelse

Siden Databeskyttelse beskriver i almindeligt sprog, hvad der gemmes, hvor, og hvem der kan se det. Den er et udgangspunkt for en databehandleraftale, ikke selve aftalen; få den gennemgået af din juridiske rådgiver, og bekræft hostingregionen i Netlify, før du sender den til en kunde.

Hvad offentligheden ser

De to sider er den samme engine, hvor alle måder at ændre data på er fjernet. De har ingen logon, og intet linker til dem — alle, der kender adressen, kan åbne dem, så del kun adressen med kunden. Læg ikke fortrolige oplysninger i en logik, der pushes i produktion.

Ikke tilgængeligt på de offentlige sider: redigering af regler, etiketter, gruppekoder eller takster, ændringsloggen, import, eksport, logikker og gruppering fra filer.

Valideringstests

Enhver logik kan have et sæt valideringstests: testkontakter sammen med den DRG, hver af dem skal grupperes til (og om ønsket takst og trimpunkt). De er sikkerhedsnettet, før noget når en kunde.

• Tilføje tests. I Grouper grupperer du en kontakt og vælger Gem som valideringstest; eller du åbner Valideringstests på logikken i Library og importerer en CSV (download skabelonen dér). Op til 300 tests pr. logik.
• Køre dem. Kør validering grupperer hver test mod logikkens aktuelle regler og viser bestået eller fejlet pr. test. Download rapport gemmer resultatet som en CSV.
• Automatisk port. Når du pusher en logik til en kunde og når du pusher til en produktionsside, køres testene først. Hvis nogen fejler, stoppes pushet, og de fejlende tests listes. En Helios-administrator kan vælge at pushe alligevel; tilsidesættelsen registreres på valideringskørslen.
• Når en logik pushes eller duplikeres, følger dens tests med kopien, så kundens kopi kan gentestes efter senere ændringer.

Notifikationer, problemrapporter og kundebrugere

Klokken og knappen "Rapportér et problem"

Brugere, der er logget ind, ser en lille klokke og en Rapportér et problem-knap nederst til højre i portalen og engine'en. Klokken viser det, der er relevant for dem: en ny logik i deres bibliotek, en logik, der er gået i produktion, en godkendt eller afvist ændring, en API-nøgle, der snart udløber. Helios ser nye problemrapporter og nye invitationer.

En problemrapport indeholder beskrivelsen, siden, logikken og året, der var åbent, samt seneste fejl og mislykkede forespørgsler. Den indeholder aldrig patientdata. Helios-administratorer behandler dem under Problemrapporter i Helios-sektionen af kundeportalen (markér som løst, genåbn).

Kundebrugere

Under Jeres team i portalen kan en kundes administrator invitere kolleger, gøre nogen til administrator eller fjerne adgang. En Helios-administrator ser det samme kort med en kundevælger. Den første administrator hos hver kunde skal have rollen portal-admin af en Helios-administrator i Netlify Identity (ud over grouper og customer-<name>); derefter administrerer kunden selv sine brugere. Der skal altid være én administrator tilbage, og ingen kan fjerne sin egen adgang.

Valgfri e-mail

Notifikationer vises altid i klokken. For også at sende e-mail skal du angive RESEND_API_KEY og NOTIFY_FROM (en verificeret afsenderadresse) som miljøvariabler på sitet; angiv REPORT_TO for også at modtage problemrapporter på e-mail. Uden dem sendes der ikke noget, og intet går i stykker.

Roller hos en kunde

Hver kundebruger har ét af fire niveauer: Skrivebeskyttet, Redaktør, Godkender eller Administrator (se Hvem kan hvad). En kundes administrator sætter dem under Jeres team i kundeportalen: vælg niveauet, når du inviterer nogen, eller ændr det bagefter i rullelisten ved siden af personen. En Helios-administrator kan gøre det samme for enhver kunde.

• En konto, der fandtes, før denne funktion kom, har ingen af disse roller og regnes som Godkender, hvilket er alt, den kunne før (brugeradministration er fortsat forbeholdt administratorerne). Der fjernes intet; sæt en person til Redaktør eller Skrivebeskyttet for at begrænse vedkommende.
• Hav mindst to personer hos hver kunde på niveauet Godkender (eller administrator): ingen kan godkende sin egen ændring, så en enkelt godkender kan ikke godkende sit eget arbejde. Den, der er inviteret som Redaktør, kan ikke acceptere en pushet logik eller godkende en ændring.
• En skrivebeskyttet bruger ser kun panelerne Grouper og Atlas. Hvis de prøver noget andet, svarer serveren insufficient_role, og skærmen siger, at deres rolle ikke tillader det.
• Hver ændring af niveau skrives i aktivitetsloggen.

Massegruppering

Til store filer grupperer Massegruppering (under Grouper, under Gruppér fra filer) op til ca. 20.000 kontakter på serveren, så ingen behøver holde en browser åben.

• Brugeren vælger en logik, uploader en Excel-projektmappe (samme Stam / Diag / Proc / Forl-layout som i Gruppér fra filer, hvor forløb grupperes efter løkkemetoden) eller en CSV med én kontakt pr. række (der kan downloades en skabelon) og trykker på Upload og start.
• Jobbet viser sin fremdrift; når det er klart, får den, der startede det, en e-mail (hvis e-mail er sat op) og en notifikation, og resultatet kan downloades som Excel eller CSV. Åbn siden igen når som helst — jobbene er listet dér.
• Et gemt job kan gentages hver uge eller måned mod logikken, som den er på det tidspunkt. Gentagelsen startes af den daglige planlagte funktion; den kræver JOBS_SECRET (en vilkårlig lang tilfældig tekst) i sitets miljøindstillinger, eller ellers TWOFA_SECRET, som bruges, hvis den er angivet. Uden nogen af dem starter gentagelser ikke.
• En gentagelse eller kørsel bruger kun en logik, hvis kunden har godkendt den, og den har sine tabeller — ellers fejler jobbet med en tydelig årsag, og personen får besked.
• Kun redaktører og derover kan oprette job; skrivebeskyttede brugere kan downloade resultater. En kunde ser kun sine egne job, Helios ser alle.
• Grænser: 50.000 poster pr. job (et forløb tæller én gang pr. kontakt), 20 gemte job pr. kunde.
• Data: den uploadede fil gemmes kun som kodede felter (diagnoser, procedurer, alder, køn og kontaktkoderne samt kundens eget kontaktnummer) sammen med resultatet. Et job, der ikke gentages, slettes automatisk 30 dage efter, det er afsluttet; et gentagende job beholdes, indtil nogen sletter det. Fortæl det til kunderne — se siden om databeskyttelse.

Tjeklisten Kom i gang

Kundebrugere ser et Kom i gang-kort øverst i kundeportalen: godkend logikken, gruppér en testkontakt, få en API-nøgle, send en første API-forespørgsel og (valgfrit) prøv en hel fil og se det live site. Afkrydsningerne kommer fra det, der rent faktisk er sket, så ingen behøver at krydse noget af. Hver kunde kan skjule kortet og vise det igen.

Kortet linker også til to eksempelfiler, sample-contacts.xlsx og sample-contacts.csv, til at prøve Gruppér fra filer og Massegruppering. Koderne i dem er eksempler; tjek resultaterne mod din egen logik, før du viser dem til en kunde.

Advarsler og statussiden

Advarsler

• Fejltop. Når en kundes fejl for dagen overstiger 20 og udgør mindst 20 % af det, der er sendt, får kundens klokke en besked, og det får Helios' klokke også (og en e-mail, hvis e-mail er sat op). Højst én pr. dag pr. kunde. Ændr grænserne med ALERT_MIN_ERRORS og ALERT_ERROR_RATE (for eksempel 0.3 for 30 %).
• Nøgle udløber snart. Kunder ser det allerede i klokken. Derudover sendes en e-mail til kundens brugere, når en nøgle har 14 dage tilbage og igen ved 3 dage, og Helios får en besked.
• Disse kører fra den daglige planlagte funktion og fra selve API'et, så de virker kun på det live site.

Statussiden

status.html er offentlig. Hver time spørger sitet sit eget grupperings-API (/api/v1/health) og portalsiden, om de svarer, og gemmer resultatet pr. dag. Siden viser, om hver af dem er oppe lige nu, oppetid for de seneste 90 dage med én bjælke pr. dag og seneste hændelser. Den indeholder ingen kundedata. Hvis tjekkene stopper i mere end 90 minutter, siger siden ukendt i stedet for i drift. Helios får en besked, når noget holder op med at svare.

Siden linkes fra sidefoden på alle sider. Tjekkene er Netlify-planlagte funktioner, som kun kører på det udgivne (produktions-)deploy.

Support af en kunde

• "Hvilken logik bruger min nøgle?" Hvis ingen logik er nævnt i forespørgslen, den, der er aktiv i Library. Resultatet af hvert kald indeholder logikkens id, navn og år.
• "Resultaterne er ændret." En ny logik er sat som API-standard, eller en rettelse af API-standardlogikken er blevet godkendt. Kunder, der har brug for stabile resultater, bør angive et logik-id i deres forespørgsler eller få deres nøgle begrænset til én logik.
• Rettelser når API'et inden for ca. et minut (logikker caches kortvarigt). Produktionssider ændres kun, når du pusher.
• Grænser: 500 kontakter pr. forespørgsel, 100 koder pr. liste. Større filer sendes i flere forespørgsler.
• Kontakter, der sendes via API'et, gemmes ikke; kun nøglens tidspunkt for sidst brugt registreres.

Fejlfinding

Staging-site og automatiske tjek

Prøv ændringer af, før de når kunderne.

• Automatiske tjek. Hvert deploy kører først npm test (build-kommandoen i netlify.toml). Hvis et tjek fejler, udgiver Netlify ikke det deploy, og det live site forbliver, som det var. GitHub kører de samme tjek på hver pull request (.github/workflows/test.yml).
• En staging-kopi. Opret en branch med navnet staging i GitHub, og aktivér Branch deploys for den i Netlify (Site configuration → Build & deploy). Den får sin egen adresse, som staging--heliosgroup.netlify.app. Pull requests får på samme måde et deploy preview.
• Adskilte data. Et staging- eller preview-deploy bruger sit eget lager (grouper-branch-deploy, grouper-deploy-preview), så intet, der gøres dér, rører de live logikker, nøgler eller kunder. Det starter tomt: importér en logik eller to til at teste med. En banner øverst siger Testmiljø.
• Indstillinger. Miljøvariablerne skal være tilgængelige for kontekstene Branch deploys og Deploy Previews, ikke kun Production (Site configuration → Environment variables). Brug andre værdier til TWOFA_SECRET og til Resend-indstillingerne, hvis du ikke vil have testmails sendt ud. Planlagte tjek og massegentagelser kører ikke på staging.
• Flytte en ændring til det live site. Flet branchen ind i hovedbranchen; buildet kører tjekkene igen, før der udgives.

Førstegangsopsætning

1. Deploy sitet med API- og produktionsfunktionerne og den opdaterede netlify.toml. Omdirigeringerne /api/v1/* og /<customer>/flow, /<customer>/group findes først efter det deploy.
2. Tjek https://heliosgroup.dk/api/v1/health i en browser; den skal svare {"ok":true,"apiVersion":"1"}.
3. Sørg for, at en logik er sat som API-standard og har sine takstdata, opret derefter den første nøgle, og test den med curl-eksemplet i kundevejledningen.
4. Tilføj den første kunde, push en logik, og åbn begge kundesider i et privat browservindue (uden at være logget ind) for at bekræfte, at de virker for offentligheden.