# data[].attributes.body
FERNANDEZ BARÁN FABRICIO

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.

# data[].attributes.body
Un dato debe ser claro, unívoco y descripto de una sola manera para evitar inconsistencias o riesgos en la toma de decisiones. En el grupo de respuestas de mis compañeros encuentro la misma dificultad que tengo yo. El dar el nombre correcto al tipo de error, si es de exactitud, consistencia o conformidad cuando se trata de nombrar a una mismo dato de distintas maneras. A esta altura de la materia, podemos ya valorar la importancia que tiene la normalización, que organiza los datos para reducir la redundancia y mejorar la integridad, coherencia y precisión en la base de datos. Dejo el post hoy, no pude encontrar mi publicación anterior.

# data[].attributes.body
Disculpas, tengo idea que cumplí con la actividad pero no puedo encontrar mi publicación. Hay varios ejemplos de diferentes maneras de registrar el mismo dato. En la columna Nacionalidad existen registros de personas que nacieron en nuestro país figurando como "ARG", Argentina", Argentino". En la columna Sede se encuentra por ejemplo "Belgrano" "Belgrano I" "Belgrano 1" siendo que debe tratarse del mismo lugar.

# data[].attributes.headline
Error en la columna de servicio medico a cargo.

# data[].attributes.subject
Error en la columna de servicio medico a cargo.

# data[].attributes.body
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.

Sebastián Pereda

# data[].attributes.body
Perdón por la demora, creí haber posteado esto anteriormente pero no lo encuentro en ningún lado.

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!

# data[].attributes.body
En la base de datos se encuentran varios errores de inconsistencia. Algunos puntuales son, por ejemplo, en la fila 57 y la columna NACIONALIDAD aparece como dato "Colonia", siendo que esta es una ciudad y no un país, menos una nacionalidad. Otro ejemplo, en la columna de MEDICO CABECERA, un mismo profesional aparece en diferentes "servicios médicos a cargo", como la Dra Maria Pissano que en algunos casos tiene como dato CLINICA MÉDICA y en otros GINECOLOGÍA.

# data[].attributes.body
Cierre de Padlet

# data[].attributes.body
Cierre de Padlet

# data[].attributes.body
Cierre de Padlet

# data[].attributes.body
Cierre de Padlet

# data[].attributes.body
Cierre de Padlet

# data[].attributes.body
Cierre de Padlet

# data[].attributes.body
Cuando evaluamos CONSISTENCIA, para varios registro ID INTERNACION N 1, 2,3,46

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.

# data[].attributes.body
Concuerdo con los companeros en que la conformidad no se cumple en el campo "Tipo de Sangre". Se podria tomar algunas acciones para remediar esto:

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.

# data[].attributes.body
Coincido con mis compañeros en que la Complitud no se cumple en los campos de Contacto. Podrían tomarse ciertas medidas que pueden remediar esto, a saber:

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.

# data[].attributes.body
En base al analisis que se necesite realizar se puede evaluar el tema de completitud. Por ejemplo telefono, tal vez para el trabajo asistencial no es un dato obligatorio, pero si se necesita contactar al paciente para alguna consulta o gestión la falta de ese datos dificultara la tarea.

# data[].attributes.body
El dato Nacionalidad al no estar estandarizado, o normalizado, pemite mas de una forma para definir unaa mismo concepto, por ejemplo "Argentina" y "ARG". Al procesar el dato se puede contemplar que son dos tipos de nacionalidad diferentes, y eso genera la necesidad de tener que realizar una tarea de limpieza de los datos antes de procesarlos. Cuando mas grande es el volumen de datos el esfuerzo de limpieza es mayor con el riesgo de que no quede correcto de todas maneras. Otro ejemplo de es el dato "Diagnostico de ingreso". Para este caso se complica aun mas la limpieza, por la cantidad de posibles terminos, cuando mas amplio es mas compleja es la limpieza

