Skip to main content
Healthcare

A record is run with precision not with estimation

We implement operating systems for health facilities: organised appointments and waiting lists, a procedure and documentation record, medicine and consumable stock by batch and expiry, insurance claims with the rejected ones and their reasons, and a readable cost per service — sized to your facility: a clinic needs appointments, a record and an invoice; a multi-specialty centre needs departments connected to stock and claims; a laboratory needs sample and result tracking; and a pharmacy needs batch, expiry and cold-chain records. What they share: what is not recorded in its time cannot be proven — not to the patient, not to the regulator, not to the insurer.

Request a facility assessmentSee the care settings
  • Four care settings, four scopes
  • No medical advice, no clinical decision support
  • We certify no compliance
  • Patient data used for nothing else
  • No outcome or waiting-time promises

Direct answers

The questions asked first

Do you provide medical advice or clinical decision support?

No, and we are not qualified to: we are a systems company and provide no diagnosis, no treatment recommendation, no triage and no clinical decision support of any kind, and we issue no opinion on the suitability of a treatment, a dose or the interpretation of a test result. What we build is the operation: the appointment, the procedure record, the stock, the claim, the cost and the documentation. Any clinical function remains the licensed physician’s decision and responsibility, and we do not build a system that suggests a clinical decision.

How do you handle patient data?

By three rules: the data stays in the facility’s systems and remains its property; we use it for nothing beyond the agreed scope of work; and we move it to no other tool or service without written approval — and we never share it with a third party. Permissions are built by role: who sees what, in which department, with a change log for every access or edit. We issue no compliance certificate: the facility is the data controller and carries the statutory responsibility, and our role is to implement and document the technical controls it requires.

Do you guarantee shorter waits or better outcomes?

No. Waiting is set by the number of physicians, rooms and emergencies, by season and by how appointments are distributed, and the clinical outcome is set by medicine, the patient and adherence — not by an administrative system. What we do commit to is that durations, missed appointments, reasons for failure and reasons for claim rejection are measured, and that where time is lost is known by a figure rather than an impression. Anyone promising a clinical outcome or a waiting-time reduction percentage in this sector is promising what they do not control.

What usually stops systems projects in health facilities?

Three things we see repeatedly, none of them technical: a scattered patient record across paper, an old system and spreadsheets, so what happened to the patient cannot be read in order; medicine and consumable stock without batch or expiry, so an expired item is discovered on use or a drug of unknown origin is dispensed; and claims rejected without recording the reason, so the same rejection repeats every month. That is why we start with unifying the record, with batches and expiry, and with the reason for rejection, before any promise of a report or an indicator.

Context

Why this sector is different in the Kingdom

Four operational realities impose strict requirements on the system — with no market figures and no targets.

Health transformation within Vision 2030

Healthcare is one of the strategic sectors in the Kingdom’s Vision 2030, with a general direction towards digital service and connected care pathways — context that explains the demand for documentation and measurement, while we publish no numbers or targets, because they are not ours and we cannot verify them.

Context, not a figure

Protection of health data

Health data is among the most sensitive by law, so the system is built on least privilege, an access log and a defined retention period — with the facility as the data controller responsible for compliance.

Least privilege and an access log

Insurance claims and repeated rejection

A rejected claim is not revenue, and repeated rejection for one reason points to a documentation or coding problem rather than to the insurer; recording the reason usually fixes more than reviewing every claim by hand.

The rejection reason recorded

Shift operation that does not stop

Work spans shifts, emergencies and weekends, so the system needs precise permissions by role and shift, and entry that does not break when the connection changes.

A permission per role and shift

We state the context because it explains the requirements — not to sell with it: we publish no market size, no growth rate, no programme target and no expected improvement percentage, and we issue no compliance certificates. The facility is the data controller and carries the statutory responsibility; we implement and document the controls.

Settings

Four care settings — and four different scopes

The same sector does not mean the same project. Read your setting first, then what fits you — and, plainly, what does not.

Clinic or small polyclinic

A few clinics · physicians and reception · appointments and invoices

What it suffers from
Appointments run on calls and a notebook, the record is on paper or on a physician’s device, and the invoice is written by hand, so bookings collide and what happened to the patient is lost in order.
What fits it
Organised appointments with a clear waiting list, one procedure record per patient in chronological order, an invoice built on the service delivered, role-based permissions, and a simple daily report the clinic manager reads.

What does not fit you: A loyalty programme or a patient app before the record is stable, running complex insurance claims before coding and appointments are clean, and loading granular permissions a small team cannot carry so they get abandoned.

Multi-specialty centre or hospital

