FHIR

Buscar citas (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Agenda una cita enviada por un integrador (FHIR create)

Un HIS externo agenda en la plataforma desde su sistema — CR-449. La cita que sale de aquí es una cita **normal**: la misma fila, en la misma agenda, con el mismo estado inicial que si la hubiera tecleado la recepcionista. No hay marca de «venida de fuera» ni tabla aparte, porque el médico no atiende integraciones, atiende pacientes, y una cita que se comportara distinto según por dónde entró sería una trampa esperando a que alguien la pise. Por eso se le exigen **las mismas reglas**, que ahora viven en `app.services.appointment_rules` y las comparte con el portal: horario del consultorio, solapamientos y una cita por paciente y día. Un integrador no tiene una interfaz que le ofrezca sólo huecos válidos, así que aquí es donde tienen que aplicarse.

Requiere: PartnerApiKey, PartnerBearer

Consultar una cita (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Buscar reclamaciones (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Consultar una reclamación (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Buscar condiciones clínicas (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Consultar una condición clínica (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Buscar coberturas de seguro (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Consultar una cobertura de seguro (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Buscar informes diagnósticos (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Consultar un informe diagnóstico (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Consultar un encuentro clínico (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Buscar episodios asistenciales (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Consultar un episodio asistencial (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Buscar facturas (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Consultar una factura (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Buscar prescripciones de medicamentos (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Consultar una prescripción de medicamento (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Buscar observaciones (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Consultar una observación (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Consultar una organización (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Buscar pacientes (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Registra un paciente enviado por un integrador (FHIR create)

La primera escritura FHIR de la plataforma. Se autentica como INTEGRADOR —token OAuth o clave de socio—, no como usuario: quien escribe aquí es un sistema, y la institución no la elige él sino la que tiene ligada su credencial. Eso cierra de raíz la pregunta de en qué institución cae el paciente. Devuelve **201 si lo creó y 200 si ya existía**, que es la diferencia que un cliente necesita para saber si su reintento llegó tarde o si estaba duplicando de verdad. En los dos casos el cuerpo es el mismo recurso, para que dé igual por cuál de las dos entró.

Requiere: PartnerApiKey, PartnerBearer

Consultar un paciente (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Consultar un profesional sanitario (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Consultar una solicitud de servicio (FHIR)

Requiere: PartnerApiKey, PartnerBearer

Lista las suscripciones de este integrador (FHIR search)

Las suyas y sólo las suyas: mismo integrador y misma institución. No admite parámetros de búsqueda porque no hay nada más que filtrar — el conjunto ya está acotado por la credencial— y declarar uno que se ignorase sería la mentira de siempre.

Requiere: PartnerApiKey, PartnerBearer

Suscribe a un integrador a los cambios de su institución (FHIR create)

Crea la suscripción y devuelve el recurso, con el secreto de firma dentro. **EL SECRETO SALE AQUÍ Y EN NINGÚN OTRO SITIO.** Viaja como extensión (`.../subscription-signing-secret`) y no aparece ni en el `GET` ni en el Bundle. El razonamiento es el mismo que ya está escrito en `create_webhook`: en almacenamiento el secreto queda en claro porque con él se FIRMA —no se verifica—, y no hay forma de volver a enseñarlo en una lectura sin exponerlo en cada listado. **Sin él, el receptor no puede verificar la firma de las notificaciones** y lo único que le queda es darse de baja y volver a suscribirse. La única excepción es el reintento con la misma `Idempotency-Key`, que devuelve el mismo recurso con el mismo secreto. No es una segunda oportunidad para leerlo: es que un cliente cuya conexión se cortó a mitad de la respuesta no tiene otro camino, y ese reintento exige exactamente las mismas credenciales que crearon la suscripción. **El destino se valida igual que un webhook**, con `webhooks.validate_destination`: HTTPS obligatorio y nada que resuelva a una dirección interna. Es la misma función y no una copia de sus reglas, porque un integrador es tan capaz como un administrador de apuntar la notificación a `169.254.169.254`, y dos implementaciones de la misma defensa se separan.

Requiere: PartnerApiKey, PartnerBearer

Consulta una suscripción y su estado de entrega (FHIR read)

El recurso, con el estado que refleja si está entregando o en error. El `status` no se lee de una columna: se calcula con la última entrega. Ver `fhir_subscription.estado_derivado` para por qué.

Requiere: PartnerApiKey, PartnerBearer

Cancela una suscripción (FHIR delete)

Cancela: deja de encolar entregas, pero **la fila no se borra**. `status` pasa a `PAUSED`, que es lo que ya hace que `webhooks.subscriptions_for()` deje de elegirla, y el recurso pasa a leerse como `off`. Borrar la fila también detendría las notificaciones, y de paso se llevaría por delante la bitácora de entregas: las que ya salieron dejarían de tener a quién apuntar, y la pregunta «¿qué le mandamos a este integrador antes de que se diera de baja?» se quedaría sin respuesta justo cuando alguien la hace. Un `DELETE` de FHIR no obliga a destruir el registro; obliga a que el recurso deje de estar activo.

Requiere: PartnerApiKey, PartnerBearer

CapabilityStatement — qué recursos FHIR expone esta API

Declaración de conformidad FHIR R4. **Sin autenticación, y a propósito.** El conformance es el catálogo, no el dato: un sistema que aún no tiene credenciales necesita poder leerlo para saber si merece la pena pedirlas. Es lo que hace la especificación y lo que esperan las herramientas de validación. No revela ni un dato de paciente: sólo qué recursos existen y por qué se pueden buscar. La escritura se declara **sólo donde de verdad existe** (CR-448, CR-449, CR-450): hoy `create` en `Patient`, `Appointment` y `Subscription`, y `delete` únicamente en este último. Declararla en todos haría que un cliente programara un POST que siempre fallaría, que es el mismo daño que negarla donde sí está. **El vocabulario se declara por recurso** (CR-447): que `Observation` traiga LOINC es la diferencia entre que el integrador cargue el resultado directo o lo mapee a mano, y es una decisión que toma antes de escribir una línea. Se declara con su reserva —«cuando la prueba está mapeada»— porque prometerlo siempre le haría programar contra un campo que a veces no está, que es la misma mentira que declarar una escritura inexistente. **La lectura la hace un integrador y sólo un integrador** (CR-472, cerrado por el CR-473), así que el documento dice con qué ámbito — y dice que lo declarado de categoría especial no viaja sin el segundo. Un conformance que promete `read` sin mencionar que parte del contenido se filtra deja al cliente creyendo que recibió todo. Y nombrar aquí una credencial que no vale —una sesión de plataforma— le haría perder una tarde averiguando por qué su 401 no se arregla.