Tu primera receta en 5 minutos

No hace falta hablar con nadie: el sandbox emite credenciales de prueba por sí solo, la documentación es pública y los datos son ficticios. Cuando tu integración funcione, escribinos a [email protected] para pasar a producción.

1 · Conseguí credenciales de prueba

¿Preferís el navegador? Creá tus credenciales en el registro autoservicio y ejecutá cada endpoint desde el playground, sin salir de esta pestaña.

Elegí el rol que querés ensayar: clinic emite recetas y verifica asegurados, pharmacy las busca y dispensa, insurer sincroniza su padrón y audita verificaciones.

curl -X POST https://sandbox.api.emedic.la/v1/sandbox/signup \
  -H "Content-Type: application/json" \
  -d '{"organizationName": "Mi Clínica de Prueba", "type": "clinic"}'

# → { "apiKey": "emk_test_...", "scopes": ["prescriptions:write", ...] }
# Guardá la llave: se muestra una sola vez.

2 · Emití una receta

La autenticación va en el header X-API-Key. El header Idempotency-Key hace el reintento seguro: repetir la misma llamada no duplica la receta.

curl -X POST https://sandbox.api.emedic.la/v1/prescriptions \
  -H "X-API-Key: emk_test_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "patient": { "identityNumber": "4567890", "firstName": "María", "lastName": "González", "phone": "0981 123 456" },
    "practitioner": { "name": "Dr. Juan Pérez", "licenseNumber": "12345" },
    "medications": [{
      "name": "Amoxicilina 500 mg cápsulas",
      "quantityPrescribed": 21,
      "unit": "cápsula",
      "dosageInstruction": { "text": "1 cápsula cada 8 horas por 7 días" }
    }],
    "signature": { "type": "scanned_image", "value": "aW1hZ2Vu" }
  }'

El celular del paciente es opcional pero conviene mandarlo. Con él, la plataforma le avisa por SMS que tiene su receta y lo lleva a la app; el mensaje nunca menciona el medicamento, el diagnóstico ni la clínica. Se normaliza solo a E.164 (+595981123456) y no se expone a las farmacias.

¿Tu sistema ya produce FHIR R4? Enviá el Bundle tal cual a POST /v1/adapters/fhir-r4/prescriptions y la plataforma lo traduce.

3 · Buscá y dispensá como farmacia

Creá una segunda credencial con "type": "pharmacy". Por privacidad, la búsqueda es solo por documento de identidad del paciente.

# Buscar recetas activas del paciente
curl "https://sandbox.api.emedic.la/v1/prescriptions?patientIdentityNumber=4567890" \
  -H "X-API-Key: emk_test_FARMACIA"

# Dispensar una línea (parcial o total)
curl -X POST https://sandbox.api.emedic.la/v1/prescriptions/rx_.../dispensations \
  -H "X-API-Key: emk_test_FARMACIA" \
  -H "Content-Type: application/json" \
  -d '{ "dispensedBy": "Q.F. Laura Ríos", "items": [{ "lineId": "line_...", "quantity": 21 }] }'

4 · Suscribite a eventos

Cada entrega llega firmada con HMAC-SHA256 en X-Emedic-Signature; rechazá lo que no verifique.

curl -X POST https://sandbox.api.emedic.la/v1/webhook-endpoints \
  -H "X-API-Key: emk_test_FARMACIA" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://mi-sistema.example/webhooks", "events": ["prescription.created"] }'

Los datos del paciente se mantienen solos. Cuando un paciente actualiza su celular o su correo desde su app, la plataforma te manda patient.contact_updated con la cédula y el dato nuevo —ya verificado por él— para que tu ficha no quede con un número de hace ocho meses. Solo lo recibís si esa persona es paciente tuyo: es un evento dirigido, no una difusión.

5 · Verificación de asegurados (aseguradoras y prestadores)

La familia /v1/identity reemplaza la hoja firmada: la recepción del prestador verifica el rostro del asegurado y obtiene un código de autorización que acompaña al claim. La aseguradora sincroniza su padrón, recibe cada evento por webhook y valida los códigos.

