Flache Datenstrukturen in der Operationsdokumentation.

Präsentation zum Thema: "Flache Datenstrukturen in der Operationsdokumentation."—  Präsentation transkript:

1 Flache Datenstrukturen in der Operationsdokumentation.

2 Definition Eine Datenbank ist eine Gruppe von Tabellen, die durch Relationen verknüpft sind. Eine Tabelle besteht aus Feldern (Spalten) und Datensätzen (Zeilen). Flache Datenstrukturen zeichnen sich durch eine hohe Anzahl von Feldern und eine vergleichsweise geringe Anzahl von Datensätzen aus, die nicht weiter normalisiert werden können. Typischerweise enthalten FDS große Redundanzen an nicht benutzten Feldern pro Datensatz.

3 Wo gibt es flache Datenstrukturen?
FDS trifft man vor allem in der medizinischen Dokumentation bzw. Operationsdokumentation. Die hohe Anzahl der Merkmale (Felder) ergibt sich aus der Komplexität der medizinischen Fachgebiete. Die Notwendigkeit eine strukturierten Datenerfassung ergibt sich aus dem Wunsch nach statistischen Auswertungen sowie nach hierarchisch strukturierter und validierter Dateneingabe. Die 1:1 Beziehung zwischen Merkmal und Patient bedingt das Fehlen relationaler Strukturen. Redundanzen folgen daraus, daß jeder Patient nur einen bestimmten Teilaspekt des Gesamtsystems abdeckt. Ca. 95% der Felder werden im Einzelfall nicht gebraucht.

4 Welche spezifischen Aufgaben ergeben sich aus FDS?
Fachwissen Systemanalyse Aufgabenverteilung Datenbank Datenerfassung Auswertung

5 Fachwissen Das medizinische Fachwissen ist immens und für den EDV-Fachmann kaum erlernbar, ebenso ist die Kompetenzanforderung an den Programmierer hoch und nicht durch einen Arzt im Schnellgang aufzuholen. Am Markt werden Lösungen von EDV-kompetenten Fachmedizinern oder im Team erarbeitete Lösungen angeboten. Lösungen sollten die Kompetenzverteilung berücksichtigen und an Ort und Stelle belassen.

6 Systemanalyse Bereits in der Systemanalyse ist der EDV-Fachmann regelmäßig überfordert. Budgets werden nur geschätzt, da die Kompetenzen fehlen um realitätsnah und zuverlässig zu budgetieren. Die klassische Reihenfolge: Systemanalyse, Budgetierung, Umsetzung ist nicht machbar. Die Systemanalyse muss in die Umsetzung integriert werden, das System muss also von vornherein ‚offen‘ für Veränderungen programmiert werden.

7 FDS – Datenbank Die Anzahl der Felder einer Tabelle ist im Normalfall auf 255 beschränkt. Tausende von Feldern erfordern demnach dutzende von Tabellen, die durch Relationen verknüpft sind. Alternativ können die Merkmale in einer einzigen Tabelle gespeichert werden. Daten werden umgebrochen, vgl. Tabellendesigner VFP. Die Beziehung zwischen Feldern und Datensätzen wird ‚auf den Kopf gestellt‘.

8 Datenerfassung Wie bekomme ich tausende von Feldern auf eine Bildschirmseite? Dynamischer Bildschirmaufbau statt fester Programmierung. Dynamische Objekte haben drei Anzeige-Modi zur effektiven Nutzung der Bildschirmfläche. Hierarchische Strukturen, Datenobjektbäume, Eltern-Kind Beziehungen. Validierung im Datenobjektbaum. Kopieren von Standardobjekten und ihren ‚Familien‘.

9 Datenerfassung/Programmierung
Wo ist denn hier die controlsource? Arrays als Datenpuffer. Container und Objekte. Modi umschalten. Offenes Datenmodell. Validierung.

10 Der OP-Bericht Daten vom Kopf auf die Füße stellen. Spaltenlayout.
Wer gestaltet den OP-Bericht? Aufgabenverteilung und Programmierung. Patienten-Stammdaten.

11 Abfragen Das Zurückführen der FDS in normalisierte Tabellen.
Relationen ade? Einfache Abfragen. Komplexe Abfragen. Aufteilen komplexer Abfragen. Aufgabenverteilung.

12 Zeichnen mit VFP? VFP ist kein Zeichenprogramm, aber...
Schemen (Folien) und Symbole. Zeichnungen ‚speichern‘. Bitmaps herstellen und drucken. Datensensitives Zeichnen, hier wird der Fuchs wieder stark. Grenzen des Zeichnens mit VFP.