Uma plataforma clínica deve aceitar HL7 v2 ou FHIR R4?

Já vi equipes se declararem «FHIR first» e descobrirem no primeiro hospital que as admissões chegam por mensagens ADT, os resultados laboratoriais saem por feeds ORU e ninguém pagará pela substituição das interfaces. Também vi o erro inverso: um pipeline v2 maduro vira desculpa para evitar uma API utilizável, então cada novo consumidor precisa de outro feed privado. Os padrões não são formatos de arquivo concorrentes. Eles expõem modelos de interação, regras de conformidade e custos operacionais diferentes.

Essa escolha deve ocorrer durante a descoberta do produto e a contratação, antes que os engenheiros criem parsers. Conte os tipos de endpoint, nomeie cada direção dos dados, identifique quem inicia cada troca e vincule toda declaração regulatória a uma versão exata do guia de implementação. Esse trabalho produz um escopo menor e mais defensável que «aceitar HL7 e FHIR».

A combinação de endpoints decide a primeira interface

Crie a primeira interface para os endpoints que os clientes realmente conseguem habilitar durante a implantação. Um roadmap baseado em logotipos do mercado alvo ou em alegações genéricas sobre interoperabilidade moderna calculará o trabalho de forma errada.

Comece com um inventário no nível da transação. Para cada cliente inicial, registre o sistema remetente, o destinatário, o padrão e a versão disponíveis, o tipo de mensagem ou recurso, a direção, o gatilho, o volume esperado, a tolerância de latência, o método de autenticação e o responsável pela interface remota. «Epic aceita FHIR» ou «o laboratório usa HL7» não preenche nenhum desses campos, e uma anotação comercial nesse nível não deve virar requisito de engenharia.

Uma plataforma para prestadores que precisa de mudanças de censo quase em tempo real provavelmente encontrará primeiro feeds ADT v2 existentes. Um aplicativo de paciente que busca alergias, medicamentos e resultados pode encontrar uma API FHIR R4 moldada pelo US Core. Uma plataforma que importa registros em massa de vários módulos certificados talvez precise de FHIR para acesso populacional e ainda receba notificações v2 de sistemas locais. Conte essas integrações como classes separadas, mesmo quando pertencem ao mesmo cliente.

Pondere o inventário pela receita contratada ou provável, não pelo número total de conexões teóricas. Um sistema de saúde com quatro feeds v2 obrigatórios pode importar mais que vinte prospects que apenas citam FHIR no roadmap. Registre também a dificuldade de habilitação. Um endpoint FHIR aparentemente disponível pode exigir cadastro do aplicativo, análise de segurança, correspondência de pacientes, configuração do tenant e atualização antes de devolver os dados necessários. Um feed v2 pode exigir solicitação à equipe de interfaces, trabalho de firewall e meses na fila do hospital. Nenhum rótulo prevê a entrega.

Use três grupos quando as evidências forem incompletas:

• Endpoints contratados têm sistema, transação, direção e responsável pela aceitação definidos.
• Endpoints confirmados têm documentação técnica ou uma conversa de descoberta concluída, mas não compromisso contratual.
• Endpoints presumidos vêm de uma crença de mercado e não devem orientar a primeira versão.

Se os endpoints contratados forem principalmente feeds de eventos v2, entregue primeiro um adaptador v2 limitado e mantenha o modelo interno pronto para FHIR. Se forem sobretudo leituras US Core em APIs certificadas, implemente primeiro o comportamento necessário do cliente R4. Se os dois grupos puderem impedir a entrada em produção, aceitar ambos não é indecisão arquitetural. É uma descrição honesta do mercado.

Eventos e consultas resolvem tempos diferentes

HL7 v2 costuma ser a melhor opção quando o sistema de origem precisa enviar um evento de negócio assim que ele ocorre; FHIR R4 REST costuma ser melhor quando um consumidor pede o estado atual de um recurso. Confundir entrega push com representação de recursos cria ciclos de consulta, eventos perdidos e promessas enganosas.

