Kurze Antwort: Eine Encounter ist eine Interaktion zwischen einem Patienten und dem Gesundheitssystem: ein ambulanter Besuch, ein Krankenhausaufenthalt, eine Notaufnahme, eine Videosprechstunde, ein Hausbesuch. Sie erfasst wann (period), in welchem Setting (class: ambulant, stationär, Notfall, häusliche Pflege, virtuell), ihren Status (geplant → in Bearbeitung → abgeschlossen), wer teilgenommen hat, warum (reasonCode) und was diagnostiziert wurde (diagnosis, Verknüpfung zu Conditions). Beobachtungen, Prozeduren, Medikamentenbestellungen und Dokumente verweisen auf die Encounter, zu der sie gehören, wodurch ein Datensatz Besuch für Besuch gelesen werden kann.
Ein gültiges FHIR R4 Beispiel
Eine gültige FHIR R4 Encounter-Ressource benötigt nur Status und Klasse, aber eine nützliche enthält auch Subjekt, Zeitraum, Typ, Teilnehmer, einen Grund und die gestellten Diagnosen. Das folgende Beispiel ist eine abgeschlossene ambulante Konsultation für Typ-2-Diabetes mit einem primären Behandler, einer Hauptbeschwerde-Diagnose an erster Stelle, einem Ort und der verantwortlichen Organisation.
{
"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"}
}
Status: der Lebenszyklus
Der Status eines FHIR Encounters durchläuft planned, arrived, triaged, in-progress, onleave und finished, mit cancelled, entered-in-error und unknown als weiteren Ausgängen. Das Element statusHistory speichert jeden früheren Zustand mit seinem Zeitraum, sodass ein Krankenhausaufenthalt zeigt, wann der Patient ankam, aufgenommen wurde und ging. Ein Encounter ist die Interaktion selbst, nicht der Termin, der ihn gebucht hat.
planned (gebucht, noch nicht begonnen) → arrived → triaged (Notaufnahmen) → in-progress → onleave (stationär auf vorübergehendem Urlaub) → finished. cancelled und entered-in-error beenden sie anderweitig; unknown existiert für Importe. statusHistory speichert die früheren Zustände mit ihren Zeiträumen, sodass ein Krankenhausaufenthalt zeigt, wann der Patient ankam, wann er aufgenommen wurde und wann er entlassen wurde. Beachten Sie, dass eine Encounter keine Appointment ist: Die Appointment ist die Buchung; wenn der Patient ankommt, wird eine Encounter erstellt, die über appointment darauf verweist.
Klasse: das Setting
Die class des Encounters stammt aus dem HL7 v3 ActCode-System: AMB ambulant (ambulant), IMP stationär, EMER Notfall, HH häusliche Krankenpflege, VR virtuell (Telemedizin), ACUTE und NONAC für stationäre Untertypen, OBSENC Beobachtung, PRENC Voraufnahme, SS Kurzaufenthalt. classHistory erfasst Überweisungen, zum Beispiel eine Notfallbehandlung, die zu einer Aufnahme wurde.
Die anderen Elemente
Über Status und Klasse hinaus enthält ein FHIR Encounter Typ und serviceType (welche Art von Besuch und welche Leistung), Teilnehmer (Ärzte mit ihren Rollen und Zeiträumen), reasonCode oder reasonReference, Diagnose (verknüpfte Conditions mit Nutzung und Rang), Hospitalisierung (Aufnahme- und Entlassungsdetails), Ortsangaben im Laufe der Zeit, Länge, serviceProvider und partOf für Unter-Encounters.
- type und serviceType geben die Art der Encounter und die Leistungslinie (Kardiologie, Diabetesberatung) an, mit länderspezifischen Codes.
- participant listet Kliniker und andere mit einem Teilnahmetyp (Aufnahmeger, Behandler, Hauptleister, Berater, Überweiser) und dem Zeitraum, in dem jeder beteiligt war.
- reasonCode / reasonReference geben den Grund für den Besuch an; diagnosis verknüpft die festgestellten oder behandelten Conditions mit einem
use(Aufnahmediagnose AD, Entlassungsdiagnose DD, Hauptbeschwerde CC, Komorbidität CM, Abrechnung) und einemrank. Siehe FHIR Condition erklärt. - hospitalization enthält Aufnahmedetails:
admitSource(Überweisung vom Hausarzt, Notfall, Verlegung),dischargeDisposition(nach Hause, in ein anderes Krankenhaus, verstorben),preAdmissionIdentifier, Diät und spezielle Vorkehrungen. - location listet die Orte mit ihrem Status im Laufe der Zeit auf (geplant, aktiv, reserviert, abgeschlossen); eine Verlegung auf eine Station fügt einen neuen Eintrag hinzu.
- length ist die Dauer; serviceProvider die verantwortliche Organisation; partOf verknüpft eine Unter-Encounter (einen Stationsaufenthalt) mit der Aufnahme, zu der sie gehört.
Was sich in R5 geändert hat
FHIR R5 benannte Encounter.hospitalization in admission um, fasste reasonCode und reasonReference zu reason zusammen, machte class zu einer Liste von CodeableConcept (ein Encounter kann mehrere Klassifizierungen haben), verschob participant.individual zu actor und führte EncounterHistory als separate Ressource für Status- und Klassenhistorie ein. R4 bleibt die Version in US Core und den meisten nationalen Leitfäden; siehe FHIR R4 vs R5.
Mapping von HL7 v2
HL7 v2 ADT-Nachrichten werden nach Ereignistyp auf FHIR Encounter abgebildet: A01 admit erstellt einen stationären Encounter im Status 'in progress', A03 discharge beendet ihn mit period.end und Entlassungsstatus, A02 transfer fügt einen Orts-Eintrag hinzu, A04 registriert einen ambulanten Encounter und A08 aktualisiert ihn. Die meisten Daten stammen aus dem PV1-Segment, dessen Besuchsnummer zum Encounter.identifier wird.
Ein ADT^A01 (Aufnahme) erstellt eine Encounter mit der Klasse IMP und dem Status in-progress; A03 (Entlassung) setzt den Status auf finished und füllt period.end und dischargeDisposition; A02 (Verlegung) fügt einen location-Eintrag hinzu; A04 (Registrierung ambulanter Patient) erstellt eine AMB-Encounter; A08 aktualisiert sie. PV1 enthält die meisten Daten (Patientenklasse in PV1-2, Ort in PV1-3, behandelnder Arzt in PV1-7, Besuchsnummer in PV1-19, die zu Encounter.identifier wird). Siehe HL7 v2 Nachrichten erklärt.
In Anpheros
Die Anpheros Platform erstellt FHIR Encounter-Ressourcen auf zwei Arten: Kliniken schreiben sie über die API, und der eigene protokollierte Besuch einer Person wird zu einem abgeschlossenen Encounter, sobald der Termin stattgefunden hat. Ergebnisse, Dokumente und Notizen von diesem Besuch verweisen auf den Encounter, sodass der Datensatz von der Person und von jeder Klinik, mit der sie ihn teilt, von Besuch zu Besuch gelesen werden kann.
In der App gebuchte Termine sind Appointment-Ressourcen, bis sie stattfinden.
Verwandte Seiten
- FHIR Condition erklärt
- FHIR Patient Ressource erklärt
- HL7 v2 Nachrichten erklärt: ADT und ORU
- FHIR R4 vs R5
- FHIR DiagnosticReport erklärt
- Encounter Beispiel auf der Entwicklerseite
Quellen
- 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
Häufige Fragen
Was ist der Unterschied zwischen Encounter und Appointment?
Eine Appointment ist die Buchung eines zukünftigen Zeitfensters; eine Encounter ist die Interaktion, die tatsächlich stattgefunden hat (oder stattfindet). Wenn der Patient ankommt, wird die Encounter erstellt und verweist auf die Appointment.
Ist ein Krankenhausaufenthalt eine Encounter oder viele?
Normalerweise eine Encounter für die Aufnahme, mit Standortangaben für jede Station und classHistory für Änderungen des Settings. Einige Systeme erstellen Unter-Encounters pro Stationsaufenthalt, die über partOf verknüpft sind; nationale Leitfäden geben an, welche.
Wo kommt die Entlassungszusammenfassung hin?
Als DocumentReference oder als FHIR-Dokument, dessen Composition die Encounter referenziert. Die Encounter selbst enthält die Entlassungsdisposition und die Daten, nicht die narrative Darstellung.
Benötigt jede Observation eine Encounter?
Nein. Beobachtungen, die der Patient zu Hause aufzeichnet oder die von einem Wearable kommen, haben keine Encounter. Diejenigen, die während eines Besuchs durchgeführt werden, sollten darauf verweisen, damit der Datensatz nach Besuch gelesen werden kann.
Kostenlos in der Sandbox testen
Ihr erster FHIR-Aufruf in 5 Minuten. Eine HL7 FHIR R4 API mit der Zustimmung des Patienten: probieren Sie sie in der Sandbox aus und verbinden Sie dann Ihre eigene App oder Ihr Kliniksystem.
Kostenlos · 30 synthetische Patienten · keine Karte
Anpheros entwickelt eine Patientenakte, die der Patient kontrolliert und mit jeder Klinik teilen kann, auf einer HL7 FHIR R4-Plattform mit Sitz in der EU. Diese Anleitungen helfen Ihnen, Ihre Gesundheit zu verstehen und zu organisieren; sie ersetzen nicht Ihren Arzt.
Über Anpheros →