# data[].attributes.body
Para garantizar esta dimensión y asegurar las referencias entre las entidades es necesario contar con identificadores unívocos para cada entidad. La falta de identificadores unívocos de cada entidad por ejemplo (Paciente, especialidad, sede, etc) va a imposibilitar referenciarlos desde otras entidades y de utilizar los datos para extraer información. Para ello una manera de subsanar esto es usar estándares de codificación, tablas maestras e identificadores autonuméricos.

# data[].attributes.body
Este criterio establece que ninguna entidad existente en los registros debe estar duplicada y que cada entidad registrada es única. Esta medida pregunta si existen datos duplicados. Existen registros duplicados tal como se mencionan los ID de internación 38 y 60 o 52 y 61. En el caso de los DNI duplicados si es usado como identificador del paciente esto indica un problema de calidad de datos relacionado con la unicidad de los identificadores, y más específicamente, podría afectar a la integridad de datos y a la consistencia de datos.

# data[].attributes.body
Los datos representan correctamente el verdadero valor del atributo deseado de un concepto.

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.

# data[].attributes.body
Cuando evaluamos conformidad, hablamos del uso de formatos o estándares,

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.

# data[].attributes.body
Se identifican valores que no representan el valor correcto de los atributos.

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.

# data[].attributes.body
La columna fecha de nacimiento cumpliría con la dimensión conformidad, puesto que cumple con el estándar día/mes/año, si se considera éste el estándar.

# data[].attributes.body
Se detectan problemas en la dimensión unicidad: hay registros duplicados, mismo ID en igual período de internación.

# data[].attributes.body
Se identifican datos que no son consistentes en la información registrada de los pacientes.

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.

# data[].attributes.body
Fecha del alta posterior a fecha de ingreso, refleja datos contradictorios

# data[].attributes.body
Se identifican datos que no son consistentes en la información registrada de los pacientes.

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.

# data[].attributes.body
En la columna de Diagnóstico ingreso: aparecen siglas como ACV y VSR, que no representan con exactitud el valor del atributo. Además figura "dificultad respiratoria" que corresponde a un síntoma, no a un diagnóstico

# data[].attributes.body
Al referirnos a la consistencia, buscamos que no existan contradicciones entre los datos y sean coherentes entre sí. Es este caso, los errores en las fechas de ingreso y de alta son ejemplos de la ausencia o falla en esta dimensión

# data[].attributes.body
Considero que hay problemas en la dimensión consistencia: el registro de datos que corresponden a un mismo atributo, se realiza de forma diferente. Por ej, Sexo: Masculino, varón, masculino, m, M. Nacionalidad: Argentina, ARG, Argentino, ARG. Recibe sangre: Si, S. Tipo Sangre: O+, 0+

# data[].attributes.headline
En cuanto a la conformidad, podemos observar, por ejemplo en la columna referida al grupo sanguíneo hay errores en las anotaciones de los datos (con el uso de cero y letra "o") como errores en el formato que por convención se utiliza. 

# data[].attributes.subject
En cuanto a la conformidad, podemos observar, por ejemplo en la columna referida al grupo sanguíneo hay errores en las anotaciones de los datos (con el uso de cero y letra "o") como errores en el formato que por convención se utiliza. 

# data[].attributes.body
Sol Macarena Barrios

# data[].attributes.body
En relación a la completitud del dato, teniendo en cuenta que ningún dato debería ser obviado, podemos destacar que faltan datos en las columnas del resgistro de datos telefónicos, familiares y su vínculo con los pacientes.

# data[].attributes.body
Se encuentra incompleta la información de datos de contacto para algunos pacientes. Esto fue comentado en general por mis compañeros sugiriendo que estos datos puedan ser obligatorios y estructurados para evitar la falta de completitud. Con motivo de recuperar la información o actualizarla; se sugiere que en una siguiente atención del paciente se les pueda consultar por estos datos a modo de completarlos o bien actualizarlos.

# data[].attributes.body
Coincido con otros compañeros de que existen faltantes en la dimensión completitud. Faltan datos en relación a: nombre de médico de cabecera (en algunos figura sólo el apellido), en la columna de contactos están la mayoría sin datos, y en algunos sólo está registrado el nombre, sin apellido)