# La aseguradora sincroniza su padrón (scope members:sync)
curl -X POST https://sandbox.api.emedic.la/v1/identity/members/sync \
  -H "X-API-Key: emk_test_ASEGURADORA" \
  -H "Content-Type: application/json" \
  -d '{ "members": [{ "identityNumber": "4123456", "policyNumber": "POL-001",
        "fullName": "Ana Benítez", "status": "active" }] }'

# El prestador enrola (una vez, con consentimiento) y verifica
curl -X POST https://sandbox.api.emedic.la/v1/identity/verifications \
  -H "X-API-Key: emk_test_CONSULTORIO" \
  -H "Content-Type: application/json" \
  -d '{ "insurerId": "org_...", "identityNumber": "4123456", "image": "rostro:ana" }'
# → { "result": "verified", "authorizationCode": "EMD-7K4P-2X", ... }

# La aseguradora cruza el claim contra el código (scope identity:read)
curl https://sandbox.api.emedic.la/v1/identity/verifications/EMD-7K4P-2X \
  -H "X-API-Key: emk_test_ASEGURADORA"

En el sandbox la imagen es simbólica ("rostro:<x>" enrola y verifica; "foto:<x>" reprueba la prueba de vida). En producción el liveness es obligatorio por sesión (POST /v1/identity/liveness/sessions) con proveedor certificado: una imagen suelta se rechaza. La atención nunca se bloquea: si la verificación no es posible, POST /v1/identity/exceptions registra la excepción tipificada y la aseguradora la ve en tiempo real. El log completo y el ranking por prestador están en GET /v1/identity/verifications y GET /v1/identity/operators/stats — la misma lectura que alimenta la consola web para aseguradoras sin sistemas.

6 · Liquidación viva (adiós a la planilla mensual)

Con el código de autorización de la verificación, el claim nace presentado: arancel y copago salen del nomenclador del convenio, la aseguradora adjudica claim por claim (la objeción llega al día siguiente, no a los 60), y los aprobados ganan firmeza y se liquidan en cortes.

# La aseguradora publica su nomenclador (una vez)
curl -X POST https://sandbox.api.emedic.la/v1/claims/fee-schedule/sync \
  -H "X-API-Key: emk_test_ASEGURADORA" -H "Content-Type: application/json" \
  -d '{ "items": [{ "code": "CONS-COMUN", "name": "Consulta común",
        "amountCents": 15000000, "copayCents": 3000000 }] }'

# El prestador presenta el claim con el código verde de la verificación.
# La matrícula es la identidad profesional de la red: cada acto llega con
# ella y vuelve en claim.approved para rutear a la cuenta del médico.
# ¿Tu sistema no tiene campo de matrícula? Declarás tu plantel UNA vez
# (POST /v1/practitioners/sync: tu id interno → matrícula) y mandás
# practitionerRef; o pedís una credencial con matrícula atada si sos un
# consultorio unipersonal.
curl -X POST https://sandbox.api.emedic.la/v1/claims \
  -H "X-API-Key: emk_test_CONSULTORIO" -H "Content-Type: application/json" \
  -d '{ "insurerId": "org_...", "serviceCode": "CONS-COMUN",
        "practitionerLicense": "MED-4455", "authorizationCode": "EMD-7K4P-2X" }'

# La aseguradora adjudica; el corte liquida los firmes por prestador
curl -X POST https://sandbox.api.emedic.la/v1/claims/{claimId}/adjudicate \
  -H "X-API-Key: emk_test_ASEGURADORA" -H "Content-Type: application/json" \
  -d '{ "decision": "approve" }'
curl -X POST https://sandbox.api.emedic.la/v1/claims/settlements \
  -H "X-API-Key: emk_test_ASEGURADORA"

Reglas del dominio: un código respalda un solo claim y solo lo presenta el prestador que operó la verificación. La cuenta viva del prestador está en GET /v1/claims/summary; los eventos claim.* y settlement.created llegan por webhook, cada lado con solo lo suyo.

7 · Anticipo del banco (siempre opcional)

