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 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. | |||||||||||||||||||||||||||||||||||||||||||||
| 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·
| |||||||||||||||||||||||||||||||||||||||||||||
