Sector · Healthcare

Electronic health record app. A mobile layer on top of your EHR.

We build custom apps for healthcare professionals that run alongside the EHR system. Record access on a tablet, nursing documentation at the bedside, medication administration with BEM checks, wound photos for reporting, and voice-to-text for quick notes. Secure via UZI pass or ZorgID, connected to HiX, Epic or another EHR through HL7 FHIR R4, and tested against NEN 7510. For hospitals, mental health services, long-term care, GPs and pharmacists.

SettingHospital / UMC

SettingMental health

SettingNursing and care homes / disability care

SettingGPs / pharmacists

Arrange an introductory call Read about custom healthcare software

Dutch healthcare IT in figures.

~70%

Market share of HiX (ChipSoft) in Dutch hospitals

100%

Mandatory NEN 7510 for healthcare providers

2.300+

Healthcare providers connected to MedMij

FHIR R4

Standard for data exchange since Wegiz

Source: Nictiz information standards, MedMij register, Wegiz implementation plan.

The EHR was never built for the shop floor.

HiX, Epic, Cerner and CGM's GP EHRs do what they're meant to do: reliably keep the patient record and provide the regulatory assurance that comes with it. But frontline staff experience them every day as cumbersome, click-heavy and tied to a desktop at a nursing station. The nurse who needs to log a check at 03:00 wants to do it on a device at the patient's side, not four rooms away at a workstation on wheels where someone is already sitting.

The consequences are well known: duplicate admin on a paper worksheet that is later transcribed, reporting delayed until after the shift, and frustrated nurses losing working time to navigating screens. In long-term care the picture is sharper still. Staff often work at locations without fixed workstations, and EHR use sometimes falls back on a colleague who completes the record later.

An app on top of your EHR fills exactly those gaps that the EHR system itself leaves open. Recording vital signs at the bedside, adding a wound photo and observation to the record, dictating a SBAR handover with speech-to-text, signing off medication with a BEM scan, working through a discharge checklist: all at the bedside or in the community, all synced back to the EHR via FHIR.

We don't replace the EHR. It is deeply embedded in your organisation's workflows, regulations and financial processes, and a rip-and-replace makes sense in almost no care context. We build the mobile layer that works on top of it, sparing the EHR clicks that never belonged there, and bringing your care staff back to where they want to be: at the bedside, not in front of a screen.

An EHR app for each care setting.

The workflow on a surgical ward differs fundamentally from that in a mental health clinic or at a GP practice. For each setting we build the functionality it needs, with the right integrations and the right authorisation model.

Hospitals & university medical centres

On a ward, doctors and nurses work at a fast pace with patterns that fit poorly with a desktop EHR. The EHR app brings the record to the iPad, a shared tablet or the workstation on wheels: lab results, imaging thumbnails, the current medication overview, allergies, vital signs, and the ability to report straight away, without the user having to log out and back in on a shared desktop each time.

Frequently requested in this setting: an SBAR handover module with voice input for warm handovers between wards, a BEM medication scan workflow that links the barcode on the patient wristband to the medication with a double-check, photo capture for pressure ulcer or wound reporting with automatic sizing and historical comparison, and an admission/discharge checklist that synchronises with HiX or Epic. We integrate via HL7 FHIR R4 or, where necessary, via the existing HL7v2 interfaces of your integration layer (Cloverleaf, Rhapsody, Mirth). In university medical centres we also often work with research infrastructure. An EHR app that supports opt-in research participation and can deliver data to the research environment via i2b2 or OMOP mapping does not need to be a separate build; it can be a module of the same app.

Record access at the bedsideLab values, medication, allergies, vital signs on tablet.
BEM medication administrationBarcode scan of patient and medication, double-check workflow.
Wound reporting with photosEncrypted upload, retention managed within the EHR.
Ambient AI scribeSpeech-to-text for clinical notes and SOEP reporting.

Built to the strictest healthcare standards.

An EHR app handles special category personal data and, where diagnostic features are involved, may fall under the Medical Device Regulation. For us, compliance is not a document written afterwards; it is part of the first sprint. Read how we build NEN 7510-compliant software.

NEN 7510-1 / 7510-2

Information security in healthcare

The standard healthcare providers must comply with, based on ISO 27001 but with healthcare-specific controls. From sprint one, we build role-based access control, end-to-end encryption, audit logging and key management in line with the NEN controls. For your organisation's certification processes, we can supply the relevant app documentation for the external auditor.

GDPR / UAVG Art. 9

Special category personal data

Health data falls under Art. 9 of the GDPR and may only be processed under strict conditions: a treatment relationship, explicit consent, or a specific legal basis. For every project, we deliver a DPIA, a data minimisation analysis, a retention schedule and a data processing agreement in line with the UAVG implementation. Your organisation's Data Protection Officer (FG) receives the full file and is actively involved in the scoping phase.

WGBO & Wkkgz

Medical Treatment Agreement Act (WGBO)

