ASAbsence reporting (SIVI)
Nmbrs to occupational health service via SIVI: sick, partly recovered and recovered per Nmbrs company
With an integration between Nmbrs and the occupational health service, sick notifications, partial recovery and recovery from Nmbrs go to the health service automatically, in the SIVI format health services use, per company in your Nmbrs environment. Payroll reports absence only once, and a notification the health service rejects is noticed straight away.
What the integration does
Organisations that run the payroll of one or more companies in Nmbrs and have a health service that receives SIVI notifications record absence in Nmbrs for continued pay and then type it into the health service portal again. Without an integration a partial recovery sometimes arrives there days later, and the health service plans a consultation for someone already working half days.
- Payroll or HR records a sick notification in Nmbrs, at the company where the employee is employed.
- KoppelHet fetches the notification and looks up that company's employer identifiers at the health service.
- The health service receives the sick notification in the SIVI format, with department and an absence number that stays the same for every following notification.
- A partial recovery in Nmbrs is sent as a change of the percentage, with the effective date. A recovery closes the absence case with the recovery date.
- The health service's confirmation shows in the KoppelHet platform; a rejected notification becomes a task for HR.
What to watch for with Nmbrs and Arbodienst (SIVI)
- One Nmbrs environment often holds several companies, each a separate employer. The health service issues its own identifiers per employer. KoppelHet sends every notification under the identifiers of the employee's Nmbrs company, so absence does not end up at the wrong operating company.
- Nmbrs records partial recovery and full recovery as separate messages on an existing absence notification. KoppelHet turns a partial recovery into a SIVI change with the effective date, and a recovery into a notification with the recovery date, so the health service sees the half working days on time.
- In Nmbrs every absence notification belongs to a file, and HR chooses on entry whether it is a new file. KoppelHet uses the file number as the fixed number of the absence case at the health service. A relapse that HR puts in the same file thus stays one case at the health service too.
- The absence notification in Nmbrs has no field for the safety net scheme or for pregnancy-related sickness, while SIVI requires the safety net. KoppelHet derives the safety net from an attribute you record in Nmbrs, for example a custom field on the employee, and holds the notification if it is missing.
- An absence notification in Nmbrs has a free comment field. It sometimes holds more than the health service may know. KoppelHet never sends that comment; the SIVI notification only contains dates, percentages and codes, without a diagnosis.
- Nmbrs stops its older SOAP interface on 1 March 2027, which currently has the most complete absence functions. KoppelHet reads absence through the Nmbrs REST API where it provides the same, so notifications to the health service do not stop on that date.
- If the start date of an absence is changed afterwards in Nmbrs, it goes to the health service as a correction, including the old date. A new percentage from a date, on the other hand, is an ordinary change.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Does medical data go to the health service?
No. Only dates, percentages and codes. The comment on an absence notification in Nmbrs is not sent.
Do all our companies need the same health service?
No. Per Nmbrs company we record which health service receives the notifications and with which identifiers.
Which SIVI version do you use?
We agree it with the health service. SIVI releases a new version every year, and between two parties all notifications use the same version.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Nmbrs is read through the Nmbrs REST API (absences per employee under /employees/{employeeId}/absences) with OAuth 2.0 and read-only scopes, per company. Where it does not yet provide everything, through the SOAP EmployeeService (Absence_GetAll_AllEmployeesByCompany and Absence_GetList, Netherlands only; Absence with Start, Percentage, Dossier, Dossiernr and Comment; partial recovery and recovery as separate messages with StartDate and Percent or Lastdayabsence). The SOAP API stops on 1 March 2027.
- The message is Verzuimmeldingen from the SIVI absence standard for employers and health services, with processing code new, changed or correction, validated against the XML schema of the agreed version. Employer identification and data exchange connection number per Nmbrs company. Vangnet J/N and organisational unit are mandatory. Transport under the SIVI 2025 interface specification - REST endpoint at the health service, XML in Base64 inside JSON, OAuth 2.0 - with a return and processing message back.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Nmbrs | Field in Arbodienst (SIVI) | Notes |
|---|---|---|
Personeelsnummer | Identificatie werknemer | No citizen service number |
Dienstverband | Identificatie dienstverband | |
Dossiernummer verzuim | Verzuimgeval identificatie | Stays the same for every recovery message in the same file |
Startdatum verzuim | Datum eerste verzuimdag | |
Percentage | Percentage verzuim | |
Gedeeltelijk herstel (startdatum en percentage) | Ingangsdatum mutatie verzuim en nieuw percentage | |
Herstel (laatste verzuimdag) | Datum hersteld en Einde verzuim J/N | |
Afdeling | Organisatie-eenheid, code | |
Bedrijf in Nmbrs | Werkgeverskenmerk en aansluitnummer | Issued per company by the health service |
Related
ADP Workforce Now → Nmbrs
ADP Workforce Now to Nmbrs integration: the Dutch payroll group from ADP in the right Nmbrs company
AlexisHR → Nmbrs
AlexisHR (Simployer One) to Nmbrs integration: Dutch employees into payroll
BambooHR → Nmbrs
BambooHR to Nmbrs integration: Dutch payroll next to a global HR system
Bullhorn → Nmbrs
Bullhorn to Nmbrs integration: placements with hourly pay and end date in payroll