Health Authority Abu Dhabi

Health Authority Abu Dhabi Reliable Excellence in Healthcare

Encounter/ Claims Guidance

September 20

2007

PublHeal

© 20

isher th Authority

+9712 4493

+9712 4493

P.O.Box 56

www.haad

007

y Abu Dhabi

3333

3822

74 Abu Dha

.ae statistic

bi, United A

[email protected]

Health AutReliable Exce

rab Emirate

hority Abu Dha

ellence in Healthca

s

bi re


T a b l e o f C o n t e n t s | I

Contents 1 Introduction ................................................................................................................................................................................................ 1 1 Key definitions and principles ................................................................................................................................................................... 2

Claim ........................................................................................................................................................................................................................................... 2 Encounter .................................................................................................................................................................................................................................... 2 How claims and Encounters relate to records ............................................................................................................................................................................. 2 Record ......................................................................................................................................................................................................................................... 4 Activity ........................................................................................................................................................................................................................................ 4

2 What to submit to HAAD .......................................................................................................................................................................... 5 Record fields ............................................................................................................................................................................................................................... 5 Required fields ............................................................................................................................................................................................................................ 7 Which Encounters/Claims to include .......................................................................................................................................................................................... 9 How to Claim non‐paying non‐insured patients .......................................................................................................................................................................... 9 File format ................................................................................................................................................................................................................................. 10

3 When to submit data .............................................................................................................................................................................. 10 4 How to submit data ................................................................................................................................................................................ 10

Requirements ............................................................................................................................................................................................................................ 10 Login.......................................................................................................................................................................................................................................... 10 Support for submissions ............................................................................................................................................................................................................ 12

5 Communication standards ...................................................................................................................................................................... 13 6 Field Definitions ...................................................................................................................................................................................... 14

PatientFirstName ...................................................................................................................................................................................................................... 14 PatientContactNumber ............................................................................................................................................................................................................. 15 PatientBirthDate ....................................................................................................................................................................................................................... 16 PatientGender ........................................................................................................................................................................................................................... 17 PatientNationality ..................................................................................................................................................................................................................... 18 ClaimID ...................................................................................................................................................................................................................................... 19 ClaimIDPayer ............................................................................................................................................................................................................................. 20 ClaimIDInvoice .......................................................................................................................................................................................................................... 21 ClaimPatientID .......................................................................................................................................................................................................................... 22 ClaimPayerID ............................................................................................................................................................................................................................. 23 ClaimProviderID ........................................................................................................................................................................................................................ 24 ClaimGross ................................................................................................................................................................................................................................ 25 ClaimPatientShare ..................................................................................................................................................................................................................... 26 ClaimNet ................................................................................................................................................................................................................................... 27 ClaimPaymentAmount .............................................................................................................................................................................................................. 28 ClaimDateSubmitted ................................................................................................................................................................................................................. 29 ClaimDateReceived ................................................................................................................................................................................................................... 30 ClaimDateSettlement ................................................................................................................................................................................................................ 31 ClaimDateSettlementReceived.................................................................................................................................................................................................. 32 ClaimDateLastTransaction ......................................................................................................................................................................................................... 33 ClaimStatus ............................................................................................................................................................................................................................... 34 EncounterID .............................................................................................................................................................................................................................. 36 EncounterPatientID ................................................................................................................................................................................................................... 37 EncounterFacilityID ................................................................................................................................................................................................................... 38 EncounterStart .......................................................................................................................................................................................................................... 39 EncounterStartType .................................................................................................................................................................................................................. 40 EncounterType .......................................................................................................................................................................................................................... 41 EncounterSpecialty ................................................................................................................................................................................................................... 43 EncounterLocation .................................................................................................................................................................................................................... 44 EncounterEnd ............................................................................................................................................................................................................................ 45 EncounterEndType .................................................................................................................................................................................................................... 46 EncounterDiagnosisPrincipal ..................................................................................................................................................................................................... 47 EncounterDiagnosisSecondary .................................................................................................................................................................................................. 48 EncounterDiagnosisAdmitting ................................................................................................................................................................................................... 49 EncounterTransferSource ......................................................................................................................................................................................................... 50 EncounterTransferDestination .................................................................................................................................................................................................. 51 ActivityStart .............................................................................................................................................................................................................................. 52 ActivityType .............................................................................................................................................................................................................................. 53 ActivityCode .............................................................................................................................................................................................................................. 54 ActivityQuantity ........................................................................................................................................................................................................................ 55 ActivityNet ................................................................................................................................................................................................................................ 56 ActivityClinician ......................................................................................................................................................................................................................... 57


P a g e | 1

1 Introduction The Vision for the Health System in Abu Dhabi is to provide access to high quality health care services to all. To enable this, there is a need to monitor and report on activity and quality. This requires data to be collected from all entities providing heath care and health insurance within the health system of the Emirate of Abu Dhabi. The data collected should become a byproduct of the routine operations of providers and insurers, rather than creating an additional or separate burden of information collection. The aspiration is for the data standards to become self‐sustaining, because they add value for participating healthcare organizations. Standardising data will create a shared language for healthcare organizations, thus increasing consistency and transparency, facilitating discussion, and enabling for efficient electronic communications between healthcare organizations. This Guidance

• Defines key terms and principles • Sets out data definitions for all healthcare organizations in Abu Dhabi • Defines what data needs to be submitted to HAAD by all Hospitals, Primary Healthcare Centers, and

health insurers • Explains how data needs to be submitted to HAAD

The Guidance will develop as the health system matures. Your feedback on making this document clearer and easier to understand is welcome.


P a g e | 2

1 Key definitions and principles Claim A claim is an original request for payment for health services provided to a single patient. A Claim is typically recorded on a claims form and supported by one or multiple invoices. Claims are generally linked to patients that are covered by health insurance. For the purposes of this guidance, any invoices made out to non‐insured patients should also be considered as Claims.

Encounter An Encounter starts when a patient is first brought under the care of a responsible healthcare professional and ends when the patient stops being under the care of a responsible healthcare professional at the healthcare provider. Example| A patient has an accident at home and is driven by his family to the emergency room of a local hospital. After triage in the emergency room, the patient is admitted to a ward and has surgery a few hours later. After five days the patient is discharged home. The time period from being registered in the emergency room until discharge from the hospital is considered to be one Encounter. Example | A patient has an outpatient consultation during which she undergoes a lab test and receives a prescription, which she collects on her way out of the hospital. Four days later she has an x‐ray, and a further two days later a follow‐up appointment with a doctor. The patient has had three Encounters: {outpatient consultation + lab test + prescription}, {X‐ray}, {follow‐up appointment} Example| A patient has an outpatient consultation, during which he receives a lab test, does an x‐ray and receives a prescription, which he collects on the way out of the hospital. This patient has only one Encounter. {outpatient consultation + lab test + x‐ray + prescription}

