Primary Navigation for the CDC Website
CDC en Español

Intimate Partner Violence Prevention banner
Technical Notes



The following Technical Notes are taken predominantly from Data Elements for Emergency Department Systems (DEEDS), Release 1.0(National Center for Injury Prevention and Control, 1997). These notes provide technical information about how the data elements in this document conform to the data types defined in Health Level 7, Version 2.3(HL7, 1996); conventions for addressing missing, unknown, and null data values; and recommendations for dealing with data elements or components of data elements that do not apply to certain individuals. For more comprehensive information about the HL7data types and the technical terms used in these notes, please refer to HL7, Version 2.3.


Data Types Used

CE — coded element CX — extended composite ID with check digit NM — numeric TS — time stamp XAD — extended address


In the data type descriptions that follow, these symbols are used to denote structural features of the data types or to indicate how entries are made in data fields. 


< > 

Angle brackets demarcate each component of a multicomponent data type. For example, the three components of the CE data type are represented as <identifier>, <text>, and <name of coding system>. 


 ( )

Parentheses enclose the abbreviation of component data types. For example, in the CE data type description, (ST) specifies that the <identifier (ST)> component is a string data type. 


The carat separates adjacent components of a multicomponent data type. For example, the CE data type is represented as <identifier (ST)>^<text (ST)>^< name of coding system (ST)>^. 


 [ ]

Square brackets specify a part of a component in which data entry is optional. For example, the [SS] in the TS . time stamp data type indicates that entering seconds is optional. 



The tilde separates multiple occurrences of a single component. For example, if names were to be recorded, the tilde in the family name Rodriguez~Garcia indicates that the person has a compound name. 



Double quotes represent null values in alphanumeric fields. For example, the entry of "" in the check digit component of the CX data type field would indicate that no check digit was used.



CE — coded element


<identifier (ST)>^<text (ST)>^<name of coding system (ST)>^

<alternate identifier (ST)>^<alternate text (ST)>^<name of alternate coding system (ST)>

This data type is composed of two parallel triplets, each of which specifies a coded identifier, a corresponding text descriptor, and a designation for the coding system from which the coded identifier is taken. The CE data type permits use of different coding systems to encode the same data. Components 1–3 comprise a triplet for the first code, and Components 4–6 comprise a triplet for the alternate code. For example, in the coding system used in this document, the code "3" (6-10 episodes) for data element 3.202 Number of episodes involving sexual violence by any intimate partner ever is coded:

3^6-10 episodes

An entry "" or Unknown in Component 1, without entries in other components, indicates that the value for the entire data element is null or unknown.

CX — extended composite ID with check digit


<ID (ST)>^<check digit (ST)>^

<code identifying the check digit scheme employed (ID)>^

<assigning authority (HD)>^<identifier type code (IS)>^<assigning facility (HD)>

This data type is used for certain fields that commonly contain check digits (e.g., internal agency identifier indicating a specific person, such as a patient or client). Component 1 contains an alphanumeric identifier. The check digit entered in Component 2 is an integral part of the identifier but is not included in Component 1. Component 3 identifies the algorithm used to generate the check digit. Component 4, <assigning authority>, is the unique name of the system that created the identifier. Component 5, <identifier type code>, is a code for the identifier type, such as MR for medical record number (see Table 0203 in HL7, Version 2.3). Component 6, <assigning facility>, is the place or location where the identifier was first assigned to the individual (e.g., University Hospital).

NM — numeric

An entry into a field of this data type is a number represented by a series of ASCII numeric characters consisting of an optional leading sign (+ or -), one or more digits, and an optional decimal point. In the absence of a + or - sign, the number is assumed to be positive. Leading zeros, or trailing zeros after a decimal point, are not meaningful. The only nonnumeric characters allowed are the optional leading sign and decimal point.

TS — time stamp



A data element of this type is string data that contains the date and time of an event. YYYY is the year, MM is the month, and DD is the day of the month. The time, HHMM, is based on a 24-hour clock in which midnight is 0000 and 2359 is 11:59 pm, and +/- ZZZZ is the offset from Greenwich Mean Time (for example -0500 is Eastern Daylight Time, and -0600 is Eastern Standard Time). If the optional +/-ZZZZ is missing, local time is assumed.

