Perguntas frequentes sobre a API do Azure para FHIR

O Fast Healthcare Interoperability Resources (FHIR - pronunciado "fire") é um padrão de interoperabilidade destinado a habilitar a troca de dados de saúde entre diferentes sistemas de integridade. Esse padrão foi desenvolvido pela organização HL7 e está sendo adotado por organizações de saúde em todo o mundo. A versão mais atual do FHIR disponível é a R4 (versão 4). A API do Azure para FHIR dá suporte a R4 e à versão anterior STU3 (Standard for Trial Use 3). Para saber mais sobre o FHIR, visite HL7.org.

Sim, os dados são armazenados em bancos de dados gerenciados no Azure. A API do Azure para FHIR não fornece acesso direto ao armazenamento de dados subjacente.

No serviço gerenciado, você não pode acessar os dados subjacentes. Isso é para garantir que a API do Azure para FHIR possa oferecer as certificações de privacidade e conformidade necessárias para dados de saúde. Se precisar de acesso aos dados subjacentes, você poderá usar o servidor FHIR de código aberto.

Damos suporte ao Microsoft Azure Active Directory como provedor de identidade.

Não, não damos suporte a B2C na API do Azure para FHIR. Se precisar de controles de acesso mais granulares, recomendamos examinar o proxy FHIR de código aberto.

Os dados do serviço gerenciado são armazenados automaticamente a cada quatro horas e dois backups são mantidos. Portanto, a duração da retenção é de oito horas. A recuperação de dados é feita pela equipe de suporte e o RPO (objetivo de ponto de recuperação) é menor que 240 minutos.

Os clientes podem fazer uma solicitação para restaurar os dados ou alterar a política de backup de dados padrão por meio de um tíquete de suporte.

Damos suporte às versões 4.0.0 e 3.0.1. Para obter mais informações, confira Recursos com suporte do FHIR. Você também pode ler sobre o que mudou entre as versões do FHIR (STU3 para R4) no histórico de versões do HL7 FHIR.

O Conector da Internet das Coisas do Azure para FHIR (versão prévia) atualmente dá suporte apenas à versão R4 do FHIR e está visível em instâncias R4 da API do Azure para FHIR.

A API do Azure para FHIR é um serviço FHIR gerenciado geralmente disponível. Os Serviços de Dados de Saúde do Azure permitem implantar um serviço FHIR e um serviço DICOM no mesmo workspace. A visão geral dos Serviços de Dados de Saúde do Azure fornece mais detalhes.

A API do Azure para FHIR é uma versão hospedada e gerenciada do Microsoft FHIR Server de software livre para Azure. No serviço gerenciado, a Microsoft fornece todas as atualizações e a manutenção.

Ao executar o FHIR Server para Azure, você terá acesso direto aos serviços subjacentes, mas somos responsáveis por manter e atualizar o servidor e todo o trabalho de conformidade necessário se estiver armazenando dados PHI.

Temos disponibilidade geral pública e governamental em várias regiões geográficas. Para saber mais sobre serviços de nuvem governamental na Microsoft, confira Serviços do Azure por FedRAMP.

A página de notas de versão dá uma visão geral de tudo o que já foi enviado para serviço gerenciado no mês anterior.

Para saber mais sobre o que será lançado na API do Azure para FHIR, confira versões do FHIR Server de código aberto. Trabalhamos para marcar itens com o Azure-API-for-FHIR se eles forem liberados para o serviço gerenciado e geralmente estiverem disponíveis duas semanas depois que eles estiverem na página de lançamento em software livre. Também incluímos instruções sobre como testar o build se você quiser testá-lo em seu próprio ambiente.

Para ver qual pacote de lançamentos está atualmente no serviço gerenciado, veja a declaração de capacidade da API do Azure para FHIR na propriedade software.version. Você verá qual pacote foi implantado.

Você pode encontrar a versão exata do FHIR exposta na declaração de capacidade na propriedade fhirVersion.

Não. Não temos uma maneira de alterar a versão de um banco de dados existente. Você precisará criar uma nova API do Azure para FHIR e recarregar os dados. Você pode tirar proveito do conversor JSON para FHIR como ponto de partida para converter dados STU3 em R4.

Não. Não é possível alterar a URL da API do Azure para FHIR.

SMART (Substitutable Medical Applications and Reusable Technology, Aplicativos Médicos Substituíveis e Tecnologia Reutilizável) no FHIR é um conjunto de especificações abertas para integrar aplicativos parceiros a servidores FHIR e outros sistemas de TI de integridade, como registros de saúde eletrônicos e trocas de informações de saúde. Ao criar um aplicativo SMART no FHIR, você pode fazer com que seu aplicativo possa ser acessado e aproveitado por uma infinidade de sistemas diferentes. Para saber mais sobre o SMART, visite o site SMART Health IT.

Sim, há suporte para a funcionalidade SMART on FHIR usando exemplos do AHDS. Isso é conhecido como SMART no FHIR(Avançado). SMART on FHIR(Enhanced) can be consider to meet requirements with SMART on FHIR Implementation Guide (v 1.0.0) and §170.315(g)(10) Standardized API for patient and population services criterion. Para obter mais informações, visite a Documentação do SMART on FHIR(Enhanced).

