Healcloud háziorvosi ügyviteli rendszer
PROBLÉMA
Tervezzünk egy olyan web-alapú orvosi ügyviteli rendszert, amely megfelel az összes szabályozásnak és az orvosok jelentős része hajlandó lenne feladni a mostani szoftverét ezért cserébe.
KONTEXTUS
Ahhoz, hogy egy orvosi szoftver legálisan működjön, meg kell felelnie az OEP, a NAV, a KSH, az ÁNTSZ, az OÉGYI és a többi rövidítésszervezet összes törvényi rendelkezésének. A szoftverek hibái súlyos pénzbüntetéssel járnak.
Egy orvosi rendelőben nincs olyan, hogy ez a funkcionalitás jelenleg nincs kész: több mint 40 modulnak kell az első perctől naprakészen működnie, hisz bármikor beeshet bárki egy ritka betegséggel, heti szinten alakul ki vészhelyzet és az időnyomás hatalmas.
FOLYAMAT
1. KUTATÁS
Több tucat orvost látogattunk meg rendelés után, érdeklődve hogy zajlott a nap, mik voltak a főbb esetek.
Letöltöttünk minden elérhető kézikönyvet és próbaváltozatot a hasonló szoftverekről, átolvastunk minden jogszabályt, jelentési "rekordképet" (API-t) és összegyűjtöttük az összes űrlapot.
Ezekből kiderült, milyen modulokat kell építenünk. Minden modulnál megkérdeztük az orvosokat az elmélet és a gyakorlat közti különbségekről, ha valami nem volt egyértelmű, rákérdeztünk, miért van, mire való, és példákat kértünk konkrét esetekről.
2. TERVEZÉS
A kutatások alapján modulról modulra haladva 2 hetes szakaszokban elkészítettük az összes kulcsképernyőt.
Az, hogy milyen feladatok vannak az orvosok történeteiből raktuk össze. Az információs felépítés alapja a jogszabályok voltak.
Elemeztük a konkurenciát hogy megtudjuk, mit szeretnek az egyes termékekben az orvosok, de ugyanakkor modern, felhasználóbarát felületet szerettünk volna: végül életünk eddigi legkomplexebb UI rendszerét alkottuk meg, amely rengeteg információt ad kattintásra.
3. TESZTELÉS
Ha elkészült egy modul interaktív prototípusa amely képes volt pár feladat ellátására, megkértünk egy orvost, használja, mintha igazi terméket tartana a kezében.
Bármi, ami nem sikerült elsőre az először felkért orvosnak kijavításra került, mielőtt odaadtuk volna egy következőnek, remélve, neki már könnyebb lesz kezelni a rendszert.
Minden modul legalább 3 orvos látott így egymás után, folyamatosan javítva, mielőtt véglegesítettük volna, mit is kell lefejleszteni.
4. SPECIFIKÁLÁS
Miután a modulok átmentek a teszteken, specifikációt írtunk amikből a fejlesztők dolgozhatnak.
A user story-kat az orvosok tényleges gyakorlatára építettük. Forgatókönyveket írtunk, így minden történet lépésről-lépésre lejátszható, így elképzelhető és tesztelhető lett.
Meghatároztunk minden adatmezőt: nevüket, típusokat, miért szmítanak, mi az alapértékük és értékkészletük, és kellenek-e valamilyen törvény, rendelkezés, vagy API betartásához.
A felületet komponensekre bontottuk, egyesével definiálva viselkedésüket és tartalmukat, részletezve a szélsőeseteket.
ELSŐRE HASZNÁLHATÓ ORVOSI SZOFTVER
Az egyik nap egy új munkatárs kezdett a cégnél: megkértük, írjon fel magának egy doboz algopirint a szoftver segítségével. Ez másfél perc alatt mindenféle segítség nélkül sikerült.
EREDMÉNY
35
orvossal beszéltünk
40
modulról
374
oldal specifikációt írtunk
250
képernyőt rajzoltunk meg
Az egyik nap egy új munkatárs kezdett a cégnél: megkértük, írjon fel magának egy doboz algopirint a szoftver segítségével. Ez másfél perc alatt mindenféle segítség nélkül sikerült.
A fejlesztők a projekt fél éves fejlesztése alatt kevesebb, mint 10 kérdést tettek fel nekünk, ami a dokumentumokból nem volt kiolvasható.
Egy olyan rendszert sikerült tervezni, amely 21. századi konkurenciája a piacvezető megoldásoknak.