Uma mensagem ADT A01 informa que ocorreu uma admissão. Seu significado inclui o gatilho, a ordem da mensagem, o identificador de controle e a relação de confirmação. Um recurso Encounter do FHIR descreve o estado clínico e administrativo, mas sua leitura não reproduz sozinha o contrato do evento. A especificação FHIR R4 oferece histórico, mensageria e mecanismos Subscription além de REST, porém um endpoint que expõe recursos talvez não implemente o mecanismo de eventos necessário. Um CapabilityStatement informa o que o servidor declara aceitar; um selo FHIR não.

O erro inverso trata todo consumidor como destinatário de feed. Um aplicativo assistencial que precisa da lista atual de medicamentos de um paciente não deveria reconstruir o estado presente com anos de mensagens. Uma busca FHIR pode devolver os recursos que o servidor expõe agora, sujeita a perfis, parâmetros de busca, autorização, paginação e disponibilidade dos dados. Muitas equipes de aplicativos entendem e testam esse modelo com mais facilidade.

Faça duas perguntas para cada troca. Primeiro, quem sabe que o trabalho deve acontecer? Segundo, o destinatário precisa do evento ou do estado resultante? Quando um sistema de registro sabe imediatamente que um paciente foi transferido e o sistema de leitos deve reagir, um feed de eventos funciona. Quando um usuário de análise abre o prontuário e precisa das condições atuais, uma consulta funciona. Se a plataforma precisa dos dois, um evento recebido pode invalidar ou atualizar uma visão de recursos sem obrigar as interfaces a compartilhar o formato de transporte.

Não prometa «tempo real» sem uma definição operacional. Registre o atraso permitido, o período de nova tentativa, a regra de ordenação, a política de duplicatas e o procedimento de recuperação. Uma mensagem v2 entregue por conexão persistente ainda pode parar na fila do motor de integração. Uma requisição FHIR pode responder depressa enquanto o repositório está horas atrasado em relação à fonte. Meça a atualidade clínica na origem e no consumidor, não apenas a latência HTTP ou a entrega no socket.

A mensageria FHIR não apaga essa diferença. A especificação R4 separa explicitamente mensageria de REST e afirma que os sistemas não precisam aceitar os dois. Quando um cliente disser «aceitamos FHIR», verifique o CapabilityStatement e o guia de implementação, depois teste a interação exata. O nome indica a forma dos dados. A interação determina se o fluxo funcionará.

O trabalho bidirecional amplia o contrato

Enviar dados de volta a um sistema clínico é uma capacidade diferente de ler ou receber dados. Uma plataforma que ingere resultados com segurança não provou que consegue fazer um pedido, atualizar um prontuário, agendar uma consulta ou mesclar registros de pacientes.

Interfaces v2 de entrada costumam chegar como notificações não solicitadas. O trabalho clínico de saída pode usar outra família de mensagens, outra conexão, segmentos específicos do local e um processo de confirmação mais rigoroso. Receber resultados ORU, por exemplo, não significa que o cliente aceite pedidos ORM da mesma plataforma. Mesmo dentro de uma família, a especificação do destinatário pode restringir campos obrigatórios, conjuntos de códigos, repetições, valores vazios e tempo de confirmação além do esperado por um parser genérico.

Leituras FHIR também não implicam escritas FHIR. O US Core tem se concentrado em um piso comum de acesso, e um endpoint pode cumprir interações obrigatórias de leitura e busca sem aceitar create ou update para os recursos alterados pelo fluxo. A especificação REST do FHIR R4 define create, update, patch, transaction e interações condicionais, mas o servidor escolhe quais interações e recursos expõe e os declara no CapabilityStatement.

Descreva cada fluxo bidirecional como uma transição de estado com um sistema de registro responsável. «Enviar dados de medicação ao EHR» é vago demais. Especifique se a plataforma propõe um medicamento, cria um pedido, reconcilia uma lista ou arquiva um documento; quem aprova; qual identificador liga a resposta; como a rejeição aparece; e qual sistema prevalece depois de mudanças simultâneas. Essas decisões controlam o risco clínico e o desenho do adaptador.

