Imaginá un consultorio chico en una mañana ajetreada. Un laboratorio manda los resultados en un PDF por mail. Un equipo del propio consultorio imprime una tira con números. La recepcionista abre la ficha del paciente y carga los valores uno por uno, entre llamados y gente en el mostrador. La mayoría de las veces sale bien. El día que no, un valor queda en el campo equivocado, o en la ficha de otro paciente, y nadie se entera hasta que un médico toma una decisión con ese dato.
Nadie en esa historia es descuidado. El descuidado es el proceso. Volver a tipear es un paso manual en medio de información que importa, y los pasos manuales fallan en el peor momento: cuando hay más trabajo.
Por qué volver a tipear resultados es más riesgoso de lo que parece
Hay tres riesgos distintos escondidos en esa rutina:
- Errores de tipeo. Una coma en el lugar equivocado, un dígito cambiado, una unidad que se pierde.
- Paciente equivocado. El PDF dice un nombre, la pantalla muestra otro parecido, y el resultado termina en la ficha que no es.
- Ningún rastro. Semanas después, nadie puede decir quién cargó el valor, cuándo, ni si alguien lo comparó con el original.
Cada uno es chico. Juntos significan que el consultorio depende de la memoria y la atención de las personas, y eso es justamente lo que se agota en un día cargado.
Qué significa "integración" en la práctica
No hace falta aprender ningún estándar para tener esta conversación. En términos simples, conectar un laboratorio o un equipo con el sistema del consultorio significa que el resultado viaja de su sistema al tuyo sin que una persona lo copie. Hay algunas formas comunes:
- Archivos. El laboratorio o el equipo deja un archivo estructurado en un lugar compartido, y tu sistema lo toma y lo lee. Es simple y frecuente, pero el formato tiene que acordarse de antemano.
- Mensajes. Los sistemas de salud intercambian resultados desde hace mucho con mensajes estándar. HL7 es la organización detrás de los estándares de mensajería en salud más conocidos, y esos mensajes son una forma definida de decir "este resultado pertenece a este paciente y a este pedido".
- APIs. Un enfoque más nuevo, donde tu sistema le pide los resultados al otro por internet, o los recibe a medida que están listos. El estándar FHIR de HL7 se describe como "un estándar para intercambiar información de salud por medios electrónicos" y está pensado para este tipo de intercambio.
Cuál se usa depende de lo que ofrezca tu laboratorio o el proveedor del equipo. Un sistema a medida normalmente puede trabajar con cualquiera de ellos. Lo que importa no es la tecnología, sino lo que pasa alrededor.
La parte difícil: asignar el resultado al paciente correcto
La decisión de diseño más importante es cómo encuentra un resultado a su paciente. El nombre es una mala clave: dos pacientes pueden llamarse igual, un nombre se puede escribir de tres maneras y la gente cambia de apellido. Un sistema bien hecho asigna por un identificador (un número de paciente que asigna tu consultorio, o el número de documento) que ambas partes acuerdan, idealmente combinado con una segunda verificación, como la fecha de nacimiento.
Cuando los identificadores no coinciden, el sistema no debería adivinar. Tiene que dejar el resultado en una cola de "requiere revisión", donde una persona lo mira y decide. Parece trabajo extra, pero es lo contrario: la persona solo ve los casos raros, en vez de manejar a mano cada resultado.
Cómo se ve un buen manejo de errores
Las conexiones reales fallan. El servidor del laboratorio está caído, un archivo llega a medio escribir, llega un resultado de un paciente que todavía no existe en el sistema. Un sistema cuidadoso lo prevé:
- Nunca descarta en silencio un resultado. Todo lo que no puede procesar va a una lista visible.
- Guarda el original tal como llegó, junto a los valores interpretados, para que cualquiera pueda comparar uno con el otro.
- Registra el historial: cuándo llegó el resultado, qué se hizo con él, quién lo revisó.
- Marca lo que se ve raro, como un valor sin unidad o un resultado corregido que reemplaza a uno anterior, en lugar de pisarlo sin avisar.
- Avisa a alguien cuando no llegó nada de una fuente que normalmente manda algo todos los días.
Nada de esto es exótico. Es la diferencia entre una conexión que funciona en un buen día y una en la que se puede confiar.
Qué preguntarles a tu laboratorio y a los proveedores de equipos
Antes de empezar cualquier trabajo técnico, unas pocas preguntas ahorran semanas:
- ¿De qué maneras pueden entregarnos los resultados: archivos, mensajes, una API? ¿Hay documentación escrita que le podamos pasar a nuestro desarrollador?
- ¿Qué identificador del paciente usan, y puede ser el que ya usamos nosotros?
- ¿Cómo envían las correcciones y los resultados modificados?
- ¿Qué podemos usar para probar la conexión sin datos reales de pacientes?
- ¿A quién llamamos cuando dejan de llegar resultados?
Algunos proveedores responden las cinco en una página. Otros no sabrán. Las dos respuestas te dicen algo sobre cómo va a ir el proyecto.
Por dónde empezar
No hace falta conectar todo de una vez. Elegí la fuente que más re-tipeo genera, normalmente el laboratorio que más usás, y fijate qué puede enviarte. Contá cuántos resultados volvés a tipear en una semana normal y cuántas veces alguien tiene que volver a revisar uno. Ese número es el argumento para el proyecto, y las respuestas del proveedor a las cinco preguntas te dicen qué tan grande es.
La información de salud es sensible, y las reglas sobre cómo debe guardarse y protegerse dependen de dónde operes. Un profesional calificado debería confirmar qué aplica en tu caso. La parte de software, llevar resultados de un punto a otro con exactitud, con rastro y con una persona involucrada solo cuando hace falta, es algo en lo que puedo ayudarte a pensar.