The QMS Engine: A Rule-Based Architecture for JAWDA KPI Computation Across Multi-Facility Health Systems

Cyscode Technology · Technical White Paper · 2026

Healthcare quality measurement has followed the same trajectory as clinical costing: what began as a periodic, manually compiled reporting obligation has become a continuous, auditable operational requirement, driven in the UAE context by the Department of Health Abu Dhabi's JAWDA (Healthcare Quality) program. This whitepaper examines the architecture of Cyscode Technology's QMS (Quality Management System) platform, a purpose-built engine for computing quality and safety indicators against JAWDA and equivalent standards. We focus on three defining architectural characteristics: a fully configurable, rule-based numerator/denominator computation engine that is indicator-agnostic by design; a dual-mode multi-facility data architecture supporting both per-facility instances and a centralized data lake; and a security and audit posture built to ADHICS requirements. Together, these characteristics position the QMS platform as infrastructure capable of computing not only today's published JAWDA KPI set, but any future indicator a health authority or health system defines.

1. Introduction: Why KPI Computation Is Harder Than It Looks

On the surface, a healthcare KPI looks like simple arithmetic: a numerator divided by a denominator, multiplied by a constant, benchmarked against a target. In practice, each of those three components hides significant complexity:

• The numerator is rarely "a count of events." It is a count of events that meet a precise, often multi-condition inclusion definition - a specific ICD code range, occurring within a specific time window relative to admission or a procedure, excluding cases that meet a defined exclusion criterion (e.g., a present-on-admission flag, a transfer-out before a threshold length of stay, a documented palliative-care exemption).
• The denominator is rarely "total patients." It is an eligible population defined by its own inclusion/exclusion logic - patient-days at risk, discharges within an age band, encounters of a specific type, excluding populations for whom the indicator does not clinically apply.
• The benchmark is rarely static. Many programs, JAWDA included, require risk adjustment, facility-type stratification, or peer-group benchmarking rather than a flat national target.

A platform that hard-codes this logic per indicator becomes a maintenance liability the moment a standards body - DOH Abu Dhabi, in JAWDA's case - revises a specification, retires an indicator, or introduces a new one. The QMS platform's core design decision is to treat every KPI as a configured rule set rather than a coded feature, which is the architectural property this whitepaper focuses on.

2. Platform Positioning

The QMS platform is a distinct product from Cyscode's CliniCost Engine, though the two share an architectural philosophy: both treat their domain (costing, quality) as a configurable rules layer sitting atop a common data ingestion and validation core, rather than as indicator-specific or country-specific code. Where CliniCost computes the financial cost of an episode of care, QMS computes the quality and safety performance of that same care - and the two are natural companions for a health system needing both cost and quality visibility from a shared operational dataset (encounters, diagnoses, procedures, length of stay, adverse events).

The platform is built around JAWDA - the Abu Dhabi Department of Health's healthcare quality reporting program - as its primary reference standard, but its architecture is explicitly indicator-agnostic: because numerator and denominator logic are user-defined rule configurations rather than hard-coded calculations, the same engine can compute any indicator a user defines, whether that is a published JAWDA measure, an internally defined quality metric, or an indicator drawn from another national or international framework.

3. The Numerator/Denominator Rule Engine

3.1 Core Design Principle: Indicators as Configuration, Not Code

The defining architectural claim of the QMS platform is that indicator logic is entirely rule-based and user-configurable. In practice, this means each KPI is defined as a structured rule object rather than a bespoke calculation routine, typically comprising:

• A numerator rule set, defining the inclusion criteria an event, encounter, or patient record must satisfy to be counted (e.g., diagnosis code ranges, procedure codes, event-type flags, temporal windows relative to an index event).
• A denominator rule set, defining the eligible population against which the numerator is measured (e.g., all discharges of a given encounter type within a period, all patient-days in a given unit, all patients meeting an age/condition criterion).
• Exclusion criteria, applied independently to numerator and denominator, capturing cases that should be removed from consideration despite otherwise matching inclusion logic (e.g., transfers, deaths within a defined window, documented comorbidity-driven exemptions, present-on-admission flags for conditions that would otherwise trigger inclusion).
• Risk adjustment parameters, where the raw numerator/denominator ratio is adjusted for case-mix or population risk factors before being compared against a benchmark, so that facilities serving higher-acuity populations are not unfairly penalized in cross-facility comparison.

This structure is expressed generically as:

Where the constant is indicator-specific (e.g., ×100 for a percentage-based indicator, ×1,000 for a rate per 1,000 patient-days, as is standard for indicators like central-line-associated bloodstream infection rates).

3.2 Why Configurability Is the Load-Bearing Feature

Because JAWDA - like most national quality programs - periodically revises its indicator specifications, retires measures, and introduces new ones, a platform that encodes indicator logic in application code requires a development cycle every time a standard changes. A platform that encodes indicator logic as configuration allows a quality/compliance team to update, retire, or introduce indicators without engineering involvement, provided the configuration interface exposes the full range of logic described above (inclusion codes, exclusion codes, temporal windows, risk adjustment factors).

This also means the platform is not structurally limited to JAWDA. Since the rule engine is defined generically - numerator logic, denominator logic, exclusions, risk adjustment, benchmark comparison - the same computation core can express indicators from other frameworks (e.g., AHRQ Patient Safety Indicators, CMS eCQMs, HEDIS-style measures, or purely internal quality metrics a health system wants to track that have no external reporting obligation at all).

