A Heidi, ausztrál alapítású AI Care Partner, a Heidi Scribe nevű termékével az orvosok adminisztratív munkájának jelentős részét automatizálja: a cég szerint a szolgáltatás ma több mint 190 országban működik, és nagyjából heti 2,7 millió betegellátási interakciót támogat. A gyors növekedés mögött több évvel korábbi infrastruktúra-döntések állnak, amelyek a szabályozási követelmények és a megbízhatóság biztosítására fókuszáltak.
Miért más az egészségügyi AI üzembe helyezése?
Yu Liu, a Heidi társalapítója és technológiai igazgatója hangsúlyozza, hogy az egészségügyben egy viszonylag alacsony hibaarány is klinikai biztonsági kockázattá válhat. Emiatt a rendszerarchitektúrát úgy tervezték, hogy minden kimenetet ellenőrizhetőnek, auditálhatónak és jogilag bizonyíthatónak tartsanak: mi volt a modell bemenete, mit adott vissza, és a klinikus mit módosított egy adott munkamenet során, akár hónapokkal később is.
Adat-lokalizációs követelmények szintén alapfeltételnek számítanak. Egy szidnei, londoni, tokiói vagy denveri klinikus különböző jogszabályi rendszer alatt dolgozik (például Australian Privacy Principles, GDPR, APPI, HIPAA), így a páciensadatoknak az adott régióban kell maradniuk. Ennek megfelelően a Heidi teljesen logikailag elszigetelt, régiónként külön üzemelő termelési telepítéseket futtat; a lakóhely-szabályok (data residency) így nem csak szerződéses ígéretként, hanem infrastruktúraszinten érvényesülnek.
Liu azt is kiemeli, hogy a változások következményeit minimalizálni kell: a Heidi fejlesztési folyamatai CI-gátakat alkalmaznak kockázatos változtatásoknál, canary kiadásokat használnek és még az adatbázis-séma vagy index változtatásokat is kódként kezelik, átvizsgálási folyamaton átvezetve. Szerinte a cég sebessége a beépített biztonság eredménye, nem pedig annak ellenére valósul meg.
Miért dokumentum-alapú adatbázis?
A Heidi számos forrásból gyűjt és konszolidál orvosi adatokat — űrlapok, beutalók, klinikusok feljegyzései és egyéb források — amelyeket egységes formátumba és helyre kellett hozni az AI-munkafolyamatok számára. Rugalmatlan sor–oszlop szerkezetek nem lettek volna alkalmasak erre a dinamikus, heterogén adattípusokra épülő munkaterhelésre.
A cég ezért dokumentum-orientált adatbázist választott; a Heidi a MongoDB-t és különösen a MongoDB Atlas platformot használja. Ez a megközelítés lehetővé tette, hogy a munkamenetek — amelyek tranzskriptumokból, strukturált jegyzetekből, sablonokból, dokumentumokból, páciens-környezeti adatokból, EHR-integrációs állapotból és további elemekből állnak — együtt éljenek olyan szerkezetben, ami megfelel a klinikusok munkamódjának. A dokumentummodell rugalmassága megkönnyíti az adatstruktúrák fejlődését anélkül, hogy minden termékfrissítésnél migrációs megszakításra lenne szükség.
MongoDB Atlas emellett beépített, AI-hoz kész funkciókat kínál, mint a MongoDB Vector Search, így a Heidi nem volt kénytelen külön „bolt-on” vektoradatbázist bevezetni. A cég LangChain segítségével alakít át nagy mennyiségű orvosi dokumentumot vektorbeágyazásokká Atlas-on belül, ami szemantikus keresést tesz lehetővé és közvetlenül köti a leírt orvosi kifejezéseket a releváns külső tudásforrásokhoz. A migráció Atlasra a Heidi szerint a kulcs API-k késleltetését közel 33%-kal csökkentette.
Megbízható klinikai RAG-hez szükséges elemek
Liu szerint a retrieval (visszakeresés) elsősorban adat-architektúra kérdése, nem csupán AI-probléma. A fogyasztói RAG (retrieval-augmented generation) esetén gyakran a nyílt webről történik a keresés, ami egészségügyben nem elfogadható. A Heidi Evidence modul csak licencelt, jogilag megfelelő klinikai tudásbázisokból ad visszakeresést — partnerek között említik a BMJ Best Practice-et, a NICE CKS-t és a MIMS-et —, továbbá a rendszer tudja, melyik joghatóságra vonatkozó irányelveket kell használni (például a brit vs. az ausztrál előírások eltérései miatt).
A beágyazások és vektorindexek a MongoDB Vector Search-ben tárolódnak, ugyanabban a régióhoz kapcsolt, elszigetelt telepítésekben, mint a többi adat. Ez biztosítja, hogy a visszakeresés fizikailag ne lépje át a lakóhely-határt, és hogy ne legyen külön, saját compliance történettel rendelkező vektoradatbázis.
A hivatkozások (citations) a Heidi rendszerében merev szerződésként működnek: a modell csak olyan előhívott töredékeket lát, amelyek már forrásrekordokhoz kötődnek.
Regionális izoláció: hogyan segíti a megfelelőséget és a skálázást
Minden régió külön, teljesen elszigetelt termelési telepítés: saját MongoDB Atlas klaszterekkel, saját számítási erőforrással és saját titkos kulccsal. Ennek köszönhetően a cég egyértelműen válaszolni tud a lakóhely követelményére, az infrastruktúra érvényesíti a megfelelőséget, nem csak a szerződés.
A több elszigetelt régió hatékony futtatása kis létszámú csapattal akkor működik, ha az adatbázisszint kezelt és konzisztens. A Heidi multi-cloud megközelítést alkalmaz: új régiókat a már kiépített „sínrendszeren” lehet felállítani anélkül, hogy minden alkalommal újra fel kellene építeni a teljes megoldást.
Ez a megközelítés különösen látható az Egyesült Államokban: a Beth Israel Lahey Health, New England egyik legnagyobb egészségügyi rendszere bevezette a Heidi AI scribe-át egy olyan pilot után, amelyben a klinikusok 74%-a csökkentettnek jelezte az otthoni adminisztrációs időt (az úgynevezett „pizsamaidőt”). Emellett a MaineGeneral Health nonprofit rendszer a vidékies egészségügyben stratégiai partnerként választotta a Heedit.
Liu szerint az Egyesült Államok piacára lépés során nem utólag kellett HIPAA-kompatibilitást építeni, hanem egyszerűen egy új régiót állítottak fel a meglévő, megfelelőséget biztosító rendszeren.
Tanulságok és további irányok
A Heidi tapasztalatai szerint a nagy, folyamatosan aktív gyűjtemények újrapartícionálása komoly mérnöki program; ezzel szemben a helyes kezdeti shard-kulcs kiválasztása már a tervezési fázis része. A horizontális skálázás és a lakóhely döntések alapító jellegűek egy adat-intenzív AI-termék esetén.
A cég most bővíti a funkcionalitást a konzultációs jegyzeteken túl, és a teljes klinikai munkafolyamatot kívánja támogatni a pre-visit kontextustól a post-visit dokumentumokig, beutalásokig és munkafolyamat-automatizálásig. Emellett vizsgálják, hogyan használhatók fel a MongoDB, a nagynyelvi modellek és a saját eszközkészletük egy ügynökalapú (agentic) klinikai munkafolyamat-ökoszisztéma kiépítéséhez.
Liu összegzése szerint az egészségügyi AI-ban a megbízhatóságot jelentő megbízhatóságmérnökség valójában a bizalom felépítése: a klinikus bizalma ugyanolyan gyorsan elveszhet egy kiesés, magas késleltetés vagy adatinkonzisztencia miatt, mint egy hibás jegyzet miatt. A vállalatnál sok magas hasznosságú munka láthatatlan — automatikus rollbackkel működő canary kiadások, CI-gátak az adatbázis-változásokra, és régiók közötti következetességellenőrzések —, mert a klinikusok bizalma a termék.
Ez a cikk szponzorált tartalom volt, a MongoDB bemutatásában.
