Frequently asked questions

MANSOQ brings healthcare software, connected clinical and operational workflows, and agreed revenue services into one product ecosystem. Start with the shared Core, select the care setting and departments you need, then confirm the available release, integrations and implementation scope with the team.

The website describes clinics, polyclinics, hospitals, medical groups, TeleICU and home or palliative care settings. Each setting needs its own workflow, capacity, clinical dependencies and delivery review; a public product page does not by itself establish that every capability is ready for your facility.

No. You can plan replacement, a defined integration, a phased transition or a retained archive. Decide which system owns each record, how updates cross the boundary and how staff handle exceptions. Confirm source-vendor access and acceptance before committing to the transition.

Software enables the selected workflows. Managed operations covers the agreed non-clinical work within the package allowance. RCM RaaS is an additional, accepted revenue service with its own worklists, authority and collection-fee basis. Neither service automatically supplies clinical staffing or transfers medical accountability.

Use the contact or demonstration request and describe your care setting, locations, users, current systems and the workflow you want to see. The team can review a relevant scenario, clarify dependencies and prepare an agreed scope. Use synthetic examples rather than sending patient records through a public enquiry.

Yes. The public product, FAQ and implementation guidance is available in Arabic and English, with language-specific links. During implementation, confirm the exact application language, translated terminology, right-to-left layouts, document templates and user training required for your selected release.

Start with the people doing the work: registration, clinicians, nurses, departmental teams, pharmacy, revenue, finance, IT, managers and authorized support users. Map each role to its facilities, tasks and approval responsibilities. Product and release acceptance determine the exact permissions available.

Plan the legal-entity and facility hierarchy, local operating owners, cross-site access and consolidated reporting together. A group view must respect the accepted sharing boundary and financial ownership. Confirm the selected package, capacity and actual multi-entity capabilities before activation.

Your authorized clinical team remains responsible for patient care, record accuracy, orders and professional decisions. Define who drafts, reviews, signs and corrects records in the accepted workflow. Software assistance and operational support do not replace professional review or local clinical governance.

A website account and a deployed clinical workspace serve different purposes. Commercial account access does not establish authorization to a patient record or prove that a clinical deployment is active. Your organization must complete its approved identity, role assignment, environment and activation process.

Review the relevant product handbook and demonstrate your real sequence of work using synthetic cases. Include normal care, handovers, corrections, escalation and downtime. Accept the supported release and configuration with clinical owners before using it in patient care.

No. Results access, external-system integration and full departmental operation are distinct scopes. For laboratory or imaging operations, agree the required ordering, specimen or study handling, verification, reporting and exception workflows. Confirm analyzer, imaging, PACS and other interfaces separately.

Validate the selected prescribing, dispensing, administration and inventory handovers against your policies. Confirm the accepted formulary, units, permissions, review steps and correction process, including any external pharmacy connection. Do not assume that every clinical alert or medication safety function is available without release-specific validation.

Assistive AI must remain within the accepted intended use and human approval process. An authorized clinician reviews and corrects any generated draft before accepting it. Agree consent, data handling, supplier involvement and validation; generated content can be incomplete or incorrect and does not replace clinical judgement.

The software scope and clinical service arrangement must be agreed separately. Confirm the bedside team, remote clinical coverage, licensing, escalation route, equipment and connectivity. A TeleICU package does not by itself provide clinical staffing, emergency response or transfer responsibility for patient care.

Approve a local downtime process covering patient identification, urgent communication, medications, orders and documentation. Rehearse who declares downtime, how work continues and how records are reconciled after recovery. Agree technical recovery arrangements and clinical acceptance before go-live.

Use the source-system migration reference to plan the route for your installed product and version. Access rights, extraction formats, vendor contracts, mapping and data quality determine the actual scope. A listed vendor is a planning reference, not a promise of a ready connector, partnership or guaranteed migration.

Inventory patient identifiers, demographics, active encounters, clinical records, attachments, appointments, financial balances and reference catalogues as applicable. For each domain, agree whether to import, integrate, archive or exclude it, together with the owner, retention needs and acceptance checks. Historical data is not automatically included in a setup allowance.

Preserve source identifiers and define matching rules before import. Profile duplicates, missing identifiers and conflicting demographics, then route uncertain matches to an authorized reviewer. Reconcile accepted records and record any correction; do not silently merge ambiguous patients.

Run an agreed rehearsal with representative data, mapping checks and clinical and financial reconciliation. Record rejected rows, counts, attachments, ownership and sign-off. Agree the extraction freeze, final changes, cutover window, rollback criteria and retained-system access before the final transfer.

Timing depends on source access, data quality, external vendors, testing, training and acceptance. Define a delivery plan with dependencies and a cutover rehearsal rather than assuming zero downtime. The accepted statement of work determines milestones, responsibilities and any agreed service commitments.

A retained archive can be part of an agreed transition. Confirm licensing, retention, access, patient matching, audit and the process for retrieving older records. Define which system owns new transactions and ensure staff know when to consult the archive.

No. A standard is only part of an integration. Agree the installed versions, supported resources or messages, identifiers, authentication, mapping, error handling and acceptance tests. Confirm the actual adapter, source-vendor rights and commissioning scope before relying on live exchange.

Provide the sending and receiving systems, versions, owner, use case, fields, message frequency, environment and security requirements. Include sample synthetic payloads, test credentials through an approved channel and vendor dependencies. Agree monitoring, reconciliation, retries and who owns failed transactions.

Required NPHIES and ZATCA workflows are included in every plan, but live transmission needs your organization’s credentials and external acceptance. Agree enrolment, supported transactions, test evidence, reconciliation and incident ownership. A subscription alone does not grant national-platform approval.

Discuss company sign-in with the MANSOQ team during technical discovery. Availability depends on the selected product, identity provider and accepted deployment scope. Configuration and account administration are handled within your authorized account experience.

Build a readiness list for your accepted workflows, including workstations, mobile use, printers, scanners, medical devices and telepresence where needed. Confirm supported browsers, versions, connectivity, bandwidth and fallback arrangements with implementation owners. Hardware supply and device interfaces require explicit scope.

Discuss architecture, data location, isolation, operations and recovery needs in an Enterprise proposal. A customer-owned database or a storage choice does not establish dedicated deployment of every application component. Confirm the complete infrastructure and responsibility boundary in the accepted design.

Agree the maintained version, monitoring owner, support boundary and change process when commissioning the connection. A vendor upgrade may need mapping changes, retesting or a separate build. Record release notices and avoid upgrading a dependent system before impact review and acceptance.

Request the controls and evidence relevant to your selected service, deployment and data flows. Review access, audit, encryption, incident handling, suppliers, retention and recovery together with your security and legal teams. Confirm the scope and validity of any evidence; a website description does not establish a certification or legal conclusion.

Your agreement must define the organization’s authority over its records and the permitted processing roles. Assign access only to authorized people and approved service activities, with the accepted audit and support process. A storage choice alone does not define all access, data flows or legal responsibilities.

Review the complete data-flow map for the accepted environment, including application databases, files, logs, backups, support systems and external AI or communication providers. Agree locations, subprocessors, transfer controls and permitted use in the relevant documents before activation.

Recovery arrangements depend on the accepted deployment and service scope. Confirm backup ownership, frequency, retention, encryption, restore tests and any agreed recovery time or recovery point objectives. A database option or product description alone is not evidence of a tested recovery commitment.

Patients should contact the healthcare provider responsible for their record through its approved privacy or records channel. The provider verifies identity, reviews the request and applies its obligations and clinical correction policy. Do not submit medical records, identity documents or sensitive details through the public marketing enquiry.

For a public enquiry, describe the workflow, organization and issue without patient-identifiable details, passwords, API keys or production files. Use synthetic examples where possible. Your support owner should provide the approved secure channel and authorization when sensitive evidence is necessary.

Name an executive sponsor, delivery owner, clinical and financial approvers, IT contacts and data owners. Prepare the facility structure, role matrix, product scope, source-system inventory and required integrations. Agree the statement of work, dependencies, acceptance evidence and planned operating model before scheduling activation.

There is no universal timeline. The schedule follows the accepted scope, source-data readiness, interface access, configuration, training and external approvals. Use milestones with named owners and readiness gates; confirm dates after discovery rather than treating a package purchase as a go-live commitment.

Train each team on its accepted tasks, permissions, handovers and exceptions using synthetic scenarios. Include registration, clinical, departmental, financial and administrative owners as relevant, and record attendance and competency checks. Agree delivery format, materials, train-the-trainer support and any onsite training separately.

Your designated business, clinical, financial and technical owners should accept the areas they control. Review configuration, role tests, migration reconciliation, interfaces, training, downtime and support readiness. Document open issues, their impact and the authorized go/no-go decision before activating live workflows.

Support coverage, severity definitions, response targets, channels and escalation follow the accepted service agreement. Confirm the named contacts and incident ownership for software, hosting, devices, vendors and clinical operations. A public FAQ does not create an unagreed 24/7 coverage or resolution guarantee.

Use the support route agreed with your organization and include the environment, time, affected workflow, impact and safe reproduction steps. Separate urgent clinical escalation from the software ticket according to your local policy. Send sensitive evidence only through the approved secure channel and keep the incident owner informed.

Review capacity, licensing, workflow dependencies, permissions, data sharing, interfaces and support impact before activation. Update the accepted configuration and commercial scope, then test and train the affected roles. More care capacity does not automatically increase managed hours or interface allowances.

State your care settings, sites, capacity, roles, required workflows, current systems, data volumes and integration needs. Add security evidence, hosting, recovery, support, training and acceptance requirements. Separate mandatory requirements from optional requests so the proposal can show gaps, dependencies and costs clearly.

Compare the accepted recurring software and managed-service charges, setup and migration, additional capacity, RCM RaaS where selected, tax and third-party costs. Include hardware, messaging, bespoke interfaces, dedicated infrastructure and optional services when needed. Use the accepted quotation rather than adding assumptions to a published package price.

Agree the product and service scope, quotation, statement of work, responsibilities, data-processing terms and acceptance criteria relevant to your deployment. Confirm support, billing, renewals, changes, termination and data-exit arrangements in the applicable contract. Website guidance helps evaluation but does not replace accepted agreements.

Expected benefits depend on the starting process, selected scope, data quality, adoption and operating responsibilities. Agree baseline measures and review actual results with your team. Illustrative scenarios and workflow examples are not audited customer outcomes or a guarantee of revenue, savings or clinical results.

Discuss the proposed partner role and agree the delivery boundary, technical access, training, change ownership and acceptance responsibilities. A partner must work within the approved security and data-processing arrangements. Being named in a migration reference does not establish a commercial partnership.

Agree export formats, included records and attachments, authorized recipients, timing, costs, retention and deletion before signing. Confirm how the destination will interpret the data and how remaining legal or clinical record obligations are handled. A storage connection alone does not guarantee complete application portability.

The public MANSOQ website provides product and service information. Contact your healthcare provider for medical advice, appointments and care-related questions. For an emergency, use your local emergency service or your provider’s urgent-care route; a marketing enquiry is not monitored as a clinical emergency channel.

Your healthcare provider confirms whether a patient-facing workflow is active and supplies the correct access route. Verify the provider’s identity and contact its registration or support team for account recovery. The public MANSOQ website does not provide a universal portal for every healthcare organization.

Family or representative access must follow the healthcare provider’s identity, consent, guardianship and authorization policy. Confirm the supported proxy workflow and its limits with the provider. A family relationship alone does not establish permission to view a record or receive clinical updates.

Contact the healthcare provider’s billing or insurance team using the details on your bill or care documents. They can verify your identity and review the relevant account. MANSOQ’s public product team cannot determine an individual claim decision or disclose patient-account details through a sales enquiry.

Shared patient identity and record, administrative and clinical context, access, audit and common configuration within an agreed data boundary.

1. Identify: Register the person with the identifiers your organization uses. Review a possible duplicate before creating another patient; preserve the original identifiers when a source system is retained.

2. Organize: Define legal organizations, facilities, departments and locations. Assign each operational record to its facility and keep cross-site sharing within the approved boundary.

3. Authorize: Assign named users to roles and facilities, then verify their read, create and update permissions. Test a restricted user as well as an administrator before accepting the setup.

4. Connect context: Link encounters, notes, observations, requests and attachments to the correct person. Departmental and revenue modules use this context through their selected capabilities and permissions.

