Exportando um diário miccional para o Epic, Cerner e outros EMRs

Bladder Diaries exporta o diário do paciente em dois arquivos padrão: um FHIR R4 Bundle (.fhir.json) para EMRs modernos que ingerem FHIR, e um HL7 C-CDA R2.1 CCD (.ccd.xml) para sistemas legados e mensageria Direct Secure Messaging. Ambos os arquivos são construídos no navegador, baixados localmente e, em seguida, anexados ao prontuário pela entrada padrão do EMR receptor. Nenhum dado do paciente trafega pelos servidores de bladderdiaries.com; o placeholder de Patient sintético é substituído pela ferramenta de chart-matching do receptor na ingestão.

Você acabou de concluir um diário de 3 dias com um paciente. A calculadora devolveu MVV (volume miccional máximo) 320 mL, AVV (volume miccional médio) 145 mL, NPi (índice de poliúria noturna) 32%, 24hVV (volume miccional de 24 horas) 2,1 L e FVC (frequency-volume chart) com frequência de 9 micções por 24 horas. Resta a pergunta mecânica: como esses números aterrissam no prontuário em uma forma que o codificador, a enfermagem e a próxima consulta consigam ler? Este percurso cobre os dois formatos de arquivo, onde cada um aterrissa no Epic, no Cerner / Oracle Health, no Athena Health, no Prompt Health (via Kno2) e no EMR legado, além de como se configura o contrato de chart-matching do lado do receptor.

Os dois formatos de arquivo: FHIR R4 Bundle vs HL7 C-CDA R2.1 CCD

Os dois padrões no catálogo de importação de prontuário são FHIR (Fast Healthcare Interoperability Resources) e C-CDA (Consolidated Clinical Document Architecture). Ambos são padrões HL7; ambos carregam os mesmos dados do diário em formatos de transporte distintos. Bladder Diaries emite os dois porque o ecossistema EMR é bilíngue: instalações modernas ingerem FHIR nativamente, instalações ambulatoriais legadas ingerem C-CDA, e mandatos federais norte-americanos (21st Century Cures Act, ONC Cures Act Final Rule) exigem desde 2023 que as tecnologias EHR certificadas suportem FHIR R4, com C-CDA R2.1 como rampa de entrada para o legado.

FHIR R4 Bundle: o caminho moderno

FHIR R4 (publicado em outubro de 2019) é o padrão JSON orientado a recursos que a coorte EMR moderna ingere. A exportação é entregue como um Bundle de type: "collection" contendo:

• 1 recurso Patient placeholder, carregando o sentinela REPLACE_WITH_MRN em Patient.identifier. O receptor preenche o MRN real na ingestão.
• N recursos Observation em nível de evento: um por micção, um por ingesta de líquido, um por pontuação de urgência (quando registrada), um por evento de perda urinária. O receptor enxerga a linha do tempo bruta.
• 5 recursos Observation no nível de métrica calculada para MVV, AVV, NPi, 24hVV e FVC, cada um carregando codificação híbrida LOINC mais codificação do CodeSystem personalizado de Bladder Diaries (conforme Phase 8 D-12). O receptor obtém uma codificação padrão e uma codificação precisa.
• 1 recurso DiagnosticReport que sintetiza as métricas, com o PDF codificado em base64 dentro de presentedForm[0].data. Um artefato legível por humanos acompanha sempre os dados estruturados.

O Bundle valida contra o esquema HL7 R4 e contra o perfil US Core 6.1.0 Implementation Guide. Receptores que perfilam contra o US Core (Epic, Cerner / Oracle Health, Athena, Allscripts / Veradigm) recuperam os campos esperados: Patient.identifier, Observation.code, Observation.value[x], Observation.effectiveDateTime, DiagnosticReport. Receptores que não perfilam contra o US Core ainda recebem a forma R4 de base, suficiente para a ingestão.

HL7 C-CDA R2.1 CCD: a rampa de entrada para sistemas legados

