A proteção por pseudonimização no setor de saúde

Pode-se definir a pseudonimização como um tipo particular de desidentificação que remove a associação com o sujeito dos dados e adiciona uma associação entre um conjunto específico de características relacionadas ao sujeito dos dados e um ou mais pseudônimos.

A NBR ISO 25237 de 02/2020 – Informática em saúde — Pseudonimização contêm princípios e requisitos para proteção de privacidade usando serviços de pseudonimização para a proteção de informações pessoais de saúde. Este documento é aplicável às organizações que desejem realizar processos de pseudonimização por si mesmas ou às organizações que desejem reivindicar a confiabilidade de operações envolvidas em serviços de pseudonimização. Este documento estabelece um conceito básico para pseudonimização (ver Seção 5), estabelece uma metodologia básica para serviços de pseudonimização, incluindo aspectos organizacionais e técnicos (ver Seção 6), especifica um framework de política e requisitos mínimos para reidentificação controlada (ver Seção 7), oferece uma visão geral de diferentes casos de uso de pseudonimização que podem ser reversíveis ou irreversíveis (ver Anexo A), oferece uma orientação para avaliação de risco na reidentificação (ver Anexo B), oferece exemplo de sistema que utiliza a desidentificação (ver Anexo C), oferece requisitos informativos para interoperabilidade de serviços de pseudonimização (ver Anexo D) e especifica um framework de política e requisitos mínimos para práticas confiáveis para operações de um serviço de pseudonimização (ver Anexo E).

Acesse algumas questões relacionadas a essa norma GRATUITAMENTE no Target Genius Respostas Diretas:

Qual é o conceito idealizado de identificação e desidentificação?

Qual o conceito de pseudonimização?

Quais os níveis de garantia de proteção de privacidade?

Quais são as categorias de sujeitos dos dados?

Pode-se definir a pseudonimização como um tipo particular de desidentificação que remove a associação com o sujeito dos dados e adiciona uma associação entre um conjunto específico de características relacionadas ao sujeito dos dados e um ou mais pseudônimos. A pseudonimização é reconhecida como um método importante para proteção de privacidade para informações pessoais de saúde. Estes serviços podem ser usados em escala nacional, assim como em comunicações transfronteiriças.

As áreas de aplicação incluem, mas não estão limitados a: uso indireto de dados clínicos (por exemplo, pesquisa); ensaios clínicos e vigilância pós-mercado; assistência pseudônima; sistemas de identificação de pacientes; monitoramento e avaliação de saúde pública; comunicação confidencial de segurança do paciente (por exemplo, efeitos adversos de medicamentos); comunicação de indicadores comparativos de qualidade; revisão por pares; grupos de consumidores; serviço de campo. Este documento oferece um modelo conceitual das áreas problemáticas, requisitos para práticas confiáveis e especificações para suporte ao planejamento e implementação de serviços de pseudonimização.

A especificação do fluxo geral de trabalho juntamente com uma política confiável de operações, serve tanto como uma orientação a implementadores como também para garantia da qualidade, auxiliando usuários dos serviços de pseudonimização a determinar sua confiança nos serviços oferecidos. Este manual servirá para educar organizações para que elas possam realizar, por si mesmas, pseudonimização com proficiência suficiente para alcançar o desejado grau de qualidade e redução de risco.

O objetivo da proteção de privacidade como parte do objetivo de confidencialidade da segurança é prevenir a revelação não autorizada ou indesejada de informação sobre uma pessoa que possa ainda influenciar fatores de risco legais, organizacionais e financeiros. Proteção de privacidade é um subdomínio da proteção geral à privacidade que, por definição, inclui outras entidades sensíveis à privacidade, como as organizações.

Como a privacidade é mais regulada e aprofundada, este modelo conceitual foca na privacidade. Soluções protetivas projetadas para privacidade também podem ser transpostas para a proteção de privacidade de outras entidades. Isto pode ser útil em países nos quais a privacidade de entidades ou organizações é regulada por lei.

Existem dois objetivos na proteção de dados pessoais; um é a proteção de dados pessoais na interação com aplicativos on-line (por exemplo, navegação na web) e o outro é a proteção de dados pessoais coletados em bases de dados. Este documento se restringirá ao último objetivo. Dados podem ser extraídos de bases de dados. O objetivo é reduzir o risco de que as identidades dos sujeitos dos dados sejam reveladas.

Os pesquisadores trabalham com “casos”, histórias longitudinais de pacientes coletadas ao longo do tempo e/ou a partir de diferentes fontes. Contudo, para a agregação dos vários elementos de dados nos casos é necessário usar uma técnica que possibilite agregações sem comprometer a privacidade dos sujeitos dos dados cujos dados estão sendo agregados. Isto pode ser obtido por meio da pseudonimização dos dados.

A desidentificação é usada para reduzir os riscos à privacidade em uma ampla variedade de situações. A desidentificação extrema é usada para materiais educacionais que serão amplamente revelados ao público, ainda que convenha transmitir detalhes suficientes para que sejam úteis para fins de educação médica. Existe um perfil IHE para assistência de automação para realizar este tipo de desidentificação. Grande parte do processo é personalizado para o paciente individual e para fins educacionais.

A saúde pública usa bases de dados desidentificadas para acompanhar e entender doenças. Ensaios clínicos usam a desidentificação para proteger a privacidade e para evitar viés subconsciente por meio da remoção de outras informações, como se o paciente recebeu um placebo ou um medicamento experimental. Usa-se uma desidentificação ligeira em muitas revisões clínicas nas quais os revisores se mantêm ignorantes sobre o médico responsável, hospital, paciente, etc., seja para reduzir os riscos de privacidade e para remover vieses subconscientes.

Este tipo de desidentificação só previne a revelação incidental para os revisores. Um esforço intencional facilmente descobrirá a identidade do paciente, etc. Ao produzir estatísticas de carga de trabalho e análises de carga de trabalho em hospitais ou de tratamentos fornecidos mediante contratos como comissionados ou compradores de serviços de assistência à saúde, é necessário ser capaz de separar pacientes individuais sem a necessidade de conhecer quem são os pacientes individuais.

Este é um exemplo do uso da desidentificação em um ambiente de negócios. O processo de estratificação de risco (de reinternação, por exemplo) pode ser realizado por meio do uso de registros de atenção primária e secundária dos pacientes. Os registros são desidentificados para a análise, mas quando os pacientes são indicados como sendo pacientes de alto risco, estes pacientes podem ser reidentificados por um clínico indicado para permitir intervenções de acompanhamento. Para detalhes sobre a pseudonimização em saúde, ver Anexo A.

A desidentificação é o termo geral usado para qualquer processo de redução da associação entre um conjunto de dados identificadores e o sujeito dos dados com um ou mais usos previstos para o conjunto de dados resultante. Pseudonimização é uma subcategoria de desidentificação. O pseudônimo é o meio pelo qual os dados pseudonimizados são vinculados à mesma pessoa ou aos sistemas de informação, sem revelar a identidade da pessoa.

Desidentificação inerentemente pode limitar a utilidade dos dados resultantes. Pseudonimização pode ser realizada com ou sem a possibilidade de reidentificação do sujeito dos dados (pseudonimização reversível ou irreversível). Na assistência à saúde existem diversos cenários de casos de uso para a pseudonimização com aplicabilidade relevante no aumento do processamento eletrônico de dados de pacientes, juntamente com o aumento na expectativa dos pacientes com respeito à proteção de sua privacidade. Diversos exemplos desta proteção são fornecidos no Anexo A.

É importante notar que, enquanto houver qualquer dado pseudonimizado, existe algum risco de reidentificação não autorizada. Não é diferente da criptografia, para a qual a força bruta pode quebrar a criptografia, mas o objetivo é torná-la tão difícil que seu custo seja proibitivo. Existe menos experiência com a desidentificação que com a criptografia de forma que os riscos não sejam completamente entendidos.

Convém que o processo de desidentificação considere os controles de segurança e privacidade que irão gerenciar o conjunto de dados resultante. É raro conseguir reduzir tanto o risco que o conjunto de dados não necessite de controles adicionais de segurança. A figura abaixo é um diagrama informativo de uma visualização deste processo de desidentificação. Isto mostra que o conceito mais superior é desidentificação, como um processo. Este processo utiliza subprocessos: pseudonimização e/ou anonimização. Estes subprocessos usam várias ferramentas que são específicas para o tipo de elemento de dados em que operam e o método de redução de risco.

O estado inicial é de que não é permitida a passagem de dado algum pelo sistema. Convém que cada elemento seja justificado pelo uso previsto do conjunto de dados resultante. Este uso previsto do conjunto de dados afeta enormemente o processo de desidentificação. A desidentificação pode influenciar a pseudonimização na qual seja necessário manter consistência longitudinal.

Isto pode ser feito para manter unidos registros que convém que estejam associados uns aos outros, e que sem essa consistência longitudinal podem acabar dissociados. Isto é útil para manter juntos todos os registros de um paciente, sob um pseudônimo. Também pode ser usado para assegurar que, a cada vez que os dados são extraídos para um conjunto desidentificado, as novas inserções também são associadas com o mesmo pseudônimo.

Na pseudonimização, o algoritmo usado pode ser intencionalmente reversível ou intencionalmente irreversível. Um esquema reversível pode ser uma tabela secreta de consulta que, quando autorizada, pode ser usada para descobrir a identidade original. Em um esquema não reversível, pode-se usar uma tabela temporária durante o processo, que é destruída ao término do processo.

A anonimização é o processo e conjunto de ferramentas usadas quando não é necessária qualquer consistência longitudinal. O processo de anonimização também é usado quando a pseudonimização tiver sido usada para tratar os atributos de dados restantes. A anonimização utiliza ferramental como redação, remoção, branqueamento, substituição, randomização, deslocamento, enviesamento, agrupamento, etc. A anonimização pode levar a uma diminuição na possibilidade de vinculação.

Convém que cada elemento autorizado a passar seja justificado. Convém que cada elemento apresente o risco mínimo, considerando o uso previsto do conjunto de dados resultante. Desta forma, quando o uso previsto do conjunto de dados resultante não requer código de grão fino, pode ser usado um agrupamento de códigos.

O processo de desidentificação aborda três tipos de dados: identificadores diretos, que identificam o paciente por si mesmo; identificadores indiretos, que proporcionam correlação quando usado com outro conhecimento indireto ou externo; e dados não identificadores, o restante dos dados. Normalmente, o processo de desidentificação é aplicado a um conjunto de dados, composto por entradas que possuem muitos atributos. Por exemplo, uma planilha composta por linhas de dados organizadas em colunas.

