Login Multi-Perfil

Só são suportadas integrações no padrão REST.

Orientações

Negócio

De acordo com a estrutura de sua empresa, o método de login pode devolver estruturas de login que permitam o acesso a alguns perfis de usuário:

• Login de beneficiário;

• Login de profissional de saúde;

• Login de beneficiário + profissional de saúde (quando um profissional de saúde também é um beneficiário de plano de saúde);

Estrutura sugerida para o retorno do perfil do Beneficiário

• Retorna os seus dados + dados dos dependentes;

• Retorna os seus dados + os demais dependentes (não retorna os dados do titular);

• Retorna apenas os dados do beneficiário logado;

• Quando o usuário for um titular;

• Quando o usuário for o cônjuge;

• Quando for outro tipo de dependente (filho, filha, etc);

• Dica: retorne apenas dados que possam ser exibidos. Se um beneficiário da família estiver, por exemplo,  bloqueado ou impedido de utilizar o plano, não devolva-o no retorno do endpoint.

Perfil do profissional de saúde

Caso seu sistema identifique que o usuário logado também é um profissional de saúde, o método deve retornar a estrutura dedicada aos profissionais de saúde;

Recomendações gerais

• O endpoint de login deve validar todas as suas regras de negócio, permitindo acesso apenas a usuários autorizados;

• O endpoint deverá retornar o usuário que fez login, e de acordo com o perfil, poderá enviar ainda mais informações;

• Quando o perfil for exclusivamente  profissional de saúde, não é necessário retornar a estrutura de beneficiário;

• Quando o perfil for exclusivamente beneficiário, não é necessário retornar a estrutura de profissional de saúde;

• Quando o perfil for beneficiário e  profissional de saúde, retornar todas as estruturas descritas no layout;

• Caso o usuário autenticado possua mais de um contrato, esses devem ser descritos no item Contratos e o array de beneficiário e de profissional de saúde deve conter as informações de todos os contratos;

  • Ex.: Beneficiário possui um plano de saúde com um filho dependente e um plano odontológico sem dependentes. Os dois contratos precisam estar descritos no array Contratos e o array Família vai conter 3 objetos (dois do plano de saúde e um do plano odontológico). Essa mesma lógica se aplica à estrutura do profissional de saúde;

Retornar ao índice

Tokens de segurança ou autenticação

A Mobile Saúde descreve nesta documentação o formato de adoção obrigatória quando sua empresa desejar utilizar TOKENS de segurança.

O formato suportado pela aplicação está descrito no objeto SEGURANÇA, e sua empresa deve necessariamente implementa-lo conforme descrito quando desejar utilizar essa camada adicional de segurança.

Não serão suportadas outras formas de transacionar TOKENs de segurança, como por exemplo tokens de autenticação na URL da requisição, entre outros.

Caso tenha dúvidas, ou deseje maiores esclarecimentos, entre em contato com o gestor de projeto encarregado de sua implantação, para atendimento às questões ANTES DE DESENVOLVER SUA API.

Objeto permissões

Devemos somente informar na estrutura de permissões dentro do objeto contratos as funcionalidades que o usuário não tem acesso ou ocultar caso queira que não apareça, mas para requisito de validação da estrutura do beneficiário, eleger uma ou mais funcionalidades junto com a equipe de desenvolvimento da Mobile Saúde para facilitar os testes de permissionamento.

Lembrando que a tabela de funcionalidades está no final do documento de especificações.

Exemplos de uso:

• Funcionalidade negada com mensagem customizada

 "permissoes": [ {

        "funcionalidade": "1",

        "acesso": false,

        "mensagemBloqueio": "Você não possui acesso a está funcionalidade, para mais informações entre em contato com 0800",

        "ocultar": false

}]

• Funcionalidade negada sem mensagem customizada, será exibida uma mensagem padrão

 "permissoes": [ {

        "funcionalidade": "1",

        "acesso": false,

        "mensagemBloqueio": null,

        "ocultar": false

}]

• Funcionalidade oculta no app

