Genotypowanie probabilistyczne: możliwości i ograniczenia

Streszczenie

Genotypowanie probabilistyczne nie „odczytuje, kto jest w mieszaninie”. Buduje matematyczny model tego, jak założone genotypy, proporcje dawców, ilość DNA, degradacja, stutter, dropout i drop-in mogły wytworzyć obserwowane piki. Następnie sumuje prawdopodobieństwo danych po wielu możliwych konfiguracjach i porównuje dwie propozycje w postaci ilorazu wiarygodności.

Program może używać tylko informacji, które otrzymał i które jego model potrafi reprezentować. Nie wie sam, czy próbkę zamieniono, czy liczba dawców jest poprawna, czy pik jest pull-up, czy alternatywą powinien być brat, ani czy DNA znalazło się na przedmiocie podczas czynu. Te decyzje należą do zwalidowanego workflow i kompetentnego analityka.

Modele półciągłe używają obecności alleli oraz prawdopodobieństw dropout/drop-in. Modele ciągłe wykorzystują wysokości pików i rozkłady stutter, mixture proportions, template i degradation. Więcej danych może poprawić rozróżnienie, ale tylko wtedy, gdy rozkład dobrze opisuje używany assay i typ próbek.

Walidacja obejmuje nie tylko poprawne wyniki dla prawdziwych dawców. Potrzebuje non-contributors, wielu liczb dawców, skrajnych proporcji, pokrewieństwa, stutter overlap, degradacji, inhibicji, różnych ilości, powtórzeń MCMC i przypadków poza zakresem. Ocenia się rozkłady LR, false support, calibration, precision, sensitivity na assumptions oraz failure modes.

PGS jest narzędziem do sub-source evaluation. Nie przenosi automatycznie LR na poziom rodzaju płynu, czynności albo winy. Duża liczba z programu pozostaje opinią warunkową względem propozycji, danych, parametrów i wersji software’u.

Po co powstały modele probabilistyczne

W prostym profilu jednego dawcy allele można porównać bez wielkiej przestrzeni konfiguracji. W mieszaninie pojawiają się:

• wspólne allele;
• wielu dawców;
• nierówne proporcje;
• dropout;
• drop-in;
• stutter;
• degradacja;
• nieznane genotypy;
• pokrewieństwo.

Ręczna dekonwolucja wybiera jedną lub kilka konfiguracji, choć wiele może wyjaśniać dane. Probabilistic genotyping sumuje albo integruje po konfiguracjach i nadaje im wagi według modelu.

NISTIR 8351 uznaje ramę probabilistyczną za najlepsze obecnie dostępne narzędzie dla mieszanin na poziomie sub-source, ale podkreśla konieczność walidacji na znanych próbkach podobnych do casework.¹

Program generatywny

Model generatywny odpowiada:

Gdyby dawcami były określone genotypy i działały określone parametry procesu, jak prawdopodobny byłby taki elektroferogram?

Nie rozpoczyna od pytania „kto pasuje”, lecz od symulowanego mechanizmu:

1. wybierz genotypy dawców;
2. przypisz proporcje;
3. określ ilość i degradation;
4. przewidź produkty alleliczne;
5. dodaj stutter;
6. uwzględnij variability;
7. zastosuj threshold i dropout;
8. ewentualnie drop-in;
9. porównaj przewidywane heights z obserwacją.

Likelihood jest wysoki, jeśli konfiguracja generuje dane podobne do obserwowanych.

Dane wejściowe nie są surowym światem

Typowe wejście:

• allele i peak heights;
• locus/channel;
• analytical threshold;
• profile odniesienia;
• NOC;
• known contributors;
• population database;
• propositions;
• ustawienia stutter;
• software version.

Zanim dane trafią do PGS, pipeline wykona:

• spectral separation;
• sizing;
• allele calling;
• panel/bins;
• pull-up editing;
• artifact review;
• thresholding.

PGS nie widzi piku usuniętego w preprocessing. Dlatego audit musi obejmować kroki przed programem.

Model półciągły

Semi-continuous model używa głównie:

• obecności/braku alleli;
• genotype frequencies;
• Pr(dropout);
• Pr(drop-in);
• NOC;
• conditioning.

Nie wykorzystuje pełnej informacji o wysokościach. Dwa profile z tymi samymi allelami, ale innymi proporcjami mogą dać podobny wynik.

Zalety:

• prostsza struktura;
• łatwiejsza weryfikacja;
• może działać przy danych, gdzie heights są niewiarygodne.

Ograniczenia:

• utrata mixture proportion;
• mniej informacji o stutter;
• Pr(D) może być uproszczone;
• większa wrażliwość na listę alleli.

Model ciągły

Continuous model używa heights albo read counts. Typowa wartość oczekiwana piku allelu zależy od:

scale × Σ(contributor proportion × allele copy number)
× degradation(length)
+ expected stutter contributions

Wokół oczekiwania istnieje rozkład, np. gamma, lognormal lub inny. Parametr variance opisuje amplification stochasticity i pomiar.

Model może jednocześnie estymować:

• mixture proportions;
• total template;
• degradation;
• stutter ratios;
• variability;
• dropout implied by height below threshold.

To bogatszy opis, ale więcej assumptions.

Peak height model