El prestador que lo activa cede sus claims firmes al banco socio y cobra hoy con un descuento explícito; el que no, cobra por corte sin costo. eMedic lleva el registro único de cesiones (un claim, una cesión) y emite la instrucción de dispersión del corte: lo cedido al banco, el resto a cada prestador. La plata nunca pasa por la plataforma.

# El prestador activa el anticipo y anticipa un claim firme
curl -X PUT https://sandbox.api.emedic.la/v1/financing/preference   -H "X-API-Key: emk_test_CONSULTORIO" -H "Content-Type: application/json"   -d '{ "mode": "manual" }'
curl -X POST https://sandbox.api.emedic.la/v1/financing/advances   -H "X-API-Key: emk_test_CONSULTORIO" -H "Content-Type: application/json"   -d '{ "claimId": "clm_..." }'
# → { "amountCents": 15000000, "feeCents": 300000, "netCents": 14700000, ... }

# El banco confirma la transferencia y lee la instrucción del corte
curl -X POST https://sandbox.api.emedic.la/v1/financing/cessions/{cessionId}/paid   -H "X-API-Key: emk_test_BANCO"
curl https://sandbox.api.emedic.la/v1/financing/settlements/{settlementId}/instruction   -H "X-API-Key: emk_test_BANCO"

8 · Órdenes de estudios con visación instantánea

El médico emite la orden contra el catálogo de la plataforma y el motor de reglas del convenio decide cada estudio en un segundo: autorizado, rechazado con motivo, o a la cola del auditor. Se acabó la foto de la orden por WhatsApp. El laboratorio atiende con la cédula del paciente, realiza cada ítem una sola vez y sube el resultado: el médico tratante y el paciente lo ven al instante, a la par.

# La aseguradora publica sus reglas de visación (una vez)
curl -X POST https://sandbox.api.emedic.la/v1/orders/coverage-rules/sync \
  -H "X-API-Key: emk_test_ASEGURADORA" -H "Content-Type: application/json" \
  -d '{ "rules": [{ "studyCode": "CBC", "covered": true },
        { "studyCode": "RMN-CEREBRO", "covered": true, "requiresReview": true }] }'

# El consultorio emite; la respuesta YA trae el veredicto de cada ítem.
# practitionerLicense y externalReference (el id de la orden EN TU SISTEMA)
# son opcionales y vuelven intactos en respuestas y webhooks del emisor:
# con ellos ruteás el resultado a la bandeja del médico correcto.
curl -X POST https://sandbox.api.emedic.la/v1/orders \
  -H "X-API-Key: emk_test_CONSULTORIO" -H "Content-Type: application/json" \
  -d '{ "insurerId": "org_...", "patientIdentityNumber": "4123456",
        "patientFullName": "Ana Benítez", "studyCodes": ["CBC", "GLU"],
        "practitionerLicense": "MED-4455", "externalReference": "HIS-ORD-000123" }'
# → items: [{ "studyCode": "CBC", "status": "authorized" }, ...]
# → el webhook result.available llega con practitionerLicense y externalReference

# El laboratorio busca por cédula (sin diagnóstico, jamás), realiza y sube
curl https://sandbox.api.emedic.la/v1/orders/patient/4123456   -H "X-API-Key: emk_test_LABORATORIO"
curl -X POST https://sandbox.api.emedic.la/v1/orders/{orderId}/items/{itemId}/fulfill   -H "X-API-Key: emk_test_LABORATORIO"
curl -X POST https://sandbox.api.emedic.la/v1/orders/{orderId}/items/{itemId}/result \
  -H "X-API-Key: emk_test_LABORATORIO" -H "Content-Type: application/json" \
  -d '{ "resultText": "Hemograma dentro de parámetros normales" }'

El catálogo con prerrequisitos para el paciente está en GET /v1/orders/catalog; la cola del auditor de la aseguradora es GET /v1/orders?itemStatus=pending_review. Los eventos order.* y result.available llegan por webhook, dirigidos: la visación al emisor, el resultado nunca con contenido clínico adentro.

Lo que conviene saber

Referencia completa

Todos los endpoints, schemas y códigos de error, generados de la especificación OpenAPI (la misma que valida el servidor):

Abrir la referencia de la API  Descargar openapi.yaml