As confirmações também precisam de semântica precisa. O material de controle do HL7 v2 separa aceitação de processamento pela aplicação no modo de confirmação aprimorado. Uma confirmação de aceitação pode indicar que o destinatário assumiu a responsabilidade de guardar a mensagem com segurança; ela não quer dizer necessariamente que a aplicação clínica aplicou a mudança. Se a plataforma marcar um pedido como concluído após a aceitação do transporte, o usuário verá sucesso enquanto a aplicação remota talvez o rejeite depois.

Para cada caminho de saída, contrate quatro estados:

• recebido pelo transporte remoto;
• aceito para processamento durável;
• aplicado ou rejeitado pela aplicação clínica;
• reconciliado com o estado visível ao usuário na plataforma.

Esse modelo de estados fica acima de qualquer adaptador v2 ou FHIR. Com FHIR, um sucesso HTTP e o recurso retornado podem oferecer evidência útil, mas ainda pode haver uma revisão assíncrona. Com v2, os campos MSA e respostas da aplicação fornecem evidência, porém as convenções locais variam. Trate o sucesso do protocolo e a conclusão clínica como fatos separados em todos os casos.

Motores de integração custam mais que a licença

O custo do v2 vem da operação de interfaces específicas para cada parceiro, não apenas da análise de texto separado por barras. O custo do FHIR vem de perfis, autorização, buscas, terminologia e variações entre servidores, não apenas do tratamento de JSON.

Um motor de integração hospitalar pode reduzir o trabalho de conexão porque já roteia mensagens, gerencia canais, transforma campos e oferece monitoramento conhecido pela equipe. Ele também pode adicionar compra, trabalho entre ambientes, mão de obra especializada e outro lugar onde os mapeamentos ficam escondidos. Se a plataforma exigir que clientes comprem ou ampliem um motor, inclua isso no modelo comercial. Se eles já tiverem um, não presuma que há licenças, pessoal ou janelas de mudança disponíveis.

Operar seu próprio gateway v2 evita a dependência do motor do cliente na normalização interna, mas torna sua equipe responsável pelo ciclo de vida das conexões, confirmações, filas duráveis, reprocessamento, mensagens mortas, isolamento entre parceiros, observabilidade de mensagens e informações de saúde protegidas nas ferramentas operacionais. Uma biblioteca que interpreta segmentos cobre uma parte pequena dessa obrigação.

FHIR leva parte da variação para artefatos computáveis, o que ajuda, mas não elimina o trabalho. Servidores diferem nos parâmetros de busca, includes, paginação, limites de requisição, erros, resolução de referências, versões de perfil, terminologia e política de autorização. O CapabilityStatement é uma entrada necessária, não uma prova de comportamento correto. Teste com dados reais e mantenha visíveis as exceções do endpoint.

Estime uma interface ao longo da sua vida operacional. Inclua descoberta, construção, validação pelo cliente, entrada em produção, monitoramento, incidentes, mudanças de versão, regressão e manutenção específica. Separe o custo do adaptador compartilhado do custo por endpoint. Um parser ADT reutilizável pode ser compartilhado; o mapeamento local de um código de unidade não. Um cliente de recursos US Core pode ser compartilhado; uma combinação de buscas sem suporte não.

A recomendação popular de colocar um motor diante de toda diferença está errada para uma empresa de produto. Ela agrada porque os motores facilitam a primeira transformação e dão aos analistas um console conhecido. Falha quando o significado do produto fica dividido entre mapeamentos opacos do cliente e código da aplicação. Mantenha a adaptação de transporte na borda, mas conserve dentro da plataforma o significado canônico, a validação, a proveniência e o estado do fluxo.

Um motor continua útil com uma fronteira clara: conectar, rotear, aplicar transformações documentadas na borda e expor evidência de entrega. Não deixe que ele decida o significado de um resultado laboratorial para o produto nem qual estado do paciente prevalece. Essas regras precisam de versões, testes e responsabilidade do produto.

US Core é um escopo de conformidade versionado

