Sympa logoVS

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.

  1. Your Sympa administrator creates an API interface with employee, employer and the absence table; we supply the field list.
  2. Every hour KoppelHet fetches the changed absence rows of the Dutch employer.
  3. An approved row of a sickness type becomes a new or changed report.
  4. If a reported row is declined, it becomes a cancelled report.
  5. Per agreed period all reports go to the insurer together.
Sympa → KoppelHet → Verzuimverzekeraar (SIVI)SOURCESympaTARGETVerzuimverzekeraar (SIVI)Verzuimverzekeraar (SIVI)KoppelHetmapping · logging · monitoringSympa → KoppelHet → Verzuimverzekeraar (SIVI)SOURCESympaTARGETVerzuimverzekeraar (SIVI)Verzuimverzekeraar (SIVI)KoppelHetmapping · logging · monitoring
Out: Absence rows of a sickness type · Approval status per row · Employer with payroll tax number of the policy · Extent of the absence as percentage · Cancelled report after decline

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, architecture and compliance

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.

Price indication · Basic

Leave your work email and you see the price indication right away.

We only use your address to follow up on your question about this integration.

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 SympaField in Verzuimverzekeraar (SIVI)Notes
Werkgever op de medewerkerskaart (via tabel)Werkgever: loonheffingennummer
Unieke sleutel van de datakaartIdentificatie werknemerNo citizen service number
Rij-id van de afwezigheidsregelVerzuimgeval identificatie
Begindatum van de regelDatum eerste verzuimdag
Omvang van de afwezigheidPercentage verzuim
Einddatum + 1 dagDatum hersteld en Einde verzuim J/N
Approval 4 (Declined) na meldingVerwerkingscode 03 vervallen

Related

Which systems do you want to connect?

Tell us which systems you use and what should happen automatically. Together we define the smallest working solution, with a clear design and a quote before building.