<StructureDefinition xmlns="http://hl7.org/fhir">
  <url value="https://simplifier.net/ziv-schnittstellen/ziv_kontakt" />
  <name value="ZIV_Kontakt" />
  <status value="active" />
  <description value="Der ZIV_Kontakt basiert auf dem isik v4 Profil ISiKTerminKontaktMitGesundheitseinrichtung und spezialisiert sich dabei auf die trennung relevanter Informationen für Patient und Klinikseite." />
  <fhirVersion value="4.0.1" />
  <kind value="resource" />
  <abstract value="false" />
  <type value="Encounter" />
  <baseDefinition value="https://gematik.de/fhir/isik/StructureDefinition/ISiKTerminKontaktMitGesundheitseinrichtung" />
  <derivation value="constraint" />
  <differential>
    <element id="Encounter.extension:Aufnahmegrund">
      <path value="Encounter.extension" />
      <sliceName value="Aufnahmegrund" />
      <comment value="Aufnahmegrund nach § 301 Abs. 3 SGB V.&#xD;&#xA;&#xD;&#xA;Hinweis: Relevant für den Patienten. Klinik kann entscheiden, ob die Informationen an den Patienten weitergegeben werden soll." />
    </element>
    <element id="Encounter.extension:plannedStartDate">
      <path value="Encounter.extension" />
      <sliceName value="plannedStartDate" />
      <definition value="Optional Extension Element - found in all resources.&#xD;&#xA;ZIV: Für Klinik und Patient einsehbar." />
      <comment value="There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions.  The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.&#xD;&#xA;&#xD;&#xA;Für Patienten zählt beim Kontakt nur der tatsächliche und nicht der geplante Zeitraum, daher wird dies in Period (start|end) festgelegt und kann darüber dem Patienten zur Verfügung gestellt werden." />
    </element>
    <element id="Encounter.extension:plannedEndDate">
      <path value="Encounter.extension" />
      <sliceName value="plannedEndDate" />
      <definition value="Optional Extension Element - found in all resources.&#xD;&#xA;ZIV: Für Klinik und Patient einsehbar." />
    </element>
    <element id="Encounter.status">
      <path value="Encounter.status" />
      <definition value="planned | arrived | triaged | in-progress | onleave | finished | cancelled +.&#xD;&#xA;ZIV: Für Klinik und Patient einsehbar." />
    </element>
    <element id="Encounter.statusHistory">
      <path value="Encounter.statusHistory" />
      <definition value="The status history permits the encounter resource to contain the status history without needing to read through the historical versions of the resource, or even have the server store them.&#xD;&#xA;ZIV: Für Klinik und Patient einsehbar." />
    </element>
    <element id="Encounter.class">
      <path value="Encounter.class" />
      <definition value="Concepts representing classification of patient encounter such as ambulatory (outpatient), inpatient, emergency, home health or others due to local variations.&#xD;&#xA;ZIV: Für Klinik und Patient einsehbar." />
      <comment value="Die Klassifikation von Encountern nach Fallarten folgt den internationalen Vorgaben und &#xA;  dient der groben Unterscheidung von Besuchen mit und ohne Bettendisposition (ambulant/stationär). &#xA;  Die in Deutschland übliche Fallklassifikation anhand von unterschiedlichen &#xA;  regulatorischen und abrechnungrelevanten Rahmenbedingungen, erfolgt in `type`.  &#xA;  Für ein korrektes Mapping der in Deutschland gebräuchlichen Fallarten auf `class` siehe [Deutsche Basisprofile](https://simplifier.net/guide/leitfaden-de-basis-r4/ig-markdown-Ressourcen-AmbulanterStationaererFall?version=current)&#xD;&#xA;&#xD;&#xA;Hinweis: Relevant für den Patienten. Klinik kann entscheiden, ob die Informationen an den Patienten weitergegeben werden soll." />
    </element>
    <element id="Encounter.classHistory">
      <path value="Encounter.classHistory" />
      <definition value="The class history permits the tracking of the encounters transitions without needing to go  through the resource history.  This would be used for a case where an admission starts of as an emergency encounter, then transitions into an inpatient scenario. Doing this and not restarting a new encounter ensures that any lab/diagnostic results can more easily follow the patient and not require re-processing and not get lost or cancelled during a kind of discharge from emergency to inpatient.&#xD;&#xA;ZIV: Für Klinik und Patient einsehbar." />
    </element>
    <element id="Encounter.type">
      <path value="Encounter.type" />
      <definition value="Specific type of encounter (e.g. e-mail consultation, surgical day-care, skilled nursing, rehabilitation).&#xD;&#xA;ZIV: Für Klinik und Patient einsehbar." />
    </element>
    <element id="Encounter.subject">
      <path value="Encounter.subject" />
      <definition value="The patient or group present at the encounter.&#xD;&#xA;ZIV: Nur relevant einsehbar, wenn der Kontakt für eine andere Person verwaltet wird" />
    </element>
    <element id="Encounter.episodeOfCare">
      <path value="Encounter.episodeOfCare" />
      <definition value="Where a specific encounter should be classified as a part of a specific episode(s) of care this field should be used. This association can facilitate grouping of related encounters together for a specific purpose, such as government reporting, issue tracking, association via a common problem.  The association is recorded on the encounter as these are typically created after the episode of care and grouped on entry rather than editing the episode of care to append another encounter to it (the episode of care could span years).&#xD;&#xA;ZIV: Für Klinik und Patient einsehbar." />
    </element>
    <element id="Encounter.participant">
      <path value="Encounter.participant" />
      <definition value="The list of people responsible for providing the service.&#xD;&#xA;ZIV: Kann für Patient einsehbar sein, wenn von Klinik gewünscht." />
      <comment value="Im Rahmen der Implementierung sollte entschieden werden, ob Informationen zu den Teilnehmern dem Patienten zur Verfügung gestellt werden." />
    </element>
    <element id="Encounter.appointment">
      <path value="Encounter.appointment" />
      <comment value="**Hinweis:**  Zur Umsetzung der Funktionalität zum Dokumentenaustausch gemäß ISiK ist der entsprechende [Implementation Guide zum Modul Dokumentenaustausch](https://simplifier.net/guide/isik-dokumentenaustausch-v4?version=current) zu beachten.&#xA;  &#xA;  Begründung Must Support: Die Referenz auf Appointment ermöglicht Portalen den Fallbezug aus dem Termin zu ermitteln und Dokumente an ein KIS zu senden. Das Element 'appointment' ist Must-Support, um sicherzustellen, dass ein Termin immer abrufbar ist, sofern er mit einem Fallkontaktverknüft ist.&#xD;&#xA;&#xD;&#xA;Auf Patientenseite sollte die Verknüpfung immer zusammengeführt werden zwischen Termin und Kontakt, wenn beides gegeben." />
    </element>
    <element id="Encounter.period">
      <path value="Encounter.period" />
      <definition value="The start and end time of the encounter.&#xD;&#xA;ZIV: Für Klinik und Patient einsehbar." />
      <comment value="**WICHTIGER Hinweis für Implementierer:** &#xA;  * Das Aufnahmedatum  MUSS angegeben werden, &#xA;  wenn der `status` des Encounters impliziert, dass dieser bereits begonnen hat.&#xA;  * Das Entlassdatum MUSS angegeben werden, &#xA;  wenn der `status` des Encounters impliziert, dass dieser beendet ist.  &#xA;  Siehe hierzu die Übersicht der Invarianten in diesem Profil. &#xD;&#xA;&#xD;&#xA;Hinweis: Relevant für den Patienten. Klinik kann entscheiden, ob die Informationen an den Patienten weitergegeben werden soll." />
    </element>
    <element id="Encounter.period.start">
      <path value="Encounter.period.start" />
      <comment value="Hier ist stets das *tatsächliche* Aufnahmedatum anzugeben.&#xA;    *Geplante* Aufnahmedaten müssen über die Extension `plannedStartDate` erfasst werden.&#xD;&#xA;&#xD;&#xA;Hinweis: Relevant für den Patienten. Klinik kann entscheiden, ob die Informationen an den Patienten weitergegeben werden soll." />
    </element>
    <element id="Encounter.period.end">
      <path value="Encounter.period.end" />
      <comment value="Hier ist stets das *tatsächliche* Entlassdatum anzugeben.&#xA;    *Geplante* Entlassdaten müssen über die Extension `plannedEndDate` erfasst werden.&#xD;&#xA;&#xD;&#xA;Hinweis: Relevant für den Patienten. Klinik kann entscheiden, ob die Informationen an den Patienten weitergegeben werden soll." />
    </element>
    <element id="Encounter.reasonReference">
      <path value="Encounter.reasonReference" />
      <comment value="For systems that need to know which was the primary diagnosis, these will be marked with the standard extension primaryDiagnosis (which is a sequence value rather than a flag, 1 = primary diagnosis).&#xD;&#xA;&#xD;&#xA;Sollte intern geklärt werden, ob die Aufnahmediagnose an den Patienten weitergeleitet werden soll oder nicht." />
    </element>
    <element id="Encounter.account">
      <path value="Encounter.account" />
      <comment value="Der Bezug zu einem Account stellt den Abrechnungskontext für einen oder mehrere Encounter her.&#xA;  Mittels der Account-Referenz können zum Beispiel ein vorstationärer, ein stationärer &#xA;  und ein nachstationärer Besuch zu einem 'DRG-Fall' zusammengefasst werden.  &#xA;  **WICHTIGER Hinweis für Implementierer:** Im Deutschen Sprachgebrauch ist unter dem Begriff 'Fall' &#xA;  meist der Abrechnungskontext gemeint, nicht der einzelne Besuch. Die 'Fallnummer' ist daher nicht der Identifier des Encounters, &#xA;  sondern der des Accounts auf den der Encounter referenziert. &#xA;  Auf diesem Wege können mehrere Besuche einer Fallnummer zugeordnet werden.  &#xA;  Da die Fallnummer ein häufig verwendetes Suchkriterium darstellt, &#xA;  ist diese hier als logische Referenz (`account.identifier`) zu hinterlegen.&#xA;  Damit wird sichergestellt, dass diese als Suchparameter für die Suche nach Encountern zur Verfügung steht, &#xA;  auch wenn einzelne Systeme kein Chaining unterstützen oder einzelne Benutzer keine Sichtberechtigung auf Abrechnungsdaten haben,&#xA;  im Versorgunskontext aber dennoch Encounter anhand der assoziierten Fallnummer suchen möchten.&#xD;&#xA;&#xD;&#xA;Account Ressourcen werden im ZIV-Kontext nicht definiert, da die Abrechnung für Patienten irrelevenat ist. Daher werden Verknüpfungen zu Account in ZIV immer leer sein." />
    </element>
    <element id="Encounter.hospitalization">
      <path value="Encounter.hospitalization" />
      <comment value="Details zu einem stationären Aufenthalt&#xD;&#xA;&#xD;&#xA;Für Patient nicht relevant." />
    </element>
    <element id="Encounter.location">
      <path value="Encounter.location" />
      <definition value="List of locations where  the patient has been during this encounter.&#xD;&#xA;&#xD;&#xA;ZIV: Für Klinik und Patient einsehbar." />
    </element>
    <element id="Encounter.serviceProvider">
      <path value="Encounter.serviceProvider" />
      <definition value="The organization that is primarily responsible for this Encounter's services. This MAY be the same as the organization on the Patient record, however it could be different, such as if the actor performing the services was from an external organization (which may be billed seperately) for an external consultation.  Refer to the example bundle showing an abbreviated set of Encounters for a colonoscopy.&#xD;&#xA;ZIV: Für Klinik und Patient einsehbar." />
    </element>
  </differential>
</StructureDefinition>