Jeśli dwóch dawców ma wspólny allel, oczekiwana wysokość sumuje copy contributions. Homozygota wnosi zwykle dwie kopie względem heterozygotycznej jednej, po korekcie procesu.

Przykład:

U1 proportion 0,7; genotype 10,12
U2 proportion 0,3; genotype 12,14

Oczekiwane względne wkłady:

10: 0,7
12: 0,7 + 0,3 = 1,0
14: 0,3

Rzeczywiste piki odchylają się i mają stutter. Wysoki 12 jest allele stacking, nie trzecią osobą.

Variance

Amplifikacja z małej liczby cząsteczek ma większą względną zmienność. Model może uzależniać variance od expected height.

Jeśli variance jest zbyt mała, model nadmiernie karze normalne odchylenia i daje overconfident LR. Jeśli za duża, akceptuje prawie każdą konfigurację.

Parametry pochodzą z validation samples, ale software może estymować część per case. Zakres powinien odpowiadać assay.

Stutter model

Continuous PGS przewiduje stutter od parent allele:

• n−1;
• n+1;
• n−2;
• allele/locus-specific ratios.

Pik w stutter position może otrzymać:

expected stutter + expected true allele

To przewaga nad binarnym usuwaniem. Model musi jednak znać typ stutter i zakres walidacji. Nietypowy allele-specific stutter może nie pasować do średniej locus.

Degradation model

Expected height może maleć wykładniczo z długością fragmentu. Parameter degradation estymuje slope.

Ograniczenia:

• mieszanina może mieć dawców o różnej degradacji;
• inhibicja może imitować slope;
• primer bias jest locus-specific;
• short/long relationship nie jest idealna;
• kilka loci daje słabą estymację.

Model jednego wspólnego degradation parameter może źle opisać mieszaninę świeżej i starej tkanki.

Dropout w modelu ciągłym

Allele dropout zachodzi, gdy symulowany peak jest poniżej analytical threshold. Probability wynika z height distribution.

Nie potrzeba osobnego ręcznego Pr(D) w tej samej postaci co semi-continuous. Jednak dropout zależy od:

• threshold;
• scale;
• variance;
• degradation;
• mixture proportion;
• genotype.

Zły threshold lub variance daje zły dropout.

Drop-in

Model może zakładać:

• probability jednego drop-in;
• Poisson count;
• height distribution;
• allele frequency;
• profile-wide process.

Drop-in rate z blanków laboratoryjnych może nie reprezentować background DNA na przedmiocie. Dodatkowy spójny contributor nie powinien być serią niezależnych drop-in.

Analyst musi odróżnić quality incident od modelowanego rzadkiego allelu.

Genotype probabilities

Nieznane genotypy są ważone przez allele frequencies, Hardy-Weinberg, theta i relatedness.

W locus:

P(aa), P(ab), P(ac)...

Program sumuje combinations dla wszystkich unknown contributors. Przy wielu dawcach przestrzeń rośnie kombinatorycznie.

Known contributor ogranicza przestrzeń, ale tylko gdy conditioning jest uzasadnione.

Co właściwie jest sumowane

Warto rozdzielić trzy poziomy niewiadomych. Pierwszym są genotypy osób nieznanych. Drugim są parametry ciągłe, takie jak proporcje mieszaniny, łączna ilość matrycy, stopień degradacji i wariancja wysokości pików. Trzecim są zdarzenia dyskretne: dropout konkretnego allelu, drop-in albo przypisanie piku do określonej klasy stutter.

Dla propozycji oskarżenia zapis schematyczny ma postać:

P(E | Hp) =
Σ_genotypy ∫_parametry
P(E | genotypy, parametry, Hp)
× P(genotypy | Hp)
× P(parametry | Hp)

Analogicznie oblicza się mianownik dla Hd. LR jest ilorazem dwóch ogromnych sum lub całek, a nie ilorazem dopasowania profilu osoby porównywanej do jednej ręcznie wybranej dekonwolucji.

To wyjaśnia, dlaczego program może uwzględnić wiele słabo wspieranych konfiguracji. Każda z osobna ma niewielką wagę, lecz łącznie wpływają na prawdopodobieństwo danych. Wyjaśnia też, dlaczego lista „najbardziej prawdopodobnych genotypów U1” nie zastępuje LR: raportowanie tylko najwyższej konfiguracji odrzuca masę pozostałych możliwości.

Licznik i mianownik mogą opisywać różne przestrzenie

W typowym porównaniu:

Hp: A + U1 + U2
Hd: U1 + U2 + U3

genotyp A jest ustalony wyłącznie w liczniku. W mianowniku program musi zintegrować po genotypie trzeciej osoby nieznanej. Nie pyta więc „czy A pasuje?”, lecz czy dane są bardziej prawdopodobne, gdy jeden z dawców ma genotyp A, niż gdy wszyscy trzej są osobami nieznanymi z określonej populacji.

Jeżeli w Hd wpisano brata A, rozkład genotypu alternatywnego nie pochodzi już ze zwykłych częstości populacyjnych. Jest warunkowany genotypem A i dziedziczeniem. Mianownik może wzrosnąć, a LR spaść. To nie korekta kosmetyczna, tylko zmiana pytania.

Nuisance parameters nie są „ukrytymi dawcami”