C-CDA R2.1 (publicado em julho de 2015) é o padrão documental baseado em XML que a coorte EMR ambulatorial legada e o transporte Direct Secure Messaging ingerem. A exportação é entregue como um ClinicalDocument com:

• O US Realm Header (CONF:1198-*) cobrindo o placeholder Patient, a organização custodian, o autor do documento e o esqueleto CDA padrão.
• Um body contendo as seis seções obrigatórias do CCD (Alergias, Medicações, Problemas, Procedimentos, Resultados, História Social), com nullFlavor="NI" nas seções que o diário não preenche.
• Um organizer Results carregando as mesmas cinco métricas calculadas, cada <observation> com dupla declaração do templateId Result Observation V3 (2.16.840.1.113883.10.20.22.4.2, extensão 2015-08-01).
• Um elemento observationMedia carregando o relatório PDF codificado em base64 inline, sem necessidade de anexo separado.

O CDA valida contra o schematron HL7 SDWG C-CDA R2.1 (fechado durante a Phase 11 Plan 11-01). A via C-CDA é a escolha correta quando o EMR receptor antecede o ciclo de conformidade do 21st Century Cures Act, quando o fluxo de trabalho é mediado por Direct Secure Messaging, ou quando a equipe de TI do receptor desabilitou a entrada FHIR.

Qual escolher?

| EMR receptor | Formato | Superfície de entrada | | ------------------------ | ---------- | --------------------------------------------------------------------------- | | Epic | FHIR R4 | App SMART on FHIR, FHIR Inbox, anexo de prontuário em consulta de rotina | | Cerner / Oracle Health | FHIR R4 | Entrada FHIR R4, Bridges, Code App Gallery | | Athena Health | FHIR R4 | Entrada More Disruption Please (MDP); recai em CCD onde MDP está desabilitado | | Prompt Health | Qualquer um | Parceria Kno2: o normalizador do lado do receptor aceita os dois | | Allscripts / Veradigm | FHIR R4 | Ingestão dbMotion / TouchWorks | | NextGen | C-CDA | Entrada CCD; roadmap FHIR ainda não entregue em todas as edições | | eClinicalWorks | C-CDA | Entrada CCD | | Greenway / Intergy | C-CDA | Entrada CCD | | Cauda longa legada | C-CDA | Direct Secure Messaging (DSM), entrega HIE à caixa de entrada |

Regra de decisão: envie FHIR R4 se souber que o receptor suporta FHIR. Envie C-CDA se não souber, ou se o receptor estiver explicitamente na rampa de entrada legada. Bladder Diaries emite ambos os arquivos a partir da mesma saída da calculadora; você pode manter os dois à mão e usar o que o receptor de fato aceita.

Passo a passo: de /entry ao prontuário

O fluxo de trabalho de ponta a ponta tem quatro passos. Os três primeiros vivem no seu navegador, em bladderdiaries.com. O quarto vive no EMR receptor.

Passo 1: Inserir o diário em /entry

Abra a Calculadora em bladderdiaries.com. Insira o diário do paciente como micções, ingestas de líquido, marcadores de hora de dormir e (quando documentados) eventos de perda urinária e pontuações de urgência. O formulário de tela única leva cerca de 90 segundos para um diário típico de 3 dias. A idade do paciente e a marcação de enurese pilotam o limiar do NPi por faixa etária e a classificação de continência.

Passo 2: Ler as métricas em /results

A calculadora roteia para /results após o envio. A página renderiza MVV, AVV, NPi, 24hVV, FVC e a classificação IPC (Integrated Pelvic Care) 4Is (Fluid Imbalance, Storage Impairment, Voiding Impairment, Incontinence). O quadro de quatro compartimentos alimenta a linguagem do prontuário para a nota da consulta; consulte o pilar de interpretação do diário miccional para a disciplina clínica que casa os números com o diagnóstico diferencial.

Passo 3: Apertar o botão de exportação

