A incorporação de Dados de Saúde Gerados pelo Paciente (PGHD) em uma plataforma existente de Arquivo Neutro de Fornecedores (VNA) representa um avanço fundamental para a construção de um prontuário de saúde verdadeiramente centrado no paciente. Esta integração vai além de um simples aumento de capacidade de armazenamento, constituindo um esforço sistemático que envolve conversão de formatos, normalização semântica e governança de dados.

Avaliação dos Obstáculos Principais

Antes de qualquer extensão, é crucial reconhecer as diferenças entre PGHD e dados clínicos tradicionais:

• Alta heterogeneidade de fontes e formatos: Os dados originam-se de múltiplas plataformas (aplicativos móveis, vestíveis, portais do paciente) em formatos díspares (CSV, JSON, XML, PDF, imagens), frequentemente sem um padrão comum.
• Qualidade inconsistente: Precisão dos dispositivos, erros de entrada pelo usuário e lacunas nos dados são problemas recorrentes.
• Alta frequência e volume: Dispositivos vestíveis podem gerar grandes quantidades de dados em série temporal (ex.: frequência cardíaca contínua).
• Sensibilidade extrema à privacidade: Dados de saúde pessoais exigem os mais altos níveis de proteção e conformidade.
• Dificuldade de fusão com dados clínicos: O principal desafio é correlacionar dados como passos, qualidade do sono e medições domiciliares com o registro médico eletrônico (EMR) do paciente para gerar valor clínico.

Proposta de Evolução da Arquitetura da Plataforma

Recomenda-se a introdução de uma "Camada de Mediação e Processamento para PGHD" como intermediária na arquitetura, preservando o núcleo estável do VNA. Esta camada atua como uma ponte que conecta fontes de dados heterogêneas ao sistema VNA existente.

Esta camada deve oferecer múltiplos canais de entrada e suportar processamento assíncrono para gerenciar picos de carga.

• Interfaces Diversificadas: Um gateway de APIs (ex.: baseado em frameworks como Express.js ou Spring Cloud Gateway) fornece endpoints RESTful padronizados para receber dados de plataformas como Apple HealthKit ou Google Fit. O portal do paciente permite o upload direto de arquivos (PDF, imagens, XML). Para dispositivos IoT fornecidos pelo hospital, SDKs ou protocolos específicos podem ser utilizados.
• Fila de Mensagens: Implementar um sistema de filas (como Apache Kafka ou RabbitMQ) é essencial para desacoplar a recepção dos dados do seu processamento, garantindo resiliência e escalabilidade.

2. Camada de Transformação e Normalização

Esta é a etapa crítica, transformando dados brutos em informações estruturadas e semanticamente significativas.

• Parseamento Específico: Desenvolver ou utilizar uma biblioteca de parsers para cada fonte de dados comum. Por exemplo, um parser para arquivos XML do HealthKit, outro para JSON do Garmin e outro para CSV de glicosímetros.
• Mapeamento para Terminologias Padrão: Os dados extraídos devem ser mapeados para códigos clínicos reconhecidos:
  • LOINC: Para identificar testes laboratoriais (ex.: "glicemia em jejum" → código 1558-6).
  • SNOMED CT: Para termos clínicos (ex.: "fibrilação atrial" → código 49436004).
  • UCUM: Para padronizar unidades de medida.
• Conversão para FHIR: O objetivo final é representar os dados como recursos HL7 FHIR. Medições de sinais vitais se tornam recursos Observation, enquanto relatórios completos podem se tornar DiagnosticReport. Isso permite uma integração semântica perfeita com outros dados clínicos já armazenados.

3. Camada de Governança e Enriquecimento

Assegurar a confiabilidade, rastreabilidade e utilidade dos dados.

• Vinculação ao Paciente: Os dados devem ser associados inequivocamente ao registro correto do paciente no VNA, utilizando mecanismos de autenticação robustos ou identificadores únicos validados.
• Controle de Qualidade: Implementar regras para sinalizar valores anômalos (ex.: pressão arterial sistólica > 300 mmHg) ou inconsistentes, acrescentando metadados de qualidade ao recurso FHIR.
• Enriquecimento de Metadados: Adicionar informações contextuais cruciais como a marca/modelo do dispositivo, timestamp de coleta e relatório, e a versão do parser utilizado.

4. Estratégia de Armazenamento no VNA

O VNA deve ser estendido para suportar novos tipos de dados de maneira otimizada.

• Recursos FHIR: A forma preferencial para armazenar PGHD processado. Modernos VNAs expõem endpoints FHIR para aceitar recursos como Observation.
• Dados Originais (Binários): Os arquivos brutos recebidos (PDFs, imagens) devem ser preservados como recursos Binary no FHIR, servindo como evidência de auditoria e vinculados aos recursos Observation normalizados.
• Dados de Alta Frequência: Para dados em série temporal de alto volume (ex.: ECG contínuo), uma abordagem em camadas é mais eficiente. Os dados brutos podem residir em um armazenamento de objetos de baixo custo ou em um banco de séries temporasi, enquanto apenas resumos e agregações (ex.: média diária, extremos) são convertidos em recursos Observation e armazenados no VNA para acesso clínico.

Exemplo de Transformação para FHIR

Considere a transformação de uma medição de pressão arterial vinda de um dispositivo não padronizado.

Dado Bruto (JSON simplificado):

{
    "fonte": "monitor_modelo_X",
    "paciente_cod": "usr789",
    "medicoes": {
        "pressao_sistolica": 125,
        "pressao_diastolica": 82,
        "pulso": 70
    },
    "unidade": "mmHg",
    "epoch": 1719859200
}

Dados Parseados e Normalizados:

• Chaves e valores extraídos.
• Mapeamento de terminologias:
  • pressao_sistolica → LOINC 8480-6
  • pressao_diastolica → LOINC 8462-4
  • Evento de medição → LOINC 85354-9
  • mmHg → UCUM mm[Hg]
  • epoch 1719859200 → 2024-07-01T12:00:00Z
  • paciente_cod "usr789" → ID do paciente no VNA: Pat101

Recurso FHIR Observation Resultante:

{
    "resourceType": "Observation",
    "status": "final",
    "category": [
        {
            "coding": [
                {
                    "system": "http://terminology.hl7.org/CodeSystem/observation-category",
                    "code": "vital-signs"
                }
            ]
        }
    ],
    "code": {
        "coding": [
            {
                "system": "http://loinc.org",
                "code": "85354-9",
                "display": "Painel de pressão arterial com todos os componentes opcionais"
            }
        ]
    },
    "subject": {
        "reference": "Patient/Pat101"
    },
    "effectiveDateTime": "2024-07-01T12:00:00Z",
    "component": [
        {
            "code": {
                "coding": [{"system": "http://loinc.org", "code": "8480-6"}]
            },
            "valueQuantity": {
                "value": 125,
                "unit": "mmHg",
                "system": "http://unitsofmeasure.org",
                "code": "mm[Hg]"
            }
        },
        {
            "code": {
                "coding": [{"system": "http://loinc.org", "code": "8462-4"}]
            },
            "valueQuantity": {
                "value": 82,
                "unit": "mmHg",
                "system": "http://unitsofmeasure.org",
                "code": "mm[Hg]"
            }
        }
    ]
}

Este recurso é então armazenado via API FHIR no VNA. O arquivo JSON original também pode ser salvo como um Binary e referenciado através do campo derivedFrom no Observation, garantindo a rastreabilidade completa.