triqura-ecd/docs/datamodel/onderzoek/onderzoek-engelstalige-epd-terminologie.md

# Onderzoek Engelstalige EPD-terminologie — referral en instroom

**Status:** onderzoeksrapport, aanbeveling nog niet als begrippenbesluit verwerkt  
**Datum:** 18 juli 2026  
**Aanleiding:** de werktermen `Inbound Care Signal` en `Access Assessment Case` uit `../begrippenlijst-kernmodel.md` zijn onvoldoende vanzelfsprekend voor Engelstalige ontwikkelaars en zorgprofessionals  
**Scope:** Amerikaanse EHR’s, behavioral-health EHR’s, HL7 FHIR, Amerikaanse closed-loop referral guidance en NHS-terminologie

## 1. Onderzoeksvraag

Welke Engelse technische termen passen het beste bij:

1. **AANMELDSIGNAAL** — iedere afzonderlijke binnenkomst met eigen bron, ontvangsttijd, documenten en oorspronkelijk geuite zorgvraag;
2. **AANMELDINGSTRAJECT** — de institutionele workflow waarin één samenhangende zorgvraag wordt beoordeeld, eventueel gevoed door meerdere binnenkomsten, vóór klinische intake en formele acceptatie?

## 2. Hoofdconclusie

De twijfel bij de huidige werktermen is terecht:

- **`Inbound Care Signal` afwijzen.** `signal` is geen gangbare EHR-term voor een ontvangen aanmelding. In zorg-IT klinkt het eerder als klinisch signaal, alert of vroegsignaal.
- **`Access Assessment Case` afwijzen als canonieke naam.** De woorden zijn begrijpelijk, maar deze combinatie komt niet herkenbaar terug in de onderzochte EHR’s of standaarden. `access assessment` beschrijft eerder een activiteit binnen een workflow dan de beheerde workflow zelf.

Amerikaanse EHR’s gebruiken vrijwel overal **referral** als overkoepelende term voor de beheerde instroomworkflow. Ze maken in publieke documentatie alleen niet altijd scherp onderscheid tussen:

- het zorgverzoek;
- de ontvangen verzending of documentenbundel;
- de interne workflow die het verzoek behandelt.

Dat onderscheid is voor Triqura wel nodig. Daarom is de sterkste oplossing geen simpele hernoeming, maar een model met drie begrippen:

1. **Referral Request — `referral_request`**  
   Het semantische verzoek om zorg of beoordeling, geïnitieerd door professional, organisatie, cliënt of vertegenwoordiger.
2. **Referral Submission — `referral_submission`**  
   Eén afzonderlijke ontvangst of indiening, via bijvoorbeeld portaal, telefoonregistratie, e-mail, eFax of koppeling, met eigen bron en documenten.
3. **Referral Case — `referral_case`**  
   De door de ontvangende instelling beheerde workflow waarin submissions en requests worden beoordeeld, aangevuld, getrieerd en afgesloten.

Voor de huidige Nederlandse begrippen betekent dit voorlopig:

- **AANMELDSIGNAAL → `Referral Submission`**
- **AANMELDINGSTRAJECT → `Referral Case`**
- **VERWIJZING → waarschijnlijk `Referral Request`**, voor zover het de formele zorgvraag/verwijzing representeert

De precieze grens tussen `Referral Request` en de bestaande Nederlandse entiteit VERWIJZING moet in de volgende feitenronde worden vastgesteld.

## 3. Wat de leveranciers laten zien

### 3.1 Epic

Epic publiceert een eersteklas `REFERRAL`-object:

- classificeert referrals als `Internal`, `Incoming` of `Outgoing`;
- kent statussen als `New Request`, `Open`, `Pending Review`, `Authorized`, `Denied`, `Closed` en `Incomplete`;
- bewaart bron, reden, prioriteit, ontvangstdatum en besluitdatum;
- kent triage-uitkomsten zoals `Accept`, `Reject`, `Redirect`, `Information Request`, `Respond` en `Convert`;
- heeft een afzonderlijke referralhistorie.

Dit lijkt sterk op het Nederlandse AANMELDINGSTRAJECT: één beheerd object met lifecycle en triage. Epic noemt dit eenvoudigweg een **Referral**.

Epic publiceert daarnaast `ServiceRequest (Referral)` als FHIR-projectie en een `Incoming Referral Notification` als uitwisselingsinterface. Dat bevestigt dat een bericht, verzoek en beheerd referralobject niet noodzakelijk hetzelfde zijn.

**Les voor Triqura:** `referral` is herkenbaar voor de workflow, maar zonder suffix te ambigu wanneer ook request en submission afzonderlijk worden gemodelleerd.

