/
1.1 - Login

1.1 - Login

Índice

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

 

Segurança e permissões

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.

Clique aqui para visualizar a tabela de funcionalidades.

 

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

Critérios de preenchimento

Abreviação

Nome

Descrição

Abreviação

Nome

Descrição

M

Mandatório

O preenchimento do atributo é obrigatório. Caso o atributo esteja nulo ou em branco, seu "response" será rejeitado.

C

Condicional

O atributo pode tornar-se obrigatório quando um ou mais atributos auxiliares for preenchido / atualizado.

OP

Opcional

Seu preenchimento não é obrigatório. Pode-se enviar NULL para objetos, ou arrays vazios para tipos Array

Retornar ao índice

Objetos e atributos de retorno

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

 

Grupo Familiar

Grupo Familiar
Grupo familiar são beneficiários (titulares, dependentes e agregados) que compõe uma familia o campo que determina esta amarração é o "cod_familia” ou seja todos que necessitam estar no mesmo grupo familiar necessitam estar com este código igual.

Visibilidade x Correlação

  • Titular: tipoUsuario = T e grauParentesco = 01

    • Retorna todos dentro do grupo familiar;

  • Dependente do tipo cônjuge: tipoUsuario = D e grauParentesco = 02

    • Retorna ele mesmo e todos os demais dependentes, excluindo os do tipo Agregado (A);

  • Dependentes diferentes do tipo cônjuge: tipoUsuario = D e grauParentesco != 02

    • Retorna apenas ele mesmo;

  • Agregados: tipoUsuario = A e grauParentesco > 02

    • Retorna apenas ele mesmo;

 

Multi-contrato

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.

Método de login

Endpoint

Endpoint

Método

Header Content-Type

Descrição

Endpoint

Método

Header Content-Type

Descrição

exemplo.com/login

Atenção

O endpoint obrigatoriamente deve terminar com "/login".

POST

application/json

Endpoint de login

 

Parâmetros de entrada

Parâmetro

Obrigatório

Tipo

Descrição

Parâmetro

Obrigatório

Tipo

Descrição

login

M

String

ID de identificação do usuário do app. Sugerimos que o login seja o CPF do usuário.

senha

M

String

Senha de acesso informada pelo usuário no momento do login.
Observação sobre criptografia: caso seja necessário criptografar a senha, sugerimos fornecer um acesso via HTTPS ao invés de usar algoritmos próprios.

 

Exemplo request

url: https://www.operadoradesaude.com.br/mobilesaude/login Body: { "login": "<login>", "senha": "<senha>" }

 

Descrição dos objetos e atributos de retorno - Sucesso

Está indicado abaixo a estrutura de retorno do seu método login. Esse método deve obedecer as regras indicadas no objeto principal e em seus desdobramentos.

Atributo

Critério

Tipo

Descrição

Regra de preenchimento

Atributo

Critério

Tipo

Descrição

Regra de preenchimento

seguranca

OP

Objeto seguranca

Lista parâmetros que devem ser enviados no header dos demais endpoints de integração do sistema para garantir que o beneficiário está autenticado no sistema.

Preencher com o objeto do tipo "seguranca". Se não for utilizar não informar, ou informar com o valor "NULL"

usuarioLogado

M

Objeto usuarioLogado

Usuário que efetuou login

Objeto precisa ter sua estrutura completamente preenchida.

beneficiarios

C

Array de objetos "beneficiarios"

Array que contém todos os beneficiários vinculados ao login

Se contrato possuir tipo = "beneficiario", obrigatório ter a menos 1 registro com conteúdo válido. Caso contrário, não enviar o atributo ou preencher com o valor NULL

profissionaisSaude

C

Array de objetos "profissionalSaude"

Array que contém todos os profissionais de saúde vinculados ao login.



Se contrato possuir tipo = "profissionalSaude", obrigatório ter a menos 1 registro com conteúdo válido. Caso contrário, não enviar o atributo ou preencher com o valor NULL

contratos

M

Array de objetos "contrato"

Indique ao menos um contrato que está vinculado ao login.

Deve-se ter no mínimo 1 ocorrência válida, que tenha relação com um elemento do array "beneficiario" ou "profissionalSaude"

segmentacao

OP

Array de objetos "segmentacao”

 Array que contem informações para uso da feature de Filtro de Segmentação no Painel.

Temporariamente indisponivel

 

mosia

OP

Objeto "mosia"

Identifique os atributos que permitem ao usuário do aplicativo ser corretamente encaminhado para o atendente do MOSIA.

Preencher quando possuir o produto Mosia. Caso não tenha o produto contratado, não enviar o atributo ou preencher com o valor NULL

agenteRelacionamento

OP

Array de objetos "agenteRelacionamento"