How claims and Encounters relate to records A Claim often relates exactly to one Encounter. There are cases, however, where there are several claims related to one Encounter, and conversely when one Claim comprises several Encounters. Thus, to be able to analyze the data by Encounter or by Claim, every Claim‐Encounter combination should be treated as one record. This is shown conceptually in the illustration below, and elaborated in the following examples. Example 1 | A patient is admitted to a hospital for elective surgery and is assigned a hospital bed. The following items and activities define the hospital stay:

• Room and Board • Medical and/or surgical procedures • Clinical laboratory tests • Physical and occupational therapy services • Radiological services


P a g e | 3

• Hearing and vision services • Transportation services including ambulance • Medical supplies • Drugs

All the above activities provided as part of this Encounter would typically be aggregated in one Claim. If this Encounter was billed to two or more insurers, there would be multiple claims for the same Encounter.

Example 2 | A hospital patient visits a Radiology center, an independently owned laboratory outside the hospital, for a CAT scan. The laboratory visit would be considered one Encounter and comprises one Activity (CAT scan). The laboratory would typically bill the insurer for this Encounter as a separate Claim. Example 3 | A woman delivers a baby at a hospital. The hospital will bill the charges for its activities as one Claim, although there are two Encounters – one for the mother and one for the baby. All activities related to the mother Encounter and the baby Encounter will be billed as parts of the same Claim. Example 4 | In example 1, if the hospital bills insurers A and B for the Encounter, there would be separate Claims going to Insurer A and Insurer B for only one Encounter. For example, Insurer A provides primary insurance but does not cover high cost drugs, which are covered by Insurer B. Example 5| In example 3, the hospital would bill the mother‐related charges separately from the baby‐related charges, if the mother delivered a sick baby that needs to stay in the hospital after the mother was discharged. In this example, the mother’s Claim would comprise two Encounters with multiple activities, but the baby‐related charges would be claimed as a separate Claim.

Claim 1 Encounter 1

Claim 2 Encounter 2

Encounter 3

Claim 3 Encounter 4

Claim 4

Claim 1 Encounter 1

Claim 2 Encounter 2

Encounter 3

Claim 3 Encounter 4

Claim 4

Claim 2

Encounter 4


P a g e | 4

Record In many cases there is one Claim per Encounter. In certain cases, however, there are more Claims than Encounters or more Encounters than Claims. In such cases, the data sets must be split according to the illustration above:

• If there is one Claim for one Encounter the data should be submitted as one record • If there are multiple Claims for one Encounter, there should be as many records as there are Claims;

the Encounter information should be repeated for each record • If a Claim comprises multiple Encounters, there should be as many records as there are Encounters;

the Claims information should be repeated for each record

Note | If a sick newborn is charged as a separate Claim to the mother’s delivery, then the mother’s Encounter needs to be linked with that Claim, i.e., there needs to be a record with the newborn Claim, and the mother’s Encounter. Such linking allows an analysis, e.g., of whether the baby was born after the mother entered the provider as an emergency or as a result of a transfer. This is important information for quality purposes.

Activity A Claim may comprise one or many Claim items, often referred to as service items. Analogously, an Encounter may comprise one or more items, e.g., only a visit to the emergency room (one item), or for example, a visit to the emergency room followed by an admission, lab test, diagnostics and prescriptions (five items). An Activity is any Claim item or Encounter item.

• Generally a Claim item corresponds to an Encounter item, so every Claim item/Activity item is considered an Activity. This could be the case for example for a first outpatient consultation or a prescription, two separate activities.

• Some Encounter items however do not correspond with Claim items. For instance, individual surgical procedures are Encounter items, yet they may be claimed summarily as a DRG or flat fee (the Claim item). Both the surgical procedures as well as the DRG or flat fee are considered individual activities.

• Some Claim items don’t have corresponding Encounter items. In the example above, the DRG Claim item is a Claim item, but not an Encounter item.

Note | Activity information is not a mandatory requirement in the initial phases. To create additional transparency and allow organizations to plan, this is included here as a data standard. Each record should contain all non‐chargeable activities relating to the Encounter. Example | A patient has elective surgery and receives a tailored drug cocktail, which is not covered by his primary insurance. For this one Encounter the hospital makes two Claims: one to the primary insurance which is billed as a DRG, and one to the supplementary insurance for the expensive drugs. The two Claims need to be reported in two separate records. The Encounter information on each record should include information on the procedures performed, even if they are not charged. On the first Claim the only charge relates to the DRG; on the second , the only charge relates to the drugs. Each record should specify those chargeable activities that are related to the Claim.


P a g e | 5

Example | A patient has an outpatient consultation and receives a prescription. If the provider makes two separate Claims for this one Encounter. This would result in two records, one covering the consultation and one covering the prescription. The record claiming the consultation would only have the consultation Activity, while the record claiming for the prescription would only comprise the prescription Activity.

2 What to submit to HAAD Record fields Individual records must contain all fields in the order defined in the illustration on the next page. The blue fields are primarily administrative. They permit counting of money (Claims) and hospital Activity (Encounters). The red fields provide insight into “what is wrong with the patient”, i.e., the diagnosis. The grey fields – the majority – shed light on “what was done with the patient”. They are not mandatory at present and therefore do not necessarily need to be recorded. They are included here to provide direction and allow organizations to plan for the future. Individual fields are defined in detail in the chapter Field Definitions.


P a g e | 6

FieldName FieldName FieldName FieldName FieldName1 PatientFirstName 51 ActivityCode 101 ActivityNet 151 ActivityStart 201 Empty2 PatientContactNumber 52 ActivityUnits 102 ActivityClinician 152 ActivityType 202 Empty3 PatientBirthDate 53 ActivityNet 103 ActivityStart 153 ActivityCode 203 Empty4 PatientGender 54 ActivityClinician 104 ActivityType 154 ActivityUnits 204 Empty5 PatientNationality 55 ActivityStart 105 ActivityCode 155 ActivityNet 205 Empty6 ClaimID 56 ActivityType 106 ActivityUnits 156 ActivityClinician 206 Empty7 ClaimIDPayer 57 ActivityCode 107 ActivityNet 157 ActivityStart 207 Empty8 ClaimIDInvoice 58 ActivityUnits 108 ActivityClinician 158 ActivityType 208 Empty9 ClaimPatientID 59 ActivityNet 109 ActivityStart 159 ActivityCode 209 Empty