Aceitar FHIR R4 não significa automaticamente estar em conformidade com US Core. O US Core restringe recursos R4, terminologia, elementos obrigatórios, comportamento Must Support, referências, parâmetros de busca e interações para atores definidos, e toda declaração deve citar a versão do guia.

O guia oficial US Core 8.0.1 se baseia em FHIR R4. O material 9.0.0 é uma versão posterior em votação até a publicação oficial pela HL7. Essa diferença importa em contratos e planos de teste. «US Core atual» muda durante uma implantação longa; «obrigações do servidor US Core 8.0.1 para estes perfis e buscas» pode ser implementado e testado.

Must Support muitas vezes é entendido como «este campo deve aparecer em todos os recursos». O guia US Core define comportamento conforme o ator. Um respondente precisa conseguir preencher os elementos aceitos quando a informação existe, e um solicitante precisa processá-los sem falhar. Também se aplicam regras de dados ausentes e suprimidos. Cardinalidade, Must Support e disponibilidade respondem a perguntas diferentes; uma validação que exige todo elemento marcado rejeitará registros válidos.

Obrigações regulatórias e de certificação também dependem do que é vendido. O critério de API padronizada da ASTP/ONC em 45 CFR 170.315(g)(10) rege módulos certificados de tecnologia de saúde dentro de seu escopo e referencia especificações adotadas de FHIR, US Core, SMART e Bulk Data. Uma plataforma clínica não se torna legalmente obrigada a obter certificação apenas por guardar dados de pacientes dos EUA ou conectar-se a um EHR. Por outro lado, um módulo que busca a certificação não cumpre o critério oferecendo recursos R4 arbitrários.

Transforme o requisito em um registro de conformidade. Para cada papel do produto e caso de uso, registre a autoridade ou contrato aplicável, a versão exata do guia e patch, o ator, os perfis, as interações, buscas, terminologia, guia de autorização, ferramenta de teste e responsável pela evidência. Separe obrigações regulatórias de metas voluntárias de compatibilidade. Juristas e especialistas em certificação decidem a aplicabilidade legal; engenheiros tornam o escopo adotado executável.

Não trate US Core como uma API completa de escrita. Consulte as tabelas de interação do guia e perfil escolhidos. Se o produto deve criar notas clínicas, enviar pedidos ou atualizar agendas, identifique outro guia ou um contrato específico do cliente. A falta de um caminho padronizado de escrita não impossibilita o fluxo, mas reduz a promessa comercial e aumenta o risco.

A especificação FHIR R4 também diz que sua API REST não define diretamente autenticação, autorização nem coleta de auditoria. SMART App Launch e requisitos relacionados cobrem partes importantes, enquanto políticas organizacionais e a arquitetura cobrem outras. Passar pela validação estrutural sem um projeto de controle de acesso e auditoria não é interoperabilidade segura.

Um modelo canônico mantém as duas bordas honestas

Plataformas que aceitam os dois padrões devem normalizar dados em um modelo canônico versionado, preservando a carga original e a proveniência. Não use um recurso FHIR como todo o modelo do banco interno e não transforme uma árvore de segmentos v2 no domínio do produto.

O modelo canônico deve expressar fatos usados pelo produto: identificadores de pacientes com autoridades emissoras, transições de atendimento, observações com códigos e unidades, estado de pedidos, horários de origem, proveniência e incerteza. Ele também precisa de regras de identidade e ciclo de vida deixadas pelos formatos à implementação. Guarde mensagens ou recursos brutos sob controles de retenção e acesso para que operadores expliquem como um fato normalizado foi produzido.

Adaptadores devem tratar a sintaxe e os mapeamentos declarados da borda. Serviços de domínio devem decidir correspondência de pacientes, deduplicação, transições e conflitos. Adaptadores de saída então representam uma mensagem ou recurso próprio do destino a partir de uma ação aprovada. Essa separação impede que um segmento Z local ou uma extensão FHIR chegue a todos os consumidores.

Um pequeno manifesto de capacidades força o escopo a usar linguagem revisável:

