Patientenbett-Verwaltung Verfasser: Roman B., Marcel H., Micha H., Markus S. Projektart: MySQL Datenbank mit grafischer Benutzeroberfläche (Java), aus den Modulen DB, SWE und D&K Im Auftrag und Betreuung von: Prof. Dr. Datum: 1. Juni 2004
Inhaltsverzeichnis 1 Zielbestimmung 3 1.1 Musskriterien 3 1.2 Wunschkriterien 3 1.3 Abgrenzungskriterien 3 2 Produkteinsatz 4 2.1 Anwendungsbereiche 4 2.2 Zielgruppen 4 2.3 Betriebsbedingungen 4 3 Produktübersicht 4 4 Produktfunktionen 5 5 Produktdaten 17 5.1 Daten zum Patient 17 5.2 Daten zum Fall 17 5.3 Daten zur Bettendisposition 18 6 Produktleistungen 18 7 Qualitätsanforderungen 19 8 Benutzungsoberfläche 20 8.1 Grundlegende Anforderungen 20 8.2 GUI - Entwurf und Prototyp 20 9 Nichtfunktionale Anforderungen 22 10 Technische Produktumgebung 22 10.1 Software 22 10.2 Hardware 22 10.3 Orgware 22 10.4 Produkt-Schnittstellen 22 11 Spez. Anforderungen an die Entwicklungsumgebung 22 12 Gliederung in Teilprodukte 22 13 Ergänzungen 23 14 Glossar 23 Seite 2
1 Zielbestimmung Das Produkt soll die Disposition der Bettenbelegung, welche bis jetzt von Hand gemacht wurde, automatisieren und vereinfachen. Die Software soll Spitäler in die Lage versetzen, ihre Bettendisposition rechnergestützt durchzuführen. Es soll möglich sein, sich rasch einen Überblick über die aktuelle Bettenauslastung zu verschaffen. 1.1 Musskriterien Verwalten: Verwalten der Patientendaten Verwalten der Fälle der Patienten gemäss Diagnose Verwalten von Spezialbehandlungen der Patienten Verwalten der Bettenbelegung Betten automatisch zuteilen Informieren: Anzeige von Historydaten eines Patienten Wie viele Betten sind im Moment frei, besetzt oder reserviert? Wann werden die Betten von wem genutzt? 1.2 Wunschkriterien Passwortschutz Statistische Informationen über Patienten und Fälle Abteilungen aus verschiedenen Gebäuden auswählen 1.3 Abgrenzungskriterien Keine Verwaltung der Zimmer Keine Verwaltung der Abteilungen Keine integrierte Buchhaltung Keine Schnittstelle zu einem Buchhaltungssystem, deshalb auch keine Abfrage über Bettenbelegung der Vergangenheit Seite 3
2 Produkteinsatz Die zu entwickelnde Software soll die Disposition von Betten in einem Spital ermöglichen. Die unterschiedlichen Zimmer-, Patienten- und Abteilungskategorien müssen zugeteilt werden können. Es muss jederzeit möglich sein, sich einen Überblick über die Bettenbelegung für einen bestimmten Zeitpunkt zu verschaffen. 2.1 Anwendungsbereiche Administrativer und organisatorischer Anwendungsbereich in Spitälern. 2.2 Zielgruppen Bettendisponent Stationsschwester 2.3 Betriebsbedingungen Das Produkt wird auf einem normalen Arbeitsplatzrechner (PC) ausgeführt. 3 Produktübersicht Abbildung 1: Übersichtsdiagramm der Geschäftsprozesse Seite 4
4 Produktfunktionen /F01/ Geschäftsprozess: Benutzer Login Vorbedingung: Benutzer ist erfasst Nachbedingung Erfolg: Benutzer ist angemeldet Nachbedingung Fehlschlag: Anwender hat kein Benutzerrecht Akteure: Bettendisponent, Stationsschwester Auslösendes Ereignis: Programm wird gestartet 1. Programm starten 2. Der Benutzername eingeben 3. Passwort eingeben 4. OK wählen Erweiterung: Softwareupdate um sich an externem Server anzumelden. Alternativen: keine Seite 5
/F10/ Geschäftsprozess: Patient erfassen Vorbedingung: Patient ist noch nicht erfasst Nachbedingung Erfolg: Patient ist erfasst Nachbedingung Fehlschlag: Aufnahme erfolgt nicht Akteure: Bettendisponent Auslösendes Ereignis: Patient kommt zum ersten mal ins Spital 1. Register "Patient" auswählen 2. Neu anklicken 3. Persönliche Angaben erfassen 4. Versicherungsart auswählen 5. Speichern Erweiterung: mit OK gelangt man zur Fallerfassung Alternativen: Patient suchen, mutieren Seite 6
/F15/ Geschäftsprozess: Patient suchen Vorbedingung: Patient ist bereits erfasst im Spital Nachbedingung Erfolg: Patientendaten werden angezeigt Nachbedingung Fehlschlag: Patient ist unbekannt Akteure: Bettendisponent, Stationsschwester Auslösendes Ereignis: Patient meldet sich erneut beim Spital 1. Register "Patient" auswählen 2. Suchen anklicken 3. mindestens ein bekannter Parameter angeben 4. Suchen anklicken 5. In der Liste den gesuchten Patienten auswählen 6. OK klicken Erweiterung: keine Alternativen: neuen Patienten erfassen Seite 7
/F20/ Geschäftsprozess: Patient mutieren Vorbedingung: Patient ist erfasst. Nachbedingung Erfolg: Patientendaten wurden geändert Nachbedingung Fehlschlag: Patientendaten sind nicht geändert Akteure: Bettendisponent Auslösendes Ereignis: a) Patientendaten haben sich geändert b) Patient ist verstorben 1. Register "Patient" auswählen 2. Mutieren anklicken 3. gewünschte Daten ändern 4. Speichern Erweiterung: zuerst /F15/ Patient suchen Alternativen: neuen Patient erfassen Seite 8
/F30/ Geschäftsprozess: Fall erfassen Vorbedingung: Patientendaten erfasst Nachbedingung Erfolg: Fall erfolgreich aufgenommen Nachbedingung Fehlschlag: Fall konnte nicht erfasst werden Akteure: Bettendisponent Auslösendes Ereignis: a) Diagnose durch Arzt b) ev. Verordnung von Spezialbehandlungen (zb. Massage) 1. Patientendaten abrufen 2. Neu auswählen 3. Patient auswählen (siehe Kurzaddresse) 3. Leistungserbringer auswählen 4. Diagnose-Code erfassen 5. Spezialbehandlung erfassen 6. Speichern Erweiterung: keine Alternativen: Neuen Patienten erfassen, Fall mutieren Seite 9
/F35/ Geschäftsprozess: Fall suchen Vorbedingung: Fall ist erfasst Nachbedingung Erfolg: Fall des gewünschten Patienten wird angezeigt Nachbedingung Fehlschlag: Fall ist noch nicht erfasst Akteure: Bettendisponent, Stationsschwester Auslösendes Ereignis: Informationsbedarf zu erfasstem Fall 1. Im Register "Fall" Suchen anklicken 2. Falldaten eingeben 3. Suchen 4. gesuchten Fall aus Liste auswählen Erweiterung: keine Alternativen: keine Seite 10
/F40/ Geschäftsprozess: Fall mutieren Vorbedingung: Fall muss bereits erfasst sein Nachbedingung Erfolg: Mutation erfolgreich abgeschlossen Nachbedingung Fehlschlag: Mutation wird nicht durchgeführt Akteure: Bettendisponent Auslösendes Ereignis: Patient in Behandlung bekommt neue Anweisungen des Arztes oder ist als falscher Fall erfasst 1. Falldaten abrufen 2. Mutieren wählen 3. Änderungen vornehmen 4. Speichern Erweiterung: keine Alternativen: keine Seite 11
/F45/ Geschäftsprozess: Fall abschliessen Vorbedingung: Fall erfolgreich aufgenommen Nachbedingung Erfolg: Fall abgeschlossen, Bett wieder frei Nachbedingung Fehlschlag: Fall bleibt aktiv Akteure: Bettendisponent Auslösendes Ereignis: Fall ist abgeschlossen und der Patient verlässt das Spital 1. Falldaten abrufen 2. Status auf abgeschlossen ändern 3. Speichern Erweiterung: keine Alternativen: Fall wird wiedereröffnet, Fall mutieren Seite 12
/F50/ Geschäftsprozess: Bett zuteilen Vorbedingung: Fall erfolgreich aufgenommen Nachbedingung Erfolg: Bett wurde zugeteilt Nachbedingung Fehlschlag: Bett konnte nicht zugeteilt werden Akteure: Bettendisponent Auslösendes Ereignis: Diagnose: stationäre Behandlung im Spital 1. Falldaten abrufen 3. Abteilung zuteilen 4. Zimmer zuteilen 5. Bett zuteilen 6. Zeitdauer bestimmen 7. Bett reservieren oder belegen 8. Speichern Erweiterung: Zusatzleistungen wie Fernseher erfassen; Bett automatisch zuteilen Alternativen: keine Seite 13
/F55/ Geschäftsprozess: Bett suchen Vorbedingung: Bett existiert Nachbedingung Erfolg: Bettdaten werden angezeigt Nachbedingung Fehlschlag: Bett wird nicht angezeigt Akteure: Bettendisponent, Staationsschwester Auslösendes Ereignis: Informationsbedarf über bestimmtes Bett 1. Bettendisposition auswählen 2. Bettdaten eingeben 3. Suchen 4. gewünschtes Bett aus Liste auswählen Erweiterung: keine Alternativen: keine Seite 14
/F60/ Geschäftsprozess: Bett mutieren Vorbedingung: Bett / Zimmer zugeteilt Nachbedingung Erfolg: Bett wurde erfolgreich geändert Nachbedingung Fehlschlag: Bett konnte nicht geändert werden Akteure: Bettendisponent Auslösendes Ereignis: Patient wird verlegt oder der geplante Aufenthalt hat sich verändert. Der Patient nimmt eine Zusatzleistung wie Telefon in Anspruch 1. Falldaten auswählen 2. Bettzuteilung abrufen 3. Daten ändern Erweiterung: keine Alternativen: Fall abschliessen und einen neuen Fall eröffnen Seite 15
/F70/ Geschäftsprozess: Informieren Vorbedingung: keine Nachbedingung Erfolg: Benutzer hat gewünschte Information Nachbedingung Fehlschlag: Auskunft konnte nicht erteilt werden Akteure: Stationsschwester, Bettendisponent Auslösendes Ereignis: Informationsbedarf 1 Benutzer wählt Statistik 2 Benutzer informiert sich anhand der Daten Erweiterung: keine Alternativen: keine Seite 16
5 Produktdaten 5.1 Daten zum Patient /D10/ patient PatientID, PName, PVorname, PStrasse, PPLZ, POrt, PGeschlecht, PTelefonNr, PgebDat, PAHVNr, Versart, Status 5.2 Daten zum Fall /D20/ fall FallID, Patient, Leistungserbringer, Status /D30/ diagnosen Fall, DiagnosenTyp, Bemerkungen /D35/ diagnosentyp DiagnosenTypID, Name, FallNr, Stellplatz /D40/ spezbeh Fall, SpezBehTyp, Bemerkung /D45/ spezialbehtyp Spezialid, Name /D50/ leistungserbringer LeistungserbringerID, LBName, LBStrasse, Plz, Ort Seite 17
5.3 Daten zur Bettendisposition /D100/ liege FallNr, Stellplatz, ZusatzFeatures, BettenPlzNr /D110/ bettenstatus BettenPlzNr, Bettenstatus, belegtvon, belegtbis, Zimmer, ZimmerID /D120/ zimmer ZimmerID, Kategorie, Abteilung, abtid /D130/ abteilung abtid, AbtName, Gebauede, GebauedeID 6 Produktleistungen Für ein angnehmes Arbeiten soll die Reaktionszeit für Abfragen und Speichern unter einer Sekunde liegen. Seite 18
7 Qualitätsanforderungen Produktqualität sehr gut gut normal nicht relevant Funktionalität Angemessenheit Richtigkeit Interoperabilität Ordnungsmässigkeit Sicherheit Zuverlässigkeit Reife Fehlertoleranz Wiederherstellbarkeit Benutzbarkeit Verständlichkeit Erlernbarkeit Bedienbarkeit Effizienz Zeitverhalten Verbrauchsverhalten Änderbarkeit Analysierbarkeit Modifizierbarkeit Stabilität Prüfbarkeit Übertragbarkeit Anpassbarkeit Installierbarkeit Konformität Austauschbarkeit Seite 19
8 Benutzungsoberfläche 8.1 Grundlegende Anforderungen /B10/ Die Benutzungsoberfläche muss mit Java 1.4.x realisiert werden. /B20/ Ergonomische Grundsätze sollen beim Layout berücksichtigt werden. /B30/ Die Bedienungsoberfläche ist auf Mausbedienung auszulegen. 8.2 GUI - Entwurf und Prototyp Menüzeile Patient Fall Betten / Zimmer persönliche Daten Krankenkasse History Grafik: GUI Entwurf Seite 20
Grafik: GUI Entwurf (Fall) Menüzeile Patient Fall Betten / Zimmer Suchen Mutieren Neu Kuzadresse Patient Vorname, Name, Ort Diagnose Diagn. Typ Name Bemerkung Leistungserbringer Bemerkung Spezialbehandlung Name Bemerkung OK Abbruch Bild: Prototyp GUI (Bettendispo) Seite 21
9 Nichtfunktionale Anforderungen Die Basisdaten der Fälle haben bei der Einführung der Software im Spital nach den rechtlich geltenden Bestimmungen nach dem Katalog (normierte Diagnosen) zu erfolgen. Die Benutzerrechte sind, gemäss geltendem Recht über den Datenschutz bei der Einführung mit dem verantwortlichen Administrator zu implementieren. 10 Technische Produktumgebung Das Produkt ist als Einzelplatzanwendung zu konzipieren. 10.1 Software Java2 Laufzeitumgebung (J2RE) Version 1.4.2 muss lauffähig sein Windows 2000; P Datenbank MySQL ab Version 4.0 Constrains werden nicht in der Datenbank erstellt, da myisam - Tabellen diese nicht unterstützen (MySQL - Standard). 10.2 Hardware Arbeitsplatzrechner (PC: Pentium 3 oder besser) 10.3 Orgware Keine 10.4 Produkt-Schnittstellen Keine 11 Spez. Anforderungen an die Entwicklungsumgebung IDE: JBuilder 9 mit J2SE (Java2 Standard Edition) Vers.1.4.2 für Implementierung des Java Source-Codes 12 Gliederung in Teilprodukte Keine Seite 22
13 Ergänzungen Keine 14 Glossar GUI Historydaten IDE J2RE JBuilder 9 Login Graphical User Interface, grafische Benutzeroberfläche Daten aus der Vergangenheit Integrated Development Environment Java 2 Runtime Environment Entwicklungsumgebung für Java von der Firma Borland (US) Anmeldung des Benutzers beim Programmstart Seite 23