Cibersegurança em Ultrassom Legado 2026: Aplicar Patch, Segmentar, Isolar ou Substituir?

Neste guia

• A carta com dois relógios
• Nove em cada dez projetos liberados são anteriores à lei
• O catálogo que não' contém seu scanner
• O catálogo que contém
• O que o histórico de segurança diz e não' diz
• O panorama de ameaças, dimensionado com sinceridade
• Como posso descobrir o que este equipamento executa?
• Aplicar patch, segmentar, isolar ou substituir, definidos com precisão
• Onde a manutenção independente se encaixa e onde ela para
• Cláusulas de aquisição para o próximo sistema
• Metodologia e limitações
• Perguntas frequentes
• Conclusão

A carta com dois relógios

Ponto principal: uma notificação de encerramento de suporte não é um evento único. A carta da Olympus sobre o EU-ME2 separa pelo menos cinco relógios — e o próprio OEM afirma quais pararam e quais não'.

Leia a notificação da Olympus com atenção, pois ela declara formalmente quase tudo o que este relatório defende ¹. O fator determinante não foi o desgaste do equipamento: "Isso é necessário porque os componentes de software subjacentes do EU-ME2' já não são suportados por seus fornecedores." A postura de risco no momento da carta era limpa: "A Olympus não identificou nenhuma vulnerabilidade nesses produtos e não tem conhecimento de nenhum ataque cibernético direcionado a esses produtos." O que se encerra é a possibilidade de uma correção futura por software: nenhuma "contramedida baseada em software para quaisquer vulnerabilidades futuras" e quaisquer atualizações futuras de software "seriam voltadas à funcionalidade, e não à cibersegurança." Os controles compensatórios que o fabricante recomenda são físicos e em nível de rede — travas de porta USB com chave, travas de porta LAN com chave, lacres com evidência de violação. E o suporte a hardware — a reposição de peças — continua explicitamente.

São cinco relógios distintos em uma única carta, e eles expiram em momentos diferentes:

