Sector · Healthcare & Life Sciences

AI in healthcare. Responsibly built, clinically useful.

We build AI applications for hospitals, mental health organisations, health insurers and health-tech start-ups. No black-box demos, but workflow AI, administrative AI and EHR integrations that respect strict healthcare compliance and hold up in practice.

SettingHospitals & university medical centres

SettingMental health & long-term care

SettingPrimary care

SettingHealth-tech & insurers

Schedule an exploratory conversation Our healthcare software service

The Dutch healthcare sector in numbers.

~70

General and academic hospitals

~1,5M

People working in healthcare and welfare

~13%

Share of healthcare in GDP

High-risk

Medical AI under EU AI Act Annex III

Source: CBS Healthcare in Figures, NZa monitor, EU AI Act Annex III.

AI in healthcare is no longer pilot territory.

Many healthcare organisations are caught between two extremes. On one side, package vendors who put "AI" on their roadmap without anything clinically useful coming out of it. On the other, standalone AI start-ups with impressive demos that never get past information security, the EHR team or the scientific council.

In practice, what's needed is different: AI that works within an existing EHR workflow, complies with GDPR, NEN 7510, MDR and the AI Act, and can be explained to regulators and the medical staff. No black box. No diagnostic claim that won't clear MDR certification.

We build on the non-diagnostic side of the healthcare AI chain: administrative AI, workflow AI, customer service AI and predictive analytics on operational data. We integrate with EHRs such as HiX, ChipSoft, Epic and Cerner. For medical device AI, we work with NEN 7510 partners who handle the MDR route.

Our audiences differ widely in their AI maturity. University medical centres and STZ hospitals often have their own data science teams and look for a partner to take research models to production readiness. General hospitals and ZBCs mainly want workflow gains without having to work out how GDPR, NEN 7510 and MDR interact. Mental health institutions and long-term care are looking at reporting AI and client communication. GP out-of-hours services and pharmacies need triage bots and medication monitoring. Health insurers and diagnostic centres already run their own customer service AI and claims AI projects. We match the maturity level of the team. Not everything needs to be AI, and not all AI needs to be built by us.

The caveat behind all of these use cases: for medical diagnostics or treatment AI, MDR Class IIa or higher is not an option but a requirement. We do not build that device layer under our own name. What we do build is the administrative, workflow and non-diagnostic AI layer, which delivers the bulk of the time savings for healthcare professionals. This is often the difference between a doctor catching up on paperwork late into the evening and a doctor closing their records within their shift.

Use cases we typically build.

Each type of AI application has its own risk classification, its own integration chain and its own compliance process. These are the four main categories Appfront works in.

Workflow and administrative AI

This is where most of the short-term time savings for healthcare lie, with the lowest MDR risk. Documentation assistants for doctors, DBC coding, claims checking, nursing report extraction, and intake bots for out-of-hours GP services. These are non-diagnostic, so they do not fall under a Class IIa MDR process, but they do require full GDPR, NEN 7510 and transparency compliance under the AI Act.

Comparable commercial tools are Nuance DAX, Suki AI and Abridge for ambient clinical documentation. We build custom when deep integration with HiX or ChipSoft, a Dutch-language healthcare vocabulary or a specific protocol template is not covered by a SaaS product.

Ambient documentationAn LLM that captures the consultation and fills in the EHR fields according to protocol, with the physician remaining ultimately responsible.
DBC coding & claimsProposed codes drawn from the record, with checks before the claim is submitted to the health insurer.
First-line triage botsA symptom checker for out-of-hours GP services within NHG guidelines, with escalation to a human.
Reporting extractionConverting nursing notes into structured EHR fields in line with Nictiz profiles.
Patient flow optimisationPlanning, theatre capacity and readmission risk based on operational data, with no patient-level diagnostics.
Adverse event detectionMedication interaction checks through pattern detection on prescribing and laboratory data.

Built on the Netherlands' strictest compliance framework.

Healthcare AI faces more overlapping legislation than any other sector. We work within the full framework from the first sprint, with a DPIA and risk analysis as deliverables.

EU AI Act — Annex III

Medical AI = high-risk

