Era marzo de 2025, más o menos. En España, Kit Digital ofrecía ayudas financiadas por la Unión Europea para que pequeñas empresas y autónomos pudieran incorporar herramientas digitales. La clínica tenía un CRM nuevo. Años de historiales de pacientes seguían en papel.
Trabajaban allí tres dentistas a jornada completa, cada uno con una persona de apoyo. El CRM gestionaba citas, historiales, seguimiento comercial y comunicación con los pacientes. Querían tener también los historiales anteriores en ese mismo sistema.
El archivo reunía información de unos 800 pacientes en unas 3000 hojas, muchas escritas por las dos caras. Algunas se leían bien. Otras tenían la letra que te puedes imaginar después de años de dentistas tomando notas.
Cuando contactaron conmigo, el equipo auxiliar ya había empezado a pasar los historiales al CRM a mano. Leer las notas, teclearlas, comprobarlas. Siguiente hoja. Todo eso, además de su trabajo con los dentistas.
Ahora que sabemos dónde duele...
...toca buscar una solución.
Tuvimos una reunión. El dueño me explicó el problema y con qué recursos contaba. Tres auxiliares conocían los historiales, sabían a qué paciente correspondían y podían dedicar tiempo al archivo entre citas o en ratos reservados para ello.
Con eso pude concretar qué necesitaba la solución:
- Encajar con el trabajo diario del equipo en la clínica.
- Reducir el tecleo, incluso cuando la letra fuera demasiado mala para el OCR.
- Permitir que el equipo revisara y corrigiera cada entrada antes de incorporarla al historial del paciente.
- Generar datos que el CRM existente pudiera importar.
- Poder construirse rápido y ser fácil de usar para esas tres personas. Había un archivo que terminar.
Volví con tres estrategias y una recomendación.
- Me encargo yo de la transcripción y preparo los archivos para importar. Quitaría trabajo al equipo, pero la clínica seguiría teniendo que ayudar con las notas difíciles de leer y la identificación de pacientes. Ya tenían personas que conocían el archivo y tiempo para dedicarle.
- El equipo sigue introduciendo todo a mano. No hay que desarrollar nada, pero sigue tocando teclear cada hoja. Las notas ya estaban escritas. Hacer que alguien volviera a escribirlas enteras me parecía una mala forma de aprovechar su tiempo.
- Creo una herramienta sencilla para fotografiar o dictar las notas y revisar el texto antes de importarlo. Requería algo de desarrollo al principio, pero aprovechaba el equipo y el tiempo disponibles en la clínica y evitaba buena parte del tecleo.
Recomendé la tercera. El equipo podía aprovechar su conocimiento de los historiales para revisar el texto y asignarlo al paciente correcto. La aplicación se encargaría de la transcripción. Y el dictado permitiría resolver las notas que el OCR no consiguiera leer.
El dueño tenía opciones y mis razones para decidir. No tenía que inventarse cómo debía funcionar la aplicación. Yo definí los requisitos, escribí la especificación, diseñé cada paso que seguiría el equipo y la desarrollé.
Si estás leyendo esto, seguramente ya te imaginas qué opción eligió.
Creé una aplicación web en React para usar desde el navegador del móvil, con tres cuentas de personal y sin registro público. Esas tres personas eran todos sus usuarios.
La aplicación ofrecía dos formas de introducir un documento.
Haz una foto
Una persona del equipo fotografiaba la hoja y subía la imagen. El OCR de Google leía las notas manuscritas en español y devolvía el texto con sus puntuaciones de confianza.
Fijamos un umbral del 88% de confianza para decidir el siguiente paso. Por debajo, la aplicación proponía dictar. A partir del 88%, el texto pasaba a revisión. La puntuación nunca sustituía la comprobación de la información médica por parte del equipo.
Léelo en voz alta
Cuando el OCR no podía con la letra, la persona leía las notas en voz alta y Google Speech-to-Text V2 transcribía la grabación. Si podía descifrar la letra, podía dictarla en vez de teclearlo todo.
Ambas vías acababan en una revisión con las correcciones necesarias. La aplicación generaba archivos JSON o CSV para importar, y el equipo asignaba cada entrada al paciente correcto en el CRM.
Hoja a hoja, hasta terminar
Desarrollé la aplicación en 11 días laborables. El equipo procesó el archivo en otros 27 días laborables. En total, 38 días laborables entre el desarrollo y la digitalización.
De las 3000 hojas del archivo:
- 1920 pasaron por OCR, el 64%.
- 750 se dictaron, el 25%.
- 330 quedaron fuera de la importación al CRM, el 11%.
Con algunas de aquellas letras, que el 64% pasara por OCR fue más de lo que esperaba.
El resultado fueron 2670 hojas transcritas, revisadas e importadas al CRM por el propio equipo de la clínica, compaginándolo con su trabajo habitual. No tengo una cifra fiable de horas ahorradas. Lo que sí puedo dar son el volumen procesado y el tiempo que llevó. Las decisiones sobre qué hacer con el archivo físico quedaban fuera de mi trabajo.
La aplicación ya no se usa. Hizo su trabajo y se jubiló. Sinceramente, bien por ella :)
Por eso me gusta tanto este proyecto. Tres personas, una pila de papeles y un problema concreto que podía quitarles de encima. Sabía para quién estaba construyendo, con qué contaban y qué tenía que pasar para darlo por terminado.
No tenía que imaginarme un millón de futuros usuarios. Todos mis usuarios cabían alrededor de una mesa. Podía dedicar el tiempo a lo que de verdad les ayudaría, como descifrar la mala letra y revisar los resultados antes de importarlos.
Y entonces llegaron al final del archivo. Ya está. Se acabó el papel con el que alimentar la aplicación. Hay algo bonito en crear un programa que consigue dejar de hacer falta. Haría más proyectos así encantado.