Zasób FHIR Encounter – wyjaśnienie z przykładem

Krótka odpowiedź: Encounter (wizyta/zdarzenie medyczne) to jedno spotkanie pacjenta z systemem opieki zdrowotnej: wizyta ambulatoryjna, pobyt w szpitalu, przyjęcie na izbie przyjęć, konsultacja wideo, wizyta domowa. Rejestruje kiedy (period), w jakim miejscu/kontekście (class: ambulatoryjna, stacjonarna, nagła, domowa, wirtualna), jej status (zaplanowana → w trakcie → zakończona), kto brał w niej udział, dlaczego (reasonCode) i co zdiagnozowano (diagnosis, powiązane z Warunkami zdrowotnymi). Obserwacje, procedury, zlecenia leków i dokumenty wskazują na Encounter, do którego należą, co pozwala na czytanie historii choroby wizyta po wizycie.

Prawidłowy przykład FHIR R4

Prawidłowy zasób FHIR R4 typu Encounter wymaga jedynie statusu i klasy, ale użyteczny zasób zawiera również temat, okres, typ, uczestników, powód oraz zdiagnozowane choroby. Poniższy przykład to zakończona konsultacja ambulatoryjna dotycząca cukrzycy typu 2, z głównym wykonawcą, diagnozą główną jako pierwszą, lokalizacją i odpowiedzialną organizacją.

