ADEMSIS Data Requirements: What Your ePCR Must Capture and Submit

With roughly seven weeks left before the stated ADEMSIS deadline of 30 December 2026, the question for most Abu Dhabi ambulance providers is no longer whether the framework applies. It is how far the current electronic Patient Care Record (ePCR) sits from the Data Dictionary.

For many teams, that distance is larger than expected. Legacy forms were designed around narrative documentation, while ADEMSIS expects structured, coded and time-stamped data. The line between mandatory and recommended fields is often unclear, and an element that appears on a screen may not exist in a form that can be validated, counted or submitted.

This article explains what an ePCR must capture and submit for ADEMSIS compliance, how each data element behaves, where legacy forms typically fail, and how to run a gap analysis in the time remaining. For background on the circular and the deadline, see our guide to the ADEMSIS mandate and compliance deadline.

A note on method: we separate what DoH states from what we recommend. Statements about requirements come from DoH sources, and implementation suggestions are ours. Confirm every element-level detail against the original DoH documents before building a plan around it.

Quick Answer: What Does an ADEMSIS-Compliant ePCR Have to Capture?

An ADEMSIS-compliant ePCR must capture structured EMS data across agency, dispatch, response, crew, timestamps, patient, scene, clinical, injury, cardiac arrest, history, transport and outcome domains, as defined in the ADEMSIS Data Dictionary. Each element carries an obligation level that decides whether it must be completed and whether 'NOT' values are permitted. The ePCR must also support secure, auditable submission and the evidence needed for JAWDA EMS reporting.

1. What the ADEMSIS Data Requirements Cover

Scope

ADEMSIS is Abu Dhabi's standardised EMS data framework. It applies to licensed ambulance service providers operating in the Emirate, including their operational, clinical, quality, information-management and ePCR systems. DoH Circular No. 2026/110 asks providers to assess current systems, close gaps, train relevant personnel and achieve compliance through the ePCR within six months of issuance.

The purpose, as DoH describes it, is consistent reporting, service monitoring, performance measurement, clinical quality improvement and system-wide planning for prehospital care. That purpose explains the design. If one provider records 'arrival' when the vehicle stops and another when the crew reaches the patient, the two response times cannot be compared. Shared definitions remove that ambiguity.

What changes for the ePCR

Under this framework, the ePCR is no longer only a clinical record. It becomes the platform for compliance evidence, quality measurement, interoperability and operational intelligence, and it must capture structured data across the full journey from call to outcome.

Why NEMSIS alignment alone is not enough

Providers familiar with NEMSIS will recognise the identifier convention in the Data Dictionary, such as dAgency.01 for agency data and eResponse.01 for response data. Familiarity helps, but the dictionary also contains Abu Dhabi-specific requirements, including DoH licence numbers, Emirates ID, preferred language, and linkage to JAWDA indicators. A platform that maps to a general standard still needs checking element by element against ADEMSIS.

The authoritative source is the DoH ADEMSIS resource page. For the vendor side of the decision, our ePCR implementation and vendor selection guide covers selection criteria in detail.

2. How ADEMSIS Classifies Data Elements

This is where most of the confusion arises. The Data Dictionary does not treat every field alike. It specifies how each element must behave inside the ePCR.

The four obligation levels

Quick answer: can a mandatory field be closed with a 'NOT' value? No. A mandatory element must hold a real value. For a required element, the dictionary permits specified 'NOT' values, but only those. Confirm the exact wording in the Data Dictionary for each element.

'NOT' values and pertinent negatives

Three structured values stop a blank field from meaning several different things: Not Applicable, Not Recorded and Not Reporting. They are used only where the dictionary permits them.

Pertinent negatives work differently. They document a clinically meaningful omission. If aspirin is protocol-indicated for chest pain but was not given, the ePCR should record the aspirin element with a reason such as 'Medication Already Taken' or 'Refused', not leave an unexplained blank. A blank tells a reviewer nothing. A coded reason tells them what happened.

Recurrence: single-value and repeatable fields

Elements are either single-value (1:1) or repeatable (1:M). This matters more than it first appears. A legacy form with one box for 'medication given' cannot represent a patient who received three medications, and a free-text list cannot be counted or validated. Repeatable elements need their own structure.

These rules are what the search terms 'ADEMSIS data dictionary' and 'ADEMSIS data elements' point to in practice: not a list of fields, but a set of behaviours each field must exhibit.

3. The Data Domains Your ePCR Must Capture

The tables and examples below are representative, not exhaustive. The Data Dictionary determines which elements within each domain are mandatory, required, recommended or optional.

