Absence reporting (SIVI)
Sympa to the absence insurer via SIVI: approved absence of the Dutch employer
With an integration between Sympa and the absence insurer, approved sickness of employees at the Dutch employer in Sympa goes to the insurer automatically, as a SIVI employer-to-insurer message. For this KoppelHet reads a dedicated API interface in Sympa holding only the fields the insurer needs.
What the integration does
Organisations that use Sympa as HR system and have insured the sickness risk for their Dutch employer now enter sick employees by hand in the insurer's portal. Sympa is often used across Northern Europe, and only the Dutch employees belong to the policy.
- Your Sympa administrator creates an API interface with employee, employer and the absence table; we supply the field list.
- Every hour KoppelHet fetches the changed absence rows of the Dutch employer.
- An approved row of a sickness type becomes a new or changed report.
- If a reported row is declined, it becomes a cancelled report.
- Per agreed period all reports go to the insurer together.
What to watch for with Sympa and Verzuimverzekeraar (SIVI)
- Sympa only delivers through the API what the administrator has put in an interface. For the insurer that is employer, dates, extent, type and approval. Explanations are not in the interface and can therefore not reach the insurer by accident.
- The approval of a table row in Sympa is a number, with five for approved and four for declined. KoppelHet only reports rows with five. If a reported row switches to four, a cancelled report goes to the insurer in the next period.
- By default Sympa allows one hundred requests per hour per interface, reading and writing combined. One run per hour with large pages stays well below that. For an insurer that receives reports per period, an hour of delay is no problem.
- Sympa answers read queries from a reporting database that can lag up to half an hour. The integration therefore also requests the rows of the previous hour on every run, so a late approval still goes along in the right period.
- A filter on the absence table in Sympa still returns all employees, only with fewer rows. KoppelHet therefore first filters the employees on the Dutch employer, so no absence of colleagues in Finland or Sweden ends up under the Dutch policy.
- With since and until Sympa finds rows that are valid in a window, even if they began long before. That way KoppelHet compares all ongoing sickness with what was reported to the insurer once a week, also for long-term absence that has been running for months.
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
Who creates the API interface in Sympa?
Your Sympa administrator, in the API panel. We supply the list of fields.
Can the same interface also serve the health service?
Yes, if the fields for both are in the interface. The hundred requests per hour then apply to both integrations together.
Does the explanation on the absence go along?
No. It is not in the interface and stays in Sympa.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Sympa Integration API (OData v4 subset) on a dedicated interface under https://api.sympahr.net/api, with X-ApiKey or basic authentication. Reading with $filter (eq, gt, ge, and, or; no in) on the employer, $expand on the absence table with a filter on modified and Approval, $top and $skip, and since/until for validity (requires effectivity settings). Approval per table row as a number (3 WaitingApproval, 4 Declined, 5 Approved). By default 100 requests per hour per interface; reporting database up to 30 minutes behind.
- Message Verzuimmeldingen from employer to insurer (XML, targetNamespace VerzuimmeldingenWerkgeverVerzekeraar, file name prefixed WV-), processing codes 01 new, 02 changed, 03 cancelled, 04 for information and 05 correction, cause codes 10, 11 and 99. Transport to be agreed per insurer.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Sympa | Field in Verzuimverzekeraar (SIVI) | Notes |
|---|---|---|
Werkgever op de medewerkerskaart (via tabel) | Werkgever: loonheffingennummer | |
Unieke sleutel van de datakaart | Identificatie werknemer | No citizen service number |
Rij-id van de afwezigheidsregel | Verzuimgeval identificatie | |
Begindatum van de regel | Datum eerste verzuimdag | |
Omvang van de afwezigheid | Percentage verzuim | |
Einddatum + 1 dag | Datum hersteld en Einde verzuim J/N | |
Approval 4 (Declined) na melding | Verwerkingscode 03 vervallen |
Related
Greenhouse → Sympa
Greenhouse to Sympa integration: hired candidate as a data card with contract row in Sympa
Recruitee → Sympa
Recruitee to Sympa integration: hired candidates as a data card in Sympa
SmartRecruiters → Sympa
SmartRecruiters to Sympa integration: ready to onboard becomes a data card in Sympa
Sympa → 4PS Construct
Sympa to 4PS Construct integration: fitters of the Dutch employer from Sympa in 4PS, with cost centre as a dimension