endpoint: hospital-a
direction: inbound
standard: hl7-v2
version: "2.5.1"
transactions:
  - ADT_A01
  - ADT_A03
acknowledgment: accept_and_application
ordering: per_connection
duplicate_key: message_control_id
canonical_release: "2026-02"

Esse trecho evita uma falha comum: uma tarefa diz «adicionar HL7», enquanto engenharia, vendas e cliente imaginam mensagens diferentes. Guarde um manifesto por endpoint implantado, valide-o na automação de entrega e vincule sua versão aos testes de mapeamento. Para FHIR, o equivalente deve nomear o patch R4, o pacote do guia, perfis, buscas, operações, autorização e paginação.

Preserve identificadores como pares de valor e namespace. O número 12345 sozinho não identifica com segurança um paciente, visita, pedido ou observação entre organizações. Não descarte autoridades emissoras v2 ao normalizar e não elimine Identifier.system do FHIR porque dois sistemas usam o mesmo valor em um tenant de teste.

Preserve também a semântica temporal. A hora de criação da mensagem, do evento, o tempo efetivo da observação, sua emissão, a última atualização do servidor e a ingestão respondem a perguntas diferentes. Colocá-las em um único timestamp cria cronologias plausíveis, porém erradas. O modelo pode oferecer um horário preferido, mas a proveniência deve guardar como ele foi escolhido.

Versione transformações separadamente da plataforma. Uma mudança de mapeamento pode alterar significado clínico sem mudar o parser. Processe cargas antigas com o novo mapeamento, compare a saída canônica e exija revisão para identificadores perdidos, mudanças de códigos ou unidades e transições alteradas. O suporte aos dois padrões funciona quando os adaptadores geram fatos comparáveis e registram o que não foi possível mapear.

Uma admissão revela falhas escondidas

Uma única mensagem de admissão pode parecer bem-sucedida em todas as camadas de transporte e ainda criar o estado errado para o paciente. Percorra o caminho antes de declarar uma interface ADT pronta.

Suponha que um hospital envie esta mensagem reduzida:

MSH|^~\&|REG|NORTH|PLATFORM|CLOUD|202607271030||ADT^A01|84721|P|2.5.1
PID|1||778899^^^NORTH^MR||Rivera^Ana
PV1|1|I|4W^412^1||||1234^Chen^Lee

O gateway aceita a conexão, guarda a carga e devolve uma confirmação de aceitação de aplicação para o ID 84721. O parser funciona. O comparador de pacientes, porém, ignora NORTH como autoridade emissora e encontra um 778899 de outra unidade. Ele associa o novo atendimento à pessoa errada. Os painéis de transporte ficam verdes porque a entrega funcionou como configurada.

A próxima falha aparece no reprocessamento. Um operador reenvia a carga guardada após uma interrupção. Se a deduplicação usa um UUID de ingestão em vez do ID de controle mais o escopo do remetente, a plataforma cria uma segunda admissão. Se rejeita todo ID repetido para sempre, pode tratar mal um remetente que reinicia identificadores conforme uma regra documentada. A deduplicação deve corresponder ao contrato e ser observável.

Depois, uma alta A03 chega antes de uma transferência A02 atrasada. Processar pela ordem de chegada reabre ou move um atendimento encerrado. É preciso declarar uma estratégia: ordem da conexão, hora do evento com tolerância, sequência da origem quando disponível ou uma regra específica de reconciliação. Não há resposta universal, mas a ordem silenciosa de chegada raramente é defensável.

Teste o caminho em quatro níveis. Testes do parser provam a sintaxe. Testes de mapeamento provam a semântica de identificadores, códigos, nulos, repetições e horários. Testes de fluxo provam transições, duplicatas, atrasos e rejeições. Testes de aceitação provam que o sistema remoto envia e recebe o que foi documentado. Um validador genérico não substitui os três últimos.

