Serviços ao redor do registro clínico

A plataforma precisa também cadastrar usuários, comunicar eventos, validar acesso e administrar integrações.

GrupoEntradas encontradasFinalidade inferível da fonte
Notificaçãoapi-notificacoes, api-notifica1hora, notificagovbrOrquestrar comunicações e lembretes
Cadastro e contasign-up, registrationservices, passrecoveryservice, userCiclo de vida de usuários
DiretórioSCIM, user-ebserh, practitioner/practitionerroleRepresentar e sincronizar identidades
Autorizaçãooauth-validator, introspectiontokenservices, consentimentoValidar token, escopo e contexto
Administraçãoadmin, ehrrunneradmin, registry compositeSuporte à operação e ao registro de componentes

Notificação como efeito do processo

Uma comunicação deve derivar de um evento válido, mas não substituir o registro clínico ou a auditoria.

Evento válido
     ↓ regra de negócio
Serviço de notificação
     ↓ canal autorizado
Usuário destinatário
     ↓
Entrega / falha / nova tentativa
  • Confirmar destinatário e preferência de canal.
  • Minimizar informação clínica no texto da mensagem.
  • Não usar entrega da notificação como prova de processamento clínico.
  • Registrar estado de entrega e falha sem persistir segredo de acesso.
  • Aplicar limite e idempotência para evitar envios repetidos.

Cadastro não é autorização clínica

Criar ou sincronizar uma conta é diferente de permitir acesso a um prontuário.

PerguntaCamada responsável
Quem é o usuário?Identidade e diretório
A credencial é válida?OAuth/introspecção
Qual papel ele exerce?Perfis e PractitionerRole
Pode executar esta operação?Política e escopo
Pode acessar este paciente agora?Consentimento, finalidade e contexto

Configuração segura

Exemplos de integração frequentemente misturam contrato e material secreto; o portal os separa.

Requisição conceitual
POST /servico-autorizado HTTP/1.1
Host: [HOST_DO_AMBIENTE]
Authorization: Bearer [TOKEN_OBTIDO_COM_SEGURANCA]
Content-Type: application/json

{ "evento": "[TIPO_DOCUMENTADO]" }