A identificação inequívoca dos instrumentos financeiros

A NBR 16885 de 06/2020 – Identificador global de instrumento financeiro (FIGI) – Diretrizes fornece as diretrizes para a identificação inequívoca de instrumentos financeiros em três diferentes níveis, local/sistema de registro/negociação (nível câmara), mercado onde o instrumento financeiro é emitido/negociado (nível país) e nível global. Estas diretrizes englobam a sintaxe para a composição de um identificador global de instrumentos financeiros, o conteúdo associado a um identificador, bem como a sua relação com instrumentos financeiros e com outros identificadores de instrumentos financeiros.

Acesse algumas dúvidas relacionadas a essas normas GRATUITAMENTE no Target Genius Respostas Diretas:

O que é um identificador global composto?

Qual é o fluxo do processo de alocação de prefixos de identificador?

Como é a conformidade como provedora de identificadores?

Para que fazer a solicitação de serviço de um novo identificador?

O desenvolvimento de um identificador global de instrumento financeiro originou-se do reconhecimento de que a teoria do caos não contempla a complexidade gerada todos os dias pelos bilhões – talvez trilhões – de transações com instrumentos financeiros que realizam câmaras de compensação e bolsas de valores em todo o mundo. Quase todos os aspectos do gerenciamento de instrumentos financeiros são baseados em sistemas fechados que usam identificadores proprietários que são de propriedade restrita e utilização licenciada.

Fechar cada acordo é tanto um exercício de tradução de informações quanto de processamento de transações, já que os traders, investidores e corretores lutam com vários formatos proprietários para determinar o que é, quem é o dono, quanto vale determinado instrumento financeiro e quando uma negociação precisa ser fechada. Ele introduz uma enorme quantidade de atrito no ciclo de vida do negócio e cria opacidade onde a clareza é procurada. Além disso, o uso de identificadores proprietários acrescenta custos e despesas gerais significativos quando os usuários desejam integrar dados de fontes diferentes ou migrar para um sistema de dados de outro mercado.

A evolução das simbologias avançadas ajudou a indústria de valores mobiliários a crescer, mas as limitações e os custos impostos pelos sistemas fechados tornaram-se mais evidentes à medida que as empresas e instituições continuam a integrar as operações em uma escala global. A simbologia proprietária agora se coloca como uma das barreiras mais significativas para aumentar a eficiência e a inovação em um setor que realmente necessita dela.

Além disso, a falta de identificadores comuns é um obstáculo fundamental para alcançar o estado da arte do processamento direto (STP). Alguns pontos merecem ser destacados. As taxas de licenciamento exigem que as empresas paguem por cada sistema de símbolos que usam. As organizações internacionais arcam com um ônus especialmente pesado, porque muitas vezes precisam licenciar diversas simbologias para administrar operações comerciais em vários países.

As restrições impostas por simbologias proprietárias impedem as empresas de mapear facilmente um conjunto de códigos para outro. Isso dificulta a integração de dados de mercado de diversas fontes, bem como esforços para automatizar as atividades comerciais e de liquidação. Os consumidores de dados de mercado que adotam símbolos proprietários para uso em seus próprios sistemas não precisam pagar apenas as taxas de licenciamento, mas esses símbolos também levam a custos futuros significativos, associados aos esforços para se conectar aos sistemas comerciais emergentes.

Os ambientes de negociação proprietários podem ter funcionado bem durante anos, mas são um subproduto de uma época em que os sistemas de dados funcionavam em grande parte como ilhas que não precisavam interoperar com outros sistemas. Um nível de abordagem diferente: mercados, clientes e governos estão exigindo maior conectividade, transparência e eficiência.

Além disso, a abertura dos sistemas baseados na internet alterou profundamente a forma como as empresas e os indivíduos coletam, gerenciam e compartilham informações. Assim, além de novas regulamentações que exigem clareza e responsabilidade, a mudança para a simbologia aberta está sendo impulsionada por crescentes demandas institucionais e de investidores.

A adoção de um sistema aberto de simbologia compartilhada estabelece as bases para um tremendo salto na negociação eficiente e na liquidação de valores mobiliários, bem como no gerenciamento de dados e relatórios de instrumentos financeiros de maneira mais geral. Esse sistema permitirá que empresas e provedores de serviços de tecnologia transfiram recursos de processos trabalhosos e ineficientes para novos investimentos em ferramentas e produtos que melhor atendam aos clientes.

O rápido crescimento do processamento distribuído levou à necessidade de uma estrutura de coordenação para essa padronização e às recomendações da ISO/IEC 10746 (todas as partes); o Modelo de Referência de Processamento Distribuído Aberto (RM-ODP) fornece tal estrutura. Ele define uma arquitetura na qual o suporte de distribuição, interoperabilidade e portabilidade pode ser integrado.

A ISO/IEC 10746-2 estabelece os conceitos fundamentais e a estrutura de modelagem para descrever sistemas distribuídos. Os escopos e objetivos da ISO/IEC 10746-2 e da Linguagem de Modelagem Unificada (UML), embora relacionados, não são os mesmos e, em vários casos, a ISO/IEC 10746-2 e a especificação da UML usam o mesmo termo para conceitos relacionados, mas estes não são idênticos (por exemplo, interface). No entanto, uma especificação usando os conceitos de modelagem da ISO/IEC 10746-2 pode ser expressa usando UML com extensões apropriadas (usando estereótipos, tags e restrições).

A ISO/IEC 10746-3 especifica uma arquitetura genérica de sistemas distribuídos abertos, expressa usando os conceitos fundamentais e a estrutura estabelecida na ISO/IEC 10746-2. Devido à relação entre a UML como linguagem de modelagem e a ISO/IEC 10746-3, é fácil demonstrar que a UML é adequada como uma notação para as especificações de pontos de vista individuais definidas pelo RM-ODP.

Esta norma estabelece um método para automatizar a contagem de pontos de função, que é geralmente consistente com a versão 4.3.1 do Manual de Práticas de Contagem (CPM do inglês Counting Practices Manual), produzido pelo Grupo Internacional de Usuários de Pontos de Função (IFPUG do inglês International Function Point Users Group). As diretrizes desta norma podem diferir daquelas do CPM do IFPUG em pontos onde os julgamentos subjetivos precisavam ser substituídos pelas regras necessárias para automação. O CPM do IFPUG foi selecionado como base para esta norma, porque é a especificação de medição funcional mais amplamente utilizada, com uma grande infraestrutura de suporte mantida por uma organização profissional.

Pode-se ressaltar que um identificador global de instrumento financeiro é estruturado como uma cadeia de 12 caracteres que é semanticamente sem sentido. Como a cadeia se destina a permanecer ligada a um determinado instrumento financeiro ao longo da vida desse instrumento, além de servir como referência histórica para instrumentos financeiros obsoletos, é vital que a cadeia seja estruturada de forma a ser semanticamente neutra.

Devido à granularidade do identificador global de instrumento financeiro, existe a necessidade de vários tipos de identificadores para fornecer agrupamentos de instrumentos financeiros. Os três tipos de identificadores globais de instrumento financeiro são os seguintes: identificador global: esse é o tipo mais básico de identificador que se aplica exatamente a um único instrumento financeiro no nível mais granular. Por exemplo, ações comuns da Apple (AAPL) negociadas no mercado NASDAQ Global Select.

A granularidade desse identificador é encontrada naquilo que ele identifica. Em particular, o FIGI mais básico identifica um instrumento financeiro, onde aplicável, ao nível do local de negociação. Isto é, quando aplicável, o identificador global identifica um instrumento financeiro dentro do contexto de um local de negociação.

Um identificador global composto é, ele próprio, um identificador global que é diferenciado de um identificador global normal, na medida em que serve como “pai” em uma hierarquia de identificadores globais individuais. Por exemplo, ações comuns da AAPL negociadas no mercado NASDAQ Global Select (nível local/sistema) e em nível global, apresentadas como uma lista de identificadores globais compostos. O propósito desta versão do identificador é agrupar identificadores individuais, conforme descrito anteriormente, em agrupamentos no nível do país.

O identificador global composto só se aplica a um subconjunto limitado de identificadores globais. Em particular, aplica-se apenas àqueles identificadores globais que podem ser diferenciados com base na bolsa em que o ativo é negociado, ou na fonte de preços do ativo. Essas condições só são obtidas no caso de ações. Como tal, o identificador global composto é usado apenas no agrupamento de ações.

O identificador global da classe de ativos é semelhante a um identificador global composto, porém o identificador global da classe de ativos identifica um instrumento financeiro dentro do contexto da perspectiva global, por exemplo, ações ordinárias da Apple. Como um mecanismo de agrupamento para identificadores globais compostos, o identificador global da classe de ativos é usado apenas no agrupamento de ações.

Convém que os caracteres utilizados dentro de um identificador global de instrumento financeiro (FIGI) sejam os seguintes: todas as seguintes consoantes em maiúsculas: B, C, D, F, G, H, J, K, L, M, N, P, Q, R, S, T, V, W, X, Y, Z; os únicos dígitos inteiros são 0 – 9. Enquanto a cadeia em si é semanticamente sem sentido, existe uma estrutura específica que é usada. Convém que as regras de sintaxe para os 12 caracteres sejam as seguintes: caracteres 1 e 2: qualquer combinação de consoantes maiúsculas, com as seguintes exceções: BS, BM, GG, GB, GH, KY, VG. O objetivo desta restrição é reduzir as chances de que o identificador resultante possa ser idêntico a uma sequência do código ISIN (International Securities Identification Number) (ver ISO 6166).

Estritamente falando, uma duplicata não é um problema, pois as strings designam coisas diferentes, mas mesmo assim foi tomado cuidado para reduzir a ambiguidade. A maneira que o ISIN é construído é que os dois primeiros caracteres correspondem ao país de emissão. O terceiro caractere, dependendo da organização emissora, é tipicamente um numeral. No entanto, no caso do Reino Unido, a letra “G” é atribuída. Como está sendo usada a letra “G” como o caractere 3, as únicas combinações que podem surgir dentro do ISIN que somente incorporam consoantes são BSG (Bahamas), BMG (Bermudas), GGG (Guernsey), GBG (Reino Unido) e VGG (Ilhas Virgens Britânicas).