{
  "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: cykl życia

Status zasobu FHIR Encounter przechodzi przez zaplanowany, przybył, wstępnie oceniony, w toku, na urlopie i zakończony, z anulowanym, wprowadzonym błędem i nieznanym jako pozostałe zakończenia. Element statusHistory przechowuje każdy wcześniejszy stan z jego okresem, dzięki czemu pobyt w szpitalu pokazuje, kiedy pacjent przybył, został przyjęty i opuścił placówkę. Encounter to sama interakcja, a nie wizyta, która ją zarezerwowała.

planned (zarezerwowana, jeszcze nie rozpoczęta) → arrived → triaged (na izbie przyjęć) → in-progress → onleave (pacjent na przepustce ze szpitala) → finished. cancelled i entered-in-error kończą ją inaczej; unknown występuje przy imporcie danych. statusHistory przechowuje wcześniejsze stany wraz z ich okresami, dzięki czemu pobyt w szpitalu pokazuje, kiedy pacjent przybył, kiedy został przyjęty i kiedy opuścił szpital. Należy pamiętać, że Encounter to nie to samo co Appointment (wizyta/termin): Appointment to rezerwacja terminu; gdy pacjent przybywa, tworzony jest Encounter, który się do niego odwołuje poprzez appointment.

Klasa: kontekst/miejsce

Klasa Encounter pochodzi z systemu kodów HL7 v3 ActCode: AMB ambulatoryjna (poza szpitalem), IMP szpitalna, EMER nagła, HH opieka domowa, VR wirtualna (telemedycyna), ACUTE i NONAC dla podtypów szpitalnych, OBSENC obserwacja, PRENC przed przyjęciem, SS krótki pobyt. classHistory rejestruje transfery, na przykład przyjęcie nagłe, które stało się przyjęciem szpitalnym.

Pozostałe elementy

Poza statusem i klasą, FHIR Encounter zawiera typ i serviceType (jaki rodzaj wizyty i jaka linia usług), uczestnika (lekarzy z ich rolami i okresami), reasonCode lub reasonReference, diagnozę (powiązane Warunki z użyciem i rangą), hospitalizację (szczegóły przyjęcia i wypisu), wpisy lokalizacji w czasie, długość, serviceProvider i partOf dla pod-spotkań.

type i serviceType określają rodzaj wizyty i linię usług (kardiologia, edukacja diabetologiczna), z kodami różniącymi się w zależności od kraju.
participant wymienia lekarzy i inne osoby z typem udziału (osoba przyjmująca, lekarz prowadzący, główny wykonawca, konsultant, osoba kierująca) oraz okres, w którym każda z nich była zaangażowana.
reasonCode / reasonReference podają powód wizyty; diagnosis łączy zdiagnozowane lub leczone Warunki zdrowotne, z use (diagnoza przyjęcia AD, diagnoza wypisu DD, główna dolegliwość CC, choroba współistniejąca CM, rozliczenie) i rank (rangą). Zobacz Wyjaśnienie FHIR Condition.
hospitalization zawiera szczegóły przyjęcia do szpitala: admitSource (skierowanie od lekarza rodzinnego, nagły przypadek, transfer), dischargeDisposition (do domu, do innego szpitala, zgon), preAdmissionIdentifier, dietę i specjalne ustalenia.
location wymienia miejsca z ich statusem w czasie (zaplanowane, aktywne, zarezerwowane, zakończone); zmiana oddziału dodaje nowy wpis.
length to czas trwania; serviceProvider to odpowiedzialna organizacja; partOf łączy pod-wizytę (pobyt na oddziale) z przyjęciem, do którego należy.

Co się zmieniło w R5

FHIR R5 zmienił nazwę Encounter.hospitalization na admission, połączył reasonCode i reasonReference w reason, uczynił class listą CodeableConcept (spotkanie może mieć kilka klasyfikacji), przeniósł participant.individual do actor i wprowadził EncounterHistory jako osobny zasób dla historii statusu i klasy. R4 pozostaje wersją w US Core i większości krajowych przewodników; zobacz FHIR R4 vs R5.

Mapowanie z HL7 v2

Wiadomości HL7 v2 ADT są mapowane na FHIR Encounter według typu zdarzenia: A01 przyjęcie tworzy Encounter szpitalny w toku, A03 wypis kończy go z okresem.end i dyspozycją wypisu, A02 transfer dodaje wpis lokalizacji, A04 rejestruje Encounter ambulatoryjny, a A08 go aktualizuje. Większość danych pochodzi z segmentu PV1, którego numer wizyty staje się Encounter.identifier.

ADT^A01 (przyjęcie) tworzy Encounter z klasą IMP i statusem in-progress; A03 (wypis) ustawia status finished i wypełnia period.end oraz dischargeDisposition; A02 (transfer) dodaje wpis location; A04 (rejestracja pacjenta ambulatoryjnego) tworzy Encounter AMB; A08 go aktualizuje. PV1 zawiera większość danych (klasa pacjenta w PV1-2, lokalizacja w PV1-3, lekarz prowadzący w PV1-7, numer wizyty w PV1-19, który staje się Encounter.identifier). Zobacz Wyjaśnienie komunikatów HL7 v2.

W Anpheros

Platforma Anpheros tworzy zasoby FHIR Encounter na dwa sposoby: kliniki zapisują je przez API, a zalogowana wizyta osoby staje się zakończonym Encounterem po odbyciu się wizyty. Wyniki, dokumenty i notatki z tej wizyty odnoszą się do Encounteru, dzięki czemu rekord może być czytany wizyta po wizycie przez osobę i przez każdą klinikę, z którą się dzieli.

Wizyty zarezerwowane w aplikacji to zasoby Appointment, dopóki się nie odbędą.

Powiązane strony

Źródła

Najczęstsze pytania

Jaka jest różnica między Encounter a Appointment?

Appointment to rezerwacja przyszłego terminu; Encounter to interakcja, która faktycznie miała miejsce (lub ma miejsce). Kiedy pacjent przybywa, tworzony jest Encounter i odwołuje się on do Appointment.

Czy pobyt w szpitalu to jeden Encounter czy wiele?

Zazwyczaj jeden Encounter dla przyjęcia, z wpisami lokalizacji dla każdego oddziału i classHistory dla zmian miejsca. Niektóre systemy tworzą pod-Encounters dla pobytów na oddziałach, powiązane przez partOf; krajowe przewodniki określają, które.

Gdzie trafia podsumowanie wypisu?

Jako DocumentReference lub dokument FHIR, którego Composition odwołuje się do Encounter. Sam Encounter zawiera informacje o dyspozycji wypisu i datach, a nie opis narracyjny.

Czy każda Obserwacja wymaga Encounter?

Nie. Obserwacje, które pacjent rejestruje w domu lub które pochodzą z urządzenia noszonego, nie mają Encounter. Te wykonane podczas wizyty powinny się do niej odwoływać, aby można było odczytać historię choroby według wizyt.

Anpheros Platform

Wypróbuj za darmo w sandboksie

Pierwsze wywołanie FHIR w 5 minut. API HL7 FHIR R4 z wbudowaną zgodą pacjenta: wypróbuj w piaskownicy, a następnie połącz własną aplikację lub system kliniczny.

Utwórz darmowy sandbox Przeczytaj przewodniki dla programistów →

Za darmo · 30 syntetycznych pacjentów · bez karty

Ten poradnik ma charakter informacyjny i nie zastępuje konsultacji lekarskiej. Decyzje dotyczące zdrowia podejmuj z lekarzem. W nagłym wypadku zadzwoń pod lokalny numer alarmowy (112 w Europie).

Napisane przez

Zespół Anpheros

Anpheros tworzy dokumentację medyczną, nad którą pacjent ma kontrolę i którą może udostępniać dowolnej klinice, na platformie HL7 FHIR R4, z siedzibą w UE. Te przewodniki pomogą Ci zrozumieć i uporządkować informacje o Twoim zdrowiu; nie zastępują one wizyty u lekarza.

O Anpheros →