Parentela

Parentela

Blog: genetica forense y probabilidad

Familias y mucho más
¿No os acordáis? sen^2 x + cos^2 x = 1 :))))))

Milagros y genealogía

CasosPostado por Lourdes Prieto Solla mar, octubre 02, 2018 11:15:21

Hola a Tod@s!!

Para retomar la actividad después de las vacaciones y unos cuantos viajes hoy os propongo echar un vistazo a un par de noticias que para mí han sido impactantes.

La primera de ellas tiene que ver con la localización de un cadáver en Chipre. Como muchos sabéis, a mediados del siglo XX (1963-1964 y 1974) se generó un conflicto allí entre turco-chipriotas y greco-chipriotas. Como resultado el país ha quedado dividido en dos partes y es bastante impactante atravesar el único muro que queda dentro de Europa y que separa la República Turco-chipriota (no reconocida como país, excepto por Turquía) y la greco-chipriota. Pues bien, el Programa de Naciones Unidas para el Desarrollo (UNDP) está colaborando en la identificación de las 2003 víctimas del conflicto (http://www.cmp-cyprus.org/). Y hemos tenido el honor de que la coordinadora forense de tal proyecto de identificación fuera nuestra querida Yarimar Ruiz, una genetista buenísima que se formó en el Laboratorio de Ángel Carracedo (cómo no!!).

Bueno, a lo que iba, que me despisto. Recientemente se ha localizado uno de los cadáveres gracias a que un científico localizó una higuera en una zona donde no era habitual ver este tipo de árbol. Al extrañarse por este hallazgo, el científico se acercó al árbol y empezó a inspeccionar su raíz, encontrando una serie de restos humanos. Los restos han sido identificados como pertenecientes a una de las víctimas del conflicto, y se cree que esta persona se alimentó con un higo antes de morir. La semilla del higo germinó, y creció el árbol!! Os podéis imaginar el significado sentimental que tendrá ese árbol para sus familiares. Alucinante!! Podéis encontrar el recorte de prensa aquí:

https://www.mirror.co.uk/news/world-news/murdered-mans-body-found-after-13278205

La segunda de ellas seguro que muchos de vosotros la conocéis, es el caso del asesino del Golden State (https://www.univision.com/los-angeles/kmex/noticias/asesinatos/un-sitio-web-genealogico-llevo-a-los-investigadores-hasta-el-asesino-del-golden-state). Se trata de la detención de Joseph James DeAngelo Jr., de 72 años, sospechoso de haber cometido varios homicidios y numerosas agresiones sexuales en varias ciudades de California durante los años 70 y 80. La policía utilizó los servicios de una compañía on-line que ofrece servicios de genealogía. Se analizó una de las muestras recolectadas en una de las escenas del delito (700.000 SNPs). Las propias compañías ofrecen candidatos de quienes pueden ser tus posibles familiares, de entre los clientes que tienen. Y tras varios candidatos, eureka! uno de Sacramento, una de las ciudades donde se cometieron algunos crímenes. Lo demás ya es fácil, una vez tienes a un candidato, sólo tienes que tomar muestras abandonadas por los familiares de ese candidato y ver cuál de ellas coincide con el perfil genético anónimo tradicional (nuestros adorados STRs) detectado en varias escenas. Pero lo más sorprendente de este caso es que el candidato era un primo tercero de Joseph James DeAngelo Jr., según me comentó Thore, quien hizo una búsqueda intensa para obtener información fiable sobre el caso (Ehrlich et al 2018:
https://www.biorxiv.org/content/early/2018/06/19/350231).

La última semana de agosto tuve la oportunidad de asistir a un fantástico meeting de matemáticos en Colonia (Alemania) y Thore presentó el caso allí. Thore coméntanos, ¿tú crees que la policía tuvo mucha suerte en este caso?

Y seguro que en la mente de muchos queda esta pregunta: ¿es ético utilizar la información de familiares generada con fines distintos a los de una investigación criminal? ¿Podemos evitar que se utilice esta nueva herramienta? Pues me temo que el caso de DeAngelo no es el único… el asesinato de KRISTY MIRACK también tiene un sospechoso encontrado a través de un familiar que se realizó una prueba de ADN en una de estas compañías (https://www.debate.com.mx/mundo/crimen-asesinato-maestra-christy-mirack-dj-freez-sospechoso-muerte-20180626-0088.html).

Alucinante!!



workshops GHEP 2018 Inscripción abierta

CursosPostado por Lourdes Prieto Solla sáb, julio 07, 2018 11:10:02
Hola Chic@s!!

Ya está abierta la inscripción para los workshops que organiza el GHEP en colaboración con la Universidad de Porto!
Estos son los links en español, portugués e inglés:

https://ghep-isfg.org/inscripcion-workshops-oporto-octubre-2018/
https://ghep-isfg.org/pt-pt/inscricao-workshops-porto-outubro-2018/
https://ghep-isfg.org/en/cycle-workshops-porto-october-2018-registration/

Yo ya me he inscrito! Espero que todos vengáis a Porto y nos podamos tomar unos vinitos juntos!

Muchos abrazos en doble hélice para todos!!

workshops GHEP 2018

CursosPostado por Lourdes Prieto Solla jue, junio 28, 2018 15:59:04

Mis queridos,

Seguro que muchos ya lo sabéis, pero para los que aún no os hayáis enterado, el próximo octubre vamos a tener la oportunidad de disfrutar muchísimo!

António Amorim, Nádia Pinto, Iva Gomes, Cíntia Alves y Maria João Prata han tenido la generosidad de ocuparse de organizar varios workshops para el GHEP, con la colaboración de la Universidad de Porto.

Las fechas son 25 y 26 de octubre de 2018 y podéis encontrar más información aquí:

https://ghep-isfg.org/ciclo-workshops-porto-octubre-2018/

Pero ya os adelanto que los workshops son de auténtico lujo!!:

1 Day Workshop: “Disaster Victim Identification – applications and statistics”, con Thomas Parsons, Zlatan Bajunovic, Thore Egeland y Nádia Pinto.

1/2 Day Workshop: “Non-human forensic genetics”, con Fernando González-Candelas, Miguel Arenas y Filipe Pereira.

1/2 Day Workshop: “RNA Profiling in case-work”, con Titia Sijen y Iva Gomes.

La inscripción aún no está abierta, pero pronto lo estará en la página del GHEP. Os avisaré, por supuesto!

El evento será en Porto, y para los que no lo conozcáis, os diré que es una ciudad que enamora! Tiene rincones que son únicos, una gastronomía de lujo y los vinos son increíbles. No hay país en el mundo que haga un café tan espectacular como lo hacen en Portugal, así que los somos muy cafeteros pensamos a veces en cometer la locura de ir a Porto una tarde sólo para tomar un café, aunque tengamos que recorrer unos cuantos cientos de kilómetros.

Pero sin duda, lo mejor de todo esto, es el grupo que nos va a acoger (mil gracias António et al.!!!), la calidad científica y humana de los ponentes (algunos no-Latinos son ya parte del GHEP como sabéis:)))) y que nos da la oportunidad para vernos una vez más!!

