AHV/AVS/NSS in one field: the Swiss healthcare ID problem

Switzerland has one social security number. It has three names — AHV in German, AVS in French, NSS in Italian — and it shows up in healthcare data under all three, sometimes on the same file. It is also formatted as an EAN-13, which means it looks like a product barcode to anything that does not know better.

A naive import treats AHV, AVS, and NSS as three columns. The downstream code then deduplicates patients by matching against all three. That works until a French-speaking clinic ships a German-speaking file (or vice versa) and the columns swap.

One field, three hints

AdaptivMapr resolves AHV / AVS / NSS to a single logical field on the patient_demographics template. The hint list includes:

["AHV", "AHV-Nr", "AHVN13", "Sozialversicherungsnummer",
 "AVS", "no AVS", "numero AVS",
 "NSS", "numero NSS"]

plus the English-language fallback "Swiss SSN". The heuristic layer normalises both the incoming header and the hint list and matches deterministically. The cascade does not need the LLM for this one.

The validator

Validation is two layers. First, the surface shape — 13 digits, optionally formatted as 756.1234.5678.97 with dots:

/^756[.\s]?\d{4}[.\s]?\d{4}[.\s]?\d{2}$/

Second, the EAN-13 check digit. Switzerland uses GS1 prefix 756, and the last digit is a checksum computed across the first twelve. The validator rejects rows where the checksum does not match — that catches typos that pass the format check but would land in production as bogus identifiers.

Why not three fields

A common design choice is to model AHV, AVS, and NSS as three separate identifier columns and let downstream code pick whichever is populated. That doubles the schema surface area for no compliance or interop benefit — they really are the same number — and it creates a class of bugs where the same patient appears twice because the French file and the German file landed on different columns.

The FHIR emit on this field uses identifier.system = "urn:oid:2.16.756.5.32" regardless of which language the column header was in. That is what every downstream FHIR server expects, and it is what deduplication should key on.

What this does not solve

Some legacy files carry the AHV without the GS1 prefix — 1234.5678.97 on its own. The validator will not accept that; it is ambiguous. The cascade flags those rows for human review rather than guessing a prefix. That is the right default for a healthcare identifier: a false-positive AHV is worse than a delayed import.

See the patient_demographics template for the full field definition, including the multilingual hints and the FHIR Patient emit. Or jump to the dashboard to test against the anonymised Swiss fixture.