A mismos recursos se les adjudica un servicio medico con nombre diferente como por ejemplo Servicio de Cardióloga y cardiología o cirugía general y Departamento de cirugía general. O mismas especialidades escritas con minúsculas o mayúsculas.

La misma sede tiene diferentes maneras de nombrarse, cito ejemplos: Belgrano I, Blegrano 1, Belgrano II, Belgrano 2.

Algunos ejemplos incluyen:

• Internación: "2023-01-30", Alta: "2023-01-29"

• Internación: "2022-05-12", Alta: "2022-01-07"

En este caso el error se produce debido que no presenta un formato estándar , en algunas columnas el "si" aparece como SI o S

La fecha de nacimiento que figura (18/12/2023) es posterior a la fecha de ingreso y egreso de la internación (12/05/2022-07/01/2022, que ya de por sí son inconsistentes ya que la fecha de ingreso es mayor a la de egreso).

Además, según el dato de la edad, tiene 3 años, algo que tampoco es consistente con el peso que presenta, de 96 kg.

Hay una inconsistencia en el período de internación del paciente 15, ya que figura una fecha de ingreso posterior al alta (30/1/2023 y 29/1/2023 respectivamente).

El error se produce por que no esta establecido el formato para su registro: Ejemplo registrar DNI sin puntos ni espacios. La mayoría de los datos de DNI están registrados con punto pero existen registros con datos sin punto.

id 36 Horacio Moreno: 3 años, 96 kg inconsistencia: entre edad y peso.

id 9, Naranjo Gutierrez, 54 años, 9 kg, inconsistencia entre edad y peso.

id 36 Horacio Moreno: 3 años, 96 kg inconsistencia: entre edad y peso.

id 9, Naranjo Gutierrez, 54 años, 9 kg, inconsistencia entre edad y peso.

Un dato que no cumple con las dimensiones de calidad es en la columna de "Tipo de Sangre". Algunos registros utilizan "A-B", mientras que otros emplean formatos como "b +" o "0-". Esta falta de uniformidad afecta la conformidad del dato, ya que no sigue un estándar común. Para mejorar la calidad, sería importante normalizar todos los tipos de sangre a un formato consistente, como "A-", "B+", "O-", etc

La misma sede tiene diferentes maneras de nombrarse, cito ejemplos: Belgrano I, Blegrano 1, Belgrano II, Belgrano 2.

Sección CONTACTO / Dato VÍNCULO/

Hay un faltante importante de atributos para la entidad (Vínculo), para la cual hay escasos registros (no sabemos si es un dato requerido), y este faltante puede ser porque no se registra, porque no es un dato obligatorio o por falta de adecuada recolección. Una solución podría ser estructurar la recolección y hacerla obligatoria.

Error en el Apartado de Contactos / Dato: Nombre y Apellido.

En la Base de Datos, no se completó de forma adecuada toda la información correspondiente al Nombre y Apellido del contacto para cada uno de los pacientes internados. Para este punto es importante tener claro si este dato es sensible y requerido para los dueños de la base de datos, en mi caso particular considero que representa información sensible a la hora de dar de Alta a un paciente internado o por cualquier complicación que se presente en su estancia, por cuanto es de mucha relevancia. La forma de corregirlo es que dentro del formulario se pueda contar con campos estructurados que permitan el adecuado registro de información, los cuales deben ser establecidos como obligatorios y que permitan continuar con los registros únicamente si se completan con información valida. En este caso propondría que, en lugar de anotar nombre y apellido, se pida el número de identificación y que el sistema haga una búsqueda en la Base de Datos de registro nacional de habitantes (residentes) y me traiga el nombre y apellido completo del contacto, de esta forma se asegura de contar con el dato preciso para su registro en la Base de Datos.

1. Que la fecha de nacimiento sea anterior a la fecha de ingreso a la internación.

2. Que la fecha de egreso sea posterior a la fecha de ingreso.

3. Y no permita el ingreso de datos de fecha que no cumplan estos criterios.

• La letra "M" se podría interpretar como "Mujer" o "Masculino"

• En el contexto de la planilla los datos 1 y 2 no es posible saber a que valor representan.

Los datos no representan claramente el concepto que se pretende registrar.

Coincide con un error de consistencia que la fecha de alta es anterior a la de ingreso.

Existen 3 registros que tienen inconsistencia entre edad y la dupla: fecha de ingreso y fecha de nacimiento.

Además del ID 36 que tiene otras inconsistencias ya mencionadas.

Dependiendo de la herramienta que se utilice para ingresar el dato se podría ofrecer solamente esos dos valores al ingreso, o bien, la posibilidad de marcar Sí o No y solamente uno de los valores.