Right of access, right of rectification and the twenty-year retention period from the WGBO are built into the data model. For Wkkgz incident registration, we provide a separate audit trail that remains visible independently of the client record.

MedMij & Nictiz

Personal health environment

For PHE functions or patient portals, we work in line with the MedMij guidelines and Nictiz information standards, with FHIR zib mapping (healthcare information building blocks) applied to the exchanged fields.

MDR (EU 2017/745)

Medical Device Regulation

If a feature supports clinical decision-making or delivers diagnostics, the app falls under the MDR, usually class IIa or higher. That entails a notified body process, technical documentation, a quality management system (often ISO 13485) and a post-market surveillance plan. During the scoping phase, we classify together with your notified body or clinical physicist, and only then decide which functionality falls within or outside the MDR process. It is often wise to separate MDR features from non-MDR features into a distinct module to keep the scope manageable.

EU AI Act

Responsible AI in a clinical context

AI features such as an ambient scribe, risk triage or image classification fall into the high-risk category under the AI Act. We document the risk assessment, transparency requirements and human oversight in accordance with the Annex III criteria.

SNOMED CT & ICF

Clinical coding

Where possible, we code diagnoses, findings and interventions in SNOMED CT, and functioning in ICF. This saves integration headaches later with quality registries and insurer DBC reporting.

Connected to the EHR systems used in healthcare.

EHR systems are deeply embedded in healthcare organisations, so a rip-and-replace is rarely sensible. We build apps that work alongside your existing EHR, via FHIR API, HL7v2 or HL7v3 interfaces, or via your EHR vendor's native interfaces.

HiX

ChipSoft: hospitals

Epic

University medical centres and large care groups

Cerner / Oracle Health

International

CGM

GP EHR

Topicus

Care & youth services

VIPLive

eHealth layer

Nedap Ons

Long-term care

UZI / ZorgID

Authentication

Our app is a layer, not a replacement.

The EHR remains the source system. Our app reads and writes via FHIR, with audit logging on every transaction and a data model that uses the zibs (Dutch health information building blocks) as its anchor. For fields not covered by FHIR R4 (there are still EHR-specific flows outside the standard), we work through a vendor-specific interface. For HiX, for example, that is the Cure API or the IHE-conformant XDS interface; for Epic, the App Orchard canvas; for CGM, the GP API interface. We align with your organisation's existing integration platform so that our app does not become an extra integration layer that has to be maintained separately later.

For authentication we support UZI pass (PKIoverheid), ZorgID and, in office contexts, eHerkenning. Session management meets the NEN 7510-3 controls for clinical logins: short sessions, automatic lock on inactivity, hardware-bound secrets. For offline use (poor Wi-Fi on wards or in community nursing), the app uses an encrypted local cache that syncs on reconnect, with a conflict resolution strategy we agree per workflow. Last-write-wins is rarely safe enough in a clinical context; a merge with clinical review is often the right choice. Our experience with offline-first field service apps applies directly here, even though healthcare regulation is stricter.