Execute falhas equivalentes para FHIR. Retorne dois recursos Patient com o mesmo identificador em sistemas diferentes. Omita um elemento Must Support quando a fonte não tiver o dado. Divida uma busca em páginas. Retorne OperationOutcome com status HTTP de sucesso. Altere um recurso entre páginas. O objetivo não é tolerar absurdos, mas definir qual variação o cliente processa, informa, repete ou rejeita.

Por isso, «interpretamos v2 e JSON» é uma afirmação fraca de prontidão. Estar pronto para produção significa que um usuário consegue rastrear um fato clínico até a carga, versão do mapeamento, decisão de identidade, transição, confirmação e histórico de correção.

A matriz deve produzir uma versão limitada

Escolha os dois padrões quando endpoints relevantes para o lançamento exigirem ambos, mas limite cada um a transações e interações nomeadas. Escolha um primeiro quando ele cobrir os fluxos bloqueadores e a arquitetura deixar uma fronteira de adaptador testada para o segundo.

Avalie cada capacidade com evidências, não preferências:

• Endpoints favorecem v2 quando feeds contratados dominam, FHIR quando APIs R4 contratadas dominam, e ambos quando grupos bloqueadores usam cada um.
• O tempo favorece v2 quando uma origem envia eventos, FHIR quando um consumidor consulta estado, e ambos quando o produto reage e busca recursos.
• A direção favorece a interface que expõe a ação de entrada ou saída necessária; exige ambas quando a leitura difere da escrita ou do evento.
• O escopo US Core favorece FHIR quando perfis e interações nomeados se aplicam, mas operações locais ainda podem exigir v2 ao lado da API.
• A prontidão favorece o lado com especificações, amostras, acesso e equipe remota responsável; ambos exigem os dois grupos no go-live.

A incerteza não favorece padrão algum. Contratos assinados antes de receber uma especificação, CapabilityStatement, sandbox ou amostra criam trabalho de descoberta independentemente do nome da interface.

Uma versão v2 inicial pode aceitar ADT A01, A02, A03 e A08 de parceiros 2.5.1 por um transporte documentado, com confirmação aprimorada, reprocessamento e mapeamentos próprios. Não deve prometer pedidos, resultados, agenda, documentos, todas as versões ou segmentos Z arbitrários. Essas são capacidades posteriores com testes separados.

Uma versão FHIR inicial pode atuar como solicitante R4 para uma versão nomeada do US Core, recuperar um conjunto limitado de perfis, implementar buscas e paginação exigidas, processar Must Support e usar a autorização necessária. Não deve prometer conformidade FHIR genérica, todos os recursos, subscriptions, escritas ou todos os guias.

Uma versão dupla ainda deve ser assimétrica. v2 pode cuidar dos eventos ADT enquanto FHIR cuida de leituras clínicas solicitadas pelo paciente. O modelo canônico e a proveniência conectam os fatos, mas nenhuma exigência diz que ambos os adaptadores devem executar todo fluxo. A simetria dobra o trabalho e costuma criar capacidades que nenhum cliente testará.

Defina critérios de saída sobre o comportamento implantado. Exija um conjunto representativo de cargas, casos negativos, ensaios de recuperação, evidência da versão do mapeamento, filas observáveis e um responsável pela aceitação. Para FHIR, acrescente validação de perfil, buscas, paginação, falhas de autorização e a declaração de capacidade preservada. Para v2, acrescente confirmação, duplicatas, mensagens atrasadas, perda de conexão e reprocessamento.

Coloque preço na incerteza. Se um prospect não fornecer especificação, CapabilityStatement, sandbox, cargas de exemplo ou responsável técnico, cobre descoberta antes de comprometer o adaptador. Uma estimativa fixa baseada na palavra «HL7» transfere todas as incógnitas para a equipe da plataforma.

O contrato deve dizer o que rodará em produção

A decisão final deve caber em um cronograma curto de capacidades anexado ao contrato. Ele nomeia endpoints, direções, eventos ou interações FHIR, versões, perfis, segurança, latência, confirmações, recuperação, evidências, exclusões e o responsável por cada dependência.

