Tudástár / Technikai leírás

Hogyan működik technikailag?

Ez az oldal a LeletMagyarul.hu felépítését írja le: hol fut a feldolgozás, milyen modellek és szűrők vesznek részt benne, és mikor hagyja el először a maszkolt szöveg a saját üzemeltetésű szervereket. A felhasználói lépéseket a Hogyan működik oldal mutatja be.

Miért így épült a rendszer

A szolgáltatás kiindulópontja egy konkrét félelem: senki ne adja oda a személyes egészségügyi adatait egy mesterséges intelligenciának vagy egy nagyvállalatnak anélkül, hogy a visszakövethető azonosítók előtte ki lennének takarva.

Ezért a feltöltött PDF-ből először szöveget nyerünk, azt Európai Uniós régióban, saját üzemeltetésű előszűrőn maszkoljuk, Ön átnézi az eredményt, és csak ezután kerül a már szűrt szöveg a Google Gemini API-hoz. A szűrés best-effort: nem ígérjük, hogy minden személyes adat eltűnik. Ezért van kézi átnézés, és ezért van egy második, technikai AI-ellenőrzés a magyarázat előtt.

A folyamat egyben

1Feltöltés
A böngésző a PDF bájtjait a backendnek küldi. Nincs fiók, a fájl mérete legfeljebb 8 MB.
2Szövegkinyerés
A pdf-parse memóriában olvassa a beágyazott szöveget. Ha egy oldalnak nincs szövege, a saját, EU-s OCR-szolgáltatás ismeri fel. Az eredeti PDF-et nem mentjük.
3Regex maszkolás
Reguláris kifejezések takarják a nyilvánvaló azonosítókat: TAJ, adószám, esetszám, telefon, dátum.
4NER maszkolás
Egy magyar nyelvű névelemző modell takarja a személy-, hely- és szervezetneveket.
5Kézi átnézés
Ön elolvassa a szűrt szöveget, mielőtt bármilyen nagy nyelvi modell megkapná.
6Elő-ellenőrzés
A Gemini 2.5 Flash-Lite azt nézi: maradt-e olvasható személyes adat, és alkalmas-e a szöveg magyarázatra.
7Fizetés
Stripe Embedded Checkout. A kártyaadat a Stripe-nál marad; a magyarázó modell csak ezután indul.
8Magyarázat
A Gemini 2.5 Flash strukturált, közérthető magyarázatot készít. A PDF 48 óra múlva törlődik.

Szövegkinyerés és saját OCR

Beágyazott szöveg, szükség esetén optikai felismerés

A feltöltés után a backend — egy Convex Node.js action, vagyis szerveroldali, rövid életű futtatás — a pdf-parse könyvtárral kinyeri a PDF-ben már meglévő szöveget, oldalanként. Ez memóriában történik: az eredeti fájlt nem írjuk tárhelyre, és nem készül belőle hosszú távú másolat.

Ha egy oldalnak nincs vagy alig van beágyazott szövege, a rendszer optikai karakterfelismerést (OCR, optical character recognition) futtat: a képből szöveget állít elő. Az OCR a Szolgáltató saját Cloud Run szolgáltatásán fut, europe-west1 régióban (Belgium), ugyanazon az elven, mint a PII-előszűrő: a PDF a kérés idejére memóriában van, nincs mentés, és nincs tartalmi napló. A Tesseract magyar és angol nyelvi adatai a Docker-képbe vannak beégetve, a szolgáltatás induláskor nem tölt le semmit az internetről.

Kézzel írt jegyzeteket és homályos, ferde fényképeket az OCR nem tud megbízhatóan felismerni. A támogatott dokumentumtípusokat a Támogatott leletfajták oldal részletezi.

Kettős PII-szűrés az EU-ban

A kinyert, még maszkolatlan szöveget a rendszer a Szolgáltató saját PII-előszűrőjére küldi. A PII (personally identifiable information) a személyazonosításra alkalmas adat: név, TAJ, telefonszám, esetszám. Az előszűrő Google Cloud Run-on fut, europe-west1 régióban (Belgium): ez egy konténeres, kérés idejére memóriában dolgozó szolgáltatás, nem egy állandó virtuális gép adatbázissal.

1. Reguláris kifejezések

Először statikus minták (regex, regular expression) takarják a nyilvánvaló, előre megadott formátumú adatokat. Csillagokkal helyettesítik a találatot, például TAJ: XXX típusú mezőket.

  • TAJ-szám és adóazonosító
  • esetszám, naplószám, iktatószám
  • dátumok
  • magyar telefonszámok
  • EESZT, NEAK, NNGYK azonosítók
2. Névfelismerés (NER)

