• alle AK Mitglieder bearbeiten die Tabelle

• Sebastian Dries: 5 Stimmen
• Frank Oemig: 3 Stimmen
• Sebastian Dries angenommen

• IEEE: Institute of Electrical and Electronics Engineers (2000). IEEE-Std 1471-2000: recommended practice for architectural description of software-intensive systems. http://standards.ieee.org. Accessed 15 Jan 2023.
  • The architecture of an information system describes its fundamental organization, represented by its components, their relationships to each other and to the environment, and by the principles guiding its design and evolution
• Frage nach Zuständigkeiten klären
• Input Sebastian Dries, Aspekte die geklärt werden müssen:
  • Zusammenarbeit der Menschen
    • mit PatientInnen und Zuweisenden
    • Fachkräfte intra- und inter-professionell
    • Einbindung KI in Workflows
  • Zusammenspiel von Lösungen
    • Server-Virtualisierung Applikations, Datenbanken, ...
    • Client-Harmonisierung Rollen- und Arbeitsplatz-gerecht
  • Betrieb der Infrastruktur
    • Sicherheit
    • Performance
    • Stabilität, z.B. Redundanz Netzwerk, Storage

• Einbindung diverser Systeme über verschiedene Ebenen (Geschäftsprozesse, Integration und Implementation, etc.)

• Unterbindung von Doppeleingaben im klinischen Alltag
• Wunsch nach Modell, indem der IT Experte im KH schneller vorankommen kann → pragmatische Lösungen → IT'ler müssen abgeholt werden

• Grundverständnis muss existieren, bei zu hoher Flughöhe leider nicht gegeben
• die komplette Patient Journey muss betrachtet werden

• Wichtige Anforderungen an eine Referenzarchitektur aus meiner Sicht:
  • Wie können wir eine solche Architektur effizient, kollaborativ und agil erstellen?
  • Wie kann eine solche Architekture einfach (z.B. auf PPT-Folien) visualisiert und kommuniziert werden?

• Konzentration auf IT Landschaft, nicht Software Architektur → Institutionsarchitektur

• Inhalte aus unserem Projekt:

  • Ziel / Domäne = Vereinfachung des Austausches von Dokumenten und strukturierten Daten von Patientinnen und Patienten va mit externen Kooperationspartnern
  • Daraus folgend Architekturebenen: 
    • Infrastruktur / Technik (inkl. Schnittstellen)
    • Organisation & Prozesse
    • Regulatorik & Datenschutz
    • Data Governance & Terminologien
• Referenzarchitekturen mitunter zu theoretisch

• Architektur := Komponenten und deren Zusammenspiel
• Referenzarchitektur := Architektur, an der man andere vergleichen kann
• für Interoperabilität braucht man Kompatiblität; das orientiert sich aber den Informationsmodellen, hier der Übertragungsinhalte in Kombination mit den IT-Systemen
• Frage nach der Art der Architektur: IT-Systeme miteinander, innerhalb von IT-Systemen, Domänen, Integrationsszenarios, ..
• die Nutzung von Referenzarchitekturen hat sicherlich Potenzial, auch wenn ein derartiger Ansatz in der Breite nicht bekannt ist

• Pragmatischer Ansatz:

  Eine Referenzarchitektur besteht aus:

  1. Einer Applikationsschicht=Verschiedene SW Produkte am Prozess orientiert
  2. Einer Datendrehscheibe=IOP Komponente
  3. Einem Datenhafen=Clinical Data Repository
  4. Verschiedene Auswerte SW die sich aus strukturierten Daten aus dem Datenhafen bedienen

• Brainstorming zu bestehenden Architekturen, in Tabellenform
• Herauskristalisieren, welche Aspekte tatsächlich relevante zu betrachtende Architekturen sind
• Vorschlag Englmaier: eher Visio, an welchen Punkte Daten entstehen und die in den Prozess eingefügt werden müssen
• Wahle: nicht zu lange aufhalten mit den Gründen, warum die Situation so ist, wie sie ist, sondern darauf fokussieren, die Situation zu ändern
• Ritthaler: Domänen müssen mit definiert/betrachtet werden
  • Governance muss mit abgedeckt sein