Esse cronograma evita três discussões caras. Vendas não pode tratar um feed ADT como suporte a todo HL7 v2. Um cliente não pode tratar um cliente R4 de leitura como servidor US Core certificado. Engenharia não pode chamar aceitação de transporte de ação clínica concluída.

Crie um caminho vertical fino pelo endpoint de maior risco antes de completar a biblioteca. Use formatos reais de cargas desidentificadas, a declaração de capacidade do cliente e regras de identidade de produção. O caminho deve atravessar conexão, validação, normalização, estado, armazenamento, observabilidade e correção. Ele revelará mais escopo que outra semana discutindo padrões em abstrato.

A SaaS Production constrói sistemas de saúde, incluindo trabalhos com EMR e EHR, e pode transformar um inventário de endpoints em uma implementação limitada. Sua abordagem Human-in-the-Loop combina entrega assistida por IA com engenheiros experientes, algo útil somente depois que o contrato disser exatamente o que eles precisam provar.

Não adie o segundo padrão fingindo que ele será um tradutor simples. Preserve entradas brutas, significado canônico, proveniência e fronteiras de adaptador desde a primeira versão. Adicione a segunda borda quando os fluxos contratados justificarem. A resposta certa não é «ambos» como slogan; é o menor conjunto testado de eventos v2 e interações R4 que executa o trabalho clínico pretendido.

Perguntas Frequentes

O FHIR R4 está substituindo o HL7 v2 nos hospitais?

Não. FHIR R4 ganhou importância no acesso padronizado por API, enquanto v2 continua em admissões, resultados, pedidos e feeds operacionais. Planeje com base nos endpoints que o cliente consegue implantar, não numa data prevista de abandono.

Um motor pode converter mensagens HL7 v2 em recursos FHIR?

Ele pode transformar a sintaxe e muitos campos mapeados, mas não inventa semântica de fluxo, identidade ou terminologia ausentes. Mantenha o significado canônico e as decisões clínicas em código testado mesmo quando um motor transforma as bordas.

Aceitar FHIR R4 torna uma plataforma compatível com US Core?

Não. US Core acrescenta perfis versionados, Must Support, terminologia, buscas e interações por ator ao R4. Nomeie a versão exata e teste as obrigações de servidor ou solicitante que declarar.

O US Core exige que uma plataforma clínica aceite escritas?

Não presuma isso. Consulte as interações para a versão, ator e perfil exatos e defina a escrita em outro guia ou contrato. Acesso de leitura e escrita clínica têm riscos diferentes.

Quando HL7 v2 é a melhor primeira escolha?

Escolha v2 quando endpoints contratados enviarem eventos operacionais, como admissões ou resultados, por interfaces existentes. Limite a versão a eventos, direções, confirmações e mapeamentos nomeados.

Quando FHIR R4 é a melhor primeira escolha?

Escolha R4 quando o fluxo bloqueador buscar estado padronizado em APIs disponíveis ou precisar cumprir um escopo US Core nomeado. Verifique autorização, perfis, buscas, páginas, erros e dados antes de estimar.

Como uma plataforma deve deduplicar mensagens HL7 v2?

Use o identificador de controle no escopo do remetente e suas regras documentadas de reutilização, guardando a decisão como evidência. Um UUID de ingestão não detecta reenvios e uma proibição global pode rejeitar tráfego legítimo.

O que uma confirmação HL7 comprova?

Ela comprova somente a etapa definida pelas partes. Recepção, aceitação durável, processamento e trabalho clínico concluído podem ser estados separados, portanto a interface não deve uni-los.

Recursos FHIR devem ser o modelo interno da plataforma?

Normalmente não. Use um modelo canônico do produto para identidade, proveniência, fatos clínicos e estado, enquanto adaptadores consomem ou produzem FHIR. Guarde o recurso original para explicar e corrigir mapeamentos.

Como estimar o custo de aceitar os dois padrões?

Separe o adaptador compartilhado da descoberta, mapeamento, teste, entrada em produção, monitoramento, incidentes e atualização de cada endpoint. Cobre descoberta quando faltarem especificações, amostras, evidências de capacidade ou responsável técnico.