DocumentaciónSoporteCosta Rica · Contacto
  • Técnica

SMART App LaunchSubstitutable Medical Applications and Reusable Technologies

En pocas palabras

SMART App Launch es la guía de HL7 que define cómo una aplicación obtiene permiso para leer o escribir datos en un sistema de salud con API FHIR, sin conocer la contraseña del usuario. Permite que una misma app funcione con historias clínicas de distintos proveedores. En EUA, la certificación de software clínico de la ONC (antes ASTP/ONC) la exige para las APIs FHIR estandarizadas.

Tipo
Guía de implementación
Versión vigente
STU 2.2 (2.2.0)
Revisado
25 de octubre de 2026

Explicación

Qué es

SMART App Launch, conocida como «SMART on FHIR», es una guía de implementación de HL7 International que define patrones basados en OAuth 2.0 para que aplicaciones cliente se autoricen, se autentiquen y se integren con sistemas de datos FHIR. SMART (Substitutable Medical Applications and Reusable Technologies) nació en 2010 como proyecto de Harvard Medical School y Boston Children's Hospital, adoptó FHIR en 2013 y hoy su guía la publica HL7. A octubre de 2026, la versión vigente es la STU 2.2 (2.2.0), basada en FHIR R4.

Qué define

  • Descubrimiento: cada servidor publica en .well-known/smart-configuration sus direcciones de autorización y las capacidades que soporta.
  • Dos patrones de autorización: el lanzamiento de apps orientadas al usuario y los servicios de backend, para procesos automáticos sin usuario, como una exportación masiva de datos.
  • Dos formas de lanzar una app: desde dentro de la historia clínica (EHR launch), que recibe el contexto de la sesión, como el paciente abierto; o de forma independiente (standalone launch), donde el usuario elige al iniciar.
  • Ámbitos (scopes): permisos expresados con recursos FHIR, por ejemplo user/Encounter.rs para leer y buscar los encuentros a los que el usuario tiene acceso. La sintaxis cambió respecto de SMART v1.
  • Autenticación del cliente: preferentemente con par de claves asimétricas (JWT firmado), o con secreto compartido.

Toda app SMART debe soportar PKCE (RFC 7636). Para identificar al usuario, SMART añade OpenID Connect con los ámbitos openid y fhirUser.

Errores frecuentes

  • SMART no es un estándar de datos: no dice qué contiene un recurso, solo quién puede acceder y con qué permisos.
  • Un ámbito amplio como patient/*.rs da acceso a mucho más de lo que una app suele necesitar. El principio de mínimo privilegio aplica también aquí.
  • El servidor decide qué contexto y permisos concede. Una app no debe asumir que obtuvo todo lo que pidió.
  • La versión de SMART importa. Según el kit de pruebas (g)(10) de la ONC, US Core 7.0.0 solo debe usarse con SMART App Launch 2.0.0 o superior, por sus requisitos de ámbitos granulares.

Ejemplos de uso

  1. En EUA, el criterio § 170.315(g)(10) de la ONC (antes ASTP/ONC) exige que el software clínico certificado autorice sus APIs FHIR con SMART App Launch, tanto en lanzamiento desde la historia clínica como independiente.

  2. La guía FHIR Bulk Data Access de HL7 recomienda autorizar las exportaciones masivas de datos según el perfil SMART Backend Services, sin intervención de un usuario.

  3. En EUA, CMS incluye SMART App Launch 2.0.0 entre los estándares de la Patient Access API que deben ofrecer las aseguradoras alcanzadas por sus reglas de interoperabilidad; la versión 1.0.0 expiró el 1 de enero de 2026.

  4. El kit de pruebas (g)(10) de la ONC (antes ASTP/ONC) permite probar con SMART App Launch 2.0.0 o 2.2.0, junto con US Core y Bulk Data.

  5. La API Blue Button 2.0 de CMS usa ámbitos con la sintaxis de SMART, como patient/ExplanationOfBenefit.rs y launch/patient.

  6. Un médico abre una calculadora de riesgo desde la historia clínica; la app recibe por contexto (launch/patient) el paciente que el médico tiene abierto.

  7. Una app para pacientes consulta el archivo .well-known/smart-configuration del prestador para saber dónde pedir autorización.

Relación con otros términos

Se apoya en3

  • FHIRObligatoria

    SMART autoriza el acceso a servidores FHIR y expresa los permisos con tipos de recursos FHIR.

  • OAuth 2.0Obligatoria

    Todos los patrones de autorización de SMART son perfiles de OAuth 2.0.

  • OpenID ConnectMediana

    Solo cuando la app necesita saber quién es el usuario (capacidad sso-openid-connect, ámbitos openid y fhirUser).

Dependen de este0

Ningún término del glosario depende de este.

Fuentes

  1. HL7 — SMART App Launch Implementation Guide (STU 2.2)hl7.org
  2. SMART App Launch — Scopes and Launch Contexthl7.org
  3. Mandel et al. — SMART on FHIR: a standards-based, interoperable apps platform for electronic health records (JAMIA, 2016)academic.oup.com
  4. ONC — ONC Certification (g)(10) Standardized API Test Kitfhir.healthit.gov
  5. CMS — APIs and relevant standards and implementation guidescms.gov
  6. HL7 — FHIR Bulk Data Access: Exporthl7.org
  7. CMS — Blue Button 2.0 API: Authorizationbluebutton.cms.gov
  8. Federal Register — HHS Statement of Organization: Office of the National Coordinator for Health IT (91 FR 16204, 1 April 2026)federalregister.gov
Glosario de interoperabilidad en salud