Healthcare compliance intelligence for ISO and internal controls.

Audit preparation usually breaks down because evidence is scattered across teams, folders, tools, and email.

The compliance layer can help teams

• Map requirements to owners and evidence.
• Search policies, SOPs, controls, and prior audit material.
• Draft evidence summaries with source references.
• Identify missing or stale documentation.
• Prepare internal audit packs for review.

This is designed to reduce last-minute audit pressure and improve consistency.

For a system that tracks controls and evidence all year, see compliance management systems.

Staff should be able to ask controlled questions against approved internal material.

Example questions

• Which SOP applies to this incident type?
• What evidence is required for this control?
• Which policy owner should review this exception?
• What changed between the current policy and the previous version?
• Which open remediation tasks affect this department?

Answers can be limited by role and backed by source links.

Healthcare compliance is not only search. It is follow-through.

Lenouar can connect AI assistance to incident notes, CAPA drafts, evidence requests, remediation owners, and approval steps. The system can prepare the work, but humans remain responsible for decisions and sign-off.

Useful workflow outputs

• CAPA draft with source context.
• Remediation checklist.
• Control owner task list.
• Evidence request summary.
• Management reporting note.

Healthcare deployments can run on a private node, private cloud, rack server, or hybrid model.

The local layer can handle retrieval, embeddings, indexing, redaction, audit logging, and routine AI tasks. If external or UAE-hosted model routing is allowed, Lenouar can enforce routing rules so sensitive data is handled according to the agreed policy.

Most software a DoH-licensed provider buys was not written with ADHICS in mind, and the gap shows up at assessment rather than at purchase.

We build custom systems for Abu Dhabi healthcare providers with the controls designed in from the start, not retrofitted after a finding.

What that means in the build

• Access control that follows the source system permissions, so no user can reach a record they were never entitled to open.
• Per-query audit logging tied to an authenticated identity, retained long enough to reconstruct an incident.
• Encryption at rest and in transit covering the whole estate, including caches, indexes and log storage rather than only the primary database.
• Change control on every release, so any output can be traced to the version that produced it.
• An evidence trail designed around what an assessor asks for, validated before handover.

We map each control to the current Department of Health catalogue rather than to a third-party summary. Published summaries of ADHICS v2 disagree on how many control domains exist and what they are called, and an assessor checks the real references.

ADHICS v2 requires healthcare entities to run periodic information security awareness training for their people. It is one of the easiest controls to fail, because it needs evidence of delivery and not just intent.

We deliver that training, in English and Arabic, and hand you the attendance and completion records an assessor will ask to see.

Sessions are built around how your staff actually work

• Handling patient data in the systems your teams use every day.
• Phishing and social engineering aimed at clinical and administrative staff.
• Incident recognition and the 24-hour notification obligation.
• Safe use of AI tools, and why pasting patient records into a public chatbot is a reportable event.
• Role-specific sessions for clinicians, administrators, IT and management.

The Department of Health also runs its own Health Sector Cyber Learning Program. Our training is built to sit alongside it and cover the parts specific to your systems and your deployments, not to replace it.

The online course, in English and Arabic with a certificate for each participant, is described under corporate training.

Rostering a clinical workforce is a compliance activity, not just an operations one. ADHICS treats personnel as a control family, and the licence on the wall is only valid while the credential behind it is.

What we build

• Clinical rostering that respects skill mix, so a shift is never covered by someone not credentialed for it.
• Licence and credential expiry tracking for every clinician, with escalation before the date rather than after.
• Joiner, mover and leaver workflow, so access is granted on day one and removed the day someone leaves.
• Training and awareness completion tracked per person, which is what an assessor asks for.
• Leave, coverage and overtime visible against the roster, not reconstructed from messages.

The leaver case is the one that fails assessments. An account that stays live after someone has left is an access control finding, and it is almost always a process gap rather than a technical one.

ADHICS puts third-party security in scope, and a vendor handling patient data on your behalf is your exposure, not theirs.

What the system holds

• A register of every vendor and service that touches patient data, including the ones procured outside IT.
• What each one accesses, under which agreement, and for how long.
• Security assessment status per vendor, with the review date rather than a one-off questionnaire.
• Contract and data-processing terms attached to the vendor record, so the obligation is findable when it matters.
• Vendor access that expires, and is granted per engagement instead of permanently.

The common finding is a vendor with standing production access from a project that closed two years ago. We make that visible, then make it expire.

Vendor risk is one part of a wider cybersecurity risk assessment and risk register.

Asset management is the control everything else depends on. A control cannot attach to an asset nobody has registered.

What we track

• An asset register covering IT, clinical systems and connected medical devices, with a named owner and a classification each.
• Connected medical devices and IoMT, which version 2 of the standard reaches further into than version 1 did.
• Where each asset sits, what it holds, and who can reach it.
• Lifecycle: procurement, deployment, maintenance, and decommissioning with evidence of data removal.
• The assets that usually go unregistered: vector stores, prompt logs, review queues and reporting extracts.

That last line is where AI deployments fail an ADHICS assessment. The clinical logic gets scrutinised; the infrastructure around it was stood up during a pilot and never re-entered the governance process.

A practical first deployment should focus on one compliance domain.

Recommended starting points

1. Regulatory readiness evidence map.
2. Internal policy and SOP assistant.
3. Incident and CAPA drafting workflow.
4. ISO control evidence tracker.
5. Audit pack preparation for one department.

The pilot should measure answer quality, evidence quality, time saved, and staff adoption.