Agency and record identity

Every record must identify the licensed provider and uniquely identify the patient-care report: agency name, DoH licence number, Emirate, PCR number, and the software creator, name and version, together with the incident, response and CAD record identifiers where applicable.

Design requirement: every record should be traceable to a provider, vehicle, crew, incident, software version and patient encounter.

Dispatch and response

ADEMSIS expects structured dispatch and response data, not only a narrative note. That includes dispatch reason, whether EMD was performed and the determinant code, dispatch centre, priority and acuity, response mode, delay types, unit identifiers, GPS location and odometer readings. These fields support response-time analysis, deployment planning, delay root-cause review and defensible reporting. They depend on clean integration with dispatch, which is why computer-aided dispatch system features such as shared identifiers matter to ePCR design. Providers reviewing that integration can also consider computer-aided dispatch software for UAE operators.

Crew and critical timestamps

The ePCR must record crew member ID, clinical level and response role, plus a complete sequence of times: 999 call, dispatch notification, unit notification, acknowledgement, en route, scene arrival, patient contact, care transfer, departure, destination arrival, handover, back in service, cancellation and call completion, with MCI staging arrival where relevant.

Design requirement (our recommendation): timestamps should be system-generated where possible, synchronised to a reliable time source, locked after submission, and flagged when missing or invalid. JAWDA reporting expects auditable exclusion and missing-timestamp counts, so timestamp integrity is a reporting issue as much as a documentation one.

Patient demographics and payment

The record must carry enough identity, demographic and payment information to support care continuity, billing and reporting: patient ID, name, Emirates ID, gender, age, date of birth, contact details and preferred language, plus insurer, policy and guarantor details, and guardian or next-of-kin information where relevant. This is personal and financial data, so it needs encryption, role-based access and retention rules aligned with DoH privacy requirements.

Scene and situation

Structured scene context includes the first EMS unit on scene, other agencies, number of patients, incident location type, facility, GPS and address. Clinical presentation adds symptom onset, possible injury, complaint and its duration, anatomic location, primary and associated symptoms, provider impressions, initial acuity, last-known-well time and transfer justification. This is the foundation for triage review, epidemiology and demand planning.

Injury, cardiac arrest and history

For trauma and cardiac arrest, the ePCR must support condition-specific data, not free text alone. Trauma captures cause, mechanism, triage criteria, vehicle impact, safety equipment, airbag deployment and fall height. Cardiac arrest captures confirmation, etiology, witnessed status, prior AED use, CPR type, rhythm, ROSC, key timestamps, discontinuation reason and destination rhythm. History covers barriers to care and relevant patient background.

Design requirement: build workflows that appear only when triggered, such as a cardiac arrest module for a confirmed or suspected arrest.

Assessment, treatment, transport and outcome

The ePCR must document the full encounter: impressions, acuity, vital signs, medications, procedures, airway management, refusals, contraindications, allergies, pertinent negatives, destination, transport mode, handover and outcome. This applies across 999 responses, event standbys, MCIs and interfacility transports, and an ePCR record must be completed for every transported patient.

4. Why Legacy Forms Do Not Map

Most legacy ePCR gaps are structural. They are not fixed by moving a button.

Five recurring gap patterns

1. Narrative where a code is expected. Complaint, rhythm or outcome entered as text cannot be counted, filtered or compared.
2. One time field instead of a chain. A single 'arrival' time cannot support scene arrival, patient contact, care transfer and handover as separate events.
3. No 'NOT' value handling. Fields are either blank or filled, with no way to distinguish not applicable from not recorded.
4. No repeatable structure. Medications, procedures and vital sign sets collapse into one entry.
5. Broken keys. The CAD record ID does not match the ePCR incident number, so dispatch and care cannot be reconciled.

An illustrative scenario

The following is a hypothetical, not a client case. A provider's cardiac arrest record captures rhythm and return of spontaneous circulation as free text in the narrative. On paper the record looks complete. In a KPI extract, it cannot be counted, because the structured elements are empty. The crew did the work, but the data cannot show it. Fixing this means changing the data model, not retraining the crew.

Where the underlying application cannot support these structures, the realistic option is often targeted rework. Our legacy application modernization services address that situation, and the answer is frequently remediation of the data layer, not wholesale replacement.

5. Submission, Interoperability and Audit Requirements

Security and audit

