# Sviluppo di software sanitario

> Cosa c'è di diverso nella creazione di software medico e come è strutturata un'applicazione sanitaria: il tuo prodotto in cima, l'API Anpheros, il record FHIR e il consenso del paziente sottostanti.

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

**Il software sanitario è software che crea, memorizza o agisce su informazioni relative alla salute delle persone — app per pazienti, strumenti per cliniche, sistemi di laboratorio, servizi di monitoraggio remoto, assistenti AI.** Ciò che lo distingue da altro software non è l'interfaccia utente, ma i dati: sono sensibili, duraturi, standardizzati, condivisi tra organizzazioni e soggetti a consenso. Anpheros è l'infrastruttura per questo livello di dati; questa pagina spiega i livelli di un'applicazione sanitaria e quali di essi Anpheros può fornire.

## L'architettura generale

```
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
```

La tua applicazione gestisce l'esperienza; Anpheros gestisce il record e le regole ad esso associate.

## Cosa c'è di diverso nella creazione di software medico

### Il modello dati è uno standard, non una scelta di progettazione
Altri software possono inventare il proprio schema. Il software medico che inventa il proprio schema non può scambiare dati con laboratori, cliniche o altre applicazioni senza un progetto di traduzione. Utilizzare le risorse HL7 FHIR R4 e i codici standard (LOINC, ICD-10, ATC, UCUM) fin dalla prima riga di codice evita questo problema. [Piattaforma FHIR](https://developers.anpheros.com/it/guides/fhir)

### Ogni valore necessita di una fonte
Un valore di glucosio digitato da un paziente, misurato da un dispositivo, importato da un referto di laboratorio o prodotto da un modello AI ha significati diversi. Anpheros registra il tipo di autore (paziente, professionista sanitario, dispositivo, importazione, AI), l'organizzazione e il sistema sorgente per ogni scrittura, e conserva ogni versione.

### L'accesso è deciso dal paziente, non solo dall'applicazione
Oltre all'accesso utente e ai ruoli, il software medico necessita del consenso: quale applicazione può leggere quale parte del record di quale persona, per quanto tempo, e un audit che la persona può visionare. [Modello di consenso e accesso](https://developers.anpheros.com/it/guides/consent)

### I dati devono sopravvivere all'applicazione
I record vengono conservati per anni e spostati tra i fornitori. Separare il record (infrastruttura) dall'applicazione significa che una riprogettazione, una nuova app o un nuovo partner non richiedono la migrazione dei dati medici. [Infrastruttura del record medico digitale](https://developers.anpheros.com/it/guides/digital-medical-record)

### Sviluppare e testare senza pazienti reali
I dati medici reali non dovrebbero trovarsi negli ambienti di sviluppo. Anpheros dispone di una sandbox: un database separato con pazienti sintetici e chiavi sandbox che fisicamente non possono accedere ai dati di produzione.

### L'AI necessita delle stesse regole di tutti gli altri
Una funzionalità AI è un altro lettore del record. Dovrebbe ricevere solo ciò che il paziente ha consentito, con le fonti, e i suoi output dovrebbero essere etichettati come generati dall'AI. [Applicazioni AI per la sanità](https://developers.anpheros.com/it/guides/ai-healthcare)

## Cosa costruisci e cosa fornisce Anpheros

| Livello | Tu costruisci | Anpheros fornisce |
|---|---|---|
| Esperienza utente | schermate, flussi, notifiche, contenuti clinici | — |
| I tuoi utenti e account | registrazione, accesso, ruoli nel tuo prodotto | consenso per paziente per l'accesso ai dati; accesso paziente sulla pagina di consenso |
| Archiviazione dati medici | — | record FHIR R4, 26 tipi di risorse, cronologia, documenti |
| Codifica | scelta di cosa registrare | sistemi di codici standard, ricerca LOINC raggruppata |
| Controllo accessi ai record | quale dei tuoi utenti vede quale paziente | isolamento del progetto, ID pairwise, ambiti OAuth |
| Audit | — | provenienza sulle scritture, log di accesso visibile al paziente |
| Integrazione | specifiche dei tuoi partner | importazione di laboratori, transazioni FHIR, webhook, SDK |
| AI | prompt, scelta del modello, sicurezza della tua funzionalità | API di contesto con budget di token ed etichette di provenienza |
| Conformità | i tuoi obblighi normativi e la sicurezza clinica | residenza dei dati UE, crittografia dei documenti con una chiave gestita dal cliente, un accordo di elaborazione dati per la produzione |

## Dove andare dopo

- Un percorso passo-passo dall'accesso alla produzione: [Build with Anpheros](https://developers.anpheros.com/it/guides/build-with-anpheros)
- Un tutorial funzionante: [Build a healthcare app](https://developers.anpheros.com/it/guides/build-a-healthcare-app)
- Le responsabilità di un backend medico: [Medical app backend and database](https://developers.anpheros.com/it/guides/medical-app-backend)
- Diagrammi e flussi di dati: [Architecture](https://developers.anpheros.com/it/guides/architecture)
- Per team in fase iniziale: [Healthcare startups](https://developers.anpheros.com/it/guides/healthcare-startups)

## Correlati

- [Infrastruttura dati medicali](https://developers.anpheros.com/it/guides/medical-data-infrastructure)
- [API Sanitaria](https://developers.anpheros.com/it/guides/healthcare-api)
- [Sicurezza, privacy e residenza dei dati](https://developers.anpheros.com/it/guides/security)