10 ClaimPayerID 60 ActivityClinician 110 ActivityType 160 ActivityUnits 210 Empty11 ClaimProviderID 61 ActivityStart 111 ActivityCode 161 ActivityNet 211 Empty12 ClaimGross 62 ActivityType 112 ActivityUnits 162 ActivityClinician 212 Empty13 ClaimPatientShare 63 ActivityCode 113 ActivityNet 163 ActivityStart 213 Empty14 ClaimNet 64 ActivityUnits 114 ActivityClinician 164 ActivityType 214 Empty15 ClaimPaymentAmount 65 ActivityNet 115 ActivityStart 165 ActivityCode 215 Empty16 ClaimDateSubmitted 66 ActivityClinician 116 ActivityType 166 ActivityUnits 216 Empty17 ClaimDateReceived 67 ActivityStart 117 ActivityCode 167 ActivityNet 217 Empty18 ClaimDateSettlement 68 ActivityType 118 ActivityUnits 168 ActivityClinician 218 Empty19 ClaimDateSettlementReceived 69 ActivityCode 119 ActivityNet 169 ActivityStart 219 Empty20 ClaimDateLastTransaction 70 ActivityUnits 120 ActivityClinician 170 ActivityType 220 Empty21 ClaimStatus 71 ActivityNet 121 ActivityStart 171 ActivityCode 221 Empty22 EncounterID 72 ActivityClinician 122 ActivityType 172 ActivityUnits 222 Empty23 EncounterPatientID 73 ActivityStart 123 ActivityCode 173 ActivityNet 223 Empty24 EncounterFacilityID 74 ActivityType 124 ActivityUnits 174 ActivityClinician 224 Empty25 EncounterStart 75 ActivityCode 125 ActivityNet 175 ActivityStart 225 Empty26 EncounterStartType 76 ActivityUnits 126 ActivityClinician 176 ActivityType 226 Empty27 EncounterType 77 ActivityNet 127 ActivityStart 177 ActivityCode 227 Empty28 EncounterLocation 78 ActivityClinician 128 ActivityType 178 ActivityUnits 228 Empty29 EncounterEnd 79 ActivityStart 129 ActivityCode 179 ActivityNet 229 Empty30 EncounterEndType 80 ActivityType 130 ActivityUnits 180 ActivityClinician 230 Empty31 EncounterDiagnosisPrincipal 81 ActivityCode 131 ActivityNet 181 ActivityStart 231 Empty32 EncounterDiagnosisSecondary 82 ActivityUnits 132 ActivityClinician 182 ActivityType 232 Empty33 EncounterDiagnosisSecondary 83 ActivityNet 133 ActivityStart 183 ActivityCode 233 Empty34 EncounterDiagnosisSecondary 84 ActivityClinician 134 ActivityType 184 ActivityUnits 234 Empty35 EncounterDiagnosisSecondary 85 ActivityStart 135 ActivityCode 185 ActivityNet 235 Empty36 EncounterDiagnosisSecondary 86 ActivityType 136 ActivityUnits 186 ActivityClinician 236 Empty37 EncounterDiagnosisSecondary 87 ActivityCode 137 ActivityNet 187 ActivityStart 237 Empty38 EncounterDiagnosisSecondary 88 ActivityUnits 138 ActivityClinician 188 ActivityType 238 Empty39 EncounterDiagnosisSecondary 89 ActivityNet 139 ActivityStart 189 ActivityCode 239 Empty40 EncounterDiagnosisAdmitting 90 ActivityClinician 140 ActivityType 190 ActivityUnits 240 Empty41 EncounterTransferSource 91 ActivityStart 141 ActivityCode 191 ActivityNet 241 Empty42 EncounterTransferDestination 92 ActivityType 142 ActivityUnits 192 ActivityClinician 242 Empty43 ActivityStart 93 ActivityCode 143 ActivityNet 193 ActivityStart 243 Empty44 ActivityType 94 ActivityUnits 144 ActivityClinician 194 ActivityType 244 Empty45 ActivityCode 95 ActivityNet 145 ActivityStart 195 ActivityCode 245 Empty46 ActivityUnits 96 ActivityClinician 146 ActivityType 196 ActivityUnits 246 Empty47 ActivityNet 97 ActivityStart 147 ActivityCode 197 ActivityNet 247 Empty48 ActivityClinician 98 ActivityType 148 ActivityUnits 198 ActivityClinician 248 Empty49 ActivityStart 99 ActivityCode 149 ActivityNet 199 Empty 249 Empty50 ActivityType 100 ActivityUnits 150 ActivityClinician 200 Empty 250 Empty

RequiredRequired as of November 15thNon‐Mandatory or not applicable


P a g e | 7

Required fields The following fields are generally available and required as part of the record of an Encounter that has ended and for which that Claim has been settled

Some patient data may be unavailable. For instance, some patients carry no form of identification and do not know their Date of Birth and/or for instance they may not have a contact number. Some fields may even have to remain empty, when the Encounter has ended and the Claim is settled because the information can not be procured. These situations should decrease over time. For example

Required fields*FieldName Insurer Provider

1 PatientFirstName R R2 PatientContactNumber ( R ) R3 PatientBirthDate R R4 PatientGender R R5 PatientNationality R R6 ClaimID ( R ) ( R )7 ClaimIDPayer R ( R )8 ClaimIDInvoice ( R ) R9 ClaimPatientID R R

10 ClaimPayerID R R11 ClaimProviderID R R12 ClaimGross R R13 ClaimPatientShare R R14 ClaimNet R R15 ClaimPaymentAmount R R16 ClaimDateSubmitted R ( R )17 ClaimDateReceived ( R ) R18 ClaimDateSettlement R ( R )19 ClaimDateSettlementReceived ( R ) R20 ClaimDateLastTransaction R R21 ClaimStatus R R22 EncounterID ( R ) R23 EncounterPatientID ( R ) R24 EncounterFacilityID R R25 EncounterStart ( R ) R26 EncounterStartType ( R ) R27 EncounterType ( R ) R28 EncounterLocation ( R ) R29 EncounterEnd ( R ) R30 EncounterEndType ( R ) R31 EncounterDiagnosisPrincipal ( R ) R32 EncounterDiagnosisSecondary ( R ) R

*Required, when encounter has ended, and claim has been settled( R ) Required if recorded by the Insurer or provider


P a g e | 8

• Insurers may not at present have a PatientContactNumber, because this is not always routinely recorded when insurance is taken out.

• Insurers may not at present have certain information, because they do not collect it from providers. This could include

o EncounterID o EncounterLocation o EncounterEndType o EncounterDiagnosisPrincipal o EncounterDiagnosisSecondary o EncounterDiagnosisAdmitting

Note | If insurers record a diagnosis related to a specific Claim, this should be recorded in EncounterDiagnosisPrincipal, EncounterDiagnosisSecondary, EncounterDiagnosisAdmitting, even if no further information about the Encounter is available to the insurer. Note | It is possible for insurers to reconstruct individual Encounter information with some degree of accuracy from invoice data

o For outpatient Claims, all invoice items that occurred on the same day at one facility can be assumed to constitute one Encounter

o For inpatient Claims, all invoice items that occurred between the admission date (EncounterStart) and the discharge data (EncounterEnd) can be considered one Encounter.

