(1) Summarize the project goals, context, and stakeholders

Wir hatten uns als Ziel gesetzt, eine App zu erstellen, mit der es möglich ist, Krankenkassen hinsichtlich ihrer angebotenen ePa zu vergleichen. Die Handhabung der App sollte dabei auf dem “Swiping” Prinzip von Datingapps wie Tinder basieren. Es sollen also verschiedene Thesen präsentiert werden, denen die nutzende Person zustimmen, sie ablehnen oder sich enthalten kann. Beim finalen Namen haben wir uns für “MediMatch” entschieden.
Auf das Thema sind wir gestoßen, da sich der Kurs in diesem Semester mit der elektronischen Patientenakte (ePA) sowie Digitalen Gesundheitsapps (DiGas) beschäftigt hat. Zur Auswahl der Projekte standen dann ebendiese beiden Hauptthemen. Nachdem wir uns zunächst darüber informiert hatten, welche ePA Anbieter es gibt um uns eine davon auszusuchen, bekamen wir die Idee, diesen Vergleichsprozess in einer sinnvollen Art unterzubringen. Von der ursprünglichen Aufgabe eine bestehende Oberfläche zu vergleichen kamen wir somit etwas ab, was nach Rücksprache aber kein Problem darstellte.
Stakeholder sind bei uns neben den Designer*innen und Entwickler*innen insbesondere Nutzende, die gerade ihr 25. Lebensjahr abgeschlossen haben und damit aus der Familienversicherung ihrer Krankenkasse rutschen. Im weiteren Sinne sind Stakeholder bei uns außerdem die Krankenkassen selbst, da es natürlich in deren Interesse ist, Mitglieder zu halten oder zu gewinnen, und deren Angebot sich in der App widerspiegelt.
Als weitere, indirekte, Stakeholder haben wir beispielsweise die Datenschutzbeauftragte, oder Werbetreibende, welche mit den Krankenkassen zusammenarbeiten.

(2) Summarize your test results.

• What method(s) did you use to evaluate the results of your usability tests?
  Wir haben uns für ein “User Experience Questionaire” (UEQ) entschieden, um Feedback festzuhalten. Dieses haben wir ausfüllen lassen, nachdem der*die Tester*in unsere fünf Tasks durchgearbeitet hat:
  
  1. Tutorial
  2. Start der ePA Suche
  3. Infotaste
  4. Zurücktaste
  5. Test bis zum Ende
  
  Währenddessen haben wir mündlich gegebenes Feedback mitgeschrieben.
  Insgesamt hatten wir vier Tester*innen.

• How did you evaluate the results?
  Für das Auswerten betrachten wir erst die Zeit und das gegebene Feedback pro Task und am Ende den Durchschnitt des UEQs.
  
  
  • Task 1: Absolviere das Tutorial von MediMatch
    • Durchschnittliche Zeit: 2.25 Minuten
    • Mündliches Feedback:
      • “deine” groß schreiben
      • Beispieltext besser schreiben
      • Buttons schrittweise oder alles?
      • Nach dem ersten Drücken gemerkt wie es geht
      • Nach dem ersten Drücken erst verstanden
      • “Weiter Button” im Tutorial
        
        
  • Task 2: Starte die ePA Suche
    • Durchschnittliche Zeit: < 1 Minute
    • Mündliches Feedback: /
      
      
  • Task 3: Verwende die Informationstaste für zusätzliche Informationen zur Frage
    • Durchschnittliche Zeit: < 1 Minute
    • Mündliches Feedback: /
      
      
  • Task 4: Verwende die Zurück-Taste um deine Antwort zu überarbeiten
    • Durchschnittliche Zeit: 1 Minute
    • Mündliches Feedback:
      • Beim Neustarten wieder auf die Landing Page
      • Man sieht nicht, was man ausgewählt hat
      • Bei letzter Frage geht es nicht mehr zurück
        
        
  • Task 5: Führe den Test bis zum Ende durch um dein Ergebnis zu erfahren
    • Durchschnittliche Zeit: 3.75 Minuten
    • Mündliches Feedback:
      • Infobuttons
      • Mediplaner besser erklären
      • Proaktivere Fragen
      • Informationshintergründe und Datenschutz besser darstellen
        
        
  • UEQ:
    • behindernd 1  5.50   7   unterstützend
    • kompliziert 1 6.75   7   einfach
    • ineffizient 1 5.25   7   effizient
    • verwirrend 1 6.75   7   übersichtlich
    • langweilig 1 3.75   7   spannend
    • uninteressant 1 5.25   7   interessant
    • koventionell 1 4.00   7   originell
    • herkömmlich 1 4.75   7   neuartig

