Formato de datos de la PHR

Los datos de los registros de salud personales (PHR) se almacenan en el formato HL7 FHIR.

La PHR admite las siguientes versiones de recursos de interoperabilidad para atención médica rápida (FHIR):

Tipos de recursos médicos

FHIR se compone de un conjunto de componentes modulares llamados recursos. El conjunto de recursos de FHIR admitidos y las categorías correspondientes se basan, en términos generales, en las secciones de resumen de pacientes internacionales.

Estos recursos se asignan a categorías de datos en Health Connect, que se denominan tipos de recursos médicos en la API. Los recursos de observación se asignan en función de contenido, como los códigos de los nombres y códigos de los identificadores de observación lógica (LOINC) y las categorías de FHIR.

Las observaciones que no pertenecen a ninguna de estas categorías no se escriben en Health Connect.

Tabla 1: Tipos de recursos médicos de Health Connect
Tipo de recurso médico de Health Connect Recursos de FHIR
Alergias AllergyIntolerance
Condiciones Condition
Laboratorio

Observación

  • Categoría laboratory de FHIR
Medicamentos Medication, MedicationRequest, MedicationStatement
Detalles personales Paciente
Detalles del profesional Practitioner, PractitionerRole
Embarazo

Observación

  • Códigos LOINC de embarazo
Procedimientos Procedimiento
Historia social

Observación

  • Códigos de LOINC de la historia social
  • Categoría social-history de FHIR
Vacunas Vacunación
Visitas Encuentro, ubicación y organización
Signos vitales

Observación

  • Códigos LOINC de los signos vitales
  • Categoría vital-signs de FHIR

Recursos para pacientes

Por el momento, Health Connect está diseñado para almacenar datos de PHR de una sola persona. Por lo tanto, todos los recursos de FHIR escritos deben pertenecer a la misma persona.

No es raro que existan varios recursos de pacientes de FHIR en un sistema para una sola persona. Se prefiere que las apps concilien los datos y escriban un solo recurso de paciente en Health Connect. Sin embargo, esto no se aplica para adaptarse a las diferentes estructuras organizativas que puedan existir.

Validación de datos

Las APIs de PHR aceptan recursos de FHIR válidos de las versiones compatibles, y Health Connect realiza algunas validaciones para confirmar que se sigue la especificación de FHIR para cada versión compatible.

Las verificaciones de validación marcadas como Próximamente aún no se aplican, pero lo harán en una versión futura. Te recomendamos que desarrolles con todas las verificaciones de validación enumeradas para mantener la compatibilidad con versiones futuras.

Tabla 2: Validación de Health Connect de los datos de FHIR
Nivel Verificación de validación
JSON válido Los datos cumplen con el formato JSON.
FHIR compatible

Se admite la versión de FHIR que declara la aplicación de escritura. Health Connect admite las siguientes versiones de FHIR:

  • 4.0.1
  • 4.3.0
FHIR compatible

Se admite el tipo de recurso de FHIR registrado en la instancia de recurso. Health Connect admite los siguientes tipos de recursos de FHIR:

  • AllergyIntolerance
  • Condition
  • Encounter
  • Vacunación
  • Ubicación
  • Medicamentos
  • MedicationRequest
  • MedicationStatement
  • Observación
  • Organización
  • Paciente
  • Profesionales
  • PractitionerRole
  • Procedimiento