5. Review & maintain: Review record changes and responsible users, maintain shared configuration and confirm release-specific retention, backup and support arrangements. Re-test affected permissions when adding a site or module.

Core supplies shared identity and context. Cross-tenant data exchange, external patient matching and enterprise sharing require a separately accepted interface and governance scope.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Registration, appointments, encounter queues, consultations and follow-up with required clinical and billing scope.

1. Book & arrive: Configure clinic services, practitioner resources, sessions and visit types. Book into the intended slot, record arrival and route the visit to the appropriate clinical team.

2. Consult: Open the encounter, review relevant history and allergies, capture observations and document the assessment. Use approved forms and keep the author and encounter attached to the record.

3. Order & act: Create service and medication requests with their clinical context. Route them to the selected laboratory, radiology or pharmacy workflow; review completed results before determining the next action.

4. Close & follow up: Document the care plan and follow-up responsibility, complete the encounter and link performed services to billing. Insurance verification, claims and electronic invoices depend on the selected revenue extensions.

Scheduling and encounters form the visit pathway. Department operation, results exchange, medication and insurance processing are configured through their own modules.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Admission, transfer and discharge, wards, beds, nursing, orders and medication in a complete admitted-care workflow.

1. Admit & locate: Create the admission encounter and assign the patient to an appropriate ward and bed location. Confirm the responsible team and retain the referral or emergency context.

2. Coordinate care: Record assessments and observations, maintain the care plan and track service requests. Keep clinical notes, results and outstanding actions available to authorized ward staff.

3. Medication & transfers: Connect medication requests, administration records and pharmacy dispensing. On a ward or team transfer, review the current plan, location and unresolved tasks with the receiving team.

4. Discharge & reconcile: Complete the discharge record, medication instructions and follow-up responsibility. Review documented service activity and open financial items through billing and the selected revenue-cycle workflow.

An inpatient encounter brings the stay together. ICU, surgery, pharmacy and departmental interfaces retain their own configuration, access and acceptance requirements.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Emergency encounter context, observations and accountable care handovers according to verified operational scope.

1. Receive: Record the arrival and establish identity using the locally approved process, including the temporary-identity route where required. Open the emergency encounter and assign the location and team.

2. Assess & prioritize: Capture the presenting concern and observations. Configure your approved triage categories and escalation responsibilities; clinical priority remains the care team’s decision.

3. Treat & observe: Document care, medication and urgent requests. Keep results and repeat observations attached to the encounter and identify who owns each outstanding action during observation.

4. Determine destination: Document discharge, admission or transfer with the receiving team, current treatment and pending requests. Billing and insurance tasks follow their authorized workflow without replacing clinical disposition.

Emergency documentation connects to selected diagnostic, inpatient and critical-care services. Triage rules, escalation thresholds and emergency policies must be approved locally.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

A defined remote critical-care coordination composition with supported local-system, video or device interfaces scoped separately.

1. Establish hub & spoke: Identify participating facilities, critical-care beds and specialist coverage. Agree which organization owns care, which records remote staff may access and the escalation contacts for each site.

2. Prepare the case: Link the person and encounter to the shared review context. Confirm available observations, notes and imaging sources; commission camera or device connections only within the agreed scope.

3. Review remotely: Let the authorized specialist review the case and document the assessment and recommendations. Name the bedside owner who receives and acts on the plan; remote advice does not silently transfer clinical responsibility.

4. Follow & escalate: Track the next review and handover responsibilities. Maintain contact and downtime procedures for unavailable video, incomplete source information or a case requiring direct escalation.

Specialist workflow, video, cameras and clinical/device exchange have distinct delivery boundaries. Confirm each facility’s network, equipment and supported integrations before commissioning.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Visits, care plans and multidisciplinary documentation with verified palliative workflows. Mobile, offline and family channels are distinct scope.

1. Enroll & plan: Establish the person’s care context, consent and caregiver contacts. Define the service zone, multidisciplinary team and approved home or palliative-care plan with escalation responsibilities.

2. Schedule the visit: Assign the practitioner and visit time, accounting for service area and travel constraints. Confirm required equipment, medication and the information the visiting team needs.

3. Deliver & document: Record the encounter, observations, symptom review and delivered care. Keep medication and service requests with the current plan and document the caregiver discussion and next responsibilities.

4. Continue care: Plan the next visit or referral and hand over unresolved needs to the multidisciplinary team. Reconcile supplied items and delivered services through inventory and billing where selected.

Home-care documentation, scheduling, stock and remote support are selected separately. Offline work, remote devices and route optimization must be explicitly confirmed for the chosen deployment.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Verified case booking, preparation, perioperative documentation, resources, consumables and post-operative handover scope.

1. Plan the procedure: Connect the procedure request to the patient and encounter. Configure theatres, practitioners, sessions, equipment and service codes; confirm the responsible surgeon, anesthesia team and receiving ward.

2. Prepare & verify: Record preparation, consent references and the locally approved safety checklist. Review the relevant record, medication and required investigations before moving to the procedure.

3. Document the procedure: Keep clinical documentation, observations, medication and used supplies with the encounter. Link performed services and consumables to the relevant stock and charge records where those modules are selected.

4. Recover & hand over: Record recovery status and the next care plan. Transfer the current treatment, pending requests and responsibilities to the ward or discharge team, then reconcile documented service activity.

Theatre scheduling and clinical records are composed with inpatient, medication, inventory and billing capabilities. Anesthesia-device capture and external theatre systems need separate interface acceptance.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Verified critical-care record, observations, medication and device-connection scope. Monitoring and alarm functionality must be explicitly verified.

1. Receive into the unit: Link the admitted patient to the critical-care location and responsible team. Review the referral, current treatments and outstanding investigations at the initial handover.

2. Observe & document: Keep observations, assessments and care documentation in the encounter. Agree measurement units, recording frequency and local escalation responsibility; automated device feeds require an accepted device connection.

3. Coordinate treatment: Connect orders, medication administration and diagnostic reports to the current plan. Reconcile changes with the bedside team and document the owner of each pending action.

4. Handover & transfer: Review the current record and outstanding responsibilities at each shift or unit transfer. TeleICU review can be added with separately defined remote access, response ownership and device scope.

ICU clinical records do not imply every monitor, ventilator or alarm is integrated. Specify device models, supported protocols, responsible clinicians and downtime procedures in the selected scope.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Medication requests, dispensing and stock operation beyond prescribing or viewing a medication list.

1. Prescribe: Create the medication request with the encounter, product, dose, route, frequency and duration. Keep allergy and current medication context available for professional review.

2. Verify & prepare: Review the prescription in the pharmacy queue, confirm the item and quantity and choose the appropriate stock lot. Record any substitution through the authorized process rather than silently changing the prescription.

3. Dispense & hand over: Record prepared and handed-over medication, quantity, days supply and instructions. Link the dispense record to the patient, location, authorizing request and applicable charge.

4. Track & reconcile: Review outstanding prescriptions, completed dispensing and inventory movements. Handle returns and corrections through the approved stock and finance processes; inpatient administration remains a separate clinical record.

Prescribing, dispensing, administration and stock are linked but separate records. Formulary rules, unit conversions, payer coverage and external dispensers need their own accepted configuration.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Lab orders, specimen and result workflows with native operation distinct from external LIS integration.

1. Request: Select the test from the service catalogue and link it to the patient, encounter and ordering clinician. Include the clinical question, priority and required specimen information.

2. Collect & receive: Record specimen type, collection information, accession identifier, received time and condition. Keep processing notes and the original request linked so recollection can be traced.

3. Record & review: Keep observations and diagnostic reports with the request and specimen. Configure the approved test definitions, units and result interpretation; name the result reviewer and critical-result communication route.

4. Release & follow up: Make the approved report available in the clinical encounter. Preserve amendment reasons, reviewer responsibility and communication evidence; the ordering team owns the clinical follow-up.

Native requests, specimens, observations and reports are distinct from an external LIS or analyzer connection. Device protocols, code mappings, acknowledgements and downtime recovery require interface testing for the chosen release.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Verified radiology requests, departmental operation and reporting; RIS/PACS interfaces have separate delivery scope.

1. Refer & schedule: Create the imaging request with the clinical question, patient, encounter and requested procedure. Confirm modality, department availability and required preparation before the scheduled examination.

2. Acquire & identify: Connect departmental work to the request and accession information. When PACS is selected, verify patient, study and encounter identifiers before accepting the linked imaging study.

3. Interpret & report: Attach the diagnostic report to the correct clinical request. Confirm author, report status and clinical communication responsibility; agree the external reporting workflow if interpretation occurs in another system.

4. Communicate & amend: Return the report to the authorized care team, document critical findings through the approved pathway and retain addenda with their reason and owner. Track outstanding reports at handover.

Radiology request and report context is separate from image storage, viewing, acquisition hardware and RIS/PACS integration. Agree each included component and test DICOM study linkage and report exchange where selected.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Stock, stores and departmental supply operation within the agreed supported scope.

1. Define stock: Configure products, stores, units and supplier references. Import opening quantities by lot and location with cost and expiry information; reconcile the opening file to an approved stock count.

2. Request & receive: Create supply requests and delivery records, confirm the supplying and receiving locations and inspect actual received quantities. Retain references to the original request and supplier.

3. Issue & transfer: Select the item and lot for departmental use, dispensing or transfer. Confirm source, destination and quantity so physical movement can be reconciled with the correct inventory record.

4. Count & reconcile: Review on-hand stock, expiry and pending deliveries. Investigate count variances and record authorized adjustments and returns with a reason; agree the finance export when external accounting is used.

Stock and supply records support departmental activity. Procurement approvals, accounting exports, barcode devices and external warehouse systems require explicit scope and testing.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Required clinician and nursing documentation, observations, forms, care plans and handovers as defined for the selected care workflow.

1. Prepare forms: Configure approved questionnaires, clinical forms and author permissions for the care setting. Define required fields, terminology and review responsibility before use.

2. Document the encounter: Capture the assessment, observations, conditions and clinical narrative against the correct encounter. Keep structured responses and attachments linked to the patient and responsible author.

3. Review & complete: Review required information and the care plan. Apply the approved completion and signature process for the selected release, then make the relevant record available to authorized receiving teams.

4. Amend & retain: Handle corrections with an identified author and reason. Agree retention and record access, and preserve relevant versions and audit evidence when documentation is used for coding or external exchange.

Documentation supplies clinical context to orders, handovers and coding. External document exchange, signatures and retention policies must match the accepted release and organization rules.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Required order/result and medication scope for the chosen workflow, separate from native departmental operation.

1. Define destinations: Configure requestable services, medication catalogues and departmental destinations. Agree order statuses, required information and which roles may create, change or cancel requests.

2. Place the request: Link the order to the patient and encounter with the requested item, quantity and clinical context. For medication, record the dosage instructions and authorizing prescriber.

3. Fulfil & track: Route work to the selected department or pharmacy. Track request status and linked specimen, diagnostic report, dispense or administration records without treating these distinct events as one completion.

4. Review & reconcile: Review completed results and medication activity, document cancellations or changes and resolve outstanding requests at handover. Charge capture follows the performed service and selected billing configuration.

Order management coordinates requests. Laboratory processing, imaging systems, dispensing and administration need the corresponding operational modules; an interface alone does not supply departmental operation.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Registration, scheduling, encounter access and queues; patient portal and family communication scope is separately verified.

1. Publish availability: Configure practitioner or location resources, session dates, opening hours and slot rules. Link services and approved booking permissions to the resource.

2. Register & book: Identify the patient, review contact and identifier information and book the intended service. Preserve referral and payer details where the selected care and revenue workflow requires them.

3. Arrive & route: Record arrival and queue information, open or link the encounter and direct the person to the responsible clinic or department. Confirm the next responsibility rather than leaving a booking without a care destination.

4. Reschedule & follow up: Record completion, cancellation or missed attendance, then arrange an appropriate follow-up. Apply the configured revisit and charging policy using the selected billing workflow.

Access links a person to a care service. Public booking channels, patient communications and external identity or insurance services require selected and accepted connections.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Invoices, payments and financial records linked to care activity, with accounting connections defined separately.

1. Define charges: Configure service charge definitions, currency and the applicable tax treatment. Confirm account ownership, gross prices and authorized billing roles; contracted payer prices belong to the selected revenue-cycle configuration.

