BI-Fit und Catalog-Sichtbarkeit in der Klinik
Wann Qlik, Tableau, Power BI, SAC, Looker oder Excel zum Klinik-Job passen — und wie OpenMetadata den Chaos-Bestand sichtbar macht, ohne Purpose Binding zu ersetzen.
Eine Engine-Rangliste ist noch kein Vertrag. Klinik-Governance scheitert, wenn „Qlik gewinnt in Häusern“ oder „Tableau ist schöner“ den Feed ersetzt. Derselbe Extract kann in sechs Welten landen — der Zweck hängt an der App, nicht am Lizenznamen.
Dieser Teil ordnet Qlik, Tableau, Power BI, SAP Analytics Cloud, Looker und Excel den Klinik-Jobs zu und setzt OpenMetadata als Sichtbarkeit — Influence, nicht Owner.
Vorher: Extract-Grain und Abteilungs-Listen. Die Gold-Klammer bleibt Care vs Research.
zdem drei Apps ohne Zweck. Section Access, zertifiziert und Glossary-Term tun so, als wäre der Feed entschieden.
Lösung: Die Engine folgt dem Job. Der Catalog macht den Chaos-Bestand auffindbar. Purpose Binding bleibt am Produkt. Qlik, Tableau und OpenMetadata sind gleichberechtigte Influence-Pfade — keines entscheidet Care vs Research.
In einem Satz: Job zuerst, Engine danach; Catalog zeigt den Pfad, er gibt ihn nicht frei.
Entscheidung
Vor der nächsten App oder dem nächsten Metadatenimport gilt:
- ein App-Zweck — Betrieb/Steuerung, QM/Konferenz, kaufmännisch/Planung, Research — genau einer;
- eine Engine zum Job, nicht zum Vendor-Slide (siehe Fit-Karte);
- ein Konsumvertrag — Grain, erlaubte Joins oder Assoziationen, Maskierung, Stopp;
- ein Catalog-Asset für App, Extract und steuernde Datei mit Owner und Zweck;
- kein Sieger-Tool — zwei Engines im Haus sind normal; die dritte Wahrheit dazwischen ist das Risiko.
Section Access, Row-Level Security und Tableau zertifiziert sind Reduktion oder Badge — kein Zweck. OpenMetadata ist Metadaten-Kontext, keine Policy-Engine — siehe Wann OpenMetadata passt.
Fit-Karte nach Klinik-Job
Die allgemeine Engine-Logik steht in BI-Tools. Hier zählt der Job auf dem Chaos-Pfad.
| Klinik-Job | Oft stärker | Typische Falle |
|---|---|---|
| Lose Exports steuern (RIS, Gerät, Excel) | Qlik — Assoziation ohne Star Schema | App wird inoffizieller Patientenabgleich |
| Visuelle QM-/Konferenz-Argumentation, Grain schon geschnitten | Tableau — View, Join, LOD | LOD und Filterreihenfolge in der Arbeitsmappe statt im Extract-Vertrag |
| Identität schon Microsoft 365 / Fabric | Power BI — tabellarisches Modell | Workspace-Zugriff als Care-Zweck missverstanden |
| SAP IS-H / i.s.h.med / Controlling als Spine | SAP Analytics Cloud | Radiologie-Takt in SAC erzwingen, obwohl die Feeds nicht SAP sind |
| Warehouse/FHIR-Ziel, Git, zentrale Measures | Looker | Als Start über Excel-Worklists — LookML braucht das Modell, das fehlt |
| Slot, Dienstplan, Reconciliation | Excel als Produkt | Hilfsdatei genannt, obwohl sie Betrieb ändert |
Zwei Plattformen in einem Haus sind der Normalzustand. Qlik für den Takt, Tableau für QM, SAC für DRG — zulässig. Dieselbe Worklist in allen dreien ohne Zweck am Feed ist es nicht.
Wann Tableau besser ist als Qlik
Tableau denkt in View, Join und LOD. Qlik denkt in Assoziation und Auswahl. Der Fit kippt, sobald die Assoziation nicht mehr die Hauptarbeit ist.
Tableau ist der bessere Fit, wenn:
- ein Exportdatei-Vertrag aus Teil 2 existiert und die fachliche Ebene steht;
- der Output eine visuelle Argumentation ist (QM, Tumorkonferenz, Research-Gruppe), kein Steuerungscockpit über Brüche;
- ihr LOD braucht — Wartezeit je Modalität unabhängig vom aktuellen Stationsfilter;
- Joins sichtbar bleiben sollen, damit Re-Identifikation nicht still über gleiche Feldnamen passiert;
- Tableau bereits die Sprache von QM oder Universität ist.
Tableau ist der schlechtere Start, wenn MTRA-Liste, RIS-Worklist und Gerätelog noch drei Wahrheiten sind. Dann baut ihr in Tableau zuerst ein Modell, das die Klinik nicht hat — oder ihr schiebt das Chaos nach Prep/Hyper und nennt es Warehouse.
Qlik bleibt stark, solange die Quellen lose sind. Section Access reduziert Stationen; es bindet keinen Research-Zweck. Master Items steuern Kennzahlen in der App — den Identifier-Vertrag ersetzen sie nicht. Siehe Qlik Master Items und Tableau-Governance starten.
Power BI gewinnt, wenn Entra die Identität schon führt. SAC gewinnt auf dem kaufmännischen SAP-Strang. Looker ist Zielzustand nach Warehouse, nicht der erste MRT-Export. Excel bleibt Inventar und Ablösung, kein verbotenes Werkzeug.
Catalog macht Chaos sichtbar
OpenMetadata passt, wenn der Bestand heterogen ist — genau die Klinik: Qlik-App, Tableau-Workbook, Excel-Liste, HIS-Extract, FHIR-Consumer. Collibra oder Purview, wenn die Suite schon scannt oder Workflows nicht verhandelbar sind. Keine Healthcare-Vergleichsserie; die Einordnung liegt in OpenMetadata vs. Collibra und Catalog Deep Dive.
Der Catalog muss tragen:
- App, Exportdatei und steuernde Datei als Assets;
- verantwortliche Person, Zweck, fachliche Ebene;
- Lineage vom Feed zur App — so weit der Connector reicht.
Der Catalog darf nicht tragen:
- Care- vs Research-Freigabe;
- MPI-Merge;
- Pseudonym-Prüfpunkt.
Teil 1 der Gold-Serie bleibt richtig: Research-Portal kaufen und Katalog taggen ohne Purpose ist die falsche Tool-Reaktion. Hier gilt die Umkehrung: ohne Catalog-Asset bleibt die Excel-Liste unsichtbar — und genau dann speist sie drei Apps.
Tools auf diesem Pfad: Report Inventory, OpenMetadata-Domain- und Produkt-Generator, Qlik Set Analysis Generator, PII Policy Generator, Stakeholder Matrix.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| Care Owner | Steward | App-Zweck (Betrieb, QM, Planung oder Research) |
| Steward | BI-Custodian | Konsumvertrag: Engine, Grain, Join/Assoziation, Maskierung |
| Steward | Catalog-Steward | Asset-Karte für App, Extract, Datei |
| QM- oder Controlling-Owner | Care Owner | Eigener Zweck, wenn Tableau oder SAC denselben Feed will |
| Catalog-Steward | Steward | Lückenliste: Dateien und Apps ohne Asset |
| Custodian | Care Owner | Nachweis: Section Access ≠ Purpose; zertifiziert ≠ Owner |
Anti-Patterns
- „Qlik gewinnt in Kliniken“ als Architekturentscheidung
- Tableau einführen, um den ungeordneten Exportdatei zu umgehen
- OpenMetadata-Metadatenimport als Freigabe für Research
- Power-BI-Workspace mit Entra-Gruppen als Purpose Binding
- Looker verlangen, solange Excel die Worklist führt
- Crystal-, Cognos- oder HIS-Prints aus dem Inventar lassen, weil sie „kein BI“ sind
Umsetzung im Alltag
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
- Alle BI-Apps und steuernden Dateien einer Modalität listen — inklusive Excel und Legacy-Prints.
- Jeder App genau einen Zweck zuordnen; doppelte Feeds killen oder neu schneiden.
- Engine gegen die Fit-Karte prüfen; Tableau nur auf vertraglichem Extract, Qlik nur ohne Klarname-Assoziation.
- Drei Assets im Catalog anlegen (Ops-App, Extract, kritischste Liste) mit Owner und Zweck — Tag ist nicht Freigabe.
- Ist-Stack dokumentieren (HIS, PACS, Qlik/Tableau, Excel, Catalog) im Custom Stack Builder — nachdem Purpose und Owner stehen. Der Builder ersetzt weder MPI noch FHIR-Vertrag.
Weiterlesen
- Governance in der Healthcare-Landschaft
- OpenMetadata-Landschaft
- Catalog Deep Dive
- Operations-Landschaft
- BI-Governance-Entscheidungen
- Custom Stack Builder
Imaging, department Excel, and BI
Part 3 of 3
View series