Data science consultancy in Utrecht

It builds models that predict an outcome or support a decision in individual cases: will this patient be admitted, will this customer leave, is this candidate a good fit for this job opening? Much of the work lies in determining what data is available when the decision is made, validating the model and embedding it in day-to-day work.

These models are part of the AI applications we build. Our office is in Amsterdam; in Utrecht, we work on site or online. For Rotterdam, see data science agency Rotterdam.

St. Antonius has emergency departments in Utrecht and Nieuwegein. According to the case study, pressure on the emergency department affects care, workloads and patient satisfaction. The aim was to improve patient flow by starting the admission process earlier.

As part of the hospital’s AI team, we developed an algorithm to help doctors decide whether a patient can go home or needs to be admitted. When wards hear about a possible admission in time, they can start preparing earlier. Read the case study.

Internal validation tests the model on data from the same source as the training data. External validation uses data that was not used in development, such as data from a later period or another location. You assess how well the model distinguishes between cases (does it assign higher probabilities to the right cases?), its calibration (are those probabilities accurate?) and its performance across subgroups.

Only then do you know whether the model also works for your patients or customers.

The Guideline for Quality Diagnostic and Prognostic AI Applications in Healthcare distinguishes six phases: collecting and managing data, developing the algorithm, validating it, developing the software, testing its added value in practice and implementing it. The website leidraad-ai.nl is registered to UMC Utrecht.

One requirement in phase 2 is to define the intended use: in what context, by whom and at what point the model will be used. After implementation, its outcomes should be monitored in practice. The guideline has no legal status.

Data leakage means the model uses information during training that would not yet be available when the decision is made. This could be a lab result entered into the system later, or a field completed only after admission. The model then scores very well in testing, but not in practice.

That is why we first establish when each piece of information appears in the electronic health record, CRM or case file, and build the training set based on that timing.

Yes. Attrition, claims, payment arrears and suitable matches are also outcomes for individual customers or cases. For Olympia, we built a classification model to match candidates and job openings more efficiently.

Bear in mind the AI Act: Annex III includes AI used to recruit and select people, and to assess risk and set prices for life and health insurance. Your legal or compliance team determines whether your model falls within its scope; we help identify the relevant requirements. Read more about data and AI for insurers.

It can. Under Rule 11 of the MDR, software that provides information for diagnostic or therapeutic decisions is classified as class IIa or higher.

Annex III of the AI Act also covers systems used to triage patients in emergency healthcare. Exactly when those obligations take effect depends on European decisions about a possible postponement; check the latest position.

Your regulatory, legal or compliance team determines whether your model falls within their scope. We help identify the relevant requirements. See the AI Act.

When an established score, a fixed rule or good reporting already supports the decision well enough, or when the outcome is not recorded anywhere. If you first want to know where AI would be worthwhile in your organisation, start with AI consultant Utrecht.

For AI that we build and manage in day-to-day operations, see AI agency Utrecht. If your data is still spread across separate systems, start with data engineering in Utrecht.