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

Infraestrutura de registo médico digital

A infraestrutura de que um registo médico digital necessita — estrutura, histórico, documentos, isolamento, consentimento, auditoria, intercâmbio — e por que é mantida separada da aplicação voltada para o paciente.

Um registo médico digital necessita de duas coisas distintas: uma aplicação voltada para o paciente que as pessoas usam diariamente e a infraestrutura subjacente que armazena, protege e partilha o registo. A Anpheros fornece a segunda: o armazenamento, versionamento, identidade, consentimento, auditoria e intercâmbio do registo, através de uma API. A aplicação voltada para o paciente pode ser a Anpheros Daily ou uma que você construa.

Aplicação versus infraestrutura

	Aplicação voltada para o paciente	Infraestrutura de dados médicos
O que é	ecrãs, notificações, lembretes, gráficos, um assistente	o próprio registo e as regras associadas
Muda frequentemente	sim — design, funcionalidades, plataformas	raramente — tem de se manter estável e compatível
Exemplos de trabalho	um diário de sintomas, um lembrete de medicação, um calendário familiar	Armazenamento FHIR, histórico de versões, consentimento, proveniência, auditoria, importação de laboratório, webhooks
Em Anpheros	Anpheros Daily (Android, macOS, web)	Anpheros Platform (`platform.anpheros.com`)

Manter estas duas separadas permite que um registo sobreviva a qualquer aplicação individual e seja partilhado entre várias. O Anpheros Daily segue esta divisão: o que as pessoas registam na aplicação é escrito na plataforma através da mesma API pública que qualquer outra aplicação utiliza, pelo que está disponível — com o consentimento do paciente — para outras aplicações no mesmo formato FHIR.

O que a infraestrutura tem de fornecer

Estrutura

Um registo só é útil se outro software o conseguir compreender. A Anpheros armazena-o como recursos HL7 FHIR R4 — 26 tipos — com códigos standard (LOINC, ICD-10, ATC, UCUM) e mantém o texto original ao lado de cada código. Plataforma FHIR

Histórico

Os dados médicos são corrigidos, não sobrescritos. Cada atualização cria uma nova versão, legível através de /fhir/R4/{type}/{id}/_history; atualizações condicionais com If-Match impedem que dois escritores se sobrescrevam mutuamente (uma versão desatualizada responde com 412).

Documentos

Digitalizações e PDFs são armazenados como DocumentReference com o ficheiro original: carregados através da plataforma ou diretamente para o armazenamento, depois finalizados com um checksum SHA-256 e tamanho. Após a finalização, o original não pode ser alterado; os valores extraídos dele apontam de volta para ele (derived_from). Os ficheiros são mantidos num bucket de armazenamento da UE encriptado com uma chave gerida pelo cliente, até 25 MiB cada.

Identidade e isolamento

Cada aplicação funciona dentro de um projeto e vê apenas os seus próprios pacientes (mais aqueles que lhe concederam acesso), sob os seus próprios identificadores par-a-par. Um registo fora do seu alcance não existe para ele (404).

Consentimento

Um paciente concede a uma aplicação acesso por um período (30–365 dias), a tipos de recursos e ações específicos, opcionalmente limitados a uma categoria. As concessões são espelhadas como recursos FHIR Consent e podem ser revogadas a qualquer momento. Modelo de consentimento e acesso

Proveniência e auditoria

Cada escrita regista quem a escreveu (paciente, profissional de saúde, dispositivo, importação ou IA), para qual organização e de qual sistema. Cada leitura é registada e mostrada ao paciente por aplicação.

Troca

O registo pode ser exportado na totalidade (Patient/$everything), resumido no formato International Patient Summary (Patient/$summary), alimentado por laboratórios (CSV, HL7 v2 ORU^R01, JSON) e monitorizado através de webhooks assinados. Integrações de saúde

Residência e eliminação

Os dados são armazenados e processados na União Europeia. A eliminação de um paciente elimina todos os recursos do registo.

Construir a sua própria aplicação para o paciente

Se estiver a construir a camada da aplicação, pode concentrar-se na experiência e usar o Anpheros para o registo:

crie um paciente para cada utilizador (POST /v1/patients) ou peça o consentimento a um utilizador Anpheros existente;
escreva o que o utilizador regista (/v1/patients/{id}/observations, /conditions, /medications, /documents);
leia de volta como listas ou uma linha cronológica (/v1/patients/{id}/timeline);
subscreva webhooks para atualizar os ecrãs quando um laboratório ou clínica adicionar algo.

O guia completo encontra-se em Build a healthcare app.

Relacionado

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