The DoH standard for EMS and ambulance services expects entries to be time-stamped, audit logs to be retained (the source summary cites at least 25 years, or longer where UAE law requires, so confirm the period against the original), encryption and role-based access to be in place, and records to be available to DoH on request for quality assurance. Mandatory and required ADEMSIS elements and current JAWDA EMS indicators must be collected. Teams handling sensitive patient data may also find our overview of PDPL compliance and mobile app security in Abu Dhabi useful.

Data exchange

The same sources describe ePCR integration with hospital medical records, transmission of prearrival information, electronic transfer to the receiving hospital and Unified Medical Operations Command (UMOC), integration with ESTIJABAH, and upload to Malaffi. One caution: several of these integrations originate in earlier DoH guidance and standards, not necessarily in the 2026 circular. Confirm in the applicable DoH document which are in scope for your service lines, and do not treat each as a new ADEMSIS obligation without checking.

On the technical side, hospital handover and exchange connectivity depend on consistent identifiers and structured interfaces. Our guide to Malaffi and HL7/FHIR integration in UAE hospital information systems explains the hospital side. For implementation, see our HL7 and FHIR integration services in UAE and health information exchange integration for UAE providers. Note that HL7 and FHIR are widely used exchange standards, but the sources reviewed do not show that ADEMSIS mandates a particular one.

Accessible and submission-ready records

For DoH EMS data submission and audit, the practical test is simple: can you produce a complete, validated record, with its audit history, on request? If the answer depends on manual reconstruction, the ePCR is not yet submission-ready.

6. JAWDA Reporting Readiness

ADEMSIS links to performance measures in seven areas: airway management, out-of-hospital cardiac arrest, acute paediatric care, EMS response time, STEMI, acute stroke and trauma care. DoH publishes separate Pre-Hospital EMS JAWDA guidance (Version 2). Check how its indicator definitions relate to the data your ePCR captures.

For each KPI submission, a provider should be able to evidence:

• The raw numerator and denominator.
• The exclusion count by category, and the exclusion rate.
• The count of invalid or missing timestamps.
• The raw case volume.
• Auditable linkage between ePCR, dispatch, UMOC, device and operational data.

The implication is architectural. Treat KPI reporting as a data pipeline, not a monthly spreadsheet exercise. ePCR, CAD, dispatch, telematics and hospital data should reconcile to a single trusted case record. We cannot promise clinical improvement from better data, but without it, review is not possible.

7. Running an ADEMSIS Gap Analysis in the Time Left

A gap analysis is the most direct way to turn the mandate into bounded work. It is also where a delay costs the most, because every later phase depends on it.

Field-level mapping

For each ADEMSIS element, record: the element ID, its obligation level, its recurrence (1:1 or 1:M), the current ePCR field, how it is captured today (structured, free text or not at all), the validation in place, the gap type and an owner. Include paper and manual processes, since data collection outside the ePCR still has to reconcile.

Classifying the gaps

Sort every gap into one of four types: configuration (a setting or code list), development (new fields or logic), integration (an interface or identifier) and workflow or training. This classification decides effort, cost and sequence, and it stops a configuration task from being scoped as a rebuild.

A compressed plan (our recommendation)

The phases below overlap by design. A strictly sequential plan does not fit the remaining time.

What a good output looks like

The deliverables should be a gap register with owners, a prioritised remediation plan, and an evidence pack (configuration records, test results, training records and sample extracts) that can be shown if DoH requests it. Where the platform lacks the necessary structure, our team can assess EHR and EMR software development in UAE options alongside targeted remediation.

8. Evaluating Vendors: ADEMSIS-Ready or Standard-Only?

We found no approved-vendor list in the DoH sources reviewed, so be cautious of any claim of 'ADEMSIS certification'. A better approach is to ask specific questions.

The right answer is often configuration or targeted remediation, not replacement. Where development is needed, assess a healthcare software development partner in UAE on integration and testing experience, as well as on the platform itself.

9. Board-Level Readiness Indicators

A short executive dashboard keeps the programme visible:

• Mandatory-field and required-field completion rates.
• Share of records with a complete timestamp chain, and the invalid or missing timestamp rate.
• ePCR submission success rate and prearrival transmission success rate.
• Share of records available for a DoH quality assurance request.
• Audit-log retention compliance.

Request an ADEMSIS Gap Assessment

Readiness depends on accurate mapping, a correctly configured ePCR, tested interoperability, trained staff and clear governance. SISGAIN can assess your current ePCR against the ADEMSIS Data Dictionary at field level and deliver a gap register, a prioritised remediation plan and an evidence pack.

Request an ADEMSIS gap assessment

This article reflects DoH sources available at the time of writing. Confirm circular details, deadlines and element-level requirements against the original DoH documents.