# Desenvolvimento de software de saúde

> O que é diferente na criação de software médico e como uma aplicação de saúde é estruturada em camadas: o seu produto no topo, a API Anpheros, o registo FHIR e o consentimento do paciente por baixo.

Source: https://developers.anpheros.com/pt/guides/healthcare-software

**Software de saúde é software que cria, armazena ou atua sobre informações sobre a saúde das pessoas — aplicações para pacientes, ferramentas de clínica, sistemas de laboratório, serviços de monitorização remota, assistentes de IA.** O que o distingue de outro software não é a interface do utilizador, mas sim os dados: são sensíveis, de longa duração, padronizados, partilhados entre organizações e sujeitos a consentimento. Anpheros é infraestrutura para essa camada de dados; esta página explica as camadas de uma aplicação de saúde e quais delas a Anpheros pode fornecer.

## A arquitetura geral

```
Healthcare application        your product: UI, workflows, notifications, business rules
        ↓
Anpheros API                  REST v1 and FHIR R4, OAuth 2.1 / SMART on FHIR, webhooks, SDKs
        ↓
FHIR medical data             one HL7 FHIR R4 record per patient, versioned, with provenance
        ↓
Consent / authorisation       per-application grants chosen and revocable by the patient
```

A sua aplicação detém a experiência; a Anpheros detém o registo e as regras associadas.

## O que é diferente na criação de software médico

### O modelo de dados é um padrão, não uma escolha de design
Outros softwares podem inventar o seu próprio esquema. Software médico que inventa o seu próprio esquema não pode trocar dados com laboratórios, clínicas ou outras aplicações sem um projeto de tradução. Utilizar recursos HL7 FHIR R4 e códigos padrão (LOINC, ICD-10, ATC, UCUM) desde a primeira linha de código evita isso. [Plataforma FHIR](https://developers.anpheros.com/pt/guides/fhir)

### Cada valor precisa de uma origem
Um valor de glicose digitado por um paciente, medido por um dispositivo, importado de um relatório de laboratório ou produzido por um modelo de IA significa coisas diferentes. Anpheros regista o tipo de autor (paciente, profissional de saúde, dispositivo, importação, IA), a organização e o sistema de origem para cada escrita, e mantém cada versão.

### O acesso é decidido pelo paciente, não apenas pela aplicação
Para além do login e das funções do utilizador, o software médico necessita de consentimento: qual aplicação pode ler qual parte do registo de qual pessoa, por quanto tempo, e uma auditoria que a pessoa pode ver. [Modelo de consentimento e acesso](https://developers.anpheros.com/pt/guides/consent)

### Os dados devem sobreviver à aplicação
Os registos são mantidos durante anos e transitam entre prestadores de cuidados. Separar o registo (infraestrutura) da aplicação significa que uma remodelação, uma nova aplicação ou um novo parceiro não requer a migração de dados médicos. [Infraestrutura de registo médico digital](https://developers.anpheros.com/pt/guides/digital-medical-record)

### Desenvolver e testar sem pacientes reais
Dados médicos reais não devem estar em ambientes de desenvolvimento. Anpheros tem uma sandbox — uma base de dados separada com pacientes sintéticos — e chaves de sandbox que fisicamente não conseguem aceder a dados de produção.

### A IA precisa das mesmas regras que todos os outros
Uma funcionalidade de IA é mais um leitor do registo. Deve obter apenas o que o paciente permitiu, com origens, e os seus resultados devem ser rotulados como gerados por IA. [Aplicações de IA na saúde](https://developers.anpheros.com/pt/guides/ai-healthcare)

## O que constrói e o que a Anpheros fornece

| Camada | Constrói | Anpheros fornece |
|---|---|---|
| Experiência do utilizador | ecrãs, fluxos, notificações, conteúdo clínico | — |
| Os seus utilizadores e contas | registo, início de sessão, funções no seu produto | consentimento por paciente para acesso a dados; início de sessão do paciente na página de consentimento |
| Armazenamento de dados médicos | — | registo FHIR R4, 26 tipos de recursos, histórico, documentos |
| Codificação | escolha do que registar | sistemas de código padrão, pesquisa LOINC agrupada |
| Controlo de acesso a registos | qual dos seus utilizadores vê qual paciente | isolamento de projeto, IDs par a par, âmbitos OAuth |
| Auditoria | — | proveniência em escritas, registo de acesso visível para o paciente |
| Integração | especificidades dos seus parceiros | importação de laboratório, transações FHIR, webhooks, SDKs |
| IA | prompts, escolha do modelo, segurança da sua funcionalidade | API de contexto com orçamentos de tokens e rótulos de proveniência |
| Conformidade | as suas obrigações regulamentares e segurança clínica | residência de dados na UE, encriptação de documentos com uma chave gerida pelo cliente, um acordo de processamento de dados para produção |

## Para onde ir a seguir

- Um percurso passo a passo, do acesso à produção: [Construir com Anpheros](https://developers.anpheros.com/pt/guides/build-with-anpheros)
- Um tutorial funcional: [Construir uma aplicação de saúde](https://developers.anpheros.com/pt/guides/build-a-healthcare-app)
- As responsabilidades de um backend médico: [Backend e base de dados de aplicações médicas](https://developers.anpheros.com/pt/guides/medical-app-backend)
- Diagramas e fluxos de dados: [Arquitetura](https://developers.anpheros.com/pt/guides/architecture)
- Para equipas em fase inicial: [Startups de saúde](https://developers.anpheros.com/pt/guides/healthcare-startups)

## Relacionado

- [Infraestrutura de dados médicos](https://developers.anpheros.com/pt/guides/medical-data-infrastructure)
- [API de Saúde](https://developers.anpheros.com/pt/guides/healthcare-api)
- [Segurança, privacidade e residência de dados](https://developers.anpheros.com/pt/guides/security)