# data[].attributes.body
No cumple con la conformidad ya que los datos en la columna no siguen un orden en el caso del grupo sanguineo lo especifica bien.-

# data[].attributes.body
Cuando evaluamos este valor, hacemos referencia a que los datos existen, primordialmente en los campos obligatorios.

Ejemplo:

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

# data[].attributes.body
En la columna de tipo de sangre hay undato que se refleja como "b negativo" donde en los datos anteriores y posteriores se estaba denominando de otra manera. Esto quiere decir que no cumple con los atributos de los estándares o normativas vigentes de recolección de datos.

# data[].attributes.body
En la columna de contacto, se nota de forma incompleta, por lo tanto se puede observar un error en la dimension de completitud. Demostrando un escaso registro siendo un dato de importancia.

# data[].attributes.body
La columna de teléfono muestra inconsistencias en sus datos. Cada registro aparece en un formato distinto; por ejemplo, el número de la fila 12 es el único que contiene el código de país. Además, ciertos números tienen más dígitos que otros, lo que provoca variación y posibles confusiones.

# data[].attributes.body
Considero que la integridad se mantiene en la tabla, porque si bien existen errores en los datos se mantiene en cada fila la informacion de forma coherente (exceptuando donde existen errores demasiado importantes). Pero no tenemos otra tabla u fuente de datos aparte de la tabla presentada para hablar de integridad, propiamente dicha.

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

# data[].attributes.body
La unicidad establece que ninguna entidad existente en los registros esté duplicada. En otras palabras, cada entidad registrada es única. En lo personal me costo mucho encontrar datos duplicados, pero algunos compañeros lograron encontrarlos.

# data[].attributes.body
Los datos deben estar libres de contradicción y ser coherentes con otros datos, se debe realizar un análisis del registro (fila) comparando unos campos o atributos con otros campos de la misma fila o registro.

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.

# data[].attributes.body
En las columnas que pertenecen a Contacto (teléfono, vinculo, nombre y apellido) se visualiza que estan incompletas, por lo que podemos decir que no cumple con una de las dimensiones que seria completitud.

# data[].attributes.body
Evaluando la calidad del dato de la base del ejercicio, detectamos en la variable "SEDE" valores inexactos a la hora de cargar el valor. Por ejemplo La Sede Belgrano tiene valores cargados con numeros Romanos, "Belgrano I " y despues tiene datos con numeros enteros "Belgrano 1" o " Belgrano II" y "Belgrano 2". Esta mala calidad si no se detecta puede traducirse en mal analisis y malos resultados.

# data[].attributes.body
Uno de los grandes problemas relacionados a la inexactitud de los datos se debe al ingreso manual (o tipeo). En mi opinión es uno tipo de error bastante difícil de controlar. Parte de la solución radica en intentar implementar todas aquellas tecnologías tendientes a evitar la carga manual, ya se desde lectura por código de barras, RFID, validación con bases de datos gubernamentales etc.

# data[].attributes.body
Una alternativa para evitar errores de consistencia o incoherencia de los datos es aplicar reglas de restricción. Por ej "La fecha de internación no puede ser posterior a la fecha de alta"

# data[].attributes.body
Una forma de evitar los errores de conformidad de datos es establecer un sistema de validacion de datos que limite el tipo de dato posible de ingresar a un conjunto de opciones prestablecidas. Esto permitira estandarizar el dato y que a futuro sirva para extraer informacion.

# data[].attributes.body
Por error publique en anonimo y en la columna equivocada, hasta el texto libre en PADLET puede conducir al ingreso de datos erroneos (falta de exactitud).

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.

# data[].attributes.body
Leyendo las publicaciones anteriores me doy cuenta como se puede confundir un error de exactitud con uno de consistencia, debido a que la exactitud es el grado en el que los datos representan correctamente el verdadero valor del atributo deseado de un concepto, en un contexto de uso específico. Y por ejemplo en id 9 se coloca que un paciente adulto pesa 9kg, esto claramente es inexacto pero también es inconsistente, porque la consistencia es el grado en el que los datos están libres de contradicción y son coherentes con otros datos en un contexto de uso específico.