### 3.2 Oracle Health

Oracle Health gebruikt eveneens **Referral** voor het beheerde object:

- actieve en eerdere referrals;
- status;
- referring en referred providers;
- attachments;
- comments;
- activity timeline;
- gekoppelde afspraken;
- requested start date en service-by date.

Een nieuwe referral begint in de UI als **Referral Order**. De order is het verzoek; de Referral Management-functionaliteit beheert vervolgens de lifecycle.

**Les voor Triqura:** `Referral Order` is te smal voor zelfaanmelding en informele instroom. `Referral` past bij de ontvangende workflow.

### 3.3 athenahealth

athenahealth publiceert vooral:

- `Referral Order`;
- `Referral/Auth`;
- attachments gekoppeld aan een referral authorization order;
- generieke `Patient Cases`.

`Referral/Auth` vermengt verwijzing en verzekeringsautorisatie. `Patient Case` is te breed en in de publieke documentatie niet specifiek genoeg verbonden aan instroom.

**Les voor Triqura:** `order`, `authorization` en een ongekwalificeerde `patient_case` passen niet als generieke kernnamen.

### 3.4 Netsmart — behavioral health

Netsmart is voor de GGZ-context bijzonder relevant. Referral Manager:

- verzamelt **incoming referrals** uit onder andere eFax en PDF-upload;
- organiseert referral packets, tijdlijnen, notities, communicatie, taken en wachtrijen rond één referral;
- ondersteunt acceptatie en afwijzing;
- spreekt expliciet over het **referral intake process**;
- zet een geaccepteerde referral door naar een afzonderlijke **pre-admit workflow** in het EHR.

Netsmart gebruikt dus:

- `incoming referral` voor de ontvangen instroom;
- `referral record`/`referral` als beheerd lifecycle-object;
- `referral packet` voor de documentenbundel;
- `referral intake` voor het proces;
- `pre-admit` pas na acceptatie.

**Les voor Triqura:** referralterminologie past ook bij behavioral health. `intake` is daar echter breder en administratief gebruikt, terwijl Triqura `INTAKE` al reserveert voor het klinische onderzoekstraject. Daarom is `Referral Intake Case` voor Triqura onnodig verwarrend.

### 3.5 NextGen en Qualifacts

NextGen gebruikt vooral `Referral Order` binnen een encounter en een `Intake Template` voor gegevens binnen dat contact. `Case` heeft er een andere betekenis: het groepeert encounters voor juridische of verzekeringsdoeleinden.

Qualifacts gebruikt publiek vooral `intake`, `case management` en configureerbare workflows, maar publiceert onvoldoende technisch detail om een zelfstandig referralobject betrouwbaar af te leiden.

**Les voor Triqura:** `case` moet altijd worden gekwalificeerd als `referral_case`; een kaal `case` is te breed.

## 4. Wat de standaarden laten zien

### 4.1 HL7 FHIR

FHIR maakt nuttige conceptuele scheidingen:

- **`ServiceRequest`** — voorstel, plan of order om een dienst te laten uitvoeren;
- **`Task`** — administratieve coördinatie en voortgang van de uitvoering;
- **`EpisodeOfCare`** — periode waarin een organisatie verantwoordelijkheid draagt;
- **`Encounter`** — feitelijk contact of interactie.

FHIR beschrijft een intakevoorbeeld waarin:

1. een `ServiceRequest` wordt ontvangen;
2. eligibility en capaciteit worden beoordeeld;
3. een geplande `EpisodeOfCare` kan worden gemaakt;
4. verdere assessment volgt;
5. na acceptatie een plan ontstaat en de episode actief wordt.

Triqura heeft bewust een andere semantische grens: de ZORGEPISODE ontstaat pas bij formele acceptatie en acceptatie impliceert nog niet automatisch alle behandelverantwoordelijkheid. Daarom moet het pre-acceptatietraject niet rechtstreeks `EpisodeOfCare` worden genoemd.

Een Triqura Referral Submission kan bij uitwisseling bestaan uit meerdere FHIR-resources, bijvoorbeeld `ServiceRequest`, `DocumentReference`, `Communication` en provenance. Het lokale object hoeft dus geen FHIR-resourcenaam te dragen.

### 4.2 Amerikaanse ONC/360X

360X gebruikt:

- `referral request`;
- `referral order`;
- een persistente `Referral Identifier`;
- een closed-loop `referral workflow`;
- statussen en terugkoppelingen tot de referral is gesloten.

