Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Integrações de saúde

Padrões de integração suportados hoje: relatórios de laboratório numa única chamada, clínicas a escrever em nome de uma organização, dispositivos, apps de terceiros consentidas, webhooks e SDKs — e o que não está disponível.

Uma integração de saúde conecta um sistema que produz ou necessita de dados de saúde — um laboratório, uma clínica, um dispositivo, outra aplicação — ao registo do paciente. Com o Anpheros, cada integração passa pela mesma API e pelas mesmas regras: os dados são escritos como HL7 FHIR R4, atribuídos à sua origem, visíveis para o paciente e partilhados com outras partes apenas sob o consentimento do paciente. Esta página descreve os padrões de integração que a plataforma suporta hoje.

Explore o diretório de integrações Anpheros para ver cada integração com o seu estado verificado (disponível, beta ou guia do desenvolvedor), os dados e recursos FHIR que troca, a sua direção, autenticação e documentação.

Laboratórios: relatórios completos numa única chamada

Um laboratório, ou qualquer sistema que detenha relatórios de laboratório, envia um relatório completo e a plataforma transforma cada resultado num laboratório Observation:

curl -X POST https://platform.anpheros.com/v1/patients/$PID/labs/import \
     -H "Authorization: Bearer $KEY" -H "Content-Type: text/csv" \
     -H "X-Anpheros-Source-System: labx" -H "Idempotency-Key: report-2026-0917-77" \
     --data-binary @report.csv

• Formatos: CSV (cabeçalhos em romeno ou inglês, vírgula decimal aceite), HL7 v2 ORU^R01 e JSON.
• Os marcadores são mapeados para LOINC quando o relatório fornece um código ou o nome corresponde à terminologia da plataforma; outros mantêm o código próprio do laboratório e são listados como unmapped.
• Cada linha recebe um identificador estável, pelo que o reenvio do mesmo relatório ignora o que já foi importado.
• Até 500 linhas por pedido; cada resultado carrega a proveniência, nomeando o sistema de origem e o relatório.

Detalhes: Conector de Laboratório.

Clínicas: escrever em nome de uma organização

Clínicas e as pessoas que nelas trabalham são recursos de diretório (Organization, Practitioner, PractitionerRole). O sistema de uma clínica pode então indicar quem está por trás de cada pedido:

• X-Anpheros-Acting-As: PractitionerRole/<id> — o profissional de saúde a trabalhar através da sua aplicação; escrito no registo de acesso e mostrado ao paciente pelo nome;
• X-Anpheros-On-Behalf-Of: Organization/<id> — a organização para a qual uma escrita é feita;
• X-Anpheros-Author-Ref: Practitioner/<id> — o autor registado em Provenance.

Com o consentimento do paciente, a clínica lê o registo completo, incluindo o que outras organizações escreveram, e altera apenas o que escreveu. Vários recursos podem ser escritos atomicamente com um pacote transaction FHIR (POST /fhir/R4).

Um exemplo prático, do diretório a uma consulta escrita como uma transação: Como integrar sistemas de clínicas com um backend FHIR.

O fluxo consentimento → laboratório Observation escrito por um projeto de clínica → notificação na aplicação do paciente foi exercido de ponta a ponta com um projeto de clínica de teste.

Dispositivos e wearables

Medições de dispositivos são Observations com author_type: "device" e um código LOINC — frequência cardíaca, pressão arterial, SpO₂, peso, glicose, passos, duração do sono e outros (FHIR code systems). O Anpheros Daily escreve os resumos diários que lê do Apple Health e Health Connect como Observations da mesma forma. O Anpheros não se conecta diretamente às nuvens dos fornecedores de dispositivos; a sua aplicação ou backend lê o dispositivo e escreve o resultado. Como ler Apple Health, Health Connect e Samsung Health e mapear cada métrica para LOINC: Wearable data in FHIR.

Aplicações de terceiros: acesso consentido

Uma aplicação que pretende aceder a dados que uma pessoa já guarda no Anpheros regista-se uma vez e solicita consentimento através de OAuth 2.1 com PKCE (SMART on FHIR standalone launch):

1. GET /oauth/authorize?...&scope=patient/Observation.rs?category=laboratory offline_access — a página de consentimento alojada;
2. a pessoa escolhe o registo e a duração (30, 90, 180 ou 365 dias);
3. POST /oauth/token troca o código por um token de acesso (30 minutos) e um token de atualização rotativo (30 dias);
4. a aplicação vê apenas esse paciente, apenas dentro dos seus escopos, sob o seu próprio ID par.

Autenticação e OAuth

Eventos: reagir a alterações

Em vez de sondar, registe um webhook. As entregas são assinadas com HMAC-SHA256, retentadas com backoff por até 24 horas e transportam IDs, nunca conteúdo clínico. Quando outro projeto escreve num registo ao qual tem acesso, o evento informa (data.external: true, com a origem). Webhooks

SDKs

Os SDKs TypeScript (@anpheros/sdk) e Dart / Flutter (anpheros_sdk) implementam tudo o que foi descrito acima — importação de laboratório (labs.importCsv, labs.importHl7, labs.importItems), OAuth com PKCE, gestão de webhooks e verificação de assinatura. SDKs

O que não está disponível

• Conectores prontos para sistemas de informação de laboratório ou EHRs hospitalares específicos; as integrações são construídas contra a API.
• Lançamento SMART EHR (lançamento dentro de um EHR); apenas o lançamento autónomo é suportado.
• Integrações diretas com fornecedores de dispositivos.

Relacionado

• Como integrar sistemas de clínica com um backend FHIR: tutorial passo a passo para sistemas de gestão de clínica (EMRs)
• Como normalizar dados médicos: códigos, unidades, datas, duplicados, validação
• Como importar resultados de laboratório para um registo FHIR: tutorial passo a passo com CSV e HL7 v2
• Interoperabilidade de dados de saúde
• API de Saúde
• Arquitetura
• Casos de uso

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card