2. Capture activity: Link charges to the encounter and performed service with quantity and supporting context. Review unbilled medication and departmental services, and resolve missing or duplicate items before invoice preparation.

3. Invoice & collect: Review account charges, invoice ownership and the permitted patient or payer liability. Record payments against their reference and invoice; insurance estimates and submission approval remain separate decisions.

4. Reconcile & correct: Reconcile invoices and payments to accepted control totals. Handle refunds, reversals and adjustments with reasons and approval; agree accounting exports when required. ZATCA e-invoicing is included and transmits live after your ZATCA credentials and external acceptance.

Billing records service activity and money movements. Required NPHIES and ZATCA workflows are included in every plan. Live transmission is activated after your organisation’s NPHIES and ZATCA credentials and external acceptance. External accounting integration is agreed separately.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

A complete connected revenue workflow with granular modules for eligibility, authorization, payer configuration, charges, claims, denials and reconciliation.

1. Establish the rules: Configure legal organizations, administration agreements, provider contracts, products, issued policies and member classes in dependency order. Keep source evidence, effective dates and approval with each configuration version.

2. Verify coverage: Resolve member eligibility, provider network, benefit rules, exclusions, limits and tariff applicability for the requested service. An unknown fact creates a named review item; it must not silently become an assumed price or patient liability.

3. Authorize & prepare: Prepare required authorization and supporting evidence. Keep requested and approved services, quantities and validity separate. Review the provisional estimate, unresolved facts and expiry before accepting financial preparation.

4. Capture & submit: Attest performed activity, reconcile charges and assemble the claim with coding and attachments. Validate the payload and submission identity; production transmission requires approved credentials, endpoints, exchange package and activation evidence.

5. Resolve responses: Distinguish transport validation, payer business errors and adjudicated denials. Route corrections, evidence requests, contract disputes and clinical appeals to the right owner with the original business references and applicable deadlines.

6. Settle & explain: Link remittance advice to claims, distinguish adjudication from cash settlement and reconcile partial payments, deductions and unmatched cash. Review ageing, exceptions and decision traces without converting unresolved balances into patient charges.

Required NPHIES and ZATCA workflows are included in every plan. Live transmission is activated after your organisation’s NPHIES and ZATCA credentials and external acceptance. Catalogue reference data is not certified production configuration; payer credentials, terminology rights and external finance connections are each accepted before use.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Specific supported service-code mapping and update scope. Required clinical/claim codes are not removed to create a price upgrade.

1. Select the edition: Identify the supported Saudi Billing System catalogue release and usage rights. Agree whether the selected scope uses specified service codes or the full licensed catalogue.

2. Map local services: Connect each provider service to the approved code and effective period. Preserve local service identifiers, descriptions and mapping evidence; resolve unmatched services through coding review.

3. Validate use: Check required codes, inactive entries, duplicates and mapping completeness. Review representative service activity through the selected charge and claim workflow before accepting the mapping.

4. Maintain versions: Review edition changes and effective dates with the catalogue owner. Preserve earlier mappings for historical records and test affected downstream pricing and claims before activation.

SBS mapping is distinct from catalogue licensing and from NPHIES exchange acceptance. A mapping file does not grant catalogue rights or certify a claim.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Full supported catalogue import, mapping and update tooling; the actual release, scope and usage permissions are agreed.

1. Select the edition: Identify the supported Saudi Billing System catalogue release and usage rights. Agree whether the selected scope uses specified service codes or the full licensed catalogue.

2. Map local services: Connect each provider service to the approved code and effective period. Preserve local service identifiers, descriptions and mapping evidence; resolve unmatched services through coding review.

3. Validate use: Check required codes, inactive entries, duplicates and mapping completeness. Review representative service activity through the selected charge and claim workflow before accepting the mapping.

4. Maintain versions: Review edition changes and effective dates with the catalogue owner. Preserve earlier mappings for historical records and test affected downstream pricing and claims before activation.

SBS mapping is distinct from catalogue licensing and from NPHIES exchange acceptance. A mapping file does not grant catalogue rights or certify a claim.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Defined coding/casemix workflow, supported grouper release, licensing and interfaces; catalogue access does not imply an active grouper license.

1. Prepare coded episode: Identify the encounter and approved coding inputs required by the selected grouper. Review diagnosis, procedure and episode completeness with the coding owner before grouping.

2. Agree the grouper: Confirm the grouper release, licence, supported input format and delivery route. Establish whether processing is external or supplied in the accepted deployment; test representative coded cases.

3. Review grouping output: Keep the returned grouping result with its episode, input version and review responsibility. Validate errors and unexpected group assignments before using the result in casemix analysis.

4. Correct & compare: Preserve previous results when coding is corrected or a grouper version changes. Agree financial use and reporting definitions separately, then re-test representative episodes after changes.

DRG capability requires an agreed licensed grouper and supported integration. No particular grouper, national reimbursement rule or automatic financial outcome is implied.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Supported eligibility, authorization and claims exchange, with onboarding, credentials, versions and activation agreed explicitly.

1. Prepare provider identity: Confirm provider and payer identifiers, the supported exchange package and the responsible organization. Record onboarding evidence and agreed sandbox and production endpoints before connection testing.

2. Check eligibility & authorization: Prepare member, policy and service context for supported eligibility and authorization exchanges. Validate the request and preserve payer responses, validity and unresolved coverage information.

3. Exchange claims: Assemble supported claims and attachments, apply package validation and keep message and claim identities traceable. Transmission is permitted only after the production activation gates and required evidence are accepted.

4. Follow responses & reconcile: Track supported responses, polling and payment advice. Distinguish platform errors from payer decisions and reconcile returned business references under the accepted retry and correction rules.

NPHIES capability is subject to package support, onboarding, credentials and certification evidence. Built exchange code and sample reference data do not establish certified production readiness.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Supported e-invoice integration and onboarding, with applicable phase, configuration and operational responsibilities stated.

1. Define taxpayer & phase: Confirm the legal taxpayer, VAT identifier, applicable invoicing phase and invoice type. Assign the invoicing owner and record the approved tax and document identity rules.

2. Onboard the connection: Prepare the selected invoice unit, endpoint and securely managed credential references. Complete required onboarding and testing evidence; sample credentials or sandbox success do not authorize live submission.

3. Prepare & validate invoice: Link the supported invoice to billing activity, document identity and tax treatment. Verify required invoice data and the selected reporting or clearance route before transmission.

4. Submit & retain evidence: Keep the supported response and trace with the invoice. Follow approved rejection, retry, credit-note and credential-renewal procedures and reconcile submitted documents to the billing ledger.

E-invoice scope, phase, document types and production onboarding are explicitly agreed. This module description is not a certification or compliance claim.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Selected operational, departmental and revenue reports, separate from standard Core reporting.

1. Choose sources: Identify the operational source, owner and reporting boundary. Agree which facilities, encounters and financial records can contribute to each view and how data completeness will be checked.

2. Define measures: Specify the unit of analysis, numerator, denominator, exclusions and reporting period. Reconcile financial and activity totals before treating a dashboard as an accepted measure.

3. Publish a view: Configure the selected dashboard provider and view for its facility context. Verify role access, refresh behaviour, filters and the meaning of each displayed value with the intended users.

4. Monitor & maintain: Review source freshness and changes to definitions or mappings. Agree export controls and retain acceptance evidence when a view is used for operational or financial decisions.

The analytics connector supplies provider-based dashboard access. Specific dashboards, metrics, warehouse design and external finance feeds require a defined reporting scope and acceptance.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Only verified assistive tasks, defined data boundaries and responsible human review are offered. No autonomous diagnostic claim is made.

1. Approve the task: Define the text or image assistance use case, permitted data, model provider and responsible reviewer. Agree consent, data handling, evaluation criteria and a manual fallback before activation.

2. Provide context: Supply only the approved record context and inputs. Configure allowed models and usage limits; confirm image size, input boundaries and access for the selected feature.

3. Generate assistance: Use the configured provider to produce assistance for the approved task. Treat the output as proposed content with possible omissions or errors; the model does not replace professional judgment.

4. Review & retain: Have the responsible professional verify and edit the proposed content before saving or acting on it. Monitor approved evaluation results, access and provider failures under the agreed governance procedure.

The plugin supports configured text and image assistance. Autonomous diagnosis, prescribing or clinical action is not implied; each deployed use case and provider must be approved and evaluated.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Actual HIS, LIS, RIS/PACS, identity, device or API connections, protocols, licenses and delivery scope are specified individually.

1. Define the exchange: Name source and target systems, message types, direction, protocol and version. Agree whether the connection carries identity, encounters, orders, results, devices or financial activity and identify its owners.

2. Map identifiers & data: Map patient, facility, practitioner and encounter identifiers alongside service codes, units, timestamps and statuses. Define required fields, transformations and the treatment of unsupported values.

3. Test & accept: Use the agreed test environment, credentials and endpoint. Verify valid, invalid, duplicate and delayed messages, acknowledgements, ordering and reconciliation before approving production access.

4. Operate & recover: Monitor failed and pending exchanges and assign support responsibility. Follow approved retry and duplicate rules, then reconcile records after downtime, credential rotation or interface version changes.

Available protocols and adapters are release-specific. A third-party system name or standards logo is not proof of an active connector; accept the exact data, direction, license and support scope.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Defined entity, tenant and record boundaries, accountable access and governed network composition.

1. Map the network: Identify legal organizations, facilities, departments and their administrative owners. Define which catalogues and patient contexts are shared and which remain isolated.

2. Delegate access: Assign cross-site and local responsibilities to named roles. Test access within a site, across accepted sharing boundaries and against restricted records.

3. Coordinate continuity: Agree referral, record and responsibility handovers across participating services. Specify identifier mapping and the systems retaining ownership when an external facility is connected.

4. Review boundaries: Maintain governance and acceptance evidence as sites, roles or releases change. Re-test sharing, restricted access and interface recovery before extending the network.

Shared facilities in one deployment and exchange between separate tenants are different scopes. The agreed governance and integration design determines record sharing.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

Qualified people, authorized access and an accepted operating scope, separate from RCM software.

1. Agree responsibilities: Specify delegated revenue tasks, authorized users, provider and payer boundaries and service coverage. Name the organization that retains each clinical, contractual and financial decision.

2. Prepare the work: Establish source access, work queues and the documents needed for eligibility, coding, authorization or claim tasks. Approve handover rules and quality checks before processing live work.

3. Process & escalate: Perform only the agreed tasks through authorized workflows. Route missing clinical evidence, contracting questions and payer disputes to the retained owner and keep submission authority explicit.

4. Review service delivery: Reconcile completed work, remittance and outstanding exceptions with the provider. Review agreed measures, support coverage and change requests against the service terms without promising unsupported financial outcomes.

People services are distinct from software licensing and integration activation. Agree staffing, delegated authority, hours, deliverables and support terms in the service proposal.

Accept the release, configuration, permissions, dependencies and tests with the workflow owner before activation. Public visibility alone does not establish clinical readiness.

MANSOQ connects the patient record, care workflow, billing and agreed non-clinical operations. Your team works from a shared care context instead of repeatedly reconstructing what happened across separate queues. Choose a care product and plan, then agree the modules, connections, responsibilities and launch scope that fit your organisation.

These care packages combine software with a defined monthly allowance of managed non-clinical work. Software supports the workflow; managed services help with agreed configuration, specialist review and operational queues. The proposal separates the two fees so you can see what you are buying. Licensed clinical staffing is supplied by the customer.

Choose Clinics for appointment-led outpatient care; Polyclinics for connected specialties, pharmacy, laboratory and stock; TeleICU for remote ICU consultation and handover; and Home & Palliative Care for visits, continuity, care plans and authorised family communication. Choose by the workflow you need to operate, not only by the facility name.

Essential suits teams that can own their daily operations and need the complete contracted care workflow with baseline security, support and required national foundations. It provides a smaller managed-hours allowance. For example, your own reception and billing teams perform the daily work while MANSOQ helps with agreed setup and review tasks.

Choose Premium when repeated tasks, disconnected handoffs or growing activity are making daily work harder. It adds workflow automation, operational dashboards, more care capacity, more managed hours and the published maintained-interface allowance. Its benefit is helping your team see and handle exceptions sooner; your team still owns the operational decisions and follow-through.

Diamond includes Premium and adds a named owner for agreed operational queues, a monthly performance and capacity review, larger service allowances and the option to use your own clinical database and file storage. For example, an agreed unresolved billing or visit task has an identified MANSOQ contact coordinating the next action within the contracted hours.