Several departments · shifts · stock and claims

What it suffers from
Departments do not talk to each other: stock is managed per department, claims are rejected without a recorded reason, and cost per service is unreadable per department, so decisions are taken on the total.
What fits it
One patient record across departments, central stock with documented internal issue, claims managed with a recorded rejection reason that fixes coding, cost per service per department, and permissions by role and shift with an access log.

What does not fit you: Starting with executive dashboards before the record and stock are unified, switching all departments on in one day, and connecting medical devices before permissions and the record are stable.

Laboratory or imaging centre

Many orders and samples · results and reports · delivery to patient and physician

What it suffers from
Samples are tracked on paper or by phone: which order is delayed and at which stage is unknown, the result report is handed over with no delivery record, and the physician’s order is re-entered by hand.
What fits it
Tracking the order and sample by stage with the time at each, result delivery with a clear record of who received it and when, examination reporting built from recorded data, and permissions that hide results from the unauthorised.

What does not fit you: Promising analyser integration before inspecting its interface, relying on separate files per device instead of a central record, and sending results without a delivery or consent record.

Pharmacy or medical distribution

Items with batches and expiry · cold chain · dispensing and traceability

What it suffers from
An item is managed by quantity rather than batch: which batch to dispense first and what is nearing expiry are unknown, the fridge temperature log is on paper, and expired items are found on use.
What fits it
A batch and expiry per item with first-expired-first-out dispensing, a documented temperature log with exception records for out-of-range readings, traceability from receipt to dispensing, and alerts well before expiry.

What does not fit you: A customer loyalty programme before batch and expiry are tracked, relying on manual temperature logging with no exception record, and merging pharmacy stock into general stock so batch traceability is lost.

The bands here are indicative guidance rather than an official classification, and the criterion is the nature of the obligation: a clinic owes an appointment and a patient, a centre owes departments and claims, a laboratory owes a sample and a result, and a pharmacy owes a batch and an expiry. More than one can coexist in a facility, and each has a different starting point.

Symptoms

What usually shows up in health facilities

Eight recurring symptoms, each with a different root cause — which is why the treatment differs even when the complaint sounds the same.

A record split between paper and a system

Part of the patient history is on paper, part on a physician’s device and part in a spreadsheet, so what happened cannot be read in order or evidenced on review.

Cause: no single source

Missed appointments with no recorded reason

It is known that appointments are missed, but not whether the cause is a missing reminder, a long wait or a clash, so it repeats untreated.

Cause: reason not captured

Stock without batch or expiry

The quantity is known and the batch is not, so what to dispense first and what is nearing expiry are unknown, and expired stock is found on use.

Cause: quantity without batch

A rejected claim with no reason

Rejection is handled by manual review every month, the reason is not recorded, the same rejection repeats and revenue is delayed.

Cause: no rejection log

Consumables issued with no link to the service

Consumables are issued with no link to the procedure, so the real cost per service and per department is unknown and shortages appear when needed.

Cause: undocumented issue

A cold chain on paper

Temperature is logged by hand with no exception record, so whether it went out of range and which batches were affected are unknown.

Cause: logging without exceptions

Broad access for someone who needs less

A user signs in with access to more than they need, and with no access log evidencing who opened the record and when.

Cause: access without a role

A report requested and not found

Activity data or documentation is requested by a reviewer, and it is assembled by hand from several places and arrives late or incomplete.

Cause: unstructured documentation

Components

What we implement in the facility

Eight components built in order according to your setting; we do not implement all of them for a facility that does not need them all.

One unified procedure record

One record per patient gathering appointments, procedures and documents in chronological order, so what happened is read rather than recalled.

The base

Appointments and the waiting list

Scheduling per physician and room, reminders, a recorded reason for every missed appointment, and an organised waiting list instead of a call list.

An organised appointment

Medicine and consumable stock by batch

A batch and expiry per item, first-expired-first-out dispensing, traceability from receipt to issue, and alerts well before expiry.

A documented batch

Cold-chain and exception log

A temperature log with its timestamps, and an exception record for every out-of-range reading with the batches affected — the thing asked for on review.

An exception recorded

The invoice and the insurance claim

An invoice built on the service delivered, a claim with a submission and response log, and a written reason for every rejection that fixes coding instead of reviewing every claim.

A rejection with its reason

Consumables linked to the procedure

Issuing consumables tied to the procedure, so consumption per department and the real cost per service are readable rather than estimated.

Cost per service

Permissions and the access log

Permissions by role and shift on least privilege, an access log for every open or edit, and a defined retention period.

Least privilege