Proporcja mieszaniny, wariancja, degradacja czy poziom stutter to parametry pomocnicze. Program może je:

• maksymalizować oddzielnie pod każdą propozycją;
• estymować wspólnie;
• integrować z rozkładem a priori;
• utrzymywać częściowo jako wartości zwalidowane.

Sposób postępowania ma znaczenie. Model o bardzo elastycznych parametrach może lepiej dopasować zarówno licznik, jak i mianownik, a wynik LR nie musi rosnąć. Z kolei niezależna maksymalizacja pod dwiema propozycjami może dać każdej z nich inne „najlepsze” proporcje. Raport techniczny powinien ujawniać tę konstrukcję, szczególnie gdy porównuje się wyniki dwóch programów.

Label switching

Nieznani U1 i U2 są wymienni. Konfiguracja:

U1 = a/b, U2 = c/d

jest biologicznie ta sama co odwrotna, jeśli roles nie są ustalone. MCMC może przełączać labels.

Software rozwiązuje to przez ordering mixture proportions lub symetrię. Użytkownik nie powinien odczytywać „genotypu U1” jako spójnej osoby bez znajomości metody.

Maximum likelihood i integracja bayesowska

Różne programy:

• maksymalizują likelihood po nuisance parameters;
• integrują je z prior distributions;
• używają Bayesian networks;
• używają MCMC;
• enumerują genotype sets;
• łączą metody.

Wynik może formalnie być Bayes factor, nazywany LR w praktyce. Różne modele mogą dać różne wartości bez prostego wskazania jednego „prawdziwego”.

NIST zaznacza, że LR zależy od model choices, preprocessing i expert judgement; nie ma jednej liczby niezależnej od metody.²

MCMC

Markov chain Monte Carlo próbuje z rozkładu genotypów i parametrów, gdy pełna integracja jest zbyt kosztowna.

Terminy:

• chain;
• iteration;
• burn-in;
• proposal;
• acceptance;
• convergence;
• effective sample size;
• seed.

Losowość powoduje simulation variance. Dwa runy nie muszą być identyczne.

Convergence

Brak convergence oznacza, że chain nie zbadał stabilnie przestrzeni. Wskazówki:

• różne runy dają odległe LR;
• trace plot dryfuje;
• niska effective sample size;
• parametry przy granicach;
• genotype sets zmieniają się;
• acceptance nieprawidłowe.

Zwiększenie iteracji może pomóc, ale nie naprawia złego modelu ani NOC.

Laboratorium ustala quantitative criteria.

Precision MCMC

NIST, FBI i ESR przeprowadziły współpracujące badanie precyzji MCMC pokazujące, że powtórne interpretacje z tym samym input, wersją i settings mogą różnić się przez seed i komputer; precyzję trzeba mierzyć.³

Praktyka:

• duplicate runs dla złożonych cases;
• raport log LR precision;
• określony tolerance;
• zachowany seed;
• nie wybieranie większego run.

Jeśli wyniki różnią się o kilka rzędów, nie wystarczy uśrednić.

NOC jest wejściem albo zmienną

Wiele programów wymaga ustalonego NOC. Niektóre porównują modele.

NOC zaniżony:

• wymusza drop-in;
• zwiększa stacking;
• daje złe genotypy.

NOC zawyżony:

• dodaje niewidocznych dawców;
• zwiększa flexibility;
• może dilute LR.

Sensitivity across NOC jest obowiązkowe, gdy uncertainty istotna.

Conditioning

Known contributor jest traktowany jako obecny w obu propozycjach:

Hp: V + A + U
Hd: V + U1 + U2

Conditioning na V redukuje przestrzeń. Nie „odejmuje” heights.

Nie wolno condition on A tylko dlatego, że jest podejrzany. Presence A jest oceniana.

Propozycje

PGS oblicza LR dla dokładnej pary:

• liczba dawców;
• profiles known;
• related/unrelated unknowns;
• population;
• conditioning.

Zmiana Hd z unrelated na brother zmienia genotype probabilities. Program nie wie, która jest prawnie realna.

Propositions są częścią input i raportu.

Analiza wrażliwości nie jest wybieraniem wyniku

Gdy rozsądne są dwa założenia, wykonuje się zaplanowane warianty, na przykład:

• NOC 3 oraz 4;
• populacja referencyjna A oraz B;
• Hd z osobą niespokrewnioną oraz bratem;
• różne dopuszczalne progi analityczne;
• model z forward stutter i bez niego;
• conditioning na bezspornym dawcy oraz brak conditioning, jeśli jego udział jest sporny.

Celem jest sprawdzenie stabilności wniosku. Nie wolno wybrać wariantu dającego największy LR i nazwać go „najlepiej dopasowanym”, jeśli kryterium wyboru powstało po obejrzeniu wyniku.

Dobry raport rozróżnia:

1. model główny — wybrany na podstawie informacji o sprawie i procedury;
2. warianty wrażliwości — realne alternatywy dla niepewnych założeń;
3. testy diagnostyczne — warianty celowo zaburzające model, aby ujawnić słabość;
4. analizy eksploracyjne — nieprzeznaczone jeszcze do raportowania jako dowód.