Ezután egy névelemző (NER, named entity recognition) modell keresi a szabadszöveges neveket. A modell a SZTAKI / NYTK nyilvános, magyar nyelvre tanított HuBERT-alapú hálózata: NYTK/named-entity-recognition-nerkor-hubert-hungarian.

A modell a Docker-képbe van beégetve, és offline fut: a szolgáltatás nem tölt le semmit a Hugging Face-ről a feldolgozás közben, és a leletszöveget nem küldi oda.

Mit takar, és mit hagy szándékosan

A NER három entitáscsoportot maszkol: PER (személynevek), LOC (helyszínek) és ORG (szervezetek, intézmények). A MISC (egyéb) kategóriát szándékosan kihagytuk, hogy a leletben szereplő gyógyszer-, hormon- és vitaminnevek ne tűnjenek el a magyarázat elől.

A PII-szolgáltatás a kérés idejére memóriában dolgozik: nincs lelettartalom-adatbázis, nincs mentés, és nincs tartalmi vagy audit napló a lelet törzséről. A maszkolt szöveg visszakerül a backendhez. Ön ezután látja a szűrt verziót.

Ön ellenőrzi, mielőtt az adat elhagyná a szűrőt

Emberi lépés a gépi szűrés után

A kettős szűrő után a felhasználó hozzájárulásával hagyja el először a saját üzemeltetésű előszűrőt a már maszkolt adat. Szándékosan maradhat a nem, az életkor, a laborértékek és a diagnózisok: ezek kellenek az értelmezéshez. Ha TAJ, teljes név, pontos lakcím vagy esetszám még olvasható, ne folytassa, és vegye fel velünk a kapcsolatot.

Az AI — nagy nyelvi modell (LLM, large language model) — csak az Ön által jóváhagyott szűrt szöveget kapja. A feltöltés előtt külön jelölőnégyzettel járul hozzá az egészségügyi adat kezeléséhez; a részleteket az adatvédelmi tájékoztató tartalmazza.

Elő-ellenőrzés: Gemini 2.5 Flash-Lite

Technikai szűrő, nem orvosi vélemény

A jóváhagyott maszkolt szöveget először a Google Gemini egy kisebb modellje, a gemini-2.5-flash-lite kapja. Feladata kettős, és szándékosan nem magyaráz orvosi tartalmat:

  • Van-e még olvasható személyes adat? A már csillagokkal takart mező nem számít annak. Csak a konkrét, visszaolvasható azonosító számít.
  • Alkalmas-e a szöveg laikus magyarázatra? Van-e benne vizsgálati eredmény, diagnózis vagy megállapítás, vagy üres, töredezett, értelmezhetetlen.

A modell strukturált választ ad: pii_detected (van-e olvasható azonosító) és medical_usability (jó / részleges / rossz). Ha olvasható személyes adat maradt, vagy a szöveg magyarázatra alkalmatlan, a folyamat leáll, és nem indul a magyarázó modell.

Fizetés, majd magyarázat: Gemini 2.5 Flash

Csak a zöld jelzés után

Az elő-ellenőrzés sikere után a fizetés a Stripe Embedded Checkouton történik. A bankkártyaadat a Stripe-nál marad; a szolgáltatás a tranzakcióazonosítót, az összeget és a számlázáshoz szükséges adatokat látja. A magyarázó modell csak a sikeres fizetés után indul — ez az utolsó előtti lépés már nem a személyes adatok elsődleges szűrése, hanem a magyarázat előtti utolsó kapu.

A magyarázatot a gemini-2.5-flash készíti, a Google Gemini API-n keresztül (nem a fogyasztói Gemini-csevegőfelületen). A bemenet a már jóváhagyott, maszkolt szöveg. A kimenet strukturált JSON: bevezető, összefoglaló, vizsgálati szekciók, következtetés, szójegyzék és az orvosnak szánt kérdések. Ebből készül a letölthető PDF.

A kimenet nem diagnózis, nem kezelési javaslat, és nem helyettesíti az orvosi konzultációt. A Google API-használat során a Szolgáltató nem engedélyezi a bemenet modelltanításra fordítását.

Hol fut mi

A szolgáltatás több adatfeldolgozót használ. A Convex és a Gemini API az Egyesült Államokhoz is kötődik; a továbbítás a GDPR 46. cikke szerinti garanciákkal (jellemzően EU–USA Data Privacy Framework és/vagy általános szerződési feltételek) történik. A jogi részleteket az adatvédelmi tájékoztató tartalmazza.

