Lars Treinat zum stellvertrenden Vorsitz mit 10/10 Stimmen gewählt

Es muss geklärt werden

• Wie soll der Referenzvalidator eingesetzt werden und in welcher Einsatzumgebung?

  • Gesellschafterbeschluss zur Kentnis nehmen

• Wofür ist der Referenzvalidator, wofür nicht?

• Wie wird mit Versionierungen (bspw. von Value Sets oder Profilen) umgegangen?

• Welche Themen sollen durch Referenzvalidator abgedeckt werden (neben eRezept und ggf. MIOs)

Techn. Detailfragen außen vor lassen, besser innerhalb des AKs auf Governance-Fragen konzentrieren

Präsentationsfolien Referenzvalidator (gematik)

Präsentationsfolien allgemeines zur ersten Sitzung

Peter Osburg legt Confluence Seiten zu den Fragen an

• Welche Themen deckt der Referenzvalidator ab?

• Was tun um Teil des Refrenzvalidators zu sein

• Nutzung durch Anbieter

• Spielregeln für Referenzvalidator

alle Mitglieder des AK befüllen Unterseiten (ggf. stichpunktartig) um Diskussion in der zweiten Sitzung lenken zu können

Vorstellungsrunde

Wahl des Stellvertreters

• Lars Treinat mit 10/10 Stimmen

Osburg: Kommunikationstools, Vergütung vorgestellt

Vorstellung des Status quo des Referenzvalidators durch Alexey Tschudnowsky (gematik)

• Rückfragen und Hinweise zur Präsentation

• Meincke: Regeln zur Einsetzung/Einsatzumgebungen muss geklärt werden - wofür ist der Referenzvalidator gedacht und wofür ist er nicht gedacht. 

  • Oemig: In den USA gibt es dazu Überlegungen, die im Januar weiter diskutiert werden

• Sydow: Versionierungsumgang muss geklärt werden, Vorschläge von uns in Form der Handlungsempfehlungen möglich

• Treinat: Open Source Lizenz der Veröffentlichung?

  • Tschudnowsky: Apache Lizenz - kann durch jeden weiterverwendet werden

• Weigel: Einsatz in Produktivumgebungen diskutieren und nicht von vornherein ausklammern

• Weigel: Testdaten sind wichtig, aber diese zu erarbeiten ist nicht trivial

• Wiedekopf: Es benötigt Prozessdefinitionen zum Umgang mit Atkaulisierungen von Profilen - insbesondere Breaking Changes

• Wiedekopf: Kann eine Anbindung des Validators an Terminologieservices relevant sein?

• Dietzel: Woher können Referenzdaten für den Referenzvalidator kommen?

  • Können live-Daten anonymisiert und dann verwendet werden?

  • Tschudnowsky: Testdaten systematisch auf Basis der Profildefinition erstellen, um eine gewisse "Profilabdeckung" zu erreichen. Geschehen kann das im Rahmen der Prüfmodulerstellung oder während der Spezifikationserstellung / Qualitätssicherung

• Franke: Können wir dafür sorgen, dass mit Nutzung des Referenzvalidators Interpretationsspielräume in den Spezifikationen unterbunden werden? Klare Regeln müssten erstellt werden.

• Reith: Überlegen, auf welcher Flughöhe man sich im AK bewegt. Teilweise sind die Diskussionen schon recht technisch. Bspw. offen: Ist der Referenzvalidator gesetzt oder kann er Änderungen unterlegt werden? Wann ist ein Fehler ein Fehler?

• Degner: Refvalidator als Element in Test- und Entwicklungsphase ansehen.

  • Weigel: Es gibt einen Gesellschafterbeschluss für den Einsatz in der Produktivumgebung

  • Meincke: Beschluss kann durchaus geprüft werden und sollte kein Hinderungsgrund für Analysen werden

  • Degner: Gesellschafterbeschluss zur Kenntnis nehmen. Aber die Thematik erstmal für Test- und Entwicklungsphase definieren/betrachten

• Degner: Welche Themen laufen in den Referenzvalidator rein? eRezept ist klar gesetzt, mio42 sicherlich auch relevant, aber wie sieht es darüber hinaus aus (bspw. KIM Daten, etc)

  • techn. Detailfragen erstmal außen vor lassen, besser auf Governance-Fragen konzentrieren

  • Weigel stimmt ein

  • Werner: reden wir von einem oder mehrere Validatoren (ein Validato für alles oder projektbezogene Validatoren)

ToDos für nächste Sitzung

• Degner: Idee, näcshtes Mal folgende 3 Aspekte besprechen

  • Welche Themen deckt der Referenzvalidator ab?

  • Was tun um Teil des Refrenzvalidators zu sein

  • Nutzung durch Anbieter

  • Spielregeln für Referenzvalidator

Schug: Termin für kleineres Auditorium um Referenzvalidator aktiv zu zeigen

• Tschudnowsky bestätigt die Möglichkeit 

Degner: Vorbereitung auf Confluence Seite Arbeitsstand Referenzvalidator vorgestellt