Jeżeli LR zmienia znak, na przykład z powyżej 1 na poniżej 1, przy dwóch równie uzasadnionych wartościach NOC, niepewność jest częścią wyniku. Nie można jej schować przez podanie tylko jednej liczby.

Hierarchia niepewności

PGS nie usuwa niepewności; porządkuje część z niej. Przydatny podział obejmuje:

• niepewność danych — szum, progi, artefakty, brakujące piki;
• niepewność genotypów — wiele konfiguracji dawców;
• niepewność parametrów — proporcje, degradacja, wariancja;
• niepewność modelu — wybór rozkładów i uproszczeń;
• niepewność scenariusza — NOC, conditioning, pokrewieństwo i propozycje;
• niepewność obliczeniową — MCMC, tolerancje numeryczne, seed;
• niepewność pozamodelową — zamiana próbek, kontaminacja procesowa, transfer i kontekst.

Pierwsze trzy mogą być częściowo zintegrowane w likelihood. Kolejne wymagają walidacji, analiz wrażliwości i jawnego opisu. Ostatniej nie wolno ukrywać w cyfrze z programu, który jej nie modeluje.

PGS nie ustala źródła płynu

Program analizuje STR z ekstraktu. Nie wie, czy allele pochodzą z krwi, śliny, nasienia czy touch DNA.

Jeśli próbka ma kilka materiałów, genotyp nie przypisuje ich do dawców. Potrzebne tissue-specific assays lub separation.

Sub-source LR nie jest source LR.

PGS nie ustala czynności

Transfer, persistence, prevalence i recovery nie są zwykle w standardowym PGS. Program może powiedzieć, jak DNA profile pasuje do dawców, nie jak znalazł się na obiekcie.

Activity-level model wymaga innych danych. Nie wolno użyć sub-source 10^20 jako prior dla activity w sposób liczący ten sam profil dwa razy.

Black box

„Czarna skrzynka” może oznaczać:

• zamknięty kod;
• nieznany model;
• brak validation data;
• niezrozumiałe ustawienia;
• brak logów;
• nieczytelny output.

Source code access pomaga review, ale nie jest wystarczający. Poprawny kod może implementować zły model lub być źle użyty. Zamknięty kod może być intensywnie testowany, ale ogranicza niezależny audit.

Minimum transparentności:

• model documentation;
• version;
• parameters;
• validation;
• inputs;
• output diagnostics;
• known limitations;
• change history.

Developmental validation

Twórca bada:

• mathematical correctness;
• algorithms;
• boundary conditions;
• simulated and empirical samples;
• different kits;
• speed/precision;
• code tests;
• security.

Developmental validation nie zastępuje internal validation laboratorium. Producent nie zna lokalnego instrumentu, threshold, population i casework.

Internal validation

Laboratorium określa fitness for purpose:

• kits;
• instruments;
• thresholds;
• NOC range;
• template range;
• mixtures;
• degradation;
• propositions;
• populations;
• users;
• report policy.

NISTIR 8351 wskazuje, że zakres i publiczna dostępność internal validation różnią się, a podobieństwo próbek casework do walidacji jest kluczowe. Aktualne wytyczne SWGDAM traktują walidację, szkolenie, analizę danych, przegląd i raportowanie jako jeden system użycia PGS, a nie niezależne formalności.⁶

Zakres zastosowania jako mapa, nie hasło

Stwierdzenie „zwalidowano mieszaniny do pięciu dawców” jest zbyt ogólne. Pięciu równych dawców w dobrej jakości profilu może być łatwiejszych niż trzech dawców w proporcji 100:5:1, z degradacją minor i nakładaniem stutter. Zakres powinien być opisany wielowymiarowo:

Wymiar	Przykład granicy
liczba dawców	do 4 dla rutyny, 5 tylko po dodatkowej ocenie
ilość minor	nie mniej niż zwalidowany zakres RFU/template
proporcja	do określonego imbalance
kompletność	minimalna liczba loci z informacją
degradacja	zakres wskaźnika qPCR lub slope
artefakty	typy stutter i obsługa saturation
pokrewieństwo	relacje uwzględnione w testach
assay	konkretny kit, instrument i ustawienia
obliczenia	wersja programu, parametry i długość runu

Przypadek może być wewnątrz zakresu w jednym wymiarze, a poza nim w innym. Laboratorium potrzebuje reguły postępowania dla próbek granicznych: dodatkowe replikaty, case-specific study, ograniczony wniosek albo rezygnacja z interpretacji.

Jak zaprojektować próbki walidacyjne

Walidacja nie jest zbiorem efektownych przykładów. Powinna odzwierciedlać rozkład trudności przyszłej pracy i celowo zagęszczać próby przy granicach. Dobre serie obejmują:

• mieszaniny o znanych składach przygotowane przez inną osobę niż analityk;
• ślepe próbki, w których operator nie zna dawców ani proporcji;
• próbki rozdzielone między operatorów i dni;
• serię rozcieńczeń przekraczającą granicę dropout;
• zmienne udziały minor przy tej samej ilości całkowitej;
• tę samą proporcję przy różnych ilościach całkowitych;
• pary z silnym allele sharing i bez niego;
• krewnych prawdziwego dawcy jako non-contributors;
• mieszaniny z celowo dodanym stutter overlap;
• zdegradowane komponenty o różnej jakości;
• próbki z typowymi zakłóceniami instrumentu.

