Datumseinschränkung Consent

[julsas]

eine Frage zum KDS bzgl. Datumseinschränkung Consent. Ist eine Liste der Datumselemente in den Profilen bekannt, welche für die Datumseinschränkung im Consent relevant sind bzw. herangezogen werden sollen. Gerade bei Diagnose gibt es ja sowohl onset als auch recordedDate.

-> sowas sollten die KDS Teams festlegen

[julsas]

@karoline-buckow soll auf die Agenda für die nächste TF KDS Sitzung

[SebStaeubert]

Ein Ausgangspunkt kann 'clinical-date' in der Tabelle der FHIR Search Parameter sein: https://hl7.org/fhir/R4/searchparameter-registry.html (Tipp von @alexanderkiel ) Allerdings fehlen hier einige Ressourcen, z.B. condition.

Eine verwandte Vorarbeit ist die Tabelle zum Mapping von Policies auf KDS Module bzw. Profile/Ressourcen. Dort könnten die entspr. Datumsattribute ebenfalls aufgeführt werden.

[SebStaeubert]

Kandidaten: Observation.issued Condition.recordedDate

[julsas]

Vielleicht sollten wir uns auch Resource.meta.lastUpdated angucken. Das wäre unabhängig vom Ressourcentyp.

[SebStaeubert]

Ausgangssituation:

• Es gibt an den DIZ-Standorten Ressourcen, die einen Bezug zum Fall haben
• Es gibt an den DIZ-Standorten Ressourcen, die keinen Bezug zum Fall haben
• Im MII DIZ FHIR Server liegen KDS FHIR Ressourcen vor

Vorschlag der TF KDS:

• Auswertung auf Basis von Fallgrenzen
  • Start-Datum (Encounter.period.start statt Consent.provision.provision.period.start): alle Daten, die im Fall anfallen, in dem der BC erfasst wurde
  • End-Datum (Consent.provision.provision.period.end): nur die Daten, die im letzten vollständig im 5-Jahres-Erfassungszeitraum liegenden Fall inkludieren (Policy: 2.16.840.1.113883.3.1937.777.24.5.3.6 'MDAT erheben')
  • in Bezug auf die Grafik wären das Fall 1-3; Fall 4 würde nicht berücksichtigt
• sollte kein Fallbezug möglich sein, sollte 'clinical-date' entspr. FHIR Search Parameter verwendet werden und mit Start-/End-Datum der betreffenden Policy gefiltert (Consent.provision.provision.period.start, Consent.provision.provision.period.end)

Begründung

• technische Gründe: unterschiedliche Datumsangaben mit unterschiedlichen Bedeutungen je Ressource machen die Umsetzung der Filterung auswändig
• inhaltliche Gründe: Bias durch Auswertung unvollständiger Fälle

Weiteres Vorgehen:

• Bestätigung, Kenntnisnahme, Kommentierung durch die AG Consent
  • -> Verweis an AG IOP bzw. AG Data Sharing
• Bestätigung, Kenntnisnahme, Kommentierung durch die AG IOP + DS
• Beschreibung in dem Dokument zu den Handlungsanweisungen (TF CU)
• Verteilung über die MII-Verteiler, ggf. Vorstellung im Forum der DIZ-Leiter
• Umsetzung in FDPG, SMITH FTS, etc.

[juliangruendner]

@SebStaeubert , @julsas - wäre bei Condition recordedDate richtig oder müsste man hier eigentlich onset nehmen?

[juliangruendner]

@SebStaeubert , @julsas - To implement this we need a mapping profile -> consent field for each CDS profile, which should be made available or data extraction

Profile	Consent Date field elementId
https://simplifier.net/medizininformatikinitiative-modullabor/observationlab	Observation.effective[x]
https://simplifier.net/medizininformatikinitiative-modullabor/servicerequestlab	?

[julsas]

Profile	Consent Date field elementId
https://simplifier.net/medizininformatikinitiative-modullabor/observationlab	Observation.effective[x]
https://simplifier.net/medizininformatikinitiative-modullabor/servicerequestlab	ServiceRequest.authoredOn

[SebStaeubert]

Siehe auch https://github.com/medizininformatik-initiative/torch/issues/6

ToDos

• [ ] @juliangruendner macht Vorschlag für Tabelle der zu verwendenden Datumsangaben je Profil bzw. Ressource
• [ ] Datumsangaben, festgelegt durch die KDS-Modul Teams bestätigen und als Minor Change in den jeweiligen IGs
• [ ] Ermittlung Zugehörigkeit Fall: (Anfrage an AG Consent am 05.07.2024 gestellt)
  • [ ] Variante 1: über Datumsangaben in den Ressourcen (entspr. Tabelle)
  • [ ] Variante 2: über Referenzen - Umgang mit Referenzen ausgehend vom Fall bzw. von den Ressourcen auf den Fall