Zum Inhalt springen
Search the hub
Bildgebung, Abteilungs-Excel und BI — der echte Datenpfad

Bildgebung, Abteilungs-Excel und BI — der echte Datenpfad

Operating-Sibling zur Healthcare-Landschaft: Imaging-Ops ohne Pixel, Abteilungs-Listen mit Owner und BI-/Catalog-Konsumvertrag — Zweck am Export, nicht am Dashboard.

Category
Data Governance
Reading time
6 min
Published
Tags
healthcare imaging excel qlik tableau openmetadata purpose-binding
Download PDF

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 assoziiert 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.

Vorher: Governance in Healthcare. Diese Serie ist kein sechster Teil von Care vs Research.

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 Ebene 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 Ebene; 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 Ebene, Maskierung; die Engine ist Influence.
  • Catalog-Sichtbarkeit — OpenMetadata oder eine Suite macht Assets auffindbar; der Tag ersetzt keine Purpose-Entscheidung.

Lesepfad

  1. Der echte Healthcare-Datenpfad
  2. Extract-Grain und Abteilungs-Listen
  3. BI-Fit und Catalog-Sichtbarkeit

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.

Lösung: 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.

In einem Satz: 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-Grain. 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 Grain 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, Grain 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, Grain-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

Symptom: 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.

Typischer Fehlstart: OpenMetadata anbinden und die App als certified taggen — oder Tableau kaufen, weil die Folien schöner sind — ohne Zweck am Feed und ohne Pixel-/Identitäts-Schnitt.

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 Grain
Listen-Owner Steward Inventareintrag, Kritikalität, Ablösungstermin
Steward BI-Custodian (Qlik/Tableau/SAC) Extract-Vertrag: Felder, Grain, 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

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.

  1. Eine Radiologie- oder OP-App wählen und alle Feeds listen (Excel, CSV, QVD, HIS, RIS, Catalog-Asset).
  2. Pixel und Klarname aus dem Ops-Extract streichen; Grain auf Study/Accession setzen.
  3. Die kritischste Abteilungs-Liste mit Owner und Ablösungstermin versehen.
  4. Negativtest dokumentieren: Patientenname darf die Ops-App nicht als Klartext verlassen.

Weiterlesen

Imaging, department Excel, and BI

Part 1 of 3

View series

Knowledge check

Tour