Note | It is of great importance to identify a unique reference number, which permits linking of Health Insurance data with Provider data. For different, insurance‐provider relationships, the nature of this unique reference number is different. Some insurers and providers use the

• Provider’s Claims reference number (ClaimID) • Insurer’s Claims reference number (ClaimIDPayer) • Provider’s invoice reference number (used to create ClaimIDInvoice)

To ensure that a unique reference can be created, all fields that are collected by Insurers and Providers need to be reported. This allows the data collection to create a unique reference without imposing on the health system, which unique reference system to use.

Some required fields may remain empty, because the event has not yet taken place. For example

• If the Claim has not yet been received by the Payer, the following fields will remain empty o ClaimDateReceived o ClaimDateSettlement o ClaimDateSettlementReceived o ClaimStatus (from the Payer’s perspective) o ClaimPaymentAmount

• If the Claim has not been submitted, in addition the following fields will remain empty o ClaimDateSubmitted o ClaimDateLastTransaction o ClaimNet o ClaimGross o ClaimStatus

• If the Encounter has not yet ended, the following fields will remain empty o EncounterEnd o EncounterEndType


P a g e | 9

Note | The fields for Activity – ActivityStart, ActivityType, ActivityCode, ActivityQuantity, ActivityNet, ActvityClinician – are repeated. This reflects the fact that a record may be associated with multiple activities.

Which Encounters/Claims to include Records need to be submitted for all Claims/Encounters that have been active during the month preceding the submission deadline. For example, the calendar month for submissions on November 15th is October. An Encounter/Claim was active during a calendar month, if any of the following fall within the calendar month:

• EncounterStart • EncounterEnd • ClaimDateSubmitted • ClaimDateReceived • ClaimDateLastTransaction

An Encounter/Claim is also considered active, if:

• EncounterStart is before the Calendar month, but EncounterEnd has not yet occurred. This ensures long‐stay patients that have not yet been discharged are included.

How to Claim non‐paying non‐insured patients Patients who receive care at a facility, yet are neither insured nor SelfPayers, need to be recorded as Claims in the following way:

• ClaimPayerID should be ProFormaPayer • ClaimGross should be equivalent to what ClaimGross would have been if the patient had been

insured using Daman’s International Plan • ClaimPatientShare should be treated as per the standard definition • ClaimNet should be empty • ClaimDateSubmitted should be the date at which the Claim was recorded in the system • ClaimDateReceived should be empty • ClaimDateLastTransaction should be empty • ClaimStatus should be ProviderSettled • ClaimPaymentAmount should be empty

Example | Nationals currently receive free treatment in public facilities. They should be considered as non‐paying non‐insured patients. Note | The main purpose of this convention is to gain transparency on the pro Forma Claims that might be expected, if all Nationals were insured. It is possible that it turns out that for certain insured patients, the Encounter is not or only partially covered, and they cannot pay. In this case the ProFormaPayer is only known after the Claim has been rejected by the payer.


P a g e | 10

File format The file format to be used for submission is a comma separated values file, (*.csv). This is a standard file format which can be created with MS Excel. CSV files have a fixed number of fields per record. It is thus important to include all fields for all records, even if they are empty. Example | If the record fields 1,3 and 6 have values and fields 2, 4,5,7‐9 are empty,

• the record should read “Field 1,,Field 3,,,Field 6,,,” • and not “Field 1,Field 3, Field 6”

Note | In the medium term it is likely that uploads will be required by the Health Authority in xml file format. This format is more flexible, but is also more complex.

3 When to submit data Submissions are to be made by the 15th of every month for the preceding month.

4 How to submit data Requirements The following infrastructure is required for data submissions to HAAD

• Data file(s) in *.csv file format with all required records, in the format specified in the preceding chapter

• Computer with internet access • User ID & Password – for Insurers, this is the same user ID and password as used to upload member

Data; for healthcare providers the user ID and password are the same as the ones needed to log on to the HAAD website for licensing purposes.

Login • Open the site www.haad.ae/DataUpload. The screen below should appear


P a g e | 11

• Enter your User ID and your password, and then click the Login button. The screen below should appear

Note | To practice using the site, log in with the user ID “test” and the password “test”. Any uploads made using this log in will be deleted periodically, and do not constitute an upload for a particular organization.

• Click the Upload Encounters/Claims button. The screen below should appear


P a g e | 12

• Click the Browse button on the screen and select the file you would like to upload. Once the desired file is selected, click Save.

• After a successful upload you will be informed, that the file has been uploaded. Start from the beginning if you need to upload more files.

Note | Large files may take a while to upload, during which time there is no feedback. In some cases computers may time‐out if there is no feedback. In this case, the time‐out period needs to be increased to enable a download. Note | The network is generally slowest during HAAD’s working hours. It may be faster to upload outside of office hours. As several dozen organizations need to submit data by the same deadline, uploading may be faster some days before the deadline.

Support for submissions Downloads Several documents are available for download on www.haad.ae/DataUpload (login “test”; password “test”), to make submissions easier

• this submission guidance • a sample upload file • a regularly updated list of attributes, including a reference list of Nationalities and Facility IDs

FAQs There is a “Frequently Asked Questions” section on www.haad.ae/DataUpload, where users can inquire about the data sets and submission process. The most common questions will be posted for common reference.


P a g e | 13

5 Communication standards Electronic transfer of healthcare information between healthcare organizations should be consistent with HL‐7 version 3. Any data definitions used must be interoperable with the fields defined here.


P a g e | 14

6 Field Definitions PatientFirstName Definition The patient’s first name, as spelled in the passport Note | To protect patient confidentiality, HAAD will only store an encrypted version of the field.

Field type Char(‐)

Restrictions None


P a g e | 15

PatientContactNumber Definition This is the telephone contact number provided by the patient. If multiple numbers are available, the mobile phone number should be used. If multiple mobile phone numbers are provided, it should be the first mentioned number, which is personal to the patient. Note | To protect patient confidentiality, HAAD will only store an encrypted version of PatientContactNumber.

Field type Char

Restrictions None


P a g e | 16

PatientBirthDate Definition The date on which a person was born or is officially deemed to have been born. In cases, where despite best efforts PatientBirthDate is not known, but the age is known; then the birth date should be assumed to be on the 1st of January of the current year, minus the age of the patient Example | A patient arrives on January 8th 2008 and Claims he is 64 years old, but does not know his date of birth. The PatientBirthDate should be assumed to be 01/01/1944.

Field type Small Date Format: DD/MM/YYYY

Restrictions The PatientBirthDate cannot be a future date The PatientBirthDate cannot be less than 01/01/1900


P a g e | 17

PatientGender Definition The patient’s gender

Field type Integer

Restrictions Only values allowed are 1 = male 0 = female


P a g e | 18

PatientNationality Definition The current nationality of the patient, as defined by the passport