A razão para isso é que o Reino Unido emite números ISIN para entidades dentro de sua jurisdição mais ampla. A alocação dos prefixos para diferentes Provedores Certificados (PC) é especificada no Anexo A. O caractere 3: a letra maiúscula G (para global); o caractere 4-11: qualquer combinação de consoantes maiúsculas e algarismos 0 – 9; caracteres 12: um dígito de verificação (0 – 9) calculado da seguinte forma: as letras são convertidas em números inteiros, conforme a tabela abaixo.

Usando os primeiros 11 caracteres, começando no último caractere em formato inteiro e trabalhando da direita para a esquerda, cada segundo inteiro é multiplicado por dois. A sequência de inteiros resultante (números maiores que 10 se tornam dois dígitos separados) é somada. Subtrair o total do próximo inteiro mais alto que termina em zero. Se o total obtido ao somar os dígitos for um inteiro terminando em zero, convém que o dígito de verificação seja zero.

Embora o identificador global esteja no centro desta norma, um conjunto de campos complementares está associado ao identificador, sendo dois dos quais instâncias especiais do próprio identificador. A necessidade dos pontos de dados adicionais é amplamente uma função da granularidade do identificador global. Como o identificador global serve para identificar instrumentos financeiros no nível mais granular possível, é muito útil especificar claramente os diferenciadores que constituem a granularidade.

Para esse fim, vários elementos-chave de dados estão associados a cada identificador global, que servem para destacar os recursos de diferenciação, além de fornecer informações adicionais sobre o instrumento financeiro, como, por exemplo, o seu nome. Os instrumentos financeiros são, pela sua natureza, coisas que podem ser compradas ou vendidas. Os instrumentos financeiros de que esta norma trata são comprados ou vendidos em uma bolsa de valores.

Como o identificador global atribui identificadores exclusivos aos instrumentos financeiros no nível mais granular possível, convém especificar o local no qual o instrumento financeiro individual é negociado. Convém que o identificador global seja agrupado, juntamente com a fonte de preços, como um código associado. Os códigos dos locais de negociação estão associados aos instrumentos financeiros por meio da propriedade de objeto “has” que é usado em vez de uma propriedade de objeto mais descritiva, como “hasAssociatedCode”, para alavancar os recursos de raciocínio e ser “mapeável” para as relações da Ontologia de Negócios da Indústria Financeira (FIBO).

O nome do instrumento financeiro é o nome da empresa e, às vezes, pode incluir uma breve descrição do instrumento financeiro. O nome de um instrumento pode mudar em conjunto com eventos corporativos. Conforme mencionado anteriormente, convém que o identificador associado ao instrumento financeiro não seja alterado em resposta a tal evento. Em muitos casos, como, por exemplo, ações ordinárias, o nome do instrumento financeiro também é o nome do órgão emissor.

Isso não é suficiente para individualizar o instrumento financeiro, uma vez que as organizações emitem instrumentos financeiros com exatamente o mesmo nome, mas que são negociados em diferentes bolsas. Esta é uma distinção que está ausente em outros identificadores, mas serve como uma característica particular para o FIGI.

O imageamento e comunicações digitais em medicina (DICOM)

Nos equipamentos eletromédicos pode-se controlar seguintes objetos de informação: um Objeto de Informação de Imagem DICOM (DICOM Image Information Object – IOD) para Radioterapia. Este especifica o conteúdo semântico das Imagens de RT. Normalmente se abrevia como RT Imagem IOD. Também inclui a Classe de Armazenamento (Storage SOP) correspondente para que a IOD possa ser usada nos intercâmbios de Rede e de Armazenamento de Mídia (Network).

A ABNT IEC/TR 61852 de 06/2020 – Equipamentos eletromédicos — Imageamento e comunicações digitais em medicina (DICOM) — Objetos de radioterapia especifica os seguintes objetos de informação: um Objeto de Informação de Imagem DICOM (DICOM Image Information Object – IOD) para Radioterapia. Este especifica o conteúdo semântico das Imagens de RT. Normalmente se abrevia como RT Imagem IOD. Também inclui a Classe de Armazenamento (Storage SOP) correspondente para que a IOD possa ser usada nos intercâmbios de Rede e de Armazenamento de Mídia (Network). O escopo da RT Imagem IOD apresenta imagens de radioterapia que tenham sido obtidas em uma geometria cônica de imageamento, como as encontradas em simuladores convencionais e dispositivos de imageamento de portal.

Também podem ser usadas para imagens calculadas usando a mesma geometria, como as radiografias reconstruídas digitalmente (RRD). Um Objeto de Informação de Dose DICOM (DICOM Dose Information Object) para Radioterapia. Especifica o conteúdo semântico das Doses de RT. Normalmente se abrevia como RT Dose IOD. Também inclui a Classe de Armazenamento (Storage SOP) correspondente para que a IOD possa ser usada nos intercâmbios de Rede (Network) e de Armazenamento de Mídia. O escopo da RT Dose IOD apresenta distribuições de dose de radioterapia que tenham sido calculadas em um sistema de planejamento de tratamento radioterápico, representadas como grades bidimensionais ou tridimensionais de dose, grupos de pontos de dose nomeados ou não nomeados, curvas de isodose, e histogramas dose-volume (DVH).

Um Objeto de Informação de Conjunto de Estrutura DICOM (DICOM Structure Set Information Object) para Radioterapia. Especifica o conteúdo semântico dos Conjuntos de Estrutura de RT. Normalmente se abrevia como RT Structure Set IOD. Também inclui a Classe Storage SOP correspondente para que a IOD possa ser usada nos intercâmbios de Rede (Network) e de Armazenamento de Mídia. O escopo da RT Structure Set IOD apresenta as estruturas relativas ao paciente de radioterapia que tenham sido identificadas em dispositivos como tomógrafos computadorizados (TC), estações de simulação virtual (workstations) ou sistemas de planejamento de tratamento. Um Objeto de Informação de Plano DICOM (DICOM Plan Information Object) para Radioterapia. Este especifica o conteúdo semântico dos Planos (Tratamentos) de RT.

Normalmente se abrevia como RT Plano IOD. Também inclui a Classe Storage SOP correspondente para que a IOD possa ser usada nos intercâmbios de Rede (Network) e de Armazenamento de Mídia. O escopo da RT Plan IOD apresenta os dados geométricos e dosimétricos especificando um curso de feixe externo e/ou tratamento de braquiterapia. Este Relatório inclui uma diversidade de emendas às Partes existentes da DICOM. Portanto, convém que o leitor tenha uma compreensão operacional da Norma. 1. Parte 3 Emendas (Extensão do corpo, Anexos A, B, C e D); 2. Parte 4 Emendas (Extensão do Anexo B); e 3. Parte 6 Emendas (Extensão da Seção 6 e do Anexo A).

Acesse algumas dúvidas relacionadas a essas normas GRATUITAMENTE no Target Genius Respostas Diretas:

Quais os símbolos e abreviaturas usados nessa norma?

Como pode ser feita a descrição do RT Plan IOD?

Como deve ser estruturado o Módulo RT FRACTION SCHEME?

Quais os atributos do Módulo RT Image?

Este complemento da norma DICOM define uma variedade de objetos de informação aplicáveis ao domínio da radiação em oncologia. A intenção destes objetos é dar suporte à transferência de dados relativos à radioterapia entre os dispositivos encontrados dentro e fora de um departamento de radioterapia. No entanto, eles não têm a intenção de dar suporte ao gerenciamento dos dados transferidos, uma função que pode ser tratada em revisões futuras da norma DICOM.

Esta tarefa de gerenciamento de processos não tem sido tratada na publicação atual devido à ausência de um modelo de processo consistente para um departamento de radioterapia, especialmente em um contexto internacional. Como resultado, os objetos de informação de radioterapia contêm um grande número de elementos de dados condicionais e opcionais. Essencialmente, os objetos são destinados a serem utilizados como contêineres para dados relacionados à radioterapia, com os dados sendo acrescentados à medida que o objeto avança pelo departamento.

O foco desta IOD de Imagem de Radioterapia (RT Image IOD) é tratar dos requisitos para transferência de imagem encontrados em aplicações gerais de radioterapia executadas em simuladores convencionais, simuladores virtuais e dispositivos de imageamento portal. Estas imagens têm uma geometria de imageamento cônica e podem tanto ser adquiridas diretamente do dispositivo, ou digitalizadas usando um digitalizador de filme. Elas podem ou não ter curvas sobrepostas descrevendo as aberturas do dispositivo limitador do feixe (colimador), dispositivos de modificação do feixe, estruturas do paciente e volumes-alvo. Os parâmetros numéricos de dados de feixe também podem ser registrados com a imagem, indicando os valores dos parâmetros no momento em que a imagem foi tomada ou criada. O modelo E-R para a RT Image IOD é apresentado na figura abaixo.

Deve-se observar que não existe qualquer provisão para representação de curvas multiframe (ou seja, todas as curvas são interpretadas em relação ao primeiro frame de imagem em uma imagem multiframe). Curvas que não sejam estruturas de paciente também podem ser representadas usando os tipos de curva HIST, POLY ou TABL (ver P3.3, C.10.2.1). O módulo Equipment contém informações descrevendo o equipamento usado para captar ou gerar a Imagem de RT (como um imageador de portal, simulador convencional ou sistema de planejamento de tratamento).

No entanto, os atributos de equipamento no módulo de RT Image descrevem o equipamento no qual o tratamento foi ou será administrado, normalmente um acelerador de elétrons. Para imagens de RT que não contenham dados pertinentes de pixel, como imagens BEV sem informações RRD, convém que Pixel Data (7FE0,0010) seja preenchido com uma sequência de zeros. O módulo Frame of Reference tem sido incluído para possibilitar a indicação da associação espacial de dois ou mais RT Image (por exemplo, quando as imagens tiverem sido adquiridas no mesmo Frame of Reference, ou tiverem sido reamostradas para compartilhar o mesmo Frame of Reference).