• What did you learn from the testing? What are your main takeaways? Please list these takeaways.
  Wir haben vor allem gelernt, dass wir das Design noch anpassen können. Es wird auch nach der Anpassung nicht originell, aber das war zu erwarten. Der main Takeaway hier ist, dass wir im Tutorial klarer machen sollten, wie das gesamte Layout funktioniert statt Knöpfe nacheinander einzuführen. Die Fragen/Thesen und ihre Beschreibung bedarfen auch Überarbeitung.
  Was uns gut gelungen ist, ist eine einfache und übersichtliche Oberfläche zu schaffen, wie die Ergebnisse des UEQs zeigen (jeweils 6.75 von 7 möglichen Punkten).
  Dass es dabei langweilig ist (3.75 Punkte) haben wir in Kauf genommen, um es simpel und minimalistisch zu halten.

(3) Compare your results with the defined problem (problem statement) you wanted to solve.

• To what extent have you been able to meet your goals? Discuss it.
  Unser Ziel haben wir nur teilweise erreicht. Aufgrund der Einschränkungen von Penpot (fehlende Logik, hohe Redundanz der Screens) ist ein tatsächlicher Vergleich aktuell nicht möglich. Außerdem fehlen tatsächliche Infos der Krankenkassen sowie Links zu weiterführenden Quellen wie den Websites der KK.
  Was wir aber geschafft haben, ist ein Prototyp für ein sinnvollen Design, bei dem noch leichte Änderungen erfolgen müssen. Die Idee sowie die aktuelle Umsetzung wurde den den Testenden positiv aufgenommen, wir sind also auf dem richtigen Weg.

• What would be your next steps? How would you proceed with this project?
  Unsere nächsten Schritte wären es, den Prototypen anhand des gesammelten Feedbacks zu verbessern. Im Anschluss würden wir eine neue Testrunde starten, und das neue Feedback wieder einfließen lassen. Dabei würden wir einen tatsächlich funktionierenden Prototypen bauen. Das bedeutet für uns, dass wir weg von Penpot hin zu Code wechseln. Hauptgrund ist, dass es bei Penpot aktuell nicht möglich ist, Logik einzubauen. Allerdings brauchen wir auch irgendwann ein Produkt, dass deployed werden kann.
  Sobald dieser neue Prototyp steht, sollten wir uns Gedanken über die Finanzierung machen und ggf. Werbepartner finden. Dabei schließen wir Krankenkassen als Sponsoren aus, um unabhängig zu bleiben. Möglicherweise können wir mit Geldern vom Bund gesponsort werden.
  Gleichzeitig brauchen wir Kontakte zu den Krankenkassen, um rechtliche Sachen wie Urheberrechte, aber auch inhaltliche Fragen, wie Antworten auf die Thesen zu klären.

(1) Continue to improve your high-fidelity prototype.

(2) Prepare for a summative evaluation

Script:
Wir heißen Sie herzlich willkommen und möchten uns aufrichtig bei Ihnen bedanken, dass Sie sich die Zeit genommen haben, an diesem Test teilzunehmen.
Wir sind Studierende der Informatik an der FU-Berlin und beschäftigen uns im Rahmen der Veranstaltung „Human-Computer Interaction“ in diesem Sommersemester mit der elektronischen Patientenakte. Unser Ziel ist es, eine Oberfläche zu entwickeln, die ähnlich dem Wahl-O-Mat funktioniert und es den Nutzenden ermöglicht, die passende Krankenkasse bzw. ePA für ihre Bedürfnisse zu finden.