Ya estoy deseando que llegue octubre!! Ya sabéis que vosotros sois un motor, una inyección de positividad y una auténtica droga para mi (y ahora tengo una dosis más!!).





relMix-pedigries 2

SoftwarePostado por Lourdes Prieto Solla mié, junio 06, 2018 17:40:26

Bueno, pues quedamos el otro día en ver cómo se hacen los pedigríes del caso de la mujer mantiene relaciones sexuales con dos hermanos, queda embarazada y quiere saber cuál de los dos es el padre del bebé antes de su nacimiento.

Como ya sabéis, lo primero que tenemos que hacer es listar los individuos necesarios para definir el pedigrí. En este caso necesitaremos al hijo, los dos presuntos padres, la madre y claro, también necesitaremos a los padres de los presuntos padres para poder definir que son hermanos entre sí. Vamos a darles los siguientes nombres: Child (hijo), Thore (PP1), Daniel (PP2), Mother (la madre, he tenido grandes tentaciones de darle un nombre de chica GHEP o llamarla Guro, pero no liemos las cosas…J)), A (padre de Thore y Daniel) y B (madre de Thore y Daniel).

Por tanto, el vector id sería:
c ("Child", "Thore", "Daniel", "Mother", "A", "B")

Las hipótesis de nuestro caso son: Thore es el padre vs. Daniel es el padre, así que los vectores dadid y momid serían, para cada caso:

Ped1: Thore es el padre:
c("Thore","A","A",NA,NA,NA)
c("Mother","B","B", NA, NA, NA)

Si leéis en vertical los tres vectores definidos hasta ahora, estamos diciendo que Thore y Mother son los padres de Child, y que A y B son los padres de Thore y de Daniel.

Ped2: Daniel es el padre:
c("Daniel","A","A",NA,NA,NA)
c("Mother","B","B", NA, NA, NA)

que significa que Daniel y Mother son los padres de Child, y que A y B son los padres de Thore y de Daniel.

Y finalmente, el vector sex, que es igual en ambos pedigríes, claro está:
c("male", "male", "male","female","male","female")

Vale, ya lo tenemos, ahora sólo tenemos que poner todo en orden y llamar a la función FamiliasPedigree. Quedaría así:

ped1 <- FamiliasPedigree(c("Child","Thore","Daniel","Mother","A","B"),
c("Thore","A","A",NA,NA,NA),
c("Mother","B","B", NA, NA, NA),
c("male", "male", "male","female","male","female"))

ped2 <- FamiliasPedigree(c("Child","Thore","Daniel","Mother","A","B"),
c("Daniel","A","A",NA,NA,NA),
c("Mother","B","B", NA, NA, NA),
c("male", "male", "male","female","male","female"))

¿Comprobamos si lo hemos hecho bien? Es muy fácil! Sólo tenéis que hacer lo siguiente:
- Abrir R
- Cargar la librería Familias escribiendo: library(Familias)
- Copiar el ped1 tal y como lo hemos escrito
- Ver la representación gráfica del pedigrí simplemente escribiendo: plot(ped1)

Y lo mismo para el ped2. Qué bonito! ¿verdad?

También podéis poner nombre a los pedigríes en la representación gráfica. Sólo tenéis que escribir en R:

par(mfcol = c(1,2))
plot(ped1); title("Thore")
plot(ped2); title("Daniel")
par(mfcol = c(1,1))

Como vimos en la presentación en pdf del post anterior, también se pueden escribir los pedigríes especificando los nombres de los vectores. Podéis verlo si descargáis los archivos ped1-Thore y ped2-Daniel.

Todo esto que os he contado, también sirve para Familias, claro está. Por ejemplo, si habéis definido los pedigríes en Windows Familias como en este archivo llamado trio, podéis ir a la ventana de Pedigrees, seleccionar un pedigrí y “Plot in R”. Os aparecerá una ventana con el código:

#Define the persons involved in the case
persons <- c("AF", "mother", "child")
sex <- c("male", "female", "female")

#Define the pedigree
ped1 <- FamiliasPedigree(id=persons, dadid=c(NA,NA,"AF"), momid=c(NA,NA,"mother"), sex=c("male", "female", "female"))

Ahora ya sabéis lo que significa todo eso!

