🐛 [BUG] - Im CapabilityStatement wird der Account nicht (!) als pflicht angegeben, ist in Titus aber nicht abwählbar

[simoneOnFhir]

Description

Laut CS ist Account nicht verpflichtend (wird gar nicht erwähnt!!)
Wir haben die Verlinkung über die Logical Reference im Encounter auch extra so modelliert (IIRC), dass der Account in Stufe 2 zunächst mal optional bleiben kann.

Dennoch ist das Testszenario in Titus nicht abwählbar
Betrifft Stufe 2 und 3 von Basis.

Reproduction URL

https://simplifier.net/guide/implementierungsleitfadenisik-basismodul/ImplementationGuide-markdown-CapabilityStatement?version=current

Version or Branch

No response

Reproduction Steps

...

Stack Trace and Logs

No response

Screenshots

![DESCRIPTION](LINK.png)

Software and Environment

No response

Tasks

Preview Give feedback

1. PTDATA-663

[simoneOnFhir]

[f-peverali]

@alexey-tschudnowsky kannst du das übernehmen?

[MaxMTheilig]

Der Account wird in mehreren Interaktionen (z.B. "Encounter:account" Reference SHALL) als verpflichtend angegeben.
Und auch der IG sagt explizit, dass Account Read implementiert werden MUSS: https://simplifier.net/guide/implementierungsleitfadenisik-basismodul/ImplementationGuide-markdown-Datenobjekte-Datenobjekte-Abrechnungsfall?version=current

Also im ersten Schritt glaube ich erstmal, dass Titus das richtig umsetzt. Jetzt müssten wir nochmal schauen, was da im CP potenziell fehlt

[simoneOnFhir]

In Encounter.account ist nur die Fallnummer als Identifier (also die logische Referenz) verpflichtend, die Verlinkung auf den Account ist optional.

[simoneOnFhir]

Ich bin mir jetzt ehrich gesagt nicht sicher, was es heißt, wenn in der Beschreibung einer Ressource READ als SHALL angegeben ist, aber im CS nicht. Ich würde das interpretieren als "wenn ein System die Ressource unterstützt, dann muss auf jeden Fall die READ-Interaktion bereitgestellt werden", was nicht zwangsläufig impliziert, dass die Ressource unterstützt werden muss.

[MaxMTheilig]

Also die Beschreibung im IG ist wohl nur als der Vollständigkeit halber und als Klarstellung anzusehen - Ich vermute da könnte auch nichts stehen und das Profile Account wäre streng genommen trotzdem normativ.
Die Intention des Gesetzgebers ist klar, dass abgestimmte und veröffentlichte Profile einer ISiK Stufe durch die jeweils bestätigungsrelevanten System auch umzusetzen sind. In dem Detailgrad, der über die MS-Flag, SHALLs, MAYs usw
definiert wird. Also dass die ganze Ressourcen nicht unterstützt wird, das sehe ich in dem aktuellen Konstrukt nicht gegeben.

An der Verbesserung der IGs arbeiten wir ja jetzt in Stufe 4 auch schon (wäre für mich nochmal nachgelagert zu Korrektur des CP).

[simoneOnFhir]

Es wäre nicht das erste mal, dass eine Ressource nicht verpflichtend umzusetzen ist. Im CapabilityStatement geben wir an, was verpflichtend ist und was optional ist.
Dass wir nicht alle KIS-Hersteller zur Implementierung aller Resourcen verpflichten können ist schlicht der Tatsache geschuldet, dass es keine klare Definition gibt, was ein "KIS" ist und welche Funktionalitäten es bereitstellen muss. Manche KISse sind nur für die Abrechnung zuständig, manche nur für die klinische Dokumentation, manche für alles beide. Manche haben eine Fieberkurve, manche nicht. Manche verwalten Dokumente, manche nicht.

[simoneOnFhir]

Wenn ich mich richtig erinnere (aber dazu würde ich gerne nochmal die Meinung von @alexzautke hören, wenn er aus dem Urlaub zurück ist), war es Anno 2021 nicht unsere Intention, Account für alle verpflichtend zu machen, eben aufgrund der Erkenntnis, das KIS-Systeme mal Abrechnungsysteme sein können aber auch mal reine klinische Dokumentationssysteme. Aus dem selben Grund haben wir im Encounter.account.reference auf 0..1 gesetzt und nur Encounter.account.identifier verpflichtend gemacht. Der Hintergrund ist, der, dass die Gruppierung von Encountern zu einem "Fall" in allen Systemen üblich ist, unabhängig von der Abrechnungsrelevanz. Ebenso muss die Möglichkeit, Encounter anhand der Fallnummer zu suchen, flächendeckend verfügbar sein. Was jedoch nicht zwingend notwendig ist, ist dass ein System, was mit Abrechnung nichts am Hut hat, die Details der Abrechnung eines Falles kennen muss. Das Mitführen der Fallnummer ist daher verpflichtend, das Verlinken auf einen Account jedoch nicht.

AUch hier mein Hinweis, dass das CapabilityStatement nicht verbos genug ist, um Aussagen wie: "man muss den Account nur implementieren, wenn man ein KIS-System ist, das Abrechnungsdaten verwaltet, dann aber mindestens die READ-Interaktion).

Früher hatten wir dazu unter "Bestätigungsrelevante Systeme" eine tabellarische Liste, die all das ausgesagt hat, was das CapabilityStatement nicht differenzieren kann, aber diese wurde offenbar durch das Statement der DKG ersetzt.

[f-peverali]

Früher hatten wir dazu unter "Bestätigungsrelevante Systeme" eine tabellarische Liste, die all das ausgesagt hat, was das CapabilityStatement nicht differenzieren kann, aber diese wurde offenbar durch das Statement der DKG ersetzt.

womöglich hier der letzte Stand dazu - über folgende commit ID unter UebergreifendeFestlegungen-Bestätgung... ? f0781aa83833ed16e492a92fb1804b3f071a6841 - für Stufe 2 steht dort "Ausschlaggebend für den Umfang der zu zertifizierenden Datenobjekte sind die Funktionalitäten der jeweiligen Systeme: ... | Abrechnungsfall (Account)| alle |"

Für Stufe 1 (Stand nach commit ID: bade0a3) war der Abrechnungsfall nicht gelistet

[simoneOnFhir]

Jaa genau, die Tabelle meinte ich! Dass Account in Stufe 1 noch nicht gelistet ist, macht Sinn, den gab's damals noch gar nicht, der kam erst in Stufe 2 dazu. Aus der Tabelle geht aber klar die Aussage hervor, dass der Account für ALLE verpflichtend zu imlementieren ist. Durch die Ersetzung mit den Festlegungen der DKG ging diese Info dann leider verloren...

[f-peverali]

Dann sollten wir das so auch beibehalten und im Testing nicht zurückrudern. Würde aber die Seite im IG nochmal umarbeiten, sodass auch die detaillierteren Anforderungen auf Profil-Ebene wieder einsehbar sind. FYI @MaxMTheilig , @alexey-tschudnowsky

[f-peverali]

Ich eröffne einen PR im Sinne eines Fixes. Prüfe in dem Zuge die Tabellen-Anforderungen zu CP und passe letzteren entsprechend an.

[f-peverali]

@simoneOnFhir ggf. könnten wir das Thema allgemeiner fassen - "Abbildung ambulanter Prozesse im Krankenhauskontext" - und auch im Zusammenhang mit dem Topic Organization angehen? Das würde den Scope gegenüber der ursprünglichen Intention erweitern, könnte aber der Klarheit dienen, siehe : #326

[ylboerner]

Done: #334