# data[].attributes.headline
 La base de datos presenta una identificacion por numero de  ID por numeración ascendente simple, esto dificultara para futuros análisis de datos referenciar la información 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.

# data[].attributes.subject
 La base de datos presenta una identificacion por numero de  ID por numeración ascendente simple, esto dificultara para futuros análisis de datos referenciar la información 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.

# data[].attributes.body
Los errores de consistencia no son tan frecuentes en esta tabla como otros, y esto creo que es debido a que son tan evidentes que normalmente los operadores tienden a evitarlos.

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.

# data[].attributes.body
Como bien han detallado mis compañeros, los errores de conformidad son los mas frecuentes en esta tabla y ejemplos de esto son:

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.

# data[].attributes.body
Coincido con mis compañeros en que existen múltiples errores de completitud en las columnas de contactos porque falta ingresar los datos en la columna de teléfono, vinculo y nombre y apellido. Probablemente esta información no haya sido proporcionada por el paciente por considerarla de poca importancia, por lo cual es responsabilidad de la institución la insistencia para la obtención de este dato.

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.

# data[].attributes.body
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

# data[].attributes.body
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

# data[].attributes.body
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

# data[].attributes.body
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 .

# data[].attributes.body
Coincido que los atributos de contacto estan incompletos algunos como el parentesco quizás puedan considerarse como opcional pero si queremos evaluar la calidad de atención de un paciente, es conveniente mantener un contacto estrecho con el y su familia, es por que es conveniente aplicar técnicas de CRM y para ello mantener un canal de contacto es fundamental por lo que estos campos deberian ser obligatorios para evitar que no lo carguen y que también tenga validación del nro. de telefóno ya que esta cargado con diversos formatos

# data[].attributes.body
En la columna SERVICIO MEDICO A CARGO del paciente identeficado como ID1, dice el dato ingresado es CINICO en lo que probablemente hayan querido decir CLINICO. De la misma forma ese area esta identificada de distintas maneras: Clínica, Clinica Médica, Clínico. Con mayúsculas, minusculas, con tildes o sin tildes.

# data[].attributes.headline
Inconsistencia de fechas de ingreso y de alta

# data[].attributes.subject
Inconsistencia de fechas de ingreso y de alta

# data[].attributes.body
Algunas altas están cargadas con fecha anterior al ingreso.

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.

# data[].attributes.body
No cumplen con la dimensión conformidad ya que se utilizan diferentes formas para plasmar un mismo dato (ej sede Belgrano 1 y Belgrano I; varón y masculino, etc.)

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

# data[].attributes.body
Existen varios errores respecto esta dimensión:

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.

# data[].attributes.body
Fecha de alta previa a la fecha de ingreso. Datos no consistentes.

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

# data[].attributes.body
Datos de contacto: Las columnas de contacto están incompletas. Siendo datos de gran importancia ante un evento de internación. Se podría regularizar estandarizando el campo como obligatorio para el registro de la epicrisis.

# data[].attributes.body
En la planilla, la "Cama 54" aparece asignada a diferentes pacientes en múltiples registros (Ejemplo: ID 34 y ID 35). Esto sugiere un error en la actualización o manejo del inventario de camas.

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.

# data[].attributes.body
En la columna "Diagnóstico de ingreso" hay pacientes que tienen como diagnóstico "Control de salud", lo que no corresponde a un diagnóstico médico, por lo que este dato no representa correctamente el verdadero valor del atributo deseado del concepto "Diagnóstico de ingreso"

# data[].attributes.body
En la fila 59 hay un paciente de 18 años que se encuentra ingresado en el servicio de pediatría. Por lo menos en Chile los paciente de 15 años o más son considerados adultos.

# data[].attributes.body
Existen varios datos como por ejemplo los de la columna "sexo", "nacionalidad", "médico de cabecera" que se encuentren registrados de distinta manera, por ejemplo en la columna "nacionalidad" la nacionalidad Argentina en algunos aparece como "Argentina" y en otros aparece como "ARG". Este problema se podría subsanar dejando el campo, como un campo de tipo estructurado, en el cual el profesional despliega las opciones que se encuentran cargados en dicho campo y elige la que desea cargar en dicho campo.