Por cierto, Thore y Daniel, qué habéis estado haciendo para estar involucrados en este caso???
Thore dice que hay una palabra en noruego para definir la relación entre dos hombres que tienen relaciones sexuales con la misma mujer ('Buksvogere'), y que curiosamente, la versión en femenino de esta palabra ('Buksvigerinner') no existe virtualmente. También dice, sonriendo, que no hay traducción al español de estas palabras, quizás porque no sean necesarias en nuestro mundo latino... Está claro que está siendo muy sarcástico... no tenemos la palabra, pero desde luego la practicamos, tanto en femenino como en masculino smileysmiley!!! Yo creo que incluso habría que inventarse algunas palabras más, sólo hay que ver los casos de paternidad que tenemos en nuestros labs!!!!



relMix-pedigries 1

SoftwarePostado por Lourdes Prieto Solla vie, mayo 25, 2018 19:44:25

Definiendo pedigríes sencillos

Hola queridos!
Hoy os voy a mostrar una de las cosas más entretenidas de relMix, la definición de los pedigríes. Es como hacer sudokus! Incluso podríamos hacer una competición para ver quién hace el pedigrí más complejo.

Como sabéis, por defecto, relMix ya viene con los típicos pedigríes de un caso estándar de paternidad: el que define el trío padre-madre-hijo (llamado "Paternity") y el que define que el presunto padre no está realmente relacionado con el hijo (llamado "Unrelated", definiendo sólo la relación madre-hijo). Seguro que os habéis preguntado cómo relMix establece las relaciones de parentesco. Bueno, pues lo hace con una de las funciones de Familias en R, llamada FamiliasPedigree, creada por Peter Mostad y que se basa en una función anterior llamada kinship2. Me parece bastante difícil que yo pueda entender con claridad cómo funciona FamiliasPedigree, pero es bastante fácil darle órdenes.

Esto os va a ser muy útil para usar relMix con otros pedigríes que no sean el típico trío, ya vemos un ejemplo después. Pero es mejor empezar por lo más sencillo, el trío. El pedigrí se define mediante 4 vectores. Ya empezamos ... vectores, estudié esto en el Jurásico!! Pero no nos compliquemos, un vector no es más que una lista de valores, y para que R lo entienda hay que escribirlo con una "c" y unos paréntesis que contienen los valores. Ejemplo para tres valores: c("valor1", "valor2", "valor3").

Bueno, pues ya casi sabemos todo lo que necesitamos saber en cuanto a programación, lo demás es lógica pura. Vamos a ver entonces los cuatro vectores necesarios:

a) En el primer vector (llamado id), definimos los individuos necesarios para el pedigrí, por ejemplo: c("mother", " child", "AF") para el típico trío

b) En el segundo vector (llamado dadid) definimos los padres de cada uno de los individuos del primer vector. En el caso del trío, no nos interesa para nada quién es el padre de "mother", ni quién es el padre del presunto padre "AF", así que sólo tenemos que decir que "Not Available" (NA). El orden de los valores es el que define a quién nos estamos refiriendo, me explico, en el vector id, el valor "mother" está en la primera posición, así que en este vector "dadid", tenemos poner quién es el padre de "mother" también en la primera posición. Y lo mismo para las siguientes posiciones. Así, con el vector

c(NA, "AF", NA)

estamos diciendo que no nos importa quién es el padre de "mother" (primera posición), que el padre de "child" es "AF" (segunda posición), y que no nos no nos importa quién es el padre de "AF" (tercera posición). ¿Se entiende?

c) En el tercer vector (llamado momid) definimos las madres de cada uno de los individuos del primer vector. En el caso del trío, también teniendo en cuenta sus posiciones:

c(NA, "mother", NA)

Traducido a frase: no nos importa quién es la madre de "mother", la madre de "child" es "mother", y no nos no nos importa quién es la madre de "AF".

d) Y el cuarto vector (llamado sex) nos sirve para establecer el género de cada individuo. En el caso de que "child" fuera una niña, el vector se definiría:

c("female", "female", "male")