Se o Frame of Reference ocorrer dentro de um SOP Instances em uma determinada série, então todos os SOP Instances desta série estarão espacialmente relacionados. Por exemplo: duas RT Images podem compartilhar o mesmo Frame of Reference se estiverem localizadas no mesmo plano físico, como determinado pelo Ângulo do Gantry da máquina de tratamento (300A,011E) e pela distância do plano fonte-imagem especificada pela RT Image SID (3002,0026).

O foco para esta IOD de Dose de Radioterapia (RT Dose IOD) é tratar dos requisitos de transferência de distribuições de dose calculados por sistemas de planejamento de tratamento de radioterapia. Estas distribuições podem ser representadas por grades 2D ou 3D, como curvas de isodose, ou como pontos de dose nomeados ou não nomeados espalhados por todo o volume. Esta IOD também pode conter dados de histograma dose-volume, overlays isolados ou de multiframes, anotações de áudio e tabelas de pesquisa definidas pela aplicação.

Esta IOD não apresenta definição de doses no feixe ou outros sistemas de coordenadas. Dentro da RT Dose IOD, o módulo de RT Dose suporta grades de dose 2D e 3D. O Structure Set, ROI Contour e módulos da RT Dose ROI juntos suportam curvas e pontos de isodose, e o módulo RT DVH suporta dados de histograma dose-volume. Eles não são mutuamente exclusivos: todas as quatro representações podem ser incluídas em um único caso do objeto e podem ser incluídos em qualquer combinação.

Convém que Declarações de Conformidade de Produto declarem claramente quais destes mecanismos têm suporte e sob quais condições. A RT Dose IOD foi definida como uma IOD composta, separada da RT Plan IOD. Isso tem sido feito pelos seguintes motivos: para possibilitar a multiplicidade de cálculos de dose usando modelos de feixe para o mesmo plano básico e para evitar transmissão indesejada de grandes quantidades de dados com o plano de tratamento.

O foco para esta IOD de Conjunto de Estrutura de Radioterapia (RT Structure Set IOD) é tratar dos requisitos para transferência de estruturas do paciente e de dados relacionados definidos nos tomógrafos TC, estações de simulação virtual, sistemas de planejamento de tratamento e dispositivos similares. Esta IOD também pode conter anotações de curva em áudio.

Como definir os elementos consistentes dos metadados

O propósito deste modelo é permitir a descrição padronizada de documentos de arquivo e entidades contextuais críticas para documentos de arquivo, fornecer uma compreensão comum dos pontos fixos de agregação para permitir a interoperabilidade de documentos de arquivo e informações relevantes para documentos de arquivo entre sistemas organizacionais e permitir reutilização e padronização de metadados para gerenciar documentos de arquivo ao longo do tempo, espaço e entre aplicações.

A NBR ISO 23081-2 de 04/2020 – Informação e documentação — Gerenciamento de metadados para documentos de arquivo – Parte 2: Problemas conceituais e implementação estabelece um modelo para definir os elementos de metadados consistentes com os princípios e as considerações de implementação descritos na NBR ISO 23081-1. O propósito deste modelo é permitir a descrição padronizada de documentos de arquivo e entidades contextuais críticas para documentos de arquivo, fornecer uma compreensão comum dos pontos fixos de agregação para permitir a interoperabilidade de documentos de arquivo e informações relevantes para documentos de arquivo entre sistemas organizacionais e permitir reutilização e padronização de metadados para gerenciar documentos de arquivo ao longo do tempo, espaço e entre aplicações. Ela também identifica alguns dos pontos de decisão críticos que precisam ser abordados e documentados para permitir a implementação de metadados para gerenciar documentos de arquivo. Ela visa identificar os problemas que precisam ser abordados na implementação de metadados para gerenciamento de documentos de arquivo, identificar e explicar as várias opções para abordar as questões, e identificar vários caminhos para tomar decisões e escolher opções na implementação de metadados para gerenciar documentos de arquivo.

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

Quais as relações entre entidades nos metadados?

Quais são os conceitos relativos à implementação de metadados?

Por que os metadados podem ser herdados de um agregado superior para um inferior?

Qual o modelo de metadados para gerenciar documentos de arquivo?

A série NBR ISO 23081 descreve metadados para documentos de arquivo. Esta parte 2 concentra-se no modelo de definição de elementos de metadados para gestão de documentos de arquivo, e fornece uma declaração genérica de elementos de metadados, sejam estes físicos, analógicos ou digitais, de acordo com os princípios da NBR ISO 23081-1. Ela fornece uma fundamentação sólida dos metadados para gerenciar documentos de arquivo em organizações, modelos conceituais de metadados e um conjunto de elementos de alto nível de metadados genéricos, adequados para qualquer ambiente de documentos de arquivo.

Abrange, por exemplo, implementações atuais de gestão de documentos de arquivo ou arquivísticas. Ela define os tipos genéricos de metadados, tanto para entidades de documentos de arquivo quanto para outras entidades que precisam ser gerenciadas para documentar e entender o contexto dos documentos de arquivos. Esta parte 2 também identifica, para entidades-chave, um número mínimo de camadas de agregação fixas que são necessárias para fins de interoperabilidade. Os modelos e os tipos de metadados genéricos delineados nesta parte são principalmente focados na entidade documentos de arquivo.

No entanto, eles também são relevantes para as outras entidades. Não estabelece um conjunto específico de elementos de metadados. Em vez disso, ela identifica tipos genéricos de metadados que são necessários para cumprir os requisitos para gerenciar documentos de arquivo. Essa abordagem fornece às organizações a flexibilidade para selecionar metadados específicos para atender aos requisitos de seus negócios e gerenciar seus documentos de arquivo enquanto eles são necessários.

Ela fornece diagramas para determinar os elementos de metadados que podem ser definidos em uma implementação específica e os que podem ser aplicados a cada agregação das entidades definidas. Ela reconhece que essas entidades podem existir em diferentes camadas de agregação. Ela define tipos de metadados genéricos que podem ser aplicados em todas as camadas de agregação, ao mesmo tempo em que alerta aos implementadores para elementos de metadados que só podem ser aplicados em camadas de agregação específicas.

A implementação de metadados para gerenciar documentos de arquivo usando parâmetros organizacionais e de sistema envolve uma série de escolhas, que são determinadas pelas conjunturas da organização, pelos sistemas instalados e pelos requisitos para gerenciar documentos de arquivo. Com base nos princípios da NBR ISO 23081-1, esta parte 2 fornece explicações adicionais sobre os conceitos subjacentes de esquemas de metadados para gerenciar documentos de arquivo, oferece orientações práticas para o desenvolvimento e construção desses esquemas do ponto de vista organizacional e, finalmente, aborda questões relacionadas à implementação e ao gerenciamento de metadados ao longo do tempo.

Destina-se a arquivistas (ou pessoas atribuídas dentro de uma organização para gerenciar documentos de arquivo em qualquer ambiente) responsáveis pela definição de metadados para gerenciar documentos de arquivo em qualquer camada de agregação em um sistema de negócios ou software de documentos de arquivo dedicado, sistemas/analistas de negócio responsáveis pela identificação de metadados para gerenciar documentos de arquivo em sistemas de negócio, arquivistas ou analistas de sistemas que abordam os requisitos de interoperabilidade do sistema envolvendo documentos de arquivo, e fabricante de software, como fornecedores de aplicativos que apoiam e permitem a definição, captura e gestão de metadados ao longo do tempo. As organizações precisam de sistemas de informação que capturem e gerenciem informações contextuais adequadas para auxiliar o uso, compreensão, gerenciamento e acesso a documentos de arquivo ao longo do tempo.

Esta informação é crítica para assegurar autenticidade, confiabilidade, integridade, usabilidade e qualidades probatórias de documentos de arquivo. Coletivamente, essa informação é conhecida como metadados para gerenciamento de documentos de arquivo. Os metadados para gerenciar documentos de arquivo podem ser usados para uma variedade de propósitos dentro de uma organização, apoiando, identificando, autenticando, descrevendo, localizando e gerenciando seus recursos de forma sistemática e consistente para atender às necessidades de negócio, responsabilidade e requisitos societários das organizações.

O software de documentos de arquivo e os sistemas de negócio com funcionalidade de gerenciamento de registros gerenciam documentos de arquivo, capturando e gerenciando os seus metadados e o contexto de sua produção e uso. Os documentos de arquivo, particularmente sob a forma de transações eletrônicas, podem existir fora do software de documentos de arquivo formais, muitas vezes sendo produzidos em sistemas de negócio que atendem a fins específicos (por exemplo, sistemas de licenciamento).

Os documentos de arquivo são usados e compreendidos por pessoas que possuem ou têm acesso a conhecimentos suficientes sobre os processos que estão sendo realizados ou por pessoas que estão envolvidas na transação dos documentos de arquivo gerados e seu contexto imediato. Tais documentos de arquivo nem sempre são robustos, por razões que incluem as ligações contextuais que podem não ser escritas e depender da memória individual e do grupo.

Essa confiança no entendimento contextual não escrito não é confiável; algumas pessoas têm acesso a mais conhecimento do que outras; ao longo do tempo, a usabilidade dos documentos de arquivo será comprometida pelo movimento do pessoal e pela diminuição da memória corporativa. Os documentos de arquivo muitas vezes não possuem informações explícitas necessárias para identificar os componentes de uma transação fora do contexto de negócio específico e, portanto, são difíceis de intercambiar com outros sistemas de negócio relacionados aos fins de interoperabilidade.

Os processos de gestão necessários para assegurar a sustentabilidade dos documentos de arquivo ao longo do tempo, que eles requerem, geralmente não são uma característica de tais sistemas. Existem limites práticos para a quantidade de informações contextuais que podem ser explicitadas e capturadas em um determinado sistema na forma de metadados. O contexto é infinito, enquanto um único sistema de informação possui limites finitos. Outras informações contextuais sempre existirão fora dos limites de qualquer sistema. Um único sistema de software de documentos de arquivo precisa capturar o máximo de metadados que forem considerados úteis para que o sistema e seus usuários interpretem e gerenciem os documentos de arquivo pelo tempo que forem necessários no sistema e para permitir a migração daqueles documentos de arquivo requeridos fora do sistema.