Field type Char (‐);

Restrictions Only values from the reference list of nationalities are allowed. The latest List of Nationalities can be downloaded from www.haad.ae/DataUpload under Download/Attributes.


P a g e | 19

ClaimID Definition The unique number assigned by the health provider to identify the Claim. This is also known as the provider’s Claims reference number. It will be unique for each Claim. If the patient is not insured and pays out of pocket, this will be the external invoice reference number.

Field type Char (‐)

Restrictions None


P a g e | 20

ClaimIDPayer Definition The unique number assigned by an insurer to identify the Claim. It helps the provider and payer to locate the Claim. For non‐insured patients this field is empty.


Restrictions None


P a g e | 21

ClaimIDInvoice Definition The concatenation of all external provider invoice reference numbers, sorted alphabetically and separated by “@”. Rationale | In some insurer‐provider relationships, the provider does not record the insurer’s Claims number (ClaimIDPayer) and the insurer does not record the provider’s Claim number either (ClaimID). Financial transactions are instead communicated using the provider’s invoice number. The only way to reconcile payments at the level of a Claim is to define a reference number ClaimIDInvoice by concatenating each of the provider external reference numbers on the invoices relating to the Claim. This creates a unique key for the Claim, which can be created independently by the provider as well as the insurer. It can thus be used to uniquely identify a Claim. Example | A provider submits a Claim to an insurer. The Claim has three invoices H00‐1‐op‐017, H00‐1‐med‐023, H00‐2‐sur‐017. ClaimIDInvoice is “H00‐1‐med‐023@H00‐1‐op‐017@H00‐2‐sur‐017” Example | A patient goes to a hospital, receives an invoice for his treatment, and pays out pocket. The invoice number is H23‐07‐09‐11‐0124. ClaimIDInvoice is “H23‐07‐09‐11‐0124” Example | A provider submits a Claim to an insurer. The Claim has only one invoice H001‐1‐op‐984. ClaimIDInvoice is “H001‐1‐op‐984”


Restrictions None


P a g e | 22

ClaimPatientID Definition The patient’s insurance member number, if the patient is claiming insurance. Otherwise, this field should be left empty


Restrictions Needs to be non‐empty if the ClaimPayerID is neither “SelfPay” nor “ProFormaPayer”


P a g e | 23

ClaimPayerID Definition If the patient is claiming insurance cover, this is HAAD’s insurance license number If the patient is claiming insurance from an insurance not licensed by HAAD, this should be “@” followed by the name of the Insurance If the patient is paying directly for services provided, this should be “SelfPay” If the patient neither claims insurance nor pays directly for services provided, this should be “ProFormaPayer” Example | H018 Example | @Cigna Medical Example | SelfPay Example | ProFormaPayer


Restrictions Any values are allowed if the field starts with “@” If the field does not start with “@” only SelfPay, ProFormaPayer and valid HAAD insurance license numbers are permitted. Some of the fields – PatientNationality, EncounterFacilityID, ClaimPayerID and EncounterDiagnosisPrincipal have a large number of sometimes changing attributes. The latest version of these attributes can be downloaded from www.haad.ae/DataUpload. See “How to submit data to HAAD” for further details.


P a g e | 24

ClaimProviderID Definition ClaimProviderID is the HAAD license number of the provider claiming from the Payer. This can be a facility or a clinician. If the provider has no HAAD license number, the provider should be “@” followed by the name of the provider.

Note | ClaimProviderID is sometimes also known as the billing provider. In general, the facility that hosted the Encounter is also the one that claims from the payer. In these cases, ClaimProviderID is the same as EncounterFacilityID. However, under some circumstances, it is a different party that claims, e.g., a clinician or a different facility. Example | A hospital group has multiple licensed facilities. The hospital group centralizes billing and claims on the main site. In this case, an Encounter that occurred in a satellite facility (EncounterFacilityID = SatelliteSite) would be billed by the main site, i.e., ClaimProviderID = MainSite) Field type Char(‐)

Restrictions Any HAAD license number for facilities or clinicians is permitted Otherwise, any values are allowed if the field starts with “@” The latest version of these attributes can be downloaded from www.haad.ae/DataUpload. See “How to submit data to HAAD” for further details.


P a g e | 25

ClaimGross Definition The total AED amount of the charges included on the Claim. ClaimGross includes any patient financial responsibility for the Claim, such as co‐pays and deductibles, as well as charges made to other insurers for the Encounter(s) covered by the Claim. The prices on which ClaimGross are based should reflect the general agreement between the payer and provider for the Claim items for insuree. Example | A patient visits a clinic for a hip operation. The published list price is AED 8000. However, the insurer has negotiated with the provider a general discount of 10% on the published list price. ClaimGross is AED 7200. Example | A patient visits a clinic for a routine physical exam which costs AED 2000.The patient pays a co‐pay of AED 250. ClaimGross is AED 2000. Example | A patient visits a clinic for a physical exam (AED 500) and an expensive diagnostic test (AED 1500) in one Encounter. The patient pays a co‐pay of AED 250 and claims the diagnostic test from a supplementary insurance, because the primary insurance does not cover this diagnostic test. ClaimGross is AED 2000. Note | If the claimed amount is not in AED, then value should be converted to AED on the date of ClaimDateSubmission

Field type Float

Restrictions Non‐negative and greater than or equal to ClaimPatientShare + ClaimNet


P a g e | 26

ClaimPatientShare Definition Any fee insurees must pay for their use of specific medical services covered by their Insurance plan. This includes payments made for co‐pays and deductibles. Example 1 | A patient visits a laboratory for an CT scan. ClaimGross is AED 1000. The total charges for the service are AED 1000 (ClaimGross is AED 1000). The Patient pays a co‐pay of AED 200 for this service. ClaimPatientShare is AED 200. Example 2 | A patient visits a laboratory for an X‐ray. The total charges of the service are AED 1000. The Patient’s annual deductible is AED 500 under her insurance policy terms. In addition, the patient co‐pay for this service is AED 200. ClaimPatientShare is AED 700 (AED 500 + AED 200).

Field type Float

Restrictions Needs to be between 0 and ClaimGross


P a g e | 27

ClaimNet Definition The net charges included on the Claim. This is the amount the provider is expected to be paid. Example | A patient is admitted to the hospital for elective surgery. The surgery is billed on one Claim, and ClaimGross is AED 5000. The patient pays a co‐pay of AED 400 (ClaimPatientShare is 400). The hospital charges the payer for the remaining AED 4600. ClaimNet is 4600.

Field type Float

Restrictions Non‐negative


P a g e | 28

ClaimPaymentAmount Definition The amount paid by the payer towards the provider’s Claim.

Example | A payer received a Claim with a net amount of AED 4600 (ClaimNet AED is 4600). The payer decides to make deductions of AED 600, and pays the remaining amount. ClaimPaymentAmount is 4000. Field type Float



