Aufnahmegrund nach § 301 Abs. 3 SGB V. Dieser gehört zu den 'Medizinischen Daten des Behandlungsfalls' entsprechend der Definitionen für die Datenübermittlung nach § 301 Abs. 3 SGB V. Somit sind diese über den Kontakt und nicht über den Abrechnungsfall zu dokumentieren. Diese Extension SOLLTE am ersten Abteilungskontakt, der die stationäre Aufnahme repräsentiert, dokumentiert werden. Wird durch den Encounter ein Einrichtungskontakt repräsentiert, SOLLTE dort zusätzlich zu dem Abteilungskontakt der Aufnahmegrund dokumentiert werden.

1. und 2. Stelle des Aufnahmegrunds nach § 301 Abs. 3 SGB V.

3. Stelle des Aufnahmegrunds nach § 301 Abs. 3 SGB V.

4. Stelle des Aufnahmegrunds nach § 301 Abs. 3 SGB V.

Hier ist stets der Wert http://terminology.hl7.org/CodeSystem/v2-0203 anzugeben.

Hier ist stets der Wert VN anzugeben.

Hier ist stets der eindeutige Name (URL) des Namensraums anzugeben, aus dem der Identifier stammt. Hinweise zur Festlegung der URLs für lokale Namensräume sind in den Deutschen Basisprofilen beschrieben.
Begründung Pflichtfeld: system stellt in Kombination mit value die Eindeutigkeit eines Identifiers sicher.

Enthält den eigentlichen Wert des Identifiers.
Begründung Pflichtfeld: Ist der Wert nicht bekannt, sollte der gesamte Slice weggelassen werden.

Zeigt den aktuellen Status der Ressource an.
WICHTIGER Hinweis für Implementierer:

• Alle server-seitigen Implementierungen MÜSSEN in der Lage sein, die systemintern möglichen Statuswerte korrekt in FHIR abzubilden, mindestens jedoch die Werte in-progress, finished und cancelled.
• Alle client-seitigen Implementierungen MÜSSEN in der Lage sein, sämtliche Status-Codes zu interpretieren und dem Anwender in angemessener Form darstellen zu können, beispielsweise durch Ausblenden/Durchstreichen von Ressourcen mit dem status entered-in-error und Ausgrauen von Ressourcen, die einen Plan- oder Entwurfs-Status haben.
  Historie: Die Reduktion der zulässigen Status-Werte im Vergleich zur FHIR-Kernspezifikation erfolgt im Vorgriff auf eine entsprechende Anpassung in FHIR R5.

Die Klassifikation von Encountern nach Fallarten folgt den internationalen Vorgaben und dient der groben Unterscheidung von Besuchen mit und ohne Bettendisposition (ambulant/stationär). Die in Deutschland übliche Fallklassifikation anhand von unterschiedlichen regulatorischen und abrechnungrelevanten Rahmenbedingungen, erfolgt in type.
Für ein korrektes Mapping der in Deutschland gebräuchlichen Fallarten auf class siehe Deutsche Basisprofile

Begründung Pflichtfeld: Die Abteilungsebene muss aus Kompatibilitätsgründen angegeben werden.

**Hinweis bei Abbildung von Versorgungsstellenkontakten:**

Es ist ein üblicher Fall, dass die Dauer eines Versorgungsstellenkontaktes in der Versorgung die eines Abteilungskontaktes übersteigt. Ein Beispiel hierfür: Ein Patient bleibt im Bett (Versorgungsstellenkontakt), aber ein Fachabteilungswechsel geschieht, da die Diagnose über eine Fachabteilung (Onkologie) läuft, dann aber der Wechsel zur Fachabteilung Chirurgie (neuer Abteilungskontakt) notwendig wird. Für einen solchen Fall gilt auf Ebene der FHIR-Instanzen (z.B. entgegen des tatsächliche Aufenthaltes im gleichen Bett): Im Falle eines Fachabteilungswechsels legt ein System einen neuen Abteilungskontakt an. Bestehende Versorgungsstellenkontakt SOLLEN NICHT in ihrer Relation (.partOf) zum Abteilungskontakt modifiziert werden. Hingegen SOLL das System einen oder mehrere Versorgungsstellenkontakte erzeugen und mit dem neu angelegten Abteilungskontakt in Verbindung setzen.

Hintergrund: Das Konzept der 'Kontaktebene' stammt aus dem Fallmodell der Medizininformatik-Initiative, das bei Encountern zwischen 'Einrichtungskontakten', 'Fachabteilungskontakten' und 'Versorgungsstellenkontakten' unterscheidet. Im Kontext dieses Moduls werden lediglich Encounter der Ebene 'Fachabteilungskontakt' abgebildet.

Hier ist stets der Wert http://fhir.de/CodeSystem/Kontaktebene anzugeben.

