La plataforma de Health Connect proporciona una variedad de tipos de datos, que abarcan principalmente casos de uso de bienestar y fitness, lo que permite que las apps del ecosistema de Android compartan datos sin necesidad de integraciones de API individuales de alto costo. Los registros de salud personales (PHR) extienden esta capacidad para incluir datos médicos básicos en formato Fast Healthcare Interoperability Resources (FHIR®), incluidos los siguientes:
- Una API para aplicaciones que escriben datos médicos.
- Una experiencia de navegador para el usuario para los datos médicos almacenados en Health Connect como nuevos tipos de datos médicos, junto con permisos detallados para permitir lecturas descendentes.
- Una API para aplicaciones que leen datos médicos según los permisos otorgados por el usuario.
Las APIs de PHR están disponibles a través del SDK de Android 16. Consulta Cómo configurar el SDK de Android 16 para obtener instrucciones sobre cómo comenzar.
Limitaciones
Como estas APIs aún están en desarrollo, aún existen algunas limitaciones y algunos componentes no están disponibles por completo.
- Por lo general, el SDK de Health Connect para Jetpack se usa para simplificar la integración uniendo las APIs de Health Connect, pero aún no están disponibles, por lo que se deben usar las APIs subyacentes del framework de Android.
- La Política de Play para el acceso a la PHR aún está en desarrollo, y es posible que las apps deban cumplir con requisitos adicionales para poder lanzarse en Play Store.
- Algunas funciones, como las APIs basadas en registros de cambios, aún no se desarrollaron para las APIs de PHR.
Formato de datos de la PHR
Los datos del PHR se almacenan en el formato HL7 FHIR, que inicialmente solo admite la versión R4.
Validación de datos
Las APIs de PHR aceptan recursos de FHIR R4 válidos, y Health Connect realizará algunas validaciones para garantizar que se siga la especificación de FHIR R4.
Las verificaciones de validación marcadas como Próximamente aún no se aplican, pero lo harán en una versión futura. Recomendamos desarrollar con todas las verificaciones de validación enumeradas para evitar problemas con versiones futuras.
| 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:
|
||||||||
| 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:
|
||||||||
| 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 contiene 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 crear 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 | 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.
|
||||||||
| 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 |
||||||||
| FHIR de base válido | Todos los campos obligatorios de nivel superior están presentes. |
Categorías de datos
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:
- Categoría de intolerancia a las alergias: Contiene recursos de AllergyIntolerance.
- Categoría Condiciones: Contiene recursos de condición.
- Categoría Visitas: Contiene recursos de encuentro, ubicación y organización.
- Categoría Vacunas: Contiene recursos de inmunización.
- Categoría de detalles personales: Contiene recursos de paciente.
- Categoría Detalles del profesional: Contiene recursos de Practitioner y PractitionerRole.
- Categoría Procedimientos: Contiene recursos de procedimientos.
- Categoría de medicamentos: Contiene los recursos Medication, MedicationRequest y MedicationStatement.
Los recursos de observación se clasifican según su contenido:
- Embarazo: Se basa en los códigos LOINC de embarazo.
- Historia social: Se basa en los códigos LOINC de historia social o en la categoría “social-history” de FHIR.
- Signos vitales: Se basan en los códigos LOINC de los signos vitales o en la categoría "signos vitales" de FHIR.
- Laboratorio: Se basa en la categoría "laboratorio" de FHIR.
Las observaciones que no pertenecen a ninguna de estas categorías no se escriben en Health Connect.
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. Preferimos escribir apps para conciliar datos y escribir un solo recurso de paciente en Health Connect. Sin embargo, esto no se aplica para adaptarse a las diferentes estructuras organizativas que puedan existir.
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
MedicalDataSourceen 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
MedicalDataSourcepuede 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 campometa.sourcepara cada recurso con la fuente original del registro (por lo general, una URL base de FHIR).
Experiencia del usuario
En esta sección, se proporciona información general sobre la experiencia del usuario.
Permisos
Solicitar permisos de lectura o escritura de registros médicos se comporta de manera similar a las pantallas de permisos existentes de Health Connect, pero se muestra una pantalla de registros de salud independiente:
Navegación de datos
Health Connect también proporciona visualización y navegación básicas de los datos del PHR almacenados, similares a los tipos de datos de Health Connect existentes.
