DocumentaçãoSuporteCosta Rica · Contato
  • Técnica

SMART App LaunchSubstitutable Medical Applications and Reusable Technologies

Em poucas palavras

SMART App Launch é o guia da HL7 que define como um aplicativo obtém permissão para ler ou escrever dados em um sistema de saúde com API FHIR, sem conhecer a senha do usuário. Permite que um mesmo app funcione com prontuários de diferentes fornecedores. Nos EUA, a certificação de software clínico do ONC (antes ASTP/ONC) o exige para as APIs FHIR padronizadas.

Tipo
Guia de implementação
Responsável
HL7 International
Versão vigente
STU 2.2 (2.2.0)
Revisado
25 de outubro de 2026

Explicação

O que é

O SMART App Launch, conhecido como «SMART on FHIR», é um guia de implementação da HL7 International que define padrões baseados em OAuth 2.0 para que aplicativos clientes se autorizem, se autentiquem e se integrem a sistemas de dados FHIR. O SMART (Substitutable Medical Applications and Reusable Technologies) nasceu em 2010 como projeto da Harvard Medical School e do Boston Children's Hospital, adotou o FHIR em 2013 e hoje seu guia é publicado pela HL7. Em outubro de 2026, a versão vigente é a STU 2.2 (2.2.0), baseada no FHIR R4.

O que define

  • Descoberta: cada servidor publica em .well-known/smart-configuration seus endereços de autorização e as capacidades que suporta.
  • Dois padrões de autorização: o lançamento de apps voltados ao usuário e os serviços de backend, para processos automáticos sem usuário, como uma exportação de dados em massa.
  • Duas formas de lançar um app: de dentro do prontuário (EHR launch), recebendo o contexto da sessão, como o paciente aberto; ou de forma independente (standalone launch), em que o usuário escolhe ao iniciar.
  • Escopos (scopes): permissões expressas com recursos FHIR, por exemplo user/Encounter.rs para ler e buscar os atendimentos aos quais o usuário tem acesso. A sintaxe mudou em relação ao SMART v1.
  • Autenticação do cliente: preferencialmente com par de chaves assimétricas (JWT assinado), ou com segredo compartilhado.

Todo app SMART deve suportar PKCE (RFC 7636). Para identificar o usuário, o SMART acrescenta o OpenID Connect com os escopos openid e fhirUser.

Equívocos comuns

  • O SMART não é um padrão de dados: não diz o que um recurso contém, apenas quem pode acessá-lo e com quais permissões.
  • Um escopo amplo como patient/*.rs dá acesso a muito mais do que um app costuma precisar. O princípio do menor privilégio também vale aqui.
  • O servidor decide qual contexto e quais permissões concede. Um app não deve presumir que obteve tudo o que pediu.
  • A versão do SMART importa. Segundo o kit de testes (g)(10) do ONC, o US Core 7.0.0 só deve ser usado com o SMART App Launch 2.0.0 ou superior, por seus requisitos de escopos granulares.

Exemplos de uso

  1. Nos EUA, o critério § 170.315(g)(10) do ONC (antes ASTP/ONC) exige que o software clínico certificado autorize suas APIs FHIR com SMART App Launch, tanto no lançamento a partir do prontuário quanto no independente.

  2. O guia FHIR Bulk Data Access da HL7 recomenda autorizar as exportações de dados em massa conforme o perfil SMART Backend Services, sem intervenção de um usuário.

  3. Nos EUA, o CMS inclui o SMART App Launch 2.0.0 entre os padrões da Patient Access API que as operadoras abrangidas por suas regras de interoperabilidade devem oferecer; a versão 1.0.0 expirou em 1º de janeiro de 2026.

  4. O kit de testes (g)(10) do ONC (antes ASTP/ONC) permite testar com o SMART App Launch 2.0.0 ou 2.2.0, junto com o US Core e o Bulk Data.

  5. A API Blue Button 2.0 do CMS usa escopos com a sintaxe do SMART, como patient/ExplanationOfBenefit.rs e launch/patient.

  6. Um médico abre uma calculadora de risco a partir do prontuário; o app recebe por contexto (launch/patient) o paciente que o médico tem aberto.

  7. Um app para pacientes consulta o arquivo .well-known/smart-configuration do prestador para saber onde pedir autorização.

Relação com outros termos

Apoia-se em3

  • FHIRObrigatória

    O SMART autoriza o acesso a servidores FHIR e expressa as permissões com tipos de recursos FHIR.

  • OAuth 2.0Obrigatória

    Todos os padrões de autorização do SMART são perfis do OAuth 2.0.

  • OpenID ConnectMédia

    Só quando o app precisa saber quem é o usuário (capacidade sso-openid-connect, escopos openid e fhirUser).

Dependem deste0

Nenhum termo do glossário depende deste.

Fontes

  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
Glossário de interoperabilidade em saúde