AI used in medical decision-making and triage falls under Annex III. Conformity assessment, a quality management system and post-market monitoring are mandatory. Our pipeline and documentation are set up to meet these requirements. See also our page on enterprise AI implementation.

MDR — EU 2017/745

Medical Device Regulation

AI that directly influences diagnosis or treatment is a Class IIa, IIb or III medical device. We do not build that device layer independently. We work in a partner flow with MDR-certified suppliers and deliver the integration and workflow layer around it.

GDPR + UAVG

Special category personal data

Health data falls under the special categories of Article 9 of the GDPR. We rely on an explicit legal basis, data minimisation and pseudonymisation where possible. Our AI architecture isolates personal data in a separate layer, and we train models on pseudonymised data wherever we can.

NEN 7510 + NEN 7512/13

Information security in healthcare

Our development and hosting environment complies with NEN 7510. Access control, logging, encryption at rest and in transit, BIA and risk analysis are standard. See our page on NEN 7510-compliant software for the details.

WGBO + Wkkgz

Treatment agreement & quality

The WGBO governs record-keeping obligations, information and consent. The Wkkgz requires incident registration and complaints handling. AI features that touch these areas, such as AI-generated clinical notes, receive an audit log that a supervisory authority can review.

MedMij + HL7 FHIR + Nictiz

Interoperability

Data exchange with patient PHRs and between healthcare providers follows the MedMij framework and the HL7 FHIR profiles from Nictiz. We build our integrations accordingly, with no proprietary export formats that would break the chain.

Algorithm Register

Public transparency

Health insurers and public healthcare providers publish AI applications with an impact on citizens in the Algorithm Register. Our model cards and governance documentation are prepared so you can complete that registration.

Cyber Resilience Act

Security obligations across the product lifecycle

The CRA requires security updates, vulnerability reporting and an SBOM. Our releases ship with an SBOM, dependency scanning and a vulnerability disclosure procedure that supports the CRA deadlines.

Seamlessly connected to the healthcare IT ecosystem.

We integrate with the systems your organisation already runs. No rip-and-replace. Our AI layer complements them, uses existing authorisation and respects record-level access rights.

HiX

ChipSoft EHR

Epic

EHR platform

Cerner

Oracle Health EHR

Nictiz

FHIR profiles

MedMij

PHR data exchange

DigiD

Patient identification

Azure / GCP

EU-region hosting

OpenAI / Anthropic

LLM providers

Off-the-shelf vendors where relevant, custom where needed.

For imaging AI, strong commercial solutions exist, including Aidoc, Lunit, RetinAI, PathAI and Paige.AI. For clinical documentation there are Nuance DAX, Suki and Abridge. For triage, Babylon, Mediktor and Ada Health. Dutch players such as Pacmed and Healthplus.ai serve specific niche markets. We recommend investigating that market first before you consider custom development.

Custom development through Appfront is appropriate for niche applications without a commercial product, deep EHR integration where SaaS integrations fall short, multi-system orchestration (EHR + lab + radiology + patient portal), or a custom LLM integration on internal clinical data in a research context. For health insurers, we build white-label customer service AI with explainability layers that support the Algoritmeregister (Dutch algorithm register) format; for independent treatment centres (ZBCs), we build patient portals in which an AI assistant supports the appointment flow without giving medical advice itself.

We make the choice between SaaS and custom work during the validation phase. Sometimes the advice is to run an existing tool for six months first, before custom AI makes sense. Only once the real workflow and data quality are clear is it sensible to build your own model around it. We don't always sell our own build; sometimes integrating an existing vendor into your EHR is the wisest first step. For broad AI adoption across the whole organisation, we refer clients to AI literacy training and enterprise AI implementation.

From use-case validation to going live.

An AI project in healthcare has its own rhythm: more compliance work up front, more clinical validation afterwards. Five phases we work through for every project.

01 · Use case

Validation & risk classification

Workshop with IT, medical staff, the DPO and the privacy officer. Outcome: a chosen use case, AI Act risk classification and an initial DPIA draft assessment.

02 · Architecture

Data flow & integrations

