A plataforma Conexão Saúde oferece uma gama de tipos de dados, principalmente para casos de uso de bem-estar e condicionamento físico, permitindo que os apps no ecossistema Android compartilhem dados sem a necessidade de integrações de API um-para-um de alto custo. Os registros de saúde pessoais (PHRs) estendem esse recurso para incluir dados médicos básicos no formato Recursos rápidos de interoperabilidade de saúde (FHIR®), incluindo:
- Uma API para apps que gravam dados médicos.
- Uma experiência de navegador voltada ao usuário para dados médicos armazenados no app Conexão Saúde como novos tipos de dados médicos, além de permissões detalhadas para permitir leituras downstream.
- Uma API para aplicativos que leem dados médicos com base nas permissões concedidas pelo usuário.
As APIs de PHR são disponibilizadas pelo SDK do Android 16. Consulte Configurar o SDK do Android 16 para instruções sobre como começar.
Limitações
Como essas APIs ainda estão em desenvolvimento, ainda há algumas limitações e alguns componentes não estão totalmente disponíveis.
- O SDK do Jetpack para a Conexão Saúde geralmente é usado para simplificar a integração ao agrupar as APIs da Conexão Saúde. No entanto, como elas ainda não estão disponíveis, é necessário usar as APIs do framework Android.
- A política do Google Play para acesso a PHRs ainda está sendo desenvolvida, e os apps podem precisar atender a outros requisitos antes de serem lançados na Play Store.
- Alguns recursos, como APIs baseadas em registros de mudanças, ainda não foram desenvolvidos para APIs de PHR.
Formato de dados do PHR
Os dados do PHR são armazenados no formato HL7 FHIR, que inicialmente oferece suporte apenas à versão R4.
Validação de dados
As APIs de PHR aceitam recursos válidos do FHIR R4, e o Health Connect vai realizar algumas validações para garantir que a especificação do FHIR R4 seja 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 evitar problemas com versões futuras.
| 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:
|
||||||||
| FHIR com suporte | O tipo de recurso FHIR registrado na instância de recurso é aceito. O Conexão Saúde oferece suporte aos seguintes tipos de recurso FHIR:
|
||||||||
| ID exclusivo do recurso | O recurso tem um campo de ID com um valor que atende aos requisitos de expressão regular. | ||||||||
| ID exclusivo do recurso | 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 contém 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 um recurso independente com existência independente. |
||||||||
| Base FHIR válida | Os campos de nível superior no JSON do FHIR existem na especificação do FHIR para o tipo de recurso fornecido. | ||||||||
| FHIR de base válido | Os campos de nível superior não têm valores nulos JSON. | ||||||||
| Base FHIR válida | Os campos de nível superior definidos como
elementos recorrentes 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.
|
||||||||
| 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 |
||||||||
| FHIR de base válido | 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 |
||||||||
| FHIR de base válido | 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 outras informações 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 |
||||||||
| FHIR de base válido | Todos os campos obrigatórios de nível superior estão presentes. |
Categorias de dados
O conjunto de recursos FHIR e as categorias correspondentes com suporte são baseados aproximadamente nas seções do resumo internacional do paciente:
- Categoria de intolerância a alergias: contém recursos de AllergyIntolerance.
- Categoria "Condições": contém recursos de condição.
- Categoria "Visitas": contém recursos de encontro, local e organização.
- Categoria "Vacinas": contém recursos de imunização.
- Categoria de detalhes pessoais: contém recursos de pacientes.
- Categoria "Detalhes do profissional de saúde": contém recursos de "Profissional de saúde" e "Função do profissional de saúde".
- Categoria "Procedimentos": contém recursos de procedimento.
- Categoria de medicamentos: contém os recursos Medication, MedicationRequest e MedicationStatement.
Os recursos de observação são categorizados com base no conteúdo:
- Gravidez: com base nos códigos LOINC de gravidez.
- História social: baseada em códigos LOINC de história social ou na categoria FHIR "social-history".
- Sinais vitais: com base em códigos LOINC de sinais vitais ou na categoria "sinais-vitais" do FHIR.
- Laboratório: com base na categoria FHIR "laboratório".
As observações que não pertencem a nenhuma dessas categorias não são gravadas no Health Connect.
Recursos para pacientes
No momento, a Conexão Saúde tem como objetivo armazenar dados de PHR apenas para 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. Preferimos criar apps para reconciliar dados e gravar 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.
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 escrever 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
MedicalDataSourcena 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
MedicalDataSourcepode obscurecer a origem dos dados. Como geralmente é útil para os consumidores de dados entender a procedência dos dados, recomendamos preencher o campometa.sourcede cada recurso com a origem original do registro (normalmente um URL base do FHIR).
Experiência do usuário
Informações gerais sobre a experiência do usuário são fornecidas nesta seção.
Permissões
Solicitar permissões de leitura ou gravação de registros médicos se comporta de maneira semelhante às telas de permissões do Conexão Saúde, mas uma tela de registros de saúde separada é mostrada:
Navegação de dados
A Conexão Saúde também oferece visualização e navegação básicas dos dados de PHR armazenados, semelhantes aos tipos de dados da Conexão Saúde.