Os bons esquemas de metadados são dinâmicos e podem incluir metadados adicionais para gerenciar documentos de arquivo conforme necessário ao longo do tempo. Muitos metadados para gerenciar documentos de arquivo podem ser obtidos de outros sistemas de informação. Para que eles sejam úteis em um sistema de gerenciamento de documentos de arquivo, eles precisam ser estruturados e organizados de forma padronizada.

Os metadados padronizados são um pré-requisito essencial para a interoperabilidade do sistema de informação dentro e entre organizações. Os metadados para gerenciar documentos de arquivo não só descrevem seus atributos, de forma a permitir seu gerenciamento e uso/reutilização, mas também documentam as relações entre os documentos de arquivo e os agentes que os definem e os usam, além dos eventos ou circunstâncias em que os documentos de arquivo são produzidos e utilizados. Os metadados apoiam a busca de informações e a manutenção de sua autenticidade.

As organizações precisam produzir documentos de arquivo de suas transações e mantê-los enquanto forem necessários. Isso pode ser feito somente se os sistemas de negócio das organizações capturarem metadados de documentos de arquivo de acordo com os requisitos organizacionais para gerenciá-los. O quanto melhor um sistema gerencia documentos de arquivo é em grande parte dependente das funcionalidades de metadados do sistema. As relações entre os sistemas de negócio e os sistemas de softwares específicos de documentos de arquivo estão sujeitas às decisões nas implementações, conforme descrito na Seção 11.

A interoperabilidade refere-se à capacidade de dois ou mais sistemas automatizados de trocar informações e reconhecer, processar e usar essas informações com sucesso. Os sistemas interoperáveis precisam ser capazes de funcionar simultaneamente em níveis técnicos, semânticos e sintáticos. Os metadados padronizados são um pré-requisito essencial para a interoperabilidade do sistema de informação.

Os metadados padronizados para gerenciar documentos de arquivo ajudam a permitir a interoperabilidade da seguinte maneira: entre sistemas de negócio dentro de uma organização (por exemplo, entre os sistemas que apoiam um processo de negócio e aqueles que oferecem apoio a outros processos de negócio em toda a organização); entre sistemas de negócio que produzem documentos de arquivo e software de documentos de arquivo que os administram como documentos de arquivo; entre sistemas de negócio durante a migração de um sistema; entre várias organizações envolvidas na condução de processos de negócio (por exemplo, em uma cadeia de gerenciamento ou transações de comércio eletrônico); entre organizações para uma variedade de outros propósitos do negócio (por exemplo, na realização de transações compartilhadas ou transferência de documentos de arquivo para um terceiro); ao longo do tempo entre os sistemas de negócio que produzem documentos de arquivo e sistemas arquivísticos que os preservam. Ao apoiar a interoperabilidade, os metadados para gerenciar documentos de arquivo permitem a descoberta de recursos em sistemas de negócio, bem como em software de documentos de arquivo.

Os esquemas de metadados podem ser adaptados aos requisitos organizacionais para mitigação dos riscos. As organizações especificarão elementos que devem estar presentes para que os documentos de arquivo sejam confiáveis, autênticos e íntegros. Outros elementos serão opcionais, para inclusão, a critério das subunidades de organizações, ou para sistemas de negócio específicos dentro das organizações.

Ao considerar estratégias de implementação de metadados, recomenda-se que as organizações identifiquem os riscos que existem, considerem o grau de risco envolvido e garantam que a estratégia de implementação: forneça acesso aos sistemas de negócio críticos ao longo do tempo, satisfaça os requisitos legais de autenticidade e confiabilidade, e seja sustentável a partir de uma perspectiva de recursos ao longo do tempo. Os metadados estruturados para gerenciamento de documentos de arquivo, em combinação com boas funcionalidades de sistemas de busca, apoiam o acesso e a recuperação de documentos de arquivo em toda a organização. Isso maximiza a capacidade das pessoas de encontrar documentos de arquivo relevantes de forma rápida e fácil, quando precisam.

Além disso, os metadados de documentos de arquivo estruturados permitem que as informações sejam recuperadas no contexto do negócio, aumentando assim a compreensão e a confiabilidade das informações recuperadas para reutilização. Um investimento inicial, relativamente pequeno, em bons metadados, pode melhorar a qualidade e reduzir os custos de recuperação de informações para a organização. Os metadados para gerenciar documentos de arquivo podem ser usados para reduzir o risco de uso não autorizado. Metadados são necessários para especificar se o acesso aos documentos de arquivo é restrito.

Recomenda-se que somente aqueles com autorização apropriada tenham acesso aos documentos de arquivo. Convém que quaisquer instâncias de acesso sejam documentadas como metadados. Os metadados de controle de acesso são vitais para assegurar os interesses legais e de negócio da organização. Eles asseguram o gerenciamento adequado da confidencialidade e privacidade de informações pessoais e outras restrições de uso e segurança identificadas nos documentos de arquivo de uma organização.

Com a mudança da estrutura, função ou processo de trabalho de uma organização, ocorre uma alteração nas responsabilidades para as atividades do negócio. A implementação de metadados de documentos de arquivo padronizados e estruturados ajudam a identificar os documentos de arquivo apropriados para serem movidos em todos os sistemas e limites organizacionais. Esses metadados padronizados também ajudam a extrair documentos de arquivo de um sistema e importá-los para outros sistemas, preservando a ligação contextual, independentemente de qualquer sistema de negócio particular.

Os documentos de arquivo digitais dependem de metadados para sua existência, gestão e uso futuro. As características dos documentos de arquivo (ISO 15489-1:2001, 7.2), em todos os formatos, são definidas nos metadados dos documentos de arquivo. Assegurar a preservação dos documentos de arquivo, incluindo seus metadados, em formato eletrônico, exige conformidade com padrões de metadados estáveis, estruturados e bem definidos, para sua sustentabilidade em atualizações ou mudanças de software. A preservação dos documentos de arquivo digitais, enquanto eles são necessários, pode envolver uma série de estratégias (ver Seção 11), mas todas as estratégias dependem da existência de metadados padronizados para gerenciar documentos de arquivo.

Muitas das informações necessárias para documentar e descrever os documentos de arquivo e seu contexto em sistemas arquivísticos podem ser obtidas a partir dos metadados em software de documentos de arquivo. Recomenda-se que esta interligação seja tão perfeita quanto possível. Capturar metadados para gerenciar documentos de arquivo de acordo com um esquema padronizado torna esse processo mais fácil de implementar.

Conforme indicado na ISO 23081-1:2006, Seção 6, recomenda-se que estratégias de metadados sejam tratadas como parte integrante, ou explicitamente relacionada, a uma estratégia mais ampla de gerenciamento de informações e documentos de arquivo da organização. A este respeito, convém que seja elaborada uma política clara relacionada aos metadados, seja como uma área de política autônoma separada, ligada ao modelo de políticas de documentos de arquivo existente ou mesmo como uma parte integrante e distinta das políticas de documentos de arquivo organizacionais existentes.

Em ambos os casos, recomenda-se que as organizações identifiquem e atribuam funções e responsabilidades, incluindo responsabilidades para assegurar a qualidade de metadados; identifiquem os requisitos de confiabilidade, acessibilidade, recuperação, manutenção e segurança de metadados; selecionem padrões ou esquema de metadados aplicáveis; identifiquem e estabeleçam regras para a aplicação de esquemas de codificação de metadados (vocabulários controlados, esquemas de sintaxe); determinem normas técnicas a serem utilizadas na implementação; identifiquem como a política de metadados para gerenciar documentos de arquivo se relaciona a outras políticas ou esquemas de metadados que estão em uso na organização; identifiquem critérios e metodologias de avaliação para determinar a conformidade e a eficácia da política; desenvolvam estratégias de monitoramento e avaliação para acompanhar a política; determinem como a política será mantida atualizada, de acordo com as atividades do negócio.

Recomenda-se que qualquer política permita diferentes níveis de implementação. Convém identificar o nível e a forma a serem alcançados. Recomenda-se que uma política também identifique as áreas mais críticas e requeira atenção especial em relação às estratégias de implementação de metadados, como sustentabilidade, acessibilidade, identificação de documentos de arquivo vitais, preservação e análise de risco.

Em conformidade com o modelo estabelecido de funções e responsabilidades para os documentos de arquivo (ver ISO 15489-1:2001, 6.3), recomenda-se que a responsabilidade pelo desenvolvimento, implementação e manutenção de modelos de metadados para gerenciamento de documento de arquivo seja atribuída aos arquivistas, em associação com outros funcionários da organização, como da área de tecnologia da informação ou profissionais da área jurídica, conforme apropriado. Esta responsabilidade inclui analisar as necessidades da organização de metadados para gerenciar documentos de arquivo baseados nos requisitos do negócio; monitorar e analisar a evolução da organização em relação aos metadados, em particular os requisitos para o gerenciamento dos documentos de arquivo; assegurar que os esquemas de metadados para gerenciamento de documentos de arquivo sejam desenvolvidos de acordo com as melhores práticas e com as normas aplicáveis da indústria; desenvolver o modelo de metadados para gerenciar documentos de arquivo, incluindo o esquema de metadados, e as normas organizacionais relacionados e as regras para utilizar o modelo; identificar ou desenvolver esquemas de codificação de metadados apropriados, refinamentos de elementos e qualificadores, por exemplo, plano de classificação; manter o esquema de metadados atualizado e alinhado com as necessidades do negócio; gerenciar o esquema de metadados também como um documento de arquivo; manter a qualidade geral dos metadados definidos por máquina e por seres humanos, particularmente no que se refere à sua precisão, integridade, autenticidade, usabilidade e confiabilidade; coordenar as questões de implementação entre os documentos de arquivo e o pessoal de tecnologia da informação; realizar a coordenação com os proprietários dos sistemas de negócio para assegurar a integração dos metadados de gerenciamento de documentos de arquivo, conforme apropriado; realizar a coordenação com autoridades/processos arquivísticos para assegurar a interoperabilidade entre o software de documentos de arquivo e os ambientes de arquivamento de documentos de arquivo que possuem valor permanente; elaborar um programa e rotina de treinamento dos agentes sobre o uso e a aplicação do esquema de metadados; comunicar sobre o esquema de metadados dentro da organização.

