Profil Kontakt

Ziel

Aufgabe ist die Abbildung der Kontakte zwischen Patienten und klinischen Einrichtungen. Dafür wird aufgenommen wann der Patient in welcher Abteilung wie versorgt wurde (Prozeduren) und warum (Diagnose(n)).

Die Ressource Kontakt umfasst daher, neben stationären Aufenthalten auch ambulante Besuche, sowie virtuelle oder telemedizinische Kontakte. In einer Patienten-App hilft diese Ressource dabei den Behandlungsverlauf (in Form der Behandlungskontakte) für den Patienten nach zu verfolgen.

Wichtig ist hierbei, den Kontakt abzugrenzen vom (DRG-)Abrechnungsfall, der gemäß ISiK als Account abgebildet wird, und dem Medizinischen Fall, der als "EpisodeOfCare" dargestellt wird.

Verwendetes FHIR-Profil

Für die Profilierung des Kontakts mit einer Gesundheitseinrichtung wird die ISiK Stufe 4 Definition ISiKTerminKontaktMitGesundheitseinrichtung als Basis verwendet. https://simplifier.net/isik-terminplanung-v4/isikterminkontaktmitgesundheitseinrichtung

Orientierung an Encounter der ISiK und Verknüpfung mit ISiK appointment. https://simplifier.net/guide/isik-basis-v4/ImplementationGuide-markdown-Datenobjekte-Datenobjekte_Kontakt?version=current

Kompatibilität

Die hier abgebildete Ressource ist in beide Richtungen kompatibel zur ISiK-Encounter-Ressource v4.

ZIV-Profil Kontakt

Unterschiede zu MII

• alle extension und modifier raus, bis auf die ganz oben im Encounter

1. meta (Metadaten zur Ressource): entfernt, da Metadaten zur Ressource für den Patienten nicht wichtig sind

2. extension

   → Aufnahmegrund mit aufnehmen: in Simplifier von MII Fall (aber nicht im Snapshot)

3. identifier

   → Aufnahmenummer: extension raus, da nicht wichtig für den Patienten

   → Aufnahmenummer → type: extension raus, da nicht in MII

   → Aufnahmenummer → type → coding: kann entfernt werden, wenn nur die Sicht des Patienten berücksichtig wird. Diesen interessiert das Terminologiesystem nicht

   → Aufnahmenummer → type → coding → extension: raus, da nicht in MII

   → Aufnahmenummer → type → text: auf 1..1 gesetzt da es für den Menschen lesbar sein sollte

   → Aufnahmenummer → assigner→extension: raus, um klare Definitionen zu haben (könnte genutzt werden…)

   → Aufnahmenummer → period: extension raus, da nicht in MII

   → Aufnahmenummer → period: start und end zusätzlich zu MII, da reales Datum als Nachschlagewerk für Patienten dienen kann

4. statusHistory:

   status History → period → extension raus, da nicht in MII

5. class→extension: raus, da nicht in MII

6. class History

   → period → extension raus, da nicht in MII

7. type

   →Kontakteben→ extension raus, da nicht in MII

   →KontaktArt→ extension raus, da nicht in MII

8. serviceType

   →coding → extension: raus, da nicht in MII

   →text: auf must support, weil Menschen lesbar wichtig für Patienten

9. priority→ raus: da nicht alle Terminologien zu diesem Muster passen

10. subject

    →reference: dazu da in Simplifier Profil

    →type: dazu da in Simplifier Profil

    →identifier: dazu da in Simplifier Profil

    →display: dazu da in Simplifier Profil

11. episodeOfCare

    →reference: dazu da in Simplifier Profil

    →type: dazu da in Simplifier Profil

    →identifier: dazu da in Simplifier Profil

    →display: dazu da in Simplifier Profil

12. basedON

    →reference: dazu da in Simplifier Profil

    →type: dazu da in Simplifier Profil

    →identifier: dazu da in Simplifier Profil

    →display: dazu da in Simplifier Profil

13. participant

