MANSOQ implementation kit · version 2 · reviewed 2026-10-10

Start at https://mansoq.com/resources/implementation

1. Read all implementation stages, select the product and scenario guide.
2. Freeze scope, release versions, owners, data boundaries and acceptance evidence.
3. Download the matching template inside your account setup for its frozen version.
4. Upload UTF-8 CSV files, preview errors, apply valid records, then Save and continue.
5. Import foundation files before their dependent product files.
6. Complete dataset decisions for every applicable product dataset. Blank does not mean not applicable.
7. Confirm setup manually; launch imports product records atomically and verifies counts.
8. Complete product-specific approval, tests, certification, migration, training and cutover before production use.

Folders:
templates/ = headers only
examples/ = synthetic structure examples; never production approval or real patient data
data-dictionary.csv = every column, required/optional status, format, example and destination
manifest.json = materials, complete implementation stages, scenarios and product checklists
permission-catalogue.json = source-exported facility permissions and system roles

CSV: keep all headers, identifiers as text and leading zeros; true/false booleans; dates YYYY-MM-DD; times HH:MM; quote commas/newlines. At most 1 MB and 1,000 data records per file, with 16 MB combined setup; larger history requires approved batch migration; scalar steps accept one record. Formula cells are rejected.

Account setup imports: organization, facilities, departments, locations, staff, operations, integrations, domain, and the selected product datasets. The exact account template is authoritative.

Prices/SBS mappings and stock catalogues are draft pending verification; device records are inactive pending commissioning. Uploading readiness data never establishes external certification. Product settings accept only typed function settings from the supported registry, currently scheduling closures; each one is applied natively and read back, and free-form keys are refused.

Project records and migration preparation files upload into Account setup -> Implementation files & acceptance evidence and are saved as account evidence. Evidence can be updated after provisioning with a new account version; native bootstrap remains frozen. They need a release-specific field mapping and approved import adapter before a product load. They do not activate RCM rules or load clinical history. New-tenant bootstrap creates no patients.

Examples use example.invalid and EXAMPLE/TO-CONFIRM values. Replace all placeholders, confirm effective dates, authority, currency, units, licence rights and ownership. Record exceptions and fallback explicitly. Never place passwords or credentials in CSV; use secure credential-manager references. Store authorized clinical migration files only in the secure project workspace.

Regulatory references:
NPHIES https://portal.nphies.sa/ig/index.html
ZATCA https://zatca.gov.sa/en/E-Invoicing/Pages/default.aspx
SDAIA https://dgp.sdaia.gov.sa/wps/portal/pdp/home
Public documentation does not certify a production connection.

Existing-system transitions:
55 named products and legacy variants across 33 system entries, plus an assessment route for another vendor/in-house system. Official sources, release boundaries and detailed paths are in manifest.json and the online guide.
Actions: migration, integration, phased transition, consolidation, archive, carve-out, export/exit, recovery.
Integration scopes: identity/ADT, clinical read, orders/results, medications, appointments, revenue, imaging/devices, finance/inventory, SSO.
Each scope needs its own contract, ownership, field mapping, access approval, exception tests and accepted target adapter.
12 additional planning templates cover source systems, transition scope, exports/checksums, identity policy, terminology, reconciliation, interface scopes/contracts/access/mappings/tests and archive/exit. These are saved account implementation records, not a generic clinical history importer.
Follow the relevant vendor route and every applicable step, including file dependencies, reconciliation, UAT, training, final changes, cutover/rollback, hypercare and support handover. Record non-applicable or unavailable domains with an owner, reason and approved alternative.
Keep actual patient records, identity crosswalk rows, original documents, images and credentials in approved restricted workspaces. Preserve actual vendor formats (TSV, NDJSON, XML, DICOM, native media); never rename them to CSV. A clinical API export may cover only part of the agreed source inventory.
Confirm installed releases, supported operations, licensing and target-adapter acceptance before execution. A named vendor or public FHIR specification does not establish a prebuilt MANSOQ connector, write capability or production certification.