Os sistemas desenvolvidos para gerenciar documentos de arquivo requerem metadados que apoiam processos de arquivos ou mesmo de gerenciamento de documentos de arquivo. Um dos principais usos dos metadados é representar entidades a partir do ambiente de negócio no sistema de negócio. As entidades apoiam a perspectiva dos documentos de arquivo para entender o ambiente de negócio, mas eles não são em si mesmos objetos sempre tangíveis.

A figura abaixo especifica o modelo conceitual de entidade e apoia qualquer número de entidades, mas de particular importância são as seguintes: os próprios documentos de arquivo sejam um documento individual ou agregações de documentos de arquivo (conhecidos como entidades de registro); as pessoas ou estruturas de organização no ambiente de negócio (conhecidas como entidades agente); transações de negócio (conhecidas como entidades de negócio); as regras que regem a transação e documentação de negócio (conhecidas como entidades competentes).

Não se espera que todas as implementações desta parte da NBR ISO 23081 implementem diretamente todas as classes de entidades descritas. Tais decisões dependerão da capacidade de assegurar ligações contínuas descritas entre as várias classes de entidades. As incertezas sobre a persistência podem levar a implementações centradas em documentos de arquivo, onde metadados sobre outras classes de entidades são trazidos explicitamente para dentro dos limites da própria classe de documento de arquivo.

Tais implementações achatam o modelo de entidade e incluem a informação sobre as classes faltantes de entidades dentro de outras entidades. Por exemplo, uma implementação que não contenha classes de agentes, determinações ou de negócio pode incluir as informações necessárias para a implementação da classe de documento de arquivo.

As orientações para a gestão da segurança da informação

Conheça as orientações sobre os requisitos para um sistema de gestão de segurança da informação (SGSI) conforme especificado na NBR ISO/IEC 27001.

A NBR ISO/IEC 27003 de 04/2020 – Tecnologia da informação — Técnicas de segurança — Sistemas de gestão da segurança da informação — Orientações fornece explicações e orientações sobre a NBR ISO/IEC 27001:2013.

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

Como entender as necessidades e expectativas das partes interessadas?

Quais as orientações para estabelecer o escopo de um SGSI?

Por que a liderança e o comprometimento são essenciais para um sistema de gestão de segurança da informação (SGSI) efetivo?

Quais as orientações para uma política de segurança?

Este documento fornece orientações sobre os requisitos para um sistema de gestão de segurança da informação (SGSI) conforme especificado na NBR ISO/IEC 27001 e fornece recomendações (‘Convém que’), possibilidades (‘pode’) e permissões (‘pode’) em relação a eles. Não é a intenção de este documento fornecer orientações gerais sobre todos os aspectos de segurança da informação. As Seções 4 a 10 deste documento espelham a estrutura da NBR ISO/IEC 27001:2013. Este documento não adiciona quaisquer novos requisitos para um SGSI e seus termos e definições relacionados.

Convém que as organizações consultem a ABNT NBR ISO/IEC 27001 e a ISO/IEC 27000 para requisitos e definições. As organizações implementando um SGSI não estão sob qualquer obrigação de observar as orientações deste documento. Um SGSI enfatiza a importância das seguintes fases: compreender as necessidades da organização e a necessidade de estabelecer política de segurança da informação e objetivos de segurança da informação; avaliar a organização, e os riscos relacionados à segurança da informação; implementar e operar processos, controles e outras medidas de segurança da informação para o tratamento de riscos; fiscalizar e analisar o desempenho e a eficácia do SGSI; e praticar a melhoria contínua.

Um SGSI, semelhante a qualquer outro tipo de sistema de gestão, inclui os seguintes componentes principais: política; pessoal com responsabilidades definidas; processos de gestão relacionados com o estabelecimento de política; provisão de conscientização e competência; planejamento; implementação; operação; avaliação de desempenho; análise crítica pela direção; melhoria; e informação documentada. Um SGSI tem componentes principais adicionais, como: avaliação de riscos de segurança da informação; e tratamento de riscos de segurança da informação, incluindo a determinação e a implementação de controles.

Este documento é genérico e se destina a ser aplicável a todas as organizações, independentemente do tipo, tamanho ou natureza. Convém que a organização identifique que parte destas orientações se aplica a ela de acordo com o seu contexto organizacional específico (ver NBR ISO/IEC 27001:2013, Seção 4). Por exemplo, algumas orientações podem ser mais adequadas para grandes organizações, mas para organizações muito pequenas (por exemplo, com menos de dez pessoas) algumas das orientações podem ser desnecessárias ou inadequadas.

As descrições das Seções 4 a 10 são estruturadas da seguinte forma: Atividade necessária: apresenta as principais atividades necessárias na subseção correspondente da NBR ISO/IEC 27001; Explicação: explica o que os requisitos da NBR ISO/IEC 27001 demandam; Orientações: fornece informações mais detalhadas ou de apoio para implementar a “atividade necessária”, incluindo exemplos para implementação; e Outras informações: fornece mais informações que podem ser consideradas.

As NBR ISO/IEC 27003, NBR ISO/IEC 27004 e NBR ISO/IEC 27005 formam um conjunto de documentos que dão suporte e orientações para a NBR ISO/IEC 27001:2013. Dentre esses documentos, a NBR ISO/IEC 27003 é um documento básico e abrangente que fornece orientações para todos os requisitos da NBR ISO/IEC 27001, mas não tem descrições detalhadas sobre “monitoramento, medição, análise e avaliação” e gestão de riscos de segurança da informação.

As NBR ISO/IEC 27004 e ABNT NBR ISO/IEC 27005 focam em conteúdos específicos e fornecem orientações mais detalhadas sobre “monitoramento, medição, análise e avaliação” e gestão de riscos de segurança da informação. Existem várias referências explícitas à informação documentada na NBR ISO/IEC 27001. No entanto, uma organização pode reter informações documentadas adicionais que considera necessárias para a eficácia do seu sistema de gestão como parte de sua resposta à NBR ISO/IEC 27001:2013, 7.5.1 b).

Nestes casos, este documento usa a frase “Informação documentada sobre esta atividade e o seu resultado é mandatório somente na forma e na medida em que a organização determina como necessário para a eficácia do seu sistema de gestão (ver NBR ISO/IEC 27001:2013, 7.5.1 b)”. A organização determina questões externas e internas relevantes para sua finalidade e que afetam a sua habilidade para obter o (s) resultado (s) pretendido (s) do sistema de gestão da segurança da informação (SGSI).

Como uma função integrante do SGSI, a organização analisa constantemente a si própria e o mundo que a rodeia. Esta análise está preocupada com questões internas e externas que de alguma maneira afetam a segurança da informação e como a segurança da informação pode ser gerida, e que são relevantes para os objetivos da organização. A análise destas questões tem três objetivos: entender o contexto a fim de decidir o escopo do SGSI; analisar o contexto para determinar riscos e oportunidades; e assegurar que o SGSI esteja adaptado para mudar questões externas e internas.

Questões externas são aquelas que estão fora do controle da organização. Isso é frequentemente referido como o ambiente da organização. A análise deste ambiente pode incluir os seguintes aspectos: social e cultural; político, jurídico, normativo e regulatório; financeiro e macroeconômico; tecnológico; natural; e competitivo. Estes aspectos do ambiente da organização apresentam continuamente questões que afetam a segurança da informação e como a segurança da informação pode ser gerida. As questões externas relevantes dependem da situação e das prioridades específicas da organização.

Por exemplo, questões externas para uma organização específica podem incluir: implicações legais do uso de um serviço de TI terceirizado (aspecto legal); características da natureza em termos de possibilidade de desastres como incêndios, inundações e terremotos (aspecto natural); avanços técnicos de ferramentas de invasão e uso de criptografia (aspecto tecnológico); e demanda geral por serviços da organização (aspectos sociais, culturais ou financeiros).

Questões internas estão sujeitas ao controle da organização. A análise das questões internas pode incluir os seguintes aspectos: cultura da organização; políticas, objetivos e estratégias para alcançá-los; governança, estrutura organizacional, funções e responsabilidades; normas, diretrizes e modelos adotados pela organização; relações contratuais que podem afetar diretamente os processos da organização incluídos no escopo do SGSI; processos e procedimentos; capacidades, em termos de recursos e de conhecimento (por exemplo, capital, tempo, pessoas, processos, sistemas e tecnologias); infraestrutura e ambiente físicos; sistemas de informação, fluxos de informação e processos de tomada de decisão (ambos formal e informal); e auditorias anteriores ou resultados de análise de riscos anteriores. Os resultados desta atividade são usados em 4.3, 6.1 e 9.3.

Com base em um entendimento da finalidade da organização (por exemplo, se referindo a sua declaração de missão ou plano de negócios), bem como o(s) resultado(s) pretendido(s) do SGSI da organização, convém para a organização: analisar criticamente o ambiente externo para identificar questões externas relevantes; e analisar criticamente os aspectos internos para identificar questões internas relevantes. A fim de identificar questões relevantes, a seguinte pergunta pode ser feita: Como uma determinada categoria de questões (ver 4.1 a) a t)) afetam os objetivos de segurança da informação?

Três exemplos de questões internas servem como uma ilustração de: EXEMPLO 1 Sobre a governança e a estrutura organizacional (ver 4.1 m)): Ao estabelecer um SGSI, convém considerar a governança e as estruturas organizacionais já existentes. Como um exemplo, a organização pode modelar a estrutura do seu SGSI com base na estrutura de outros sistemas de gestão existentes, e pode combinar funções comuns, como análise crítica pela direção e auditoria.

EXEMPLO 2 Sobre a política, objetivos e estratégias (ver 4.1 l)): Uma análise das políticas, objetivos e estratégias existentes pode indicar o que a organização pretende obter e como os objetivos de segurança da informação podem ser alinhados com os objetivos de negócio para assegurar resultados bem-sucedidos. EXEMPLO 3 Sobre os sistemas de informação e fluxos de informação (ver 4.1 s)): Quando determinar questões internas, convém à organização identificar, a um nível de detalhe suficiente, os fluxos de informação entre os seus vários sistemas de informação.

