TU Wien:Mobile Computing in Health Care VU (Tappeiner)
- Mobile Computing in Health Care VU (Tappeiner) (TU Wien, 0 Materialien)
- Mobile Computing in Health Care VU (Baranyi) (TU Wien, veraltet, 0 Materialien)
Daten[Bearbeiten | Quelltext bearbeiten]
Vortragende | Rene Baranyi• Geraldine Fitzpatrick• Karin Kappel• Barbara Tappeiner |
---|---|
ECTS | 3 |
Letzte Abhaltung | 2022S |
Sprache | Deutsch |
Mattermost | mobile-computing-in-health-care • Register • Mattermost-Infos |
Links | tiss:183636, eLearning |
Bachelorstudium Medizinische Informatik |
Inhalt[Bearbeiten | Quelltext bearbeiten]
Die Lehrveranstaltung gliedert sich in einen Vorlesungsteil, der als Block zu Beginn des Semesters abgehalten wird. Aufbauend auf die darin vermittelten theoretischen Grundlagen folgt eine Gruppenübung, in der Studenten die Wissensinhalte der Vorlesung anwenden und eine mobile Applikation entwickeln.
Im SS13 war das Thema des Vorlesungsteils die medizinische Triage und auf diesen theoretischen Kenntnissen aufbauend in der Übungsphase die Entwicklung eines elektronischen Triage-Tags (siehe Wikipedia: http://en.wikipedia.org/wiki/Triage_tag) in Form einer App (welches mobile OS dabei verwendet wurde ist dabei der Gruppe überlassen).
Ablauf[Bearbeiten | Quelltext bearbeiten]
Der Vorlesungsteil wird geblockt am Anfang des Semesters abgehalten und behandelt das Thema, das im Anschluss als Projekt von den 3er-Gruppen bearbeitet werden muss.
- Vorbesprechung zur Vorlesung (1h): Diese dient vor allen der Gruppenbildung. Im SS13 keine Anwesenheitspflicht! Wenn man jedoch noch keine Gruppe hat, wäre es durchaus sinnvoll hinzugehen.
- geblockte Vorlesungseinheiten (7.5h): Informationen über das in der Übungsphase zu bearbeitende Thema. Im SS13 wurde der Sinn der Triage erklärt, was Triage ist, warum Triage benötigt wird, usw.
Hat man ein Team gefunden (2er Teams sind wohl auch erlaubt, aber grundsätzlich 3er-Teams) kann man am Übungsteil der VU teilnehmen. Die Übung ist das einzig notengebende in dieser VU. Es gibt keine zusätzliche Prüfung am Ende des Semesters.
Es gibt 4 Abgaben im Übungsteil:
- Abgabe 1: Anforderungsanalyse, Projektplan, Use-Case-Analse bzw. User-Stories, Beschreibung des Workflows der App, Technische Spezifikationen, ... also ein Dokument ausarbeiten
- Abgabe 2: CDA-Dokument- und REST-Service-Definition (mit den anderen Gruppen gemeinsam auf ein einheitliches CDA-Schema und eine REST-Definition einigen - alle geben das selbe ab)
- Abgabe 3: 60% Zwischenabgabe. Zu diesem Zeitpunkt sollten 60% der im Projektplan definierten Funktionalität bereits implementiert/vorhanden sein.
- Abgabe 4: Finale Abgabe + Connectathon. Fertiggestelltes Projekt präsentieren vor den anderen Gruppen und im Anschluss Austausch der Backend-Daten um auf Server der anderen Gruppen zugreifen zu können.
Benötigte/Empfehlenswerte Vorkenntnisse[Bearbeiten | Quelltext bearbeiten]
- Programmiererfahrung im entsprechenden mobilen OS sind von Vorteil
- Software Engineering und Projektmanagement PR sollte davor gemacht werden (Wenn man keine Ahnung von Patterns wie DAOs/MVC bzw. generell von DB-Anwendungen hat, dürfte der Aufwand für MCHC wohl explodieren!)
Vortrag[Bearbeiten | Quelltext bearbeiten]
Die Vorlesungen in dieser VU sind nicht uninteressant und geben einen guten Einblick in die Thematik, die in der Übung bearbeitet werden muss. Anwesenheitspflicht herrscht nicht, aber es lohnt sich schon hinzugehen.
Übungen[Bearbeiten | Quelltext bearbeiten]
Aus der Übung ergibt sich die Note. D.h. es gibt keine Zwischentests/Prüfung über den in den in der Vorlesung behandelten Stoff.
Die App besteht aus einem Client (Android, iOS, ...) am Smartphone, der via REST mit dem Server-Backend kommuniziert. Bei der Kommunikation werden valide CDA-Dokumente (Level 1) gesendet.
Prüfung, Benotung[Bearbeiten | Quelltext bearbeiten]
Die Benotung erfolg über den Übungsteil und die ensprechenden Abgaben.
- Abgabe 1: 50 Punkte
- Abgabe 2: 50 Punkte
- Abgabe 3: 50 Punkte
- Abgabe 4: 100 Punkte: 50 Punkte für finale Abgabe/Präsentation und 50 Punkte für Connectathon (wurde uns von Herrn Köstlinger gesagt, jedoch hat der Connectathon im SS13 nicht funktioniert und uns wurden nur 10 Punkte abgezogen)
Die Benotung ist fair und eher "milde".
Dauer der Zeugnisausstellung[Bearbeiten | Quelltext bearbeiten]
- Finale Abgabe im SS13 am 21.6.2013 - Bewertung erhalten am 8.7.2013 - Zeugnis erhalten am 15.07.2013
Zeitaufwand[Bearbeiten | Quelltext bearbeiten]
- für Vorlesungen (Vorbesprechung 1h + Vorlesungseinheiten 7.5h): 8.5h
- für den Übungsteil pro Gruppenmitglied etwa 50h (etwa der Mittelwert, es gab Gruppen die Mitglieder mit bis zu 100h Aufwand hatten (mit weniger Programmiererfahrung im entsprechenden OS) und auch welche mit deutlich weniger Aufwand mit ca. 30h)
Unterlagen[Bearbeiten | Quelltext bearbeiten]
gibts im TUWEL-Kurs vor der Vorlesungseinheit
Tipps[Bearbeiten | Quelltext bearbeiten]
- umbedingt vor der CDA-/REST-Definition (2. Abgabe) über den CDA-Standard (und auch REST) informieren, da in diesem Schritt Dinge definiert werden, die in der Übungsphase ständig verwendet werden. Wenn hier bereits unnötig komplizierte Dinge festgelegt werden, leiden alle Gruppen während der Übungsphase an einer unterspezifizierten Lösung und beginnen Workarounds zu entwickeln was den Conencectathon dann schlussendlich zum Disconnectathon verkommen lässt.
- Umso genauer man die CDA-/REST-Defintion gestaltet, umso reibungsloser wird die Entwicklung von statten gehen. (WIRKLICH BEMÜHEN HIER! Nachträgliche Inter-Team-Kommunikation - für Korrekturen - verläuft idR nur sehr schleppend!)
- Kommunikation mit ALLEN anderen Gruppen aufrecht erhalten
- etwa eine Woche vor der finalen Abgabe (zumindest mit dem Server) fertig werden und Backend-Daten austauschen - hier können Fehler noch behoben werden.
- Achtung, viele Technologien die in der "sicheren Umgebung" des Computers gut funktionieren, könnten auf der Mobilen Plattform nicht laufen (z.B. der Jersey REST Client ist inkompatibel zu Android (Stand Juli 2013) - Ausweichmöglichkeit Apache HTTPClient)
- Wird das CDA-Dokument "per Hand" (o.ä.) und nicht mit den MDHT CDA-Tools erstellt, so empfiehlt es sich JSON als Datenstruktur für die Tag-Daten zu nutzen. (Keine eigenen XML-Tags! Das gibt nur Scherereien mit bereits existenten XML-Parsern!)
Verbesserungsvorschläge / Kritik[Bearbeiten | Quelltext bearbeiten]
- Übungsangabe ist jeweils nur eine Folie pro Abgabe - sehr dürftig. Dies lässt sehr viel Spielraum für Fehler. Beispielsweise wurde nirgends erwähnt, dass JUnit-Tests geschrieben werden müssen. Dies wurde bei der Abgabe jedoch bemängelt.
- Im SS13 haben die MCHC-Teams es (mit vereinten Kräften!!) nicht geschafft das empfohlene MDHT-Tool zur CDA-Dokument erstellen einzusetzen. Hierzu wurde von der LVA-Leitung jedoch auch kein Tutorial oder sonstwas gegeben und das Programm ist alles andere als Intuitiv. (Beginnend bei der Bedienung, bis zur Integration auf die mobile Plattform)