Dr. Axis — Legal, Regulatory & Compliance Document Set

Status: DRAFT v10.1 — Internal Legal, Regulatory & Compliance Working Document — Counsel Review Draft

Classification: Internal legal, regulatory & compliance working document

Not legal advice. All jurisdiction-specific positions, policies and regulatory conclusions must be reviewed and approved by qualified legal, privacy and regulatory counsel before publication, commercial deployment, clinical use or app-store submission.

Statutory citations: All law/regulation citations in this document (numbers, years, titles) must be independently verified against official sources by counsel before reliance. This document has not been through a citation-verification pass beyond spot-checks noted inline.

Last updated: 25 August 2026

Owner: Dr. Axis Legal / Operations Team

Effective date: To be established upon approval and publication

---

0. Why This Document Is Scoped to Dr. Axis Only

Dr. Axis is Hajti Group's go-to-market entry point for the broader Nuraxis AI Clinical Intelligence Platform. It began as a calculator module and has evolved into a clinician-facing tool for calculations, protocol/guideline reference, and AI-assisted clinical information Q&A (referred to consistently throughout this document as the "Q&A function") — used deliberately to build clinician adoption and clinical champions ahead of the full Nuraxis AI continuous-monitoring MVP (including RoboCam integration).

Because Dr. Axis and the future full Nuraxis AI platform have materially different functionality and risk profiles, they are treated as separate regulatory tracks:

	Dr. Axis (current, in scope of this document)	Full Nuraxis AI MVP (future, separate track)
Function	Clinician-entered calculations, protocol/guideline display, Q&A function	Continuous multimodal patient monitoring, RoboCam bedside layer, early deterioration detection
Data input	Clinician-entered, session-based	Continuous physiological signals from monitoring devices
Output	Calculated result + sourced protocols, clinician validates/rejects and selects	Continuous alerts/context, closer to real-time decision support
Regulatory posture (working assessment, subject to counsel confirmation)	Function-level regulatory assessment pending; potential pathways include FDA Non-Device CDS or applicable enforcement-discretion policy (per function), and EU non-MDSW/MDSW depending on function and intended purpose. No classification is presumed or finalized.	Likely regulated medical device software; separate classification workstream
RoboCam hardware	Not applicable	Separate hardware medical-device classification track

Rule: Regulatory classification is assessed against Dr. Axis's actual current functionality, not the eventual Nuraxis AI vision. Any functional expansion (e.g., continuous monitoring, RoboCam integration, closed-loop alerting, auto-applied protocols) triggers mandatory re-assessment before release, and likely moves that functionality into the Full Nuraxis AI MVP track rather than Dr. Axis.

Assessment, not conformity. For the current Dr. Axis phase, the company's objective is not to claim regulatory conformity or approval. It is to: document a defensible intended purpose (Section 2.4); constrain the product to that intended purpose; complete the applicable function-level regulatory assessment (Section 4, Section 5); implement the required privacy, security, and clinical-safety controls; and avoid unsupported claims of regulatory approval, clearance, or conformity anywhere the product is described. This framing governs Section 17's deployment tiering and the "What we are not claiming" list within it.

---

1. Scope

This document set establishes the legal, regulatory, privacy, security and clinical-safety framework for Dr. Axis, a physician-facing AI clinical intelligence application developed by Hajti Group / Nuraxis AI.

Initial target markets, in sequence (see Section 3a — Phased Rollout):

1. Phase 1: Tunisia, United Arab Emirates
2. Phase 2: Broader GCC (Saudi Arabia, Qatar, Bahrain, Kuwait)
3. Phase 3: European Union, United States (post-pilot / post-Series A or on confirmed demand)

The purpose of this document set is to provide a common compliance foundation while recognizing that Dr. Axis may have different legal, regulatory and contractual obligations depending on jurisdiction, user type, customer/deployment model, data categories processed, actual functionality, and intended-use claims.

1.1 How to Read This Document — Statement-Type Key

Throughout this document, statements fall into three distinct categories. The type is not always restated at each sentence, but every substantive regulatory claim should be understood as one of the following, and readers (particularly counsel and new team members) should default to treating any unlabeled regulatory statement as a Working Hypothesis unless it is plainly a fact about the product itself:

* 🔹 FACT — a verifiable statement about what Dr. Axis actually does (e.g., "the clinician manually enters inputs"). These should be confirmed against the shipped product per Section 13's technical validation step, but are not legal conclusions.
* 🔸 WORKING HYPOTHESIS — this document's internal, non-binding assessment of how a fact pattern likely maps onto a regulatory framework (e.g., "this function's design is intended to align with Non-Device CDS Criterion 4"). These are reasoned positions, not settled classifications, and are explicitly marked "subject to counsel confirmation" throughout.
* 🔺 COUNSEL DETERMINATION REQUIRED — a question this document deliberately does not answer, and flags for formal legal/regulatory sign-off (e.g., every item in Section 14 and Section 15).

This document set does not, and is not intended to, resolve any 🔺 item on its own. Its function is to organize the facts and hypotheses clearly enough that counsel's determination is efficient rather than to substitute for that determination.

---

2. Product & Intended Purpose

2.1 Product

Dr. Axis is a physician-facing clinical calculation and reference application, developed as the go-to-market flagship of the broader Nuraxis AI platform (Hajti Group).

2.2 How Dr. Axis Works (Actual Functional Flow)

This sequence is the operative basis for Dr. Axis's regulatory positioning and must remain accurate to the shipped product at all times:

1. The clinician selects the calculation, protocol, or guideline area they need.
2. The clinician manually enters the relevant patient data and parameters.
3. Dr. Axis performs the calculation and displays the result together with the formula/method and inputs used.
4. Dr. Axis displays suggested, clearly sourced protocols and guidelines relevant to the result.
5. The clinician independently validates or rejects the calculated result. Rejection allows the clinician to re-enter inputs or flag the result; it is not a cosmetic option.
6. If validated, the clinician separately selects which protocol(s) or guideline(s), if any, to follow. Dr. Axis does not auto-apply, auto-order, or auto-select any protocol.
7. Both checkpoints (result validation and protocol selection) are logged, along with the inputs, calculated result, and sourced protocol version used, for auditability, workflow verification, safety monitoring, and controlled evidence-generation purposes (see Section 10 and Section 11, which defines what "evidence-generation" does and does not mean — these logs alone do not constitute clinical validation). Logging must be limited to the minimum data necessary for clinical safety, auditability, and legitimate operational purposes, with retention, access, deletion, and secondary-use rules governed by the applicable Data Retention Policy (Document 5), Information Security Policy (Document 9), and the relevant deployment-specific agreement — what exactly is logged, whether patient identifiers are included, retention period, access rights, whether logs constitute clinical records, and whether logs are ever used for model improvement are open questions this document does not resolve on its own (see Section 12's data-minimization principle and Open Action 4).

2.3 Intended-Use Principle

Dr. Axis is designed as a reference and calculation tool that supports, but does not make, clinical decisions. For the deterministic calculation function, the clinician:

* enters all inputs;
* independently reviews and validates or rejects each calculated result;
* independently selects which protocols or guidelines to apply.

For the Q&A function, the clinician instead independently evaluates the generated response, which is subject to the source-grounding, scope, and refusal controls defined in Section 4.4 and Section 10 — this is a different review mechanism from the calculation function's validate/reject checkpoint, not the same checkpoint applied to a different function. This distinction is deliberate and must not be flattened in product copy, the Privacy Policy, the Medical Disclaimer, or investor materials (see the cross-material consistency requirement in Section 4.4).

Dr. Axis does not acquire physiological signals from monitoring or diagnostic devices, and does not auto-generate orders. Dr. Axis is designed so that clinically consequential outputs are presented with an identifiable basis that the clinician can independently review, where such a basis exists — for the deterministic calculation function, this is the formula, inputs, and source guideline (Section 2.2); for the Q&A function, generated responses are instead subject to the source-grounding, scope, and refusal controls defined in Section 4.4 and Section 10, which are a different mechanism achieving the same underlying goal rather than an identical one.

Dr. Axis is designed not to make autonomous clinical decisions; clinical decisions remain with the clinician. This is not a marketing claim — it is a designed, logged, and auditable property of the product: the system produces outputs (calculated results, sourced protocols, AI-generated answers) that may inform a clinician's decision, but it does not autonomously make or execute a clinical decision on the patient's behalf. Product, engineering, and legal must keep the UI and the underlying interaction flow consistent with this principle as features evolve; any UI change that weakens either checkpoint (e.g., pre-selected validation, auto-applied protocols) must trigger legal review before release.

2.4 Scope Statement (for use in regulatory submissions, privacy documentation, and Hub71/investor materials)

Dr. Axis's current scope is limited to: (a) clinical calculations based on established, published formulas, performed on clinician-entered inputs; (b) reference display of clinical protocols and guidelines, clearly sourced; and (c) the Q&A function, providing clinician-directed responses referencing published clinical sources. For deterministic calculations, the clinician independently validates or rejects each calculated result and separately selects which protocol(s) to follow. For the Q&A function, the clinician independently evaluates each generated response, subject to the source-grounding, scope, and refusal controls described in Section 4.4 — this is a distinct review mechanism, not the calculation function's validate/reject checkpoint applied to a different function. Dr. Axis does not acquire physiological signals, does not auto-generate orders, and does not auto-apply or auto-select protocols on the clinician's behalf. This scope is deliberately narrower than the full Nuraxis AI platform and is re-assessed at each functional expansion (e.g., RoboCam integration, continuous monitoring, closed-loop alerting).

2.5 Regulatory Classification Principle

Dr. Axis must not be positioned outside medical-device / clinical-decision-support regulation merely by describing it as "informational" or "educational." Classification must be determined from actual functionality, intended purpose, clinical claims, user population, outputs, level of automation, and role in diagnosis, monitoring, prediction or treatment decisions — assessed against the actual flow in Section 2.2, not aspirational language.

2.5a Default Data-Use Rule (Global)

Patient-identifiable or otherwise protected clinical data processed through Dr. Axis must not be used for foundation-model training, model fine-tuning, product development, or unrelated analytics unless the specific processing purpose, legal basis, contractual authorization, technical controls, and jurisdictional requirements have been separately assessed and approved. This is a default-off rule, not a default-on rule with listed exceptions — any new use of patient data beyond the immediate clinical interaction requires affirmative approval before implementation, not merely the absence of an objection. This rule governs Section 8 (controller/processor allocation for such secondary uses), Section 10 (AI governance controls), and Section 12 (data minimization).

2.6 What This Document Does Not Claim (Summary — see Section 17.1a for the deployment-specific version)

To prevent this document's careful internal reasoning from being flattened into a marketing claim, three things bear repeating up front: Dr. Axis is not positioned as universally exempt from medical-device regulation; its regulatory status is function-specific and pending counsel confirmation (Section 4, Section 5); and its positioning says nothing about the regulatory status of the future full Nuraxis AI platform (Section 0). The full claims-governance list for the Tier 1 physician evaluation appears in Section 17.1a.

---

3. Jurisdictional Regulatory Framework

Jurisdiction	Primary framework(s)	Principal regulatory / compliance focus
Tunisia	Organic Law No. 2004-63 on protection of personal data; Tunisian Code of Medical Ethics; applicable telemedicine and health regulations	Personal-data protection, medical confidentiality, professional ethics, health/telemedicine requirements
United Arab Emirates	Federal Decree-Law No. 45 of 2021 on Personal Data Protection and implementing framework; Department of Health – Abu Dhabi (DoH) requirements; ADHICS (see footnote¹)	Health-data protection, cross-border transfers, DoH-regulated deployment requirements, healthcare-sector cybersecurity (ADHICS)
GCC (broader)	KSA PDPL and Implementing Regulations; Qatar Law No. 13 of 2016; Bahrain PDPL; applicable Kuwait privacy/health-sector requirements	Health-data protection, cross-border transfers, localization/hosting, cybersecurity, healthcare-sector requirements
European Union	GDPR (Reg. EU 2016/679); applicable ePrivacy rules; EU MDR (Reg. EU 2017/745)/MDCG 2019-11 Rev.1 (June 2025) guidance where applicable; EU AI Act (Reg. EU 2024/1689, as amended by Regulation (EU) 2026/1744, in force July 27, 2026) — high-risk classification via Article 6(1) or Article 6(2)/Annex III, where applicable (see Section 5.4 for the amended compliance timeline); other EU digital-health requirements as relevant to the specific deployment	Personal data, health data, medical-device software (MDSW) classification, AI Act high-risk classification (assessed separately from MDR outcome), cybersecurity, transparency, data subject rights
United States	FD&C Act; FDA Clinical Decision Support Software guidance (January 2026) — Non-Device CDS criteria; HIPAA where applicable; FTC Act; FTC Health Breach Notification Rule; applicable state privacy and health-data laws	Non-Device CDS assessment, health-data privacy, breach notification, cybersecurity, state-level privacy obligations

¹ ADHICS = Abu Dhabi Healthcare Information and Cyber Security Standard, current version ADHICS V2 (superseding the 2019 standard). See Section 7 for the fuller UAE/Abu Dhabi framework, including DoH Responsible AI requirements as a separate track from ADHICS's cybersecurity controls. Working hypothesis, counsel confirmation required: the applicability of the UAE federal PDPL to Dr. Axis's health-related processing must be confirmed against the current statutory scope, applicable implementing instruments, and sector-specific healthcare requirements. This document does not assume that the general PDPL alone governs all clinical/health-data processing in a DoH-regulated deployment — see Open Action 19.

Important: ADHICS and the EU AI Act are each independent tests — meeting Non-Device CDS criteria (US) or falling outside MDR (EU) does not automatically satisfy ADHICS security requirements or avoid EU AI Act high-risk classification. Each must be assessed on its own criteria.

3a. Phased Regulatory Rollout (Resourcing Sequence)

Given pre-seed stage resourcing, jurisdictional workstreams are sequenced rather than pursued in parallel:

* Phase 1 — Now: Tunisia (home base) and United Arab Emirates (Hub71 / DoH / ADHICS), matching actual near-term deployment plans.
* Phase 2 — Post-pilot: Broader GCC (Saudi Arabia, Qatar, Bahrain, Kuwait), triggered by confirmed hospital-group interest in those markets.
* Phase 3 — Post-Series A or confirmed demand: European Union (GDPR + MDCG 2019-11 Rev.1 + AI Act) and United States (Non-Device CDS + HIPAA/FTC + state law).

Each phase's regulatory workstream is opened when commercial deployment in that market becomes concrete, not preemptively.

---

4. United States — FDA Software Regulatory Assessment

🔺 Partial primary-source verification completed; full counsel review still required. This section was originally built from secondary legal analysis of FDA's January 2026 CDS guidance. The core four-criteria structure (Section 4.2) and the "simple medical calculations" example list (Section 4.3) have since been checked directly against FDA's own published Clinical Decision Support Software FAQ page and are consistent with it. This is a meaningfully stronger basis than secondary commentary alone, but it is still not a substitute for function-specific counsel sign-off — FDA FAQ pages are informal agency guidance, not binding law, and the application of these criteria to Dr. Axis's specific functions has not been assessed by counsel. Sections 4.2–4.3 should still be reviewed by counsel before any external reliance, but the underlying factual basis is now primary-source-checked rather than purely secondary.

4.1 Function-Level Assessment

Dr. Axis must be assessed function-by-function, not as a single product with one FDA classification. FDA's Clinical Decision Support Software Final Guidance, re-issued January 29, 2026 (following an initial January 6, 2026 issuance, both superseding the September 2022 guidance), recognizes that a single product can contain multiple functions with different regulatory treatment.

Dr. Axis's three function categories, assessed separately:

Function category	Description	Applicable analysis
Deterministic clinical calculations	Formula-based outputs from clinician-entered inputs (see Section 4.3)	Non-Device CDS four-criteria test; enforcement discretion analysis where a single output is the only clinically appropriate one
Clinical reference / protocol display	Display of published protocols and guidelines matched to a result	Generally lower regulatory risk; still assessed against the four criteria
Q&A function	Open-ended clinician questions answered by the AI system (see Section 4.4)	Non-Device CDS four-criteria test; hallucination/traceability risk is the dominant concern (Section 10)

The company must not represent Dr. Axis as a whole as "Non-Device CDS" until this function-level assessment has been completed by qualified counsel. Marketing, investor, and regulatory materials should describe the assessed status of specific functions, not the product as an undifferentiated whole.

4.2 Non-Device CDS — The Four Criteria

A software function is excluded from the FDA device definition as Non-Device CDS when it satisfies all four statutory criteria under Section 520(o)(1)(E) of the FD&C Act (21st Century Cures Act):

#	Criterion (statutory/guidance language — 🔺 verify against primary FDA text before external use)	Dr. Axis working position — 🔸 WORKING HYPOTHESIS, subject to counsel confirmation
1	Not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system	Working position: satisfied — all inputs are clinician-entered; no image, IVD signal, or signal-acquisition-system input. Continuous monitoring is explicitly out of scope for Dr. Axis (see Section 0).
2	Intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (e.g., peer-reviewed studies, clinical practice guidelines)	Working position: satisfied — calculations and published guideline/protocol content only.
3	Intended for the purpose of supporting or providing recommendations to a healthcare professional about prevention, diagnosis, or treatment	Working position: satisfied by design. FDA's 2026 guidance materially changed the analysis of this criterion — see Section 4.3.
4	Intended for the purpose of enabling the HCP to independently review the basis for the recommendation, so that the HCP does not rely primarily on the recommendation itself	Design intent: formula, inputs, and sourced protocol are always shown; result validate/reject and protocol selection are separate, logged clinician actions (Section 2.2). Whether this satisfies the criterion is a legal determination, not a product self-assessment.

Criterion 4 is a frequent point of failure for CDS tools generally, and is the criterion most directly shaped by product design choices. Dr. Axis's two-checkpoint flow (validate/reject result → separately select protocol) reflects a deliberate design decision aimed at criterion 4, but whether it is sufficient — on its own or combined with the other criteria — is a determination for qualified regulatory counsel, not a conclusion this document should assert. This checkpoint flow, as currently described, applies to the deterministic calculation functions. It must not be assumed to extend automatically to the Q&A function — see Section 4.4.

4.3 Deterministic Clinical Calculations — Enforcement Discretion Pathway

🔺 Nothing in this section constitutes a conclusion that any Dr. Axis function qualifies for Non-Device CDS treatment or FDA enforcement discretion. The examples and pathways described below are working hypotheses, drawn from secondary legal analysis of FDA's January 2026 CDS guidance rather than a primary-source reading by this team, pending primary-source verification and function-specific counsel assessment (see the verification banner at the top of Section 4).

FDA's current guidance separately discusses simple medical calculations routinely used in clinical practice and states that such software is not Non-Device CDS, while indicating that FDA intends to exercise enforcement discretion for qualifying functions under specified conditions:

Simple, routine clinical calculations are not, by themselves, Non-Device CDS. FDA's own published Clinical Decision Support Software FAQ explicitly lists, as examples of simple medical calculations subject to this treatment: Body Mass Index (BMI), Total Body Water/Urea Volume of Distribution, mean arterial pressure, Glasgow Coma Scale score, APGAR score, NIH Stroke Scale, and delivery date estimator. FDA states these are examples of a non-exhaustive list of functions for which it "intends to exercise enforcement discretion" as software that "automates simple tasks for health care professionals," including calculations "routinely used in clinical practice and [that] can be calculated manually if needed." This list has been confirmed directly against FDA's published FAQ page as of this document's last update; counsel should still confirm the FAQ's current text has not changed and that it applies to Dr. Axis's specific calculation functions.*
* Criterion 3 was materially loosened for single-output tools. The prior (2022) guidance treated a single, specific recommendation as failing Criterion 3. The current 2026 guidance states FDA intends to exercise enforcement discretion for a software function that provides a single output where only one recommendation is clinically appropriate, provided the function meets the other three criteria.

Implication for Dr. Axis: a calculator that performs a simple medical calculation routinely used in clinical practice may fall within FDA's enforcement-discretion policy where it provides only one clinically appropriate recommendation and satisfies the remaining applicable criteria — this is a materially different (and more conservative) framing than treating the calculator as straightforwardly Non-Device CDS. Enforcement discretion is not the same thing as a legal determination that a function is outside the statutory definition of a device; it describes FDA's stated enforcement policy for specified functions, not a conclusion that the function is non-device software. This distinction must not be collapsed in product, marketing, or investor materials — a function subject to enforcement discretion remains, as a legal matter, potentially a device; FDA has simply indicated it does not intend to enforce premarket requirements against it under stated conditions. Two distinct, non-identical pathways must be assessed by counsel for each calculation function:

1. Non-Device CDS (all four criteria independently satisfied), or
2. Device software function subject to FDA enforcement discretion (single clinically-appropriate output, other criteria met).

These pathways have different practical and disclosure implications and must not be conflated, and neither should be assumed by default. Until counsel confirms which pathway (if either) applies to each calculation function, marketing and product materials should avoid asserting that Dr. Axis's calculators are categorically non-regulated or categorically Non-Device CDS.

4.4 Q&A Function (AI-Assisted Clinical Information Q&A)

The Q&A function must be assessed separately from the deterministic calculators, and must not be assumed to inherit the calculator functions' validate/reject workflow or its resulting analysis. Concretely:

* Deterministic calculations: result displayed → formula shown → inputs shown → clinician validate/reject checkpoint → protocol selection is a separate clinician action (Section 2.2).
* Q&A function (current state, to be confirmed against the shipped product): answer displayed, ideally with source citations and limitations noted; the clinician remains responsible for evaluating the answer; there is no automatic downstream clinical action. If the Q&A function does not currently have a formal accept/reject or validation action equivalent to the calculator workflow, that must be stated plainly in product and regulatory documentation rather than implied to exist.

Cross-material consistency requirement: this distinction must be maintained consistently across every place Dr. Axis's behavior is described — the Privacy Policy, Medical Disclaimer, in-app UI copy, website, App Store / marketplace listing, and investor materials. None of these should state or imply that "the clinician validates every Dr. Axis output" as a blanket claim; the validate/reject checkpoint is specific to the deterministic calculation function (Section 2.2), and the Q&A function's actual review mechanism (clinician review + source traceability + restricted scope + refusal behavior, per the table below) must be described on its own terms.

For the Q&A function, the analysis must explicitly address, beyond Criterion 4 alone:

* whether a given output constitutes a recommendation concerning prevention, diagnosis, or treatment (Criterion 3 relevance);
* whether the clinician can independently review the basis for that specific output (Criterion 4);
whether the intended use is time-critical — the 2026 FDA framework does not treat "time-critical" as a standalone Criterion 3 prohibition the way the 2022 guidance implicitly did; however, FDA's published FAQ expressly and directly states that "software that is meant to support time-critical decision making does not meet the definition of Non-Device CDS," noting that time-sensitive or critical outputs often involve detecting life-threatening and/or time-critical conditions. This concern is addressed through the Criterion 4 analysis specifically: FDA's position is that time-critical functions generally do not satisfy Criterion 4 because a healthcare professional is unlikely to have sufficient time to independently review the basis for the recommendation before acting. This is a direct, current FDA statement, not merely an inference from secondary commentary — but it does not mean every function operating in a time-sensitive care setting (e.g., an emergency department) is automatically a device; the question is whether the specific function's intended use* is to support time-critical decision-making. As a matter of both this regulatory concern and product safety policy, Dr. Axis's Q&A function is not intended for emergency, time-critical, or autonomous clinical decision-making; any expansion into such use requires a separate regulatory assessment before deployment;
* whether the system is expected to be relied upon primarily for an individual patient decision;
* whether cited sources actually support the generated answer (citation-groundedness — see Section 10);
* whether the system introduces patient-specific interpretation rather than merely retrieving or displaying information.

Product constraint: Dr. Axis's Q&A function must not be intended, marketed, or operationally positioned for time-critical clinical decision-making unless and until a separate FDA device-regulatory assessment specific to that use has been completed.

Q&A function operational boundary (product safety specification, not merely governance language):

Q&A category	Dr. Axis treatment
General medical knowledge (definitions, mechanisms, background)	Allowed
Published guideline explanation	Allowed, with source citation
Explanation of a calculation or formula	Allowed
Patient-specific interpretation of entered data	Restricted / controlled — see detailed specification below.
Diagnosis	Not permitted
Treatment selection	Not permitted
Medication dosing recommendation	Not permitted, unless separately assessed and approved as its own function under Section 4.3
Emergency / time-critical decision support	Not permitted
Autonomous clinical recommendation (i.e., an output presented as a directive rather than a reference point)	Not permitted
Unsupported or off-label question	Refuse and escalate rather than speculate

This table is the operative product specification for what Dr. Axis's Q&A function is permitted to do — engineering and product must treat it as a hard boundary, not aspirational guidance, and any proposed feature that would move a row from "Not permitted" toward "Allowed" requires the Section 4.1/4.3 assessment to be repeated, not a product decision alone.

This table describes a Dr. Axis product-scope restriction, not a categorical statement about what FDA's Non-Device CDS framework permits or prohibits in general. FDA's own guidance discusses Non-Device CDS examples involving differential diagnosis support, treatment options, prioritized treatment options, and next-step options, provided the relevant criteria are satisfied — so "diagnosis" and "treatment selection" are not per se excluded from Non-Device CDS treatment as a matter of FDA policy. Dr. Axis's table above is more conservative than what FDA's framework might permit, reflecting this document's current risk-management posture for a pre-seed company's first physician evaluation (Section 17), not the outer boundary of what FDA would allow. This distinction matters because expanding the table later is a product/business decision informed by a fresh regulatory assessment — it is not "asking FDA for an exception," since the restriction was never an FDA requirement in the first place.

Detailed specification — "Patient-specific interpretation of entered data." This is the highest-ambiguity row in the table above and "Restricted / controlled" is not by itself an operational instruction. It must be broken down as follows before engineering can build against it:

* Permitted within this row: the AI may (a) restate or contextualize a value the clinician has already entered or a result the calculator has already produced (e.g., "this creatinine clearance value falls in the range this guideline associates with dose adjustment"); (b) explain what a published guideline says about a given patient parameter in general terms; (c) surface multiple relevant considerations from published sources for the clinician to weigh, explicitly presented as considerations rather than a conclusion.
* Not permitted within this row, and must trigger refusal/escalation instead: (a) synthesizing multiple patient-specific inputs into a single novel clinical conclusion not directly stated in a cited source (this crosses into diagnosis/treatment territory); (b) any output using directive language (defined below) rather than a reference framing; (c) resolving ambiguity or conflicting guidance on the AI's own judgment rather than presenting the conflict to the clinician. As a matter of Dr. Axis product-safety policy (not an implied FDA requirement), for patient-specific interpretation the system must refuse or escalate where it cannot provide a specific, checkable source supporting the relevant statement.
* Refusal trigger (concrete, testable condition): the system must decline to answer, and instead state its limitation, when it cannot ground its answer in a specific, checkable source, when the question requires synthesizing across multiple patient-specific data points into a novel conclusion, or when the question falls into any "Not permitted" row above (diagnosis, treatment selection, dosing, emergency use).
* Escalation trigger: a refusal for a patient-specific question should be paired with a prompt directing the clinician to their own judgment or to a specialist/consult, not merely a bare refusal message.

Directive language — defined technical safety-control category. The underlying control is not "the AI doesn't make the decision" as an abstract principle; it is that the system must not present a patient-specific clinical conclusion or directive as its own judgment. Concretely, outputs using constructions such as the following are treated as prohibited directive language unless that specific functionality has been separately assessed and approved under Section 4.3:

* "You should start / stop / increase / decrease..."
* "The patient should receive..." / "The patient needs..."
* "This patient has [diagnosis]..."
* "The appropriate treatment is..."
* "Increase the dose to..." / "Discontinue the medication..."

This list is illustrative, not exhaustive, and should be extended by product/engineering as real usage surfaces new phrasing patterns with the same directive effect. Detecting and blocking this category of output (via prompt design, output filtering, or both) is an engineering deliverable — see Open Action 24 and Section 17's risk-control tier.

🔺 This detailed specification is a proposed product/safety control, not yet confirmed as sufficient by regulatory counsel — it is offered here as the level of precision engineering needs to build against, and should be reviewed alongside the Section 4.1 function-level FDA assessment before being treated as final.

4.5 Implementation Requirements to Preserve Regulatory Positioning

* Validate and Reject controls must carry equal visual weight — no pre-selection, no default-accept styling.
* Rejecting a result must allow correction/re-entry or flagging — not a dead end.
* Every suggested protocol/guideline must show a visible, traceable source (name, publisher, version/date).
* Protocol selection must be a distinct clinician action, never auto-applied following result validation.
* Product/marketing copy must use language consistent with reference/support ("suggested protocols matching this result, for you to review") — never authoritative/directive language ("recommended protocol," "follow this treatment").
* Any proposed feature that would acquire device/monitoring signals, auto-apply protocols, or push alerts without a clinician step must be flagged to legal before development begins, not before release.

4.6 HIPAA / Business Associate

Relationship- and deployment-dependent. Dr. Axis may become a Business Associate where it creates, receives, maintains, or transmits PHI on behalf of a HIPAA Covered Entity. Not automatic merely from selling software to a healthcare organization — actual PHI access must be assessed per deployment.

4.7 FTC Health Breach Notification Rule

Where Dr. Axis operates outside HIPAA scope but within the FTC's Health Breach Notification Rule (certain personal-health-record vendors), applicable breach-notification obligations must be assessed.

4.8 State Privacy Laws

U.S. compliance must separately assess applicable state-level privacy and health-data laws; HIPAA should not be assumed to be the complete U.S. framework.

4.9 U.S. AI Governance & Evidence Documentation

Maintain: AI model documentation; intended-use documentation per function category (Section 4.1); model/version records; clinical validation records; human-oversight procedures (Section 2.2 flow); error and incident management; cybersecurity controls; audit logs (Section 2.2 step 7); change-management procedures; evidence supporting whichever regulatory pathway (Non-Device CDS or enforcement discretion) applies to each function.

4.10 Required Counsel Determination

Action: Obtain a U.S. regulatory assessment, performed function-by-function per Section 4.1, confirming the applicable pathway (Non-Device CDS vs. enforcement discretion vs. regulated device) for each of Dr. Axis's calculation, reference, and Q&A functions before commercial deployment or definitive claims in the United States.

---

5. European Union

5.1 GDPR

Determine Hajti Group's role (controller / joint controller / processor) per processing activity. Health data is a special category requiring an appropriate legal basis and Article 9 condition.

5.2 EU Representative

Not automatically required merely because Dr. Axis targets EU users — assessed under GDPR Articles 3 and 27 based on EU establishment, Article 3(2) applicability, and processing nature/scale.

5.3 EU MDR / MDCG 2019-11 Rev.1 (June 2025)

MDCG 2019-11 Rev.1 (June 2025) is the current version of the European Commission's guidance on qualification and classification of software under the MDR/IVDR. As with all MDCG guidance documents, it is not itself legally binding and does not constitute a formal Commission position with the force of law — it reflects the Medical Device Coordination Group's endorsed interpretation and is treated as persuasive/authoritative in practice, but the MDR itself remains the binding legal text. Whether Dr. Axis qualifies as MDSW must be assessed primarily against its manufacturer-defined intended purpose and actual functionality, including its claims, outputs, and role in clinical decision-making — Rev.1 is explicit that intended purpose is determined from labeling, instructions for use, promotional/sales material, and clinical evaluation, not from technical architecture alone (consistent with the classification principle in Section 2.5).

The fact that Dr. Axis displays published guidance, exposes calculation inputs/formulas, and requires clinician validation and separate protocol selection may support a non-MDSW position for particular functions, but does not by itself establish that conclusion. This determination must be made by qualified counsel and, where appropriate, Notified Body input — this document describes design intent and a working hypothesis, not a settled classification.

Rev.1 also reinforces a modular approach (each software module/function assessed separately) and clarifies that software processing health information is only in scope where it directly serves a medical purpose — both points reinforce the function-level assessment approach in Section 4.1, applied equally on the EU side, and both reinforce the primacy of intended purpose over architecture described above.

A conclusion that a function is not MDSW does not eliminate other applicable obligations, including GDPR, cybersecurity, professional, contractual, or AI Act requirements (Section 5.4) — non-MDSW status is a conclusion about one specific regulatory question, not a general "not regulated" status.

5.4 EU AI Act — Assessed Separately from MDR

Regulatory update: As of the date of this document, Regulation (EU) 2026/1744 (the "Digital Omnibus on AI"), which entered into force July 27, 2026, has amended the EU AI Act and modifies the applicable implementation timeline. This amendment deferred, but did not cancel, the high-risk compliance timeline: obligations for stand-alone Annex III high-risk systems are stated to now apply from December 2, 2027 (previously August 2, 2026), and obligations for AI embedded in Annex I-covered products from August 2, 2028 (previously August 2, 2027). The AI Act's general application date and Article 50 transparency obligations were not deferred and remain in effect from August 2, 2026 — the deferral applies specifically to the high-risk compliance obligations, not the Act as a whole. The amendment's existence and entry-into-force date are confirmed (see Source Register EU-02); the specific dates stated here should nevertheless be rechecked against the consolidated AI Act text and applicable implementing guidance immediately before any EU deployment decision, since practical implementation details can continue to evolve even where the core amendment is settled.

The EU AI Act assessment must be conducted independently from the MDR/MDSW assessment. MDR qualification and AI Act classification are separate legal questions. The correct order of analysis is:

1. Primary question (Article 6(1)): Is Dr. Axis, or a specific function of it, itself a product — or a safety component of a product — covered by EU harmonisation legislation listed in Annex I, such that it would require third-party conformity assessment under that legislation? This is the route most directly connected to the MDR/MDSW analysis in Section 5.3, since MDR is itself Annex I-listed legislation.
2. Separate question (Article 6(2)): Independently of the Article 6(1) analysis, does any specific Dr. Axis function fall within an Annex III high-risk use case? Ordinary clinician-facing clinical decision support is not automatically an Annex III use case simply because it is healthcare-related. Annex III's healthcare-related examples are narrower and more specific than "healthcare AI" generally — they include categories such as public-authority eligibility determinations for healthcare services, health/life insurance risk assessment and pricing, emergency-call classification/dispatch, and emergency healthcare patient triage. A physician using Dr. Axis for clinical calculations, reference display, or Q&A does not obviously fall into these specific categories, but this must be confirmed against the current Annex III text function-by-function, not assumed either way. Accordingly, the fact that Dr. Axis is used by healthcare professionals, processes health-related information, or provides clinical information does not by itself establish Annex III high-risk status; the specific Annex III use case and the precise intended purpose must be identified before Article 6(3) is analyzed.
3. Only if Article 6(2)/Annex III applies, assess Article 6(3): the derogation described below.

Relevant to Dr. Axis's human-in-the-loop architecture, if and only if an Annex III category is found to apply: Article 6(3) provides a derogation under which an Annex III system is not considered high-risk where it does not pose a significant risk of harm to health, safety, or fundamental rights — including by not materially influencing the outcome of decision-making — provided at least one of four conditions is met: the system performs a narrow procedural task; improves the result of a previously completed human activity; detects decision-making patterns without replacing or influencing the prior human assessment (without proper human review); or performs a preparatory task. This derogation does not apply, and the system is always high-risk, if it performs profiling of natural persons — this carve-out must be checked explicitly and cannot be assumed away. Where a provider relies on the Article 6(3) derogation, it must document that assessment before placing the system on the market or putting it into service.

Article 6(3) should be treated as a counsel-assessed exception/derogation, not as the product's default AI Act positioning, and only becomes relevant at all if Article 6(2)/Annex III is found to apply in step 2 above. The correct strategic framing is: "we need to determine whether Article 6(1) or Article 6(2) applies at all, and if Article 6(2) applies, whether the Article 6(3) derogation can legitimately be relied upon" — not "we are not high-risk because Article 6(3) applies," and not "we are healthcare AI, so Annex III obviously applies." Building product or investor positioning around either of these shortcuts would overstate a conclusion this document does not reach.

Action: Obtain written regulatory counsel advice — covering MDR/MDCG 2019-11 Rev.1, the Article 6(1) vs. Article 6(2) threshold question, Annex III applicability specifically (not assumed from the healthcare context alone), and the Article 6(3) derogation if applicable — each as an independent assessment, and incorporating the amended Regulation (EU) 2026/1744 timeline, before EU commercial deployment.

---

6. Tunisia

Framework must address: personal-data protection (Organic Law No. 2004-63); health/medical data; confidentiality; medical ethics; applicable telemedicine requirements; healthcare-professional obligations; formalities before processing/transferring personal data.

Action: Obtain Tunisian counsel confirmation of applicable INPDP declarations, authorizations, and registrations before processing Tunisian health data at scale.

---

7. GCC

Treated as a country-by-country compliance program, not a single GCC-wide regime.

United Arab Emirates / Abu Dhabi (Phase 1 priority)

Given that Dr. Axis is explicitly an AI-based healthcare application rather than generic SaaS, the applicable UAE/Abu Dhabi framework is broader than PDPL plus a single security standard, and should be organized as follows rather than collapsed into one line:

* Federal data protection: Federal Decree-Law No. 45 of 2021 and implementing framework. Note the caveat already flagged in Section 3's footnote — whether the federal PDPL applies to Dr. Axis's health-related processing specifically, versus sector-specific health-data legislation, requires confirmation.
* DoH requirements generally: Department of Health – Abu Dhabi (DoH) requirements — directly relevant given active Hub71+ Life Sciences engagement.
* ADHICS V2 — the current version of the Abu Dhabi Healthcare Information and Cyber Security Standard, which superseded the 2019 standard (and the separate 2020 IoMT Security Standard and Patient Healthcare Data Privacy Standard, both folded into V2). ADHICS V2 uses a capability-based, three-tier control model and explicitly includes AI use among its mandatory policy domains — relevant to Dr. Axis specifically, not just to hosting/infrastructure generally.
* DoH Responsible AI requirements — DoH has published Responsible AI guidance for the Abu Dhabi healthcare ecosystem (referencing ADHICS explicitly) covering, among other things, patient consent/opt-out for AI-driven services, data provenance and sourcing requirements for datasets used in AI systems, and third-party data-sharing due diligence. This is a separate compliance track from ADHICS's cybersecurity controls and must be assessed on its own terms — treating "ADHICS-compliant" as equivalent to "Responsible-AI-compliant" would be a gap, not a simplification.
* Data localization / cross-border transfer, as distinct from ADHICS cybersecurity controls — now confirmed as two separate, overlapping legal bases. Federal Law No. 2 of 2019 (the "Health Data Law," also referred to as the "ICT Health Law") is a UAE federal law — not an Abu Dhabi-specific one — regulating the use of ICT in the health sector across the UAE, including free zones. It imposes a general prohibition on transferring, storing, generating, or processing UAE health data outside the UAE, subject to exemptions under Ministerial Resolution 51 of 2021 and implementing regulations under Cabinet Decision No. 32 of 2020. Separately, ADHICS itself contains its own cross-border restriction (in its Communications Policy control area), independently limiting the use of cloud services/infrastructure to store, process, or share health information outside approved arrangements, subject to DoH case-by-case exceptions. These are two distinct, overlapping legal requirements — satisfying one does not automatically satisfy the other, and both must be assessed for any cloud/hosting architecture decision. Practical note: some engagements are additionally subject to case-by-case Emirate-level health-authority approval for any cross-border data flow not squarely covered by a listed exemption.
* DoH interoperability / Health Information Exchange (HIE) requirements — conditional. DoH maintains HIE standards specifying data formats, coding standards, and minimum datasets for systems that connect to Abu Dhabi's health information exchange infrastructure (e.g., Malaffi). This is not currently a Tier 1 requirement for Dr. Axis, since Dr. Axis is not initially expected to integrate with a hospital's EMR/HIE infrastructure — but if and when such integration is scoped, it must be assessed as a distinct regulatory/technical requirement, not treated as a standard API integration project.
* Cross-border transfers; controller/processor responsibilities.

Saudi Arabia, Qatar, Bahrain, Kuwait (Phase 2)

Assessment scope per country: PDPL/local data-protection law; sensitive/health data; controller/processor roles; cross-border transfers (assessed against specific legal mechanisms, not blanket consent); cybersecurity; healthcare-sector requirements; data-hosting requirements where applicable.

---

8. Patient Data Legal-Basis & Controller/Processor Framework

Dr. Axis's clinician-entered inputs may include patient-identifiable clinical data. This framework must address the following elements separately, rather than being collapsed into a single "consent" narrative:

* Legal basis. The hospital/healthcare provider, as the data controller in the treatment relationship, is responsible for establishing a valid legal basis — which may be patient consent, but may equally be another lawful basis (e.g., necessity for the provision of healthcare, public interest, or legal obligation) depending on applicable law — for use of patient data within clinical workflows, including tools such as Dr. Axis. Consent should not be assumed to be the operative legal basis by default; the correct basis is jurisdiction- and deployment-specific and must be confirmed by counsel.
* Sensitive/special-category data condition. Where applicable (e.g., GDPR Article 9, or equivalent health-data provisions in Tunisia/GCC frameworks), the specific condition permitting processing of health data must be identified separately from the general legal basis.
* Transparency. Patients and clinicians must be informed of Dr. Axis's role in the workflow consistent with the provider's own transparency obligations and Dr. Axis's Privacy Policy.
* Controller/processor allocation. Hajti Group / Dr. Axis is expected to act as a processor for certain hospital/B2B processing activities where it processes patient data solely on documented instructions from the healthcare provider. This role must nevertheless be determined separately for each processing activity and deployment model — including any processing undertaken for product analytics, security, service improvement, AI model operation, or other independent purposes. Controller/processor status is functional, not something a contract can declare on its own — a DPA that labels Dr. Axis "processor" does not control the analysis if Dr. Axis in fact determines the purposes and means of a given processing activity (e.g., independent use of data for model improvement may result in controller status for that processing activity specifically, though the exact analysis is jurisdiction-specific and requires counsel confirmation).
* Hospital instructions. Processing under the processor role must be limited to documented instructions from the provider, recorded in the Data Processing Addendum (Document 6).
* Secondary uses (analytics, model improvement, security monitoring, customer support) must each be mapped individually against the controller/processor question above — these are the activities most likely to shift Dr. Axis into a controller role if not carefully scoped and consented to separately.
* Retention of patient data processed through Dr. Axis must follow the Data Retention Policy (Document 5) and any provider-specific instructions.

This division of responsibility must be explicit in every hospital/B2B deployment contract and reflected consistently in the Data Processing Addendum and Privacy Policy, with each processing activity mapped individually rather than assumed to fall under a single blanket role.

Action: Confirm this legal-basis and controller/processor model with counsel per jurisdiction, particularly Tunisia and UAE for Phase 1 deployments, with each processing activity (clinical use, analytics, model improvement, security, support) assessed separately, and ensure hospital onboarding materials state the applicable model explicitly.

---

9. Document Index

#	Document	File	Purpose
1	Privacy Policy	01-privacy-policy.md	Public-facing privacy notice
2	Terms of Service	02-terms-of-service.md	End-user contractual terms
3	Medical Disclaimer	03-medical-disclaimer.md	Clinical scope, human oversight, limitations
4	Acceptable Use Policy	04-acceptable-use-policy.md	Permitted and prohibited uses
5	Data Retention Policy	05-data-retention-policy.md	Retention and deletion rules
6	Data Processing Addendum	06-data-processing-addendum.md	Controller/processor terms, legal-basis and role-allocation reference (Section 8)
7	Cookie & Local Storage Policy	07-cookie-policy.md	Web cookies, local storage, tracking
8	Incident Response Plan	08-incident-response-plan.md	Security and personal-data incident workflow
9	Information Security Policy	09-information-security-policy.md	Technical and organizational measures, incl. ADHICS alignment
10	Regulatory Position & Function-Level Assessment	10-regulatory-position.md	FDA function-level assessment (Non-Device CDS / enforcement discretion / device); EU MDR/MDSW qualification; EU AI Act classification (incl. Article 6(3)); scoped to Dr. Axis functionality only
11	AI Governance & Clinical Safety Policy	11-ai-governance-clinical-safety.md	Human oversight, validation, hallucination management, EU AI Act assessment
12	U.S. Regulatory & Privacy Assessment	12-us-regulatory-assessment.md	FDA function-level assessment (Non-Device CDS / enforcement discretion / device), HIPAA, FTC, state law
13	Clinical Validation & Evidence Policy	13-clinical-validation-evidence.md	Validation methodology, KOL involvement, logged checkpoint data (Section 2.2)
14	Full Nuraxis AI MVP — Future Regulatory Track	14-full-mvp-future-track.md	Placeholder: continuous monitoring, RoboCam hardware classification, closed-loop alerting — separate workstream, not covered by this document

---

10. AI Governance & Clinical Safety

Because Dr. Axis incorporates a Q&A function alongside deterministic calculations, governance must separately address both:

Deterministic calculation component:
* formula accuracy and version control;
* correct sourcing of published formulas;
* input validation (range checks, unit consistency).

Q&A function:
* hallucination/error management;
* source traceability (clinician can see the guideline/study behind an answer);
* citation-groundedness verification — a citation being present is not sufficient; the system must be checked to confirm the cited source actually supports the generated answer (citation existence ≠ answer accuracy);
* scope limitation (explicit boundaries on what Dr. Axis will and won't answer) and defined refusal/escalation behavior for out-of-scope or unsupported questions;
* prompt/input logging policy, including retention and access controls for logged prompts;
* model-provider data-use restrictions — contractual confirmation of how any third-party model provider may or may not use submitted data;
* prohibition on using patient data to train external foundation models without an approved legal basis and contractual framework specifically covering that use — see the global default rule in Section 2.5a;
* source freshness and versioning (which guideline/protocol version was current at time of answer);
* model/version traceability and change control, including a model change impact assessment and regression testing after any model or provider update;
* red-team / adversarial testing for clinically unsafe or misleading outputs;
* a defined clinical safety event taxonomy and escalation path;
* a rollback procedure for reverting to a prior model/version if a safety issue is identified post-deployment;
* a defined fallback behavior for model/provider outage;
* performance monitoring and drift;
* bias and fairness review;
* confidence/uncertainty representation in outputs where appropriate;
* incident escalation and auditability;
* explicit clinician responsibility statements at point of use.

No AI output — calculated or generated — should be represented as infallible or as a substitute for qualified clinical judgment. This is reinforced structurally by the mandatory validate/reject and protocol-selection checkpoints for the deterministic calculation component (Section 2.2), not only by disclaimer language. As noted in Section 4.4, this structural checkpoint is confirmed for the calculation component; whether an equivalent explicit checkpoint exists for the Q&A function must be confirmed against the shipped product rather than assumed.

---

11. Clinical Validation & Evidence

Clinical claims must be supported by documented evidence, including:

* clinical validation activities and methodology;
* KOL involvement — validation activity should be traceable to signed KOL Endorsement and/or KOL Engagement Agreements, maintained in the company's controlled documentation system;
* applicable datasets and formula sources;
* model/formula versions in use at time of validation;
* validation results and limitations;
* intended clinical population and use cases;
* the logged checkpoint data described in Section 2.2 (inputs, result, validate/reject decision, protocol selection) as supplementary real-world usage evidence documenting the operation of the human-in-the-loop workflow. Such logs do not, by themselves, constitute clinical validation or evidence of clinical safety or effectiveness — they demonstrate that the workflow operates as designed, not that the underlying calculations or AI outputs are clinically accurate or safe. Clinical accuracy/safety evidence must come from the clinical validation activities and KOL involvement listed above.

---

12. Security & Data Architecture

Must be aligned with actual technical architecture, documented for each target jurisdiction:

* hosting providers, server locations, cloud regions;
* database locations, backups, encryption, key management;
* access controls, authentication, MFA, audit logging;
* vulnerability management, incident response, disaster recovery;
* data deletion procedures;
* third-party/subprocessor access;
* ADHICS V2-specific controls (capability-based, three-tier model) where deployment involves DoH-regulated entities (Phase 1, UAE), including the AI-use policy domain specifically.

Data minimization principle: Dr. Axis should process only the patient information necessary for the selected calculation, reference task, or permitted Q&A interaction (Section 4.4). Where a calculation can be performed using de-identified or non-identifying inputs, identifying information should not be requested or retained. Concretely: if a given calculator only requires inputs such as age, weight, and a lab value, the UI should not additionally request name, national ID, phone number, or address. This is a privacy-by-design control that engineering should implement at the input-field level, not only a legal/policy statement — treat it alongside the Section 2.5a default data-use rule as a design constraint checked at each new feature, since minimizing what is collected in the first place materially simplifies every downstream jurisdictional analysis in Sections 3–8.

---

13. How to Use This Document Set

1. Internal review — CEO/management, CTO, medical advisors, clinical/regulatory advisors, privacy lead, legal counsel.
2. Jurisdiction-specific review, in phase order (Section 3a):

* Phase 1: Tunisia (data protection, medical ethics, healthcare law) and UAE (PDPL, DoH, ADHICS); * Phase 2: Saudi Arabia, Qatar, Bahrain, Kuwait; * Phase 3: EU (GDPR, MDCG 2019-11 Rev.1, AI Act) and US (Non-Device CDS, HIPAA, FTC, state law).

1. Technical validation — CTO confirms published policies match actual data flows, storage locations, subprocessors, authentication, retention, deletion, logging (incl. the Section 2.2 checkpoint log), AI processing, and third-party services.
2. Localization — English (international/GCC/US), French (Tunisia/EU use), Arabic (GCC), additional languages as required.
3. Publication — via https://draxis.app/legal/{document-slug} (placeholder URL structure — confirm and replace with the actual canonical domain/path before any document is published, and ensure the pattern is applied consistently across every legal-document link rather than ad hoc per document), linked from the Dr. Axis application, website, app-store listings, hospital onboarding, B2B contracts, and physician onboarding.
4. Version control — every published version includes version number, publication date, effective date, applicable jurisdiction, document owner, approval status. Prior versions retained in the compliance archive.

---

14. Critical Regulatory Decisions — Dr. Axis (Current Scope Only)

* ⚠️ Intended purpose & claims governance — maintain a controlled intended-purpose statement, and ensure product UI, IFU-equivalent in-app text, website, app-store listing, investor materials, sales materials, and clinical claims remain consistent with it. Any material change to claims, functionality, or positioning triggers regulatory reassessment before release. This is listed first because intended purpose is the central input to both the EU MDSW analysis (Section 5.3) and the US independent-review analysis (Section 4.2, Criterion 4) — getting this governance right upstream reduces risk across every other item below.
* ⚠️ US FDA function-level status — confirm, per function (calculations, reference display, Q&A function), whether Non-Device CDS criteria are met, whether enforcement discretion applies, or whether device regulation applies (Section 4.1–4.4).
* ⚠️ EU MDSW classification (MDCG 2019-11 Rev.1) — confirm non-MDSW positioning per function, assessed primarily against intended purpose, with counsel/Notified Body input.
* ⚠️ EU AI Act Article 6(1)/6(2) threshold, then Annex III and Article 6(3) if applicable — first determine whether Article 6(1) (Annex I product/safety-component route) applies; separately determine whether any specific Dr. Axis function falls within an Annex III category under Article 6(2) — not assumed from healthcare context alone; only if Annex III applies, assess the Article 6(3) derogation (narrow procedural task, improvement of completed human activity, pattern detection with human review, or preparatory task) and the profiling carve-out. Assess against the amended timeline under Regulation (EU) 2026/1744 (Annex III obligations from Dec 2, 2027; Annex I obligations from Aug 2, 2028).
* ⚠️ GDPR role — controller/processor/joint-controller status per processing activity.
* ⚠️ GDPR Article 27 — determine whether an EU representative is required.
* ⚠️ HIPAA status — determine Business Associate status per US deployment.
* ⚠️ FTC HBNR applicability — assess for consumer-facing/non-HIPAA deployments.
* ⚠️ ADHICS V2 compliance and DoH Responsible AI requirements — confirm hosting/security posture (ADHICS V2) and separately confirm applicable DoH Responsible AI requirements (consent/opt-out, data provenance) for DoH-regulated UAE deployments (Phase 1 priority) — these are two distinct tracks, not one (Section 7).
* ⚠️ UAE data localization legal basis — confirm the specific statutory/regulatory basis for health-data localization/cross-border restrictions applicable to Dr. Axis, as distinct from ADHICS's cybersecurity controls (Section 7).
* ⚠️ Tunisia INPDP requirements — confirm applicable declarations/authorizations.
* ⚠️ Saudi cross-border transfers — confirm mechanism and safeguards (Phase 2).
* ⚠️ GCC data residency — assess per country as each becomes active (Phase 2).
* ⚠️ Consent-chain confirmation — validate the Section 8 model with counsel per Phase 1 jurisdiction.
* ⚠️ Clinical claims — ensure marketing/product claims stay consistent with the Section 2.2 flow and available evidence at all times.

Note: Full Nuraxis AI MVP items (continuous monitoring, RoboCam hardware classification, closed-loop alerting) are intentionally excluded from this list — see Document 14 (placeholder) for that separate future workstream.

---

15. Open Compliance Actions

Owner and target-date columns should be completed by the Legal/Operations lead before this document is treated as actionable rather than reference material.

Status values: Not started / In progress / Pending counsel / Completed / Approved. Use these five terms consistently rather than free text, so the register can be scanned or filtered reliably.

#	Action	Owner	Target Date	Status
1	Confirm Dr. Axis / Hajti Group legal entity name, registration number, registered address	TBD	TBD	Not started
2	Confirm Hajti Group's controller/processor role by processing activity (Section 8)	TBD	TBD	Not started
3	Map the complete Dr. Axis data flow (Section 2.2 checkpoints included)	TBD	TBD	Not started
4	Document all subprocessors and third-party services, incl. AI model providers	TBD	TBD	Not started
5	Confirm hosting/cloud regions (incl. any OVH/Firebase/GCP locations)	TBD	TBD	Not started
6	Define jurisdiction-specific data residency requirements (Phase 1 first)	TBD	TBD	Not started
7	Obtain FDA function-level assessment for deterministic calculation functions (Section 4.3)	TBD	TBD	Not started
8	Obtain FDA function-level assessment for clinical reference/protocol-display functions	TBD	TBD	Not started
9	Obtain FDA function-level assessment for the Q&A function (Section 4.4)	TBD	TBD	Not started
10	Document applicable pathway per function: Non-Device CDS / enforcement discretion / regulated device	TBD	TBD	Not started
11	Obtain EU MDSW classification opinion, per function, against intended purpose (MDCG 2019-11 Rev.1)	TBD	TBD	Not started
12	Obtain EU AI Act assessment: Article 6(1) threshold, Article 6(2)/Annex III applicability (not assumed from healthcare context), Article 6(3) derogation and profiling carve-out if applicable, against the amended Regulation (EU) 2026/1744 timeline	TBD	TBD	Not started
13	Assess HIPAA Business Associate status for any US hospital deployment	TBD	TBD	Not started
14	Assess FTC Health Breach Notification Rule applicability	TBD	TBD	Not started
15	Confirm GDPR Article 27 representative requirement	TBD	TBD	Not started
16	Confirm ADHICS V2 requirements for UAE/DoH deployment, including the AI-use policy domain	TBD	TBD	Not started
17	Confirm applicable DoH Responsible AI requirements (patient consent/opt-out, data provenance, third-party data-sourcing due diligence) as a track separate from ADHICS V2 cybersecurity controls	TBD	TBD	Not started
18	Confirm the specific legal basis for UAE health-data localization/cross-border restrictions (federal PDPL, ADHICS V2, sector-specific health-data law, or combination) rather than relying on an unverified specific citation	TBD	TBD	Not started
19	Confirm whether UAE PDPL applies to Dr. Axis's health data or whether a separate sector-specific UAE health-data framework governs instead	TBD	TBD	Not started
20	Determine Tunisian INPDP requirements	TBD	TBD	Not started
21	Obtain Saudi PDPL transfer assessment (Phase 2)	TBD	TBD	Not started
22	Assess Qatar, Bahrain, Kuwait requirements (Phase 2)	TBD	TBD	Not started
23	Appoint privacy/DPO function where legally required	TBD	TBD	Not started
24	Finalize AI Governance & Clinical Safety Policy (Document 11), incl. citation-groundedness, model-provider data-use restrictions, regression testing, and rollback procedure (Section 10)	TBD	TBD	Not started
25	Finalize Clinical Validation & Evidence Policy (Document 13), link to KOL agreements	TBD	TBD	Not started
26	Define data retention/deletion schedules and implement backend auto-purge	TBD	TBD	Not started
27	Establish security incident response procedure	TBD	TBD	Not started
28	Establish formula/protocol-source version-control procedure	TBD	TBD	Not started
29	Establish clinical incident escalation procedure and clinical safety event taxonomy	TBD	TBD	Not started
30	Confirm patient-data legal-basis and controller/processor model (Section 8) with counsel, Phase 1 jurisdictions, per processing activity	TBD	TBD	Not started
31	Establish and maintain a controlled intended-purpose statement, reviewed against all product/marketing/investor materials (Section 14)	TBD	TBD	Not started
32	Set up legal@draxis.app, privacy@draxis.app, dpo@draxis.app (if required)	TBD	TBD	Not started
33	Translate/localize approved documents (EN/FR/AR)	TBD	TBD	Not started
34	Obtain final legal approval before publication	TBD	TBD	Not started
35	Archive approved and superseded versions	TBD	TBD	Not started
36	Open Document 14 (Full Nuraxis AI MVP future track) as a separate workstream when continuous-monitoring development begins	TBD	TBD	Not started

---

16. Regulatory Source Register

This register exists so counsel (and future team members) can verify each significant legal proposition in this document against its actual source, rather than re-deriving where a claim came from by re-reading the full document. Every ID referenced elsewhere in this document (e.g., "see US-02") points back to this table. Status values: Primary verified (checked directly against the primary source text by this team), Secondary only (based on legal commentary/analysis, not yet checked against primary text), Counsel review (requires formal legal assessment beyond source-checking, e.g., an application question rather than a text question).

ID	Jurisdiction	Source	Provision / Reference	Topic	Status
US-01	US	FDA Clinical Decision Support Software Final Guidance (fda.gov guidance page; final, January 2026)	Non-Device CDS four criteria, verbatim	Section 4.2	Primary verified — exact statutory criteria text confirmed against fda.gov guidance-document listing and cross-confirmed by multiple independent law-firm summaries quoting identical language
US-02	US	FDA Clinical Decision Support Software FAQ (fda.gov)	"Simple medical calculations" example list	Section 4.3	Primary verified — checked directly against FDA's published FAQ page
US-03	US	FDA Clinical Decision Support Software FAQ (fda.gov)	Time-critical decision-making statement	Section 4.4	Primary verified — direct quote confirmed against FDA's FAQ
US-04	US	21st Century Cures Act, Section 3060(a)	FD&C Act §520(o)(1)(E), all four criteria verbatim	Statutory basis for Non-Device CDS exclusion	Primary verified — exact criteria wording confirmed via fda.gov and cross-confirmed by AHA, NAMSA, Executives for Health Innovation, Crowell & Moring, and Frier Levitt, all quoting identical statutory language
US-05	US	HIPAA / HITECH	Business Associate definition	Section 4.6	Counsel review — deployment-specific application
US-06	US	FTC Act / Health Breach Notification Rule	Applicability to non-HIPAA health apps	Section 4.7	Counsel review
EU-01	EU	Regulation (EU) 2024/1689	Article 6(1)/(2)/(3); Annex III point 5(a)–(d) verbatim (public-benefit eligibility, creditworthiness, insurance risk/pricing, emergency-call/triage)	High-risk AI classification	Primary verified — Annex III text confirmed directly against the European Commission's own AI Act Service Desk (ai-act-service-desk.ec.europa.eu) and independently against artificialintelligenceact.eu
EU-02	EU	Regulation (EU) 2026/1744	Amending provisions, application-date changes	AI Act timeline (Dec 2027 / Aug 2028)	Primary verified — confirmed via EUR-Lex listing and multiple independent legal-industry summaries
EU-03	EU	MDCG 2019-11 Rev.1 (June 2025)	Qualification/classification guidance, non-binding status	Section 5.3	Secondary only — non-binding status and June 2025 date confirmed via commentary; full text not read primary-to-primary
EU-04	EU	GDPR (Regulation (EU) 2016/679)	Articles 3, 6, 9, 27	Legal basis, special-category data, EU representative	Counsel review
EU-05	EU	European Commission draft Article 6(5) guidelines (consultation closed July 23, 2026)	Interpretive examples incl. AI assisting diagnostic/treatment decisions, ER triage prioritization	Relevant if Q&A function scope ever expands (Section 4.4 boundary table)	🔺 Partially conflicting sources — one source (Osborne Clarke, citing the Commission's draft guidelines directly) cites ER-triage prioritization as a confirmed example; a second source describes "AI assisting diagnostic/treatment decisions" as high-risk more broadly, but this may conflate the Article 6(2)/Annex III route with the separate Article 6(1)/Annex I (MDR safety-component) route. Counsel must resolve which route(s) apply before this is relied upon — see Section 5.4.
UAE-01	UAE	Federal Decree-Law No. 45 of 2021	Personal data protection, general scope	Section 3, Section 7	Secondary only — enactment year confirmed; health-data scope exclusion flagged as needing confirmation
UAE-02	UAE (Abu Dhabi)	ADHICS V2 (DoH)	Capability-based, three-tier control model; AI-use policy domain; Communications Policy cross-border restriction	Section 7, Section 12	Secondary only — structure and AI-use domain confirmed via multiple independent compliance-vendor sources describing the same eleven control domains; the Communications Policy cross-border provision confirmed via a third, independent source (trade.gov); primary ADHICS V2 document itself not read in full by this team
UAE-03	UAE (Abu Dhabi)	DoH Responsible AI guidance (doh.gov.ae)	Consent/opt-out, data provenance, third-party data-sourcing	Section 7	Primary verified (partial) — confirmed by directly retrieving content from a doh.gov.ae-hosted document; full document not read in its entirety by this team
UAE-04	UAE (federal)	Federal Law No. 2 of 2019 ("Health Data Law" / "ICT Health Law")	UAE-wide (not Abu Dhabi-specific) data localization requirement; general prohibition on storing/transferring/processing UAE health data outside the UAE, subject to exemptions under Ministerial Resolution 51 of 2021 and Cabinet Decision No. 32 of 2020	Section 7	Primary verified — confirmed directly against the UAE's official legislation portal (uaelegislation.gov.ae) and cross-confirmed by six independent law-firm sources. Correction from an earlier draft of this document: this is a UAE federal law, not an Abu-Dhabi-specific law as previously (incorrectly) flagged as a possibility.
TN-01	Tunisia	Organic Law No. 2004-63	Personal data protection	Section 6	Counsel review

Maintenance note: this register should be updated every time a new statutory or regulatory claim is added to the document, and every time a "Secondary only" item is upgraded to "Primary verified" or resolved via "Counsel review." An entry should never be deleted, even if superseded — mark it superseded and add the replacement as a new row, so the document retains a record of what changed and why.

---

17. Deployment-Readiness Tiering

This document set is deliberately broad — covering current and future markets — but not everything needs to be finished before any deployment happens. "First physician test deployment" is not one event; it can mean several materially different things with very different risk and documentation profiles, so this section uses four explicit tiers instead of a single undifferentiated "must-have" bucket.

17.0 Deployment Tiers

* Tier 0 — Internal development / non-clinical testing. No real patient data. No clinical reliance. Internal team members only, testing functionality rather than relying on outputs for any clinical purpose.
* Tier 1 — Controlled physician evaluation. Named physicians, controlled access, restricted scope, no emergency use, preferably no identifiable patient data unless the relevant legal basis, DPA, and security controls are already established for that specific evaluation.
* Tier 2 — Public beta / App Store distribution. Real external users, potentially uncontrolled usage. Materially higher privacy, contractual, marketplace, and regulatory exposure than Tier 1 — the tiers below should not be read as authorizing this stage without a separate, later review.
* Tier 3 — Hospital / B2B clinical deployment. Patient data at institutional scale, institutional contracts, DPA, security assessment, clinical validation, and jurisdiction-specific requirements.

The remainder of this section addresses Tier 1 (controlled physician evaluation) specifically, since that is Hajti Group's current near-term objective. Reaching Tier 2 or Tier 3 requires a fresh review against that tier's own requirements — the Tier 1 list below is not a subset checklist toward Tier 2/3, and should not be treated as "mostly done, just add more."

17.1 Item Classification (Tier 1)

Within Tier 1, items are further split into three types, and — critically — only counsel-confirmed items are labeled as legally mandatory. This document is not legal advice and does not itself establish legal requirements; where a label below says "required," it reflects this document's working risk-management judgment, not a legal conclusion, unless explicitly marked as counsel-confirmed.

* [INTERNAL RELEASE GATE — COMPANY REQUIREMENT] — an internal deployment gate adopted by Hajti Group: Tier 1 evaluation should not begin, as a matter of internal policy, without this in place (e.g., a Terms of Service, a Medical Disclaimer). This label does not represent a statement that the listed document is legally mandatory in every jurisdiction or deployment model. Whether any specific item is a strict legal precondition depends on the actual deployment model, jurisdiction, contractual relationship with the physicians involved (employee/advisor/evaluator/customer), whether patient data is processed, and applicable professional rules — that determination has not been made by counsel, and this label should not be copied into other documents as if it were one.
[RISK CONTROL] — a product/engineering safeguard that should be operating in the product* before real clinicians touch it, but is a design/engineering deliverable rather than a legal document per se (e.g., the Q&A function refusal behavior specified in Section 4.4).
[CAN FOLLOW LIMITED TESTING] — genuinely useful and should be completed promptly, but does not need to exist before a small, controlled Tier 1 evaluation begins, provided the test population and scope stay narrow (e.g., a fully finalized Regulatory Position Statement — the working hypotheses in Section 4 are sufficient to begin* a controlled evaluation responsibly, but should mature into a finalized position before Tier 2/3).

Tier 1 — Controlled Physician Evaluation:
* [INTERNAL RELEASE GATE — COMPANY REQUIREMENT] Privacy Policy (Document 1)
* [INTERNAL RELEASE GATE — COMPANY REQUIREMENT] Terms of Service (Document 2)
* [INTERNAL RELEASE GATE — COMPANY REQUIREMENT] Medical Disclaimer (Document 3)
* [INTERNAL RELEASE GATE — COMPANY REQUIREMENT] Acceptable Use Policy (Document 4)
* [CAN FOLLOW LIMITED TESTING, complete promptly] Data Retention Policy (Document 5)
* [RISK CONTROL] Security baseline (Document 9)
* [RISK CONTROL] Incident Response Plan (Document 8) — plan must exist; full tooling can mature alongside limited testing
* [RISK CONTROL] AI Governance / Clinical Safety Policy (Document 11), including the Q&A function operational boundary and refusal/escalation behavior (Section 4.4) — this is a product behavior requirement, not just a paper policy, and should be verified in the shipped product before real clinicians use it
* [CAN FOLLOW LIMITED TESTING, working hypotheses sufficient to begin] Regulatory Position Statement (Document 10) — the working function-level positions in Section 4 are sufficient to begin a small, controlled evaluation responsibly; full counsel sign-off should follow promptly and precede Tier 2/3
* [INTERNAL RELEASE GATE — COMPANY REQUIREMENT] An actual, verified data-flow map (Open Action 3) — needed to know what the Privacy Policy and Medical Disclaimer must actually say
* [RISK CONTROL] An actual, verified subprocessor / AI model-provider inventory (Open Action 4)

Tier 3 — Hospital / B2B Clinical Deployment (for later reference; not a Tier 1 requirement):
* Data Processing Addendum (Document 6)
* Controller/processor assessment per processing activity (Section 8, Open Action 2 and 30)
* Jurisdiction-specific data-processing analysis for the relevant Phase 1 market
* ADHICS / DoH assessment, where the deployment is UAE-based
* Clinical validation package (Document 13, Section 11)
* Contractual liability / indemnification framework (not yet covered elsewhere in this document set — to be developed with counsel alongside the DPA)

Can wait until the corresponding market becomes real (per the Phase sequencing in Section 3a):
* Full EU assessment (GDPR, MDCG 2019-11 Rev.1, AI Act) — Phase 3
* Full U.S. assessment (FDA, HIPAA, FTC, state law) — Phase 3
* Saudi Arabia, Qatar, Bahrain, Kuwait workstreams — Phase 2

This tiering does not remove any item from Section 15's action register — it sequences them. Items outside the Tier 1 list remain open actions but are not blockers to a Tier 1 evaluation specifically.

17.1a What We Are NOT Claiming (Tier 1 / First Physician Evaluation / App Store)

To keep claims-governance explicit and prevent scope creep in marketing, app-store, or investor language, the following must not be stated or implied about Dr. Axis at the Tier 1 stage:

* No claim of FDA clearance or approval.
* No claim of CE marking.
* No claim that Dr. Axis is universally "not a medical device" — classification is function-specific and pending per Section 4/5.
* No claim that the entire Nuraxis AI platform's regulatory status is established based on Dr. Axis's positioning.
* No emergency or time-critical clinical-use claim (Section 4.4).
* No claim of autonomous diagnosis or treatment recommendation.
* No claim of automatic protocol selection or ordering — protocol selection remains a distinct, clinician-only action (Section 2.2).
* No use of continuous-monitoring or RoboCam functionality within Dr. Axis — that functionality sits entirely within the separate Full Nuraxis AI MVP track (Section 0, Document 14).
* No claim that beta or test status itself creates a regulatory exemption — beta/test framing affects internal risk management and rollout scope, not legal classification.

Any proposed product, marketing, App Store, or investor copy should be checked against this list before publication, alongside the intended-purpose governance process in Section 14 and the claims-approval workflow in Section 17.2.

17.2 Claims Approval Workflow

No external statement concerning Dr. Axis's regulatory status, clinical performance, diagnostic/treatment capability, safety, accuracy, compliance, certification, clearance, or approval may be published without documented review by the designated regulatory/legal owner. This applies to: website copy, LinkedIn and other social posts, pitch decks, investor emails and updates, the App Store / marketplace listing, physician onboarding materials, hospital proposals, product demos, press releases, and conference materials.

Approval sequence: Product/Marketing drafts → Regulatory/Legal owner reviews against Section 17.1a and Section 14 → CEO sign-off → Publication. No step may be skipped for external-facing claims, regardless of urgency (e.g., a fundraising deadline is not a basis to bypass the Regulatory/Legal review step).

17.3 Regulatory Change-Trigger Matrix

The concept of "certain changes require re-assessment" appears throughout this document (Sections 0, 2, 4, 5, 14, 17). This table consolidates it into one reference so product and engineering can check a proposed change against it directly, rather than searching the full document each time.

Product change	Mandatory reassessment before release?
Add physiological/device data acquisition	Yes — likely fails FDA Criterion 1 / moves to Full Nuraxis AI MVP track (Section 0)
Add medical imaging analysis	Yes — likely fails FDA Criterion 1
Add continuous monitoring	Yes — moves to Full Nuraxis AI MVP track (Section 0)
Add automated alerts	Yes — automation-bias/Criterion 4 analysis (Section 4.2)
Add diagnosis output	Yes — Section 4.4 prohibited-use table
Add treatment recommendations	Yes — Section 4.4 prohibited-use table
Add medication dosing recommendations	Yes — separate FDA assessment required (Section 4.3)
Auto-select or auto-apply protocol	Yes — breaks the Section 2.2 checkpoint design
Auto-generate orders	Yes — breaks Section 2.3 intended-use principle
Remove or weaken clinician validation/rejection step	Yes — Criterion 4 / Section 2.2
Remove or weaken source traceability	Yes — Criterion 4 / Section 4.4
Add patient-facing (non-clinician) functionality	Yes — different FDA/EU analysis applies to patient-facing CDS
Enter a new jurisdiction	Yes — Section 3/3a phased rollout
Materially change the AI model or provider	Yes — safety/regression assessment (Section 10)
Change UI/marketing wording affecting intended purpose	Yes — claims review (Section 17.2)
Change hosting or data location	Yes — privacy/security assessment (Section 12)
Introduce a new secondary use of patient data (analytics, training, etc.)	Yes — Section 2.5a default data-use rule

Any change not listed here that plausibly touches the Section 4/5 regulatory analysis should be treated as requiring reassessment by default — this table is illustrative of the most likely triggers, not an exhaustive gate list.

---

18. Document Hierarchy

In the event of an inconsistency between documents or statements within this document set, the following hierarchy applies, from highest to lowest authority:

1. Applicable law, regulation, and binding regulatory requirements.
2. Executed customer/deployment agreements, where legally applicable to the specific relationship.
3. The approved Intended Purpose / Product Regulatory Specification (once formally approved — see Section 2.4 and Section 4.4's operational boundary as current working versions).
4. The approved AI Governance & Clinical Safety Policy (Document 11).
5. Approved Privacy/Security policies (Documents 1, 9).
6. This master legal, regulatory and compliance document.
7. Draft/internal working materials (including prior versions of this document, pitch decks, and informal notes).

This hierarchy exists specifically to prevent the team from treating an outdated policy, an old pitch deck, or an informal Slack decision as authoritative when it conflicts with something higher on this list.

---

19. Compliance Principle

Dr. Axis's legal and regulatory position must follow the actual product, actual data flows, actual claims, and actual deployment model — specifically, the flow described in Section 2.2. The company must not modify terminology or marketing descriptions solely to obtain a preferred regulatory classification; classification follows function, not the reverse.

Where regulatory status is uncertain, the uncertainty must be documented and resolved through qualified jurisdiction-specific legal or regulatory advice before the relevant functionality is commercially deployed or publicly promoted.

Any functional change that could affect the Section 4.2 Non-Device CDS criteria, the Section 4.3 enforcement-discretion pathway, or the Section 5.3/5.4 EU positioning — including but not limited to auto-applying protocols, acquiring device signals, or removing either clinician checkpoint in Section 2.2 — requires legal sign-off before development begins. See Section 17.3 for a consolidated table of specific change triggers.