O processo de desidentificação, incluindo pseudonimização e anonimização, é aplicado a todos os dados. Geralmente, a pseudonimização é usada para identificadores diretos, mas pode ser usada para identificadores indiretos, conforme for apropriado para reduzir o risco ao mesmo tempo em que mantém as necessidades longitudinais do uso previsto do conjunto de dados resultante. As ferramentas de anonimização são usadas para tratar todos os tipos de dados, conforme for apropriado para reduzir o risco.

A identificação de produtos medicinais

As normas para a identificação de produtos medicinais (IDMP) suportam as atividades de agências reguladoras do mundo todo por jurisdição. Isso inclui uma variedade de atividades regulatórias relacionadas com o desenvolvimento, registro e gestão do ciclo de vida de produtos medicinais assim como de farmacovigilância e gestão de risco.

A NBR ISO 11239 de 08/2019 – Informática em saúde — Identificação de produtos medicinais — Elementos e estruturas de dados para a identificação unívoca e intercâmbio de informação regulada sobre formas farmacêuticas, unidades de apresentação, vias de administração e embalagens especifica as estruturas e relacionamentos entre os elementos de dados necessários para o intercâmbio de informações que identificam, de forma unívoca e precisa, formas farmacêuticas, unidades de fornecimento, vias de administração e itens de embalagens, incluindo recipientes, fechos e dispositivos de administração, relacionados aos produtos medicinais; um mecanismo para a associação das traduções de um único conceito em diferentes idiomas que é parte integral do intercâmbio de informações; um mecanismo de versionamento dos conceitos, de forma a rastrear suas evoluções; regras para permitir que autoridades regionais mapeiem termos regionais existentes aos termos criados, usando esta norma de uma forma harmonizada e significativa.

Além disso, para suportar a aplicação exitosa desta norma, são fornecidas, de acordo com a necessidade, referências normativas aos padrões envolvidos com a Identificação de Produtos Medicinais (IDMP) e as mensagens para informação sobre produtos medicinais.

Acesse algumas dúvidas relacionadas a essa norma GRATUITAMENTE no Target Genius Respostas Diretas:

Quais são as abreviaturas usadas nessa norma?

Quais são exemplos teóricos de mapeamento de termos regionais para conceitos centrais com níveis baixos (região A) e altos (região B) de granularidade?

Qual seria o diagrama conceitual para a classe forma farmacêutica?

Qual seria o diagrama ilustrando as relações entre a forma farmacêutica manufaturada, a forma farmacêutica administrável e a forma farmacêutica combinada para um produto medicinal consistindo em dois itens manufaturados e para o qual é necessário realizar uma transformação?

Esta norma foi desenvolvida em resposta a uma demanda mundial por especificações internacionalmente harmonizadas para produtos medicinais. É uma de um grupo de cinco normas que, em conjunto, proporcionam a base para a identificação única de produtos medicinais. O grupo de normas compreende: a ISO 11615, Health informatics – Identification of medicinal products – Data elements and structures for the unique identification and exchange of regulated medicinal product information; a ISO 11616, Health informatics – Identification of medicinal products – Data elements and structures for the unique identification and exchange of regulated pharmaceutical medicinal product; a ISO 11238, Health informatics – Identification of medicinal products – Data elements and structures for the unique identification and exchange of regulated information on substances; a ISO 11239, Health informatics – Identification of medicinal products – Data elements and structures for the unique identification and exchange of regulated information on pharmaceutical dose forms, units of presentation, routes of administration and packaging; a ISO 11240, Health informatics – Identification of medicinal products – Data elements and structures for the unique identification and exchange of units of measurement.

Estas normas para a identificação de produtos medicinais (IDMP) suportam as atividades de agências reguladoras do mundo todo por jurisdição. Isso inclui uma variedade de atividades regulatórias relacionadas com o desenvolvimento, registro e gestão do ciclo de vida de produtos medicinais assim como de farmacovigilância e gestão de risco. Para atender aos objetivos primários da regulação de medicamentos e farmacovigilância, é necessário que a troca de informações dos produtos medicinais seja feita de maneira robusta e confiável. Os padrões IDMP dão suporte às seguintes interações: regulador para regulador; companhia farmacêutica para regulador; patrocinador de ensaio clínico para regulador; regulador para outras partes interessadas; regulador para fontes de dados mantidas internacionalmente. As necessárias especificações de mensagens estão incluídas como parte integral dos padrões IDMP para assegurar as interações acima. Os identificadores unívocos produzidos com os padrões IDMP têm por objetivo suportar aplicações nas quais seja necessário identificar e rastrear confiavelmente o uso de produtos medicinais.

Existem muitos termos em uso para descrever conceitos básicos no domínio de desenvolvimento de padrões regulatórios, farmacêuticos e de assistência à saúde para diferentes propósitos e em diferentes contextos. Os termos e definições descritos nesta norma são para ser aplicados para os conceitos que são necessários para identificar, caracterizar e intercambiar univocamente os produtos medicinais regulados e a informação associada. Os termos e definições adotados nesta norma têm o objetivo de facilitar a interpretação e a aplicação de requisitos regulatórios e legais sem prejuízo a qualquer documento legal vinculado.

Em caso de dúvidas ou conflito potencial, prevalecem os termos e definições contidos em documentos legalmente vinculados. No contexto da identificação de formas farmacêuticas, unidades de apresentação, vias de administração e embalagens, esta norma descreve os elementos essenciais para a especificação, tradução e versionamento dos termos controlados especificados. Também estão descritas recomendações sobre o mapeamento de termos que já são utilizados pelas partes interessadas para os conceitos aparecendo na implementação desta norma.

Os conceitos de alto nível definidos consistem em: forma farmacêutica; unidade de apresentação; via de administração; recipiente. Os componentes de suporte mais mecânicos estão descritos separadamente dos conceitos clínicos de alto nível. Os conceitos de suporte são: termos e códigos; traduções; versionamento; mapeamento. Esta norma faz parte de um conjunto de normas para a identificação de produtos medicinais (IDMP).

Ela proporciona especificações para dar suporte à criação de um conjunto de vocabulários controlados que são essenciais para a implementação do conjunto de padrões como um todo, em particular: ISO 11615, Health informatics – Identification of medicinal products – Data elements and structures for the unique identification and exchange of regulated medicinal product information (MPID); ISO 11616, Health informatics – Identification of medicinal products – Data elements and structures for the unique identification and exchange of regulated pharmaceutical product information (PhPID). Entretanto, os vocabulários controlados também podem ser usados, independentemente do conjunto de padrões do IDMP. Mensagens Health Level Seven (HL7) Commom Terminology Services (CTS) versão 2 são utilizadas para comunicação de mensagens de vocabulários controlados do IDMP.

Esta norma descreve a gestão de traduções de termos controlados de forma que a troca de informações relacionadas aos produtos medicinais possa ser implementada em escala global. Descreve a gestão do versionamento dos termos controlados, de modo que os vocabulários controlados e quaisquer modificações possam ser rastreados de forma apropriada, permitindo um histórico auditável. Proporciona as diretrizes para assistir aos usuários no mapeamento de termos existentes para os termos controlados, de modo que os termos já em uso nas diferentes regiões possam ser associados aos termos controlados.

Para que os vocabulários controlados fornecidos por esta Norma sejam adequados ao seu propósito, como partes integrais do conjunto de normas IDMP, eles devem satisfazer os seguintes critérios: fornecer termos e identificadores adequados para descrever a forma farmacêutica de um produto medicinal, como requerido pela necessidade de geração e descrição dos PhPID e MPID; fornecer termos e identificadores adequados para descrever a (s) via (s) de administração de um produto medicinal, como requerido para a descrição completa do medicamento e a geração do MPID; fornecer termos e identificadores adequados para descrever a unidade de apresentação de um produto medicinal, tal como requerido para a descrição completa da concentração de certos tipos de produto medicinal para a geração do MPID; fornecer termos e identificadores adequados para descrever o recipiente (o que inclui a embalagem primária, a embalagem intermediária e a embalagem secundária), fecho e dispositivo de administração de um produto medicinal, como requerido para a descrição do produto medicinal para a geração do MPID.

Os termos e códigos controlados devem estar publicamente disponíveis, e a expectativa é que seu uso não requeira o pagamento de royalties. Esta norma descreve os elementos essenciais para a especificação, tradução e versionamento dos termos controlados. Também descreve recomendações sobre o mapeamento de termos que já estão sendo utilizados pelas partes interessadas para os conceitos que surgirão a partir da sua implementação.

Os componentes de suporte são: termos e códigos; traduções; versionamento; mapeamento. Os conceitos de alto nível são: forma farmacêutica; unidade de apresentação; via de administração; embalagem. Os esquemas empregam os tipos de dados ST (String), CD (Descritor de Conceito), TS (Ponto no Tempo) e INT (Inteiro), conforme especificado na ISO 21090. Um atributo que não mostre uma cardinalidade explícita indica que o atributo deve ser valorado com um valor (equivalente a [1..1]).

Os modelos conceituais estabelecem os elementos, estruturas e relacionamentos entre os elementos que descrevem os conceitos de suporte (termos e códigos, traduções, versionamento e mapeamento) para cada conjunto de termos controlados. O codeTermPair deve ser usado como a classe subjacente que carrega o código básico, a string de texto associada e outros elementos de definição e será usado como tipo de dado na criação do codedConcept.

Os atributos da classe subjacente codeTermPair são: code: um identificador único (processável por máquina) para o codeTermPair (tipo de dado: ST); term: a descrição textual do termo para o conceito (tipo de dado: ST); definition: uma definição textual do conceito (tipo de dado: ST); domain: indica se o conceito é para uso “humano e veterinário” ou “somente veterinário” (tipo de dado: CD); comment: um comentário textual opcional (tipo de dado: ST); languageCode: o idioma no qual estão descritos os itens “b” e “e”, de acordo com a ISO 639 (tipo de dado: CD); regionCode: o país ou região que utiliza o codeTermPair em seu idioma, de acordo com a ISO 3166 (tipo de dado: CD).

O codedConcept associa o conceito de um idioma e região geográfica (por exemplo, inglês para o Reino Unido) com zero ou mais traduções deste mesmo conceito em diferentes idiomas e/ou regiões (por exemplo, francês para França e alemão para Alemanha). O código codeTermPair conceitua para o idioma e região selecionados pelo usuário, sendo utilizado o elemento “value” e zero para muitos códigos codeTermPair. Para este mesmo conceito em diferentes idiomas e/ou regiões, é usado o elemento “translation”; em conjunto, eles definem o tipo de dados codedConcept.

