Perguntas mais frequentes sobre a API do Azure para FHIR

Fast Healthcare Interoperability Resources (FHIR – Pronunciado "fire") é uma norma de interoperabilidade destinada a permitir a troca de dados de cuidados de saúde entre diferentes sistemas de saúde. Esta norma foi desenvolvida pela organização HL7 e está a ser adotada por organizações de cuidados de saúde em todo o mundo. A versão mais atual do FHIR disponível é R4 (Versão 4). A API do Azure para FHIR suporta R4 e a versão anterior STU3 (Standard for Trial Use 3). Para obter mais informações sobre o FHIR, visite HL7.org.

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

No serviço gerido, não pode aceder aos dados subjacentes. Isto é para garantir que a API do Azure para FHIR oferece as certificações de privacidade e conformidade necessárias para os dados de cuidados de saúde. Se precisar de acesso aos dados subjacentes, pode utilizar o servidor FHIR de código aberto.

Suportamos Microsoft Azure Active Directory como fornecedor de identidade.

Não, não suportamos b2C na API do Azure para FHIR. Se precisar de controlos de acesso mais granulares, recomendamos que veja o proxy FHIR de código aberto.

Os dados do serviço gerido são efetuados automaticamente cópias de segurança a cada 4 horas e são mantidas duas cópias de segurança. Assim, a duração da retenção é de 8 horas. A recuperação de dados é feita pela equipa de suporte e o objetivo do ponto de recuperação (RPO) é inferior a 240 minutos.

Os clientes podem fazer um pedido para restaurar os dados ou alterar a política de cópia de segurança de dados predefinida através de um pedido de suporte.

Suportamos as versões 4.0.0 e 3.0.1. Para obter mais informações, veja as funcionalidades suportadas pelo FHIR. Também pode ler sobre o que mudou entre as versões FHIR (STU3 para R4) no histórico de versões do HL7 FHIR.

Atualmente, o Azure IoT Connector para FHIR (pré-visualização) suporta apenas a 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 gerido geralmente disponível. Os Serviços de Dados de Saúde do Azure permitem-lhe implementar um serviço FHIR e um serviço DICOM na mesma área de trabalho. A descrição geral dos Serviços de Dados de Saúde do Azure fornece mais detalhes.

A API do Azure para FHIR é uma versão alojada e gerida do Microsoft FHIR Server de código aberto para o Azure. No serviço gerido, a Microsoft fornece toda a manutenção e atualizações.

Quando executa o Servidor FHIR para o Azure, tem 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 a armazenar dados PHI.

Temos disponibilidade geral tanto para o público como para a administração pública em várias regiões geográficas. Para obter informações sobre serviços cloud governamentais na Microsoft, veja Serviços do Azure da FedRAMP.

A página de notas de versão fornece uma descrição geral de tudo o que foi enviado para o serviço gerido no mês anterior.

Para obter mais informações sobre o que está a ser lançado na API do Azure para FHIR, veja lançamentos do Servidor FHIR open source. Trabalhámos para etiquetar itens com o Azure-API-for-FHIR se forem lançados para o serviço gerido e estiverem normalmente disponíveis duas semanas depois de estarem na página de lançamento em open source. Também incluímos instruções sobre como testar a compilação se quiser testar no seu próprio ambiente.

Para ver que pacote de versão está atualmente no serviço gerido, pode ver a instrução de capacidade da API do Azure para FHIR na software.version propriedade . Verá que pacote está implementado.

Pode encontrar a versão exata do FHIR exposta na instrução de capacidade na fhirVersion propriedade .

N.º Não temos uma forma de alterar a versão de uma base de dados existente. Terá de criar uma nova API do Azure para FHIR e recarregar os dados. Pode tirar partido do conversor JSON para FHIR como um local para começar com a conversão de dados STU3 em R4.

N.º Não pode alterar o URL da API do Azure para FHIR.

SMART (Aplicações Médicas Substituíveis e Tecnologia Reutilizável) no FHIR é um conjunto de especificações abertas para integrar aplicações parceiras com servidores FHIR e outros sistemas de TI de Estado de Funcionamento, tais como Registos de Estado de Funcionamento Eletrónico e Trocas de Informações de Estado de Funcionamento. Ao criar uma aplicação SMART no FHIR, pode garantir que a sua aplicação pode ser acedida e aproveitada por uma panóplia de sistemas diferentes. Para obter mais informações sobre o SMART, visite o site de TI do SMART Health .

Sim, a capacidade SMART no FHIR é suportada com exemplos do AHDS. Isto é referido como SMART on FHIR(Enhanced). O SMART on FHIR(Enhanced) pode ser considerado para cumprir os requisitos com o SMART no Guia de Implementação do FHIR (v 1.0.0) e o critério de API Padronizada para pacientes e serviços populacionais . Para obter mais informações, visite a Documentação smart on FHIR(Enhanced).

Não permitimos recursos FHIR personalizados. Se precisar de um recurso FHIR personalizado, pode criar um recurso personalizado sobre o recurso Básico com extensões.