A TS data field should be left blank when the time of an event or the information is not recorded (missing data). As a convention (not an HL7 standard), 99 can be used to indicate that this information is not known:

Entry Description

Leave blank Date/time not recorded

99 Date/time unknown

1996 Year known; remainder of date/time not recorded

199699 Year known, nothing else known

199608 Year and month known; remainder of date/time not recorded

19960899 Year and month known; nothing else known


199608011600-0500 A complete date/time indicating EDT

199608011600-0600 A complete date/time indicating EST

For some events the exact date or time may be unavailable and an estimate is preferable to leaving the date/time blank or entering 99. For example, if the event is estimated to have occurred 4 days ago (assuming that today’s date is June 6, 1997), then 1997060299 would be entered. If the event is estimated to have occurred about 3 months ago, then 19970399 would be entered.

XAD — extended address


<street address (ST)>^<other designation (ST)>^<city (ST)>^<state or province (ST)>^

<zip or postal code (ST)>^<country (ID)>^<address type (ID)>^

<other geographic designation (ST)>^<county/parish code (IS)>^<census tract (IS)>

Component 1, <street address>, contains the street address, rural route designation, or post office box. Component 2, <other designation>, qualifies the address (e.g., Apt 1). Component 3, <city>, is the city name. Component 4, <state or province>, is represented by the U.S. Postal Service code. Component 5, <zip or postal code>, takes the form 99999[-9999] for a zip code or has 6 alphanumeric characters for a Canadian postal code. Component 6, <country code>, is assumed to be USA if no entry is made. Component 7, <address type>, is coded as follows:

Entry Description

C Current or temporary

P Permanent

M Mailing

B Business

O Office

H Home

F Country of origin

Component 8, <other geographic designation>, is a user’s choice that could include such designations as catchment area, EMS region, and health services area. Component 9, <county/ parish code>, represents the county or county equivalent in which the specified address is located (see HL7 Table 0289 — County/Parish). Component 10, <census tract>, is a code that represents the census tract (or enumeration district) in which the specified address is located (see HL7 Table 0288 — Census Tract).


1234 Easy Street^Suite 123^San Francisco^CA^95123^USA^B^^SF


Design Considerations for Record System Implementers

Missing, Unknown, and Null Data Values. Missing, unknown, and null data values must be addressed consistently by surveillance system implementers. The following definitions and conventions are recommended:

Missing values are values that are either not sought or not recorded. In a computerized system, missing values should always be identifiable and distinguished from unknown or null values. Typically, no keystrokes are made, and as a result alphanumeric fields remain as default characters (most often blanks) and numeric fields are identifiable as never having had entries.

Unknown values are values that are recorded to indicate that information was sought and found to be unavailable. Various conventions are used to enter unknown values: the word "Unknown" or a single character value (9 or U) for the CE – coded element data type; 99 for two or more unknown digits for the TS – time stamp data type; and 9 or a series of 9s for the NM – numeric data type. Note: the use of Unknown, U, and 9s in this document to represent values that are not known is an arbitrary choice. Other notations may be used for unknown value entries.

Null values are values that represent none or zero or that indicate specific properties are not measured. For alphanumeric fields, the convention of entering "" in the field is recommended to represent none (e.g., no telephone number), and the absence of an inquiry requires no data entry (e.g., not asking about a telephone number results in missing data). For numeric fields, the convention of entering 8 or a series of 8s is recommended to denote that a measurement was not made, preserving an entry of zero for a number in the measurement continuum. Note: the use of "" and 8s in this document to represent null values is an arbitrary choice. Other notations may be used for null value entries.

Null or unknown values in multicomponent data types (i.e., CE, CX, and XAD) are indicated in the first alphanumeric component. For example, in an XAD data type, "" or Unknown would be entered in the <street name (ST)> component to indicate there was no address or that the address was not known, and no data would be entered in the remaining components.

Data Elements and Components That Are Not Applicable. Data entry is not required in certain fields when the data elements or their components do not pertain (e.g., victim’s pregnancy status would not be applicable to male victims). Skip patterns should be used as needed to reduce data entry burdens.






Content Source: National Center for Injury Prevention and Control
Page last modified: September 25, 2008