De Amerikaanse definitie van **Referral Order** is doorgaans provider-authored. Die term sluit zelfaanmelding en instroom vanuit niet-klinische bronnen onvoldoende in.

**Les voor Triqura:** gebruik `request` in plaats van `order` voor het inhoudelijke verzoek, en modelleer de ontvangende workflow afzonderlijk.

### 4.3 NHS

De NHS definieert:

- **Service Request** — verzoek om zorgdiensten;
- **Referral Request** — subtype voor een zorgdienst, inclusief expliciete zelfverwijzing;
- **Patient Pathway** — de bredere route vanaf het eerste ontvangen verzoek, mogelijk over langere tijd en meerdere behandelperioden.

De NHS vermeldt bovendien dat een mondeling en later schriftelijk bevestigd verzoek normaliter als één referral wordt verwerkt. Dit ondersteunt het onderscheid tussen:

- één semantisch request;
- meerdere ontvangsten of representaties van dat request.

`Patient Pathway` is voor Triqura te breed: het kan chronische of recidiverende zorg en meerdere referral-to-treatment periods omvatten.

## 5. Beoordeling van naamparen

### Optie A — Referral Submission / Referral Case

**Identifiers:** `referral_submission` / `referral_case`  
**Advies:** voorkeur

Sterke punten:

- voor Amerikaanse developers direct herkenbaar als onderdeel van referral management;
- submission duidt één ontvangst aan;
- case duidt één beheerde workflow-instance aan;
- self-referral kan expliciet als referral request door de cliënt worden geïnitieerd;
- geen botsing met admission, encounter of EpisodeOfCare;
- laat ruimte voor een afzonderlijke Referral Request.

Risico’s:

- `Referral Submission` is een lokale technische term, geen universele EHR-standaardterm;
- `case` kan elders financieel of juridisch betekenen en moet daarom altijd als `referral_case` worden geschreven;
- de definitie moet expliciet maken dat referral ook self-referral en andere toegestane bronnen omvat.

### Optie B — Care Access Submission / Care Access Case

**Identifiers:** `care_access_submission` / `care_access_case`  
**Advies:** inhoudelijk inclusief, maar minder idiomatisch

Sterke punten:

- neutraler voor zelfaanmelding en niet-formele bronnen;
- benadrukt toegang tot zorg in plaats van verwijzing door een professional.

Risico’s:

- veel minder herkenbaar in de onderzochte EHR-documentatie;
- `access` kan voor developers systeem-, dossier- of autorisatietoegang betekenen;
- het verband met referral management en closed-loop uitwisseling wordt minder zichtbaar.

### Optie C — Referral Submission / Referral Intake Case

**Identifiers:** `referral_submission` / `referral_intake_case`  
**Advies:** niet kiezen voor Triqura

Sterke punten:

- zeer expliciet over de instroomfase;
- sluit aan bij behavioral-healthtaal als `referral intake process`.

Risico’s:

- Triqura kent al een afzonderlijke klinische INTAKE;
- Amerikaanse systemen gebruiken intake zowel administratief als klinisch;
- vergroot precies de begripsverwarring die het kernmodel probeert te voorkomen.

### Optie D — Inbound Care Submission / Access Assessment Case

**Identifiers:** `inbound_care_submission` / `access_assessment_case`  
**Advies:** niet kiezen

Sterke punten:

- domeinneutraal;
- inhoudelijk te begrijpen met een definitie ernaast.

Risico’s:

- geen herkenbaar naamgebruik in de onderzochte EHR’s;
- te abstract en samengesteld;
- `assessment` klinkt als één activiteit;
- `inbound care` klinkt eerder als gegevenslogistiek dan als cliëntinstroom.

## 6. Aanbevolen conceptueel model

De terminologische onduidelijkheid komt mede doordat AANMELDSIGNAAL nu twee betekenissen bevat: de ontvangen verzending én het inhoudelijke zorgverzoek.

De aanbevolen scheiding is:

```text
Referral Request
  het inhoudelijke verzoek om zorg of beoordeling

Referral Submission
  één ontvangen representatie of aanvulling van een request

Referral Case
  de ontvangende workflow die submissions en requests behandelt
```

Voorbeelden:

- Een huisarts stuurt een verwijzing met brief: één Referral Request, ontvangen via één Referral Submission, behandeld in één Referral Case.
- De huisarts stuurt later aanvullende diagnostiek: dezelfde Referral Request en Referral Case, tweede Referral Submission.
- De cliënt belt daarnaast zelf met aanvullende informatie: derde Referral Submission bij dezelfde Referral Case.
- Twee instanties melden onafhankelijk dezelfde zorgvraag: twee requests of submissions kunnen na menselijke beoordeling aan één Referral Case worden gekoppeld.
- Een gelijktijdige crisisvraag en reguliere hulpvraag kunnen ieder een eigen Referral Case krijgen.