14. appointment\n→reference: dazu da in Simplifier Profil\n→type: dazu da in Simplifier Profil

    →identifier: dazu da in Simplifier Profil

    →display: dazu da in Simplifier Profil

15. period

16. length mit allen Unterpunkten raus

17. reasonCode → raus da Aufnahmegrund bereits in neuer Extension enthalten und nicht doppelt (evtl. entscheiden beim Validieren welche Position besser ist, für extension entschieden wegen Must Flag)

18. reasonReference →abgedeckt durch diagnosis daher raus

19. diagnosis

    →condition→use→coding-text: auf must Support, damit damit lesbar für Patienten

20. account→ nicht wichtig aus Patientensicht

21. hospitalization

22. localization

    → must Flag in Forge hinzugefügt, da auch im MII Snapshot

23. serviceProvider

24. partOf

Beobachtung: dass Snapshot auf MII Seite, nicht immer mit Forge Profil übereinstimmt. Hier ist das Forge Profil oft detaillierter.

Beispiel-FHIR-Ressource —> Encounter

https://hl7.org/fhir/R4/encounter-example-f201-20130404.json.html

{
  "resourceType": "Encounter",
  "id": "f201",
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Generated Narrative with Details</b></p><p><b>id</b>: f201</p><p><b>identifier</b>: Encounter_Roel_20130404 (TEMP)</p><p><b>status</b>: finished</p><p><b>class</b>: ambulatory (Details: http://terminology.hl7.org/CodeSystem/v3-ActCode code AMB = 'ambulatory', stated as 'ambulatory')</p><p><b>type</b>: Consultation <span>(Details : {SNOMED CT code '11429006' = 'Consultation', given as 'Consultation'})</span></p><p><b>priority</b>: Normal <span>(Details : {SNOMED CT code '17621005' = 'Normal', given as 'Normal'})</span></p><p><b>subject</b>: <a>Roel</a></p><h3>Participants</h3><table><tr><td>-</td><td><b>Individual</b></td></tr><tr><td>*</td><td><a>Practitioner/f201</a></td></tr></table><p><b>reasonCode</b>: The patient had fever peaks over the last couple of days. He is worried about these peaks. <span>(Details )</span></p><p><b>serviceProvider</b>: <a>Organization/f201</a></p></div>"
  },
  "identifier": [
    {
      "use": "temp",
      "value": "Encounter_Roel_20130404"
    }
  ],
  "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"
        }
      ]
    }
  ],
  "priority": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "17621005",
        "display": "Normal"
      }
    ]
  },
  "subject": {
    "reference": "Patient/f201",
    "display": "Roel"
  },
  "participant": [
    {
      "individual": {
        "reference": "Practitioner/f201"
      }
    }
  ],
  "reasonCode": [
    {
      "text": "The patient had fever peaks over the last couple of days. He is worried about these peaks."
    }
  ],
  "serviceProvider": {
    "reference": "Organization/f201"
  }
}

Organisatorische Regelungen für die Befüllung des FHIR-Profils

Herausforderungen

1. Wann sollte ein Kontakt dokumentiert werden? Kurzkontakt macht weder für den Patienten noch für die klinische Dokumentation Sinn (z.B. Abholung eines Rezepts). \nWann ist eine Kontakt ein Kontakt? *Beispiele: 1) Bei Corona kann selbst kurze Begegnung relevant sein 2) Pfleger fragt auf dem Gang wie es Patient aktuell geht.

2. Überschneidungen zu Termin vermeiden.

3. Klinik intern muss entschieden werden welche Informationen zu Participants an den Patienten weitergegeben werden (Datenschutz).

4. Klare Referenzierungen zwischen Beteiligten im Kontakt notwendig.

Lösungen

1. Klinikintern muss bspw. durch SOPs festgelegt werden, wann ein Kontakt die nötige Relevanz hat um dokumentiert zu werden.

2. Abgrenzung des Falls zu Termin durch Fokus auf den Behandlungspfad (Kontakte in der Klinik). Aus diesem Grund wird bspw. kein Behandler im Kontakt eingetragen. Kontakt in Behandlungskontext, aber ohne Termin möglich. Fallüberschneidung zu Termin vermeiden, da Kontakte auch ohne vorherigen Termin stattfinden können.