Enterprise suits groups with multiple legal entities, complex integrations, dedicated deployment or an operating scope that needs a tailored agreement. It adds agreed group governance, permissions, consolidated reporting and a coordinated implementation programme. Sales defines the actual capacity, interfaces, managed scope, infrastructure responsibilities and service targets in the proposal.

The baseline includes role-based access, an audit trail, consent, backup and export, plus Saudi insurance and coding foundations for the contracted workflow. Required NPHIES and ZATCA workflows are included in every plan. Live transmission is activated after your organisation’s NPHIES and ZATCA credentials and external acceptance. Higher plans add capacity, automation, managed follow-through and governance.

Compare the actual constraint you want to remove: care capacity, repeated work, interfaces, operational follow-through or group governance. Then compare the included hours and connections with your workload. An illustrative measure is the number of overdue tasks or repeated data-entry steps before and after rollout. MANSOQ does not promise a fixed saving or revenue increase without your baseline and agreed measurement.

Yes, a mixed care scope can be discussed in one composition proposal. For example, a group may need outpatient clinics, remote ICU consultation and home-care follow-up. Agree each workflow, capacity measure, data boundary and responsible team. Do not simply add public card prices and assume that this covers shared infrastructure or separate legal entities.

Patient record, scheduling, documentation, orders, medication and billing for the contracted care workflow.

Role-based access, audit trail, consent, backup and export; required Saudi insurance, coding, NPHIES and ZATCA workflows where applicable.

Patient / family access, baseline product support, onboarding and agreed migration specification.

Customer supplies licensed clinicians, clinical decisions, escalation coverage, medical governance and source-system permissions. MANSOQ supplies the contracted technology and non-clinical operations.

What it means A managed revenue-cycle service for your approved billing and payer worklists, priced on the money actually collected within the agreed scope.

How it works Agree the revenue-service scope, customer responsibilities and eligible collection definition with the team. The service supports the accepted eligibility, claims and reconciliation workflows. Collection fees follow the accepted agreement and reviewed financial evidence.

One example On SAR 100,000 of approved eligible collections, the RaaS fee is SAR 18,000, plus applicable VAT. The package subscription is charged separately.

Your benefit & expected result An accountable team follows revenue exceptions through to reconciliation, with a transparent fee tied to eligible collections. Payer approval and collection outcomes depend on the actual evidence and payer decisions.

Included scope Agreed eligibility and authorisation follow-up, claim preparation and submission, rejection and denial worklists, payer follow-up and remittance reconciliation. Customer retains clinical decisions, source permissions and approval of refunds, write-offs and bank changes. Fees are additional to the package subscription, on eligible cleared collections after agreed refunds and exclusions; implementation and service acceptance are required. Activate only after signed scope and implementation/service acceptance. No annual discount applies to collection fees.

What it means Patients and authorised family members can access the agreed patient-facing information. Staff access is based on their job and care responsibilities.

How it works Assign roles such as clinician, reception and billing, then approve patient or family access. Permissions control available actions and records; the audit trail records activity.

One example A receptionist manages an appointment while the treating clinician updates clinical notes. An authorised family member sees only the information approved for them.

Your benefit & expected result People can do their work and follow care with appropriate access, while you retain visibility of who used the system.

Included scope Access depends on configured permissions, consent and the agreed patient/family workflow.

What it means A current view of agreed operational measures, such as activity, outstanding work and capacity usage.

How it works The dashboards summarise recorded system activity. Authorised managers can review the agreed measures and investigate the underlying work.

One example A clinic manager reviews completed visits and outstanding billing tasks, then assigns the backlog to the appropriate team.

Your benefit & expected result A clearer view of where work is building up, so managers can prioritise action using recorded data.

Included scope Measures and refresh frequency depend on the accepted scope and the completeness of source data.

What it means A scheduled review of agreed operational results, outstanding issues and how much of your package capacity you are using.

How it works The named owner prepares the agreed measures, reviews them with you and records actions, responsible people and any capacity changes you approve. Preparation and review use managed hours.

One example You review clinician-capacity usage and the billing backlog, then agree the next month’s operational priorities.

Your benefit & expected result An agreed action plan and fewer surprises about capacity. Outcomes depend on the recorded data and follow-through by both teams.

What it means An agreed access and governance structure for a group with multiple facilities or legal entities.

How it works Map the entities, data boundaries and responsible roles with sales and implementation. Approve who can work within each entity and who can see permitted group-level information, then test those permissions before launch.

One example A branch manager sees the records they are authorised to manage at their branch; a group director sees the approved group-level reports.

Your benefit & expected result Clearer accountability across the group and access that follows your agreed organisational boundaries.

Included scope Separate legal entities and patient-record sharing require an agreed data and deployment scope.

What it means Bring agreed measures from multiple facilities into a group view for authorised leadership.

How it works Agree the facilities, measures, definitions and reporting frequency. The group view consolidates the accepted data while respecting the approved permissions and data boundaries.

One example A director compares monthly care activity and outstanding operational work across three branches using the same agreed definitions.

Your benefit & expected result Easier comparison across locations and a clearer basis for assigning resources and investigating differences.

Included scope Included sources, reporting frequency and any custom report development are agreed in the Enterprise proposal.

What it means A separately defined integration and support scope designed around your organisation’s systems and operating needs.

How it works Sales and delivery agree the systems, exchanged data, acceptance tests, service hours, response targets and responsibilities. Each connection is commissioned before use; the signed agreement sets the support commitment.

One example A group needs its existing finance system connected to accepted billing data. The proposal defines the mapping, tests and support arrangements for that connection.

Your benefit & expected result A clear scope for your more complex setup and measurable service commitments once agreed.

Included scope Connections, vendor charges, service targets and price are determined in the sales quotation. Enterprise does not imply unlimited integrations or automatic 24/7 coverage.

What it means A coordinated launch plan for your agreed facilities, migration, integrations, training and acceptance.

How it works Agree milestones, owners and acceptance criteria. Prepare and reconcile the migration, test access and connections, train the agreed users, and review readiness before a planned cutover.

One example Three branches launch in stages: a pilot branch first, migration reconciliation and training next, then the other branches after their acceptance checks.

Your benefit & expected result A clearer launch sequence, visible responsibilities and agreed evidence for each readiness decision.

Included scope Delivery dates, migration work, on-site attendance and price are defined in the signed implementation scope.

What it means The Saudi insurance, coding and electronic-invoicing workflows that apply to your contracted care service.

How it works During setup, agree which workflows apply, such as NPHIES insurance exchange, Saudi billing codes and ZATCA invoicing. Activate and test the relevant connections with your organisation’s required credentials and approvals.

One example An insured clinic needs NPHIES eligibility checks and electronic invoices. Those applicable workflows are included in the foundation and accepted before use.

Your benefit & expected result Your applicable national workflows are part of the care foundation, with required information and connection status easier to follow.

Included scope Organisational approvals, payer/vendor access and connection acceptance are required. National foundation connectors do not use the separate external-interface allowance.

What it means An optional deployment choice: keep the primary clinical database and private clinical, facility and report files in infrastructure you control.

How it works Provide a dedicated PostgreSQL database and private S3-compatible storage, such as AWS S3, DigitalOcean Spaces or MinIO on your server. After credentials, network, backup and recovery are accepted, the live app, imports, reports and background workers use that destination.

One example Your organisation owns a PostgreSQL database and a private Spaces bucket. A new clinical record is saved in your database, and a patient attachment is saved in your bucket.

Your benefit & expected result More control over the primary clinical data location, infrastructure access and recovery policy. The clinical runtime has no automatic fallback to a MANSOQ database or bucket.

Included scope Available in Diamond and Enterprise after connection acceptance. Infrastructure and connection/migration work are scoped separately. The full data-processing and retention scope is defined in the accepted agreement. Changing an existing live destination requires an agreed migration.

The recurring base combines the published software fee and managed-services fee. Additional care capacity, sites and approved managed hours are added at the selected plan rates. Setup, migration, bespoke work, customer infrastructure and applicable third-party usage are scoped separately. Review the itemised proposal, tax and commercial term before accepting it.

The care-package card prices are in Saudi riyals (SAR) before VAT. Applicable tax is shown separately in the proposal. Check the billed currency and tax treatment on the final quotation, especially for an organisation outside Saudi Arabia. A displayed monthly amount should be compared with the complete invoice, not treated as a tax-inclusive total.

Enterprise depends on your entities, scale, integration work, deployment, migration and agreed operating responsibilities. A public fixed price could hide material work or imply commitments that have not been scoped. Use Request a sales call; the selected care product and Enterprise package are included in the request so the team can prepare the right quotation.

Annual prepayment applies the published discount to the base software fee only. Managed services, additional care capacity, sites, hours, setup and third-party charges are not reduced by that discount. The package builder shows the selected billing basis. The signed proposal determines payment dates and the actual invoicing arrangement.

These are launch projects whose effort depends on source data, record quality, interfaces, training, sites and cutover work. The monthly package describes recurring use and the agreed ongoing service allowance. A small clean import and a complex multi-system migration need different launch scopes. Any displayed setup range is a planning budget, with the final scope agreed in writing.

Depending on your selection, budget for messaging, video, network carriers, hardware, external-system licences or interface fees, and customer-owned infrastructure. Agree the supplier, payer, usage limit and consent requirements before activation. An included workflow or maintained interface does not mean the supplier provides its equipment or traffic free of charge.

Have the proposal list base capacity, additional-unit and site rates, included hours, approved extra hours, interfaces, setup, infrastructure and third-party usage. Agree who can approve extra work and how usage is reported. Routine service terms call for notifications at 80% and 100% of the managed-hours allowance and approval before additional work.

No contract duration should be inferred from the card price. The quotation and signed agreement define the term, payment schedule, renewal, notice and cancellation rules. Ask the sales team to state those terms explicitly before signing, including how an annual prepayment or staged implementation affects your commitment.

The builder lets you review a proposed scope and request help without making a payment. Sending a proposal request does not activate a clinical service or accept a contract. Review the itemised commercial and implementation scope, then use the agreed acceptance and payment process if you decide to proceed.

Discuss the country, care workflow, billing rules, data location, hosting and required local connections with sales. The Saudi catalogue is a starting point for scope, not an automatic promise of every country-specific integration or tax arrangement. A regional proposal should state the applicable currency, local requirements, deployment and support window.

Essential: SAR 150.00 per additional care unit per month; SAR 400.00 per additional site per month; SAR 180.00 per approved extra managed hour.

Premium: SAR 200.00 per additional care unit per month; SAR 600.00 per additional site per month; SAR 180.00 per approved extra managed hour.

Diamond: SAR 250.00 per additional care unit per month; SAR 900.00 per additional site per month; SAR 180.00 per approved extra managed hour.

These rates are before VAT and do not increase other included allowances. Enterprise additions are scoped in its sales quotation. Bespoke work, infrastructure and vendor charges are separate.

Essential: SAR 150.00 per additional care unit per month; SAR 1,500.00 per additional site per month; SAR 180.00 per approved extra managed hour.

Premium: SAR 200.00 per additional care unit per month; SAR 2,000.00 per additional site per month; SAR 180.00 per approved extra managed hour.

Diamond: SAR 250.00 per additional care unit per month; SAR 3,000.00 per additional site per month; SAR 180.00 per approved extra managed hour.

These rates are before VAT and do not increase other included allowances. Enterprise additions are scoped in its sales quotation. Bespoke work, infrastructure and vendor charges are separate.

Essential: SAR 200.00 per additional care unit per month; SAR 1,500.00 per additional site per month; SAR 280.00 per approved extra managed hour.

Premium: SAR 350.00 per additional care unit per month; SAR 2,500.00 per additional site per month; SAR 280.00 per approved extra managed hour.

Diamond: SAR 500.00 per additional care unit per month; SAR 4,000.00 per additional site per month; SAR 280.00 per approved extra managed hour.

These rates are before VAT and do not increase other included allowances. Enterprise additions are scoped in its sales quotation. Bespoke work, infrastructure and vendor charges are separate.

Essential: SAR 20.00 per additional care unit per month; SAR 750.00 per additional site per month; SAR 180.00 per approved extra managed hour.

Premium: SAR 35.00 per additional care unit per month; SAR 1,250.00 per additional site per month; SAR 180.00 per approved extra managed hour.