Es decir, "mother" es "female", "child" es también "female" y "AF" es "male". El hecho de que los varones no puedan quedarse embarazados facilita mucho este vector ;)))))

Bueno, pues ya casi lo tenemos! Ahora sólo tenemos que llamar a FamiliasPedigree y mandarle que cree el pedigrí teniendo en cuenta la información que le damos en los 4 vectores. Hay varias formas de escribir el código para esto, pero la más sencilla tiene la estructura:

ped1 <- FamiliasPedigree(vector1, vector2, vector3, vector4)

Es decir, en el ejemplo que hemos visto, sería:

ped1 <- FamiliasPedigree(c("mother", "child", "AF"), c(NA, "AF", NA), c(NA, "mother", NA), c("female", "female", "male"))

Qué contenta estoy!! Me siento menos analfabeta al saber interpretar unas líneas de código!! Los jóvenes no pensaréis lo mismo, pero para los que somos del siglo pasado esto es todo un hito!


Una vez que ya sabemos todo esto, es más fácil definir el pedigrí para hipótesis alternativa (AF no está relacionado con child):

ped2 <- FamiliasPedigree(c("mother", "child", "AF"), c(NA, NA, NA), c(NA, "mother", NA), c("female", "female", "male"))

La única diferencia con ped1 está en el segundo vector (dadid), que define quién es el padre de "child".

Bueno, algo muy importante, los vectores dadid, momdid y sex deben tener la misma longitud que el vector id siempre, es decir, si id tiene tres valores, los demás deben tener también 3 valores. Como os he dicho, lógica pura.

Podéis descargaros aquí un resumen de todo lo que hemos visto.

En el siguiente post veremos cómo definir los pedigríes para resolver este caso:

Una mujer mantiene relaciones sexuales con dos hermanos y queda embarazada. Con el fin de saber cuál de los dos es el padre del bebé antes de su nacimiento, se somete a una prueba no invasiva de paternidad a partir de plasma.

Y nada más por hoy, que me he enrollado mucho! Dejarme sólo que le de las gracias a Thore por revisarme esto. Y esta vez se merece mucho el agradecimiento, pues están teniendo temperaturas de 20 grados por las noches en Oslo y él ha tenido la paciencia de sentarse a leer esto, perdiéndose un rato del Caribe Noruego!!



relMix 2

SoftwarePostado por Lourdes Prieto Solla jue, mayo 17, 2018 20:18:17

Frecuencias mínimas en relMix

Como mucho de vosotros sabéis, en relMix y en Familias se requiere que la suma de las frecuencias alélicas de cada marcador sume 1, como en la vida real. Esto también tiene que ver con los modelos mutacionales que el software puede utilizar (ver por ejemplo, pág. 171 del libro de Thore: http://www.familias.name/book.html). Pero ¿qué pasa si queremos utilizar una frecuencia mínima en algún caso que estemos evaluando? Bueno, pues aquí va la explicación de cómo funciona esto en relMix (aplicable también a Familias), con un ejemplo que me envió Thore.

En realidad existen dos versiones de relMix:
i) la llamada "function version" más orientada a investigadores y
ii) la "GUI version" más orientada a usuarios.
Pero ambas versiones usan el mismo código, la misma función de verosimilitud y necesitan que las frecuencias de cada marcador sumen 1. En la versión GUI, las frecuencias alélicas se "pre-procesan" de forma que si no suman 1, el usuario tiene que tomar una decisión (como en Familias).

Por ejemplo, imaginemos que disponemos de las siguientes frecuencias (no muy realistas, sólo es un ejemplo) para el siguiente marcador M1:

Marker-1

Alelo 8 = 0.0008

Alelo 9 = 0.3992

Alelo 10 = 0.4000

Suman 0.8, en lugar de 1. El software entonces te ofrece dos opciones:

a) Añadir un "rest allele", es decir añadir un alelo extra con la frecuencia necesaria para que la suma sea 1