Como tanto as questões internas e externas irão mudar ao longo do tempo, convém serem analisadas criticamente, de forma periódica, as questões e a sua influência sobre o escopo, restrições e requisitos do SGSI. Informação documentada sobre esta atividade e os seus resultados é mandatória somente na forma e na medida em que a organização determina como necessária para a eficácia do seu sistema de gestão (ver NBR ISO/IEC 27001:2013, 7.5.1 b).

Na ISO/IEC 27000, a definição de “organização” possui uma nota que diz: “O conceito de organização inclui, mas não se limita a, comerciante independente, companhia, corporação, firma, empresa, autoridade, parceria, caridade ou instituição, ou parte ou combinação destas, incorporadas ou não, pública ou privada”. Alguns destes exemplos são entidades jurídicas em sua totalidade, enquanto outros não são.

BS ISO 19626-1: as plataformas de comunicação confiáveis para documentos eletrônicos

Essa norma internacional, editada pelo BSI em 2020, define os requisitos sobre a comunicação confiável em considerações legais, administrativas e técnicas. Este documento mostra uma arquitetura do sistema trusted communication platforms (TCP) para garantir uma comunicação confiável e promover os serviços confiáveis, fornecendo evidências de comunicação confiáveis como prova.

A BS ISO 19626-1:2020 – Processes, data elements and documents in commerce, industry and administration. Trusted communication platforms for electronic documents. Fundamentals define os requisitos sobre a comunicação confiável em considerações legais, administrativas e técnicas. Este documento mostra uma arquitetura do sistema trusted communication platforms (TCP) para garantir uma comunicação confiável e promover os serviços confiáveis, fornecendo evidências de comunicação confiáveis como prova.

Este documento enfoca o TCP na exibição da 7ª camada do aplicativo do Modelo de Referência OSI (Open Systems Interconnection). As audiências são os decisores políticos para a inovação de TI, como desmaterialização, especialistas jurídicos em atividades eletrônicas, planejadores de TI para janelas únicas e transações seguras, provedores de serviços de TI relacionados a redes e livros distribuídos, auditores de sistemas confiáveis, partes interessadas em comunicação confiável e assim por diante.

Conteúdo da norma

Prefácio

Introdução

1 Escopo

2 Referências normativas

3 Termos e definições

4 Comunicação confiável

4.1 Visão geral

4.2 Considerações legais

4.3 Requisitos administrativos

5 Plataforma de comunicação confiável (TCP)

5.1 Visão geral

5.2 Arquitetura do sistema TCP

5.3 Requisitos de sistema do TCP

5.4 Regras do sistema TCP

5.5 Comunicação TCP

6 Evidência de comunicação confiável (TCE)

6.1 geração TCE

6.2 Procedimento probatório

6.3 Custódia de TCE

Anexo A Modelo de referência de comunicação confiável

Anexo B TCP principal: qualidade e gestão de riscos

B.1 Geral

B.2 Gerenciamento de riscos

B.3 Gerenciamento de qualidade

B.4 Monitoramento e auditoria

Ligação de comunicação dos anexos C dos TCPSPs (um exemplo)

Bibliografia

Em meio ao grande fluxo de abertura e integração na economia mundial, as TIC (tecnologia da informação e comunicação) são usadas como um meio de inovação em produtividade e conectividade. Como a cadeia de valor de produtos e serviços é ampliada globalmente, as colaborações comerciais precisam que as comunicações eletrônicas sejam seguras em um ambiente aberto e distribuído.

Nesse sentido, os documentos eletrônicos são solicitados como prova das comunicações comerciais, enquanto isso é necessário. No entanto, pode ser difícil reconhecer documentos eletrônicos como a fonte original. Existem casos em que muitos processos dependem apenas de documentos em papel, mesmo que os documentos eletrônicos sejam amplamente implementados nos processos de negócios.

Porém, a realidade é que, mesmo que os documentos eletrônicos sejam adequadamente comunicados nas transações comerciais, a saída final dos dados pode estar em papel e armazenada na forma de cópias impressas, como evidência legal por um período de longo prazo. Assim, esse ambiente coexistente de documentos eletrônicos e documentos em papel causa quebra da cadeia de valor, resultando em produtividade lenta, ineficiência, aumento de custos e compensação do benefício obtido das TIC, a fim de melhorar essas situações.

Uma solução desmaterializante deve atender a considerações legais sobre documentos comunicados eletronicamente. Essa solução não é fácil, porque a própria comunicação eletrônica inclui as incertezas decorrentes de falhas na rede e o próprio documento eletrônico é insuficiente para proteger a integridade durante seu ciclo de vida. Enquanto isso, o problema devido ao repúdio, divulgação inadvertida ou adulteração foi considerado muito sensível para finalizar a solução de desmaterialização relacionada a transações comerciais, bem como diversos serviços governamentais, porque pode ser envolvido em disputas ou conflitos legais.

Este documento se concentra em como aprimorar a comunicação confiável em um ambiente aberto e distribuído. A comunicação confiável significa que a comunicação eletrônica pode garantir a integridade e o repúdio às transações eletrônicas por terceiros confiáveis, de forma desmaterializada, sob a orientação da United Nations Commission on International trade Law (Uncitral). Para esse ambiente aberto e distribuído, inicialmente, ele deve ser capaz de minimizar algumas dificuldades inatas em torno da desmaterialização.

Para resolver essas dificuldades, este documento aborda uma solução, formando um relacionamento confiável e orientado a terceiros de confiança mútua entre as partes interessadas e implementando uma plataforma compartilhada que seja responsável e rastreável. Em detalhe, uma plataforma de comunicação confiável precisa ser capaz de manter as evidências sobre documentos comunicados eletronicamente de maneira confiável e confiável. Para isso, é necessária uma nova abordagem, pois o ambiente de TIC existente possui alguns limites para a comunicação confiável em alguns aspectos. Embora uma transação EDI (troca eletrônica de dados) possa fornecer evidências legais sobre documentos eletrônicos intercambiados de acordo com a regra de sintaxe EDI, ela tem limitações permitidas apenas para usuários fechados da rede EDI e processos predefinidos de semântica EDI.

No caso da internet, não importa quais transações comerciais sejam comunicadas com segurança, é difícil reconhecer a legitimidade das comunicações realizadas em outros sistemas de autenticação. Nesse sentido, este documento estabelece um processo de desmaterialização refinado, permitido no ambiente de TIC aberto e distribuído, aplicável à comunicação confiável, como comércio eletrônico, administração eletrônica, comércio eletrônico e assim por diante.

A tecnologia de segurança foi usada como uma tecnologia central para documentos eletrônicos protegidos. No entanto, não basta manter a desmaterialização de documentos eletrônicos, pois é fácil quebrar a integridade no aspecto do período de segurança válido. Nesse sentido, este documento apresenta uma nova maneira que pode garantir a autenticidade da evidência de comunicação confiável por um longo período de tempo necessário como evidência legal.

Os serviços de TI em um ambiente aberto não podem identificar facilmente a originalidade das comunicações eletrônicas, contabilizando o contexto da comunicação, que é originador, destinatário (s), tempo de comunicação e assim por diante. Em relação às incertezas, como modificação, falsidade ou descoramento de documentos comunicados eletronicamente, não é fácil identificar e perguntar de quem é a responsabilidade entre várias partes interessadas.

Além disso, se a blockchain deve ser aplicada em toda a cadeia de suprimentos, é necessária uma comunicação confiável para uma conectividade perfeita. Nesse sentido, este documento pode tornar as transações comerciais responsáveis e confiáveis e, consequentemente, promover serviços de TI confiáveis. Uma evidência gerada por meio de uma plataforma de comunicação confiável pode explicar a verdade das atividades de comunicação e instalações de serviços de comunicação confiáveis.

A gestão dos serviços em tecnologia da informação

Um sistema de gestão de serviço (SGS) pode ser usado para um cliente procurando serviços e requerendo garantia relacionada à qualidade destes serviços; um cliente requerendo uma abordagem consistente para o ciclo de vida do serviço por todos os seus provedores de serviço, incluindo aqueles em uma cadeia de fornecimento; uma organização que queira demonstrar sua habilidade para o planejamento, desenho, transição, entrega e melhoria de serviços; uma organização para monitorar, medir e analisar criticamente seu SGS e os serviços; uma organização para melhorar o planejamento, o desenho, a transição, a entrega e a melhoria de serviços através da implementação e operação efetivas de um SGS; uma organização ou outra parte executando avaliações da conformidade utilizando os requisitos especificados neste documento; e um provedor de treinamento ou consultoria em gestão de serviço.

A NBR ISO/IEC 20000-1 de 03/2020 – Tecnologia da informação – Gestão de serviços – Parte 1: Requisitos do sistema de gestão de serviços especifica requisitos para uma organização estabelecer, implementar, manter e melhorar continuamente um sistema de gestão de serviço (SGS). Os requisitos especificados neste documento incluem o planejamento, desenho, transição, entrega e melhorias de serviços para atender aos requisitos de serviço e entregar valor.

Este documento pode ser usado para um cliente procurando serviços e requerendo garantia relacionada à qualidade destes serviços; um cliente requerendo uma abordagem consistente para o ciclo de vida do serviço por todos os seus provedores de serviço, incluindo aqueles em uma cadeia de fornecimento; uma organização que queira demonstrar sua habilidade para o planejamento, desenho, transição, entrega e melhoria de serviços; uma organização para monitorar, medir e analisar criticamente seu SGS e os serviços; uma organização para melhorar o planejamento, o desenho, a transição, a entrega e a melhoria de serviços através da implementação e operação efetivas de um SGS; uma organização ou outra parte executando avaliações da conformidade utilizando os requisitos especificados neste documento; e um provedor de treinamento ou consultoria em gestão de serviço.

O termo serviço, conforme utilizado neste documento, refere-se ao serviço ou serviços no escopo do SGS. O termo organização, conforme utilizado neste documento, refere-se à organização no escopo do SGS que gerencia e entrega serviços aos clientes. Uma organização ou parte de uma organização que gerencia e entrega serviço ou serviços a clientes internos ou externos pode ser conhecida como um provedor de serviço. A organização no escopo do SGS pode ser parte de uma organização maior, por exemplo, um departamento de uma grande corporação.