P a g e | 29

ClaimDateSubmitted Definition The date a Claim was submitted by the billing healthcare provider.

Field type Small Date. Format: DD/MM/YYYY

Restrictions ClaimDateSubmitted cannot be a future date ClaimDateSubmitted needs to be after EncounterStart


P a g e | 30

ClaimDateReceived Definition The date a Claim is received by the insurer


Restrictions ClaimDateReceived cannot be a future date ClaimDateReceived needs to be on or after ClaimDateSubmitted


P a g e | 31

ClaimDateSettlement Definition The date the payer settles the Claim. In general this will be the date that payment is made. If Payment is made in several steps, the latest date should be used. If the value of the Claim agreed by the Payer is 0, then settlement does not entail payment.


Restrictions ClaimDateSettled needs to be after ClaimDateReceived


P a g e | 32

ClaimDateSettlementReceived Definition The date the payee receives payment of the Claim.

• If settlement is made in several steps, the latest date of receipt should be used. • If the settlement value is 0, then this is the date of notification of settlement • If the provider has designated an intermediary, e.g., another provider or organization to receive

payment, it is the date that designated organization receives payment.


Restrictions Needs to be between ClaimDateSettled and the present


P a g e | 33

ClaimDateLastTransaction Definition The latest date at which the ClaimStatus changed. Example 1 | A provider submits a Claim on March 12 2007. The Payer receives the Claim on March 14 2007. Since that time the Claim has been in process with the Payer. For the Provider ClaimDateLastTransaction is 12/03/2007, whereas for the Payer ClaimDateLastTransaction is 14/03/2007 . Example 2 | A Payer receives a Claim on March 14 2007. On March 19 the Payer asks the Provider for necessary supporting detail about the Claim. The Provider has not replied since. ClaimDateLastTransaction is 19/03/2007 for both the Payer and the Provider.


Restrictions Needs to be at or after ClaimDateReceived and cannot be in the future


P a g e | 34

ClaimStatus Definition ClaimStatus describes the processing status of the Claim, from the time the provider submits the Claim to the time until the provider considers it settled. ClaimStatus is empty, until the Provider has submitted a Claim The Provider considers ClaimStatus to be

• In Process with the Payer from the time the Claim has been submitted until the Payer either asks for clarification (ClaimStatus is then Pending), settles the Claim and the settlement is received by the Provider (ClaimStatus is then PayerSettled), or the Payer chooses to actively withhold payment and has communicated this to the provider (ClaimStatus is then Withheld).

• Pending with the provider from the time the provider has received a request for clarification from the Payer until the Provider has replied to the Payer. (ClaimStatus is then In Process)

• Withheld from the time the Payer has communicated that payment is Withheld, until the Payer settles the Claim (ClaimStatus is then PayerSettled)

• PayerSettled from the time the provider receives notice of settlement, either through receipt of a settlement amount or notification that the settlement amount is 0.

• ProviderSettled as and when the Provider considers the Claim to be settled.

The Payer considers ClaimStatus to be

• In Process with the Payer from the time the Claim has received until the Payer either asks for clarification (ClaimStatus is then Pending), settles the Claim and the settlement is received by the Provider (ClaimStatus is then PayerSettled), or the Payer may choose to actively withhold payment and has communicated this to the provider (ClaimStatus is then Withheld).

• Pending with the provider from the time the Payer has made a request for clarification from the Provider until the Provider has replied to the Payer. (ClaimStatus is then In Process)

• Withheld if the Payer has fully processed the Claim to the point that it is ready to be settled, but that the Payer chooses – for a reason unrelated to the specific Claim in question – to withhold payment and has communicated this to the provider. ClaimStatus remains Withheld until the Payer settles the Claim (ClaimStatus is then PayerSettled)

• PayerSettled from the time the Payer has settled the Claim. • ProviderSettled as and when the Payer has received notification that the Provider considers the

Claim to be settled

Example | A provider submits a Claim C1 to an insurer in a batch. The insurer processes the Claim and is ready to settle it. Some other Claims in the batch are still pending with the provider, however. The insurer decides to wait for payment of the entire batch, until all Claims have been processed. The Claim C1 would have ClaimStatus Withheld. If for any reason the Payer or the Provider is unable to differentiate between

• In Process and Pending, ClaimStatus should be “InProcess or Pending” • In Process and Withheld, ClaimStatus should be “InProcess or Withheld” • Pending and Withheld, ClaimStatus should be “Pending or Withheld” • In Process, Pending and Withheld, ClaimStatus should be “Pending, In Process or Withheld”


P a g e | 35

Field type Integer

Restrictions If ClaimDateSubmitted is empty, ClaimStatus needs to be empty; only values allowed are 1= In Process with Payer 2=Pending at Provider 3=Withheld by Payer 4=PayerSettled 5=ProviderSetled 6=In Process or Pending 7=In Process or Withheld 8=Pending or Withheld 9=Pending, In Process or Withheld


P a g e | 36

EncounterID Definition A unique number assigned by the healthcare provider to identify an Encounter. Note | It will help the provider and insurer locate the Encounter. This number will also facilitate posting of payment information and identification of the billed Encounter.


Restrictions None


P a g e | 37

EncounterPatientID Definition The unique number a healthcare provider assigns to a patient. This is often known as the medical record number.


Restrictions None


P a g e | 38

EncounterFacilityID Definition This HAAD license number of the facility responsible for the Encounter. If the If the facility is not licensed by HAAD, enter “@” followed by the name of the facility


Restrictions Needs to be an element of the Attribute list FacilityID or start with “@” Some of the fields – PatientNationality, EncounterFacilityID, ClaimPayerID and EncounterDiagnosisPrincipal have a large number of sometimes changing attributes. The latest version of these attributes can be downloaded from www.haad.ae/DataUpload. See “How to submit data to HAAD” for further details.


P a g e | 39

EncounterStart Definition EncounterStart is the date and time at which the patient comes under the care of a responsible clinician.

• For Elective patients this will typically be the date and time of the visit registration/admission on arrival of the patient at the healthcare facility.

• For Emergency patients this will typically be the date and time of the registration and admission on arrival of the patient at the healthcare facility.

• For Transfer patients between facilities (i.e. inter‐hospital transfers), this will typically be the date and time of the visit registration and admission on arrival of the patient at the receiving healthcare facility.

• For Livebirth this will typically be the date and time of the registration and admission of the newborn at the healthcare facility. The Encounter start will also be the date and time of birth.

• For Stillbirth this will typically be the date and time of the registration of the stillborn at the healthcare facility. The Encounter start will also be the date and time of stillbirth.

• For Death on arrival this will typically be the date and time of the visit registration on arrival of the patient at the healthcare facility for pronouncement.

Field type DateTime. Format DD/MM/YYYY HH:MM

Restrictions Needs to be after 1/1/1900 and before the present