3. Klinikintern muss bspw. durch SOPs festgelegt werden, welche klinischen Informationen zum Kontakt an den Patienten weitergeleitet werden sollen/dürfen, zum Beispiel welche Pflegekräfte und ÄrztInnen involviert waren (Element participant).

4. Klinikintern muss festgelegt werden, ob Patienten den Aufnahmegrund (der in der Regel der Überweisungsdiagnose bzw. Aufnahmediagnose entspricht) weitergeleitet werden müssen. (Element ResonCode bzw. ReasonReference)

5. Account-Ressourcen (Abrechnungs-Fall) sind im ZIV-Kontext nicht definiert, entsprechende Verweise sind daher im Regelfall leer.

6. Der Fall sollte egal ob als Kontakt oder Behandlungsfall auf die Patientin / den Patienten, Diagnosen und Prozeduren verweisen.

Validierungsregeln

Technische FHIR-Validierung

Die Validierung einer gesendeten FHIR-Ressource erfolgt gegenüber dem ZIV-Profil, indem die Ressourcen-Struktur auf ZIV-Konformität überprüft wird. Konkret muss überprüft werden, ob alle Datenelemente mit Pflichtfeld oder mustSupport-Flag in der Ressource vorhanden sind oder ob nicht zugelassene Datenelemente existieren.

Die Validierung erfolgt via Simplifier, da darüber das Profil spezifiziert ist.

Organisatorische Validierung

Solange die o.g. SOPs eingehalten werden, ist keine organisatorische Validierung notwendig.

Die Klinik muss dafür Sorge tragen, dass die in diesen Feldern eingetragenen Daten korrekt sind.

Kliniken können sich in Abhängigkeit vom Durchsetzungsgrad der SOPs einigen, stichprobenhafte Kontrollen der Korrektheit der ausgefüllten Elemente im KIS durchzuführen.

Beschreibung eines Anwendungsszenarios

Ein Use Case für die Ressource Fall (Encounter) könnte beispielsweise eine Darmspiegelung als Früherkennung in der Darmkrebsvorsorge sein, die in einer Klinikambulanz durchgeführt wird.

Dass der Einsatz von Apps z.B. in der Vorbereitung auf die Darmspiegelung die Effektivität der Koloskopie steigert, konnte bereits in der ColoprAPP Studie des Universitätsklinikums Ulm aufgezeigt werden. Eine Dokumentation des Behandlungsverlaufs in Form von Behandlungskontakten würde es dem Patienten ermöglichen seine Behandlung noch detaillierter zu verfolgen und einen weiteren Baustein im Patienten Empowerment bilden.

Beispiel für den Use Case Darmspiegelung - Datenobjekt

