Risposta breve: un Encounter è una singola interazione tra un paziente e il sistema sanitario: una visita ambulatoriale, un ricovero ospedaliero, un accesso al pronto soccorso, una videoconsulenza, una visita domiciliare. Registra quando (period), in quale contesto (class: ambulatoriale, ricovero, pronto soccorso, assistenza domiciliare, virtuale), il suo stato (pianificato → in corso → terminato), chi ha partecipato, perché (reasonCode) e cosa è stato diagnosticato (diagnosis, collegato a Conditions). Osservazioni, procedure, prescrizioni di farmaci e documenti puntano all'Encounter a cui appartengono, permettendo così di leggere la cartella clinica visita per visita.
Un esempio valido di FHIR R4
Una risorsa FHIR R4 Encounter valida richiede solo stato e classe, ma una utile contiene anche soggetto, periodo, tipo, partecipanti, un motivo e le diagnosi che ha stabilito. L'esempio seguente è una consultazione ambulatoriale conclusa per il diabete di tipo 2, con un operatore primario, una diagnosi di motivo principale classificata per prima, una sede e l'organizzazione responsabile.
{
"resourceType": "Encounter",
"id": "visit-2026-03-14",
"status": "finished",
"class": {"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "AMB", "display": "ambulatory"},
"type": [{"coding": [{"system": "http://snomed.info/sct", "code": "11429006", "display": "Consultation"}]}],
"serviceType": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/service-type", "code": "165", "display": "Diabetes Education"}]},
"subject": {"reference": "Patient/example"},
"participant": [{
"type": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType", "code": "PPRF", "display": "primary performer"}]}],
"individual": {"reference": "Practitioner/gp-42"}
}],
"period": {"start": "2026-03-14T09:00:00+01:00", "end": "2026-03-14T09:25:00+01:00"},
"reasonCode": [{"coding": [{"system": "http://snomed.info/sct", "code": "44054006", "display": "Type 2 diabetes mellitus"}]}],
"diagnosis": [{
"condition": {"reference": "Condition/t2dm"},
"use": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/diagnosis-role", "code": "CC", "display": "Chief complaint"}]},
"rank": 1
}],
"location": [{"location": {"reference": "Location/clinic-3"}, "status": "completed"}],
"serviceProvider": {"reference": "Organization/hospital"}
}
Stato: il ciclo di vita
Lo stato di un FHIR Encounter attraversa pianificato, arrivato, triage, in corso, in permesso e concluso, con cancellato, inserito per errore e sconosciuto come altre uscite. L'elemento statusHistory conserva ogni stato precedente con il suo periodo, quindi un ricovero ospedaliero mostra quando il paziente è arrivato, è stato ricoverato e se n'è andato. Un Encounter è l'interazione stessa, non l'Appuntamento che l'ha prenotato.
planned (prenotato, non ancora iniziato) → arrived → triaged (pronto soccorso) → in-progress → onleave (paziente ricoverato in permesso temporaneo) → finished. cancelled e entered-in-error lo terminano diversamente; unknown esiste per le importazioni. statusHistory conserva gli stati precedenti con i relativi periodi, quindi un ricovero ospedaliero mostra quando il paziente è arrivato, quando è stato ricoverato e quando è stato dimesso. Si noti che un Encounter non è un Appointment: l'Appointment è la prenotazione; quando il paziente arriva, viene creato un Encounter che vi fa riferimento tramite appointment.
Classe: il contesto
La class dell'Encounter proviene dal sistema HL7 v3 ActCode: AMB ambulatoriale (esterno), IMP ricoverato, EMER emergenza, HH assistenza domiciliare, VR virtuale (teleassistenza), ACUTE e NONAC per sottotipi di ricovero, OBSENC osservazione, PRENC pre-ammissione, SS breve degenza. classHistory registra i trasferimenti, ad esempio un accesso al pronto soccorso che è diventato un ricovero.
Gli altri elementi
Oltre a stato e classe, un FHIR Encounter contiene tipo e serviceType (che tipo di visita e quale linea di servizio), partecipante (clinici con i loro ruoli e periodi), reasonCode o reasonReference, diagnosi (Condizioni collegate con uso e rango), ricovero (dettagli di ammissione e dimissione), voci di luogo nel tempo, durata, serviceProvider e partOf per sotto-incontri.
- type e serviceType indicano il tipo di encounter e la linea di servizio (cardiologia, educazione al diabete), con codici che variano da paese a paese.
- participant elenca i medici e altri professionisti con un tipo di partecipazione (admitter, attender, primary performer, consultant, referrer) e il periodo in cui ciascuno è stato coinvolto.
- reasonCode / reasonReference forniscono il motivo della visita; diagnosis collega le Conditions stabilite o affrontate, con un
use(diagnosi di ammissione AD, diagnosi di dimissione DD, motivo principale CC, comorbilità CM, fatturazione) e unrank. Vedere FHIR Condition spiegato. - hospitalization contiene i dettagli del ricovero:
admitSource(invio medico di base, pronto soccorso, trasferimento),dischargeDisposition(a casa, altro ospedale, deceduto),preAdmissionIdentifier, dieta e accordi speciali. - location elenca i luoghi con il loro stato nel tempo (pianificato, attivo, riservato, completato); un trasferimento di reparto aggiunge una nuova voce.
- length è la durata; serviceProvider l'organizzazione responsabile; partOf collega un sotto-encounter (un soggiorno in reparto) al ricovero a cui appartiene.
Cosa è cambiato in R5
FHIR R5 ha rinominato Encounter.hospitalization in admission, ha unito reasonCode e reasonReference in reason, ha reso class una lista di CodeableConcept (un incontro può avere diverse classificazioni), ha spostato participant.individual in actor e ha introdotto EncounterHistory come risorsa separata per la cronologia di stato e classe. R4 rimane la versione in US Core e nella maggior parte delle guide nazionali; vedere FHIR R4 vs R5.
Mappatura da HL7 v2
I messaggi HL7 v2 ADT vengono mappati a FHIR Encounter per tipo di evento: A01 ammissione crea un Encounter ricoverato in corso, A03 dimissione lo conclude con period.end e discharge disposition, A02 trasferimento aggiunge una voce di luogo, A04 registra un Encounter ambulatoriale e A08 lo aggiorna. La maggior parte dei dati proviene dal segmento PV1, il cui numero di visita diventa Encounter.identifier.
Un ADT^A01 (ammissione) crea un Encounter con classe IMP e stato in-progress; A03 (dimissione) imposta lo stato finished e compila period.end e dischargeDisposition; A02 (trasferimento) aggiunge una voce location; A04 (registrazione ambulatoriale) crea un encounter AMB; A08 lo aggiorna. PV1 contiene la maggior parte dei dati (classe del paziente in PV1-2, posizione in PV1-3, medico curante in PV1-7, numero di visita in PV1-19, che diventa Encounter.identifier). Vedere Messaggi HL7 v2 spiegati.
In Anpheros
Anpheros Platform crea risorse FHIR Encounter in due modi: le cliniche le scrivono tramite API e la visita registrata di una persona diventa un Encounter concluso una volta che l'appuntamento ha avuto luogo. Risultati, documenti e note di quella visita fanno riferimento all'Encounter, in modo che il record possa essere letto visita per visita dalla persona e da qualsiasi clinica con cui condivide.
Gli appuntamenti prenotati nell'app sono risorse Appointment fino a quando non avvengono.
Pagine correlate
- FHIR Condition spiegato
- Risorsa FHIR Patient spiegata
- Messaggi HL7 v2 spiegati: ADT e ORU
- FHIR R4 vs R5
- FHIR DiagnosticReport spiegato
- Esempio di Encounter sul sito per sviluppatori
Fonti
- HL7 FHIR R4: Encounter
- HL7 FHIR R5: Encounter
- HL7 Terminology: v3 ActCode (encounter class)
- HL7 Terminology: diagnosis-role code system
- HL7 US Core: Encounter profile
Domande frequenti
Qual è la differenza tra Encounter e Appointment?
Un Appointment è la prenotazione di uno slot futuro; un Encounter è l'interazione che è effettivamente avvenuta (o sta avvenendo). Quando il paziente arriva, viene creato l'Encounter e questo fa riferimento all'Appointment.
Un ricovero ospedaliero è un solo Encounter o molti?
Di solito un solo Encounter per il ricovero, con voci di location per ogni reparto e classHistory per i cambi di contesto. Alcuni sistemi creano sotto-encounter per ogni soggiorno in reparto collegati tramite partOf; le guide nazionali indicano quale approccio seguire.
Dove va il riassunto di dimissione?
Come DocumentReference o un documento FHIR la cui Composition fa riferimento all'Encounter. L'Encounter stesso contiene la disposizione alla dimissione e le date, non la narrazione.
Ogni Observation necessita di un Encounter?
No. Le Observation che il paziente registra a casa, o che arrivano da un dispositivo indossabile, non hanno un Encounter. Quelle effettuate durante una visita dovrebbero farvi riferimento in modo che la cartella clinica possa essere letta per visita.
Provalo gratis nella sandbox
La tua prima chiamata FHIR in 5 minuti. Un'API HL7 FHIR R4 con il consenso del paziente integrato: provala nella sandbox, poi collega la tua app o il sistema della tua clinica.
Gratis · 30 pazienti sintetici · senza carta

