Formato de dados do PHR

Os dados de registros de saúde pessoais (PHRs, na sigla em inglês) são armazenados no formato HL7 FHIR.

O PHR oferece suporte às seguintes versões de recursos rápidos de interoperabilidade de saúde (FHIR, na sigla em inglês):

Tipos de recursos médicos

O FHIR é composto por um conjunto de componentes modulares chamados de recursos. O conjunto de recursos do FHIR e as categorias correspondentes compatíveis são baseados aproximadamente nas seções do resumo internacional do paciente.

Esses recursos são mapeados para categorias de dados no Conexão Saúde, chamados de tipos de recursos médicos na API. Os recursos de observação são mapeados com base em conteúdos como códigos de nomes e códigos de identificadores de observação lógica (LOINC, na sigla em inglês) e categorias FHIR.

As observações que não pertencem a nenhuma dessas categorias não são gravadas na Conexão Saúde.

Tabela 1: tipos de recursos médicos do Health Connect
Tipo de recurso médico da Conexão Saúde Recursos do FHIR
Alergias AllergyIntolerance
Condições Condição
Laboratório

Observação

  • Categoria FHIR laboratory
Medicamentos Medication, MedicationRequest, MedicationStatement
Dados pessoais Paciente
Detalhes do profissional de saúde Profissional de saúde, PractitionerRole
Gravidez

Observação

  • Códigos LOINC de gravidez
Procedimentos Procedimento
História social

Observação

  • Códigos de LOINC da história social
  • Categoria FHIR social-history
Vacinas Imunização
Visitas Encontro, local, organização
Sinais vitais

Observação

  • Códigos LOINC de sinais vitais
  • Categoria FHIR vital-signs

Recursos para pacientes

No momento, a Conexão Saúde tem como objetivo armazenar dados de PHR de um único indivíduo. Portanto, todos os recursos FHIR escritos precisam pertencer à mesma pessoa.

Não é incomum que vários recursos de paciente do FHIR existam em um sistema para uma única pessoa. É recomendável que os apps conciliem dados e gravem um único recurso de paciente na Conexão Saúde. No entanto, isso não é aplicado para acomodar as diferentes estruturas organizacionais que podem existir.

Validação de dados

As APIs de PHR aceitam recursos FHIR válidos das versões com suporte, e o Health Connect realiza algumas validações para confirmar que a especificação FHIR para cada versão com suporte é seguida.

As verificações de validação marcadas como Em breve ainda não são aplicadas, mas serão em uma versão futura. Recomendamos o desenvolvimento de acordo com todas as verificações de validação listadas para manter a compatibilidade com versões futuras.

Tabela 2: validação da Conexão Saúde dos dados do FHIR
Nível Verificação de validação
JSON válido Os dados são compatíveis com o formato JSON.
FHIR com suporte

A versão do FHIR declarada pelo aplicativo de gravação é aceita. As seguintes versões do FHIR são compatíveis com a Conexão Saúde:

  • 4.0.1
  • 4.3.0
FHIR com suporte

O tipo de recurso FHIR registrado na instância do recurso é aceito. O Conexão Saúde oferece suporte aos seguintes tipos de recurso FHIR:

  • AllergyIntolerance
  • Condição
  • Encounter
  • Imunização
  • Local
  • Medicamento
  • MedicationRequest
  • MedicationStatement
  • Observação
  • Organização
  • Paciente
  • Profissional de saúde
  • PractitionerRole
  • Procedimento
