Intended Purpose
What is the specific function intended to do, for which users, patients, care setting and jurisdiction?
BestCura / Inside BestCura / Regulatory Architecture
Regulatory ArchitectureRegulatory boundaries are part of the architecture.
BestCura does not treat regulatory classification as a label applied after development. Functions are considered separately by intended purpose, clinical impact, execution effect, AI involvement and jurisdiction.
Rules constrain. AI informs. Professionals interpret. Execution requires authority. Evidence preserves accountability.
Intended Purpose→Regulatory Qualification→Classification→Evidence Requirements→Deployment Authority
Product Boundaries
Not every BestCura function is the same regulatory product.
Administrative healthcare IT, clinical documentation, patient-specific decision support, AI components and execution-critical functions are assessed separately. The concrete regulatory status depends on final intended purpose and actual use.
Patient Impact
Does it merely store data, provide information, influence a clinical decision, or constrain execution?
AI Boundary
AI generates intelligence, not standalone execution authority. AI outputs remain separate from professional and system authorization.
Authority
Professional role, credential, facility policy, task, patient context and jurisdiction are resolved separately from visibility and access.
Execution Boundary
A decision is not automatically an execution. Execution-critical actions can be revalidated against current authoritative state.
Evidence
Rule version, context, authority, decision and execution are designed to remain distinguishable and traceable.
Public Regulatory Status
Technically available does not automatically mean regulatory released.
BestCura separates technical maturity from regulatory release state. This avoids conflating development, validation and market authorization.
Healthcare IT FunctionAdministrative or supporting function
No medical intended purpose is inferred merely because a function exists.
Regulatory AssessmentIntended purpose under assessment
Patient impact, output, human review, jurisdiction and execution effect are evaluated.
Clinical Validation RequiredValidation before corresponding use
A clinically relevant output requires the evidence and validation path appropriate to its intended purpose.
Medical Device CandidatePotential MDSW pathway
Qualification depends on final intended purpose, function, patient impact and applicable law.
Not ReleasedNot released for the corresponding clinical execution
Technical availability is not presented as regulatory authorization.
Validated / ReleasedOnly with supporting evidence
This status should be used only when the specific function and intended purpose have completed the required pathway.
Important: This page describes BestCura's architecture and regulatory product boundaries. It does not claim blanket MDR, EU AI Act, HIPAA or other certification of the entire BestCura system. Regulatory status is function-, intended-purpose-, jurisdiction- and deployment-specific.
Execution Trust Boundary
The client describes intent. The authoritative state comes from the system.
For execution-critical workflows, BestCura is designed to resolve clinical state, context, applicable rules, authority and orders from authoritative server-side sources and revalidate them at the point of action.
Authoritative Server State
Patient and order state, rule set and authority are not treated as trusted simply because a client submits them.
Authenticated Actor Binding
The executing actor is bound to authenticated system identity rather than a freely supplied client field.
Point-of-Action Revalidation
Earlier authorization can become stale after a relevant state change. The execution point is therefore a distinct safety boundary.
Rule Governance
Clinical thresholds belong in versioned, source-bound and approved rules. Unapproved clinical rules should not create a hard clinical block.
External Frameworks
Architecture follows the function, not the buzzword.
For medical device software, actual intended purpose is central. For AI components, AI Act classification is not inferred simply from a function being “critical”; product-law qualification and third-party conformity requirements must be considered first.