Propuesta de integración · TrustCare para GHIPS
TrustCare acompaña al paciente desde que busca un especialista hasta que termina su recuperación. El contacto con GHIPS empieza cuando entra el especialista y se concentra cuando la clínica opera el caso. Este documento muestra ese recorrido, señala los nueve momentos de contacto y lista exactamente qué servicios de su API usaríamos y cuáles no.
01
Ocho etapas, y el contacto con GHIPS no empieza al principio. Mientras el paciente busca, se registra y paga su consulta todavía no ha elegido especialista ni clínica: no hay historia clínica que consultar, y no consultamos ninguna. Nuestra frontera con GHIPS se abre en dos zonas:
Los nueve pines naranjas marcan los momentos exactos de contacto.
02
Para cada punto: qué está pasando en ese momento, qué necesitamos de GHIPS, y con qué servicios de su API creemos que se resuelve.
El paciente ya eligió con quién hablar, y con ello quedó definida la clínica. A partir de aquí hay una historia clínica que consultar y una agenda real que respetar. Nota importante de alcance: no consultamos su directorio para poblar un buscador público. Consultamos la agenda del especialista que el paciente ya eligió, y solo los datos de ese paciente.
Apenas el especialista entra en la conversación, su caso deja de ser una exploración y pasa a ser un paciente de esa clínica. Es el momento correcto para verificar si ya existe en GHIPS y, si no, crearlo — antes de que haya que agendarle nada.
Tras la videoconsulta el especialista suele pedir una valoración presencial o exámenes previos. Si él agenda también en GHIPS, la disponibilidad que mostremos sin consultarlos estará incompleta y le ofreceremos al paciente horas ya ocupadas.
La cotización que recibe el paciente lleva un precio. Si la clínica ya tiene su tarifario cargado en GHIPS, ese valor debería salir de ahí en vez de teclearse, y así lo que el paciente compara es lo que la clínica efectivamente factura.
Es el punto de mayor valor inmediato, y sigue vigente durante todo el tratamiento. El paciente le pide a Aurora reprogramar su cita y no llama a la clínica; el personal la ve al instante en el sistema de clínicas. Si esa cita no baja a GHIPS, alguien tiene que copiarla a mano y el riesgo de choque de agenda es real.
Aquí está el grueso de la integración: cinco de los nueve puntos. Es el tramo en que hoy el personal de la clínica registra en el sistema de clínicas lo mismo que registra en GHIPS. Cada punto de esta zona elimina una de esas duplicaciones.
Es el servicio de mayor impacto de toda la lista. Mientras el caso avanza dentro de la clínica, el paciente quiere saber en qué va: si ya está programado, si falta la valoración pre-anestésica, si le toca firmar algo. Ese dato ya lo tiene GHIPS. Si podemos consultarlo, el caso avanza solo en el sistema de clínicas y el paciente ve su progreso actualizado — sin que nadie de la clínica tenga que mover el estado dos veces. Es la duplicación más costosa de todas, porque ocurre en cada transición.
El paciente firma electrónicamente el consentimiento informado, el habeas data y demás documentos desde la app, con validez legal. Ese PDF tiene que terminar archivado en GHIPS — si no, la clínica va a volver a pedirlo en papel el día de la cirugía y el trabajo digital no habrá servido de nada.
La valoración pre-anestésica depende de exámenes. Hoy le pedimos al paciente que los suba como archivo. Si la clínica los procesa en su propio laboratorio, ya están en GHIPS y podemos mostrárselos sin pedirle nada — y sabemos cuándo su proceso puede avanzar.
Cuando la clínica abre la atención del paciente, ese identificador se vuelve la llave de casi todo lo demás en GHIPS: archivador, formatos, resultados, notas. Sin él, los puntos P6 y P7 se quedan sin el parámetro que necesitan.
Al cerrarse el proceso le pedimos al paciente una reseña. Hoy eso lo dispara el especialista a mano; el egreso registrado en GHIPS es la señal más fiable de que el procedimiento efectivamente ocurrió y terminó.
03
La lista consolidada, agrupada por función. 40 servicios de los 334 que expone GHIPS. Treinta y tres son consultas; siete escriben, y de esos siete, cinco son citas del propio paciente y dos son documentos que él mismo firmó.
La columna «Punto» remite a la sección anterior: P1 a P4 son la zona A (conversación con el especialista) y P5 a P9 son la zona B (la clínica operando el caso en el sistema de clínicas).
| Servicio | Para qué | Punto | Tipo |
|---|---|---|---|
| Acceso | |||
| GET api/login/echoping | Verificar conectividad | — | Consulta |
| POST api/login/authenticate | Obtener token | — | Consulta |
| Catálogos y directorio | |||
| GET api/Sedes · GET api/SedesID?id= | Sedes activas | P2 | Consulta |
| GET api/ServiciosById?id= | Servicios por sede | P2 | Consulta |
| GET api/EspecialidadesServicioById?id= | Especialidades por servicio | P2 | Consulta |
| GET LeonCitas/GetAllSedes | Sedes del módulo de agenda | P2 | Consulta |
| GET LeonCitas/GetAllTipoCitaBySede/{IdSede}/{Particular} | Tipos de cita | P2 | Consulta |
| GET LeonCitas/GetTipoDocuentos | Tipos de documento | P1 | Consulta |
| GET LeonCitas/GetEstadosCivil · GetNacionalidades | Catálogos para crear el paciente | P1 | Consulta |
| GET Festivo/GetFestivosDesdeEsteMes/{mes}/{ano} | Días no hábiles | P2 | Consulta |
| GET CupsPorFormato/ConsultarTodos | Catálogo CUPS | P3 | Consulta |
| GET ConsultarDiagnostico/{descripcion} | Catálogo de diagnósticos | P3 | Consulta |
| Pacientes | |||
| POST LeonCitas/VerificarPaciente · VerificarPacienteParticular | Ver si ya existe | P1 | Consulta |
| GET api/ConsultarPaciente | Datos del paciente | P1 | Consulta |
| POST LeonCitas/RegistrarPacienteNuevo | Crear paciente | P1 | Registra |
| Disponibilidad y agenda | |||
| POST LeonCitas/GetAllMedicosDisponibles | Profesionales con agenda | P2 | Consulta |
| POST LeonCitas/GetProfesionalesConCitasDisponibles | Profesionales con cupo a 30 días | P2 | Consulta |
| POST LeonCitas/GetAllHorariosDisponibles | Horas libres | P2 | Consulta |
| POST LeonCitas/GetAgendasDisponibles | Agendas disponibles | P2 | Consulta |
| POST LeonCitas/GetDiasConDisponibilidad | Días con cupo en el año | P2 | Consulta |
| GET LeonCitas/ObtenerValorServicioParticular/{IdSede}/{Cups}/{Institucional} | Tarifa particular | P3 | Consulta |
| Citas | |||
| POST LeonCitas/GenerarCitaPaciente | Agendar | P4 | Registra |
| POST LeonCitas/GetAllCitasPendientesByPaciente | Citas pendientes | P4 | Consulta |
| GET Rutas/GetCitasActivasPaciente/{Documento}/{Tipo} | Citas activas | P4 | Consulta |
| POST LeonCitas/CancelarCitaPaciente | Cancelar | P4 | Modifica |
| POST LeonCitas/ReprogramarCitaPaciente | Reprogramar | P4 | Modifica |
| Proceso quirúrgico | |||
| GET Ticorange/GetEtapa/{numeroIdentificacion}/{tipoIdentificacion} | Etapa actual del caso | P5 | Consulta |
| GET api/GetEncabezadoHospitalizacionDatosPaciente?atencionId= | Datos de la atención | P8 | Consulta |
| POST api/Admision/RegistrarAtencionRapida | Abrir atención | P8 | Solo si lo prefieren |
| GET Informes/ConsultarEgresos/{Sede}/{FechaInicial}/{FechaFinal} | Egresos | P9 | Consulta |
| Documentos y resultados | |||
| POST Files/GuargarConsentimientoInformado | Archivar consentimiento firmado | P6 | Registra |
| POST Files/GuardarEnArchivadorv2 | Archivar sin atención asociada | P6 | Registra |
| GET Files/GetReporteByFormatoId/{IdPacienteAtencion}/{Formato} | Leer formato de atención | P6 | Consulta |
| GET LeonCitas/GetResultsLaboratoriosDisponibles | Resultados de laboratorio | P7 | Consulta |
| GET LeonCitas/GetResultsAyudasDxDisponibles | Ayudas diagnósticas | P7 | Consulta |
| GET LeonCitas/GetReporteLaboratorio/{IdPacienteAtencion}/{Numero} | PDF de laboratorio | P7 | Consulta |
| GET LeonCitas/GetReporteAyudaDx/… | PDF de ayuda diagnóstica | P7 | Consulta |
Conviene decirlo explícitamente: el 88 % de su API queda fuera de nuestro alcance y no pedimos acceso a nada de esto.
| Grupo | Servicios | Por qué no lo necesitamos |
|---|---|---|
| Activos | 78 | Inventario, traslados, compras y proveedores de farmacia |
| GhipsLite | 55 | Dispensación, kardex y recepción de medicamentos intrahospitalaria |
| Financiero · Crue · RPA · Tableau · Informe | 29 | RIPS, facturación, reportes gerenciales y de gestión |
| Mipres · MedicamentosGrupoAfin | 9 | Prescripción y dispensación de medicamentos |
| Hospitalizacion · Encabezados · NotasEvolucion · RondasInterconsultas | 9 | Operación de piso y hospitalización |
| SignalR · Mirth · Prodiagnostico · Configuration | 15 | Mensajería interna, interoperabilidad HL7 e integraciones de terceros |
| Autorizaciones · Aseguradoras · otros módulos de agenda y grupos menores | 99 | Autorizaciones de EPS (el procedimiento es particular), agendas alternativas, docencia, turnos, SSTDC, Calipsu, Livinglab |
Su documentación expone seis módulos de agendamiento distintos — LeonCitas, Telemed, BonnetCitas, CocoCitas, CeroCitas y DonDoctor — con modelos de datos que no parecen intercambiables. Todo este documento asume LeonCitas por ser el más completo, pero es una suposición nuestra. Necesitamos que nos confirmen cuál usa esta clínica; si es otro, reharemos el mapeo sobre el módulo correcto.
04
Toda la información que viaja por TrustCare va cifrada, de extremo a extremo del recorrido: entre el paciente y nosotros, entre nuestros servicios, y entre nosotros y GHIPS. Las credenciales que ustedes nos entreguen quedan cifradas en reposo y nunca salen del servidor.
TrustCare no es un sistema de historia clínica y no aspira a serlo. La historia clínica del paciente es de la institución y vive en GHIPS; nosotros no la replicamos ni construimos un repositorio paralelo. Ese es precisamente el papel que le corresponde al software clínico, y la razón por la que preferimos consultarles a ustedes antes que acumular información de nuestro lado.
Cuando un dato clínico existe en GHIPS, esa es la copia buena. Nosotros lo mostramos, no lo poseemos. Es una decisión de diseño de la integración y estamos dispuestos a dejarla escrita en el acuerdo de tratamiento de datos, incluyendo el compromiso de no persistir resultados clínicos consultados a través de su API.
HTTPS entre el paciente y nosotros, y HTTPS entre nosotros y GHIPS. Ningún dato clínico viaja en claro en ningún tramo del recorrido.
El usuario, la contraseña y cualquier clave que nos entreguen se guardan cifrados en base de datos y se descifran solo en el momento de usarlos. Nadie de nuestro equipo las lee en texto plano.
Ni la app del paciente ni el sistema de clínicas reciben o ven las credenciales de GHIPS. Las sesiones usan cookies seguras que el navegador no puede leer, y toda llamada a GHIPS se origina en nuestro servidor.
Los mensajes automáticos entre nuestros propios servicios van firmados criptográficamente (HMAC-SHA256) y se rechazan si la firma no coincide. Aplicaremos el mismo criterio a cualquier canal que definamos con ustedes.
40 servicios de 334, y solo los datos del paciente que ya eligió a un especialista de esa clínica. No poblamos un buscador con su directorio, no consultamos censos ni listados masivos, y no accedemos a pacientes ajenos al proceso. Lo clínico se consulta, no se acumula.
Un único punto de salida con IP fija. Revocar credenciales o retirar la IP de su lista blanca corta el acceso por completo, de inmediato y sin efectos colaterales en su sistema.
Sobre el tratamiento de datos personales quedamos atentos a firmar el acuerdo que la institución requiera, definiendo qué información podemos almacenar de nuestro lado, por cuánto tiempo y bajo qué condiciones se elimina. El paciente ya firma su autorización de habeas data dentro de TrustCare y podemos compartir ese registro.
05
Con los cuatro primeros puntos ya podemos escribir código y mostrarles algo funcionando. El resto se puede resolver sobre la marcha.
Idealmente contra una base que no sea la de producción, con al menos un paciente de prueba de documento conocido y una agenda con cupos libres. Si no existe ambiente de pruebas, díganlo y planteamos alternativas.
Es la definición que más determina el trabajo. Si son varios según la sede, necesitamos la correspondencia sede → módulo.
Si hay lista blanca de IP, VPN o certificado de cliente. Salimos desde una dirección fija, así que darla de alta es sencillo — solo necesitamos saberlo antes de desplegar.
Alguien a quien escribirle cuando una respuesta no coincida con lo esperado. Nos ahorra días a ambos lados.
Cuánto dura, cómo se renueva, si puede viajar en la cabecera Authorization y qué significa el campo Encrypt del login. Notamos que varios servicios lo reciben como segmento de la URL; preferiríamos cabecera, porque las URLs quedan registradas en los intermediarios de red. Si no es posible, lo manejamos sin registrar esas rutas.
IdSede, IdServicio, IdEspecialidad, IdAgenda, tipos de cita, tipos de documento y CUPS. Basta una entrega inicial más una forma de refrescarlos; sin ellos no podemos armar ni una sola llamada real.
La documentación pública detalla muy bien los cuerpos de petición, pero deja casi todas las respuestas en blanco. Un ejemplo real por servicio, y saber qué devuelven ante «paciente no existe», «sin cupo disponible» y «no autorizado», nos evita adivinar.
La lista cerrada de etapas y qué significa cada una. De esto depende por completo el punto P5, que es el que le ahorra a su personal mover el estado del caso dos veces.
No encontramos un mecanismo por el que GHIPS nos avise de un cambio. Si existe, nos interesa mucho. Si no, propongamos consulta periódica y acordemos frecuencia y volumen aceptables — no queremos generarles carga innecesaria. Un servicio de «cambios desde tal fecha» sería la solución más eficiente para ambos.
Si nuestra petición de agendamiento se corta después de que ustedes ya la procesaron, el reintento podría crear dos citas. ¿Aceptan una clave de idempotencia, o preferimos acordar una regla de deduplicación por paciente, agenda y hora?
FechaCita, HoraInicial y HoraFinal viajan como texto. Confirmarnos que son hora local de Colombia y su formato exacto evita desfases que el paciente vería directamente en su cita.
Si la clínica mueve una cita en GHIPS y el paciente la mueve desde la app, ¿cuál prevalece? Preferimos acordarlo antes de que ocurra. Nuestra propuesta por defecto: GHIPS es la fuente de verdad y nosotros nos ajustamos.
Todo lo anterior se construyó leyendo la documentación pública de GHIPS 44.6. No hemos ejecutado ninguna llamada real contra su API, así que los mapeos son por nombre y descripción, no por comportamiento observado. Es muy probable que en la primera sesión técnica corrijamos varios: lo damos por descontado y preferimos llegar con una propuesta concreta que con preguntas abiertas.