Não permitimos recursos FHIR personalizados. Se você precisar de um recurso FHIR personalizado, poderá criá-lo com base no recurso básico com extensões.

Permitimos que você carregue qualquer dado JSON FHIR válido no servidor. Se você quiser armazenar a definição de estrutura que define a extensão, poderá salvá-la como um recurso de definição de estrutura. Para pesquisar nas extensões, você precisará definir seus próprios parâmetros de pesquisa.

Seu recurso precisa ter um pouco menos de 2 MB. Essa é uma limitação do armazenamento de dados subjacente e não podemos aumentar esse valor.

No serviço gerenciado, só damos suporte a JSON. O servidor FHIR de software livre dá suporte a JSON e XML. Para exibir a versão XML de código aberto, use _format= application/fhir+xml.

O limite atual de _count é 1000. Se você definir _count para mais de 1000, receberá um aviso no pacote de que apenas 1000 registros serão mostrados.

No caso de Exportação de Grupo, exportamos somente as referências incluídas do grupo e não todas as características do grupo de recursos.

Atualmente damos suporte à postagem de pacotes em lote, mas não damos suporte à postagem de pacotes de transação na API do Azure para FHIR. Você pode usar o serviço FHIR nos Serviços de Dados de Saúde do Azure se precisar de suporte ao pacote de transações.

Você pode usar a operação Patient-$everything, ou pode usar uma pesquisa de compartimento na API do Azure para FHIR. Isso permite que você obtenha todos os recursos relacionados a um paciente específico. Observe que o compartimento do paciente inclui todos os recursos relacionados ao paciente, mas não ao próprio paciente e, portanto, você precisará também pesquisar para obter o paciente se precisar do recurso do paciente em seus resultados.

Damos suporte à classificação pela data da última atualização: _sort=_lastUpdated. Também damos suporte a _sort nos elementos FirstName, LastName, BirthDate e ClinicalDate. Para saber mais sobre outros parâmetros de pesquisa com suporte, confira Visão geral da Pesquisa do FHIR.

Sim, temos suporte a patient-$everything. Para saber mais, confira otutorial de patient-$everything.

Não, a API do Azure para FHIR não dá suporte a operações de terminologia atualmente.

$export é parte da especificação de FHIR. Se o serviço FHIR estiver configurado com uma identidade gerenciada e uma conta de armazenamento, e se a identidade gerenciada tiver acesso a essa conta de armazenamento, você poderá chamar $export na API do FHIR e todos os recursos de FHIR serão exportados para a conta de armazenamento. Para saber mais, confira o artigo $export.

Temos uma ferramenta de software livre para remover a identificação de dados de FHIR. A mesma tecnologia também está integrada à API do Azure para FHIR na forma de exportação desidentificada.

Atualmente, há suporte à exportação anônima somente em uma exportação completa do sistema (/$export) e não à exportação do paciente (/Paciente/$export). Estamos trabalhando para disponibilizá-lo no nível do paciente também.

Há dois tipos básicos de Exclusão com suporte na API do Azure para FHIR. Eles são Exclusão e Exclusão Condicional.

• Com Exclusão, você pode optar por fazer uma exclusão reversível (tipo mais comum) e ainda conseguir recuperar versões históricas do seu registro.
• Com a Exclusão Condicional, você pode transmitir um critério de pesquisa para excluir um recurso de um item por vez ou vários de cada vez.
• Com Exclusão ou Exclusão Condicional, se você transmitiu o parâmetro hardDelete, todos os registros e o histórico serão excluídos e não poderão ser recuperados.

Você pode recuperar arquivos excluídos se não usar o parâmetro hardDelete. Os registros na API do Azure para FHIR ainda devem existir. Os registros podem ser encontrados por uma pesquisa de histórico no recurso e com a procura da última versão com dados.

Para obter detalhes sobre a habilitação de logs e consultas de amostra, confira Habilitar log de diagnósticos na API do Azure para FHIR. Se você quiser incluir outras informações nos logs, confira Usando cabeçalhos HTTP personalizados.

Para resolver isso, você pode aumentar a taxa de transferência ou mudar para dimensionamento automático a fim de garantir computação suficiente para processar as solicitações. Se você ainda tiver problemas, abra um tíquete de suporte.

O valor mínimo de RU precisa ser pelo menos 40 RUs/GB. À medida que você carrega dados, as RUs no banco de dados aumentarão se você estiver abaixo desse valor mínimo.

Temos uma coleção de arquiteturas de referência disponíveis na página do GitHub Arquitetura de Integridade.

Para executar marcar de integridade no serviço FHIR, insira {{fhirurl}}/health/check na solicitação GET. Você deve ser capaz de ver o Status do serviço FHIR. A resposta de código de status HTTP com 200 e OverallStatus como "Íntegro" em resposta significa que sua marcar de integridade foi bem-sucedida. Em caso de erros, você receberá uma resposta de erro com HTTP status código 404 (Não Encontrado) ou status código 500 (Erro interno do servidor) e informações detalhadas no corpo da resposta em alguns cenários.

Sim, a API do Azure para FHIR permite configurar chaves gerenciadas pelo cliente tirando proveito do suporte do Azure Cosmos DB. Para saber mais sobre como criptografar seus dados com uma chave pessoal, confira Configurar chaves gerenciadas pelo cliente em REST.