De cardinaliteiten mogen nog niet uit deze voorbeelden worden afgeleid. Eerst moeten de elementaire feitzinnen worden gevalideerd.

## 7. Aanbeveling voor de begrippenlijst

Nog niet automatisch aanpassen; eerst inhoudelijk bevestigen:

1. vervang `Inbound Care Signal` door **Referral Submission**;
2. vervang `Access Assessment Case` door **Referral Case**;
3. voeg **Referral Request** toe als afzonderlijk begrip;
4. herbeoordeel of de huidige VERWIJZING volledig samenvalt met Referral Request of slechts één subtype/bron daarvan is;
5. behoud **Clinical Intake Assessment** als afzonderlijk klinisch proces na of rond acceptatie;
6. behoud **Clinical Care Episode** voor de geaccepteerde zorgperiode.

## 8. Betrouwbaarheid en beperkingen

- Epic EHI-exporttabellen geven sterke aanwijzingen voor het logische exportmodel, maar zijn niet automatisch het operationele interne databaseschema.
- Oracle, athenahealth, Netsmart, NextGen en Qualifacts publiceren vooral product-, UI- en API-termen.
- FHIR is een uitwisselingsmodel en geen verplicht lokaal domeinmodel.
- Marketingdocumentatie is gebruikt om gangbaar taalgebruik te beoordelen, niet om cardinaliteiten of juridische betekenis af te leiden.
- Er bestaat geen universele EHR-term voor “iedere afzonderlijke binnenkomst ongeacht kanaal”. `Referral Submission` is daarom een expliciet gekozen lokale technische term.

## 9. Bronnen

### Amerikaanse EHR’s

- Epic, `REFERRAL`: https://open.epic.com/EHITables/GetTable/REFERRAL.htm
- Epic, `REFERRAL_2` triage decision: https://open.epic.com/EHITables/GetTable/REFERRAL_2.htm
- Epic, `REFERRAL_HIST`: https://open.epic.com/EHITables/GetTable/REFERRAL_HIST.htm
- Epic, FHIR interfaces: https://open.epic.com/Interface/FHIR
- Oracle Health, Referrals: https://docs.oracle.com/en/industries/health/oracle-health-ehr/ehrfg/referrals.html
- Oracle Health, Create Referral: https://docs.oracle.com/en/industries/health/oracle-health-ehr/ehrfg/create-referral.html
- athenahealth, Referral Authorization: https://docs.athenahealth.com/api/api-ref/referral-authorization
- athenahealth, Patient Cases: https://docs.athenahealth.com/api/api-ref/document-type-patient-case
- Netsmart, Referral Management: https://www.ntst.com/carefabric/population-health-management/referral-management
- Netsmart, referral intake workflow: https://www.ntst.com/blog/2025/optimizing-human-services-intake-with-ai-and-automation
- NextGen, Referrals: https://docs.nextgen.com/en-US/nextgenc2ae-adaptive-content-engine-help-enterprise-8-3-1-3288208/add-referrals-251359
- NextGen, Cases: https://docs.nextgen.com/en-US/nextgenc2ae-enterprise-ehr-help-3270157/cases-in-nextgenc2ae-enterprise-ehr-324977
- Qualifacts, InSync EHR: https://www.qualifacts.com/about/insync-ehr-platform/

### Standaarden en guidance

- HL7 FHIR ServiceRequest: https://hl7.org/fhir/R5/servicerequest.html
- HL7 FHIR Task: https://hl7.org/fhir/R5/task.html
- HL7 FHIR EpisodeOfCare: https://hl7.org/fhir/R5/episodeofcare.html
- HL7 FHIR Encounter: https://hl7.org/fhir/R5/encounter.html
- HL7 US SDOH Referral Management Task: https://hl7.org/fhir/us/sdoh-clinicalcare/STU2.3/StructureDefinition-SDOHCC-TaskForReferralManagement.html
- ONC 360X: https://oncprojectracking.healthit.gov/wiki/spaces/TechLab360X/pages/18776120/360X+Home
- US Health IT Referral Order: https://isp.healthit.gov/uscdi-data/referral-order
- NHS Service Request: https://www.datadictionary.nhs.uk/classes/service_request.html
- NHS Referral Request: https://archive.datadictionary.nhs.uk/DD%20Release%20May%202024/classes/referral_request.html
- NHS Patient Pathway: https://www.datadictionary.nhs.uk/classes/patient_pathway.html