1. Utilidade clínica — o sistema ainda produz as imagens de que seus procedimentos necessitam? (A Olympus não afirma que o EU-ME2 deixou de ser clinicamente útil. E não deixou'.)
2. Suporte de produto do OEM — a janela de suporte comercial, que a carta encerra parcialmente.
3. Suporte a software e componentes — o relógio que de fato desencadeou a carta: fornecedores upstream encerraram o suporte para componentes internos do dispositivo.
4. Suportabilidade dos controles de segurança — após a carta, os controles viáveis são os físicos e de rede listados pelo OEM, e não patches.
5. Manutenibilidade física — "continuará sendo oferecida." Ainda em andamento.

O International Medical Device Regulators Forum define "legado" exatamente desta forma: um dispositivo legado é aquele que "não pode ser razoavelmente protegido contra ameaças atuais de cibersegurança" — uma condição de suportabilidade, e não uma faixa de idade. Um dispositivo novo pode ser legado; um antigo pode ser suportável ⁶. O marco legal dos EUA reforça a mesma estrutura: a Seção 524B da Lei FD&C exige um plano de gerenciamento de vulnerabilidades, um processo de aplicação de patches e uma lista de componentes de software (SBOM) — mas apenas para submissões cobertas recebidas em ou após 29 de março de 2023, e ela não é retroativa ⁷. A orientação atual de cibersegurança pré-mercado da FDA's, finalizada em fevereiro de 2026, rege novas submissões; ela não retroage para alcançar a base instalada ⁸.

Portanto, a pergunta "qual é a idade do scanner?" é a primeira pergunta errada. As perguntas corretas são: quais dos cinco relógios expiraram, quais ainda estão correndo e a quem pertence cada um. O restante deste relatório responde a essas perguntas com dados.

Nove em cada dez projetos liberados são anteriores à lei

Conclusão: a população de projetos de ultrassom é, em sua esmagadora maioria, anterior a qualquer exigência aplicável de cibersegurança — e como as liberações continuam chegando em um patamar estável de 55 a 83 por ano frente a uma vida útil de 10 a 15 anos, a população anterior à legislação não sairá de circulação por idade em nenhum horizonte de planejamento.

Utilizamos a base de dados 510(k) da FDA's — todas as liberações pré-mercado já emitidas — e a filtramos para os dois códigos de produto que definem um sistema de ultrassom diagnóstico tipo carrinho/console: as máquinas com sistema operacional, porta de rede e endereço IP hospitalar. Isso resulta em 2,066 decisões de liberação de agosto de 1977 a junho de 2026 ². Em relação aos três marcos de cibersegurança:

Ao ampliar o filtro para todos os onze códigos de produto de ultrassom — sondas, transdutores, Dopplers fetais —, o padrão se mantém em 91.8% dos 2,726 registros; o achado não é um artefato da escolha do código ².

Três pontos fundamentais de precisão acompanham cada número desta seção. Uma liberação é um projeto, não uma unidade — a FDA não publica dados de base instalada, portanto nada aqui diz "N máquinas em operação." Pré-524B não significa inseguro — a lei criou uma obrigação, não uma vulnerabilidade, e muitos fabricantes mantinham programas sérios de segurança muito antes de 2023. E as 204 decisões pós-transição (9.9%) são um teto, não uma contagem — o 524B passa a vigorar na data em que a submissão é recebida, e as decisões ocorrem meses após o recebimento, de modo que parte dessas 204 foi liberada sob submissões anteriores à lei.

O que os números de fato estabelecem é estrutural: o mecanismo legal que força a existência de um processo de patches e de um SBOM foi acionado depois que quase toda a população de projetos liberados já existia.

Vejamos agora as faixas de antiguidade que os hospitais realmente operam:

Todos os consoles liberados entre 2006 e 2020 — a faixa que predomina nas frotas em operação, considerando a vida útil real de 10 a 15 anos documentada em nosso relatório de fim de vida útil de frotas — são anteriores à lei, sem exceção. Mesmo a década completa mais recente de projetos liberados é 70% pré-524B. Um hospital que adquire uma substituição hoje tem cerca de uma chance em dez de que o projeto da 'substituição' tenha sido liberado sob a lei de dispositivos cibernéticos, e até mesmo isso é uma superestimativa.

E a população não está saindo de circulação por envelhecimento. O volume de liberações tem se mantido em uma faixa estável de 55 a 83 sistemas por ano desde 2012, sem nenhum aumento após 2014 ou 2023 ²:

Esperar que a frota se modernize não é uma estratégia de segurança cibernética. É um plano de várias décadas.

Mais um fato estrutural, pois ele fundamenta tudo na seção de hierarquia de evidências abaixo: a frota é multifabricante por concepção, e a cauda de fabricantes é muito longa. 532 nomes distintos de solicitantes liberaram um sistema de ultrassom desde 1977; 238 solicitantes distintos liberaram um sistema apenas em 2011–2026; mais da metade de todos os fabricantes que já liberaram um sistema liberou exatamente um ². Para 2011–2026, as oito maiores famílias de OEMs respondem por apenas 55.2% das liberações — 349 de 1,005 vieram de solicitantes fora dos quatorze nomes que todos reconhecem:

Cada um desses fornecedores tem sua própria prática de divulgação de segurança de produtos — ou nenhuma. E a maioria dos fornecedores por trás das faixas de idade em serviço silenciou como solicitante nos EUA: de 167 fornecedores que liberaram um sistema entre 2006 e 2018, 116 (69.5%) não têm nenhuma liberação de ultrassom nos EUA decidida em 2020–2026 ². A ausência de uma nova liberação não é prova de que uma empresa encerrou as atividades — empresas são adquiridas, mudam de nome, obtêm liberações sob uma controladora ou vendem em outros mercados —, mas é um limite inferior de quão difícil é na prática a instrução de "ligar para o fabricante para obter um patch validado". A contraparte frequentemente não é um solicitante ativo nos EUA.

O catálogo que não contém o seu scanner

Conclusão: O catálogo Known Exploited Vulnerabilities da CISA's é a ferramenta de priorização correta para o parque de TI de um hospital's e um erro de categoria quando aplicado a um scanner — seus 276 fornecedores não incluem nenhum fabricante de diagnóstico por imagem, e seu prazo mediano de remediação de 21 dias é algo que nenhum dispositivo médico validado pode cumprir.

Se uma equipe de segurança hospitalar consulta uma lista federal para orientar a aplicação de patches, essa lista é o catálogo Known Exploited Vulnerabilities (KEV) da CISA's — a lista de vulnerabilidades confirmadas como exploradas ativamente, com prazos de remediação que vinculam agências federais sob a Diretiva Operacional Vinculante 22-01 ⁵¹¹. O catálogo de 7 de agosto de 2026 contém 1,662 entradas em 276 fornecedores distintos. Ao analisar todas as 1,662 em relação a fabricantes de diagnóstico por imagem e dispositivos médicos, você encontra zero — nenhuma GE HealthCare, nenhuma Philips, nenhuma Siemens Healthineers, nenhuma Canon Medical, nenhuma Mindray, nenhuma Samsung Medison, nenhuma Esaote. A única entrada genuinamente da área da saúde em todo o catálogo é um motor de integração de TI em saúde (NextGen Healthcare Mirth Connect). O pano de fundo Microsoft/Windows com o qual a versão anterior desta análise começou — 382 entradas da Microsoft, 170 rotuladas como "Windows" — é real, mas é contexto, não uma constatação sobre ultrassom ⁵.

Dois números do KEV realmente importam para um parque de diagnóstico por imagem, e nenhum deles é a contagem de fornecedores:

Uma em cada cinco vulnerabilidades com exploração conhecida está associada a ransomware. 338 de 1,662 entradas (20.3%) contêm o sinalizador de campanha conhecida de ransomware da CISA's — e as entradas em plataformas Microsoft ficam cerca de 50% acima, em 27.2% ⁵. Para um dispositivo cujo valor clínico é sua disponibilidade, a associação com ransomware é o enquadramento correto da ameaça, não a contagem bruta de CVEs.

O relógio do KEV é de 21 dias. A janela mediana entre a inclusão de uma entrada no KEV's e sua data limite federal de remediação é de 21 dias ⁵. Um dispositivo médico não pode operar com esse relógio: um patch deve ser validado pelo fabricante em relação à configuração liberada antes que um hospital possa instalá-lo com segurança, e a própria orientação pós-mercado da FDA's contempla 30 dias para comunicação e 60 dias para remediação de riscos não controlados ¹⁰ — duas a três vezes a janela do KEV. Onde o OEM não oferece mais suporte à plataforma, não há relógio algum. Essa lacuna — 21 dias de expectativa corporativa contra um ciclo de validação do OEM medido em meses, ou nunca — é a razão operacional pela qual "segmentar" e "isolar" existem como disposições.

A declaração precisa do que uma entrada do Windows no KEV informa sobre um scanner: uma camada de uso comum que está sob alguns dispositivos médicos está sendo explorada no ambiente real. Ela não informa se a configuração validada do seu scanner's inclui esse componente, se o expõe ou se dispõe de uma correção aprovada pelo OEM. Componentes embarcados em dispositivos aparecem no KEV sob o nome do fornecedor do componente's, nunca sob o do fabricante do dispositivo's — razão exata pela qual os SBOMs existem, e exatamente por que o catálogo da próxima seção's é mais importante.

O catálogo que realmente informa

Conclusão: Os Avisos Médicos ICS da CISA's são o registro do setor de dispositivos — e, nesse registro, quando uma linha de produtos de ultrassom é citada, a solução nunca foi, até hoje, um patch completo. Metade dos avisos de diagnóstico por imagem verificados deixou pelo menos um produto sem correção de software; a instrução oficial foi restringir o acesso ou substituir.

A CISA mantém uma série dedicada de avisos para dispositivos médicos: os Avisos Médicos ICS (ICSMA). Enumeramos toda a série — 176 avisos ao longo dos anos completos de 2016–2025, além de mais 10 até 9 de agosto de 2026 — e obtivemos e verificamos individualmente os 18 avisos que afetam produtos de diagnóstico por imagem ³. (Outros 27 títulos relacionados a diagnóstico por imagem, em sua maioria visualizadores DICOM e softwares PACS, foram catalogados, mas não verificados detalhadamente; a contagem de avisos mede a atividade de divulgação, não a incidência, e o total de um ano's mescla novos avisos com revisões.)

O resultado de disponibilidade de patch nos 18 avisos verificados de diagnóstico por imagem:

Metade dos alertas de imagem deixou pelo menos um produto citado sem nenhum patch disponível. E o recorte mais restrito e incisivo: todos os quatro alertas que citam explicitamente linhas de produtos de ultrassom — produtos de imagem e ultrassom da GE, produtos de ultrassom da GE, sistemas de ultrassom Philips, Philips HDI 4000 — tinham cobertura incompleta de patches para as linhas de ultrassom citadas no momento da publicação ^312131415. Três dos quatro não tinham patch algum para ultrassom; o quarto contava com uma correção lançada para uma de cinco linhas de produtos citadas, com as demais "planejadas". Quatro alertas são uma amostra pequena, e nós a apresentamos exatamente como tal — mas a direção não poderia ser mais clara, e ela provém do próprio texto de remediação do órgão regulador'.

Leia o que os alertas realmente instruem, textualmente:

"A GE Healthcare recomenda que as organizações restrinjam o acesso físico aos dispositivos por indivíduos não autorizados." — alerta de escape de quiosque em ultrassom da GE, no qual a mitigação é o controle de acesso físico, não um patch ¹⁴

"O ciclo de vida de suporte para o sistema de ultrassom Philips HDI 4000 terminou em 31 de dezembro de 2013… Os usuários devem implementar controles para limitar o acesso à rede e considerar a substituição do sistema." — o caso de fim de vida útil, em que a solução é a substituição ¹⁵

"Se a segurança e o tratamento do paciente não estiverem em risco, desconecte o produto da rede e utilize em modo autônomo." — imagem molecular da Siemens, a instrução de isolamento expressa da forma mais direta possível ¹⁶

Patch, segmentar, isolar, substituir: não são uma invenção deste relatório'. Elas são as quatro soluções que o registro oficial de alertas já utiliza. A contribuição deste relatório' é definir critérios de passagem e condições de parada para elas.

O exemplo prático — com suas ressalvas no mesmo fôlego. Em maio de 2024, pesquisadores da Nozomi Networks (uma fornecedora de segurança de TO; identifique-a como tal) publicaram 11 vulnerabilidades no sistema de ultrassom Vivid T9 da GE HealthCare's, em sua aplicação web Common Service Desktop e no software da estação de trabalho EchoPAC — sendo a mais grave uma falha de credenciais fixadas no código com classificação CVSS 9.6 — e demonstraram uma prova de conceito de ransomware bloqueando o scanner ¹⁷. Três fatos tornam este o caso de segurança em ultrassom mais instrutivo já registrado. Primeiro, a porta de entrada da cadeia's foi um escape do modo quiosque divulgado originalmente em 2020 (CVE-2020-6977) — uma falha de quatro anos ainda era o primeiro elo, e a resposta da CISA's foi reeditar o mesmo comunicado de 2020 como "Update A", em vez de abrir um novo ¹⁴. Segundo, como observou uma análise do setor, o Vivid T9 "é essencialmente um PC completo executando uma versão do Windows 10 personalizada pela GE" ¹⁸ — o console é uma máquina Windows revestida por uma interface clínica, e o shell do quiosque é o limite de segurança. A idade não era a variável; o projeto de contenção, sim. Terceiro — e estas ressalvas não são opcionais —, a cadeia do Vivid T9 exige acesso físico ao teclado do console's, a GE publicou mitigações em seu portal de segurança, a GE declarou a jornalistas que não havia recebido nenhum relato de exploração, e o próprio boletim da GE's lista um conjunto abrangente de produtos de ultrassom não vulneráveis, incluindo o Vivid E9 (todas as versões) e o LOGIQ E9/E8/S8 (todas as versões) ¹⁷¹⁹²⁰. Citar a demonstração de ransomware sem a pré-condição de acesso físico distorceria a fonte — e é precisamente esse tipo de enquadramento alarmista que este relatório existe para substituir.

Uma observação sobre os padrões de divulgação, formulada com cautela: não existe nenhum comunicado ICSMA dedicado para Canon Medical, Hologic, Sectra, Mindray, Samsung Medison, Hitachi ou Esaote. Isso reflete onde os pesquisadores de segurança concentraram suas análises e como transcorreu o processo de divulgação coordenada — não constitui evidência de que os produtos desses fabricantes' sejam mais seguros, e este relatório não faz tal inferência ³.

O que o histórico de segurança diz e o que não diz

Conclusão prática: Os canais de eventos adversos e de recalls da FDA's são quase perfeitamente silenciosos quanto à cibersegurança em ultrassom — zero menções cibernéticas em 8,525 relatórios desde 2019, apenas um recall em todo o histórico —, enquanto o mesmo canal de recalls registra 18 eventos cibernéticos em outros tipos de dispositivos. Esse silêncio reflete uma via de notificação, não um nível de risco. Esperar por um sinal de segurança é esperar por um sinal que, estruturalmente, não pode chegar.

Pesquisamos o texto descritivo de cada relatório de eventos adversos de ultrassom no banco de dados MAUDE da FDA's — 13,213 relatórios em todo o histórico, distribuídos por onze códigos de produtos de ultrassom ⁴. Todo o vocabulário de cibersegurança produz ocorrências de apenas um dígito: "ransomware" duas vezes, "malware" três vezes, "cybersecurity" cinco vezes; "hacked", "unauthorized access", "phishing", "data breach" e "firewall", zero vezes cada. Ao restringir o período de 2019 a 2026 — 8,525 relatórios —, todos os termos cibernéticos caem para zero.

As ocorrências não nulas sobrepostas remontam quase inteiramente a um único episódio: WannaCry, junho de 2017. A busca em todo o banco de dados do MAUDE — todos os tipos de dispositivos, todos os anos — por "wannacry" retorna 12 relatórios, e cinco são de ultrassom: cinco sistemas e estações de trabalho da família Siemens ACUSON, notificados em uma única janela de dez dias ⁴²¹.

Vale a pena citar a própria narrativa do fabricante' nesses relatórios, porque ela descreve o modelo de ameaça melhor do que qualquer fornecedor de segurança:

"A exploração da vulnerabilidade permite o controle remoto total do dispositivo sem qualquer outro pré-requisito além do fato de que o computador atacante está na mesma rede que o dispositivo de ultrassom." ²¹

Esse é o argumento da segmentação, apresentado pelo OEM. A mesma narrativa indica a via real de dano clínico — "um possível atraso em um procedimento para um paciente sedado, a reinserção de um transdutor transesofágico ou cateter, ou a repetição de um exame de ecocardiograma de estresse" — dano à disponibilidade, e não diagnósticos corrompidos. E registra a resolução: "O problema foi solucionado com lançamentos de patches de software em junho de 2017" ²¹. Uma falha comum no SMB do Windows atingiu três plataformas ACUSON distintas; o OEM validou e disponibilizou patches em poucas semanas, notificando sob a orientação pós-mercado de 2016 da FDA' ¹⁰. O único episódio real nos registros defende a aplicação de patches e a segmentação ao mesmo tempo — o que é a tese das quatro opções em miniatura. ("Lesão" nesses relatórios é a classificação de notificabilidade do fabricante' para dano potencial, declarado condicionalmente — não uma lesão confirmada em paciente.)

O registro de recalls conta a mesma história com um grupo de controle mais nítido. Entre os 542 registros de recall de ultrassom no banco de dados da FDA', exatamente um é motivado por cibersegurança: um recall de 2008 de um console de ultrassom intravascular que "pode estar infectado com um worm (malware de computador)" ⁴²². Mas o canal de recalls é comprovadamente capaz de registrar eventos cibernéticos — ele contém 18 eventos distintos de recall motivados por cibersegurança em outros tipos de dispositivos desde 2008: sistemas de infusão, monitores de pacientes, ventiladores pulmonares, sequenciadores, um visualizador de imagens médicas, um sistema de informação em radioterapia, um robô cirúrgico, um controlador de suporte circulatório ⁴. O canal funciona. Os eventos cibernéticos em ultrassom simplesmente não chegam por meio dele.

Por que o silêncio? Porque os canais de notificação apontam para outro lugar. O MAUDE registra óbitos, lesões graves e mau funcionamento relacionados a dispositivos; um evento de ransomware que deixe um scanner fora de operação por um dia sem uma consequência clínica notificável geralmente não constitui um MDR de forma alguma. Os hospitais relatam incidentes cibernéticos ao HHS OCR, à CISA, ao FBI e às suas seguradoras — e não a um banco de dados de segurança de dispositivos. Portanto, os usos corretos desse silêncio são dois, e apenas dois: ele derruba a ideia de que uma equipe de HTM possa esperar por um sinal de segurança antes de agir e justifica tomar a decisão de destinação com base em evidências de ativos e de avisos de segurança. Isso nunca deve ser invertido em "sem notificações, portanto seguro".

Para fins de completude, o registro ordinário de falhas, recalculado na exportação atual: no conjunto de 2,534 relatórios de ultrassom em 2025–2026, 94.3% correspondem a mau funcionamento, 4.9% a lesões e 0.6% a óbitos — e nada disso é cibernético ⁴. A distribuição é estável em relação aos números de 2020–2026 do nosso relatório de parque de julho de 2026's. O software já é a segunda maior causa-raiz de recalls de ultrassom (125 de 542 registros — por defeitos funcionais, não por segurança). A história da confiabilidade e a história da segurança são histórias diferentes.

O panorama de ameaças, dimensionado com honestidade

Conclusão: os números em nível setorial justificam inventário, segmentação e monitoramento disciplinados. Nenhum deles é uma estatística de ultrassom, e este relatório se recusa a fingir o contrário — o panorama honesto já é alarmante o suficiente sem inflação.

Cada número nesta seção traz a indicação de seu publicador e de sua amostra, porque cada um deles provém de uma contagem de agência governamental ou da telemetria própria de um fornecedor de segurança's — e não de um censo.

Volume de violações no setor de saúde (dados do HHS OCR). Em relação a 2025, 772 violações de 500+ registros constavam no portal do OCR até junho de 2026, afetando 139.7 milhões de indivíduos — um número que cresce durante meses à medida que o portal é atualizado retroativamente (o recorte de fevereiro de 2026 do mesmo ano mostrava 710 violações e 61.6 milhões de indivíduos; sempre date o recorte) ²³. No período mais recente contabilizado com clareza, os incidentes de hacking/TI representaram 77.8% das grandes violações no setor de saúde (301 de 387, H1 2024) ²³.

Exposição de sistemas de imagem conectados (Claroty Team82, 2025 — telemetria do fornecedor proveniente de 351 organizações de saúde que executam seu produto; não é um censo). Dos 195,659 dispositivos de imagem no conjunto de dados da Claroty's, 28% apresentam vulnerabilidades conhecidas e exploradas, e 8% tanto apresentam KEVs vinculadas a ransomware quanto estão conectados de forma insegura à internet — uma combinação que afeta 85% das organizações de saúde da amostra ²⁴. A categoria de "sistemas de imagem" da Claroty's cita o ultrassom como um componente, mas não publica números exclusivos para ultrassom — portanto, trata-se de um contexto para a categoria à qual o ultrassom pertence, não de uma estatística de ultrassom.

Economia do ransomware (Sophos, outubro de 2025 — pesquisa com organizações vítimas). O cenário na área da saúde melhorou em 2025: 58% dos prestadores atingidos se recuperaram em até uma semana (acima dos 21% em 2024), e a mediana do valor de resgate exigido caiu 91% em relação ao ano anterior, para aproximadamente $343,000–$345,000 ²⁵. A melhoria é real; o volume de ameaças não está desaparecendo.

O enquadramento do FBI's (Private Industry Notification, setembro de 2022). O FBI alertou que dispositivos médicos sem patches e desatualizados oferecem oportunidades de ataque, citando "um relatório de pesquisa realizado por uma empresa de segurança cibernética" — o FBI não cita o nome da empresa — que constatou que 53% dos dispositivos médicos conectados em hospitais apresentavam vulnerabilidades críticas conhecidas. A frase mais duradoura do PIN's não precisa de estatísticas: "O hardware de dispositivos médicos frequentemente permanece ativo por 10-30 anos; no entanto, os ciclos de vida do software subjacente são especificados pelo fabricante… permitindo que atores de ameaças cibernéticas tenham tempo para descobrir e explorar vulnerabilidades" ²⁶. (Omitimos deliberadamente dois números amplamente repetidos — "6.2 vulnerabilidades por dispositivo" e "40% dos dispositivos em fim de vida útil" — porque sua fonte primária não pode ser rastreada; o próprio FBI os atribui apenas a um relatório não identificado.)

Infraestrutura de imagem exposta (Trend Micro, dados de varredura de novembro–dezembro de 2025). 3,627 servidores DICOM estavam diretamente acessíveis a partir da internet pública em 100+ países; apenas 0.14% utilizavam TLS ²⁷. Esta é a camada de PACS/armazenamento em torno dos dispositivos de imagem, e não os próprios scanners — mas é a rede com a qual esses scanners se comunicam.

E o incidente canônico, corrigido. O impacto do WannaCry's no NHS é a história que todos citam e a maioria cita de forma incorreta. O National Audit Office do Reino Unido constatou 34 trusts infectados e impedidos de acessar dispositivos, com pelo menos 81 de 236 trusts afetados no total — dois números distintos que não devem ser mesclados — e 6,912 consultas com cancelamento confirmado, com cerca de 19,500 estimadas ²⁸. Mas a lição sobre o sistema operacional é o oposto do folclore popular. A própria análise de lições aprendidas do NHS England's: "Este foi um ataque que utilizou uma vulnerabilidade específica do Microsoft Windows, não um ataque a software sem suporte. A maioria dos dispositivos do NHS infectados estava executando o sistema operacional com suporte, porém sem patches, Microsoft Windows 7" — máquinas com Windows XP representavam uma minoria das infecções, reduzidas a 1.8% do parque instalado em janeiro de 2018 ²⁹. O WannaCry não é um argumento de que sistemas operacionais antigos causam violações de segurança. É um argumento de que sistemas com suporte, porém sem patches, causam violações de segurança — o que é uma falha de governança de patches, e não uma falha de idade. Essa é a tese deste relatório's, declarada por um serviço nacional de saúde. (O registro do NHS cita scanners de ressonância magnética e analisadores de sangue entre os equipamentos afetados; nenhuma fonte confirma especificamente sistemas de ultrassom no incidente do NHS — a evidência sobre ultrassom no caso WannaCry é o registro separado do MAUDE dos EUA acima.)

Como posso descobrir o que este equipamento executa?

Conclusão: na maioria das vezes, você 'não consegue' — não a partir de fontes públicas. Zero de dez fabricantes pesquisados publicam um documento aberto de status de suporte ou SO por produto; apenas 8 de 26 plataformas de ultrassom nomeadas tinham um sistema operacional identificável publicamente; os resumos de 510(k) da FDA também não revelam isso. O registro do ativo de que você precisa deve ser obtido no próprio equipamento e exigido do fabricante, pois não pode ser consultado.

Profissionais de HTM fazem essa pergunta publicamente, exatamente com estas palavras — "Como sei se o meu ultrassom roda Windows 10?"; "Existe uma lista mestre de EOL/EOS com a qual eu possa comparar meu inventário?" — e não obtêm nenhuma resposta concreta ³⁰. Tentamos responder a isso de forma sistemática, e o insucesso é a própria constatação.

O levantamento de divulgação dos fabricantes (dez fornecedores, agosto de 2026). Cinco de dez publicam uma lista datada e aberta de avisos ou boletins de segurança: Philips, Siemens Healthineers, Canon Medical, GE HealthCare e Olympus. Zero de dez publicam um documento aberto de status de suporte ou SO por produto. Onde quer que tal repositório exista, ele fica protegido por credenciais de cliente: GE's Product Security Portal ("um portal global seguro baseado na web que oferece aos clientes credenciados um repositório centralizado"), Philips's InCenter e biblioteca MDS² (cadastro por e-mail), Siemens's teamplay Fleet (SBOMs e comunicados anteriores a 2022), Mindray's service portal, Fujifilm's secure request form ^19313233. O padrão exato: a divulgação da vulnerabilidade é pública; o patch validado e o status por produto exigem login. Você pode descobrir gratuitamente que a família do seu scanner foi afetada. Você precisa de uma conta para obter a correção.

O mapeamento entre plataforma e sistema operacional (26 plataformas nomeadas). Apenas 8 puderam ser vinculadas a um sistema operacional documentado a partir de qualquer fonte pública acessível, e apenas três delas chegam ao nível de um documento de OEM que declare isso formalmente — o comunicado da Canon's situando o Windows 10 IoT Enterprise LTSC 2015 no segundo console opcional do Aplio i-series', e a declaração de conformidade DICOM da Esaote's colocando as famílias MyLab no Windows 10 ³³³⁴. Para o GE Voluson série S, LOGIQ E9 e série P, Vivid E9, as famílias Philips EPIQ/Affiniti/HD11/CX50, as séries S e X do Siemens ACUSON, Hitachi/Fujifilm Arietta, Samsung RS80 — nenhuma fonte pública declara o sistema operacional. Verificamos diretamente dois resumos de 510(k) da FDA como teste (uma liberação do GE LOGIQ E10 e uma liberação do Canon Aplio): nenhum dos dois divulga o sistema operacional ². Até mesmo as declarações de conformidade DICOM são inconsistentes — a da Esaote's divulga o sistema operacional; as da Philips's e da GE's não o fazem'. Não existe um documento padrão que um profissional de engenharia clínica possa consultar de forma confiável entre as marcas.

O cronômetro da Microsoft, para quando você de fato identificar a compilação. O Windows XP está 12.3 anos além do fim do suporte; o Windows 7, 6.6 anos; o Windows 8.1, 3.6; o Windows 10 voltado ao consumidor final (22H2) ultrapassou o fim do suporte em outubro de 2025 e agora funciona com atualizações estendidas pagas até, no máximo, 2028 ³⁵. No entanto, as compilações IoT/embarcadas com as quais muitos consoles de fato saem de fábrica divergem drasticamente: o Windows 10 IoT Enterprise LTSC 2019 tem suporte até janeiro de 2029, o LTSC 2021 até janeiro de 2032, e o LTSC da geração de 2024 é baseado no Windows 11 e tem suporte até outubro de 2034 ³⁵. Dois comunicados de OEMs de setembro de 2025 reforçam o mesmo ponto sob a perspectiva dos fabricantes: a Canon Medical e a Philips publicaram, cada uma, respostas sobre o fim de suporte do Windows 10 destacando que a única compilação IoT afetada pelo encerramento de 2025 (LTSB 2015) ou não está presente em seus produtos ou está isolada de redes externas ³³³¹. "Aparece Windows 10 na tela de inicialização" não é, portanto, um dado de inventário — a edição e a compilação diferenciam uma plataforma que expirou em outubro passado de outra com suporte mantido até os anos 2030.

O que isso significa para o registro do ativo. Como nada disso pode ser consultado, deve ser coletado e exigido. No equipamento: versão do software aplicativo, edição/versão/build do SO na tela de informações do sistema (com a data e o método de coleta — nunca uma suposição a partir do tema da área de trabalho), fluxos de rede configurados, estado do acesso remoto e volume local de dados de pacientes. Do fornecedor, por escrito: o status de suporte do produto's com datas separadas para serviço de hardware, manutenção de software e suporte de segurança; o MDS² (Manufacturer Disclosure Statement for Medical Device Security) atual; o SBOM onde a 524B ou contrato lhe dê direito a um; acesso a avisos de segurança por meio de uma conta institucional, em vez da caixa de entrada de um único funcionário's; e o status de patch validado para a build exata que você registrou. "Desconhecido" é um valor permitido no registro — é uma constatação com responsável e prazo definido, não um campo em branco.

Patch, segmentar, isolar ou substituir, definidos com precisão

Conclusão: as quatro disposições são usadas de forma intercambiável na literatura; elas não são intercambiáveis. Cada uma tem uma definição, gates de evidência e uma condição de parada — e custo e cibersegurança são decididos em eixos diferentes da idade.

A literatura existente — incluindo as orientações regulatórias — transita entre essas palavras de forma imprecisa, e essa imprecisão tem consequências: uma frota indicada como "isolada" em uma planilha pode, na prática, estar segmentada, conectada ou meramente desconectada até que alguém precise da worklist. O registro de avisos acima utiliza todas as quatro medidas; aqui está o que cada uma realmente é, quais evidências exige e o que a encerra.

Patch significa uma remediação de software autorizada pelo OEM instalada no dispositivo sob controle de mudanças. Seus gates: um aviso de segurança ou atualização validada que cite exatamente o seu modelo, versão do aplicativo e build; um procedimento definido de backup e rollback; e um teste funcional pós-instalação — inicialização, reconhecimento do transdutor, aquisição, medições, worklist, DICOM store — antes do retorno ao uso clínico. Sua condição de parada: não existir pacote autorizado para a sua configuração ou a validação funcional falhar. Um patch corporativo enviado a um equipamento apenas porque o nome do SO coincide não é um patch; trata-se de uma modificação não controlada de um dispositivo médico validado.

Segmentar significa que o dispositivo permanece conectado, mas apenas por meio de uma lista de permissões (allowlist) documentada: destinos específicos de PACS, worklist, DNS/NTP e assistência remota, com bloqueio por padrão (default-deny) para todo o restante, aplicado em um perímetro que o hospital realmente controla. Seus gates: um mapa de fluxos verificado, objetos de firewall testados em relação a fluxos de trabalho clínicos reais (consulta de worklist, aquisição, armazenamento, recuperação após indisponibilidade) e revisão de logs para verificar tráfego bloqueado, mas necessário. As metas de desempenho setorial do HHS's apontam a segmentação e o inventário de ativos entre as práticas prioritárias, e o modelo zero-trust do NIST's estabelece o princípio fundamental — a localização na rede por si só não confere confiança ³⁶³⁷. Seu limite, declarado com franqueza: a segmentação reduz o alcance; ela não remove o código vulnerável e não protege contra mídias USB ou um protocolo permitido que transporte uma carga maliciosa. Sua condição de parada: os fluxos necessários não podem ser delimitados, ou a aplicação de regras não existe no perímetro relevante.

Isolar é mais rigoroso: o sistema opera sem acesso rotineiro à rede — o comunicado da Siemens's de "desconectar o produto da rede e usar em modo autônomo" e as travas físicas de portas na carta da Olympus ¹⁶¹. Seus critérios de controle: um fluxo de trabalho que se sustenta off-line (entrada de dados demográficos do paciente, saída de imagens, em mídias gerenciadas), autoridade controlada para reconexão e interfaces secundárias desativadas ou bloqueadas. Sua condição de interrupção: o fluxo de trabalho clínico não pode ser executado com segurança off-line, ou a condição de "isolado" não pode ser verificada — um cabo removido hoje e reconectado amanhã não é uma destinação.

Substituir é a destinação quando nem a suportabilidade do software nem os controles compensatórios conseguem sustentar o risco residual — o caso do Philips HDI 4000, em que o próprio comunicado do órgão regulador's diz "considere substituir o sistema" ¹⁵ — ou quando o próprio hardware não for mais passível de manutenção confiável. Seus critérios de controle são um projeto financiado com termos de aquisição em segurança cibernética (próxima seção) e uma desativação controlada: dados de pacientes sanitizados com comprovação, credenciais e certificados revogados, objetos de rede removidos.

Os dois eixos são pontuados separadamente, e nunca por média:

Um transdutor perfeito não pode compensar o acesso remoto descontrolado, e um sistema operacional com todos os patches aplicados não pode compensar uma fonte de alimentação com falha em uma função de cuidados críticos. E todo estado de controle compensatório precisa de uma data de expiração: um responsável, uma data de revisão e um evento definido que o encerre — um patch validado, a entrega da substituição, uma reavaliação de risco. A palavra mais perigosa em um programa de ciclo de vida é "temporariamente".

Se um dispositivo apresentar um sinal suspeito — um destino inesperado no log do firewall, uma reinicialização não explicada, uma solicitação de serviço que ninguém reconhece — a primeira atitude é a coordenação, e não um desligamento por reflexo: confirmar o ativo e o sinal, proteger qualquer procedimento em andamento com o paciente, escolher a contenção menos disruptiva que realmente reduza o risco (bloquear um destino, desativar o acesso remoto, restringir a política de rede), preservar logs e entrar em contato com o canal de segurança de produtos do fabricante's com o modelo, a versão de compilação e a observação exatos. Um dispositivo médico não deve ter sua imagem de disco gerada, ser submetido a varreduras ou ser restaurado aos padrões de fábrica com ferramentas comuns de TI apenas porque as ferramentas estão disponíveis.

Onde a manutenção independente se encaixa e onde ela termina

Conclusão: a carta da Olympus traça o limite melhor do que qualquer consultor: quando o relógio do software para, o relógio do hardware continua correndo — e alguém precisa manter o hardware em funcionamento. Esse é o campo de atuação da manutenção independente, acessado pela mesma estrutura de destinação, e nunca como substituto para ela.

Toda destinação, exceto "substituir imediatamente", pressupõe que o scanner permaneça clinicamente confiável enquanto a decisão cibernética se desenrola. Um hospital que passa um trimestre projetando uma exceção de segmentação para um sistema cuja placa está falhando resolveu o problema errado primeiro. A matriz de dois eixos necessita de evidências reais no eixo físico: códigos de falha e sintomas atuais, condição do transdutor e do conector, isolamento de falhas em nível de placa, integridade da alimentação elétrica e do arrefecimento, disponibilidade de peças para o modelo e histórico de falhas reincidentes.

Essas evidências são a contribuição de uma operação independente de serviços multimarca. Os fatos operacionais verificados da Rongtao Medical' definem o escopo dessa atuação: 35+ engenheiros seniores realizando diagnóstico e reparo em nível de placa, mais de 3,000 SKUs de peças das principais marcas de OEMs, um teste em equipamento real de 48 horas antes do envio com comprovação por foto ou vídeo, prazo padrão de entrega de 5–8 dias úteis, garantia típica de 90 dias, certificação ISO 13485:2016 e ISO 9001:2015 e envio a partir de entreposto aduaneiro para 140+ países ³⁸. Quanto aos aspectos econômicos de extensão versus substituição e às questões de procedência de peças que fundamentam essa atuação, consulte nossos relatórios complementares sobre o parque instalado envelhecido após a carta de fim de suporte, sobre a segurança da manutenção independente e sobre os padrões de falha de placas.

E o limite, declarado de forma tão direta quanto a própria Olympus declara o seu: um reparo de hardware não cria um patch de OEM, não torna uma CVE inaplicável, não valida uma alteração de sistema operacional, não certifica uma rede e não torna um dispositivo ciberseguro. A Rongtao não é autorizada por OEMs, não é uma fornecedora de cibersegurança, não desenvolve patches e não avalia redes hospitalares; os nomes de OEMs neste relatório são identificadores de cobertura de serviços e evidências públicas, nunca de afiliação. Os responsáveis de HTM, segurança e da área clínica do hospital' detêm a decisão de destinação; o parceiro de serviços fornece um dos eixos dessa decisão.

Uma regra prática de interface fecha o ciclo: após qualquer intervenção em placa, drive ou módulo — realizada por qualquer pessoa — a verificação de retorno ao serviço deve confirmar não apenas a qualidade da imagem, mas também o estado relevante para a cibersegurança: compilação do software inalterada, contas e configuração de rede intactas, status de serviço remoto conforme aprovado e cadastro do ativo atualizado. "Hardware reparado" e "ativo retornado ao seu estado operacional aprovado" são duas aprovações distintas, sob a responsabilidade de dois encarregados diferentes.

Cláusulas de aquisição para o próximo sistema

Conclusão: as evidências ausentes de hoje' são a cláusula contratual de amanhã'. Tudo o que este relatório não conseguiu consultar — status do sistema operacional por produto, datas de término de suporte, direitos a patches — é exatamente o que o próximo pedido de compra deve exigir por escrito.

Nada disso evita vulnerabilidades. Isso garante que, quando o próximo alerta for publicado, o hospital detenha os direitos e as evidências em vez de descobrir — como fez o levantamento de consulta de SO acima — que a resposta está protegida por um login que ele não possui.

Metodologia e limitações

Conclusão: cada número calculado acima é reproduzível a partir de dados públicos com os filtros aqui declarados, e cada silêncio é rotulado como uma propriedade do canal que o produziu.

Análise do 510(k) da FDA. Banco de dados 510(k) da FDA's, exportação de 22 de julho de 2026 (175,559 registros). Coorte primária: códigos de produto IYN e IYO — sistemas de ultrassom diagnóstico tipo carrinho/console — 2,066 decisões, de agosto de 1977 a junho de 2026; verificado em cruzamento com um conjunto de ultrassom de 11 códigos (2,726 registros), que reproduz o padrão (91.8% pré-524B). As liberações são decisões de projeto, não unidades instaladas; não existe contagem pública da base instalada, e nenhuma é alegada. As 204 decisões pós-transição representam um teto para projetos da era 524B porque a lei vincula no recebimento da submissão, não na data da decisão ².

Análises da CISA. Catálogo KEV versão 2026.08.07 (1,662 entradas; triagem de fornecedores em relação a listas de fabricantes de diagnóstico por imagem e dispositivos médicos; sinalização de ransomware e cálculo de prazos a partir dos próprios campos do feed's) ⁵. Série ICSMA enumerada página por página a partir da listagem de alertas da CISA's em 9 de agosto de 2026 — 176 alertas para os anos completos de 2016–2025, mais 10 no ano parcial de 2026; 18 alertas relevantes para diagnóstico por imagem obtidos individualmente e verificados; outros 27 títulos correlatos a diagnóstico por imagem catalogados, mas não verificados em profundidade. As contagens de alertas medem a atividade de divulgação, não a incidência ³.

Análises de registros de segurança da FDA. Busca nas narrativas do MAUDE via openFDA (dados atualizados em 28 de julho de 2026) em onze códigos de produtos de ultrassom, 13,213 relatos em todo o histórico; recálculo da composição de eventos na janela de exportação de 2025–2026 (2,534 relatos). Análise de recalls em 542 registros de recall de ultrassom e uma triagem em todo o banco de dados para eventos de recall motivados por cibersegurança (18 desde 2008). O silêncio do MAUDE é uma propriedade dos fluxos de notificação — os hospitais relatam incidentes cibernéticos ao OCR, à CISA, ao FBI e a seguradoras, e não a um banco de dados de segurança de dispositivos — e nunca é interpretado aqui como evidência de segurança ⁴.

Levantamento de divulgações de OEMs. Propriedades públicas de segurança de produtos de dez fabricantes' levantadas em agosto de 2026; "gated" significa que o documento ou repositório requer uma credencial de cliente. A ausência de um fornecedor's do KEV, do registro do ICSMA ou de divulgações públicas não é evidência sobre a segurança de seus produtos' em nenhuma das direções.

Estatísticas do setor são identificadas com a entidade publicadora e a amostra sempre que citadas: os números da Claroty's são telemetria de sua própria base de clientes de 351 organizações, e não um censo ²⁴; os da Sophos's são uma pesquisa com vítimas ²⁵; as contagens de violações do OCR aumentam durante meses conforme o portal preenche registros retroativos ²³. Dois números amplamente repetidos (6.2 vulnerabilidades por dispositivo; 40% dos dispositivos em fim de vida útil) são omitidos porque sua fonte primária não pode ser rastreada. Uma via de análise tentada é divulgada como vazia: uma triagem de 29,979 títulos de avisos de contratação da UE (2016–2026) encontrou zero referências a requisitos de cibersegurança — as cinco correspondências para "cyber" eram o nome comercial CyberKnife —, mas títulos de editais não permitem visualizar anexos de especificação; portanto, a afirmação correta é "não testável com estes dados", e não "buyers don't ask".

Perguntas frequentes

Como descubro qual sistema operacional meu equipamento de ultrassom executa? Na maioria dos casos, você não consegue pesquisar — é preciso capturar a informação diretamente. Apenas 8 de 26 plataformas citadas tinham um SO documentado publicamente em nosso levantamento; os resumos do FDA 510(k) não o divulgam, e nenhum fabricante OEM publica um documento de status por produto com acesso livre ²¹⁹³¹. Registre a edição, a versão e a compilação na própria tela de informações do sistema do dispositivo's, depois solicite por escrito ao fabricante o status de suporte dessa compilação exata, o MDS² atual e o acesso a comunicados de segurança por meio de uma conta institucional.

O suporte ao Windows 10 terminou — preciso substituir meu sistema de ultrassom? Não apenas por esse fato. "Windows 10" não é um relógio único: a versão de consumo 22H2 teve o suporte encerrado em outubro de 2025, mas as compilações IoT Enterprise LTSC que acompanham muitos consoles têm suporte até janeiro de 2029 (LTSC 2019) e janeiro de 2032 (LTSC 2021), e tanto a Canon quanto a Philips publicaram declarações informando que a única compilação afetada pelo limite de 2025 está ausente de seus produtos atuais ou isolada neles ³⁵³³³¹. Identifique a compilação exata primeiro; em seguida, execute a verificação dos cinco relógios, e não a verificação por data de aniversário.

Posso instalar por conta própria uma versão mais recente do Windows no scanner? Não. O sistema operacional em um sistema de ultrassom aprovado é parte de uma configuração validada de dispositivo médico; uma alteração não autorizada do SO é uma modificação não controlada que pode afetar a segurança, a eficácia e o status regulatório. O caminho para aplicação de patches passa pelas atualizações validadas do fabricante's ¹⁰. Se esse caminho não existir, as opções íntegras são as outras três disposições — segmentar, isolar ou substituir.

Um equipamento de ultrassom antigo é automaticamente um risco de cibersegurança? Não — a idade não é a variável, a capacidade de suporte é. O IMDRF define um dispositivo legado como aquele que não pode ser razoavelmente protegido contra ameaças atuais, explicitamente não como uma faixa de idade ⁶. O próprio WannaCry é a prova: o NHS England constatou que a maioria dos dispositivos infectados executava o Windows 7, com suporte mas sem patches, e não o antigo XP ²⁹. Um console antigo com portas bloqueadas, fluxos delimitados e uma via ativa de manutenção de hardware pode ser um ativo gerenciado; um novo com acesso remoto não gerenciado, não.

O que é um "dispositivo cibernético" nos termos da Seção 524B? Um dispositivo que inclui software autorizado pelo patrocinador, pode se conectar à internet e possui características que podem ser vulneráveis a ameaças. Para submissões abrangidas recebidas em ou após 29 de março de 2023, o fabricante deve fornecer um plano de gerenciamento de vulnerabilidades, um processo de aplicação de patches e um SBOM ⁷. Não é retroativo — razão pela qual 90.1% da população de projetos de ultrassom liberados fica fora dele ².

Onde encontro avisos de segurança para meu modelo de ultrassom? Três locais, em ordem de autoridade: a página de segurança de produtos do fabricante's (cinco de dez OEMs publicam listas de avisos gratuitas e datadas — Philips, Siemens Healthineers, Canon Medical, GE HealthCare, Olympus); a série ICS Medical Advisories da CISA's; e o portal protegido por credenciais do fabricante's para a correção validada e o status por produto ³¹⁹³¹. Atribua o monitoramento de avisos a um responsável na organização — o histórico mostra que a correção fica sistematicamente atrás do login.

Uma carta de fim de suporte significa que as peças não estão mais disponíveis? Não necessariamente — verifique quais relógios a carta realmente interrompe. O aviso de ultrassom da Olympus de 2025 encerrou o suporte de software e futuras contramedidas de segurança, declarando no mesmo documento que "o suporte de hardware, como substituição de peças, etc., continuará sendo oferecido" ¹. O suporte de software, a disponibilidade de peças e a manutenção completa podem terminar com anos de diferença, e o mercado independente de peças e reparos estende ainda mais o relógio do hardware; confirme cada data por escrito.

Conclusão: a disposição, não o aniversário

Quatro constatações sustentam este relatório.

Os relógios são separáveis, e os próprios OEMs os separam. A Olympus encerrou o relógio de software de um sistema de ultrassom's e continuou seu relógio de hardware em uma única carta ¹. Gerenciar uma frota legada é a disciplina de saber qual dos cinco relógios expirou em cada ativo — não classificar por data de compra.

O regulamento chegou depois da frota. Nove em cada dez projetos de sistemas de ultrassom liberados são anteriores à legislação que exige um processo de aplicação de patches, a população não está saindo de circulação a 55–83 liberações por ano, e um terço das liberações recentes provém de uma longa cauda de fornecedores com práticas de divulgação escassas ou ausentes ². Esperar pela modernização é um plano de várias décadas.

O registro oficial já indica que a aplicação de patches frequentemente não é o remédio. Metade dos avisos de imagem verificados da CISA deixou pelo menos um produto sem correção; todos os avisos que citavam ultrassom tinham cobertura incompleta de patches; as instruções eram restringir, isolar, substituir ³. Enquanto isso, o relógio corporativo de aplicação de patches — 21 dias — é um ritmo no qual nenhum dispositivo validado pode operar ⁵. Segmentar e isolar não são falta de coragem; são os remédios documentados.

O silêncio do registro de segurança's é um caminho, não um veredito. Zero menções a questões cibernéticas em 8,525 relatórios recentes de segurança de ultrassom significa que o sinal nunca chegará por esse canal ⁴. A decisão deve ser tomada com base em evidências dos ativos e dos avisos — o registro que você constrói, porque aquele que você pode consultar não existe.

Para cada sistema que permanece em serviço sob essa decisão, o relógio do hardware precisa continuar funcionando: placas confiáveis, peças testadas, transdutores operacionais, funcionamento documentado. Se uma avaliação física de manutenibilidade puder ajudar na sua decisão de destinação — isolamento de falhas, disponibilidade de peças testadas para os seus modelos, evidência de teste em equipamento real —, essa é a conversa para a qual a Rongtao Medical foi estruturada, como um subsídio para uma decisão que cabe aos seus responsáveis de HTM, segurança e clínicos.