Operations and cost reporting

Reports decisions can be read from: appointments and procedures, consumption, claims and their rejection, and cost per service per department — with no promises about clinical outcomes.

A decision, not an archive

Method

The method: from unifying the record to operation

Eight stages, each with a published output, starting with unifying the record and with permissions rather than with configuration — because a system on a scattered record repeats the error faster.

  1. 01

    Assessment and setting

    A visit covering the facility, departments, reception and pharmacy, establishing the real setting, what runs on paper today, and where the largest operational or financial risk sits.

    Output: an assessment naming your setting
  2. 02

    Unifying the record and permissions

    Structuring the procedure record with one source for it, defining roles and their limits and the retention policy — before any configuration.

    Output: a unified record and approved roles
  3. 03

    Configuration and testing

    Configuring appointments, stock, invoicing and claims, and running a full cycle on anonymised data: appointment, procedure, issue, invoice, claim, response.

    Output: one complete tested cycle
  4. 04

    Training on the process

    Training each role on its own process: reception, nursing, pharmacy and accounting — with illustrated guides left with you.

    Output: a guide per role
  5. 05

    Phased go-live

    Going live on one department, clinic or shift first, then expanding — not switching the whole facility in a single day.

    Output: one department running, then expansion
  6. 06

    Batches and the cold chain

    Running batch, expiry and first-expired-first-out dispensing, and activating the temperature and exception logs before any review.

    Output: batch and expiry running
  7. 07

    Integration and reconciliation

    Connecting claims, e-invoicing and accounting, and laboratory devices where an interface exists after inspecting it, reconciling stock and closing a first period.

    Output: a documented close with its differences
  8. 08

    Periodic improvement

    A periodic review: where missed appointments recur, which rejection reason repeats, which item is nearing expiry, and which report nobody uses and should be dropped.

    Output: a periodic improvement report

The durations shown are planning ranges to help you build your schedule, not contractual commitments: the actual duration depends on the state of your current record, the complexity of your permissions and how quickly roles are approved, and can be affected by peak service load.

Measurement

What we measure in a health project

Indicators read from the operation itself, not promises about clinical outcomes.

Procedure-record completeness

The share of procedures recorded with who performed them, when and with their document, because a procedure without a record is provable neither on review nor in a claim.

Batch and expiry data completeness

The share of items registered with a batch and expiry, because that is the condition making first-expired-first-out dispensing and source traceability possible.

Claims accepted on first submission

The share, with rejection reasons recorded, because repeated rejection for one reason is a documentation or coding fault rather than an insurance one.

Medicine and consumable balance accuracy

The gap between physical count and system balance, because an untrusted balance corrupts cost, availability and purchasing together.

Access-log completeness

The share of record opens or edits logged with who performed them and when, because that is what is requested in any privacy review.

We announce no waiting-time reduction, no clinical outcome improvement, no occupancy percentage and no saving, and no figures about market size or programme targets. What we measure is procedure-record completeness, batch and expiry data completeness, the share of claims accepted on first submission with their rejection reasons, medicine and consumable balance accuracy, and access-log completeness — figures read from your system about your operation.

Integration

Where the system lives in your facility

We connect what you have instead of forcing its replacement, and we inspect every interface before promising it.

Odoo (stock, accounting and purchasing)

Medicine, consumables and the invoice on the same stock and accounting entries, so the work is not run in two systems.

The primary integration

Laboratory and analyser devices — where an interface exists

We read from a device only if it exports data through an available interface, and after inspecting it; we supply no devices and do not calibrate or interfere with calibration.

An explicit boundary

Insurance claims and e-invoicing

Connecting the claim and invoice to the available integration with a submission and response log and rejection reasons; we claim no accreditation or compliance we do not hold.

With a documented log

Reminders and appointments

Appointment reminders with sending limits and templates managed from settings, and the patient’s consent to the channel before sending.

With patient consent

Payer and partner systems

Connecting what can genuinely be connected among insurer or authority systems, after inspecting the interface; if none is available we say so and promise nothing.

After the interface check

Boundaries

Where our scope stops — written before you ask

In healthcare, systems get conflated with medical responsibility, licensing, compliance and devices, so the separation is written out plainly.

Medical advice and clinical decision support

We provide no diagnosis, treatment recommendation, triage or interpretation of a result, and build no system that suggests a clinical decision; the medical decision and its responsibility belong to the licensed physician.

Licensing, accreditation and compliance certificates

We are not a regulator or an accrediting body: we issue no health licences and no quality or compliance certificates and represent no authority. We implement and document controls; the facility is the data controller and carries the statutory responsibility.