{
  "resourceType": "Encounter",
  "id": "patient-001",
  "extension": [
{
  "url": "https://www.medizininformatik-initiative.de/fhir/core/modul-fall/StructureDefinition/Aufnahmegrund",
  "extension": [
      {
          "url": "ErsteUndZweiteStelle",
          "valueCodeableConcept": {
              "coding": [
                  {
                      "system": "http://snomed.info/sct",
                      "code": "185389009",
                      "display": "Screening for malignant neoplasm of colon (procedure)"
                  }
              ],
              "text": "Screening colonoscopy"
          }
      },
      {
          "url": "DritteStelle",
          "valueCodeableConcept": {
              "coding": [
                  {
                      "system": "http://example.org/fhir/CodeSystem/aufnahmegrund-dritte-stelle",
                      "code": "01",
                      "display": "First diagnosis"
                  }
              ],
              "text": "Primary diagnosis"
          }
      },
      {
           "url": "VierteStelle",
          "valueCodeableConcept": {
              "coding": [
                  {
                      "system": "http://example.org/fhir/CodeSystem/aufnahmegrund-vierte-stelle",
                      "code": "001",
                      "display": "Preventive screening"
                  }
              ],
              "text": "Screening procedure"
          }
      }
      ]
  }
  ],
  "identifier":  [
      {
          "system": "http://hospital-xyz.de/encounters",
          "value": "ENC-2025-00001"
      }
  ],
  "status": "finished",
  "class": {
      "code": "AMB",
      "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
      "display": "ambulatory"
  },
  "type": [
      {
          "coding": [
              {
                  "system": "http://snomed.info/sct",
                  "code": "73761001",
                  "display": "Colonoscopy"
              }
          ],
          "text": "Colonoscopy procedure"
      }
  ],
  "serviceType": {
      "coding": [
          {
              "system": "https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Fachabteilungsschluessel",
              "code": "0100",
              "display": "Innere Medizin"
          }
      ],
      "text": "Internal Medicine I – Gastroenterology"
  },
  "subject": {
      "reference": "Patient/patient-001"
  },
  "episodeOfCare": [
      {
          "reference": "EpisodeOfCare/episode-gastroenterology-001",
          "display": "Gastroenterology diagnostic episode"
      }
  ],
  "appointment": [
      {
          "reference": "Appointment/appointment-colonoscopy-001"
      }
  ],  
  "period": {
      "start": "2025-05-26T10:00:00+02:00",
      "end": "2025-05-26T10:30:00+02:00"
  },
  "diagnosis": [
      {
          "condition": {
              "reference": "Condition/polyp"
          },
          "use": {
              "coding": [
                  {
                      "code": "AD",
                      "system": "http://terminology.hl7.org/CodeSystem/diagnosis-role",
                      "display": "Admission diagnosis"
                  }
              ]
          } 
      }
  ],
  "hospitalization": {
      "admitSource": {
          "coding": [
                  {  
                  "code": "gp",
                  "system": "http://terminology.hl7.org/CodeSystem/admit-source",
                  "display": "General Practitioner referral"
              }
          ],
          "text": "Referral by GP for colorectal screening"
      },
      "dischargeDisposition": {
          "coding": [
              {
                  "code": "home",
                  "system": "http://terminology.hl7.org/CodeSystem/discharge-disposition",
                  "display": "Discharged to home"
              }
          ],
          "text": "Patient monitored post-procedure and discharged home"
      }
  },
  "location": [
      {
          "location": {
          "reference": "Location/location-001",
          "display": "Endoscopy Unit – Internal Medicine I"
      },
      "status": "completed",
      "period": {
          "start": "2025-05-26T10:00:00+02:00",
          "end": "2025-05-26T10:30:00+02:00"
      },
    "physicalType": {
      "coding": [
              {
              "system": "http://terminology.hl7.org/CodeSystem/location-physical-type",
              "code": "ro",
              "display": "Room"
              }
          ]
      }
      }
  ],
  "serviceProvider": {
      "reference": "Organization/hospital-xyz",
      "display": "University Hospital XYZ"
  },
  "partOf": {
      "reference": "Encounter/enc-outpatient-episode-001",
      "display": "Outpatient visit on 2025-05-26"
  }
}

Beschreibung der Elemente und Implementierungshilfen

Hier finden Sie nochmal eine kurze Erklärung zu einigen der verwendeten Datenelemente:

Wir empfehlen in Ihren FHIR Profilen die Verwendung von display oder text als hilfreiche Zusammenfassungen für Ihre Elemente, insbesondere für User Interfaces, Dashboards, oder FHIR viewers.

Encounter.class: gibt das Setting an, in dem die Gesundheitsdienstleistung erbracht wurde. Der Klassenwert gewährleistet die korrekte Klassifizierung für die Analyse des Versorgungsumfelds, die Abrechnung und die Interoperabilität zwischen den Systemen.

• system: Das class Element in der FHIR Encounter Ressource verwendet Codes aus dem HL7 ActCode System, um das Setting darzustellen, in dem die Gesundheitsleistung erbracht wurde (z.B. stationär, ambulant, Notfall).
  • code: Häufig verwendete Codes für das Klassenelement:

\
\

Encounter.type: gibt die klinische Art der Begegnung aus der Sicht des Verfahrens oder des Leistungserbringers an

• der im Beispiel verwendete Code stammt aus dem SNOMED CT Terminologiesystem und steht für Koloskopie
• die Aufnahme des Feldes verbessert die semantische Klarheit der Begegnung
• Encounter.type vs Encounter.reasonCode:
  • type beschreibt, um welche Art von Begegnung es sich handelt (z.B. eine Prozedur oder eine diagnostische Leistung)
  • reasonCode beschreibt, warum die Begegnung stattgefunden hat (z.B. Screening, Symptome)

Encounter.serviceType:

• Der Code 0100 steht für "Innere Medizin". Da das Kodierungssystem nicht Subkategorien wie beispielsweise Gastroenterologie aufschlüsselt, können Sie das Textfeld für weitere Spezifizierungen verwenden wie z.B. "Innere Medizin I - Gastroenterologie". Wenn Ihre Einrichtung lokale interne Unterabteilungscodes verwendet, können Sie eine zusätzliche Kodierung mit einem lokalen System hinzufügen.

"serviceType": {
    "coding": [
    {
        "system": "https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Fachabteilungsschluessel",
        "code": "0100",
        "display": "Innere Medizin"
    },
    {
        "system": "http://your-hospital.org/departments",
        "code": "IM1-GASTRO",
        "display": "Internal Medicine I – Gastroenterology"
    }
    ],
    "text": "Internal Medicine I – Gastroenterology"
}

Encounter.subject: Bezieht sich auf den Patienten, der im Mittelpunkt der Begegnung steht

• In der FHIR Encounter Ressource verlinkt das subject Element über eine FHIR-Referenz auf eine Patienten-Ressource

Patient resource

{
"resourceType": "Patient",
"id": "1",
"name": [
    {
    "use": "official",
    "family": "Mustermann",
    "given": ["Maximilian"]
    }
]
} 

Diese Patienten Ressource wird im in der Encounter Ressource über reference dargestellt:

Reference in Encounter

"subject": {
"reference": "Patient/patient-001",
"display": "Maximilian Mustermann"
}

Encounter.episodeOfCare: verknüpft die Begegnung mit einer umfassenderen Versorgungsepisode (EpisodeOfCare Ressource), z.B. einem Behandlungsprozess, der unter einem klinischen oder administrativen Dach verwaltet wird. Auf diese Weise können mehrere Begegnungen (z.B. Konsultation, pro-operative Behandlung, Eingriff, Nachsorge) unter einer kohärenten Versorgungsepisode zusammengefasst werden. Die reference verweist also auf die EpisodeOfCare Resource

EpisodeOfCare Ressource

{
"resourceType": "EpisodeOfCare",
"id": "episode-gastro-2025",
"status": "active",
"type": [
    {
    "coding": [
        {
        "system": "http://snomed.info/sct",
        "code": "408478003",
        "display": "Gastroenterology service"
        }
    ]
    }
],
"patient": {
    "reference": "Patient/patient-001"
}
}

Bestandteil episodeOfCare in der Encounter Ressource

"episodeOfCare": [
{
    "reference": "EpisodeOfCare/episode-gastro-2025",
    "display": "Colonoscopy screening process"
}
]

Encounter.appointment:

• reference: verweist auf die Ressource Appointment

Encounter.period: Definiert den Zeitraum in der die Begegnung tatsächlich statt gefunden hat. Das Element period spiegelt also den realen Versorgungszeitpunkt wider.

• start: das genaue Datum und die Uhrzeit, zu der die Behandlung begann (z.B. der Patient aufgenommen wurde, sich anmeldete oder mit dem Verfahren begonnen wurde). Dieses Element ist in der Regel erforderlich.
• end: das genaue Datum und die Uhrzeit, zu der die Behandlung abgeschlossen wurde. Dieser Teil kann bei laufenden Begegnungen weggelassen werden.
• FHIR verwendet das ISO 8601 Datums-Zeit Format mit optionalen Zeitzoneninformationen.
  • Beispiel: 2025-05-26T10:00:00+02:00 bedeutet:
    • Datum: 26 Mai 2025
    • Zeit: 10:00 Uhr
    • Zeitzone: +02:00 (Central European Summer Time, z.B. Deutschland)