O codedConcept é composto pelos seguintes atributos: code: o identificador único (processável por máquina) para o codedConcept (tipo de dado: ST); value: o código do codeTermPair para o conceito que possui o código de idioma selecionado pelo usuário (por exemplo, inglês) e o código de região selecionado pelo usuário (por exemplo, Reino Unido) (tipo de dado: codeTermPair); translation: zero ou mais códigos codeTermPair para o mesmo conceito com diferentes códigos de idioma e/ou regiões (por exemplo, francês para a França, alemão para Alemanha).

O versionamento fornece um histórico rastreável para cada conceito, desde o momento de sua criação até a inclusão de detalhes e demais modificações realizadas. O versionamento deve ser composto pelos seguintes atributos: code: o identificador único (processável por máquina) do conceito que está sujeito ao versionamento (tipo de dado: ST); creationDate: um time stamp indicando a data e a hora em que o conceito foi criado (tipo de dado: TS); createdBy: informação para identificar a pessoa que criou o conceito (tipo de dado: ST); modificationDate: um time stamp indicando a data e a hora na qual a alteração foi realizada para a versão especificada (tipo de dado: TS); modificationMade: uma descrição em texto livre da alteração realizada para a versão especificada (tipo de dado: ST); concpetStatus: o status do conceito, ou seja, se ele está ativo, descontinuado etc. (tipo de dado: CD); currentConcept [0..*]: quando um conceito é descontinuado, o código do conceito que o substitui.

Pode haver mais que uma substituição para um único conceito descontinuado (tipo de dado: codedConcept); versionNumber: um número que indica a versão do conceito (tipo de dado: INT). Os conceitos decorrentes da implementação desta norma (aqui denominados “conceitos centrais”) não coincidirão necessariamente com os termos já utilizados pelas diversas partes interessadas nos diferentes países e regiões (aqui referidos como “termos regionais”).

A fim de que os termos regionais já utilizados, em particular aqueles definidos por agências reguladoras de medicamentos dos diferentes países e regiões, possam estar ligados aos conceitos centrais, prevê-se que as partes interessadas mapeiem seus termos regionais para estes conceitos centrais em suas próprias bases de dados e/ou sistemas. Este exercício de mapeamento ajudará os usuários de uma base de dados existente a identificarem o conceito central equivalente para um dado termo regional. Um único termo regional pode mapear para zero ou mais conceitos centrais, e zero ou mais termos regionais podem mapear para um único conceito central.

As peças compradas e fabricadas por manufatura aditiva

Pretende-se que este documento seja utilizado pelos fornecedores de peças e/ou pelos clientes de peças fabricadas por manufatura aditiva. Este documento é uma norma de nível superior na hierarquia de normas de manufatura aditiva, destinado a ser aplicado às peças fabricadas por qualquer processo de manufatura aditiva e qualquer tipo de material.

A NBR ISO/ASTM 52901 de 11/2019 – Manufatura aditiva — Princípios gerais — Requisitos para peças compradas, fabricadas por manufatura aditiva define e especifica os requisitos para peças compradas, fabricadas por manufatura aditiva. Fornece as diretrizes para os elementos a serem trocados entre o cliente e o fornecedor da peça no momento do pedido de compra, incluindo as informações da solicitação do cliente, dados de definição da peça, requisitos de material de alimentação, características e propriedades da peça final, requisitos de inspeção e métodos de aceitação da peça. É aplicável ao uso como uma base para obter peças fabricadas por manufatura aditiva que atendam aos requisitos mínimos de aceitação. Requisitos mais rigorosos da peça podem ser especificados por meio da adição de um ou mais requisitos complementares no momento do pedido de compra.

Acesse algumas questões relacionadas a essa norma GRATUITAMENTE no Target Genius Respostas Diretas:

O que as características da peça devem atender?

Como deve ser feita a inspeção das peças?

Qual deve ser a documentação de aceitação?

Quais são as informações do pedido de compra da peça?

Este documento abrange a definição e a comunicação de requisitos para peças compradas, fabricadas por manufatura aditiva. Ele é destinado a permitir uma comunicação eficiente e inequívoca entre os fornecedores de peças e os clientes de peças fabricadas por manufatura aditiva, assegurando que a peça resultante atenda aos requisitos do cliente.

Pretende-se que este documento seja utilizado pelos fornecedores de peças e/ou pelos clientes de peças fabricadas por manufatura aditiva. Este documento é uma norma de nível superior na hierarquia de normas de manufatura aditiva, destinado a ser aplicado às peças fabricadas por qualquer processo de manufatura aditiva e qualquer tipo de material.

Este documento permite diferentes requisitos com base na classificação da criticidade e do uso final esperado das peças fabricadas por manufatura aditiva. O pedido de compra da peça deve incluir os seguintes elementos: organização e informações de contato do cliente (de preferência com pontos de contato para pedidos de compra, pagamento e entrega); definição da (s) peça (s) a ser (em) fabricada (s); condições associadas de entrega ao cliente; outros requisitos de compra; uma identificação de referência deste documento, ou seja, NBR ISO/ASTM 52901, e outros regulamentos nacionais/internacionais pertinentes; identificação do pedido de compra da peça do cliente (número de requisição, data de requisição etc.); designação ou descrição da (s) peça (s) desejada (s) (número/identificação da peça, índice de revisão, etc.); quantidade desejada de peças; data de entrega requerida, se for um único pedido de compra; quantidade de entrega, frequência e período de duração requeridos do pedido de compra, se for um pedido com entrega programada ou múltiplos pedidos; marcação ou etiquetagem requerida das peças, incluindo, por exemplo, rótulos, número de série, número de lote, tipo de material de alimentação, referência do fornecedor da peça, identificador de inspeção, referência de rastreabilidade, etc.; requisitos da embalagem da peça para entrega ao cliente; endereço de entrega do cliente.

Os valores específicos dos elementos estão sujeitos a um acordo entre o cliente e o fornecedor da peça. A definição da peça deve incluir os seguintes elementos: geometria da peça; tolerâncias; textura superficial; orientação de fabricação, se necessário, para atender aos requisitos do cliente; material de alimentação para a peça a ser fabricada, se necessário, para atender aos requisitos do cliente; métodos de reparo (levando em consideração as categorias de ensaio definidas na NBR ISO 17296-3); imperfeições ou desvios aceitáveis; informações de controle do processo.

A divulgação de informações confidenciais está sujeita a um acordo entre o cliente e o fornecedor da peça. A definição da peça deve incluir os seguintes elementos: referência do desenho de engenharia (número, índice e versão), se aplicável; referência do arquivo digital (nome, formato, versão), se aplicável; descrição da geometria por um desenho de engenharia que defina completamente a peça, ou um arquivo digital contendo o modelo 3D ou as informações de geometria da peça.

Para troca de dados eletrônicos, o cliente e o fornecedor da peça devem assegurar que os sistemas utilizados sejam compatíveis e devem definir o método de fornecimento de arquivos digitais, incluindo o nível de confidencialidade e os métodos de proteção de dados, o formato dos dados eletrônicos, e os procedimentos para criação do arquivo digital (incluindo a fonte dos dados eletrônicos e os requisitos de conversão necessários para produzir o arquivo digital). Os documentos de descrição da geometria da peça podem ser fornecidos pelo cliente ou pelo fornecedor da peça.

O formato de arquivo STL utilizado por muitas máquinas de manufatura aditiva não contém unidades de medida como metadados. Quando somente arquivos STL forem fornecidos pelo cliente, as informações do pedido de compra especificam as unidades de medida da peça juntamente com o arquivo digital. Mais informações sobre arquivos digitais podem ser encontradas na ISO/ASTM 52915.

As tolerâncias devem ser especificadas (por exemplo, tolerâncias gerais, ver NBR ISO 2768-1 e NBR ISO 2768-2, e/ou tolerâncias específicas, ver ISO 1101), incluindo a definição de zonas funcionais (por exemplo, sobremetal para usinagem para acabamento ou retrabalho) e zonas estéticas ou cosméticas, de modo que o fornecedor da peça possa orientar a peça de acordo com os requisitos e decidir sobre a localização e o tipo de estruturas de suporte da peça, se necessário. Convém que a textura superficial (também conhecida como acabamento superficial) da peça seja especificada, se possível por referência a normas existentes (por exemplo, utilizando a ISO 1302 e/ou a ISO 25178-1).

O requisito de textura superficial pode ser especificado por um valor máximo de rugosidade/ondulação para toda a peça ou por uma rugosidade/ondulação específica para uma ou mais superfícies críticas. A textura superficial geralmente depende de diversos parâmetros do processo, incluindo a orientação da peça e a espessura de camada.

O processo de fabricação desejado para construir a peça deve ser identificado, incluindo as etapas de pós-processamento necessárias (por exemplo, tratamento térmico, acabamento superficial). A orientação de fabricação deve seguir as regras fornecidas na ISO/ASTM 52921. A orientação de fabricação geralmente é escolhida pelo fornecedor da peça para atender aos requisitos; entretanto, o cliente pode especificar a orientação de fabricação da peça, se necessário, para obter as propriedades mecânicas específicas.

O tipo e/ou os limites da composição química do material de alimentação para a peça a ser fabricada devem ser especificados por referência a normas e/ou especificações existentes do material. O pedido de compra deve mencionar ou referenciar especificações apropriadas para as características do material de alimentação para a peça a ser fabricada, os requisitos de armazenamento, manuseio e processamento para o uso adequado do material de alimentação e para o controle de suas propriedades, e se for necessário atender aos requisitos do cliente, informações sobre o uso permitido do material de alimentação reciclado (reutilizado).

Se o cliente tiver preocupações sobre o país de origem do material de alimentação ou do produtor do material de alimentação, a fonte desejada do material de alimentação pode ser especificada. Qualquer reparo deve ser comunicado ao cliente e autorizado antes de ser realizado. Os métodos de reparo autorizados (como reparo por deposição de material, soldagem, colagem ou aglutinação) e as condições de reparo correspondentes devem ser especificados, se necessário, e devem ser aprovados pelo cliente.

As tolerâncias para trincas, defeitos, descontinuidades, material estranho, inclusões, imperfeição (ões) ou desvio (s) aceitável (eis), descolorações e porosidade devem ser acordadas entre o fornecedor da peça e o cliente. Os requisitos para a repetibilidade do processo de fabricação devem ser identificados, incluindo referência a normas ou métodos de medição relevantes para avaliar a repetibilidade, particularmente para pedidos de compra de peças múltiplas ou pedidos de compra múltiplos esperados da mesma peça.

