# Infraestrutura de registo médico digital

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

Source: https://developers.anpheros.com/pt/guides/digital-medical-record

**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](https://developers.anpheros.com/pt/guides/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](https://developers.anpheros.com/pt/guides/consent)

### 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](https://developers.anpheros.com/pt/guides/healthcare-integrations)

### 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:

1. crie um paciente para cada utilizador (`POST /v1/patients`) ou peça o consentimento a um utilizador Anpheros existente;
2. escreva o que o utilizador regista (`/v1/patients/{id}/observations`, `/conditions`, `/medications`, `/documents`);
3. leia de volta como listas ou uma linha cronológica (`/v1/patients/{id}/timeline`);
4. 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](https://developers.anpheros.com/pt/guides/build-a-healthcare-app).

## Relacionado

- [Registo médico do paciente](https://developers.anpheros.com/pt/guides/patient-medical-record)
- [Backend e base de dados da aplicação médica](https://developers.anpheros.com/pt/guides/medical-app-backend)
- [Segurança, privacidade e residência de dados](https://developers.anpheros.com/pt/guides/security)
- [Infraestrutura de dados médicos](https://developers.anpheros.com/pt/guides/medical-data-infrastructure)