Diamond: SAR 50.00 per additional care unit per month; SAR 2,000.00 per additional site per month; SAR 180.00 per approved extra managed hour.

These rates are before VAT and do not increase other included allowances. Enterprise additions are scoped in its sales quotation. Bespoke work, infrastructure and vendor charges are separate.

Illustrative example using the published Clinics Premium rate: SAR 1,090.00 base software + SAR 900.00 managed services = SAR 1,990.00 per month before VAT.

With annual software prepayment, the base monthly-equivalent total is SAR 1,881.00 and the recurring-year equivalent is SAR 22,572.00. Only software receives the published discount. Approved extras, setup, tax and supplier fees are additional, and invoice timing follows the contract.

Illustrative Clinics Premium configuration: 152 clinician units, two sites and one approved extra managed hour.

Base SAR 1,990.00 + two extra care units SAR 400.00 + one extra site SAR 600.00 + one extra hour SAR 180.00 = SAR 3,170.00 per month before VAT, setup and third-party costs.

The care-unit increase does not add hours or interfaces. Actual changes require approval and the accepted quotation.

Clinics and Polyclinics count named independent clinicians; TeleICU counts commissioned ICU beds; Home & Palliative Care counts unique active patients during the month. These measures reflect the workload of each care setting. A care unit is not a visit, a software login or a shift unless your accepted contract explicitly defines it that way.

The clinician measure counts named independent clinicians delivering care. Assisting nursing, administration and support accounts do not add a clinician fee under that definition. For example, 20 independent clinicians and five reception accounts use 20 clinician units. Agree named clinician identities and role access; this definition does not promise unlimited accounts or infrastructure resources.

The measure is a commissioned, enabled ICU bed under the contract. It is not the daily number of occupied beds. For example, 50 commissioned beds use 50 units even if occupancy changes. Agree which sites and beds are accepted, enabled and later decommissioned so the contracted count stays clear.

No. A unique patient with a completed contracted visit or active remote episode is counted once during the month across contracted branches. Four visits for the same patient still count as one active patient. Archived or deceased patients do not remain billable under the published definition; agree reconciliation and activity records before billing.

Additional care units and sites do not automatically increase managed hours or maintained interfaces. These are separate allowances. For example, more home-care patients may require both additional patient capacity and extra agreed dispatch support; the second part needs its own managed-hours scope. The proposal should show each change separately.

The non-Enterprise packages include one facility or branch in the contracted data boundary. Additional sites are priced separately and require agreed access, capacity and setup. A separate legal entity or a requirement to segregate patient data may need an Enterprise proposal rather than a simple extra-site fee.

Review actual care usage, managed workload and interface needs together. Compare approved extra capacity with the next plan instead of looking at the unit price alone. Agree the capacity change, effective date and resulting fees before use. Clinical continuity, access and billing reconciliation should be part of the change plan.

The plus sign indicates a larger deployment to be scoped with sales. It is not an unlimited allowance or an automatic minimum purchase requirement. The quotation specifies actual care units, sites, users, interfaces, managed operations and infrastructure limits. Use the reference as an invitation to size your organisation accurately.

Clinics: Essential 50 active clinicians; Premium 150 active clinicians; Diamond 250 active clinicians; Enterprise 550+ active clinicians

Polyclinics: Essential 50 active clinicians; Premium 150 active clinicians; Diamond 250 active clinicians; Enterprise 550+ active clinicians

TeleICU: Essential 50 commissioned ICU beds; Premium 150 commissioned ICU beds; Diamond 250 commissioned ICU beds; Enterprise 550+ commissioned ICU beds

Home & Palliative Care: Essential 50 active patients / month; Premium 150 active patients / month; Diamond 250 active patients / month; Enterprise 550+ active patients / month

The non-Enterprise packages include one site. Enterprise is a sizing reference; sales agrees actual limits. Use the product’s counting definition and reconcile the accepted capacity before billing.

Within the accepted workflow, reception schedules and registers the patient, the clinician documents the consultation and orders, and the authorised team prepares the cash or insurance billing and follow-up. The shared patient and encounter context connects those steps. Example: a missing insurance detail remains a visible operational task rather than being lost after the consultation.

The contracted outpatient scope includes cash and insurance workflows. Agree your services, tariffs, payers, authorisation requirements and applicable national connections during setup. The platform helps connect documented care with billing and payer follow-up; payer approval and collection still depend on correct evidence, eligibility, contracts and the payer response.

Premium and above add agreed recall and reminder automation. Define which follow-ups need a task or message, who owns the queue and how consent and contact details are handled. For example, an agreed follow-up list helps reception see whom to contact next. Message delivery, attendance and clinical follow-up are not guaranteed; provider usage is scoped separately.

Use the tailored builder or discuss an expansion with sales. Additional departments require their accepted module scope, required companions, setup, access roles and any external connections. A clinic package should not be assumed to include every hospital department. If several specialties and departmental workflows are central to your operation, compare the Polyclinics scope.

Essential: 18%; Premium: 15%; Diamond: 10%; Enterprise: 4.5%–7.5%. These percentages apply to approved eligible cleared collections, additional to the package subscription. Enterprise needs an approved exact rate within the range and an accepted scope. Actual fees are calculated from reviewed financial evidence after agreed refunds and exclusions; estimated collections in the builder do not create an invoice.

Essential: SAR 990.00 per month, comprising SAR 690.00 software + SAR 300.00 managed services. Includes 50 active clinicians and one site.

Premium: SAR 1,990.00 per month, comprising SAR 1,090.00 software + SAR 900.00 managed services. Includes 150 active clinicians and one site.

Diamond: SAR 3,490.00 per month, comprising SAR 1,690.00 software + SAR 1,800.00 managed services. Includes 250 active clinicians and one site.

Enterprise: Price and actual operating scope are determined by the sales quotation.

All public amounts are before VAT. The setup and migration budget range is indicative; the final price follows the statement of work. Additions and third-party costs are separately scoped. An unapproved price is not a public offer.

Essential: Complete the care workflow. Appointment, consultation, referral and cash / insurance workflow with basic operating reports.

Premium: Reduce repeat work and find exceptions sooner. Appointment, consultation, referral and cash / insurance workflow with basic operating reports. Recall and reminder automation, eligibility / authorization worklists, denial analytics and monthly specialist optimization.

Diamond: Give agreed operational queues an accountable owner. Appointment, consultation, referral and cash / insurance workflow with basic operating reports. Recall and reminder automation, eligibility / authorization worklists, denial analytics and monthly specialist optimization. Named owner for agreed claims / recall queues, exception follow-up and a monthly recovery and performance review. Use your own PostgreSQL database and private S3-compatible storage, including customer cloud, Spaces or server-hosted storage. Migrations, clinical files, reports and background jobs use the accepted customer destination; credentials, network, backups and recovery are commissioned before go-live.

Enterprise: Govern care and operations across the organization. Appointment, consultation, referral and cash / insurance workflow with basic operating reports. Recall and reminder automation, eligibility / authorization worklists, denial analytics and monthly specialist optimization. Named owner for agreed claims / recall queues, exception follow-up and a monthly recovery and performance review. Group governance, entity-specific permissions, consolidated reporting, agreed integrations and dedicated operating scope. Use your own PostgreSQL database and private S3-compatible storage, including customer cloud, Spaces or server-hosted storage. Migrations, clinical files, reports and background jobs use the accepted customer destination; credentials, network, backups and recovery are commissioned before go-live.

Higher tiers retain the contracted care foundation. Capacity, managed-hour and interface allowances are separate; the accepted proposal determines the live scope.

What it means The daily care workflow in one system: appointments, the patient record, clinical documentation, orders and billing.

How it works Reception books the visit, the clinician documents care, and authorised billing staff use the recorded services to prepare the invoice or insurance workflow.

One example A patient books a consultation. The doctor records the visit and orders a test; billing staff prepare the agreed charges from that visit.

Your benefit & expected result Less repeated entry and an easier way to trace the appointment, care record and charges together.

What it means Routine steps follow agreed rules, while items needing human attention appear in a shared work list.

How it works Agree the trigger, next step and responsible role. When a required item is missing or a task cannot move forward, it is routed to the appropriate team for review.

One example A visit is ready for billing but an insurance detail is missing. The case goes to the billing team’s follow-up queue instead of being lost among completed visits.

Your benefit & expected result Fewer forgotten tasks and less time searching for the next action. Your team reviews and resolves exceptions.

Included scope Automation rules are configured for your accepted workflow; insurer approval and payment are not guaranteed.

What it means A named MANSOQ operations contact is accountable for following through on your agreed non-clinical work queues.

How it works Agree the queue, actions and escalation route. The owner reviews outstanding work, coordinates with your team and records progress within the included managed-hours allowance.

One example A billing task is missing documentation. The owner coordinates with your billing team, records the next action and follows its progress.

Your benefit & expected result Clearer responsibility and fewer hand-offs between contacts, with a visible record of follow-up.

Included scope The owner operates within the agreed service window and hours. Full outsourced billing, unlimited queue work and clinical staffing require their own scope.

Polyclinics adds shared outpatient records and cross-specialty referrals with the contracted pharmacy, laboratory, inventory and departmental billing scope. Its operational focus is the handoff between teams. Example: a clinician requests an accepted laboratory service, the result stays linked to the patient and the documented service supports the authorised billing workflow.

Shared care context is governed by approved roles, facilities and data boundaries. Agree which clinicians and departmental teams may read or update each relevant part, then test their permissions before launch. The benefit is a more connected referral or handover while preserving accountability. Separate legal entities require an agreed sharing and deployment scope.

Accepted departmental workflows connect service requests, results or medication activity with the patient and the relevant stock and charge evidence. This helps teams follow what was requested, performed and recorded. Premium adds agreed handoff automation, stock and expiry alerts and contribution reporting. Exact data, catalogue setup and device connections are accepted during implementation.

Agree specific exception or revenue-cycle queues with the named operations owner. The owner coordinates outstanding documentation, handoffs or charge-evidence issues and records progress within the included hours. The monthly review helps identify repeated causes and assign actions. It is a defined follow-through service, not a guarantee that every possible lost charge will be recovered.

Essential: 18%; Premium: 15%; Diamond: 10%; Enterprise: 4.5%–7.5%. These percentages apply to approved eligible cleared collections, additional to the package subscription. Enterprise needs an approved exact rate within the range and an accepted scope. Actual fees are calculated from reviewed financial evidence after agreed refunds and exclusions; estimated collections in the builder do not create an invoice.

Essential: SAR 2,490.00 per month, comprising SAR 1,490.00 software + SAR 1,000.00 managed services. Includes 50 active clinicians and one site.

Premium: SAR 4,990.00 per month, comprising SAR 2,790.00 software + SAR 2,200.00 managed services. Includes 150 active clinicians and one site.

Diamond: SAR 8,990.00 per month, comprising SAR 4,490.00 software + SAR 4,500.00 managed services. Includes 250 active clinicians and one site.

Enterprise: Price and actual operating scope are determined by the sales quotation.

All public amounts are before VAT. The setup and migration budget range is indicative; the final price follows the statement of work. Additions and third-party costs are separately scoped. An unapproved price is not a public offer.

Essential: Complete the care workflow. Shared outpatient records, cross-specialty referrals, pharmacy, laboratory, stock and departmental billing.

Premium: Reduce repeat work and find exceptions sooner. Shared outpatient records, cross-specialty referrals, pharmacy, laboratory, stock and departmental billing. Department handoff automation, tariff / denial review, stock and expiry alerts and service contribution reporting.

Diamond: Give agreed operational queues an accountable owner. Shared outpatient records, cross-specialty referrals, pharmacy, laboratory, stock and departmental billing. Department handoff automation, tariff / denial review, stock and expiry alerts and service contribution reporting. Named operations owner for cross-department exceptions, charge leakage and agreed RCM queues; monthly management review. Use your own PostgreSQL database and private S3-compatible storage, including customer cloud, Spaces or server-hosted storage. Migrations, clinical files, reports and background jobs use the accepted customer destination; credentials, network, backups and recovery are commissioned before go-live.