For the patient side of the story (a PGO integration, an appointment portal, or access to one's own record), we work in line with the MedMij framework requirements and Nictiz guidelines. This involves its own authorisation flow (BSN-based via DigiD) and its own retention and revocation rights.

Ambient AI alongside the record.

The most interesting improvement we are currently building in healthcare is an ambient AI scribe: a microphone feature on the tablet or phone that records the conversation between doctor and patient, transcribes it locally or in a NEN 7510 environment, and prepares a draft report in SOEP structure for the doctor. The doctor edits, checks and files it in the EHR. Comparable to Nuance DAX or Abridge, but built within Dutch compliance frameworks.

For nursing documentation we work with Whisper-based speech-to-text (locally or in a European cloud environment), with a post-processing layer that understands clinical terminology — abbreviations, medication names, anatomical terms. In an early test, the time saving is already evident within a few shift rounds, provided the language model is well tuned to your field.

For every AI feature we document the risk classification under the EU AI Act, the role of human oversight, and how the user is informed of the AI's involvement. A hallucination in a SOAP report is far more consequential than in a marketing email; human review is therefore a standard part of the flow, not an option.

From scope to live on the ward.

A healthcare project has its own rhythm: medical ethics, IT security and the work floor all need to sit at the table. Five phases that recur in every EHR app project.

01 · Exploration

Workflow shadowing

We join the ward. One nurse, one doctor, one operations manager as guide. Result: current flows mapped out, friction points identified.

02 · Design

Scope & classification

Which flows in the app, which integrations first, does anything fall under MDR? First-draft DPIA. AI features get an Annex III check.

03 · Build

Sprints with clinical test users

One working flow delivered every sprint. Nurses test along the way. FHIR integration live in a test EHR environment early on.

04 · Cutover

Phased rollout by ward

First one ward, then a second, then a full rollout. With each rollout: training, a super-user programme, and a parallel-running period.

05 · Maintenance

Compliance maintenance

We adapt with every iOS or Android update, EHR release or change in legislation. First-line support via your IT department, escalation to us.

What the healthcare IT literature refers to.

Nictiz · MedMij framework

"FHIR R4 and Dutch healthcare information building blocks form the basis for data exchange between EHRs, PGOs and healthcare apps in the Netherlands."

Wegiz: the Dutch Act on Electronic Data Exchange in Healthcare

Since Wegiz, electronic data exchange between healthcare providers has been mandatory. Apps connecting to the EHR therefore need to deliver FHIR-compliant output as standard.

NEN 7510-3: Logging in healthcare

"Every access to a patient record is traceable to an individual user, with an immutable audit trail." Our apps meet this requirement from the first release.

Answers for IT directors and business leaders.

The questions we hear most often from CMIOs, IT managers and medical directors.

What exactly is an EHR app?

An EHR app is a mobile or tablet application that runs alongside your existing electronic health record. The app does not replace the EHR, which remains the source system, but adds mobile functionality: bedside record access, nursing documentation, medication administration with barcode scanning, photo capture for wound care, or voice-to-text for quick notes. The EHR remains the source of truth; the app reads and writes via FHIR or a vendor integration. For clinicians, this means the work comes back to the bedside or consulting room, away from the shared desktop in a corner of the ward.

How does your app integrate with HiX or Epic?

HiX offers the ChipSoft Cure API for read and write access from certain versions onwards; in addition, we often work with HL7v2 messages via your organisation's integration layer (for example Cloverleaf or Rhapsody). For Epic, we use the App Orchard programme and the associated FHIR endpoints. Both vendors require a formal integration process with certification, so we guide the application and build against the test environment before going to production.

Does the app comply with NEN 7510?

Yes. From sprint one, we build within the NEN 7510-1 and 7510-2 control framework: role-based authorisation, end-to-end encryption of data at rest and in transit, key management in a KMS, audit logging in line with NEN 7510-3, and periodic penetration tests. For large projects, we involve an external NEN 7510 auditor for formal assessment. The NEN 7510-3 logging requirements are a standard part of the architecture.

What is FHIR, and do we really need it?

FHIR (Fast Healthcare Interoperability Resources) is the international standard for exchanging healthcare data, defined in resources such as Patient, Observation, MedicationRequest and Encounter. In the Netherlands, FHIR R4 is effectively the standard for PGO and MedMij integrations, and Wegiz is making it increasingly mandatory. Yes, for a new EHR app FHIR is our default. Only if your EHR does not yet support it do we build a bridging integration via HL7v2 or a vendor-specific API.

Does our EHR app fall under the Medical Device Regulation?

That depends on the functionality. A record-viewing app or a reporting tool typically does not fall under the MDR. As soon as a feature supports clinical decision-making, for example a triage algorithm, a risk score, or diagnostic image analysis, MDR classification becomes relevant (often class IIa or higher). During the design phase, we carry out a classification check together with your clinical physicist or a notified body. Only then do we determine which features fall within or outside an MDR pathway.

Does the app also work offline?

Yes, that is a common requirement. On nursing wards, in community care, or in basements of older care buildings, WiFi coverage is not always reliable. Our apps use an encrypted local cache: you can view record data, type notes, take photos and sign off medication without a connection. On reconnection, the app syncs with the EHR via FHIR, using a conflict-resolution strategy we agree for each workflow (last-write-wins is usually not safe enough in a clinical context).

What determines the cost of an EHR app?

For one ward and one specific workflow (for example only wound documentation or only medication administration), the project is compact. A broad mobile layer across several wards with FHIR integration, offline mode, ambient AI scribe and a patient portal component is a larger project. The main cost drivers are usually: the complexity of your EHR integration (particularly whether a FHIR endpoint is available), MDR classification where applicable, the number of different role-based flows in the app, and the extent of offline functionality. We work with a fixed sprint budget and, after the scoping phase, provide a concrete price estimate for the complete build.

Who can be the client within a healthcare organisation?

In practice we work most with IT directors, CMIOs (Chief Medical Information Officers) and department or service managers. On larger projects, the Board of Directors or the medical director sits at the table for scope definition. For the frontline input, which is crucial to the success of an EHR app, we work with super-users from nursing, medicine and allied health. The DPO (data protection officer) is involved from the DPIA phase onwards and stays involved until go-live.

How does this fit with Wegiz and MedMij?

The Wegiz (Dutch Act on Electronic Data Exchange in Healthcare) requires healthcare providers to exchange data electronically and in a standardised way, in most cases via FHIR with zib mapping. MedMij is the framework of agreements that governs how personal health environments (PGOs) communicate with EHRs. If your EHR app offers patient access or exchanges data with other healthcare providers, it must be built in line with Wegiz and MedMij. We build to these standards from day one, not as a mandatory retrofit, but as the natural architecture.

Talk to us about your EHR app.

An initial introduction with a CMIO, IT director or service manager. We listen to the workflow, look over your existing EHR with you, and suggest an initial direction. No obligation, from our office on the Westerdoksdijk or on site at your location.

Schedule an introductory call Email fabian.vandijk@appfront.nl