Todos os requisitos especificados neste documento são genéricos e destinam-se a serem aplicáveis a todas as organizações, independentemente do seu tipo, do porte ou da natureza dos serviços entregues. A exclusão de qualquer dos requisitos nas Seções 4 a 10 não é aceitável quando uma organização declara conformidade com este documento, independentemente da natureza da organização.

A conformidade com os requisitos especificados neste documento pode ser demonstrada pela própria organização, apresentando evidência de atendimento a estes requisitos. A própria organização demonstra conformidade com as Seções 4 e 5. No entanto, a organização pode ser apoiada por outras partes. Por exemplo, outra parte pode conduzir auditorias internas em nome da organização ou apoiar a preparação do SGS.

Alternativamente, uma organização pode mostrar evidência de que detém a responsabilidade pelos requisitos especificados neste documento e demonstrar controle quando outras partes estão envolvidas em atender aos requisitos nas Seções 6 a 10 (ver 8.2.3). Por exemplo, a organização pode demonstrar evidência de controles para outras partes que estejam fornecendo componentes de serviço de infraestrutura ou operando a central de serviço, incluindo o processo de gerenciamento de incidente.

A organização não pode demonstrar conformidade com os requisitos especificados neste documento se outras partes são usadas para fornecer ou operar todos os serviços, componentes de serviço ou processos no escopo do SGS. O escopo deste documento exclui a especificação para produtos ou ferramentas. Porém, este documento pode ser usado para auxiliar no desenvolvimento ou aquisição de produtos ou ferramentas que apoiam a operação de um SGS.

Acesse algumas perguntas relacionadas a essa norma GRATUITAMENTE no Target Genius Respostas Diretas:

Quais devem ser as ações para abordar riscos e oportunidades?

Como deve ser executado o planejamento do sistema de gestão de serviço?

Como fazer o controle da informação documentada?

Como deve ser feito o planejamento e controle operacional?

Este documento foi preparado para especificar requisitos para estabelecer, implementar, manter e melhorar continuamente um sistema de gestão de serviço (SGS). Um SGS apoia a gestão do ciclo de vida do serviço, incluindo o planejamento, desenho, mudança, entrega e a melhoria dos serviços,

os quais preenchem os requisitos acordados e entregam valor aos clientes, usuários e à organização que está entregando os serviços. A adoção de um SGS é uma decisão estratégica para uma organização e é influenciada pelos objetivos da organização, o corpo governante, outras partes envolvidas no ciclo de vida do serviço e a necessidade por serviços efetivos e resilientes.

A implementação e a operação de um SGS proveem visibilidade contínua, controle dos serviços e melhoria contínua, resultando em grande efetividade e eficiência. A melhoria para a gestão de serviço é aplicável ao SGS e aos serviços. Este documento é intencionalmente independente de orientação específica. A organização pode usar uma combinação de estruturas geralmente aceitas e sua própria experiencia.

Os requisitos especificados neste documento estão alinhados com metodologias de melhoria comumente utilizadas. Ferramentas apropriadas para gestão de serviço podem ser usadas para apoiar o SGS. A ISO/IEC 20000-2 fornece orientações sobre a aplicação de sistemas de gestão de serviço incluindo exemplos de como atender aos requisitos especificados neste documento. A ISO/IEC 20000-10 fornece informação sobre todas as partes da série ISO/IEC 20000, benefícios, mitos e outras normas relacionadas.

A ISO/IEC 20000-10 lista os termos e definições incluídos neste documento em acréscimo aos termos não usados neste documento, mas em outras partes da série ISO/IEC 20000-1. A estrutura de seções (por exemplo, sequência da seção), termos em 3.1 e muitos dos requisitos são retirados do Anexo SL do Suplemento ISO Consolidado às Diretivas ISO/IEC Parte 1, conhecido como a estrutura comum de alto nível (HLS) para normas de sistema de gestão. A adoção da HLS permite à organização, alinhar ou integrar múltiplas normas de sistema de gestão. Por exemplo, um SGS pode ser integrado com um sistema de gestão da qualidade com base na NBR ISO 9001 ou um sistema de gestão da segurança da informação com base na NBR ISO/IEC 27001.

A figura abaixo ilustra um SGS apresentando o conteúdo das seções deste documento. Isto não representa uma estrutura hierárquica, sequência ou níveis de autoridade. Não há nenhum requisito neste documento para sua estrutura e terminologia a ser aplicado ao SGS de uma organização. Não há nenhum requisito para os termos utilizados por uma organização a serem substituídos pelos termos utilizados neste documento.

As organizações podem escolher utilizar termos que combinem com suas operações. A estrutura de seções destina-se a prover uma apresentação coerente de requisitos, ao invés de um modelo para documentar políticas, objetivos e processos de uma organização. Cada organização pode escolher como combinar os requisitos em seus processos. O relacionamento entre cada organização e seus clientes, usuários e outras partes interessadas influencia em como os processos são implementados. No entanto, um SGS conforme desenhado por uma organização, não pode excluir quaisquer dos requisitos especificados neste documento.

A organização deve determinar questões externas e internas que sejam pertinentes ao seu propósito e que afetem sua capacidade de alcançar o(s) resultado (s) pretendido (s) de seu SGS. A palavra questão neste contexto pode se referir a fatores que tenham um impacto positivo ou negativo. Estes são fatores importantes para a organização no contexto de sua capacidade de entregar serviços com a qualidade acordada com seus clientes.

A organização deve determinar as partes interessadas que sejam pertinentes para o SGS e para os serviços; os requisitos pertinentes destas partes interessadas. Os requisitos das partes interessadas podem incluir serviço, desempenho, requisitos legais e regulatórios e obrigações contratuais relacionadas ao SGS e a os serviços.

A Alta Direção deve demonstrar liderança e comprometimento com relação ao SGS, através de assegurar que a política de gestão de serviço e os objetivos de gestão de serviço sejam estabelecidos e sejam compatíveis com o direcionamento estratégico da organização; assegurar que o plano de gestão de serviço seja criado, implementado e mantido com o intuito de apoiar a política de gestão de serviço, o atingimento dos objetivos de gestão de serviço e o atendimento aos requisitos de serviço; assegurar que níveis apropriados de autoridade sejam designados para a tomada de decisões relacionadas ao SGS e aos serviços; assegurar que o que se define como valor para a organização e seus clientes seja determinado; assegurar que exista o controle sobre outras partes envolvidas no ciclo de vida do serviço; assegurar a integração dos requisitos do SGS com os processos de negócios da organização; assegurar que os recursos necessários para a SGS e para os serviços estejam disponíveis; comunicar a importância de uma gestão de serviço eficaz, alcançando os objetivos de gestão de serviço, entregando valor e conformidade com os requisitos do SGS; assegurar que o SGS alcance seu (s) resultado (s) pretendido (s); dirigir e apoiar pessoas a contribuir para a eficácia do SGS e dos serviços; promover a melhoria contínua do SGS e dos serviços; e apoiar outros papéis de gestão pertinentes a demonstrar sua liderança conforme ela se aplica às áreas sob sua responsabilidade.

A organização deve determinar a competência necessária de pessoas que realizem o trabalho sob seu controle, que afete seu desempenho e a eficácia do SGS e dos serviços; assegurar que essas pessoas sejam competentes com base em educação, treinamento, ou experiência apropriados. Onde aplicável, deve-se tomar ações para adquirir a competência necessária e avaliar a eficácia das ações tomadas, além de reter informação documentada apropriada como evidência de competência.

As ações aplicáveis podem incluir, por exemplo, a provisão de treinamento, a mentoria ou a mudança de atribuições de pessoas empregadas no momento ou empregar ou contratar pessoas competentes. Pessoas que realizam o trabalho sob o controle da organização devem estar conscientes da política de gestão de serviço; dos objetivos da gestão de serviço; dos serviços pertinentes ao seu trabalho; da sua contribuição para a eficácia do SGS, incluindo os benefícios do desempenho melhorado; as implicações de não estar em conformidade com os requisitos do SGS.

A organização deve determinar as comunicações internas e externas relevantes para o SGS e os serviços, incluindo: sobre o que ela irá comunicar; quando comunicar; com quem se comunicar; como comunicar; quem vai ser responsável pela comunicação. Incidentes de segurança da informação devem ser registrados e classificados; priorizados levando em consideração o risco relacionado à segurança da informação; escalados caso necessário; resolvidos; fechados. A organização deve analisar os incidentes de segurança da informação por tipo, volume e impacto ao SGS, serviços e partes interessadas. Incidentes de segurança da informação devem ser reportados e analisados criticamente para identificar oportunidades de melhoria.

A salvaguarda da privacidade dos dados pessoais

A estrutura de privacidade é destinada a ajudar as organizações a estabelecerem os seus requisitos de salvaguarda de DP dentro de um ambiente TIC: especificando uma terminologia comum de privacidade; especificando os atores e os seus papéis no tratamento de DP; descrevendo os requisitos de salvaguarda da privacidade; e referenciando princípios conhecidos de privacidade.

A NBR ISO/IEC 29100 de 03/2020 – Tecnologia da informação — Técnicas de segurança — Estrutura de Privacidade fornece uma estrutura de privacidade que especifica uma terminologia comum de privacidade; especifica os atores e os seus papéis no tratamento de dados pessoais (DP); descreve considerações de salvaguarda de privacidade; e fornece referências para princípios conhecidos de privacidade para tecnologia da informação. É aplicável às pessoas naturais e organizações envolvidas na especificação, aquisição, arquitetura, concepção, desenvolvimento, teste, manutenção, administração e operação de sistemas de tecnologia da informação e comunicação ou serviços em que controles de privacidade são necessários para o tratamento de DP.

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

Quais são os exemplos de atributos que podem ser usados para identificar pessoas naturais?

O que são dados pseudonimizados?

Quais são os fatores que influenciam a gestão de riscos de privacidade?

Como estabelecer as políticas de privacidade?

Essa norma fornece uma estrutura de alto nível para a proteção de dados pessoais (DP) dentro de sistemas de tecnologia da informação e de comunicação (TIC). Ela é geral em sua natureza e coloca os aspectos organizacionais, técnicos e processuais em uma estrutura abrangente de privacidade.