Os requisitos para documentar as informações de controle do processo durante a fabricação devem ser identificados. As informações requeridas, conforme acordado entre o fornecedor da peça e o cliente, devem ser documentadas durante a fabricação e incluídas no registro de qualidade para a peça de manufatura aditiva como retidas pelo fornecedor da peça. O período de retenção do registro de qualidade e as informações de controle do processo a serem transmitidas ao cliente devem ser acordados entre o cliente e o fornecedor.

Se prestadores de serviços externos autorizados forem requeridos (por exemplo, para pós-tratamento, inspeção, etc.), eles devem ser acordados entre o fornecedor da peça e o cliente, e devem ser documentados. O pedido de compra deve especificar se a inspeção deve ser realizada em uma ou mais peças finais ou de referência (por exemplo, em um turno completo de produção, em amostras dos turnos de produção ou em peças de referência que tenham características similares, porém geometria ou escala diferentes).

Se os resultados do ensaio especificado no pedido de compra estiverem em conformidade com os critérios de aceitação, a peça deve ser aceita. Se os resultados dos ensaios não estiverem em conformidade com os valores definidos no pedido de compra, amostras adicionais do mesmo turno de produção devem ser submetidas a ensaios adicionais para aceitação.

Qualquer peça que não esteja em conformidade com os requisitos, porém que atenda às condições para retrabalho estipuladas no pedido de compra, pode ser reparada ou aceita. Qualquer não conformidade remanescente com os requisitos do pedido de compra, se o retrabalho for realizado ou não, deve ser revisada pelo cliente para determinar se um desvio específico dos requisitos pode ser aceito. Caso contrário, as peças devem ser rejeitadas.

Os riscos de segurança em software para a saúde

No passado, os softwares relacionados à saúde eram aplicados principalmente em funções administrativas relativamente não críticas, nas quais o potencial de causar danos ao paciente era baixo em contraste com o risco de interrupção da organização.

No passado, os softwares relacionados à saúde eram aplicados principalmente em funções administrativas relativamente não críticas, nas quais o potencial de causar danos ao paciente era baixo em contraste com o risco de interrupção da organização. Geralmente, os sistemas clínicos não eram sofisticados e frequentemente apresentavam um grande conteúdo administrativo (e não clínico) e pouco apoio à decisão. Mesmo os sistemas de apoio à decisão clínica tendiam a ser leves, relativamente simples e compreensíveis em sua lógica, e usados como um complemento básico para as decisões, em vez de constituir-se em uma grande influência na qual se confia rotineiramente.

Isso mudou e continuará a mudar substancialmente. A natureza destas mudanças aumentará o potencial de riscos para os pacientes. Têm ocorrido alguns incidentes negativos de grande destaque relacionados com software clínico, por exemplo, na área de triagem e recepção de pacientes e/ou recall, nos quais os problemas de funcionamento do software resultaram em falha ao chamar pacientes em risco. Tais incidentes não só causaram angústia para muitos pacientes envolvidos, mas também podem ter levado a mortes prematuras.

A confiança do público foi gravemente prejudicada. O escopo de triagem de doenças está aumentando significativamente, e é nesses aplicativos, que envolvem um grande número de indivíduos, que haverá grande dependência, tanto administrativa como clínica, de softwares para detectar elementos normais e anormais e para chamar ou processar aqueles considerados como estando em risco. Tal software precisa ser seguro para o propósito a que se destina.

Existe uma preocupação crescente em todo o mundo com o número substancial de incidentes clínicos evitáveis que causam um efeito adverso nos pacientes e dos quais uma proporção significativa resulta em morte evitável ou incapacidade grave. Vários destes incidentes evitáveis envolvem diagnósticos ou outras decisões inconsistentes ou erradas. Muitas vezes um fator contribuinte é a informação em falta ou incompleta, ou simplesmente ignorância, por exemplo, a respeito de opções clínicas em circunstâncias difíceis ou reações cruzadas de tratamentos.

Cada dia está mais confirmado que os sistemas de informação, como apoio à decisão, protocolos, diretrizes e linhas de cuidado, poderiam reduzir acentuadamente estes efeitos adversos. Somente este motivo (independentemente de outros que existem) está conduzindo ao aumento na utilização de sistemas de apoio à decisão e de gerenciamento de doenças, que, inevitavelmente, se tornarão mais sofisticados e complexos.

Também se pode prever que, devido às pressões de tempo e dos aspectos médico-legais, os clínicos dependerão cada vez mais destes sistemas com menos questionamentos sobre seu resultado. De fato, à medida que estes sistemas se tornam integrados aos cuidados médicos, qualquer falha em usar instalações, padrão de apoio pode ser criticada por motivos legais. Pode-se prever um aumento no suporte à decisão não somente no tratamento clínico, mas também em outras áreas importantes para a segurança do paciente, como a tomada de decisão de encaminhamento, em que a falha em realizar um encaminhamento correto ou realizar um encaminhamento a tempo pode causar graves consequências.

Pressões econômicas também estão levando a mais sistemas de suporte à decisão. A área de prescrição genérica e/ou econômica é a mais óbvia, sendo outra a economia no número e custo de ensaios de investigação clínica. Sistemas como os de suporte à decisão têm um considerável potencial para reduzir erros clínicos e melhorar a prática clínica. Por exemplo, um grande corpo de evidências publicadas oferece testemunho da redução de erros e incidentes adversos, resultantes da implantação da prescrição eletrônica.

No entanto, todos estes sistemas também carregam o potencial de causar dano. Os danos podem, obviamente, resultar do uso sem questionamentos e/ou não profissional, embora os fabricantes possam mitigar estas circunstâncias por meio de, por exemplo, instruções de uso, treinamento e técnicas de apresentação na tela, orientação ou instrução. O potencial de dano pode estar igualmente no projeto de sistema, em áreas como: fraca base de evidências para o projeto; falha na lógica do projeto em representar adequadamente as intenções de projeto; falha na lógica para representar boa prática ou evidências na fase de projeto; apresentação insatisfatória ou confusa da informação ou funcionalidades de busca precárias; falha em atualizar em sincronia com o conhecimento mais atual.

Algumas destas deficiências de sistemas são insidiosas e podem ser invisíveis ao usuário. Em muitos sistemas nacionais de saúde, é evidente um aumento substancial nos gastos com gestão da informação e tecnologia. Os cronogramas associados são apertados e as metas são ambiciosas. Pode-se esperar que este aumento no gasto atraia novos fabricantes e alguns destes podem ser inexperientes nos processos de assistência à saúde.

Esta circunstância pode levar a um ambiente de aumento nos riscos ao bem-estar do paciente. Parte da explosão na tecnologia de informação e comunicação previsível ocorrerá na telemedicina. Muitos dos produtos de software para saúde que suportam estes aplicativos serão inovadores e não experimentados, e a distância entre clínicos e pacientes aumentará a possibilidade de erros assim como os tornará menos evidentes.

Da mesma forma, o aumento no uso de dispositivos móveis inovadores e o seu uso em novos campos provavelmente estão associados a riscos. Considerando que se está a muitos anos de distância de hospitais sem papel e sem filme, as práticas de clínica geral estão indo nesta direção. A incapacidade de recorrer ao papel e filmes traz maior dependência de computadores e bancos de dados. Corrupção e perda de dados podem não apenas trazer caos administrativo, mas também podem afetar o atendimento ao paciente de forma significativa.

Em suma, o potencial de causar danos aos pacientes decorrentes do uso de tecnologias de informação e comunicação (TIC) em aplicações para a saúde aumentará, à medida que o uso de TIC em aplicações de saúde cresça, a sofisticação dos aplicativos aumente e a confiança nas TIC cresça. Há evidência de crescente preocupação entre os profissionais e o público com incidentes de mau funcionamento de software que levam a consequências adversas à saúde, aumentando a conscientização do público.

Consequentemente, várias organizações de saúde estão cada vez mais concentradas nos padrões de garantia de controles, incluindo aqueles sobre governança e gerenciamento de risco. Uma característica importante destes controles consiste no gerenciamento de risco no contexto de danos aos pacientes e deficiências na qualidade assistencial. Estes controles geralmente envolvem a compra e a aplicação de produtos de software para a saúde.

Falhas e deficiências em produtos de software para a saúde podem, é claro, apresentar impactos adversos, além de causar danos aos pacientes. Elas podem, por exemplo, criar inconveniências administrativas ou mesmo gerar caos administrativo, com uma variedade de possíveis impactos na organização, incluindo perdas financeiras. O dano causado a um paciente também pode resultar em impacto na organização, como perdas financeiras resultantes de litígios.

Considerando que estes impactos organizacionais adversos serão significativos para uma organização, eles não são objeto desta especificação técnica, a menos que resultem em danos a um paciente. Por exemplo, a falha do sistema central de administração de pacientes de um hospital certamente causará transtornos administrativos substanciais, mas este impacto adverso não está, por si mesmo, no escopo desta especificação técnica, a menos que tenha o potencial de causar danos a um paciente (o que é possível).

O tema desta especificação técnica é o dano potencial ao paciente. Em muitos países assegura-se a segurança de medicamentos e de dispositivos médicos por meio de uma diversidade de medidas legais e administrativas; por exemplo, na União Europeia se está sujeito a várias diretivas da UE. Estas medidas são, muitas vezes, apoiadas por uma série de normas relacionadas com a segurança, provenientes de várias fontes, nacionais e internacionais, incluindo a International Organization for Standardization (ISO), o European Committee for Standardization (CEN) e a International Electrotechnical Commission (IEC).

Estes controles legislativos frequentemente abrangem o software necessário para a aplicação ou funcionamento correto de um dispositivo médico. No entanto, outros softwares aplicados à saúde geralmente não estão cobertos desta maneira. Esta especificação técnica se refere ao software aplicado à saúde, excluindo o que é necessário para a aplicação ou funcionamento corretos de um dispositivo médico. Um precursor necessário para estabelecer e implementar controles apropriados de projeto e produção, para minimizar os riscos aos pacientes decorrentes do mau funcionamento do produto ou do seu desempenho inadequado, é um entendimento claro dos riscos que um produto pode apresentar aos pacientes se puder ocorrer mau funcionamento ou um evento não intencional, e a possibilidade deste mau funcionamento ou evento causar danos ao paciente.

Além disso, se os fabricantes de produtos de software para a saúde forem orientados no projeto e controle de produção (e os correspondentes padrões produzidos), então será preciso reconhecer que os controles necessários para produtos com baixo risco não serão os mesmos que para aqueles apresentando riscos elevados. Os controles precisam corresponder ao nível de risco que um produto pode representar para um paciente.

