PACS's tartaruga?

Nesse mais de 10 anos, montamos uma infinidade de estruturas de complexas de comunicação otimizada para ambientes médicos. Percebemos que, quando se centraliza a entrega de imagens, o volume e a simultaneidade de dados colapsa os sistemas PACS's convencionais, mesmo aqueles com bancos de dados capazes de suportar grandes volumes e quantitativo de processos - como o Oracle Enterprise Edition, por exemplo.

Reuni, e compartilho com todos, algumas impressões que podem ser úteis aos gestores desses sistemas, visando reduzir o impacto e a lentidão.

• A máxima da engenharia de sistemas se emprega: tudo depende da escala. A capacidade operacional depende do desenho da solução feita e das necessidades. Se seu fornecedor não faz uma escolha de ambiente específico ao seu caso, ou parece estar "chutando" alguma coisa, desconfie: ele pode não saber o que está fazendo;
• Não use compressão para disco JPEG2000. Consome muita memória no processo de aquisição da imagem e conversão, além de ser lento individualmente. Use, no máximo, o JPEG sem perdas ou nenhuma, para evitar erro e queda do nó dicom: Essa regra serve para quase todos, e normalmente é a que mas ocasiona falha: Nosso sistema comprime para guarda muito mais eficientemente do que os que os PACS utilizam, e trabalha antes da entrega a ele. Já entrega compresso e otimizado, e guarda os dados antes dele;
• Mantenha ativo um volume de exames de alguns meses - recomendamos sempre no máximo 6 meses. Um dia depois, já mantenha em acervos externos de guarda de dados: Nosso sistema funciona como um nó DICOM com possibilidade de consulta, ou como um servidor remissivo de arquivos, o que facilita muito sua acessibilidade;
• Amplie a quantidade de conexões simultâneas que o banco de dados pode ter, para algo como o triplo de quantidade de conexões simultâneas em DICOM possíveis: Alguns PACS e modalidades enviam dados de forma simultânea entre eles;
• Ajuste o banco de dados para que o mesmo possa utilizar tabelas maiores de informações: Parece relativamente óbvio, mas é uma das falhas mais comuns;
• Crie um disco de SWAP de, no mínimo, o mesmo tamanho da memória RAM atual. A literatura do Unix, por exemplo, recomenda o dobro no minimo, em discos SCSI;
• Regra de Ouro: Não use discos SSD para SWAP. Além de reduzir muito o tempo de vida útil dos discos (acessos em grande quantidade), gera MUITO erro de disco !!!
• Se não for usar um equipamento de storage integrado ao hardware, como um SAN convencional, e se for possível escolher, trabalhe com um NAS baseado em Unix;
• Caso use NAS para armazenamento, não utilize CIFS, ou o sistema de arquivos da Microsoft para comunicação de ambientes remotos. Sua capacidade máxima de transmissão ocupa somente 20% do canal disponível, pelo tamanho de seu header e forma de operação;
• Discos NTFS não são recomandáveis no uso de gravações simultâneas em disco. Use outros sistemas de arquivo, como o ex2, ext3 ou o ext4, do Unix, para serviço de arquivos e guardar. Armazena mais, comprime um pouco e é mais confiável;
• Sempre o ideal é não utilizar o mesmo equipamento físico para firewall e o PACS: Mais interessante separar em máquinas diferentes, mesmo virtuais - usam pilhas e consomes muita memória por conexão.
• PACS estruturados sobre servidores Java com Banco de Dados sempre ativos: BD é altamente consumidor de memória. O banco sem movimento ou operação já consome, em média, 20% do Hardware físico: Separe sempre o servidor PACS de tudo, incluindo seu Banco de Dados, Firewall e do Servidor de Arquivos - caso use.

Apenas para salientar, quem trabalha conosco não sofre com isso. Nosso sistema de comunicação faz uma espécie de janelamento e controle de acesso ao PACS, sendo a entrega feita pelo nosso equipamento e respeitando sua capacidade.

Além disso, guardamos os dados em acervos quase ilimitados de data centers já compressos. Muito mais fácil de operação, com capacidade de compressão de mais de 95%. Em suma, paga somente 5% da necessidade de dados e de comunicação!

Ainda sofrendo com isso? Quer nossa ajuda? Contacte-nos, teremos prazer em ajudar!