"permissoes": [ {

        "funcionalidade": "1",

        "acesso": false,

        "mensagemBloqueio": null,

        "ocultar": true

}]

• Acesso liberado

"permissoes": null

Retornar ao índice

Retornar ao índice

Os atributos devem seguir exatamente os mesmos nomes indicados nesta documentação, caso contrário, serão rejeitados pelo validador de integração.

Exemplo do atributo "usuarioLogado":

• usuario-logado

• usuario_logado

• usuario

• usuarioLogado

Multi-contrato

Em Operadoras de saúde é normal existir o mesmo beneficiário vinculado a contratos diferentes ou seja termos um beneficiário como:

Titular em um contrato e dependente em outro contrato.

Para que ele possa ter acesso a ambos os contratos o vinculo é realizado pelo campo chave_unica, ou seja um beneficiário em 2 contratos distintos é vinculado a partir deste campo os critérios de exibição seguem os conceitos de grupo familiar desta documentação.

• Este método é obrigatório;

• Atente-se as orientações fornecidas pela Mobile Saúde;

• Atente-se as orientações de segurança e permissões;

• Atente-se aos critérios de preenchimento;

• Atente-se aos critérios de objetos e atributos de retorno;

• Atente-se as mensagens de retorno para cada HTTPS Status Code;

• Este objeto é opcional;

• Este objeto é destinado as propriedades relacionadas a segurança dos dados do beneficiário.

• Em caso de não utilização não informar, ou informar com o valor "NULL"

• Atente-se as orientações fornecidas pela Mobile Saúde;

• Atente-se as orientações de segurança e permissões;

• Atente-se aos critérios de preenchimento;

• Atente-se aos critérios de objetos e atributos de retorno;

• Atente-se as mensagens de retorno para cada HTTPS Status Code;

• Array de objetos “auth” que está contido no objeto “seguranca”;

Retornar ao índice

• Este objeto é obrigatorio;

• Essa estrutura contém os dados do usuário logado.

• Atente-se as orientações fornecidas pela Mobile Saúde;

• Atente-se as orientações de segurança e permissões;

• Atente-se aos critérios de preenchimento;

• Atente-se aos critérios de objetos e atributos de retorno;

• Atente-se as mensagens de retorno para cada HTTPS Status Code;

• Objeto “contato” que está contido no objeto “usuarioLogado”;

• Essa estrutura contém os dados pra contato do usuário logado.

• Objeto “sexo” que está contido no objeto “pessoaFisica”;

• Objeto “estadoCivil” que está contido no objeto “pessoaFisica”;

• Objeto “perfil” que está contido no array de objetos “perfis” do usuário logado;

• Essa estrutura contém os dados de perfil do usuário logado.

• Objeto “custom” que está contido no array de objetos “perfil”;

• Utilize esse objeto para enviar campos que não são suportados pelo layout padrão de atributos (por exemplo, exibir número da matricula funcional de empregado, tipo sanguíneo e etc).

• Crie quantas chave / valor forem necessários, desde que obedeçam as premissas descritas no objeto.

• Não possui regra de preenchimento;

• Pode ser enviada qualquer estrutura desde que seja uma estrutura JSON valida

• Objeto “permissoes” que está contido no objeto “usuarioLogado”;

• Essa estrutura contém as instruções sobre quais funcionalidades do aplicativo o usuário logado poderá visualizar ou ter acesso, conforme as regras de negocio da operadora.

• Por padrão, todas as funcionalidades (do escopo do projeto) são permitidas e essa estrutura deve tratar a exceção, ou seja, apenas aquilo que o usuário não pode visualizar ou acessar.

Retornar ao índice

• Este objeto é obrigatório;

• Estrutura que contém todo os contratos que o usuário logado está vinculado.

• Atente-se as orientações fornecidas pela Mobile Saúde;

• Atente-se as orientações de segurança e permissões;

• Atente-se aos critérios de preenchimento;

• Atente-se aos critérios de objetos e atributos de retorno;

• Atente-se as mensagens de retorno para cada HTTPS Status Code;