b) Escalar, es decir, redondear las frecuencias de los alelos 8, 9 y 10 para que sumen 1

En el ejemplo anterior, si el usuario decide añadir un alelo extra llamado "rest allele", obtendrá:

Marker-1

Alelo 8 = 0.0008

Alelo 9 = 0.3992

Alelo 10 = 0.4000

Rest allele = 0.2

Y si por el contrario, el usuario decide escalar, cada frecuencia alélica se dividirá por la suma de todas las frecuencias (en este caso, por 0.8), y así obtendrá:

Marker-1

Alelo 8 = 0.0010

Alelo 9 = 0.4990

Alelo 10 = 0.5000

Pero no nos perdamos, estábamos interesados en usar frecuencias mínimas, así que imaginemos que la frecuencia del alelo 8 (0.0008) nos parece demasiado pequeña e imprecisa y pensamos que esto podría sesgar el resultado. Queremos entonces usar la frecuencia mínima en lugar de la estimada, por ejemplo queremos usar una frecuencia mínima de 0.01. En relMixGUI esto se define cuando cargamos la base de datos (Database -> Options) y así, nuestro archivo original (con alelo 8 = 0.0008) se convierte en:

Marker-1

Alelo 8 = 0.01

Alelo 9 = 0.3992

Alelo 10 = 0.4000

En este caso, como las frecuencias no suman 1 (suman 0.8092), el usuario tiene que decidir si escalar o añadir un alelo extra. Pero en otros casos, si al añadir la frecuencia mínima, la suma supera el valor 1, la única opción es escalar (no se pueden añadir alelos extra, pues la suma aún daría un valor más grande que 1).

En el ejemplo, lo más razonable es añadir un alelo extra, pues si escalamos la frecuencia mínima que hemos introducido en el alelo 8 se modificaría también (0.01/(0.01+0.3992+0.4000) = 0.0125), y no queremos que eso pase.

Veamos cómo funciona entonces con un ejemplo de Thore:

Ejemplo (sin drop-out, sin alelo silente, sin theta)

Madre = 9/9

Padre = 8/10

Mezcla = 8/9

p = frec. alelo 8 = 0.0008

H1 : "Padre" es el padre

H2 : un hombre al azar es el padre

LR = 0.5/p = 625

(En detalle: LR =0.5/(p^2+2*p(1-p)*0.5)=1/p)

El resultado LR = 625 es exactamente el que saldría con relMixGUI si la frecuencia mínima la definimos = 0 y no escalamos.

Si decidimos escalar, pero seguimos sin usar la frecuencia mínima, entonces la frecuencia del alelo 8 pasa de ser 0.0008 a ser 0.001 como hemos visto anteriormente (p = 0.0008 / 0.8) y el LR sería entonces:

LR = 0.5/p = 500

Finalmente, si decidimos usar una frecuencia mínima de 0.01 y no escalamos (p = 0.01), el LR tomaría un valor de:

LR = 0.5/p =50

Para que lo podáis comprobar Thore nos manda archivos con este ejemplo. Podéis descargarlos aquí: mezcla, referencias, database (ya sabéis, una vez estéis en la dirección, control + s para guardarlos en vuestro ordenador)

Espero que os sea útil este comentario! Lo importante es que sigamos aprendiendo!



relMix 1

SoftwarePostado por Lourdes Prieto Solla mar, mayo 15, 2018 10:59:28

Menudo grupo de matemáticos forenses hay en Noruega!! Además de ser buenísimos, son de lo más generoso. Hoy os voy a hablar de una herramienta que ha creado Guro Dørum, una genial matemática que además es la mejor bailarina de salsa de Europa, os lo aseguro!

