Codice sorgente per tutti i clienti
Verifichi la realizzazione insieme al Suo servizio IT o a un professionista indipendente.
DOCUMENTAZIONE TECNICA
Stato delle fonti: 4 ottobre 2026Tecnica che si può verificare.
La Sua struttura di cura deve poter comprendere come funziona Oronela. Qui spieghiamo la base tecnica, la protezione dei Suoi dati e la nostra garanzia di qualità, con versioni concrete e stati di verifica tracciabili.
Visualizzare tutti i moduliGestione secondo la Sua scelta
Oronela SaaS in Svizzera oppure un'installazione gestita autonomamente con aggiornamenti continui.
Qualità dimostrabile
Il codice sorgente, i processi documentati e le versioni precise rendono verificabile l’implementazione tecnica.
Un nucleo funzionale comune. Responsabilità chiare.
Oronela è in fase di completamento. I 18 moduli collegano cure, accompagnamento, amministrazione e gestione operativa. Lei sceglie l'ambito adatto alla Sua struttura. La piattaforma tecnica raggruppa accesso, autorizzazioni attuali, archiviazione cifrata, incarichi in background e modifiche tracciabili. Un modulo riceve informazioni da altri ambiti tramite interfacce definite, anziché modificarne arbitrariamente i dati.
L'interfaccia browser utilizza Vue e TypeScript. Il nucleo professionale lato server e l'API sono scritti in Rust. SQL definisce strutture dei dati, regole di integrità e migrazioni in PostgreSQL. Python supporta strumenti di verifica, processi operativi e gestione dell'IA privata. La logica eseguibile e le sue interfacce si trovano insieme ai relativi test nel repository del prodotto.
L’interfaccia comunica con un’API controllata. Un Backend-for-Frontend gestisce la sessione lato server e collega l’interfaccia a identità e processi professionali. Il dispositivo del browser non riceve accesso diretto al database né una connessione libera al server del modello. Anche una schermata aperta non sostituisce una verifica dei diritti: prima di un’azione vincolante vengono nuovamente considerati tenant, ruolo, responsabilità, contesto professionale e revisione attuale.
Ambiente di lavoro
Finestre dei residenti, cure, personale, cucina e amministrazione nel browser.
API e nucleo professionale
Diritti attuali, regole professionali e contratti dei moduli versionati.
Dati protetti
PostgreSQL, documenti cifrati, gestione delle chiavi e audit.
Trasferimenti autorizzati
Collegamenti ai partner e IA privata opzionale con ambito dei dati limitato.
Le versioni concretamente fissate.
Questa tabella riporta le versioni fissate nel repository del prodotto al 4 ottobre 2026. Descrive lo stato di sviluppo e integrazione tracciabile. Per un'installazione valgono inoltre il relativo pacchetto di rilascio, la sua configurazione approvata e la sua attestazione delle versioni.
Sono inclusi anche strumenti Python. Nel manifest radice esaminato non è fissata una versione Python comune; per questo non indichiamo un numero di versione inventato. La versione viene registrata nella rispettiva prova operativa e di verifica. Modello, runtime e configurazione vengono gestiti come versioni separate.
Basi delle versioni: rust-toolchain.toml, Cargo.toml e Cargo.lock, package.json e pnpm-lock.yaml, compose.yaml e la prova documentata del runtime IA privato.
Oronela SaaS oppure la Sua installazione.
Ogni cliente può scegliere tra il servizio Oronela SaaS e un sistema gestito autonomamente. Nel servizio SaaS, Oronela gestisce il sistema sull'infrastruttura svizzera propria. Archiviazione, elaborazione e IA opzionale restano in Svizzera. L'infrastruttura è certificata ISO 27001; questo non implica una certificazione propria dell'applicazione.
Per un’installazione gestita autonomamente, la Sua struttura definisce insieme al proprio servizio IT il luogo di esercizio e la responsabilità tecnica. Anche questi clienti ricevono costantemente aggiornamenti. Il pacchetto di rilascio, le versioni incluse e i passaggi documentati d’installazione e migrazione costituiscono la base comune. Chi gestisce autonomamente assume la responsabilità di accessi, confini di rete, chiavi, backup e monitoraggio o incarica un partner operativo adeguato.
Le funzionalità sono configurate secondo necessità. Anche l’IA è una scelta consapevole della Sua struttura. La gestione autonoma non è un motivo per trasmettere dati a un servizio IA pubblico: elaborazione del modello e fonti consentite rimangono nell’ambiente proprio predisposto a questo scopo. Una sostituzione tacita con un’IA esterna è esclusa dal concetto di sistema.
- SaaS: Oronela è responsabile della gestione operativa concordata e della distribuzione controllata degli aggiornamenti.
- Gestione autonoma: il Suo reparto IT riceve le basi tecniche e aggiornamenti continui per la propria installazione.
- Entrambe le opzioni: stato delle versioni, modifiche di sicurezza, dipendenze e indicazioni di migrazione restano tracciabili.
L’accesso al codice sorgente è incluso.
Tutti i clienti Oronela ricevono accesso al codice sorgente. Le promesse di sicurezza devono poter essere verificate nell'implementazione effettiva. Il Suo reparto IT o una persona specializzata da Lei incaricata può comprendere come viene verificata un'autorizzazione, dove viene utilizzata una chiave, quali dati riceve un collegamento e come viene registrata una modifica.
Comprendere richiede più delle interfacce visibili. Il patrimonio tecnico comprende moduli professionali, contratti API, schemi del database, migrazioni, test e documentazione per sviluppatori. Codice proprio e documenti per sviluppatori utilizzano l'inglese, affinché interfacce e conoscenze di manutenzione restino univoche oltre persone e confini linguistici. La documentazione utente resta disponibile nella lingua della Sua interfaccia.
L’accesso al codice sorgente è anche una base per audit indipendenti e una decisione operativa a lungo termine. Permette alla Sua struttura di verificare in modo mirato i percorsi critici e porre domande riferite a passaggi concreti. Credenziali, chiavi private e dati dei residenti non fanno naturalmente parte di questo codice sorgente.
Proteggere i dati durante la trasmissione e l’archiviazione.
Il nucleo professionale contiene cifratura autenticata con AES-256-GCM. Per una cifratura viene utilizzata una nuova chiave dei dati. OpenBao protegge questa chiave in un servizio di chiavi separato. Il testo in chiaro di un record professionale non viene trasmesso al servizio di chiavi per questa operazione.
L'informazione cifrata è vincolata alla propria identità attesa: cliente, oggetto di archiviazione, finalità e revisione appartengono al contesto verificato. Perciò non basta copiare un contenuto cifrato in un altro record. Modifiche del contenuto o un contesto inadeguato portano al rifiuto. La decifratura resta inoltre vincolata a un'autorizzazione professionale attuale; un contenuto crittograficamente valido da solo non consente ancora l'accesso.
I documenti più grandi vengono elaborati in segmenti autenticati. Il percorso documentale esistente verifica, tra l’altro, la lunghezza completa, la fine del documento e la conferma finale. Le singole parti decifrate non vengono già considerate documenti approvati. Versioni delle chiavi e revisioni dei documenti restano tracciabili, affinché rotazione e ripristino tengano conto degli originali corretti.
Per la trasmissione il sistema utilizza HTTPS. Le connessioni interne tra servizi ricevono certificati e identità di servizio verificati secondo il profilo operativo, anche tramite autenticazione TLS reciproca. Ruoli del database, accessi di rete e finalità delle chiavi sono limitati. In caso di errore, né contenuti medici né token vengono esposti nei messaggi d’errore generici.
- Campi e documenti: cifratura autenticata anziché una semplice etichetta di riservatezza.
- Chiavi: gestione separata con accesso riferito a cliente e finalità.
- Trasmissione: connessioni protette e destinatari esplicitamente autorizzati.
- Ripristino: originali, storico delle chiavi ed effettiva leggibilità vengono considerati insieme.
Confini tra clienti e diritti professionali agiscono insieme.
Una struttura di cura e una sede non sono filtri arbitrari nell'interfaccia. Il server lavora con il cliente identificato in modo affidabile e con le facoltà attuali della persona che agisce. La conservazione dei dati e i ruoli limitati del database completano questo confine professionale. Un ID di residente altrui o un modulo del browser manipolato non possono creare un accesso.
Le autorizzazioni possono cambiare mentre una finestra è aperta. Per questo un comando vincolante verifica la situazione attuale. A seconda dell’operazione, vi rientrano competenza professionale, scopo, stato delle fonti e revisione. Una copia obsoleta o un’approvazione scaduta non diventano valide soltanto perché sono state visualizzate in precedenza.
Un modulo mantiene la responsabilità delle proprie informazioni professionali. Per esempio, ammissione e soggiorno appartengono a M01, posto e camera a M05 e base tariffaria contrattuale a M11. Gli altri ambiti acquisiscono le informazioni necessarie tramite contratti versionati. Questo aiuta a evitare copie contraddittorie e responsabilità poco chiare.
Un audit segue il processo effettivo.
Per le modifiche rilevanti, il percorso tecnico di audit registra fonte, momento, contesto e revisione. Stato professionale, cronologia, audit e incarico conseguente in uscita vengono trattati insieme nel percorso di transazione previsto. L'outbox distingue la registrazione durevole di un incarico dalla sua consegna successiva. Così un incarico può essere elaborato nuovamente dopo un'interruzione del collegamento senza duplicarne indiscriminatamente l'effetto professionale.
Gli eventi di audit sono collegati al predecessore tramite SHA-256. La verifica considera i byte originali memorizzati e il rispettivo tipo di evento. L’archivio separato verifica i pacchetti ricevuti e rilascia conferme firmate; il percorso di conferma esistente utilizza Ed25519. La fonte conferma l’archiviazione soltanto sulla base della conferma correttamente verificata. Una consegna tecnica e una conferma professionale restano fatti diversi.
Anche le autorizzazioni di lettura rilevanti ricevono un contesto tracciabile. Una vista audit limitata non afferma completezza per aree storiche che non contiene. In una verifica vengono quindi considerati insieme ambito, periodo, collegamento della catena, ricevute d’archivio e autorizzazioni d’accesso.
L'audit di sicurezza e qualità del prodotto completa queste evidenze operative. Le modifiche vengono ricondotte a requisiti, rischi, protezione dei dati e dipendenze. Le basi di approvazione richiedono revisione indipendente, risultati di verifica concreti e valutazione responsabile professionale, di sicurezza e operativa. Un test dei componenti riuscito non sostituisce né un'accettazione clinica né un audit indipendente.
Sviluppo continuo senza modifiche incontrollate dei dati.
Procedure di cura, basi legali e requisiti tecnici cambiano. Per questo Oronela viene sviluppato continuamente. I bisogni reali delle strutture confluiscono in requisiti concreti; ne derivano modifiche tracciabili con test e impatti documentati. Procedure consolidate, interfacce e prove storiche restano una responsabilità comune dello sviluppo professionale e della gestione.
Il versionamento riguarda applicazione, librerie, migrazioni del database, regole e IA facoltativa. Una regola modificata non può reinterpretare tacitamente una prova storica di cura o fatturazione. Una proposta attuale fa riferimento alle fonti effettivamente utilizzate; un originale già creato conserva la base dell’epoca.
Le modifiche al database vengono gestite in migrazioni ordinate. Il processo di approvazione richiede stati iniziali e finali definiti, dipendenze, compatibilità, somme di controllo e un percorso di ripristino. Un annullamento sicuro dipende dal tipo concreto di modifica e dalle scritture successive. Quando un annullamento diretto non è consentito, occorre una correzione o un ripristino documentati.
Un aggiornamento per un'installazione gestita autonomamente resta verificabile attraverso il pacchetto di rilascio. Questo comprende le nuove versioni, gli effetti su configurazione e interfacce e le fasi necessarie di migrazione. Nella gestione SaaS, la stessa versione approvata costituisce la base della distribuzione controllata.
- Comprendere requisito e impatto.
- Modificare insieme codice, test e documentazione.
- Riunire verifica indipendente ed evidenze adeguate.
- Approvare la versione esatta e distribuirla in modo controllato.
- Osservare la gestione, raccogliere i riscontri e fornire rettifiche in modo tracciabile.
L’IA rimane facoltativa e all’interno del Suo ambiente dati.
Oronela funziona con i moduli scelti dalla Sua struttura. L'IA viene utilizzata soltanto quando Lei la desidera e le relative funzioni sono attivate. Nel servizio Oronela SaaS, elaborazione dei modelli e accesso alle conoscenze funzionano su server Oronela propri in Svizzera. Non esiste alcuna chiamata nascosta a un fornitore di IA pubblico.
Lo stato tecnico di verifica comprende un runtime del modello Qwen effettivamente utilizzato localmente. Versione del modello, runtime e provenienza degli artefatti vengono registrati separatamente. Il modello riceve il contesto necessario per una finalità approvata. Fonti consentite, persona attualmente agente e rimozione di un contesto sono parti del percorso applicativo.
Una risposta resta una proposta con fonti distinguibili. Un riepilogo non sostituisce un’osservazione documentata e una raccomandazione sul piano dei turni non annulla una regola professionale. Nel caso di verifica documentato, il modello sceglie tra proposte di piano già nuovamente verificate; non ne modifica liberamente gli impieghi. L’approvazione resta alle persone autorizzate.
La qualità del modello viene valutata con casi professionali appropriati e verifiche di protezione dei dati. La copertura classica del codice può misurare la logica degli adattatori, ma non giustificare un’affermazione di risposte corrette del modello al 100 per cento. Una nuova versione del modello o del prompt riceve quindi un proprio contesto di valutazione e approvazione.
Il Suo reparto IT può approfondire.
Presentiamo le caratteristiche tecniche affinché restino verificabili. Le domande su cifratura, confini tra clienti, versioni o ripristino possono essere discusse sulla base di implementazioni ed evidenze concrete. L'accesso al codice sorgente permette ai Suoi specialisti di esaminare autonomamente i percorsi importanti per la Sua struttura.
Per la gestione vengono considerati insieme l’effettivo ambito del rilascio, la sua configurazione e le relative approvazioni. I testi generali sul prodotto non sostituiscono questi documenti. Ci contatti se il Suo servizio IT, il responsabile della protezione dei dati o un auditor indipendente necessitano di una prova specifica, o se desidera discutere con noi la gestione autonoma.