Die Deutschen Kodierrichtlinien und die 'German Modification' ermöglichen es teilweise, ICD-10-Codierte Diagnosen miteinander zu verknüpfen ("Kreuz-Stern-Ausrufezeichen-Notation"), diese aber dennoch wie eigenständige Diagnosen (mit jeweils eigener Diagnosesicherheit oder -Lokalisation) zu kommunizieren. Daher ist es in Deutschland nicht möglich, dem internationalen Usus zu folgen und verknüpfte Diagnosen als postkoordinierten Code einer Condition-Ressource aufzufassen. Statt dessen müssen sie zwei eigenständige Condition-Ressourcen abgebildet werden, die mit Hilfe der related-Extension miteinander verknüpft werden.
Die Sekundärdiagnose verweist jeweils auf die Primärdiagnose.

Begründung MS: Auch in Stufe 4 sind keine (client-seitigen) schreibenden Operationen für das Erstellen einer Condition-Ressource vorgesehen (siehe CapabilityStatement). Das heißt, entweder führen KISe entsprechende Informationen und exponieren diese, oder es gibt keinen pragmatischen Mechanismus (im ISIK-Kontext), um den Use Case einer zusätzlichen Annotation mittels Client zu erfüllen. Da alle KIS-Hersteller, die sich zu Wort gemeldet haben, eine Befüllung von Condition.clinicalStatus NICHT unterstützen, erscheint das MS nach übergreifender Definition und ein verpflichtender Testfall nicht angemessen.
Einschränkung der übergreifenden MS-Definition: Verfügt ein bestätigungsrelevantes System nicht über die Datenstruktur zur Hinterlegung des Status einer Diagnose, so MUSS dieses System die Information NICHT abbilden. Das System MUSS jedoch clinicalStatus befüllen, sofern die entsprechende Information verfügbar ist.
Hinweis: Für Diagnosen aus der ambulanten Versorgung können die Werte für clinicalStatus und verificationStatus aus dem ICD-10-Zusatzkennzeichen für die Diagnosesicherheit abgeleitet werden. Das entsprechende Mapping kann den Deutschen Basisprofilen entnommen werden.

Diagnosen SOLLEN mindestens entweder mit einem der angebenen standardisierten Codier-Verfahren codiert werden. Ist keine Codierung möglich, MUSS statt dessen eine textuelle Beschreibung der Prozedur angegeben werden.
Begründung Pflichtfeld: Ist weder eine Codierung noch eine textuelle Beschreibung vorhanden, besitzt diese Ressource keine medizinische Aussagefähigkeit.

Begründung MS: Harmonisierung mit KBV-Profil (KBV_PR_Base_Condition_Diagnosis)

Begründung Must-Support: Ein Patientenbezug der Diagnose MUSS stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.

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 Must-Support: Ein Aufenthaltsbezug der Diagnose MUSS stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.

Begründung Pflichtfeld: Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.
WICHTIGER Hinweis für Implementierer: Die Zuordnung MUSS auf auf einen Encounter der Ebene "Abteilungskontakt" (siehe hierzu Abbildung des Konstrukts "Fall") erfolgen. Bei der Auswahl des Encounters ist zu beachten, dass unter einer (Abrechnungs-)"Fallnummer" (hier: Encounter.account) unter Umständen mehrere Encounter gruppiert sein können (z.B. stationärer Besuch mit mehreren vor- und nachstationären Aufenthalten.)

Datum oder Alter/Lebensphase des Erkrankungsbeginns Begründung MS: Die Kenntnis des Erkrankungszeitraumes ist wichtig für die korrekte Einschätzung der medizinischen Relevanz einer Erkraknung.
Einschränkung der übergreifenden MS-Definition: Verfügt ein bestätigungsrelevantes System nicht über die Datenstruktur zur Hinterlegung des Erkrankungszeitraumes, so MUSS dieses System die Information NICHT abbilden. Das System MUSS jedoch klinischen Status (active/inactive/resolved...) der Diagnose korrekt angeben, sofern die Information verfügbar ist.

Datum oder Alter/Lebensphase des Erkrankungsendes
Begründung MS: Die Kenntnis des Erkrankungszeitraumes ist wichtig für die korrekte Einschätzung der medizinischen Relevanz einer Erkraknung.
Einschränkung der übergreifenden MS-Definition: Verfügt ein bestätigungsrelevantes System nicht über die Datenstruktur zur Hinterlegung des Erkrankungszeitraumes, so MUSS dieses System die Information NICHT abbilden. Das System MUSS jedoch klinischen Status (active/inactive/resolved...) der Diagnose korrekt angeben, sofern die Information verfügbar ist.

Datum, an dem die Diagnose dokumentiert wurde.
Begründung Pflichtfeld: Das Dokumentationsdatum der Diagnose MUSS zu Qualitätssicherungszwecken angegeben werden. Dies ist das fachliche Dokumentationsdatum, nicht zu verwechseln mit der technischen Anlage des Datensatzes im Primärsystem. Diese beiden Daten können jedoch identisch sein.
Hinweis: Das Recorded Date MUSS mindestens auf den Monat genau angegeben werden.

Ergänzende Hinweise und Anmerkungen zur Diagnose