Guro ha puesto a nuestra disposición de forma gratuita, una aplicación para evaluar mezclas en las que los contribuyentes están emparentados. ¿Habéis tenido alguna vez un caso de agresión sexual con resultado de embarazo en el que hayáis necesitado comparar una muestra de suero de la víctima (mezcla) con un sospechoso? Demostrar la paternidad en este caso es muy importante, pues puede implicar al sospechoso como agresor. Y sin ir a un caso tan extremo... ¿habéis necesitado investigar la paternidad de un niño aún no nacido?

El principal problema de estos casos de mezclas es que no conocemos el perfil genético del bebé, lo tenemos formando parte de una mezcla con su madre. Claramente, en las hipótesis tendremos que tener en cuenta que la mezcla está formada por individuos emparentados.

El software se llama relMix y está hecho en R. Una vez que os descarguéis e instaléis el paquete "relMix" en R, podéis acceder a él con los siguientes comandos:

> library(relMix)

> relMixGUI()

Es bastante frecuente que en las muestras de plasma materno detectemos la mezcla muy desequilibrada, con un perfil muy mayoritario procedente de la madre y un perfil muy minoritario correspondiente al niño. No pasa nada! Con relMix podéis evaluar este tipo de mezclas sin problemas, pues se puede tener en cuenta que puede haber drop-out y drop-in en la mezcla (y también podéis evaluar varios replicados de la mezcla a la vez). El software también es capaz de evaluar la mezcla considerando mutación (con diferentes modelos). Es decir, que el caso puede ser complicado, pues relMix está preparado para evaluar casos complejos.

Más aún, las relaciones de parentesco no tienen por qué ser el típico trío padre-madre-hijo, relMix evalúa también otros parentescos. Por ejemplo, una mujer que ha mantenido relaciones con 2 hermanos y queda embarazada puede querer saber cuál de los dos es el padre, antes de que nazca el bebé. Pues simplemente hay que definir bien las hipótesis y ya está. Alucinante!!

Podéis encontrar toda la información sobre relMix en la publicación de Guro:

Dørum, G., Kaur, N. & Gysi, M. Pedigree-based relationship inference from complex DNA mixtures. Int J Legal Med (2017) 131: 629. https://doi.org/10.1007/s00414-016-1526-x

Y además podéis descargaros una presentación .pdf y un vídeo explicativo de nuestro queridísimo Thore en estos links:

http://www.few.vu.nl/~ksn560/Block-III-Part2-Mixtures-TE-ISFG2017.pdf

http://familias.name/VideosBook.pdf (es el primer vídeo de la lista)

Bueno, pues además tenemos que dar la enhorabuena a Guro doblemente, por el software y porque ha sido mamá hace poco. Esperamos que hayas pasado un feliz día de la madre querida Guro!!



El peligro de las exclusiones en los casos de parentesco

HipótesisPostado por Lourdes Prieto Solla vie, marzo 23, 2018 18:26:55

