Stream: german/mi-initiative
Topic: Data-Provenance
Georg Fette (Feb 16 2021 at 08:24):
Hallo, was gibt es bisher in der MII an Überlegungen Data-Provenance in Resourcen zu dokumentieren ? Es gibt ja ein Provenance Profil. Gibt es bereits Standorte, die so etwas benutzen um diese Aspekte in ihren FHIR-Stores abzudecken ? Müsste man sowas nicht für die anstehenden Audits bezüglich Data-Quality mit drin haben, oder kann man darauf verzichten ?
Alexander Zautke (Feb 16 2021 at 09:10):
Hi @Georg Fette, Provenance war von Anfang ein Thema das auf der Roadmap der Taskforce Kerndatensatz stand und auch weiterhin steht. Das Problem ist hier, dass alle beteiligten Personen zu sehr ausgelastet sind um hier die Vorgaben auszuarbeiten und es in einem IG zu dokumentieren.
Alexander Zautke (Feb 16 2021 at 09:12):
Generell würde ich erwarten, dass in vielen Fällen ein Import aus einem Primärsystem aus einem Bundle von Ressourcen besteht. Pro Bundle würde ich eine Provenance Ressource mit Links auf alle Ressourcen im Bundle generieren.
Gustav Vella (Feb 19 2021 at 16:53):
Alexander Zautke said:
Hi Georg Fette, Provenance war von Anfang ein Thema das auf der Roadmap der Taskforce Kerndatensatz stand und auch weiterhin steht. Das Problem ist hier, dass alle beteiligten Personen zu sehr ausgelastet sind um hier die Vorgaben auszuarbeiten und es in einem IG zu dokumentieren.
@Georg Fette Bei MII Kunden von uns ist es definitiv ein Thema. @Alexander Zautke- geht es darum das die Anforderungen nicht klar sind? Der Bedarf ist ziemlich fundamental und straight forward. Die wichtigsten Szenarien sind Abbildung von Qualität und Latenz von 'gleichen' Daten. Beispiel §21 Schnittstelle und Krebsregister Schnittstelle - hohe Latenz aber gute Qualität. Die gleichen Datenelemente aus dem KIS - schnell aber lückenhaft . Wenn ich eine retrospektive Analyse mache ist die Latenz unwichtig. In Echtzeit-Monitoring und Pre-Screening schon. Dann haben wir das Thema der Intention - Provenance.entity.role z.B. bei §21 Abrechnung vs. klinisch um ein Beispiel zu nennen. Was gibt es sonst für Szenarien?
Gustav Vella (Mar 11 2021 at 16:22):
Ich sehe anhand des Feedbacks ist das Thema nicht wirklich eine Prio für die MI-I Entscheider. @Simone Heckmann - wäre das etwas was wir bei den deutschen Basisprofilen aufnehmen könnten?
Mareike Przysucha (Mar 14 2021 at 18:45):
@Gustav Vella : Inwieweit muss die Ressource auf deutsche Gegebenheiten angepasst werden? Wenn ich mir die Ressource anschaue, bin ich da etwas unsicher, was gemacht werden muss, wenn wir Deutschland allgemein anschauen.
Simone Heckmann (Mar 15 2021 at 10:06):
Ja, sehe ich genau so. Provenance kann alles Mögliche sein von "diese Infos hat der Patient mitgebracht" zu "diese Ressourcen hat der Kommserver aus einer V2-Nachricht extrahiert" oder auch "ich will einfach nur diese Ressourcen mit einer externen Signatur versehen"...
Wo sind da die gesamtdeutschen Gemeinsamkeiten...?
Ich denke ein Provenance-Profil macht immer nur im Kontext eines Konkreten Anwendungsfalles Sinn.
IIRC hat IHE ein Provenance Profil für den Use Case "Diese Ressourcen wurden aus einem Strukturierten Dokument extrahiert" in mXDE
Simone Heckmann (Mar 15 2021 at 10:11):
Gustav Vella (Mar 16 2021 at 19:46):
ja sehe ich auch so - aber worauf ich mich mit der Frage beziehe ist genau die Aussage "Provenance kann alles Mögliche sein"
Und gerade weil es anscheinend eine gute Abstimmung zwischen IsiK, Basisprofile von HL7 Deutschland, die Spezifikationen der KBV inbes. die KBV-Basisprofile die ,eRezept/eAU UND die Kerndatensatz-Module der MI-I gibt stelle ich die Frage.
Aber wir können das auf die MI-I begrenzen. Was ist für die MI-I hinsichtlich provenance infos relevant wenn ein Medic Daten an das Konsortium sendet - "diese Ressourcen kommen vom Kommserver oder von Subystem X/Y" Punkt. Ist das ausreichend? Gibt es interkonsortial eine Erwartung über das absolute Minimum an Informationen?
Gustav Vella (Mar 16 2021 at 20:05):
Und wenn das als ausreichend gesehen wird dann ist die Konsequenz dass wir keine Aussage über Qualität oder Latenz für die spätere Verwertung der Daten haben. Diese Informationen können ja aktuell nur über eine extension in proveneance abgebildet werden.
Simone Heckmann (Mar 18 2021 at 09:35):
Gustav Vella said:
Und gerade weil es anscheinend eine gute Abstimmung zwischen IsiK, Basisprofile von HL7 Deutschland, die Spezifikationen der KBV inbes. die KBV-Basisprofile die ,eRezept/eAU UND die Kerndatensatz-Module der MI-I gibt stelle ich die Frage.
IsiK ist mit MI-I und KBV Basis harmonisiert, IsiK, MI-I und KBV basieren auf den Deutschen Basisprofilen.
einzig eAU und eRezept schlagen hier ein Stück weit aus der Art, da es sich dabei um hochspezialisierte Profile handelt, die div. gesetzliche/datenschutzrechtliche Vorgaben einhalten müssen und daher sehr stark constraint sind, was zu Inkompatibilitäten mit den anderen Spezifikationen führt.
Simone Heckmann (Mar 18 2021 at 09:38):
Wer Inkompatibilitäten zwischen Isik, MI-I, HL7-DE Basis und KBV Basis findet, darf diese gerne hier melden. Alle beteiligten Organisationen sind bestrebt, diese zu vermeiden/zu minimieren.
Last updated: Apr 12 2022 at 19:14 UTC