Indique os dados de atendentes que estarão disponíveis para serem visualizados como "contatos de atentes de atendimento". 

Preencher o array com objetos do tipo "agenteRelacionamento". Se não tiver nenhum contato desse tipo, não enviar o atributo ou preencher com o valor NULL

 

Objeto “seguranca”

Atributo

Critério

Tipo 

Descrição 

Regra de preenchimento

Atributo

Critério

Tipo 

Descrição 

Regra de preenchimento

auth

M

Array de objetos “auth”

Lista parâmetros que devem ser enviados no header dos demais endpoints de integração do sistema para garantir que o beneficiário está autenticado no sistema.

Objeto auth valido

 

Objeto “auth” 

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

{ "seguranca": { "auth": [Array-objetos] }

Atributo

Critério

Tipo

Descrição

Regra de preenchimento

Atributo

Critério

Tipo

Descrição

Regra de preenchimento

chave

M

String

Nome do parâmetro no header aonde será enviado o valor da propriedade token.

 ASCII (nao permite especiais)

token

M

String

Valor do token que será enviado no header, em caso de tokens no padrão Bearer, JWT, Api-Key etc. enviar o prefixo junto do token. Ex: JWT 123xyz

Formato: Texto livre

expiracao

O

Number

Caso o token tenha data de expiração, deve ser retornado nessa propriedade o timestamp da data na qual o token irá expirar.

Timestamp (em milissegundos)

Retornar ao índice

 

Objeto “usuarioLogado”

"usuarioLogado": { "permissoes": [Array-objetos], "login": "string", "chaveUnica": "string", "contato": {objeto}, "esquemaCor": "String", "integracao": {objeto} },

Atributo

Critério

Tipo

Descrição

Regra de preenchimento

Atributo

Critério

Tipo

Descrição

Regra de preenchimento

login

M

String

A mesma informação digitada pelo usuário

 

ASCII (nao permite especiais - sem acentos, por exemplo)

chaveUnica

M

String

 Chave de identificação única de pessoa. Não deve se repetir em nenhuma hipótese, para pessoas diferentes.

Importante: caso um mesmo beneficiário esteja presente em mais de um contrato ou em mais de um grupo familiar, a chave única poderá se repetir, desde que seja o MESMO BENEFICIARIO.

É obrigatório o preenchimento deste campo:

Recomendamos o uso do CPF, pois é ÚNICO POR PESSOA, ou seja, 2 pessoas diferentes terão sempre CPFs diferentes. Porém, se a mesma pessoa tiver 2 ou mais planos, ela terá o mesmo CPF nos 2 planos, que é o desejado para este campo.

 

integracao

M

Objeto

Informações necessárias para realizar a identificação do beneficiário no sistema. Deve existir um objeto idêntico para um dos beneficiários no array "beneficiarios" para que seja feita a identificação de qual usuário está logado.

Não possui regra de preenchimento, pode ser enviada qualquer estrutura desde que seja uma estrutura JSON valida

contato

M

Objeto "contato”

 

 

esquemaCor

OP

String

O aplicativo pode ter uma customização de cores diferente do padrão, caso deseja que um usuário tenha essa customização, bastar criar um esquema de cor no configurador de aplicação definindo um nome para o esquema e cadastrando novas cores. Informe nesse campo o nome do apelido que foi gerado ao criar um novo esquema de cor.

Ex: Ao criar um esquema de cor e definindo um nome de "Esquema Premium", o apelido gerado será "esquema-premium". Informe esse apelido nesse campo.

A string deve ser a mesma que o apelido gerado na opção de esquema de cor no configurador de aplicação, caso tenha definido um esquema de cor que não existe, o aplicativo irá usar as cores padrão.

permissoes

OP

Array de objeto "permissoes"

 

Objetos válidos relacionados às funções do app contratado.

 

Objeto “contato”

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

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

"usuarioLogado": { "contato": { "email": "string", "telefoneCelular": "string", "telefoneFixo": "string" } }

Atributo

Critério

Tipo

Descrição

Regra de preenchimento

Atributo

Critério

Tipo

Descrição

Regra de preenchimento

email

OP

String

Indique o email do usuario logado

Email precisa ser válido 

telefoneCelular

OP

String

Indique o telefone celular do usuário logado

 

Tamanho mínimo / máximo 11 posições. Somente números

telefoneFixo

OP

String

Indique o telefone fixo do usuário logado

Tamanho mínimo 10 / máximo 11 posições. Somente números

 

Objeto “integracao”

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

  • Não possui regra de preenchimento;

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

"usuarioLogado": { "integracao": { "xpto": "voluptatibus", "xyz": "quibusdam", "abcdef": 9288701 } }

 

Objeto “permissoes”

Mobile Saúde - Mosia Omnichannel