Ergebnisse, Entscheidungen, o.ä. die gesondert aufgelistet werden müssen. Eine Sitzung kann auch ohne Ergebnisauflistung enden

• Toolsets zur Darstellung von Architekturen
• Orientierungshilfe

Dedizierte Auflistung der ToDos, idealerweise mit Mitgliederbenennung und Deadline

• prozessorientiert, IST vs. SOLL-Abgleich, Drei-Ebenen-Ansatz (Datenhafen/CDR, Applikationsebene, IOP-Plattform/Kommserver)

• universelle vs. proprietäre Referenzarchitekturen
• wichtig ist: Flughöhe zu wählen, die Interoperabilität mit behandelt (bspw. Datenkompatibilität) aber nicht zu sehr ins Detail gehen

• Herausforderungen für IOP im Krankenhaus
• mögliche Ziele einer Referenzarchitektur
• verschiedene Häuser mit verschiedenen Prozessmodellierungen
  • Diversität in den unterschiedlichen Landschaften sehr hoch
  • IT Landschaften zu harmonisieren ist zeitlich und finanziell zu komplex
• Mehrwertdienste über Daten-Layer
• Feedback:
  • Toolset zur vereinheitlichten Darstellung von Architekturen sinnvoll
  • sehr gutes Beispiel für Potenzial einer Referenzarchitektur
  • Harmonisierungsbestrebungen sind kontinuierlich in der Konzernlandschaft vorgesehen
  • in kleinen Häusern sind Kompetenzen für IHE und FHIR mitunter nicht vorhanden → Hilfestellung in konkreter Struktur oder Cookbook würden weiterhelfen

• Nutzung v.a. im universitären Umfeld, bspw. im SMITH-Konsortium der MII
• ermöglicht "echte" Modellierungen (statt Zeichnungen), Toolset für Modellierungen verfügbar und mit mehreren Praxisbeispielen erprobt
• sehr granulare Modellierungen möglich

• www.digitalradar-krankenhaus.de
• DigitalRadar-Ergebnisse veranschaulichen vorhandene Digitaliserungslücken/-schwächen → Referenzmodelle könnten als Orientierungshilfe daran anknüpfen

• Oemig: Ist eine Domänentrennung notwendig? Statt auf einzelne Systeme (iwe KIS) zu schauen, sollten die Prozesse und Ziele bzw. logische Anforderungen in den Mittelpunkt gestellt werden; Funktionsumfang einzelner SW-Lösung kann zu stark variieren (bspw. anstatt KIS von "Patientenadministration" vs. "Pflegedokumentation" usw. reden; nicht alle KIS unterstützen alle Bedarfe/Funktionen).
  • Domänengesamtsicht in Positionspapier benennen/betrachten
• Ritthaler: Zustimmung zur Domänentrennung, gemeinsames Verständnis von Daten ebenso notwendig, Datenaustausch muss auch sektorenübergreifend gedacht werden

• Einleitung
  • Ziele des Dokuments und Abgrenzung
  • Problemstellung
    • beispielhaft von Paul Hellwig: Herausforderungen für Interoperabilität im Krankenhaus
    • vernetzendes Gesundheitssystem
  • Begriffsklärungen
• Hauptteil
  • Welche Lösungen können Referenzarchitekturen bereitstellen
  • sektorenübergreifender Überblick & Domänentrennung
  • Dimensionen der Betrachtung
    • fachliche Bereiche: Admin, Abr, Fachbereiche, ..
    • Granularität
    • Prozesse: business, use cases, Daten, techn. Implementierung
    • IT-Systeme
    • wo macht eine Referenzarchitektur Sinn und wo nicht
  • Betrachtung Digitalradar
  • Verwendung der Beispielarchitekturen
  • Zielgruppen, Akteure