ID de recurso único El recurso tiene un campo de ID con un valor que cumple con los requisitos de la expresión regular.
ID de recurso único El recurso no comparte un ID con otro recurso de FHIR del mismo tipo de recurso del mismo MedicalDataSource.
Reglas de negocio No incluye un recurso de FHIR contenido. Los recursos contenidos son recursos de FHIR anidados dentro de un recurso “superior”. Se usan cuando el recurso superior necesita hacer referencia a otro recurso, pero el sistema no tiene suficiente información para crearlo como un recurso independiente con existencia independiente.
FHIR de base válido Los campos de nivel superior en el JSON de FHIR existen en la especificación de FHIR para el tipo de recurso determinado.
FHIR de base válido Los campos de nivel superior no tienen valores nulos de JSON.
FHIR de base válido Todos los campos obligatorios de nivel superior están presentes.
FHIR de base válido Los campos de nivel superior definidos como elementos repetidos en FHIR tienen un tipo de datos array de JSON.
FHIR de base válido Los campos de nivel superior (incluidos los elementos dentro de los array de JSON) definidos como tipos complejos en FHIR tienen un tipo de datos object de JSON.
FHIR de base válido Los campos de nivel superior (incluidos los elementos dentro de los array de JSON) definidos como tipos primitivos en FHIR tienen el tipo de datos JSON correcto.
Tipo de datos de FHIR Tipo de datos JSON
integer, unsignedInt, positiveInt, decimal número
boolean boolean
instant, time, date, dateTime, string, code, markdown, id uri, url, oid, uuid, canonical, integer64, base64Binary número
Próximamente
FHIR de base válido Los campos de nivel superior definidos como tipos primitivos en FHIR cumplen con los requisitos de las expresiones regulares. Próximamente
FHIR de base válido Las extensiones a los tipos primitivos existen en la especificación de FHIR y tienen un tipo de datos object JSON.
FHIR de base válido No se registra más de un campo para los campos de elección (fieldname[x]).Por ejemplo, effectiveDateTime y effectivePeriod no pueden estar presentes en la misma instancia de recurso.
FHIR de base válido Los tipos de datos complejos contienen campos y tipos de datos que coinciden con la especificación de FHIR. Próximamente
FHIR de base válido Los elementos de médula (y los elementos dentro de los tipos complejos) contienen campos y tipos de datos que coinciden con la especificación de FHIR. Próximamente
FHIR de base válido Los campos value[x] del elemento de extensiones son un tipo válido y contienen contenido según ese tipo de datos. Los elementos de extensión se pueden incluir en cualquier recurso para representar información adicional que no forma parte de la especificación base. Contienen un campo url que vincula a la definición de la extensión y un campo value[x] que contiene el valor de la extensión. value[x] debe provenir de la lista establecida de tipos de datos aceptados. Próximamente

Datos de FHIR transformados

Algunas apps transforman los datos de FHIR para cumplir con sus propios requisitos. Por ejemplo:

  • Combinar datos de diferentes fuentes (por lo general, APIs de FHIR)
  • Asignar códigos a terminologías globales (por ejemplo, SNOMED, LOINC, ICD) y estandarizar las unidades
  • Consolidación y anulación de la duplicación de datos
  • Corregir el formato o cualquier otro problema de calidad de los datos
  • Filtrar registros según reglas comerciales específicas de la app

Los datos de FHIR no transformados y transformados se pueden escribir en Health Connect, siempre que cumplan con la especificación FHIR R4. Te recomendamos que escribas datos transformados siempre que sea posible. Sin embargo, ten en cuenta las siguientes consideraciones:

  • Las apps con casos de uso limitados pueden filtrar una cantidad significativa de registros con los que otras apps del ecosistema podrían crear valor para el usuario. En tales situaciones, puede ser beneficioso escribir el FHIR no transformado que sea más completo. Sin embargo, asegúrate de informar a los usuarios que se comparte este conjunto de datos más amplio.
  • Si combinas datos que provienen de diferentes fuentes, puedes escribir los datos en un solo MedicalDataSource en Health Connect. También debes asignar un ID nuevo a cada recurso para evitar conflictos y actualizar las referencias de recursos para que apunten a los IDs nuevos.
  • La combinación de datos de varias fuentes en un solo MedicalDataSource puede ocultar el origen de los datos. Como a menudo es útil para los consumidores de datos comprender la procedencia de los datos, te recomendamos que propagues el campo meta.source para cada recurso con la fuente original del registro (por lo general, una URL base de FHIR).