Bildgebung, Abteilungs-Excel und BI — der echte Datenpfad
Eine Fachabteilung führt Untersuchungslisten in Excel und erhält einen anderen Bestand als das Bildgebungssystem.
Der konkrete Auftrag in dieser Landschaft
Beispielfall: Eine Fachabteilung führt Untersuchungslisten in Excel und erhält einen anderen Bestand als das Bildgebungssystem. Kläre für einen Bericht, ob Untersuchung, Bildserie oder Behandlungsfall gezählt wird. Für den Abgleich werden nur die benötigten und freigegebenen Angaben übergeben.
Ergebnis für den ersten begrenzten Einsatz: Fachabteilung bestätigt Zählebene und Ausnahmen. Schnittstellenbetrieb und BI dokumentieren Auszug, Transformation und Aktualität; ein Katalog macht diese Entscheidung auffindbar, entscheidet sie aber nicht.
Die Kapitel helfen, die dafür nötigen Entscheidungen nacheinander zu klären. Wähle bei einer bestehenden Lösung den Teil, dessen Ergebnis noch fehlt.
- Problem und ersten Auftrag klären (dieses Kapitel).
- Extract-Bezugs- und Detailebene und Abteilungs-Listen führen
- BI-Fit und Catalog-Sichtbarkeit in der Klinik
Die Serie Healthcare Landscape erklärt, warum Care und Research getrennt sein müssen. Dieser Sibling erklärt, wo das in der Klinik hängt: an Modalitäts-Exports, Excel-Listen und der BI-App, die sie asso
Begriffe vor dem Lesen
- Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
- Owner — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
- Custodian — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
- Evidence — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.
ziiert oder visualisiert.
HIS und PACS bleiben Custodian. Die reale Betriebsfläche darunter sind Worklists, Gerätelogs, MTRA-Listen und die App, die Accession, Slot und Station zusammenzieht.
Die Serie Bildgebung, Abteilungs-Excel und BI gibt dir den Einstieg und den roten Faden für die folgenden Teile.
Ausgangslage
Die Radiologie steuert Durchsatz über eine Qlik-App. Die Warteliste lebt in Excel. Das MRT schreibt ein Protokoll. Tableau zeigt QM-Wartezeiten. OpenMetadata harvestet Warehouse-Tabellen — die Excel-Liste steht nicht im Catalog. Dieselbe RIS-Worklist speist Betrieb, QM und morgen die Studienkohorte. Niemand hat den Zweck an den Feed gehängt.
Diese Serie ist für dich, wenn Modalitäts-Export, Abteilungs-Excel und BI-App denselben Feed ohne Zweck teilen — oder Qlik-Assoziation und Catalog-Tag so tun, als wäre Care vs Research entschieden.
Nicht diese Serie, wenn du Care vs Research, Identität und Pseudonym schneiden musst — Healthcare Landscape — oder den FHIR-Consumer-Vertrag — FHIR-Schnittstellenverträge.
Was diese Serie klärt
- Orientierung: drei Produkte auf dem Chaos-Pfad (diese Seite)
- Vertiefung: Exportdatei-fachliche Zählebene und Abteilungs-Listen
- Abschluss: BI-Fit (Qlik, Tableau, Power BI, SAC, Looker, Excel) und Catalog-Sichtbarkeit
Begriffe vor dem Lesen
- Imaging-Ops — Steuerungsprodukt auf Study-/Accession-fachliche Zählebene; Metadaten ja, Pixel und Befundtext nein.
- Abteilungs-Liste — Excel/CSV, die einen Slot, eine Warteliste oder einen Dienstplan verändert; operatives Produkt, keine Hilfsdatei.
- BI-Konsumvertrag — Zweck der App, erlaubte Assoziationen oder Joins, fachliche Zählebene, Maskierung; die Engine ist Influence.
- Catalog-Sichtbarkeit — OpenMetadata oder eine Suite macht Assets auffindbar; der Tag ersetzt keine Purpose-Entscheidung.
Die Beispiele sind Lehrfälle (keine Patientendaten). Ersetzt Modalität, App- und Dateinamen durch eure RIS-, PACS-, Catalog- und Prozessquellen.
zdem wechselt der Zweck still zwischen Modalitäts-Export, Excel-Liste und BI-App. Ein Catalog-Tag oder Section Access ersetzt weder Purpose Binding noch den Identifier-Vertrag.
Entscheidung: Drei Produkte mit Owner führen: Imaging-Ops ohne Pixel, Abteilungs-Listen mit Ablösung, BI-/Catalog-Konsum mit Zweck an der App. Qlik, Tableau und OpenMetadata sind Influence — nicht Owner der Zweckentscheidung.
Merksatz: Governance hängt am Export und an der Assoziation, nicht am Dashboard und nicht am Metadatenimport.
Produkte und Entscheidungen
1. Imaging-Ops-Produkt
Study- oder Accession-Bezugs- und Detailebene. Felder: Modalität, Dauer, Gerät, Slot, Station, Accession. Nicht: DICOM-Pixel, Befund-PDF, Klarname. Owner ist ärztliche Leitung Radiologie oder OP — nicht der Qlik-Admin. Entscheidung: welcher Feed darf laden, welches Bezugs- und Detailebene gilt, wann der Job stoppt.
2. Abteilungs-Listen-Produkt
Jede Excel- oder CSV-Datei, die den nächsten Slot, die Warteliste oder den Dienstplan steuert, ist ein Produkt. Inventar, Kritikalität, Owner, Ablösungspfad — wie in Excel/CSV ablösen. Entscheidung: welche Datei führt, welche nur analysiert, welche tot ist.
3. Sichtbarkeit und Konsumvertrag
Die BI-App (Qlik, Tableau, Power BI, SAC, Looker) trägt einen Zweck. Der Catalog (OpenMetadata oder Suite) trägt Owner, Bezugs- und Detailebene und Feed — nicht die Freigabe. Entscheidung: welche Engine zu welchem Job, welche Assoziation oder welcher Join erlaubt ist, welches Asset im Catalog stehen muss.
Wo Governance hängt
Zwischen Modalitäts-Export / Excel-Liste / Catalog-Asset und der BI-App
Genau hier wechseln Kliniken den Zweck still. Dieselbe RIS-Worklist darf nicht ungeprüft Betrieb, QM und Research speisen. Der Breakpoint sitzt am Feed, nicht am Diagrammtyp.
Zwischen Pixel, Ops-Metadaten und Identität
DICOM-Objekt bleibt in PACS. Dauer, Gerät, Slot dürfen Operating. Patient, Diagnose, Befundtext brauchen Purpose Binding — Research extra.
Zwischen Assoziation oder Join und dem Identifier-Vertrag
Qlik verknüpft über Feldnamen. Tableau joint sichtbar. Beide können Excel-Warteliste und PACS-Accession zur de-facto Re-Identifikation machen. Dieselbe Identity Authority wie in Patientenidentität.
Zwischen App-Zweck und Section Access oder Zertifizierung
Station A sieht Station A — das ist Reduktion, kein Zweck. Tableau zertifiziert ist kein Care-Owner. Catalog-Tag ist kein Pseudonym-Gate.
Zwischen BI-Admin / PACS-Admin und Care Owner
Wer das Load Script oder die Published Data Source setzt, entscheidet nicht, ob Klaridentität die Ops-App verlassen darf.
Zwischen mehreren Engines im selben Haus
Qlik für Radiologie-Takt, Tableau für QM, SAC für DRG, Excel für den Dienstplan — normal. Das Problem ist die dritte Wahrheit dazwischen, nicht die zweite Lizenz.
Rollen-Mapping
Data Owner (Care / Radiologie / OP)
Ärztliche Leitung der Modalität oder des OP-Bereichs. Accountable für Zweck der Ops-App und Ablehnung eines Feeds mit Klaridentität.
Listen-Owner
Stations- oder MTRA-Leitung für die Datei, die den Slot steuert. Nicht „die, die das Excel kennen“.
Data Steward
Medizincontrolling, Radiologie-Koordination oder Research Ops triagiert Feeds, Bezugs- und Detailebene-Konflikte und Catalog-Lücken.
Data Custodian
HIS/PACS-Admin, Qlik- oder Tableau-Admin, Integration. Setzt Extract, Section Access, Join, Metadatenimport um — entscheidet den Zweck nicht.
Catalog-Steward
OpenMetadata- oder Suite-Betrieb. Macht Asset, Owner und Feed auffindbar. Metadatenimport ist kein Operating-Vertrag.
Mini-Fall
Alltagssituation: Eine Liste der Radiologieassistenz enthält Patientennamen, Untersuchungsnummern und Wunschzeiten. Eine Qlik-App verknüpft diese Liste mit dem Bildarchiv-Protokoll. Das Qualitätsmanagement kopiert denselben Export nach Tableau. Research bittet anschließend „nur um die Wartezeiten“, obwohl der Export viel mehr enthält.
Was schiefläuft: Operative Planung, Qualitätsauswertung und Forschung nutzen denselben Export, haben aber unterschiedliche Zwecke und Identitätsgrenzen. Ein Katalog-Tag oder ein anderes BI-Tool trennt diese Zwecke nicht.
Vereinbarung: Die operative Imaging-Liste läuft auf Untersuchungsnummer ohne Klarname, wo das genügt. Qualitätsauswertung bekommt einen eigenen Zweck und Empfängerkreis. Forschung läuft nur über den Pseudonymisierungspfad. Der Katalog zeigt alle drei Assets und ihre Grenzen.
Vereinbarung: Imaging-Ops auf Accession ohne Klarname. Listen-Produkt mit Owner und Ablösung. Eine Ops-App, ein QM-Exportdatei mit eigenem Zweck. Research hinter dem Pseudonym-Prüfpunkt aus der Gold-Serie. Catalog zeigt alle drei Assets.
Kritische Übergaben
| Von | An | Artefakt |
|---|---|---|
| Care Owner (Radiologie / OP) | Steward | Zweck der Ops-App plus erlaubtes Bezugs- und Detailebene |
| Listen-Owner | Steward | Inventareintrag, Kritikalität, Ablösungstermin |
| Steward | BI-Custodian (Qlik/Tableau/SAC) | Extract-Vertrag: Felder, Bezugs- und Detailebene, Maskierung, Stopp-Regel |
| Steward | Catalog-Steward | Asset-Karte: App, Datei, Feed, Owner, Zweck |
| Care Owner | Research Owner | Ablehnung, wenn derselbe Feed Kohorte werden soll |
| Custodian | Care Owner | Negativtest: Klarname verlässt die Ops-App nicht |
Anti-Patterns
- Qlik-App als inoffiziellen MPI betreiben, weil die Felder gleich heißen
- Tableau-Arbeitsmappe mit Klaridentität, weil QM „die Fälle sehen muss“
- Catalog-Tag oder Metadatenimport als Purpose Binding verkaufen
- Excel-Warteliste als Hilfsdatei behandeln, obwohl sie den Slot steuert
- Section Access oder Row-Level Security mit Care vs Research verwechseln
- Eine Engine zum Sieger küren und die anderen Feeds ignorieren
Umsetzung im Alltag
Wähle einen begrenzten betrieblichen Fall, an dem sich die beschriebene Entscheidung und ihre Umsetzung gemeinsam prüfen lassen.
Im verlinkten Arbeitsplan hältst du fest, wer die einzelnen Aufgaben übernimmt, bis wann sie erledigt werden und welche Entscheidungen noch offen sind.
Starte mit dem kleinsten echten 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.
- Eine Radiologie- oder OP-App wählen und alle Feeds listen (Excel, CSV, QVD, HIS, RIS, Catalog-Asset).
- Pixel und Klarname aus dem Ops-Extract streichen; Bezugs- und Detailebene auf Study/Accession setzen.
- Die kritischste Abteilungs-Liste mit Owner und Ablösungstermin versehen.
- Negativtest dokumentieren: Patientenname darf die Ops-App nicht als Klartext verlassen.
Weiterlesen
Arbeitsstand für die Übergabe
Vorbereiten und prüfen: Abgegrenzter Weg von Bildgebung und Arbeitsliste zum vereinbarten Bericht.
Nächste offene Aufgabe: Bestätigte Zählebene mit Herkunft, Fachbereichsliste und sichtbaren Ausnahmen. Extract-Bezugs- und Detailebene und Abteilungs-Listen führen.
Imaging, department Excel, and BI
Part 1 of 3
View series