Com este fim, muitos padrões, legislações e especificações que lidam com o controle de riscos, tanto em projeto como em produção, agrupam produtos em um número limitado de classes ou tipos, de acordo com o risco que podem representar. Esta especificação técnica apresenta um processo para este tipo de agrupamento de produtos de software para a saúde. Ela propõe cinco classes de risco e facilitará uma ampla triagem de tipos genéricos de produtos e de produtos individuais, de forma a permitir diferentes níveis, ou rigor, na aplicação de controles de projeto e produção compatíveis com o risco.

Assim, a classificação proposta pode ser a precursora para padrões de projeto e de controles de produção, em que os últimos podem requerer uma análise de risco muito mais detalhada, aprofundada e rigorosa para um produto específico daquele requerido para o processo de classificação mais amplo descrito nesta especificação técnica. São oferecidos exemplos da aplicação do processo de atribuição de uma classe de risco para vários tipos diferentes de produtos de software de saúde.

O termo produtos de software para a saúde refere-se a qualquer produto de software para a saúde, esteja ou não colocado no mercado, e esteja à venda ou seja distribuído gratuitamente. Esta especificação técnica, portanto, abrange produtos comerciais, bem como, por exemplo, software de código aberto e softwares criados para, e usados em, uma única organização de saúde, como um hospital. Existe uma ampla gama de produtos de software para a saúde, que vão desde simples bancos de dados de pesquisa até sistemas de chamadas e rechamadas, suporte a decisões clínicas, sistemas de registros eletrônicos de saúde, sistemas de despacho de ambulância, sistemas de laboratório clínico hospitalar e sistemas de clínica geral. O Anexo B fornece quatro exemplos da aplicação desta especificação técnica a diferentes produtos de software para a saúde. Entretanto, qualquer software que seja necessário para o uso adequado ou para o funcionamento de um dispositivo médico está fora do escopo desta especificação técnica.

A ABNT ISO/TS25238 de 09/2019 – Informática em saúde – Classificação dos riscos de segurança em software para a saúde preocupa-se com a segurança dos pacientes e fornece orientação sobre a análise e a categorização dos perigos e riscos que os produtos de software para a saúde apresentam para os pacientes, a fim de permitir a classificação de qualquer produto em uma das cinco classes de risco. É aplicável aos perigos e riscos que podem causar danos a um paciente. Outros riscos, como riscos financeiros ou organizacionais, estão fora do escopo desta especificação técnica, a menos que tenham potencial de prejudicar um paciente.

É aplicável a qualquer produto de software para a saúde, quer seja ou não colocado no mercado, e esteja à venda ou seja gratuito. São oferecidos exemplos da aplicação do esquema de classificação. Não se aplica a qualquer software que seja necessário para a correta aplicação ou para o funcionamento de um dispositivo médico. Destina-se a classificar o software para a saúde em classes de risco amplas, para auxiliar em decisões como, por exemplo, quais controles convém que sejam aplicados para garantir a segurança. Não se destina à aplicação da análise de risco e gerenciamento de risco ao projeto de produtos de software para a saúde e à mitigação de quaisquer riscos identificados a níveis aceitáveis (ver Anexo A).

Acesse algumas questões relacionadas a essa norma GRATUITAMENTE no Target Genius Respostas Diretas:

Quais os perigos de uma atribuição de categorias de consequência?

Qual é a atribuição de possibilidade a consequências?

Qual é o conceito das classes de risco?

Como executar a análise de consequências?

Qual é o relacionamento de classes de risco ao projeto e controle de produção de produtos?

Convém que os fabricantes de produtos de software para a saúde possuam um claro entendimento dos perigos que o seu produto pode representar para um paciente, se ele funcionar de maneira errada ou causar um evento inesperado, e do grau de possibilidade de que o perigo se concretize se ele ocorrer em circunstâncias razoáveis de uso. Este conhecimento é necessário para a extensão e natureza das medidas de controle necessárias e o rigor com que elas precisam ser aplicadas, assim como para reduzir os riscos aos pacientes a níveis aceitáveis, por exemplo, por meio de medidas como características inerentes de projeto, instruções de uso e treinamento de indução.

O que é tolerável dependerá das circunstâncias e das atuais visões da sociedade e reguladores. O precursor essencial para este processo é realizar uma análise de perigos e riscos. Existem diversas abordagens para realizar as análises de perigos e riscos, sendo que todas compartilham um conjunto de conceitos básicos. Os padrões, diretrizes e publicações existentes tendem a focar em setores específicos de atividade (por exemplo, sistemas de segurança eletrônica, aeronáutica) ou áreas de conhecimento (por exemplo, riscos financeiros, riscos à propriedade, riscos à segurança de dados pessoais).

Desta forma, necessitam de interpretações no contexto de produtos de software para saúde. Esta especificação técnica se inspira em uma diversidade de fontes para se manter alinhada com princípios geralmente aceitos. A Bibliografia fornece uma lista de fontes de informação úteis no contexto. Ao considerar a abordagem a ser adotada para produtos de software para a saúde, tem-se que atentar para como os dispositivos médicos são classificados e controlados em termos de segurança. O Anexo A trata desta matéria.

A seguir são apresentados alguns dos conceitos básicos, na forma como são utilizados nesta especificação técnica. Esta seção não pretende abranger todos os aspectos da análise de perigo/risco. O risco para a segurança de um paciente ou pacientes a partir de um produto de software para a saúde dependerá das possíveis consequências que podem resultar, se o produto funcionar de forma errada ou resultar em um evento ou eventos adversos, e da possibilidade de que estas consequências possam acontecer de fato.

Desta forma, o risco possui dois aspectos: consequência e probabilidade. O ISO Guide 51 define risco como a combinação da probabilidade de um evento e sua consequência, enquanto esta especificação técnica define risco como a combinação da possibilidade de ocorrência de dano e a gravidade deste dano (2.7). A probabilidade que um perigo se concretize pode, em alguns domínios, ser quantitativamente representada como uma probabilidade que pode estar baseada em análises de falhas históricas ou experimentais e estatísticas de incidentes.

É muito improvável que esta situação ocorra com a segurança de produtos de informática em saúde, uma vez que estas estatísticas e evidências não estão disponíveis e, desta forma, são necessários julgamentos qualitativos. Ainda que a probabilidade possa ser representada qualitativamente, o termo possibilidade representa melhor este significado e é usado nesta especificação técnica.

O ISO Guide 73:2002 define risco como a combinação da probabilidade de um evento e sua consequência”. Esta definição possui os mesmos problemas que o uso do termo probabilidade ao invés de possibilidade. Entretanto, esta especificação técnica está focada somente em eventos que são propensos a causar dano a pacientes e a gravidade deste dano, mais do que outros eventos.

Desta forma, não é usado o termo evento. A consequência, ou seja, o dano ao paciente, pode ocorrer de diferentes formas, variando da morte a inconvenientes menores, por exemplo. Consequências podem ser categorizadas. Estas categorias precisam ser interpretadas de acordo com a sua esfera de aplicação, neste caso a aplicação de TIC à saúde.

Esta Especificação Técnica propõe cinco categorias de consequências, cada uma com uma descrição de seu escopo (ver 5.2). A possibilidade de um perigo se concretizar em circunstâncias razoavelmente previsíveis pode, em alguns domínios, ser quantitativamente representada como uma probabilidade que pode estar baseada em análises históricas ou experimentais de falhas e na análise de incidentes.

É muito improvável que este seja o caso para a segurança de produtos de software para a saúde para os quais não estão disponíveis estatísticas e evidências e, deste modo, são necessários julgamentos qualitativos. Esta especificação técnica propõe cinco categorias de possibilidade, cada uma com uma descrição de seu escopo (ver 5.3). Como notado anteriormente, o risco para a segurança de um paciente ou pacientes de um produto de software para a saúde depende das possíveis consequências que podem ocorrer se o produto tiver mau funcionamento ou resultar em um ou mais eventos adversos, e da possibilidade de que estas consequências possam ocorrer de fato. O nível de riscos pode ser representado em uma matriz de riscos na qual a possibilidade e a consequência são suas duas dimensões (ver tabela abaixo).

Cada célula da matriz representa um nível de risco. Desta forma, na matriz de risco da tabela, as 25 células representam 25 resultantes de risco, que diminuem de gravidade ao mover-se diagonalmente do quadrante superior esquerdo para o inferior direito. Estas resultantes de risco podem ser agrupadas em classes como as seguintes: a classe de risco mais alta pode ser um grupo de células na parte superior esquerda, como 1, 2 e 3; a classe de risco mais baixa pode ser um grupo de células na parte inferior direita, como 4, 5 e 6.

As células na matriz de riscos podem, desta forma, ser preenchidas com classes de risco. Ao agrupar conjuntos de células em uma classe, considerações precisam ser tomadas sobre as circunstâncias no setor de aplicação e os significados atribuídos a cada categoria de consequência e possibilidade. O objetivo é reduzir a complexidade por meio da identificação de células que representem de forma ampla um grau similar de risco ao paciente e agrupá-las em uma classe com este perfil. Assim, uma consequência menor, com uma alta possibilidade, geralmente pode se equiparar a uma consequência pior, mas com menor possibilidade. Esta especificação técnica propõe cinco classes de risco.

O controle e as comunicações de dados em tratores agrícolas ou florestais

Atualmente, está disponível um sistema de comunicações para equipamentos agrícolas com base no protocolo da ISO 11898-2.

A NBR ISO 11783-1 de 08/2019 – Tratores e máquinas agrícolas e florestais — Rede serial para comunicação de dados e controle – Parte 1: Padrão geral para comunicação de dados móveis especifica uma rede serial de dados para controle e comunicações em tratores agrícolas ou florestais e implementos montados, semimontados, rebocados ou autopropelidos. Sua finalidade é padronizar o método e o formato de transferência de dados entre sensores, atuadores, elementos de controle, unidades de armazenamento e exibição de informações, montados ou se forem parte do trator ou implemento. Ela é destinada a fornecer interligação de sistema aberto (Open System Interconnect – OSI) para sistemas eletrônicos utilizados por equipamentos agrícolas e florestais. Fornece uma visão geral da NBR ISO 11783.

