A integração inicia com o cadastro do médico, que é obrigatório para utilizar a Memed.

Veja um exemplo de REQUEST para a nossa API

curl -X POST \
  'https://DOMINIO_API_MEMED/v1/sinapse-prescricao/usuarios?api-key=API-KEY&secret-key=SECRET-KEY' \
  -H 'Accept: application/vnd.api+json' \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json' \
  -d '{
        "data": {
         "type": "usuarios",
          "attributes": {
              //ID para vincularmos o médico ao parceiro (obrigatório)
              // Pode ser um documento criptografado por exemplo.
              "external_id": ID_EXTERNO,
              // Nome do Médico (obrigatório)
              "nome": "José",
              // Sobrenome do Médico (Obrigatório)
              "sobrenome": "da Silva",
              // Data de nascimento (recomendado, não obrigatório)
              "data_nascimento": "01/01/1985",
              // CPF do Médico (recomendado, não obrigatório)
              "cpf": "000.000.000-00",
              // Email do Médico (recomendado, não obrigatório)
              "email": "meu@email.com.br",
              // Estado onde o CRM está cadastrado (obrigatório se informado o CRM)
              "uf": "SP",
              // Sexo (recomendado, não obrigatório)
              "sexo": "M",
              // CRM (recomendado, não obrigatório)
              "crm": "54321"
          },
          "relationships": {
          // Cidade do profissional (recomendado, não obrigatório)
           "cidade": {
              "data": { "type": "cidades", "id": "5213" }
            },
            // Especialidade do profissional: Clínica médica, Oftalmologia, etc. (recomendado para otimizarmos nossa busca)
           "especialidade": {
              "data": { "type": "especialidades", "id": "50" }
            }
          }
        }
 }'

Obs.: Embora o CRM e a data de nascimento não sejam obrigatórios, ressaltamos a importância de serem informados corretamente. Nossa API realiza a validação dos dados do médico junto ao CFM e, caso haja alguma inconsistência, o cadastro permanecerá inativo na nossa base até o ajuste dos dados.

Veja abaixo uma descrição de cada atributo

Atributos do usuário:

external_id - Identificador externo usado na sincronização
nome - Nome do usuário (apenas o primeiro nome)
sobrenome - Sobrenome do usuário
data_nascimento - Data de nascimento do usuário, no padrão brasileiro (DD/MM/YYYY)
cpf - CPF do usuário, com pontuação (XXX.XXX.XXX-XX)
crm - CRM do usuário, somente números
uf - UF do usuário (onde o CRM está cadastrado)
email - E-mail do usuário
sexo - Sexo do usuário (M ou F)

Relacionamentos do usuário:

cidade (relationships.cidade.id) - ID da cidade que o usuário atende
especialidade (relationships.especialidade.id) - ID da especialidade do usuário

Obs.: Para encontrar os IDs da cidade e da especialidade, é necessário fazer dois requests:

O retorno seguirá a estrutura a seguir

{
    "data": {
        "type": "usuarios",
        "attributes": {
            "nome": "FULANO",
            "data_nascimento": "18/06/1968",
            "sobrenome": "DA SILVA",
            "cpf": "12312312300",
            "email": "seu@email.com",
            "sexo": "M",
            "terms_accepted": false,
            "status": "Em análise",
            "cidade": "São Paulo",
            "clinica_ativa": "",
            "cns": null,
            "cnes": "",
            "configuracoes": [],
            "crm": "4321",
            "endereco": "",
            "especialidade": "Neurologia pediátrica",
            "estudante": false,
            "farmacia_artesanal": false,
            "iamspe": false,
            "is_partner": true,
            "nome_completo": "FULANO DA SILVA",
            "perola_byington": false,
            "sociedades": "",
            "telefone": null,
            "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
            "uf": "SP",
            "universidade": "",
            "fabricante": "",
            "user_type": "Medicos",
            "total_of_prescriptions": 0,
            "total_of_prescripted_drugs": 0,
            "total_of_sms_prescriptions": 0,
            "avatar": "",
            "ambiente": "any",
            "is_editor": false,
            "user_name": false,
            "biografia": "",
            "imagem_capa": "",
            "synchronized": false,
            "percentage_of_completed_profile": 66.66
        },
        "links": {
            "self": "http://local.api.memed.com.br/v1/usuarios/31567"
        },
        "relationships": {
            "cidade": {
                "data": {
                    "id": 5213,
                    "type": "cidades"
                },
                "links": {
                    "self": "http://local.api.memed.com.br/v1/sinapse-prescricao/usuarios/relationships/cidade"
                }
            },
            "sociedades": {
                "data": [],
                "links": {
                    "self": "http://local.api.memed.com.br/v1/sinapse-prescricao/usuarios/relationships/sociedades"
                }
            },
            "especialidade": {
                "data": {
                    "id": 62,
                    "type": "especialidades"
                },
                "links": {
                    "self": "http://local.api.memed.com.br/v1/sinapse-prescricao/usuarios/relationships/especialidade"
                }
            },
            "universidade": null
        },
        "id": 31567
    },
    "links": {
        "self": "http://local.api.memed.com.br/v1/usuarios/31567"
    }
}

Obs.: O token retornado no payload após o cadastro do usuário pode ser persistido de forma segura no seu banco de dados. Caso ocorra alguma atualização nos dados cadastrais, um novo token pode ser gerado.

Como proceder?

  • Você deve sempre comparar se o token que possui ainda é válido (comparar token atual com token retornado pela API da Memed). 
  • Caso o token esteja divergente, é preciso atualizá-lo na sua base de dados.
  • Um outro ponto que recomendamos é criticar se o token retornado pela API Memed corresponde ao usuário logado no sistema do parceiro. Imagine que o médico A está autenticado no sistema de vocês e que o GET para a API Memed é feito usando o external_id do médico B, por exemplo. Se isso ocorrer, ocorrerá um falso-positivo de mudança de token, pois a API Memed retornará um token diferente. Para contornar essa situação, basta comparar o conteúdo do token JWT que vocês possuem com o retornado pela API Memed. Dessa forma, vocês podem identificar se o ID do usuário/médico Memed retornado no token é o mesmo do token que vocês já possuem.

É possível consultar os dados do usuário/médico, recuperar o token e usar em tempo real para autenticação na plataforma Memed.

Leitura recomendada:



Estamos à disposição para eventuais dúvidas no chat!

Encontrou sua resposta?