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

Sviluppo software sanitario

Cosa cambia nello sviluppo 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 sotto.

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

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

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

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à

Cosa costruisci e cosa fornisce Anpheros

Dove andare dopo

• Un percorso passo-passo dall'accesso alla produzione: Build with Anpheros
• Un tutorial funzionante: Build a healthcare app
• Le responsabilità di un backend medico: Medical app backend and database
• Diagrammi e flussi di dati: Architecture
• Per team in fase iniziale: Healthcare startups

Correlati

• Infrastruttura dati medicali
• API Sanitaria
• Sicurezza, privacy e residenza dei dati

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