• Statement: Referenzvalidator soll Basis für das deutsche Gesundheitssystem sein

• Referenzvalidator modularisiert via Prüfmodule

• Schug: Governance sollte mit benannt werden

  • Degner: Korrekt, wird in Diskussion im AK hinzugefügt

• Reith: Wording "Prüfmodul" ist "zu viel" - besser: Plug-Ins

• Degner: AK muss Governance Fragen als Ergebnis beantwortet haben

• Franke: Wer wird Autor der Plugins sein?

  • Degner: Müssen wir bestimmen. Die Plugins werden auch Bereiche abdecken können, die noch nicht benannt oder von gematik vorgesehen sind.

  • Tschudnowsky: Sehr gute Idee, Referenzvalidator kann als "Framework" geöffnet werden. Wichtig ist dann wieder, die Governance zu klären.

  • Franke: Industrie könnte sehr schnell sein, was Plugins anbelangt. Governance ist wichtig und notwendig. Es muss verhindert werden, dass "Referenz"validator nicht verkommt und freiwild wird.

    • Degner: Referenzvalidator ist die Basis bereitgestellt durch gematik. Referenzvalidator mit Referenz-plugins.

  • Treinat: Zuständigkeitsbereiche definieren

  • Meincke: Vielleicht kann man Bestätigte Plugins benennen

    • Degner: Idee, wer einen Standard definiert, kann auch ein Plugin bereitstellen. Bestätigung wäre dann durch eine "neutrale" Stelle und Aufnahme in Standardbuild

    • Degner: Referenzvalidator ist nicht die Qualitätssicherung von Standards

• Wiedekopf: Überlegung, Bereitstellung der Plugins zur Laufzeit? Erfordert aber andere Governance.

  • Tschudnowsky: Plugins sollen unabhängig entwickelbar sein. Auch zu klären, wie QS sichergestellt werden kann.

• Weigel: Ist Plugin das richtige Wording? Wichtig ist, die Begrifflichkeit zu definieren.

  • Degner: Was stellt sich gematik unter Plugin vor?

  • Tschudnowsky: Bisher Sammlung von FHIR Packages → Konformitätsprüfung → Warnungen/Meldungen/Kritikalität einstufen und an Referenzvalidator übergeben. Vielleicht sollet der RefValidator nicht nur im Kontext der TI gedacht werden.

  • Kahlert: Es gäbe aber auch Prüfungen außerhalb des FHIR Kontextes, wie wird das abgebildet in der Definition von "Plugin"

    • Reith stimmt zu, das kann vorkommen. Zuschnitt des Referenzvalidators auf "FHIR Referenzvalidator" daher nur FHIR-bedingte Validierung durchführen. Neben der Validierung ist die Bewertung der Ausgaben wichtig. Unterscheidung zu HL7 Validator: Prüfung ist nicht nachvollziehbar und Ausgaben werden nicht bewertet - das kann der Referenzvalidator zum Besseren unterscheiden. Kann der Referenzvalidator überhaupt den "ultimativen Stempel" bekommen

    • Tschudnowsky: Mit Fehlern muss man rechnen, sie müssen schnell korrigiert werden, damit der Referenzvalidator möglichst schnell zur Referenz werden kann.

• Werner:

  • Businesslogik sollte außerhalb des Validators liegen.

  • Plugins sollten in sich abgeschlossen sein, ohne dynamisches Nachladen

  • Versionsupdates müssen zugelassen werden - Testsuite für Validator und Use Case sollte Positiv- und Negativ-Testfälle bereitstellen - Testsuite durch gematik bereitzustellen

• Tschudnowsky: Wer macht Qualitätssicherung der Plugins. Negativ-Testfälle sind schwer bereitzustellen.

  • Werner: Instanzen, die Fehler werfen definieren, und prüfen ob sie zuverlässig auch nach Änderungen weiterhin Fehler werfen.

• Weigel: im Github Repo des Validators gibt es eine Definition des Referenzvalidators, was er tun soll und was nicht. Der Validator soll nur eine technische Verarbeitung entlang der Prozessketten gewährleisten

• Degner: Versionierung des Referenzvalidators notwendig und Definition, für welche Refvalidator-versionen Plugins zur Verfügung gestellt werden.

• Kahlert: Wir grenzen ein. Referenzvalidator nun FHIR-Referenzvalidator und Business Logik aus Validator herausgenommen.

  • Weigel: Prüfkataloge werden tw. gar nicht offengelegt, daher kann Businesslogik nicht überall validiert werden

  • Kahlert: Generell zufrieden mit dem klaren Statement, was der Referenzvalidator leisten kann

  • Weigel: Durch die Abgrenzung wird die Erwartungshaltung korrekt gelenkt

  • Degner: Fachliche Validierung wäre nicht im aktuellen AK leistbar.

  • Osburg: Kann gern in einer Handlungsempfehlung an Folge-Arbeitskreise aufgenommen werden

