Segurança

1. A nossa abordagem

A Practiq detém informação clínica sobre doentes reais. A segurança não é uma preocupação secundária — é a espinha dorsal da forma como operamos. Esta página descreve as medidas que tomamos para manter essa informação segura, no espírito do artigo 19.º da POPIA. É actualizada sempre que alguma dessas medidas se altera de forma material.

2. Onde os seus dados vivem

Os dados de produção estão alojados na União Europeia, em infra-estrutura que cumpre normas internacionais reconhecidas de segurança. Não armazenamos dados de produção em portáteis de programadores, em ambientes de não-produção, ou em qualquer local fora do ambiente de alojamento controlado.

Os testes e o desenvolvimento ocorrem contra fixtures sintéticas e amostras desidentificadas. Nenhuma informação real de doente entra alguma vez num ambiente de não-produção.

3. Cifragem

• Em trânsito. Cada ligação à Practiq — aplicação, página de marcação, API — é cifrada com cifragem de transporte ao padrão actual da indústria. Protocolos mais antigos e mais fracos são recusados na fronteira.
• Em repouso. A base de dados subjacente e o armazenamento são cifrados. Por cima disso, os identificadores mais sensíveis — números de identificação e números de plano médico — são cifrados novamente na camada da aplicação com uma chave única para cada prática. Os identificadores cifrados de uma prática são ilegíveis mesmo para alguém com acesso total à base de dados.
• Gestão de chaves. As chaves-mestras de cifragem são guardadas num cofre de segredos gerido, nunca são escritas no controlo de versões ou em registos, e são rodadas segundo um calendário documentado.

4. Isolamento entre práticas

Os dados de cada prática estão isolados dos de qualquer outra prática ao nível da base de dados. O acesso requer uma associação activa à prática — não existe um conjunto partilhado de registos contra o qual uma prática pudesse alguma vez consultar outra. As acções no servidor impõem a mesma fronteira ao nível da aplicação, pelo que seria necessária uma falha simultânea de duas salvaguardas independentes para uma fuga ser possível.

5. Controlo de acessos

• Dentro de uma prática, as permissões são baseadas em papéis e seguem padrões de privilégio mínimo. O pessoal de recepção vê a agenda e os dados de contacto; os profissionais vêem o registo clínico; proprietários e administradores vêem tudo. Os papéis são atribuídos e revogados a partir da página de definições da equipa.
• Os identificadores cifrados (número de identificação, número de plano médico) são mascarados por defeito. Revelar um exige um clique deliberado, e cada revelação é registada com o utilizador, o momento e a origem.
• O nosso pessoal não tem acesso de rotina aos dados de clientes. O acesso a produção é concedido apenas mediante necessidade documentada, limitado no tempo, totalmente registado, e revogado no momento em que o trabalho termina. A autenticação de dois factores é obrigatória para qualquer conta interna com qualquer alcance a produção.

6. Autenticação

• Os utilizadores autenticam-se com e-mail e palavra-passe. As palavras-passe são guardadas como hashes irreversíveis com salt — o valor original nunca nos é visível.
• As sessões têm duração curta e são renovadas silenciosamente em segundo plano. Terminar a sessão invalida a sessão activa de imediato.
• Monitorizamos abusos de credential-stuffing e de pedidos de reposição de palavra-passe, e limitamos a actividade suspeita por origem.

7. Trilho de auditoria

Cada alteração a um registo clínico é registada: quem a fez, quando, de onde, e quais eram os valores antes e depois. As gravações de áudio, transcrições e rascunhos gerados por IA carregam uma impressão digital adicional da entrada que os produziu, pelo que qualquer decisão clínica pode ser retraçada à posteriori para uma revisão interna, um pedido de um regulador, ou para a tranquilidade do próprio profissional.

O registo de auditoria é append-only. As entradas passadas não podem ser editadas ou eliminadas por ninguém, incluindo o nosso próprio pessoal.

8. IA e dados do doente

• A informação do doente nunca é usada para treinar modelos de aprendizagem automática — nem nossos, nem de ninguém. Os fornecedores que suportam a transcrição e a redacção clínica estão contratualmente proibidos de treinar com base nos pedidos que lhes enviamos, e são obrigados a eliminar o estado intermédio assim que a resposta é devolvida.
• Os pedidos de IA são enviados por canais cifrados com o payload mínimo necessário para produzir a saída. Os identificadores são tokenizados sempre que a tarefa o permitir.
• Nenhuma saída de IA é alguma vez emitida sem revisão e aprovação explícita de um profissional. Os rascunhos de receita passam ainda por uma verificação determinística de segurança contra a medicação activa e alergias do doente antes de qualquer modelo ser consultado.

9. Cópias de segurança e recuperação

• Os dados de produção são copiados diariamente, cifrados, e retidos durante trinta (30) dias. A recuperação a um ponto no tempo está disponível para os últimos sete (7) dias, pelo que podemos regressar a qualquer momento ao minuto da última semana.
• Realizamos um ensaio de restauro para um ambiente isolado pelo menos mensalmente e verificamos a integridade do que sai.
• O nosso objectivo de tempo de recuperação para produção é de quatro (4) horas; o nosso objectivo de ponto de recuperação é de quinze (15) minutos.

10. Testes de segurança e actualizações

• As dependências de software são continuamente verificadas quanto a vulnerabilidades conhecidas. As alertas críticos de segurança são aplicados nas setenta e duas (72) horas seguintes à disponibilização de uma correcção.
• Cada alteração à plataforma passa por verificações automatizadas de segurança antes de poder chegar a produção.
• É realizado anualmente, no mínimo, um teste de penetração independente. Os achados são remediados consoante a gravidade, e um sumário está disponível aos clientes sob acordo de confidencialidade mútuo.

11. Resposta a incidentes

Mantemos um procedimento documentado de resposta a incidentes com gravidades definidas, rotação de prevenção, e caminhos de comunicação claros. Sempre que tenhamos fundamentos razoáveis para acreditar que informação pessoal foi acedida ou adquirida por pessoa não autorizada, notificamos o Oficial de Informação da prática afectada nas setenta e duas (72) horas seguintes à identificação do incidente, em conformidade com o artigo 22.º da POPIA, e fornecemos a informação necessária para que a prática possa por sua vez notificar o Regulador da Informação e quaisquer doentes afectados.

12. Reportar uma preocupação de segurança

Acolhemos relatórios de vulnerabilidades ou problemas de segurança. Envie um e-mail para support@starlightgroupsa.co.za com o máximo de detalhe que conseguir. Reconhecemos os relatórios no prazo de um dia útil e comprometemo-nos a trabalhar com investigadores de boa-fé.

Para acordos de processamento de dados, informação de auditoria ou questões detalhadas antes da contratação, consulte /popia ou contacte support@starlightgroupsa.co.za.