A barra de exportação no topo de /results traz três botões: PDF, FHIR Bundle e C-CDA CCD. Aperte o formato que o EMR receptor aceita. O arquivo é construído no navegador (FHIR Bundle em JSON, CCD em XML) e aterrissa na pasta local de downloads com nome determinístico: bladder-diary-YYYY-MM-DD.fhir.json ou bladder-diary-YYYY-MM-DD.ccd.xml. Não há upload HTTPS para bladderdiaries.com; o toast confirma "baixado. Observação: o arquivo está armazenado no seu dispositivo, fora desta calculadora".

Passo 4: Anexar ao prontuário no EMR receptor

Epic via SMART on FHIR: se sua organização desenvolveu um app SMART on FHIR voltado ao paciente, o paciente carrega o FHIR Bundle pelo MyChart. Se sua equipe de TI habilitou a FHIR Inbox, deposite o arquivo nela. Se nenhum desses caminhos estiver disponível, anexe o FHIR Bundle como anexo de prontuário em uma consulta de rotina; o arquivo passa a viver no prontuário como binário, e os dados estruturados podem ser reparseados posteriormente.

Cerner / Oracle Health: a entrada FHIR R4 aceita o arquivo pela operação R4/$import quando a TI a habilitou. Muitas instituições roteiam pelo Bridges (a camada de interoperabilidade da Oracle Health). O Code App Gallery é uma terceira via: uma superfície SMART on FHIR em que o arquivo é carregado como recurso anexado ao paciente.

Athena Health: a entrada More Disruption Please (MDP) é o caminho FHIR R4. Deposite o FHIR Bundle pelo endpoint MDP. Se sua instância Athena dispõe apenas da entrada CCD legada, envie o C-CDA CCD no lugar.

Prompt Health: a parceria Kno2 aceita ambos os formatos. O Kno2 atua como normalizador do lado do receptor, convertendo FHIR ou CCD para o formato que o EMR a jusante espera. O mesmo caminho vale para qualquer EMR na rede Kno2.

EMR legado via Direct Secure Messaging (DSM): o C-CDA CCD trafega via DSM como anexo XML. O Health Information Service Provider (HISP) do receptor o entrega na caixa do receptor. A via DSM é a escolha correta para consultórios ambulatoriais que ainda não adotaram FHIR.

A alternativa por e-mail simples não é recomendada. Prefira a entrada padrão do EMR receptor; o caminho por e-mail é um fluxo manual de último recurso.

O contrato de privacidade: puro cliente, sem trânsito de PHI

A propriedade mais importante do pipeline de exportação é que ele nunca transmite dados do paciente. Ambos os arquivos são construídos integralmente no seu navegador a partir dos dados do diário inseridos pelo clínico em /entry. O diário vive apenas no localStorage do navegador: nenhum banco de dados do lado do servidor, nenhum upload HTTPS para bladderdiaries.com, nenhuma análise de terceiros sobre a carga do diário.

O EMR receptor é a autoridade de chart-matching. O placeholder de Patient carrega REPLACE_WITH_MRN em Patient.identifier exatamente para que o receptor possa rodar seu próprio matching contra o espaço de nomes local de MRN. A política de TI do receptor determina se o matching é automático (operação R4/$import do lado do sistema, com regra de vinculação ao prontuário) ou manual (a equipe da recepção casa o arquivo entrante com o prontuário). Bladder Diaries não vê, não armazena e não transmite qualquer informação de matching.

A postura HIPAA / LGPD decorre desse design. Bladder Diaries permanece fora do perímetro HIPAA Covered Entity e fora do perímetro LGPD de controlador de dados porque nunca retém dados do paciente em seus servidores. O navegador local do clínico retém o diário; o sistema de arquivos do clínico retém a exportação; o EMR receptor retém o prontuário. Cada elo é uma superfície de conformidade conhecida pela equipe de TI local e pelo Business Associate Agreement local (quando aplicável); o elo bladderdiaries.com está vazio por design.

