La noche después de visitar la consulta fue una de esas noches en las que en realidad no quieres hacer nada más. Estaba en casa, con un cuaderno delante en el que por la mañana había ido apuntando rayitas. ¿Cuántas veces buscó Mala una ficha? ¿Cuántas veces copió el mismo número de teléfono? ¿Cuántas veces tuvo la doctora que escribir dos veces una frase de la receta porque el primer papel no se leía en la farmacia?
Soy prudente con los números cuando no los he medido bien, y estos no los medí bien. Fueron tres horas de observación, un lápiz y mi intuición. Pero la intuición era clara. A lo largo del día, en esa consulta pequeña se iban varias horas en tareas que un ordenador resuelve en segundos: buscar, copiar, cuadrar, reescribir. Varias horas, cada día, pagadas a alguien que en realidad está ahí para otra cosa.
Por qué no comprar algo y ya
Fue mi primera reacción, y es la correcta. En veinte años he aprendido que construir software propio es casi siempre la respuesta más cara a un problema. Así que miré qué había. El mundo del software para consultas se puede dividir a grandes rasgos en tres tipos, al menos tal como lo viví entonces.
El primer tipo es demasiado grande. Son sistemas para clínicas con departamento de informática, con formaciones y proyectos de implantación de meses. Para tres médicos y una recepcionista, es como comprar un camión para ir por pan.
El segundo tipo es demasiado viejo. Programas que alguna vez fueron buenos, pero cuya pantalla parece que nadie la ha tocado en quince años, y de los que uno se pregunta quién los mantiene todavía.
El tercer tipo es bueno, pero de otro mundo. Los productos modernos en la nube suelen ser excelentes, pero están hechos para un mercado que no es el de esa consulta: otra moneda, otros formatos de impuestos, otro internet. Lo conté con detalle en mi comparación con Cliniko, así que no quiero repetirlo aquí. Solo diré que no descarté esos productos por malos. Los descarté porque estaban hechos para otras salas.
La regla que me puse
Antes de escribir la primera línea de código, apunté una regla: solo construyo lo que en esa consulta se usa todos los días. Nada que solo quede bonito. Nada que construya solo porque puedo.
Suena obvio. En realidad es la disciplina más difícil que conozco, porque uno, como desarrollador, tiene ideas constantemente. Un panel con gráficos bonitos. Una función de recordatorios. Una estadística. Puse todas esas ideas en una lista que llamé “más adelante” y no la toqué hasta que lo diario funcionó.
Lo diario eran, según mis rayitas, cinco cosas.
Lo primero que construí
El paciente. Un formulario con lo que Mala ya pregunta por teléfono de todos modos: nombre, fecha de nacimiento, sexo, teléfono, dirección. Y cosas que una doctora quiere saber antes de recetar: grupo sanguíneo, alergias, antecedentes. Estuve dándole vueltas a si las alergias debían ser un campo propio o parte de los antecedentes. Me decidí por un campo propio, porque no quería que se perdieran entre veinte líneas de texto.
La cita. Una cita pertenece a un paciente y a un médico, tiene fecha, hora, un tipo (por ejemplo consulta o control) y un estado. En la pantalla de inicio está la lista de las citas del día. Parece banal, pero esa lista es la que Mala copiaba cada mañana de la agenda.
La consulta. Es el núcleo. La doctora anota qué tiene la paciente, qué molestias y síntomas hay, qué diagnostica, qué receta, si recomienda análisis y cuándo debe volver. Todo cuelga de la cita y de la paciente.
El laboratorio. Una solicitud de análisis, un estado, un resultado. Nada más. Pero sustituye al montón de fotos que llegaban por el mensajero de la consulta.
La factura. Una factura tiene partidas de consulta, medicamentos, laboratorio y otros, un descuento, un total, el importe pagado, la forma de pago y un estado. A eso se suma una lista sencilla de farmacia con existencias, mínimo y fecha de caducidad, porque la consulta dispensa algunos medicamentos ella misma.
Eso es todo. Nada de milagros, pero es lo que realmente sucede en un día normal.
Por qué una aplicación de escritorio
La pregunta que me hace todo desarrollador: ¿por qué no una aplicación web? Sería hoy el camino natural. La respuesta tiene que ver con la consulta, no conmigo.
Una aplicación web necesita un servidor y una conexión a internet. Quien maneja el servidor tiene que mantenerlo, respaldarlo, actualizarlo. Una consulta pequeña no tiene a nadie para eso. Quien lo alquila entrega los datos de los pacientes, y justo eso no quería la doctora. Y cuando el internet se cae, todo se detiene.
Así que construí un programa de Windows que funciona sin internet. Los datos están en un único archivo SQLite en el ordenador de la consulta. Por dentro es VB.NET, y la pantalla es una vista web dentro de la ventana de Windows, porque así consigo más rápido un aspecto limpio. Para la consulta solo significa: abrir el programa, trabajar, copiar el archivo.
Tiene un precio y no quiero ocultarlo. Un programa local significa que la consulta es responsable de sus copias de seguridad. Varios ordenadores usando los mismos datos a la vez es más difícil que en una solución en la nube. Y alguien tiene que instalar las actualizaciones. Pesé esas desventajas contra la ventaja de que la consulta pueda seguir trabajando aunque la luz parpadee y la red se vaya, y me quedé con el programa de escritorio. Para otra consulta la cuenta puede salir distinta.
Lo que me sorprendió
Pensaba que los mayores desafíos serían técnicos. Apenas lo fueron. Las mayores sorpresas vinieron de Mala y de la doctora.
Mala quería que al crear una cita se viera al instante si la paciente ya había venido antes. Yo no lo había previsto. Era un deseo pequeño, pero me mostró en qué se fija alguien que sujeta el teléfono entre el hombro y la oreja. Lo puse en la lista.
La doctora quería fijar la fecha de la próxima revisión directamente en la consulta, no en una ventana de citas aparte. Dijo: “Si lo escribo donde de todos modos escribo, no se me olvida.” Por eso hay un campo para eso en la consulta.
Lo que más me impresionó: casi nunca me dijeron qué les gustaba. Me dijeron qué estorbaba. Es la mejor información que se puede recibir, y aprendí a fijarme en los suspiros, no en los cumplidos.
Las semanas en que dudé
Hubo una fase, más o menos después del primer mes, en la que pensé en serio en tirarlo todo. No porque técnicamente no se pudiera, sino porque me hice la más honesta de las preguntas: ¿quién necesita en realidad otro software para consultas?
Hay decenas. Algunos son muy buenos. Durante dos semanas tuve la sensación de estar reinventando una rueda que ya es perfectamente redonda. Por las noches me sentaba con las líneas de código delante y pensaba: podrías haberle recomendado a la doctora una suscripción y el asunto estaría resuelto.
Lo que al final me mantuvo no fue una gran meta, sino una observación pequeña y poco romántica. Cada vez que pasaba por la consulta, la agenda seguía sobre la mesa, pero Mala miraba cada vez más a menudo primero la pantalla. No porque yo la empujara, sino porque la lista de ahí era más rápida. Es una frase que me quedó grabada: nadie cambia por un buen argumento, la gente cambia porque algo es más fácil.
Lo que decidí no construir
Una lista de lo que no está dice más de un producto que una lista de lo que está. Esta es la mía.
No incluí inteligencia artificial que proponga diagnósticos. Se pide a menudo, y me parece una mala idea en un programa que construye un solo desarrollador y que no puede validar clínicamente. Un error ahí no sería un defecto estético.
No incluí una base de datos de medicamentos con control de interacciones. El texto de la receta en la consulta es un campo de texto. La doctora escribe lo que receta. El programa no piensa con ella, y no quiero presentarlo de otro modo. Una base de medicamentos revisada es un proyecto de varios años con especialistas, no algo que se añada de paso.
No construí cuentas de usuario con roles y permisos en el sentido de los sistemas grandes. Para tres médicos y una recepcionista que se conocen, no era el problema más urgente. Para una consulta mayor lo sería, y entonces tendría que ponerme al día.
Y no construí conexión con aseguradoras. En esa consulta la mayoría de los pacientes paga de su bolsillo, y cada conexión sería un país distinto con reglas distintas.
Una mañana con el programa
Imagina que son las ocho y media. Mala enciende el ordenador y abre el programa. En la pantalla de inicio están las citas del día, ordenadas por hora. La primera es un control, la segunda un paciente nuevo.
El paciente nuevo entra. Mala lo da de alta: nombre, fecha de nacimiento, teléfono, una frase sobre alergias que él menciona al preguntarle. Lleva un minuto. La doctora abre la cita, anota las molestias, escribe el diagnóstico, teclea la receta y fija la fecha del control. Si quiere un análisis de sangre, crea una solicitud de laboratorio.
Al final el paciente vuelve a sentarse con Mala. Ella emite la factura: consulta, medicamentos, laboratorio, quizá un descuento, pago en efectivo o de otra forma. Listo.
Nada de eso es espectacular, y ese es el punto. Como desarrollador, a veces uno desearía que alguien dijera “guau”. Aquí sería mala señal. Cuando el software es bueno, nadie dice nada. Simplemente está ahí, y la mañana pasa más rápido.
Lo que todo esto me costó
Quiero ser sincero con el tiempo y el esfuerzo, porque creo que aquí muchos desarrolladores lo adornan.
Un programa como este no es cosa de un par de fines de semana. La primera versión que se puede enseñar está en pocos días. La versión en la que alguien se apoya cada día lleva meses, y sobre todo exige la paciencia de ir una y otra vez a la consulta, mirar y tirar cosas que uno creía inteligentes. He pasado más tiempo observando que programando, y lo volvería a hacer así.
Además, hay responsabilidad. Cuando una consulta confía sus citas y sus historias a un programa, un fallo ahí ya no es un juego. Por eso aprendí a ser cauto con las promesas, y me acostumbré a decir, en cada texto como este, lo que no funciona.
Lo que aún falta, y por qué no lo escondo
ClinicPlusPlus no está terminado. No lo escribo por modestia, sino porque es verdad.
Algunas pantallas todavía son prototipos. El inicio y los informes aún no están conectados en todas partes a los datos reales. No hay copia de seguridad automática, solo copiar el archivo a mano. Una factura conforme a la normativa fiscal de la India, con GST, está en mi lista y todavía no está construida. Los pacientes no pueden reservar en línea y no hay recordatorios por SMS. Tampoco existe aún una protección automática contra citas duplicadas; escribiré sobre eso en una entrada aparte.
Quien necesite una solución terminada no debería esperar a mi programa, sino mirar los productos maduros. Lo digo en serio.
Lo que me llevo
Mirando atrás, la frase más importante de toda esta historia no fue técnica. Fue la pregunta que me hice aquella noche del cuaderno: ¿estoy resolviendo un problema que alguien tiene de verdad, o construyo algo porque puedo?
No sé si ClinicPlusPlus acabará siendo un gran producto. Sé que empezó con un problema que vi con mis propios ojos, y que cada función que lleva está ahí porque alguien la necesita a diario. Es un buen comienzo, aunque no sea un final.
Si diriges una consulta y te reconoces en alguna parte de esta historia, escríbeme. Me interesa menos si te gusta el programa que saber qué te estorba a ti.
Esta entrada describe el estado del desarrollo en el momento de su publicación.