Rozdzielenie ilości całkowitej od proporcji jest ważne. Mieszanina 1:10 z dużą ilością minor może być łatwa, a 1:2 przy skrajnie małym template — trudna. Sam stosunek nie definiuje złożoności.

Jednostka analizy w walidacji

Wyniki można liczyć per:

• próbka;
• osoba porównywana;
• locus;
• run obliczeniowy;
• rodzina parametrów;
• kategoria trudności.

Jeśli do jednej mieszaniny przetestowano milion losowych non-contributors, powstaje milion LR, ale nie milion niezależnych eksperymentów laboratoryjnych. Współdzielą ten sam elektroferogram, artefakty i model. Liczebności należy raportować tak, aby nie tworzyć pozornej mocy statystycznej.

Podobnie sto powtórzeń MCMC tego samego wejścia mierzy precyzję obliczeniową, a nie biologiczną skuteczność metody. Każdy typ powtórzenia odpowiada na inne pytanie.

Verification i performance check

Po instalacji sprawdza się, czy system działa jak validated build. Po drobnej zmianie, np. formatu raportu, performance check porównuje wyniki z poprzednią wersją; NIST/OSAC definiuje tę kontrolę w kontekście standardu ANSI/ASB 018.⁴

Większa zmiana:

• model;
• software version;
• OS;
• database;
• threshold;
• kit;
• instrument;
• code;

może wymagać partial lub full revalidation.

Macierz walidacyjna

Osie:

• 1–5+ contributors;
• balanced do 1:100+;
• high/low template;
• complete/partial;
• undegraded/degraded;
• unrelated/related;
• no/strong allele sharing;
• stutter overlap;
• drop-in;
• inhibition;
• replicate;
• multiple kits.

Nie trzeba testować każdej kombinacji pełnym factorial, ale design musi pokryć interactions krytyczne.

Ground truth

Walidacja potrzebuje znanych genotypów i proportions. Materiały:

• laboratory mixtures;
• reference materials;
• dilution series;
• mock evidence;
• publicly available datasets.

Artificial mixtures mogą być łatwiejsze niż casework: czyste DNA, dokładne proporcje, brak tła. Mock stains zwiększają realizm.

True contributor tests

Dla prawdziwego dawcy oczekujemy zwykle LR >1. Nie zawsze:

• bardzo niski wkład;
• dropout;
• NOC misspecification;
• related alternative;
• bad model;
• stochastic variation.

Rozkład false negative support jest ważniejszy niż średnia.

Non-contributor tests

Porównuje się wiele osób, które nie wniosły DNA. Nie powinny systematycznie dawać dużych LR, ale allele sharing może sporadycznie wspierać Hp.

Dobór:

• random unrelated;
• close relatives;
• database individuals;
• high allele-sharing;
• same population;
• alternate populations.

Szukamy tail false support.

False positive nie ma jednej definicji

Możliwe kryteria:

• LR >1 dla non-contributor;
• LR > threshold;
• verbal category;
• inclusion decision.

Error rate zależy od progu i case class. Raport powinien definiować zdarzenie.

PGS nie ma uniwersalnego „błędu 1%”.

Calibration

LR system jest dobrze kalibrowany, jeśli strength odpowiada empirycznym outcomes. Model nie powinien być nadmiernie pewny.

Badania calibration porównują distributions dla same-source i different-source. NIST rozwija metody oceny calibration i demonstruje je m.in. na PROVEDIt.⁵

Calibration wymaga wielu samples i właściwego sampling plan.

Discrimination

Discrimination to zdolność oddzielenia true contributors od non-contributors. ROC/AUC może ją opisać.

Model może mieć dobre AUC, ale złe calibration. Ranking osób jest dobry, lecz LR za duże.

Obie własności są potrzebne.

Empirical cross-entropy

Empirical cross-entropy i Cllr oceniają information loss i calibration w systemach LR. Nie zawsze są używane w routine validation, ale pokazują, że liczy się nie tylko znak LR.

Skrajny błędny LR jest bardziej szkodliwy niż neutralny.

Case-specific performance

Ogólna validation matrix może nie zawierać dokładnego case. Case-specific assessment:

• simulations przy podobnym NOC/proportions;
• conditioned genotype structure;
• non-contributor test;
• parametric bootstrap;
• sensitivity;
• neighboring validation samples.

Nie można generować symulacji po to, aby potwierdzić już wybrany wynik bez pre-defined protocol.

Symulacja a profil empiryczny

Symulacje pozwalają szybko utworzyć tysiące znanych konfiguracji i badać rzadkie genotypy. Są użyteczne do testowania:

• poprawności kodu;
• calibration;
• wpływu NOC;
• siły allele sharing;
• parametrów poza łatwym laboratorium.

Ich ograniczeniem jest to, że często powstają z modelu bardzo podobnego do ocenianego programu. Jeżeli generator i analizator zakładają ten sam rozkład height i stutter, wynik może wyglądać idealnie, mimo że oba źle opisują realne elektroferogramy.

Próbki empiryczne zawierają nieprzewidziane zjawiska, ale są kosztowne i dają mniej kombinacji. Dlatego potrzebne są oba rodzaje danych:

symulacja → kontrola algorytmu i szeroki stress test
materiał empiryczny → zgodność z rzeczywistym assay
casework-like mocks → zgodność z pełnym workflow

Próby poza zakresem

Out-of-scope samples nie służą do rozszerzania deklarowanego zakresu tylnymi drzwiami. Mają pokazać, jak system zawodzi i czy operator rozpoznaje ten stan.

Przykłady:

• więcej dawców niż maksymalnie zwalidowano;
• component poniżej najniższego template;
• silniejsza degradacja;
• nowy kit;
• nieobsługiwany stutter;
• relatives in mixture;
• allele poza bins;
• profile z rozległym saturation.

Pożądanym wynikiem testu może być komunikat o błędzie, niestabilna diagnostyka albo neutralny wynik prowadzący do odmowy raportowania. „Program policzył LR” nie jest sukcesem poza zakresem.

Najgorszy przypadek jest bardziej informacyjny niż średnia

Średnia log LR dla prawdziwych dawców może wyglądać znakomicie, gdy większość próbek jest łatwa. Dla praktyki ważne są ogony rozkładu:

• największe fałszywe wsparcie dla non-contributor;
• najsilniejsze wsparcie dla krewnego, który nie jest dawcą;
• najmniejszy LR dla prawdziwego dawcy;
• największa rozbieżność między powtórzeniami;
• przypadek o największym błędzie calibration;
• przypadek, w którym model nie sygnalizował jawnego artefaktu.

Każdy ekstremalny wynik powinien przejść analizę przyczyny. Nie chodzi o usunięcie go jako „odstającego”, lecz o ustalenie, czy pokazuje realną granicę systemu.

Model misspecification

Przykłady:

• NOC 3 zamiast 4;
• jeden degradation dla dwóch jakości;
• brak forward stutter;
• unrelated zamiast brothers;
• wrong threshold;
• saturation;
• inhibition;
• null allele;
• contamination profile jako drop-in.

PGS zawsze zwróci liczbę, jeśli input przejdzie. Number existence nie dowodzi model fit.

Model diagnostics

Możliwe:

• fitted vs observed peaks;
• residuals;
• posterior predictive checks;
• locus likelihoods;
• parameter boundaries;
• genotype posterior;
• convergence;
• replicate consistency.

Analityk nie powinien patrzeć tylko na overall LR.

Dopasowanie nie jest prawdziwością

Model o większej liczbie parametrów zwykle lepiej dopasuje obserwowane piki. Nie znaczy to, że lepiej przewiduje nowe dane ani że wybrana liczba dawców jest prawdziwa. Elastyczny model może:

• przypisać artefakt dodatkowemu dawcy;
• użyć skrajnej wariancji do wyjaśnienia mismatch;
• zwiększyć dropout dla niewygodnych alleli;
• rozłożyć jeden donor między dwie komponenty;
• dopasować inhibicję parametrem degradacji.

Dlatego diagnostyka powinna pytać nie tylko „czy fitted peaks są blisko?”, lecz „jak model osiągnął dopasowanie?”. Parametry na granicach, niezwykłe proporcje i ogromny predicted dropout mogą być ostrzeżeniem nawet przy wysokim likelihood.

Posterior predictive check

W modelu bayesowskim można generować elektroferogramy z rozkładu parametrów dopasowanego do danych i porównać je z obserwacją. Sprawdza się między innymi:

• rozkład wysokości;
• liczbę pików pod progiem i nad nim;
• balans heterozygot;
• stutter ratios;
• slope względem długości;
• liczbę loci z ekstremalnym residual.

Jeżeli dane rzeczywiste systematycznie leżą w ogonach symulowanych rozkładów, model może być źle określony. Taki test nie wybiera automatycznie poprawnej alternatywy, lecz wskazuje, że samego LR nie należy traktować bezkrytycznie.

Konflikt loci

Ogólny LR jest iloczynem wkładów loci tylko przy założonej strukturze zależności. Jeden bardzo rzadki zgodny układ może zdominować wiele słabszych loci. Dlatego przegląd pyta:

• czy ekstremalny wkład pochodzi z prawidłowo wywołanego allelu;
• czy locus ma null allele, saturation albo nietypowy stutter;
• czy baza częstości dobrze reprezentuje allel;
• czy zależność między markerami jest obsłużona;
• czy konflikt jest biologicznym dropout, czy błędem wejścia.

Wyłączenie locus po zobaczeniu niekorzystnego LR jest selekcją wyniku. Kryteria jakości muszą działać symetrycznie wobec obu propozycji.

Locus-to-locus review

Per-locus LR ujawnia:

• locus z ekstremalnym wsparciem;
• allele mismatch;
• rare genotype;
• unmodeled stutter;
• data entry error.

Usunięcie locus musi wynikać z quality criterion, nie z niekorzystnego wkładu.

Saturation

Off-scale peaks mają censored height. Model zakładający dokładny RFU może zaniżyć major i zmienić proportions.

Rozwiązania:

• validated saturation handling;
• reinjection after dilution;
• reamplification;
• exclusion according to policy.

Wyniku nie wprowadza się jak zwykłego piku.

Pull-up i spike

Preprocessing powinien je sklasyfikować. Jeśli pull-up pozostanie, PGS może stworzyć dodatkowy allele i contributor.