Para desenvolvedores de aplicações segundo a NBR ISO 11783, o conteúdo desta base de dados eletrônicos fornece a listagem atual das designações de endereços, designações de identidade e definições de parâmetros da NBR ISO 11783-1 que foram designadas e que estão oficialmente registradas pela SAE J1939. Estas informações são encontradas na base de dados on-line no website da ISOBUS (http://www.isobus.net/).

Acesse algumas questões relacionadas a essa norma GRATUITAMENTE no Target Genius Respostas Diretas:

Quais os termos abreviados usados nessa norma?

Qual seria uma estrutura de conexão física típica da rede do trator/implemento?

Qual seria uma topologia típica da rede da NBR ISO 11783?

Como seria a interface do computador de gerenciamento da fazenda?

O que contém a base de dados eletrônicos da NBR ISO 11783-1?

A NBR ISO 11783 especifica um sistema de comunicações para equipamentos agrícolas com base no protocolo da ISO 11898-2. Os documentos SAE J19391, em que as partes da NBR ISO 11783 são baseadas, foram desenvolvidos em conjunto para uso em aplicações de caminhões e ônibus e para aplicações na construção e agricultura. Documentos conjuntos foram concluídos para permitir que as unidades eletrônicas que atendem às especificações SAE J1939 de caminhões e ônibus sejam utilizadas por equipamentos agrícolas e florestais com alterações mínimas.

Informações gerais sobre a NBR ISO 11783 podem ser encontradas nesta parte da NBR ISO 11783. O objetivo da NBR ISO 11783 é fornecer um sistema aberto e interligado para sistemas eletrônicos embarcados. Ela é destinada a permitir que unidades de controle eletrônico (ECU) se comuniquem entre si, fornecendo um sistema padronizado.

A interligação de sistemas abertos (OSI) especificada na ISO/IEC 7498-1 é um modelo de arquitetura de comunicações por computador que possui sete camadas, conforme mostrado na figura abaixo. Pretende-se que as redes de comunicações de dados, como a serie ABNT NBR ISO 11783, sejam desenvolvidas para realizar as funções de cada uma das camadas OSI, conforme requerido.

Camada 1 – Física – Esta camada refere-se à transmissão de um fluxo de bits não estruturado sobre mídia física; ela trata das características mecânicas, elétricas, funcionais e de processo para acessar a mídia física.

Camada 2 – Dados – Esta camada fornece a transferência confiável de informações pela da camada física; ela envia blocos de dados com o sincronismo, controle de erros, controle sequencial e controle de fluxo.

Camada 3 – Rede – Esta camada fornece camadas superiores com independência das tecnologias de transmissão e comutação de dados utilizados para conectar sistemas; ela é responsável por estabelecer, manter e encerrar conexões.

Camada 4 – Transporte – Esta camada fornece transferência confiável e transparente de dados entre pontos finais, recuperação de erros de ponta a ponta e controle de fluxo, e segmentação e remontagem de mensagens muito grandes.

Camada 5 – Sessão – Esta camada fornece a estrutura de controle para comunicação entre aplicações; ela estabelece, gerencia e encerra conexões (sessões) entre aplicações de cooperação.

Camada 6 – Apresentação – Esta camada fornece independência ao processo da aplicação das diferenças na representação de dados (sintaxe).

Camada 7 – Aplicação – Esta camada fornece acesso ao ambiente OSI para usuários e também fornece serviços de informações distribuídas.

Não é requerido que qualquer norma baseada no modelo OSI, incluindo a NBR ISO 11783, seja particionada explicitamente nas sete camadas OSI, desde que a funcionalidade fundamental seja suportada. Nem todas as camadas OSI são requeridas para a rede NBR ISO 11783, porque esta rede é um sistema de comunicações específico, suportando conjuntos específicos de aplicações para uma indústria específica.

Somente as camadas requeridas para o uso previsto são definidas na NBR ISO 11783, com uma parte separada da NBR ISO 11783 especificando cada uma das camadas e com outras partes fornecendo suporte de funcionalidade para as camadas. Em redes concordantes com a série NBR ISO 11783, muitas mensagens são transmitidas. Estas redes incluem a rede do trator (6.6.2) e a rede do implemento (6.6.3). Portanto, os dados são transmitidos na rede sem direcioná-los para um destino específico.

Esta configuração permite que qualquer função de controle utilize os dados sem utilizar mensagens de solicitação adicionais. A NBR ISO 11783 também especifica que um endereço de destino específico seja incluído no identificador rede de área de controle (CAN) da mensagem, quando uma mensagem for direcionada para uma função de controle específica. O formato da mensagem específica de destino é, portanto, diferente do formato da mensagem global de destino.

A comunicação de propriedade também é permitida na NBR ISO 11783, utilizando formatos de mensagens específicas de destino ou mensagem globais de destino. A NBR ISO 11783-2 especifica a subcamada de acesso à mídia para as ECU e a subcamada dependente do meio físico para as redes do trator e do implemento. A interface da ECU deve estar em conformidade com a subcamada de sinalização física, conforme normalizado na ISO 11898-1:2015, e a subcamada de acesso à mídia física, conforme normalizado na ISO 11898-2:2016. A rede é composta de um único cabo linear torcido quadruplamente conectado a cada ECU em um nó. Um cabo curto fornece uma conexão do nó ao cabo torcido quadruplamente para cada ECU.

Circuitos de polarização da terminação ativos são especificados para cada extremidade de um segmento de rede. A NBR ISO 11783-2 também especifica os conectores requeridos para conectar implementos a tratores, ECUs adicionais a uma rede existente instalada no equipamento e uma ferramenta de serviço na rede. A NBR ISO 11783-2 também especifica as fontes de energia requeridas para a operação da rede e suas conexões.

As ECU concordantes com a série NBR ISO 11783 devem utilizar o Formato de Estrutura Estendida CAN Clássica, definido na ISO 11898-1:2015. Os formatos de estruturas CAN FD não podem ser utilizados. A NBR ISO 11783-3 define a estrutura do identificador CAN para especificar os formatos de mensagens. Os formatos de mensagem ou unidades de dados de protocolo são utilizados para identificar o conteúdo de uma mensagem.

A NBR ISO 11783-3 especifica um campo (PF) de formato PDU de 8 bits, um campo (PS) específico PDU de 8 bits e um campo de página de dados de 2 bits que é utilizado para identificar uma PDU. Para reduzir a sobrecarga de mensagens, a NBR ISO 11783-3 especifica que um número de itens ou parâmetros de dados relativos deve ser agrupado dentro de uma PDU. A NBR ISO 11783 especifica mensagens adicionais para mensagens proprietárias do fabricante.

As mensagens que necessitam de mais 8 bytes de dados são enviadas como mensagens multipacote. A NBR ISO 11783-3 especifica um protocolo de transporte para transmitir mensagens multipacote de até 1 785 bytes de comprimento. A NBR ISO 11783-6 especifica um segundo protocolo de transporte para transmitir mensagens de 1 786 bytes até 117 megabytes.

As definições individuais do formato de mensagem da aplicação, incluindo a taxa de transmissão da mensagem, o comprimento da estrutura de dados, a página de dados, PF, PS ou DA e a prioridade padrão, são fornecidas na parte da NBR ISO 11783 que especifica a aplicação específica. Quando duas redes com diferentes arquiteturas de rede forem conectadas, o integrador do sistema conectado deve utilizar uma unidade de interligação de rede para isolar cada segmento de rede do outro.

As unidades de interligação de rede estão detalhadas na NBR ISO 11783-4. Também é possível que sistemas complexos possam requerer mais do que o limite elétrico de 30 nós, conforme especificado na NBR ISO 11783-2, em uma série NBR ISO 11783. Nestes casos, o fabricante do sistema do implemento deve utilizar unidades de interligação de rede para manter os limites de carga elétrica requeridos da rede.

Cada função de controle que se comunica na rede de dados da ABNT NBR ISO 11783 requer um endereço da fonte (SA). Se uma ECU realizar as mais de uma função de controle, um endereço é requerido para cada função de controle. Para identificar exclusivamente cada função de controle, a NBR ISO 11783-5 especifica um NAME de 64 bits. A NBR ISO 11783-5 define o processo específico para determinar os endereços de fonte e resolver quaisquer conflitos de endereço que possam ocorrer.

O SA é pré-ajustado ou dinamicamente reivindicado por cada controlador, à medida que são ativados. Um NAME deve ser designado para cada função de controle que se comunica em uma rede NBR ISO 11783. Existem exemplos, como um terminal virtual e porta de gerenciamento em uma ECU comum, onde vários NAME e endereços coexistem dentro de uma única ECU.

A base de dados da NBR ISO 11783 em http://www.isobus.net/ lista os seguintes códigos para campos de um NAME: as indústrias que utilizam especificações de gerenciamento de rede ABNT NBR ISO 11783; endereços pré-ajustados ou preferidos para funções de controle não específicas; endereços iniciais designados para equipamentos agrícolas e florestais; os NAME a serem utilizados pelas funções de controle em uma rede de dados da NBR ISO 11783; os fabricantes que fornecem ECU para operar em uma rede de dados ABNT NBR ISO 11783. Os endereços utilizados pelas funções de controle também são ilustrados.

A NBR ISO 11783 suporta dois ou mais segmentos de rede. Um segmento é identificado como a rede do trator. Este segmento é destinado a fornecer as comunicações de controle e dados para o trem de acionamentos e chassi do trator ou a unidade de energia principal em um sistema. O segundo segmento é identificado como a rede do implemento que fornece as comunicações de controle e dados entre implementos e entre implementos e o trator ou a unidade de energia principal no sistema. Uma ECU do trator é requerida para conectar à rede do trator e a rede do implemento.

Dá para medir a eficácia da segurança da informação em sua empresa?

Os criminosos digitais estão cada vez mais querendo acessar as empresas e a segurança da informação, nesse contexto, passa a ser um ponto de extrema importância ligada à estratégia corporativa. Para se ter uma ideia, estima-se que o número de ataques cibernéticos aumentou entre 30 e 40% na América Latina nos últimos anos.

Assim, para garantir um bom nível de segurança, é fundamental ter uma infraestrutura robusta. Portanto, deve-se investir em vários aspectos: arquitetura, design de um esquema de proteção, operações e práticas seguras, além de uma boa gestão de riscos.

Quanto à arquitetura, pode-se pensar na análise do projeto de uma prisão ou de uma base militar. Sempre se deve levar em consideração qual é a finalidade de um edifício. Ele abrigará réus de alta periculosidade? Que informações e objetos ficarão dentro de uma área militar?

O sistema precisa ser projetado como um todo, já que ele é formado por um conjunto de componentes que devem ser protegidos individualmente. Uma infraestrutura segura leva em conta um design geral da solução sem deixar de prestar atenção à proteção dos dados. Dessa forma, há uma segurança específica para cada um dos elementos: servidores, computadores, a rede, os componentes de comunicação, etc.

Ao configurar um serviço ou registrar um usuário, essas ações estão relacionadas a uma interação com um sistema e também devem ser feitas com segurança. Uma pessoa pode até ter um automóvel extremamente seguro e equipado com os melhores acessórios de segurança, mas acabará sofrendo um acidente se dirigir bêbado ou ultrapassar o limite de velocidade da via.

É preciso considerar as boas práticas que estabelecem qual é a melhor forma de atuar na maioria dos casos e das vezes. Precisa-se saber como são essas boas práticas e adotá-las para ter uma referência de aprimoramento.

Todas as empresas são diferentes. Cada setor tem suas próprias ameaças e exposições a riscos específicos. Por isso, é importante contar com uma referência. Quais seriam as circunstâncias de uma pequena e média empresa? Depende da área de atuação e da importância das informações com as quais essa empresa trabalha. Traçar um panorama de riscos gera certeza na hora de avaliar até que ponto deve-se otimizar o sistema e o que é preciso priorizar.

Quanto à computação na nuvem, possibilita a realização de operações seguras por causa de sua arquitetura e de seu design de soluções. A arquitetura da nuvem assemelha-se a uma fortaleza. Ela já fica armada e as operações e configurações são feitas pelo provedor, motivo pelo qual há menos exposição aos riscos.

E pode-se medir a eficácia de todo esse sistema?A NBR ISO/IEC 27004 de 04/2010 – Tecnologia da informação – Técnicas de segurança – Gestão da segurança da informação – Medição fornece as diretrizes para o desenvolvimento e uso de métricas e medições a fim de avaliar a eficácia de um Sistema de Gestão de Segurança da Informação (SGSI) implementado e dos controles ou grupos de controles, conforme especificado na NBR ISO/IEC 27001. Esta norma é aplicável a todos os tipos e tamanhos de organizações.

O usuário deste documento precisa interpretar corretamente cada uma das formas verbais das expressões fornecidas (por exemplo: “deve”, “não deve”, “convém que”, “não convém que”, “pode”, “não precisa” e “não pode”) como sendo um requisito a ser atendido e/ou recomendações em que existe certa liberdade de escolha. Convém que seja consultado o Anexo A da ISO/IEC 27000:2009 para esclarecimentos adicionais.

Esta norma fornece diretrizes para elaboração e uso de medidas e medições a fim de avaliar a eficácia de um Sistema de Gestão de Segurança da Informação (SGSI) implementado e de controles ou grupos de controles, conforme especificado na NBR ISO/IEC 27001. Isto inclui a política, gestão de riscos de segurança da informação, objetivos de controles, controles, processos e procedimentos, e apoio ao processo de sua revisão, ajudando a determinar se algum processo ou controle do SGSI precisa ser modificado ou melhorado.

É necessário lembrar que nenhuma medição de controles pode garantir segurança completa. A implementação desta metodologia constitui um Programa de Medição de Segurança da Informação. O Programa de Medição de Segurança da Informação vai apoiar a gestão na identificação e avaliação de processos e controles do SGSI ineficazes e não conformes e na priorização de ações associadas com a melhoria ou modificação desses processos e/ou controles.

Também pode auxiliar a organização na demonstração da conformidade com a NBR ISO/IEC 27001 e prover evidências adicionais para os processos de análise crítica pela direção e de gestão de riscos em segurança da informação. Esta norma assume que o ponto de partida para o desenvolvimento das medidas e medições é o entendimento claro dos riscos de segurança da informação que a organização enfrenta e que as atividades de análise de riscos da organização têm sido executadas corretamente (por exemplo, baseada na NBR ISO/IEC 27005), conforme requerido pela NBR ISO/IEC 27001.

O Programa de Medição de Segurança da Informação encorajará que uma organização forneça informações confiáveis às partes interessadas pertinentes relacionadas com os riscos de segurança da informação e com a situação do SGSI implementado para gerenciar esses riscos. Se for eficazmente implementado, o Programa de Medição de Segurança da Informação aumentará a confiança das partes interessadas nos resultados das medições e possibilitará às partes interessadas a usarem essas medidas para realizar a melhoria contínua da segurança da informação e do SGSI.

Os resultados acumulados de medição permitirão a comparação do progresso em atingir os objetivos de segurança da informação sobre um período de tempo como parte de um processo de melhoria contínua do SGSI da organização. A NBR ISO/IEC 27001 exige que a organização “realize análises críticas regulares da eficácia do SGSI levando em consideração os resultados da eficácia das medições” e que “meça a eficácia dos controles para verificar se os requisitos de segurança da informação foram alcançados”.

A NBR ISO/IEC 27001 também exige que a organização “defina como medir a eficácia dos controles ou grupo de controles selecionados e especifique como essas medidas devem ser usadas para avaliar a eficácia dos controles para produzir resultados comparáveis e reproduzíveis”. A abordagem adotada por uma organização para atender os requisitos de medição especificados na NBR ISO/IEC 27001 vai variar de acordo com o número de fatores significantes, incluindo os riscos de segurança da informação que a organização enfrenta, o tamanho da organização, recursos disponíveis, e requisitos legais, regulatórios e contratuais aplicáveis.

A seleção e a justificativa criteriosa do método usado para atender aos requisitos de medição são importantes para assegurar que recursos em excesso não sejam direcionados a estas atividades do SGSI em detrimento de outras. Em condições ideais, as atividades de medição em curso devem ser integradas nas operações normais da organização com um acréscimo mínimo de recursos.

Os objetivos da medição de Segurança da informação no contexto de um SGSI incluem: avaliar a eficácia dos controles ou grupos de controles implementados (ver “4.2.2 d)” na Figura 1); avaliar a eficácia do SGSI implementado (ver 4.2.3 b)” na Figura 1); verificar a extensão na qual os requisitos de segurança da informação identificados foram atendidos (ver “4.2.3 c)” na Figura 1); facilitar a melhoria do desempenho da segurança da informação em termos dos riscos de negócio globais da organização; fornecer entradas para a análise crítica pela direção para facilitar as tomadas de decisões relacionadas ao SGSI e justificar as melhorias necessárias do SGSI implementado.