3.3 Validation Considerations for the Rule Engine

A fully configurable rule engine is powerful but shifts risk from "does the code correctly implement indicator X" to "was indicator X correctly configured." This has a direct implication for quality assurance: the platform's validation layer should be capable of confirming not only that the engine computes ratios correctly given a rule set, but that a specific configured rule set correctly reproduces the published JAWDA specification for that indicator (correct code sets, correct exclusion logic, correct time windows). This is a configuration-validation concern rather than an engine defect concern, and is the natural focus area for any indicator-specific testing conducted against this platform.

3.4 Validated Accuracy: Rule Filtration and Computation Testing

This result is significant because the rule filtration layer is the highest-risk component in a configurable KPI platform: if a filter incorrectly includes or excludes records, the resulting KPI rate is wrong regardless of whether the arithmetic engine itself is correct. The clean validation across all rules confirms that the configuration-to-computation pathway - from rule definition through filtration to final rate calculation - is reliable end-to-end, not just at the arithmetic level.

4. Multi-Facility Data Architecture

4.1 The Aggregation Problem

Multi-facility KPI computation is architecturally harder than single-facility computation for a reason that is easy to overlook: KPIs do not aggregate the way raw counts do. A simple sum of numerators divided by a simple sum of denominators across facilities (a pooled rate) is not the same as an average of facility-level rates (an unweighted mean of rates), and neither is automatically the "correct" answer - the appropriate method depends on the indicator's statistical design and the reporting requirement. A platform that flattens facility-level data into a single pool before computing the rate will produce systematically different - and potentially misleading - results compared to one that computes facility-level rates first and then rolls them up.

The QMS platform's architecture explicitly separates these two stages:

1. Facility-specific denominator (and numerator) computation, performed independently at each facility using that facility's own eligible population and event data.
2. Roll-up aggregation, performed after facility-level computation, to produce health-system-level KPI results.

This ordering - compute per facility first, then aggregate - preserves the ability to report facility-level performance accurately (a facility is never diluted or distorted by another facility's population characteristics) while still enabling system-level and cross-facility benchmarking.

4.2 Facility-to-Facility Benchmarking

Because facility-level results are computed and preserved as first-class outputs (not discarded once rolled up), the platform supports facility-to-facility benchmarking directly - comparing performance across facilities within the same health system, potentially stratified by facility type, size, or case-mix, consistent with how JAWDA and comparable programs expect peer benchmarking to function rather than flat comparison across structurally different facility types.

4.3 Dual Data Architecture: Facility Instance vs. Centralized Data Lake

The platform supports two deployment/data models, and - notably - both simultaneously rather than as an either/or architectural choice:

Supporting both models within one platform is architecturally significant because it avoids forcing a health system into a single data topology. A system with facilities across different regulatory environments (each with its own data residency requirement, as is common across GCC and international multi-facility groups) can run facility-instance processing where residency requires it, while still feeding aggregated, de-identified or permitted results into a centralized data lake for system-level KPI reporting and benchmarking - reflecting the same per-jurisdiction data residency principle applied in the platform's broader security posture.

5. Alignment with JAWDA

JAWDA (an Arabic term broadly meaning "quality") is the Department of Health Abu Dhabi's healthcare quality and patient safety reporting program, requiring licensed healthcare facilities to report standardized indicators covering domains such as patient safety, clinical effectiveness, and patient experience. A platform intended to serve as a health system's JAWDA reporting infrastructure needs to support:

• The specific numerator/denominator/exclusion logic published for each JAWDA indicator, expressed through the configurable rule engine described in Section 3.
• Facility-level computation consistent with how DOH Abu Dhabi expects individual facilities to report, given JAWDA's facility-level reporting obligations.
• System-level roll-up for health systems operating multiple licensed facilities under JAWDA, without collapsing facility-level accountability.
• An audit trail sufficient to demonstrate, on inspection, how each reported indicator value was derived from source data - the same principle underlying CliniCost's cost audit trail, applied here to quality indicator computation.

Because the rule engine is not JAWDA-specific in its underlying logic - JAWDA is simply the configured rule set most commonly loaded - the platform is positioned to extend to future JAWDA indicator revisions, or to other quality frameworks entirely, without core re-engineering.

6. Security and Data Governance

The QMS platform is built to ADHICS (Abu Dhabi Healthcare Information and Cyber Security Standard) security requirements, consistent with its primary deployment context as JAWDA reporting infrastructure for Abu Dhabi-licensed facilities. Reported security architecture includes:

7. Conclusion

The QMS platform's central architectural bet - that quality indicators should be expressed as user-configurable rule sets rather than coded features - is well matched to the operating reality of a national quality program like JAWDA, where indicator specifications evolve and health systems increasingly want the flexibility to track internally meaningful metrics alongside externally mandated ones. Its multi-facility architecture, computing denominators and numerators at the facility level before rolling up to system-level reporting, correctly avoids the aggregation distortions that a naive pooled-data approach would introduce, while its dual facility-instance/centralized-data-lake model accommodates the differing data residency and system-independence needs of health systems operating across multiple facilities and, potentially, multiple regulatory jurisdictions. Combined with an ADHICS-aligned security posture - including configuration-level audit logging, which is the feature most specific to a rule-configurable KPI platform - and validated rule filtration accuracy across all tested indicators, the QMS platform is positioned as durable infrastructure for JAWDA compliance today and quality measurement more broadly as standards continue to evolve.