Sugerencias para software de captura masiva de datos

[ivantech]

de acuerdo,

entonces vamos a recomponer de nuevo todo, favor de explicarme como lo comienzo, es decir, los siguientes factores que vamos a tener son:

los centros de digitacion y acopio no tienen acceso a internet, y en esta etapa no esta previsto invertir en internet eso me lo dejaron muy claro. entonces como lo haríamos, porfavor orientenme ya que no he tenido mucha experiencia con aplicativos mas alla de una red LAN. y tengo por política no recomendar lo que no puedo manejar.

que conste, nunca he esta en desacuerdo con ustedes, pero como no tenia mucho de donde elejir eso fue lo que se me ocurrió, transferir los datos a través de archivos TXT enviándolos por cualquier medio y en la oficina central una aplicación que leyera dicho archivo e importara el dato y rechazara el que no cumpla con ciertos criterios.

OJO: tampoco quiero que se entienda que tienen que hacer dicho proyecto, ya que estoy consciente de que solo me pueden hacer sugerencias desde sus puntos de vista, pero es que nunca había trabajado proyectos que se conectaran a replicacion y no tengo idea por donde comenzar.

les estoy muy agradecido a todos por sus comentarios, muchas gracias

[Neftali [Germán.Estévez]]

Antes de nada, he de decir que mi primera impresión ha sido similar a la de otros compañeros. Me daba la impresión de que el proyecto se estaba enfocando mal, en el sentido que que se estaban dando muchas vueltas para hacer algo que se podía hacer de forma sencilla y mejor.

También es verdad que muchas veces damos por supuestas cosas que no lo son, como que todo el mundo tiene acceso a un equipo medio-alto, conexión a internet, velocidad tipo "ADSL",...

Tal vez la suposición a sido incorrecta, y se hubiera evitado si de primeras hubieras comentado esa cuestión "levemente" importante de acceso a internet... ;-)

Empezado por ivantech

PREMISA: Los centros de digitacion y acopio no tienen acceso a internet, y en esta etapa no esta previsto invertir en internet eso me lo dejaron muy claro.

OK.
A partir de esta premisa ¿Qué nos queda?

(1) Si hay línea telefónica.
Lo único que se me ocurre en este caso es utilizar módems. Tendrían que estar dispuestos a comprarlos (creo que son bastante asequibles de precio) y en este caso buscar cómo implementar una comunicación vía modem.
Al final el sistema sería parecido al que comentas, pero el envío se haría vía modem-modem.
Las ventajas en este caso serían la fiabilidad y la rapidez. Las desventajas, que el sistema se complica (por el tema de la comunicación), se encarece y es más propenso a errores "técnicos".

NOTA: Si esta opción es viable, dilo y podemos ahondar en este camino...

(2) Si no hay línea telefónica.
Pues no hay mucha más opción que la que comentas. Generar un fichero TXT/CSV/DBF (como más te guste) que envías a la central y que allí importan.

La única "pega" que le veo al sistema que comentas: delphi 7 + ADO + ODBC + Firebird 2.1 es la forma de acceder a FB. Hacerlo vía ADO+ODBC no es la forma más directa y seguro que hay componentes de acceso nativo a FB para poder hacer: delphi 7 + CompNativo + Firebird 2.1 y ahorrate así un paso.

[Casimiro Noteví]

Para poder opinar con más seguridad necesitamos conocer más a fondo el proyecto.
Suponemos que se van a recoger unos datos mediante un formulario, ¿están asociados esos datos a códigos de pacientes?, ¿esos códigos son independientes para cada uno o se repiten en cada centro de salud?, ¿con qué propósito se recogen esos datos?, ¿para qué se quieren centralizar?, etc.
En fin, conocer más del proyecto y su objetivo.

[[AzidRain]]

Andale Casimiro, coincido, con esos datos si podemos pensar en alguna solución. Ya nos quedó claro las limitantes del caso obviamente hay que pensar en todos los puntos que hay que cuidar y por donde la cosa puede fallar. Un punto que considero muy importante es asegurar la calidad de los datos capturados ya que no hay contra qué validarlos al momento de hacer las capturas. Hay que pensar en una manera de asegurarnos que el "paquete" con la información capturada es correcto.

