Feature/rollback stufe 3 interactions encounter+patient ptdata 1419 #226
Conversation
ImplementationGuide/markdown/AkteureUndInteraktionen-Dokumentenabfrage.md
Show resolved
Hide resolved
…-PTDATA-1419' of https://github.com/gematik/spec-ISiK-Dokumentenaustausch into feature/rollback-Stufe-3-interactions-encounter+patient-PTDATA-1419
There was a problem hiding this comment.
Folgendes: wir haben noch Ticket https://service.gematik.de/browse/PTDATA-1328 offen, was dazu führen könnte, dass wir die Expectation des Suchparameters "subject" von SHALL auf MAY lockern. Wenn wir dazu auch einen Backport nach Stufe 3 machen, sollte das hier auch gelockert werden.
Ich würde empfehlen, das hier bei den Suchparametern von Encounter und DocumentReference schon direkt anzuwenden, sonst vergessen wir es beim Backport.
| * type = #reference | ||
| * searchParam[+] | ||
| * extension.url = "http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation" | ||
| * extension.valueCode = #SHALL |
There was a problem hiding this comment.
| * extension.valueCode = #SHALL | |
| * extension.valueCode = #MAY | |
There was a problem hiding this comment.
question: wäre es nicht im Sinne der Wartbarkeit die Begründung hier direkt im CpS zu dokumentieren? wie könnte man das machen?
suggestion: @simoneOnFhir könntest du hier ggf. noch einen Vorschlag machen
|
|
||
| Datum: tbd | ||
|
|
||
| * `fix` `test modifying` Rollback der Entfernung von Patienten- und Encounter-Interaktionen (veranlasste Änderung in TC 3.0.1) https://github.com/gematik/spec-ISiK-Dokumentenaustausch/pull/226 |
There was a problem hiding this comment.
| * `fix` `test modifying` Rollback der Entfernung von Patienten- und Encounter-Interaktionen (veranlasste Änderung in TC 3.0.1) https://github.com/gematik/spec-ISiK-Dokumentenaustausch/pull/226 | |
| * `fix` `test modifying` Rollback der Entfernung von Patienten- und Encounter-Interaktionen (veranlasste Änderung in TC 3.0.1) - in diesem Zusammenhang wird auch der Suchparameter "subject" von SHALL auf MAY gesetzt https://github.com/gematik/spec-ISiK-Dokumentenaustausch/pull/226 |
|
|
||
| * Problem: Durch die Entfernung von Anforderungen die Abfragen von Patienten- und Encounter-Ressourcen betreffend wäre die Herstellung von Dokumentenkontexten zu besagten Ressourcen in der Regel nicht mehr möglich. | ||
| * Lösung: Rollback der Änderung - wodurch die entsprechenden Suchparameter wieder in die Spezifikation aufgenommen werden. | ||
|
|
There was a problem hiding this comment.
- Hintergrund:
Während der Überlegung zum Entfernen der Suchparamter waren zwei Architekturen angenommen worden:
Architektur A - Integrierte Umgebung: Wir haben ein patientenführendes System (Basis -Server), das alleinig ISiK-Patienteninstanzen (und Encounter) verwaltet
Architektur B - geteilte Patienten (und -Encounter) Verwaltung: Basis-Server und DMS persistieren voneinander unabhängig ISiK-Patienten-Instanzen
Nachträglich erscheint Architektur A als nicht der Realität in KH-Umgebungen entsprechend - womöglich auch nicht als wünschenswert da eine autonomie der Datenhaltung der verschiedenen Systeme auch bei Ausfällen ein Sicherheits-Feature darstellt.
Es stimmt daher NICHT, dass das DMS selbst keine Abfrage auf eine Patienten-Instanz erfüllen muss - sondern lediglich in der Lage sein SOLL/MUSS (dies nicht geprüft) die "referentielle Integrität" zu prüfen (ggf. noch zu forwarden) durch eine Anfrage an den Basis-Server.
Es muss dagegen angenommen werden, dass ein DMS auch immer Patienter- und Encounter-Abfragen (zumindest zur Herstellung der Ressourcen-Kontexte) ermöglichen muss.
|
|
||
| * Problem: Durch die Entfernung von Anforderungen die Abfragen von Patienten- und Encounter-Ressourcen betreffend wäre die Herstellung von Dokumentenkontexten zu besagten Ressourcen in der Regel nicht mehr möglich. | ||
| * Lösung: Rollback der Änderung - wodurch die entsprechenden Suchparameter wieder in die Spezifikation aufgenommen werden. | ||
|
|
There was a problem hiding this comment.
| * **Hintergrund**: | |
| Während der Überlegung zum Entfernen der Suchparamter waren zwei Architekturen angenommen worden: | |
| - Architektur A - Integrierte Umgebung: Wir haben ein patientenführendes System (Basis -Server), das alleinig ISiK-Patienteninstanzen (und Encounter) verwaltet | |
| - Architektur B - geteilte Patienten (und -Encounter) Verwaltung: Basis-Server und DMS persistieren voneinander unabhängig ISiK-Patienten-Instanzen | |
| Nachträglich erscheint Architektur A als nicht der Realität in KH-Umgebungen entsprechend - womöglich auch nicht als wünschenswert da eine Autonomie der Datenhaltung der verschiedenen Systeme auch bei Ausfällen ein Sicherheits-Feature darstellt. | |
| Es stimmt daher NICHT, dass das DMS selbst keine Abfrage auf eine Patienten-Instanz erfüllen muss - sondern lediglich in der Lage sein SOLL/MUSS (dies nicht geprüft) die "referentielle Integrität" zu prüfen (ggf. noch zu forwarden) durch eine Anfrage an den Basis-Server. | |
| Es muss dagegen angenommen werden, dass ein DMS auch immer Patienter- und Encounter-Abfragen (zumindest zur Herstellung der Ressourcen-Kontexte) ermöglichen muss. |
Historie hinzugefügt
Versionslabel in Historie korrigiert
Contributor Pull Request
Description
rollback auf commits that deleted functionality for Paitent and Encounter interactions - (git revert for cc6972d and 27aaa17)
Motivation and Context
How has this been tested?
Snippets or Screenshots (if necessary):
Types of changes
Checklist:
Reviewer / Quality Assurance Checklist
content review steps (based on Best Practice IG Germany)
formal intellectual review steps of Implementation Guide
no formal review needed
proofreading for orthography
there are no (critical) validation Errors in the CI pipeline
skim reading for correct rendering of IG (possibly using IG-grep of string String like "Could not render")
automated review steps:
For reviewers
You migh use this: https://conventionalcomments.org/