Enterprise: Govern care and operations across the organization. Shared outpatient records, cross-specialty referrals, pharmacy, laboratory, stock and departmental billing. Department handoff automation, tariff / denial review, stock and expiry alerts and service contribution reporting. Named operations owner for cross-department exceptions, charge leakage and agreed RCM queues; monthly management review. Group governance, entity-specific permissions, consolidated reporting, agreed integrations and dedicated operating scope. Use your own PostgreSQL database and private S3-compatible storage, including customer cloud, Spaces or server-hosted storage. Migrations, clinical files, reports and background jobs use the accepted customer destination; credentials, network, backups and recovery are commissioned before go-live.

Higher tiers retain the contracted care foundation. Capacity, managed-hour and interface allowances are separate; the accepted proposal determines the live scope.

What it means The daily care workflow in one system: appointments, the patient record, clinical documentation, orders and billing.

How it works Reception books the visit, the clinician documents care, and authorised billing staff use the recorded services to prepare the invoice or insurance workflow.

One example A patient books a consultation. The doctor records the visit and orders a test; billing staff prepare the agreed charges from that visit.

Your benefit & expected result Less repeated entry and an easier way to trace the appointment, care record and charges together.

What it means Routine steps follow agreed rules, while items needing human attention appear in a shared work list.

How it works Agree the trigger, next step and responsible role. When a required item is missing or a task cannot move forward, it is routed to the appropriate team for review.

One example A visit is ready for billing but an insurance detail is missing. The case goes to the billing team’s follow-up queue instead of being lost among completed visits.

Your benefit & expected result Fewer forgotten tasks and less time searching for the next action. Your team reviews and resolves exceptions.

Included scope Automation rules are configured for your accepted workflow; insurer approval and payment are not guaranteed.

What it means A named MANSOQ operations contact is accountable for following through on your agreed non-clinical work queues.

How it works Agree the queue, actions and escalation route. The owner reviews outstanding work, coordinates with your team and records progress within the included managed-hours allowance.

One example A billing task is missing documentation. The owner coordinates with your billing team, records the next action and follows its progress.

Your benefit & expected result Clearer responsibility and fewer hand-offs between contacts, with a visible record of follow-up.

Included scope The owner operates within the agreed service window and hours. Full outsourced billing, unlimited queue work and clinical staffing require their own scope.

The customer supplies the licensed remote and bedside clinicians, clinical decisions, escalation coverage and medical governance. MANSOQ supplies the contracted technology and non-clinical operating support. Commissioned bed capacity does not purchase clinician shifts, continuous clinical alarm surveillance or emergency response staffing.

The Essential scope is consultation-led with secure consultation, manually entered or charted data, handover, escalation and downtime procedures. Agree the information your clinicians require, who enters it and how they verify its time and source. A clinical record containing manually entered data should not be presented as a live monitor feed.

Examples include an admission or EHR feed, monitors, ventilators and laboratory results, within the selected maintained-interface allowance. Each feed needs an authorised source, supported format, agreed mapping, patient and bed matching, freshness checks and accepted tests. A plan allowance is a scope limit; it does not mean every vendor device is already commissioned.

Freshness and disconnect controls are part of the accepted connected workflow. Agree how the team recognises an unavailable or old feed, verifies current information and uses the downtime procedure. The clinical team must not rely on an outdated value as current. Escalation, fallback documentation and ownership are rehearsed before clinical launch.

Your licensed clinical organisation defines and provides that response. Agree the bedside and remote escalation chain, response coverage and emergency pathway under your medical governance. Managed operational hours and a named technical workflow owner do not replace clinical alarm surveillance or an emergency care team.

Equipment, telepresence and connectivity are customer-owned or separately quoted. Assess compatible devices, permissions, bandwidth, maintenance, power and recovery with your technical and clinical teams. The package describes a technology and operating scope; the proposal must identify the hardware and carrier responsibilities needed to run it.

The intended benefit is clearer consultation documentation, more consistent handover and a visible agreed follow-up path. Accepted connected feeds can reduce repeated information collection; named operational follow-through can make unresolved technical tasks easier to track. Measure these changes against your own baseline. Clinical outcomes depend on your clinicians, protocols, data quality and delivery context.

Essential: 18%; Premium: 15%; Diamond: 10%; Enterprise: 4.5%–7.5%. These percentages apply to approved eligible cleared collections, additional to the package subscription. Enterprise needs an approved exact rate within the range and an accepted scope. Actual fees are calculated from reviewed financial evidence after agreed refunds and exclusions; estimated collections in the builder do not create an invoice.

Essential: SAR 6,500.00 per month, comprising SAR 4,500.00 software + SAR 2,000.00 managed services. Includes 50 commissioned ICU beds and one site.

Premium: SAR 12,500.00 per month, comprising SAR 8,500.00 software + SAR 4,000.00 managed services. Includes 150 commissioned ICU beds and one site.

Diamond: SAR 22,000.00 per month, comprising SAR 14,000.00 software + SAR 8,000.00 managed services. Includes 250 commissioned ICU beds and one site.

Enterprise: Price and actual operating scope are determined by the sales quotation.

All public amounts are before VAT. The setup and migration budget range is indicative; the final price follows the statement of work. Additions and third-party costs are separately scoped. An unapproved price is not a public offer.

Essential: Complete the care workflow. Consult-led remote ICU workflow: secure consultation, manual/charted data, handoff, escalation and downtime procedures.

Premium: Reduce repeat work and find exceptions sooner. Consult-led remote ICU workflow: secure consultation, manual/charted data, handoff, escalation and downtime procedures. Two accepted data interfaces, such as ADT/EHR and monitor feeds; freshness / disconnect controls and specialist workflow optimization.

Diamond: Give agreed operational queues an accountable owner. Consult-led remote ICU workflow: secure consultation, manual/charted data, handoff, escalation and downtime procedures. Two accepted data interfaces, such as ADT/EHR and monitor feeds; freshness / disconnect controls and specialist workflow optimization. Four accepted interfaces, such as ADT, monitor, ventilator and laboratory; named technical workflow owner and review of exceptions. Use your own PostgreSQL database and private S3-compatible storage, including customer cloud, Spaces or server-hosted storage. Migrations, clinical files, reports and background jobs use the accepted customer destination; credentials, network, backups and recovery are commissioned before go-live.

Enterprise: Govern care and operations across the organization. Consult-led remote ICU workflow: secure consultation, manual/charted data, handoff, escalation and downtime procedures. Two accepted data interfaces, such as ADT/EHR and monitor feeds; freshness / disconnect controls and specialist workflow optimization. Four accepted interfaces, such as ADT, monitor, ventilator and laboratory; named technical workflow owner and review of exceptions. Group governance, entity-specific permissions, consolidated reporting, agreed integrations and dedicated operating scope. Use your own PostgreSQL database and private S3-compatible storage, including customer cloud, Spaces or server-hosted storage. Migrations, clinical files, reports and background jobs use the accepted customer destination; credentials, network, backups and recovery are commissioned before go-live.

Higher tiers retain the contracted care foundation. Capacity, managed-hour and interface allowances are separate; the accepted proposal determines the live scope.

What it means A shared record for your remote ICU consultations, care plans and clinical handovers.

How it works Your licensed team records the consultation, documents decisions and assigns follow-up to the responsible clinician. Authorised colleagues can see the same care record.

One example A remote intensivist documents a consultation for a patient in bed 12. The bedside team reads the plan and records the agreed follow-up.

Your benefit & expected result A clearer handover and less searching for the latest plan. Your clinicians remain responsible for treatment and escalation.

What it means Bring agreed ICU data sources into the care workflow so authorised teams can review information together.

How it works Agree the source system and data fields, connect and test the interface, and define who follows up when information is missing or a connection needs attention.

One example An accepted hospital interface sends lab results into the ICU workflow. A missing result appears in an agreed follow-up queue for the responsible team.

Your benefit & expected result Less manual transfer and clearer visibility of missing information. Clinical interpretation and escalation stay with your licensed team.

Included scope Sources, devices and refresh frequency require interface acceptance. This feature does not supply continuous clinical alarm surveillance.

What it means A named MANSOQ operations contact is accountable for following through on your agreed non-clinical work queues.

How it works Agree the queue, actions and escalation route. The owner reviews outstanding work, coordinates with your team and records progress within the included managed-hours allowance.

One example An agreed ICU documentation task is still incomplete. The owner follows up with the responsible team and records its status; your clinicians make the clinical decisions.

Your benefit & expected result Clearer responsibility and fewer hand-offs between contacts, with a visible record of follow-up.

Included scope The owner operates within the agreed service window and hours. Full outsourced billing, unlimited queue work and clinical staffing require their own scope.

Within the accepted scope, your team registers the patient, creates the agreed care plan, schedules visits, documents observations and medication information, and records follow-up and authorised family communication. Each visiting team can review the current plan and prior notes. The customer supplies the licensed clinicians and the clinical approval of that plan.

Premium and above add agreed recurring-visit automation and route or roster optimisation. Define visit frequency, locations, team availability and exceptions. For example, a rescheduled visit remains visible in the work queue so the dispatcher can coordinate the next action. Actual travel, staffing availability and clinical priorities still need human judgement.

Patient and family access follows agreed identity, consent and role permissions. Define who is authorised, what information they may see and who manages access changes. Example: an approved caregiver can receive the agreed visit update, while other records remain restricted. External messages and branded apps may require separately scoped services and provider usage.

The contracted workflow covers care plans, symptom and medication documentation, caregiver communication and family or bereavement-support records. It helps authorised teams keep the care context and follow-up together. The clinical organisation defines treatment, symptom management, escalation and family support delivery; the software does not prescribe care or replace licensed staff.

Connected monitoring workflows are optional and require an accepted device and interface scope. Agree what is measured, who reviews the information, its timing, clinical escalation and supplier costs. A patient record or video workflow alone is not continuous monitoring, and managed operational support does not supply a clinician to watch the feed.

The named owner follows agreed dispatch, visit-exception and documentation queues within the managed-hours allowance. The owner coordinates with your dispatcher or clinical team, records outstanding actions and reviews continuity and capacity monthly. For example, an unfinished visit note can be assigned back to its responsible team instead of being left in an unowned backlog.

The customer supplies the licensed clinical coverage and emergency or escalation pathway. Agree patient and caregiver instructions through your clinical governance and rehearse the escalation process. Messaging, reminders and non-clinical managed queues should not be treated as an emergency-response service.

Essential: 18%; Premium: 15%; Diamond: 10%; Enterprise: 4.5%–7.5%. These percentages apply to approved eligible cleared collections, additional to the package subscription. Enterprise needs an approved exact rate within the range and an accepted scope. Actual fees are calculated from reviewed financial evidence after agreed refunds and exclusions; estimated collections in the builder do not create an invoice.

Essential: SAR 1,990.00 per month, comprising SAR 990.00 software + SAR 1,000.00 managed services. Includes 50 active patients / month and one site.

Premium: SAR 3,990.00 per month, comprising SAR 1,790.00 software + SAR 2,200.00 managed services. Includes 150 active patients / month and one site.

Diamond: SAR 6,990.00 per month, comprising SAR 2,490.00 software + SAR 4,500.00 managed services. Includes 250 active patients / month and one site.

Enterprise: Price and actual operating scope are determined by the sales quotation.

All public amounts are before VAT. The setup and migration budget range is indicative; the final price follows the statement of work. Additions and third-party costs are separately scoped. An unapproved price is not a public offer.

Essential: Complete the care workflow. Visits, care plans, symptom / medication documentation, caregiver communication and family / bereavement support records.

Premium: Reduce repeat work and find exceptions sooner. Visits, care plans, symptom / medication documentation, caregiver communication and family / bereavement support records. Route and roster optimization, recurring visit automation, family updates and optional connected monitoring workflows.

Diamond: Give agreed operational queues an accountable owner. Visits, care plans, symptom / medication documentation, caregiver communication and family / bereavement support records. Route and roster optimization, recurring visit automation, family updates and optional connected monitoring workflows. Named owner for dispatch and visit exceptions, documentation follow-up and monthly continuity / capacity review. Use your own PostgreSQL database and private S3-compatible storage, including customer cloud, Spaces or server-hosted storage. Migrations, clinical files, reports and background jobs use the accepted customer destination; credentials, network, backups and recovery are commissioned before go-live.

Enterprise: Govern care and operations across the organization. Visits, care plans, symptom / medication documentation, caregiver communication and family / bereavement support records. Route and roster optimization, recurring visit automation, family updates and optional connected monitoring workflows. Named owner for dispatch and visit exceptions, documentation follow-up and monthly continuity / capacity review. Group governance, entity-specific permissions, consolidated reporting, agreed integrations and dedicated operating scope. Use your own PostgreSQL database and private S3-compatible storage, including customer cloud, Spaces or server-hosted storage. Migrations, clinical files, reports and background jobs use the accepted customer destination; credentials, network, backups and recovery are commissioned before go-live.