EHR integrations via FHIR, a pseudonymisation layer, model choice (in-house training or an LLM hosted in an EU region). Security design review with information security.

03 · Build

Sprints with clinical testing

Each sprint delivers a working component. Clinical validation with a small group of doctors and nurses. For every model: a model card, an evaluation set and a fairness check.

04 · Pilot

Small-scale clinical pilot

A ward or outpatient clinic runs the solution live. Complete audit log and incident procedure in place. Results reported to medical management.

05 · Maintenance

Post-market monitoring

Model performance measured continuously, drift detection active, annual re-evaluation. Updates follow the CRA procedure, with SBOM and CVE monitoring.

At every phase there is a fixed point of contact with information security, the medical staff and, where applicable, the scientific council. Compliance is not a report that appears at the end, but a continuous trail of DPIA updates, model evaluations and governance decisions that grows with you. When handing over to your own team, we deliver the documentation, runbooks and monitoring dashboards, so that your information security officer and your operations team can carry on independently, without any ongoing dependence on Appfront.

What we typically build in healthcare AI.

Workflow · Hospital

EHR documentation assistant

An LLM records the consultation, fills in record fields according to protocol and respects the consent rules under the WGBO (Dutch Medical Treatment Contracts Act). The doctor remains ultimately responsible and signs off.

HiX / Epic

EHR integration

EU region

model hosting

Patient flow · University Medical Centre

Predictive readmission risk

A prediction model built on anonymised record data that helps operating theatre planners with triage and readmission risk. Includes fairness monitoring per patient group.

FHIR feed

data source

Algorithm Register

ready for publication

Insurer & primary care

Customer service and claims AI

White-label customer service AI for a health insurer, AI checks on DBC (diagnosis-treatment combination) claims, and a triage bot for a GP out-of-hours service within the NHG (Dutch College of General Practitioners) framework.

GDPR art. 9

compliance layer

NEN 7510

information security baseline

Research, education and the university medical centre context.

For UMC, RIVM and ZonMW-funded research projects, AI initiatives have a dual dynamic. The research side delivers the idea, the model and the evaluation set. The production side must bring that model into an EHR or client system, with the audit trail that regulators and the medical staff need. Many promising research models fall down at exactly that gap: the move from a Jupyter notebook with strong AUC scores to a production-ready system that complies with GDPR, NEN 7510 and the AI Act.

We bridge that gap. For research institutions, we build the production layer around a model, including pseudonymisation, audit logging, a model card, an evaluation pipeline and governance documentation. For publication-oriented research, we deliver reproducibility tooling and data management plans that support FAIR principles. For education and internal knowledge transfer, we work alongside your own data science department, with no lock-in and no vendor handover that leaves your research team powerless.

Drug discovery and genomics are a separate branch with their own tooling chain. We do not build a platform of our own there, but we do build custom data pipelines, LLM integrations with public knowledge sources, and integrations with laboratory instruments. For precision medicine applications in a UMC, we usually work alongside a biotech or pharma partner who provides the scientific validation.

A recurring theme at research institutions is FAIR data discipline: findable, accessible, interoperable and reusable. AI projects that do not meet these principles run into trouble later on, at publication, peer review or when seeking follow-on funding. Our pipeline records metadata, model versions and evaluation runs, so that an external party (a scientific committee, a regulator or the grant provider) can reconstruct the chain. For health-tech start-ups heading towards a Series A, this is the difference between a credible due diligence and a red flag in the tech report.

How AI in healthcare is developing.

Nictiz — Strategic Agenda 2025

"The deployment of AI in healthcare calls for early assessment against the GDPR, the MDR and the AI Act. Interoperability via HL7 FHIR is a prerequisite for scalability."

Federatie Medisch Specialisten — AI Vision

"AI applications that support clinical decision-making require clinical validation, transparent model documentation and a clear division of responsibility between supplier and healthcare professional."

Dutch Data Protection Authority — regulator

"Processing health data for AI applications requires a DPIA and strict adherence to the principles of lawfulness, purpose limitation and data minimisation."

Answers for healthcare executives exploring AI.

Questions we frequently hear from CMIOs, CIOs, privacy officers and business developers in healthcare.