[ivantech]

hola

por donde comiezo, fijate

en dicha captura el 90% de los datos ya estan precodificados, solo un 10% de informacion se digita lo demas se selecciona de una lista. un ejemplo es que dicho formulario maneja el CIE10 y CIE9 que son códigos internaciones de clasificacion de procedimientos y diagnósticos de enfermedades. datos como la aseguradora y el regimen de salud al que pertenecen son seleccionables de una lista y ademas muchos datos son por default. la edad seria calculada en base a un algoritmo y la fecha de nacimiento. datos a capturar serian el nombre, fecha de nacimiento, dirección.

bueno adjunto les dejo una version prelimiar del formulario en formato de aplicacion. revisenlo y a ver que tal.

[ivantech]

con respecto a los códigos, se repiten en todas parte, es decir, es el mismo código en cada un a de las 9 regiones de salud que tiene mi país. el dato es redundante, es decir, cada vez que te atienden te vuelven a capturar el nombre y tus datos personales, por la misma naturaleza como no es un sistema on-line en la que construyes una base de datos de pacientes y/o usuarios entonces se redundaría en lo mismo, ya se realizaría un proceso de filtrado para unificar los datos. puesto que para el resultado de la información en esta etapa no nos interesa el dato de manera individual, sino que se sacan indicadores población mensual, bimensual, trimestral, semestral y anual, basándonos en los códigos de diagnósticos, procedimientos e intervenciones internacionales .

un ejemplo es, un informe que indique el los primeros 3 meses del año cuantos usuarios del servicio se enfermo de "dengue" en edades entre los 5 y 30 años del sexo femenino. es por ahí la cosa, pero no nos interesa saber quien se enfermo porque en las UNAP tienen el registro clínico del paciente y es al medico al que le interesa la información individual.

ya en lo adelante cuando se hagan las inversiones en conectividad podríamos analizar una estrategia para hacer una plataforma on-line que ayude a validar y crear bases de datos de usuarios del servicio y ademas ver información en tiempo real.

[[AzidRain]]

Entonces partimos de que cada registro no requiere ser identificado de manera única. Es decir no importa quien es el paciente sino sus datos.

[ivantech]

exactamente, siempre se redundaría ya que cada atención es única y para esto estoy analizando la posibilidad de crear un id de registro único que no se repita a nivel nacional (R.D.) para esto estoy pensando en utilizar el código de cada región que esta compuesto por sus siglas SRS0 al SRS8 entonces eso lo concatenaria con el código de la Gerencia de Área que no pasaría de 5 por Región, y luego el código estándar a nivel nacional registrado en la Oficina Nacional de Estadística de mi pais (Rep. Dom.) que es el código de la Provincia que va de 01 a 32, seguido de codigo de la zona de salud, seguido del código de de la atención que va de 0 a 6, seguido del código de la UNAP que va de 1 a N según la REGION, seguido de la fecha de la atención mas la hora de la atención obviamente descomponiendo la fecha y ordenándola en formato aaaammdd y la hora hhmmss sin puntos y backslah.

al final debería quedar asi. ej. SRS00101010100120100607223201

[SRS0] --> Código de la región de salud
[01] --> Código de la Gerencia de área
[01] --> Código de la provincia
[01] --> Código de la zona de salud
[01] --> Código de la Atención
[001] --> Código de la UNAP
[20100607] --> Fecha de la Atención
[223201] --> Hora de la atención

con este Id Único de Registro podría saber por esa combinación de donde proviene dicho registro, no nos interesa saber a quien fue que se le dio la atención, sino de donde proviene el dato y corregirlo, hasta donde se, este registro nunca se repetiría. ademas que cuando cargue la información en la oficina de la región este me permitiría poder ubicar dicho registro y al cargar puedo hacer 2 cosas primero si existe lo actualizo de lo contrario lo inserto como un nuevo registro. pudiera darse el caso que dicho usuario asista a una UNAP 3 veces el mismo día, pero nunca podrá asistir a la misma hora 3 veces.