ErdDocs

Beispiele / Krankenhausverwaltung

Krankenhausverwaltung

Die Datenbank eines Krankenhauses dreht sich um zwei Ereignistabellen. Ein Termin ist ein ambulanter Besuch bei einer Ärztin oder einem Arzt, eine Aufnahme ein stationärer Aufenthalt. Beide Tabellen verweisen auf den Patienten. Verordnungen werden je Termin ausgestellt und verweisen auf einen Medikamentenkatalog.

Unten zeichnet ErdDocs dieses Schema aus seinem SQL, mit allen Tabellen und Beziehungen. Im Reiter „Data Dictionary“ finden Sie das druckbare Nachschlagewerk, vollständig und kostenlos auf dieser Seite. Das SQL steht weiter unten.

Ihr Schema

Fahren Sie über eine Tabelle, um ihre Beziehungen hervorzuheben. Ein Klick hält sie fest.

Wozu jede Tabelle dient

  • patientsDas Personal arbeitet mit der Patientennummer, mrn. Die Ersatz-id bleibt intern.
  • doctors / departmentsEine schlichte 1:n-Beziehung. Die Fachrichtung gehört zur Ärztin, nicht zur Abteilung.
  • appointmentsDer ambulante Besuch. Er hält Patient, Arzt, Zeit und Ergebnis fest.
  • admissionsDer stationäre Aufenthalt. Solange er dauert, bleibt discharged_at NULL.
  • medications / prescriptionsVerordnungen hängen am Termin, denn der Besuch liefert den klinischen Kontext.

Entwurfsentscheidungen zum Übernehmen

  • Termine und Aufnahmen stehen in getrennten Tabellen, nicht in einer Tabelle „Besuche“ mit Typspalte. Sie haben kaum gemeinsame Spalten. Zusammengelegt entstünden NULLs, deren Bedeutung vom Typ abhängt.
  • Verordnungen verweisen auf den Termin statt direkt auf Patient und Arzt. Der Besuch ist der Kontext für Audits, und Patient und Arzt erreicht man über ihn.
  • NULL in discharged_at heißt „noch stationär“. Das ist eine Tatsache, die man abfragen kann. Einen eigenen Statustext müsste man dagegen ständig nachführen.

Das SQL

PostgreSQL-Dialekt. Im Tool oben steht dieses SQL schon. Sie dürfen es frei kopieren und in die eigene Datenbank oder eine Migration übernehmen.

CREATE TABLE departments (
    id    bigserial   PRIMARY KEY,
    name  varchar(80) NOT NULL UNIQUE
);

CREATE TABLE doctors (
    id             bigserial    PRIMARY KEY,
    department_id  bigint       NOT NULL REFERENCES departments(id),
    full_name      varchar(120) NOT NULL,
    specialty      varchar(80)  NOT NULL
);

CREATE TABLE patients (
    id          bigserial    PRIMARY KEY,
    mrn         varchar(20)  NOT NULL UNIQUE,
    full_name   varchar(120) NOT NULL,
    born_on     date         NOT NULL,
    blood_type  varchar(3)
);
COMMENT ON COLUMN patients.mrn IS 'Patientennummer – die Kennung, die das Personal benutzt';

CREATE TABLE appointments (
    id          bigserial   PRIMARY KEY,
    patient_id  bigint      NOT NULL REFERENCES patients(id),
    doctor_id   bigint      NOT NULL REFERENCES doctors(id),
    at          timestamptz NOT NULL,
    status      varchar(20) NOT NULL DEFAULT 'booked',
    notes       text
);
COMMENT ON COLUMN appointments.status IS 'gebucht -> behandelt, oder nicht erschienen / abgesagt';

CREATE TABLE admissions (
    id           bigserial   PRIMARY KEY,
    patient_id   bigint      NOT NULL REFERENCES patients(id),
    ward         varchar(40) NOT NULL,
    admitted_at  timestamptz NOT NULL,
    discharged_at timestamptz
);
COMMENT ON COLUMN admissions.discharged_at IS 'NULL, solange der Patient stationär liegt';

CREATE TABLE medications (
    id    bigserial    PRIMARY KEY,
    name  varchar(120) NOT NULL,
    form  varchar(40)  NOT NULL
);
COMMENT ON COLUMN medications.form IS 'Tablette / Injektion / Saft …';

CREATE TABLE prescriptions (
    id              bigserial  PRIMARY KEY,
    appointment_id  bigint     NOT NULL REFERENCES appointments(id),
    medication_id   bigint     NOT NULL REFERENCES medications(id),
    dosage          varchar(60) NOT NULL,
    days            int        NOT NULL
);

Häufige Fragen

Wohin gehören Laboruntersuchungen?

Dafür braucht es zwei Tabellen. lab_orders verweist auf den Termin, wie die Verordnungen. lab_results verweist auf lab_orders, als 1:1 oder 1:n, je nachdem, ob ein Panel mehrere Werte meldet.

Reicht eine Ärztetabelle auch für Pflege und Personal?

Für ein Übungsschema genügt eine Tabelle staff mit Rollenspalte. Echte Systeme trennen das klinische Personal, weil sich Dienstplan, Approbation und Abrechnung unterscheiden. Fangen Sie einfach an und trennen Sie erst, wenn eine Abfrage es verlangt.

Weitere Beispiele