# data[].attributes.body
La consistencia, se refiere a la coherencia de los datos en cuanto a su tipo y formato a lo largo del sistema (interno o externo), en los datos cargados en la columna DNI se observa inconsistencia.

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.

# data[].attributes.body
Las columnas de contacto: "teléfono", "vínculo" y "nombre y Apellido" en su mayoría se encuentran vacíos. Este error se podría subsanar colocando estos campos como campos obligatorios, por lo que los profesionales que completan estos datos se verían en la obligación de completarlos

# data[].attributes.body
En la columna médico cabecera los formatos de nombre son distintos (sólo apellido/nombre,apellido/apellido,nombre). Una solución sería estandarizar el registro mediante una lista desplegable de médicos del staff con un solo formato.

# data[].attributes.body
En la columna tipo de sangre hay valores escritos en forma diferentes. Ya que existe un número limitado de opciones, una solución sería tener una lista desplegable de las combinaciones posibles predeterminadas

# data[].attributes.body
En la fila (alta 98), el nombre de la persona es Guillermo, varón, pero sale como control ginecológico, llama la atención a menos que pudiera tener disforia de género y fuera su nombre "social"

# data[].attributes.body
En la columna de "servicio médico a cargo", hay valores Neumonología y Neumonólogo, lo cual no corresponde. También se observan diferencias de ortografía entre los mismo servicios registrados.

# data[].attributes.body
No se respeta un estándar al llamar los tipos de sangre. En ocasiones un grupo se llama o, a veces 0 y a veces O. Ocurre lo mismo con AB, incluso llegan a llamarlo "a-b+" impidiendo reconocer si el factor RH es negativo o positivo.

# data[].attributes.body
En la columna "diagnósticos" hay inconsistencia en cuanto a las enfermedades respiratorias. En algunos casos se completo con diagnostico de bronquitis , neumonía y en otros se puso " dificultad respiratoria" . Por otro lado en cuanto a las neumonías en algunos casos se completo "neumonía" y en otros "neumonía bacteriana" , eso lleva a una posible interpretación errónea: en algunos casos se aclara la causa infecciosa de la neumonía y en otros no se especifica.

# data[].attributes.body
El campo "Sexo" contiene datos como M, Masculino, Mujer, Varón, F. siendo imposible agrupar los datos de una misma categoría porque no se nombran de una manera unívoca.

# data[].attributes.body
La columna "Sector" contiene datos que difieren. Un mismo dato se nombra de diferentes maneras (A, Sector A, Sección A).

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.

# data[].attributes.body
En la columna "sector" ID 14, el dato es ingresado como "sección B" En lugar de "B" como en el resto de los registros. La falta de exactitud del dato puede dificultar su interpretación. Una solución posible a este error es borrar la palabra "sección"

# data[].attributes.body
el peso esta expresado como numero entero sin decimales no indicando si habla de libras o kilogramos por ejemplo. La forma internacional habirual de reportarlo es en kilos y con decimales.

En este caso no fueron datos con atributo de conformidad.

# data[].attributes.body
En la columna de servicio clinico a cargo podemos ver que por ejemplo Clinica Medica es mencionado de distintas maneras y no siemrpe se asocian adecuadamente a la patologia. Esto lo hace inconsistente porque si uno quiere valorar la tasa de apcientes que ingresan al lugar por origen ( ginecologico, cirugia, clincia etc) , no sera posible ya que los datos ingresados son variables y no coinciden siempre con el servicio a cargo.

# data[].attributes.body
Los diagnosticos estan duplicados en algunos casos , no haciendo referencia a que motivo genero la internacion. Por ejemplo VSR que significa virus sinsicial resporatorio esta mas de una vez. En una tabla donde buscquemos etiologias de cuadros gripales podria ser valido, pero la columna solicita diagnosticos, que en este caso seria neumonia, sindorme gripal u otros.