Sin embargo no aclara la significancia del mismo no dandole integridad al dato. Podria referirse a que el pacinete acepta transfusion en caso de ser necesario, o que el paciente requiruio transfusion realmente, o que la cirugia o procedimiento realziado tiene asignado unidades de sangre en reserva. En este caso el valor del dato se pierde ya que la valoracion no es unanime con SI/No por ejemplo y poruqe ademas no menciona a que se refiere.

En este caso no fueron datos con atributo de conformidad.

La columna "Nombre Apellido" tiene algunos registros que figuran como Hernández, Augusto y otros que tienen solo apellidos, otros siguen el orden propuesto Juan Pérez.

En este centro de salud, se tiene un grupo de datos llamado "DNI" donde se espera que se ingrese únicamente el número de documento nacional de identidad en un mismo formato, de manera correcta y consistente. Sin embargo, algunos usuarios pueden estar ingresando datos de CI, LE, LC, ente otros tipos de identificaciones en este mismo campo, ya que el DNI aunque es el documento de identidad más habitual en nuestro país, no es el único, y en poblaciones tam variadas es casi improbable que toda su población siempre mantenga ese unico documento de identidad.

Este registro, además, se realiza en un campo libre, sin validaciones previas en la carga (lo que se infiere por las diferencias en la carga de datos de la misma columna) ni validaciones con otros datos como la fecha de nacimiento, nombre/s y apellido/s, fundamentales todos para la correcta identificación de las personas.

Si estos datos se utiliza en otros sistemas, incluso si se realizan validaciones de identificación externa, las inconsistencias imposibilitan la trazabilidad de la información.

Por ejemplo:

En un registro el número es un DNI 12345678 (sin puntos), en otro es 33.789.043 (con puntos) y en otro al comparar los datos cargados en la columna DNI con los cargados en la columna FECHA NACIMIENTO, se ven claramente inconsistencias de información.

Cómo afecta la inconsistencia:

Errores en la validación de identidad: Cuando los datos son utilizados para verificar la identidad de los pacientes en distintos sistemas, podría fallar la autenticación, ya que el sistema puede estar configurado para procesar solo números de DNI.

Problemas en la interoperabilidad: Si estos datos son enviados a otras entidades (como seguros o autoridades gubernamentales), podría haber fallos en la interoperabilidad si ellos esperan un DNI o distintos tipos de identificación y reciben datos numéricos, sin una estructura preestablecida o diferenciados.

Confusión en la toma de decisiones: el personal asistencial o administrativo, podría no confiar en la información del sistema si encuentra inconsistencias en los documentos de identidad, o en su forma de registrar esos datos. Pudiendo generar problemas graves desde indicaciones y tratamientos, registros, facturación, autorizaciones externas, etc.

La duplicación de este registro afecta la unicidad, ya que compromete la veracidad del uso de recursos hospitalarios, dificultando el seguimiento adecuado de las camas disponibles y ocupadas.

También x ejemplo hay camas que están utilizadas al mismo tiempo en internaciones diferentes.

Médico de Cabecera: algunos solo apellidos , otros nombre y apellido.

DNI: algunos datos no corresponden con la estructura de un DNI

Peso: sólo números enteros

Tipo de Sangre: diferentes tipos ingresados no respetando la normativa internacional.

Sede - misma sede con más de una forma de registro

Lo mismo se repite para las variables: Sector, Sexo, Nacionalidad, Recibe Sangre.

Se podría solucionar implementando, por ejemplo, listas desplegables para campos con opciones limitadas.

Este error podría corregirse implementando una regla de validación en el programa que utilizamos para cargar los datos (ej Excel) que impida ingresar una fecha de alta anterior a la del ingreso.

Hay varias falencias con respecto a esta dimensión:

1) Paciente, no respetan escribir el Nombre y Apellido y en varios casos están intercambiados.

2) El sector esta ingresado con diferentes formatos con y sin sufijos

3) La sede también mezcla numeros arabigos con romanos.

4) Igual que el sexo, solo falto que algun inclusivo ponga una X :)

5) Nacionalidad, Recibe Sangre, Tipo de Sangre también

Para solucionar todo esto hay que hacer un trabajo de ETL (extract, transformation, load) luego quizás se puede tener información confiable .

Con respecto a la consistencia hay varias contradicciones:

1) alta anterior al ingreso, ID de internacion 15,36,44,51

2) Otro que nacio un año y medio despues de su alta ID 36

Con respecto a esta dimensión existen falencias en:

1) La edad del paciente al momento del ingreso, hay caso que difiere la edad calculada con la que muestra la columna (id 36,72,88,90)

2) También el peso tiene errores como el id 9 que dice 9kg siendo un hombre de 54 años

Por lo general estos datos se descartan para evitar el sesgo

Con respecto a la unicidad

1) Existe un ingreso repetido el id 38 y 60 es el mismo paciente y el mismo periodo de internación.