Zu diesem Zweck haben wir einen Prototypen entwickelt und möchten gerne mit Ihnen einen Usability-Test durchführen. Damit wir die Daten aus diesem Test verwenden dürfen, benötigen wir Ihre unterschriebene Einverständniserklärung. Wir möchten betonen, dass Sie sich keine Sorgen machen müssen, etwas falsch zu machen. Wir führen den Test nicht an Ihnen durch, sondern am Prototypen selbst. Ihr Verhalten während des Tests hilft uns dabei, mögliche Verbesserungen am Prototypen zu identifizieren.

Während des Tests werden wir Ihnen Aufgaben stellen, die Sie mit unserem Prototypen ausführen sollen. Wir bitten Sie darum, Ihre Gedanken während der Bearbeitung der Aufgaben laut auszusprechen.

Consent form:
https://drive.google.com/file/d/1inT8J6fNePocxLqaA-Y93ZWSf0Gp1PJC/view?usp=sharing

Usability Test Observation Coding Form:
https://drive.google.com/file/d/1Y60lTsLu9m-FuFDQ1cZa011VM1L8z169/view?usp=sharing

Taskflows:

1. Absolviere das Tutorial von MediMatch
2. Starte die ePA Suche
3. Verwende die Informationstaste für zusätzliche Informationen zur Frage
4. Verwende die Zurück-Taste um deine Antwort zu überarbeiten
5. Führe den Test bis zum Ende durch um dein Ergebnis zu erfahren

Post-task or post-test questionnaire:

Wir haben uns entschieden, die abgespeckte Version des User Experience Questionnaire (UEQ) zu verwenden. Ein Post-Test-Fragebogen passt gut zu unserem Vorhaben, da wir nur wenige Funktionen testen und die Aufgaben kurz sind. Die verkürzte Version gefällt uns besser, da sie uns ermöglicht, die Bewertungspunkte klarer voneinander abzugrenzen als die Langversion. Außerdem reicht die verkürzte Version für unser kleines Projekt völlig aus. Dadurch können wir die Testergebnisse auch leichter vergleichen.

https://drive.google.com/file/d/1YGlM2MrUO6wGU1qWrOC00-M4q2gkKHDm/view?usp=sharing

Aufgrund unseres Projektes und sich der daraus ergebenen Probleme haben wir diese Woche nur ein Interview führen können. Wir holen die Aufgaben nach, sobald wir mehr Interviews geführt haben.

Wer hat welchen Beitrag geleistet?
Wir haben das Interview gemeinsam geführt.

Was habt ihr gelernt?
– In dem Interview haben wir Anreize zur Finalisierung unseres Themas bekommen

Was lief gut?
– Kontaktpersonen

Was möchtet ihr verbessern?
– Mehr Interviews führen
– Gewünschtes Interface planen

Summary of the article:
“Humanity-Centered Design” cares less about designing small things and more about designing political systems that solve 21st-century problems like the climate crisis, world hunger, poverty, etc. Thus, in addition to Human-Centered design, the focus is not only on individuals but on all of humanity and all living beings and their environment.

Our main takeaways:
The most important principle is to design together with the community and not for the community. Unfortunately, this is not feasible for our small student project. What we can do, however, is to examine how the electronic health record has so far been developed past the needs of the community.
Another important principle of humanity-centered design that we would like to use for our project is to solve the root cause of the problems, not just the problem itself.
Continually testing the design isn’t feasible either, because we do not have a test group. We might show it to the other people in the course or friends and family, but those tests are not representative.

More useful resources:
• Telematics infrastructure of gematik:
https://www.gematik.de/telematikinfrastruktur
• Bitmarck’s plan for future versions of the ePA

• Disruptions in the gematik telematics infrastructure: https://fachportal.gematik.de/ti-status#c7551

More resources on the Cyber attack:
• Bitmarck’s FAQ on the cyber attack