• Degner: zu klären, wie Verpflichtung hergestellt werden kann

  • Tschudnowsky: Wie kann geprüft werden, dass der Verpflichtung nachgekommen wird?

  • Degner: Sanktionen erstmal ausblenden

  • Treinat: Der Validator muss nicht zwingend in jeden Produktivbetrieb übernommen werden. Besser: Im Streitfall eine Validierung durchführen und als verbindliche Schlichtung ansehen.

  • Meincke: Produktivbetrieb ist mitunter (Software-)architektonisch aktuell nicht möglich

• Tschudnowsky: Für wen soll der Validator als verbindlich erklärt werden? Das müssen wir klären.

  • Degner: Für die Autoren für Standards verpflichtend. Aber wo hat man eine Handhabe? Idee: Definition der Verbindlichkeit für alle TI Anwendungen, auch für die Aufnahme in INA möglich. Welche Druckmittel stünden zur Verfügung? Annahme-ausschluss.

    • Osburg: Idee der Transparenzoffensive, wer unterstützt Validator-Plugins?

    • Meincke: Validator auf jeden Fall auf Daten-annehmender Seite verwenden

    • Tschudnowsky: Anstelle Verpflichtung, von Empfehlung reden. Intrinsische Motivation aufgrund von Kosten-Nutzen-Rechnung 

    • Reith: Nicht nur Empfänger, auch Sender muss validieren. Ist aber eine Diskussion für Produktiveinsatz.

    •  Degner: KhPflEg benennt schon Verpflichtung für MIOs.

Degner: Kleine Runde vor nächster Sitzung einberufen - Tschudnowsky und Treinat zusammen mit Degner, wer aus dem AK möchte, kann mit dabei sein.

• Osburg setzt Termin auf

Potenzielle Struktur für Positionspapier erarbeitet

• Ausblick: Zeitnah mit textuellen Formulierungen starten
• Präsentation zu "potenzielle Struktur des Positionspapiers"
• Im AK detaillierte Diskussion zur Versionierung der Plugins, des Validators, der zu validierenden FHIR Profile
  • Tschudnowsky: Idee, Konfiguration für Referenzvalidator, die beschreibt, gegen welche Versionen zu validieren wären
    • Reith: Findet die Idee eleganter und der Anforderungen gerecht, Plugin-Architektur könnten später nachgeliefert werden
    • Degner: Über die Idee weiter nachdenken, es ist aber erstmal wichtig, alte Versionen des Validators am Leben zu erhalten
  • Tschudnowsky: Es ist wichtig, das Ziel der Architektur klar zu definieren. Bspw. "Es müssen verschiedene Versionen möglichst lang unterstützt werden können. - Stabilität erhalten"
    • Kahlert: Wäre auch usability-verbessernd für Validierende (aber nicht für Plugin-Entwickelnde)
  • Degner mit Bitte, dass Tschudnowsky innerhalb der gematik diskutiert, was eine adäquate Lösung sein könnte

• Franke: passende Struktur, wünscht sich aber noch ein wenig Zeit zum Durchlesen - Bitte, um Deadline, für Kommentierung

• besonderer Fokus auf "Zielsetzung"

• Meincke: Was passiert bei Framework-Versions-Erhöhung, aber das Plugin bleibt bei gleicher Version
• Degner: Empfehlung wäre, das Plugin auch in der Version anzuheben und dem Framework anzupassen.
  • Meincke: Sollte nicht nur Empfehlung sein, sondern Verpflichtung. Durchaus mit der Konsequenz, Plugins abkündigen zu können
• Kahlert: Plugin-Erstellende sollen immer mitgeben, ob das Plugin mit spezifischen Framework Versionen kompatibel ist.
  • muss prozessual definiert werden
• Werner: Vorsicht bei Breaking Changes. Ggf. Angabe zu Unterstützung einer maximalen Framework-Version

• Problembeschreibung: Treinat, Franke
• Zielsetzung des Referenzvalidators: Tschudnowsky, Reith
• Governance: Degner, Schug & Sydow (Zwei-Teilung: Governance für Plugin-Erstellende, Governance für Plugin-Nutzende)
• Fazit mit Handlungsempfehlung, später, wenn die Hauptkapitel fertiggestellt sind
• Kahlert und Werner fragen, ob es gewünscht ist, quer zu lesen und zu kommentieren
  • Degner: dedizierten Kommentarbereich unter den Kapiteln erstellen und beachten, dass viel noch bis zum 06.02. als work in progress zu kategorisieren ist
  • Tschudnowsky: State-of-art Input wäre noch gut. Was gibt es aktuell und wo fehlt es, um dann eine Überleitung zum Referenzvalidator zu bekommen.

• Reith: Es geht "nur" darum verschiedene Dependencies zu laden.
• Osburg: sollte in "Zielsetzung" mit behandelt und dokumentiert sein

• Formulierung offener Punkte, die im Positionspapier beantwortet werden müssen

• Rechnungstellung
• Retrospektive
• Fristgerechte Einreichung der Ergebnisse