ID exclusivo do recurso O recurso tem um campo de ID com um valor que atende aos requisitos de expressão regular.
ID de recurso exclusivo O recurso não compartilha um ID com outro recurso FHIR do mesmo tipo de recurso do mesmo MedicalDataSource.
Regras de negócios Não inclui um recurso FHIR contido. Os recursos contidos são recursos FHIR aninhados em um recurso "pai". Elas são usadas quando o recurso pai precisa referenciar outro recurso, mas o sistema não tem informações suficientes para criar esse recurso como um recurso independente com existência independente.
FHIR de base válido Os campos de nível superior no JSON do FHIR existem na especificação do FHIR para o tipo de recurso especificado.
Base FHIR válida Os campos de nível superior não têm valores nulos JSON.
Base FHIR válida Todos os campos obrigatórios de nível superior estão presentes.
Base FHIR válida Os campos de nível superior definidos como elementos repetitivos no FHIR têm um tipo de dados JSON array.
FHIR de base válido Os campos de nível superior (incluindo elementos em arrays JSON) definidos como tipos complexos no FHIR têm um tipo de dados object JSON.
FHIR de base válido Os campos de nível superior (incluindo elementos em arrays JSON) definidos como tipos primitivos no FHIR têm o tipo de dados JSON correto.
Tipo de dados FHIR Tipo de dados JSON
integer, unsignedInt, positiveInt, decimal número
booleano booleano
instant, time, date, dateTime, string, code, markdown, id uri, url, oid, uuid, canonical, integer64, base64Binary número
Em breve
Base FHIR válida Os campos de nível superior definidos como tipos primitivos no FHIR atendem aos requisitos de expressão regular. Em breve
Base FHIR válida As extensões para tipos primitivos existem na especificação FHIR e têm um tipo de dados object JSON.
FHIR de base válido Não é possível registrar mais de um campo para Campos de escolha (fieldname[x]).Por exemplo, effectiveDateTime e effectivePeriod não podem estar presentes na mesma instância de recurso.
FHIR de base válido Os tipos de dados complexos contêm campos e tipos de dados que correspondem à especificação FHIR. Em breve
Base FHIR válida Os elementos de backbone (e os elementos em tipos complexos) contêm campos e tipos de dados que correspondem à especificação FHIR. Em breve
FHIR de base válido Os campos Extensions element value[x] são um tipo válido e contêm conteúdo de acordo com esse tipo de dados. Os elementos de extensão podem ser incluídos em qualquer recurso para representar informações adicionais que não fazem parte da especificação básica. Eles contêm um campo url que vincula à definição da extensão e um campo value[x] que contém o valor da extensão. value[x] precisa ser de uma lista definida de tipos de dados aceitos. Em breve

Dados FHIR transformados

Alguns apps transformam os dados do FHIR para atender aos próprios requisitos. Exemplo:

  • Mesclar dados de diferentes fontes (normalmente APIs FHIR).
  • Mapear códigos para terminologias globais (por exemplo, SNOMED, LOINC, ICD) e padronizar unidades.
  • Consolidar e eliminar a duplicação de dados.
  • Corrigir a formatação ou outros problemas de qualidade de dados.
  • Filtrar registros com base em regras de negócios específicas do app.

Os dados FHIR não transformados e transformados podem ser gravados na Conexão Saúde, desde que estejam em conformidade com a especificação FHIR R4. Recomendamos que você grave dados transformados sempre que possível. No entanto, considere as seguintes considerações:

  • Apps com casos de uso limitados podem filtrar um número significativo de registros que outros apps no ecossistema podem usar para criar valor para o usuário. Em tais situações, pode ser útil gravar o FHIR não transformado, que é mais completo. No entanto, informe aos usuários que esse conjunto de dados mais amplo está sendo compartilhado.
  • Se você estiver mesclando dados de origens diferentes, poderá gravar dados em um único MedicalDataSource na Conexão Saúde. Você também precisa atribuir um novo ID a cada recurso para evitar conflitos e atualizar as referências de recursos para apontar para os novos IDs.
  • A mesclagem de dados de várias fontes em um único MedicalDataSource pode obscurecer a origem dos dados. Como geralmente é útil para os consumidores de dados entender a procedência dos dados, recomendamos preencher o campo meta.source de cada recurso com a origem original do registro (normalmente um URL base do FHIR).