ADHICS and DHA Requirements for Healthcare Software Builds

ADHICS compliance and the Dubai Health Authority's health data rules shape how healthcare software must be built, not only how a clinic runs. For a product team, they translate into concrete requirements: who can see which records, what gets logged, where data is hosted and how the system connects to the emirate health information exchanges. This guide turns those standards into build decisions, and shows where expert review is essential.

What the standards cover and who they apply to

Healthcare software in the UAE sits under several layers of rules. Knowing which layer applies is the first job, because it decides hosting, integration and audit scope.

ADHICS in Abu Dhabi

The Abu Dhabi Healthcare Information and Cyber Security Standard, known as ADHICS, is issued by the Department of Health Abu Dhabi. It applies to entities in the emirate that generate, access, store, use, process or transmit health information. That scope names healthcare technology and service providers as well as facilities and payers, so a software vendor serving an Abu Dhabi provider should expect to be inside it. The standard was launched in 2019; secondary sources describe a later revision, so check the current version with the Department of Health.

DHA rules in Dubai

In Dubai, the Dubai Health Authority publishes policies and standards on health data, including data classification, information security, consent and access control, and health information sharing. NABIDH, Dubai's health information exchange, has its own set of policies on authentication, authorisation, audit and interoperability. DHA documents are updated over time, so always work from the latest version on the DHA website.

Federal law across the UAE

Federal Law No. 2 of 2019 on the use of information and communication technology in health fields applies across the country, supported by an implementing Cabinet Resolution. Legal commentary highlights its rule that health data relating to services in the UAE should be stored and processed inside the country, with exceptions only where the health authority allows them. The UAE Personal Data Protection Law, Federal Decree-Law No. 45 of 2021, carves out health data that is regulated by its own legislation, which is why the health specific rules carry most of the weight.

This is a summary for planning, not legal advice. Confirm which rules apply to your product, and how, with healthcare counsel and the relevant regulator.

Turning ADHICS compliance into build requirements

Standards describe controls; software teams need features, configurations and evidence. The table below maps common control areas to what a team actually builds. Use it to start the conversation with your compliance lead, not as a complete control list.

Start with a data map

Before any of these controls can be designed, the team needs a map of every place health data goes: the app, the API, the database, file storage, logs, backups, analytics, messaging and every third party service. Each entry should note the data class, the hosting location and the owner. This map becomes the basis for the classification register, the hosting decision and the supplier list, and it is usually the first document an auditor or the client's compliance lead asks to see.

Access control: design it with clinicians

Access control is where health information security meets daily work. Get it wrong one way and clinicians cannot do their jobs; get it wrong the other way and too many people see too much.

Practical rules for the build

• Roles from real job functions. NABIDH policy, for example, ties authorisation to a user's role. Map doctors, nurses, front desk, billing and administrators separately, and avoid a single "staff" role.
• Relationship based access. Where possible, limit access to patients the user is treating, with a clear route to request wider access.
• Break glass with accountability. Emergency access should be possible, require a reason and trigger review afterwards.
• Consent awareness. If the patient has restricted sharing, the interface must show it and enforce it.
• Regular access reviews. Build a report that lets managers confirm who still needs which access.

Hypothetical example: a Dubai outpatient group builds a patient app and a staff portal. The first design gives every receptionist access to full clinical notes. In a review with clinicians, the team splits the role so reception sees appointments and demographics only, and clinical notes require a clinician role plus an active appointment link.

Audit logs that stand up to review

Audit logging is easy to underbuild. A log that records only logins will not answer the question an investigator asks: who looked at this patient's record, when and why.

• Log every view, create, update, delete, print and export of health data, with user, time, patient and action.
• Log failed sign in attempts and permission denials; the NABIDH audit policy calls out failed logons specifically.
• Write logs to a separate store that application users cannot change.
• Keep logs for the retention period your compliance team sets, and make them searchable.
• Build a patient access report, so a privacy officer can answer a complaint quickly.

Treat logs as health data too. They often contain patient identifiers and need the same protection.

Hosting, data location and backups

Hosting is the decision that most often forces a redesign late in a project. Settle it during discovery.

Questions to answer early

• Will all health data, including backups, logs and analytics copies, stay in UAE hosting?
• Do any third party services, such as email, SMS, crash reporting, transcription or AI models, send health data outside the country?
• Has the health authority approved any exception you rely on, and is that approval documented?
• Does your cloud provider's UAE region meet the regulator's and the client's requirements?

Commentary on the federal law and on DHA policies does not always agree on cross border flows, which is another reason to get written advice before choosing an architecture. When unsure, design for in country processing and add exceptions only once approved.

Connecting to Malaffi and NABIDH

Malaffi is the Abu Dhabi health information exchange, a strategic initiative of the Department of Health. NABIDH plays the equivalent role in Dubai. If your software is a clinical system such as an electronic medical record, it may need to send data to, or receive data from, one of these exchanges.

What integration usually involves

• Following the exchange's published interoperability standards; NABIDH documentation, for example, refers to HL7 messaging standards.
• Mapping internal codes to required clinical coding standards.
• Matching patient identity reliably, usually based on Emirates ID and local identifiers.
• Passing conformance or onboarding testing with the exchange operator.
• Monitoring message failures and fixing them quickly, since gaps affect patient care.

Not every healthcare app needs an exchange connection. A wellness app or booking tool may not, while a clinic system probably will. Confirm the requirement with the facility's licensing team and the exchange operator.

Security in the development process

Health information security is also about how the software is made.

• Threat model the product at the design stage, focusing on patient data flows.
• Use code review, dependency scanning and secrets management for every release.
• Separate environments and never copy real patient data into test systems without approved controls.
• Commission independent penetration testing before go live and after major changes.
• Patch operating systems, frameworks and libraries on a fixed schedule.

AI features need extra care. Transcription, summarisation and chat tools often call external models. Check where those models run, what they retain and whether that fits the data location rules before adding them. Security teams weighing AI for threat detection can read AI in cybersecurity: strengths and limits.

Where expert review fits

A software team can build the controls, but it should not certify its own work. Plan for review at three points:

1. Discovery. Healthcare counsel and the client's compliance lead confirm which rules apply and any hosting constraints.
2. Design sign off. A security specialist reviews the architecture, access model and logging design.
3. Pre launch. Independent testing and an audit readiness check against the client's ADHICS or DHA obligations.

Budget for these reviews from the start. Fixing access control or hosting after launch costs far more than designing it in.

For budget planning, see what drives healthcare app cost. For other security topics, read realistic uses of blockchain in cybersecurity and how steganography hides data and how to detect it.

Build compliant healthcare software with Codeeo

Codeeo builds healthcare software in the UAE, from patient apps to staff portals and clinical business systems. Our custom software and mobile app development teams design access control, audit logging and hosting into the architecture from the first sprint, and work alongside your compliance advisers and security testers. See our healthcare industry work for more. With 200+ projects delivered and an office in Dubai, you can meet the team to map your requirements. Contact us to plan your build.