Higher tiers retain the contracted care foundation. Capacity, managed-hour and interface allowances are separate; the accepted proposal determines the live scope.

What it means One care record for home visits, the agreed care plan, symptom and medication notes, and authorised family communication.

How it works Your team schedules a visit, records what happened and updates the care plan. Family communication and follow-up are kept with the patient record, under the agreed access permissions.

One example After a home visit, a nurse records symptom observations and the clinician updates the care plan. The next visiting team can review both before attending.

Your benefit & expected result Better continuity between visits and a clear record of what the care team and family have agreed.

What it means Organise recurring visits and help dispatchers plan team schedules and travel routes.

How it works Set the clinician-approved visit frequency, team availability and service area. The workflow prepares recurring visits and routing information for your dispatcher to review and confirm.

One example A patient needs two visits each week. The recurring schedule creates those visits and the dispatcher groups nearby visits into an appropriate route.

Your benefit & expected result Less repeated scheduling and a clearer daily plan. Your team confirms clinical priority, staffing and the final route.

What it means A named MANSOQ operations contact is accountable for following through on your agreed non-clinical work queues.

How it works Agree the queue, actions and escalation route. The owner reviews outstanding work, coordinates with your team and records progress within the included managed-hours allowance.

One example A home visit needs rescheduling. The owner follows up with your dispatcher and tracks the agreed action until its operational status is clear.

Your benefit & expected result Clearer responsibility and fewer hand-offs between contacts, with a visible record of follow-up.

Included scope The owner operates within the agreed service window and hours. Full outsourced billing, unlimited queue work and clinical staffing require their own scope.

They cover agreed configuration, specialist review and operational queue work. For example, a specialist may review an agreed exception list, adjust an accepted workflow and document the next actions. Define the queue, allowed actions, access, owner and expected output before work starts. Managed hours are not clinician shifts or unlimited outsourcing.

The routine service terms record work in 15-minute increments. Preparation for a review counts as well as the review itself. Agree the task record and usage report so your organisation can understand what was done and what remains. Example: preparing an exception review and discussing its actions both use the agreed allowance.

The published routine service terms provide no rollover unless separately agreed. Plan priorities and review dates with the responsible team so the monthly allowance is used for useful work. If your workload is seasonal, ask for a written arrangement; do not assume unused hours create an unlimited future balance.

Routine terms call for notifications at 80% and 100% of the allowance and approval before extra work. Decide whether to reprioritise, add approved hours or change the service scope. Clinical and critical support responsibilities follow their own accepted arrangements; care-unit capacity and interface allowances do not increase just because extra hours are purchased.

The published routine window is Sunday to Thursday, 08:00–18:00 Arabia Standard Time, excluding agreed holidays. Agree scheduling, contacts and any special coverage in the proposal. This operational window is distinct from application availability, your clinical coverage and separately commissioned critical technical incident cover.

Product support addresses the accepted product and technical incidents. Managed operations are the agreed ongoing configuration, review and queue work. The routine package terms state that product defects and critical support do not consume the managed-hours allowance. Contact routes, severity, coverage and response commitments must be defined in the accepted support agreement.

The owner is accountable for follow-through on the agreed queues within the accepted hours, permissions and service window. Your team still supplies the required evidence, approvals and clinical decisions. Full outsourced billing or a larger operational team requires a separate scope. The benefit is clearer responsibility and recorded next actions for the work you have agreed.

It is a visible list of work needing attention, with an owner, reason, next action and status. Example: a visit is complete but billing documentation is missing. The responsible team receives a follow-up task and records progress. Automation helps identify the exception; it does not invent missing evidence or approve a payer decision.

Agree the measures in advance: capacity use, overdue work, repeated exceptions and any relevant care or revenue-cycle measures. The owner reviews the accepted data with your team and records priorities, actions, responsible people and approved capacity changes. Preparation uses managed hours. The useful result is an actionable follow-up plan, not a guaranteed improvement percentage.

The customer supplies licensed clinicians, treatment decisions, clinical escalation and medical governance. MANSOQ supplies the contracted technology and non-clinical operations. An automated task, dashboard or operations owner can support coordination but cannot substitute for your clinician approval, clinical protocol or staffing arrangement.

Clinics: Essential 2 hours/month; Premium 6 hours/month; Diamond 12 hours/month; Enterprise agreed with sales

Polyclinics: Essential 4 hours/month; Premium 12 hours/month; Diamond 24 hours/month; Enterprise agreed with sales

TeleICU: Essential 4 hours/month; Premium 12 hours/month; Diamond 24 hours/month; Enterprise agreed with sales

Home & Palliative Care: Essential 4 hours/month; Premium 12 hours/month; Diamond 24 hours/month; Enterprise agreed with sales

The allowance is for agreed non-clinical work, not staffing shifts. Review preparation counts; additional care units and sites do not increase hours.

RCM RaaS assigns the agreed non-clinical revenue queues to an accountable operating team: eligibility and authorisation follow-up, claim preparation and submission, rejected claims, denial follow-up and remittance reconciliation. Agree the supported payers, entities, volumes, service window and approvals. Your clinicians remain responsible for clinical evidence and decisions; your finance team retains approval of sensitive financial changes.

Yes. The approved collection fee is additional to the package’s software and managed-operations subscription. The proposal separates fixed subscription fees from collection-based fees. Define which work belongs to the package’s included hours and which belongs to the RaaS scope. Selecting RaaS requests the service; it does not authorise automatic charges or establish an accepted operating scope.

Actual billing uses eligible bank-cleared collections for the agreed period, less documented refunds and agreed exclusions or adjustments. It does not use the face value of submitted claims, unpaid invoices or a customer-entered planning estimate. Reconcile remittances and financial evidence with your finance sponsor, record the excluded amount and obtain independent fee review. The contract defines which entities, payers and receipts are eligible.

No. The annual software discount applies only to the eligible base software subscription. The collection fee is calculated separately for the agreed collection period using the approved contract rate. The builder’s RaaS estimate remains separate from the fixed monthly and annual subscription amounts; it is neither a prepaid collection fee nor a guaranteed invoice.

The service provides defined operational responsibility and transparent collection-based billing. Agree workload, staffing, coverage, queue ownership, approvals and performance reporting in the signed scope. Payer payment and denial outcomes depend on evidence and payer decisions. Customer clinicians supply care decisions and clinical documentation. A published fee percentage alone does not commission unrestricted volumes, staffing or 24/7 coverage.

It is an agreed connection exchanging specified data with a named external system, within the published plan allowance. Define the source, destination, format, mapping, timing, permissions, tests and maintenance responsibility. Example: an accepted admission feed updates the agreed patient or bed context. Building a bespoke connector and paying the supplier are separately scoped.

The accepted interface specification determines the count. A single supplier name does not automatically make all its feeds one interface, and one feed should not be split into arbitrary charges without a defined scope. Agree each data domain, direction, endpoint, acceptance test and maintenance obligation before approving the proposal.

The published service terms exclude applicable national foundation connectors from the standard maintained external-interface allowance. Required NPHIES and ZATCA workflows are included in every plan. Live transmission is activated after your organisation’s NPHIES and ZATCA credentials and external acceptance. Bespoke additions, external vendor work and charges are separately reviewed.

A named capability is not proof of an accepted production connection. Confirm the exact release, facility and payer scope, authorised credentials, onboarding, mappings and accepted tests. Eligibility, authorisation, claims and payer responses are separate workflow steps. Your team supplies the relevant source permissions and correct clinical and billing evidence.

Agree the applicable invoicing and coding scope, current licensed catalogues, service mapping, authorised credentials and production acceptance. National e-invoicing, insurance service mapping and any grouping requirements have distinct setup needs. Review the Saudi and implementation references with your responsible finance and technical teams; do not infer certification from a marketing name.

Discuss an add-to-existing-system model, a full migration or a phased transition. Define which system owns each record and how accepted data passes between them. Existing-system permissions, exports, vendor cooperation and tested mappings are needed. A FHIR clinical extract alone may not include schedules, claims, balances or attachments.

The accepted connection scope should define detection, ownership, retry or reconciliation rules, downtime work and escalation. Record failed or delayed exchanges so the responsible team can verify what reached the destination. Example: a delayed laboratory feed is investigated and reconciled rather than treated as a complete result transfer. Supplier incidents follow the agreed responsibility boundary.

Confirm the exact vendor, product and installed release against the accepted connection scope. A generic integration capability is not an already commissioned adapter for every model. Supply interface documentation and authorised access, agree the mapping and test cohort, and accept both successful and failed exchange scenarios before live use.

Clinics: Essential 0 interfaces; Premium 1 interfaces; Diamond 2 interfaces; Enterprise agreed with sales

Polyclinics: Essential 0 interfaces; Premium 2 interfaces; Diamond 4 interfaces; Enterprise agreed with sales

TeleICU: Essential device interfaces scoped in the proposal; Premium 2 interfaces; Diamond 4 interfaces; Enterprise agreed with sales

Home & Palliative Care: Essential 0 interfaces; Premium 1 interfaces; Diamond 3 interfaces; Enterprise agreed with sales

These are agreed standard external connections. Applicable national foundation connectors are separate. Each connection must be commissioned; vendor fees and bespoke build work are separately scoped.

Diamond and Enterprise offer this optional deployment choice. Your organisation provides an accepted dedicated PostgreSQL database and private S3-compatible file storage. Infrastructure, connection work and any migration are scoped separately. Essential and Premium do not include this deployment option in the published care-package scope.

Customer-owned storage is an option, not a mandatory purchase. Choose the accepted MANSOQ-managed deployment or propose your own destination, then confirm the hosting and recovery terms. Your own infrastructure can provide more direct control over location and access, but it also needs agreed administration, monitoring, backup and incident responsibilities.

The supported customer destination is a dedicated PostgreSQL database plus private S3-compatible object storage, such as AWS S3, DigitalOcean Spaces or MinIO on a customer server. A plain shared folder or an arbitrary database type is not interchangeable with that accepted interface. Confirm your region, connectivity, certificates, permissions and backup design before commissioning.

After the connection is accepted, the clinical runtime uses the approved customer database and private file destination. The scope includes native database migrations, clinical files, facility and report files, clinical imports, reports and background jobs that use that runtime. The selected destination is an operating deployment choice, not just a configuration label.

Provide the authorised destination and scoped service credentials, then accept network access, certificate validation, database and file operations, migration readiness, backups and recovery. Agree owners and incident contacts. A selected checkbox or submitted address does not establish a live accepted connection; commissioning verifies the destination before clinical use.

The clinical runtime does not automatically fall back to a MANSOQ database or bucket. An affected operation reports a connection or storage problem rather than silently placing clinical data elsewhere. Use the accepted downtime and escalation process, restore the destination and reconcile affected work. Agree recovery and clinical continuity responsibilities before launch.

Customer infrastructure and its connection or migration work are separately scoped. The agreement should name who pays the provider and who manages database maintenance, storage, capacity, certificates, networking, backups and monitoring. Owning the account alone does not transfer those operating responsibilities to MANSOQ or make the infrastructure charge part of the card price.

Treat the move as an agreed migration, not a live checkbox change. Inventory the database and files, prepare the new destination, map and reconcile records, rehearse cutover and recovery, and accept the final switch. Agree downtime, ownership and rollback so the move does not split the live clinical record between unapproved destinations.

State the required location in the proposal and data agreement. Confirm the agreed data domains, files, backups and external provider flows separately. Your own destination gives direct control over its location; it does not by itself confirm the location of every connected service. The accepted deployment and data terms should describe the complete boundary.

Package names and security features are not certification evidence. Review the actual release, controls, data agreement, deployment, supplier responsibilities and accepted tests with your organisation. Any certification or approval claim needs its own current evidence for the relevant scope. The proposal should identify required assurance documents rather than assume them from the tier.

A backup must be restorable and accepted for your deployment. A recovery-time objective describes the target time to restore service; a recovery-point objective describes how much recent data loss the agreed design aims to limit. Agree the targets, schedule, retention, owners and restore tests. The public cards do not promise a universal recovery time or zero data loss.