Permitimos que carregue quaisquer dados JSON FHIR válidos para o servidor. Se quiser armazenar a definição de estrutura que define a extensão, pode guardá-la como um recurso de definição de estrutura. Para procurar extensões, terá de definir os seus próprios parâmetros de pesquisa.

O recurso tem de ter pouco menos de 2 MB. Esta é uma limitação do arquivo de dados subjacente e não podemos aumentar este valor.

No serviço gerido, só suportamos JSON. O servidor FHIR de código aberto suporta JSON e XML. Para ver a versão XML em open source, utilize _format= application/fhir+xml.

O limite atual no _count é 1000. Se definir _count para mais de 1000, receberá um aviso no pacote a indicar que apenas serão apresentados 1000 registos.

Para Exportação de Grupo, exportamos apenas as referências incluídas do grupo e não todas as características do recurso de grupo.

Atualmente, suportamos a publicação de pacotes de lotes, mas não suportamos a publicação de pacotes de transações na API do Azure para FHIR. Pode utilizar o serviço FHIR nos Serviços de Dados de Saúde do Azure se precisar de suporte do pacote de transações.

Pode utilizar a operação patient-$everything ou pode utilizar uma pesquisa de compartimento na API do Azure para FHIR. Isto permite-lhe obter todos os recursos relacionados com um paciente específico. Tenha em atenção que o compartimento do paciente inclui todos os recursos relacionados com o paciente, mas não o próprio paciente, pelo que também terá de procurar para obter o paciente se precisar do recurso do paciente nos resultados.

Suportamos a ordenação até à data da última atualização: _sort=_lastUpdated. Também suportamos _sort em elementos FirstName, LastName, BirthDate e ClinicalDate. Para obter mais informações sobre outros parâmetros de pesquisa suportados, veja Descrição geral da Pesquisa FHIR.

Sim, temos apoio para $everything pacientes. Para obter mais informações, consulte o guia de procedimentos $Everything paciente.

Não, a API do Azure para FHIR não suporta operações de terminologia hoje em dia.

$export faz parte da especificação FHIR. Se o serviço FHIR estiver configurado com uma identidade gerida e uma conta de armazenamento e se a identidade gerida tiver acesso a essa conta de armazenamento, pode chamar $export na API FHIR e todos os recursos FHIR serão exportados para a conta de armazenamento. Para obter mais informações, consulte o artigo $export.

Temos uma ferramenta open source para desidentificador dados FHIR. A mesma tecnologia também está integrada na API do Azure para FHIR na forma de exportação desidentificado .

A exportação anonimizada é atualmente suportada apenas numa exportação completa do sistema (/$export) e não na exportação do Paciente (/Paciente/$export). Estamos a trabalhar para disponibilizá-lo ao nível do Paciente também.

Existem dois tipos básicos de Eliminação suportados na API do Azure para FHIR. Estes são Eliminar e Eliminar Condicional.

• Com a opção Eliminar, pode optar por efetuar uma eliminação recuperável (tipo mais comum) e continuar a conseguir recuperar versões históricas do seu registo.
• Com a Eliminação Condicional, pode transmitir um critério de pesquisa para eliminar um recurso um item de cada vez ou vários de cada vez.
• Com Eliminar ou Eliminar Condicional, se tiver passado o hardDelete parâmetro, todos os registos e históricos serão eliminados e irrecuperáveis.

Pode recuperar ficheiros eliminados se não utilizar o hardDelete parâmetro. Os registos na API do Azure para FHIR ainda devem existir. Os registos podem ser encontrados ao fazer uma pesquisa de histórico no recurso e ao procurar a última versão com dados.

Para obter detalhes sobre como ativar registos de auditoria e consultas de exemplo, veja Ativar o Registo de Diagnósticos na API do Azure para FHIR. Se quiser incluir informações adicionais nos registos, consulte utilizar cabeçalhos HTTP personalizados.

Para resolver este problema, pode aumentar o débito ou mudar para o dimensionamento automático para garantir que tem computação suficiente para processar os pedidos. Se ainda estiver a ter problemas, abra um pedido de suporte.

O valor mínimo de RU tem de ser, pelo menos, 40 RU por GB. À medida que carrega dados, as RUs na base de dados aumentarão se estiver abaixo deste valor mínimo.

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

Para efetuar a verificação de estado de funcionamento no serviço FHIR, introduza {{fhirurl}}/health/check o pedido GET. Deverá conseguir ver o Estado do serviço FHIR. A resposta do código de estado HTTP com 200 e OverallStatus como "Em bom estado de funcionamento" em resposta significa que a verificação de estado de funcionamento foi efetuada com êxito. Em caso de erros, receberá a resposta de erro com o código de estado HTTP 404 (Não Encontrado) ou o código de estado 500 (Erro do Servidor Interno) e informações detalhadas no corpo da resposta em alguns cenários.

Sim, a API do Azure para FHIR permite configurar chaves geridas pelo cliente, tirando partido do suporte do Azure Cosmos DB. Para obter mais informações sobre como encriptar os seus dados com uma chave pessoal, veja Configurar chaves geridas pelo cliente em REST.