A Figura 1 ilustra o relacionamento cíclico de entrada e saída das atividades de medição em relação ao ciclo Planejar-Fazer-Checar-Agir (PDCA), especificado na NBR ISO/IEC 27001. Os números em cada figura representam as subseções relevantes da NBR ISO/IEC 27001:2006.

Clique nas figuras para uma melhor visualização

figura-1_medicao

Convém que a organização estabeleça objetivos de medição baseados em certas considerações, incluindo: o papel da segurança da informação em apoiar as atividades globais da organização e os riscos que ela encara; requisitos legais, regulatórios e contratuais pertinentes; estrutura organizacional; custos e benefícios de implementar as medidas de segurança da informação; critério de aceitação de riscos para a organização; e a necessidade de comparar diversos SGSI dentro da própria organização. Convém que uma organização estabeleça e gerencie um Programa de Medição de Segurança da Informação, a fim de alcançar os objetivos de medição estabelecidos e adotar um modelo PDCA nas atividades de medição globais da organização.

Também convém que uma organização desenvolva e implemente modelos de medições, a fim de obter resultados repetitivos, objetivos e úteis da medição baseado no Modelo de Medição da Segurança da Informação (ver 5.4). Convém que o Programa de Medição de Segurança da Informação e o modelo de medição desenvolvidos assegurem que uma organização alcance efetivamente os objetivos e as medições de forma repetitiva e forneça os resultados das medições para as partes interessadas pertinentes de modo a identificar as necessidades de melhorias do SGSI implementado, incluindo seu escopo, políticas, objetivos, controles, processos e procedimentos.

Convém que um Programa de Medição de Segurança da Informação inclua os seguintes processos: desenvolvimento de medidas e medição (ver Seção 7); operação da medição (ver Seção 8); relato dos resultados da análise de dados e da medição (ver Seção 9); e avaliação e melhoria do Programa de Medição de Segurança da Informação (ver Seção 10). Convém que a estrutura organizacional e operacional de um Programa de Medição de Segurança da Informação seja determinada levando em consideração a escala e a complexidade do SGSI do qual ele é parte.

Em todos os casos, convém que os papéis e responsabilidades para o Programa de Medição de Segurança da Informação sejam explicitamente atribuídos ao pessoal competente ( ver 7.5.8). Convém que as medidas selecionadas e implementadas pelo Programa de Medição de Segurança da Informação, estejam diretamente relacionadas à operação de um SGSI, a outras medidas, assim como aos processos de negócio da organização.

As medições podem ser integradas às atividades operacionais normais ou executadas a intervalos regulares determinados pela direção do SGSI. Assim, o Modelo de Medição de Segurança da Informação é uma estrutura que relaciona uma necessidade de informação com os objetos relevantes da medição e seus atributos. Objetos de medição podem incluir processos planejados ou implementados, procedimentos, projetos e recursos.

O Modelo de Medição de Segurança da Informação descreve como os atributos relevantes são quantificados e convertidos em indicadores que fornecem uma base para a tomada de decisão. A Figura 2 mostra o modelo de medição de Segurança da Informação.

figura-2_medicao

Uma medida básica é a medida mais simples que pode ser obtida. A medida básica resulta da aplicação do método de medição aos atributos selecionados de um objeto de medição. Um objeto de medição pode ter muitos atributos, dos quais somente alguns podem fornecer valores úteis a serem atribuídos a uma medida básica. Um dado atributo pode ser usado para diversas medidas básicas.

Um método de medição é uma sequência lógica de operações usadas para quantificar um atributo de acordo com uma escala especificada. A operação pode envolver atividades, tais como a contagem de ocorrências ou observação da passagem do tempo. Um método de medição pode aplicar atributos a um objeto de medição.

Exemplos de um objeto de medição incluem mas não estão limitados a: desempenho dos controles implementados no SGSI; situação dos ativos de informação protegidos pelos controles; desempenho dos processos implementados no SGSI; comportamento do pessoal que é responsável pelo SGSI implementado; atividades de unidades organizacionais responsáveis pela segurança da informação; e grau da satisfação das partes interessadas.

Um método de medição pode usar objetos de medição e atributos de variadas fontes, tais como: análise de riscos e resultados de avaliações de riscos; questionários e entrevistas pessoais; relatórios de auditorias internas e/ou externas; registros de eventos, tais como logs, relatórios estatísticos, e trilhas de auditoria; relatórios de incidentes, particularmente aqueles que resultaram na ocorrência de um impacto; resultados de testes, por exemplo, testes de invasão, engenharia social, ferramentas de conformidade, e ferramentas de auditoria de segurança; ou registros de segurança da informação da organização relacionados a programa e procedimentos, por exemplo, resultados de treinamentos de conscientização em segurança da informação.

tabela-1_medicao