Isso está documentado na Política de Privacidade. O invariante de puro cliente é o cadeado arquitetural que mantém Bladder Diaries fora do perímetro regulatório; o catálogo de formatos de arquivo é a rampa operacional que, ainda assim, entrega dados estruturados ao prontuário.

O que é o OID CodeSystem 2.25.* no meu log de auditoria?

Receptores que auditam o documento entrante por CodeSystem verão um Object Identifier (OID) específico de Bladder Diaries no log de auditoria, na forma 2.25.<uuid-decimal>. Isso é intencional e merece uma breve explicação, porque equipes de TI clínica às vezes sinalizam OIDs desconhecidos como questão de segurança.

Um OID é um identificador hierárquico registrado contra uma árvore global (o arco OID ISO/IEC 9834). Os padrões HL7 usam OIDs para identificar sistemas de codificação de forma inequívoca: LOINC é 2.16.840.1.113883.6.1, SNOMED CT é 2.16.840.1.113883.6.96. Cada OID corresponde a uma autoridade registrada que mantém os códigos.

As cinco métricas calculadas de Bladder Diaries (MVV, AVV, NPi, 24hVV, FVC) ainda não estão totalmente cobertas pelo LOINC canônico. O LOINC dispõe de códigos para os volumes subjacentes (por exemplo 28604-5 Voided volume, 28649-0 Urine output 24 hour), mas não para as métricas calculadas específicas do diário miccional na forma precisa exigida pelo framework IPC. A codificação híbrida emite tanto um código LOINC (quando existe) quanto um código personalizado de Bladder Diaries (sempre), de modo que o receptor obtém uma codificação padrão para ancorar uma busca e uma codificação precisa para ancorar um cálculo.

O CodeSystem personalizado precisa de um OID. Em vez de solicitar um arco registrado pelo HL7 (um processo de vários meses), Bladder Diaries usa o arco 2.25.* conforme RFC 4122 §4.5, que permite a qualquer parte derivar um OID globalmente único a partir de um UUID, tratando o UUID como inteiro decimal. O OID resultante é único sem registro, rastreável e em conformidade com o padrão HL7 para identificadores de CodeSystem. A equipe de TI clínica pode documentar o OID como emitido por Bladder Diaries (uma aprovação única na lista de permitidos de OID) e o log de auditoria segue fluindo normalmente.

O que perguntar ao seu setor de TI antes da primeira exportação

Cinco perguntas alinham as expectativas antes da primeira exportação de paciente. As respostas determinam qual formato de arquivo e qual superfície de entrada usar:

1. Suportamos ingestão FHIR R4? A maioria das instalações EMR em 2026 suporta FHIR R4 em algum grau; a variância está na superfície de entrada (app SMART on FHIR, FHIR Inbox, R4/$import, caminho específico do fornecedor).
2. Suportamos ingestão C-CDA R2.1? Receptores C-CDA R2.0 costumam parsear documentos R2.1 (o esquema é retrocompatível), mas os avisos do schematron podem diferir.
3. Qual é a nossa superfície de app SMART on FHIR? Epic e Cerner / Oracle Health: essa resposta indica se o FHIR Bundle é carregado por um app voltado ao paciente (MyChart) ou apenas pela FHIR Inbox de back-office.
4. Nosso endereço Direct Secure Messaging é descobrível? EMRs ambulatoriais legados: o endereço DSM é o destino do C-CDA CCD. Seu HISP pode confirmar que o endereço está publicado no registro DirectTrust.
5. Temos uma parceria com Kno2? Prompt Health e outros EMRs conectados ao Kno2: a entrada Kno2 é um único endpoint que roteia para múltiplos EMRs a jusante.

Bônus: quais são as regras de chart-matching para um arquivo entrante com MRN placeholder? Alguns receptores fazem matching automático por demografia (nome mais data de nascimento mais sexo mais endereço); outros exigem um Patient.identifier totalmente preenchido. Conhecer a política do receptor diz se o arquivo roteia automaticamente ou se a equipe do receptor casará o arquivo manualmente.