2) También existen Documentos repetidos que hacen referencia a distintas personas como es el caso del ID 36 y 91

3) Tambien se detecta internaciones cuyo periodo de internacion estan solapados como el id 52 y 51

En la columna medico de cabecera existen múltiples errores de completitud debido a que no se encuentra el dato completo del nombre y apellido del medico, esto puede conducir a errores porque múltiples médicos pueden presentar el mismo apellido.

id30 existe un error de conformidad porque el dato DNI no se ingresa según la convención

id5 existe un error de conformidad en el dato de servicio médico a cargo porque no se escribe solo el servicio que es cardiología, sino que escribe servicio de cardiología

 id34 existe un error de conformidad en el columna de tipo de sangre

En la columna de sexo existe un error de conformidad porque no se respetan una sola convención para el ingreso del dato

Y esto solo es por dar ejemplos, porque hay varios mas. Sin dudas una columna desplegable con las opciones correspondientes seria una muy buena opción para evitar estos errores donde no se respeta una convención.

Podemos mencionar errores como:

En el id 29 existe un error de consistencia debido a que el DNI tiene el valor de 00.267.963 lo cual es imposible porque el paciente tiene 22 años

En el id 9 existe un error de consistencia en el dato del peso porque por la edad y sexo el paciente no podría pesar 9kg

Para evitar estos errores y otro mas expuestos por mis compañeros, la misma tabla debería tener avisos para valores máximos y mínimos respecto al peso, entendiendo que son todos pacientes adultos, y además respecto a la fecha, no permitiendo ingresar valores sin lógica.

Correponde a esta columna la siguiente observacion:

La base de datos presenta una identficacion por numeracion de ID ascendente simple, esto dificultara para futuros analisis de dadots referenciar la informacion clinica y filiatoria de un mismo paciente con los eventos de internacion. Ademas si por alguna razón, se reinicia la numeración (por ejemplo, al llegar a un número límite), podría haber duplicados. Esto causaría confusión y dificultaría la identificación de la internación específica de un paciente.

Es un termino que considero el mas complejo de todos los tipos de errores, y me disculpo si no es correcta esta respuesta.

Ejemplo: 

En el caso de Médico de Cabecera que algunos tengan solo apellidos, otros nombre y apellido tal y como está planteado correspondería a un defecto de la dimensión Completitud. 

Que nombres y apellidos del paciente estén en un mismo campo no es una buena práctica y debieran separarse en dos campos Apellido y Nombre para evitar errores como el mencionado que correspondería a Exactitud.

Inconsistencia en la variable "Tipo Sangre", Nacionalidad, Formato de genero v, Inconsistencia de información en la columna de "Recibe sangre": es de conformidad.

Promedio de días de estadía para neumonías, Paciente Id 23: es de exactitud.

Servicio médico a cargo/Control de salud como bien decis depende del país, no es un error.

Paciente 17 ingresa por control de salud y es internado en un servicio quirúrgico lo cual no es consistente: puede ingresar por un control de salud y ser transferido al servicio de cirugía por un problema mayor, en todo caso se debe corregir el diagnóstico y sería de exactitud.

Un año internado: puede ser un caso real, a lo sumo se debe analizar su historia clínica.

OCUPACIÓN DE CAMA EN EL MISMO PERÍODO: es de unicidad.

Este se puede confundir con la dimensión de completitud o conformidad. El ejemplo que pusieron de “Inexactitud entre datos de edad y peso” es muy bueno ya que el mismo es de conformidad inicialmente y después debemos evaluar el de exactitud para ver cual de los dos datos son erróneos.

Nombre y apellido, lo aconsejable es que sean dos atributos diferentes para evitar que se carguen en un orden no deseado.

Sexo, Nacionalidad, Grupo Sanguíneo (O), Distintos términos para la misma entidad, Error en Sector, Error en Sede: es de conformidad.

“Nacionalidad, Se registra el nombre del país de origen y no nacionalidad”: El adjetivo debe concordar en género y número con el sustantivo nacionalidad, que es femenino, por lo tanto poner Argentina en el campo Nacionalidad es correcto.

Ejemplo: 

La ausencia de datos de contacto es un ejemplo de falta de completitud.

Una forma de Evitar esto, pudiera ser contar con algoritmos de validación de la información ingresada como, por ejemplo, para el DNI y Fechas. Se observa que para un mismo paciente se tiene el registro con dos DNIs diferentes, o bien la fecha de internación es anterior a la fecha de nacimiento.

Una forma de Evitar esto, pudiera ser contar con algoritmos de validación de la información ingresada como, por ejemplo, para el DNI y Fechas. Se observa que para un mismo paciente se tiene el registro con dos DNIs diferentes, o bien la fecha de internación es anterior a la fecha de nacimiento.

