Qué hace y para quién

Audiencia

Desarrolladores internos de EMA construyendo productos FHIR-native multi-país y multi-tenant: emaclinic, emalab, emavault, emawell. No es un producto cliente-facing — es plumbing del ecosistema.

Problema que resuelve

Si cada producto hablara con Aidbox a mano, repetiríamos 5 veces los mismos errores. Las cosas que cuesta hacer bien:

1. Multi-tenancy. Cada tenant tiene su Aidbox client OAuth2 y su URL /Organization/{id}/fhir/*. Hacerlo a mano se olvida en endpoints nuevos.
2. Meta inyectado correctamente. Cada recurso debe tener meta.profile (canonical sin versión) y meta.tag (urn:ema:tenant, urn:ema:ig-version). Si un producto se olvida, Aidbox no valida y los reportes regulatorios quedan rotos.
3. Multi-país sin redeployar. El canonical base del IG cambia cuando Vault publica un país nuevo. Si está hardcoded en el producto, hay que rebuildear y redeployar todo.
4. Validadores nacionales. RUN, CURP, RFC, DNI son re-implementados mal cada vez que un producto los necesita.
5. Tipado FHIR. 35 recursos R4 a mano es trabajo, y mantener tipos sincronizados con el spec no es trivial.

Propuesta de valor

• Tenant scoping automático. Pasás el tenant una vez al crear el cliente, todas las requests salen scope-adas.
• Meta auto-inyectada. create() y update() agregan meta.profile y meta.tag antes del write. Idempotente, no duplica.
• ProfileResolver runtime. Cuando Vault publica un país nuevo o cambia un canonical, los productos lo reflejan en menos de 5 minutos sin redeployar.
• Tipos correctos. 35 recursos FHIR R4 con ResourceTypeMap que infiere el tipo de retorno automático.
• Validadores listos. validateRun, validateCurp, validateRfc, validateDni con checksum real.
• Helpers que usás todo el día. ref(), transaction(), search() cubren los patrones repetitivos.
• Zero-dep en runtime. El SDK no carga librerías; sólo fetch nativo. Funciona en Workers, Deno, Bun, Node 18+.

Diferencia con escribir fetch a Aidbox a mano

No es un thin wrapper. El SDK encapsula decisiones de dominio EMA:

	Fetch a mano	EMA FHIR SDK
Tenant scoping	manual en cada URL	automático
Meta inyectado	manual y propenso a olvido	automático e idempotente
Multi-país	hardcoded o config estática	runtime via Supabase
Tipos	any o tipos parciales	35 recursos + ResourceTypeMap
Búsqueda	string concat	builder fluent
Auth	propio	strategies pluggables
Validadores ID	reescrito por producto	centralizados
$translate	manual	opt-in con un flag

¿Es solo un cliente HTTP o agrega lógica de dominio?

Agrega lógica de dominio. Bundles decisiones FHIR de EMA: profile sin versión (ADR-0002), tag system urn:ema:tenant (ADR-0001), profile resolution multi-país (Wave 1 ProfileResolver), $translate opt-in append-only (Wave 1).

Por eso es un producto interno con su propio versionado, ADRs y CHANGELOG, no un script de utilidad.