The data agreement must define the organisation’s rights and responsibilities, authorised processing, access, export, retention and deletion. Customer-owned infrastructure adds control over the accepted destination; it does not replace those terms. Ask for the agreed clinical and service-data retention boundaries before onboarding real records.

Agree the products, release, facilities, data boundary and responsibilities. Prepare account and foundation setup, product configuration and authorised imports. Accept interfaces, reconcile migration records and balances, train users, rehearse normal and failed workflows, and approve downtime, recovery and cutover. Then hand over monitoring and the accepted support arrangements.

The delivery plan depends on the source data, interfaces, sites, infrastructure, training and acceptance work. Sales and delivery agree milestones and owners after scoping those inputs. A card price does not promise a fixed launch date. A phased rollout can start with an agreed pilot site and expand after its readiness checks are accepted.

Provide the responsible project and clinical owners, facilities and roles, service and tariff catalogues, clinician schedules, authorised source-system extracts and interface information. If using your storage, also provide the agreed infrastructure and scoped service access. Keep real credentials out of public enquiries; use the agreed secure commissioning process.

The implementation guide provides templates, examples and field dictionaries for selected foundation and product data, including departments, users, roles, services, doctors, schedules, assets and stock. Validate field formats and references, preview errors, and reconcile accepted records before committing an import. Not every spreadsheet is a ready-to-load migration file.

Accept the data domains and mappings before transfer, preserve source identifiers, and reconcile records, financial balances, attachments and relationships separately. Use an agreed test cohort and investigate exceptions. A successful upload alone is not acceptance of a complete clinical and financial migration; the authorised owners sign off the agreed evidence.

A governed history archive can be considered as part of the transition scope. Agree which history must be active, which remains in an authorised archive and how users locate and access it. Preserve provenance and identifiers. The proposal must define retention, search or access needs and responsibility; an archive is not automatically a fully editable live patient record.

Agree user groups, workflows, trainers, materials and evidence that the responsible users can complete their accepted duties. Baseline onboarding and an agreed migration specification are part of the package foundation; delivery days, travel and on-site training are separately scoped. Training should include exceptions, access limits and downtime procedures as well as normal screens.

A commercial selection is not clinical go-live acceptance. Confirm the deployed release and accepted capabilities, roles, migration, interfaces, training, clinical governance and support. Rehearse downtime and escalation, then approve the launch evidence. Planned capabilities or uncommissioned connections must not be assumed operational merely because they appear in a proposal.

A staged implementation can reduce the amount of change your teams handle at once. Agree the pilot scope, data boundary, measures, acceptance gate and expansion plan. Example: accept the first branch’s access, migration and billing workflow before adding other branches. The schedule and cost of staged work are defined in the implementation proposal.

Cutover is the agreed switch from the old operating arrangement to the accepted new one. Rehearse the final data changes, reconciliation, permissions, downtime communications and recovery path before the date. A rollback plan defines how the authorised team responds if acceptance fails. This gives your organisation a clearer continuity decision at launch.

Clinics: Essential SAR 1,500.00–SAR 3,000.00; Premium SAR 2,500.00–SAR 5,000.00; Diamond SAR 4,000.00–SAR 8,000.00; Enterprise agreed with sales

Polyclinics: Essential SAR 5,000.00–SAR 10,000.00; Premium SAR 8,000.00–SAR 18,000.00; Diamond SAR 15,000.00–SAR 30,000.00; Enterprise agreed with sales

TeleICU: Essential SAR 10,000.00–SAR 20,000.00; Premium SAR 20,000.00–SAR 50,000.00; Diamond SAR 40,000.00–SAR 100,000.00; Enterprise agreed with sales

Home & Palliative Care: Essential SAR 3,000.00–SAR 6,000.00; Premium SAR 5,000.00–SAR 10,000.00; Diamond SAR 8,000.00–SAR 20,000.00; Enterprise agreed with sales

These ranges are before VAT and separate from the recurring total. The setup and migration budget range is indicative; the final price follows the statement of work.

The contracted care workflow and required companions form the package foundation: patient context, documentation, orders and medication, billing, secure access, audit, backup and applicable national workflows. Optional services such as AI assistance, branding, equipment, extra interfaces and full outsourced RCM are selected and scoped separately. Your signed composition states what is actually included.

A selection records your interest in the proposed scope. It does not commission a device, create an accepted integration, approve a supplier or finalise bespoke pricing. The team reviews compatibility, dependencies, responsibilities and usage, then quotes and accepts the service. Only the accepted deployment and entitlements determine what goes live.

Opt-in; clinician review, consent, intended-use and supplier review required.

An accepted documentation assistant can help prepare text for clinician review. Define intended use, consent, supplier handling and the human approval step; it does not replace clinical judgement or make every generated statement correct.

One example A clinician reviews and corrects an assisted draft before accepting the note.

Selection expresses a request; price, compatibility and acceptance are confirmed in the proposal.

Branding, distribution and app maintenance scoped separately.

An agreed branded patient or family experience can make the service easier to recognise and access. Define supported workflows, identity and access, distribution, maintenance and ownership in the separate scope.

One example Authorised users see the organisation’s agreed branding when accessing the accepted patient workflow.

Selection expresses a request; price, compatibility and acceptance are confirmed in the proposal.

Each connector has an acceptance specification and supplier cost.

Connect a needed external workflow beyond the standard allowance or connector scope. Agree source data, mapping, testing, maintenance, dependencies and vendor fees before development or commissioning.

One example A finance-system exchange is defined with its required fields and reconciliation tests.

Selection expresses a request; price, compatibility and acceptance are confirmed in the proposal.

Customer-owned devices or separately quoted hardware, carrier and vendor fees.

The right accepted equipment and connectivity support the selected workflow. Confirm compatibility, supply, installation, network capacity, maintenance and incident ownership rather than assuming the subscription includes hardware.

One example A remote ICU workflow uses customer-provided telepresence equipment accepted during setup.

Selection expresses a request; price, compatibility and acceptance are confirmed in the proposal.

Travel, delivery days and attendance agreed in advance.

Hands-on role training can help users practise the accepted workflow with an instructor present. Agree delivery days, attendance, travel, materials and competence checks before scheduling.

One example Reception and billing users rehearse registration, billing exceptions and the agreed downtime process.

Selection expresses a request; price, compatibility and acceptance are confirmed in the proposal.

Architecture, recovery objectives and infrastructure require an Enterprise proposal.

A separately designed deployment and continuity arrangement can address organisational architecture and recovery needs. It requires an Enterprise proposal defining application infrastructure, operations and recovery objectives. Diamond’s own-database option alone does not establish a dedicated deployment of every application component.

One example An Enterprise group agrees its application deployment, incident coverage and tested recovery targets.

Selection expresses a request; price, compatibility and acceptance are confirmed in the proposal.

The selected plan’s configured percentage of eligible cleared collections, additional to the package subscription. Enterprise requires an approved exact rate within its configured range and an accepted operating scope.

RCM RaaS takes the agreed operational responsibility for revenue worklists beyond the package’s managed-hours allowance. Its plan-specific percentage is additional to the subscription, on reviewed eligible cleared collections after agreed refunds and exclusions. Approve the queues, authority, evidence and reporting before activation. Enterprise needs an approved exact rate within the configured range.

One example A defined claims follow-up service reports agreed actions and collections under the accepted contract.

Selection expresses a request; price, compatibility and acceptance are confirmed in the proposal.

Third-party usage budget and consent agreed; no unlimited carrier charges.

Accepted external messaging and video can support reminders, consultations and authorised updates. Agree the supplier, patient consent, data flow, usage budget and charges. A software communication workflow does not include unlimited carrier or video-provider usage.

One example Agreed appointment reminders use an approved provider within the accepted message budget.

Selection expresses a request; price, compatibility and acceptance are confirmed in the proposal.

Select Build your tailored platform beside the package heading or in the page introduction. The packages hide and the builder appears on the same page. Choose a facility, care and services, review the plan and enter your request details. This keeps the package comparison and the detailed configuration as two clear views.

Use Back to packages. The builder hides and the packages return. Reopening the builder in the same page session preserves its current choices and step. Browser Back and Forward also follow the view switch. Changing the selected starting package intentionally loads that package’s scope, so review your capacity and additions after a new package choice.

The selected care product and starting package open in the builder so you can review their included services, capacity and optional additions. You can keep the package or tailor the proposed scope. Enterprise’s Request a sales call instead starts a proposal enquiry with its product and package context; it does not expose an unscoped public price.

Your facility identifies the care setting. Care & services selects the operating model, package or own plan, modules and required scale. Review your plan shows the proposed composition and commercial breakdown. Your details captures the request and consent. Review every step before submitting; a quote request is not a live clinical deployment.

A complete care system runs the accepted care and operations scope on MANSOQ. Adding to an existing system keeps the current system and connects the selected services through an accepted integration scope. Decide which system owns each record and what must be exchanged. The operating model can affect eligibility, interfaces, setup and final pricing.

Some services depend on shared patient identity, clinical documentation, orders, billing, access or other required companions. The builder includes those dependencies so the proposed workflow can be reviewed as a complete scope. An automatically included dependency is not an arbitrary extra; review the itemised scope and accepted operating model if it is unclear.

Where offered in the review flow, saving stores the proposed scope on the current browser or device so you can compare it later. It is not the same as submitting a request or reserving a price. Avoid putting patient data in a saved commercial scope. If the catalogue changes, review the updated scope and fees before relying on an older saved selection.

It should state the care products, operating model, release, included modules, capacity, sites, recurring software and managed fees, setup and migration, interfaces, optional work, tax and third-party charges. It should also define responsibilities, data terms, milestones, acceptance, support commitments, payment and contract conditions. Enterprise needs a sales-defined price for that complete scope.

A published duration is not activation. Trial eligibility and timing are confirmed with your team for the selected products and agreed evaluation scope before activation. The accepted activation and expiry dates govern the actual evaluation period.

The guided evaluation acceptance process uses a synthetic-data scenario. Agree the test users, workflow, support and success criteria. Real-patient operation needs its own accepted data, clinical, security and launch arrangements. A demo can show a workflow and help validate fit without treating a preview or unaccepted connection as clinical production.

The currently published care packages do not include an automatic trial period. You can request a demonstration and discuss a separately accepted evaluation with the team. Do not assume a universal 14-day trial from another plan or an own-plan configuration. Any evaluation depends on scope, readiness, policy, synthetic data and an accepted activation date.

Discuss the new capacity, interfaces, managed workload, sites and data requirements with sales. Agree the effective date, revised fees, entitlements and any migration or setup work before changing the live scope. The builder helps compare a proposed starting package; it does not amend an existing customer contract by itself.

Check whether the smaller plan can support your actual care capacity, maintained connections and operational work. Review any functions or deployment options that depend on Diamond or Enterprise. If you use customer-owned storage, do not assume a lower tier can keep that option; agree a supported deployment and migration plan. Contract timing and price changes follow the signed terms.

Treat the change as a reviewed operating-scope update. Confirm dependencies, affected users and records, interfaces, care continuity and commercial impact. Adding a department can require configuration, training and acceptance; removing one can require a record-access or archive plan. Agree the change before altering live workflows.

The signed quotation and agreement define those rules; the public package cards do not publish a universal notice period, refund entitlement or automatic renewal policy. Ask the team to specify term, notice, outstanding charges, annual prepayment treatment and any early-exit conditions before signing. Apply the accepted terms to your organisation’s case.

Backup and export are part of the package foundation, while the exit agreement defines the authorised export domains, format, files, timing, recipients and responsibilities. Agree clinical records, attachments, financial history and the agreed service records separately. Verify completeness and access before decommissioning the old service.

Owning the accepted infrastructure gives direct control over that destination. You still need an orderly application and data transition: supported exports, record and file relationships, identifiers, access, backup and any schema or interface mapping for the receiving system. Retention and service decommissioning follow the agreed data and exit terms.

Describe the business need, affected workflow, owner, expected output and acceptance test. The proposal or change record should state delivery effort, price, responsibilities, dependencies and effect on the release or support scope. Do not treat a verbal idea or an optional checkbox as an accepted custom development commitment.

Agree a baseline and a small set of workflow measures before rollout, such as overdue operational tasks, handoff completeness, repeat entry, documentation completion and capacity use. Use consistent definitions and compare periods after users are trained. Track actions from the monthly review. Distinguish observed improvement from an illustrative benefit or an unverified revenue claim.