ETL e suas regras
Premissas
São premissas do ETL - Evolução Multisistemas e por lote:
- Os dados dos sistemas de origem serão enviados para o Q-ware onde será feito o ETL para carregar os dados no CMD conforme layout definido pela área demandante;
- As informações poderão ser incluídas com os contatos assistenciais até 12 meses após o mês de admissão do contato;
- A migração dos dados advindos dos sistemas de origem será executada e endereçada em lotes;
- O controle dos lotes deverá ser feito pelo sistema de origem;
- As chaves dos registros oriundos dos sistemas de origem deverão respeitar unicidade, sempre, independente de reenvio do registro no mesmo ou em outro lote;
- A periodicidade poderá ser quinzenalmente, podendo alterar o parâmetro;
- O UUID deverá ser gerado pelos sistemas de origem do CMD seguindo os padrões da RFC versão 4;
- Os arquivos gerados pelos sistemas de origem deverão ser disponibilizados no Qware;
- Em caso de erro, será gerado um retorno vinculando ao UUID com o código e a descrição do erro ao sistema de origem, conforme detalhado a seguir:
Regra - CONTATO ASSISTENCIAL- NÚMERO DE IDENTIFICAÇÃO (WebService e ETL)
O número de identificação de um registro de contato assistencial será o código UUID, versão 4, padrão RFC. Para mais informações consultar as especificações do UUID no link a seguir:
https://www.ietf.org/rfc/rfc4122.txt
Deverá ser realizada a verificação do código do contato assistencial, se o mesmo existe na base de dados do CMD e se está de acordo com a máscara especificada acima.
Caso seja solicitado uma inclusão e o código já exista ou seja inválido, emitir mensagem de erro ao usuário.
Caso seja solicitado uma alteração e o código não exista ou seja inválido, emitir mensagem ao usuário.
Integração de Dados
Os registros candidatos a integração, serão entregues pelas pontas, atendendo as regras de um layout específico.
Para a importação das informações dos sistemas das pontas para a base nacional do CMD, os Contatos Assistenciais deverão ser enviados em quatro (4) visões, conforme descrito a seguir:
- Contato assistencial
Campo: UUID
Tipo de dados: Caracteres alfanuméricos
Tamanho: 36
Obrigatoriedade: Sim (chave primária)
Regra: Código único e inalterável utilizado na própria base de dados para identificar o contato assistencial. Ao final do processo de ETL será atribuída uma UUID (chave única utilizada em cada contato assistencial do CMD) a cada código enviado, ou as mensagens de rejeição, se não for possível gerar um contato assistencial com os dados enviados. Este código nunca poderá sofrer mudança, pois é utilizado para identificar operações de alteração.
Domínio: -
Campo: SG_SISTEMA_ORIGEM
Tipo de dados: Caractere Alfanumérico
Tamanho: 2
Obrigatoriedade: Sim
Regra: Sigla que identifica o sistema de origem.
Domínio: -
Campo: NO_SISTEMA_ORIGEM
Tipo de dados: Caracteres alfanuméricos
Tamanho: 20
Obrigatoriedade: Sim
Regra: Nome do sistema de origem.
Domínio: -
Campo: CO_CNES_CONTATO
Tipo de dados: Caracteres alfanuméricos
Tamanho: 7
Obrigatoriedade: Sim
Regra: Número do Cadastro Nacional de Estabelecimentos de Saúde (CNES) onde o contato assistencial foi realizado.
Domínio: -
Campo: DT_ADMISSAO
Tipo de dados: Data
Tamanho: -
Obrigatoriedade: Sim
Regra: Data de início do contato assistencial.
Domínio: -
Campo: DT_CADASTRO
Tipo de dados: Data
Tamanho: -
Obrigatoriedade: Não
Regra: Data de cadastro no banco de dados da stage.
Domínio: -
Campo: CO_PROCEDENCIA
Tipo de dados: Caracteres alfanuméricos
Tamanho: 2
Obrigatoriedade: Sim
Regra: Procedência o indivíduo do contato assistencial, identifica o tipo de serviço que encaminhou o indivíduo ou a sua iniciativa/de seu responsável na busca pelo acesso ao serviço de saúde.
Domínio: a ser validado no SIGTAP/RTS
Campo: CO_MODALIDADE
Tipo de dados: Caracteres alfanuméricos
Tamanho: 2
Obrigatoriedade: Sim
Regra: Modalidade do contato assistencial, classifica os contatos assistenciais de acordo com as especificidades do modo, local e duração do atendimento.
Domínio: a ser validado no SIGTAP/RTS
Campo: CO_CARATER_ATENDIMENTO
Tipo de dados: Caracteres alfanuméricos
Tamanho: 2
Obrigatoriedade: Sim
Regra: Caráter do atendimento do contato assistencial, identifica a prioridade de realização do contato assistencial.
Domínio: a ser validado no SIGTAP/RTS
Campo: CO_DESFECHO
Tipo de dados: Caracteres alfanuméricos
Tamanho: 2
Obrigatoriedade: Sim
Regra: Motivo do desfecho do contato assistencial, caracteriza o motivo de conclusão total ou parcial do contato assistencial.
Domínio: a ser validado no SIGTAP/RTS
Campo: DT_DESFECHO
Tipo de dados: Data
Tamanho: -
Obrigatoriedade: Não
Regra: Data de finalização do contato assistencial, não preencher se o CO_DESFECHO for 07 - Permanência. Neste caso, o contato assistencial foi enviado parcialmente e seu envios futuros terão a complementação das informações.
Domínio: -
Campo: ST_REGISTRO_ATIVO
Tipo de dados: Caractere
Tamanho: 1
Obrigatoriedade: Sim
Regra: Identifica a operação a ser realizada com o contato assistencial.
Domínio: S: Inclusão ou Alteração N: Cancelamento (exclusão)
Campo: CO_SEXO
Tipo de dados: Caracteres alfanuméricos
Tamanho: 1
Obrigatoriedade: Sim
Regra: Sexo do indivíduo do contato assistencial.
Domínio: a ser validado no CNS
Campo: NU_CNS_INDIVIDUO
Tipo de dados: Caracteres alfanuméricos
Tamanho: 15
Obrigatoriedade: Não
Regra: obrigatório se CO_JUSTIFICATIVA_AUSENCIA_CNS for NULL.
Campo: CO_JUST_AUSENCIA_CNS
Tipo de dados: Caracteres alfanuméricos
Tamanho: 2
Obrigatoriedade: Não
Regra: Preenchido quando não for possível identificar o indivíduo ou o CNS não estiver preenchido no modelo de origem.
Domínio: a ser validado no SIGTAP/RTS
Campo: DT_NASCIMENTO
Tipo de dados: Data
Tamanho: -
Obrigatoriedade: Sim
Regra: Data de nascimento, preencher somente se o indivíduo não possuir o número do CNS e, neste caso, é admitido utilizar apenas a informação do ano estimado de nascimento, quando não for possível identificar o indivíduo (CO_JUSTIFICATIVA_AUSENCIA_CNS está preenchido).
Domínio: -
- Procedimentos do contato assistencial