P a g e | 40

EncounterStartType Definition EncounterStartType is 1 = Elective, i.e., an Encounter is scheduled in advance 2 = Emergency 3 = Transfer, i.e., primarily inter‐hospital transfers, not between wards within a hospital 4 = Live birth 5 = Still birth 6 = Dead On Arrival

Example | An urgent referral from an outpatient clinic to the cardiology ward, i.e., not scheduled, would be considered as EncounterStartType 2 = Emergency, and EncounterType would be 3 = Inpatient bed + No emergency room Example | A patient is referred to a consultant, by her general practitioner, and an appointment is scheduled for two weeks later. This outpatient appointment has EncounterStartType 1= Elective. Field type Integer

Restrictions Only values allowed are 1 = Elective 2 = Emergency 3 = Transfer 4 = Live birth 5 = Still birth 6 = Dead On Arrival


P a g e | 41

EncounterType Definition 1 = No Bed + No emergency room 2 = No Bed + Emergency room 3 = Inpatient Bed + No emergency room 4 = Inpatient Bed + Emergency room 5 = Daycase Bed + No emergency room 6 = Daycase Bed + Emergency room

Note | There are different ways to classify Encounters as inpatients, daycases, emergencies and outpatients. They vary according to whether the Encounter went past midnight, lasted for more than 24 hours, involved a hospital bed and whether they involved an emergency room. To benchmark with different countries, one needs to know, whether the patient was in the emergency room, and whether the patient occupied a hospital bed. Inpatient bed | A licensed bed approved by the competent authority which is assigned to a patient who is arriving to a health care facililty for an emergent, urgent or elective/planned Encounter. Beds assigned temporarily for "holding" purposes in a no bed situation may be designated and included in hospital occupancy rate calculation (e.g. emergency room, recovery room). Only beds included in the licensed inpatient bed complement will be used for purposes of hospital occupancy rate calculation. Beds may have an associated accommodation value such as private (i.e. single bed/room) or shared (i.e. multiple beds/room). Beds included in the inpatient bed complement:

• Beds in general wards or units set up and staffed for inpatient services • Beds in special care units set up and staffed for inpatient services such as intensive care, coronary

care, neonatal intensive care, pediatric intensive care, medical and surgical step‐down, burn units

Beds excluded from the inpatient bed complement:

• Beds/cots for healthy newborns • Beds in Day Care units, such as surgical, medical, pediatric day care, interventional radiology • Beds in Dialysis units • Beds in Labor Suites (e.g. birth day beds, birthing chairs) • Beds in Operating Theatre • Temporary beds such as stretchers • Chairs, Cots or Beds used to accommodate sitters, parents, guardians accompanying patients or sick

children and healthy baby accompanying a hospitalized breast feeding mother • Beds closed during renovation of patient care areas when approved by the competent authority

Daycase bed | Daycase beds, also known as observation beds, are beds used in Day Care units such as surgical, medical, pediatric day care interventional radiology. They are not included in the inpatient bed complement. Field type Integer

Restrictions


P a g e | 42

Only values allowed are: 1 = No Bed + No emergency room 2 = No Bed + Emergency room 3 = Inpatient Bed + No emergency room 4 = Inpatient Bed + Emergency room 5 = Daycase Bed + No emergency room 6 = Daycase Bed + Emergency room


P a g e | 43

EncounterSpecialty Definition The predominant specialty of the primary caregiver for the Encounter. Note | As there are at present no detailed standardized specialty definitions, providers should use their own, pre‐existing naming conventions. Example | Urology Example | Cardiology Field type Char(‐) Restriction None


P a g e | 44

EncounterLocation Definition The name used by the provider to describe the location where the Encounter took place. If the patient visited an outpatient clinic, this would be the name used by the provider for the particular clinic. In some cases, where the patient was in multiple inpatient locations while in the healthcare facility, the discharge location should be used. If the patient was in multiple clinics on the same day, each visit would typically be a separate Encounter, and the clinic location should be reported for each Encounter. Example | ENT Clinic Example | Cardiology Ward 3 Field type Char(‐) Restriction None


P a g e | 45

EncounterEnd Definition In general this is the time the patient ceases to be under the direct care of a responsible clinician

• For inpatients and day patients this would be the discharge date and time. • For emergency patients this would be the time that the patient was released from the ER

Note | EncounterEnd is not required for outpatients, even though the field logic applies analogously to other outpatients.

Field type DateTime. Format DD/MM/YYYY HH:MM

Restrictions


P a g e | 46

EncounterEndType Definition How the patient was discharged. 1 = Discharged with approval 2 = Discharged against advice 3 = Discharged absent without leave 4 = Transfer to another facility 5 = Deceased

Field type Integer

Restrictions Only values allowed are 1 = Routine discharge home or selfcare 2 = Transfer 3 = Against Advice 4 = Absent without Leave 5 = Deceased


P a g e | 47

EncounterDiagnosisPrincipal Definition Identifies the principal diagnosis code (full ICD‐9‐CM) for the condition established after examination. It will identify the nature of a disease or illness.

• Inpatients Condition established, after study, to be chiefly responsible for occasioning the admission of the patient to the hospital for care.

• Ambulatory patients The condition or problem that explains the clinician’s assessment of the presenting symptoms/problems and corresponds to the tests or services provided. This assessment may be a suspected diagnosis or a rule‐out diagnosis and is based on the patient’s presenting history and physical and the physician’s review of symptoms. This may also be a symptom where the underlying cause has yet to be determined.

The classification is based on the International Classification for Disease version 9 clinical modification, US version, as outlined in the CodingManual published by the Abu Dhabi’s Clinical Coding Steering Committee. The coding manual can be downloaded from http://healthstatistics.pbwiki.com/f/CodingManual.doc. Background information on ICD‐9CM and coding are provided on http://healthstatistics.pbwiki.com/Coding.

Note | A number of insurers code diagnoses related to specific Claims. Where this is done, the insurer should use this diagnosis to populate EncounterDiagnosisPrincipal. Note | This field is key to understanding “what is wrong with the patient”. It contributes to understanding the health of the population. Field type Char (‐)

Restrictions the basis of a comprehensive ICD9‐CM list The latest version of these attributes can be downloaded from www.haad.ae/DataUpload. See “How to submit data to HAAD” for further details.


P a g e | 48

EncounterDiagnosisSecondary Definition

• Inpatients All conditions that co‐exist at the time of admission, or develop subsequently, which affect the treatment received and/or the length of stay. Diagnoses that refer to an earlier episode that have no bearing on the current hospital stay are to be excluded. Conditions should be coded that affect patient care in terms of requiring: Clinical evaluation, therapeutic treatment, diagnostic procedures, extended length of hospital stay, increased nursing care and/or monitoring.

• Ambulatory patients All co‐existing conditions, including chronic conditions that exist at the time of the Encounter or visit and require or affect patient management.