Perguntas frequentes

Qual formato de arquivo devo enviar ao Epic? FHIR R4 Bundle (.fhir.json). O Epic ingere FHIR R4 pela superfície de app SMART on FHIR, pela FHIR Inbox quando a equipe de TI a habilitou, ou como anexo de prontuário em uma consulta de rotina. Valida contra o US Core 6.1.0.

Qual formato de arquivo devo enviar ao Cerner ou Oracle Health? FHIR R4 Bundle (.fhir.json). Cerner / Oracle Health ingere FHIR R4 pelo mesmo padrão. Algumas instituições roteiam pelo Bridges ou pelo Code App Gallery; a entrada FHIR de back-office é o caminho padrão.

Qual formato de arquivo devo enviar ao Athena Health? FHIR R4 Bundle (.fhir.json) pela entrada More Disruption Please (MDP). Se sua instância Athena dispõe apenas da entrada CCD legada, envie o C-CDA CCD (.ccd.xml) no lugar.

Qual formato de arquivo devo enviar ao Prompt Health? Qualquer um. O Prompt Health aceita ambos via parceria Kno2; o normalizador do Kno2 do lado do receptor converte para o formato que o EMR a jusante espera.

Bladder Diaries faz upload dos meus dados de paciente em algum lugar? Não. Ambos os formatos são gerados integralmente no seu navegador. O arquivo aterrissa na sua pasta local de downloads; nenhum upload HTTPS para bladderdiaries.com ou para qualquer terceiro. A Política de Privacidade descreve isso em detalhe.

O que é o placeholder REPLACE_WITH_MRN? Um valor sentinela deliberado no recurso Patient sintético. A ferramenta de chart-matching do seu EMR o substitui pelo número de prontuário real na ingestão. Esse padrão permite que o arquivo seja enviado sem qualquer dado de identificação do paciente e permite ao receptor aplicar sua própria política de chart-matching.

Por que meu log de auditoria do EMR mostra um OID CodeSystem 2.25. que não reconheço?* Esse é o CodeSystem personalizado de Bladder Diaries, autoalocado sob o arco OID RFC 4122 §4.5. Usado para as cinco métricas calculadas (MVV, AVV, NPi, 24hVV, FVC) que o LOINC canônico ainda não cobre. Cada métrica também carrega um código LOINC híbrido quando ele existe.

Posso enviar o mesmo arquivo a múltiplos EMRs? Sim. Ambos os formatos são agnósticos em relação ao receptor. O mesmo FHIR Bundle ou C-CDA CCD pode ser roteado a múltiplos EMRs em paralelo (por exemplo atenção primária mais encaminhamento à especialidade). O chart-matching em cada destino é independente.

Encerramento: experimente no próximo diário

O próximo diário de 3 dias que você concluir com um paciente em Bladder Diaries é o caso de teste. Abra a Calculadora, insira o diário, leia as métricas em /results e aperte o botão de exportação correspondente ao EMR receptor. O arquivo aterrissa na sua pasta de downloads; anexe-o pela entrada padrão do EMR receptor. O clínico passa a ter, no prontuário, os mesmos números estruturados que a calculadora devolveu na tela; os servidores de bladderdiaries.com permanecem vazios; e o arquivo baseado em padrões aterrissa onde pertence: no prontuário, ao lado do restante do registro do paciente.

Autor: Dr. Di Wu, MD, PT (membro fundador do IPC). O marco v5.0 de Bladder Diaries entrega interoperabilidade EMR baseada em padrões. Padrões referenciados: HL7 FHIR R4, HL7 C-CDA R2.1, US Core 6.1.0 Implementation Guide, LOINC e RFC 4122 §4.5 (arco OID derivado de UUID). Foto: Vitaly Gariev no Unsplash.