El establecimiento de hipótesis en los casos de parentesco también tiene sus matices. Ya vimos en los comentarios sobre el significado del LR (http://parentela.familias.name/#category8) que es posible que no conozcamos todos los escenarios posibles de nuestros casos. Como ya vimos, el LR no nos dice si una hipótesis es cierta o no, más bien, si los resultados apoyan más una hipótesis que otra. Pero resulta que ambas hipótesis podrían no ser ciertas!!

Imaginaros que una mujer que viaja con tres menores (niña1, niña2 y niño3) declara en la frontera que son sus hijos. La policía detecta que el pasaporte de la mujer es falso. Esto podría ser un caso de inmigración ilegal, pero también pude ser algo más grave como tráfico de menores. Para aclarar la situación os piden que hagáis estudios de ADN con el fin de determinar si los tres menores son hijos de esta mujer... y tras analizar aSTRs veis que la niña1 presenta incompatibilidades con esta mujer en 12 de los 21 marcadores analizados y los otros dos menores son compatibles con la mujer.

Bueno, pues parece un caso fácil. Y si calculamos LRs suponiendo "maternidad" vs. "no relacionado" para cada uno de los tres menores obtendríamos un LR muy cercano a 0 en el caso de la niña1 (demasiadas mutaciones para que la hipótesis de maternidad sea cierta!) y LRs muy elevados en el caso de los otros dos menores.

Hasta aquí todo perfecto, pero en los casos en los que se vean involucrados varios individuos y tengamos exclusión en uno de ellos, os recomiendo ir un poco más allá y pensar en la posibilidad de otras hipótesis. Tenemos claro que la niña1 no es hija de esta mujer, pero quizás esté emparentada por vía paterna con los otros dos menores o al menos con uno de ellos. También tendremos que ver entonces si la niña2 y el niño3 pueden tener o no tener el mismo padre, con las siguientes hipótesis:

H1 = la niña2 y el niño3 son hermanos completos, la mujer es su madre

H2 = la niña2 y el niño3 son medio-hermanos, la mujer es su madre

Imaginaros que obtenemos esto cuando hacemos este cálculo con Familias:

Claramente, H1 se ve favorecida por los resultados (LRH1vsH2 = 42e+06). Así que ahora podemos plantear las siguientes hipótesis, pero sin perder de vista que lo que estamos intentando aclarar es si la niña1 puede pertenecer a este grupo familiar de alguna forma o se trata de una persona no emparentada con ninguno de ellos. Planteemos entonces las hipótesis:

H3 = la niña2 y el niño3 son hermanos completos (la mujer es su madre), y la niña 1 es medio hermana paterna de 2 y 3.

H4 = la niña2 y el niño3 son hermanos completos (la mujer es su madre), y la niña 1 no está relacionada con este pedigrí.

Quizás el LR aquí no sea muy elevado (imaginaros que alrededor de 380) y decidamos ampliar análisis. El estudio de XSTRs nos ayudaría mucho en este caso, está clarísimo. Imaginaros que hemos analizado las 4 muestras, que la niña1 y la niña2 comparten alelos en cada cluster y que planteamos las mismas hipótesis H3 y H4. Con FamLinkX podemos calcular de manera muy sencilla si los resultados de nuestro análisis de XSTRs apoyan más una hipótesis que otra. Supongamos que obtenemos LRH3vsH4 = e+07. Menos mal que hemos pensado en otras hipótesis y no nos hemos limitado a informar de la exclusión entre la niña1 y la madre!! Está claro que las consecuencias podrían haber sido terribles para esta madre.

Pero Thore me ha dicho que hay una forma mejor de hacer los cálculos! No es necesario que bombardeemos con tantos LRs en los informes... se pueden contrastar todas las hipótesis a la vez:

H1 = la niña2 y el niño3 son hermanos completos, la mujer es su madre

H2 = la niña2 y el niño3 son medio-hermanos, la mujer es su madre

H3 = la niña2 y el niño3 son hermanos completos (la mujer es su madre), y la niña 1 es medio hermana paterna de 2 y 3.

H4 = la niña2 y el niño3 son hermanos completos (la mujer es su madre), y la niña 1 no está relacionada con este pedigrí.

Si hacemos esto con Familias (marcadores autosómicos) y escalamos en H4, obtenemos:

Es decir, un LR de unos 380 favoreciendo H3: lo mismo que cuando comparábamos H3 y H4 sólo. Veis que para H1 nos sale 1 (como H4 escalado). Es porque H1 y H4 son básicamente la misma hipótesis, pero la hemos definido para poder compararla con H2. Para ello, escalamos en H2 y obtenemos:

En este caso, H1 se ve favorecida 42E+06 veces, como ya habíamos visto al comparar sólo H1 y H2. De nuevo, H1 y H4 nos da el mismo resultado porque son en realidad la misma hipótesis.

Bueno, pues espero que os haya sido útil este ejemplo! Nos ha servido para ilustrar una vez más lo importante que son las hipótesis y tener la mente abierta a varias posibilidades!!



Siguiente »