Encounter.diagnosis: verweist auf eine oder mehrere Condition Ressourcen, die relevante klinische Probleme beschreiben. Wir empfehlen für die Ressource Condition, die Verwendung von SNOMED CT oder ICD-10 Codes (im oben genannten Beispiel wurde ein Polyp gefunden).

• condition: verweis auf eine Condition Ressource
• use: beschreibt die Rolle der Diagnose
  • Mögliche values sind:

• Zusätzlich kann noch ein rank dem use Element hinzugefügt werden, der die numerische Priorität beschreibt (Primärdiagnose = 1, Sekundärdiagnose = 2)

Encounter.hospitalization:

• wird in der Regel nur für stationäre Aufenthalte verwendet, wenn die Begegnung also eine Krankenhauseinweisung beinhaltet.

  • Beispiel Darmspiegelung: die Begegnung ist stationär (class = IMP) im Falle einer Darmspiegelung unter Sedierung auf einer internistischen Station

• Wenn der Patient nicht stationär aufgenommen wird, aber er Eingriff formale Aufnahmeprozesse beinhaltet (z.B. Check-in, Vorbereitung vor dem Eingriff, Überwachung danach), kann das Element hospitalization dennoch verwendet werden, um logische Details zu dokumentieren, allerdings in vereinfachter Form

• admitSource: beschreibt woher der Patient eingewiesen wurde, also den administrativen Ursprung der Begegnung. FHIR bietet einen Standardsatz an Codes für diesen Wert: http://terminology.hl7.org/CodeSystem/admit-source

  • Beispiele:

• dischargeDisposition: beschreibt den Zustand des Patienten und sein Ziel am Ende der Untersuchung
  • Verwenden Sie nach Möglichkeit Standard FHIR Codes und ergänzen diese mit Text für zusätzlichen Kontext (z.B. mit Anweisungen zur häuslichen Pflege)

• Verwenden Sie dischargeDisposition nur, wenn es einen formalen Entlassungsprozess gibt

Encounter.location: Aufzeichnung des tatsächlichen oder beabsichtigten Ortes, an dem die Begegnung stattgefunden hat

• reference: Verweis auf eine FHIR Location Ressource (z.B. Einrichtung, Krankenhausstation, Zimmer)
  • Verlinken Sie idealerweise eine vollständige FHIR-Standortressource mit Metadaten wie Adresse, Typ, verwaltender Organisation
• status: gibt an, ob der Patient aktuell dort befindet (active) oder befunden hat (completed)
  • Fügen Sie mehrere Ortseinträge hinzu mit dem jeweiligen Zeitraum, wenn der Patient das Zimmer oder die Station wechselt. Verwenden Sie status = active für den aktuellen Standort und completed für frühere Standorte
• period: Zeitraum, in dem sich der Patient während der Begegnung an diesem Ort aufhielt
• physicalType: Art des Ortes (z.B. Zimmer, Bett, Gebäude). Diese Verwendung ist optional, wir empfehlen bei Verwendung jedoch die Anwendung von SNOMED CT Codes

Encounter.serviceProvider: gibt die Organisation an, die für die Begegnung verantwortlich ist. Dies ist in der Regel ein Krankenhaus, eine Klinik oder eine Praxis, in der die Behandlung erbracht wurde

• reference: verlinkt FHIR Ressource Organization

Encounter.partOf: wird verwendet, wenn es sich bei der Begegnung um eine Unterbegegnung oder einen Bestandteil einer anderen Begegnung handelt, z.B. eine Prozedur-Begegnung als Teil eines längeren stationären Aufenthalts.

• reference: verlinkt einen weiteren FHIR Ressource Encounter, wenn der abgebildete Encounter ein Subset ist