Medical, laboratory and imaging devices

We supply no devices or medical consumables and do not install, calibrate or repair them; where an existing device exposes an interface we read from it after inspection.

Guaranteed outcomes or waiting-time reduction

We guarantee no clinical outcome, no waiting-time reduction percentage, no occupancy percentage and no saving; those are set by medicine, resources, season and behaviour rather than by an administrative system.

When what is needed falls outside our scope we say so in the assessment and refer a licensed specialist instead of accepting it and learning at your facility’s expense. That is written in the contract, not left to courtesy.

FAQ

Questions specific to health facilities

Direct answers on scope, data, responsibilities and what we do not guarantee.

Do you provide medical advice or clinical decision support?

No, and we are not qualified to: we are a systems company and provide no diagnosis, no treatment recommendation, no triage and no clinical decision support of any kind, and we issue no opinion on the suitability of a treatment, a dose or the interpretation of a test result. What we build is the operation: the appointment, the procedure record, the stock, the claim, the cost and the documentation. Any clinical function remains the licensed physician’s decision and responsibility, and we do not build a system that suggests a clinical decision.

How do you handle patient data?

By three rules: the data stays in the facility’s systems and remains its property; we use it for nothing beyond the agreed scope of work; and we move it to no other tool or service without written approval — and we never share it with a third party. Permissions are built by role: who sees what, in which department, with a change log for every access or edit. We issue no compliance certificate: the facility is the data controller and carries the statutory responsibility, and our role is to implement and document the technical controls it requires.

Do you guarantee shorter waits or better outcomes?

No. Waiting is set by the number of physicians, rooms and emergencies, by season and by how appointments are distributed, and the clinical outcome is set by medicine, the patient and adherence — not by an administrative system. What we do commit to is that durations, missed appointments, reasons for failure and reasons for claim rejection are measured, and that where time is lost is known by a figure rather than an impression. Anyone promising a clinical outcome or a waiting-time reduction percentage in this sector is promising what they do not control.

What usually stops systems projects in health facilities?

Three things we see repeatedly, none of them technical: a scattered patient record across paper, an old system and spreadsheets, so what happened to the patient cannot be read in order; medicine and consumable stock without batch or expiry, so an expired item is discovered on use or a drug of unknown origin is dispensed; and claims rejected without recording the reason, so the same rejection repeats every month. That is why we start with unifying the record, with batches and expiry, and with the reason for rejection, before any promise of a report or an indicator.

Does a small clinic need a full health system?

No. It needs three things done well: organised appointments with a recorded reason for every missed one, one unified procedure record per patient, and an invoice built on the service delivered. An advanced clinical record, complex insurance claims and multi-level granular permissions add setup and entry a small team cannot carry and get abandoned after months so everything returns to paper. An abandoned project is worse than a small successful one — and we say so at assessment stage even when it means a smaller scope for us.

How do you handle existing laboratory or imaging devices?

We inspect the interface first: does the device export data through a file, a protocol or an API? If yes we connect the reading or result to the central record; if not we say so plainly and promise no integration. We neither sell nor install nor calibrate devices and do not interfere with their calibration — that is medical-device specialist work, and separating responsibility helps you both at failure and at any regulatory review.

What is out of scope?

Medical advice, clinical decision support, diagnosis and triage; health licences and quality or compliance certificates; medical, laboratory and imaging devices and their supply, installation, calibration and maintenance; medical insurance and provider contracting; recruiting and clinical qualification of staff; running operations on your behalf (we run the system, not the clinical team); system and cloud licences (contracted in your name); and publishing market-size figures or national programme targets. We say all of this at assessment stage, before the contract.

Which setting are you?

Tell us your setting, the number of departments or clinics and users, and whether insurance claims are managed, and we will come back with an assessment naming your type, the fitting scope — and what does not fit you.

  • An assessment that names your setting
  • A written scope before any commitment
  • A plain statement of what is outside our scope
Request a proposal

Related topics

We are a systems implementation and integration company, not a healthcare provider, a regulator or an accrediting body: we provide no diagnosis, treatment recommendation, triage or clinical decision support, we issue no health licences and no compliance certificates, and we supply no medical, laboratory or imaging devices and connect them only through an interface that already exists and has been inspected. We guarantee no clinical outcome, no waiting-time reduction, no occupancy percentage and no saving, and we publish no figures about market size or national programme targets. Patient data stays in the facility’s systems, is used for nothing beyond the scope of work and is never shared; the facility is the data controller and carries the statutory responsibility. Durations shown are planning ranges, not commitments.