Intended Purpose
Was soll die konkrete Funktion für welche Nutzer, Patienten, Versorgungssituation und Jurisdiktion leisten?
BestCura / Inside BestCura / Regulatory Architecture
Regulatory ArchitectureRegulatorische Grenzen sind Teil der Architektur.
BestCura behandelt regulatorische Einordnung nicht als Etikett, das nach der Entwicklung auf ein System geklebt wird. Funktionen werden nach Zweckbestimmung, klinischem Einfluss, Ausführungswirkung, AI-Beteiligung und Jurisdiktion getrennt betrachtet.
Rules constrain. AI informs. Professionals interpret. Execution requires authority. Evidence preserves accountability.
Intended Purpose→Regulatory Qualification→Classification→Evidence Requirements→Deployment Authority
Product Boundaries
Nicht jede BestCura-Funktion ist regulatorisch dasselbe Produkt.
Administrative Healthcare-IT, klinische Dokumentation, patientenspezifische Entscheidungsunterstützung, AI-Komponenten und ausführungskritische Funktionen werden getrennt bewertet. Die konkrete Einordnung hängt von der finalen Zweckbestimmung und dem tatsächlichen Einsatz ab.
Patient Impact
Speichert die Funktion nur Daten, informiert sie, beeinflusst sie eine klinische Entscheidung oder begrenzt sie eine Ausführung?
AI Boundary
AI erzeugt Intelligence, aber keine alleinige Execution Authority. AI-Ausgaben bleiben von professioneller und systemischer Autorisierung getrennt.
Authority
Professionelle Rolle, Credential, Facility Policy, Aufgabe, Patientenkontext und Jurisdiktion werden getrennt von Sichtbarkeit und Zugriff betrachtet.
Execution Boundary
Eine Entscheidung ist nicht automatisch eine Ausführung. Vor einer ausführungskritischen Handlung kann der aktuelle autoritative Systemzustand erneut geprüft werden.
Evidence
Regelversion, Kontext, Autorität, Entscheidung und Ausführung sollen nachvollziehbar voneinander getrennt und als Evidenz erhalten bleiben.
Public Regulatory Status
Technisch vorhanden bedeutet nicht automatisch regulatorisch freigegeben.
BestCura unterscheidet den technischen Reifegrad einer Funktion von ihrem regulatorischen Release-Status. Diese Trennung soll verhindern, dass Entwicklungsstand, Validierung und Marktzulassung sprachlich vermischt werden.
Healthcare IT FunctionAdministrative oder unterstützende Funktion
Keine medizinische Zweckbestimmung wird allein aus der Existenz der Funktion abgeleitet.
Regulatory AssessmentZweckbestimmung wird geprüft
Patienteneinfluss, Output, Human Review, Jurisdiktion und Ausführungswirkung werden bewertet.
Clinical Validation RequiredValidierung vor entsprechendem Einsatz
Ein klinisch relevanter Output benötigt den für die konkrete Zweckbestimmung erforderlichen Evidenz- und Validierungspfad.
Medical Device CandidateMDSW-Pfad möglich
Die Einordnung hängt von finalem Intended Purpose, Funktion, Patienteneinfluss und anwendbarem Recht ab.
Not ReleasedNicht für die entsprechende klinische Ausführung freigegeben
Technische Verfügbarkeit wird nicht als regulatorische Freigabe dargestellt.
Validated / ReleasedNur mit belastbarer Evidenz
Dieser Status soll nur verwendet werden, wenn die konkrete Funktion und Zweckbestimmung den erforderlichen Nachweisweg abgeschlossen haben.
Wichtiger Hinweis: Diese Seite beschreibt BestCuras Architektur und regulatorischen Produktgrenzen. Sie behauptet keine pauschale MDR-, EU-AI-Act-, HIPAA- oder sonstige Zertifizierung des gesamten BestCura-Systems. Die regulatorische Einordnung erfolgt funktions-, zweckbestimmungs-, jurisdiktions- und deploymentbezogen.
Execution Trust Boundary
Der Client beschreibt die Absicht. Der autoritative Zustand kommt vom System.
Für ausführungskritische Abläufe ist BestCura darauf ausgelegt, klinischen Zustand, Kontext, anwendbare Regeln, Authority und Order serverseitig aus autoritativen Quellen aufzulösen und vor dem Ausführungspunkt erneut zu prüfen.
Authoritative Server State
Patienten- und Auftragszustand, Rule Set und Authority sollen nicht vom Client als Wahrheit geliefert werden.
Authenticated Actor Binding
Die ausführende Identität wird an die authentifizierte Systemidentität gebunden, nicht an eine frei wählbare Client-Angabe.
Point-of-Action Revalidation
Eine frühere Autorisierung kann durch relevante Zustandsänderungen veralten. Der Ausführungspunkt bildet deshalb eine eigene Sicherheitsgrenze.
Rule Governance
Klinische Schwellen gehören in versionierte, quellengebundene und freigegebene Rules. Nicht freigegebene klinische Regeln sollen keine harte klinische Blockade erzeugen.
External Frameworks
Architektur folgt der Funktion, nicht dem Schlagwort.
Für Medical Device Software ist die tatsächliche Zweckbestimmung zentral. Bei AI-Komponenten wird die AI-Act-Einordnung nicht isoliert aus „kritischem“ Verhalten abgeleitet, sondern erst nach der produktrechtlichen Qualifikation und der Frage, ob die Voraussetzungen für eine Drittstellen-Konformitätsbewertung vorliegen.