RSE SIGA CSP > CSH
RSE SIGA CSP > CSH
Análise Funcional
Novembro 2023
Este trabalho não pode ser reproduzido ou divulgado, na íntegra ou em parte, a terceiros nem utilizado para outros fins que não aqueles para que foi fornecido sem a autorização escrita prévia ou, se alguma parte do mesmo for fornecida por virtude de um contrato com terceiros, segundo autorização expressa de acordo com esse contrato. Todos os outros direitos e marcas são
Os direitos de autor deste trabalho pertencem à SPMS e a informação nele contida é confidencial.
As cópias impressas não assinadas representam versões não controladas.
Índice
Referência a outros documentos 10
1.1. Funcionalidades iguais para destinos de pedidos diferentes 11
1.3. Contagem do tempo do Pedido 12
2.1. Cancelamento de Pedido através da Área do Cidadão 12
2.2. Concordar ou Discordar com Instituição do pedido através da Área do Cidadão 12
2.3. Cancelar pedido/agendamento após encaminhamento ULGA através da Área do Cidadão 12
2.4. Mensagem de aviso de pedido de referenciação em caso de criação de novo pedido local 13
2.5. Ecrã de visualização de todos os pedidos de referenciação ativos para o utente 13
4. Processo de referenciação CSP>CSH 17
5.2.1. Enviar Pedido de Referenciação 20
5.2.2. Complementar Pedido de Referenciação 21
5.3. Funcionalidade de cancelar o pedido de referenciação na origem 23
5.4. Funcionalidade de acompanhamento de gestão de pedidos de referenciação na origem 23
6.1. Criação do pedido de referenciação localmente 25
6.2. Atualização do pedido de referenciação com o processo 29
6.3. Análise do pedido de referenciação 31
6.6. Reencaminhar o pedido para outra especialidade 41
6.7. Devolver o pedido para os CSP 44
6.9. Cancelar o agendamento da consulta 48
6.11. Associação do pedido de referenciação a uma consulta 52
6.14. Cancelar o pedido no Hospital 57
6.15. Funcionalidade de acompanhamento de gestão de pedidos de referenciação no destino 59
7. Duplicação de pedidos de referenciação 61
8. Impressão de pedidos de referenciação 62
Índice de Figuras
Figura 1 – Processo de referenciação CSP > CSH 18
Figura 2 – Fluxo de criação e envio de um pedido de referenciação para os CSH 19
Figura 3 – Fluxo para o processo de criação do pedido na instituição hospitalar de destino 29
Figura 4 – Fluxo para o processo de atualização do processo na instituição hospitalar de destino 31
Figura 5 – Fluxo para o processo de análise do pedido 33
Figura 6 – Fluxo para o processo de triar o pedido 39
Figura 7 – Fluxo para o processo de retriar o pedido 41
Figura 8 – Fluxo para o processo de reencaminhar o pedido para outra especialidade 43
Figura 9 – Fluxo para o processo de devolver o pedido para os CSP 46
Figura 10 – Fluxo para o processo de agendar a consulta 48
Figura 11 – Fluxo para o processo de associar o pedido de referenciação a uma consulta 53
Figura 12 – Fluxo para o processo de efetivar a consulta 54
Figura 13 – Fluxo para o processo de realizar a consulta 57
Figura 14 – Fluxo para o processo de cancelar o pedido de referenciação 59
Índice de Tabelas
Tabela 1 – Acrónimos e Descrição 7
Tabela 2 – Histórico de Alterações 8
Tabela 3 – Documentação de Suporte 10
Glossário
Tabela 1 – Acrónimos e Descrição
Termo | Significado |
SIGA | Sistema Integrado de Gestão de Acesso |
RSE-SIGA | Registo de Saúde Eletrónico - Sistema Integrado de Gestão de Acesso |
CSP | Cuidados de Saúde Primários |
CSH | Cuidados de Saúde Hospitalares |
SPMS | Serviços Partilhados do Ministério da Saúde |
SNS | Serviço Nacional de Saúde |
ARS | Administração Regional de Saúde |
TMRG | Tempos Máximos de Resposta Garantidos |
ULGA | Unidades Locais de Gestão do Acesso |
ACES | Agrupamento de Centros de Saúde |
CIT | Certificado de Incapacidade Temporária |
Controlo do Documento
Tabela 2 – Histórico de Alterações
Versão | Data | Autores | Revisores | Alterações | Aprovação |
1.1 | 17/01/2019 | Xxxx Xxxxxxxxxx | Versão atualizada de acordo com as alterações solicitadas pela ACSS e pela DGS na reunião do dia 16 de Janeiro de 2019, a saber: Alteração da designação da suspeita “Saúde Pública”, para “Doenças Virais Crónicas”. | ||
2.0 | 13/02/2019 | Xxxx Xxxxxxxxxx | Versão atualizada de acordo com as alterações solicitadas pela ACSS nas sessões de trabalhos realizadas em 24-01- 2019 e 30-01-2019 | ||
3.0 | 04/03/2020 | Xxxx Xxxxxxxxxx | Versão atualizada de acordo com as alterações solicitadas pela ACSS, para a Triagem e Retriagem (página 38), na sessão de trabalho realizada em 03-03-2020. | ||
3.1 | 30/04/2020 | Xxxxxxx Xxxxx | Versão atualizada com as alterações solicitadas pela ACSS de acordo as reuniões realizadas. | ||
3.2 | 01/06/2020 | Xxxxxxx Xxxxx e Xxxx Xxxxxxxxxx | Xxxxx Xxxxxx | Versão do DAF sem as matrizes de campos e sem referência a tecnologia e sistemas que integram com o RSE SIGA | |
3.3 | 03/08/2020 | Xxxxxxx Xxxxx | Xxxxx Xxxxxx | Versão que contempla o preenchimento do consentimento informado, quando da criação do pedido no CSP. Esta alteração tem impacto nos capítulos referentes à criação de pedido no CSP e na triagem dos pedidos no CSH. A versão deverá ser acompanhada pelo documento DIG v0.3, que contempla as alterações acima referidas (ver capítulo Referências a outros Documentos). Nota: as alterações estão identificadas em notas de rodapé com referência para a versão v3.3 | |
3.4 | 12/08/2020 | Xxxxxxx Xxxxx | Xxxxx Xxxxxx | Versão atualizada com a nova estrutura. Inclusão dos processos no DAF (anteriormente contidos no DIG). O conjunto DAF v3.4 e DIG 0.4 (que acompanha esta versão do DAF) não contém qualquer adição de conteúdo. | |
3.5 | 19/08/2020 | Xxxxxxx Xxxxx | Xxxxx Xxxxxx | Versão que contempla o preenchimento do consentimento informado o âmbito no projeto do Xxxx.XX, aquando da anexação de documentos no RSE AP. Nota: as alterações estão identificadas em notas de rodapé com referência para a versão v3.5 | |
3.6 | 11/09/2020 | Xxxxxxx Xxxxx | Xxxxx Xxxxxx | Versão que contempla as alterações sugeridas pela ACSS em e-mail enviado a 27.08.2020. Nota: as alterações estão identificadas em notas de rodapé com referência para a versão v3.6 | |
3.7 | 25/09/2020 | Xxxxxxx Xxxxx | Xxxxx Xxxxxx | Versão que contempla as alterações na pesquisa de destino dos pedidos de referenciação (iniciar pela valência ou subvalência e filtrado pelas redes de referenciação definidas no backoffice) |
Nota: as alterações estão identificadas em notas de rodapé com referência para a versão v3.7 | |||||
3.8 | 15/10/2020 | Xxxx Xxxxxxxxxx | Xxxxx Xxxxxx | Versão que contempla as alterações relativamente à triagem dos pedidos no CSH, tendo como base o valor do consentimento informado. Versão atualizada, não contendo conteúdo informativo relativo ao token no âmbito do projeto Xxxx.XX. Nota: as alterações estão identificadas em notas de rodapé com referência para a versão v3.8 | |
3.9 | 26/02/2021 | Xxxx Xxxxxxxxxx | Xxx Xxxxxx | Versão atualizada com as alterações solicitadas pela ACSS e que se encontram incluídas no Pack de Fevereiro. Nota: as alterações estão identificadas em notas de rodapé com referência para a versão v3.9 | |
3.10 | 23/04/2021 | Xxxx Xxxxxxxxxx | Xxx Xxxxxx | Versão atualizada com novas alterações solicitadas pela ACSS e que se encontram incluídas no Pack de Fevereiro. Nota: as alterações estão identificadas em notas de rodapé com referência para a versão v3.10 | |
3.11 | 14/10/2021 | Xxxx Xxxxxxxxxx | Xxxxx Xxxxx | Versão atualizada de acordo com as alterações solicitadas pela ACSS, relativamente à criação do pedido de referenciação de forma local, no hospital de destino. Nota: as alterações estão identificadas em notas de rodapé com referência para a versão v3.11 | |
3.12 | 11/03/2022 | Xxxx Xxxxxxxxxx | Xxxxx Xxxxx | Versão atualizada de acordo com as alterações solicitadas pela ACSS, relativamente ao processo de realizar a consulta, na instituição de destino. Nota: as alterações estão identificadas em notas de rodapé com referência para a versão v3.12 | |
3.13 | 04/10/2022 | Xxxx Xxxxxxxxxx | Xxxxxxxxx Xxxxxxxx | Versão atualizada de acordo com as alterações solicitadas pela ACSS, de forma a não contemplar as funcionalidades “Encaminhar o pedido para a ULGA” e “Atribuição de um Destino pela ULGA”. Tendo em conta que foi pedida pela UGA a desativação de ambas as funcionalidades. Nota: as alterações estão identificadas em notas de rodapé com referência para a versão v3.13 | |
3.14 | 21/04/2023 | Xxxxxxx Xxxxxxx | Versão atualizada com as seguintes alterações: - adição da hipótese do médico triador poder alterar o campo “Suspeita/Confirmação”; - eliminação do capítulo das notificações ao utente; - adição da possibilidade do administrativo poder alterar a especialidade dentro do conjunto de valência/subvalência registado. Nota: as alterações estão identificadas em notas de rodapé com referência para a versão v3.14 | ||
3.15 | 18/07/2023 | Xxxxxxx Xxxxxxx | Versão atualizada com as seguintes alterações: - automatismo de pedidos de referenciação do estado 'Efetivado' para o estado 'Realizado' | ||
3.16 | 20/07/2023 | Xxxxxxx Xxxxxxx | Versão com data na capa do documento atualizada e com a issue sobre a alteração da valência e sub-valência pelo médico Triador que não esteja aberta ao exterior |
3.17 | 31/07/2023 | Xxxxxxx Xxxxxxx | Versão com alterações sbre a issue do automatismo de pedidos de referenciação do estado 'Efetivado' para o estado 'Realizado' | ||
3.18 | 03/10/2023 | Xxxxxxx Xxxxxxx | Versão com alterações sobre a teleconsulta e número de pontos de prestação de cuidados | ||
3.19 | 13/11/2023 | Xxxxxxx Xxxxxxx | Versão atualizada com as alterações realizadas no CER da Fase 2. Nota: as alterações estão identificadas em notas de rodapé com referência para a versão v3.19. |
Referência a outros documentos
Tabela 3 – Documentação de Suporte
Autor | Versão | Data | Documento |
Xxxx Xxxxxxxxxx | V0.15 | 22.12.2022 | SPMS_RSE SIGA - Analise Funcional Fase 2 (CSP_CSH)_Origem_Destino_Interface gráfica |
Xxxxxxx Xxxxx | V7.0 | 27.05.2020 | SPMS_SIGA RSE BACKOFFICE DAF |
Xxxxxxx Xxxxx | V1.0 | 17.06.2020 | SPMS_SIGA RSE BACKOFFICE DIG [Documento anexado no capítulo Anexos” - Ver Anexo III] |
Notação BPMN
Tabela 4 – Notação BPMN
Símbolo | Descrição |
Evento de início do processo, não possuindo qualquer sequência de atividades, anterior a este evento. | |
Evento de término do processo, não possuindo fluxo de processo posterior a este evento. | |
Evento intermédio que indica o término de um evento (Subprocesso) que ocorre entre o início e o fim do processo. Afeta o fluxo do processo, mas não representa o inicio nem diretamente o término deste. | |
Atividade do processo, executada pelo utilizador, através da interação com um ecrã. | |
Atividade do processo, executada automaticamente, através de um serviço, sem interação do utilizador (webservice). | |
Atividade do processo, executada automaticamente, pelo sistema informático da instituição origem e que efetua a impressão do documento de Referenciação. | |
Decisão (utilizador) exclusiva com duas ou mais saídas de fluxo, apenas uma saída é selecionada para dar continuidade ao processo. | |
Ponto de decisão (sistema) com duas ou mais do que duas saídas de fluxo possíveis, apenas uma é selecionada para dar continuidade ao processo. | |
Ponto de decisão (sistema) usado para divergir e convergir fluxos paralelos do processo | |
Usado para ligar duas ou mais atividades/eventos para execução do processo. | |
Usado para representar a ordem das atividades/ pontos de decisão/ eventos para execução do processo. | |
A Pool comporta todo o fluxo do processo. | |
A Lane é uma subdivisão da Pool que representa um role ou uma área organizacional específica. |
1. Pressupostos Globais
Apresentamos de seguida, os pressupostos globais que foram considerados no âmbito da solução apresentada.
1.1. Funcionalidades iguais para destinos de pedidos diferentes
Independente do destino do pedido de referenciação (se se trata de Hospital SNS ou Protocolado), as funcionalidades e o fluxo de referenciação a implementar serão os mesmos.
1.2. Notificação ao utente1
1.3. Contagem do tempo do Pedido2
Tendo em conta que um pedido de referenciação pode ser enviado para o Hospital até ao 8º dia subsequente à consulta do CSP, a data inicial a considerar para a contagem de tempo do pedido será a data de envio do CSP para o RSE SIGA e, em seguida, para o Hospital destino, ou seja, a data em que o pedido passa para o estado “Enviado”.
2. Temas em Aberto
Apresentamos, de seguida, os temas em aberto que foram considerados no âmbito da solução apresentada.
2.1. Cancelamento de Pedido através da Área do Cidadão
Através da Área do Cidadão, o utente terá hipótese de efetuar o cancelamento do agendamento da consulta e de selecionar uma nova data, se pretendido. O sistema informático local registará esse pedido e retornará ao utente a confirmação do cancelamento do agendamento e da nova data da consulta (considerar para futuros desenvolvimentos).
2.2. Concordar ou Discordar com Instituição do pedido através da Área do Cidadão
Através da Área do Cidadão, o utente terá hipótese de poder concordar ou não com a escolha da instituição de destino onde a consulta vai ser realizada (considerar para futuros desenvolvimentos).
2.3. Cancelar pedido/agendamento após encaminhamento ULGA através da Área do Cidadão
Através da Área do Cidadão, será dado ao utente conhecimento da nova instituição de destino onde irá ser realizada a consulta, após encaminhamento do pedido pela ULGA. Neste cenário, caso o utente não concorde com o novo destino para onde foi enviado o pedido, o utente terá possibilidade de cancelar o agendamento e/ou o pedido (considerar para futuros desenvolvimentos).
1 Capítulo eliminado no âmbito da v3.14
2 Alteração realizada no âmbito da v.3.6.
2.4. Mensagem de aviso de pedido de referenciação em caso de criação de novo pedido local
Quando o utente tiver um pedido de primeira consulta hospitalar ativo no sistema hospitalar, e o assistente técnico marcar uma consulta para esse utente, sem que esta esteja relacionada com esse pedido, então deverá ser disponibilizada uma mensagem de aviso para o utilizador (considerar para futuros desenvolvimentos).
As situações para as quais esta mensagem deverá ser apresentada são as seguintes:
• Para todos os agendamentos de consultas (primeiras e subsequentes); apenas para primeiras consultas sem nenhum pedido de referenciação associado; primeiras consultas com e sem pedido de referenciação associado;
• Para qualquer marcação de consulta independentemente da especialidade; ou para a marcação de consulta com especialidade correspondente à valência e subvalência do pedido de referenciação ativo para doente?
• Deverão ser considerados pedidos de referenciação ativos e em que estado? Apenas os pedidos
que se encontram em “Aguarda agendamento”? Ou também noutros estados, se sim quais?
• Esta mensagem deverá surgir apenas nos ecrãs de marcação de consultas? A mensagem deverá surgir ao abrir o ecrã ou ao submeter o agendamento?
2.5. Ecrã de visualização de todos os pedidos de referenciação ativos para o utente
Aquando da triagem, o médico triador deverá ter acesso a todos os pedidos de referenciação ativos associados ao utente, dentro e fora da instituição, e para qualquer valência e ou subvalência. Assim, poderá fazer uma decisão consciente relativamente à triagem do pedido (considerar para futuros desenvolvimentos).
3. Introdução e Contexto
O projeto RSE SIGA tem como objetivo a disponibilização e partilha de informação entre profissionais de saúde e implementação de um documento digital – VAI (Via de Acesso Integrado) – que caracteriza o acesso no âmbito clínico e que serve para referenciação clínica.
Desta forma será possível obter:
• Ganhos sistémicos de eficiência;
• Maior comodidade para o utente;
• Promoção da competitividade e aumento da qualidade geral do sistema;
• Melhoria nos prazos e qualidade de atendimento na referenciação;
• Maior transparência.
Tendo em conta que o projeto será implementado de forma faseada, optou-se por elaborar um documento de análise funcional distinto para cada uma das fases.
3.1. Âmbito do Documento
O presente documento descreve as funcionalidades a implementar no âmbito da Fase CSP>CSH do projeto:
• Referenciação de um CSP para Hospital SNS (Consulta de Especialidade);
• Referenciação de um CSP para Hospital Protocolado (Consulta de Especialidade).
A seguir, serão descritas todas as funcionalidades a implementar no âmbito desta fase. Este documento deverá ser analisado em conjunto com o documento de interface gráfica, disponível no Anexo I3, que detalha em pormenor as interfaces gráficas que deverão ser tidas em consideração para dar resposta às funcionalidades descritas neste documento.
3 O Anexo I contém o Documento de Interface Gráfica (DIG).
O fluxo de referenciação CSP > CSH é semelhante para os dois tipos de referenciação acima mencionados, pelo que o fluxo ilustrado no capítulo 4 representa o processo de um pedido de referenciação desde o momento em que é criado nos CSP, até culminar nos CSH com a realização da consulta de especialidade inerente ao pedido de referenciação. Adicionalmente ao processo de referenciação, existem funcionalidades que deverão estar disponíveis nos sistemas CSP e CSH, que serão também detalhados de seguida.
Assim, os capítulos encontram-se subdivididos da seguinte forma:
• CSP: São listadas todas as funcionalidades realizadas no âmbito dos Cuidados de Saúde Primários pelo médico prescritor e sistemas utilizados, nomeadamente:
o Preencher formulário;
o Enviar Pedido de Referenciação;
o Complementar Pedido de Referenciação;
o Funcionalidade de cancelar o pedido de referenciação na origem;
o Funcionalidade de acompanhamento de gestão de pedidos de referenciação na origem.
• CSH: São listadas todas as funcionalidades realizadas no âmbito dos Cuidados de Saúde Hospitalares, pelos profissionais (Médico Triador e Assistente Técnico (AT) CSH) e sistemas utilizados:4
o Criação do pedido de referenciação localmente;
o Atualização do pedido de referenciação com o processo;
o Análise do pedido de referenciação;
o Triar o pedido,,;
o Retriar o pedido;
o Reencaminhar o pedido para outra especialidade5;
o Devolver o pedido para os CSP;
o Agendar a consulta;
o Cancelar o agendamento da consulta;
o Reagendar a consulta;
o Associação do pedido de referenciação a uma consulta6;
o Efetivar a consulta;
o Realizar a consulta;
4 Alteração realizada no âmbito da v.3.13. 5 Alteração realizada no âmbito da v.3.10. 6 Alteração realizada no âmbito da v.3.10.
o Cancelar o pedido no Hospital;
o Funcionalidade de acompanhamento de gestão de pedidos de referenciação no destino.
4. Processo de referenciação CSP>CSH
O fluxo apresentado na figura seguinte ilustra o processo de um pedido de referenciação de solicitação de primeira consulta hospitalar desde que é criado pelo médico geral e de saúde familiar (MGF) nos Cuidados de Saúde Primários até à sua realização numa consulta de especialidade nos Cuidados de Saúde Hospitalares7.
7 Alteração realizada no âmbito da v.3.10.
Figura 1 – Processo de referenciação CSP > CSH8,9
8 Alteração realizada no âmbito da v.3.10.
5. Funcionalidades – CSP
Neste capítulo serão abordadas as funcionalidades que deverão estar disponíveis no sistema de origem dos pedidos de referenciação CSP>CSH. Aqui estarão listadas as funcionalidades do sistema informático local na instituição de origem em todas as fases do processo de referenciação, ou seja, aquando da criação (início), acompanhamento ou cancelamento de pedidos de referenciação.
5.1. Processo
Conforme o fluxo apresentado na figura seguinte, o preenchimento do pedido de referenciação deverá ser realizado pelo médico, na instituição de origem dos cuidados de saúde primários. O médico tem a possibilidade de poder efetuar um pedido de referenciação para solicitação de primeira consulta de especialidade hospitalar.
O processo de preencher o formulário do pedido de referenciação permite explicar as ações que o utilizador pode realizar ao aceder ao formulário, tendo sempre em conta as regras de negócio. Na figura seguinte, é possível visualizar o fluxo de preenchimento do formulário do pedido de referenciação10.
Figura 2 – Fluxo de criação e envio de um pedido de referenciação para os CSH11
10 Alteração realizada no âmbito da v.3.9.
11 Alteração realizada no âmbito da v.3.9.
5.2. Preencher formulário
O pedido de referenciação deverá ser iniciado a partir do sistema informático local na instituição de origem e no momento em que o médico prescritor esteja a efetuar uma consulta ao utente. O médico, no contexto do utente, poderá criar uma Consulta Hospitalar como pedido de referenciação externo para o RSE SIGA12.
A partir desta criação, o fluxo de referenciação dar-se-á de forma automática entre a instituição de origem e de destino. Os pedidos de referenciação de Primeira Consulta Hospitalar poderão ser solicitados pelos médicos prescritores, através do sistema informático local para todas as valências e subvalências.
No contexto do preenchimento do formulário do pedido de referenciação, o médico prescritor poderá preencher as informações presentes nas secções referentes a «Dados», «Diagnóstico», «Destino»,
«Consentimento Informado»13, «História Clínica», «Notas Adicionais» e «Anexos», que deverão ser preenchidas de acordo com as regras referidas no documento inserido no Anexo I14.
5.2.1. Enviar Pedido de Referenciação
Ao finalizar o preenchimento do pedido, o sistema informático local deverá enviar o pedido de referenciação ao RSE SIGA15. Para que o pedido seja enviado, o sistema informático local deverá chamar o webservice do RSE SIGA que tem como objetivo a criação e o envio do pedido de referenciação à instituição de destino. Este webservice deverá atribuir o ID (número de identificação do pedido) e o estado igual a “Novo” ao pedido.
Para a(s) valência(s) e/ou subvalência(s), parametrizada(s) em Backoffice RSE SIGA, para obrigatoriedade de anexo, no caso de resposta afirmativa ou negativa, seja dado ou não consentimento pelo utente, em paralelo ao fluxo natural do pedido de referenciação (envio do pedido para CSH), é obrigatório a anexação de ficheiros. Nesta situação, após a submissão do pedido de referenciação, o RSE SIGA irá gerar o número de pedido, e o pedido deverá transitar para o estado “Novo Aguarda Anexo”, contudo o pedido de referenciação permanecerá neste estado e no RSE SIGA, até um período de cinco dias consecutivos16. Durante este prazo, o sistema informático local deverá na funcionalidade de acompanhamento de gestão de pedidos de
12 Ver subcapítulo 2.1., Documento de Interface Gráfica (DIG).
13 Alteração realizada no âmbito da v.3.3. - Versão que contempla o preenchimento do consentimento informado, aquando da criação do pedido no CSP.
14 Ver subcapítulo 2.1., Documento de Interface Gráfica (DIG).
15 Ver subcapítulo 2.1.1.3, Documento de Interface Gráfica (DIG).
16 Alteração realizada no âmbito da v.3.9.
referenciação, realçar os pedidos no estado “Novo Aguarda Anexo”, de forma a que o utilizador perceba que esta em falta informação e despoletará, todos os dias, para o médico prescritor, uma mensagem de aviso, a alertar para que deverá anexar a informação em falta de forma a que o pedido siga para a instituição hospitalar, contudo após ser ultrapassado esse intervalo de tempo, haja ou não anexos associados ao pedido de referenciação, o RSE SIGA enviará o pedido de referenciação para a instituição hospitalar de destino, traduzindo-se assim numa submissão diferida do pedido. Contudo o médico triador, nos CSH, ao analisar o pedido de referenciação, poderá, caso assim o pretenda, devolver o pedido de referenciação para o médico prescritor, dos CSP, se pretender solicitar ficheiros ou mais informação adicional ao pedido de referenciação rececionado17.
Subsequentemente, o RSE SIGA valida e envia o pedido de referenciação à instituição de destino, sendo o respetivo estado do pedido atualizado para “Enviado”. Uma vez no estado “Enviado”, o tempo de resposta do pedido de referenciação, isto é, o período até realização do pedido de referenciação, começa a ser contabilizado. A resposta do hospital de destino deverá estar de acordo com os TMRG18,19.
5.2.2. Complementar Pedido de Referenciação
Esta ação permitirá ao médico prescritor adicionar informações clínicas, notas relevantes ao pedido de referenciação e/ou anexar ficheiros ao pedido de referenciação20. Ao finalizar a complementação do pedido, o médico prescritor deverá submetê-lo, de forma a enviar para a instituição de destino o pedido atualizado com todas as novas informações inseridas.
A complementação do pedido pode ocorrer por estímulo do próprio médico prescritor sempre que este necessite (ver subcapítulo abaixo Por iniciativa do médico prescritor), ou a pedido do médico triador por intermédio da devolução do pedido para a instituição dos CSP de origem (ver subcapítulo Por devolução do Pedido).
17 Alteração realizada no âmbito da v.3.9.
18 Ver portaria 153/2017, de 4 de maio os Tempos Máximos de Resposta Garantidos (TMRG).
19 Alteração realizada no âmbito da v.3.6.
20 Ver subcapítulo 2.1.1.3, Documento de Interface Gráfica (DIG).
Por iniciativa do médico prescritor
O médico prescritor, na origem, poderá complementar informações ao pedido que está sob sua responsabilidade, em qualquer fase do fluxo de referenciação até que o pedido atinja o estado “Efetivado” (inclusive). Para isso, o sistema informático local deverá disponibilizar os campos que possibilitem a complementação do pedido existente, sem que haja qualquer alteração, seja edição, seja eliminação das informações já registadas, no pedido, anteriormente.
Neste cenário, o médico prescritor poderá complementar o pedido com informações clínicas adicionais, notas relevantes e/ou anexar ficheiros que possam servir de apoio no processo do tratamento/consulta médica para envio para a instituição de destino.
Caso o médico triador, na instituição hospitalar de destino, considere que o pedido de referenciação carece de informação clínica ou que existem dados em falta e sem esses requisitos não seja possível proceder com a avaliação apropriada para a triagem do pedido de referenciação, o médico triador poderá devolver o pedido para os CSP de forma a obter informação adicional para a correta avaliação da triagem a realizar. Nesta situação, o pedido seguirá para os CSP de forma a que possa ser tratado pelo médico prescritor. Este irá analisar os motivos da devolução do pedido e proceder ao envio de informação clínica, de forma a complementar a informação já submetida, enviando de novo o pedido de referenciação para a instituição de destino. Após a receção do pedido devolvido, nos CSP, o sistema informático da instituição de origem deverá imediatamente despoletar um sistema de alarmística que vai gerar alerta para o médico prescritor, a partir do dia em que se receciona o pedido devolvido, e após 5 dias consecutivos, a contar da receção do pedido devolvido, vai gerar alerta para o Interlocutor Médico do VAI (IMV) ou outros, conforme parametrização da responsabilidade dos CSP, de forma a alertar de que existe um pedido devolvido pelos CSH. Este alerta irá estar ativo e será despoletado até ser realizada qualquer ação no pedido de referenciação (ser dada resposta à informação solicitada pelo médico triador ou cancelamento do pedido)21. Contudo, caso o médico prescritor nos CSP julgue já não existir necessidade do utente se deslocar à consulta hospitalar, pode proceder com o cancelamento do pedido no sistema informático da entidade origem (ver capítulo 5.3).
21 Alteração realizada no âmbito da v.3.9.
5.3. Funcionalidade de cancelar o pedido de referenciação na origem
O sistema informático local deverá permitir que o pedido de referenciação possa ser cancelado na entidade origem pelo médico prescritor em qualquer momento a partir da criação do pedido, até este se encontrar no estado “Agendado” (inclusive)22.
Na situação em que ocorreu a devolução do pedido para a entidade origem, apenas o médico prescritor dos CSP poderá proceder com o cancelamento do pedido de referenciação, caso este considere que já não se justifica a solicitação de consulta hospitalar de especialidade.
O cancelamento de um pedido que esteja no estado “Agendado” deverá promover a automática desmarcação da agenda com notificação ao utente (exceto se o motivo for “Óbito”).
Sempre que um pedido for cancelado através do sistema informático local, esta informação deverá ser enviada ao RSE SIGA. Caso o pedido não possa ser cancelado, o RSE SIGA informará o sistema informático local que, por sua vez, informará o utilizador do motivo da impossibilidade do cancelamento do pedido. Caso contrário, o RSE SIGA confirmará a ação de cancelamento ao sistema informático local e será enviada uma notificação ao utente de que o pedido foi cancelado (exceto se o motivo for “Óbito”).
5.4. Funcionalidade de acompanhamento de gestão de pedidos de referenciação na origem
O sistema informático local da entidade origem deverá disponibilizar uma funcionalidade para o acompanhamento de pedidos de referenciação, que tem como objetivo permitir ao utilizador fazer a monitorização de todos os pedidos, consultar todas as informações registadas nas várias secções do pedido de referenciação e visualizar a lista dos pedidos no contexto do utente23.
Através desta funcionalidade, tanto os utilizadores com perfil médico como os utilizadores com perfil assistente técnico, nos cuidados de saúde primários, poderão visualizar informação referente aos pedidos de referenciação, tal como acompanhar o ciclo de vida do pedido com informações sobre as ações registadas no mesmo24. Adicionalmente, o médico dos CSP terá conhecimento acerca da conclusão de um pedido, seja através da realização da consulta (com ou sem a presença do utente) ou do cancelamento do mesmo, bem como, da informação clínica que seja registada pelo médico dos CSH no âmbito do pedido.25
22 Ver subcapítulo 2.2, Documento de Interface Gráfica (DIG). 23 Ver subcapítulo 2.3, Documento de Interface Gráfica (DIG). 24 Alteração realizada no âmbito da v.3.9.
25 Alteração realizada no âmbito da v3.19
Através desta funcionalidade deverá ainda ser apresentada, para os utilizadores com perfil médico e perfil assistente técnico, na instituição de origem, informação referente à data e hora do agendamento da consulta relativa ao pedido de referenciação26,27.
A informação a ser visualizada pelo utilizador deverá ser referente ao número de identificação do pedido, ao nome do utente, à idade, à Instituição Destino, à Valência, à Subvalência, à Data e Hora de submissão do pedido e ao estado atual em que o pedido de referenciação se encontra28.
26 Alteração realizada no âmbito da v.3.9.
27 Ver subcapítulo 2.3, Documento de Interface Gráfica (DIG).
28 Ver subcapítulo 2.3, Documento de Interface Gráfica (DIG).
6. Funcionalidades – CSH
Na instituição de Destino os profissionais médicos e assistentes técnicos (ATs) poderão visualizar e consultar todas as secções do pedido de referenciação de forma integral, à exceção destes últimos que não poderão visualizar qualquer tipo de informação clínica.
Através do sistema informático local, é disponibilizado um ecrã onde os médicos/ ATs dos CSH poderão utilizar os filtros de pesquisa de acordo com a sua preferência e restringir os resultados de pesquisa recorrendo aos mesmos.
De seguida serão detalhas as funcionalidades do ciclo de vida de um pedido de referenciação CSP>CSH aquando da sua receção na instituição hospitalar de destino (CSH).
6.1. Criação do pedido de referenciação localmente
Consiste numa atividade manual a ser realizada pelo Assistente Técnico (AT) da instituição de destino dos CSH, que tem como objetivo o preenchimento do formulário do pedido de referenciação, de toda a informação relevante para solicitação de um pedido de referenciação de Primeira Consulta Hospitalar29. O AT deverá realizar este processo, somente na situação em que os CSP não possuam nos seus sistemas informáticos locais a integração com o RSE SIGA. Neste caso, o envio do pedido para a Instituição de Destino não poderá ser efetuado via sistema informático da entidade de origem. Assim sendo, nestas situações, o médico prescritor deverá efetuar o preenchimento do formulário, a requerer a primeira consulta de especialidade hospitalar, mas não poderá submeter o formulário via RSE SIGA para o Hospital através do sistema informático local30.
Nestes casos, o médico prescritor deverá imprimir o formulário e entregá-lo ao utente de forma a que este, quando se deslocar à instituição hospitalar de destino, entregue o formulário ao assistente técnico para que este possa dar o necessário seguimento ao preenchimento de um pedido no sistema, de acordo com os dados do formulário em papel.
No cenário em que se verifique a criação do pedido de referenciação de forma local, no hospital de destino, para a correta criação do pedido é necessário agir de acordo com as seguintes premissas, descritas de seguida31:
29 Ver subcapítulo 3.1, Documento de Interface Gráfica (DIG).
30 Alteração realizada no âmbito da v.3.9.
31 Alteração realizada no âmbito da v.3.9.
a) o sistema informático administrativo local de destino, deverá disponibilizar todos os campos existentes no formulário do pedido de consulta, incluindo os campos "História Clínica" e "Motivo de Referenciação Resumido" para que seja transcrita toda a informação que consta no pedido manual;
b) para todos os pedidos de referenciação sem necessidade de criação a partir do sistema informático local de destino, ou seja, pedidos de referenciação criados nos CSP e integrados corretamente através do RSE SIGA, não deverão ser disponibilizados, para os assistentes técnicos, os campos "História Clínica" e "Motivo de Referenciação Resumido" nem a informação contida nos mesmos;
c) no que diz respeito ao processo de anexação de imagens ou outros documentos, no pedido de referenciação, o mesmo deverá ser garantido através do upload no sistema informático clínico do local de destino. Contudo, deve ser garantido que esta informação, de que existe um documento afeto ao pedido de referenciação, esteja presente num campo de informação administrativa;
d) o pedido de referenciação criado localmente, pelo AT dos CSH, poderá ser alterado enquanto se verificar que o seu estado permanece em "Aguarda Triagem";
e) para um pedido de referenciação criado localmente, pelo AT dos CSH, o sistema informático local de destino, deverá permitir que o AT possa identificar a origem em "texto livre", ou seja, deverá permitir, que nestes casos seja possível, a criação de uma instituição "local" com descrição e número de contacto da mesma, para as situações em que a instituição de origem não conste da tabela de instituições ou da rede de referenciação e guardar estes novos dados inseridos;
f) aquando do preenchimento do pedido local, no que diz respeito ao preenchimento dos campos de “Valência” e “Subvalência” o sistema informático local de destino deverá mostrar os valores referentes à sua própria oferta, ou seja, à rede de referenciação do hospital de destino;
g) aquando do preenchimento do pedido local, no caso da instituição de destino que receciona o pedido de referenciação manual, não ter a valência solicitada, deve ser cumprido o procedimento determinado pelo regulamento;
h) aquando do preenchimento do pedido local, deverá constar um campo no formulário denominado
“Consentimento Informado”, de preenchimento obrigatório que o AT deverá preencher com
"Sim", se o utente consentir que a consulta seja realizada por teleconsulta ou "Não", caso o utente não dê consentimento para que a sua consulta de especialidade seja realizada por teleconsulta;
i) sempre que o AT proceda com a transcrição do pedido de referenciação manual, deverá ser de caráter obrigatório o preenchimento do Número Utente SNS ou do Número Nacional do Utente (NNU);
j) o sistema informático local de destino deverá disponibilizar, para o assistente técnico, no formulário do pedido de referenciação, um campo de informação administrativa, caso exista necessidade dos ATs acrescentarem algum tipo de informação administrativa pertinente ao pedido de consulta;
k) nas situações em que, o médico triador seleciona o tipo de consulta, poderá indicar a realização de uma teleconsulta, com um único ponto de prestação de cuidados (CSH) ou 2 pontos de prestação de cuidados (CSH e CSP), no ecrã do VAI (do pedido de referenciação).32
Nas situações em que o pedido é criado localmente mediante a apresentação excecional do Requerimento de Pedido de primeira consulta de especialidade hospitalar para Hospitais do SNS, no âmbito de uma referenciação proveniente de entidades privadas, deverá ser assegurado que o assistente técnico não terá à sua disposição a obrigatoriedade de registo de informação de teor clínico que esteja contida no respetivo formulário.33
No cenário em que se verifique esta criação do pedido de referenciação de forma local, no hospital de destino, após conclusão da criação do pedido, o mesmo permanecerá com o estado “Aguarda Criação” e só após o RSE SIGA validar as respetivas regras de negócio e caso autorize a criação do pedido, é então criado o número de identificação do pedido de referenciação e enviado o mesmo para o sistema informático local, e posteriormente o estado do pedido será atualizado, de forma automática, para “Aguarda Triagem”, ficando assim disponível para análise, na listagem dos pedidos que estão a aguardar triagem.
No cenário em que o RSE SIGA após validar as respetivas regras de negócio, não autorize a criação do pedido de referenciação, consequentemente não será originado, nem despoletado, para o sistema informático local o número de identificação do pedido, o mesmo deverá permanecer no estado “Aguarda
32 Alteração realizada no âmbito v3.18
33 Alteração realizada no âmbito da v3.19
Criação” e deverá ser mostrado para o utilizador o motivo da recusa de criação do pedido. Neste cenário, o AT tem a possibilidade de editar os campos do formulário do pedido de referenciação e submeter novamente o pedido para que o RSE SIGA valide as respetivas regras de negócio e autorize ou não a criação do pedido. No sistema informático local, deverá ser gerado um novo registo no histórico do pedido, sendo que este novo registo será novamente referente ao estado “Aguarda Criação”34.
6.1.1. Processo
Como já referido e conforme o fluxo apresentado na figura seguinte, o preenchimento do pedido de referenciação deverá ser realizado pelo AT na instituição de destino dos cuidados de saúde hospitalares. O AT deverá proceder com o preenchimento do formulário de acordo com os dados do formulário registados pelo médico da instituição de origem.
O processo de preencher o formulário do pedido de referenciação permite explicar as ações que o utilizador pode realizar ao aceder ao formulário, tendo sempre em conta as regras de negócio. Na figura seguinte, é possível visualizar o processo de preencher o formulário do pedido de referenciação na instituição hospitalar de destino.
34 Alteração realizada no âmbito da v.3.11.
Figura 3 – Fluxo para o processo de criação do pedido na instituição hospitalar de destino
6.2. Atualização do pedido de referenciação com o processo
Sempre que um pedido for rececionado no Hospital, o sistema local destino deverá enviar para o RSE SIGA e para a instituição de origem a atualização do estado do pedido para “Aguarda Triagem”, a identificação do utente no Hospital destino e a data e hora da receção do pedido.
Cada pedido de referenciação rececionado deverá ser associado, via nº Utente SNS, ao número do processo hospitalar do utente ou ao seu número de identificação sequencial no Hospital destino (caso não exista a identificação do utente com um número de processo hospitalar)35.
A associação do pedido com o número do processo hospitalar poderá ser realizada de forma manual ou automática. Sendo manual, o assistente técnico no Hospital deverá receber o novo pedido e associar o pedido de referenciação ao processo hospitalar do utente no Hospital. Caso seja automático, este processo deverá associar de imediato o número do processo hospitalar ao número do pedido através do número do SNS e de seguida atualizar o estado do pedido para “Aguarda Triagem”.
Caso o utente não possua número de processo hospitalar então o assistente técnico poderá criá-lo no sistema local e associá-lo ao pedido de referenciação. Contudo, se o Hospital não possuir como prática criar um número de processo hospitalar para um utente que nunca tenha estado na entidade hospitalar, então o assistente técnico poderá associar ao pedido o número de identificação sequencial do utente no hospital destino.
Assim, após a associação do número de identificação sequencial do utente ou do número do processo
hospitalar do utente ao pedido, o estado do pedido será atualizado para “Aguarda Triagem”.
Cenários possíveis para a atualização do processo no hospital:
• Cenário 1 – Utente com número de processo hospitalar no Hospital – pedido rececionado no hospital e enviado via RSE SIGA – Para cada pedido rececionado, o pedido de referenciação deverá ser associado ao processo hospitalar do utente existente. Após esta associação, o estado do pedido será atualizado para “Aguarda Triagem”;
• Cenário 2 – Utente sem número de processo hospitalar no Hospital – pedido rececionado no hospital e enviado via RSE SIGA – Para cada pedido rececionado, o pedido de referenciação deverá ser associado ao número de identificação sequencial do utente no hospital destino. Após esta associação, o estado do pedido será atualizado para “Aguarda Triagem”;
• Cenário 3 – O utente chega ao hospital com o pedido de referenciação em papel – O assistente técnico deverá criar o pedido de referenciação no sistema local, associá-lo ao número de identificação sequencial e/ou ao número do processo hospitalar do utente caso exista. Caso o utente não possua número de processo hospitalar, se o Hospital possuir como prática criar este número, então o assistente técnico poderá ainda criá-lo e associá-lo ao pedido. Após esta associação, o estado do pedido será atualizado para “Aguarda Triagem”.
35 Ver subcapítulo 3.2, Documento de Interface Gráfica (DIG).
6.2.1. Processo
Na figura seguinte, é possível visualizar a ação de atualizar o processo do pedido de referenciação na instituição hospitalar de destino, pelo AT.
Figura 4 – Fluxo para o processo de atualização do processo na instituição hospitalar de destino
6.3. Análise do pedido de referenciação36
Após ter ocorrido a associação do pedido de referenciação com o número do processo hospitalar ou número sequencial de identificação, o pedido deverá encontrar-se no estado “Aguarda Triagem” e com o
36 Alteração realizada no âmbito da v.3.13.
pedido neste cenário, o médico triador poderá realizar uma das seguintes ações possíveis, descritas de seguida37:
a) Triar o pedido:
• Neste cenário, o médico triador visualizará todas as informações do pedido e poderá ou não concordar com os dados registados no formulário do pedido de referenciação registados pelo médico prescritor. Posteriormente à triagem, o médico triador poderá ainda realizar: uma nova triagem ao pedido de referenciação; o agendamento da consulta ou solicitar ao assistente técnico para agendar a consulta; o cancelamento do pedido de referenciação; o reencaminhamento do pedido de referenciação para outra especialidade; a associação da referência a uma consulta38.
b) Devolver o pedido aos CSP:
• Neste cenário, o médico triador caso sinta necessidade de obter mais informação acerca do contexto da solicitação de consulta de especialidade hospitalar, para avançar com a triagem do pedido de referenciação, poderá proceder com a devolução do pedido para os CSP de forma a que o médico prescritor complemente o mesmo com mais informação e posteriormente submeta o pedido de referenciação, contendo essa nova informação, para o médico triador.
c) Cancelar o pedido39:
• Após analisar o pedido de referenciação e caso no entender do médico triador, este considere que nenhuma das opções anteriores é adequada e que não se deva dar seguimento ao pedido de referenciação, o médico triador, poderá proceder com o cancelamento do pedido de referenciação40.
d) Reencaminhar o pedido para outra especialidade41:
• Neste cenário e após analisar o pedido de referenciação, caso o médico triador pretenda, poderá reencaminhar o pedido de referenciação para qualquer especialidade que faça parte da rede do próprio hospital.
37 Ver subcapítulo 3.3, Documento de Interface Gráfica (DIG).
38 Alteração realizada no âmbito da v.3.10. 39 Alteração realizada no âmbito da v.3.9. 40 Ver subcapítulo 6.14.
41 Alteração realizada no âmbito da v.3.10.
6.3.1. Processo
Figura 5 – Fluxo para o processo de análise do pedido42,43
6.4. Triar o pedido44,45,46
No sistema informático local de destino, se forem dados acessos à consulta e permissões de triador ao médico triador selecionado, este terá acesso às consultas da agenda dessa especialidade. Desta forma, no
42 Alteração realizada no âmbito da v.3.10.
43 Alteração realizada no âmbito da v.3.13.
44 Funcionalidade alterada em virtude da inclusão do consentimento informado (Ver subcapítulo 2.1.1.1, Documento de Interface Gráfica).
45 Alteração realizada no âmbito da v.3.3.
46 Alteração realizada no âmbito da v.3.8.
Hospital, o(s) médico(s) triador(es) associado(s) à especialidade de triagem do pedido deverá(ão) visualizar a listagem dos pedidos que estão a aguardar xxxxxxx00.
As parametrizações dos pedidos de referenciação estão diretamente relacionados com as redes de referenciação definidas no BackOffice do RSE SIGA48, pelo que, as opções disponíveis para a triagem também deverão estar de acordo com o que se encontra parametrizado no BackOffice do RSE SIGA.
Os pedidos de referenciação devem ser reencaminhados/triados/retriados de acordo com a oferta (especialidades definidas na rede do hospital) da instituição hospitalar. Ou seja, o médico triador pode reencaminhar ou triar (neste caso depende do perfil do triador e das especialidades para as quais ele está associado) para qualquer especialidade que faça parte da rede do próprio hospital49.
O sistema informático local deverá permitir que os pedidos de referenciação possam ser reencaminhados/triados/retriados, as vezes que o(s) médico(s) triador(es) achem necessárias, mas respeitando um prazo máximo e após esse prazo, criar uma penalização pelo incumprimento dos TMRG, contudo esta deverá ser uma recomendação registada no regulamento, mas não uma regra que limite a utilização do sistema de informação50.
Na triagem e após analisar as informações registadas no pedido, o médico triador poderá neste cenário, realizar uma das seguintes ações possíveis, descritas de seguida51:
a) concordar com todos os valores registados pelo médico prescritor e que se encontram preenchidos com os dados do pedido original, selecionar um tipo de consulta, selecionar uma especialidade de consulta, podendo ainda, caso necessite e de forma facultativa, registar informações e/ou notas adicionais consideradas de interesse na triagem e confirmar a triagem do pedido;
47 Alteração realizada no âmbito da v.3.9.
48 Ver documentos de BackOffice do RSE SIGA Anexo II e Anexo III.
49 Alteração realizada no âmbito da v.3.9.
50 Alteração realizada no âmbito da v.3.9.
51 Ver subcapítulo 3.4, Documento de Interface Gráfica (DIG).
b) discordar com todos os valores registados pelo médico prescritor, e que se encontram preenchidos com os dados do pedido original. Caso o médico triador selecione novos valores de valência, ou subvalência e essa(s) alteração(ões) não modifique(m) a especialidade para triagem presente no pedido original, então o médico triador deverá analisar se concorda ou não com a suspeita/confirmação52 e prioridade originais, podendo atribuir, entre as opções disponíveis, uma nova suspeita53 e/ou uma nova prioridade, de acordo com a suspeita informada pelo médico prescritor no pedido original ou de acordo com a nova suspeita selecionada. Seguidamente deverá selecionar um tipo de consulta, uma especialidade de consulta, podendo ainda, caso necessite e de forma facultativa, registar informações e/ou notas adicionais consideradas de interesse na triagem e confirmar a triagem do pedido;
c) discordar com todos os valores registados pelo médico prescritor, e que se encontram preenchidos com os dados do pedido original. Caso o médico triador selecione novos valores de valência ou subvalência e essa(s) alteração(ões) modifique(m) a especialidade para triagem presente no pedido original e o médico triador não se encontre associado à especialidade para triagem selecionada, então o médico triador não poderá alterar o valor referente à suspeita ou prioridade, bem como não poderá selecionar uma especialidade de consulta, nem um tipo de consulta, e assim não poderá proceder com a ação de triagem, dessa forma, o médico triador deverá reencaminhar o pedido para a especialidade pretendida através da funcionalidade Reencaminhar o pedido para outra especialidade onde poderá selecionar qualquer rede de referenciação do próprio hospital e de forma facultativa, registar informações e/ou notas adicionais consideradas de interesse e posteriormente gravar os registos efetuados no pedido54;
d) discordar com um ou mais valores registados pelo médico prescritor, e que se encontram preenchidos com os dados do pedido original. Caso o médico triador selecione novos valores de valência ou subvalência e essa(s) alteração(ões) não modifique(m) a especialidade para triagem presente no pedido original, então o médico triador deverá analisar se concorda ou não com com a suspeita/confirmação55 e prioridade originais, podendo atribuir, entre as opções disponíveis,
52 Alteração realizada no âmbito da v3.14 53 Alteração realizada no âmbito da v3.14 54 Alteração realizada no âmbito da v.3.10. 55 Alteração realizada no âmbito da v3.14
uma nova prioridade, de acordo com a suspeita informada pelo médico prescritor no pedido original ou de acordo com a nova suspeita selecionada. Seguidamente deverá selecionar um tipo de consulta, uma especialidade de consulta, podendo ainda, caso necessite e de forma facultativa, registar informações e/ou notas adicionais consideradas de interesse na triagem e confirmar a triagem do pedido;
e) discordar com um ou mais valores registados pelo médico prescritor, e que se encontram preenchidos com os dados do pedido original. Caso o médico triador selecione novos valores de valência ou subvalência e essa(s) alteração(ões) modifique(m) a especialidade para triagem presente no pedido original e o médico triador não se encontre associado à especialidade para triagem selecionada, então o médico triador não poderá alterar o valor referente à suspeita ou prioridade, bem como não poderá selecionar uma especialidade de consulta, nem um tipo de consulta, e assim não poderá proceder com a ação de triagem, dessa forma, o médico triador deverá reencaminhar o pedido para a especialidade pretendida através da funcionalidade Reencaminhar o pedido para outra especialidade onde poderá selecionar qualquer rede de referenciação do próprio hospital e de forma facultativa, registar informações e/ou notas adicionais consideradas de interesse e posteriormente gravar os registos efetuados no pedido56;
f) No cenário em que, aquando da triagem do pedido de referenciação se selecionem valores de valência e/ou subvalência que também já se encontrem registados num pedido de referenciação que se encontre ativo, ou seja, pedido que ainda não se encontre no estado “Realizado” ou “Cancelado”, o pedido torna-se duplicado e surgirá um alerta a informar o utilizador de que poderá dar seguimento, procedendo em conformidade com as suas necessidades, se pretende dar resposta aos dois pedidos de referenciação em separado ou se pretende cancelar e/ou alterar os dados de valência e/ou subvalência, de um por ser um pedido repetido do outro;
56 Alteração realizada no âmbito da v.3.10.
g) Para os pedidos de referenciação cuja parametrização permita a funcionalidade “Responder Agora” (configuração da Rede de Referenciação, realizada no BackOffice do RSE SIGA57), deverá ser habilitada esta funcionalidade (botão “Responder Agora” disponível). A funcionalidade que permite a realização da consulta sem a presença do utente. Caso o médico triador altere os campos de maneira a que a rede já não permita a funcionalidade “Responder Agora”, o botão “Responder Agora” deverá ficar desabilitado”;
h) Para os pedidos de referenciação com valores de valência e/ou subvalência de “Dermato- Venereologia” e campo consentimento informado para 1ª consulta hospitalar por Telerrastreio Dermatológico é “Sim” (utente consente que a consulta seja realizada por Telerrastreio Dermatológico), o médico triador poderá proceder com o processo de triagem, tendo à sua disposição a funcionalidade “Responder Agora”, que permite a realização da consulta sem a presença do utente, que deverá encontrar-se habilitada. O processo de triagem irá funcionar sem qualquer restrição do que pode resultar em termos de prestação de consulta, ou seja, o hospital é que deverá decidir qual o tipo de consulta que se vai realizar ao utente e dessa forma poderá ser possível mantendo a valência e subvalência, o médico triador selecionar um tipo de consulta diferente de telerrastreio/teleconsulta. O médico triador poderá assim selecionar um tipo de consulta diferente de telerrastreio (desde que parametrizado em BackOffice do RSE SIGA), sem alterar a valência e a subvalência “Dermato-Venereologia”. Contudo se o tipo de consulta for diferente de telerrastreio/teleconsulta, o médico triador poderá dar seguimento com o processo de triagem, contudo a funcionalidade “Responder Agora” não deverá encontrar-se disponível58;
i) Para os pedidos de referenciação com valores de valência e/ou subvalência de “Dermato- Venereologia”, e campo consentimento informado para 1ª consulta hospitalar por Telerrastreio Dermatológico é “Não” (utente não consente que a consulta seja realizada por Telerrastreio Dermatológico), a funcionalidade “Responder Agora” deverá encontrar-se desabilitada e o médico triador terá de selecionar um tipo de consulta que não “Telerrastreio Dermatológico”, de forma a poder proceder com a ação de triagem. De forma a realizar a triagem, o médico triador terá de selecionar outro tipo de consulta (desde que parametrizado em BackOffice do RSE SIGA) e, para isso, sem ser necessário alterar a valência e a subvalência para outra opção que não “Dermato-
57 Ver documentos de BackOffice do RSE SIGA Anexo II e Anexo III.
58 Alteração realizada no âmbito da v.3.8.
Venereologia”. Contudo nas situações em que o médico triador ache pertinente que a resposta dada pelo utente ao consentimento informado não vai de acordo com as suas pretensões para o tipo de consulta a selecionar, o médico triador poderá solicitar ao AT da instituição hospitalar para que este entre em contacto com o utente de forma a que este tome conhecimento do tipo de consulta por teleconsulta e possa alterar a resposta dada ao consentimento.
Relativamente aos campos “Valência e “Subvalência”, caso estes sofram alterações aquando da triagem, os mesmos poderão ser novamente alterados permitindo que se trie as vezes que forem necessárias mas dentro de um prazo máximo59.
Caso o médico triador altere o pedido com novos valores de valência, subvalência e essa(s) alteração(ões) modifique(m) a especialidade para triagem presente no pedido original e o médico triador não se encontre associado à especialidade para triagem selecionada, o sistema informático local deverá exibir uma mensagem a informar o utilizador de que a especialidade para triagem foi alterada e desabilitar os campos de seleção de especialidade de consulta, tipo de consulta e de prioridade.
Após confirmar a triagem, o médico triador poderá realizar a retriagem (ver capítulo 6.5) do pedido de referenciação ou se a mesma não for necessária, agendar a consulta ou comunicar ao assistente técnico para este realizar o respetivo agendamento da consulta, ou ainda realizar a consulta de especialidade hospitalar, caso a funcionalidade “Responder Agora” se encontre habilitada.
6.4.1. Processo
Consiste numa atividade manual a ser realizada pelo médico triador da instituição hospitalar de destino dos CSH, que tem como objetivo a triagem do pedido de referenciação.
O preenchimento do ecrã referente à triagem do pedido de referenciação deverá ser realizado pelo(s) médico(s) triador(es) associado(s) à especialidade de triagem do pedido de referenciação, na instituição de destino dos cuidados de saúde hospitalares. O médico triador deverá proceder com o preenchimento dos campos habilitados para o efeito de acordo com o seu parecer podendo estar ou não de acordo com os dados do formulário registados pelo médico da instituição de origem.
O processo de triar o pedido de referenciação permite explicar as ações que o utilizador pode realizar ao aceder ao formulário, tendo sempre em conta as regras de negócio. Na figura seguinte, é possível visualizar o processo de triar o pedido de referenciação na instituição hospitalar de destino.
59 Alteração realizada no âmbito da v.3.9.
Figura 6 – Fluxo para o processo de triar o pedido60,61
60 Alteração realizada no âmbito da v.3.10.
61 Alteração realizada no âmbito da v.3.13.
6.5. Retriar o pedido
O pedido de referenciação poderá ser retriado as vezes que forem necessárias, mas dentro de um prazo máximo e até se encontrar no estado “Aguarda Agendamento” (inclusive). Na retriagem, o utilizador, não poderá eliminar e/ou editar a informação registada aquando da Triagem e visualizada na secção «Primeira Triagem»62.
O(s) médico(s) triador(es) associado(s) à especialidade de triagem do pedido pode realizar qualquer uma das ações descritas no subcapítulo anterior (ver subcapítulo 6.4), ou seja, pode alterar qualquer um dos campos, habilitados para o efeito de igual forma que na triagem.
Conforme o fluxo, apresentado na figura seguinte, o preenchimento do ecrã referente à retriagem do pedido de referenciação deverá ser realizado pelo(s) médico(s) triador(es) associado(s) à especialidade de triagem do pedido de referenciação, na instituição de destino dos cuidados de saúde hospitalares. O médico triador deverá proceder com o preenchimento dos campos habilitados para o efeito de acordo com o seu parecer podendo estar ou não de acordo com os dados da triagem realizada anteriormente.
6.5.1. Processo
O processo de retriar o pedido de referenciação permite explicar as ações que o utilizador pode realizar ao aceder ao formulário, tendo sempre em conta as regras de negócio. Na figura seguinte, é possível visualizar o processo de retriar o pedido de referenciação na instituição hospitalar de destino.
62 Ver subcapítulo 3.5, Documento de Interface Gráfica (DIG).
Figura 7 – Fluxo para o processo de retriar o pedido63,64
6.6. Reencaminhar o pedido para outra especialidade65
Na instituição hospital de destino, o médico triador, poderá reencaminhar o pedido de referenciação para qualquer especialidade/valência que faça parte da rede do próprio hospital, independentemente de estar ou não aberta ao exterior para a referenciação.66 Estas são as possíveis situações em que um pedido de referenciação poderá ser reencaminhado na própria instituição:
a) A funcionalidade de reencaminhar o pedido de referenciação para outra especialidade deverá estar habilitada, independentemente do estado, em que o pedido de referenciação se encontre, seja “Aguarda Triagem”, “Aguarda Agendamento” ou “Agendado”, podendo o médico triador,
63 Alteração realizada no âmbito da v.3.10. 64 Alteração realizada no âmbito da v.3.13. 65 Alteração realizada no âmbito da v.3.10. 66 Alteração realizada no âmbito da v.3.16.
encaminhar o pedido de referenciação para outra especialidade, da instituição hospitalar, sempre que necessário;
b) Caso o pedido se encontre no estado “Agendado” e caso seja pretendido reencaminhar o pedido de referenciação para outra especialidade, é necessário que se proceda com o cancelamento do agendamento, e para isso deverá ser selecionado um motivo, da listagem de motivos, que serão parametrizados no BackOffice do RSE SIGA, que leve ao cancelamento do agendamento, de forma a que posteriormente se possa reencaminhar o pedido de referenciação para outra especialidade, da instituição hospitalar;
c) Caso o médico triador pretenda, poderá selecionar a opção de reencaminhar o pedido de referenciação para outra especialidade, que faça parte da rede do próprio hospital, caso o pedido de referenciação se encontre num dos estados enunciados acima e caso no seu entender considere que a especialidade registada no formulário não é a adequada para se dar seguimento ao pedido de referenciação;
d) Caso na triagem, o médico triador não se encontre associado à especialidade para triagem selecionada, então o médico triador não poderá dar seguimento com o processo de triagem e dessa forma, o médico triador deverá reencaminhar o pedido para a especialidade pretendida através da funcionalidade Reencaminhar o pedido para outra especialidade onde poderá selecionar qualquer rede de referenciação do próprio hospital e de forma facultativa, registar informações e/ou notas adicionais consideradas de interesse e posteriormente gravar os registos efetuados no pedido.
Assim que o médico triador confirmar a ação de reencaminhar o pedido para a especialidade pretendida o(s) médico(s) triador(es) associado(s) à especialidade de triagem, selecionada, deverá(ão) visualizar na listagem o(s) pedido(s) que está(ão) a aguardar triagem.
Conforme o fluxo apresentado na figura seguinte, o preenchimento do ecrã referente a reencaminhar o pedido de referenciação para outra especialidade deverá ser realizado pelo(s) médico(s) triador(es), na instituição de destino dos cuidados de saúde hospitalares. O médico triador deverá proceder com o preenchimento dos campos habilitados para o efeito.
6.6.1. Processo
O processo de reencaminhar o pedido de referenciação para outra especialidade, da mesma instituição hospitalar, permite explicar as ações que o utilizador pode realizar ao aceder ao formulário, tendo sempre em conta as regras de negócio. Na figura seguinte, é possível visualizar o processo de reencaminhar o pedido de referenciação para outra especialidade.
Figura 8 – Fluxo para o processo de reencaminhar o pedido para outra especialidade67,68
67 Alteração realizada no âmbito da v.3.10.
68 Alteração realizada no âmbito da v.3.13.
6.7. Devolver o pedido para os CSP
Caso o médico triador considere que o pedido de referenciação carece de informação clínica ou que existem dados em falta e sem esses requisitos não seja possível proceder com a avaliação apropriada para a triagem do pedido de referenciação, o médico triador poderá devolver o pedido para os CSP de forma a obter informação adicional para a correta avaliação da triagem a realizar. Nesta situação, o pedido seguirá para os CSP de forma a que possa ser tratado pelo médico prescritor na instituição de origem e este analise os motivos da devolução do pedido e proceda posteriormente à complementação do pedido e ao envio do mesmo com informação clínica, de forma a complementar a informação já submetida, e enviando de novo o pedido de referenciação dos CSP para a instituição de Destino69.
O médico triador poderá devolver o pedido de referenciação as vezes necessárias para o médico prescritor nos CSP, enquanto o pedido estiver no estado “Aguarda Triagem” (inclusive), ou seja, antes de ser triado70. Após o mesmo ser triado, a funcionalidade de devolução para os CSP deverá ser desabilitada e o utilizador não poderá realizar a devolução do pedido para a instituição de origem71. Contudo, caso o pedido de referenciação ao invés de ter sido enviado pela instituição de origem, ter sido criado localmente, ou seja, ter sido criado pelo assistente técnico dos cuidados de saúde hospitalares, através da transcrição do pedido em papel, nesta situação o sistema informático local de destino não deverá habilitar a funcionalidade de devolver o pedido para os CSP e dessa forma o pedido de referenciação não poderá ser devolvido pelo médico triador para os cuidados de saúde primários72.
Assim que o pedido for devolvido, o sistema informático local de destino deverá notificar o RSE SIGA e a instituição de origem sobre a devolução do pedido junto com a atualização do estado do pedido para “Devolvido” e com a informação referente ao motivo de devolução e observações referentes à devolução, caso existam73.
Assim que o pedido for devolvido, o sistema informático local deverá notificar o RSE SIGA sobre a devolução do mesmo. Posteriormente, o RSE SIGA deverá notificar o utente a respeito da devolução do pedido para a instituição de origem com as seguintes informações: número do pedido, valência (especialidade), instituição para onde o pedido foi devolvido (instituição/ACES e polo/CSP), motivo da devolução do pedido,
69 Ver subcapítulo 3.7, Documento de Interface Gráfica (DIG).
70 Alteração realizada no âmbito da v.3.9.
71 Ver subcapítulo 3.7.1.1, Documento de Interface Gráfica (DIG).
72 Alteração realizada no âmbito da v.3.9.
73 Ver subcapítulo 3.7.1.1, Documento de Interface Gráfica (DIG).
observações referentes ao motivo da devolução do pedido, instituição que efetuou a devolução do pedido (instituição hospitalar e polo hospitalar) e o contacto da instituição de origem para onde o pedido foi devolvido74.
Conforme o fluxo, apresentado na figura seguinte, o preenchimento do ecrã referente à devolução do pedido de referenciação deverá ser realizado pelo(s) médico(s) triador(es) associado(s) à especialidade de triagem do pedido de referenciação, na instituição de destino dos cuidados de saúde hospitalares. O médico triador deverá proceder com o preenchimento dos campos habilitados para o efeito.
6.7.1. Processo
O processo de devolver o pedido de referenciação permite explicar as ações que o utilizador pode realizar ao aceder ao formulário, tendo sempre em conta as regras de negócio. Na figura seguinte, é possível visualizar o processo de devolver o pedido de referenciação da instituição hospitalar de destino, para a instituição dos cuidados de saúde primários de origem.
74 Ver subcapítulo 7.2.1, Documento de Interface Gráfica (DIG).
Figura 9 – Fluxo para o processo de devolver o pedido para os CSP75,76
75 Alteração realizada no âmbito da v.3.10.
76 Alteração realizada no âmbito da v.3.13.
6.8. Agendar a consulta
Após a realização da triagem do pedido de referenciação, o(s) médico(s) triador(es) associado(s) à especialidade de triagem e/ou o assistente técnico da instituição hospitalar de destino poderão efetuar o agendamento da consulta para o pedido em questão no sistema informático local de destino77.
Assim que a consulta for agendada no Hospital, o sistema informático local deverá notificar o RSE SIGA sobre o agendamento da consulta. Posteriormente, o RSE SIGA deverá notificar o utente a respeito do agendamento da consulta com as seguintes informações: número do pedido, a data/hora do agendamento da consulta, valência (especialidade), local da consulta (instituição e polo hospitalar), e o contacto da instituição de destino onde se vai realizar a consulta78.
Caso o utente tenha um pedido de consulta ativo no hospital, e no caso do assistente técnico agendar uma consulta sem estar associada a qualquer pedido de referenciação, o sistema deverá despoletar um aviso para informar o utilizador, de que existe um pedido de referenciação ativo para o utente. Caso o pedido de referenciação se apresente no estado “Aguarda Agendamento”, e no caso do assistente técnico agendar uma consulta sem estar associada a qualquer pedido de referenciação, deverá ser despoletada uma mensagem a questionar o utilizador se pretende ou não associar essa consulta, ao pedido de referenciação.
Conforme o fluxo apresentado na figura seguinte, o preenchimento do ecrã referente ao agendamento do pedido de referenciação poderá ser realizado pelo(s) médico(s) triador(es) associado(s) à especialidade de triagem do pedido de referenciação ou pelo AT, na instituição de destino dos cuidados de saúde hospitalares. Os utilizadores deverão proceder com o preenchimento dos campos habilitados para o efeito. Caso seja necessário, o AT pode alterar a especialidade no momento de agendamento da consulta, dentro do conjunto valência/subvalência registado.79
Contudo, na sequência de uma consulta sem agendamento, o sistema informático local da instituição de destino, não deverá enviar nenhuma mensagem a notificar o RSE SIGA sobre o agendamento da consulta80,81.
77 Ver subcapítulo 3.10.1.1, Documento de Interface Gráfica (DIG).
78 Ver subcapítulo 7.2.1, Documento de Interface Gráfica (DIG).
79 Alteração realizada no âmbito da v3.14
80 Ver subcapítulo 3.4.1, Documento de Interface Gráfica (DIG).
81 Alteração realizada no âmbito da v.3.9.
6.8.1. Processo
O processo de agendar a consulta referente ao pedido de referenciação permite explicar as ações que o utilizador pode realizar ao aceder ao formulário, tendo sempre em conta as regras de negócio. Na figura seguinte, é possível visualizar o processo de agendar o pedido de referenciação na instituição hospitalar de destino.
Figura 10 – Fluxo para o processo de agendar a consulta
6.9. Cancelar o agendamento da consulta
Após a realização do agendamento da consulta referente ao pedido de referenciação, o(s) médico(s) triador(es) associado(s) à especialidade de triagem e/ou o assistente técnico da instituição hospitalar de destino poderão efetuar o cancelamento do agendamento da consulta para o pedido em questão no sistema
informático local de destino, sempre que necessário. Os motivos para cancelamento do agendamento serão parametrizados no BackOffice do RSE SIGA82.
Assim que o agendamento da consulta for cancelado no Hospital, o sistema informático local destino deverá notificar o RSE SIGA e a instituição origem sobre o cancelamento do agendamento da consulta. Posteriormente, o RSE SIGA deverá notificar o utente a respeito do cancelamento do agendamento da consulta com as seguintes informações: número do pedido, a data/hora do agendamento da consulta, valência (especialidade), local da consulta (instituição e polo hospitalar), motivo do cancelamento do agendamento, observações referentes ao motivo do cancelamento do agendamento, e o contacto da instituição de destino onde a consulta foi desmarcada83,84.
Conforme o fluxo apresentado na Figura 10 – Fluxo para o processo de agendar a consulta, o preenchimento do ecrã referente ao cancelamento do agendamento do pedido de referenciação poderá ser realizado pelo(s) médico(s) triador(es) associado(s) à especialidade de triagem do pedido de referenciação ou pelo AT, na instituição de destino dos cuidados de saúde hospitalares. Os utilizadores deverão proceder com o preenchimento dos campos habilitados para o efeito.
6.9.1. Processo
O processo de cancelar o agendamento da consulta referente ao pedido de referenciação permite explicar as ações que o utilizador pode realizar ao aceder ao formulário, tendo sempre em conta as regras de negócio. Na Figura 10 – Fluxo para o processo de agendar a consulta, é possível visualizar o processo de cancelar o agendamento da consulta referente ao pedido de referenciação na instituição hospitalar de destino.
6.10. Reagendar a consulta
Sempre que necessário, seja por motivo do utente, seja por motivo da instituição, qualquer consulta poderá ser reagendada para uma nova data e hora85.
A pedido do utente, a consulta só poderá ser reagendada uma única vez. O utente poderá justificar e solicitar o reagendamento da consulta apenas uma vez. Se na data da consulta reagendada o utente faltar,
82 Ver subcapítulo 3.11, Documento de Interface Gráfica (DIG). 83 Ver subcapítulo 7.2.1, Documento de Interface Gráfica (DIG). 84 Ver subcapítulo 6.16 Cancelar Pedidos no Hospital.
85 Ver subcapítulo 3.12, Documento de Interface Gráfica (DIG).
mesmo que justifique esta falta, o sistema não poderá permitir o novo agendamento e deverá cancelar a consulta e o pedido.
O sistema local de destino deverá verificar se o motivo de reagendamento é imputado ao utente ou à instituição de destino. Após essa verificação e se se verificar que é a segunda vez que o reagendamento é realizado a pedido do utente, o sistema local de destino impede essa ação em causa, exibindo uma mensagem informando o utilizador de que a consulta já foi reagendada a pedido do utente e que um novo agendamento só será possível por motivos imputados à instituição de destino.
Por motivos imputados à instituição de destino, a consulta poderá ser reagendada sem um número limite máximo de vezes. Não se poderá restringir o reagendamento de uma consulta mesmo que já tenha sido ultrapassado os Tempos Máximos de Resposta Garantidos (TMRG).
Relativamente às faltas é necessário referir que:
• Se o utente faltar, dispõe de sete dias sucessivos para justificar a falta. Será dada uma tolerância de mais dois dias sucessivos para benefício do utente que por algum motivo só consiga apresentar a justificação após os sete dias;
• Caso o utente não justifique a sua falta neste prazo (sete dias sucessivos + dois dias sucessivos), o estado do pedido será atualizado para “Cancelado (por motivo de falta injustificada)”, não será mais possível reagendar o pedido e o RSE SIGA notificará o utente do cancelamento do pedido. Após o nono dia, em caso do utente se dirigir aos cuidados de saúde hospitalares, o mesmo deverá ser encaminhado para a instituição dos CSP de forma a dar seguimento junto do médico da instituição de origem à solicitação de um novo pedido de referenciação;
• No caso de o utente ter faltado por motivo de óbito, então a consulta e o pedido serão cancelados pelo assistente técnico do Hospital e nesta situação o RSE SIGA não enviará nenhuma notificação ao utente;
• Caso o utente justifique a sua ausência no prazo acima indicado (sete dias sucessivos + dois dias sucessivos):
o O utente poderá informar uma nova data e hora pretendida para a consulta e o assistente técnico do Hospital poderá proceder ao seu agendamento;
o Após ter sido cancelado o agendamento anterior e após o AT nos CSH agendar para a nova data/hora solicitada, pelo utente, o estado do pedido transitará de novo para o estado “Agendado”. O RSE SIGA notificará o utente do novo agendamento da consulta;
o O reagendamento da consulta poderá ser feito em qualquer data disponível. Contudo, se essa data ultrapassar o TMRG, será gerado um alerta para o diretor clínico e assistente técnico notificando-os do prazo. Caso o utente falte à consulta, já previamente reagendada, o pedido e a consulta serão cancelados;
• Caso a instituição não possa realizar a consulta, na data e hora suposta, então o assistente técnico do Hospital deverá contactar o utente após ter sido cancelado o agendamento anterior, e após o AT nos CSH agendar para a nova data/hora pretendida, o estado do pedido transitará de novo para o estado “Agendado”. O RSE SIGA notificará o utente do novo agendamento da consulta.
Quando for necessário reagendar uma consulta por falta justificada do utente, o reagendamento poderá ser feito de duas formas:
a. Na primeira situação, o utente sugere uma data e o assistente técnico agenda a consulta na data indicada pelo utente. O RSE SIGA notificará o utente do novo agendamento da consulta;
b. Na segunda situação, o utente sugere uma data a partir da qual estará disponível para nova consulta. O Hospital, então, será responsável por marcar uma nova data a partir da data sugerida pelo utente. O RSE SIGA notificará o utente do novo agendamento da consulta.
Assim que se der o reagendamento da consulta, o sistema informático local destino deverá notificar o RSE SIGA e a instituição origem sobre o novo agendamento da consulta. Posteriormente, o RSE SIGA deverá notificar o utente a respeito do novo agendamento da consulta com as seguintes informações: número do pedido, a data/hora do agendamento da consulta, valência (especialidade), local da consulta (instituição e polo hospitalar), e o contacto da instituição de destino onde se vai realizar a consulta86.
6.10.1. Processo
Conforme o fluxo apresentado na Figura 10 – Fluxo para o processo de agendar a consulta, o preenchimento do ecrã referente ao cancelamento do agendamento do pedido de referenciação e posteriormente o preenchimento do ecrã referente ao novo agendamento do pedido de referenciação, poderá ser realizado pelo(s) médico(s) triador(es) associado(s) à especialidade de triagem do pedido de
86 Ver subcapítulo 7.2.1, Documento de Interface Gráfica (DIG).
referenciação ou pelo AT, na instituição de destino dos cuidados de saúde hospitalares. Os utilizadores deverão proceder com o preenchimento dos campos habilitados para o efeito.
O processo de cancelar o agendamento da consulta referente ao pedido de referenciação e o processo de realizar um novo agendamento da consulta permite explicar as ações que o utilizador pode realizar ao aceder ao formulário, tendo sempre em conta as regras de negócio. Na Figura 10 – Fluxo para o processo de agendar a consulta, é possível visualizar o processo de cancelar o agendamento da consulta e de realizar um novo agendamento da consulta referente ao pedido de referenciação na instituição hospitalar de destino.
6.11. Associação do pedido de referenciação a uma consulta87
O processo de associar o pedido de referenciação a uma consulta pode ser realizado pelo(s) médico(s) triador(es) associado(s) à especialidade de triagem e/ou pelo assistente técnico da instituição hospitalar de destino desde que o pedido de referenciação se encontre no estado “Aguarda Agendamento”.
Através desta funcionalidade, o utilizador tem a possibilidade de associar o pedido de referenciação a uma consulta já marcada, efetivada ou sem agendamento.
6.11.1. Processo
O fluxo apresentado na figura seguinte ilustra o processo referente à associação da referência a uma consulta, na instituição de destino dos cuidados de saúde hospitalares. Os utilizadores deverão proceder com o preenchimento dos campos habilitados para o efeito.
O processo de associar a referência a uma consulta permite explicar as ações que o utilizador pode realizar ao aceder ao formulário, tendo sempre em conta as regras de negócio. Na figura seguinte, é possível visualizar o processo de associar o pedido de referenciação a uma consulta, na instituição hospitalar de destino.
87 Alteração realizada no âmbito da v.3.10.
Figura 11 – Fluxo para o processo de associar o pedido de referenciação a uma consulta88
6.12. Efetivar a consulta
Este processo é realizado pelo assistente técnico do Hospital de destino no momento em que o utente se apresenta na instituição de destino para a consulta referente ao seu pedido de referenciação89.
Assim que a admissão do utente for realizada, o sistema informático local destino deverá notificar o RSE SIGA e a instituição origem sobre a atualização do estado do pedido para “Efetivado”, a data e a hora da efetivação da consulta, número que identifica o profissional que efetivou a consulta e o nome desse profissional.
O médico que irá proceder com a realização da consulta só poderá dar início à realização da mesma e complementar o processo clínico com dados do utente depois de assinalada a admissão do utente no Hospital.
Quando uma consulta no Hospital for efetivada e houver o cancelamento dessa efetivação (o qual ocorre
por motivo de engano), o pedido terá de voltar ao estado “Agendado”.
88 Alteração realizada no âmbito da v.3.10.
89 Ver subcapítulo 3.14, Documento de Interface Gráfica (DIG).
6.12.1. Processo
O fluxo apresentado na figura seguinte ilustra o processo referente à efetivação da consulta pelo AT, na instituição de destino dos cuidados de saúde hospitalares. Os utilizadores deverão proceder com o preenchimento dos campos habilitados para o efeito.
O processo de efetivar a consulta referente ao pedido de referenciação permite explicar as ações que o utilizador pode realizar ao aceder ao formulário, tendo sempre em conta as regras de negócio. Na figura seguinte, é possível visualizar o processo de efetivar o pedido de referenciação na instituição hospitalar de destino.
Figura 12 – Fluxo para o processo de efetivar a consulta
6.13. Realizar a consulta9091
O pedido de referenciação é concluído com a realização da consulta (com a presença ou sem presença do utente) ou com o cancelamento da mesma.92
O processo de realizar a consulta no sistema informático é executado pelo médico responsável pela realização da consulta. O médico deverá registar no sistema informático local a hora de início, informações pertinentes no Diário Clínico e a hora de fim da realização da consulta, informando desta maneira o sistema de que a consulta foi realizada.
Nas situações em que este preenchimento não tenha sido realizado, o sistema informático local deverá garantir que surjam, para o utilizador, mensagens de aviso que o direcionem para o preenchimento dos campos referentes tanto à hora de início como à hora de fim da consulta. No caso em que nenhuma hora seja registada no sistema informático local e não haja registos no Diário Clínico, o pedido de referenciação permanecerá no mesmo estado (Efetivado), não se verificando a transição para o estado seguinte (Realizado).
Existem duas situações em que há atualização automática do estado da consulta de “Efetivado” para “Realizado”:
‒ Consulta em que a hora de início da consulta seja registada e tenha sido registada informação no Diário Clínico mas o médico não tenha registado a hora de fim da consulta, antes deste sair do ecrã correspondente, o sistema informático local deverá disponibilizar para o utilizador mensagens de aviso de que existe essa hora por registar. Contudo, caso esses avisos sejam ignorados, o sistema informático local irá mostrar uma outra mensagem de aviso que informará o utilizador de que irá ser despoletado um mecanismo automático (job) que irá fechar, ou seja, irá realizar automaticamente todas as consultas, com a data do dia da sua efetivação e hora 23:59. Com este processo garante-se que todas as consultas com hora de início de consulta registada e registo no Diário Clínico ficam realizadas, ou seja, concluídas.93
‒ Consulta em que a hora de início da consulta e a hora de fim da consulta não tenham sido registadas mas o médico tenha registado informações no campo Diário Clínico, o episódio no
90 Alteração realizada no âmbito da v.3.12. 91 Alteração realizada no âmbito da v.3.17 92 Alteração realizada no âmbito da v3.19 93 Alteração realizada no âmbito da v.3.16.
estado “Efetivado” passará para o estado “Realizado”, com a data do dia da sua efetivação e com hora de início 23:58 e hora fim 23:59.94
Não havendo qualquer registo no Diário Clínico nas duas situações descritas acima, não se procederá a qualquer atualização. De notar que estas atualizações não substituem as boas práticas de registo estipuladas no Procedimento para a Conclusão da Referenciação dos Cuidados de Saúde Primários para 1ª Consulta de Especialidade Hospitalar.
Assim que a realização da consulta for registada, o sistema informático local da instituição de destino, deverá notificar o RSE SIGA e a instituição de origem sobre a atualização do estado do pedido para “Realizado”, a data e a hora da realização da consulta, valência, subvalência, tipo de consulta, local da consulta (Instituição/Polo), número que identifica o profissional que realizou a consulta e o nome desse profissional.
6.13.1. Processo
Conforme o fluxo apresentado na figura seguinte, o preenchimento do ecrã referente à realização do pedido de referenciação deverá ser realizado pelo médico responsável pela realização da consulta referente ao pedido de referenciação, na instituição de destino dos cuidados de saúde hospitalares. O médico deverá proceder com o preenchimento dos campos habilitados para o efeito.
O processo de realizar a consulta referente ao pedido de referenciação permite explicar as ações que o utilizador pode realizar ao aceder ao formulário, tendo sempre em conta as regras de negócio. Na figura seguinte, é possível visualizar o processo de realizar o pedido de referenciação na instituição hospitalar de destino.
94 Alteração realizada no âmbito da v.3.16.
Figura 13 – Fluxo para o processo de realizar a consulta
6.14. Cancelar o pedido no Hospital
Na instituição hospital de destino, estas são as possíveis situações em que um pedido de referenciação poderá ser cancelado95,96:
• Independentemente do estado do pedido, seja “Aguarda Triagem”, “Aguarda Agendamento” ou “Agendado” tanto o médico triador como o assistente técnico da instituição hospitalar de destino poderão cancelar o pedido, sempre que necessário, ao selecionar da listagem de motivos, que serão parametrizados no BackOffice do RSE SIGA, um motivo específico para o cancelamento do pedido;
• Caso o pedido se encontre no estado “Agendado” e caso o médico ou o AT necessitarem de cancelar o pedido, deverá ser selecionado um motivo, da listagem de motivos, que serão parametrizados no BackOffice do RSE SIGA, que leve ao cancelamento do agendamento e do pedido, ou seja, que levará primeiro à desmarcação da consulta e posteriormente ao cancelamento do pedido;
Seguidamente, o pedido de cancelamento deverá ser enviado ao RSE SIGA que, de acordo com as regras de negócio, poderá autorizar o cancelamento ou não do pedido solicitado, ou seja, o RSE SIGA irá verificar se
95 Ver subcapítulo 3.16, Documento de Interface Gráfica (DIG).
96 Alteração realizada no âmbito da v.3.9.
o estado em que o pedido se encontra possibilita o cancelamento e se o motivo selecionado está parametrizado em BackOffice para cancelar ou não e, de seguida, para qualquer resposta, será sempre enviada uma mensagem de retorno.
Em caso de insucesso do cancelamento do pedido, ou seja, caso o pedido não possa ser cancelado, o RSE SIGA informará o utilizador do motivo do não cancelamento do pedido. Caso contrário, o RSE SIGA confirmará e informará o utilizador de que o pedido foi cancelado com sucesso.
Assim que o cancelamento do pedido for realizado no Hospital, o sistema informático local destino deverá notificar o RSE SIGA e a instituição origem sobre o cancelamento do pedido de referenciação. Posteriormente,
o RSE SIGA deverá notificar o utente, exceto se o motivo de cancelamento for óbito, a respeito do cancelamento do pedido de referenciação com as seguintes informações: número do pedido, valência (especialidade), local da consulta (instituição e polo hospitalar), motivo do cancelamento do pedido, observações referentes ao motivo do cancelamento do pedido, e o contacto da instituição de destino onde o pedido foi cancelado.
6.14.1. Processo
Conforme o fluxo apresentado na figura seguinte, o preenchimento do ecrã referente à realização do cancelamento do pedido de referenciação deverá ser realizado pelo médico ou pelo assistente técnico, na instituição de destino dos cuidados de saúde hospitalares. O utilizador deverá proceder com o preenchimento dos campos habilitados para o efeito.
O processo de cancelar o pedido de referenciação permite explicar as ações que o utilizador pode realizar ao aceder ao formulário, tendo sempre em conta as regras de negócio. Na figura seguinte, é possível visualizar
o processo de cancelar o pedido de referenciação na instituição hospitalar de destino.
Figura 14 – Fluxo para o processo de cancelar o pedido de referenciação
6.15. Funcionalidade de acompanhamento de gestão de pedidos de referenciação no destino
O sistema informático local da entidade de destino deverá disponibilizar uma funcionalidade para o acompanhamento de pedidos de referenciação, que tem como objetivo permitir aos utilizadores fazer a monitorização de todos os pedidos, visualizar e consultar todas as informações registadas nas várias secções do pedido de referenciação97.
Através desta funcionalidade, na instituição de destino dos cuidados de saúde hospitalares, os profissionais médicos e AT poderão visualizar informação referente aos pedidos de referenciação, contudo os assistentes técnicos não poderão visualizar qualquer tipo de informação clínica98.
As informações a serem exibidas nesta funcionalidade deverão ser ordenadas por ordem decrescente, do pedido mais recente para o mais antigo, possibilitando também que o utilizador do sistema possa reordenar por qualquer que seja a coluna de informação.
O histórico do pedido deve ser exibido pelo sistema local de destino, tendo como propósito apresentar ao utilizador as informações relativas ao ciclo de vida do pedido, ou seja, todas as ações ocorridas sob o pedido em questão.
7. Duplicação de pedidos de referenciação
A definição de pedidos de referenciação duplicados é assumida como pedidos para o mesmo utente, mesma valência e mesma subvalência. Contudo, no que diz respeito à definição de duplicação de pedidos de referenciação, a mesma só deverá acontecer de forma impeditiva para o sistema informático local de origem, que deverá impedir que seja criado um pedido duplicado se já existir um pedido ativo, (se o pedido não estiver no estado “Cancelado (Origem)”, “Cancelado (Destino)” ou “Realizado”), para o mesmo utente, mesmo valor de valência e mesmo valor de subvalência, ainda por concluir. Caso o pedido de referenciação se encontre nos seguintes estados finais, “Cancelado (Origem)”, “Cancelado (Destino)” ou “Realizado”, então será possível criar um outro pedido para o mesmo utente, mesma valência e mesma subvalência, independentemente do destino99,100.
Para o sistema informático local de destino, o comportamento a adotar deverá ser apenas de aviso, nunca tendo um procedimento impeditivo. O sistema informático local de destino, aquando da criação do pedido de referenciação localmente, deverá apenas despoletar um aviso, para o utilizador, de que já existe um pedido ativo, (se o pedido não estiver no estado “Cancelado (Origem)”, “Cancelado (Destino)” ou “Realizado”), para o mesmo utente, mesmo valor de valência e mesmo valor de subvalência, ainda por concluir, não devendo nunca impedir que o pedido de referenciação seja criado. Aquando da triagem e da retriagem caso o médico triador selecione, para o mesmo utente, o mesmo conjunto de valor de valência e subvalência que já exista num pedido ativo, o aviso a ser despoletado de pedido duplicado deverá mostrar ao utilizador o número do pedido de referenciação do pedido ativo, de forma a que este tome conhecimento da situação e posteriormente analise e decida, procedendo em conformidade com as suas necessidades, se pretende dar resposta aos dois pedidos de referenciação em separado ou se pretende cancelar um por ser um pedido repetido do outro101.
99 Ver capítulo 5, Documento de Interface Gráfica (DIG).
100 Alteração realizada no âmbito da v.3.9.
101 Alteração realizada no âmbito da v.3.9.
8. Impressão de pedidos de referenciação
Esta funcionalidade, deverá estar sempre habilitada, seja qual for o estado em que o pedido de referenciação se encontre, tanto na instituição de origem como na instituição de destino e consiste numa atividade manual onde o profissional de saúde, médico, ou assistente técnico em caso de necessidade de imprimir o pedido ou se for solicitado pelo utente, poderá através do sistema informático local da instituição de origem ou de destino, efetuar a impressão, do pedido de referenciação, em versão simplificada ou completa, em formato PDF102.
A versão simplificada é uma versão onde não consta qualquer tipo de informação clínica e é recomendável que seja a versão que o assistente técnico tenha à sua disposição, na instituição de origem como na instituição de destino, e que seja a versão que deverá ser entregue ao utente se solicitado por este. Da mesma forma, o utente poderá consultar esta versão simplificada do pedido de referenciação na “Área do Cidadão” ou através de contato com o Centro de Contacto do SNS24. O pedido de referenciação poderá ser consultado pelo utente através da “Área do Cidadão”, contudo este apenas terá acesso a informações referentes às instituições de origem e de destino. O utente não terá acesso, por esta via, a qualquer tipo de informação clínica registada no pedido103.
A versão completa é uma versão onde consta toda a informação clínica. Contudo, o médico, da instituição de origem ou da instituição de destino, caso assim o pretenda, poderá entregar ao utente esta versão onde constará informação mais detalhada do pedido de referenciação104.
102 Alteração realizada no âmbito da v.3.9. 103 Alteração realizada no âmbito da v.3.9. 104 Alteração realizada no âmbito da v.3.9.
9. Anexos
Anexo I
Documento de Análise Funcional – Interface Gráfica da Fase 2 (CSP»CSH)
RSE SIGA_DIG -
Analise Funcional Fas
Anexo II
Documento de Análise Funcional do BackOffice do RSE SIGA
SPMS_SIGA RSE BACKOFFICE DAF v7
Anexo III
Documento de Interface Gráfica do BackOffice do RSE SIGA
SPMS_SIGA RSE BACKOFFICE DIG v1.