Estruturar o plano de site de uma plataforma de saúde não se resume a alinhar páginas em um menu. A arquitetura da informação condiciona a circulação de dados entre profissionais, pacientes e sistemas terceiros. Com a entrada em vigor progressiva do regulamento europeu sobre o espaço europeu de dados de saúde (EHDS) a partir de março de 2027, e as trocas transfronteiriças previstas a partir de março de 2029, a concepção de uma árvore de navegação adequada torna-se um pré-requisito técnico tanto quanto editorial.
Interoperabilidade e plano de site: por que a árvore de navegação condiciona as trocas de dados
A maioria dos guias sobre a criação de sites médicos aborda o plano de site como um exercício editorial. Classificam-se as páginas por especialidade, adiciona-se um formulário de contato e, em seguida, passa-se ao design. Essa abordagem omite um parâmetro estruturante: a interoperabilidade impõe uma organização funcional dos conteúdos.
Uma plataforma que troca documentos com Meu espaço saúde é avaliada em vários eixos, incluindo urbanização, segurança, ética e conformidade com o RGPD. Isso significa que o plano de site deve distinguir claramente os espaços públicos (informações gerais, apresentação dos cuidados), as contas profissionais, os percursos dos pacientes e as funções de troca de documentos.
Um exemplo concreto dessa lógica aplicada à cartografia de uma plataforma pode ser visto em o site Irist Saúde, onde as seções refletem uma segmentação por tipo de usuário e por função, em vez de uma simples hierarquia editorial.
Construir o sitemap em torno de dados estruturados (padrões FHIR, DICOM) em vez de PDFs ou formulários proprietários também prepara a plataforma para as obrigações do EHDS. Os retornos de campo divergem sobre o nível de maturidade real das plataformas existentes em relação a essas exigências, mas a direção regulatória é clara.
MSSanté no plano de site: uma seção funcional, não uma página de contato
Integrar a mensageria segura de saúde (MSSanté) na árvore de navegação de uma plataforma merece uma reflexão específica. As recomendações recentes preveem interfaces padronizadas, o envio de documentos de saúde estruturados em conformidade com o CI-SIS, a integração automática das mensagens recebidas no prontuário do paciente e o uso do Diretório de Saúde para selecionar os destinatários.
MSSanté não pode ser reduzida a um simples link no rodapé. O plano de site deveria dedicar uma seção funcional distinta a ela, com no mínimo:
- Um espaço de envio e recebimento de documentos estruturados, acessível a partir do painel de controle profissional
- Um sistema de seleção de destinatários conectado ao Diretório de Saúde, para evitar erros de endereçamento
- Um mecanismo de arquivamento automático que classifica as trocas no prontuário do paciente correspondente
Tratar MSSanté como um bloco isolado, escondido em uma subpágina “contato”, resulta em perder a rastreabilidade das trocas e complicar a coordenação dos cuidados entre profissionais.
Acessibilidade RGAA e arquitetura da informação em saúde
Uma plataforma de saúde se dirige a usuários cujas capacidades variam consideravelmente: idosos, pacientes em situação de deficiência, cuidadores pouco familiarizados com o digital. O Referencial Geral de Melhoria da Acessibilidade (RGAA) impõe critérios que influenciam diretamente a estrutura do plano de site.
A acessibilidade se define desde a hierarquia das páginas, não no momento da auditoria final. Um menu de navegação muito profundo (mais de três níveis) penaliza os usuários de leitores de tela. Títulos de seções ambíguos (“Meus serviços”, “Meu espaço”) complicam a navegação para pessoas com dificuldades cognitivas.
As obrigações variam conforme o tamanho da estrutura e seu status, mas as plataformas que tratam de dados de saúde estão sujeitas a um nível de exigência elevado. Vários pontos merecem atenção especial ao projetar o sitemap:
- Cada página deve ter um título único e descritivo, legível fora de contexto por uma tecnologia de assistência
- Os percursos dos pacientes (agendamento, consulta de resultados, mensageria) devem ser acessíveis em um número limitado de cliques a partir da página inicial
- Os documentos baixáveis (receitas, laudos) devem ser agrupados em uma seção dedicada, em vez de dispersos em várias seções
Prever essas restrições desde a fase de concepção do plano de site evita reformulações custosas uma vez que a plataforma esteja em produção.
Dados estruturados e padrões FHIR: o que o sitemap deve antecipar
O regulamento EHDS empurra as plataformas de saúde para um modelo onde os dados são reutilizáveis e interoperáveis por padrão. Isso não diz respeito apenas às bases de dados internas: o próprio plano de site deve refletir essa lógica.
Organizar os conteúdos em torno de recursos FHIR (Fast Healthcare Interoperability Resources) significa, por exemplo, que a seção “Prontuário do paciente” não contém simplesmente PDFs escaneados. Ela expõe dados estruturados consultáveis por outros sistemas autorizados. O plano de site deve, portanto, prever URLs estáveis para cada tipo de recurso, em vez de caminhos dinâmicos que mudam a cada atualização do software.
Uma URL estável por tipo de recurso facilita a indexação e a interoperabilidade. Os percursos de cuidados, os documentos de coordenação, os resultados de exames: cada um desses elementos deve ocupar um lugar identificável na árvore de navegação.
Gestão dos direitos de acesso na árvore de navegação
O plano de site de uma plataforma de saúde não é totalmente público. Algumas seções são visíveis apenas para profissionais autenticados, outras para pacientes conectados. Essa segmentação dos direitos de acesso deve ser pensada desde a concepção da árvore de navegação, e não adicionada posteriormente por filtros técnicos.
Prever um sitemap XML distinto para os motores de busca (páginas públicas apenas) e uma cartografia interna completa para a gestão dos processos constitui uma boa prática. Confundir sitemap público e cartografia funcional interna gera falhas de segurança e problemas de indexação.
A arquitetura de uma plataforma de saúde se constrói na interseção de restrições raramente reunidas em outros lugares: regulamentação sobre dados pessoais, exigências de acessibilidade, interoperabilidade técnica entre sistemas, coordenação entre profissionais com perfis variados. O plano de site não é um entregável secundário a ser produzido ao final do projeto. É a base sobre a qual repousa a capacidade da plataforma de cumprir sua função primordial: fazer circular a informação correta para o usuário certo, no momento certo.