A leletfeldolgozás rétegei és a kezelt adat
RétegHol futMit kezel
WeboldalNetlify (Next.js)A felület és a statikus oldalak. A lelet tartalma nem itt marad.
BackendConvexSzövegkinyerés memóriában, szükség esetén OCR-hívás; 48 órán át a maszkolt szöveg, a hash, a token és a magyarázat.
OCRGCP Cloud Run, europe-west1 (Belgium)Csak a szöveg nélküli oldalak. PDF a kérés idejére, memóriában. Nincs tartalmi napló.
PII-előszűrésGCP Cloud Run, europe-west1 (Belgium)Kicsomagolt szöveg a kérés idejére, memóriában. Nincs tartalmi napló.
Elő-ellenőrzés és magyarázatGoogle Gemini APICsak a felhasználó által jóváhagyott, maszkolt szöveg.
FizetésStripeKártyaadat a Stripe-nál marad. A lelet szövege nem kerül a Stripe-hoz.

Mit nem tárolunk

  • Eredeti PDF: soha nem kerül adatbázisba vagy fájltárhelyre.
  • SHA-256 hash: csak szerveroldalon készül, hogy ugyanazt a fájlt ne kelljen kétszer kifizetni, és a terheléskorlátozás működjön. A hash nem szerepel a nyilvános URL-ben.
  • Hozzáférési token: kitalálhatatlan, véletlenszerű azonosító a címben; aki a hivatkozást birtokolja, 48 órán át eléri a folyamatot.
  • 48 órás törlés: a maszkolt szöveg, a token és a magyarázat óránként futó ütemezett feladat után lejár.
  • Nincs analitika a leletúton: Google Analytics, Microsoft Clarity és Meta Pixel nem fut a feltöltési és ellenőrzési oldalakon.

Gyakori kérdések

A szkennelt PDF hol készül szöveggé?
Ha egy oldalnak nincs beágyazott szövege, a rendszer a Szolgáltató saját OCR-szolgáltatását hívja (Cloud Run, europe-west1, Belgium). A PDF a kérés idejére memóriában kerül feldolgozásra: az OCR nem írja adatbázisba a lelettartalmat, nem készít róla mentést, és nem naplózza a tartalmat. Kézzel írt jegyzeteket és homályos fényképeket továbbra sem tud megbízhatóan felismerni.
Az uniós PII-szűrés hol fut, és marad-e ott a lelet?
A személyes adatok előszűrése a Szolgáltató saját, Google Cloud Platformon (Cloud Run, europe-west1, Belgium) üzemeltetett szolgáltatásán fut. A kicsomagolt szöveg a kérés idejére memóriában kerül feldolgozásra. A PII-szolgáltatás nem írja adatbázisba a lelettartalmat, nem készít róla mentést, és nem naplózza a tartalmat.
Miért két Google Gemini modell dolgozik egymás után?
Először a kisebb, olcsóbb Gemini 2.5 Flash-Lite csak technikai ellenőrzést végez: van-e még olvasható személyes adat, és alkalmas-e a szöveg laikus magyarázatra. A nagyobb Gemini 2.5 Flash csak akkor kapja meg a már jóváhagyott, maszkolt szöveget, ha ez az előszűrő nem talált olvasható azonosítót, és a dokumentum magyarázatra alkalmas. Így a magyarázó modellhez nem jut maszkolatlan lelet, és a drágább lépés csak indokolt esetben fut.
Mit tárol a rendszer a feltöltött leletből?
Az eredeti PDF-et nem tároljuk. A backend a maszkolt szöveget, egy szerveroldali SHA-256 fájlhash-t, a hozzáférési tokent és az elkészült magyarázatot őrzi 48 órán át, majd automatikusan törli. A leletfeltöltési és -ellenőrzési oldalakon nincs Google Analytics, Microsoft Clarity vagy Meta Pixel.

Lelet feltöltése

1490 Ft egyszeri díj, a feltöltéshez még nem kell fizetni.

Lelet feltöltése

Kapcsolódó oldalak

Ha nem érti, mit jelent valami az orvosi vagy laborleletében, itt megtalálhatja a magyarázatot. Referenciaérték, vérkép, laborértékek közérthetően — nem diagnózis.
Az orvosi lelet fordító itt nem idegen nyelvre fordít, hanem a zsargont közérthető magyarra. Nem diagnózis, nem orvosi tanács.
Az orvosi lelet értelmezése a konzultációra készít fel: szómagyarázat és kérdések, diagnózis és kezelés nélkül.
A lelet elemzés strukturált magyarázat: megállapítások, szótár és orvosi kérdések EESZT PDF-ből, maszkolás után.
Az orvosi AI itt nem ingyenes: maszkolás, kézi átnézés, AI elő-ellenőrzés és magyarázat. Egyszeri díj, nincs előfizetés.
PDF feltöltés, azonosítók maszkolása, egyszeri fizetés és közérthető magyarázat lépésről lépésre.