All articles

    Architecture note

    15 July 2026by Gustavo Teixeira Cuco3 min read

    Dubai Health-Data Architecture — Four Questions Beyond Healthcare

    Architecture context

    Architecture decision

    Trust and compliance

    Applied in

    Q-LIRILusiberiaStays
    Dubai Health-Data Architecture — Four Questions Beyond Healthcare

    I began with a broad question about a clinical AI product in the Middle East. The evidence forced a narrower answer: regulatory architecture is jurisdiction- and use-case-specific. Dubai's published health-data standards were the relevant source for this analysis, not a shorthand for the UAE or MENA.

    The DHA telehealth standard makes platform assessment part of the operating model and, for the information it covers, requires storage through a DESC-certified cloud service provider in the UAE. It also sets a minimum retention period of 25 years from the last encounter for telehealth-related information. Separate DHA access-control and NABIDH security standards require least-privilege access and audit trails that can be reviewed and protected from unauthorised alteration or deletion.

    Those obligations do not automatically apply to a property platform. The transferable part is the architecture of the questions, not the healthcare rules themselves.

    Both industries handle data whose use is constrained by purpose, role and jurisdiction. Saying that a record simply “belongs” to the person it describes hides the legal roles of data subject, controller and processor. The practical design problem is to make those roles, purposes and decision rights explicit.

    I found no basis for claiming that PropTech is converging on Dubai healthcare regulation. I did find four questions that should be answered in any system handling sensitive operational data.

    The architectural questions transfer; the regulatory answers do not.

    Location. Where may each data class be stored or processed under the rules that actually apply? In the Dubai telehealth case the answer shapes deployment topology. In a PT/ES property operation, the answer must instead be derived from the GDPR, contracts and the actual processing chain — not borrowed from healthcare.

    Lifecycle. What creates the record, how long must it remain available, and what authorises deletion? The 25-year Dubai telehealth requirement is a domain-specific answer. The reusable practice is to define and implement the lifecycle for every data class rather than accumulate data indefinitely.

    Authority. Who may see, change or disclose which record, and for what purpose? Least privilege is the principle. Role-based access and database-level policies are possible controls, but the control must follow the responsibility model rather than substitute for it.

    Evidence. What will prove who accessed or changed a record, when, and under which authority? The NABIDH standard supports reviewable audit trails and protection against unauthorised alteration or deletion. It does not justify my earlier, broader claim that every log must be signed, insert-only or written before commit.

    Together, location, lifecycle, authority and evidence form a more useful architecture than a generic “compliance” feature. Configuration can help express jurisdictional differences, but it cannot turn different legal regimes into one interchangeable ruleset.

    This is an architectural comparison, not a claim of regulatory equivalence, a clinical deployment, or compliance certification. The work on Q-LIRI exposed the questions; applying them to LusiberiaStays requires a separate legal basis and a separate control design.

    The professional evolution here is not that one sector supplied a ready-made playbook for another. It is that a broad analogy was narrowed into four explicit design decisions — and that unsupported certainty was removed before publication.

    Sources