Egy magán egészségügyi intézménynél a műtéti előjegyzések, a páciensadatok és az erőforrás-gazdálkodás szétszórtan élt különböző eszközökben: megosztott táblázat a foglalásokhoz, közös naptár a műtéti időpontokhoz, manuális e-mail-küldés a páciensek felé. Az ügyintézők és az orvosok párhuzamosan dolgoztak, sokszor nem ugyanazon az aktuális adaton. Statisztikát csak manuálisan lehetett összesíteni, erre a legtöbb héten nem volt kapacitás.
Belső fejlesztői kapacitás nem volt, az igény egyedi rendszerre szólt.
A megoldás 2 emberhónap alatt éles üzemben futott. Az alábbiakban bemutatjuk, hogyan és milyen feltételek mellett, és mit jelent ez egy hasonló helyzetben lévő szervezet számára.
A szállított rendszer: mit old meg, és mit nem
A Surgery Reservation egy dedikált belső adminisztrációs alkalmazás, amely egységes platformon kezeli a klinika teljes műtéti előjegyzési folyamatát. Kizárólag belső használatra készült: nincs publikus felület, nincs páciensoldali hozzáférés.
A rendszer három jogosultsági szinten működik (ügyintéző, admin, szuper admin), és az alábbi területeket fedi le: heti előjegyzési naptár műtőterem- és személyzetkezeléssel, pácienstörzs TAJ-alapú kereséssel és dokumentumkezeléssel, automatikus e-mail-kommunikáció a páciensek felé, valamint szűrhető statisztikák időszakra, orvosra és műtéttípusra.
Ez nem egy testreszabott dobozos termék, nem egy meglévő rendszer migrálása volt, és nem tartalmazott külső rendszerintegrációt. Ezek a körülmények közvetlen hatással voltak a szállítási időre is.
A 2 emberhónap: feltételek és korlátok
A 2 emberhónapos szállítási idő valós adat, de érdemes pontosan érteni, mi tette lehetővé, és mi lett volna más körülmények között.
Ami hozzájárult a gyorsasághoz: az ügyfél oldalán egyértelmű döntéshozó volt, a scope az első két héten lezárult, és nem volt migrációs kötelezettség (a korábbi Excel-alapú adatokat nem kellett rendszerbe tölteni). A fejlesztői csapat AI-eszközökkel (Cursor, GitHub Copilot) dolgozott, amelyek a jól definiált, ismétlődő fejlesztési feladatokon mérhetően gyorsítanak.
Ami más projektnél más lehet: ha a scope az együttműködés során jelentősen változik, ha meglévő rendszerekkel kell integrálni, vagy ha a döntéshozatal az ügyfél oldalán lassabb, az idő arányosan nő. Ugyanez a projekt külső rendszerintegrációval vagy adatmigrációval valószínűleg 3-4 emberhónap lett volna AI-eszközökkel is.
Az összehasonlítási alap: hagyományos fejlesztési megközelítéssel, azonos scope mellett, legalább 4 emberhónapot becsültünk volna.
Adatkezelés és GDPR egészségügyi kontextusban
A rendszer TAJ-számokat, születési adatokat, anyja nevét és egyéb különleges kategóriájú személyes adatokat kezel. Egy CIO számára ez nem megúszható kérdés, ezért pontosan leírjuk, hogyan kezeltük.
Az alkalmazás magyarországi bérelt VPS-en fut, az adatok az országon belül maradnak. A rendszer zárt, belső hálózaton üzemel, külső hozzáférési pont nincs. A Nitrowise oldaláról kizárólag a projekt időtartama alatt fértek a rendszerhez az azon dolgozó fejlesztők.
Ha egy hasonló projektnél specifikus compliance kérdések merülnek fel (GDPR, belső IT-biztonsági audit, adatkezelési tájékoztató minták), ezeket az egyeztetési fázisban kezeljük.
AI-asszisztált fejlesztés: mi ez valójában egy C-szintű döntéshozónak
Az AI-eszközök ebben a modellben a szállítási sebesség növekedését eredményezik anélkül, hogy a kockázatprofil romlana.
Ez lényegesen különbözik attól, amit a köznyelv vibe codingnak hív. A Nitrowise AI-Powered Delivery Team modelljében az AI-eszközök fejlesztői ellenőrzés alatt, auditálható folyamatban működnek, magas tesztlefedettséggel, automatizált ellenőrzési folyamatokkal. Az ügyfél kéthetente demón látja az előrehaladást, és bármikor rálátása van arra, mi készült el és mi nem. Ez nem csúszik el úgy, mint sok hagyományos fix áras projekt.
Ami benne volt, és ami nem
Ezt a kérdést procurement-szinten szinte mindig felteszik, ezért explicitté tesszük.
Benne van: igényfelmérés és scope-pontosítás, UX/UI tervezés, backend és frontend fejlesztés, adatbázis-architektúra, automatikus e-mail-integráció, tesztelés, dokumentáció, éles üzembe helyezés, kéthetente demo és napi standup az együttműködés alatt.
Nincs benne: infrastruktúra-üzemeltetés, adatmigráció korábbi rendszerekből, integrációk harmadik fél rendszerekkel, post-launch support (ez külön megállapodás tárgya).
Ami az éles üzem óta változott
Pontos mérési adatok nem állnak rendelkezésre, de az ügyfél visszajelzése alapján két területen érzékelhető a változás.
Az automatikus e-mail-kiküldés előtt érezhető gyakorisággal fordult elő, hogy egy-egy páciensnek nem ment ki a szükséges értesítés vagy az aláírandó nyilatkozat. Ezek a hibák az automatizált folyamattal gyakorlatilag megszűntek.
Az adminisztráció számára a levelek megírása, sablonból való másolása és előkeresése betegenként körülbelül fél órányi munkát jelentett. Ez az idő most felszabadul.
Mikor érdemes erről egyeztetni
Ha a szervezetedben van egy folyamat, amelyet jelenleg táblázatkezelővel, e-maillel vagy több egymástól független eszközzel koordináltok, és ennek digitalizálása vagy kiváltása napirenden van, érdemes megbecsülni, hogy ez mennyi fejlesztési kapacitást igényel valójában.
Vagy ha valamilyen szoftverre van szükségetek, ami eddig csak nagyon komplex dobozos szoftverek testreszabásával lett volna megvalósítható, esetleg ha egy saját szoftver és/vagy saját termék élesbe állásának időpontja kritikus, és ezért gyorsított fejlesztésre van szükség.
Egy 30 perces egyeztetéssel pontosabb képet tudunk adni: nem prezentációval, hanem konkrét kérdésekkel a scope-ról, a határidőről és a várható eredményről.
Írj nekünk: genai@nitrowise.com | nitrowise.com
