AI architecture for data extraction in OPAN^®

Through OPAN^® pass 97,000 registrations a year. Many of the details needed for them already exist somewhere: in the discharge report, on the prescription, in the hospital’s system. Until now, someone typed them in. That takes time and produces errors that only come to light when care has long since started.

Since summer 2026, OPAN^® has offered data extraction that can be switched on; we call it Smart-Extrakt. Once it is switched on, the person submitting decides for each registration whether to use it: they upload the discharge report, for example, and start the extraction. It reads the document, recognises the details needed for the registration and transfers them into the matching fields of the form.

This raises data quality twice over. Details come straight from the source instead of from the keyboard. And whatever is missing in the document shows up in the form as a gap before the registration goes to the care provider.

Suggestions, not automation

Control stays with the person submitting at two points: when triggering and when approving. Extracted values are suggestions. They appear in the form, are checked, corrected if necessary and only then approved. Each suggestion can be accepted or rejected individually, and whatever was accepted is recorded in the log. No field is overwritten automatically. The processing takes work off people’s hands, not responsibility.

Organisations activate the feature themselves. Those who don’t want it work as before. With health data, a wrongly accepted date of birth is not a cosmetic flaw, hence this restraint.

Play video: Smart-Extrakt in the sidebar

One pipeline per input format

It does not start with a model, but with a split by where the data comes from. Documents that are uploaded or transmitted via API go into the document processor; screenshots first pass through the image processor. Structured deliveries from UPI, API and FHIR are taken in by the JSON processor. For referrers with their own field schema, a custom mapper is added.

This separation is intentional. A screenshot needs image processing, an FHIR bundle does not. Sending both through the same processing loses either precision in the structured case or robustness in the unstructured one.

The data superset

All pipelines lead into the same step: extraction against defined schemas and rules, carried out by interchangeable models and agents. Internally, we call the result the data superset, the most structured state of a case.

The domain logic lies in the schemas and rules, not in the model. Which details a Spitex registration needs and which a rehabilitation request needs is care-specific knowledge and does not belong in model weights. That way we can swap a model for a better one without rewriting the extraction rules.

Then there are services that enrich details and check them for plausibility: VEKA queries, HIN directories, geocoordinates, the normalisation of addresses and designations. Part of the data quality does not come from language models, but from comparison with reliable registers.

What builds on the structured case

A structured case makes it possible to build functions that do not run reliably on free text. In development are the AI case summary, a plausibility and completeness check before submission, a case chat, document translations and AI-supported analyses. We are rolling them out step by step, some of them in a beta phase with selected clients.

The second route matters more than it seems: care providers can retrieve the structured data via the API and process it further in their own environment. Those who run AI themselves, for triage, reporting or pre-filling in their own system, get a clean data basis instead of yet another interface. OPAN^® does not have to be the place where every AI process takes place.

Dedicated hardware in Switzerland

We run the AI processing on dedicated high-performance hardware, including GPUs, in Switzerland, with locally hosted language models that do not send any data to the internet of their own accord. That is a data protection decision before it is a technical one. A registration contains sensitive personal data. If it goes to an external model provider, data processing on behalf, place of processing and purpose limitation depend on that provider’s terms. Then there is the organisational framework: operations run in the same ISO/IEC 27001 certified environment as our platforms.

The price of this decision is effort. We develop pipelines, extraction schemas and operations ourselves; we do not use a ready-made AI suite. In return, we align the processing with the referral process instead of a general use case, and we decide ourselves which model is used when. The AI in the stack page shows which other AI features the stack contains.

Data extraction in practice

The processing becomes particularly robust when both routes come together. Via the interface, the master data from the hospital information system reaches the form. From the accompanying documents, the extraction adds the context, that is, the details on history and needs for which there is no interface field, and puts them in the designated fields.

Where the two sources overlap, the same details are checked twice. Where the interface delivers nothing, the document fills the gap.