• Tagesspiegel’s article on the cyber attack, in which interesting questions are asked:
“When one considers the major role that the ePA is to play in the future for the treatment of insured persons and also for health research, one can nevertheless ask whether it is really such a good thing that 80 out of 96 health insurance companies depend on Bitmarck for IT issues. Measured in terms of the number of insureds, the company is also systemically important, with a one-third share of the SHI market. However, the success of the ePA stands and falls with the security of the data stored there.”
(https://background.tagesspiegel.de/cybersecurity/systemrisiko-bitmarck; translated to English)

• Heise article on the cyber attack

• Especially interesting comments on the Heise article:
„Umfangreicher Artikel zum Vorfall wünschenswert„

„Völlig vernachlässigt in der bisherigen Berichterstattung …„

„„Nachwirkungen“ ist völlige Untertreibung„

• More than one week after the cyber attack, the health insurance company SBK is not even reachable via e-mail: https://www.sbk.org/

The other W-questions:
1. What is the challenge you would like to tackle?
For example, the registration process is challenging, the privacy policy is not well explained, and the utility of the app is not transparent.

We aim to address the infrastructure supporting the ePA (electronic health record) across DAK, BKK24 and TK, and explore whether they share a common backend and infrastructure, as well as the associated risks.

2. Why do you expect your engagement to be useful?
Why is that an interesting problem?

We believe that this investigation could uncover potential challenges faced by ePA providers and offer recommendations for addressing them, while also fostering a more human-centered approach to the topic.
The investigation is also useful for the insured. For decades, the main reasons for choosing a health insurance company were the offers for insured persons: particularly favorable prices or reimbursements for certain examinations and medications that are not reimbursed by other health insurance companies. With the increase in cyber-attacks, one now also has to worry about the IT service providers of health insurance companies. Which service providers are frequent victims of attacks? What is the crisis communication of the service provider and the health insurance company? How secure is my data? How long does it take after an attack for everything to get back to normal?

3. Who are your intended stakeholders?
And who might be the indirect stakeholders?
For example, elderlies, parents, people with a certain illness, etc.

Intended stakeholders involved would encompass health insurance providers, medical personnel, patients and people who want to change their health insurance company or need to choose a health insurance company for the first time, such as foreigners who want to work in Germany.
Indirect stakeholders may include the government, developers, hackers, researchers, and more.

4. Where is your user group interacting with your software?
For example, at home, in the hospital, or on the go.

Whether in the hospital, at home, or on the go, the mobility of the app enables it to be used anywhere, making it especially valuable to have readily available in case of an accident.

5. When is the user group interacting with your software?
For example, only when being in the hospital, while biking, or daily in the morning.

Every time information regarding medications or patient data is required. Besides that, users might be interested in their data outside a specific incident. Users will normally not interact with their ePA daily unless they are receiving treatment over a couple of days or weeks and have to add/look up information on a regular basis.

Unsere Reflexion der letzen Woche:
Wer hat welchen Beitrag geleistet?
Lilli hat die Aufgabe mit dem Artikel über Humanity Centered Design gemacht und angefangen, über den Cyberangriff auf Bitmarck zu recherchieren. 
Christopher hat sich mit dem 5W´s beschäftigt, basierend auf dem Feedback aus dem letzten Tutorium.
Jan hat die Ergebnisse Aufgaben ergänzt und aufbereitet sowie den Blog Post veröffentlicht und einen Google Drive Ordner sowie zur Organisation erstellt.

Was habt ihr gelernt?
Der IT-Dienstleister Bitmarck hat gewaltige Macht und Verantwortung in der deutschen Gesundheitsinfrastruktur. Mehr als 80 Prozent der deutschen gesetzlichen Krankenkassen sind Kunden von Bitmarck, was insgesamt 25 Millionen Versicherte betrifft (https://www.bitmarck.de/unternehmen/ueber-uns/was-macht-bitmarck). 
Das wichtigste Prinzip von Humanity Centered Design ist es, zusammen mit der Community – statt für die Community – zu designen

Was lief gut?
Wir konnten uns schnell auf unser Projektthema einigen. Insbesondere durch den kürzlich erfolgten Cyberangriff auf Bitmarck ist das Thema für uns hochaktuell, spannend, wichtig und motivierend.
Außerdem haben wir jetzt einen Google Drive Ordner, in welchem wir alle Ressourcen sammeln können.

Was möchtet ihr verbessern?
Ich (Jan) würde gerne etwas zeitiger die Aufgaben bearbeiten, komme aber persönlich nicht dazu, weil ich noch zwei andere Abgaben am Montag bzw. Dienstag habe. Wenn ich das Wochenende effektiver nutze, sollte das aber möglich sein.