> For the complete documentation index, see [llms.txt](https://docs.oomus.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.oomus.org/compliance/terms-of-use.md). # Terms of Use **Public Digital Health Infrastructure · African Continental Edition** > Version 1.0 · Effective date: June 1, 2026\ > Publisher: Oomus — Dakar, Senegal · \ > Applicable to all programs deployed in Africa and in low- and middle-income countries *** ## Preamble These Terms of Use (hereinafter the "Terms") govern access to and use of the platform **Oomus CampaignID**, public digital health infrastructure (DPI — Digital Public Infrastructure) designed for sovereign management of health identity, generation and distribution of digital health cards, cryptographic verification, and institutional governance of large-scale health campaigns. Oomus CampaignID is developed and operated by **Oomus**, a company incorporated under Senegalese law, with its registered office in Dakar, Senegal. By accessing the platform, creating an account, or using all or part of the services described herein, **the Client Organization** acknowledges having read, understood, and unreservedly accepted these Terms, as well as the Privacy Policy and, where applicable, the Service Level Agreement (SLA) and Data Processing Agreement (DPA) applicable to its plan. *** ## Article 1 — Definitions For the purposes of these Terms, the terms below have the following meanings: **"Platform"** means all software services, APIs, web portals, and mobile applications that make up Oomus CampaignID, accessible at `app.campaignid.oomus.io` and its subdomains. **"Client Organization"** or **"Client"** means any institutional entity — Ministry of Health, government agency, international organization, NGO, public health program, or technical partner — that has subscribed to a Platform usage plan. **"Administrator"** means the user designated by the Client Organization to manage the program account, access, configuration, and billing. **"Authorized User"** means any natural person — health worker, program manager, field operator — granted access to the Platform by the Client Organization. **"Beneficiary"** means any natural person whose health data are processed via the Platform as part of a public health campaign. **"Beneficiary Data"** means all personal data of beneficiaries processed via the Platform, including identification, health, geolocation, and contact data. **"MPI"** (Master Patient Index) means the sovereign digital health identity registry, assigning each beneficiary a unique, cross-program and persistent identifier. **"MPI Identifier"** means the unique alphanumeric identifier in the format `[COUNTRY]-[REGION]-[YEAR]-[CODE8]` assigned to each beneficiary in the MPI registry. **"Digital health card"** means the secure digital document generated by the Platform, integrating an MPI identifier, a cryptographic QR code, and the beneficiary's health attributes. **"QR Engine"** means the cryptographic module for generating and verifying QR codes, operating with HMAC-SHA256 signatures and AES-256-GCM encryption. **"Card Studio"** means the visual editor for health card templates integrated into the Platform. **"Verification portal"** means the offline web application allowing field agents to verify card authenticity without an Internet connection. **"Sovereign Wallet"** means the digital pass issuance module compatible with Google Wallet and Apple Wallet. **"Distribution services"** means the omnichannel card sending modules via WhatsApp (Meta Graph API), SMS (Orange API, Africa's Talking), and Google Wallet. **"DHIS2"** means the District Health Information Software 2, the reference system in African public health. **"Usage Data"** means the technical metadata generated by use of the Platform (access logs, performance metrics, anonymized usage statistics). **"Audit Trail"** means the immutable and cryptographically linked log of all significant actions carried out on the Platform. **"SLA"** (Service Level Agreement) means the service level agreement specifying the availability, performance, and support commitments applicable to the subscribed plan. **"Force majeure"** means any unforeseeable, irresistible, and external event making performance of contractual obligations impossible, including natural disasters, armed conflicts, national infrastructure outages, or pandemics. *** ## Article 2 — Description of services ### 2.1 Sovereign digital identity infrastructure (MPI) The Platform provides a sovereign MPI registry enabling: * Registration of each beneficiary with a unique, persistent, cross-program digital health identifier * Probabilistic identity deduplication via an algorithmic engine based on phonetic matching, attribute similarity, and weighted confidence scores * Automatic duplicate resolution with mandatory human validation before merging * HL7 FHIR R4 interoperability for data exchange with existing health information systems * Identity lifecycle management: creation, update, merge, revocation ### 2.2 Card Studio — Health card editor The Platform provides a visual editor allowing: * Creation and customization of health card templates (11 predefined templates including the Sovereign template) * Integration of institutional logos, primary colors, and visual identities of programs * Configuration of dynamic front/back fields (beneficiary attributes, health data) * Generation of high-resolution previews (300, 450, or 600 DPI) before going into production * Export of template configurations in YAML and JSON formats for versioning * Generation of opaque, non-reversible cryptographic QR codes ### 2.3 Large-scale card generation The Platform ensures asynchronous card generation via: * Parallel generation workers supporting up to 2 million cards per campaign * Real-time progress tracking via WebSocket * Generation of artifacts: individual PDF cards, authenticity registry (SHA-256), audit report * Automatic quota refund in case of generation failure * Batch management with secure ZIP download of outputs ### 2.4 DHIS2 integration The Platform offers native integration with DHIS2 Tracker including: * Bidirectional synchronization of enrollments from DHIS2 instances * Configurable mapping of DHIS2 attributes to MPI fields and card fields * Automatic card generation from synchronized enrollments * Scheduled synchronization mode (configurable intervals: 10, 15, 30, 60, or 180 minutes) * Read-only protection of DHIS2 data (no writes to the source instance) * Sensitive data protection: 7 categories of sensitive health data (HIV/AIDS, addictions, mental health, abortion, genetics, biometrics, sexual orientation) automatically detected and flagged ### 2.5 Multichannel distribution The Platform offers digital card distribution services via: **WhatsApp (Meta Graph API)** * Sending health cards by WhatsApp message with PNG image and personalized message * Individual or mass sending from the DHIS2 distribution module * Management of delivery receipts and delivery logs * Automatic fallback to SMS in case of WhatsApp failure **SMS** * Sending SMS with card download link or reference code * Integration with Orange API (West Africa) and Africa's Talking (pan-African coverage) * Multi-operator support with automatic failover **Google Wallet** * Issuance of individual and mass digital passes (up to 100 passes simultaneously) * Cryptographically signed passes synchronizable offline * Audited revocation with immutable audit trail ### 2.6 Offline verification portal The Platform generates a deployable static verification portal allowing: * Verification of card authenticity without an Internet connection * Verification by manual code entry or QR scan * Mass verification via CSV import * Use of the browsers' native WebCrypto API without software installation * Multilingual support (French, English, Wolof) * Detection of forged, revoked, or unknown cards ### 2.7 Financial simulation and provisioning The Platform offers a simulation engine allowing: * Estimation of infrastructure, communication, and governance costs before deployment * Generation of institutional pro formas in PDF and Excel formats * Configurable multi-level admin approval workflow (submission → approval → provisioning) * Automated provisioning of dedicated environments upon approval ### 2.8 Billing and financial governance The Platform ensures complete financial traceability via: * A centralized accounting ledger: each debit automatically generates a Transaction, a signed Invoice, and an immutable AuditLog * Formal invoices numbered according to the schema `INV-{TYPE}-{YYYYMM}-{6CHARS}` * Verification of invoice integrity via cryptographic signature * Management of monthly quotas with automatic calculation of overages * Financial governance dashboard with tracking by engine (Campaign Delivery / Studio Print) ### 2.9 Physical PVC cards The Platform offers a physical card production service including: * Two quality levels: Standard PVC and Industrial Offset * Real-time order tracking with status timeline (submitted → in production → shipped → delivered) * Estimated delivery date automatically calculated according to the print type * JSON status history with timestamp at each step ### 2.10 Artificial intelligence and analytics The Platform integrates artificial intelligence components for: * Detection of behavioral anomalies in access and QR scans (IsolationForest model) * Probabilistic deduplication of beneficiary identities * Forecasting quota consumption and generation * Contextual campaign management recommendations * Geospatial analyses of coverage and territorial risk ### 2.11 RBAC and institutional governance The Platform provides an institutional access control system comprising: * 10 hierarchical role levels (from `sub_account` to `super_admin_global`) * 18 configurable granular permissions per program * Multi-level approval workflows up to 10 configurable levels * An immutable audit trail of all significant actions * Strict program-level data isolation (multi-tenancy) *** ## Article 3 — Access and registration conditions ### 3.1 Eligibility Access to Oomus CampaignID is reserved for the following organizations: * Ministries of Health and government public health agencies * International organizations and UN agencies (WHO, UNICEF, UNFPA, UNDP, etc.) * Non-governmental organizations and associations operating in the health sector * Technical and financial partners of public health programs * Universities and public health research institutions * Any other entity whose activity is directly related to public health, subject to validation by Oomus Access for purely commercial, marketing, or non-public-health-related purposes is expressly excluded. ### 3.2 Account creation The Client Organization must designate a responsible Administrator who: * Provides accurate, complete, and up-to-date information during registration * Ensures that the Client Organization has the legal authorizations required to process beneficiary data * Accepts these Terms on behalf of the Client Organization * Is solely responsible for the security of access credentials Registration is subject to validation by Oomus. Oomus reserves the right to refuse or revoke any access without justification. ### 3.3 Prior compliance obligation Before processing beneficiary data via the Platform, the Client Organization undertakes to: * Have obtained informed consent from beneficiaries or have an equivalent legal basis under the applicable national regulations * Have carried out a Data Protection Impact Assessment (DPIA) if required by the applicable regulations * Have notified its national data protection authority if required * Have implemented an internal data protection policy *** ## Article 4 — Client Organization obligations ### 4.1 Compliant use The Client Organization undertakes to use the Platform exclusively within the framework of lawful public health programs and to: * Process only the data strictly necessary for the stated purposes (data minimization principle) * Inform beneficiaries about the processing of their health data * Respect beneficiaries' rights (access, rectification, deletion, objection) * Not divert beneficiary data for purposes other than those that justified its collection * Update and delete data in accordance with applicable retention policies ### 4.2 Access security The Client Organization is solely responsible for: * Securing the login credentials of all its Authorized Users * Enabling two-factor authentication (2FA TOTP) for administrator accounts and access to sensitive data * Immediate revocation of access in the event of an Authorized User's departure or suspected compromise * Not disclosing API tokens to unauthorized third parties * Managing access rights in accordance with the principle of least privilege ### 4.3 Third-party integrations The Client Organization using DHIS2, WhatsApp, SMS, or Google Wallet integrations undertakes to: * Have appropriate access rights to the integrated third-party systems * Comply with the terms of use of third-party providers (Meta/WhatsApp, Orange, Africa's Talking, Google) * Not configure integrations allowing unauthorized access to third-party data * Inform Oomus of any change to access rights to integrated systems ### 4.4 Sensitive health data Processing of data belonging to special categories (health status, genetic data, biometrics, HIV/AIDS, mental health, addictions, sexual orientation) via the Platform is subject to the following enhanced obligations: * Obtaining explicit consent from the beneficiary or a specific legal basis * Implementation of enhanced technical security measures * Maintaining a record of processing activities * Designation of a Data Protection Officer (DPO) if required by national regulations * Immediate notification to Oomus of any data breach involving these categories ### 4.5 Prohibitions The Client Organization is expressly prohibited from: * Using the Platform to monitor, track, or profile beneficiaries for purposes other than public health * Selling, assigning, renting, or sharing beneficiary data extracted from the Platform * Decompiling, disassembling, or attempting to extract the Platform's source code * Bypassing security, access control, or billing mechanisms * Using bots, scripts, or automated systems for unauthorized access to the API * Storing API keys or tokens in public code repositories * Allowing access to the Platform to entities not authorized by these Terms *** ## Article 5 — Processing of personal data ### 5.1 Shared responsibilities The processing of beneficiary data takes place within a framework of shared responsibility: **The Client Organization acts as Data Controller** — it determines the purposes and means of processing beneficiary data, maintains the direct relationship with beneficiaries, and assumes primary responsibility for compliance with the rights of data subjects. **Oomus acts as Processor** — it processes beneficiary data exclusively on behalf of the Client Organization, according to its documented instructions and within the limits defined in this article and in the Data Processing Agreement (DPA). ### 5.2 Applicable legal framework Processing of beneficiary data is subject to the following regulations, depending on the countries of operation: **African regional framework:** * African Union Convention on Cyber Security and Personal Data Protection (Malabo Convention, 2014) * ECOWAS Supplementary Act on Personal Data Protection (A/SA.1/01/10, 2010) * UEMOA directives relating to the protection of personal data **National regulations (non-exhaustive list):** * Senegal: Act No. 2008-12 on the protection of personal data — Personal Data Protection Commission (CDP) * Côte d'Ivoire: Act No. 2013-450 on the protection of personal data — ARTCI * Mali: Act No. 2013-015 on the protection of personal data — APDP * Burkina Faso: Act No. 010-2004 AN — CIL (Commission on Information Technology and Civil Liberties) * Niger: Ordinance No. 2011-22 — ANPRD * Benin: Act No. 2009-09 — AIP * Cameroon: Act No. 2010/012 on cyber security and cybercrime * Kenya: Data Protection Act, 2019 — ODPC * Ghana: Data Protection Act, 2012 (Act 843) — DPC * Nigeria: Nigeria Data Protection Regulation (NDPR) 2019 — NITDA **Applicable international regulations:** * Regulation (EU) 2016/679 (GDPR) for Client Organizations established in the European Union or processing data of European residents * WHO recommendations on health data privacy In the event of a conflict between these regulations, the law most protective of beneficiaries' rights shall prevail. ### 5.3 Data processed by Oomus Oomus processes, on behalf of the Client Organization, the following categories of data: | Category | Data | Legal basis | | -------------------- | ------------------------------------------------------ | --------------------------------------- | | Beneficiary identity | Last name, first name, date of birth, sex, nationality | Execution of the public health mission | | Contact | Phone number (for distribution), address | Consent or public health mission | | Health | Program attributes (vaccination, nutrition, etc.) | Public health mission, explicit consent | | Identification | MPI identifier, card code, NIN number (optional) | Public health mission | | Geolocation | Region, health district, organizational unit | Public health mission | | Sensitive data | HIV, mental health, addictions (if enabled) | Mandatory reinforced explicit consent | ### 5.4 Purposes of processing Beneficiary data are processed exclusively for the following purposes: 1. Issuance and management of digital health cards 2. Deduplication and resolution of MPI identities 3. Distribution of cards via channels authorized by the Client Organization 4. Verification of card authenticity by field agents 5. Synchronization with DHIS2 systems designated by the Client Organization 6. Generation of anonymized or pseudonymized campaign statistics 7. Fraud and anomaly detection for program security Any processing for purposes other than those listed above is strictly prohibited. ### 5.5 Beneficiary rights The Client Organization is responsible for the effective implementation of beneficiary rights. Oomus provides the technical tools enabling: * **Right of access** : consultation of MPI data associated with an identifier * **Right to rectification** : updating of beneficiary profile attributes * **Right to erasure** : anonymization or deletion of beneficiary data upon request by the Client Organization * **Right to data portability** : export of beneficiary data in CSV or JSON formats * **Right to object** : blocking of processing for a specific beneficiary ### 5.6 International data transfers Beneficiary data are hosted in the datacenters designated during account provisioning. For Sovereign Enterprise plans, sovereign hosting on national or regional infrastructure is available. Any transfer of data outside the Client Organization's country of operation is subject to its prior approval and to appropriate transfer mechanisms (adequacy decision, standard contractual clauses, or equivalent provisions under the applicable national regulations). ### 5.7 Retention period Beneficiary data are retained for as long as the program account is active. In the event of termination, data are retained for 90 days and then permanently deleted, except where the Client Organization requests prior export or a longer legal retention obligation applies. *** ## Article 6 — Artificial Intelligence — Ethical safeguards ### 6.1 Responsible AI principles Oomus undertakes to deploy artificial intelligence systems in accordance with the following principles: * **Non-discrimination** : deduplication algorithms are regularly audited to detect and correct bias, especially in African first and last names * **No profiling** : no beneficiary data are used to create behavioral profiles for purposes other than fraud detection in the context of the program * **Human decision** : no significant decision affecting the rights or interests of a beneficiary is made fully automatically without human oversight * **Transparency** : the Client Organization is informed of the AI components active in its program * **Sensitive data safeguard** : 7 categories of sensitive health data receive enhanced algorithmic protection ### 6.2 Anomaly detection The anomaly detection module (IsolationForest) analyzes access patterns and QR scan behaviors to detect potential fraud. Its results are for alerting purposes only and do not constitute a final decision — any suspicion of fraud requires human investigation before corrective action. ### 6.3 MPI Deduplication The probabilistic deduplication engine generates confidence scores that make it possible to match potentially duplicate identities. An identity merge may only be carried out after explicit validation by a user with the appropriate rights. *** ## Article 7 — Intellectual Property ### 7.1 Oomus Rights The Oomus CampaignID Platform, its source code, architecture, algorithms, map models, interfaces, documentation, and registered trademarks are the exclusive property of Oomus and are protected by applicable intellectual property rights, including Act No. 2008-09 on the Senegalese Intellectual Property Code and the international conventions in force. Subscription to a plan does not entail any transfer of intellectual property rights over the Platform or its components. ### 7.2 License to Use Oomus grants the client Organization a non-exclusive, non-transferable, non-sublicensable license, limited to the subscription period and to the declared operating territories only, to access and use the Platform solely for the purposes set out in these Terms of Use. ### 7.3 Beneficiary Data — Property of the Client Organization Beneficiary data collected and processed through the Platform remains the exclusive property of the client Organization. Oomus claims no rights over such data and undertakes to use it only for the purposes defined in Article 5.4. ### 7.4 Aggregated Usage Data Oomus may use aggregated and anonymized usage data (performance metrics, generation statistics, platform health indicators) for the purpose of improving the Platform, provided that no data enabling the identification of the client Organization or its beneficiaries is used. ### 7.5 Feedback and Suggestions Any suggestion, improvement, or feedback submitted by the client Organization regarding the Platform is assigned to Oomus free of charge, with no compensation or subsequent right of claim. *** ## Article 8 — Confidentiality ### 8.1 Mutual Obligations Each party undertakes to treat as strictly confidential all information of the other party designated as such or whose confidential nature results from the context, including without limitation: beneficiary data, program configurations, API keys, negotiated rates, financial information, and technical secrets. ### 8.2 Exceptions The confidentiality obligations do not apply to information: * Which is or becomes public without fault of the receiving party * Which was already known to the receiving party before disclosure * Which is developed independently without using confidential information * Whose disclosure is required by a legal or regulatory obligation, after prior notice to the other party as soon as possible ### 8.3 Term The confidentiality obligations apply for the duration of use of the Platform and for a period of **5 years** after termination of the contract. *** ## Article 9 — Security ### 9.1 Oomus Obligations Oomus undertakes to implement and maintain the following technical and organizational security measures: * AES-256-GCM encryption of data in transit and at rest for sensitive data * Two-factor authentication (TOTP 2FA) available for all accounts * Brute-force protection on all authentication endpoints * Revocation of individual and global JWT tokens (JTI blacklist) * Automatic vulnerability scanning on each deployment (SAST, dependency audit) * Detection of exposed secrets in the source code (Gitleaks) * Immutable and complete logging of all sensitive actions * Network isolation of database and cache services * TLS 1.3 on all production communications ### 9.2 Obligations of the Client Organization The client Organization undertakes to: * Enable 2FA for all administrator accounts * Use passwords that comply with the Platform's complexity policy * Do not store API tokens in unsecured locations * Report any vulnerability discovered to within 48 hours * Do not conduct penetration testing on the Platform without Oomus's prior written consent ### 9.3 Data breach notification In the event of a data breach detected by Oomus that is likely to affect the client Organization's beneficiary data, Oomus undertakes to: * Notify the client Organization within **72 hours** after becoming aware of it * Provide a description of the nature of the breach, the categories of data concerned, and the estimated number of beneficiaries affected * Communicate the measures taken or envisaged to remedy the breach The client Organization remains responsible for notifications to data protection authorities and the beneficiaries concerned, in accordance with applicable national regulations. *** ## Article 10 — Billing and Payment ### 10.1 Plans and Pricing Access to the Platform is subject to subscription to one of the available plans: * **Essential** : designed for pilot and small-scale programs * **Regional Command** : designed for multi-district regional programs * **National Infrastructure** : designed for high-volume national programs * **Sovereign Cloud** : designed for sovereign national infrastructures and multi-country deployments Prices are provided by institutional quote. Oomus reserves the right to change its prices with 60 days' notice. ### 10.2 Quotas and Overage Each plan includes monthly quotas for identities, communications, and verifications. Overage is billed at the unit rate defined in the subscribed plan. The client Organization is notified when it reaches 80% of its monthly quota. ### 10.3 Invoices Each debit automatically generates a formal invoice containing a unique number, a cryptographic signature, and an associated audit log. Invoices can be downloaded from the billing area and verified via the API. ### 10.4 Payments Payment terms, accepted currencies, and account top-up methods are defined in the commercial agreement concluded between Oomus and the client Organization. Payments are final and non-refundable except as provided in Article 2.3 (automatic refund in case of generation failure). *** ## Article 11 — Availability and Service Levels ### 11.1 Availability Commitments Availability commitments vary depending on the subscribed plan: | Plan | Target availability | Maintenance window | | ----------------------- | ------------------- | --------------------------------- | | Essential | 99,5 % | Weekly (weekend) | | Regional Command | 99,7 % | Twice monthly (weekend) | | National Infrastructure | 99,9 % | Monthly (local night) | | Sovereign Cloud | 99,99 % | Subject to contractual scheduling | ### 11.2 Exclusions Availability commitments do not cover downtime due to: * Scheduled maintenance with prior notice * Failures of third-party services (DHIS2, WhatsApp, Orange SMS, Google) * Exceptionally large DDoS attacks * Force majeure events defined in Article 1 * Non-compliant use of the Platform by the client Organization ### 11.3 Offline verification portal The offline verification portal, once deployed locally, operates in a fully autonomous manner without dependence on the availability of the central Platform. *** ## Article 12 — Liability ### 12.1 Limitation of Oomus's Liability To the extent permitted by applicable law, Oomus's total liability under these Terms of Use, مهما the cause, is limited to the amount actually paid by the client Organization during the 12 months preceding the event giving rise to the damage. Oomus cannot be held liable for indirect, consequential, special, or punitive damages, including without limitation: loss of data, loss of revenue, damage to reputation, or business interruption, even if Oomus has been informed of the possibility of such damages. ### 12.2 Exclusions from Oomus's Liability Oomus cannot be held liable for: * Acts or omissions of the client Organization or its Authorized Users * Non-compliant use of the Platform by the client Organization * Failures of integrated third-party services (DHIS2, Meta/WhatsApp, telecom operators, Google) * Data breaches resulting from compromise of the client Organization's credentials * Decisions made by the client Organization based on data or analyses provided by the Platform ### 12.3 Responsibility of the Client Organization The client Organization is solely responsible for: * The content of beneficiary data processed through the Platform * The lawfulness of data processing in light of applicable national regulations * Communications sent to beneficiaries via distribution services * Compliance of the health program with national health regulations * Consequences for beneficiaries resulting from errors in processed data *** ## Article 13 — Termination ### 13.1 Termination at the Initiative of the Client Organization The client Organization may terminate its subscription at any time by giving 30 days' written notice sent to . Amounts already paid are not refunded, except as otherwise provided in the commercial agreement. ### 13.2 Termination at the Initiative of Oomus Oomus may terminate the client Organization's access in the following cases: * Failure to comply with these Terms of Use, notably in the event of a data breach, non-compliant use, or non-payment * Use of the Platform for unlawful purposes or in a way that infringes beneficiaries' rights * Force majeure making performance of the service impossible for more than 30 days * Cessation of Oomus's business activities In the event of termination for gross misconduct, Oomus reserves the right to suspend access without notice. ### 13.3 Effects of Termination On the effective date of termination: * The client Organization immediately stops using the Platform * Oomus retains beneficiary data for 90 days to allow export * At the end of this period, the data is permanently deleted * The immutable audit trail is retained in accordance with applicable legal obligations * The confidentiality obligations and Articles 5, 7, and 8 remain in force *** ## Article 14 — Changes to the Terms of Use Oomus reserves the right to amend these Terms of Use at any time. Changes are notified to the client Organization by email with a notice period of **30 days** before they take effect. If the changes are rejected, the client Organization may terminate its subscription without penalty within 30 days of notification, with a pro rata refund of prepaid amounts corresponding to the unused period. Continued use of the Platform after the changes take effect constitutes acceptance of them. *** ## Article 15 — Governing Law and Dispute Resolution ### 15.1 Governing Law These Terms of Use are governed by **Senegalese law**, without prejudice to the mandatory protective provisions applicable in the country where the client Organization is established. For client Organizations established in countries that are members of WAEMU, WAEMU supplementary acts on personal data and cybersecurity apply in addition. ### 15.2 Amicable Settlement In the event of a dispute relating to the interpretation, performance, or termination of these Terms of Use, the parties undertake to seek an amicable solution within **60 days** from notification of the dispute by the aggrieved party. ### 15.3 Mediation Failing amicable settlement within the prescribed period, the parties may submit the dispute to mediation by the **Dakar Arbitration Chamber** or any other approved mediation body accepted by both parties. ### 15.4 Competent Jurisdiction Failing amicable settlement or successful mediation, any dispute shall be subject to the exclusive jurisdiction of the courts of **High Court of Dakar**, Republic of Senegal. For client Organizations subject to diplomatic status or jurisdictional immunity, specific dispute resolution procedures are defined in the bilateral agreement concluded with Oomus. *** ## Article 16 — General Provisions ### 16.1 Entire Agreement These Terms of Use, supplemented where applicable by the commercial agreement, the SLA, and the DPA, constitute the entire agreement between the parties regarding the use of the Platform and supersede any prior oral or written agreement. ### 16.2 Severability If any provision of these Terms of Use is declared null or unenforceable, it shall be deemed unwritten without affecting the validity of the other provisions. ### 16.3 No Waiver Oomus's failure to rely on a breach by the client Organization does not constitute a waiver of the right to rely on subsequent breaches. ### 16.4 Assignment The client Organization may not assign all or part of its rights and obligations under these Terms of Use without Oomus's prior written consent. Oomus may assign these Terms of Use in connection with a merger, acquisition, or transfer of all or a substantial part of its assets, provided that the client Organization is informed. ### 16.5 Force Majeure Neither party shall be liable for failures to perform its contractual obligations resulting from a force majeure event. The prevented party shall notify the other within 48 hours and shall use all reasonable efforts to limit the effects and resume performance as soon as possible. *** ## Article 17 — Contact and Reporting | Subject | Contact | | ------------------------- | ------------------------------------------------ | | General questions | | | Technical support | Via the Platform's customer area | | Data protection | — subject: "DPO — \[topic]" | | Vulnerability reporting | — subject: "Security Disclosure" | | Abuse / non-compliant use | — subject: "Report Abuse" | | Legal / judicial requests | — subject: "Legal Request" | **Oomus**\ Dakar, Senegal\ +221 77 803 91 91\ *** *Last updated: June 1, 2026 — Version 1.0*\ \&#xNAN;*These Terms of Use replace all previous versions.* > **Oomus CampaignID** — *One identity. One citizen. One sovereign health system.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.oomus.org/compliance/terms-of-use.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.