O chamado de suporte: um número conhecido em um estudo externo
Ilustração fictícia: O Hospital A recebe um estudo de ultrassom da Clínica B em mídia de transferência aprovada. Seu Patient ID é 940218, um número já utilizado localmente. O sistema de arquivamento e comunicação de imagens (PACS) receptor apresenta uma possível correspondência de paciente. A equipe de engenharia clínica é questionada se o carrinho está com defeito ou se o estudo pode ser anexado a esse prontuário.
O número por si só não pode resolver nenhuma das duas questões. A Clínica B pode tê-lo atribuído a uma pessoa diferente, ou a mesma pessoa pode ter identificadores em ambas as organizações. Um cabeçalho também pode conter uma seleção de cadastro incorreta. Uma correspondência não resolvida deve permanecer no fluxo de trabalho de exceções aprovado da instituição enquanto os responsáveis pelo PACS e pela identidade do paciente verificam os registros de origem. Não presuma que todos os produtos de importação exibam o mesmo aviso ou forneçam uma função de isolamento.
Uma sobreposição vincula registros de pessoas diferentes; um registro fragmentado separa registros pertencentes a uma mesma pessoa. O artigo sobre maturidade da identidade do paciente de Dennison discute ambos os riscos em empresas consolidadas de diagnóstico por imagem. Uma verificação do emissor aborda o escopo do identificador, mas não pode, por si só, comprovar que a aquisição original foi atribuída ao paciente correto. 5
O que um DICOM Patient ID comprova — e o que o Padrão nunca promete?
O padrão Digital Imaging and Communications in Medicine (DICOM) separa identificadores de paciente, pedido e estudo. O Study Instance UID (0020,000D) é um identificador único de estudo; o Patient ID (0010,0020) é o identificador de paciente utilizado por uma autoridade de atribuição. Um identificador de estudo formatado corretamente não valida a vinculação ao paciente. 2 3
No DICOM PS3.3, Seção C.7.1.1 (Módulo do Paciente, Tabela C.7-1), o atributo Patient ID (0010,0020) é definido simplesmente como: 2
Patient ID (0010,0020): Identificador principal do Paciente.— DICOM PS3.3 Seção C.7.1.1 Tabela C.7-1
O Patient ID é Tipo 2 no Módulo do Paciente citado: o elemento é obrigatório, mas um valor desconhecido pode estar vazio. Sua definição não lhe confere unicidade universal. A questão prática é qual esquema de identificação atribuiu o valor e se o sistema receptor possui um mapeamento verificado para esse esquema. Um identificador ausente ou temporário requer o processo local de reconciliação, em vez da presunção de que o estudo seja inválido. 1 2
Por exemplo, os fictícios Hospital A e Clínica B podem, cada um, usar 100452. Uma sequência de caracteres compartilhada não demonstra se seus registros descrevem a mesma pessoa. Não deduza o esquema emissor apenas pelo comprimento do número, pontuação, um prefixo familiar ou pelo endpoint de transporte. Mantenha a autoridade e sua procedência junto com o número durante a revisão.
O que o emissor e seus qualificadores estabelecem
O Issuer of Patient ID identifica a autoridade que emitiu o número do paciente. O domínio de identidade é o esquema emissor; o identificador do paciente é interpretado dentro desse domínio. O DICOM PS3.3, Seção 10.15, define a macro do emissor e sua relação com o tipo de dados CX do HL7 v2 utilizado no PID-3. As edições atual e 2019e citadas contêm esse mecanismo. 1 4
A autoridade pode ser um sistema, organização, agência ou departamento. O atributo issuer corresponde ao componente de namespace local da autoridade atribuidora do HL7. Um valor isolado como RIS só tem significado dentro de uma configuração acordada: organizações não relacionadas podem usar o mesmo rótulo. Por outro lado, rótulos históricos e atuais de emissor podem ser aliases aprovados para um domínio. Compare os mapeamentos de autoridade configurados, não apenas a igualdade textual. 1 5
A sequência opcional Issuer of Patient ID Qualifiers Sequence (0010,0024) fornece mais contexto sobre a autoridade ou o identificador. É permitido apenas um item. Seus componentes incluem: 1
- Universal Entity ID
(0040,0032): um identificador universal ou único para a autoridade atribuidora. Se tanto ele quanto o Issuer of Patient ID estiverem presentes, eles deverão identificar a mesma autoridade. - Universal Entity ID Type
(0040,0033): obrigatório quando o Universal Entity ID está presente; identifica o formato utilizado. Verifique os termos definidos pela norma e o registro local de autoridades. - Identifier Type Code
(0040,0035): descreve o tipo de identificador usando a Tabela 0203 do HL7. Isso é diferente de Type of Patient ID(0010,0022), cujos termos definidos incluem TEXT, RFID e BARCODE. - Assigning Facility Sequence
(0040,0036), Assigning Jurisdiction Code Sequence(0040,0039)e Assigning Agency or Department Code Sequence(0040,003A): fornecem contexto de localização, jurisdição ou agência. Eles não autorizam o leitor a presumir uma autoridade ausente.
O Tipo 3 descreve a presença opcional; não é uma medição de com que frequência um campo é preenchido. O modelo PIM3 descreve sistemas de Nível 0 como assumindo um único domínio de identidade em vez de qualificar identificadores de pacientes entre domínios. Combinar domínios sem controles adequados pode criar colisões; isso é um risco, não um resultado inevitável de toda importação. 1 5
Por que a Norma descontinuou um atributo por falta de emissor?
O Patient Module também fornece a Other Patient IDs Sequence (0010,1002) para identificadores alternativos. Isso é relevante quando uma mesma pessoa possui identificadores em várias organizações: um segundo número não é automaticamente uma segunda pessoa. 2
A tabela atual explica que essa sequência substituiu o atributo descontinuado Other Patient IDs (0010,1000), cujos valores individuais não tinham emissor. Isso dá suporte à retenção do contexto de emissor para cada identificador alternativo. Não documenta uma taxa de colisão nem torna obrigatórios os valores opcionais de emissor. 2
Cada item de identificador alternativo inclui um Patient ID e um Type of Patient ID e incorpora a macro de emissor. Os atributos de emissor nessa macro permanecem opcionais. Verifique o escopo de cada item em vez de presumir que todo número alternativo herda a autoridade do nível superior. 1 2
Para uma equipe de manutenção, a consequência prática é uma questão de evidência: o registro recebido preserva a autoridade para o identificador que está sendo comparado? Uma sequência capaz de transportar informações de emissor não é prova de que o remetente a tenha preenchido ou de que o receptor a utilize corretamente.
| Tag / atributo | Tipo no módulo citado | O que descreve | Limite para correspondência |
|---|---|---|---|
| (0010,0020) ID do Paciente | 2 | Identificador de paciente em um esquema de atribuição. | A correspondência isolada do número não estabelece uma pessoa. |
| (0010,0021) Emissor do ID do Paciente | 3 | Autoridade que atribuiu o identificador do paciente. | Um rótulo local de emissor pode necessitar de um mapeamento verificado de namespace. |
| (0010,0024) Qualificadores do emissor | 3 | Delimitação adicional de autoridade e identificador; um item permitido. | Opcional; compare os valores dos qualificadores onde fornecidos. |
| (0010,0010) Nome do paciente | 2 | Nome do paciente. | A grafia, a codificação e o registro podem diferir; nomes não são exclusivos. |
| (0010,0030) Data de nascimento do paciente | 2 | Data de nascimento do paciente. | Pode estar em branco ou incorreto; a concordância constitui evidência de suporte. |
| (0010,0040) Sexo do paciente | 2 | Sexo do paciente identificado. | Não é um identificador exclusivo; uma discrepância exige revisão. |
| (0008,0050) Número de acesso | 2 | Identificador da solicitação de serviço de imagem (Imaging Service Request). | A procedência do pedido pode apoiar a revisão, mas não pode se sobrepor à incerteza de identidade. |
| (0008,0051) Emissor do número de acesso | 3 | Autoridade que emitiu o número de acesso; um item permitido. | Delimita o escopo de um número de acesso, não de um ID de paciente; não é um contêiner para múltiplos números de acesso. |
| (0020,000D) UID da Instância do Estudo | 1 | Identificador exclusivo do estudo. | Um Study UID correspondente não comprova a igualdade da instância nem a vinculação correta ao paciente. |
Fonte: DICOM PS3.3 2026d, Tabelas C.7-1, C.7-3 e 10-18 (fontes 1–3); os limites de correspondência são interpretação editorial.
Por que a identidade do pedido não é a identidade do paciente? Números de acesso e seu próprio emissor
Uma correspondência de número de acesso pode ajudar a equipe autorizada a localizar um pedido de origem. Ela não pode se sobrepor a um conflito nas evidências do paciente. A mesma cadeia de caracteres de número de acesso pode ocorrer em esquemas de emissão não relacionados, assim como ocorre com números de pacientes. Mantenha a autoridade do pedido separada da autoridade que atribuiu o ID do paciente.
O DICOM PS3.3, Tabela C.7-3, define o Accession Number como o identificador do sistema de informação departamental para uma Solicitação de Serviço de Imagem. Sua sequência opcional Issuer of Accession Number Sequence delimita o escopo desse identificador de solicitação. 3
A distinção é prática: um paciente pode ter vários pedidos, e uma instituição receptora pode criar seu próprio pedido para um estudo externo. Preserve a conexão com o pedido externo por meio do fluxo de trabalho de importação aprovado. Uma sequência de emissor de número de acesso com item único não armazena dois números de acesso. 3 12
Nosso guia de estados da worklist MPPS aborda o status da etapa do procedimento e seus vínculos com pedidos. Este artigo se limita às evidências de identidade do paciente: nem um estado de fluxo de trabalho concluído, nem um número de acesso aparentemente exclusivo comprovam que um estudo externo pertença a um prontuário local.
A reconciliação de importação pode legitimamente utilizar informações locais do paciente e do procedimento obtidas por meio de worklists ou consultas demográficas. O IHE descreve isso como um fluxo de trabalho de integração, com gerenciamento de exceções para seleções incorretas. Não confunda uma opção de importação que resolve a numeração de pedidos com uma correspondência verificada de paciente. Siga o fluxo de trabalho documentado do receptor em vez de uma regra universal sobre o que um assistente deve fazer. 12
O que cadeias reais de ultrassom fazem com emissores? Evidências de declarações de conformidade
Estes exemplos descrevem diferentes papéis na cadeia: modalidades criam instâncias, um broker de worklist fornece informações e um arquivo pode suplementar atributos. Eles não são um ranking, uma matriz de compatibilidade nem evidência de que uma instalação específica se comporte conforme testada. Os limites das linhas importam tanto quanto o comportamento declarado.
- GE Venue 40 v2.xx, DOC0837847 Rev 2, Tabela 3-3, p.24: O Patient ID é obtido a partir de entrada na interface do usuário (UI) ou de worklist; o Issuer of Patient ID está documentado como originado de worklist. O documento não lista uma fonte manual para o emissor. Inspecione uma exportação de teste permitida antes de concluir o que está ausente em uma compilação instalada específica. O PDF possui direitos autorais de 2011; seu caminho de hospedagem contém datas de 2018, que não constituem uma data de lançamento de software. 7
- ExactVu 2.9/3.0, Rev 1.3, Seção 4.2.2.3.1.3: a tabela de instâncias criadas indica o Patient ID como proveniente da lista de trabalho da modalidade (MWL) quando disponível e, caso contrário, gerado; a linha do emissor está marcada como gerada. O documento explica que os valores gerados podem provir de entrada do usuário, detalhes de aquisição ou uma cadeia de caracteres aleatória; ele não especifica o valor do emissor nem se os dispositivos compartilham um namespace. Na tabela, isso não se limita a casos de entrada manual. 8
- Sectra Connectivity Hub 9.5.0.2442, agosto de 2025, Seção 3.2.1, p. 14: a tabela de lista de trabalho mapeia o Patient ID a partir de HL7 PID-3.1 e sua autoridade emissora a partir de PID-3.4. Verifique tanto os valores recebidos quanto o mapeamento configurado no broker; a linha não comprova o que um scanner downstream armazena em última análise. 9
- Philips Lumify R5.0, HSDP-1299212, Tabela 40, p. 38: o Patient Module armazenado documenta o Patient ID como proveniente de lista de trabalho, entrada do usuário ou geração pelo sistema. Não lista o Issuer of Patient ID nessa tabela. Esta é uma limitação da documentação, não uma evidência de configuração de emissor para AE remoto nem da frequência com que exames em dispositivos portáteis omitem emissores. 10
- dcm4che Archive 5, versão da documentação 5.35, Configuração do dispositivo: a configuração de emissor fornece valores padrão e pode ser utilizada por coerções de atributos configuradas no archive para complementar a autoridade emissora ausente no recebimento e em outras transações. A complementação depende do acionamento dessa configuração; não se trata de um comportamento incondicional de todos os estudos recebidos. Um valor fornecido pelo receptor não deve ser confundido com uma autoridade verificada no remetente. 11
Para cada transferência, distinga os valores presentes na exportação daqueles adicionados posteriormente. Solicite a versão exata da modalidade, as versões do broker e do archive, e as seções de conformidade aplicáveis. Um emissor genérico ou um padrão do receptor necessita de uma interpretação documentada. Um campo preenchido não é necessariamente uma evidência mais forte do que um campo ausente se ninguém puder explicar de onde veio seu valor.
| Produto / função | Origem documentada do Patient ID | Evidência do emissor | Próxima verificação |
|---|---|---|---|
| Venue 40 v2.xx / modalidade | Interface do usuário ou lista de trabalho | Tabela 3-3: proveniente da lista de trabalho | Compare exportações de teste manuais e de lista de trabalho para a versão instalada. |
| ExactVu 2.9/3.0 / modalidade | MWL quando presente; caso contrário, gerado | Seção 4.2.2.3.1.3: gerado | Determine o valor real do emissor e o escopo da autoridade; não deduza um algoritmo. |
| Sectra Hub 9.5 / intermediador | HL7 PID-3.1 | Mapeamento da lista de trabalho a partir do PID-3.4 | Compare o feed de identidade recebido, a resposta da lista de trabalho e a instância armazenada. |
| Lumify R5.0 / modalidade | Lista de trabalho, usuário ou gerado pelo sistema | Não listado na tabela citada do Patient Module armazenado | Obtenha confirmação específica do produto; nenhuma declaração de emissor para AE remoto estabelecida. |
| dcm4che Archive 5 / receptor | Depende do objeto recebido/criado | Padrão configurável utilizado por meio de coerções de atributos | Verifique as regras habilitadas e os valores antes/depois; não presuma a procedência do remetente. |
Fonte: Fontes 7–11, com âncoras de documento/revisão e de seção acima. Estas linhas são exemplos de implementação, não um levantamento exaustivo do parque de equipamentos.
A sequência de verificação pré-importação: ler, comparar, classificar, encaminhar
Utilize esta sequência de evidências em quatro etapas dentro do processo de importação aprovado pela instituição. Trata-se de uma síntese editorial das normas e princípios de informática citados, não de um algoritmo validado de correspondência de pacientes. O operador que autoriza a correspondência e os critérios para fazê-lo são definidos pela política institucional. 5 6 12
Etapa 1: Leia o bloco de identidade recebido sem alterá-lo. Um membro autorizado da equipe deve utilizar um visualizador somente leitura aprovado ou uma ferramenta de metadados no ambiente seguro da instituição. Mantenha protegidos os arquivos originais recebidos. Registre se a exportação é uma transferência clínica original, uma cópia desidentificada ou um backup restaurado; valores de identidade ausentes têm implicações distintas em cada caso.
- ID do paciente
(0010,0020) - Emissor do ID do paciente
(0010,0021)e Sequência de qualificadores(0010,0024) - Nome do paciente
(0010,0010) - Data de nascimento do paciente
(0010,0030)e Sexo do paciente(0010,0040) - Número de acesso
(0008,0050)e Emissor do número de acesso(0008,0051) - Study Instance UID
(0020,000D), Series Instance UID(0020,000E)e Service-Object Pair (SOP) Instance UID(0008,0018)para localizar os objetos afetados; o SOP Class UID(0008,0016)identifica o tipo de objeto. 3 14 15 - Fabricante e Nome do modelo do fabricante
(0008,0070 / 0008,1090), além da versão do software instalado obtida no registro do equipamento.
Etapa 2: Compare domínios de identidade e procedência. Por meio de sistemas autorizados, compare os valores recebidos com o registro local proposto e com as informações cadastrais confirmadas da organização remetente. Verifique o mapeamento de autoridade configurado, em vez de tratar uma string de emissor como autenticação.
- O emissor parece coincidir: verifique os qualificadores e o registro de autoridades. Duas instituições podem usar um rótulo genérico, como
RIS. Mesmo um domínio reconhecido e dados demográficos correspondentes não excluem uma seleção original do paciente errado. - O emissor é diferente: verifique se os valores identificam domínios diferentes ou aliases aprovados para um mesmo domínio. Os registros podem descrever pessoas diferentes ou a mesma pessoa com identificadores entre domínios. Não force uma correspondência; solicite à equipe de identidade que verifique a relação.
- O emissor está ausente ou com valor padrão: estabeleça quem forneceu o ID do paciente e se um gateway ou receptor adicionou uma autoridade. Não preencha a lacuna com o nome de uma clínica deduzido do rótulo de um disco. Um campo opcional ausente não é, por si só, uma falha do equipamento.
Etapa 3: Compare dados demográficos e descreva a incerteza. Nome, data de nascimento e sexo podem expor uma divergência, mas não são identificadores únicos nem somas de verificação à prova de erros. Nosso guia de conjuntos de caracteres para nomes de pacientes aborda problemas de representação. Datas de nascimento e valores de sexo também podem estar ausentes, digitados incorretamente ou corrigidos; uma divergência não comprova que se trata de duas pessoas diferentes.
| Evidência observada | O que permanece incerto | Rota dentro do fluxo de trabalho aprovado |
|---|---|---|
| Mesmo ID, mesmo emissor reconhecido, dados demográficos correspondentes | A seleção correta na aquisição e a vinculação local aprovada ainda precisam de confirmação. | Continue o procedimento de verificação da instituição; nenhuma aprovação automática a partir desta tabela. |
| Mesmo ID, emissores diferentes, dados demográficos conflitantes | Possível colisão, erro de cadastro ou vinculação incorreta. | Mantenha a correspondência proposta em espera; a equipe de identidade verifica os registros de origem antes da resolução. |
| Mesmo ID, emissores diferentes, dados demográficos correspondentes | Possível mesma pessoa entre domínios; coincidência demográfica também é possível. | Responsáveis pelo PACS/MPI verificam a referência cruzada; não mescle apenas com base na concordância. |
| Mesmo ID, emissor ausente, dados demográficos conflitantes | Domínio desconhecido; a divergência pode ter várias causas. | Utilize a fila de exceções aprovada; não invente um emissor nem um novo registro de paciente. |
| Mesmo ID, emissor ausente, dados demográficos correspondentes | O escopo ainda é desconhecido, apesar da aparente concordância. | Confirme a autoridade emissora e o registro de origem por meio de canais autorizados. |
| IDs diferentes, dados demográficos correspondentes | Uma pessoa pode ter vários identificadores; duas pessoas podem compartilhar dados demográficos. | A equipe de identidade verifica se há um mapeamento entre domínios existente antes da importação. |
| Emissor genérico ou padrão fornecido pelo receptor | A autoridade exibida pode não ser a autoridade original. | Revise os mapeamentos/coerções configurados e os valores recebidos versus armazenados. |
| ID ou emissor gerado localmente | A geração não comprova invalidade nem escopo de autoridade exclusivo. | Confirme o namespace local documentado e a rota de reconciliação aprovada. |
Fonte: Síntese editorial das fontes 1–6 e 11–12. A conduta clínica permanece específica da instituição e do receptor.
Etapa 4: Encaminhar e registrar a decisão. As equipes autorizadas de PACS e de identidade do paciente decidem se devem vincular, reconciliar, criar um registro ou recusar a importação de acordo com a política local. Preserve a identidade original recebida e uma auditoria dos mapeamentos aprovados. Se um exame já puder estar no prontuário incorreto, escale por meio do procedimento de segurança do paciente e de correção de arquivo da instituição; importações repetidas ou exclusões informais podem dificultar a reconstituição das evidências.
Cinco casos fictícios e as evidências a serem escaladas
Os cinco casos fictícios a seguir ilustram onde a sequência de evidências altera a transferência de responsabilidade. Eles não são relatos de incidentes reais com pacientes nem de resultados de testes de produtos e não fornecem instruções de configuração de importação ou de banco de dados.
Caso 1: Duas unidades atribuem 100452. O Hospital A adquire a Clínica B. Cada um possui um registro com o número 100452. A equipe de migração deve verificar a autoridade original da Clínica B e o mapeamento local aprovado antes de transferir os estudos. Apenas adicionar prefixos aos números pode separar colisões sem vincular os registros da mesma pessoa entre domínios. Encarregue os responsáveis pela identidade corporativa de projetar e validar a migração, incluindo a revisão de exceções. 5 6
Caso 2: Um carrinho cria um ID local. Um exame sem worklist usa o identificador fictício GEN-004. Esse identificador pode ser legítimo em seu esquema local sem ser um número de prontuário médico (MRN) corporativo. O guia de entrada do Sonosite PX aborda a configuração de ID gerado de uma plataforma; ele não estabelece o formato de saída deste exemplo. A equipe de identidade receptora deve verificar a relação de registro antes de atribuir as imagens a um prontuário hospitalar.
Caso 3: Estudos retornam após o reparo. Um backup autorizado é reimportado após a manutenção. Compare os identificadores de estudo, série e Instância SOP retidos e as evidências do paciente com o registro do arquivo. A correspondência do Study UID por si só não comprova instâncias idênticas nem descarta um erro de vinculação de paciente. Preserve o backup enquanto o responsável pelo arquivo investiga. O guia de manuseio de dados pré-reparo define as decisões de preservação e sanitização; este caso não autoriza a exclusão nem alterações de UID.
Caso 4: A unidade receptora cria um novo pedido. O Hospital B atribui um accession local, enquanto a imagem recebida contém o accession do Hospital A. Registre ambos no sistema de reconciliação aprovado com suas respectivas autoridades. O Issuer of Accession Number Sequence delimita um accession e permite um único item; adicionar outro emissor ali não é uma forma de preservar dois pedidos. As equipes responsáveis pelo PACS e pelo sistema de informação radiológica (RIS) devem usar seu mapeamento de externo para local suportado. 3 12
Caso 5: Um número conhecido com uma data de nascimento diferente. A mídia externa contém o ID de paciente fictício 55412 e nenhum emissor. O registro local candidato tem o mesmo nome, mas uma data de nascimento diferente. Retenha a correspondência proposta e obtenha informações de registro de origem verificadas. A discrepância pode ser uma colisão ou um erro de registro. Não deduza uma nova pessoa, não crie um registro de convidado nem insira um emissor inventado com base no rótulo da mídia.
Quando a identidade é incerta: dados demográficos, proveniência e as paradas obrigatórias
O limite do suporte técnico é preservar evidências e evitar alterações não autorizadas em registros clínicos. Quando os médicos precisarem com urgência de um estudo externo incerto, use o fluxo de verificação urgente de identidade e escalonamento clínico da instituição. Um artigo não pode substituir esse procedimento. Estes três limites se aplicam à investigação de suporte:
- Não altere tags de identidade para fazer um arquivo se encaixar. Mantenha o original recebido e utilize inspeção aprovada somente leitura. Alterações descontroladas podem obscurecer a proveniência e criar uma correspondência falsa. Preserve os arquivos originais recebidos e a auditoria de qualquer reconciliação autorizada.
- Não aceite uma correspondência proposta sem as evidências exigidas. A reconciliação de importação autorizada pode legitimamente mapear identificadores e dados demográficos. O IHE especifica fluxos de trabalho para isso; a distinção é um mapeamento verificado e documentado versus uma sobrescrita improvisada. 12
- Não execute mesclagens de pacientes a partir de um guia de serviço. Os recursos de reconciliação, mesclagem e recuperação dependem do sistema e da política institucional. Deixe-os para os profissionais autorizados de PACS/RIS e de governança de identidade; não há nenhuma alegação universal aqui de que toda mesclagem seja irreversível.
Quando os valores diferirem entre a cópia de envio e o objeto armazenado, identifique o primeiro ponto de alteração: exportação da modalidade, gateway de transferência, aplicativo de importação ou sistema de arquivamento. Solicite aos responsáveis as evidências autorizadas de antes e depois e as regras de mapeamento habilitadas. O guia de rede e E/S DICOM aborda a investigação de transporte em separado. Uma discrepância de identidade por si só não é evidência para solicitar uma placa de reposição.
Quem é responsável pela reconciliação de identidade e pelo referenciamento cruzado?
A resolução definitiva cabe às equipes autorizadas de informática em imagem e de identidade de pacientes da instituição, que podem incluir o Gerenciamento de Informações de Saúde (HIM) e um Master Patient Index (MPI) ou serviço corporativo de MPI. Os cargos e as permissões variam. Os engenheiros clínicos fornecem evidências do equipamento e da transferência; os responsáveis pela identidade verificam a pessoa e o relacionamento com o registro local.
O perfil IHE Patient Identifier Cross-referencing (PIX) oferece suporte ao compartilhamento de informações de identidade do paciente e à recuperação de identificadores com referência cruzada entre domínios. Ele define transações, e não as políticas ou o algoritmo de correspondência da instituição. Ele também não corrige dados demográficos de origem deficientes automaticamente. 6
Para uma pessoa fictícia com o identificador do Hospital A 100452 e o identificador da Clínica B 98765, uma referência cruzada aprovada pode representar esse relacionamento mantendo os domínios distintos. A presença de um serviço PIX não comprova que esse relacionamento tenha sido verificado, que um visualizador específico o consulte ou que o cabeçalho de cada imagem permaneça inalterado. Essas são questões de implementação. 6
O IHE também especifica a reconciliação de importação utilizando informações locais do paciente e do procedimento. Seu Radiology Technical Framework Rev 23.0 retém o texto original descontinuado do IRWF e direciona novas implementações para o IRWF.b, listado separadamente para Trial Implementation. Estas são referências de integração para as equipes responsáveis, não uma receita de configuração. Verifique novamente o fluxo de trabalho suportado pelos produtos instalados antes de decidir como os identificadores externos serão representados. 12
Compile um pacote de escalonamento direcionado. Cabeçalhos identificáveis, registros de log e capturas de tela devem permanecer dentro do canal de suporte seguro e aprovado da instituição. Compartilhe o mínimo de informações necessárias com a equipe autorizada de PACS/RIS e de gerenciamento de identidades. Consultas de serviços externos devem utilizar evidências técnicas com dados ocultados; não envie prontuários de pacientes por meio de um formulário de contato geral no site.
- Valores de identidade recebidos e candidatos locais, incluindo qualificadores de emissor e quais valores estão ausentes, mantidos no registro autorizado da instituição.
- Modelo do sistema emissor e versão de software instalada; método de exportação, estado da lista de trabalho (worklist)/entrada manual e a seção de conformidade aplicável.
- Caminho de transferência e versão do software receptor, com qualquer regra padrão de emissor ou de coerção conhecida e a etapa na qual os valores foram alterados.
- Identificadores de estudo, série e SOP Instance afetados e referências de pedidos, tratados como informações potencialmente identificáveis.
- A correspondência proposta, a discrepância não resolvida, o status de preservação do arquivo original e a equipe designada responsável pela resolução.
| Artefato | Registrar de forma segura | O que ajuda a comprovar | Limitação |
|---|---|---|---|
| Bloco de identidade recebido | ID do paciente, emissor/qualificadores, nome, data de nascimento e sexo | Valores conforme recebidos em uma etapa conhecida | Pode já ter sido alterado em etapas anteriores (upstream); não é prova da identidade correta na aquisição. |
| Registro local candidato | Valores locais de identidade e mapeamento de autoridade registrada | Comparação com o prontuário proposto | A concordância demográfica por si só não é prova de identidade. |
| Contexto do produto e do fluxo de trabalho | Modelo, compilação de software (build), rota manual/MWL, referências de conformidade | Comportamento esperado para a versão documentada | Uma declaração de conformidade não comprova a configuração real nem uma falha. |
| Evidências da transferência antes/depois | Amostras/logs aprovados do transmissor, intermediador (broker) e receptor | Onde uma autoridade foi adicionada, removida ou mapeada | Não deduza alterações não documentadas a partir de um único cabeçalho final. |
| Referências de estudo e instância | UIDs de estudo/série/SOP Instance e referências de pedidos | Localiza objetos afetados e possível sobreposição de reenvio | Um Study UID por si só não resolve a identidade do paciente nem a equivalência de instâncias. |
Fonte: Lista de verificação editorial sugerida com base nas fontes 1–3, 5–12; não constitui um protocolo de engenharia clínica obrigatório ou validado.
| Campo de decisão | Registrar antes da resolução |
|---|---|
| Escopo de identidade | ID recebido + autoridade/qualificadores; fonte de autoridade confirmada; registro local proposto. |
| Incerteza | Discrepância demográfica ou de domínio exata; confirmação de origem ainda necessária. |
| Integridade da transferência | Original retido; etapas de exportação à importação comparadas; regras de mapeamento/padrão identificadas. |
| Responsável pela resolução | Equipe autorizada designada; desfecho aprovado de vinculação/reconciliação/novo registro/recusa e justificativa. |
| Verificação após aprovação | Confirmar a associação pretendida de prontuário e estudo no fluxo de trabalho compatível do receptor; reter referência de auditoria. |
Fonte: Planilha editorial sugerida; não constitui um algoritmo de correspondência de pacientes ou permissão para importação.
O que o recall histórico do LOGIQ e comprova?
A vinculação de imagens ao paciente errado é um risco documentado em ultrassom. O registro da FDA referente ao recall Z-1849-2013 descreve a condição de software do GE LOGIQ e na qual as imagens podiam ser vinculadas ao identificador de outro paciente. O registro identifica o projeto de software como a causa. 13
O registro da FDA afirma que a empresa planejou uma atualização de software para os sistemas afetados, com solicitações de serviço acompanhadas até a conclusão. Ele registra o início em 9 de novembro de 2012 e o encerramento em 15 de setembro de 2014. Não estabelece que colisões de emissores causaram o defeito, não documenta uma lesão resultante nem comprova que as verificações deste artigo evitariam essa falha de software. 13
A lição é limitada, mas útil: um identificador pode parecer plausível enquanto sua vinculação à imagem está incorreta. Preserve as evidências e solicite às equipes clínica e de produto adequadas que investiguem a suspeita de um evento de paciente incorreto. A verificação do escopo do emissor é uma parte da análise de importação, não um substituto para a correção pelo fabricante ou para a gestão de incidentes da instituição.
Para a decisão separada de manutenção entre hardware e software, consulte o guia de sintomas do GE LOGIQ e. Não generalize este recall histórico para outros produtos GE, para todas as unidades do LOGIQ e ou para softwares atuais de identidade de pacientes.
Onde a Rongtao se enquadra — e onde não se enquadra
A Rongtao Medical fornece reparo independente de placas de ultrassom multimarcas, serviços em transdutores, peças testadas e suporte técnico. Os nomes dos equipamentos atendidos identificam a cobertura dos serviços, não uma autorização do OEM. Para essa decisão, a contribuição útil do serviço é uma transferência técnica que ajuda a manter a investigação de identidade separada de um diagnóstico de hardware não comprovado.
- Onde a Rongtao se enquadra: análise do modelo do equipamento, da etiqueta da peça e dos sintomas para um possível caso de manutenção de hardware de ultrassom após a instituição ter avaliado o problema de integração de dados. O reparo de placas normalmente leva 5–8 dias úteis e a garantia é normalmente de 90 dias; a aplicabilidade e os termos finais dependem do item e do serviço e devem ser confirmados.
- Onde as equipes da instituição lideram: decisão sobre a identidade do paciente, mapeamento de identificadores externos, autorização de importações, correção de registros do arquivo e realização de mesclagens. A Rongtao não substitui o fornecedor do PACS/RIS nem a governança de identidade do paciente da instituição.
Para uma consulta sobre hardware, entre em contato com a Rongtao Medical informando o OEM, modelo exato do sistema e versão do software, part number do fabricante se conhecido, fotos nítidas das etiquetas e de ambos os lados de qualquer placa acessível com segurança, sintoma/mensagem de erro, histórico de manutenção, quantidade e país de destino. O acesso às placas cabe a pessoal qualificado. Oculte nomes, IDs de pacientes, identificadores de estudos e outros dados de pacientes em logs e imagens externos; mantenha o pacote de escalonamento com dados identificáveis com as equipes autorizadas da instituição.
Perguntas frequentes
O Patient ID do DICOM é único entre hospitais?
Não presuma isso. Sua autoridade emissora fornece o escopo. Um número familiar em um estudo externo requer verificações de autoridade e procedência antes que o fluxo de trabalho local de correspondência de pacientes possa aprová-lo. 1 2
O que é o Issuer of Patient ID e por que ele pode estar vazio?
Ele identifica a autoridade emissora. É opcional no Patient Module citado. A versão do produto, o fluxo de trabalho de aquisição e a configuração intermediária determinam se e como ele é preenchido; a ausência por si só não diagnostica uma falha. 1 7 8 11
Dois estudos têm o mesmo Patient ID, mas nomes diferentes — o que devo fazer?
Retenha a correspondência proposta e encaminhe a discrepância para a equipe autorizada de identidade. Pessoas diferentes, correções de cadastro e erros de representação de nomes são possíveis. Não crie um novo registro de paciente nem adivinhe um emissor apenas com base nessa discrepância.
O número de acesso pode ajudar na investigação de identidade?
Ele pode ajudar a localizar a procedência verificada do pedido, mas identifica uma Solicitação de Serviço de Imagem. Ele não pode, por si só, resolver evidências conflitantes sobre o paciente ou autorizar uma sobrescrita. 3
Um fluxo de trabalho de importação aprovado pode alterar identificadores DICOM?
Sim. A reconciliação governada pode usar informações locais verificadas do paciente e do procedimento. O atalho proibido aqui é uma alteração não autorizada feita apenas para forçar a aceitação; preserve o original e a auditoria do mapeamento aprovado. 12
O que devo verificar antes de importar um estudo de ultrassom externo?
Leia os atributos recebidos do paciente e do emissor, compare dados demográficos e mapeamentos de autoridade, estabeleça a procedência do remetente e de intermediários e mantenha as referências de pedido/estudo. Use a disposição aprovada da instituição; a concordância nestes campos não é uma garantia independente de identidade.
Quem deve realizar uma mesclagem de pacientes?
Apenas pessoal autorizado segundo os procedimentos de PACS/RIS e de identidade do paciente da instituição. Permissões, opções de recuperação e documentação dependem do produto e da política; este guia não prescreve uma operação de mesclagem.
Os IDs de paciente gerados pela modalidade são válidos fora do local?
Eles podem ter significado em seu esquema de atribuição original. O receptor deve estabelecer o escopo e uma relação local verificada; um número gerado não é automaticamente inválido nem automaticamente uma identidade corporativa. 5 8