Hier ist stets der Wert abteilungskontakt anzugeben.

Die Kontaktart dient der feingranularen Differenzierung unterschiedlicher stationärer und ambulanter Fallarten gemäß der in Deutschland üblichen regulatorischen und abrechnungsrelevanten Rahmenbedingungen.
Für ein korrektes Mapping der in Deutschland gebräuchlichen Fallarten auf type siehe Deutsche Basisprofile

Hier ist stets der Wert http://fhir.de/CodeSystem/kontaktart-de anzugeben.

vorstationaer | nachstationaer | begleitperson | tagesklinik | +

Fachabteilungen gemäß Anhang 1 der BPflV

Fachabteilungen gemäß Anhang 1 der BPflV inkl. Spezialisierungen

Begründung Pflichtfeld: Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.

Begründung und Einschränkung des Must Support: Dieses Element dient der Verknüpfung mit einem Termin (Appointment) aus dem entsprechenden ISiK Modul und - darauf aufbauend - der Dokumentenkommunikation. Das Element 'appointment' SOLL für den im Folgenden geschilderten Fall implementiert werden. Andernfalls KANN es entfallen.

Die Anforderung einer Verknüpfung mit einem Appointment stammt aus dem Szenario der Dokumentenübertragung zwischen Patientenportal und krankenhaus-internem Primärsystem (z.B. KIS) im Kontext einer Terminbuchung: Dokumente liegen bei Terminbuchung erst im Patientenportal (im Appointment) vor und werden erst mit Anlage des Encounters in das KIS (etc.) übermittelt. Dazu SOLL ein Primärsystem zu Beginn des Termins das Appointment mit dem neu angelegten Encounter verknüpfen, um die Dokumente aus dem Patientenportal darüber vermittelt zuordnen zu können (ausgenommen hiervon sind Termine, die nicht stattfinden, da für diese in der Regel keine Encounter angelegt werden).

Über die Referenz auf Appointment KÖNNEN Patientenportale den Fallbezug aus dem Termin ermitteln und Dokumente an ein KIS senden.

Hieraus folgt, dass das Element nur relevant ist, falls das bestätigungsrelevante System zusätzlich zum vorliegenden Profil (Encounter) das Profil ISiKTermin (Appointment) implementiert.

Hinweis: Zur Umsetzung der Funktionalität zum Dokumentenaustausch gemäß ISiK ist der entsprechende Implementation Guide zum Modul Dokumentenaustausch zu beachten.

WICHTIGER Hinweis für Implementierer:

• Das Aufnahmedatum MUSS angegeben werden, wenn der status des Encounters impliziert, dass dieser bereits begonnen hat.
• Das Entlassdatum MUSS angegeben werden, wenn der status des Encounters impliziert, dass dieser beendet ist.
  Siehe hierzu die Übersicht der Invarianten in diesem Profil.

Hier ist stets das tatsächliche Aufnahmedatum anzugeben. Geplante Aufnahmedaten müssen über die Extension plannedStartDate erfasst werden.

Hier ist stets das tatsächliche Entlassdatum anzugeben. Geplante Entlassdaten müssen über die Extension plannedEndDate erfasst werden.

Begründung Pflichtfeld: Die Verlinkung auf die Condition/Procedure-Ressource dient der technischen Zuordnung des Encounters zur Condition/Precedure und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.

Bedeutung der Diagnose/Prozedur im Encounter-Kontext

International standardisierte, grobgranulare Unterscheidung zwischen extern gestellten Diagnosen (referral-diagnosis) und intern gestellten Diagnosen (treatment-diagnosis)

An deutschen Kodierrichtlinien orientierte, feingranulare Unterscheidung von Diagnose-Rollen, z.B. "Fachabteilungshauptdiagnose", "Todesursache" etc.

Der Bezug zu einem Account stellt den Abrechnungskontext für einen oder mehrere Encounter her. Mittels der Account-Referenz können zum Beispiel ein vorstationärer, ein stationärer und ein nachstationärer Besuch zu einem 'DRG-Fall' zusammengefasst werden.
WICHTIGER Hinweis für Implementierer: Im Deutschen Sprachgebrauch ist unter dem Begriff 'Fall' meist der Abrechnungskontext gemeint, nicht der einzelne Besuch. Die 'Fallnummer' ist daher nicht der Identifier des Encounters, sondern der des Accounts auf den der Encounter referenziert. Auf diesem Wege können mehrere Besuche einer Fallnummer zugeordnet werden.
Da die Fallnummer ein häufig verwendetes Suchkriterium darstellt, ist diese hier als logische Referenz (account.identifier) zu hinterlegen. Damit wird sichergestellt, dass diese als Suchparameter für die Suche nach Encountern zur Verfügung steht, auch wenn einzelne Systeme kein Chaining unterstützen oder einzelne Benutzer keine Sichtberechtigung auf Abrechnungsdaten haben, im Versorgunskontext aber dennoch Encounter anhand der assoziierten Fallnummer suchen möchten.

