add Requirement ANFISK-126 #328

[f-peverali]

Description

Neue Anforderung zum Use Case: Versorgungstellenkontakt geht über den Zeitraum eine Abteilungskontaktes hinaus

Motivation and Context

Das Szenario ist üblich und sollte daher abgedeckt werden. Bisher keine Festlegung dazu
löst ANFISK-126

How has this been tested?

Kein Test dazu, soll in 2.AG Basis (und ggf. asynchchron über diesen PR kommentiert werden)

Snippets or Screenshots (if necessary):

Types of changes

• New feature (non-breaking change which adds functionality)
• es handelt es sich nicht um einen Breaking change, da nur "SOLLTE", daher (für diese Stuge) auch nicht zu testen

Checklist:

• My code follows the code style of this IG / specification.
• I have already updated the documentation / narrative (intend) accordingly.
• ggf. zu prüfen ob an diesem Beispiel auch neues Metatext Format zur Kennzeichnung für Anforderungen?

[f-peverali]

FYI @MaxMTheilig vorab für AG gerne deine Meinung einbringen

[f-peverali]

FYI @ylboerner gerne auch von Dir Feedback und Meinung dazu vor der AG

[ylboerner]

@f-peverali Ich habe mich mal etwas eingelesen, hier meine Meinung: Der Lösungsvorschlag sowie Text passen gut. Die Hersteller können dann selbst wählen, welches Konstrukt sie verwenden wollen. Wir müssen aber unbedingt das Feedback der Hersteller abwarten.

Verbesserungsmöglichkeit: Ich würde den Text eher im Abschnitt 'Motivation' ansiedeln, da er auch die Beweggründe erläutert und direkt auf den anderen Abschnitten aufbaut.

[f-peverali]

Verbesserungsmöglichkeit: Ich würde den Text eher im Abschnitt 'Motivation' ansiedeln, da er auch die Beweggründe erläutert und direkt auf den anderen Abschnitten aufbaut.

Ich weiß nicht, ob das in Motivation besser aufgehoben wäre. Es handelt sich immerhin um eine neue Anforderung (wenn auch nur "SOLL") zum Profil (und keine "motivierende" Feststellung zum Profil). Lass uns das allgemeine Thema Anforderungs-Identifikation an diesem Punkt konkret besprechen.

Es war so gemeint, dass die Hersteller hier ihren Input zu einem konkreten Änderungsvorschlag geben sollen - daher "draft"-Status.

[ylboerner]

@f-peverali Wir haben dies intern noch einmal besprochen:

Versorgungsstellenkontakte werden in der Praxis wenig bis keine Relevanz besitzen. Den Versorgungsstellenkontakt gibt es nur, weil einer der ersten UseCases in der MI-I die Kontaktverfolgung von Covid-Patienten innerhalb eines Klinikums war. Für ein generisches KIS ist dies allerdings eine zu spezielle Anforderung, da die heutigen Systeme prinzipiell nur Abteilungskontakte kennen. Wir empfehlen konkret folgendes:

1. Abändern von 'SOLL' in 'SOLLTE'
2. Hinzufügen eines Satzes als Überschrift für den Absatz: 'Bei Abbildung von Versorgungsstellenkontakten'

Dann ist der Fall korrekt abgedeckt 👍

[f-peverali]

"SOLLTE" sollten wir gar nicht nutzen; wenn dann "KANN" (siehe https://simplifier.net/guide/Implementierungsleitfaden-ISiK-Basismodul-Stufe-3/markdown-UebergreifendeFestlegungen-UebergreifendeFestlegungen-Methodik?version=current). Eine Überschrift füge ich gerne noch ein.

[ylboerner]

@f-peverali Ha, danke für das Aufpassen! KANN passt in diesem Fall 👍

[alexzautke]

Ich wäre hier dafür bei SOLL zu bleiben. Alle anderen Optionen führen zu inkonsistenten Daten. Mit SOLL machen wir schon einen guten Vorschlag.

[alexzautke]

Versorgungsstellenkontakte werden in der Praxis wenig bis keine Relevanz besitzen.

Sobald wir in der Aufbauorganisation die Betten abbilden müssen wir darüber nachdenken ob wir damit Probleme bekommen

[f-peverali]

Versorgungsstellenkontakte werden in der Praxis wenig bis keine Relevanz besitzen.

Sobald wir in der Aufbauorganisation die Betten abbilden müssen wir darüber nachdenken ob wir damit Probleme bekommen

Wie kann man diese Info sinnvoll (zur Doku/ im IG) unterbringen? Auch das wieder eine konkrete Frage zum allgemeinen Thema "Anforderungsmanagement"

[f-peverali]

@alexzautke könntest Du hierzu nochmal den Hintergrund darstellen (ggf. so, dass er auch in in die Doku/Spec eingehen kann?
Bzw. noch auf folgende Punkte eingehen; es hatte hierzu in der AG Rückmeldungen sowohl technischer als auch fachlicher Natur gegeben:

1. technische wurde darauf verwiesen, dass eine N zu M Kardinalität ohehin ausgeschlossen sei, da die Zuweisung eines Versorgungsstellenkontaktes ohnehin über das element .partOf (Kardinalität: 0..1) umgesetzt wird; das würde unsere Anforderung redundant machen. Wodurch sich der fachliche Hinweis ggf. auch erledigt hätte:
2. eine Bewegung in KH erfordere (auch auf interdisziplinären) Stationen auch einen neuen Versorgungsstellenkontakt, wodurch die Anforderung ebenfalls redundant wäre.