Um ecossistema, quatro contextos
As sessões separam o canal usado da autorização aplicada; compartilhar serviços não significa compartilhar as mesmas permissões.
| Canal | Público | Entrada apresentada | Característica |
|---|---|---|---|
| Portal paciente | Cidadão | Identidade gov.br | Registros próprios, agenda, privacidade e histórico |
| Portal profissional | Profissional da rede | Identidade institucional | Pesquisa e consulta no contexto assistencial |
| HU Digital embarcado | Profissional no AGHU | Contexto mediado pela integração | Paciente previamente selecionado e rota específica |
| App móvel | Paciente | gov.br em fluxo móvel | Experiência nativa para iOS e Android |
Autenticação e autorização em camadas
O fluxo apresentado combina provedores externos, Identity Server, API Manager e serviços clínicos.
Usuário
↓ autenticação federada
Gov.br ou identidade institucional
↓ callback autorizado
Identity Server
↓ tokens e contexto
Aplicação → API Manager → serviço FHIR / microserviço
↓
política, consentimento e auditoria| Prova | O que representa | O que não prova sozinha |
|---|---|---|
| Credencial da aplicação | Qual cliente está chamando | Qual pessoa está usando e por quê |
| Token do usuário | Identidade e atributos da sessão | Permissão irrestrita sobre qualquer paciente |
| PractitionerRole | Papel profissional no contexto cadastrado | Consentimento ou finalidade para toda consulta |
| Política de consentimento | Regra de compartilhamento aplicável | Identidade correta sem auditoria |
| Contexto AGHU | Origem e paciente selecionado | Confiança automática em parâmetros do cliente |
O repasse diferencia token da aplicação e token do usuário. Fluxos com usuário autenticado preservam o sujeito para autorização e auditoria; integrações técnicas sem contexto OIDC seguem contrato específico e não devem ser generalizadas para acesso clínico interativo.
A instância HTTP centralizada no cliente adiciona cabeçalhos e trata respostas, mas a decisão de acesso permanece no backend. Erros de autenticação, política, consentimento e conflito precisam de mensagens úteis sem revelar detalhes internos.
Portal web: uma base, builds distintas
A demonstração de 25 de setembro mostra um repositório web que produz experiências separadas por modo e ambiente.
- 1Selecionar o modo
Paciente, profissional e AGHU ativam conjuntos diferentes de rotas e features.
- 2Carregar a configuração
Settings, flags e variáveis de ambiente definem comportamento sem duplicar toda a base.
- 3Estabelecer a sessão
Contexts e hooks propagam autenticação e estado pelas páginas.
- 4Consumir serviços
Uma camada Axios centraliza base de API, cabeçalhos, renovação e tratamento de falhas.
- 5Gerar e publicar
Scripts produzem artefatos estáticos por modo para hospedagem e roteamento no Nginx.
| Decisão registrada | Benefício | Risco de manutenção |
|---|---|---|
| Base compartilhada | Reuso de componentes e regras de apresentação | Mudança comum pode afetar três experiências |
| Feature flags | Variação explícita por público | Combinações não testadas geram regressões |
| HashRouter | Compatibilidade com hospedagem estática registrada | Rotas e servidor precisam permanecer alinhados |
| API services centralizados | Autenticação e erros consistentes | Uma configuração errada afeta todas as chamadas |
| Build por ambiente | Artefato adequado ao destino | Segredo ou endpoint não deve ser incorporado indevidamente |
Aplicativo móvel: OAuth em WebView e ciclo de loja
O app apresentado é voltado ao paciente e combina React Native, Expo, serviços HTTP e autenticação gov.br.
- O fluxo de login abre a identidade gov.br em WebView e trata o callback para retornar ao aplicativo.
- A camada de serviços segue a ideia do portal: cliente HTTP central, domínios de API e contexto de autenticação.
- A organização visual registrada segue design atômico, de átomos e moléculas até templates e telas.
- Diferenças entre iOS e Android aparecem em build, estilo, manipulação de arquivos e assinatura.
- A publicação exige identificadores, versões, assinatura, trilha de testes e aprovação nas lojas.
Versões citadas são pistas históricas
As gravações registram ferramentas concretas, úteis para localizar legado, mas inadequadas como baseline automática em 2026.
| Recorte de 2025 | Registro no repasse | Ação segura |
|---|---|---|
| Portal web | React 16.14, Node 16.16 e Yarn foram mostrados | Conferir manifestos, lockfile, pipeline e runtime suportado |
| Aplicativo | React Native 0.69, Expo e ferramentas móveis foram citados | Conferir configuração atual, requisitos de loja e compatibilidade nativa |
| Android | AAB, versionCode e exigência de API mínima aparecem no fluxo | Consultar política vigente da loja antes de publicar |
| iOS | Xcode, TestFlight, certificados e revisão aparecem no fluxo | Validar conta, perfis, assinatura e requisitos vigentes |
| Deploy web | Build estática e cópia para Nginx foram demonstradas | Usar pipeline aprovado, evidência de teste e plano de reversão |
Capítulos para revisão dirigida
Abra as três gravações pelo Guia do repasse e use os timestamps abaixo.
| Sessão | Timestamp | Assunto |
|---|---|---|
| 19/09 | 00:17:13 | OAuth em três camadas |
| 19/09 | 00:25:15 | Perfis e PractitionerRole |
| 19/09 | 00:30:02 | Consentimento e portal embarcado |
| 19/09 | 01:28:26 | Token de aplicação versus token de usuário |
| 25/09 | 00:28:02 | Settings, features e ambiente |
| 25/09 | 01:07:00 | Contexts, hooks e API services |
| 25/09 | 02:04:43 | Build e deploy |
| 26/09 | 00:38:48 | Axios e autenticação em WebView |
| 26/09 | 01:07:16 | Publicação Google Play e App Store |