Begründung MS: Die Verlinkung auf eine Account-Ressource dient der technischen Zuordnung des Besuchs zu einem Abrechnungskontext und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.

Hier ist stets der eindeutige Name (URL) des Namensraums anzugeben, aus dem der Identifier stammt. Hinweise zur Festlegung der URLs für lokale Namensräume sind in den Deutschen Basisprofilen beschrieben.
Begründung Pflichtfeld: system stellt in Kombination mit value die Eindeutigkeit eines Identifiers sicher.

Enthält den eigentlichen Wert des Identifiers.
Begründung Pflichtfeld: Ist der Wert nicht bekannt, sollte der gesamte Slice weggelassen werden.

Details zu einem stationären Aufenthalt

Begründung MS: Vom Patienten gebuchte Wahlleistungen (z.B. Chefarztbehandlung, Einzelzimmer) sind häufig system- und abteilungsübergreifend zu beachten und sollten daher über die Schnittstelle kommuniziert werden können.

Anlass der stationären Aufnahme, z.B. "Einweisung", "Notfall" etc.
Begründung MS: Zur Harmonisierung den Festlegungen der Medizininformatik-Initiative

Entlassungsgrund nach § 301 Abs. 3 SGB V
Einschränkung MS: Der Entlassungsgrund muss nur implementiert werden, wenn das bestätigungsrelevante System in der Akutversorgung eingesetzt wird.

Entlassungsgrund nach §301 (Abs. 4 und 4a) SGB V
Einschränkung MS: Der Entlassungsgrund Reha muss nur implementiert werden, wenn das bestätigungsrelevante System in der Reha-Versorgung eingesetzt wird

Begründung MS: Die Verlinkung auf eine Location-Ressource dient der technischen Zuordnung des Besuchs zu einem Aufenthaltsort und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.

Hier ist stets der eindeutige Name (URL) des Namensraums anzugeben, aus dem der Identifier stammt. Hinweise zur Festlegung der URLs für lokale Namensräume sind in den Deutschen Basisprofilen beschrieben.
Begründung Pflichtfeld: system stellt in Kombination mit value die Eindeutigkeit eines Identifiers sicher.

Enthält den eigentlichen Wert des Identifiers.
Begründung Pflichtfeld: Ist der Wert nicht bekannt, sollte der gesamte Slice weggelassen werden.

Hier ist stets der Wert http://terminology.hl7.org/CodeSystem/location-physical-type anzugeben.

Hier ist stets der Wert ro anzugeben.

Begründung MS: Die Verlinkung auf eine Location-Ressource dient der technischen Zuordnung des Besuchs zu einem Aufenthaltsort und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.

Hier ist stets der eindeutige Name (URL) des Namensraums anzugeben, aus dem der Identifier stammt. Hinweise zur Festlegung der URLs für lokale Namensräume sind in den Deutschen Basisprofilen beschrieben.
Begründung Pflichtfeld: system stellt in Kombination mit value die Eindeutigkeit eines Identifiers sicher.

Enthält den eigentlichen Wert des Identifiers.
Begründung Pflichtfeld: Ist der Wert nicht bekannt, sollte der gesamte Slice weggelassen werden.

Die Kodierung in diesem Slice entstammt folgendem Valueset - gelistet unter .location.(All slices.)physicalType: https://gematik.de/fhir/isik/ValueSet/ISiKLocationPhysicalType

Hier ist stets der Wert http://terminology.hl7.org/CodeSystem/location-physical-type anzugeben.

Hier ist stets der Wert bd anzugeben.

Begründung MS: die Kenntnis des aktuellen Aufenthaltsortes ist häufig systemübergreifend relevant (z.B. für Küchen- und Logistiksysteme) und sollte daher über die Schnittstelle kommuniziert werden können.

Begründung MS: Die Verlinkung auf eine Location-Ressource dient der technischen Zuordnung des Besuchs zu einem Aufenthaltsort und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.

Hier ist stets der eindeutige Name (URL) des Namensraums anzugeben, aus dem der Identifier stammt. Hinweise zur Festlegung der URLs für lokale Namensräume sind in den Deutschen Basisprofilen beschrieben.
Begründung Pflichtfeld: system stellt in Kombination mit value die Eindeutigkeit eines Identifiers sicher.

Enthält den eigentlichen Wert des Identifiers.
Begründung Pflichtfeld: Ist der Wert nicht bekannt, sollte der gesamte Slice weggelassen werden.

Hier ist stets der Wert http://terminology.hl7.org/CodeSystem/location-physical-type anzugeben.

Hier ist stets der Wert wa anzugeben.