Automated artifact filter wymaga walidacji. Manual editing wymaga audit trail i review.

Inhibicja

Inhibicja może zmienić heights w sposób nieujęty prostym degradation model. Jeśli validation nie obejmuje, case może być out-of-scope.

Rozcieńczenie tworzy nowy profile z mniejszym template. PGS runy nie są niezależne.

Related contributors

Rodzeństwo lub parent-child w mieszaninie:

• więcej allele sharing;
• mniejszy apparent NOC;
• different genotype prior;
• possible higher false support for relatives.

Validation musi obejmować relatives, jeśli casework. Hd może specify brother.

Identical twins

Standardowe STR dają ten sam genotype. PGS nie rozdzieli bliźniąt przez peak heights, bo genotypes identyczne.

Mixture proportions nie przypisują tożsamości. Potrzebna inna metoda lub conclusion LR≈1 dla A vs twin.

Population database

Zmiana allele frequencies, theta lub population zmienia LR. PGS może mieć kilka baz.

Użytkownik:

• wybiera przed case;
• dokumentuje version;
• computes required populations;
• nie wybiera largest LR.

Rare allele floor jest parametrem.

Cyberbezpieczeństwo i integralność

PGS przetwarza wrażliwe dane. System wymaga:

• access control;
• audit logs;
• checksum;
• backups;
• validated installation;
• malware protection;
• controlled updates;
• data retention;
• disaster recovery.

Zmiana pliku wejściowego lub report template musi być wykrywalna.

Reproducibility

Reprodukcja wymaga:

• raw data;
• processed input;
• software version;
• exact settings;
• population;
• propositions;
• NOC;
• seeds;
• run length;
• logs.

„Użyto programu X” nie wystarcza.

Technical review

Recenzent sprawdza:

• suitability sample;
• controls;
• preprocessing;
• NOC;
• conditioning;
• propositions;
• population;
• parameters;
• convergence;
• diagnostics;
• sensitivity;
• report wording.

Może rerun independent. Review nie jest rubber stamp.

Kompetencje analityka

Analityk powinien rozumieć:

• STR biology;
• mixtures;
• probability;
• LR;
• population genetics;
• model assumptions;
• software operation;
• diagnostics;
• validation;
• courtroom communication.

Kliknięcie programu nie jest kompetencją. Training obejmuje known/unknown tests i failure cases.

Raport

Minimum:

• sample/profile;
• mixture/NOC;
• propositions;
• conditioning;
• LR;
• population;
• software/version;
• settings relevant;
• sensitivity;
• limitations;
• sub-source scope.

Nie raportuje się tylko liczby.

Liczba cyfr nie jest dokładnością wiedzy

Wynik 3,847291 × 10^12 nie ma siedmiu znaczących cyfr sensu dowodowego. Precyzję ograniczają:

• częstości alleli;
• model populacyjny;
• parametry biologiczne;
• wariancja MCMC;
• wybór NOC;
• propozycje;
• model stutter i dropout;
• zakres walidacji.

Raport może używać zaokrąglenia albo przedziału zgodnie z polityką laboratorium. Najważniejsze, aby nie zwiększać pozornej dokładności i nie zmieniać wyniku na korzystniejszy przez sposób zaokrąglenia.

Słowny odpowiednik LR powinien być pomocniczy. Kategorie typu „umiarkowane” czy „bardzo silne” ułatwiają komunikację, lecz ukrywają różnicę wewnątrz przedziału i mogą brzmieć jak ocena winy. Zawsze trzeba zachować kierunek warunku: dane są LR razy bardziej prawdopodobne przy Hp niż przy Hd.

Co powinien móc odtworzyć niezależny ekspert

Niezależna ocena nie wymaga identycznego komputera, ale potrzebuje kompletnego pakietu:

• surowych plików instrumentu;
• projektu GeneMapper lub równoważnego;
• historii edycji pików;
• progów i panelu;
• wejścia do PGS;
• profili odniesienia;
• obu propozycji;
• NOC i conditioning;
• populacji, θ i zasad rzadkich alleli;
• wersji programu oraz build;
• wszystkich ustawień;
• seedów, liczby iteracji i logów;
• wyników per locus i diagnostyki;
• właściwej walidacji wewnętrznej;
• raportu i technicznego przeglądu.

Brak któregoś elementu nie zawsze unieważnia analizę, ale określa granicę tego, co da się sprawdzić.

Pytania do biegłego

Zamiast pytać wyłącznie „czy program jest akredytowany?”, warto pytać konkretnie:

1. Jak ustalono liczbę dawców i jakie warianty rozważono?
2. Kto był conditioning contributor i dlaczego?
3. Dlaczego dokładnie te propozycje odpowiadają stanowiskom stron?
4. Czy alternatywa obejmuje realne pokrewieństwo?
5. Które elementy elektroferogramu ręcznie zmieniono?
6. Czy próbka mieści się w walidacji pod względem minor, proporcji i degradacji?
7. Jakie były wyniki dla podobnych non-contributors?
8. Czy wykonano powtórzenia obliczeń i test convergence?
9. Czy jakiś locus zdominował LR?
10. Jak zmienia się wynik przy rozsądnych założeniach alternatywnych?
11. Jakie ograniczenie programu jest najbardziej istotne dla tej próbki?
12. Czy wniosek dotyczy sub-source, source czy activity?