A estrutura de privacidade é destinada a ajudar as organizações a estabelecerem os seus requisitos de salvaguarda de DP dentro de um ambiente TIC: especificando uma terminologia comum de privacidade; especificando os atores e os seus papéis no tratamento de DP; descrevendo os requisitos de salvaguarda da privacidade; e referenciando princípios conhecidos de privacidade. Em algumas jurisdições, as referências deste documento aos requisitos de salvaguarda da privacidade podem ser entendidas como complementares aos requisitos legais para proteção de DP.

Devido ao crescente número de tecnologias que processam DP, é importante ter normas de segurança da informação que forneçam uma base de entendimento comum para a proteção dos DP. Esta norma destina-se a aprimorar as normas existentes de segurança, adicionando um foco pertinente para o tratamento de DP. O uso comercial e o valor crescentes dos DP, o compartilhamento de DP entre diferentes jurisdições legais e a complexidade cada vez maior dos sistemas de TIC podem tornar difícil para uma organização assegurar a privacidade e alcançar compliance com as várias leis aplicáveis.

Porém, as partes interessadas na privacidade podem prevenir o surgimento da incerteza e da desconfiança, lidando adequadamente com as questões de privacidade e evitando casos de uso dos DP. O uso dessa norma irá: ajudar no desenho, implementação, operação e manutenção de sistemas de TIC que tratem e protejam DP; incentivar soluções inovadoras que possibilitem a proteção de DP dentro dos sistemas de TIC; e melhorar os programas de privacidade nas organizações por meio do uso das melhores práticas. A estrutura de privacidade fornecida nessa norma pode servir como base para iniciativas adicionais de padronização da privacidade, como: uma arquitetura técnica de referência; implementação e uso de tecnologias específicas de privacidade e a gestão geral de privacidade; controles de privacidade para processos de dados terceirizados; avaliações de risco de privacidade; ou especificações de engenharia específicas.

Algumas jurisdições podem exigir compliance com um ou mais documentos referenciados no ISO/IEC JTC 1/SC27 WG5 Standing Documento 2 (WG 5 SD2) – Official Privacy Documents References ou com outras leis e regulamentações aplicáveis, porém, este documento não se destina a ser um modelo de política global, nem uma estrutura legislativa. Os seguintes componentes estão relacionados à privacidade e ao tratamento de DP em sistemas de TIC e compõem a estrutura de privacidade descrita nesta norma: atores e papéis; interações; reconhecimento de DP; requisitos de salvaguarda de privacidade; políticas de privacidade; e controles de privacidade.

Para o desenvolvimento desta estrutura de privacidade, conceitos, definições e recomendações de outras fontes oficiais foram levados em consideração. Estas fontes podem ser encontradas no ISO/IEC JTC 1/SC27 WG5 Documento Padrão 2 (WG 5 SD2) – Referência Oficial de Documentos de Privacidade. Para os efeitos dessa norma, é importante identificar os atores envolvidos no tratamento de DP. Existem quatro tipo de atores que podem estar envolvidos no tratamento de DP: titulares de DP, controladores de DP, operadores de DP e terceiros.

Os titulares de DP fornecem os seus DP para tratamento aos controladores de DP e operadores de DP e, quando não for previsto pela lei aplicável, eles dão consentimento e determinam as suas preferências de privacidade sobre como convém que os seus DP sejam tratados. Os titulares de DP podem incluir, por exemplo, um funcionário listado no sistema de recursos humanos de uma empresa, o consumidor mencionado em um relatório de crédito e um paciente listado em um prontuário eletrônico.

Nem sempre é necessário que a respectiva pessoa natural seja identificada diretamente pelo nome para ser considerada um titular de DP. Se a pessoa natural a quem os DP se relacionam puder ser identificada indiretamente (por exemplo, por meio de um identificador de conta, número de documento de identidade ou mesmo pela combinação de atributos disponíveis), ela será considerada o titular dos DP para esse conjunto de DP.

Um controlador de DP determina o porquê (propósito) e o como (meios) o tratamento de DP ocorrerá. Convém que o controlador de DP assegure a aderência aos princípios de privacidade desta estrutura durante o tratamento de DP sob seu controle (por exemplo, implementando os controles de privacidade necessários). Pode existir mais de um controlador de DP para o mesmo conjunto de DP ou conjunto de operações de dados realizados sobre os DP (para o mesmo ou diferentes propósitos legítimos).

Nestes casos, diferentes controladores de DP devem trabalhar conjuntamente e estabelecer os arranjos necessários para garantir que os princípios de privacidade sejam aderentes durante o tratamento de DP. Um controlador de DP também pode decidir ter todas ou parte das operações de tratamento realizadas por uma parte interessada diferente em seu nome.

Convém que os controladores de DP avaliem cuidadosamente se estão processando DP sensíveis e que implementem controles de privacidade e segurança razoáveis e apropriados com base nos requisitos estabelecidos na jurisdição pertinente, bem como em possíveis efeitos adversos para os titulares de DP, identificados durante uma avaliação de risco de privacidade. Um operador de DP realiza o tratamento de DP em nome do controlador de DP, agindo em nome dele ou conforme as instruções do controlador de DP, observando os requisitos de privacidade estipulados e implementando os controles de privacidade correspondentes. Em algumas jurisdições o operador de DP é vinculado por um contrato legal.

Um terceiro pode receber DP de um controlador de DP ou de um operador de DP. O terceiro não trata DP em nome do controlador de DP. Geralmente, o terceiro se tornará um controlador de DP por si próprio, quando receber os DP em questão. Os atores identificados na Seção anterior podem interagir entre si de várias maneiras.

Em relação aos fluxos possíveis de DP entre o titular de DP, o controlador de DP e o operador de DP, os seguintes cenários podem ser identificados: o titular de DP fornece DP para um controlador de DP (por exemplo, ao se registrar em um serviço prestado pelo controlador de DP); o controlador de DP fornece DP para um operador de DP, que realiza o tratamento de DP em nome do controlador de DP (por exemplo, como parte de um contrato de terceirização); o titular de DP fornece DP para um operador de DP, que realiza o tratamento de DP em nome do controlador de DP; o controlador de DP fornece ao titular de DP os DP que são relacionados ao titular de DP (por exemplo, respondendo a uma requisição feita pelo titular de DP); o operador de DP fornece DP ao titular de DP (por exemplo, conforme indicado pelo controlador de DP); e o operador de DP fornece DP para o controlador de DP (por exemplo, depois de ter realizado o serviço para o qual foi designado).

Os papéis do titular de DP, controlador de DP, operador de DP e um terceiro neste cenário são ilustrados na tabela abaixo. É necessário distinguir entre operadores de DP e terceiros, porque o controle legal dos DP permanece com o controlador de DP original quando ele é enviado para o operador de DP, enquanto um terceiro pode se tornar um controlador de DP por si só, uma vez que recebeu os DP em questão. Por exemplo, quando um terceiro toma a decisão de transferir DP que recebeu de um controlador de DP para outra parte, ele agirá como um controlador de DP por si só e, portanto, não será mais considerado um terceiro.

No que diz respeito aos possíveis fluxos de DP entre os controladores e operadores de DP, por um lado, e terceiros, por outro, os seguintes cenários podem ser identificados: o controlador de DP fornece DP para um terceiro (por exemplo, no contexto de um acordo comercial); e o operador de DP fornece DP para um terceiro (por exemplo, conforme indicado pelo controlador de DP). Os papéis do controlador de DP e de um terceiro nestes cenários também estão ilustrados na tabela abaixo.

Para determinar se convém que uma pessoa natural seja ou não considerada identificável, vários fatores precisam ser levados em consideração. Em particular, convém que sejam levados em consideração todos os meios que possam ser razoavelmente usados pela parte interessada na privacidade que detém os dados ou por qualquer outra parte para identificar esta pessoa natural. Convém que os sistemas de TIC suportem mecanismos que conscientizem o titular de DP de tais informações e forneçam à pessoa natural os controles apropriados sobre o compartilhamento destas informações.

As subseções a seguir fornecem esclarecimentos adicionais sobre como determinar se convém que um titular de DP seja ou não considerado identificável. Em certos casos, a identificabilidade do titular de DP pode ser muito clara (por exemplo, quando a informação contém ou está associada a um identificador que é usado para se referir ou se comunicar com o titular de DP).

As informações podem ser consideradas DP pelo menos nos seguintes casos: se elas contêm ou estão associadas a um identificador que se refere a uma pessoa natural (por exemplo, ao número do CPF); se elas contêm ou estão associadas a um identificador que pode ser relacionado a uma pessoa natural (por exemplo, um número de passaporte, uma conta bancária); se elas contêm ou estão associadas a um identificador que pode ser utilizado para estabelecer uma comunicação com uma pessoa natural identificada (por exemplo, uma localização geográfica precisa, um número de telefone); ou se elas contêm uma referência que liga os dados a qualquer dos identificadores acima.

As informações não precisam necessariamente estar associadas a um identificador para serem consideradas DP. As informações também serão consideradas DP se contiverem ou estiverem associadas a uma característica que distingue uma pessoa natural de outras pessoas naturais (por exemplo, dados biométricos). Qualquer atributo que assuma um valor que identifique exclusivamente um titular de DP é considerado uma característica distintiva.

Observar que o fato de uma determinada característica distinguir uma pessoa natural de outras pessoas naturais podem mudar, dependendo do contexto de uso. Por exemplo, embora o sobrenome de uma pessoa natural possa ser insuficiente para identificar esta pessoa em escala global, muitas vezes será suficiente para distinguir uma pessoa natural em escala de empresa. Adicionalmente, existem também situações nas quais uma pessoa natural é identificável mesmo se não existir atributo simples que a identifique unicamente.

Este é o caso onde uma combinação de vários atributos tomados juntos distingue esta pessoa natural de outras pessoas naturais. Se a pessoa natural for ou não identificável com base em uma combinação de atributos, isto pode também ser dependente de um domínio específico. Por exemplo, a combinação dos atributos “feminino”, “45” e “advogado”, pode ser suficiente para identificar uma pessoa natural em uma companhia específica, porém será sempre insuficiente para identificar uma pessoa natural fora da companhia.

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.