Um servidor FHIR armazena e serve recursos FHIR. Uma plataforma FHIR é o que realmente precisa para lançar um produto de saúde: o servidor, mais identidade, consentimento, proveniência, isolamento entre clientes, webhooks, documentos, terminologia e alguém que o mantenha a funcionar sob o RGPD. Este guia descreve a diferença e como a Plataforma Anpheros preenche cada lacuna, para que possa decidir se deve construir sobre ela ou executar a sua própria.
Versão técnica para programadores: Plataforma de API de Saúde · Comparação de servidores FHIR em developers.anpheros.com, com pedidos, respostas e limites. Esta página é a versão em linguagem simples.
Servidor versus plataforma
Servidores FHIR de código aberto (HAPI, por exemplo) são excelentes na parte FHIR: recursos, pesquisa, validação, histórico. O que eles deixam para si é tudo o que está à volta:
| Necessidade | Um servidor FHIR | Uma plataforma FHIR |
|---|---|---|
| Armazenamento de recursos, pesquisa, histórico | sim | sim |
| Quem pode ler qual paciente | o seu código | consentimento integrado |
| Quem escreveu cada valor | o seu código | Proveniência em cada escrita |
| Vários clientes num só sistema | o seu código | isolamento de projetos, IDs par a par |
| Ecrã de consentimento para o paciente | o seu código | OAuth 2.1 + SMART on FHIR |
| Notificações para a sua aplicação | polling | webhooks assinados |
| Dados de teste realistas | os seus fixtures | 30 pacientes sintéticos por sandbox |
| Alojamento, backups, RGPD, DPA | a sua equipa de operações | incluído |
Se tiver uma equipa de operações, um responsável pela conformidade e seis meses, executar o seu próprio servidor é uma boa opção. Se tiver um produto para lançar, uma plataforma é mais rápida.
Como a Plataforma Anpheros é construída
Um registo FHIR R4 por paciente. 26 tipos de recursos, codificados com LOINC, ICD-10 e ATC, validados na escrita. A API FHIR estrita encontra-se em /fhir/R4, com uma CapabilityStatement em /fhir/R4/metadata, e uma API REST simples em /v1 serve os mesmos dados com os mesmos IDs.
Isolamento de projetos e IDs par a par. Um projeto (uma chave de API) vê apenas os pacientes que criou. Cada projeto recebe o seu próprio ID para a mesma pessoa; os IDs internos nunca saem da plataforma. As referências a pacientes fora do seu âmbito são mascaradas com um token opaco, por projeto.
O consentimento decide as leituras, a propriedade decide as escritas. Com o consentimento do paciente, uma organização vê todo o registo, incluindo o que outras clínicas escreveram, mas só pode alterar ou eliminar o que escreveu. Cada versão de cada recurso regista o projeto que a escreveu; uma escrita por outro projeto é recusada com uma explicação.
Proveniência e auditoria em cada escrita. Provenance.agent.onBehalfOf nomeia a clínica ou organização no momento da escrita; uma linha de auditoria regista quem, o quê, quando, sob qual concessão, a partir de qual aplicação. O paciente pode ler o seu registo de acesso, também como recursos FHIR AuditEvent.
Webhooks finos e assinados. Os eventos transportam IDs e versões, nunca conteúdo clínico; lê o recurso através da API. As entregas são assinadas com HMAC-SHA256 e retentadas com backoff durante até 24 horas.
Sandbox e produção são bases de dados separadas. Uma chave sk_test_ não pode aceder a um paciente real. A sandbox é gratuita e auto-servida.
Residência na UE. Cloud Run em europe-west4, com um acordo de processamento de dados para organizações de produção.
O que está deliberadamente ausente
- Nenhum suporte de decisão clínica. A plataforma armazena, codifica e partilha; não diagnostica nem recomenda tratamento.
- Nenhum banco de dados completo de medicamentos com interações. Os medicamentos são codificados com ATC, e um subconjunto combinado de ATC e LOINC está disponível para consulta, mas a verificação de interações é o seu componente ou um serviço licenciado.
- Nenhum barramento de mensagens HL7 v2 de nível hospitalar. Existe uma importação HL7 v2 ORU^R01 para relatórios de laboratório; não existe gestão de ADT ou de pedidos.
Conhecer estes limites antecipadamente poupa uma semana de descoberta.
Quando executar o seu próprio servidor em vez disso
- Deve alojar dentro da sua própria rede hospitalar, sem processador externo.
- Precisa de FHIR R5 ou perfis que a plataforma não implementa.
- O seu produto é o próprio servidor FHIR.
Em todos os outros casos, comece na sandbox, meça e decida com dados. A primeira hora é descrita em developers.anpheros.com/guides/first-hour; a referência completa da API está em platform.anpheros.com/docs.
Perguntas frequentes
É a Anpheros um servidor FHIR?
Contém um: uma API FHIR R4 com 26 tipos de recursos, pesquisa, histórico, operações $everything, $summary, $validate e terminologia. À volta disso estão o consentimento, a proveniência, o isolamento, os webhooks e o alojamento, que é o que a torna uma plataforma.
Qual versão FHIR?
FHIR R4 (4.0.1), a versão exigida pela regulamentação da UE e dos EUA e implementada pela maioria dos sistemas. A conformidade foi verificada com o Inferno; veja as notas de conformidade IPS.
Podem várias clínicas partilhar o registo de um paciente?
Sim, esse é o objetivo. Com o consentimento do paciente, cada clínica lê todo o registo e escreve os seus próprios recursos, cada um marcado com a sua proveniência. Nenhuma clínica pode alterar o que outra escreveu.
Existe um backend FHIR gratuito para desenvolvimento?
Sim. A sandbox é gratuita, auto-servida e vem com 30 pacientes sintéticos por projeto. Veja Servidor FHIR gratuito: a sandbox.
Como posso migrar se precisar de o fazer?
Tudo é FHIR R4 e exportável: Patient/{id}/$everything retorna todo o registo de um paciente como um Bundle. Não há formato proprietário para desvendar.
Tenha o seu registo de saúde consigo
Anpheros Daily reúne sintomas, resultados de exames, medicamentos e documentos num só local, num formato standard, sob o seu controlo. O plano Basic é gratuito.