• External causes of injury, poisoning or adverse affect are coded as supplementary codes to the diagnosis codes of the actual condition such as “Motor Vehicle Accident” that caused a fracture of the tibia.

Note | For quality purposes, it is important to be able to track Hospital‐acquired infections. The corresponding E‐Code is 849.7 The classification is based on the International Classification for Disease version 9 clinical modification, US version, as outlined in the CodingManual published by the Abu Dhabi’s Clinical Coding Steering Committee. The coding manual can be downloaded from http://healthstatistics.pbwiki.com/f/CodingManual.doc. Background information on ICD‐9CM and coding are provided on http://healthstatistics.pbwiki.com/Coding.


Restrictions Needs to come from a comprehensive ICD9‐CM list The latest version of these attributes can be downloaded from www.haad.ae/DataUpload. See “How to submit data to HAAD” for further details.


P a g e | 49

EncounterDiagnosisAdmitting Definition The diagnosis that the physician identifies at the time of admission. Note | This diagnosis might differ from EncounterDiagnosisPrincipal. The classification is based on the International Classification for Disease version 9 clinical modification, US version, as outlined in the CodingManual published by the Abu Dhabi’s Clinical Coding Steering Committee. The coding manual can be downloaded from http://healthstatistics.pbwiki.com/f/CodingManual.doc. Background information on ICD‐9CM and coding are provided on http://healthstatistics.pbwiki.com/Coding


Restrictions The latest version of the attributes can be downloaded from www.haad.ae/DataUpload. See “How to submit data to HAAD” for further details.


P a g e | 50

EncounterTransferSource Definition EncounterTransferSource is the healthcare facility from where a hospital transfer originated (EncounterStartType = 3 Transfer) The originating healthcare facility is described by HAAD’s unique facility license number. If the patient has insurance coverage, enter HAAD’s insurance ID number If the patient does not have insurance and is paying in cash for services provided, enter (SelfPay) in this field. If the patient is neither insured by a HAAD insurance nor paying SelfPay, nor treated for Free – ProFormaPayer If another insurance, then @ “Name of the insurance”


Restrictions The latest version of these attributes can be downloaded from www.haad.ae/DataUpload. See “How to submit data to HAAD” for further details.


P a g e | 51

EncounterTransferDestination Definition EncounterTransferDestination is the healthcare facility to which a hospital transfer is made at the end of an Encounter (EncounterEndType = 4 Transfer) This is HAAD’s unique facility license number. If the patient has insurance coverage, enter HAAD’s insurance ID number If the patient does not have insurance and paying in cash for services provided, enter (SelfPay) in this field. If the patient is neither insured by a HAAD insurance nor paying SelfPay, nor treated for Free – ProFormaPayer If another insurance, then @ “Name of the insurance”




P a g e | 52

ActivityStart Definition The date and time at which Activity started. For DRGs, it is the date and time of discharge Note | If the date, but not the time is not recorded, the time should be assumed to be 00:00

Note | Activity fields are not mandatory for submission at this stage. Field type DateTime. Format DD/MM/YYYY HH:MM

Restrictions Needs to be after 1/1/1900 and before the present


P a g e | 53

ActivityType Definition ActivityType define the different types of Activity that can occur 1 = Principal procedure ICD9‐CM code

• This is the procedure performed for definitive treatment, rather than one performed for diagnostic or exploratory purposes or one that was necessary to take care of a complication. If there appear to be two procedures that are principal, then the one most related to the principal diagnosis should be selected as the principal procedure. If all procedures are diagnostic, then the one most related to the principal diagnosis.

• The classification is based on the International Classification for Disease version 9 clinical modification, US version, as outlined in the CodingManual published by the Abu Dhabi’s Clinical Coding Steering Committee. The coding manual can be downloaded from http://healthstatistics.pbwiki.com/f/CodingManual.doc

2 = Secondary procedure ICD9‐CM code

• All significant procedures are to be reported. A significant procedure is one that is surgical in nature or carries a procedural risk or carries an anesthetic risk or requires specialized training.

• The classification is based on the International Classification for Disease version 9 clinical modification, US version, as outlined in the CodingManual published by the Abu Dhabi’s Clinical Coding Steering Committee. The coding manual can be downloaded from http://healthstatistics.pbwiki.com/f/CodingManual.doc

3 = CPT code 9 = APR‐DRG code

• Some hospitals have been coding their inpatient Activity using APR‐DRGs.

Note | The introduction of DRGs as a payment system for inpatients is planned. This will require providers to code inpatient procedures, both principal as well as secondary procedures using ICD9‐CM procedures codes. Note | Over time further standard Activity types will be defined, such as for Prescriptions.

Field type Integer(‐)

Restrictions


P a g e | 54

ActivityCode Definition ActivityCode describes the ActivityType. Example | If ActivityType is 1 (Principal ICD9‐CM procedure), then ActivityCode could be 311.1, i.e., the ICD9‐CM procedure code. Example | if the ActivityType is 9 (APR‐DRG code), then ActivityCode would be the DRG in question, e.g., 124




P a g e | 55

ActivityQuantity Definition Identifies the number of units (quantity) for a specific Activity. Example | A patient is admitted to the hospital for en elective surgery and was assigned a hospital bed in a private room. The patient stayed at the hospital for 3 days at the private room. The ActivityQuantity for the private room Activity is 3. Example | A patient receives a prescription for 12 units of a pack of 10 mg Chlorpromazine tablets. ActivityQuantity is 12.

Field type Float

Restrictions


P a g e | 56

ActivityNet Definition The net charges billed by the provider to the Payer for this Activity. Note | Some activities will be charged as a line item in a Claim, such as a prescription. Other activities are not charged in their own right. For instance, in a DRG payment system, individual procedures associated with an Encounter may not be charged, but the overall Encounter is charged as a DRG‐Activity. Example | If ActivityType is 9, ActivityCode is 311, ActivityQuantity is 1, ActivityNet might be AED 8250.00 Example | If ActivityType is 1, ActivityCode is 309.3, ActivityQuantity is 1, ActivityNet might be 0, if this procedures is claimed as a DRG. Note | For non‐paying, non‐insured patients, where a pro‐forma invoice is created, this should be the gross amount that would have been charged.

Field type Float



P a g e | 57

ActivityClinician Definition The HAAD License number of the clinician or caregiver responsible for the Activity or who performed the Activity. If more than one clinician or caregiver was involved, then the caregiver who was in charge of the procedure. If the clinician is not licensed by HAAD, this should be”@” followed by the name of the clinician.

Field type Char

Restrictions Only values from Attribute List of Licensed Clinicians are allowed, unless field starts with “@”. The latest version of these attributes can be downloaded from www.haad.ae/DataUpload. See “How to submit data to HAAD” for further details.

Documents

Health Authority Abu Dhabi