Minor liability claims at a hospital: sorting files with AI hosted in Switzerland

In brief. A hospital can noticeably reduce the effort of handling its minor liability claims ("bagatelle" claims) by giving an AI model a single task: read each incoming file and place it in one of two queues. On one side, the files that meet all the conditions the hospital has set for automatic settlement. On the other, the few files that need a human eye. The model does not decide the rules or the amounts; it applies a grid written by the institution, and anything doubtful goes to a claims handler. Because these files contain patient data, an open-source model hosted in Switzerland is the easiest choice to defend here.

This article describes an illustrative scenario, representative of the sorting projects we carry out. It is not a named client and we give no quantified results: the figures that matter are those your own pilot will produce.

What we are talking about: minor liability claims

In this scenario, some of the liability claims addressed to the hospital do not concern medical errors but small material damages: a dental prosthesis mislaid during a transfer, broken glasses, a lost hearing aid, a damaged piece of clothing, a phone that disappeared from a bedside table. The amounts are small. Depending on the institution's liability insurance contract, they may be below the deductible, and the hospital then settles them itself.

Taken one by one, these files are simple. Taken together, they can keep the legal or insurance department busy beyond their financial importance: the request has to be read, the stay checked, the missing document requested, the relevant department chased, a reply drafted. The cost of handling can exceed the amount claimed, and the serious files wait in the meantime. The share of files and time concerned is measured during the pilot.

The process before and after

Before. Each request arrives by post, by email or through a form. A claims handler opens a file, enters the information, checks the documents, questions the care unit, assesses liability, decides and replies. The same route applies to a pair of glasses and to a complex claim.

After. The route splits in two from the moment of entry.

1. The request is scanned and linked to a stay.
2. The model extracts the useful elements: nature of the damage, item, amount claimed, date, unit, attachments.
3. It checks each criterion of the hospital's grid and produces a reasoned sorting proposal.
4. If all criteria are met, the file goes to the "automatic settlement" queue: payment is prepared according to the hospital's scale and the reply letter is generated.
5. In all other cases, the file goes to the "human review" queue, with the model's summary and the reason for the referral.

The claims handler does not disappear. They stop handling files with little at stake and spend their time on those that matter.

The rules and thresholds belong to the hospital

This is the central point of the project. The model does not say what is fair: it checks whether a file falls within a framework that management, the legal department and the insurer have defined in writing. A typical grid looks like this:

Three principles complete the grid. First, a single unmet criterion is enough to send the file to a person. Second, the model never issues a refusal: a request that cannot be paid automatically is examined by a person, not rejected by a machine. Finally, the thresholds are set in a configuration file that the hospital controls, not in the model. Changing them requires no retraining.

Human in the loop, in practice

Human control is not limited to the review queue. In a well-designed project, you will find:

• sample checks of the automatic queue, at a frequency set by the hospital, to verify that the files paid deserved to be;
• a right of recall: any claims handler can pull a file out of the automatic queue before payment;
• a named business owner, who validates every change to a rule or threshold;
• an emergency stop: the automatic queue can be suspended at any time, and all files then return to manual handling.

Audit trail and explainability

Every sorting decision must be reconstructable months later. For each file, the system keeps the version of the grid applied, the model version, the extracted elements, the result criterion by criterion, the queue selected and, where relevant, the intervention of a claims handler.

The explanation provided is not an opaque line of reasoning. It is a list: "amount below threshold: yes; material damage only: yes; invoice present: yes; first request: yes". An internal auditor, the insurer or the patient can understand it.

Errors: which ones, and who bears them

A model sometimes makes mistakes. This must be said from the start, and it must be decided who bears each type of error.

• File paid automatically when it should have been reviewed. The cost is capped by the amount threshold, which the hospital chose knowingly. The institution bears it. Sample checks serve to measure how often this happens.
• File sent to review when it could have been paid. The cost is claims handler time. This is the least serious error, and the system is tuned to prefer it.
• Undetected bodily harm. This is the error to avoid above all. It is handled through strict rules: certain words, certain documents (a medical certificate, for example) or certain departments trigger an automatic referral to review, whatever the model's opinion.

The patient, for their part, must never bear a system error: in case of doubt, their file is read by a person.

Medical secrecy and data protection

These files contain patient data. A few reference points, to be validated by your legal department and your data protection officer:

• Professional secrecy. Art. 321 of the Swiss Criminal Code covers in particular doctors, nurses and other health professionals, and their auxiliaries. Disclosure is not punishable if it is made with the consent of the person concerned or with the written authorisation of the superior authority or supervisory authority. The status of a technical provider who could access the files must therefore be examined before the project, and the most prudent architecture is one where it does not have access.
• Sensitive data. The Federal Act on Data Protection (FADP) classes health data as sensitive personal data (art. 5, let. c). It applies to private persons and federal bodies (art. 2): a private clinic is subject to it, whereas a cantonal public hospital is in principle governed by cantonal data protection law. The applicable regime must be checked for each institution.
• Automated decision. Art. 21 FADP requires the person concerned to be informed when a decision is taken exclusively by automated means and has legal effects on them or significantly affects them; the person may ask for the decision to be reviewed by a natural person. The law provides exceptions, notably where the decision is directly related to the conclusion or performance of a contract and the person's request is granted. The scheme described here limits automation to cases where the request is accepted, but its legal characterisation remains to be confirmed case by case.
• Impact assessment. Art. 22 FADP calls for a prior impact assessment where processing is likely to result in a high risk, and cites large-scale processing of sensitive data. The Federal Data Protection and Information Commissioner (FDPIC) points out that the FADP applies directly to processing that uses AI.
• Subcontracting. Art. 9 FADP allows subcontracting if a contract or the law provides for it and, among other conditions, if no legal or contractual duty of confidentiality prohibits it.

Why an open-source model hosted in Switzerland suits this case

The task is narrow: read a short file, extract a few elements, check a list of criteria. It does not require the most powerful model on the market. A medium-sized open-source model, such as those in the Llama, Mistral, Qwen or Gemma families, can be enough, provided it is verified on your own files.

The benefit lies elsewhere. The model runs on the hospital's servers or in a data centre in Switzerland. The files are not sent to any model vendor. Access is limited to named people. The logs stay within the institution. Questions of disclosure abroad (art. 16 FADP) and of disclosure to a third party then arise much less. The cost also becomes predictable, since it does not depend on the number of files processed.

We detail this choice in our decision guide on open-source models hosted in Switzerland.

How a pilot runs and is measured

A pilot is carried out in three stages.

1. Test on historical data. The model sorts files that are already closed, and its sorting is compared with the decisions actually taken. No patient is affected.
2. Parallel operation. The model sorts the new files, but the claims handlers continue to handle everything. The two are compared.
3. Limited automation. The automatic queue is opened with a low threshold and reinforced sample checks, then widened in stages if the results allow.

The indicators are set before the start:

We do not give expected results: they depend on the quality of the files, the thresholds chosen and the organisation. A pilot exists precisely to establish them.

Limits: when not to automate

• As soon as there is harm to health, even minor.
• When liability is disputed or the facts are not established.
• When the rule cannot be written down: if two experienced claims handlers decide differently on the same file, the practice must be clarified first.
• When volumes are too low to justify the project.
• When nobody is designated to own the rules and monitor the errors.

Frequently asked questions

Does the model decide on payment? No. It checks whether a file meets the conditions set by the hospital. The amount follows the institution's scale, and any file that falls outside the framework is handled by a person.

Can a US AI service be used for this case? Technically yes, but it raises questions about professional secrecy and disclosure of data abroad that hosting in Switzerland largely avoids. It is for your legal department to judge.

Do we need to train the model on our files? In general no. The grid of criteria and a few examples are enough to start. Further tuning is justified only if the pilot shows a specific limitation.

What happens if the system goes down? All files return to manual handling. The existing process remains the fallback.

How long does a pilot last? It depends on the volume of files and the availability of the teams. The duration is set with you during scoping, based on the number of files needed to measure something reliable.

Going further

The same scheme applies to other fields: sorting small claims at an insurer, sorting invoices and expense reports at a fiduciary firm or sorting KYC files and alerts.

Do you have a process of this kind? Our AI consulting starts with a discovery workshop. Contact us to talk about it.

References

• Swiss Criminal Code, art. 321 (professional secrecy) – Fedlex
• Federal Act on Data Protection (FADP) – Fedlex
• AI and data protection – Federal Data Protection and Information Commissioner (FDPIC)