Regras e Critérios de Migração
Publicado em
06/04/2021 11h07
Regras de Adaptação da base de dados atual de Beneficiários para o SIB.XML - versão 1.0 Arquivo de Conferência Especial – ARQCONF.MIG
Objetivo
O objetivo do presente documento é descrever as regras e critérios adotados no processo de migração dos registros de dados do atual cadastro de beneficiários das operadoras na ANS para o novo cadastro de beneficiários, que constituirá a base de dados do Sistema de Informações de Beneficiários sob o formato.XML (SIB.XML). O resultado desse processo está registrado em uma edição especial do Arquivo de Conferência, o qual está disponível para download pelas operadoras por meio do aplicativo PTA.
O processo de migração foi necessário para se promover a adequação do cadastro de beneficiário às disposições da Resolução Normativa nº 250/2011 e da Instrução Normativa nº 46/DIDES/2011, que regulamentam os procedimentos de atualização cadastral. Além disso, objetivou promover a limpeza, no cadastro, de campos de dados não mais utilizados ou com conteúdos que não atendem aos critérios de preenchimento.
Procedimentos de Migração
- A ANS disponibilizará para cada operadora um arquivo de conferência especial com o resultado da migração, em formato.XML, por meio do canal PTA, contendo o prefixo MIG nome do arquivo, atualizado até a competência maio de 2011.
- As operadoras devem realizar os respectivos downloads e conferirem com a base de dados da operadora.
- As operadoras devem verificar a existência de registros de dados de beneficiários inconsistentes, incompletos ou incoerentes em desacordo com as normas estabelecidas na Instrução Normativa vigente, e procederem à devida retificação.
- A base de dados contida no Arquivo de Conferência Especial passa a ser a referência para o processamento dos arquivos de atualização cadastral gerados pelas operadoras no formato XML, a partir de 6 de junho de 2011.
- No processo de migração, os atributos, relacionados a seguir, estão sendo submetidos à rotina de eliminação de espaços em branco – tanto antes quanto após o conteúdo – quando houver. Além da rotina de eliminar espaços em branco, estão sendo contemplados com o preenchimento de zeros, que são considerados como significativos, ou seja, fazem parte do domínio do atributo.
- CPF do beneficiário,
- PIS do beneficiário,
- Número do Cartão Nacional de Saúde,
- CEP,
- Número do Plano registrado na ANS (RPS),
- Código do Plano cadastrado na ANS (SCPA),
- Número do código de origem (portabilidade),
- CNPJ da empresa contratante,
- CEI da empresa contratante,
- Nome do beneficiário,
- Nome da mãe do beneficiário,
- Número do logradouro de residência,
- Complemento do logradouro,
- Bairro do logradouro do beneficiário.
- Na Tabela 1 - Campos de dados não migrados para o Cadastro de Beneficiários do SIB.XML, são relacionados os campos de dados existentes no atual cadastro de beneficiários que não foram migrados por não fazerem parte dos procedimentos de atualização cadastral definidos no SIB.XML.
- Na Tabela 2 - Campos de dados adaptados para o Cadastro de Beneficiários do SIB.XML, são relacionados os nomes dos campos de dados que compõem o registro de dados de beneficiário que se encontra armazenado no atual cadastro de beneficiários da operadora na ANS (Origem - Nome de campo) e a sua correspondência no cadastro de beneficiários do SIB.XML (Destino - Nome do campo), bem como as regras de preenchimento que foram aplicadas ao campo.
Tabela 1 - Campos de dados NÃO migrados para o Cadastro de Beneficiários do SIB.XML
| Seq. | Nome do campo |
|---|---|
| 1 | Carteira de Identidade do Beneficiário |
| 2 | Órgão emissor da carteira de identidade do beneficiário |
| 3 | Código do país emissor da carteira de identidade do beneficiário |
| 4 | Abrangência geográfica |
| 5 | Tipo de contratação |
| 6 | Co-participação |
| 7 | Código do motivo de inclusão |
| 8 | UF |
| 9 | Código de motivo de inclusão do contrato do beneficiário |
| 10 | Código de motivo de alteração do contrato do beneficiário |
Tabela 2 - Procedimentos adotados no processo de migração do Cadastro de Beneficiários do SIB.XML
| Seq. | Origem | Destino | Regras |
|---|---|---|---|
| Nome do campo | Nome do campo | ||
| 1 | CCO - Código de Controle Operacional | CCO - Código de Controle Operacional | O movimento de migração ocorrerá sem modificar o conteúdo do campo |
| 2 | Indicador de registro ativo ou inativo | Situação | Informa se o registro do beneficiário se encontra ativo ou inativo. |
| 3 | Sem correspondência | Data da atualização | Campo novo, não há migração, informa a data em que o arquivo de atualização de dados foi processado e armazenado no cadastro do sistema. |
|
Identificação |
|||
| 4 | CPF do beneficiário | CPF do beneficiário |
O movimento para a tabela SIB ocorrerá da seguinte maneira: Se o atributo estiver preenchido e o dígito verificador estiver correto e o atributo não for CPF "viciado" então mover o campo. Se (o atributo estiver preenchido e o DV estiver incorreto) ou (o conteúdo do atributo for CPF "viciado") então apagar o conteúdo do campo. |
| 5 | Sem correspondência | DN – declaração de Nascido Vivo | Campo novo, não há migração, será preenchido com base nas instruções de preenchimento do campo contidas nas normas do SIB.XML vigentes. |
| 6 | PIS/PASEP do beneficiário | PIS/PASEP do beneficiário |
PIS/PASEP do beneficiário O movimento de migração ocorrerá da seguinte maneira: Migrar para a tabela SIB somente se o atributo estiver preenchido e o dígito verificador estiver correto. Se o atributo estiver preenchido e o DV estiver incorreto então preencher o campo com nulos. |
| 7 | CNS - Cartão Nacional de Saúde do beneficiário | CNS - Cartão Nacional de Saúde do beneficiário |
O movimento de migração ocorrerá da seguinte maneira: Migrar para a tabela SIB somente se o atributo estiver preenchido e o dígito verificador estiver correto. Se o atributo estiver preenchido e o DV estiver incorreto então preencher o campo com nulos. |
| 8 | Nome de beneficiário | Nome do beneficiário | Antes de ser migrado, serão eliminados os espaços em branco à esquerda e à direita, caso existam. |
| 9 | Sexo do beneficiário | Sexo - Código do Sexo do beneficiário |
O movimento de migração ocorrerá da seguinte maneira: Todo o conteúdo deve ser migrado, observando: "1" --> "1"; "3" --> "3"; "2" --> "3"; "S" --> "3". |
| 10 | Data de nascimento do beneficiário | Data de nascimento do beneficiário |
Quando a data de nascimento for anterior a 01/01/1890 então anulá-la e registrar a mudança do atributo em variável específica. Quando a data de nascimento for posterior à data da primeira contratação então anulá-la e registrar a mudança do atributo em variável específica. Se a data de nascimento estiver preenchida e for posterior ou igual a 01/01/1890 e anterior ou igual à data da primeira contratação então é considerada coerente e deve ser migrada do jeito que se encontra atualmente. |
| 11 | Nome da Mãe | Nome da Mãe do beneficiário | No atributo Nome de mãe de beneficiário, quando preenchido, antes de ser migrado, serão eliminados os espaços em branco à esquerda e à direita, caso existam. |
|
Endereço |
|||
| 12 | Logradouro de residencial do beneficiário | Logradouro de residencial (ou profissional) do beneficiário | O movimento de migração ocorrerá sem modificar o conteúdo do campo. |
| 13 | Número do Logradouro | Número do Logradouro | O movimento de migração ocorrerá sem modificar o conteúdo do campo. |
| 14 | Complemento do Logradouro | Complemento do Logradouro | O movimento de migração ocorrerá sem modificar o conteúdo do campo. |
| 15 | Bairro do logradouro do beneficiário | Bairro | O movimento de migração ocorrerá sem modificar o conteúdo do campo. |
| 16 | Sem correspondência | Código do município, se indicado como profissional | Campo novo, não há migração, será preenchido com base na tabela de municípios do IBGE. |
| 17 | Código do Município de residência do beneficiário | Código do Município residencial |
O movimento de migração ocorrerá da seguinte maneira: Quando o código IBGE estiver preenchido no cadastro do sistema e existir na tabela de municípios do IBGE ou o código do município do IBGE não estiver preenchido, mas o nome da cidade e o código da UF estiverem preenchidos e forem encontrados na tabela de sinônimo de município mover o código. Quando o código do município do IBGE e o nome da cidade não estiverem preenchidos, o código da UF estiver preenchido e for encontrado na tabela de municípios do IBGE mover o código até o nível de UF. Quando o código IBGE não existir na tabela de municípios do IBGE mover NULOS. |
| 18 | CEP - Código do Endereçamento Postal | CEP | O movimento de migração ocorrerá sem modificar o conteúdo do campo. |
| 19 | Sem correspondência | Tipo de endereço - Indicação de endereço residencial ou profissional | Campo novo, não há migração, preencher com NULOS. |
| 20 | Indicação se a residência do beneficiário é no Brasil ou no exterior | Reside Exterior - Indicação se a residência do beneficiário é no Brasil ou no exterior |
Quando o conteúdo do código de UF for “EX” preencher com a indicação de que o beneficiário reside no exterior. Nesse caso, todos os dados referentes a endereço do beneficiário serão anulados. Quando o conteúdo do código de UF for diferente de “EX” proceder:
|
|
Vínculo Contratual |
|||
| 21 | Código de identificação de beneficiário na operadora | Código do Beneficiário - Código de identificação de beneficiário na operadora | Antes de ser migrado, serão eliminados os espaços em branco à esquerda e à direita, caso existam. Em caso de ocorrer coincidência de código de identificação após o processo de eliminação dos espaços em branco, os registros serão migrados – caso não haja erro fatal nos demais atributos - cabendo à operadora, a posteriori, proceder a modificação de um deles. |
| 22 | Relação de Dependência | Relação de Dependência |
O movimento de migração ocorrerá da seguinte maneira: "01" --> "01"; "02" --> (NULO); "03" --> "03"; "04" --> "04"; "05" --> "04"; "06" --> "06"; "07" --> "06"; "08" --> "08"; "09" --> "08"; "10" --> "10"; "11" --> "01"; "brancos ou nulo" --> (NULO) Quando o código for diferente de 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 e 11 então migrar o atributo ID_TIPO_DEPENDENTE com nulo. |
| 23 | Código de Identificação de beneficiário titular do plano na operadora para beneficiários informados como dependentes (não titulares) | CCO do Beneficiário Titular - Código de Identificação de beneficiário titular do plano na operadora para beneficiários informados como dependentes (não titulares) |
O movimento de migração ocorrerá da seguinte maneira: Quando o Código de identificação de beneficiário titular do plano na operadora para beneficiários informados como dependentes (não-titulares) não estiver preenchido então migrar com o conteúdo nulo; Quando o conteúdo for nulo então migrar com conteúdo nulo; Quando o conteúdo for igual a 1 (titular) então migrar com o conteúdo nulo; Quando o conteúdo for diferente de nulo e diferente de 1 (titular) então verificar se o Código de identificação de beneficiário titular do plano na operadora para beneficiários informados como dependentes (não-titulares) existe e se está associado à mesma operadora (raiz CNPJ) e se o beneficiário a ele vinculado é titular. Se não houver estas vinculações então migrar com o conteúdo nulo. Se houver mais de um registro associado a estas vinculações então migrar com o conteúdo. |
| 24 | Data de Adesão do Plano | Data de Contratação do Plano |
O movimento de migração ocorrerá da seguinte maneira: Se a data de adesão for anterior a 01/01/1940 então migrar o conteúdo com “01/01/1940”. Se a data de adesão for superior à data de inclusão no Cadastro de Beneficiários então migrar com o conteúdo da data de inclusão. Se a data de adesão não for anterior a 01/01/1940 e não for superior à data de inclusão então migrar com o conteúdo da data de adesão. Se o beneficiário não realizou mudança contratual (adaptação, migração ou mudança de contrato) e nem portabilidade interna (na própria operadora) então a data de contratação é migrada com o mesmo conteúdo da data de primeira contratação, senão a migração será realizada com a data de adequação ao plano. |
| Data de Adaptação, migração, mudança ou portabilidade de plano |
O movimento de migração ocorrerá da seguinte maneira: Se a data de adaptação ao plano estiver preenchida e for posterior à data da contratação, após ter sido tratada, então migrar com o conteúdo da data de adequação ao plano. Se a data de adaptação o ao plano estiver preenchida e for anterior ou igual à data da primeira contratação, após ter sido tratada, então migrar com o conteúdo da data de contratação. |
||
| 25 | Data de reativação | Data de Reativação |
O movimento de migração ocorrerá da seguinte maneira: Se a data de cancelamento for nula então anular a data de reativação e registrar a anulação em variável específica. Este campo será tratado pela função trunc. Se a data de cancelamento estiver preenchida e se a data de reativação estiver nula e a situação do beneficiário for ativa então migrar a data de reativação com o conteúdo da data de cancelamento e registrar a atribuição em variável específica. Se a data de cancelamento estiver preenchida e se a data de reativação não estiver nula e a situação do beneficiário for ativa e se a data de reativação for anterior à data de cancelamento ou posterior à data de fim de competência então migrar a data de reativação com o conteúdo da data de cancelamento e registrar a atribuição em variável específica. Se a data de cancelamento estiver preenchida e se a data de reativação não estiver nula e a situação do beneficiário for inativa e se a data de reativação for posterior à data de cancelamento ou anterior à data de contratação então migrar a data de reativação com o conteúdo da data de cancelamento e registrar a atribuição em variável específica. |
| 26 | Data de cancelamento | Data de Cancelamento do Plano contratado |
O movimento de migração ocorrerá da seguinte maneira: Se a data de cancelamento estiver preenchida e for posterior à data de fim de competência e a situação da operadora estiver ATIVA, então anular as datas de cancelamento e de exclusão e tornar o beneficiário ativo. Se a data de cancelamento estiver preenchida e for posterior à data de fim de competência e a situação da operadora estiver INATIVA, então a data de cancelamento recebe a data de descredenciamento da operadora e torna o beneficiário INATIVO. Se a data de cancelamento estiver preenchida e for anterior ou igual à data de fim de competência e a data de cancelamento for anterior à data de contratação (após ter sido tratada) e a situação do beneficiário estiver ATIVA (após ter sido tratada), então anular as datas de cancelamento e de exclusão. Se a data de cancelamento estiver preenchida e for anterior ou igual à data de fim de competência e é anterior à data de contratação (após ter sido tratada) e a situação do beneficiário estiver INATIVA (após ter sido tratada), então as datas de cancelamento e de exclusão recepcionam a data de contratação. Se a data de cancelamento estiver preenchida e for anterior ou igual à data de fim de competência e for anterior à data de contratação (após ter sido tratada) e a situação do beneficiário estiver INATIVA (após ter sido tratada) então a data de cancelamento recepciona a data de cancelamento no cadastro de beneficiário. Se a data de cancelamento estiver preenchida e for anterior ou igual à data de fim de competência e for anterior à data de contratação (após ter sido tratada) e a situação do beneficiário estiver INATIVA (após ter sido tratada) e então a data de cancelamento recepciona a data de contratação Se a data de cancelamento for nula, então estabelecer a situação do beneficiário como ativo. |
| 27 | Motivo de cancelamento | Motivo de cancelamento |
O movimento de migração ocorrerá da seguinte maneira: Quando o código for igual a 1 então migrar o atributo com “41”; Quando o código for igual a 2 então migrar o atributo com “41”; Quando o código for igual a 3 então migrar o atributo com “42”; Quando o código for igual a 4 então migrar o atributo com “43”; Quando o código for igual a 5 então migrar o atributo com “44”; Quando o código for igual a 8 então migrar o atributo com “45”; Quando o código for igual a 10 então migrar o atributo com “72”; Quando o código for igual a 13 então migrar o atributo com “46”; Quando o código for igual a 14 então migrar o atributo com “47”; Quando o código for igual a 32 então migrar o atributo com “41”; Quando o código for igual a 42 então migrar o atributo com “48”. Quando o código for igual a 7, 9 ou 13 e o registro estiver “inativo” então o registro não será migrado; Quando o código for igual a 7, 9 ou 13 e o registro estiver “ativo” então anular o código de motivo de cancelamento e registrar em variável específica que o conteúdo do campo foi modificado; Quando o código for igual a 6, 11, 12, 52 ou 99 então anular o código de motivo de cancelamento e registrar em variável específica que o conteúdo do campo foi modificado; Quando o código for igual a nulo então migrar o atributo com o conteúdo nulo; Quando a data de cancelamento for nula então anular o código do motivo de cancelamento e registrar em variável específica que o conteúdo do campo foi modificado. |
| 28 | Número do Código do plano registrado na ANS (RPS) | Número do plano da operadora – número do plano registrado na ANS (RPS) |
Os movimentos de migração dos três campos RPS, SCPA e Número do Plano de Origem serão analisados em conjunto e observará o que se segue: Se o atributo número de plano RPS estiver preenchido e válido, ou seja, existir na Tabela de Planos Registrados na ANS, então o atributo número de plano RPS será migrado e o atributo número de plano SCPA, se o número de plano de portabilidade estiver preenchido e for igual ao número de plano RPS então anula-lo. Se o atributo número de plano SCPA estiver preenchido e válido e o atributo número de plano RPS não estiver preenchido ou estiver preenchido e inválido então anular o atributo número de plano RPS e o atributo número de plano de portabilidade. Se o atributo número de plano de portabilidade estiver preenchido e o atributo número de plano RPS estiver preenchido e válido e o atributo tipo de contratação do número de RPS for individual ou familiar então migrar o número de plano de portabilidade. Em caso contrário, anulá-lo. |
| 29 | Número do Plano de origem | Número do plano de portabilidade registrado na ANS (RPS) | Os movimentos de migração dos três campos RPS, SCPA e Número do Plano de Origem serão analisados em conjunto e observará o descrito na sequência 21 relativa ao campo Número do Código do plano registrado na ANS (RPS). |
| 30 | Código do Plano da operadora cadastrado na ANS (SCPA) | Código do Plano da operadora cadastrada na ANS (SCPA) | Os movimentos de migração dos três campos RPS, SCPA e Número do Plano de Origem serão analisados em conjunto e observará o descrito na sequência 21 relativa ao campo Número do Código do plano registrado na ANS (RPS). No caso, a validação do SCPA será realizada pela verificação de sua existência na Tabela de Planos Antigos Cadastrados na ANS. |
| 31 | Indicação de existência de Cobertura Parcial | Indicação de existência de Cobertura Parcial |
O movimento de migração ocorrerá da seguinte maneira: "0" --> (NULO); "1" --> “1”; "2" --> "0"; " " --> (NULO) |
| 32 | Indicação de itens de procedimentos excluídos da cobertura | Indicação de itens de procedimentos excluídos da cobertura |
O movimento de migração ocorrerá da seguinte maneira: "1" --> “1”; "2" --> "0"; " " --> (NULO). |
| 33 | CNPJ da empresa a qual o beneficiário | CNPJ da empresa a qual o beneficiário está vinculado |
Para fins de migração, os atributos CNPJ e CEI de empresa contratante serão analisados em conjunto e deve ser observado o que segue: Se não houver informação de planos, ou seja, número de plano RPS e número de plano SCPA não estiverem preenchidos então anular os atributos de CNPJ e de CEI. Se houver informação de plano RPS ou SCPA e o tipo de contratação for individual ou familiar então anular os atributos de CNPJ e de CEI. Se houver informação de plano RPS ou SCPA e o tipo de contratação não for individual ou familiar e o CNPJ estiver preenchido, porém inválido, então anular o atributo CNPJ. Se houver informação de plano RPS ou SCPA e o tipo de contratação não for individual ou familiar e o CEI estiver preenchido, porém inválido, então anular o atributo CEI. Se houver informação de plano RPS ou SCPA e o tipo de contratação não for individual ou familiar e o CNPJ estiver preenchido e válido, então anular o atributo CEI. Se houver informação de plano RPS ou SCPA e o tipo de contratação não for individual ou familiar e o CNPJ não estiver preenchido ou estiver preenchido e inválido e o CEI estiver preenchido e válido então anular o atributo CNPJ. |
| 34 | CEI da empresa a qual o beneficiário está vinculado. | CEI da empresa a qual o beneficiário está vinculado. | Para fins de migração, os atributos CNPJ e CEI de empresa contratante serão analisados em conjunto e deve ser observado o descrito na seqüência 18 -CNPJ da empresa a qual o beneficiário está vinculado. |