Te pytania nie zakładają, że PGS jest niewiarygodny. Ustalają, czy konkretny wynik powstał w granicach sprawdzonego użycia.

Source code review

Code review może wykryć:

• implementation errors;
• numerical issues;
• hidden assumptions;
• reproducibility problems.

Nie zastępuje:

• empirical validation;
• model validation;
• user training;
• workflow review.

Public code ułatwia niezależną replikację. Proprietary system powinien zapewnić dokumentację i test data umożliwiające challenge.

Aktualizacja i change control

Każda zmiana ma:

• risk classification;
• impact assessment;
• test plan;
• acceptance;
• approval;
• rollback;
• release notes;
• user communication.

Historical case remains tied to old version. Reanalysis new version może dać different LR; report explains.

Incident response

Jeśli wykryto bug:

1. suspend affected use;
2. identify versions;
3. reproduce issue;
4. scope affected cases;
5. assess result impact;
6. notify stakeholders;
7. correct and validate;
8. reissue reports if needed;
9. document.

Brak zmiany conclusion nie znaczy brak obowiązku oceny.

Studium 1: dobry LR, zły NOC

Model NOC=2 daje LR 10^8 dla A. Dane mają sześć alleli w jednym locus, więc wymagają co najmniej trzech dawców.

Wynik jest nieważny mimo dużej liczby. Input sprzeczny z obserwacją.

Studium 2: high stutter

Pik minor leży w n−1 silnego allelu. Model bez allele-specific stutter przypisuje go A i daje duży LR. Model z właściwym stutter daje LR bliski 1.

Sensitivity pokazuje model misspecification. Validation musi obejmować allele.

Studium 3: related non-contributor

Brat prawdziwego dawcy, który nie wniósł DNA, daje LR 10^4 przeciw unrelated alternative dzięki allele sharing. Przeciw true brother proposition wynik jest inny.

Non-contributor testy losowe nie ujawnią tail dla krewnych.

Studium 4: MCMC instability

Trzy runy dają log10 LR 2, 7 i 5. Trace plots nie konwergują.

Nie raportuje się mediany. Trzeba poprawić run, model lub uznać case out-of-scope.

Studium 5: saturation

Major peaks są off-scale. Program estymuje proportions 55:45, choć rzeczywista mieszanka była 90:10.

Censored major zaniża. Reanalysis po validated dilution zmienia LR minor. Pierwszy run nie był fit for purpose.

Studium 6: activity claim

PGS daje sub-source LR 10^15 dla A na kierownicy. Raport mówi „A prowadziła samochód”.

To przeskok. PGS nie modelował transferu, habitual user ani czasu. Conclusion musi pozostać na sub-source.

Studium 7: software update

Nowa wersja zmienia stutter model i LR z 10^6 na 10^4. Oba w tym samym verbal category.

Laboratorium nadal bada:

• expected change;
• validation;
• affected cases;
• report precision;
• need for notification.

„Ta sama kategoria” nie kończy change control.

Najczęstsze błędy

Program zna NOC. Często użytkownik go podaje.

PGS identyfikuje dawcę. Porównuje propozycje.

Duży LR potwierdza model. Zły model też daje liczbę.

Continuous znaczy obiektywny. Ma assumptions i preprocessing.

MCMC zawsze się uśredni. Brak convergence nie znika.

Known contributor można odjąć. Conditioning zachowuje wspólne piki.

Drop-in zastępuje kontaminację. Quality incident wymaga dochodzenia.

Internal validation producenta wystarcza. Laboratorium waliduje użycie.

True contributors wystarczą. Potrzebni non-contributors i relatives.

AUC wystarcza. Calibration też.

Kod otwarty gwarantuje poprawność. Potrzebne empirical tests.

Sub-source LR opisuje czynność. Nie modeluje TPPR.

Lista kontrolna PGS

1. Czy sample jest w zakresie?
2. Czy preprocessing jest zatwierdzony?
3. Jaki NOC i dlaczego?
4. Czy conditioning jest uzasadnione?
5. Jakie propozycje?
6. Jaka populacja i relatedness?
7. Jak modeluje stutter, dropout, drop-in, degradation?
8. Czy saturation/inhibition występują?
9. Czy validation obejmuje podobny case?
10. Czy true/non-contributor performance jest znana?
11. Czy calibration oceniono?
12. Czy MCMC converged i jest precise?
13. Czy sensitivity zmienia kierunek?
14. Czy software/version/settings są zachowane?
15. Czy report pozostaje na właściwym poziomie?

Co zapamiętać

1. PGS modeluje prawdopodobieństwo danych przy genotypach i parametrach.
2. Nie „odczytuje nazwiska” z mieszaniny.
3. Model ciągły wykorzystuje heights; półciągły presence i dropout/drop-in.
4. NOC, conditioning i propozycje są kluczowymi decyzjami.
5. MCMC wymaga convergence i precision.
6. Validation musi obejmować true donors, non-contributors, relatives i failure modes.
7. Calibration i discrimination to różne własności.
8. Duży LR nie potwierdza poprawności inputu.
9. Software jest częścią workflow, nie jego zastępstwem.
10. PGS LR jest sub-source, dopóki model nie obejmuje innych poziomów.