ETL e suas regras
Índice
CMD - REGRAS DE NEGÓCIO DA ETL
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 e também será implementado pela equipe da ETL;;
- 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;
- A equipe de desenvolvimento deverá ter acesso de leitura e escrita na base de dados do CMD;
- 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 à integração serão entregues pelas áreas competentes, 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
| Campo: UUID
Tipo de dados: Caracteres alfanuméricos Tamanho: 36 Obrigatoriedade: Sim (chave primária) Regra: Código utilizado na própria base de dados do sistema de origem. 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. Domínio: - |
Campo: CO_TERMINOLOGIA_PROCEDIMENTO
Tipo de dados: Caracteres alfanuméricos Tamanho: 100 Obrigatoriedade: Sim Regra: Identificador da terminologia que será utilizada para informar o (s) procedimento (s) realizado (s). Domínio: 2.16.840.1.113883.2.21.1.123 - CBHPM 2.16.840.1.113883.2.21.1.122 - TUSS 2.16.840.1.113883.2.21.1.121 - Tabela SUS |
Campo: NU_VERSAO_TERMINOLOGIA
Tipo de dados: Caracteres alfanuméricos Tamanho: 9 Obrigatoriedade: Sim Regra: Identificador da edição da terminologia utilizada para descrever o procedimento realizado no formato AAAAMMDDL (L é uma letra na sequência do alfabeto caso exista mais de um versionamento da terminologia no mesmo dia). Utilizar 01 como mês e dia e A como a letra quando a terminologia não possuir esta informação. Exemplos de mais de uma versão no dia: 20171003A, 20171003B; mais de uma versão no mês em dias diferentes: 20171003A, 20171004A; uma única versão no mês: 20171001A. Domínio: a ser validado no SIGTAP/RTS. |
Campo: NU_PROCEDIMENTO
Tipo de dados: Caracteres alfanuméricos Tamanho: 10 Obrigatoriedade: Sim Regra: Procedimento realizado. Domínio: a ser validado no SIGTAP/RTS. |
| Campo: DT_REALIZACAO
Tipo de dados: Data Tamanho: Obrigatoriedade: Sim Regra: Data que o procedimento foi realizado Domínio: - |
Campo: QT_PROCEDIMENTO
Tipo de dados: Caracteres alfanuméricos Tamanho: 3 Obrigatoriedade: Sim Regra: Número de vezes que o procedimento foi realizado na data informada. Domínio: - |
Campo: NU_AUTORIZACAO
Tipo de dados: Caracteres alfanuméricos Tamanho: 14 Obrigatoriedade: Não Regra: Informar o código de autorização quando o procedimento tiver exigido para sua realização. Domínio: - |
Campo: CO_FINANCIAMENTO
Tipo de dados: Caracteres alfanuméricos Tamanho: 2 Obrigatoriedade: Sim Regra: Financiamento, terminologia que descreve o agente, instituição ou entidade responsável por custear as ações e serviços de saúde. Domínio: a ser validado no SIGTAP/RTS. |
- Profissional (is) que realizou (aram) o procedimento (vw_profissionais_procedimentos)
| Campo: UUID
Tipo de dados: Caracteres alfanuméricos Tamanho: 36 Obrigatoriedade: Sim (chave composta) Regra: Código utilizado na própria base de dados do sistema de origem. 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. Domínio: - |
Campo: CO_PROCEDIMENTO
Tipo de dados: caracteres alfanuméricos Tamanho: 10 Obrigatoriedade: Sim (chave composta) Regra: Procedimento realizado na vw_procedimentos |
Campo: CO_CBO
Tipo de dados: Caracteres alfanuméricos Tamanho: 6 Obrigatoriedade: Sim Regra: Código da ocupação, conforme Classificação Brasileira de Ocupações (CBO) do profissional que realizou o procedimento válido no CNES, válido no CNES do atendimento. Utilizar 999999 - Sem registro no modelo de informação de origem, quando a informação estiver ausente no documento de origem. Domínio: - |
Campo: NU_CNS_PROFISSIONAL
Tipo de dados: Caracteres alfanuméricos Tamanho: 15 Obrigatoriedade: Não Regra: Número (s) do Cartão (os) Nacional (is) de Saúde do (s) profissional (is) que realizou (aram) o procedimento, validado(s) no CNES. Um procedimento pode ser realizado por mais de um profissional. Domínio: - |
| Campo: CO_INE_PROFISSIONAL
Tipo de dados: Caracteres alfanuméricos Tamanho: 10 Obrigatoriedade: não Regra: Código do Identificador Nacional de Equipes válido do CNES quando o procedimento for realizado por uma das equipes previstas em políticas nacionais de saúde. Domínio: - |
Campo: CO_CNES_TERCEIRO
Tipo de dados: Caracteres alfanuméricos Tamanho: 13 Obrigatoriedade: Não Regra: Número do CNES onde o procedimento foi realizado, quando for realizado por um profissional externo ao estabelecimento de saúde do contato assistencial. Domínio: - |
Campo: CO_TERMINOLOGIA
Tipo de dados: Caracteres alfanuméricos Tamanho: 100 Obrigatoriedade: Sim (chave composta) Regra: Identificador da terminologia que será utilizada para informar o procedimento realizado na vw_procedimentos. Domínio: - |
Campo: DT_REALIZACAO
Tipo de dados: data Tamanho: Obrigatoriedade: Sim (chave composta) Regra: Data que o procedimento foi realizado na vw_procedimentos |
- Diagnósticos/problemas do contato assistencial
| Campo: UUID
Tipo de dados: Caracteres alfanuméricos Tamanho: 36 Obrigatoriedade: Sim (chave primária) Regra: Código utilizado na própria base de dados do sistema de origem. 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. Domínio: - |
Campo: CO_TERMINOLOGIA_DIAGNOSTICO Tipo de dados: Caracteres alfanumérico Tamanho: 100 Obrigatoriedade: Sim Regra: Identificador da terminologia que será utilizada para informar os problemas/diagnósticos avaliados. Domínio: 2.16.840.1.113883.6.3 - CID-10 2.16.840.1.113883.6.139 - CIAP2 |
Campo: NU_VERSAO_TERM
Tipo de dados: Caracteres alfanuméricos Tamanho: 9 Obrigatoriedade: Sim Regra: Versão da terminologia do diagnóstico/problema, formato AAAAMMDD. Utilizar 01 como mês e dia quando a terminologia não possuir esta informação. Exemplo da CID-10 v. 2008: 20080101. Domínio: a ser validado no SIGTAP/RTS. |
|
Campo: CO_DIAGNOSTICO Tipo de dados: Caracteres alfanuméricos Tamanho: 4 Obrigatoriedade: Sim Regra: Código do diagnóstico/problema, código válido na terminologia/classificação de origem. Utilizar 0000 - Sem registro no modelo de informação de origem, com CO_TERMINOLOGIA_DIAGNOSTICO 2.16.840.1.113883.6.3 - CID-10, quando o documento de origem não possuir esta informação. Domínio: a ser validado no SIGTAP/RTS. |
Campo: ST_PRESENCA_ADMISSAO Tipo de dados: Caracteres alfanuméricos Tamanho: 1 Obrigatoriedade: Sim Regra: Indicador de presença na admissão, identifica se o problema/diagnóstico é previamente conhecido na admissão do indivíduo para o contato assistencial. Domínio: S - Sim N - Não D – Desconhecido |
Campo: ST_DIAG_PRIMARIO
Tipo de dados: S ou N Tamanho:1 Obrigatoriedade: Sim Regra: Categoria do diagnóstico, condição estabelecida após estudo de forma a esclarecer qual o mais importante ou principal motivo responsável pela demanda do contato assistencial. O diagnóstico principal reflete achados clínicos descobertos durante a permanência do indivíduo no estabelecimento de saúde, podendo, portanto, ser diferente do diagnóstico de admissão. Domínio: - |
Regras de Negócio
Conheça abaixo as regras de negócio do ETL:
| Regras de Negócio | |||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| RN01 – CONTATO ASSISTENCIAL – NÚMERO DE IDENTIFICAÇÃO
O número de identificação de um registro de contato assistencial será gerado em cada sistema de origem. Validar se o formato da UUID {versão 4) está adequado e, se não estiver, rejeitar o contato. | |||||||||||||||||||||||||||||||||||||||||||||
| RN02 – CONTATO ASSISTENCIAL – VALIDAÇÃO CÓDIGO CNES
Ao solicitar um registro de um contato assistencial deve ser informado um código de estabelecimento válido e ativo. Será requisitado o serviço ESTABELECIMENTOSAUDESERVICE, onde o mesmo fará uma busca na base de dados do CNES para validação do código do estabelecimento de saúde do contato assistencial ou do estabelecimento terceiro, quando informado. A validação deverá ser realizada na data da competência da admissão para estabelecimento de saúde do contato assistencial e na data da competência de realização do procedimento para estabelecimento terceiro, quando informado. Caso o número informado seja inválido ou o estabelecimento de saúde esteja desativado, o serviço recusará o registro de contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| RN03 – CONTATO ASSISTENCIAL – DATA DE ADMISSÃO
A data de admissão informada não pode ser inferior à data de nascimento do indivíduo, nem superior à data de óbito do CNS, caso conste, nem superior à data atual do sistema ou superior a data do desfecho, caso conste. No caso de ter só o ano na data de nascimento (máscara YYYY), o ano da data de admissão não poderá ser inferior ao ano do nascimento. Caso a data de admissão seja incompatível, o serviço recusará o registro de contato assistencial e retornará uma mensagem de erro ao operador. O número do CNS a ser considerado para a validação deverá ser o número cartão informado (provisório ou definitivo). Entretanto, nos casos em que o número informado for o provisório, substituí-lo pelo número do cartão definitivo. | |||||||||||||||||||||||||||||||||||||||||||||
| RN04 – CONTATO ASSISTENCIAL – PROCEDÊNCIA
Será requisitado o serviço PROCEDENCIACONTATOASSISTENCIALSERVICE, onde o mesmo fará uma busca na base de dados do SIGTAP {repositório de terminologia em uso) para validar a informação de procedência do individuo no contato assistencial. A validação deverá considerar o código da procedência Caso o código seja inválido, o serviço recusará o registro do contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| RN05 – CONTATO ASSISTENCIAL – DATA DE DESFECHO
A data de desfecho informada não pode ser inferior à data de nascimento do indivíduo. No caso de ter só o ano na data de nascimento (máscara YYYY), o ano da data de admissão não poderá ser inferior ao ano do nascimento. A data do desfecho não poderá ser menor que a data de admissão do registro do contato assistencial, nem inferior à data de realização de nenhum procedimento informado e nem superior à data atual do sistema e a data de óbito do CNS, caso conste. Caso a data de desfecho seja incompatível, o serviço recusará o registro de contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| RN06 – CONTATO ASSISTENCIAL – OBRIGATORIEDADE DATA DE DESFECHO
Descrição: A data de desfecho será obrigatória somente se no campo “Desfecho” a opção selecionada for diferente de “07 - Permanência”. Caso a data de desfecho seja informada com o desfecho “07-Permanência”, o serviço recusará o registro de contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| RN07 – CONTATO ASSISTENCIAL – MODALIDADE ASSISTENCIAL
Será requisitado o seNiço MODALIDADEASSISTENCIALSERVICE, onde o mesmo fará uma busca na base de dados do SIGTAP (repositório de terminologia em uso) para validar a informação de modalidade assistencial do contato assistencial. A validação deverá considerar o código da modalidade assistencial. Caso o código seja inválido, o seNiço recusará o registro do contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN08 – CONTATO ASSISTENCIAL – CARÁTER DE ATENDIMENTO
Será requisitado o seNiço CARATERCONTATOASSISTENCIALSERVICE, onde o mesmo fará uma busca na base de dados do SIGTAP (repositório de terminologia em uso) para validar a informação de caráter de atendimento do contato assistencial. A validação deverá considerar o código do caráter de atendimento. Caso o código seja inválido, o seNiço recusará o registro do contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN09 – CONTATO ASSISTENCIAL – DESFECHO
Será requisitado o seNiço DESFECHOCONTATOASSISTENCIALSERVICE, onde o mesmo fará uma busca na base de dados do SIGTAP (repositório de terminologia em uso) para validar a informação de desfecho do contato assistencial. A validação deverá considerar o código do desfecho. Caso o código seja inválido, o seNiço recusará o registro do contato assistencial e retornará uma mensagem de erro ao operador | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN12 – IDENTIFICAÇÃO DO INDIVÍDUO – CONTATO ASSISTENCIAL SEM CNS
Se não houver preenchimento do número de CNS do individuo no contato assistencial, deverá ser informado obrigatoriamente:
Caso algum destes campos não seja informado, o serviço recusará o registro do contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN13 - INDIVÍDUO - NÚMERO DO CNS
Descrição: O número de CNS deve ser preenchido e validado de acordo com as regras do CADSUS. 1 - Caso o CNS do indivíduo seja informado, o serviço fará uma consulta na base de dados do CADSUS para validar a formação do número CNS e verificar a existência do mesmo. 2 - Caso o CNS seja encontrado, o serviço fará um match na base de dados do cartão utilizando os dados informados (Data de Nascimento, Sexo) com o intuito de verificar se o cartão realmente pertence ao indivíduo informado. 3 - Caso o CNS seja in válido, não seja encontrado ou não pertença ao indivíduo informado, o serviço recusará o registro do contato assistencial e informará uma mensagem de erro ao operador. O número do CNS a ser considerado para a validação deverá ser o número cartão informado (provisório ou definitivo). Entretanto,nos casos em que o número informado for o provisório, substituí-lo pelo número do cartão definitivo. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN14 - INDIVÍDUO - JUSTIFICATIVA DA AUSÊNCIA DE CNS
Descrição: Será requisitado o serviço JUSTIFICATIVAAUSENCIACNSSERVICE, onde o mesmo fará uma busca no SIGTAP (repositório de terminologia em uso) para validar a informação de justificativa para ausência de CNS do indivíduo. A validação deverá considerar o código da justificativa de ausência de CNS. Caso o código seja inválido, o seNiço recusará o registro do contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN15 - INDIVÍDUO- OBRIGATORIEDADE CNS/JUSTIFICATIVA DA AUSÊNCIA DE CNS
Descrição: Será obrigatório o preenchimento de uma das seguintes opções no contato assistencial:informar o CNS do indivíduo ou uma opção de ausência de CNS. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN18- INDIVÍDUO- DATA DE NASCIMENTO
Descrição: O parâmetro data de nascimento do individuo deve aceitar a data de acordo com máscara: YYYY/MM/DD. Caso o campo de Justificativa da ausência de CNS seja preenchido, deve ser permitida também a máscara para data de nascimento - YYYY . | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN21 - PROBLEMAS/DIAGNÓSTICO - TERMINOLOGIA - CÓDIGO
Descrição: Somente poderão ser registrados problemas/diagnósticos das terminologias de OID 2.16.840.1.113883.6.3 (CID-10) ou 2.16.840.1.113883.6.139 (CIAP). Para as validações serão utilizados os serviços CIDSERVICE (Vide RN22) e CIAPSERVICE (Vide RN 53) para validar os problemas/diagnósticos informados no contato assistencial. Caso seja informado um OID diferente dos citados acima, o serviço retornará uma mensagem. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN22 - DIAGNÓSTICO- CID
Descrição: Será requisitado o serviço CIDSERVICE, onde o mesmo fará uma busca no SIGTAP (repositório de terminologia em uso) para validar as informações dos termos de problemas/diagnósticos da terminologia CID-10 (Classificação Estatística Internacional de Doenças e Problemas Relacionados com a Saúde - 10a edição). A validação deverá considerar o Identificador da Terminologia (código OID), o código do termo e a competência, conforme a data de admissão do contato assistencial. Caso os códigos dos termos sejam inválidos na respectiva competência e terminologia, o serviço recusará o registro do contato assistencial e retornará uma mensagem de erro ao operador. Caso o contato assistencial não possua Diagnóstico informado, incluir um diagnóstico de código "0000". | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN23 - CONTATO ASSISTENCIAL- PROCEDIMENTOS (AÇÕES)
Descrição: Deve existir pelo menos um procedimento registrado no contato assistencial. Não existe limite de quantidade de procedimentos (ações). Caso não seja informada nenhum procedimento, o serviço recusará o registro do contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN24 - VALIDAÇÃO DE PROCEDIMENTOS (AÇÕES)- PROCEDIMENTOSERVICE
Descrição: Será requisitado o serviço PROCEDIMENTOSERVICE, onde o mesmo fará uma busca no SIGTAP (repositório de terminologia em uso) para validar as informações dos termos de procedimentos da terminologia "Tabela SUS", por meio dos códigos dos procedimentos (ações) da Tabela SUS. A validação deverá considerar o Identificador da Terminologia (código OID), o código do termo e a competência, conforme a data de realização de cada procedimento informado no contato assistencial. Caso o código do termo seja inválido na respectiva competência e terminologia, o serviço recusará o registro do contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN25 - TERMINOLOGIA DOS PROCEDIMENTOS (AÇÕES) - CÓDIGO OID
Descrição: Somente poderão ser registrados procedimentos (ações) das terminologias abaixo:
Para as validações são utilizados os serviços PROCEDIMENTOSERVICE (Vide RN24), para va lidar os procedimentos (ações) informados no contato assistencial. Caso seja informado um OID diferente dos citados acima, o serviço retornará uma mensagem. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN26-VALIDAÇÃO DE FINANCIAMENTO
Descrição: Será requisitado o serviço FINANCIAMENTOSERVICE, onde o mesmo fará uma busca no SIGTAP (repositório de terminologia em uso) para validar as informações relacionadas ao financiamento do contato assistencial. A validação deverá considerar o código do financiamento e a competência, conforme a data de realização do primeiro procedimento realizado (se houver mais de um procedimento realizado no contato assistencial). Caso o código do termo seja inválido na respectiva competência, o serviço recusará o registro do contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN27 - AÇÃO- DATA DE REALIZAÇÃO DA AÇÃO
Descrição: A data de realização de todos os procedimentos (ações) de um contato assistencial deve ser igual à data de admissão do individuo caso a modalidade do contato assistencial seja: Atenção básica e Ambulatorial Especializado. E para as modalidades assistenciais: Atenção Hospitalar, Atenção Intermediária, Atenção à Urgência e Emergência, Atenção Psicossocial e Atenção Domiciliar, a data de realização dos procedimentos (ações) deve ser igual ou maiores à Data de Admissão do Indivíduo. Nenhuma data de realização de procedimento pode ser maior que a data atual do sistema. Para todas as modalidades assistenciais, a data de realização do procedimento não pode ser maior que a data de desfecho, nem menor que a data de nascimento do individuo, nem superior a data de óbito do paciente, caso conste. Para data de nascimento, quando for informado só o ano na data de nascimento (máscara YYYY), o ano da realização do procedimento não pode ser inferior ao ano do nascimento. Caso o contato assistencial não esteja de acordo com esta regra, o serviço recusará o contato e retornará uma mensagem de erro ao operador, para cada situação. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN29 - PROFISSIONAL - CÓDIGO INE - IDENTIFICAÇÃO NACIONAL DE EQUIPE
Descrição: Será requisitado o serviço EQUIPESERVICE, onde o mesmo fará uma busca no CNES para validar as informações relacionadas à identificação de equipe (INE) e de profissionais que pertencem à equipe que realizou o procedimento do contato assistencial. A validação deverá considerar o código INE e a competência, conforme a data de realização do procedimento. Caso o código do INE seja inválido na respectiva competência, o serviço recusará o registro do contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN30 - PROFISSIONAL -VALIDAÇÃO DE PROFISSIONAL COM CNES X INE
A informação de pelo menos uma ocupação de profissional (CBO) é obrigatória para todo contato assistencial. As validações de profissional de saúde/INE, Estabelecimento, estabelecimento Terceiro deverão acontecer obedecendo aos seguintes cenários·
1. Caso seja informada apenas a informação de CBO no contato assistencial, deve-se validar se a ocupação informada (CBO) está cadastrada no CNES do contato assistencial na data da competência de realização do procedimento. 2. Caso seja informado um ou mais profissionais de saúde, deve-se validar cada profissional com seu respectivo CBO informado no CNES do contato assistencial na data da competência de realização do procedimento. 3. Caso seja info rmado um ou mais CNES de estabelecimento Terceiro, deve-se validar se o CBO informado está cadastrado no (s) Estabelecimento (s) Terceiro (s) informados na data da competência de realização do procedimento. 4. Caso seja informado apenas o Identificador Nacional de Equipe de profissionais (INE) deve-se validar se o CBO e INE estão cadastrados no CNES do contato assistencial na data da competência de realização do procedimento. 5. Caso seja informado CNS de profissional (is) de saúde e CNES de estabelecimento Terceiro, deve-se validar se o (s) profissional (is) possui (em) o CBO cadastrado no CNES do estabelecimento Terceiro, na data da competência de realização do procedimento. 6. Caso seja informado CNS de profissional (is) e Equipe de profissionais (INE), deve-se validar se a equipe de profissionais está cadastrada no CNES do contato assistencial, na data da competência de realização do procedimento. Além disso, o CNS de profissional deverá ser validado para saber se possui aquele CBO no CNES do contato assistencial e validar se o profissional pertence à equipe de profissionais (INE) informado, na data da competência de realização do procedimento (ação). 7. Caso seja informado CNES de Estabelecimento Terceiro e Identificador Nacional de Equipe de profissionais (INE), deve-se validar se o CBO e Identificador Nacional de Equipe (INE) estão cadastrados no CNES de estabelecimento Terceiro, na data da competência de realização do procedimento. 8. Caso sejam informadas todas as informações: CNS de Profissional, CNES de Estabelecimento Terceiro e Identificador Nacional de Equipe profissionais (INE), deve-se validar se o Identificador Nacional de Equipe de profissionais está cadastrado no CNES de estabelecimento Terceiro, e se o profissional possui o CBO cadastrado no CNES do Estabelecimento Terceiro, na data da competência de realização do procedimento. Além disso, deve-se validar se o profissional pertence à equipe (INE) de profissionais, na data da competência de realização do procedimento. 9. Caso o contato assistencial não esteja de acordo com esta regra, o serviço recusará o contato e retornará uma mensagem de erro ao operador, para cada situação. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN31 - AÇÕES - OCUPAÇÕES DE PROFISSIONAIS (CBO)
Descrição: As ocupações de profissionais (CBO) podem se repetir para o mesmo procedimento, desde que o CNS do profissional e o Estabelecimento Terceiro, quando informado, não estejam repetidos. Não existe limite de quantidade de ocupações de profissionais (CBO). Caso o contato assistencial não esteja de acordo com esta regra, o serviço recusará o contato e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN32 - PROFISSIONAL - VALIDAÇÃO DO CNS DE PROFISSIONAL DE SAÚDE
Descrição: O serviço fará uma busca na base de dados do CNES para va lidar as informações do Profissional de saúde. A validação será por meio do CNS do profissional informado na data de competência em que o procedimento foi realizado. Caso o código seja inválido ou não esteja cadastrado, o serviço recusará o registro do contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN39 - VERSÃO TERMINOLOGIA DE PROCEDIMENTOS
Descrição: A versão da terminologia dos procedimentos (Tabela SUS, TUSS e CBHPM) deverá aceitar a seguinte máscara: YYYYMMDDL, onde, "YYYY" é a indicação do ano, "MM" refere-se ao mês, "DO" indica o dia e "L" a versão da terminologia. Caso o formato da versão não esteja de acordo com a máscara, o serviço recusará o contato e retornará uma mensagem ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN42- MODALIDADE ASSISTENCIAL -VALIDAÇÃO DE DATA OE DESFECHO E DATA DE ADMISSÃO
Descrição: As datas de admissão e de desfecho, quando esta última for informada, devem ser validadas de acordo com a modalidade assistencial informada no contato assistencial, conforme abaixo:
Caso o contato assistencial esteja em desacordo com estas regras, o serviço recusará o envio e emitirá uma mensagem de erro ao operador conforme cada situação. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN43 - DIAGNÓSTICO - VERSÃO TERMINOLOGIA DO DIAGNÓSTICO
Descrição: A versão da terminologia de diagnósticos/problemas (CID-10/CIAP2) deverá aceitar a seguinte máscara: YYYYMMDD, onde, "YYYY" é a indicação do ano, "MM" refere-se ao mês e "DO" indica o dia. Caso a versão da terminologia do diagnóstico/problema esteja em desacordo com esta regra, o serviço deverá recusar o envio e emitir mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN46- OBRIGATORIEDADE CNS DO PROFISSIONAL
Descrição: A informação do CNS do profissional deverá ser obrigatória para cada CBO informado quando o financiamento selecionado for SUS. Caso o contato não esteja de acordo com esta regra, o serviço recusará o registro do contato assistencial e retomará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN48 - VALIDAÇÃO DE PROCEDIMENTOS E DATA
Descrição: Permitir que um mesmo procedimento possa ser informado em uma mesma data, desde que a combinação entre CBO e CNS informada seja diferente. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN51 - REGISTRO DE CBO PARA PROFISSIONAL DE SAÚDE
Descrição: Para cada CBO informado só poderá existir um CNS de profissional relacionado. Os CBO's podem se repetir para diferentes CNS's de profissional no mesmo procedimento. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN53 - PROBLEMA - CIAP
Descrição: Será requisitado o serviço CIAPSERVICE e o mesmo fará uma busca no SIGTAP (repositório de terminologia em uso) para validar as informações dos termos de problemas da terminologia CIAP (Classificação Internacional de Atenção Primária). A validação considerará o Identificador da Terminologia (código OID) e o código do termo. Caso os códigos dos termos sejam inválidos na respectiva competência e terminologia, o serviço recusará o registro do contato assistencial e retornará uma mensagem de erro ao operador. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN57 -VALIDAÇÃO DAS COMPETÊNCIAS NO CNES
Descrição: Para validar as informações referentes ao CNES (Profissionais, Equipes e Estabelecimentos) será feita uma busca nas tabelas auxiliares do CNES. | |||||||||||||||||||||||||||||||||||||||||||||
| Regra: RN58 - CNS do Indivíduo é Igual ao de um dos profissionais
Descrição: Verificar se o CNS do individuo é igual ao de um dos profissionais que realizaram procedimentos. Caso isto ocorra, remover o CNS do individuo e gravar uma Justificativa de Ausência do CNS "99". O número do CNS a ser considerado para a validação deverá ser o número cartão informado (provisório ou definitivo). Entretanto, nos casos em que o número informado for o provisório, substituí-lo pelo número do cartão definitivo. |
Envio de dados do SISAB ao CMD
Origem dos dados
Os dados do Sistema de Informação em Saúde para Atenção Básica (SISAB) são oriundos dos sistemas da estratégia e-SUS AB: Coleta de Dados Simplificada (CDS) ou Prontuário Eletrônico do Cidadão (PEC), além de sistemas terceiros através da tecnologia apache THRIFT. Os dados registrados nesses sistemas são gerados a partir do trabalho de todos os profissionais que compõe as equipes de Atenção Básica no País, cujo o conteúdo enviado à base nacional de dados é de responsabilidade dos municípios.
Validação dos dados para importação no SISAB
Os dados registrados nos sistemas da estratégia e-SUS AB são enviados à base de dados (SISAB), onde são submetidos a um processo de validação antes de serem importados. As validações realizadas são as seguintes:
- Validação das informações de profissionais, equipes e estabelecimentos: O sistema verifica se o número do estabelecimento no Cadastro Nacional de Estabelecimentos em Saúde (CNES), o número do Identificador Nacional de Equipes (INE), o número do Cartão Nacional de Saúde (CNS) e o Código Brasileiro de Ocupações (CBO) do profissional estão válidos, considerando os dados disponíveis na base do Sistema do CNES referente à competência da produção e se existe vínculo único entre eles. Esta validação ocorre de acordo com a data de processamento da base do CNES.
- Data do atendimento: O dado precisa atender às três regras abaixo para ser contabilizado normalmente. A data da produção (atendimentos individuais, procedimentos, atividades coletivas, etc.) deverá atender aos seguintes critérios: a. Ser posterior a abril/2013, quando a primeira versão dos sistemas da estratégia e-SUS AB foi disponibilizada; b. Ser anterior à data de envio; c. Não ser anterior a 12 meses em relação à data de envio.
- Duplicidade do registro enviado: O registro recebido é processado e o sistema verifica se há duplicidade de dado. Havendo duplicidade, o dado é marcado como duplicado e não é contabilizado.
Envio dos dados do SISAB ao CMD
Após a rotina de validação, os dados do SISAB são enviados ao CMD com a aplicação dos seguintes critérios:
- Nível de Atenção: Os dados enviados ao CMD correspondem apenas a atendimentos e procedimentos realizados e devidamente registrados no âmbito da Atenção Primária. São aplicados filtros de estabelecimento, equipes e profissionais que podem atuar neste nível de atenção. Estabelecimentos de média e alta complexidade que optaram por utilizar a estratégia e-SUS AB como modelo de coleta de dados, não terão seus dados carregados e enviados ao CMD.
- Modelos de informação do e-SUS AB: Os dados apresentados foram originados dos seguintes modelos de informação: Ficha de Atendimento Individual, Ficha de Procedimentos e Ficha de Visita Domiciliar e Territorial. Para cada modelo de informação citado foram enviados apenas os dados registrados por profissionais aptos ao preenchimento de cada modelo.
- Os dados dos modelos de informação: atividade coletiva, atendimento odontológico individual e atendimento domiciliar serão os próximos a serem disponibilizados, completando os dados da Atenção Primária;
- Os dados registrados tanto em fichas (modelo CDS) ou prontuário eletrônico estão contemplados no CMD.
- Variáveis disponíveis para tabulação: As variáveis disponíveis correspondem a registros de atendimentos, visitas domiciliares e procedimentos enviados ao SISAB. Para seguir as regras do CMD, os dados de atendimentos foram mapeados e enviados com um código de procedimento correspondente, de acordo com a Tabela de Procedimentos do SUS constante no SIGTAP. Inclui-se nesse item, os campos rápidos dos modelos de informação em formato ficha. No que tange ao uso do prontuário eletrônico (PEC), atendimentos que geram o procedimento correspondente, será contabilizado e enviado apenas um deles para contabilização no CMD.
- Dados identificados e não identificados: Os dados registrados em qualquer modelo de informação acima citado, cujo o Cartão Nacional de Saúde (CNS) do indivíduo estiver preenchido, este registro será considerado como identificado. Para registros sem o preenchimento do CNS, será considerado como não identificado. Ambos os registros estão sendo enviados ao CMD.
- Validação do Cartão Nacional de Saúde (CNS) do Indivíduo atendido: Para contatos assistenciais identificados, os CNS dos cidadãos serão validados antes do envio ao CMD. Para os CNS que não passarem na validação, será considerado um contato assistencial sem identificação no modelo de informação.
Os dados da Atenção Primária apresentados no CMD seguiram a estrutura e as regras estabelecidas pela equipe gestora do CMD. Estes dados são provenientes do Sistema de Informação em Saúde para a Atenção Básica (SISAB), o qual apresenta registros realizados pelos profissionais da Atenção Primária, cujo o conteúdo enviado é de responsabilidade dos municípios.
