Quellcode für alle Kunden
Prüfen Sie die Umsetzung gemeinsam mit Ihrer IT oder einer unabhängigen Fachperson.
TECHNISCHE DOKUMENTATION
Quellstand: 4. Oktober 2026Technik, die sich überprüfen lässt.
Ihre Pflegeeinrichtung soll verstehen können, wie Oronela arbeitet. Hier erklären wir die technische Grundlage, den Schutz Ihrer Daten und unsere Qualitätssicherung – mit konkreten Versionen und nachvollziehbaren Prüfständen.
Alle Module ansehenBetrieb nach Ihrer Wahl
Oronela SaaS in der Schweiz oder eine selbst betriebene Installation mit laufenden Updates.
Belegbare Qualität
Quellcode, dokumentierte Abläufe und konkrete Versionen machen die technische Umsetzung nachvollziehbar.
Ein gemeinsamer Fachkern. Klare Verantwortlichkeiten.
Oronela befindet sich in Fertigstellung. Die 18 Module verbinden Pflege, Betreuung, Administration und Betrieb. Sie wählen den Umfang, der zu Ihrer Einrichtung passt. Die technische Plattform bündelt Anmeldung, aktuelle Rechte, verschlüsselte Ablage, Hintergrundaufträge und nachvollziehbare Änderungen. Ein Modul erhält Informationen anderer Bereiche über definierte Schnittstellen, statt deren Daten beliebig zu verändern.
Die Browseroberfläche verwendet Vue und TypeScript. Der serverseitige Fachkern und die API sind in Rust geschrieben. SQL definiert Datenstrukturen, Integritätsregeln und Migrationen in PostgreSQL. Python unterstützt Prüfwerkzeuge, Betriebsabläufe und den privaten KI-Betrieb. Die ausführbare Logik und ihre Schnittstellen liegen gemeinsam mit den zugehörigen Tests im Produkt-Repository.
Die Oberfläche spricht mit einer kontrollierten API. Ein Backend-for-Frontend verwaltet die Sitzung serverseitig und verbindet die Oberfläche mit Identität und Fachprozessen. Das Browsergerät erhält keinen direkten Datenbankzugang und keine freie Verbindung zum Modellserver. Ein geöffneter Bildschirm ersetzt auch keine Rechteprüfung: Vor einer verbindlichen Aktion werden Mandant, Rolle, Zuständigkeit, fachlicher Kontext und die aktuelle Revision erneut berücksichtigt.
Arbeitsbereich
Bewohnerfenster, Pflege, Personal, Küche und Administration im Browser.
API und Fachkern
Aktuelle Rechte, Fachregeln und versionierte Modulverträge.
Geschützte Daten
PostgreSQL, verschlüsselte Dokumente, Schlüsselverwaltung und Audit.
Freigegebene Übergaben
Partneranschlüsse und optionale private KI mit begrenztem Datenumfang.
Die konkret festgeschriebenen Versionen.
Diese Tabelle bildet die im Produkt-Repository festgeschriebenen Versionen am 4. Oktober 2026 ab. Sie beschreibt den nachvollziehbaren Entwicklungs- und Integrationsstand. Für eine Installation gelten zusätzlich das zugehörige Releasepaket, dessen freigegebene Konfiguration und sein Versionsnachweis.
Python-Werkzeuge sind ebenfalls enthalten. Eine gemeinsame Python-Version ist im untersuchten Wurzelmanifest nicht festgeschrieben; deshalb nennen wir dafür keine erfundene Versionsnummer. Die Version wird im jeweiligen Betriebs- und Prüfnachweis festgehalten. Modell, Laufzeit und Konfiguration werden als eigene Versionen geführt.
Versionsgrundlagen: rust-toolchain.toml, Cargo.toml und Cargo.lock, package.json und pnpm-lock.yaml, compose.yaml sowie der dokumentierte private KI-Laufzeitnachweis.
Oronela SaaS oder Ihre eigene Installation.
Jeder Kunde kann zwischen dem Oronela SaaS Service und einem selbst betriebenen System wählen. Beim SaaS Service übernimmt Oronela den Betrieb auf eigener Schweizer Infrastruktur. Speicherung, Verarbeitung und optionale KI bleiben in der Schweiz. Die Infrastruktur ist nach ISO 27001 zertifiziert; daraus wird keine eigene Zertifizierung der Anwendung abgeleitet.
Bei einer selbst betriebenen Installation bestimmt Ihre Einrichtung gemeinsam mit ihrer IT den Betriebsort und die technische Betriebsverantwortung. Auch diese Kunden werden laufend mit Updates versorgt. Das Releasepaket, die enthaltenen Versionen und die dokumentierten Installations- und Migrationsschritte bilden dabei die gemeinsame Grundlage. Wer selbst betreibt, übernimmt die zugehörige Verantwortung für Zugänge, Netzgrenzen, Schlüssel, Sicherung und Überwachung oder beauftragt einen geeigneten Betriebspartner.
Der Funktionsumfang wird nach Bedarf eingerichtet. Auch KI ist eine bewusste Entscheidung Ihrer Einrichtung. Ein eigener Betrieb ist kein Anlass, Daten an einen öffentlichen KI-Dienst weiterzureichen: Modellverarbeitung und zulässige Quellen bleiben innerhalb der dafür eingerichteten eigenen Umgebung. Ein stiller Ersatz durch eine fremde KI ist im Systemkonzept ausgeschlossen.
- SaaS: Oronela verantwortet den vereinbarten Betrieb und die kontrollierte Auslieferung der Updates.
- Eigener Betrieb: Ihre IT erhält die technischen Grundlagen und laufende Updates für die eigene Installation.
- Beide Wege: Versionsstand, Sicherheitsänderungen, Abhängigkeiten und Migrationshinweise bleiben nachvollziehbar.
Zugriff auf den Quellcode gehört dazu.
Alle Oronela-Kunden erhalten Zugriff auf den Source Code. Sicherheitsversprechen sollen sich an der tatsächlichen Umsetzung überprüfen lassen. Ihre IT oder eine von Ihnen beauftragte Fachperson kann nachvollziehen, wie eine Berechtigung geprüft wird, wo ein Schlüssel verwendet wird, welche Daten ein Anschluss erhält und wie eine Änderung protokolliert wird.
Zum Verständnis gehören mehr als die sichtbaren Oberflächen. Der technische Bestand umfasst Fachmodule, API-Verträge, Datenbankschemata, Migrationen, Tests und Entwicklerdokumentation. Eigener Code und Entwicklerunterlagen verwenden Englisch, damit Schnittstellen und Wartungswissen über Personen und Sprachgrenzen hinweg eindeutig bleiben. Die Anwenderdokumentation bleibt in Ihrer Oberflächensprache verfügbar.
Quellcodezugang ist auch eine Grundlage für unabhängige Audits und eine längerfristige Betriebsentscheidung. Er erlaubt Ihrer Einrichtung, kritische Wege gezielt zu prüfen und Rückfragen anhand konkreter Stellen zu stellen. Zugangsdaten, private Schlüssel und Bewohnerdaten gehören selbstverständlich nicht zu diesem Quellbestand.
Daten schützen – bei der Übertragung und in der Ablage.
Der Fachkern enthält authentifizierte Verschlüsselung mit AES-256-GCM. Für eine Verschlüsselung wird ein frischer Datenschlüssel verwendet. OpenBao schützt diesen Schlüssel in einem getrennten Schlüsseldienst. Der Klartext eines Fachdatensatzes wird für diese Schlüsseloperation nicht an den Schlüsseldienst übermittelt.
Die verschlüsselte Information ist an ihre erwartete Identität gebunden: Mandant, Speicherobjekt, Zweck und Revision gehören zum geprüften Kontext. Dadurch reicht es nicht, einen verschlüsselten Inhalt in einen anderen Datensatz zu kopieren. Änderungen am Inhalt oder ein unpassender Kontext führen zur Ablehnung. Die Entschlüsselung bleibt zusätzlich an eine aktuelle fachliche Berechtigung gebunden; ein gültiger kryptografischer Inhalt allein erlaubt noch keinen Zugriff.
Grössere Dokumente werden in authentifizierten Segmenten verarbeitet. Der vorhandene Dokumentenpfad prüft unter anderem die vollständige Länge, das Ende des Dokuments und die Abschlussquittung. Einzelne entschlüsselte Teile werden nicht schon als freigegebenes Dokument behandelt. Schlüsselversionen und Dokumentrevisionen bleiben nachvollziehbar, damit Rotation und Wiederherstellung die richtigen Originale berücksichtigen.
Für die Übertragung verwendet das System HTTPS. Interne Dienstverbindungen erhalten nach ihrem Betriebsprofil geprüfte Zertifikate und Dienstidentitäten, unter anderem über gegenseitige TLS-Authentifizierung. Datenbankrollen, Netzzugriffe und Schlüsselzwecke werden begrenzt. Bei einem Fehler werden weder medizinische Inhalte noch Tokens in allgemeinen Fehlermeldungen ausgegeben.
- Felder und Dokumente: authentifizierte Verschlüsselung statt einer blossen Kennzeichnung als vertraulich.
- Schlüssel: getrennte Verwaltung mit mandanten- und zweckbezogenem Zugriff.
- Übermittlung: geschützte Verbindungen und ein ausdrücklich freigegebener Empfängerkreis.
- Wiederherstellung: Originale, Schlüsselhistorie und tatsächliche Lesbarkeit werden gemeinsam betrachtet.
Mandantengrenzen und Fachrechte greifen gemeinsam.
Eine Pflegeeinrichtung und ein Standort sind keine beliebigen Filter in der Oberfläche. Der Server arbeitet mit dem vertrauenswürdig festgestellten Mandanten und den aktuellen Befugnissen der handelnden Person. Die Datenhaltung und begrenzte Datenbankrollen ergänzen diese fachliche Grenze. Eine fremde Bewohner-ID oder ein manipuliertes Browserformular darf keinen Zugriff schaffen.
Berechtigungen können sich während eines geöffneten Fensters ändern. Deshalb prüft ein verbindlicher Befehl die aktuelle Situation. Fachkompetenz, Zweck, Quellenstand und Revision gehören je nach Vorgang dazu. Eine veraltete Kopie oder eine abgelaufene Freigabe wird nicht allein deshalb gültig, weil sie zuvor angezeigt wurde.
Ein Modul hält die Verantwortung für seine eigenen Fachinformationen. Beispielsweise gehören Aufnahme und Aufenthalt zu M01, Platz und Zimmer zu M05 und die vertragliche Tarifgrundlage zu M11. Andere Bereiche beziehen die benötigten Informationen über versionierte Verträge. Das hilft, widersprüchliche Kopien und unklare Zuständigkeiten zu vermeiden.
Ein Audit folgt dem tatsächlichen Ablauf.
Für relevante Änderungen hält der technische Auditpfad Quelle, Zeitpunkt, Kontext und Revision fest. Fachzustand, Historie, Audit und ausgehender Folgeauftrag werden im vorgesehenen Transaktionsweg gemeinsam behandelt. Die Outbox trennt die dauerhafte Festhaltung eines Auftrags von seiner späteren Zustellung. So lässt sich ein Auftrag nach einem Verbindungsabbruch erneut bearbeiten, ohne seine fachliche Wirkung blind zu verdoppeln.
Auditereignisse werden mit SHA-256 an ihren Vorgänger gebunden. Die Prüfung berücksichtigt die ursprünglichen gespeicherten Bytes und den jeweiligen Ereignistyp. Das separate Archiv prüft die empfangenen Pakete und stellt signierte Quittungen aus; der vorhandene Quittungspfad verwendet Ed25519. Die Quelle bestätigt eine Archivierung erst anhand der passend geprüften Quittung. Eine technische Zustellung und eine fachliche Bestätigung bleiben unterschiedliche Tatsachen.
Auch relevante Lesefreigaben erhalten einen nachvollziehbaren Kontext. Eine begrenzte Auditansicht behauptet keine Vollständigkeit über historische Bereiche, die sie nicht enthält. Bei einer Prüfung werden deshalb Umfang, Zeitraum, Kettenverknüpfung, Archivquittungen und Zugriffsberechtigungen zusammen betrachtet.
Der Sicherheits- und Qualitätsaudit des Produkts ergänzt diese Betriebsnachweise. Änderungen werden auf Anforderung, Risiko, Datenschutz und Abhängigkeiten zurückgeführt. Die Freigabegrundlagen verlangen unabhängiges Review, konkrete Prüfergebnisse und die verantwortliche fachliche, sicherheitstechnische und betriebliche Beurteilung. Ein grüner Komponententest ersetzt weder eine klinische Abnahme noch ein unabhängiges Audit.
Weiterentwicklung ohne unkontrollierte Datenänderungen.
Pflegeabläufe, gesetzliche Grundlagen und technische Anforderungen verändern sich. Deshalb wird Oronela laufend weiterentwickelt. Echte Bedürfnisse aus Einrichtungen fliessen in konkrete Anforderungen ein; daraus entstehen nachvollziehbare Änderungen mit Tests und dokumentierten Auswirkungen. Bewährte Abläufe, Schnittstellen und historische Nachweise bleiben dabei eine gemeinsame Verantwortung von Fachentwicklung und Betrieb.
Die Versionierung betrifft Anwendung, Bibliotheken, Datenbankmigrationen, Regeln und die optionale KI. Eine geänderte Regel darf einen historischen Pflege- oder Abrechnungsnachweis nicht stillschweigend neu interpretieren. Ein aktueller Vorschlag verweist auf seine tatsächlich verwendeten Quellen; ein bereits erstelltes Original behält seine damalige Grundlage.
Datenbankänderungen werden in geordneten Migrationen geführt. Der Freigabeprozess verlangt definierte Ausgangs- und Zielstände, Abhängigkeiten, Kompatibilität, Prüfsummen und einen Wiederherstellungsweg. Eine sichere Rücknahme ist vom konkreten Änderungstyp und von späteren Schreibvorgängen abhängig. Wo eine direkte Rücknahme nicht zulässig ist, braucht es eine dokumentierte Korrektur oder Wiederherstellung.
Ein Update für eine selbst betriebene Installation bleibt anhand des Releasepakets prüfbar. Dazu gehören die neuen Versionen, die Auswirkungen auf Konfiguration und Schnittstellen sowie die erforderlichen Migrationsschritte. Im SaaS Betrieb bildet derselbe freigegebene Versionsstand die Grundlage der kontrollierten Auslieferung.
- Anforderung und Auswirkung verstehen.
- Code, Tests und Dokumentation gemeinsam ändern.
- Unabhängige Prüfung und passende Nachweise zusammenführen.
- Exakten Versionsstand freigeben und kontrolliert ausliefern.
- Betrieb beobachten, Rückmeldungen aufnehmen und Korrekturen nachvollziehbar versorgen.
KI bleibt optional und innerhalb Ihrer Datenumgebung.
Oronela funktioniert mit den von Ihrer Einrichtung gewählten Modulen. KI wird erst eingesetzt, wenn Sie diese wünschen und die betreffenden Funktionen aktiviert sind. Im Oronela SaaS Service laufen Modellverarbeitung und Wissenszugriff auf eigenen Oronela-Servern in der Schweiz. Es gibt keinen verdeckten Aufruf eines öffentlichen KI-Anbieters.
Der technische Prüfstand enthält eine tatsächlich lokal verwendete Qwen-Modelllaufzeit. Die Modellversion, die Laufzeit und die Artefaktherkunft werden separat festgehalten. Das Modell erhält den für einen freigegebenen Zweck benötigten Kontext. Die erlaubten Quellen, die aktuelle handelnde Person und die Entfernung eines Kontextes sind Bestandteile des Anwendungspfads.
Eine Antwort bleibt ein Vorschlag mit unterscheidbaren Quellen. Eine Zusammenfassung ersetzt keine dokumentierte Beobachtung, und eine Dienstplanempfehlung hebt keine fachliche Regel auf. Im dokumentierten Prüffall wählt das Modell zwischen bereits erneut geprüften Dienstplanangeboten; es verändert deren Einsätze nicht frei. Die Freigabe bleibt bei den dafür berechtigten Menschen.
Modellqualität wird mit passenden fachlichen Fällen und Datenschutzprüfungen beurteilt. Klassische Codeabdeckung kann die Adapterlogik messen, aber keine Aussage von 100 Prozent richtigen Modellantworten begründen. Eine neue Modell- oder Promptversion erhält deshalb einen eigenen Bewertungs- und Freigabekontext.
Ihre IT kann genauer hinsehen.
Wir stellen technische Eigenschaften so dar, dass sie überprüfbar bleiben. Fragen nach Verschlüsselung, Mandantengrenzen, Versionen oder Wiederherstellung lassen sich anhand konkreter Implementierungen und Nachweise besprechen. Der Quellcodezugang ermöglicht Ihren Fachpersonen, die für Ihre Einrichtung wichtigen Pfade selbst zu untersuchen.
Für einen Betrieb werden der tatsächliche Releaseumfang, seine Konfiguration und die zugehörigen Freigaben gemeinsam betrachtet. Allgemeine Produkttexte ersetzen diese Unterlagen nicht. Sprechen Sie uns an, wenn Ihre IT, Ihr Datenschutz oder ein unabhängiger Auditor einen bestimmten Nachweis benötigt oder wenn Sie den eigenen Betrieb mit uns besprechen möchten.