# data[].attributes.body
En la columna Nacionalidad se usa como valor de respuesta indistintamente Arg, Argentino entre otros. Eso hace que el valor para poder cuantificar por ejemplo cuantos pacientes de la misma nacionalidad estuvieron internados, no se pueda realizar ya que los valores de definicion no son exactos.

# data[].attributes.body
en la columna que indica recibe sangre, se responde indistintamente con: S , Si, N, No.

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.

# data[].attributes.body
Se observa inconsistencia en el registro del dato NACIONALIDAD. El mismo se presenta de manera completa en algunas oportunidades y con abreviaturas en otras, lo cual trae dificultades a la hora de un eventual uso del mismo

# data[].attributes.body
Para que el dato Recibe sangre cumpla con conformidad debería permitir solamente el ingreso de Sí o No, S o N, Si o No, etc.

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.

# data[].attributes.body
El dato de peso (9 Kg) es inconsistente con la edad (54 años)

# data[].attributes.body
Los datos de servicio generalmente se nombran de manera estándar en las instituciones lo que garantiza que se identifique de forma unívoca y además permita el análisis de los datos. En este caso un mismo servicio que parece ser el mismo, está ingresado con diferentes nombres, por ejemplo: Cardiología (con tilde), Cardiologia (sin tilde) y Servicio de Cardiología

# data[].attributes.body
La edad al ingreso es un dato que se puede calcular en el momento que se ingresa el registro a partir de la fecha de ingreso y la fecha de nacimiento.

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.

# data[].attributes.headline
Exactitud/Consistencia entre objetivo y datos “Reporte Altas Enero 2023”

# data[].attributes.subject
Exactitud/Consistencia entre objetivo y datos “Reporte Altas Enero 2023”

# data[].attributes.body
En la planilla existen registros con fecha de alta en Enero de 2022 que no deberían formar parte de la planilla ya que el reporte se presenta como altas de Enero del año 2023

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

# data[].attributes.body
Dentro de la misma columna de Sexo los datos no son exactos ya que:

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.

# data[].attributes.body
La estandarización de los nombres de los sectores en forma de lista es una de las formas de asegurar la conformidad de los datos. Puede ser una lista de nombres de sectores que se ofrece al momento del ingreso/modificación de los datos. Al seleccionar el dato, en lugar de escribirlo evita el error de escritura o de interpretación de como ingresar dicho dato.

# data[].attributes.body
Una posible solución para la conformidad del dato Sede, es definir una lista con los nombres de las sedes de la institución, de forma que al ingreso se deba seleccionar la sede de la lista en lugar de escribirlo. De esta forma se estandariza el ingreso de los datos logrando la conformidad con el estándar definido, ya sea localmente a la institución o a nivel más amplio (nacional, internacional)

# data[].attributes.body
En relación a la consistencia de fechas de ingreso, egreso y fecha de nacimiento, una propuesta de solución es que al ingreso de un registro de internación, para los datos de fechas se controle la consistencia entre éstas:

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.

# data[].attributes.body
Un paciente registrado con una supuesta edad de 45 años en el reporte de alta, en el expediente se indica que tiene 70 años

# data[].attributes.body
El campo para el número de historia clínica tiene un formato de 8 dígitos, pero algunos registros tienen 7 dígitos o contienen letras.

# data[].attributes.body
Los valores de "SEXO" y "TIPO SANGRE" parecen tener formatos inconsistentes, por ejemplo, "M" y "Masculino" o "0+" y "O positivo". Es importante estandarizar estos valores.

# data[].attributes.body
dentro de la columna en donde se registra si se recibe sangre o no, la misma se encuentra con una variable dicotomica de "S" o "N". En esta columna podesmos encontrarnos con errores que podrian ser errores de tipeo o falta de atencion ya que en mas de una oportunidad nos encontramos con valores de SI o NO en lugar de S o N. Al querer analizar dicha variable podriamos encontrarnos con errores.

# data[].attributes.body
Dimensión Completitud:

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.

# data[].attributes.body
Error en Dimensión Completitud

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.