Which AI use cases in healthcare are realistic to build now?

Most short-term value lies in administrative and workflow AI: documentation assistants for doctors, DBC coding and claims checking, report extraction for nurses, and triage bots in primary care. Strong commercial products already exist for medical imaging and clinical decision support, so for those we first recommend a market scan. For deep EHR integration and multi-system orchestration, we build custom software.

Is an MDR process always required for healthcare AI?

No, not always. Only when the AI directly influences medical diagnosis or treatment does the tool become a Class IIa, IIb or III medical device under the MDR. Workflow AI, administrative AI and non-diagnostic support usually fall outside it. For applications that do fall under the MDR, we work in a partner model with MDR-certified suppliers, as we do not build the device layer ourselves.

How do you handle the GDPR and special category personal data?

Health data falls under the special category in Article 9 of the GDPR. Our architecture isolates PII in a separate layer with strict access control. Where possible, we train models on pseudonymised or synthetic data. As standard, we deliver a DPIA, a data processing agreement and model cards for the DPO. LLM calls to external providers go through EU-region endpoints with training opt-out.

Does your development process comply with NEN 7510?

Yes. Our development and hosting environment operates within the NEN 7510 framework: access management, logging, encryption at rest and in transit, and periodic BIA and risk analysis. For clients who are certified themselves, we provide the evidence needed for their audit. See also our service page on NEN 7510-compliant software.

How do you integrate with HiX, ChipSoft, Epic and Cerner?

We prefer to work with the official FHIR APIs and the Nictiz profiles. For HiX/ChipSoft, we connect through their integration portfolio; for Epic, through App Orchard / Vendor Services programmes; for Cerner, through the Oracle Health developer environment. Where the standard APIs fall short, we build a middleware layer rather than direct database integrations that would break the EHR's lifecycle.

What determines the cost of a healthcare AI project?

Four factors: scope (one use case versus multiple systems), regulatory weight (MDR pathway versus GDPR/NEN 7510 alone), integration depth (one EHR integration versus EHR plus lab, radiology and patient portal) and model requirements (an off-the-shelf LLM versus training on your own clinical data). We work to a fixed budget per sprint and, after the validation phase, give a concrete price for the complete build, including the compliance work.

How does this fit within the AI Act high-risk requirements?

AI in medical decision-making and triage falls under Annex III of the EU AI Act as high-risk. That requires a conformity assessment, a quality management system, transparent documentation and post-market monitoring. Our pipeline is built around these requirements: model cards, evaluation sets, drift monitoring and governance documentation are standard deliverables. For the broader implementation approach, see enterprise AI implementation and AI literacy training for your team.

How does AI fit within existing hospital budgets and funding?

Many healthcare organisations finance AI from a combination of their regular ICT budget, ZonMW or Health~Holland grants, and innovation funds from health insurers. We help you make scoping decisions so the project fits within a single financial year, and we provide a justification that can support a grant or innovation application. We do not work with percentage-of-savings pricing or value-based fees.

What do you do and not do in healthcare AI?

What we do: workflow AI, administrative AI, customer service AI, predictive analytics on operational data, EHR integrations via FHIR, patient portals with AI assistance, and LLM integrations on internal clinical data in a research context. What we do not take on alone: medical device AI that directly influences diagnosis or treatment and therefore falls under MDR Class IIa/IIb/III. For that layer, we work as a partner to an MDR-certified supplier. For medical imaging, we advise first examining the existing market (Aidoc, Lunit, RetinAI, PathAI) before custom development is considered.

How do we arrange the handover to our own IT team?

From the start, we work alongside your information security officer, EHR management team and data stewards. At the end of the engagement, we deliver runbooks, monitoring dashboards, model cards and a maintenance procedure that fits within your existing ITIL or agile workflow. We do not lock you in to proprietary tooling: models, data pipelines and infrastructure-as-code templates remain yours.

Talk to us about AI in your healthcare organisation?

A half-hour exploratory conversation with your CMIO, CIO or business developer. We listen to the use case, outline the compliance route and suggest an initial direction. No obligation.

Schedule an exploratory conversation Email fabian.vandijk@appfront.nl