Uma medida derivada é um agregado de duas ou mais medidas básicas. Uma dada medida básica pode servir como entrada para diversas medidas derivadas. Uma função de medição é um cálculo usado para combinar medidas básicas para criar uma medida derivada. A escala e a unidade da medida derivada dependem das escalas e unidades das medidas básicas das quais ela é composta, assim como da forma como elas são combinadas pela função de medição.

A função de medição pode envolver uma variedade de técnicas, como média de medidas básicas, aplicação de pesos a medidas básicas, ou atribuição de valores qualitativos a medidas básicas. A função de medição pode combinar medidas básicas usando escalas diferentes, como porcentagens e resultados de avaliações qualitativas. Um exemplo do relacionamento de elementos adicionais na aplicação do modelo de medição de Segurança da informação, por exemplo, medidas básicas, função de medição e medidas derivadas são apresentadas na Tabela 2.

tabela-2_medicao

Um indicador é uma medida que fornece uma estimativa ou avaliação de atributos especificados derivados de um modelo analítico de acordo com a necessidade de informação definida. Indicadores são obtidos pela aplicação de um modelo analítico a uma medida básica e/ou derivada, combinando-as com critérios de decisão. A escala e o método de medição afetam a escolha das técnicas analíticas utilizadas para produzir os indicadores. Um exemplo de relacionamentos entre medidas derivadas, modelo analítico e indicadores para o modelo de medição de Segurança da informação é apresentado na Tabela 3.

tabela-3_medicao

Se um indicador for representado em forma gráfica, convém que possa ser usado por usuários visualmente debilitados e que cópias monocromáticas possam ser feitas. Para tornar a representação possível, convém que ela inclua cores, sombreamento, fontes ou outros métodos visuais.

Os resultados de medição são desenvolvidos pela interpretação de indicadores aplicáveis baseados em critérios de decisão definidos e convém que sejam considerados no contexto global dos objetivos de medição para avaliação da eficácia do SGSI. O critério de decisão é usado para determinar a necessidade de ação ou investigação futura, bem como para descrever o nível de confiança nos resultados de medição.

Os critérios de decisão podem ser aplicados a uma série de indicadores, por exemplo, para conduzir análise de tendências baseadas em indicadores recebidos a intervalos de tempo diferente. Alvos fornecem especificações detalhadas para desempenho, aplicáveis à organização ou partes dela, derivados dos objetivos de segurança da informação tais como os objetivos do SGSI e objetivos de controle, e que precisam ser definidos e atendidos para se alcançar esses objetivos.

A certificação de cabeamento é mais necessária que nunca

Richard Landim

O atual cenário de crise econômica que o país enfrenta demandou uma reestruturação dos orçamentos de TI. Reduzir custos é a prioridade número um das empresas, que precisam tomar decisões difíceis para reduzir despesas operacionais e de capital. No entanto, neste processo, é fundamental que os gerentes de TI não se esqueçam de que uma infraestrutura de rede saudável está diretamente ligada à produtividade, eficiência e expansão de serviços.

Uma opção tentadora para reduzir as despesas de TI pode ser adiar a manutenção. Embora nenhuma organização prorrogue uma manutenção realmente crítica, existem tarefas que podem ser adiadas, pois estão em uma zona cinzenta que pode ser considerada “opcional”. Trafegar nessas decisões não é fácil, mas seria um grave erro suspender os testes da fundação de cada rede: seu cabeamento de cobre e fibra.

O teste mais completo para o cabeamento de rede é a certificação. A certificação prova que um sistema de cabos adere a rigorosos padrões de desempenho e de execução da instalação, por isso, este procedimento requer técnicos treinados e equipamentos de teste especializados. Este é um esforço caro que pode ser adiado, certo? Errado.

O cabeamento é responsável por metade de todas as falhas na rede. Ao certificá-lo, as falhas são significativamente reduzidas. Em tempos financeiramente desafiadores, este é um benefício crucial que pode ser potencializado de seis maneiras.

Certificar é mais barato que reparar – A certificação de cabos de cobre e fibra previne problemas. Sem ela os reparos devem ser feitos em uma rede ativa ou pior, em uma rede que está sofrendo uma interrupção. O tempo de inatividade da rede resulta em perda de receita e produtividade, redução de serviço ao cliente e desvantagem competitiva. Um estudo do Gartner estimou que uma hora de inatividade de uma rede corporativa custa, em média US$ 42.000, dependendo da indústria. Se uma empresa é desafiada a melhorar seu tempo de atividade anual de 99,9% para 99,99%, ela precisa reduzir o tempo de inatividade por oito horas. Usando a estimativa do Gartner sobre o custo de inatividade, isso gera uma economia para a empresa de US$ 336.000 por ano. Mas como se chega lá? Há muitas causas de inatividade. Um estudo do Gartner/Dataquest apontou que o erro humano e de aplicação são responsáveis por 80% das falhas. Mas se a rede representa apenas 20% da causa, ela responde por US$ 67.000 da exposição. Compare isso com o custo da certificação. Uma rede com 600 linhas de cobre Categoria 6 passa por testes de certificação. Uma suposição realista é que 5% dos links falham no teste inicial e devem ser reparados e testados novamente. Usando um certificador de cabo moderno todo o processo levaria aproximadamente 11 horas. A uma taxa comercial de R$50 por hora, a despesa será de R$600. R$600 de despesa para economizar US$67.000. O caso de sucesso da certificação é auto evidente.

As garantias do produto estão limitadas – Em tempos difíceis um proprietário de rede pode ser tentado a usar a garantia de um fabricante por segurança. Isso é compreensível uma vez que a maioria dos fabricantes de cabos e conectores oferecem boas garantias e estão por trás de seus produtos. Entretanto, esses fabricantes não podem garantir a instalação final. A qualidade de uma instalação de cabos está em grande parte nas mãos dos instaladores. Se a habilidade do profissional é fraca, mesmo produtos excelentes falham. As falhas e problemas associadas à rede estão fora do escopo de uma garantia de hardware, de modo que o proprietário da rede e o instalador devem negociar a correção. A única maneira de assegurar que a obra do instalador atenda aos padrões e que as melhores práticas sejam seguidas é através dos testes de certificação. A certificação dá a proteção necessária contra custos imprevistos ao proprietário da rede e, quando os ventos da economia estão desfavoráveis, essa proteção é sempre bem-vinda.

Certificação e recertificação serão a prova de futuro da infraestrutura – Você pode acreditar que um cabo, após instalado e certificado, nunca mais precisará de atenção. Isso pode ser imprudente. Uma planta de cabeamento recertificada pode provar ser compatível com o tráfego de alta velocidade que é implantado anos após o cabo ser instalado pela primeira vez. Quão importante é o suporte para velocidades mais altas? De acordo com um levantamento de datacenters pela empresa de pesquisa BSRIA, a tecnologia multigigabit é comum agora.

Quais são as implicações disto? O cabo de cobre da categoria 6 foi projetado para suportar uma taxa de dados de 1 Gigabit por segundo. Os recentes testes de certificação em campo indicam que boa parte do cabo Cat 6 usado nos datacenters está em conformidade com o padrão 10GBASE-T e pode suportar o serviço de 10 Gigabit em distâncias curtas a moderadas. Se você recertificar o cabo Cat 6 em seu datacenter pode encontrar um caminho eficiente para uma taxa de transferência de 10X, evitando alguns ou todos os custos de substituição de cabeamento. Além disso, quando a demanda por serviços de TI repercutir, a planta de cabos recertificados estará pronta para suportar novos equipamentos e expandir os serviços.

Cabeamento não certificado = Capital subutilizado – É um fato: recessões agitam o mercado, especialmente o imobiliário. Quando um novo inquilino entra em um edifício o estado de seu cabeamento apresenta uma série de questões. Quantos anos têm? Funciona? Para que foi usado? Quando? O novo inquilino pode ver a essa quantidade de cabos de cobre e/ou fibra como um mistério e não como algo bom. Certificar 200 links de cabos custará menos de R$ 1000. A instalação de 200 novas linhas do novo cabo Cat 6 custará de R$ 5.000 a R$ 10.000. A escolha para o locatário é fácil. A certificação é sinônimo de capital poupado para os proprietários de edifícios e inquilinos. A falta de certificação transforma o cabeamento legado em capital subutilizado: dinheiro gasto que não pode ser recuperado.

Reduzir resíduos é uma boa política – O argumento econômico para estender a vida dos cabos já foi descrito, mas pode não ser o pior caso. O Código Elétrico Nacional (NEC 2002) requer a remoção de cabos abandonados que não sejam identificados para uso futuro. Sem certificação, o custo do cabo legado pode incluir a despesa com a remoção e reciclagem dos cabos e/ou o impacto ambiental da eliminação. Maximizar o uso de cabos de cobre e fibra existentes é uma política de negócios consistente. Quando devidamente conservado tem uma longa vida útil. Com orçamentos limitados exigindo maior eficiência, faz sentido usar a certificação para implementar os três pilares da gestão ambiental: Reduzir, Reutilizar e Reciclar.

Comprador cauteloso – Uma tendência inquietante na indústria de cabos refere-se a produtos das categorias 5, 6 e 6A. Estes cabos são muitas vezes fabricados fora do país e é mais barato se comparado ao de grandes fabricantes. Infelizmente, muito destes cabos baratos são produzidos com materiais inferiores e em processos de fabricação questionáveis. Em 2008, a Communications Cable & Connectivity Association testou nove marcas de cabos sem nome em comercialização no mercado. Nenhuma delas atingiu porém os requisitos físicos definidos no TIA 568-B.2; apenas cinco atenderam aos padrões de teste elétrico determinados no TIA 568-B.2; e somente uma atende aos pré-requisitos de segurança definidos pelas normas UL 1666 e NFPA 262.

Mas como esse cabo tão fraco chega ao mercado? Isso acontece porque as agências de segurança realizam testes aleatórios na fábrica e não no campo. O abismo no processo de qualidade deixa os usuários finais expostos a riscos de segurança e desempenho totalmente evitáveis. Para assegurar que não haja prejuízo ou riscos ocultos com cabos Cat 5, 6 e 6A de baixo custo, as empresas e instaladores devem se certificar de que o cabeamento esteja de acordo com os padrões da indústria.

Em suma, o cabeamento certificado tem muito mais valor. E pode variar dependendo da aplicação e da empresa. Considere as armadilhas dos cabos não certificados. Considere o trade-off entre os testes e “espere o melhor”. A esperança é raramente uma boa estratégia e, em uma economia desafiadora, é ainda mais perigosa.

Richard Landim é especialista de produtos da Fluke Networks Brasil.