Una forma de evitar esto, es contar con datos estructurados que puedan ser elegidos por el usuario que registra la información. Por ejemplo, para el sexo masculino, se tienen pacientes identificados como M, Varón, Masculino, varón, masculino... Acá se pueden generar inconsistencias importantes al momento de realizar un análisis de los datos, dado que la "m" puede estar siendo usada para el registro de Mujer y Masculino.

1. Volver todas los campos de la información de contacto (teléfono, vínculo, nombre y apellido) como obligatorias.

2. Estandarizar la entrada de datos de tal forma que el numero de celular tenga un formato especifico (xxx xxxx xxx, por ejemplo); el vínculo una lista desplegable de las principales conexiones familiares, con un apartado "otro" que permita su digitalizacion y que tambien sea estandarizado (por ejemplo, "Amigo" lleve el formato "Xxxxxxx"; por otra parte, Nombre y Apellido del contacto vayan separados y con formato de acuerdo al DNI de la persona contacto.

1. Separar en dos campos, uno "Tipo de sangre ("A", "B", "AB", "O") y otro campo "Factor Rh" (Positivo", "Negativo").

2. Generar una lista desplegable a la hora de la introduccion de los datos que permita seleccionar el tipo y Rh de la muestra del paciente.

La estancia de internación es cercana a los 12 meses, lo cual no es coherente con los diagnostico de ingreso de los pacientes, ejem registro 46 "Depresión".

Las estancias de internación de larga duración responden a patologías crónicas, ninguna presente en los registros manifestados, la estancia promedio para las patologías registradas esta entre días y 60 días como máximo.

Los problemas más frecuentes encontrados son de conformidad, ya que no se aplico ningún estándar en la mayoría de las columnas: Sede, Sector, Sexo, DNi, Nacionalidad, Diagnóstico de Ingreso, Medico Cabecera, Servicio Medico a cargo, Recibe Sangre, Tipo Sangre, Telefono, Vinculo, Nombre y Apellido. Esto hace que no haya una consistencia en los datos y esté escrito de distintas maneras (no había una validación en el input al momento de cargarlo / ingresarlo en el sistema). Los únicos datos que presentan conformidad con un estándar son las fechas, todas están en formato DD/MM/YYYY.

Hay errores de unicidad, ya que si bien la PK de la tabla es única, hay filas exactamente iguales (por ejemplo 38 y 60).

Por otro lado hay muchos DNIs repetidos con distintas personas - (aunque si bien esto podria ser cierto ya que hasta 1990 aprox el DNI tenia una M o F), por lo cuál es probable que haya un problema de exactitud (el dato es incorrecto). Datos inexactos impresiona haber también en edad, sexo y fecha de nacimiento, ya que no son consistentes con el número de DNI y el nombre de la persona.

Respecto a la integridad de los datos, es probable que también encontremos problemas, por ejemplo si quisieramos unir estos datos con una tabla de profesionales médicos tendriamos problemas para hacerlo solo con la columna Medico Cabecera (nuestra única referencia es el apellido del medico, y son apellidos comunes, y por ejemplo para el Dr. Martinez figura con distintos servicios a cargo lo cuál hace dudar de si no son dos profesionales distintos…¿inconsistencia de los datos?). 

En terminos generales, los datos están completos, excepto para los datos de telefonos de contacto, y vinculo y nombre y apellido, que si bien pareciera que son opcionales, no tuvieron reglas claras de validación en el formato del telefono, tipo de vinculo y en la estructura del nombre y apellido por lo cual, los datos ingresados podrian no ser utiles a posterior. A veces es peor un dato no estandarizado, o incorrecto, que un missing value. 

Como decian en una de las clases, garbage-in, garbage-out. 

Si bien entiendo que esto es una tabla de muestra, es un problema frecuente en la mayoría de las empresas….en general, los productores de los datos (el equipo de desarrollo) no se siente “dueño” o propietario de los datos, y no tiene una comunicación clara ni un registro claro de las necesidades que tienen los consumidores de datos (C-level, operations, BI, data science, etc.). Hay varias empresas queriendo encontrar una solución a este problema, si les interesa el tema les sugiero bajarse una copia del preview de este libro de Data Contracts https://www.gable.ai/data-contracts-book , donde en las primeras páginas habla de este problema en particular y como esta empresa busca una solución desde la ingeniería de software, con contratos de datos a nivel código para generar restricciones y checks antes de que un desarrollo o upgrade haga un cambio que rompa o modifique toda la logica downstream (rio abajo) de los datos. 

Saludos!

Sebastián Pereda

Dato no conforme:

• Registro: "ARG" en la fila 4 (Antonio González)

El uso de "ARG" como abreviatura para referirse a Argentina no es consistente con el resto de los registros, que utilizan el nombre completo del país.