A variációk azonosítása a kutatásban nem bonyolult feladat. Elég régóta fejlesztenek megoldásokat és javítják a meglévőket. Bár a mutációk detektálási pontossága nem 100%, a mintaszám növelésével meg lehet találni azokat a mutációkat, amelyek egy jó publikációhoz elegendőek.
A klinikai diagnosztika viszont teljesen más tészta. A kutatásban megengedett pontosság itt már nem elég. Arra sincs lehetőség, hogy több mintát szekvenáljanak, elvgére csak egy beteg van, akinek megfelelő kezelés kell.
A pontatlanság egyik forrása, hogy a DNS átírás során a polimeráz hibázhat. Ha ez a hiba a PCR sokszorozás előtt (vagy egy korai ciklusban) történik, akkor a hibát több readben is látjuk. Hibásan leolvasott mutáció más okból is keletkezhet, de azokkal most nem foglalkozunk. Koncentráljunk csak a PCR hibákra.
Erre a problémára fejlesztettéki az UMI-t (unique molecular identifier). A lényege, hogy megjelölnek minden egyes eredeti, az izolálásból származó molekulát egy egyedi szekvenciával, aminek segítségével aztán a read nyomon követhető. Ha a mutáció több, de csak egyféle kóddal jelölt readekben fordul elő, akkor az jó eséllyel egy hiba.
A jelölés random primerekkel történik, de arról nem találtam információt, hogy mennyi az esélye, hogy rosszul azonosítják a szekvenciát. Elméletileg ugyanis ha pont egy UMI-ban van egy hibás leolvasás, akkor másik UMI-ként azonosíthatják azt, holott a két szekvencia ugyan olyan eredetű.
Természetesen, ha az UMI ligálás előtt történik egy hiba, az szintén fals pozitív mutációként jelentkezik.
De lássunk inkább egy példát, mit is jelent mindez a gyakorlatban.
A jelölt szekvenciák mutáció keresésére az smCounter2-t ajánlja a gyártó. A programot megpróbáltam telepíteni, de végül feladtam. Felváltva használja a Python2-t és Python3-t, ugyan azok a csomagok kellenek mindkét rendszerhez, de erre is csak próba-szerencse alapon jöttem rá. Szüksége van még néhány, szinte beszerezhetetlen programra.
Végül Dockerből futtattam, azzal nem volt gond. A futáshoz szükség van a targetált régiókra BED formátumban és egy primer fájlra. Ezt a fájlt a gyártó oldaláról tudjuk leszedni.
Volt egy kisebb kaland, aminek során megpróbáltam magam elkészíteni a primer fájlokat (mert a bioinformatikusok és a laborosok nem tudták érthetően elmondani egymásnak, milyen fájlokra van szükség) a BED és a genom alapján, de a program nem volt hajlandó futni vele. Rendszeresen azt a hibaüzenetet adta, hogy nincs elég szekvencia. Ez egyébként jellemző hibaüzenet, ami a hibás primer fájlra utal (amennyiben tényleg rendben vannak a szekvenciák)
A program futásához a paramétereket egy fájlban kell összegyűjteni. A felépítése a régi INI fájlokra hasonlít. Ha több szekvenálás eredményét is fel akarjuk dolgozni, az összes adat elérési újtját betehetjük egy paraméter fájlba, és a program parancssorában egy cimke megadásával mondhatjuk meg, melyik rész kerüljön feldolgozásra, de erről a dokumentáció részletesen ír.
Rengeteg végeredmény lesz. Kezdve a különböző illesztésektől, a kibontott FASTQ fájlokig. De még egy minden nukleotidot tartalmazó táblázatunk is lesz! Ez utóbbi segítségével vissza lehet nézni, miért nem talált meg egyes variációkat a program. Viszont ezek együttesen rengeteg helyet foglalnak el.
Kapunk viszont annotációt az eredményekhez, ami nagy pluszt jelent. Nem éri el a VEP teljességét, de elég részletes.
Még egy fontos megjegyzésem van. A program csak hg19-re működik, mivel a cég targetáló kitjeit is erre a genomra tervezték.
A pontosságról nem sokat tudok mondani, de álljon itt egy táblázat, ahol a "hagyományos", nem UMI alapú variáció kereső programmal hasonlítottam össze. Minden sor egy minta. Ez csak tájékoztató jellegű adat, nem igazi mérés. Az indeleket nem is vettem bele, mert azok pozícióját az egyes programok máshogy adhatják vissza. A hagyományos keresőt nem is én futtattam, túl sokat nem tudok róla mondani.
| Közös | Hagyományos | smCounter2 |
| 46 | 56 | 58 |
| 43 | 61 | 113 |
| 57 | 58 | 69 |
| 57 | 60 | 59 |
| 41 | 43 | 53 |
| 36 | 39 | 47 |
| 43 | 50 | 131 |
| 61 | 65 | 79 |
| 55 | 57 | 75 |
| 51 | 52 | 64 |
| 44 | 56 | 55 |
| 54 | 55 | 74 |
| 51 | 55 | 126 |
| 47 | 98 | 56 |
| 34 | 37 | 44 |
| 44 | 46 | 53 |
Számomra elég megdöbbentő az eredmény. Azt vártam volna, hogy a "hagyományos" keresés megtalál mindent, amit az smCounter2, de több fals pozitívval. Ennek ellenére hiányoznak variációk. A lefedettség elég jó volt, egyes helyeken 2000 feletti, mert erősen targetált szekvenálás volt (80 körüli génszámmal), ezért azzal nem lehetett probléma. A hibás térképezést is minimálisnak gondolom, az előbbi okból kifolyólag.
Szúrópróba szerűen kiválasztottam pár variációt, amit a hagyományos szekvenálás megtalál, de az smCounter2 nem. Ezek közül némelyik 0 lefedettséggel fordult elő az smCounter2-es analízisben, ami feltehetően visszamaradt adaptor szennyezés lehetett a read végeken (talán épp egy UMI szekvencia?), de ennek jobban utána kellene menni. Másokat pedig csak egy irányból érkező readek tartalmazták, ami miatt az smCounter2 kiszűrte őket.
Úgy látszik, mégsem olyan egyszerű a mutációk detektálása, mint azt korábban gondoltam. Két különböző technológia elég eltérő eredményt ad. Személy szerint sokkal kisebb különbségeket vártam volna. Milyen eltérések lehetnek egy teljes genom szekvenálásnál?
